O Caminho para a Verificabilidade

A principal vantagem do Web3 é a verificabilidade - os usuários podem verificar como os sistemas realmente operam. Essa característica explica por que muitos dentro e fora da indústria de criptomoedas descrevem o web3 como um passo em direção a um internet mais transparente e verificável.

Ao contrário das plataformas Web2 como o Facebook ou o Instagram, onde os algoritmos e as regras permanecem opacos mesmo quando documentados, os protocolos de criptografia são projetados para total auditabilidade. Mesmo que sejam compartilhados, você não tem a capacidade de verificar se a plataforma opera conforme o especificado. Isso é o oposto da criptografia, onde cada protocolo é projetado para ser o mais auditável possível - ou pelo menos, espera-se que seja.

Hoje, vamos explorar “The Verge”, uma seção da recém-publicada Vitalik’s série de seis partes sobre o futuro do Ethereum, para analisar os passos que o Ethereum está dando em direção à alcançar verificabilidade, sustentabilidade e escalabilidade no futuro. Sob o título “The Verge”, discutiremos como as arquiteturas de blockchain podem ser tornadas mais verificáveis, as inovações que essas mudanças trazem no nível do protocolo e como elas proporcionam aos usuários um ecossistema mais seguro. Vamos começar!

O que significa “verificabilidade”?

Aplicações Web2 funcionam como “caixas-pretas” – os usuários só podem ver suas entradas e as saídas resultantes, sem visibilidade sobre como a aplicação realmente funciona. Em contraste, os protocolos de criptomoedas geralmente disponibilizam seu código-fonte publicamente, ou pelo menos têm planos para fazê-lo. Essa transparência serve a dois propósitos: permite que os usuários interajam diretamente com o código do protocolo, se assim o desejarem, e os ajuda a entender exatamente como o sistema opera e quais regras o governam.

“Descentralize o que puder, verifique o resto.”

A verificabilidade garante que os sistemas sejam responsáveis e, em muitos casos, garante que os protocolos funcionem como pretendido. Esse princípio destaca a importância de minimizar a centralização, pois muitas vezes leva a estruturas opacas e sem responsabilidade, onde os usuários não podem verificar as operações. Em vez disso, devemos nos esforçar para descentralizar o máximo possível e tornar os elementos restantes verificáveis e responsáveis onde a descentralização não for viável.

A comunidade Ethereum parece alinhar-se com esta perspectiva, como o roteiroinclui um marco (chamado de “The Verge”) com o objetivo de tornar o Ethereum mais verificável. No entanto, antes de mergulhar no The Verge, precisamos entender quais aspectos das blockchains devem ser verificados e quais partes são cruciais do ponto de vista dos usuários.

As blockchains funcionam essencialmente como relógios globais. Em uma rede distribuída com cerca de 10.000 computadores, pode levar uma quantidade significativa de tempo para que uma transação se propague do nó de origem para todos os outros nós. Por essa razão, os nós em toda a rede não podem determinar a ordem exata das transações - se uma chegou antes ou depois de outra - uma vez que eles têm apenas suas próprias perspectivas subjetivas.

Devido à importância da ordem das transações, as redes blockchain utilizam métodos especializados chamados “algoritmos de consenso” para garantir que os nós permaneçam sincronizados e processem sequências de transações na mesma ordem. Embora os nós não possam determinar a ordem da transação globalmente, os mecanismos de consenso permitem que todos os nós concordem com a mesma sequência, permitindo que a rede funcione como um único e coeso computador.

Além da camada de consenso, há também a camada de execução que existe em todas as blockchains. A camada de execução é moldada pelas transações que os usuários desejam executar.

Uma vez que as transações tenham sido ordenadas com êxito por consenso, cada transação deve ser aplicada ao estado atual na camada de execução. Se você está se perguntando: “Qual é o estado?”, provavelmente já viu blockchains em comparação com bancos de dados – ou, mais especificamente, com o banco de dados de um banco, porque blockchains, como bancos, mantêm um registro dos saldos de todos.

Se você tem $100 no estado que chamamos de “S” e deseja enviar $10 para outra pessoa, seu saldo no próximo estado, “S+1”, será de $90. Esse processo de aplicar transações para mover de um estado para outro é o que chamamos de STF (Função de Transição de Estado).

No Bitcoin, o STF é principalmente limitado a alterações de saldo, tornando-o relativamente simples. No entanto, ao contrário do Bitcoin, o STF do Ethereum é muito mais complexo porque o Ethereum é uma blockchain totalmente programável com uma camada de execução capaz de executar código.

Em uma blockchain, existem três componentes fundamentais que você precisa - ou é capaz de - verificar:

1. Estado: Você pode querer ler um conjunto de dados no blockchain, mas não tem acesso ao estado, pois você não executa umnó completoPortanto, você solicita os dados por meio de um provedor de RPC (Remote Procedure Call) como Alchemy ou Infura. No entanto, você deve verificar se os dados não foram adulterados pelo provedor de RPC.
2. Execução: Como mencionado anteriormente, as blockchains utilizam um STF. Você deve verificar se a transição de estado foi executada corretamente - não em uma base por transação, mas em uma base por bloco.
3. Consensus: Entidades de terceiros, como RPCs, podem fornecer blocos válidos que ainda não foram incluídos na blockchain. Portanto, você deve verificar se esses blocos foram aceitos por consenso e adicionados à blockchain.

Se isso parecer confuso ou obscuro, não se preocupe. Vamos passar por cada um desses aspectos em detalhes. Vamos começar com como verificar o estado do blockchain!

Como verificar o estado da blockchain?

O ‘estado’ do Ethereum refere-se ao conjunto de dados armazenados no blockchain em qualquer momento. Isso inclui saldos de contas (contas de contrato e contas de propriedade externa ou EOAs), código de contrato inteligente, armazenamento de contrato e muito mais. O Ethereum é uma máquina baseada no estado porque as transações processadas na Máquina Virtual Ethereum (EVM) alteram o estado anterior e produzem um novo estado.

Cada bloco do Ethereum contém um valor que resume o estado atual da rede após esse bloco: o stateRoot. Esse valor é uma representação compacta do estado inteiro do Ethereum, consistindo em um hash de 64 caracteres.

À medida que cada nova transação modifica o estado, o stateRoot registrado no bloco subsequente é atualizado de acordo. Para calcular esse valor, os validadores do Ethereum usam uma combinação da função de hash Keccak e uma estrutura de dados chamada de Árvore de Merkleorganizar e resumir diferentes partes do estado.

As funções de hash são funções unidirecionais que transformam uma entrada em uma saída de comprimento fixo. No Ethereum, funções de hash como Keccaksão usadas para gerar resumos de dados, servindo como uma espécie de impressão digital para a entrada. As funções hash têm quatro propriedades fundamentais:

1. Determinismo: A mesma entrada sempre produzirá a mesma saída.
2. Comprimento de saída fixo: independentemente do comprimento da entrada, o comprimento da saída é sempre fixo.
3. Propriedade unidirecional: É praticamente impossível derivar a entrada original a partir da saída.
4. Unicidade: Mesmo uma pequena mudança na entrada produz uma saída completamente diferente. Assim, uma entrada específica mapeia para uma saída praticamente única.

Graças a essas propriedades, os validadores do Ethereum podem executar a STF (Função de Transição de Estado) para cada bloco - executando todas as transações no bloco e aplicando-as ao estado - e verificar se o estado indicado no bloco corresponde ao estado obtido após a STF. Esse processo garante que o proponente do bloco tenha agido honestamente, tornando-o uma das principais responsabilidades dos validadores.

No entanto, os validadores do Ethereum não fazem o hash do estado inteiro diretamente para encontrar seu resumo. Devido à natureza unidirecional das funções de hash, fazer o hash diretamente do estado eliminaria a verificabilidade, pois a única maneira de reproduzir o hash seria possuir o estado inteiro.

Como o estado do Ethereum tem terabytes de tamanho, é impraticável armazenar todo o estado em dispositivos cotidianos como telefones ou computadores pessoais. Por esse motivo, o Ethereum usa uma estrutura de árvore de Merkle para calcular o stateRoot, preservando a verificabilidade do estado tanto quanto possível.

Um árvore de Merkle é uma estrutura de dados criptográficos usada para verificar de forma segura e eficiente a integridade e a correção dos dados. As árvores Merkle são construídas sobre funções de hash e organizam os hashes de um conjunto de dados hierarquicamente, permitindo a verificação da integridade e correção desses dados. Essa estrutura de árvore consiste em três tipos de nós:

1. Nós folha: Esses nós contêm os hashes das peças de dados individuais e estão localizados no nível inferior da árvore. Cada nó folha representa o hash de uma peça específica de dados na árvore de Merkle.
2. Nós de ramificação: Estes nós contêm os hashes combinados de seus nós filhos. Por exemplo, em uma árvore de Merkle binária (onde N=2), os hashes de dois nós filhos são concatenados e hash novamente para produzir o hash de um nó de ramificação em um nível superior.
3. Nó raiz: O nó raiz está no nível mais alto da árvore de Merkle e representa o resumo criptográfico de toda a árvore. Este nó é usado para verificar a integridade e correção de todos os dados dentro da árvore.

Se você está se perguntando como construir uma árvore dessas, envolve apenas dois passos simples:

• Criação de nó folha: Cada pedaço de dados é processado através de uma função de hash, e os hashes resultantes formam os nós folha. Esses nós residem no nível mais baixo da árvore e representam o resumo criptográfico dos dados.

• Combine e hash: Os hashes dos nós folha são agrupados (por exemplo, em pares) e combinados, seguido por hashing. Esse processo cria nós de ramificação no próximo nível. O mesmo processo é repetido para os nós de ramificação até que reste apenas um único hash.

O hash final obtido no topo da árvore é chamado de raiz de Merkle. O Merkle Root representa o resumo criptográfico de toda a árvore e permite a verificação segura da integridade dos dados.

Como usamos as raízes de Merkle para verificar o estado do Ethereum?

Provas de Merkle permitem que o Verificador valide eficientemente peças específicas de dados, fornecendo uma série de valores hash que criam um caminho dos dados alvo (um nó folha) até a Raiz de Merkle armazenada no cabeçalho do bloco. Essa cadeia de hashes intermediários permite ao Verificador confirmar a autenticidade dos dados sem precisar fazer o hash do estado inteiro.

A partir do ponto de dados específico, o Verificador combina-o com cada hash “irmão” fornecido na Prova de Merkle e os hash passo a passo até a árvore. Esse processo continua até que um único hash seja produzido. Se este hash calculado coincidir com a Raiz de Merkle armazenada, os dados são considerados válidos; caso contrário, o Verificador pode determinar que os dados não correspondem ao estado alegado.

Exemplo: Verificando um ponto de dados com prova de Merkle

Digamos que recebemos o Dado #4 de uma RPC e queremos verificar sua autenticidade usando uma Prova de Merkle. Para fazer isso, a RPC forneceria um conjunto de valores de hash ao longo do caminho necessário para alcançar a Raiz de Merkle. Para o Dado 4, esses hashes irmãos incluiriam o Hash #3, o Hash #12 e o Hash #5678.

1. Comece com Dados 4: Primeiro, hash Data #4 para obter Hash #4.
2. Combinando com irmãos: então combinamos o Hash #4 com o Hash #3 (seu irmão na folha) e os hash juntos para produzir o Hash #34.
3. Suba a árvore: Em seguida, pegamos o Hash #34 e combinamos com o Hash #12 (seu irmão na próxima camada acima) e os hashamos para obter o Hash #1234.
4. Etapa Final: Por fim, combinamos o Hash #1234 com o Hash #5678 (o último irmão fornecido) e os juntamos. O hash resultante deve corresponder à Raiz de Merkle (Hash #12345678) armazenada no cabeçalho do bloco.

Se a Raiz de Merkle computada corresponder à raiz do estado no bloco, confirmamos que os Dados #4 são de fato válidos dentro deste estado. Caso contrário, sabemos que os dados não pertencem ao estado reivindicado, indicando possíveis adulterações. Como você pode ver, sem fornecer os hashes de todos os dados ou exigir que o Verificador reconstrua a árvore de Merkle inteira do zero, o Provador pode provar que os Dados #4 existem no estado e não foram alterados durante sua jornada—usando apenas três hashes. Esta é a razão principal pela qual as Provas de Merkle são consideradas eficientes.

Embora as árvores de Merkle sejam, sem dúvida, eficazes na fornecimento de verificação de dados segura e eficiente em grandes sistemas de blockchain como o Ethereum, elas são realmente eficientes o suficiente? Para responder a isso, devemos analisar como o desempenho e o tamanho da Árvore de Merkle impactam o relacionamento Prover-Verifier.

Dois Fatores-Chave que Afetam o Desempenho da Árvore de Merkle: ⌛

1. Fator de ramificação: O número de nós filhos por ramo.
2. Tamanho total dos dados: O tamanho do conjunto de dados sendo representado na árvore.

O Efeito do Fator de Ramificação:

Vamos usar um exemplo para entender melhor seu impacto. O fator de ramificação determina quantos ramos surgem de cada nó na árvore.

• Pequeno Fator de Ramificação (por exemplo, Árvore de Merkle Binária):
  Se uma árvore de Merkle binária (fator de ramificação de 2) for usada, o tamanho da prova é muito pequeno, tornando o processo de verificação mais eficiente para o Verificador. Com apenas duas ramificações em cada nó, o Verificador só precisa processar um hash irmão por nível. Isso acelera a verificação e reduz a carga computacional. No entanto, o fator de ramificação reduzido aumenta a altura da árvore, exigindo mais operações de hashing durante a construção da árvore, o que pode ser oneroso para os validadores.
• Maior Fator de Ramificação (por exemplo, 4):
  Um fator de ramificação maior (por exemplo, 4) reduz a altura da árvore, criando uma estrutura mais curta e larga. Isso permite que os nós completos construam a árvore mais rapidamente, pois menos operações de hash são necessárias. No entanto, para o Verificador, isso aumenta o número de hashes irmãos que eles devem processar em cada nível, resultando em um tamanho de prova maior. Mais hashes por etapa de verificação também significam custos computacionais e de largura de banda mais altos para o Verificador, transferindo efetivamente o ônus dos validadores para os verificadores.

O Efeito do Tamanho Total dos Dados:

À medida que a blockchain do Ethereum cresce, com cada nova transação, contrato ou interação do usuário adicionada ao conjunto de dados, a Merkle Tree também deve se expandir. Esse crescimento não apenas aumenta o tamanho da árvore, mas também afeta o tamanho da prova e o tempo de verificação.

• Os nós completos devem processar e atualizar regularmente o conjunto de dados em crescimento para manter a Árvore de Merkle.
• Os verificadores, por sua vez, devem validar provas mais longas e complexas à medida que o conjunto de dados cresce, exigindo tempo de processamento e largura de banda adicionais. \
  Essa crescente quantidade de dados aumenta a demanda tanto por Full Nodes quanto por Verificadores, dificultando a escalabilidade eficiente da rede.

Em resumo, embora as Árvores de Merkle ofereçam um grau de eficiência, elas não são uma solução ideal para o conjunto de dados em constante crescimento do Ethereum. Por esse motivo, durante a fase The Verge, o Ethereum visa substituir as Árvores de Merkle por uma estrutura mais eficiente conhecida comoVerkle Trees. As árvores Verkle têm o potencial de fornecer tamanhos de prova menores, mantendo o mesmo nível de segurança, tornando o processo de verificação mais sustentável e escalável tanto para os Provadores quanto para os Verificadores.

Capítulo 2: Revolucionando a Verificabilidade no Ethereum - The Verge

A Verge foi desenvolvida como um marco na estratégia do Ethereum com o objetivo de melhorar a verificabilidade, fortalecer a estrutura descentralizada do blockchain e aumentar a segurança da rede. Um dos principais objetivos da rede Ethereum é permitir que qualquer pessoa execute facilmente um validador para verificar a cadeia, criando uma estrutura em que a participação seja aberta a todos sem centralização. A acessibilidade desse processo de verificação é uma das principais características que distinguem blockchains de sistemas centralizados. Enquanto sistemas centralizados não oferecem capacidades de verificação, a correção de um blockchain está inteiramente nas mãos de seus usuários. No entanto, para manter essa garantia, a execução de um validador deve ser acessível a todos - um desafio que, no sistema atual, é limitado devido aos requisitos de armazenamento e computação.

Desde a transição para um modelo de consenso de Prova de Participação com o The Merge, os validadores Ethereum tiveram duas responsabilidades principais:

1. Garantindo Consenso: Apoiando o funcionamento adequado de protocolos de consenso probabilísticos e determinísticos e aplicando o algoritmo de escolha de bifurcação.
2. Verificando a Precisão do Bloco: Após a execução das transações em um bloco, verificando se a raiz da árvore de estado resultante corresponde à raiz de estado declarada pelo proponente.

Para cumprir a segunda responsabilidade, os validadores devem ter acesso ao estado anterior ao bloco. Isso lhes permite executar as transações do bloco e derivar o estado subsequente. No entanto, esse requisito impõe uma carga pesada aos validadores, pois eles precisam lidar com requisitos significativos de armazenamento. Embora o Ethereum seja projetado para ser viável e os custos de armazenamento tenham diminuído globalmente, o problema é menos sobre o custo e mais sobre a dependência de hardware especializado para os validadores. A Verge tem como objetivo superar esse desafio criando uma infraestrutura onde a verificação completa possa ser realizada mesmo em dispositivos com armazenamento limitado, como telefones celulares, carteiras de navegador e até smartwatches, permitindo que os validadores funcionem nesses dispositivos.

Primeiro Passo da Verificabilidade: Estado

A transição para as árvores Verkle é uma parte fundamental desse processo. Inicialmente, o Verge focou em substituir as estruturas de árvores Merkle do Ethereum por árvores Verkle. A principal razão para adotar as árvores Verkle é que as árvores Merkle representam um obstáculo significativo para a verificabilidade do Ethereum. Embora as árvores Merkle e suas provas possam funcionar de forma eficiente em cenários normais, seu desempenho degrada drasticamente em cenários de pior caso.

De acordo com os cálculos de Vitalik, o tamanho médio da prova é de cerca de 4 KB, o que parece gerenciável. No entanto, em cenários de pior caso, o tamanho da prova pode chegar a 330 MB. Sim, você leu corretamente - 330 MB.

A extrema ineficiência das Merkle Trees da Ethereum nos piores cenários decorre de duas razões principais:

1. Uso de Árvores Hexárias: Ethereum atualmente usa Árvores de Merkle com um fator de ramificação de 16. Isso significa que verificar um único nó requer fornecer os 15 hashes restantes no ramo. Dado o tamanho do estado do Ethereum e o número de ramos, isso cria um fardo substancial em cenários de pior caso.

1. Não-Merkelização de Código: Em vez de incorporar o código do contrato na estrutura de árvore, o Ethereum simplesmente faz o hash do código e usa o valor resultante como um nó. Considerando que o tamanho máximo de um contrato é de 24 KB, essa abordagem impõe um ônus significativo para alcançar total verificabilidade.

O tamanho da prova é diretamente proporcional ao fator de ramificação. Reduzir o fator de ramificação diminui o tamanho da prova. Para resolver esses problemas e melhorar os cenários de pior caso, o Ethereum poderia mudar de Árvores Hexary para Árvores Merkle Binárias e começar a merklizar códigos de contrato. Se o fator de ramificação no Ethereum for reduzido de 16 para 2 e os códigos de contrato também forem merklizados, o tamanho máximo da prova poderia diminuir para 10 MB. Embora esta seja uma melhoria significativa, é importante notar que esse custo se aplica à verificação de apenas uma peça de dados. Mesmo uma transação simples que acessa várias peças de dados exigiria provas maiores. Dado o número de transações por bloco e o estado continuamente crescente do Ethereum, essa solução, embora melhor, ainda não é totalmente viável.

Por esses motivos, a comunidade Ethereum propôs duas soluções distintas para abordar a questão:

1. Verkle Árvores
2. STARK Proofs + Árvores Merkle Binárias

Verkle Trees e Compromissos de Vetor

Verkle Trees, como o nome sugere, são estruturas de árvore semelhantes às Árvores de Merkle. No entanto, a diferença mais significativa está na eficiência que oferecem durante os processos de verificação. Nas Árvores de Merkle, se um ramo contiver 16 peças de dados e quisermos verificar apenas uma delas, uma cadeia de hash que cubra as outras 15 peças também deve ser fornecida. Isso aumenta significativamente a carga computacional da verificação e resulta em tamanhos de prova grandes.

Por outro lado, as Árvores Verkle utilizam uma estrutura especializada conhecida como “Compromissos de Vetor Baseados em Curvas Elípticas”, mais especificamente, um Compromisso de Vetor Baseado em Argumento de Produto Interno (IPA). Um vetor é essencialmente uma lista de elementos de dados organizados em uma sequência específica. O estado do Ethereum pode ser pensado como um vetor: uma estrutura onde numerosas peças de dados são armazenadas em uma ordem particular, sendo cada elemento crucial. Este estado é composto por vários componentes de dados, como endereços, códigos de contrato e informações de armazenamento, onde a ordem desses elementos desempenha um papel crítico no acesso e verificação.

As Compromissos Vetoriais são métodos criptográficos usados para provar e verificar elementos de dados dentro de um conjunto de dados. Esses métodos permitem a verificação tanto da existência quanto da ordem de cada elemento em um conjunto de dados simultaneamente. Por exemplo, as Provas de Merkle, usadas em Árvores de Merkle, também podem ser consideradas uma forma de Compromisso Vetorial. Embora as Árvores de Merkle exijam todas as cadeias de hash relevantes para verificar um elemento, a estrutura comprova inherentemente que todos os elementos de um vetor estão conectados em uma sequência específica.

Ao contrário da Merkle Trees, a Verkle Trees emprega compromissos vetoriais baseados em curvas elípticas que oferecem duas vantagens principais:

• Compromissos de vetor baseados em curvas elípticas eliminam a necessidade de detalhes de elementos que não sejam os dados sendo verificados. Em árvores de Merkle com um fator de ramificação de 16, verificar um único ramo requer fornecer os outros 15 hashes. Dada a vasta dimensão do estado do Ethereum, que envolve muitos ramos, isso cria uma ineficiência significativa. No entanto, compromissos de vetor baseados em curvas elípticas removem essa complexidade, permitindo verificação com menos dados e esforço computacional.
• Através de multiprovas, as provas geradas por compromissos vetoriais baseados em curvas elípticas podem ser comprimidas em uma única prova de tamanho constante. O estado do Ethereum não é apenas grande, mas também cresce continuamente, o que significa que o número de ramificações que precisam de verificação para acessar a raiz Merkle aumenta com o tempo. No entanto, com Verkle Trees, podemos “comprimir” as provas de cada ramo em uma única prova de tamanho constante usando o método detalhado em Artigo de Dankrad FeistIsso permite que os Verificadores validem a árvore inteira com uma pequena prova em vez de verificar cada ramo individualmente. Isso também significa que as Verkle Trees não são afetadas pelo crescimento do estado do Ethereum.

Esses recursos de compromissos vetoriais baseados em curvas elípticas reduzem significativamente a quantidade de dados necessários para verificação, permitindo que a Verkle Trees produza provas pequenas e de tamanho constante, mesmo nos piores cenários. Isso minimiza a sobrecarga de dados e os tempos de verificação, melhorando a eficiência de redes de grande escala como o Ethereum. Como resultado, o uso de compromissos vetoriais baseados em curvas elípticas em Verkle Trees permite um tratamento mais gerenciável e eficiente do estado em expansão do Ethereum.

Como todas as inovações, as Árvores Verkle têm suas limitações. Uma das principais desvantagens é que elas dependem da criptografia de curva elíptica, que é vulnerável a computadores quânticos. Computadores quânticos possuem poder computacional muito maior do que os métodos clássicos, representando uma ameaça significativa aos protocolos criptográficos baseados em curva elíptica. Algoritmos quânticos poderiam potencialmente quebrar ou enfraquecer esses sistemas criptográficos, levantando preocupações sobre a segurança de longo prazo das Árvores Verkle.

Por esse motivo, embora as Árvores Verkle ofereçam uma solução promissora para a falta de estado, elas não são a solução final. No entanto, figuras como Dankrad Feist enfatizaram que, embora seja necessária consideração cuidadosa ao integrar criptografia resistente à quântica no Ethereum, vale ressaltar que os compromissos KZG atualmente usados para blobs no Ethereum também não são resistentes à quântica. Assim, as Árvores Verkle podem servir como solução intermediária, fornecendo à rede tempo adicional para desenvolver alternativas mais robustas.

Provas STARK + Árvores Merkle Binárias

As Árvores Verkle oferecem tamanhos de prova menores e processos de verificação eficientes em comparação com as Árvores Merkle, tornando mais fácil gerenciar o estado em constante crescimento do Ethereum. Graças aos Compromissos de Vetor Baseados em Curva Elíptica, provas em larga escala podem ser geradas com significativamente menos dados. No entanto, apesar de suas impressionantes vantagens, a vulnerabilidade das Árvores Verkle a computadores quânticos as torna apenas uma solução temporária. Enquanto a comunidade Ethereum vê as Árvores Verkle como uma ferramenta de curto prazo para ganhar tempo, o foco de longo prazo está na transição para soluções resistentes a computadores quânticos. É aí que as Provas STARK e as Árvores Merkle Binárias se apresentam como uma forte alternativa para a construção de uma infraestrutura de verificabilidade mais robusta para o futuro.

No processo de verificação de estado do Ethereum, o fator de ramificação das Árvores de Merkle pode ser reduzido (de 16 para 2) usando Árvores de Merkle Binárias. Essa mudança é um passo crítico para reduzir os tamanhos das provas e tornar os processos de verificação mais eficientes. No entanto, mesmo no pior cenário, os tamanhos das provas ainda podem atingir 10 MB, o que é substancial. É aqui que as Provas STARK entram em jogo, comprimindo essas grandes Provas de Merkle Binárias para apenas 100-300 kB.

Essa otimização é particularmente vital ao considerar as restrições de validadores operacionais em clientes leves ou dispositivos com hardware limitado, especialmente se você levar em conta que as velocidades médias globais de download e upload de dispositivos móveis são de aproximadamente 7,625 MB/s e 1,5 MB/s, respectivamente. Os usuários podem verificar transações com provas pequenas e portáteis sem precisar acessar o estado completo, e os validadores podem executar tarefas de verificação de bloco sem armazenar todo o estado.

Esta abordagem de benefício duplo reduz tanto os requisitos de largura de banda quanto de armazenamento para validadores, ao mesmo tempo em que acelera a verificação, três melhorias-chave que apoiam diretamente a visão de escalabilidade do Ethereum.

Principais desafios para provas STARK:

1. Alta carga computacional para provadores: \
   O processo de geração de provas STARK é computacionalmente intensivo, especialmente no lado do provador, o que pode aumentar os custos operacionais.
2. Ineficiência em Provas de Pequenos Dados:

Embora as provas STARK se destaquem no manuseio de grandes conjuntos de dados, elas são menos eficientes ao comprovar pequenas quantidades de dados, o que pode dificultar sua aplicação em certos cenários. Ao lidar com programas que envolvem etapas ou conjuntos de dados menores, o tamanho da prova relativamente grande dos STARKs pode torná-los menos práticos ou econômicos.

Segurança quântica tem um custo: carga computacional do lado do provador

A Prova de Merkle de um bloco pode incluir aproximadamente 330.000 hashes, e em cenários de pior caso, esse número pode chegar a 660.000. Em tais casos, uma prova STARK precisaria processar cerca de 200.000 hashes por segundo.

É aqui que funções de hash amigáveis ao zk, como o Poseidon, entram em jogo, especificamente otimizadas para provas STARK para reduzir essa carga. O Poseidon foi projetado para funcionar mais perfeitamente com provas de ZK em comparação com algoritmos de hash tradicionais como SHA256 e Keccak. A principal razão para essa compatibilidade está em como os algoritmos de hash tradicionais operam: eles processam entradas como dados binários (0s e 1s). Por outro lado, as provas de ZK trabalham com campos primos, estruturas matemáticas que são fundamentalmente diferentes. Esta situação é análoga aos computadores que operam em binário, enquanto os seres humanos usam um sistema decimal na vida cotidiana. A tradução de dados baseados em bits para formatos compatíveis com ZK envolve uma sobrecarga computacional significativa. O Poseidon resolve esse problema operando nativamente dentro de campos nobres, acelerando drasticamente sua integração com as provas de ZK.

No entanto, como o Poseidon é uma função de hash relativamente nova, ela requer uma análise de segurança mais extensa para estabelecer o mesmo nível de confiança que as funções de hash tradicionais, como SHA256 e Keccak. Para isso, iniciativas como a Iniciativa de criptanálise Poseidon, lançado pela Fundação Ethereum, convida especialistas para testar e analisar rigorosamente a segurança do Poseidon, garantindo que ele possa resistir ao escrutínio adversário e se tornar um padrão robusto para aplicações criptográficas. Por outro lado, funções mais antigas como SHA256 e Keccak já foram extensivamente testadas e têm um histórico de segurança comprovado, mas não são amigáveis ao ZK, resultando em quedas de desempenho quando usadas com provas STARK.

Por exemplo, as provas STARK usando essas funções de hash tradicionais atualmente podem processar apenas 10.000 a 30.000 hashes. Felizmente, os avanços na tecnologia STARK sugerem que essa taxa de transferência pode aumentar em breve para 100.000 a 200.000 hashes, melhorando significativamente sua eficiência.

A ineficiência dos STARKs em provar dados pequenos

Embora as provas STARK sejam excelentes em escalabilidade e transparência para conjuntos de dados grandes, elas mostram limitações ao trabalhar com elementos de dados pequenos e numerosos. Nesses cenários, os dados a serem comprovados geralmente são pequenos, mas a necessidade de várias provas permanece inalterada. Exemplos incluem:

1. Validação de transação pós-AA: \
   Com a Abstração de Conta (AA), as carteiras podem apontar para o código do contrato, ignorando ou personalizando etapas como verificação de nonce e assinatura, que são atualmente obrigatórias no Ethereum. No entanto, essa flexibilidade na validação requer a verificação do código do contrato ou de outros dados associados no estado para comprovar a validade da transação.
2. Chamadas RPC do cliente leve: \
   Clientes leves consultam dados de estado da rede (por exemplo, durante uma solicitação de eth_call) sem executar um nó completo. Para garantir a corretude deste estado, as provas devem suportar os dados consultados e confirmar que correspondem ao estado atual da rede.
3. Listas de inclusão: \
   Validadores menores podem usar mecanismos de lista de inclusão para garantir que as transações sejam incluídas no próximo bloco, limitando a influência dos poderosos produtores de bloco. No entanto, validar a inclusão dessas transações requer verificar sua correção.

Nesses casos de uso, as provas STARK oferecem pouca vantagem. STARKs, enfatizando escalabilidade (como destacado pelo “S” em seu nome), têm bom desempenho para conjuntos de dados grandes, mas têm dificuldades em cenários com poucos dados. Por outro lado, SNARKs, projetados para concisão (como enfatizado pelo “S” em seu nome), focam em minimizar o tamanho da prova, oferecendo claras vantagens em ambientes com restrições de largura de banda ou armazenamento.

As provas STARK geralmente têm um tamanho de 40 a 50 KB, cerca de 175 vezes maior do que provas SNARK, que têm apenas 288 bytes. Essa diferença de tamanho aumenta tanto o tempo de verificação quanto os custos de rede. A principal razão para as provas maiores do STARK é a dependência da transparência e dos compromissos polinomiais para garantir a escalabilidade, o que introduz custos de desempenho em cenários de pequenos dados. Em tais casos, métodos mais rápidos e eficientes em termos de espaço, como Provas de Merkle, podem ser mais práticos. As Provas de Merkle oferecem baixos custos computacionais e atualizações rápidas, tornando-as adequadas para essas situações.

No entanto, as provas STARK continuam sendo cruciais para o futuro sem estado do Ethereum devido à sua segurança quântica.

Conforme resumido na tabela, o Ethereum tem quatro caminhos potenciais para escolher:

• Árvores Verkle
  1. A Verkle Trees recebeu amplo apoio da comunidade Ethereum, com reuniões quinzenais realizadas para facilitar seu desenvolvimento. Graças a esse trabalho e testes consistentes, a Verkle Trees se destaca como a solução mais madura e bem pesquisada entre as alternativas atuais. Além disso, suas propriedades aditivamente homomórficas eliminam a necessidade de recalcular cada ramo para atualizar a raiz do estado, ao contrário das árvores de Merkle, tornando as árvores de Verkle uma opção mais eficiente. Em comparação com outras soluções, a Verkle Trees enfatiza a simplicidade, aderindo a princípios de engenharia como “mantenha a simplicidade” ou “simples é o melhor”. Essa simplicidade facilita tanto a integração no Ethereum quanto a análise de segurança.
  2. No entanto, as árvores Verkle não são seguras para quantidades, o que impede que sejam uma solução a longo prazo. Se integrado ao Ethereum, essa tecnologia provavelmente precisaria ser substituída no futuro, quando soluções resistentes a quantidades forem necessárias. Até Vitalik vê as árvores Verkle como uma medida temporária para ganhar tempo para STARKs e outras tecnologias amadurecerem. Além disso, os compromissos de vetor baseados em curvas elípticas usados nas árvores Verkle impõem uma carga computacional mais alta em comparação com funções de hash simples. Abordagens baseadas em hash podem oferecer tempos de sincronização mais rápidos para nós completos. Além disso, a dependência de numerosas operações de 256 bits torna as árvores Verkle mais difíceis de provar usando SNARKs dentro de sistemas modernos de prova, complicando esforços futuros para reduzir os tamanhos de prova.

No entanto, é importante observar que as árvores Verkle, devido à sua falta de dependência de hash, são significativamente mais comprováveis ​​do que as árvores Merkle.

• STARKs + Funções de Hash Conservadoras
  1. A combinação de STARKs com funções de hash conservadoras bem estabelecidas, como SHA256 ou BLAKE, fornece uma solução robusta que fortalece a infraestrutura de segurança do Ethereum. Essas funções de hash têm sido amplamente utilizadas e testadas extensivamente tanto em domínios acadêmicos quanto práticos. Além disso, sua resistência quântica aumenta a resiliência do Ethereum contra ameaças futuras apresentadas por computadores quânticos. Para cenários críticos de segurança, essa combinação oferece uma base confiável.
  2. No entanto, o uso de funções hash conservadoras em sistemas STARK introduz limitações significativas de desempenho. Os requisitos computacionais dessas funções hash resultam em alta latência do provador, com a geração de prova levando mais de 10 segundos. Isso é uma grande desvantagem, especialmente em cenários como validação de bloco que exigem baixa latência. Embora esforços como propostas de gás multidimensionais tentem alinhar a latência do pior caso e a latência média, os resultados são limitados. Além disso, embora abordagens baseadas em hash possam facilitar tempos de sincronização mais rápidos, sua eficiência pode não estar alinhada com os objetivos de escalabilidade mais amplos dos STARKs. Os longos tempos de computação das funções hash tradicionais reduzem a eficiência prática e limitam sua aplicabilidade.
• STARKs + Funções de Hash Relativamente Novas
  1. STARKs combinados com novas funções de hash STARK-friendly da nova geração (por exemplo, Poseidon) melhoram significativamente o desempenho desta tecnologia. Essas funções de hash são projetadas para se integrar perfeitamente com sistemas STARK e reduzir drasticamente a latência do provador. Ao contrário das funções de hash tradicionais, elas permitem a geração de prova em apenas 1-2 segundos. Sua eficiência e baixa sobrecarga computacional aprimoram o potencial de escalabilidade dos STARKs, tornando-os altamente eficazes para lidar com grandes conjuntos de dados. Essa capacidade os torna particularmente atraentes para aplicações que exigem alto desempenho.
  2. No entanto, a novidade relativa dessas funções de hash exige uma análise extensiva de segurança e testes. A falta de testes abrangentes introduz riscos ao considerar sua implementação em ecossistemas críticos como o Ethereum. Além disso, uma vez que essas funções de hash ainda não são amplamente adotadas, os processos de teste e validação necessários podem atrasar os objetivos de verificabilidade do Ethereum. O tempo necessário para garantir totalmente sua segurança pode tornar esta opção menos atraente a curto prazo, potencialmente adiando as ambições de escalabilidade e verificabilidade do Ethereum.
• Árvores de Merkle baseadas em reticulados
  1. As árvores de Merkle baseadas em lattice oferecem uma solução inovadora que combina segurança quântica com a eficiência de atualização das árvores Verkle. Essas estruturas abordam as fraquezas tanto das árvores Verkle quanto dos STARKs e são consideradas uma opção promissora a longo prazo. Com seu design baseado em lattice, elas fornecem uma forte resistência às ameaças da computação quântica, alinhando-se com o foco do Ethereum em tornar seu ecossistema à prova de futuro. Além disso, ao manter as vantagens de atualização das árvores Verkle, elas visam fornecer segurança aprimorada sem sacrificar a eficiência.
  2. No entanto, a pesquisa sobre árvores de Merkle baseadas em reticulados ainda está em seus estágios iniciais e é amplamente teórica. Isso cria incertezas significativas sobre sua implementação prática e desempenho. Integrar tal solução ao Ethereum exigiria extensa pesquisa e desenvolvimento, bem como testes rigorosos para validar seus benefícios potenciais. Essas incertezas e complexidades infraestruturais tornam as árvores de Merkle baseadas em reticulados improváveis de ser uma escolha viável para o Ethereum em um futuro próximo, potencialmente atrasando o progresso em direção aos objetivos de verificabilidade da rede.

E o que dizer da execução: Provas de validade da execução do EVM

Tudo o que discutimos até agora gira em torno da remoção da necessidade de validadores para armazenar o estado anterior, que eles usam para fazer a transição de um estado para o outro. O objetivo é criar um ambiente mais descentralizado onde os validadores possam executar suas funções sem manter terabytes de dados de estado. Mesmo com as soluções que mencionamos, os validadores não precisariam armazenar todo o estado, pois receberiam todos os dados necessários para a execução por meio de testemunhas incluídas no bloco. No entanto, para fazer a transição para o próximo estado — e, assim, verificar o stateRoot na parte superior do bloco — os validadores ainda devem executar o STF. Esse requisito, por sua vez, representa outro desafio para a natureza sem permissão e descentralização do Ethereum.

Inicialmente, o Verge foi concebido como um marco que se concentrou exclusivamente na transição da árvore de estado do Ethereum de Árvores de Merkle para Árvores de Verkle para melhorar a verificabilidade do estado. Com o tempo, no entanto, evoluiu para uma iniciativa mais ampla destinada a aprimorar a verificabilidade das transições de estado e do consenso. Em um mundo onde o trio Estado, Execução e Consenso é totalmente verificável, os validadores do Ethereum poderiam operar em praticamente qualquer dispositivo com conexão à internet que possa ser categorizado como um Cliente Leve. Isso aproximaria o Ethereum de alcançar sua visão de “verdadeira descentralização”.

Qual é a definição do problema?

Como mencionamos anteriormente, os validadores executam uma função chamada STF (Função de Transição de Estado) a cada 12 segundos. Esta função recebe o estado anterior e um bloco como entradas e produz o próximo estado como saída. Os validadores devem executar esta função toda vez que um novo bloco é proposto e verificar se o hash que representa o estado no topo do bloco - comumente referido como a raiz do estado - está correto.

Os altos requisitos do sistema para se tornar um validador derivam principalmente da necessidade de executar esse processo de forma eficiente.

Se você deseja transformar uma geladeira inteligente - sim, até mesmo uma geladeira - em um validador do Ethereum com a ajuda de algum software instalado, você enfrenta dois obstáculos principais:

1. Seu refrigerador provavelmente não terá internet suficientemente rápida, o que significa que não será capaz de baixar os dados e as provas necessárias para a execução, mesmo com as soluções de verificabilidade de estado que discutimos até agora.
2. Mesmo que tivesse acesso aos dados necessários para STF, não teria o poder computacional necessário para executar do início ao fim ou construir uma nova árvore de estado.

Para resolver os problemas causados pelos Light Clients não terem acesso nem ao estado anterior nem à totalidade do último bloco, o Verge propõe que o proponente execute e anexe uma prova ao bloco. Essa prova incluiria a transição da raiz do estado anterior para a raiz do próximo estado, bem como o hash do bloco. Com isso, os Light Clients podem validar a transição de estado usando apenas três hashes de 32 bytes, sem precisar de uma prova de conhecimento-zero (zk-proof).

No entanto, como essa prova funciona por meio de hashes, seria incorreto dizer que ela apenas valida a transição de estado. Pelo contrário, a prova anexada ao bloco deve validar várias coisas simultaneamente:

Raiz do estado no bloco anterior = S, Raiz do estado no próximo bloco = S + 1, Hash do bloco = H

1. O próprio bloco deve ser válido, e a prova de estado dentro dele - seja uma Prova Verkle ou STARKs - deve verificar com precisão os dados que acompanham o bloco.
   Em resumo: Validação do bloco e a prova de estado acompanhante.
2. Quando o STF é executado usando os dados necessários para a execução e incluído no bloco correspondente a H, os dados que devem mudar no estado devem ser atualizados corretamente.
   Em resumo: Validação da transição de estado.
3. Quando uma nova árvore de estado é reconstruída com os dados corretamente atualizados, seu valor de raiz deve corresponder a S + 1.
   Em resumo: Validação do processo de construção da árvore.

Na analogia de Provador-Verificador que referimos anteriormente, é geralmente justo dizer que geralmente há um equilíbrio computacional entre os dois atores. Embora a capacidade de provas necessárias para tornar o STF verificável para validar várias coisas simultaneamente ofereça vantagens significativas para o Verificador, também indica que gerar tais provas para garantir a correção da execução será relativamente desafiador para o Provador. Com a velocidade atual do Ethereum, um bloco do Ethereum precisa ser comprovado em menos de 4 segundos. No entanto, mesmo o Provador EVM mais rápido que temos hoje só consegue provar um bloco médio em aproximadamente 15 segundos.[1]

Dito isso, existem três caminhos distintos que podemos seguir para superar esse grande desafio:

1. Paralelização na Prova & Agregação: Uma das vantagens significativas das provas ZK é a capacidade de serem agregadas. A capacidade de combinar múltiplas provas em uma única prova compacta proporciona eficiência substancial em termos de tempo de processamento. Isso não só reduz a carga na rede, mas também acelera os processos de verificação de forma descentralizada. Para uma rede grande como o Ethereum, isso permite a geração mais eficiente de provas para cada bloco.

Durante a geração de prova, cada pequena parte do processo de execução (por exemplo, etapas de computação ou acesso de dados) pode ser provada individualmente e essas provas podem ser agregadas posteriormente em uma única estrutura. Com o mecanismo correto, essa abordagem permite que as provas de um bloco sejam geradas rapidamente e de forma descentralizada por muitas fontes diferentes (por exemplo, centenas de GPUs). Isso aumenta o desempenho e contribui para o objetivo de descentralização, envolvendo uma ampla gama de participantes.

1. Usando Sistemas de Prova Otimizados: Os sistemas de prova de nova geração têm o potencial de tornar os processos computacionais do Ethereum mais rápidos e eficientes. Sistemas avançados como Orion, Bínio, e GKR pode reduzir significativamente o tempo do provador para computações de propósito geral. Esses sistemas visam superar as limitações das tecnologias atuais, aumentando a velocidade de processamento enquanto consomem menos recursos. Para uma rede focada em escalabilidade e eficiência como o Ethereum, essas otimizações proporcionam uma vantagem significativa. No entanto, a implementação completa desses novos sistemas requer testes abrangentes e esforços de compatibilidade dentro do ecossistema.
2. Mudanças no custo do gás: Historicamente, os custos do gás para operações na Máquina Virtual Ethereum (EVM) eram tipicamente determinados com base em seus custos computacionais. No entanto, hoje em dia, outra métrica ganhou destaque: a complexidade do provador. Enquanto algumas operações são relativamente fáceis de provar, outras têm uma estrutura mais complexa e levam mais tempo para verificar. Ajustar os custos do gás não apenas com base no esforço computacional, mas também na dificuldade de provar as operações, é fundamental para aprimorar tanto a segurança quanto a eficiência da rede.

Esta abordagem pode minimizar a diferença entre os cenários de pior caso e caso médio, permitindo um desempenho mais consistente. Por exemplo, operações que são mais difíceis de provar podem ter custos de gás mais altos, enquanto aquelas que são mais fáceis de provar podem ter custos mais baixos. Além disso, substituir as estruturas de dados do Ethereum (como a árvore de estados ou a lista de transações) por alternativas amigáveis ao STARK poderia acelerar ainda mais os processos de prova. Essas mudanças ajudariam o Ethereum a alcançar seus objetivos de escalabilidade e segurança, ao mesmo tempo que tornariam sua visão de verificabilidade mais realista.

Os esforços da Ethereum para permitir provas de execução representam uma oportunidade significativa para atingir suas metas de verificabilidade. No entanto, alcançar esse objetivo requer não apenas inovações técnicas, mas também maiores esforços de engenharia e decisões críticas dentro da comunidade. Tornar os processos de execução verificáveis na Camada 1 deve encontrar um equilíbrio entre ser acessível a uma ampla base de usuários, preservando a descentralização e alinhando-se com a infraestrutura existente. O estabelecimento desse equilíbrio aumenta a complexidade dos métodos utilizados para comprovar as operações durante a execução, destacando a necessidade de avanços como a geração paralela de provas. Além disso, os requisitos de infraestrutura dessas tecnologias (por exemplo, tabelas de pesquisa) deve ser implementada e operacionalizada, o que ainda exige uma pesquisa e desenvolvimento substanciais.

Por outro lado, circuitos especializados (por exemplo, ASICs, FPGAs, GPUs) projetados especificamente para certas tarefas têm um potencial significativo para acelerar o processo de geração de prova. Essas soluções fornecem uma eficiência muito maior em comparação com hardware tradicional e podem acelerar os processos de execução. No entanto, os objetivos de descentralização do Ethereum no nível da Camada 1 impedem que esse hardware seja acessível apenas a um grupo seleto de atores. Como resultado, espera-se que essas soluções sejam mais amplamente utilizadas em sistemas da Camada 2. No entanto, a comunidade também precisa chegar a um consenso sobre os requisitos de hardware para a geração de prova. Uma questão de design fundamental surge: a geração de prova deve funcionar em hardware de consumo, como laptops de alto desempenho, ou exigir infraestrutura industrial? A resposta molda toda a arquitetura do Ethereum - permitindo otimização agressiva para soluções da Camada 2, ao mesmo tempo em que exige abordagens mais conservadoras para a Camada 1.

Finalmente, a implementação de provas de execução está diretamente ligada aos outros objetivos de roadmap da Ethereum. A introdução de provas de validade não apenas suportaria conceitos como a falta de estado, mas também aprimoraria a descentralização da Ethereum, tornando áreas como o solo staking mais acessíveis. O objetivo é permitir o staking até nos dispositivos de menor especificação. Além disso, a reestruturação dos custos de gás na EVM com base na dificuldade computacional e na provabilidade poderia minimizar a lacuna entre os cenários de caso médio e pior caso. No entanto, tais mudanças poderiam quebrar a compatibilidade com o sistema atual e forçar os desenvolvedores a reescreverem seu código. Por essa razão, a implementação de provas de execução não é apenas um desafio técnico - é uma jornada que deve ser projetada para manter os valores de longo prazo da Ethereum.

Último passo para a verdadeira verificabilidade total: Consenso

O mecanismo de consenso do Ethereum se esforça para estabelecer um equilíbrio único que preserva a descentralização e a acessibilidade, ao mesmo tempo em que alcança objetivos de verificabilidade. Nesse contexto, métodos de consenso probabilísticos e determinísticos oferecem vantagens e desafios distintos.

O consenso probabilístico é construído com base em um modelo de comunicação por fofoca. Neste modelo, em vez de se comunicar diretamente com todos os nós que representam a rede, um nó compartilha informações com um conjunto selecionado aleatoriamente de 64 ou 128 nós. A seleção da cadeia de um nó é baseada nessas informações limitadas, o que introduz a possibilidade de erro. No entanto, com o tempo, à medida que o blockchain avança, espera-se que essas seleções converjam para a cadeia correta com uma taxa de erro de 0%.

Uma vantagem da estrutura probabilística é que cada nó não transmite sua visão em cadeia como uma mensagem separada, reduzindo a sobrecarga de comunicação. Consequentemente, essa estrutura pode operar com nós descentralizados muito mais sem permissão e com requisitos de sistema mais baixos. Em contraste, o consenso determinista opera por meio de um modelo de comunicação um-para-todos. Aqui, um nó envia sua visão em cadeia como um voto para todos os outros nós. Essa abordagem gera maior intensidade de mensagem e, à medida que o número de nós cresce, o sistema pode eventualmente atingir seus limites. No entanto, a maior vantagem do consenso determinístico é a disponibilidade de votos concretos, permitindo saber exatamente qual nó votou em qual bifurcação. Isso garante uma finalização rápida e definitiva da cadeia, garantindo que os blocos não possam ter sua ordem alterada e tornando-os verificáveis.

Para fornecer um mecanismo de consenso verificável, preservando a descentralização e uma estrutura sem permissão, o Ethereum conseguiu um equilíbrio entre slots e épocas. Os slots, que representam intervalos de 12 segundos, são as unidades básicas em que um validador é responsável por produzir um bloco. Embora o consenso probabilístico usado no nível do slot permita que a cadeia opere de forma mais flexível e descentralizada, ele tem limitações em termos de ordem definitiva e verificabilidade.

Épocas, que englobam 32 slots, introduzem consenso determinístico. Neste nível, os validadores votam para finalizar a ordem da cadeia, garantindo certeza e tornando a cadeia verificável. No entanto, embora esta estrutura determinística forneça verificabilidade através de votos concretos no nível da época, não pode oferecer verificabilidade completa dentro das próprias épocas devido à estrutura probabilística. Para abordar essa lacuna e fortalecer a estrutura probabilística dentro das épocas, o Ethereum desenvolveu uma solução conhecida como o Comitê de Sincronização.

Protocolo do Cliente Leve Altair: Comitê de Sincronização

O Comitê de Sincronização é um mecanismo introduzido com a atualização Altair para superar as limitações do consenso probabilístico do Ethereum e melhorar a verificabilidade da cadeia para clientes leves. O comitê é composto por 512 validadores selecionados aleatoriamente que atuam por 256 épocas (~27 horas). Esses validadores produzem uma assinatura representando a cabeça da cadeia, permitindo que clientes leves verifiquem a validade da cadeia sem precisar baixar dados históricos da cadeia. A operação do Comitê de Sincronização pode ser resumida da seguinte forma:

1. Formação do Comitê:
   512 validadores são selecionados aleatoriamente de todos os validadores na rede. Esta seleção é regularmente atualizada para manter a descentralização e evitar a dependência de um grupo específico.
2. Geração de assinatura:
   Os membros do comitê produzem uma assinatura que representa o estado mais recente da cadeia. Essa assinatura é uma assinatura BLS coletiva criada pelos membros e é usada para verificar a validade da cadeia.
3. Verificação do Cliente Leve:
   Clientes leves podem verificar a correção da cadeia simplesmente verificando a assinatura do Comitê de Sincronização. Isso lhes permite acompanhar com segurança a cadeia sem baixar os dados da cadeia passada.

No entanto, o Comitê de Sincronização tem sido alvo de críticas em algumas áreas. Notavelmente, o protocolo carece de um mecanismo para cortar validadores por comportamento malicioso, mesmo que os validadores selecionados atuem intencionalmente contra o protocolo. Como resultado, muitos consideram o Comitê de Sincronização como um risco à segurança e se abstêm de classificá-lo completamente como um Protocolo de Cliente Leve. No entanto, a segurança do Comitê de Sincronização foi matematicamente comprovada, e mais detalhes podem ser encontrados em este artigo sobre Cortes de Comitê de Sincronização.

A ausência de um mecanismo de corte no protocolo não é uma escolha de design, mas uma necessidade decorrente da natureza do consenso probabilístico. O consenso probabilístico não fornece garantias absolutas sobre o que um validador observa. Mesmo que a maioria dos validadores relate um determinado fork como o mais pesado, ainda pode haver validadores excepcionais observando um fork diferente como mais pesado. Essa incerteza torna desafiador provar a intenção maliciosa e, portanto, impossível penalizar o mau comportamento.

Nesse contexto, em vez de rotular o Comitê de Sincronização como inseguro, seria mais preciso descrevê-lo como uma solução ineficiente. O problema não decorre do design mecânico ou da operação do Comitê de Sincronização, mas da natureza inerente do consenso probabilístico. Como o consenso probabilístico não pode oferecer garantias definitivas sobre o que os nós observam, o Comitê de Sincronização é uma das melhores soluções que pode ser projetada dentro de tal modelo. No entanto, isso não elimina as fraquezas do consenso probabilístico na garantia da finalidade da cadeia. O problema não está no mecanismo, mas na estrutura de consenso atual do Ethereum.

Devido a essas limitações, há esforços contínuos no ecossistema Ethereum para redesenhar o mecanismo de consenso e implementar soluções que forneçam finalidade determinística em períodos mais curtos. Propostas como Orbit-SSFe3SFpretende reformular a estrutura de consenso do Ethereum desde o início, criando um sistema mais eficaz para substituir o consenso probabilístico. Tais abordagens buscam não apenas encurtar o tempo de finalização da cadeia, mas também oferecer uma estrutura de rede mais eficiente e verificável. A comunidade do Ethereum continua a desenvolver e preparar ativamente essas propostas para implementações futuras.

Snarkification of Consensus

O Verge tem como objetivo melhorar os mecanismos de consenso atuais e futuros do Ethereum tornando-os mais verificáveis por meio da tecnologia zk-proof, em vez de substituí-los completamente. Essa abordagem busca modernizar os processos de consenso do Ethereum, preservando seus princípios fundamentais de descentralização e segurança. A otimização de todos os processos de consenso históricos e atuais da cadeia com tecnologias zk desempenha um papel fundamental na conquista dos objetivos de escalabilidade e eficiência de longo prazo do Ethereum. As operações fundamentais utilizadas na camada de consenso do Ethereum são de grande importância nessa transformação tecnológica. Vamos dar uma olhada mais de perto nessas operações e nos desafios que elas enfrentam.

• ECADDs:
  • Finalidade: Esta operação é usada para agregar chaves públicas dos validadores e é vital para garantir a precisão e eficiência da cadeia. Graças à natureza agregada das assinaturas BLS, várias assinaturas podem ser combinadas em uma única estrutura. Isso reduz a sobrecarga de comunicação e torna os processos de verificação na cadeia mais eficientes. Garantir a sincronização entre grandes grupos de validadores de forma mais eficaz torna essa operação crítica.
  • Desafios: Como mencionado anteriormente, os validadores do Ethereum votam na ordem da cadeia durante os epochs. Hoje, o Ethereum é uma rede com aproximadamente 1,1 milhão de validadores. Se todos os validadores tentassem propagar seus votos simultaneamente, isso criaria uma pressão significativa na rede. Para evitar isso, o Ethereum permite que os validadores votem com base no slot durante um epoch, onde apenas 1/32 de todos os validadores votam por slot. Embora esse mecanismo reduza a sobrecarga de comunicação da rede e torne o consenso mais eficiente, dado o número atual de validadores, cerca de 34.000 validadores votam em cada slot. Isso se traduz em aproximadamente 34.000 operações ECADD por slot.
• Pares:
  • Objetivo: As operações de emparelhamento são usadas para verificar assinaturas BLS, garantindo a validade de épocas na cadeia. Essa operação permite a verificação em lote de assinaturas. No entanto, não é compatível com zk, o que torna extremamente custoso provar usando a tecnologia zk-proof. Isso representa um desafio importante na criação de um processo de verificação integrado com tecnologias de conhecimento zero.
  • Desafios: As operações de emparelhamento no Ethereum estão limitadas a um máximo de 128 atestações (assinaturas agregadas) por slot, resultando em menos operações de emparelhamento em comparação com ECADDs. No entanto, a falta de zk-amizade nessas operações representa um desafio significativo. Provar uma operação de emparelhamento com zk-provas é milhares de vezes mais caro do que provar uma operação ECADD [2]. Isso torna a adaptação de operações de emparelhamento para tecnologias de conhecimento zero um dos maiores obstáculos nos processos de verificação de consenso do Ethereum.
• Hashes SHA256:
  • Propósito: As funções de hash SHA256 são usadas para ler e atualizar o estado da cadeia, garantindo a integridade dos dados da cadeia. No entanto, a falta de amizade com zk leva a ineficiências nos processos de verificação baseados em zk-proof, representando um grande obstáculo para os objetivos futuros de verificabilidade da Ethereum.
  • Desafios: As funções de hash SHA256 são frequentemente usadas para ler e atualizar o estado da cadeia. No entanto, sua incompatibilidade com a zk-amizade conflita com os objetivos de verificação baseados em zk-prova do Ethereum. Por exemplo, entre dois períodos, cada validador executa o STF da Camada de Consenso do Ethereum para atualizar o estado com recompensas e penalidades com base no desempenho do validador durante o período. Esse processo depende fortemente das funções de hash SHA256, aumentando significativamente os custos em sistemas baseados em zk-prova. Isso cria uma barreira substancial para alinhar o mecanismo de consenso do Ethereum com as tecnologias zk.

As operações ECADD, Pairing e SHA256 usadas na camada de consenso atual desempenham um papel crítico nos objetivos de verificabilidade do Ethereum. No entanto, a falta de zk-amizade apresenta desafios significativos no caminho para alcançar esses objetivos. As operações ECADD criam um ônus custoso devido ao alto volume de votos de validadores, enquanto as operações de Pairing, apesar de serem menos numerosas, são milhares de vezes mais caras de provar com zk-provas. Além disso, a falta de zk-amizade das funções de hash SHA256 torna extremamente desafiador provar a transição de estado da cadeia de beacons. Essas questões destacam a necessidade de uma transformação abrangente para alinhar a infraestrutura existente do Ethereum com as tecnologias de conhecimento zero.

Solução “Beam Chain”: Reimaginando a Camada de Consenso do Ethereum

Em 12 de novembro de 2024, durante sua apresentação na Devcon, Justin Drake apresentou uma proposta chamada “Beam Chain” com o objetivo de transformar fundamental e abrangentemente a Camada de Consenso do Ethereum. A Beacon Chain tem sido o núcleo da rede Ethereum há quase cinco anos. No entanto, durante este período, não houve grandes mudanças estruturais na Beacon Chain. Em contraste, os avanços tecnológicos progrediram rapidamente, superando em muito a natureza estática da Beacon Chain.

Em sua apresentação, Justin Drake enfatizou que o Ethereum aprendeu lições significativas ao longo desses cinco anos em áreas críticas, como compreensão de MEV, avanços nas tecnologias SNARK e consciência retrospectiva de erros tecnológicos. Os projetos informados por esses novos aprendizados são categorizados em três pilares principais: Produção de Blocos, Staking e Criptografia. O visual a seguir resume esses projetos e o roteiro proposto:

• Caixas verdes e cinzas representam desenvolvimentos incrementais que podem ser implementados ano a ano. Estes tipos de melhorias, assim como atualizações anteriores, podem ser integrados passo a passo sem perturbar a arquitetura existente do Ethereum.
• Por outro lado, caixas vermelhas significam mudanças de alta sinergia, em grande escala e fundamentais que devem ser implementadas juntas. De acordo com Drake, essas mudanças visam avançar a capacidade e verificabilidade do Ethereum em um grande salto.

Nesta seção, examinamos em detalhes as etapas de Consenso, Estado e Execução do Verge, e um dos problemas mais proeminentes destacados durante esse processo é o uso da função de hash SHA256 na Beacon Chain do Ethereum. Embora o SHA256 desempenhe um papel central na garantia da segurança da rede e no processamento de transações, sua falta de amizade com zk representa um obstáculo significativo para alcançar os objetivos de verificabilidade do Ethereum. Seu alto custo computacional e incompatibilidade com tecnologias zk tornam-se um problema crítico que deve ser abordado no futuro desenvolvimento do Ethereum.

O roteiro de Justin Drake, apresentado durante sua palestra no Devcon, prevê substituir o SHA256 no Beacon Chain por funções de hash amigáveis ao zk, como o Poseidon. Esta proposta visa modernizar a camada de consenso do Ethereum, tornando-a mais verificável, eficiente e alinhada com as tecnologias à prova de zk.

Nesse contexto, vemos que o Ethereum não apenas enfrenta desafios com funções de hash incompatíveis com zk, mas também precisa reavaliar as assinaturas digitais usadas em sua camada de consenso para segurança a longo prazo. Com o avanço da computação quântica, algoritmos de assinatura digital como ECDSA atualmente em uso podem enfrentar ameaças significativas. Conforme observado nas diretrizes publicadas pelo NIST, variantes do ECDSA com um nível de segurança de 112 bits serão obsoletas até 2030 e completamente proibidas até 2035. Isso exige uma transição para o Ethereum e redes similares em direção a alternativas mais resistentes, como assinaturas quânticas seguras no futuro.

Neste ponto, as assinaturas baseadas em hash surgem como soluções resistentes a quantum que poderiam desempenhar um papel crítico no suporte aos objetivos de segurança e verificabilidade da rede. Abordar essa necessidade também remove o segundo grande obstáculo para tornar a Beacon Chain verificável: Assinaturas BLS. Um dos passos mais significativos que o Ethereum pode dar em direção à garantia de segurança quântica é adotar soluções pós-quânticas como assinaturas baseadas em hash e SNARKs baseados em hash.

Como Justin Drake enfatizou emsua apresentação Devcon, as funções de hash são inherentemente resistentes a computadores quânticos devido à sua dependência de resistência à pré-imagem, tornando-as um dos blocos de construção fundamentais da criptografia moderna. Essa propriedade garante que mesmo os computadores quânticos não consigam reverter eficientemente a entrada original a partir de um determinado hash, preservando sua segurança. Os sistemas de assinatura baseados em hash permitem que validadores e atestadores gerem assinaturas inteiramente com base em funções de hash, garantindo segurança pós-quântica e também fornecendo um nível mais alto de verificabilidade em toda a rede - especialmente se uma função de hash amigável ao SNARK for usada. Essa abordagem não apenas aprimora a segurança da rede, mas também torna a infraestrutura de segurança de longo prazo do Ethereum mais robusta e à prova de futuro.

Este sistema baseia-se na combinação de assinaturas baseadas em hash e SNARKs baseados em hash (provas semelhantes a STARK) para criar esquemas de assinatura agregáveis. As assinaturas agregáveis comprimem milhares de assinaturas em uma única estrutura, reduzindo para apenas algumas centenas de quilobytes de prova. Esta compressão diminui significativamente a carga de dados na rede, ao mesmo tempo que acelera muito os processos de verificação. Por exemplo, as milhares de assinaturas de validador produzidas para um único slot no Ethereum podem ser representadas por uma única assinatura agregada, poupando tanto espaço de armazenamento quanto energia computacional.

No entanto, a característica mais notável deste esquema é a sua agregação infinitamente recursiva. Ou seja, um grupo de assinaturas pode ser combinado ainda mais sob outro grupo, e este processo pode continuar pela cadeia. Com este mecanismo e considerando os avanços tecnológicos futuros, é justo dizer que isso abre a porta para possibilidades atualmente inatingíveis com BLS.

Considerações Finais e Conclusão

O caminho do Ethereum para a verificabilidade representa uma mudança fundamental na tecnologia blockchain. A iniciativa Verge aborda as ineficiências principais por meio de Verkle Trees para verificação de estado e provas STARK para transições escaláveis.

Uma das propostas mais ambiciosas é a Beam Chain, uma reformulação abrangente da camada de consenso do Ethereum. Ao abordar as limitações da Beacon Chain e incorporar alternativas zk-friendly, essa abordagem visa aprimorar a escalabilidade do Ethereum, ao mesmo tempo em que preserva seus princípios fundamentais de descentralização e acessibilidade. No entanto, a transição também destaca os desafios que o Ethereum enfrenta ao equilibrar as demandas computacionais com seu objetivo de manter uma rede sem permissão, inclusiva.

Com o NIST planejando eliminar a criptografia de curva elíptica atual até 2035, o Ethereum deve adotar soluções resistentes a quântica como assinaturas baseadas em hash e Poseidon. Essas soluções apresentam seus próprios compromissos de eficiência.

O uso de STARKs no roteiro do Ethereum enfatiza ainda mais a escalabilidade e a verificabilidade. Embora sejam excelentes para fornecer provas transparentes e resistentes à computação quântica, sua integração apresenta desafios relacionados aos custos computacionais do lado do provador e às ineficiências de pequenos dados. Esses obstáculos devem ser abordados para alcançar totalmente a visão do Ethereum de estado sem estado e verificação eficiente de blocos, garantindo que a rede permaneça robusta diante da crescente demanda.

Apesar desses avanços, permanecem desafios-chave. O Ethereum deve lidar com questões de zk-friendliness, escalabilidade de consenso e as complexidades da integração de criptografia resistente a quantos. Além disso, a compatibilidade com as infraestruturas existentes apresenta obstáculos práticos que exigem soluções de engenharia cuidadosas para evitar interrupções tanto para desenvolvedores quanto para usuários.

O que diferencia o Ethereum não são apenas suas inovações técnicas, mas sua abordagem iterativa para resolver alguns dos problemas mais difíceis na blockchain. O caminho a seguir - seja por meio de tecnologias como Beam Chain, Verkle Trees ou STARK proofs - depende de um esforço colaborativo de desenvolvedores, pesquisadores e da comunidade em geral. Esses avanços não se tratam de alcançar a perfeição da noite para o dia, mas de criar uma base para uma internet transparente, descentralizada e verificável.

A evolução do Ethereum destaca seu papel como um jogador crucial na formação da era Web3. Ao enfrentar os desafios de hoje com soluções práticas, o Ethereum se aproxima de um futuro em que verificabilidade, resistência quântica e escalabilidade se tornam o padrão, e não a exceção.

Aviso Legal:

1. Este artigo é reproduzido a partir de[[](https://research.2077.xyz/the-verge-making-ethereum-verifiable-and-sustainable#the-path-to-verifiability)[Pesquisa 2077](https://research.2077.xyz/)\]. Todos os direitos autorais pertencem ao autor original [Koray Akpinarr]. Se houver objeções a esta reprodução, por favor entre em contato com o Gate Aprendaequipe e eles vão lidar com isso prontamente.
2. Aviso de responsabilidade: As opiniões expressas neste artigo são exclusivamente do autor e não constituem qualquer conselho de investimento.
3. As traduções do artigo para outros idiomas são feitas pela equipe do Gate Learn. A menos que mencionado, copiar, distribuir ou plagiar os artigos traduzidos é proibido.