Novo artigo de Vitalik: O possível futuro da Ethereum, The Verge

Título original: "Possíveis futuros do protocolo Ethereum, parte 4: The Verge"

Autor original: Vitalik Buterin

Original compilation: Mensh, ChainCatcher

Agradecemos especialmente os comentários e revisões de Justin Drake, Hsia-wei Wanp, Guillaume Ballet, Icinacio, Rosh Rudolf, Lev Soukhanoy, Ryan Sean Adams e Uma Roy.

Uma das funcionalidades mais poderosas do Bloco é que qualquer pessoa pode executar um Nó em seu próprio computador e verificar a correção do Bloco. Mesmo que 9596 Nós executando o Consenso da cadeia (PoW, PoS) concordem imediatamente em alterar as regras e comecem a produzir Bloco de acordo com as novas regras, qualquer pessoa que execute um Nó de verificação completa irá recusar a cadeia. Os mineiros que não fazem parte desse grupo conspiratório automaticamente se reunirão em uma cadeia que continua a seguir as regras antigas e continuarão a construir essa cadeia, enquanto os usuários totalmente verificados seguirão essa cadeia.

Esta é a diferença fundamental entre blockchain e sistemas centralizados. No entanto, para que esta característica seja válida, é necessário que seja viável para um número suficiente de pessoas executar um nó completamente validado. Isso se aplica tanto aos validadores (porque se eles não validarem a cadeia, eles não contribuem para a execução das regras do protocolo) quanto aos usuários comuns. Hoje em dia, é possível executar um nó em um laptop de consumo (incluindo o laptop usado para escrever este artigo), mas é difícil de fazer. O Verge visa mudar isso, reduzindo o custo computacional de uma cadeia completamente validada e tornando a validação padrão para cada carteira de celular, carteira de navegador e até mesmo smartwatch.

O Mapa de Estradas do Verge 2023

Inicialmente, "Verge" referia-se à transferência do estado da Ethereum para a árvore Verkle - uma estrutura de árvore que permite provas mais compactas, permitindo a verificação sem estado dos blocos Ethereum. Um Nó pode verificar um bloco Ethereum sem armazenar qualquer estado da Ethereum (saldo da conta, código de contrato, espaço de armazenamento...) em seu disco, à custa de alguns dados de prova de alguns KB e um tempo extra de algumas centenas de milissegundos para verificar uma prova. Hoje, Verge representa uma visão maior, concentrando-se na máxima eficiência de recursos da cadeia Ethereum, que inclui não apenas a tecnologia de verificação sem estado, mas também a verificação de SNARK para todas as execuções Ethereum.

Além da validação a longo prazo de toda a cadeia pelo SNARK, outra nova questão tem a ver com se a árvore Verkle é a melhor técnica. A árvore Verkle é vulnerável ao Computador quântico, por isso, se pegarmos a árvore Verkle na atual árvore KECCAK Merkle Patricia, teremos que substituir a árvore novamente no futuro. Uma auto-alternativa para uma árvore Merkle é simplesmente pular o STARK que usa o ramo Merkle e colocá-lo em uma árvore binária. Historicamente, esta abordagem tem sido considerada inviável devido à sobrecarga e complexidade técnica. Recentemente, porém, vimos Starkware provar 1,7 milhão de hashes Poseidon por segundo usando ckcle STARKs em um único laptop, e o tempo de prova para valores de hash mais "tradicionais" está diminuindo rapidamente graças a tecnologias como GKB. Então, ao longo do último ano, "Verge" se tornou mais aberto, tem várias possibilidades.

The Verge: Objetivo chave

• Cliente sem estado: O espaço de armazenamento necessário para a validação completa do cliente e a marcação do Nó não deve exceder alguns GB.
• (Long-term) Validate the chain (Consenso) and execution on the smartwatch completely. Download some data, validate SNARK, and complete.

Neste capítulo

• Cliente sem estado: Verkle ou STARKs
• prova de validade executada pelo EVM
• Consenso的prova de validade

Verificação sem estado: Verkle ou STARKs

Que problema estamos a tentar resolver?

Atualmente, o cliente ETH precisa armazenar centenas de gigabytes de dados de estado para verificar o Bloco, e esse número está aumentando a cada ano. Os dados de estado originais aumentam cerca de 30 GB por ano, e o cliente individual deve armazenar dados adicionais para atualizar efetivamente o triplo.

Isso reduz o número de usuários capazes de executar um Nó Ethereum completo: embora haja discos rígidos disponíveis com capacidade suficiente para armazenar todo o estado do Ethereum e até mesmo anos de histórico, os computadores que as pessoas normalmente compram vêm com apenas alguns gigabytes ou terabytes de armazenamento. O tamanho do estado também introduz uma grande fricção no processo de estabelecimento inicial do Nó: o Nó precisa baixar todo o estado, o que pode levar horas ou até dias. Isso gera várias reações em cadeia. Por exemplo, isso torna muito mais difícil para os criadores de Nós atualizarem suas configurações de Nó. Tecnicamente, é possível fazer uma atualização sem interrupção - iniciando um novo cliente, esperando a sincronização e, em seguida, desligando o cliente antigo e transferindo a Chave Secreta - mas, na prática, isso é extremamente complicado.

Como funciona isso?

A validação sem estado é uma técnica que permite que os Nós verifiquem o Bloco sem possuir todo o estado. Em vez disso, cada Bloco vem com uma testemunha que inclui: (i) o valor, o código, o saldo e o armazenamento em uma posição específica do estado que o Bloco acessará; (ii) a prova da encriptação que comprova que esses valores estão corretos.

Na verdade, a implementação da verificação sem estado requer mudanças na estrutura da árvore de estado do Ethereum. Isso ocorre porque a árvore Merkle Patricia atual é extremamente desfavorável para a implementação de qualquer esquema de prova de encriptação, especialmente nos piores casos. Isso também se aplica tanto aos ramos "originais" do Merblk quanto às possibilidades de serem "empacotados" como STARK. A principal dificuldade advém de algumas fraquezas do MPT:

1. Esta é uma árvore de seis vias (ou seja, cada Nó tem 16 nós filhos). Isso significa que, em uma árvore de tamanho N, uma prova requer em média 32*(16-1)*log 16(N) = 120* log 2(N) bytes, ou cerca de 3840 bytes em uma árvore com 2 ^ 32 itens. Para uma árvore binária, apenas 32*(2-1)*log 2(N) = 32* log 2(N) bytes, ou cerca de 1024 bytes.

2. O código não foi merkleizado. Isso significa que para provar qualquer acesso ao código da conta, é necessário fornecer o código completo, com um máximo de 24000 bytes.

Podemos calcular o pior cenário da seguinte forma:

30000000 gás / 2400 (custo de leitura fria da conta) * (5 * 488 + 24000) = 330000000 bytes

O custo do ramo é ligeiramente Gota (usando 5* 480 em vez de 8* 480), porque quando há muitos ramos, a parte superior será repetida. No entanto, mesmo assim, a quantidade de dados a ser baixada em um intervalo de tempo é completamente irrealista. Se tentarmos encapsulá-lo com STARK, enfrentaremos dois problemas: (i) KECCAK não é amigável para STARK; (ii) 330 MB de dados significa que devemos provar 5 milhões de chamadas para a função de rodada KECCAK, o que pode não ser comprovado para qualquer hardware que não seja o mais poderoso, mesmo que possamos tornar a eficiência da prova STARK para KECCAK mais alta.

Se substituirmos a árvore hexadecimal por uma árvore binária e processarmos o código adicionalmente com Merkle, o pior cenário seria de cerca de 10400000 bytes (30000000/2400 * 32 * (32-14 + 8)), com 14 sendo a subtração dos bits redundantes para o ramo de 2 ^ 14 e 8 sendo o comprimento da prova do bloco de código que entra nas folhas. É importante observar que isso altera o custo de gás, cobrando por acesso a cada bloco de código individualmente; EIP-4762 faz isso. 10,4 MB de capacidade é muito melhor, mas para muitos Nós, ainda há muitos dados para baixar em um intervalo de tempo. Portanto, precisamos introduzir tecnologias mais poderosas. Nesse sentido, existem duas soluções líderes: árvores Verkle e árvores binárias STARKed.

Verkle Tree

A árvore Verkle usa compromissos de vetor baseados em curvas elípticas para provas mais curtas. A chave de desbloqueio é que, independentemente da largura da árvore, cada parte da prova correspondente a uma relação pai-filho tem apenas 32 bytes. A única restrição na largura da árvore de prova é que, se a árvore for muito larga, a eficiência do cálculo da prova será reduzida. A implementação proposta para Ethereum tem uma largura de 256.

Portanto, o tamanho de um único ramo de prova se torna 32 - 1 og 256(N) = 4 * log 2(N) bytes. Portanto, o tamanho máximo teórico de uma prova é aproximadamente de 130000 bytes (devido à distribuição desigual dos blocos de estado, os resultados reais podem ser ligeiramente diferentes, mas como uma primeira aproximação está correto).

Além disso, é importante observar que, em todos os exemplos acima, o 'pior caso' não é realmente o pior caso: o pior caso seria um atacante 'minerar' dois Endereços que tenham um prefixo comum mais longo na árvore e ler dados de um desses Endereços, o que poderia estender o comprimento do ramo do pior caso em até o dobro. No entanto, mesmo nesse caso, o comprimento da prova do pior caso da árvore Verkle é de 2,6 MB, o que é essencialmente consistente com os dados de verificação atuais no pior caso.

Também fizemos outra coisa usando esta precaução: tornamos o custo de acesso ao espaço de armazenamento "vizinho" muito baixo: ou muitos blocos de código do mesmo contrato ou slots de armazenamento adjacentes. A EIP-4762 fornece uma definição de adjacência e cobra apenas 200 gás para acesso adjacente. No caso de acesso adjacente, o tamanho da prova no pior caso se torna 30000000 / 200 * 32 - 4800800 bytes, ainda dentro da faixa de tolerância. Se quisermos reduzir esse valor para fins de segurança, podemos aumentar ligeiramente o custo de acesso adjacente.

STARKed Binary Hash Tree

O princípio desta tecnologia é autoexplicativo: basta criar uma árvore binária, obter uma prova de 10,4 MB, provar o valor no bloco e depois substituir a prova pelo STARK da prova. Desta forma, a prova em si só contém os dados a serem provados, além de um custo fixo de 100-300 kB do STARK real.

O principal desafio aqui é validar o tempo. Podemos fazer cálculos semelhantes aos acima, mas em vez de calcular o número de bytes, calculamos o valor de hash. Um bloco de 10,4 MB significa 330.000 valores de hash. Se considerarmos também a possibilidade de um atacante 'minerar' um endereço com um longo prefixo comum na árvore, o pior caso seria em torno de 660.000 valores de hash. Portanto, se pudermos provar que temos 200.000 valores de hash por segundo, não há problema.

Em laptops de consumo que usam a função hash Poseidon, esses números já foram atingidos, e a função hash Poseidon é projetada especificamente para ser amigável ao STARK. No entanto, o sistema Poseidon ainda é relativamente imaturo, então muitas pessoas ainda não confiam em sua segurança. Portanto, existem dois caminhos realistas a seguir:

1. Realize uma análise de segurança em massa rápida do Poseidon e familiarize-se o suficiente com ele para implantá-lo no L1.
2. Usar funções de hash mais "conservadoras", como SHA 256 ou BLAKE

Para provar a conservação de uma função de hash, o círculo STARK da Starkware só pode provar 10-30k valores de hash por segundo em um laptop de consumo ao escrever este artigo. No entanto, a tecnologia STARK está melhorando rapidamente. Mesmo hoje, a tecnologia baseada em GKR mostra a capacidade de aumentar essa velocidade para a faixa de 100-200k.

Exemplos de uso de testemunho fora da validação de blocos

Além da validação do Bloco, existem outros três casos de uso críticos que exigem uma validação sem estado mais eficiente:

• Pool de memória: Quando uma transação é transmitida, os Nós na rede P2P precisam verificar se a transação é válida antes de retransmiti-la. Atualmente, essa verificação inclui a validação da assinatura, bem como a verificação do saldo e do prefixo correto. No futuro (por exemplo, usando a abstração de contas nativas, como o EIP-7701, isso pode envolver a execução de algum código EVM, que fará algumas operações de acesso de estado. Se o Nó for sem estado, a transação precisará incluir uma prova de estado do objeto.
• Inclui lista: Esta é uma funcionalidade proposta que permite que os validadores de Prova de Estaca (possivelmente em pequena escala e não complexa) forcem o próximo Bloco a incluir transações, independentemente da vontade dos construtores de Bloco (possivelmente em grande escala e complexos). Isso enfraquecerá a capacidade dos detentores de poder de manipular a cadeia de Blocos através da latência de transação. No entanto, os validadores precisam ter um meio de verificar a validade das transações incluídas na lista.
• cliente ligeiro: Se quisermos que os usuários acessem a cadeia por meio de uma carteira (como Metamask, Rainbow, Rabby, etc.), eles precisam executar um cliente ligeiro (como o Helios). O módulo central do Helios fornece aos usuários uma raiz de estado verificada. E, para obter uma experiência totalmente confiável, os usuários precisam fornecer provas para cada chamada de RPC que fazem (por exemplo, para uma solicitação de chamada para a rede ETH, os usuários precisam provar acesso a todos os estados acessados durante o processo de chamada).

Todos esses casos de uso têm uma coisa em comum: eles exigem muitas provas, mas cada prova é pequena. Portanto, as provas STARK não têm significado prático para eles; em vez disso, a abordagem mais realista é usar diretamente os ramos de Merkle. Outra vantagem dos ramos de Merkle é que eles são atualizáveis: dado um estado X com raiz no Bloco B e sua prova, se receber um subbloco B2 e sua testemunha, é possível atualizar a prova para ter raiz no Bloco B2. As provas Verkle também são nativamente atualizáveis.

Quais são as conexões com pesquisas existentes:

• Árvores Verkle
• O artigo original de John Kuszmaul sobre a árvore Verkle
• Starkware
• Poseidon 2 papel
• Ajtai (Função de hash alternativa rápida baseada na dureza da rede)
• Verkle.info

O que mais posso fazer?

O trabalho principal restante é

1. Mais análise sobre as consequências da EIP-4762 (mudança nos custos de gás sem estado)

2. Concluir e testar mais trabalhos de transição, que são a parte principal da complexidade de qualquer plano de implementação sem país

3. Mais análises de segurança sobre as funções de hash Poseidon, Ajtai e outros 'STARK-friendly'.

4. Para desenvolver ainda mais as capacidades de alto desempenho do protocolo STARK "conservador" (ou "tradicional") hash, como visões baseadas em Binius ou GKR.

Além disso, em breve vamos decidir entre as três opções a seguir: (i) árvore Verkle, (ii) função de hash amigável ao STARK e (iii) função de hash conservadora. Suas características podem ser resumidas aproximadamente na tabela abaixo:

Além desses "números do título", existem outros fatores importantes a serem considerados:

• Hoje em dia, o código da árvore Verkle está bastante maduro. Além do Verkle, usar qualquer outro código atrasará a implantação, possivelmente atrasando um hard forquilha. Isso não é um problema, especialmente se precisarmos de tempo adicional para análise de função hash ou implementação de validador, ou se tivermos outros recursos importantes que desejamos incluir mais cedo no Ethereum.
• Atualizar a raiz do estado usando um valor de hash é mais rápido do que usar uma árvore Verkle. Isso significa que o método baseado em hash pode reduzir o tempo de sincronização de um Nó completo.
• A árvore Verkle tem propriedades de testemunho atualizáveis interessantes - o testemunho da árvore Verkle é atualizável. Esta propriedade é útil para mempool, 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, o testemunho da penúltima camada pode ser atualizado sem ler o conteúdo da última camada.
• Verkle torna a prova SNARK mais difícil. Se quisermos reduzir o tamanho da prova para alguns milhares de bytes, a prova Verkle trará algumas dificuldades. Isso ocorre porque a verificação da prova Verkle introduz muitas operações de 256 bits, o que exige que o sistema de prova tenha um grande custo ou uma estrutura interna personalizada que contenha a parte de prova Verkle de 256 bits. Isso não é um problema em si para o estado sem estado, mas traz mais dificuldades.

Se quisermos obter a verificabilidade atualizável do Verkle de maneira segura e eficiente em termos de quantização, outra possibilidade é a árvore de Merkle baseada em lattice.

Se, no pior caso, ficar provado que a eficiência do sistema não é suficientemente alta, podemos usar ferramentas inesperadas de gás multidimensional para compensar essa deficiência: (i) calldata; (ii) cálculo; (iii) acesso a estado e possíveis outras configurações de recursos diferentes com limites de gás separados. O gás multidimensional aumenta a complexidade, mas, em troca, ele restringe estritamente a relação entre casos médios e casos extremos. Com gás multidimensional, o número máximo de ramos teóricos que precisam ser provados pode ser reduzido de 12500 para, por exemplo, 3000. Isso tornaria o BLAKE 3 (apenas) suficiente mesmo nos dias de hoje.

O gás multidimensional permite que os recursos do bloco se aproximem mais dos limites de recursos do hardware subjacente

Outra ferramenta inesperada é calcular a latência do estado raiz após o bloco. Isso nos dá um total de 12 segundos para calcular o estado raiz, o que significa que, mesmo em cenários extremos, apenas 60000 provas de trabalho por segundo seriam suficientes, o que nos leva a acreditar que o BLAKE 3 apenas atende aos requisitos com dificuldade.

A desvantagem deste método é que irá aumentar a latência de um intervalo de tempo cliente ligeirolatência, mas existem técnicas mais inteligentes que podem reduzir esta latência para apenas a geração de prova de latência. Por exemplo, a prova pode ser transmitida na rede imediatamente após a geração em qualquer Nó, em vez de esperar pelo próximo Bloco.

Como isso se interage com outras partes do roteiro?

Resolver o problema de estado zero aumenta significativamente a dificuldade de equilíbrio individual. Se houver tecnologia para equilibrar o ponto único mínimo, como a estratégia Orbit SSF ou Camada de aplicação, como o ponto da equipe, isso se tornará mais viável.

Se EOF for introduzido ao mesmo tempo, a análise de gás multidimensional se tornará mais fácil. Isso ocorre porque a complexidade de execução mais importante do gás multidimensional vem do processamento de chamadas de sub-rotina que não passam todo o gás da chamada pai, e EOF só precisa tornar tais chamadas de sub-rotina inválidas, para tornar este problema insignificante (e fornecer um protocolo interno alternativo para o uso atual principal de gás de algumas partes da conta nativa).

Entre a validação sem estado e a expiração do histórico, há uma importante interação. Atualmente, os clientes devem armazenar quase 1 TB de dados históricos; esses dados são várias vezes maiores do que os dados de estado. Mesmo que os clientes sejam sem estado, a menos que possamos aliviar a responsabilidade de armazenamento de dados históricos dos clientes, o sonho de ter clientes sem armazenamento será quase impossível de se concretizar. O primeiro passo nesse sentido é o EIP-4444, o que também significa armazenar os dados históricos em torrents ou na rede do portal do site.

Execução EVM de prova de validade

Que problema estamos a tentar resolver?

O objetivo a longo prazo da verificação do bloco ETH é claro - deve ser possível verificar o bloco ETH de várias maneiras: (i) baixando o bloco ou mesmo apenas uma pequena parte dos dados de amostragem de disponibilidade de dados do bloco; (ii) verificando uma pequena prova de que o bloco é válido. Isso seria uma operação de baixo consumo de recursos que pode ser concluída em um cliente móvel, uma carteira de navegador ou até mesmo em outra cadeia (sem a parte de disponibilidade de dados).

Para alcançar isso, é necessário provar (i) a camada de consenso (ou seja, prova de participação) e (ii) a camada de execução (ou seja, EVM) com SNARK ou STARK. O primeiro é um desafio em si, que deve ser resolvido no processo contínuo de melhoria da camada de consenso (por exemplo, em relação à finalidade de uma única ranhura). O último requer prova de execução EVM.

O que é isso, como funciona?

Do ponto de vista formal, no Ethereum, a EVM é definida como uma função de transição de estado: você tem um estado anterior S, um Bloco B, e está a calcular um estado posterior S' = STF(S, B). Se um usuário estiver a utilizar um cliente ligeiro, ele não possui completamente o S e o S', nem mesmo E; em vez disso, ele possui uma raiz de estado anterior R, uma raiz de estado posterior R' e um valor de hash de Bloco H.

• Entrada pública: raiz de estado anterior R, raiz de estado posterior R', hash de bloco H
• Entrada privada: objetos no estado acessados pelo corpo principal do bloco B, bloco de programa Q, objetos iguais após a execução do bloco de programa Q', e prova de estado (como ramificação de Merkle) P
• A alegação 1: P é uma prova válida de que Q contém algumas partes do estado representado por R
• A alegação 2: Se STF for executado em Q, (i) o processo de execução só acessa objetos internos de Q, (ii) os blocos de dados são válidos, (iii) o resultado é Q'
• A afirmação 3: Se recalcularmos a nova raiz do estado usando as informações de Q' e P, obteremos R'

Se houver essa possibilidade, você pode ter um cliente leve que execute uma validação completa da EVM do ETH. Isso torna os recursos do cliente bastante baixos. Para um cliente ETH completo validado de verdade, também é necessário fazer o mesmo trabalho em termos de Consenso.

A implementação de prova de validade para cálculos EVM já existe e é amplamente utilizada em L2. No entanto, ainda há muito trabalho a ser feito para tornar a prova de validade EVM viável em L1.

Quais são as conexões com pesquisas existentes?

• EFPSE ZK-EVM (descontinuado devido a opções superiores)
• Zeth, seu funcionamento envolve compilar a EVM no RISC-0 ZK-VM
• Projeto de Verificação formal ZK-EVM

O que mais posso fazer?

如今，电子记账系统的prova de validade在两个方面存在不足：安全性和验证时间。

Uma prova de validade segura deve garantir que o SNARK realmente verifique o cálculo do EVM e não tenha falhas. As duas principais técnicas para melhorar a segurança são múltiplos validadores e validação formal. Múltiplos validadores referem-se a várias implementações independentes de prova de validade, assim como vários clientes, onde se um bloco for comprovado por um subconjunto suficientemente grande dessas implementações, o cliente aceitará o bloco. A validação formal envolve o uso de ferramentas normalmente usadas para provar teoremas matemáticos, como Lean 4, para provar que a prova de validade aceita apenas a execução correta da especificação subjacente do EVM (por exemplo, a semântica EVM-K ou a especificação de execução da camada ETH em python, EELS).

Um tempo de verificação rápido significa que qualquer bloco da cadeia de blocos ETH pode ser verificado em menos de 4 segundos. Hoje em dia, ainda estamos longe desse objetivo, embora estejamos muito mais perto do que imaginávamos há dois anos. Para alcançar este objetivo, precisamos progredir em três direções:

• Paralelização - atualmente, o verificador mais rápido da EVM pode provar um bloco Ethereum em média em 15 segundos. Isso é alcançado paralelizando entre centenas de GPUs e depois agregando seu trabalho no final. Em teoria, sabemos completamente como criar um verificador de EVM que pode provar computações em tempo O(log(N)): deixe uma GPU completar cada etapa e depois faça uma "árvore de agregação".

Implementar isso apresenta desafios. Mesmo no pior caso, em que uma transação muito grande ocupa todo o bloco, a divisão do cálculo não pode ser feita sequencialmente, mas sim por códigos de operação (opcodes) da máquina virtual subjacente (EVM ou RISC-V, por exemplo). Garantir a consistência da 'memória' da máquina virtual entre diferentes partes da prova é um desafio chave na implementação. No entanto, se pudermos realizar essa prova recursiva, sabemos que, mesmo sem melhorias em outras áreas, pelo menos o problema de latência do verificador foi resolvido.

• Otimização do sistema de prova - Novos sistemas de prova, como Orion, Binius, GRK e outras informações adicionais, provavelmente resultarão em uma redução significativa no tempo de verificação da computação geral.
• Outras mudanças no custo do gás EVM - Muitas coisas no EVM podem ser otimizadas para serem mais favoráveis aos validadores, especialmente nos piores casos. Se um atacante puder construir um Bloco que bloqueie os validadores por dez minutos, então levar apenas 4 segundos para provar um Bloco ETH comum não seria suficiente. As alterações necessárias na EVM podem ser divididas em várias categorias:

• A mudança no custo do gás - Se uma operação leva muito tempo para ser comprovada, mesmo que sua velocidade de cálculo seja relativamente rápida, deve ter um alto custo de gás. EIP-7667 é um EIP proposto para lidar com esse problema grave: ele aumenta significativamente o custo de gás das funções hash (tradicionais), pois os códigos de operação e pré-compilação dessas funções são relativamente baratos. Para compensar o aumento do custo de gás, podemos ajustar o custo de gás dos códigos de operação da EVM com baixo custo de prova Gota, mantendo assim o throughput médio.

• A substituição da estrutura de dados - Além de substituir a árvore de estado por um método mais amigável para STARK, também precisamos substituir a lista de transações, a árvore de recibos e outras estruturas de custo de prova elevado. A mudança das estruturas de transações e recibos para SSZ por meio do EIP de Etan Kissling é um passo nesta direção.

Além disso, os dois recursos mencionados na seção anterior (gás multidimensional e estado raiz de latência) também podem ajudar nesse aspecto. No entanto, vale ressaltar que, ao contrário da verificação sem estado, usar esses dois recursos significa que já temos a tecnologia necessária para concluir o trabalho que precisamos atualmente, e mesmo com o uso dessa tecnologia, a verificação completa do ZK-EVM exigirá mais trabalho - apenas menos trabalho é necessário.

Um ponto não mencionado acima é o hardware do verificador de provas: usar GPU, FPGA e ASIC para gerar provas mais rapidamente. Fabric Cryptography, Cysic e Accseal são três empresas que estão avançando nesse aspecto. Isso é muito valioso para a L2, mas é pouco provável que seja um fator decisivo para a L1, pois as pessoas desejam fortemente que a L1 mantenha uma alta descentralização, o que significa que a geração de provas deve estar dentro de um alcance razoável para os usuários do Ethereum e não deve ser limitada pelo gargalo de hardware de uma única empresa. A L2 pode fazer balanços mais ativos.

Nesses campos, ainda há mais trabalho a ser feito:

• A prova de paralelismo exige que as várias partes do sistema possam "compartilhar memória" (como tabelas de pesquisa). Sabemos como fazer isso, mas precisamos implementá-lo.
• Precisamos realizar mais análises para identificar o conjunto ideal de custos de gás, a fim de minimizar o tempo de verificação em situações adversas.
• Precisamos fazer mais trabalho na área de sistemas de prova

O custo possível é:

• Segurança e Tempo do Validador: Se escolher uma função hash mais agressiva, um sistema de prova mais complexo ou assumir suposições de segurança mais agressivas ou outros esquemas de design, pode diminuir o tempo do validador.
• Descentralização e Prova de Tempo: A comunidade precisa chegar a um consenso sobre as 'especificações' do hardware do provador em questão. É viável que o provador seja uma entidade de grande escala? Podemos esperar que um laptop de consumo de alta qualidade possa provar um bloco ETH em 4 segundos? Ou algo entre os dois?
• Grau de quebra de compatibilidade retroativa: Outras deficiências podem ser compensadas por mudanças mais ativas no custo do gás, mas isso provavelmente aumentará desproporcionalmente os custos de algumas aplicações, forçando os desenvolvedores a reescrever e implantar novamente o código para manter a viabilidade econômica. Da mesma forma, essas duas ferramentas também têm sua própria complexidade e desvantagens.

Como interage com as outras partes do roteiro?

A tecnologia central necessária para implementar o L1 EVM prova de validade é amplamente compartilhada com outros dois domínios:

• prova de validade do L2 (ou "ZK rollup")
• Método de prova de hash binário "STARK" sem estado

Ao alcançar sucesso em prova de validade na L1, será possível realizar facilmente stake individual: mesmo os computadores mais fracos (incluindo telefones ou smartwatches) podem realizar stake. Isso aumenta ainda mais o valor de superar outras restrições do stake individual (como o limite mínimo de 32 ETH).

Além disso, a prova de validade EVM do L1 pode aumentar significativamente o limite de gás do L1.

Consenso de prova de validade

Que problema estamos a tentar resolver?

Se quisermos verificar completamente um bloco de zona ETH usando SNARK, a execução do EVM não é a única parte que precisamos provar. Também precisamos de atestação, ou seja, parte do sistema que lida com depósitos, levantamentos, assinaturas, atualizações de saldo do validador e outras partes do Prova de Staking do bloco ETH.

Consenso é muito mais simples do que EVM, mas o desafio é que não temos convoluções L2 EVM, então a maior parte do trabalho tem que ser feito de qualquer maneira. Portanto, qualquer implementação do Proof ETH Square Consenso precisaria ser "do zero", mesmo que o próprio Sistema de Provas seja um esforço compartilhado que pode ser construído em cima dele.

O que é isso, como funciona?

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

• ECADD（用于验证 BLS 签名）
• Par (usado para verificar assinatura BLS)
• Valor Hash SHA 256 (usado para leitura e atualização de estado)

Em cada bloco, precisamos provar 1-16 BLS 12-381 ECADD para cada validador (possivelmente mais de um, pois as assinaturas podem estar contidas em várias coleções). Isso pode ser compensado por técnicas de pré-computação de subconjuntos, então podemos dizer que cada validador só precisa provar um BLS 12-381 ECADD. Atualmente, existem 30.000 assinaturas de validadores por slot. No futuro, isso pode mudar em duas direções à medida que a finalidade de um único slot for alcançada: se tomarmos a rota da "força bruta", o número de validadores por slot pode aumentar para 1 milhão. Ao mesmo tempo, se o Orbit SSF for adotado, o número de validadores permanecerá em 32.768 ou até diminuirá para 8.192.

Como funciona a agregação BLS: a verificação da assinatura total requer apenas um ECADD de cada participante, em vez de um ECMUL. No entanto, 30000 ECADD ainda é uma quantidade significativa de prova.

No que diz respeito a emparelhamentos, atualmente cada slot pode ter no máximo 128 provas, o que significa que 128 emparelhamentos precisam ser verificados. Com ElP-7549 e modificações adicionais, cada slot pode ser reduzido para 16. O número de emparelhamentos é pequeno, mas o custo é extremamente alto: o tempo de execução (ou prova) de cada emparelhamento é várias vezes maior que o ECADD.

Um dos principais desafios da computação BLS 12-381 é a falta de uma curva de ordem conveniente igual ao tamanho do campo BLS 12-381, o que adiciona um grande custo a qualquer sistema de prova. Por outro lado, a árvore Verkle proposta para o Ethereum é construída com a curva Bandersnatch, tornando o próprio BLS 12-381 uma curva autônoma usada para provar os ramos Verkle em sistemas SNARK. Uma implementação simples pode provar a adição de 100 G1 por segundo; para tornar a prova suficientemente rápida, quase certamente serão necessárias técnicas sofisticadas, como GKR.

Para o valor hash SHA 256, a pior situação atual é a conversão de época do bloco, onde toda a árvore de equilíbrio curto do validador e muitos equilíbrios de validadores serão atualizados. Cada árvore de equilíbrio curto do validador tem apenas um byte, então 1 MB de dados será re-hashed. Isso equivale a 32768 chamadas de SHA 256. Se mil validadores tiverem saldo acima ou abaixo de um limite, o saldo efetivo dos validadores no registro precisará ser atualizado, o que equivale a mil ramos de Merkle, portanto, podem ser necessárias dez mil chamadas de hash. O mecanismo de embaralhamento requer 90 Bit por validador (portanto, requer 11 MB de dados), mas isso pode ser calculado a qualquer momento durante uma época. Em caso de término de slot único, esses números podem variar dependendo da situação. O embaralhamento se torna desnecessário, embora a Orbit possa restaurar essa necessidade em certa medida.

Outro desafio é a necessidade de recuperar todo o estado dos validadores, incluindo Chave pública, para verificar um Bloco. Para 1 milhão de validadores, apenas a leitura da Chave pública requer 48 milhões de bytes, além do ramo de Merkle. Isso requer milhões de valores hash para cada época. Se precisarmos provar a validade do PoS, um método viável é algum tipo de cálculo verificável incremental: armazenar uma estrutura de dados separada dentro do sistema de prova, otimizada para pesquisa eficiente e para provar atualizações para essa estrutura.

Em suma, há muitos desafios. Para lidar de forma mais eficaz com esses desafios, provavelmente será necessário um redesenho profundo da cadeia beacon, o que pode ocorrer ao mesmo tempo em que se passa para o término do slot único. As características desse redesenho podem incluir:

• A mudança na função hash: agora estamos usando a função hash SHA 256 'completa', portanto, devido ao preenchimento, cada chamada precisa corresponder a duas chamadas de função de compressão de nível inferior. Se mudarmos para a função de compressão SHA 256, poderemos obter pelo menos o dobro do benefício. Se mudarmos para Poseidon, poderemos obter um aumento de 100 vezes, resolvendo completamente todos os nossos problemas (pelo menos no aspecto do valor hash): 1,7 milhões de valores hash por segundo (54 MB), mesmo um milhão de registros de verificação podem ser 'lidos' em alguns segundos no comprovante.
• Se for Orbit, armazene diretamente os registros de validadores embaralhados: se um determinado número de validadores (como 8192 ou 32768) for escolhido como comitê para uma determinada fenda, eles são colocados diretamente ao lado do estado um do outro, de modo que apenas o mínimo de hash seja necessário para ler as chaves públicas de todos os validadores na prova. Isso também permite que todas as atualizações de saldo sejam concluídas de forma eficiente.
• Agregação de assinaturas: Qualquer esquema de agregação de assinaturas de alto desempenho envolverá algum tipo de prova recursiva, onde diferentes Nó na rede farão a prova intermediária do subconjunto de assinaturas. Isso naturalmente distribui o trabalho de prova para vários Nó na rede, reduzindo significativamente a carga de trabalho do "provar final".
• Outros esquemas de assinatura: Para Lamport+ Merkle assinam, precisamos de 256 + 32 valores hash para verificar a assinatura; multiplicado por 32768 signatários, obtemos 9437184 valores hash. Após a otimização do esquema de assinatura, esse resultado pode ser melhorado ainda mais por um fator constante muito pequeno. Se usarmos Poseidon, isso pode ser provado em um único slot. No entanto, na prática, o esquema de agregação recursiva será mais rápido.

Quais são as conexões com pesquisas existentes?

• Prova de Consenso da Ethereum (apenas para comissão de sincronização) concisa
• Helios dentro do SP 1 conciso
• Precompilação BLS 12-381 concisa
• Verificação de assinatura de conjunto BLS baseada em Halo 2

Quais outros trabalhos precisam ser feitos e como escolher:

Na verdade, levaríamos vários anos para obter prova de validade do Consenso Ethereum. Isso é aproximadamente o mesmo tempo necessário para alcançar a finalidade de uma única posição, Orbit, modificar o Algoritmo de assinatura e realizar uma análise de segurança, com a análise de segurança exigindo confiança suficiente para usar funções de hash "agressivas" como Poseidon. Portanto, a abordagem mais sensata seria resolver esses outros problemas e, ao fazê-lo, considerar a amigabilidade do STARK.

A principal consideração provavelmente será a ordem das operações, entre uma abordagem mais progressiva para reformar a camada de consenso Ethereum e uma abordagem mais radical de 'mudar muitas coisas de uma vez'. Para o EVM, a abordagem progressiva é razoável, pois minimiza a interferência na compatibilidade com versões anteriores. Para a camada de consenso, o impacto na compatibilidade com versões anteriores é menor e há benefícios em repensar de forma mais 'abrangente' os vários detalhes da construção da cadeia beacon, otimizando a amigabilidade do SNARK da melhor maneira.

Como isso se interage com outras partes do roteiro?

Ao redesenhar a PoS do Ethereum a longo prazo, a amigabilidade do STARK deve ser a consideração primordial, especialmente para a finalidade única de slot, Orbit, alteração do esquema de assinatura e agregação de assinaturas.