O Caminho para a Verificabilidade

A principal vantagem do Web3 é a verificabilidade - os utilizadores podem verificar como os sistemas realmente operam. Esta funcionalidade 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 Instagram, onde os algoritmos e regras permanecem opacos mesmo quando documentados, os protocolos criptográficos são projetados para total auditabilidade. Mesmo que sejam compartilhados, você não tem a capacidade de verificar se a plataforma opera conforme 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 do recentemente publicado de Vitaliksérie de seis partes sobre o futuro do Ethereumpara analisar os passos que a 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 se tornar mais verificáveis, as inovações que essas mudanças trazem no nível do protocolo e como elas fornecem aos usuários um ecossistema mais seguro. Vamos começar!

O que significa “verificabilidade”?

As aplicações Web2 funcionam como “caixas-pretas” - os utilizadores apenas podem ver as suas entradas e as saídas resultantes, sem visibilidade sobre como a aplicação realmente funciona. Em contraste, os protocolos de criptomoedas normalmente disponibilizam publicamente o seu código fonte, ou no mínimo têm planos para o fazer. Esta transparência serve dois propósitos: permite aos utilizadores interagir diretamente com o código do protocolo, caso assim o desejem, e ajuda-os a compreender exatamente como o sistema opera e quais são as regras que o regem.

“Descentralize o que for possível, verifique o restante.”

A verificabilidade garante que os sistemas sejam responsabilizáveis e, em muitos casos, garante que os protocolos funcionem como previsto. Este princípio destaca a importância de minimizar a centralização, já que 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 responsabilizáveis, onde a descentralização não é viável.

A comunidade Ethereum parece alinhar-se com esta perspetiva, pois o roteiroinclui um marco (chamado de “The Verge”) com o objetivo de tornar o Ethereum mais verificável. No entanto, antes de mergulharmos 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 um tempo significativo para que uma transação se propague do nó de origem para todos os outros nós. Por esse motivo, 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 - pois eles têm apenas suas próprias perspectivas subjetivas.

Devido à importância da ordem das transações, as redes blockchain usam 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 das transações 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 computador coeso.

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

Depois que as transações são ordenadas com sucesso por consenso, cada transação deve ser aplicada ao estado atual na camada de execução. Se você está se perguntando: 'O que é o estado?', provavelmente viu comparações entre blockchains e bancos de dados - ou mais especificamente, o banco de dados de um banco, porque blockchains, assim como bancos, mantêm um registro dos saldos de todos.

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

No Bitcoin, o STF é principalmente limitado a mudanças 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.

Numa blockchain, existem três componentes fundamentais que precisa ou pode verificar:

1. Estado: Pode querer ler um pedaço de dados na blockchain, mas não tem acesso ao estado, uma vez que não executa um nó completo. Portanto, você solicita os dados por meio de um provedor RPC (Chamada de Procedimento Remoto) como Alchemy ou Infura. No entanto, é necessário verificar se os dados não foram adulterados pelo provedor RPC.
2. Execução: Como mencionado anteriormente, as blockchains utilizam uma STF. É necessário 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. Consenso: Entidades de terceiros, como RPCs, podem fornecer blocos válidos que ainda não foram incluídos no blockchain. Portanto, é necessário verificar se esses blocos foram aceitos por consenso e adicionados ao blockchain.

Se isto parecer confuso ou pouco claro, não se preocupe. Vamos analisar cada um destes aspetos em detalhe. Vamos começar por como verificar o estado da blockchain!

Como verificar o estado da blockchain?

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

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

À medida que cada nova transação modifica o estado, o stateRoot registado no bloco subsequente é atualizado em conformidade. Para calcular este valor, os validadores do Ethereum utilizam uma combinação da função hash Keccak e de uma estrutura de dados chamada Á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 Keccak são usados 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 de saída é sempre fixo.
3. Propriedade unidirecional: É praticamente impossível derivar a entrada original a partir da saída.
4. Unicidade: Mesmo uma pequena alteração na entrada produz uma saída completamente diferente. Assim, uma entrada específica mapeia para uma saída praticamente única.

Graças a estas 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 depois verificar se o estado indicado no bloco corresponde ao estado obtido após a STF. Este processo garante que o proponente do bloco agiu honestamente, tornando-se uma das principais responsabilidades dos validadores.

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

Uma vez que o estado do Ethereum tem terabytes de tamanho, é impraticável armazenar o estado inteiro em dispositivos do dia a dia, como telefones ou computadores pessoais. Por esta razão, o Ethereum utiliza uma estrutura de árvore de Merkle para calcular o stateRoot, preservando a verificabilidade do estado tanto quanto possível.

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

1. Nós folha: Estes 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 dos seus nós filhos. Por exemplo, numa árvore de Merkle binária (onde N=2), os hashes de dois nós filhos são concatenados e hasheados novamente para produzir o hash de um nó de ramificação num 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 está a perguntar como construir uma árvore desse tipo, 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.

• Combinar e hash: Os hashes dos nós folha são agrupados (por exemplo, em pares) e combinados, seguidos de hash. Este 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 hash.

O hash final obtido no topo da árvore é chamado de raiz de Merkle. A Raiz de Merkle 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?

As provas de Merkle permitem ao Verificador validar de forma eficiente partes específicas de dados, fornecendo uma série de valores de hash que criam um caminho desde os dados alvo (um nó folha) até à 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 de todo o estado.

A partir do ponto de dados específico, o Verificador combina-o com cada hash "irmão" fornecido na Prova de Merkle e os hashea passo a passo até a árvore. Este processo continua até que um único hash seja produzido. Se este hash calculado corresponder à 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 reivindicado.

Exemplo: Verificação de um ponto de dados com prova de Merkle

Digamos que tenhamos recebido o Dados n.º 4 de um RPC e queiramos verificar a sua autenticidade usando uma Prova de Merkle. Para fazer isso, o RPC forneceria um conjunto de valores de hash ao longo do caminho necessário para atingir a Raiz de Merkle. Para os Dados 4, estes hashes irmãos incluiriam o Hash n.º3, o Hash n.º12 e o Hash n.º5678.

1. Comece com Dados 4: Primeiro, hash Data #4 para obter Hash #4.
2. Combinar com os Irmãos: Em seguida, combinamos o Hash #4 com o Hash #3 (seu irmão no nível da folha) e os combinamos para produzir o Hash #34.
3. Suba na árvore: Em seguida, pegamos o Hash #34 e combinamo-lo com o Hash #12 (seu irmão na próxima nível acima) e os hash para obter o Hash #1234.
4. Etapa Final: Finalmente, combinamos o Hash #1234 com o Hash #5678 (o último irmão fornecido) e os juntamos. O hash resultante deve coincidir com a Raiz de Merkle (Hash #12345678) armazenada no cabeçalho do bloco.

Se o Merkle Root calculado corresponder à raiz do estado no bloco, confirmamos que os Dados nº 4 estão realmente válidos dentro deste estado. Caso contrário, sabemos que os dados não pertencem ao estado reivindicado, o que indica possíveis adulterações. Como pode ver, sem fornecer os hashes de todos os dados ou exigir que o Verificador reconstrua toda a Árvore de Merkle do zero, o Provador pode provar que os Dados nº 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 indiscutivelmente eficazes em fornecer verificação de dados segura e eficiente em grandes sistemas de blockchain como o Ethereum, serão elas verdadeiramente eficientes o suficiente? Para responder a isso, devemos analisar como o desempenho e o tamanho da árvore de Merkle impactam a relação Provador-Verificador.

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 que está a ser representado na árvore.

O Efeito do Fator de Ramificação:

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

• Fator de Ramificação Pequeno (por exemplo, Árvore de Merkle Binária):
  Se uma Árvore de Merkle binária (fator de ramificação 2) for usada, o tamanho da prova é muito pequeno, tornando o processo de verificação mais eficiente para o Verificador. Com apenas dois ramos 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 menor fator de ramificação aumenta a altura da árvore, exigindo mais operações de hash durante a construção da árvore, o que pode ser oneroso para os validadores.
• Fator de Ramificação Maior (por exemplo, 4):
  Um fator de ramificação maior (por exemplo, 4) reduz a altura da árvore, criando uma estrutura mais curta e mais larga. Isso permite que os Nós Completos construam a árvore mais rapidamente, uma vez que são necessárias menos operações de hash. No entanto, para o Verificador, isso aumenta o número de hashes irmãos que eles devem processar em cada nível, levando a 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, deslocando efetivamente o ônus dos validadores para os verificadores.

O efeito do tamanho total dos dados:

À medida que a blockchain Ethereum cresce, com cada nova transação, contrato ou interação do usuário adicionando-se ao conjunto de dados, a Árvore de Merkle também deve se expandir. Esse crescimento não apenas aumenta o tamanho da árvore, mas também impacta 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. \
  Este crescimento do tamanho dos dados aumenta a demanda tanto para nós completos como para verificadores, tornando mais difícil escalar a rede de forma eficiente.

Em resumo, embora as Merkle Trees ofereçam um grau de eficiência, elas ficam aquém de ser uma solução ideal para o conjunto de dados em crescimento contínuo do Ethereum. Por esta razão, durante a fase The Verge, o Ethereum pretende substituir Merkle Trees por uma estrutura mais eficiente conhecida como Árvores Verkle. 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 para provadores e verificadores.

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

A Verge foi desenvolvida como um marco na estrada do Ethereum com o objetivo de melhorar a verificabilidade, fortalecer a estrutura descentralizada da blockchain e aumentar a segurança da rede. Um dos principais objetivos da rede Ethereum é permitir que qualquer pessoa possa executar facilmente um validador para verificar a cadeia, criando uma estrutura onde a participação esteja aberta a todos sem centralização. A acessibilidade desse processo de verificação é uma das características-chave que distingue as blockchains dos sistemas centralizados. Enquanto os sistemas centralizados não oferecem capacidades de verificação, a correção de uma blockchain está completamente nas mãos de seus usuários. No entanto, para manter essa garantia, executar 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 Proof-of-Stake com The Merge, os validadores do Ethereum têm duas responsabilidades principais:

1. Assegurando o Consenso: Apoiando o funcionamento adequado de protocolos de consenso probabilísticos e determinísticos e aplicando o algoritmo de escolha de fork.
2. Verificação da Precisão do Bloco: Após a execução das transações num bloco, verificar 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 custo e mais sobre a dependência de hardware especializado para 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é mesmo smartwatches, permitindo que os validadores funcionem nesses dispositivos.

Primeiro Passo da Verificabilidade: Estado

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

Segundo 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 inflar para 330 MB. Sim, leu corretamente — 330 MB.

A extrema ineficiência das Árvores de Merkle do Ethereum em cenários de pior caso decorre de duas razões principais:

1. Uso de Árvores Hexary: 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 hash do código e usa o valor resultante como um nó. Considerando que o tamanho máximo de um contrato é 24 KB, essa abordagem impõe um fardo significativo para alcançar plena verificabilidade.

O tamanho da prova é diretamente proporcional ao fator de ramificação. A redução do fator de ramificação diminui o tamanho da prova. Para enfrentar 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 acesse 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, esta solução, embora melhor, ainda não é totalmente viável.

Por estas razões, a comunidade Ethereum propôs duas soluções distintas para resolver o problema:

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

Verkle Trees & Vector Commitments

Árvores Verkle, como o nome sugere, são estruturas de árvore semelhantes às Árvores de Merkle. No entanto, a diferença mais significativa reside na eficiência que oferecem durante os processos de verificação. Nas Árvores de Merkle, se um ramo contém 16 peças de dados e queremos 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.

Em contrapartida, as Árvores Verkle utilizam uma estrutura especializada conhecida como “Comprometimentos de Vetor Baseados em Curvas Elípticas”, mais especificamente, um Comprometimento 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 considerado um vetor: uma estrutura onde inúmeras peças de dados são armazenadas em uma ordem específica, sendo cada elemento crucial. Esse estado compreende vários componentes de dados, como endereços, códigos de contrato e informações de armazenamento, em que a ordem desses elementos desempenha um papel crítico no acesso e na verificação.

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

Ao contrário das Árvores de Merkle, as Árvores de Verkle utilizam compromissos de vetor baseados em curvas elípticas que oferecem duas vantagens-chave:

• Os compromissos vetoriais baseados em curvas elípticas eliminam a necessidade de detalhes de elementos além dos dados que estão sendo verificados. Em Árvores de Merkle com um fator de ramificação de 16, verificar um único ramo requer a disponibilização dos outros 15 hashes. Dado o tamanho vasto do estado do Ethereum, que envolve muitos ramos, isso cria uma ineficiência significativa. No entanto, os compromissos vetoriais baseados em curvas elípticas eliminam essa complexidade, permitindo a verificação com menos dados e esforço computacional.

• Através de várias provas, as provas geradas por compromissos de vetor 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 está em constante crescimento, o que significa que o número de ramos que precisam de verificação para acessar a Raiz de Merkle aumenta ao longo do tempo. No entanto, com as Árvores Verkle, podemos "comprimir" as provas para cada ramo em uma única prova de tamanho constante usando o método detalhado em Artigo de Dankrad Feist. Isso permite que os Verificadores validem toda a árvore com uma pequena prova em vez de verificar cada ramo individualmente. Isso também significa que as Árvores Verkle não são afetadas pelo crescimento do estado do Ethereum.

Essas características de compromissos de vetor baseados em curva elíptica reduzem significativamente a quantidade de dados necessários para verificação, permitindo que as árvores Verkle produzam provas pequenas e de tamanho constante, mesmo em cenários de pior caso. 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 de vetor baseados em curva elíptica em árvores Verkle permite um manuseio 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 curvas elípticas, que é vulnerável a computadores quânticos. Os computadores quânticos possuem poder computacional muito maior do que os métodos clássicos, representando uma ameaça significativa para os protocolos criptográficos baseados em curvas elípticas. Algoritmos quânticos podem potencialmente quebrar ou enfraquecer esses sistemas criptográficos, levantando preocupações sobre a segurança de longo prazo das Árvores Verkle.

Por este motivo, embora as Árvores Verkle ofereçam uma solução promissora em direção à falta de estado, elas não são a solução final. No entanto, figuras como Dankrad Feist enfatizaram que, embora seja necessária uma consideração cuidadosa ao integrar a criptografia resistente a quântica no Ethereum, vale ressaltar que os compromissos KZG atualmente usados para blobs no Ethereum também não são resistentes a quântica. Assim, as Árvores Verkle podem servir como uma 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 gerir o estado sempre crescente 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 a longo prazo está na transição para soluções resistentes a quântum. É aqui que as Provas STARK e as Árvores Merkle Binárias apresentam uma forte alternativa para construir 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. Esta 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 é onde as Provas STARK entram em jogo, comprimindo essas grandes Provas de Merkle Binárias para apenas 100-300 kB.

Esta otimização é particularmente vital ao considerar as limitações de operar validadores em clientes leves ou dispositivos com hardware limitado, especialmente se considerarmos que as velocidades médias de download e upload móveis globais são aproximadamente 7.625 MB/s e 1.5 MB/s, respetivamente. Os utilizadores podem verificar transações com provas pequenas e portáteis sem precisar de acesso ao estado completo, e os validadores podem realizar 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 que acelera a verificação, três melhorias-chave que apoiam diretamente a visão da Ethereum para escalabilidade.

Principais Desafios para Provas STARK:

1. Carga computacional elevada para os 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 tratamento de grandes conjuntos de dados, elas são menos eficientes ao provar pequenas quantidades de dados, o que pode dificultar sua aplicação em determinados cenários. Ao lidar com programas que envolvem etapas ou conjuntos de dados menores, o tamanho de prova relativamente grande dos STARKs pode torná-los menos práticos ou rentáveis.

A Segurança Quântica tem um Custo: Carga Computacional do Lado do Provedor

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

É aqui que as funções de hash amigáveis ao zk, como o Poseidon, entram em jogo, especificamente otimizadas para provas STARK para reduzir essa carga. Poseidon é projetado para funcionar mais perfeitamente com ZK-proofs em comparação com algoritmos de hash tradicionais como SHA256 e Keccak. A principal razão para essa compatibilidade reside em como os algoritmos de hash tradicionais operam: eles processam entradas como dados binários (0s e 1s). Por outro lado, as provas 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. A Poseidon resolve esse problema operando nativamente em campos nobres, acelerando drasticamente sua integração com ZK-proofs.

No entanto, como Poseidon é uma função hash relativamente nova, é necessário uma análise de segurança mais extensiva para estabelecer o mesmo nível de confiança que as funções hash tradicionais, como SHA256 e Keccak. Para esse fim, iniciativas como o Iniciativa de criptoanálise Poseidon, lançada pela Ethereum Foundation, convida especialistas a testarem e analisarem rigorosamente a segurança do Poseidon, garantindo que ele possa resistir ao escrutínio adversarial 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 comprovado de segurança, mas não são amigáveis aos ZK, resultando em queda de desempenho quando usadas com provas STARK.

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

Ineficiência do STARKs na prova de pequenos dados

Embora as provas STARK sejam excelentes em termos de escalabilidade e transparência para conjuntos de dados grandes, elas mostram limitações ao trabalhar com elementos de dados pequenos e numerosos. Nestes cenários, os dados a serem comprovados são frequentemente pequenos, mas a necessidade de múltiplas 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, contornando ou personalizando etapas como verificação de nonce e assinatura, que atualmente são obrigatórias no Ethereum. No entanto, essa flexibilidade na validação requer a verificação do código do contrato ou outros dados associados no estado para comprovar a validade da transação.
2. Chamadas de RPC do cliente leve: \
   Os clientes leves consultam dados do estado na rede (por exemplo, durante um pedido de eth_call) sem executar um nó completo. Para garantir a correção deste estado, as provas devem suportar os dados consultados e confirmar que correspondem ao estado atual da rede.
3. Listas de inclusão: \
   Os 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.

Em tais casos de uso, as provas STARK oferecem pouca vantagem. As STARKs, enfatizando escalabilidade (como destacado pelo "S" em seu nome), funcionam bem para grandes conjuntos de dados, mas têm dificuldades com cenários de dados pequenos. Ao contrário, as SNARKs, projetadas para concisão (como enfatizado pelo "S" em seu nome), focam na minimização do tamanho da prova, oferecendo claras vantagens em ambientes com restrições de largura de banda ou armazenamento.

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

No entanto, as provas STARK continuam 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:

• Verkle Trees
  1. As árvores Verkle têm recebido amplo apoio da comunidade Ethereum, com reuniões quinzenais realizadas para facilitar o seu desenvolvimento. Graças a este trabalho consistente e testes, as árvores Verkle destacam-se como a solução mais madura e bem pesquisada entre as alternativas atuais. Além disso, as suas propriedades aditivamente homomórficas eliminam a necessidade de recalcular cada ramo para atualizar a raiz do estado, ao contrário das árvores Merkle, tornando as árvores Verkle uma opção mais eficiente. Comparadas a outras soluções, as árvores Verkle enfatizam a simplicidade, aderindo a princípios de engenharia como "simplicidade é o melhor." Essa simplicidade facilita tanto a integração no Ethereum quanto a análise de segurança.
  2. No entanto, as Verkle Trees não são quânticas seguras, o que as impede de serem uma solução a longo prazo. Se integrada ao Ethereum, essa tecnologia provavelmente precisará ser substituída no futuro, quando soluções resistentes ao quântico forem necessárias. Até mesmo Vitalik vê Verkle Trees como uma medida temporária para ganhar tempo para STARKs e outras tecnologias amadurecerem. Além disso, os compromissos vetoriais baseados em curva elíptica usados em Verkle Trees impõem uma carga computacional maior em comparação com funções hash simples. As abordagens baseadas em hash podem oferecer tempos de sincronização mais rápidos para nós completos. Além disso, a dependência de inúmeras operações de 256 bits torna a Verkle Trees mais difícil de provar usando SNARKs dentro de sistemas de prova modernos, complicando os esforços futuros para reduzir os tamanhos das provas.

No entanto, é importante notar que as Árvores Verkle, devido à sua não 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 extensivamente testadas 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 do caso médio, 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 funções de hash amigáveis ​​à nova geração de STARKs (por exemplo, Poseidon) melhoram significativamente o desempenho desta tecnologia. Essas funções de hash são projetadas para se integrarem perfeitamente aos 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 melhoram o potencial de escalabilidade dos STARKs, tornando-os altamente eficazes no processamento de grandes conjuntos de dados. Essa capacidade os torna especialmente atrativos para aplicativos que exigem alto desempenho.
  2. No entanto, a relativa novidade dessas funções hash exige uma análise e teste de segurança extensivos. A falta de testes abrangentes introduz riscos ao considerar sua implementação em ecossistemas críticos como o Ethereum. Além disso, como essas funções 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 essa 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. A Merkle Trees baseada em rede oferece uma solução inovadora que combina segurança quântica com a eficiência de atualização da Verkle Trees. Estas estruturas abordam as fraquezas de Verkle Trees e STARKs e são consideradas uma opção promissora a longo prazo. Com seu design baseado em rede, eles fornecem forte resistência a ameaças de computação quântica, alinhando-se com o foco do Ethereum em preparar seu ecossistema para o futuro. Além disso, ao manter as vantagens de updatability do Verkle Trees, eles visam oferecer segurança aprimorada sem sacrificar a eficiência.
  2. No entanto, a pesquisa sobre as árvores de Merkle baseadas em lattice ainda está em estágios iniciais e em grande parte teórica. Isso cria uma incerteza significativa sobre sua implementação prática e desempenho. Integrar tal solução ao Ethereum exigiria uma pesquisa e desenvolvimento extensos, bem como testes rigorosos para validar seus benefícios potenciais. Essas incertezas e complexidades infraestruturais tornam as árvores de Merkle baseadas em lattice improváveis de serem uma escolha viável para o Ethereum no futuro próximo, o que pode atrasar o progresso em relaçã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 eliminação da necessidade de os validadores armazenarem o estado anterior, que eles usam para fazer a transição de um estado para o próximo. O objetivo é criar um ambiente mais descentralizado onde os validadores possam desempenhar suas funções sem manter terabytes de dados de estado. Mesmo com as soluções que mencionamos, os validadores não precisariam armazenar o estado inteiro, 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 sobre o bloco, os validadores ainda precisam executar o STF. Essa exigência, por sua vez, representa outro desafio para a natureza sem permissão e descentralização do Ethereum.

Inicialmente, o The Verge foi concebido como um marco que se concentrou exclusivamente na transição da árvore de estado do Ethereum de Merkle Trees para Verkle Trees para melhorar a verificabilidade do estado. Ao longo do tempo, no entanto, evoluiu para uma iniciativa mais ampla destinada a melhorar a verificabilidade das transições estatais e do consenso. Em um mundo onde o trio de Estado, Execução e Consenso é totalmente verificável, os validadores Ethereum podem operar em praticamente qualquer dispositivo com uma conexão à internet que pode ser categorizada como um Light Client. 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 (State Transition Function) 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 sempre que um novo bloco for proposto e verificar se o hash que representa o estado do topo do bloco, comumente referido como raiz do estado, está correto.

Os requisitos de sistema elevados para se tornar um validador decorrem principalmente da necessidade de realizar esse processo de forma eficiente.

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

1. O seu frigorífico provavelmente não terá internet suficientemente rápida, o que significa que não conseguirá baixar os dados e as provas necessárias para a execução, mesmo com as soluções de verificação de estado que discutimos até agora.
2. Mesmo que tivesse acesso aos dados necessários para STF, não teria a potência computacional necessária 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, A Verge propõe que o proponente execute e anexe uma prova ao bloco. Esta prova incluiria a transição da raiz do estado anterior para a raiz do estado seguinte, bem como o hash do bloco. Com isto, os Light Clients podem validar a transição de estado usando apenas três hashes de 32 bytes, sem necessidade de uma zk-proof.

No entanto, uma vez que esta prova funciona através de hashes, seria incorrecto dizer que apenas valida a transição de estado. Pelo contrário, a prova anexada ao bloco deve validar múltiplas coisas simultaneamente:

Raiz do estado no bloco anterior = S, Raiz do estado no bloco seguinte = 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 de 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 ser alterados 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 coincidir com S + 1.
   Em resumo: Validação do processo de construção da árvore.

Na analogia do Provador-Verificador que mencionamos anteriormente, é geralmente justo dizer que geralmente há um equilíbrio computacional entre os dois atores. Enquanto a capacidade de provas necessárias para tornar o STF verificável para validar várias coisas simultaneamente oferece 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 Ethereum precisa ser comprovado em menos de 4 segundos. No entanto, mesmo o Prover EVM mais rápido que temos hoje só consegue provar um bloco médio em aproximadamente 15 segundos.[1]

Dito isto, existem três caminhos distintos que podemos tomar para superar este grande desafio:

1. Paralelização na Prova e Agregação: Uma das vantagens significativas das provas ZK é a sua capacidade de serem agregadas. A capacidade de combinar várias provas em uma única prova compacta fornece 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 grande rede como o Ethereum, ele permite a geração mais eficiente de provas para cada bloco.

Durante a geração de provas, cada pequena parte do processo de execução (por exemplo, etapas de computação ou acesso a dados) pode ser provada individualmente, e essas provas podem ser posteriormente agregadas 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, ao mesmo tempo, contribui para o objetivo de descentralização, envolvendo um grupo mais amplo 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, Binius, e GKRpode reduzir significativamente o tempo do provador para cálculos de propósito geral. Estes sistemas visam superar as limitações das tecnologias atuais, aumentando a velocidade de processamento ao consumir menos recursos. Para uma rede com foco na escalabilidade e eficiência como o Ethereum, essas otimizações fornecem uma vantagem significativa. No entanto, a implementação completa desses novos sistemas requer testes abrangentes e esforços de compatibilidade dentro do ecossistema.
2. Alterações no custo de gás: Historicamente, os custos de 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 verificador. Enquanto algumas operações são relativamente fáceis de provar, outras têm uma estrutura mais complexa e levam mais tempo para serem verificadas. Ajustar os custos de gás não apenas com base no esforço computacional, mas também na dificuldade de provar operações, é fundamental para melhorar a segurança e eficiência da rede.

Esta abordagem pode minimizar a diferença entre os cenários de pior caso e de caso médio, possibilitando um desempenho mais consistente. Por exemplo, operações que são mais difíceis de provar poderiam ter custos de gás mais elevados, enquanto aquelas que são mais fáceis de provar poderiam ter custos menores. Além disso, substituir as estruturas de dados do Ethereum (como a árvore de estado ou a lista de transações) por alternativas amigáveis ​​ao STARK poderia acelerar ainda mais os processos de prova. Tais 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 alcançar seus objetivos de verificabilidade. No entanto, alcançar esse objetivo requer não apenas inovações técnicas, mas também 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, ao mesmo tempo em que preserva a descentralização e se alinha com a infraestrutura existente. Estabelecer esse equilíbrio aumenta a complexidade dos métodos usados para provar 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 implementado e operacionalizado, o que ainda exige uma pesquisa e desenvolvimento substanciais.

Por outro lado, circuitos especializados (por exemplo, ASICs, FPGAs, GPUs) projetados especificamente para tarefas específicas possuem um potencial significativo para acelerar o processo de geração de prova. Essas soluções oferecem uma eficiência muito maior em comparação com o hardware tradicional e podem acelerar os processos de execução. No entanto, os objetivos de descentralização do Ethereum no nível Layer 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 Layer 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 Layer 2, ao mesmo tempo em que exige abordagens mais conservadoras para Layer 1.

Finalmente, a implementação de provas de execução está diretamente relacionada aos outros objetivos da rota 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 do 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 no EVM com base na dificuldade computacional e na provabilidade poderia minimizar a diferença entre cenários médios e piores casos. No entanto, tais mudanças poderiam quebrar a compatibilidade retroativa com o sistema atual e forçar os desenvolvedores a reescreverem seu código. Por esse motivo, 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 do Ethereum.

Último passo para a verdadeira verificabilidade completa: 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 verificação. Nesse contexto, os 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 aleatório de 64 ou 128 nós. A escolha 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, tal estrutura pode operar com muito mais nós descentralizados e sem permissão com requisitos de sistema mais baixos. Em contraste, o consenso determinista opera através de um modelo de comunicação um-para-todos. Aqui, um nó envia sua exibiçã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 determinista é a disponibilidade de votos concretos, permitindo que você saiba 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 enquanto preserva a descentralização e uma estrutura sem permissão, o Ethereum encontrou um equilíbrio entre slots e épocas. Slots, que representam intervalos de 12 segundos, são as unidades básicas onde 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, possui limitações em termos de ordenação definitiva e verificabilidade.

Os éons, que abrangem 32 slots, introduzem um consenso determinístico. Neste nível, os validadores votam para finalizar a ordem da cadeia, garantindo a certeza e tornando a cadeia verificável. No entanto, embora esta estrutura determinística proporcione verificabilidade através de votos concretos no nível do éon, não pode oferecer verificabilidade total dentro dos próprios éons devido à estrutura probabilística. Para abordar essa lacuna e fortalecer a estrutura probabilística dentro dos éons, o Ethereum desenvolveu uma solução conhecida como o Comitê de Sincronização.

Altair's Light Client Protocol: 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 os 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. Esta assinatura é uma assinatura coletiva BLS 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 rastrear a cadeia com segurança sem baixar dados da cadeia passada.

No entanto, o Comité de Sincronização tem sido alvo de críticas em algumas áreas. Nomeadamente, o protocolo não possui um mecanismo para reduzir os validadores por comportamento malicioso, mesmo que os validadores selecionados ajam intencionalmente contra o protocolo. Como resultado, muitos consideram o Comité de Sincronização um risco de segurança e abstêm-se de o classificar totalmente como um Protocolo de Cliente Leve. No entanto, a segurança do Comité de Sincronização foi comprovada matematicamente e mais detalhes podem ser encontrados emeste artigo sobre Cortes de Comité de Sincronização.

A ausência de um mecanismo de corte no protocolo não é uma escolha de conceção, 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 relatem um garfo específico como o mais pesado, ainda pode haver validadores excecionais observando um garfo diferente como mais pesado. Esta incerteza torna difícil provar a intenção maliciosa e, portanto, impossível penalizar o mau comportamento.

Neste 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 ou operação mecânica do Comitê de Sincronização, mas da própria natureza 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 podem ser projetadas 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 atual de consenso 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 proporcionem finalidade determinística em períodos mais curtos. Propostas como Orbit-SSF e 3SFpretende 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 reduzir o tempo final da cadeia, mas também fornecer uma estrutura de rede mais eficiente e verificável. A comunidade Ethereum continua a desenvolver e preparar ativamente essas propostas para implementação futura.

Snarkification of Consenso

O Verge visa melhorar os mecanismos de consenso atuais e futuros do Ethereum tornando-os mais verificáveis através da tecnologia zk-proof, em vez de os substituir completamente. Esta abordagem procura modernizar os processos de consenso do Ethereum, preservando os 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 crítico na consecução dos objetivos de escalabilidade e eficiência a longo prazo do Ethereum. As operações fundamentais utilizadas na camada de consenso do Ethereum são de grande importância nesta transformação tecnológica. Vamos analisar mais de perto estas operações e os desafios que 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 em slots 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 de ECADD por slot.
• Pares:
  • Finalidade: As operações de emparelhamento são usadas para verificar assinaturas BLS, garantindo a validade dos epochs na cadeia. Essa operação permite a verificação em lote de assinaturas. No entanto, não é amigável ao zk, tornando extremamente custoso provar usando a tecnologia de prova-zk. Isso apresenta 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 amizade com zk 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. Isso torna a adaptação das 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 zk-amizade 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 falta de simpatia com zk entra em conflito com os objetivos de verificação baseados em zk do Ethereum. Por exemplo, entre duas épocas, 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 a época. Este processo depende fortemente das funções hash SHA256, aumentando significativamente os custos em sistemas baseados em zk-proof. 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 sua falta de convivialidade coloca desafios significativos no caminho para alcançar estes objetivos. As operações ECADD criam um fardo dispendioso devido ao alto volume de votos do validador, enquanto as operações de emparelhamento, apesar de serem em menor número, são milhares de vezes mais caras para provar com zk-proofs. Além disso, a falta de simpatia zk das funções hash SHA256 torna a comprovação da transição de estado da cadeia de beacons extremamente desafiadora. Essas questões destacam a necessidade de uma transformação abrangente para alinhar a infraestrutura existente do Ethereum com 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 a base da rede Ethereum há quase cinco anos. No entanto, durante esse período, não houve grandes mudanças estruturais na Beacon Chain. Em contraste, os avanços tecnológicos progrediram rapidamente, ultrapassando 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 retrospetiva de erros tecnológicos. Os projetos informados por esses novos aprendizados são categorizados em três pilares principais: Produção de Blocos, Estática e Criptografia. O visual a seguir resume esses projetos e o roteiro proposto:

• As caixas verdes e cinzentas representam desenvolvimentos incrementais que podem ser implementados um a um por ano. Esses tipos de melhorias, assim como as atualizações anteriores, podem ser integradas passo a passo sem interromper a arquitetura existente do Ethereum. \

• Por outro lado, as caixas vermelhas significam mudanças de alta sinergia, em grande escala e fundamentais que devem ser implementadas em conjunto. 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 The Verge, e uma das questões mais proeminentes destacadas 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 uma questão crítica que deve ser abordada nos futuros desenvolvimentos do Ethereum.

O roteiro de Justin Drake, apresentado durante sua palestra na Devcon, prevê substituir o SHA256 na 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-o mais verificável, eficiente e alinhado com tecnologias à prova de zk.

Neste contexto, vemos que Ethereum não só enfrenta desafios com funções de hash não amigáveis ​​a zk, mas também precisa reavaliar as assinaturas digitais usadas em sua camada de consenso para segurança de 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 depreciadas até 2030 e completamente proibidas em 2035. Isso torna necessária uma transição para Ethereum e redes semelhantes 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 quântica que poderiam desempenhar um papel crítico no apoio aos objetivos de segurança e verificabilidade da rede. Ao abordar essa necessidade, também se remove o segundo grande obstáculo para tornar a Beacon Chain verificável: as 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 hash são inerentemente resistentes aos computadores quânticos devido à sua dependência da resistência pré-imagem, tornando-as um dos blocos de construção fundamentais da criptografia moderna. Essa propriedade garante que mesmo computadores quânticos não possam fazer engenharia reversa eficiente da entrada original de um determinado hash, preservando sua segurança. Os sistemas de assinatura baseados em hash permitem que validadores e atestadores gerem assinaturas inteiramente baseadas em funções de hash, garantindo segurança pós-quântica e, ao mesmo tempo, 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 só melhora a segurança da rede, mas também torna a infraestrutura de segurança de longo prazo do Ethereum mais robusta e preparada para o 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 numa única estrutura, reduzindo-a para apenas algumas centenas de quilobytes de prova. Esta compressão diminui significativamente a carga de dados na rede, ao mesmo tempo que acelera bastante os processos de verificação. Por exemplo, as milhares de assinaturas de validadores produzidas para um único slot no Ethereum podem ser representadas por uma única assinatura agregada, poupando tanto espaço de armazenamento como potência 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 em outro grupo, e esse processo pode continuar em toda a cadeia. Com este mecanismo e considerando futuros avanços tecnológicos, é justo dizer que isso abre a porta para possibilidades atualmente inatingíveis com o SBV.

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 ineficiências centrais através das Árvores Verkle 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, esta abordagem visa melhorar a escalabilidade do Ethereum, ao mesmo tempo 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 e inclusiva.

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

O uso de STARKs no roadmap do Ethereum enfatiza ainda mais a escalabilidade e verificabilidade. Embora se destaquem na disponibilização de provas transparentes e resistentes à computação quântica, a sua integração introduz desafios relacionados com os custos computacionais do lado do provador e as ineficiências de dados pequenos. Estes obstáculos devem ser abordados para realizar plenamente a visão de estado sem estado do Ethereum e a verificação eficiente de blocos, garantindo que a rede permaneça robusta face à procura crescente.

Apesar desses avanços, ainda existem desafios importantes. Ethereum deve lidar com questões de compatibilidade com zk, escalabilidade de consenso e as complexidades da integração de criptografia resistente a quântica. Além disso, a compatibilidade reversa da infraestrutura existente apresenta obstáculos práticos que exigem soluções de engenharia cuidadosas para evitar interrupções para desenvolvedores e usuários.

O que diferencia o Ethereum não são apenas suas inovações técnicas, mas também sua abordagem iterativa para resolver alguns dos problemas mais difíceis no blockchain. O caminho a seguir - seja por meio de tecnologias como Beam Chain, Verkle Trees ou STARK proofs - depende de um esforço colaborativo entre desenvolvedores, pesquisadores e a 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 o seu papel como um jogador fundamental 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 a verificabilidade, a resistência quântica e a escalabilidade se tornam o padrão, não a exceção.

Aviso Legal:

1. Este artigo é reproduzido a partir de [2077 Pesquisa]. Todos os direitos autorais pertencem ao autor original [Koray Akpinarr]. Se houver objeções a esta reimpressão, por favor, entre em contato com o Gate Learnequipa, e eles tratarão disso prontamente.
2. Isenção de Responsabilidade: Os pontos de vista e opiniões expressos 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 equipa Learn da gate. Salvo indicação em contrário, é proibido copiar, distribuir ou plagiar os artigos traduzidos.