Anteriormente na leitura: "Vitalik sobre o possível futuro da Éter (um): The Merge", "Vitalik sobre o possível futuro da Éter (dois): The Surge", "Vitalik sobre o possível futuro da Éter (três): The Scourge"

Agradecimentos especiais a Justin Drake, Hsia-wei Wanp, Guillaume Ballet, Icinacio, Rosh Rudolf, Lev Soukhanoy, Ryan Sean Adams e Uma Roy pelos seus comentários e revisões.

Uma das funcionalidades mais poderosas do Nó Bloco é que qualquer pessoa pode executar um Nó em seu próprio computador e verificar a correção da cadeia do Bloco. Mesmo que os 9596 Nós que executam o consenso da cadeia (PoW, PoS) concordem imediatamente em alterar as regras e começar a produzir Blocos de acordo com as novas regras, qualquer pessoa que execute um Nó de verificação completo rejeitará a cadeia. Os mineradores que não fazem parte desse grupo conspiratório se reunirão automaticamente 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 a blockchain e os 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 executarem um Nó totalmente verificado. Isso se aplica tanto aos mineradores (pois se eles não verificarem a cadeia, não estarão contribuindo para a execução das regras do protocolo) quanto aos usuários regulares. Atualmente, é possível executar um Nó em laptops de consumo (incluindo o laptop utilizado para escrever este artigo), mas isso é difícil de ser feito. O Verge pretende mudar essa situação, tornando o custo computacional de uma cadeia totalmente verificada acessível, para que cada carteira de celular, navegador ou até mesmo relógio inteligente realize a verificação por padrão.

O roteiro do The Verge 2023

Inicialmente, "Verge" referia-se à transferência do estado de armazenamento do Ethereum para a árvore Verkle - uma estrutura de árvore que permite provas mais compactas, possibilitando a validação sem estado dos blocos do Ethereum sem armazenar qualquer estado do Ethereum (saldo da conta, código de contrato, espaço de armazenamento, etc.) no disco. Um nó pode validar um bloco do Ethereum sem precisar armazenar qualquer estado do Ethereum em seu disco, com o custo de algumas centenas de KB de dados de prova e alguns centos de milissegundos de tempo extra para validar uma prova. Atualmente, Verge representa uma visão mais ampla, concentrando-se em alcançar a máxima eficiência de recursos da cadeia Ethereum, incluindo não apenas a tecnologia de validação sem estado, mas também a validação de todos os estados da execução do Ethereum usando SNARK.

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.

O Verge: Objetivo Chave

· Cliente sem estado: O espaço de armazenamento necessário para o cliente totalmente validado e marcado Nó não deve exceder alguns GB.

· (Long term) Complete verification of the chain (Consenso and execution) on the smartwatch. Download some data, verify SNARK, and complete it.

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 Blocos, e essa quantidade está aumentando a cada ano. Os dados de estado originais aumentam cerca de 30GB por ano, e o cliente individual deve armazenar alguns dados extras nele para atualizar efetivamente as triplas.

Isso reduz o número de usuários capazes de executar o Nó Ethereum de validação completa: embora os discos rígidos grandes que podem armazenar todos os estados Ethereum e até anos de histórico sejam comuns, os computadores que as pessoas compram geralmente têm apenas algumas centenas de gigabytes de espaço de armazenamento. O tamanho do estado também cria uma grande fricção no processo de construção do Nó pela primeira vez: o Nó precisa baixar todo o estado, o que pode levar horas ou dias. Isso causa uma série de reações em cadeia. Por exemplo, isso aumenta muito a dificuldade dos autores do Nó em atualizar suas configurações de Nó. Tecnicamente, a atualização pode ser concluída sem interrupção - iniciando um novo cliente, aguardando a sincronização e, em seguida, fechando o cliente antigo e transferindo a Chave Secreta - mas na prática, isso é muito complicado.

Como funciona?

A verificação sem estado é uma técnica que permite que um Nó verifique um Bloco sem ter posse do estado completo. Em vez disso, cada Bloco é acompanhado por uma testemunha que inclui: (i) os valores, códigos, saldos, armazenamento em posições específicas do estado que o Bloco irá acessar; (ii) uma prova de encriptação que demonstra a correção desses valores.

Na verdade, a realização de uma validação sem estado requer uma alteração na estrutura da árvore de estado do Ethereum. Isso ocorre porque a árvore Merkle Patricia atual é extremamente hostil à implementação de qualquer esquema de prova de encriptação, especialmente nos piores casos. Tanto os ramos 'originais' do Merkle quanto as possibilidades 'embrulhadas' como STARK são afetados. A dificuldade principal advém de algumas fraquezas do MPT:

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

2. O código não é Merklefied. Isso significa que para provar qualquer acesso à conta de código, é necessário fornecer o código inteiro, o que pode ter no máximo 24000 bytes.

Podemos calcular a pior situação da seguinte forma:

30000000 gás / 2400 (冷conta阅读成本) *（5 * 488 + 24000) = 330000000 bytes

O custo do ramo é ligeiramente inferior a Gota (usando 5480 em vez de 8480), porque a parte superior do ramo se repete quando há muitos ramos. No entanto, mesmo assim, é totalmente irrealista a quantidade de dados a serem baixados em um único intervalo de tempo. Se tentarmos encapsulá-lo com STARK, enfrentaremos dois problemas: (i) KECCAK não é tão amigável para STARK; (ii) 330MB de dados significam que devemos provar 5 milhões de chamadas à função round KECCAK, o que pode ser impossível para qualquer hardware, exceto o mais poderoso de consumo, mesmo que possamos tornar a prova de eficiência de KECCAK mais alta com STARK.

Se substituirmos diretamente a árvore hexadecimal pela árvore binária e fizermos uma Merkleização adicional do código, o pior caso aproximado será de cerca de 10400000 bytes (14 é a subtração dos bits redundantes para o ramo 2^14 e 8 é o comprimento da prova para entrar nas folhas do bloco de código). É importante notar que isso exigirá uma alteração no custo do gás, cobrando por acesso a cada bloco de código individual; é assim que o EIP-4762 funciona. Uma capacidade de 10,4 MB é muito melhor, mas ainda é muito dados para muitos Nós baixarem em um intervalo. Portanto, precisamos introduzir tecnologias mais poderosas. Nesse sentido, existem duas soluções líderes: árvore Verkle e árvore de hash binária STARKed.

Árvore Verkle

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

Portanto, o tamanho de um único ramo na prova é reduzido para 32 - 1og256(N) = 4 * log2(N) bytes. Assim, o tamanho máximo teórico da prova é aproximadamente 30000000 / 2400 32 (32 -14 + 8) / 8 = 130000 bytes (devido à distribuição irregular dos blocos de estado, o resultado real pode ser ligeiramente diferente, mas como uma primeira aproximação está correto).

Além disso, é importante notar que, em todos os exemplos acima, esse 'pior caso' não é o pior caso: o pior caso é quando um atacante 'minera' intencionalmente dois Endereços que têm um prefixo comum mais longo na árvore e lê dados de um desses Endereços, o que pode estender o comprimento do ramo no pior caso em mais 2 vezes. Mas mesmo nesse caso, o comprimento da prova no pior caso da árvore Verkle é de 2,6MB, o que é praticamente o mesmo que o dado de verificação atual no pior caso.

Ainda usamos essa observação para fazer outra coisa: 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, o que ainda está aproximadamente dentro da faixa de tolerância. Se quisermos reduzir esse valor por segurança, podemos aumentar ligeiramente o custo do acesso adjacente.

STARKed 二进制哈希树

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

O principal desafio aqui é verificar o tempo. Podemos realizar cálculos semelhantes aos mencionados acima, exceto que não estamos calculando bytes, mas sim valores de hash. Um bloco de 10,4 MB significa 330.000 valores de hash. Se também considerarmos a possibilidade de um atacante "minerar" um endereço com um prefixo comum longo na árvore, então o pior caso seria cerca de 660.000 valores de hash. Portanto, não haverá problemas se pudermos provar que temos 200.000 valores de hash por segundo.

Nos computadores portáteis de consumo que utilizam a função hash de Poseidon, estes números já foram alcançados, enquanto a função hash de Poseidon é especificamente projetada para a amigabilidade do STARK. No entanto, o sistema Poseidon ainda é relativamente imaturo, e muitas pessoas ainda não confiam na sua segurança. Portanto, existem dois caminhos realistas a seguir:

1. Realize uma análise de segurança extensiva do Poseidon e familiarize-se o suficiente com ele para implantá-lo no L1 rapidamente.

2. Use a more "conservative" hash function, such as SHA256 or BLAKE

Para provar a conservação de uma função de hash, o STARK da Starkware só pode provar 10-30k valores de hash por segundo em um laptop de consumo no momento em que este artigo foi escrito. No entanto, a tecnologia STARK está melhorando rapidamente. Mesmo hoje em dia, a tecnologia baseada em GKR mostra que essa velocidade pode ser aumentada para a faixa de 100-2O0k.

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

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

· Piscina de memória: Quando uma transação é difundida, os Nós na rede P2P precisam validar a transação antes de difundi-la novamente para garantir sua validade. Atualmente, a validação inclui a verificação de assinaturas, bem como a verificação de saldo e prefixo corretos. No futuro (por exemplo, usando a abstração de contas nativas, como EIP-7701), isso pode envolver a execução de algum código EVM que realiza acesso a estados. Se o Nó for sem estado, a transação precisará incluir uma prova do estado do objeto.

· Inclui lista: Esta é uma funcionalidade proposta que permite que os validadores (possivelmente em escala pequena e não complexa) de Prova de Atestaçãoforçar o próximo Bloco a incluir transações, independentemente da vontade dos construtores de Bloco (possivelmente em escala grande e complexa). Isso enfraquecerá a capacidade de manipulação da cadeia de Blocos por parte de atores poderosos através da latência de transações. No entanto, os validadores precisarão de um meio de verificar a validade das transações incluídas na lista.

· cliente ligeiro: Se quisermos que os utilizadores acedam à cadeia através de uma carteira (como o Metamask, Rainbow, Rabby, etc.), para o fazer, precisam de correr um cliente ligeiro (como o Helios). O módulo central do Helios fornece aos utilizadores a raiz de estado verificada. Para obter uma experiência completamente sem confiança, os utilizadores precisam de fornecer provas para cada chamada de RPC que fazem (por exemplo, para pedidos de chamadas à rede ETH (os utilizadores precisam de provar acesso a todos os estados acedidos durante a chamada)).

Todos esses casos de uso têm algo em comum: eles exigem uma quantidade considerável de prova, 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 é sua capacidade de atualização: dado um estado X com raiz no Bloco B e uma prova recebida de um subbloco B2 e sua testemunha, é possível atualizar a prova para ter o Bloco B2 como raiz. Provas Verkle também são nativamente atualizáveis.

Com quais pesquisas existentes há conexões:

· Árvores Verkle

· John Kuszmaul sobre o artigo original da árvore Verkle

· Starkware

· Papel Poseidon2

· Ajtai (Função hash rápida alternativa baseada na dureza da rede)

· Verkle.info

O que mais pode ser feito?

O trabalho principal restante é

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

2. Concluir e testar mais trabalho de transição, que é a parte principal da complexidade de qualquer implementação de ambiente sem nacionalidade

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

4. Para desenvolver ainda mais a funcionalidade STARK super eficiente para "conservador" (ou "tradicional") hash, por exemplo, com base nas perspectivas de Binius ou GKR.

Além disso, em breve decidiremos escolher uma das três opções a seguir: (i) Árvores Verkle, (ii) Funções de hash compatíveis com STARK e (iii) Funções de hash conservadoras. Suas características podem ser resumidas aproximadamente na tabela abaixo:

Além desses "números de título", há outros fatores importantes a serem considerados:

· Agora, o código da árvore Verkle está bastante maduro. Qualquer outro código, além do Verkle, atrasará a implantação e provavelmente atrasará uma forquilha difícil. Isso não é um problema, especialmente se precisarmos de tempo extra para análise de funções hash ou implementação de validadores, ou se tivermos outros recursos importantes que queiramos incorporar ao Ethereum mais cedo.

· Atualizar o estado raiz usando valores de hash é mais rápido do que usar árvores Verkle. Isso significa que o método baseado em valores de 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 um objeto de estado for atualizado, o testemunho da penúltima camada pode ser atualizado sem a necessidade de ler o conteúdo da última camada.

· Verkle torna mais difícil a realização de provas SNARK. Se quisermos reduzir o tamanho da prova para alguns milhares de bytes, as provas Verkle apresentam algumas dificuldades. Isso ocorre porque a verificação das provas Verkle envolve muitas operações de 256 bits, o que requer um sistema de prova com muitos custos ou uma estrutura interna personalizada que contenha a parte Verkle da prova de 256 bits. Isso não é um problema em si para o estado sem memória, mas apresenta mais dificuldades.

Se quisermos obter a Verkle proof-updatability de forma segura e eficiente em termos de eficiência quântica, outra abordagem possível é a árvore de Merkle baseada em lattice.

Se, na pior das hipóteses, for provado que a eficiência do sistema não é alta o suficiente, podemos usar ferramentas multidimensionais de gás inesperadas para compensar essa deficiência: definir limites de gás separados para (i) calldata; (ii) cálculos; (iii) acesso de estado e possivelmente outros recursos diferentes. O gás multidimensional aumenta a complexidade, mas, em troca, limita mais estritamente a relação entre o caso médio e o pior caso. Com o gás multidimensional, o número máximo de bifurcações que teoricamente precisam ser comprovadas pode ser reduzido de 12500 para, por exemplo, 3000. Isso tornará o BLAKE3 (mal) suficiente, mesmo hoje.

O gás multidimensional permite que os recursos do Bloco se aproximem mais dos recursos de hardware subjacentes

Outra ferramenta surpreendente é o cálculo de latência do estado raiz até o Bloco. Dessa forma, temos um tempo de 12 segundos para calcular o estado raiz, o que significa que mesmo em situações extremas, o tempo de prova de trabalho de apenas 60.000 hashes por segundo é suficiente, o que nos leva a concluir que o BLAKE3 mal consegue atender aos requisitos.

A desvantagem deste método é que irá aumentar uma latência de um intervalo de tempo cliente ligeirolatência, mas também 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 imediatamente na rede após a geração em qualquer nó, em vez de aguardar pelo próximo bloco.

Como isso interage com as outras partes do roteiro?

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

Se o EOF for introduzido ao mesmo tempo, a análise de gás multidimensional tornará mais fácil. Isso ocorre porque a principal fonte de complexidade de execução do gás multidimensional vem do processamento de chamadas secundárias que não passam todo o gás da chamada pai, e o EOF só precisa tornar essas chamadas secundárias ilegais, tornando este problema trivial (e a abstração da conta nativa fornecerá uma alternativa interna para o uso atual principal de gás de parte).

Entre a validação sem estado e o histórico expirado, há uma interação importante. Hoje em dia, 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 o cliente esteja sem estado, a menos que possamos aliviar a responsabilidade do cliente de armazenar dados históricos, será quase impossível realizar o sonho de um cliente sem armazenamento. O primeiro passo nesse sentido é o EIP-4444, o que também significa armazenar dados históricos em torrents ou na rede do portal Portal Network.

prova de validade executada pelo EVM

Que problema estamos a tentar resolver?

O objetivo a longo prazo da verificação do Bloco ETH é muito claro - deverá ser capaz de verificar o Bloco ETH da seguinte forma: (i) Baixar o Bloco, ou até mesmo apenas uma pequena parte dos dados de disponibilidade do Bloco; (ii) Verificar uma pequena prova válida do Bloco. Isso será uma operação de baixo consumo de recursos, que pode ser feita em dispositivos móveis, na Carteira do navegador, ou até 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 abordado continuamente no processo de aprimoramento da camada de consenso (por exemplo, em relação à finalidade de uma única slot). O segundo exige prova de execução EVM.

O que é, 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á calculando um estado posterior S' = STF(S, B). Se um usuário estiver a usar um cliente ligeiro, eles não possuem completa- mente S e S', e até mesmo E; em vez disso, eles têm 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 do bloco H

· Entrada pessoal: objetos no estado acessados pelo corpo do bloco B, bloco Q, objetos idênticos depois da execução do bloco Q' e prova de estado (como ramos de Merkle) P

· A alegação 1: P é uma prova válida de que Q contém algumas partes do estado representado por R

· Argumento 2: Se STF for executado em Q, (i) o processo de execução só acessa objetos internos em 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 com as informações de Q' e P, obteremos R'

Se houver essa possibilidade, você pode ter um cliente leve que verifique completamente a execução do EVM no Ethereum. Isso torna os recursos do cliente bastante baixos. Para conseguir um cliente completo de verificação do Ethereum, também é necessário fazer o mesmo trabalho em relação ao 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 ligações com as pesquisas existentes?

· EFPSE ZK-EVM (descontinuado devido a opções melhores disponíveis)

· Zeth, seu princípio de funcionamento é compilar EVM em RISC-0 ZK-VM

· Projeto de Verificação Formal ZK-EVM

O que mais pode ser feito?

Atualmente, o sistema de contabilidade eletrônica prova de validade tem duas deficiências: segurança e tempo de verificação.

Uma prova de validade segura deve garantir que o SNARK realmente verifica o cálculo do EVM e não há falhas. As duas principais técnicas para aumentar a segurança são múltiplos validadores e validação formal. Múltiplos validadores referem-se a ter várias implementações independentes de prova de validade, assim como ter vários clientes; se um bloco for provado por um subconjunto grande o suficiente dessas implementações, o cliente aceitará o bloco. A validação formal envolve o uso de ferramentas comumente usadas para provar teoremas matemáticos, como Lean4, para provar que a prova de validade só aceita a execução correta das especificações subjacentes do EVM (como a semântica K do EVM ou a especificação da camada de execução do Ethereum escrita em Python (EELS)).

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

· Paralelização - O verificador EVM mais rápido atualmente pode provar um bloco Ethereum em média em 15 segundos. Isso é alcançado pela paralelização entre centenas de GPUs e depois agregando o trabalho delas no final. Teoricamente, sabemos como criar um verificador EVM que possa provar o cálculo em tempo O(log(N)): deixar uma GPU completar cada etapa e fazer uma 'árvore de agregação' no final.

Realizar 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 por vez, mas deve ser feita por opcode (opcodes da Máquina virtual subjacente, como EVM ou RISC-V). Garantir que a "memória" da Máquina virtual permaneça consistente entre as diferentes partes da prova é um desafio crítico na implementação. No entanto, se pudermos realizar essa prova recursiva, sabemos que, mesmo sem outras melhorias, pelo menos o problema de latência do verificador foi resolvido.

· A otimização do sistema de prova - Novos sistemas de prova, como Orion, Binius, GRK e muito mais, provavelmente levarão a uma grande redução no tempo de verificação de cálculos genéricos.

· Outras mudanças no custo do gás da EVM - Muitas coisas na EVM podem ser otimizadas para torná-la mais favorável aos validadores, especialmente nos piores casos. Se um atacante puder construir um Bloco que bloqueie os validadores por dez minutos, então apenas quatro segundos para provar um Bloco ETH comum não será 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 levar muito tempo para ser comprovada, mesmo que sua velocidade de cálculo seja relativamente rápida, o custo do gás deve ser muito alto. O EIP-7667 é um EIP proposto para lidar com esse problema mais grave: ele aumenta significativamente o custo do gás das funções de hash (tradicionais) porque suas operações de código e pré-compilação são relativamente baratas. Para compensar esse aumento no custo do gás, podemos ajustar o custo do gás das operações da EVM que comprovam ter um custo de Gota mais baixo, mantendo assim o throughput médio.

• Substituição de Estruturas de Dados - Além de substituir a árvore de estado por um método mais amigável ao STARK, também precisamos substituir a lista de transações, a árvore de recibos e outras estruturas de alto custo de prova. A mudança das estruturas de transações e recibos para o EIP de SSZ, feita por Etan Kissling, é um passo nessa direção.

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

Um ponto que não foi mencionado anteriormente é o hardware do verificador: usar GPU, FPGA e ASIC para gerar provas mais rapidamente. A Fabric Cryptography, Cysic e Accseal são três empresas que estão progredindo nessa área. Isso é muito valioso para L2, mas é pouco provável que seja um fator decisivo para L1, porque as pessoas querem fortemente que L1 permaneça altamente descentralizado, o que significa que a geração de provas deve estar dentro do alcance razoável dos usuários do Ethereum, e não deve ser limitada pelo gargalo do hardware de uma única empresa. L2 pode fazer compensações mais ativas.

Em relação a essas áreas, há mais trabalho a ser feito:

· A prova de paralelização exige que as diferentes partes do sistema possam "compartilhar memória" (como tabelas de pesquisa). Sabemos como fazer isso tecnicamente, mas precisa ser implementado.

· Precisamos de realizar mais análises para encontrar o conjunto ideal de custos de gás, a fim de minimizar o tempo de verificação em situações de pior cenário.

· Precisamos fazer mais trabalho no sistema de prova

O possível custo é:

· Segurança e tempo do validador: Se escolher uma função hash mais agressiva, um sistema de prova mais complexo, ou assumir uma postura de segurança mais agressiva ou outro esquema de design, pode encurtar o tempo do validador.

· Descentralização e Tempo do Provedor: A comunidade precisa chegar a um consenso sobre as 'especificações' do hardware do provedor em questão. É possível exigir que o provedor seja uma entidade de grande escala? Desejamos 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 com versões anteriores: outras deficiências podem ser compensadas por mudanças mais proativas no custo do gás, mas isso provavelmente aumentará desproporcionalmente os custos de certos aplicativos, forçando os desenvolvedores a reescrever e redesdobrar 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 isso interage com as outras partes do roteiro?

A tecnologia central necessária para implementar a prova de validade L1 EVM é amplamente compartilhada com outras duas áreas:

· L2 的prova de validade（即「ZK rollup」）

· Método de prova de hash binário sem estado "STARK"

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

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

Consenso的prova de validade

Que problema estamos a tentar resolver?

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

O Consenso é muito mais simples do que a EVM, mas o desafio que enfrenta é que não temos convolução L2 EVM, por isso a maior parte do trabalho tem que ser feito de qualquer maneira. Portanto, qualquer implementação do Consenso ETH Proof of Stake precisa ser construída "do zero", embora o sistema de prova em si possa ser construído sobre o trabalho compartilhado.

O que é, como funciona?

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

· ECADD (usado para verificar assinatura BLS)

· Par (usado para verificar assinatura BLS)

· Valor de hash SHA256 (usado para ler e atualizar o estado)

Em cada bloco, precisamos provar 1-16 BLS12-381 ECADDs 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 BLS12-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 total da assinatura requer apenas um ECADD de cada participante, em vez de um ECMUL. Mas 30000 ECADD ainda é uma quantidade significativa de provas.

No que diz respeito às combinações, atualmente cada slot tem no máximo 128 provas, o que significa que é necessário verificar 128 combinações. Com ElP-7549 e modificações adicionais, o número de combinações pode ser reduzido para 16 por slot. O número de combinações é pequeno, mas o custo é extremamente alto: o tempo de execução (ou prova) de cada combinação é várias vezes maior do que ECADD.

Um dos principais desafios da computação BLS12-381 é a falta de uma curva conveniente com ordem igual ao tamanho do campo BLS12-381, o que adiciona um grande custo a qualquer sistema de prova. Por outro lado, a árvore Verkle proposta para o ETH é construída com a curva Bandersnatch, o que faz com que o BLS12-381 em si seja a autêntica curva usada para provar os ramos Verkle no sistema SNARK. Uma implementação simples pode provar a adição de 100 G1 por segundo; para alcançar uma velocidade de prova suficientemente rápida, quase certamente será necessário técnicas inteligentes como o GKR.

Para o valor hash SHA256, a pior situação atual é a conversão de blocos de época, toda a árvore de equilíbrio curto do validador e muitos validadores de equilíbrio serão atualizados. A árvore de equilíbrio curto de cada validador tem apenas um byte, então 1 MB de dados será re-hashed. Isso equivale a 32768 chamadas de SHA256. Se mil validadores tiverem saldo acima ou abaixo de um limite, será necessário atualizar o saldo válido nos registros dos validadores, o que equivale a mil ramos de Merkle, portanto, pode ser necessário calcular 10 mil valores hash. O mecanismo de embaralhamento requer 90 Bit para cada validador (portanto, são necessários 11 MB de dados), mas isso pode ser calculado a qualquer momento durante uma época. Em casos de término de slot único, esses números podem variar dependendo da situação. O embaralhamento pode se tornar desnecessário, embora a Orbit possa restaurar essa necessidade em certa medida.

Outro desafio é que é necessário recuperar todo o estado dos validadores, incluindo a Chave pública, para validar 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 Merkle. Isso requer milhões de valores de hash por época. Se tivermos que mostrar a validade do PoS, uma abordagem realista seria 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 resumo, há muitos desafios. Para lidar com esses desafios da forma mais eficaz possível, pode ser necessário um redesenho profundo da cadeia beacon, possivelmente ao mesmo tempo em que se migra para o término do slot único. As características desse redesenho podem incluir:

· Alterações na função de hash: Agora estamos usando a função de hash SHA256 'completa', o que significa que, devido ao preenchimento, cada chamada requer duas chamadas de função de compressão subjacente correspondentes. Se usarmos a função de compressão SHA256, podemos obter pelo menos o dobro do rendimento. Se usarmos o Poseidon, poderíamos obter um aumento de 100 vezes e resolver completamente todos os nossos problemas (pelo menos em relação aos valores de hash): podemos 'ler' até mesmo um milhão de registros de verificação em apenas alguns segundos, com uma taxa de 1,7 milhão de valores de hash por segundo (54 MB).

· Se for Orbit, armazene diretamente os registros de validadores embaralhados: se escolher um número fixo de validadores (como 8192 ou 32768) como comitê para uma determinada fenda, coloque-os diretamente ao lado do estado um do outro, para que apenas o mínimo hash seja necessário para ler todas as chaves públicas dos validadores na prova. Isso também pode ser eficientemente concluído com todas as atualizações de saldo.

· Agregação de assinaturas: qualquer solução de agregação de assinaturas de alta performance envolve algum tipo de prova recursiva, em que diferentes Nó da rede fazem provas intermediárias dos subconjuntos de assinaturas. Isso naturalmente distribui o trabalho de prova para vários Nó na rede, reduzindo significativamente a carga de trabalho do 'provador final'.

· Outros esquemas de assinatura: Para a assinatura Lamport+ Merkle, precisamos de 256 + 32 valores de hash para verificar a assinatura; multiplicando por 32768 signatários, obtemos 9437184 valores de hash. A otimização do esquema de assinatura pode melhorar ainda mais esse resultado por um pequeno fator constante. Se usarmos Poseidon, isso pode ser provado em um único slot. No entanto, na prática, o esquema de agregação recursiva é mais rápido.

Quais são as ligações com as pesquisas existentes?

· Prova de Consenso Ethereum (apenas para comitê síncrono) concisa ETH坊

Helios dentro do SP1 conciso

· Pré-compilação BLS12-381 concisa

· Verificação de assinatura de conjunto BLS baseada em Halo2

Quais outros trabalhos precisam ser feitos e como fazer escolhas:

Na verdade, levará vários anos para obter prova de validade Consenso do Ethereum. Isso é aproximadamente o mesmo tempo necessário para alcançar a finalidade de uma única fenda, Orbit, modificar o algoritmo de assinatura e realizar a análise de segurança, sendo que esta última requer confiança suficiente para utilizar funções de hash 'agressivas' como Poseidon. Portanto, a abordagem mais sensata é resolver esses outros problemas e, ao fazê-lo, considerar a amigabilidade do STARK.

A principal ponderação provavelmente será entre a ordem de operações, com uma abordagem mais progressiva para reformar a camada de consenso do Ethereum e uma abordagem mais radical de 'mudar muitas vezes'. Para a EVM, uma abordagem progressiva é razoável, pois minimiza a interferência na compatibilidade retroativa. Para a camada de consenso, o impacto na compatibilidade retroativa é menor e repensar de forma mais 'abrangente' os vários detalhes da construção da cadeia beacon, otimizando a amigabilidade do SNARK da melhor maneira, também é benéfico.

Como interage com outras partes do roteiro?

Ao redesenhar o PoS do Ethereum, a amigabilidade do STARK deve ser considerada como um fator primordial, especialmente a finalidade de uma única jogada, a Órbita, a alteração do esquema de assinatura e a agregação de assinaturas.

Link original