Autor: Vitalik, fundador do Ethereum; Compilação: Deng Tong, Golden Finance

Nota: Este artigo é a quarta parte da série 'Desenvolvimentos futuros do protocolo Ethereum' do fundador do Ethereum, Vitalik, 'Futuros possíveis do protocolo Ethereum, parte 4: O Verge'. A terceira parte pode ser encontrada em 'Vitalik: Objetivos principais da fase The Scourge do Ethereum', a segunda parte em 'Vitalik: Como o protocolo Ethereum deve evoluir na fase The Surge', e a primeira parte em 'O que mais pode ser melhorado no Ethereum PoS'. Abaixo está o texto completo da quarta parte:

Agradecimentos especiais a Justin Drake, Hsiao-wei Wang, Guillaume Ballet, Ignacio, Josh Rudolf, Lev Soukhanov, Ryan Sean Adams e Uma Roy pelos feedbacks e revisões.

Uma das maiores forças do blockchain é que qualquer um pode executar um nó em seu próprio computador e validar se a cadeia está correta. Mesmo que 95% dos nós executando o consenso da cadeia (PoW, PoS...) concordem imediatamente em mudar as regras e comecem a produzir blocos sob as novas regras, cada pessoa que executa um nó totalmente verificado se recusará a aceitar essa cadeia. Stakeholders que não fazem parte desse grupo se juntarão automaticamente e continuarão a construir uma cadeia que continue a seguir as regras antigas, e os usuários totalmente verificados seguirão essa cadeia.

Esta é a diferença crucial entre blockchain e sistemas centralizados. No entanto, para manter essa característica, é necessário que a operação de nós totalmente verificados seja viável para um número crítico de pessoas. Isso se aplica tanto a stakers (como se stakers não validassem a cadeia, eles realmente não estão contribuindo para a execução das regras do protocolo) quanto a usuários comuns. Hoje, é possível executar nós em laptops de classe de consumo (incluindo o laptop usado para redigir este texto), mas fazê-lo é complicado. The Verge visa mudar isso, tornando o custo computacional da cadeia totalmente verificada tão baixo que cada carteira móvel, carteira de navegador e até mesmo relógios inteligentes façam isso por padrão.

The Verge, roteiro de 2023.

Inicialmente, 'Verge' se referia à ideia de transferir o armazenamento de estado do Ethereum para a árvore Verkle - essa estrutura de árvore permite provas mais compactas, possibilitando a validação sem estado dos blocos Ethereum. Nós podemos validar blocos Ethereum sem ter qualquer estado Ethereum (saldos de contas, código de contratos, armazenamento...) em seus discos rígidos, mas isso custa centenas de kilobytes de dados de prova e centenas de milissegundos de tempo extra para validar a prova. Hoje, o Verge representa uma visão maior, focada em realizar a validação da cadeia Ethereum com a máxima eficiência de recursos, que não apenas inclui tecnologias de validação sem estado, mas também a validação de toda a execução Ethereum usando SNARK.

Além de focar a longo prazo na validação SNARK de toda a cadeia, outra nova questão é se a árvore Verkle é a melhor tecnologia. As árvores Verkle são vulneráveis a ataques de computadores quânticos, portanto, se substituirmos a atual árvore Merkle Patricia KECCAK por uma árvore Verkle, teremos que substituir essas árvores novamente mais tarde. A alternativa natural para a árvore Merkle é pular diretamente para usar ramos Merkle STARK em uma árvore binária. Historicamente, isso foi considerado inviável devido à sobrecarga e complexidade técnica. No entanto, recentemente, vimos que a Starkware provou 1,7 milhões de hashes Poseidon por segundo em laptops com Circle STARK, e, devido a tecnologias como GKR, o tempo de prova para mais hashes 'tradicionais' também está caindo rapidamente.

Assim, ao longo do último ano, o Verge se tornou mais aberto e existem várias possibilidades.

The Verge: objetivos principais

  • Cliente sem estado: nós totalmente verificados e nós de staking não precisam de mais do que alguns GB de espaço de armazenamento.

  • (A longo prazo) validar completamente a cadeia em relógios inteligentes (consenso e execução). Baixe alguns dados, valide o SNARK e pronto.

Os seguintes tópicos estão em foco neste artigo:

  • Verificação sem estado: Verkle ou STARKs

  • Prova de validade da execução EVM

  • Prova de validade do consenso

Verificação sem estado: Verkle ou STARKs

Qual problema estamos tentando resolver?

Hoje, os clientes Ethereum precisam armazenar centenas de GB de dados de estado para validar blocos, e essa quantidade continua aumentando a cada ano. Os dados de estado originais aumentam cerca de 30 GB por ano, e clientes individuais devem armazenar alguns dados adicionais, além de serem capazes de atualizar a trie de forma eficaz.

Isso reduz o número de usuários que podem executar nós Ethereum totalmente verificados: embora os discos rígidos sejam grandes o suficiente para armazenar todo o estado Ethereum, mesmo anos de histórico, os computadores que as pessoas normalmente compram frequentemente têm apenas algumas centenas de gigabytes de espaço de armazenamento. O tamanho do estado também traz grandes dificuldades para o processo de configuração inicial do nó: o nó precisa baixar todo o estado, o que pode levar horas ou dias. Isso gera várias repercussões, como dificultar para os stakers atualizarem suas configurações de staking. Tecnicamente, isso pode ser feito sem downtime - iniciar um novo cliente, esperar que ele sincronize, e então desligar o cliente antigo e transferir a chave - mas, na prática, isso é complicado.

O que é e como funciona?

A verificação sem estado é uma técnica que permite que nós validem blocos sem ter o estado completo. Em vez disso, cada bloco vem com uma testemunha que inclui (i) valores em locais específicos do estado acessado pelo bloco (por exemplo, código, saldo, armazenamento) e (ii) provas criptográficas de que esses valores estão corretos.

A implementação real da verificação sem estado exige mudanças na estrutura da árvore de estado do Ethereum. Isso porque a atual árvore Merkle Patricia é extremamente hostil para implementar qualquer esquema de prova criptográfica, especialmente no pior caso. Tanto a 'prova' Merkle original quanto a possibilidade de 'embalar' a prova Merkle dentro do STARK são assim. As principais dificuldades vêm de duas fraquezas do MPT:

  • É uma árvore de seis ramificações (ou seja, cada nó tem 16 filhos). Isso significa que, em média, uma prova em uma árvore de tamanho N tem 32*(16-1)*log16(N) = 120*log2(N) bytes, ou cerca de 3840 bytes em uma árvore de 232 itens. Para uma árvore binária, é necessário apenas 32*(2-1)*log2(N) = 32*log2(N) bytes, ou cerca de 1024 bytes.

  • O código não está merkelizado. Isso significa que qualquer acesso que forneça código de conta precisará fornecer o código completo, com um comprimento máximo de 24000 bytes.

Podemos calcular o pior caso da seguinte forma:

30.000.000 Gas / 2.400 ('custo de leitura' de contas 'frias') * (5 * 480 + 24.000) = 330.000.000 bytes

O custo do ramo diminuiu um pouco (5*480 em vez de 8*480), pois quando há muitos ramos, o topo do ramo se repete. Mas mesmo assim, a quantidade de dados baixados dentro de um slot é completamente irrealista. Se tentarmos embrulhá-lo dentro do STARK, enfrentaremos dois problemas: (i) KECCAK não é amigável ao STARK, (ii) 330 MB de dados significam que precisamos provar 5 milhões de chamadas à função de rotação do KECCAK, que é uma maneira de que mesmo que possamos tornar a prova STARK do KECCAK mais eficiente, há muitas coisas que não podem ser provadas em todo hardware além do hardware de consumo mais poderoso.

Se apenas substituirmos a árvore de seis ramificações por uma árvore binária, além de Merkelizar o código, o pior caso se tornará aproximadamente 30.000.000 / 2.400 * 32 * (32 - 14 + 8) = 10.400.000 bytes ~214 ramos, onde 8 é o comprimento que entra em uma folha de prova). Observe que isso requer a mudança do custo de Gas para cobrar o acesso a cada bloco de código separado; o EIP-4762 faz isso. 10,4 MB é muito, mas para muitos nós, a quantidade de dados baixados dentro de um slot ainda é excessiva. Portanto, precisamos introduzir algumas tecnologias mais poderosas. Para isso, existem duas soluções principais: a árvore Verkle e a árvore hash binária Starked.

Árvore Verkle

A árvore Verkle usa compromissos vetoriais baseados em curvas elípticas para fazer provas mais curtas. A chave é que, independentemente da largura da árvore, cada segmento de prova correspondente a uma relação pai-filho tem apenas 32 bytes. O único limite na largura da árvore é que, se ela for muito larga, a eficiência de cálculo da prova diminuirá. A implementação sugerida do Ethereum tem uma largura de 256.

Assim, o tamanho de um único ramo na prova se torna 32*log256(N) = 4*log2(N) bytes. O tamanho máximo teórico da prova se torna cerca de 30.000.000/2.400*32*(32-14+8)/8 = 1.300.000 bytes (devido à distribuição desigual dos blocos de estado, o cálculo matemático é ligeiramente diferente na prática, mas isso serve como um bom primeiro passo).

Como um aviso adicional, observe que em todos os exemplos acima, essa 'pior situação' não é a pior situação: a situação pior é que um atacante intencionalmente 'minera' dois endereços para ter um longo prefixo comum na árvore e lê de um deles, o que pode aumentar o comprimento do ramo no pior caso em cerca de 2x. Mas mesmo com tal aviso, a árvore Verkle ainda nos permite obter cerca de 2,6 MB de prova no pior caso, que se alinha razoavelmente com os dados de chamada no pior caso de hoje.

Nós também aproveitamos esse aviso para fazer outra coisa: tornamos o acesso à 'memória adjacente' muito barato: muitos blocos de código do mesmo contrato ou slots de armazenamento adjacentes. O EIP-4762 fornece a definição de adjacência, e o acesso adjacente custa apenas 200 Gas. Para acesso adjacente, o tamanho da prova no pior caso se torna 30.000.000/200*32 = 4.800.800 bytes, que ainda está razoavelmente dentro da margem de tolerância. Se desejarmos reduzir esse valor por segurança, podemos aumentar levemente o custo de acesso adjacente.

Árvore binária hash estendida com estrela

A tecnologia aqui não é muito trivial: você faz uma árvore binária, pega a prova max-10.4-MB que você precisa para provar os valores dentro de um bloco e substitui essa prova pelo STARK dessa prova. Isso nos mostra que a prova em si contém apenas os dados provados, mais a sobrecarga fixa de cerca de 100-300 kB do STARK.

O principal desafio aqui é o tempo de prova. Podemos fazer cálculos praticamente idênticos aos acima, exceto que não calculamos bytes, mas hashes. Um bloco de 10,4 MB significa 330.000 hashes. Se adicionarmos a possibilidade de um atacante 'minerar' endereços na árvore com um longo prefixo comum, o verdadeiro pior caso se tornará cerca de 660.000 hashes. Portanto, se pudermos provar cerca de 200.000 hashes por segundo, estaremos bem.

Esses números já foram alcançados em laptops de consumo com a função hash Poseidon, que foi projetada especificamente para ser amigável ao STARK. No entanto, Poseidon é relativamente imaturo, então muitas pessoas ainda não confiam em sua segurança. Portanto, existem duas direções realistas a seguir:

  • Análises de segurança rápidas e extensivas sobre Poseidon e familiarização com ele para implantá-lo na L1.

  • Usar uma função hash mais 'conservadora', como SHA256 ou BLAKE.

No momento da redação, o provador STARK da Starkware pode provar cerca de 10-30k hashes por segundo em laptops de consumo, se tiver que provar uma função hash conservadora. No entanto, a tecnologia STARK está avançando rapidamente. Mesmo hoje, as técnicas baseadas em GKR mostram potencial promissor para elevar isso para cerca de 100-200k.

Casos de uso de testemunhas além da validação de blocos

Além da validação de blocos, há outros três casos de uso-chave para realizar verificações sem estado mais eficientes:

  • Pool de memória: quando uma transação é transmitida, os nós na rede p2p precisam validar se a transação é válida antes de retransmiti-la. Hoje, a validação envolve não apenas verificar a assinatura, mas também verificar se o saldo é suficiente e se o nonce está correto. No futuro (por exemplo, usando a abstração de conta nativa, como no EIP-7701), isso pode envolver a execução de algum código EVM, que acessa alguns estados. Se o nó for sem estado, a transação precisará vir com uma prova de que o objeto de estado é válido.

  • Lista de inclusão: esta é uma funcionalidade proposta que permite que validadores de prova de participação (que podem ser pequenos e não complexos) forcem o próximo bloco a incluir certas transações, independentemente da vontade do construtor do bloco (que pode ser grande e complexo). Isso diminuiria a capacidade de participantes poderosos manipular a blockchain através da demora de transações. No entanto, isso exige que os validadores tenham uma forma de validar a eficácia das transações na lista de inclusão.

  • Cliente leve: se quisermos que os usuários acessem a cadeia através de wallets (como Metamask, Rainbow, Rabby...) sem confiar em participantes centralizados, eles precisam executar clientes leves (como Helios). O módulo central do Helios fornece aos usuários a raiz de estado verificada. No entanto, para uma experiência completamente sem confiança, os usuários precisam fornecer provas para cada chamada RPC individual que fazem (por exemplo, para uma solicitação eth_call, o usuário precisa de provas para todos os estados acessados durante a chamada);

Um ponto comum em todos esses casos de uso é que eles exigem uma quantidade considerável de provas, mas cada prova é pequena. Portanto, a prova STARK não faz sentido para eles; em vez disso, usar diretamente os ramos Merkle é mais realista. Outra vantagem dos ramos Merkle é que eles são atualizáveis: dado uma prova de um objeto de estado X com raiz do bloco B, se você receber um sub-bloco B2 com seus testemunhas, você pode atualizar essa prova para que ela tenha B2 como raiz. Provas Verkle também são atualizáveis.

Quais são as conexões com a pesquisa existente?

Árvore Verkle: https://vitalik.eth.limo/general/2021/06/18/verkle.html

Artigo original da árvore Verkle de John Kuszmaul: https://math.mit.edu/research/highschool/primes/materials/2018/Kuszmaul.pdf

Dados de provas Starkware: https://x.com/StarkWareLtd/status/1807776563188162562

Artigo Poseidon2: https://eprint.iacr.org/2023/323

Ajtai (função hash rápida alternativa baseada na dureza de rede): https://www.wisdom.weizmann.ac.il/~oded/COL/cfh.pdf

Verkle.info: https://verkle.info/

O que mais precisa ser feito, quais trade-offs precisam ser considerados?

O principal trabalho que resta a ser feito é:

  • Mais análises sobre as consequências do EIP-4762 (mudanças de custo de gas sem estado)

  • Mais trabalho concluído e testes do programa de transição, que é uma grande parte da complexidade de qualquer EIP sem estado

  • Mais análises de segurança sobre funções hash 'amigáveis ao STARK', como Poseidon, Ajtai e outras

  • Desenvolvimento adicional de protocolos STARK ultraeficientes para funções hash 'conservadoras' (ou 'tradicionais'), como ideias baseadas em Binius ou GKR.

Em breve, tomaremos uma decisão sobre qual dos três pontos de decisão a seguir: (i) árvore Verkle, (ii) função hash amigável ao STARK, e (iii) função hash conservadora. Suas propriedades podem ser resumidas aproximadamente na tabela abaixo:

Além desses 'números de cabeçalho', há algumas outras considerações importantes:

  • Hoje, o código da árvore Verkle já é bastante maduro. Usar qualquer coisa fora do Verkle realmente atrasaria a implementação, muito provavelmente através de um hard fork. Isso pode não ser um problema, especialmente se ainda precisarmos de tempo extra para análise de funções hash ou implementação do provador, e se tivermos outras funcionalidades importantes que gostaríamos de incluir no Ethereum o mais cedo possível.

  • Usar hash para atualizar a raiz de estado é mais rápido do que usar a árvore Verkle. Isso significa que metodologias baseadas em hash podem reduzir o tempo de sincronização de nós completos.

  • A árvore Verkle tem propriedades interessantes de atualização de testemunhas - as testemunhas da árvore Verkle são atualizáveis. Essa propriedade é útil para pools de memória, listas de inclusão e outros casos de uso, e também pode ajudar a melhorar a eficiência da implementação: se o objeto de estado for atualizado, você pode atualizar a testemunha do penúltimo nível sem mesmo precisar ler o último nível.

  • Provas Verkle são mais difíceis de provar com SNARK. Se quisermos reduzir o tamanho da prova para alguns milhares de bytes, as provas Verkle apresentam algumas dificuldades. Isso porque a validação das provas Verkle introduz uma quantidade significativa de operações de 256 bits, o que exige que o sistema de prova tenha uma grande sobrecarga ou tenha sua própria estrutura interna customizada que inclua partes de 256 bits para as provas Verkle.

Se quisermos que a atualizabilidade das testemunhas Verkle ocorra de forma quântica segura e razoavelmente eficiente, uma outra possível abordagem seria a árvore Merkle baseada em grelha.

Se o sistema de prova não é eficaz o suficiente no pior caso, podemos usar outro 'coelho que saiu do chapéu' para compensar essa falta, que é o Gas multidimensional: ter limites de Gas separados para (i) calldata, (ii) computação, (iii) acesso a estado e possivelmente outros recursos diferentes. O Gas multidimensional aumenta a complexidade, mas, em troca, limita mais estritamente a razão entre a média e o pior caso. Para o Gas multidimensional, o número máximo teórico de ramos a serem provados pode diminuir de 30.000.000 / 2400 = 12.500 para 3.000. Isso tornará o BLAKE3 (justamente) suficiente mesmo hoje, sem mais melhorias na prova.

Gas multidimensional permite que as limitações de recursos dos blocos se aproximem mais das limitações de recursos do hardware subjacente.

Outro 'coelho que apareceu' é a proposta de atrasar o cálculo da raiz de estado até o slot após o bloco. Isso nos daria 12 segundos inteiros para calcular a raiz de estado, o que significa que, mesmo no pior caso, apenas cerca de 60.000 hashes/segundo de tempo de prova seriam suficientes, colocando-nos novamente no âmbito de BLAKE3, apenas o suficiente.

A desvantagem desse método é que ele aumenta o atraso do cliente leve em um período, embora a tecnologia tenha versões mais inteligentes que podem reduzir esse atraso apenas para o atraso na geração da prova. Por exemplo, assim que qualquer nó gera uma prova, essa prova pode ser transmitida na rede, em vez de esperar o próximo bloco.

Como isso interage com outras partes do roteiro?

Resolver o problema sem estado aumentou consideravelmente a conveniência do staking individual. Se a tecnologia para reduzir o saldo mínimo de staking individual (por exemplo, Orbit SSF ou estratégias de camada de aplicativo, como staking em equipe) se tornar disponível, isso se tornará mais valioso.

Se o EOF for introduzido ao mesmo tempo, o Gas multidimensional se tornará mais fácil. Isso ocorre porque uma das complexidades chave do Gas multidimensional para execução é lidar com chamadas filhas que não passam o Gas completo do pai, enquanto o EOF simplesmente tornará tais chamadas filhas ilegais (e a abstração de conta nativa fornecerá uma alternativa de protocolo para o uso principal do Gas em chamadas filhas atualmente).

Outra sinergia importante é a interação entre verificação sem estado e a expiração histórica. Hoje, os clientes precisam armazenar quase um TB de dados históricos; esses dados são várias vezes maiores do que os dados de um estado nacional. Mesmo que o cliente seja apátrida, a menos que possamos aliviar a responsabilidade do cliente de armazenar a história, o sonho de um cliente quase sem armazenamento não pode ser realizado. O primeiro passo nesse sentido é o EIP-4444, que também significa armazenar dados históricos em redes torrent ou Portal.

Prova de validade da execução EVM

Qual problema estamos tentando resolver?

O objetivo de longo prazo da validação de blocos Ethereum é claro: você deve ser capaz de validar um bloco Ethereum da seguinte maneira: (i) baixar o bloco, ou talvez apenas baixar uma pequena parte do bloco e realizar amostragem de disponibilidade de dados, e (ii) validar uma pequena parte que prove que o bloco é válido. Isso seria uma operação que consome poucos recursos e poderia ser realizada em um cliente móvel, carteira de navegador ou mesmo (sem a parte de disponibilidade de dados) em outra cadeia.

Para alcançar isso, é necessário ter (i) provas SNARK ou STARK para a camada de consenso (ou seja, prova de participação) e (ii) para a camada de execução (ou seja, EVM). O primeiro é um desafio em si e deve ser resolvido no processo de melhorar a camada de consenso (por exemplo, determinismo de slot único). O último requer provas da execução da EVM.

O que é e como funciona?

Formalmente, no padrão Ethereum, a EVM é definida como uma função de transição de estado: você tem algum estado anterior S, um bloco B e está calculando um estado posterior S' = STF(S, B). Se o usuário estiver usando um cliente leve, ele não tem S e S', nem mesmo B completo; em vez disso, ele tem uma raiz de estado anterior R, uma raiz de estado posterior R' e um hash de bloco H. A declaração completa que precisa ser provada é aproximadamente:

  • Entradas públicas: raiz de estado anterior R, raiz de estado posterior R', hash de bloco H.

  • Entrada privada: objetos no estado acessado pelo bloco B e bloco Q, o mesmo objeto após a execução do bloco Q', prova de estado (por exemplo, ramo Merkle) P.

  • Alegação 1: P é uma prova válida de que Q inclui algumas partes do estado representadas por R.

  • Alegação 2: Se você executar STF em Q, (i) a execução acessa apenas os objetos dentro de Q, (ii) o bloco é válido, e (iii) o resultado é Q'.

  • Alegação 3: Se você recalcular a nova raiz de estado usando as informações de Q' e P, você obterá R'.

Se existir, você poderá ter um cliente leve que verifica completamente a execução da EVM do Ethereum. Isso já reduz os recursos do cliente. Para ter um verdadeiro cliente Ethereum totalmente verificado, você também precisará fazer o mesmo para a parte do consenso.

A implementação da prova de validade da EVM já existe e é amplamente utilizada por L2. No entanto, para tornar a prova de validade da EVM aplicável à L1, há muito trabalho a ser feito.

Quais são as conexões com a pesquisa existente?

EC PSE ZK-EVM (agora obsoleto, pois existem opções melhores): https://github.com/privacy-scaling-explorations/zkevm-Circuits

Zeth, que funciona compilando EVM para RISC-0 ZK-VM: https://github.com/risc0/zeth

Projeto de validação formal ZK-EVM: https://verified-zkevm.org/

O que mais precisa ser feito, quais trade-offs precisam ser considerados?

Hoje, a prova de validade da EVM é inadequada em dois aspectos: segurança e tempo de prova.

Provas de segurança e eficácia precisam garantir que SNARK realmente valida o cálculo EVM e que não há erros. As duas principais técnicas para aumentar a segurança são múltiplos provadores e verificação formal. Múltiplos provadores significam ter várias implementações de prova de validade escritas de forma independente, assim como ter vários clientes, e se um subconjunto suficientemente grande dessas implementações prova um bloco, permite que o cliente aceite esse bloco. A verificação formal envolve o uso de ferramentas comumente usadas para provar teoremas matemáticos (por exemplo, Lean4) para provar que as provas de validade aceitam apenas entradas que são execuções corretas da especificação EVM subjacente escrita em Python.

Tempos de prova suficientemente rápidos significam que qualquer bloco Ethereum pode ser provado em menos de 4 segundos. Hoje, ainda estamos longe desse objetivo, embora estejamos muito mais próximos do que imaginávamos há dois anos. Para alcançar esse objetivo, precisamos avançar em três áreas:

  • Paralelização - Os provadores EVM mais rápidos de hoje podem provar um bloco Ethereum médio em cerca de 15 segundos. Isso é alcançado através da paralelização entre centenas de GPUs e, em seguida, agregando seu trabalho no final.

Implementar isso apresenta desafios. Mesmo no pior caso (ou seja, transações muito grandes ocupando todo o bloco), a divisão dos cálculos não pode ser feita por transação; deve ser feita por opcode (EVM ou VM subjacente, como RISC-V). Um dos principais desafios de implementação que torna isso não totalmente trivial é garantir que a 'memória' da VM seja consistente entre diferentes partes da prova. No entanto, se pudermos fazer essa prova recursiva, sabemos que pelo menos o problema do atraso do provador foi resolvido, mesmo que não haja melhorias em qualquer outro eixo.

  • Otimização do sistema de provas - novos sistemas de prova como Orion, Binius, GKR podem levar a uma redução significativa no tempo de prova para computação geral novamente.

  • O consumo de Gas da EVM está sujeito a outras mudanças - muitas coisas na EVM podem ser otimizadas para serem mais amigáveis aos provadores, especialmente no pior caso. Se um atacante puder construir um bloco que tome dez minutos do provador, então simplesmente provar um bloco médio do Ethereum em 4 segundos não será suficiente. As mudanças necessárias na EVM podem ser divididas em duas categorias principais:

  • Mudanças de custo de Gas - se uma operação leva muito tempo para ser provada, então, mesmo que a velocidade de computação seja relativamente rápida, deve ter um custo de Gas mais alto. O EIP-7667 é um EIP proposto para lidar com o problema mais sério nesse aspecto: ele aumenta significativamente o custo de Gas para funções hash (tradicionais) que são relativamente baratas como opcode e pré-compilados. Para compensar esse aumento de custo de Gas, podemos reduzir o custo de Gas para opcodes EVM relativamente baratos, mantendo a mesma média de throughput.

  • Substituição de estruturas de dados - além de substituir a árvore de estado por alternativas mais adequadas ao STARK, também precisamos substituir listas de transações, árvores de recibos e outras estruturas de alto custo de prova. O EIP de Ethan Kissling move estruturas de transações e recibos para SSZ ([1] [2] [3]), que é um passo nessa direção.

Além disso, os dois 'coelhos que saíram do chapéu' mencionados na seção anterior (Gas multidimensional e raiz de estado atrasada) também podem ajudar aqui. No entanto, vale a pena notar que, ao contrário da verificação sem estado, a verificação sem estado significa que temos tecnologia suficiente para fazer o que precisamos hoje, mesmo que, utilizando essas tecnologias, a verificação completa do ZK-EVM ainda exigirá mais trabalho - apenas precisará de menos esforço.

Uma coisa não mencionada acima é o hardware de prova: usar GPUs, FPGAs e ASICs para gerar provas mais rapidamente. Fabric Cryptography, Cysic e Accseal são as três empresas que estão impulsionando isso. Isso é extremamente valioso para a camada 2, mas é improvável que se torne um fator decisivo para a camada 1, uma vez que há um forte desejo de manter a camada 1 altamente descentralizada, o que significa que a geração de provas deve estar dentro da capacidade de um subconjunto considerável de usuários do Ethereum, não devendo encontrar gargalos de hardware de uma única empresa. A camada 2 pode fazer trade-offs mais radicais.

Há mais trabalho a ser feito nesses domínios:

  • Provas paralelas exigem um sistema de prova onde diferentes partes da prova podem 'compartilhar memória' (por exemplo, tabelas de busca). Conhecemos a tecnologia para fazer isso, mas ela precisa ser implementada.

  • Precisamos de mais análises para identificar o conjunto ideal de variações de custo de Gas para minimizar o tempo de prova no pior caso.

  • Precisamos fazer mais trabalho no sistema de prova.

As compensações possíveis aqui incluem:

  • Segurança e tempo do provador: a escolha ativa de funções hash, sistemas de prova com complexidade ou suposições de segurança mais robustas ou outras escolhas de design pode reduzir o tempo do provador.

  • Descentralização e tempo do provador: a comunidade precisa chegar a um consenso sobre as 'especificações' do hardware do provador que visa. É aceitável exigir que os provadores sejam entidades de grande escala? Queremos que laptops de consumo de ponta possam provar blocos Ethereum em 4 segundos? Algo entre os dois?

  • O grau de ruptura da compatibilidade retroativa: as deficiências em outros domínios podem ser compensadas por mudanças mais agressivas no custo de gas, mas isso é mais provável de aumentar desproporcionalmente o custo de certos aplicativos e forçar os desenvolvedores a reescrever e redistribuir código para manter a viabilidade econômica. Da mesma forma, os 'coelhos no chapéu' têm suas próprias complexidades e desvantagens.

Como isso interage com outras partes do roteiro?

As tecnologias centrais necessárias para implementar a prova de validade da EVM na camada 1 compartilham muito com os outros dois domínios:

  • Prova de validade da camada 2 (ou seja, 'ZK rollups')

  • Método 'STARK Binary Hash Proof' sem estado

A implementação bem-sucedida da prova de validade na camada 1 pode permitir staking individual final e fácil: mesmo os computadores mais fracos (incluindo smartphones ou relógios inteligentes) podem participar do staking. Isso aumenta ainda mais o valor de resolver outras limitações do staking individual (por exemplo, o mínimo de 32 ETH).

Além disso, a prova de validade da EVM na L1 pode aumentar significativamente o limite de Gas da L1.

Prova de validade do consenso

Qual problema estamos tentando resolver?

Se quisermos ser capazes de validar blocos Ethereum completamente com SNARK, então a execução EVM não é a única parte que precisamos provar. Também precisamos provar o consenso: a parte do sistema que lida com depósitos, saques, assinaturas, atualizações de saldo dos validadores e outros elementos da parte de prova de participação do Ethereum.

O consenso é muito mais simples que a EVM, mas enfrenta o desafio de que não temos um EVM da camada 2, que também é a razão pela qual a maior parte do trabalho ainda precisa ser feita. Portanto, qualquer implementação de prova de consenso Ethereum precisará ser feita 'do zero', embora o sistema de provas em si possa ser construído sobre o trabalho compartilhado.

O que é e como funciona?

A cadeia beacon é definida como uma função de transição de estado, assim como a EVM. A função de transição de estado é determinada por três fatores:

  • ECADD (para validar assinaturas BLS)

  • Emparelhamento (para validar assinaturas BLS)

  • SHA256 hash (para leitura e atualização do estado)

Para cada bloco, precisamos provar de 1 a 16 ECADD BLS12-381 para cada validador (pode não ser apenas um, pois a assinatura pode estar incluída em várias agregações). Isso pode ser compensado através de técnicas de pré-cálculo de subconjuntos, então podemos dizer que cada validador é um ECADD BLS12-381. Hoje, há cerca de 30.000 validadores assinando por período. No futuro, para a finalização de um único slot, isso pode mudar em qualquer direção (veja a explicação aqui): se tomarmos a rota 'forçada', o número de validadores por slot pode aumentar para 1 milhão. Ao mesmo tempo, usando Orbit SSF, isso ficará em 32.768 ou até reduzirá para 8,1.

Como funciona a agregação BLS. Validar assinaturas agregadas requer apenas ECADD de cada participante, não ECMUL. Mas 30.000 ECADD ainda requer muitas provas.

Para emparelhamento, atualmente há no máximo 128 provas por slot, o que significa que 128 emparelhamentos precisam ser validados. Com o EIP-7549 e mais mudanças, isso pode ser reduzido para 16 por slot. O número de pares é pequeno, mas o custo é muito alto: o tempo de execução (ou prova) de cada par é milhares de vezes mais longo que o ECADD.

Um dos principais desafios de provar operações BLS12-381 é a falta de curvas convenientes cuja ordem de curva seja igual ao tamanho do campo BLS12-381, o que adiciona uma quantidade considerável de sobrecarga a qualquer sistema de prova. Por outro lado, a árvore Verkle proposta para Ethereum foi construída com a curva Bandersnatch, o que torna a BLS12-381 a curva natural a ser usada em sistemas SNARK para provar os ramos Verkle. Uma implementação bastante simples pode oferecer cerca de 100 adições G1 por segundo; quase certamente precisará de técnicas inteligentes como GKR para provar rapidamente.

Para valores hash SHA256, o pior caso atual é um bloco de transição de época, onde toda a árvore de saldo de validadores e muitos saldos de validadores são atualizados. A árvore de saldo de validadores curtos tem apenas um byte por validador, então cerca de 1 MB de dados será re-hashado. Isso corresponde a 32.768 chamadas SHA256. Se o saldo de mil validadores estiver acima ou abaixo do limite, será necessária uma atualização do saldo efetivo nos registros dos validadores, o que corresponde a mil ramos Merkle, então pode haver mais de 10.000 valores hash. O mecanismo de embaralhamento requer 90 bits por validador (portanto, 11 MB de dados), mas isso pode ser calculado em qualquer momento durante um processo de época. O embaralhamento se torna desnecessário, embora a órbita possa de alguma forma restaurar a necessidade de embaralhamento.

Outro desafio é a necessidade de ler todos os estados dos validadores (incluindo chaves públicas) para validar um bloco. Para 1 milhão de validadores, mais o ramo Merkle, apenas ler as chaves públicas requer 48 milhões de bytes. Isso requer milhões de hashes por época. Se hoje tivermos que provar a validação de prova de participação, uma abordagem realista seria algum tipo de computação verificável incremental: armazenar uma estrutura de dados separada no sistema de prova que seja otimizada para buscas eficientes e forneça atualizações para essa estrutura.

Em suma, existem muitos desafios.

Para resolver esses desafios da maneira mais eficaz, pode ser necessário um redesenho profundo da cadeia beacon, o que pode acontecer ao mesmo tempo que a mudança para a finalização de slot único. As características desse redesenho podem incluir:

  • Mudanças na função hash: hoje, usamos a função hash SHA256 'completa', portanto, devido ao preenchimento, cada chamada corresponde a duas chamadas de função de compressão subjacente. Pelo menos, podemos obter um ganho de 2 ao mudar para a função de compressão SHA256. Se mudarmos para Poseidon, podemos obter um ganho de cerca de 100, o que poderia resolver todos os nossos problemas (pelo menos para hashing): 1,7 milhões de hashes por segundo (54 MB), e mesmo 'ler um milhão de registros de validadores' pode ser provado em 'poucos segundos'.

  • Se for Orbit, armazene diretamente os registros de validadores embaralhados: se você escolher um certo número de validadores (por exemplo, 8.192 ou 32.768) como o comitê para um dado slot, coloque-os diretamente em estados adjacentes, de modo que a quantidade mínima de hashes seja necessária para ler todas as chaves públicas dos validadores na prova. Isso também permitirá que todas as atualizações de saldo sejam realizadas de forma eficiente.

  • Agregação de assinaturas: qualquer esquema de agregação de assinaturas de alto desempenho provavelmente envolve algum tipo de prova recursiva, onde a prova intermediária do subconjunto de assinaturas é feita por vários nós na rede. Isso distribui naturalmente a carga da prova entre muitos nós na rede, diminuindo assim a carga de trabalho do 'provedor final'.

  • Outros esquemas de assinatura: para assinaturas Lamport+Merkle, precisamos de 256+32 hashes para validar a assinatura; multiplicado por 32.768 signatários, isso resulta em 9.437.184 hashes. A otimização de esquemas de assinatura pode melhorar isso ainda mais com um pequeno fator constante. Se usarmos Poseidon, isso está dentro do escopo da prova dentro de um único slot. Mas na prática, através de um esquema de agregação recursivo, isso se tornará mais rápido.

Quais são as conexões com a pesquisa existente?

Conciso, prova de consenso Ethereum (apenas comitê de sincronização): https://github.com/succinctlabs/eth-proof-of-consensus

Conciso, Helios no SP1: https://github.com/succinctlabs/sp1-helios

BLS12-381 pré-compilado conciso: https://blog.succinct.xyz/succinctshipsprecompiles/

Verificação de assinaturas agregadas BLS baseada em Halo2: https://ethresear.ch/t/zkpos-with-halo2-pairing-for-verifying-aggregate-bls-signatures/14671

O que mais precisa ser feito, quais trade-offs precisam ser considerados?

Na verdade, pode levar anos para obter provas de validade para o consenso do Ethereum. Isso se alinha mais ou menos com o cronograma necessário para implementar a finalização de slot único, mudanças em esquemas de assinatura e análises de segurança potenciais, para que haja confiança suficiente para usar funções hash 'radicais' como Poseidon. Portanto, resolver essas outras questões é mais significativo, e ao fazer esse trabalho, devemos manter em mente a amigabilidade do STARK.

Os principais trade-offs provavelmente estarão na ordem de operação, entre um método mais incremental para reformar a camada de consenso do Ethereum e um método mais radical de 'mudar muitas coisas de uma vez'. Para a EVM, um método incremental faz sentido, pois minimiza a ruptura da compatibilidade retroativa. Para a camada de consenso, as questões de compatibilidade retroativa são menores e é benéfico repensar de forma mais 'abrangente' os vários detalhes de como a cadeia beacon é construída para otimizar melhor a amigabilidade do STARK.

Como isso interage com outras partes do roteiro?

A amigabilidade do STARK precisa se tornar um foco principal do redesenho de longo prazo do consenso de prova de participação do Ethereum, mais notavelmente a finalização de slot único, Orbit, mudanças em esquemas de assinatura e agregação de assinaturas.