Ethereum tem um problema de verificabilidade zk? – zk-s(nt)arcas

Para construir o projeto que mencionei neste tópico comecei a aprender sobre zk-SNARKs. Uma das coisas que entendo é que o esquema de assinatura ECDSA e o hash SHA-3 (anteriormente conhecido como Keccak) não funcionam bem com zk-SNARKs porque resultam em circuitos massivos. IIUC, EdDSA com certas curvas e o hash Poseidon se saem muito melhor nesse aspecto, com circuitos que podem ser centenas de vezes menores.

Hashing e verificação de assinaturas são casos de uso muito comuns em contratos inteligentes do Solidity, mas o Solidity usa SHA-3 para hashes e AFAIK todas as carteiras Ethereum são baseadas em ECDSA. Isso significa que todos os contratos inteligentes do Solidity são inerentemente difíceis de provar em zk-SNARKs? Em caso afirmativo, como o Polygon zkEVM resolveu esse problema? Qual esquema zk-SNARK ele usa (Groth16 / PLONK / PLONKish / Halo2 / outro)?

Olá @71104,

Não, os contratos do Solidity não são “inerentemente” impossíveis para o SNARK – o que é caro são os primitivos EVM que você escolheu: KECCAK256 (opcode 0x20) e ECRECOVER (secp256k1 ECDSA).
Em circuitos zk, ECDSA-on-secp256k1 e Keccak, geralmente, explodem contagens de restrições: um verificador Circom ECDSA tem restrições de ~ 1,5 M (existe uma implementação de ~ 200.000), enquanto um verificador EdDSA (baby-Jubjub) + Poseidon tem apenas alguns milhares (~ 4,2k – 10k), ou seja, duas ordens de magnitude menores.

O Polygon zkEVM lida com isso não alterando o Solidity, mas construindo gadgets/circuitos personalizados para aquelas operações hostis ao ZK, agrupando-os em lote e, em seguida, provando toda a execução do EVM com um pipeline de vários estágios:

1. Circuitos PIL/STARK para correção de opcode/máquina de estado,
2. Recursão e agregação STARK usando uma aritmetização PLONKish com portas/pesquisas personalizadas,
3. envolva o grande STARK em um pequeno SNARK (FFLONK) que é verificado no Ethereum por meio da pré-compilação de emparelhamento.

A primeira, porém, deveria ser extremamente difundida, considerando que todos mappingvamos usá-lo. Você não pode fazer muito sem o Keccak256, nem mesmo implementar um ERC-20.

Sim, você está certo. Porém, a maioria das funções hash não são muito compatíveis com zk e pode levar algum tempo para chegar ao estágio de hardware em que essas funções hash se tornem uma tarefa fácil.

Sim, o ethereum atual é MUITO abaixo do ideal para prova, e é exatamente por isso que temos iniciativas como https://www.poseidon-initiative.info/ , que, se bem-sucedidas, nos permitiria substituir o keccak por um hash muito mais fácil de provar (e podemos fazer o mesmo com a VM, etc.)

Interessante, eu não sabia disso!

Por curiosidade, por que você escolheu Poseidon em vez de, por exemplo, Pedersen? Você está pensando em investir seus esforços no ecossistema Halo2 em vez do Circom? Se sim, por quê?

(Fiz a mesma escolha para meu próprio projeto, mas estou curioso para ouvir seu raciocínio.)

Pedersen não é resistente a quantum.

Em geral, não estamos interessados ​​em nada que não seja resistente a quantum para grandes atualizações do Ethereum neste momento.

Olá, sou o autor de um artigo recente que explora exatamente o problema que você está descrevendo.

Em meu artigo, ZK-ACE (autorização de conhecimento zero centrada na identidade), proponho uma abordagem diferente:

• Mudar o Paradigma: Em vez de verificar o próprio objeto de assinatura, provamos a autorização semântica de uma transação.
• Circuitos Minimalistas: Ao usar um compromisso de identidade ancorado na cadeia, o circuito só precisa executar alguns hashes compatíveis com ZK (como Poseidon).
• Escalabilidade massiva: Isso reduz o circuito para apenas ~1.400 restrições R1CS, independentemente da complexidade do esquema de assinatura subjacente.

Essencialmente, passamos da verificação O(n) (onde n é o tamanho da assinatura) para O(1) provas de tamanho constante. Ele evita o problema do “circuito massivo” tratando a assinatura como um artefato de geração de provas que nunca precisa tocar no blockchain.

Eu adoraria ouvir sua opinião sobre se esse modelo centrado na identidade poderia ser um caminho mais sustentável para transações Ethereum que comprovem ZK. ArXiv: 2603.07974

Obrigado,
Jasão