Uma forma pouco discutida, mas ainda assim muito importante, pela qual o Ethereum mantém a sua segurança e descentralização é a sua filosofia multi-cliente. O Ethereum não tem intencionalmente um "cliente de referência" que todos executam por defeito: em vez disso, há uma especificação gerida em colaboração (atualmente escrita em Python, muito legível mas muito lento) e há várias equipas que fazem implementações da especificação (também chamadas "clientes"), que é o que os utilizadores executam realmente.

Cada nó Ethereum executa um cliente de consenso e um cliente de execução. Atualmente, nenhum cliente de consenso ou de execução representa mais de 2/3 da rede. Se um cliente com menos de 1/3 de quota na sua categoria tiver um erro, a rede continuará a funcionar normalmente. Se um cliente com uma quota entre 1/3 e 2/3 na sua categoria (por exemplo, Prysm, Lighthouse ou Geth) tiver um erro, a cadeia continuará a adicionar blocos, mas deixará de finalizar blocos, dando tempo aos programadores para intervir.

Uma transição importante e pouco discutida, mas ainda assim muito importante, na forma como a cadeia Ethereum é validada é o surgimento das ZK-EVMs. Os SNARK que comprovam a execução de EVM estão a ser desenvolvidos há anos e a tecnologia está a ser ativamente utilizada por protocolos de nível 2 denominados ZK rollups. Alguns destes rollups ZK estão activos na rede principal hoje, e outros estão para breve. Mas, a longo prazo, os ZK-EVMs não serão apenas para rollups; queremos usá-los para verificar a execução na camada 1 também (veja também: the Verge).

Quando isso acontecer, os ZK-EVMs tornam-se de facto um terceiro tipo de cliente Ethereum, tão importante para a segurança da rede como os clientes de execução e os clientes de consenso são atualmente. E isto levanta naturalmente uma questão: como é que os ZK-EVMs vão interagir com a filosofia multi-cliente? Uma das partes difíceis já está feita: já temos várias implementações ZK-EVM que estão a ser ativamente desenvolvidas. Mas há outras partes difíceis que permanecem: como é que faríamos realmente um ecossistema "multi-cliente" para a correção da prova ZK dos blocos Ethereum? Esta questão abre alguns desafios técnicos interessantes - e, claro, a questão iminente de saber se as contrapartidas valem ou não a pena.

Qual foi a motivação original para a filosofia multi-cliente do Ethereum?

A filosofia multi-cliente do Ethereum é um tipo de descentralização e, tal como <a href="https://medium.com/@VitalikButerin/the-meaning-of-decentralization-a0c92b76a274"> descentralização em geral, pode centrar-se tanto nos benefícios técnicos da descentralização arquitetónica como nos benefícios sociais da descentralização política. Em última análise, a filosofia multicliente foi motivada por ambos e serve ambos.

Argumentos a favor da descentralização técnica

A principal vantagem da descentralização técnica é simples: reduz o risco de que um erro numa peça de software leve a um colapso catastrófico de toda a rede. Uma situação histórica que exemplifica este risco é o bug de transbordamento de Bitcoin de 2010. Na altura, o código do cliente Bitcoin não verificava se a soma dos outputs de uma transação não transbordava (voltava a zero ao somar acima do número inteiro máximo de^264-1) e, por isso, alguém fez uma transação que fez exatamente isso, dando a si próprio milhares de milhões de bitcoins. O bug foi descoberto em poucas horas, e uma correção foi feita à pressa e rapidamente implementada em toda a rede, mas se houvesse um ecossistema maduro na altura, essas moedas teriam sido aceites por bolsas, pontes e outras estruturas, e os atacantes poderiam ter fugido com muito dinheiro. Se houvesse cinco clientes Bitcoin diferentes, teria sido muito improvável que todos eles tivessem o mesmo bug, e assim teria havido uma divisão imediata, e o lado da divisão que tinha o bug teria provavelmente perdido.

Há uma desvantagem em usar a abordagem multi-cliente para minimizar o risco de bugs catastróficos: em vez disso, você obtém bugs de falha de consenso. Ou seja, se tiver dois clientes, existe o risco de os clientes terem interpretações subtilmente diferentes de alguma regra do protocolo e, embora ambas as interpretações sejam razoáveis e não permitam o roubo de dinheiro, o desacordo faria com que a cadeia se partisse ao meio. Uma divisão séria desse tipo aconteceu uma vez na história do Ethereum (houve outras divisões muito mais pequenas, em que partes muito pequenas da rede que executavam versões antigas do código se bifurcaram). Os defensores da abordagem de cliente único apontam as falhas de consenso como uma razão para não ter múltiplas implementações: se houver apenas um cliente, esse cliente não discordará de si próprio. O seu modelo de como o número de clientes se traduz em risco pode ser mais ou menos assim:

É claro que não concordo com esta análise. O ponto crucial da minha discordância é que (i) os erros catastróficos do estilo de 2010 também são importantes, e (ii) você nunca tem realmente apenas um cliente. Este último ponto é tornado mais óbvio pelo fork do Bitcoin de 2013: uma divisão da cadeia ocorreu devido a um desacordo entre duas versões diferentes do cliente Bitcoin, uma das quais acabou por ter um limite acidental e não documentado sobre o número de objectos que poderiam ser modificados num único bloco. Assim, um cliente em teoria é muitas vezes dois clientes na prática, e cinco clientes em teoria podem ser seis ou sete clientes na prática - por isso, devemos arriscar e ir para o lado certo da curva de risco, e ter pelo menos alguns clientes diferentes.

Argumentos a favor da descentralização política

Os criadores de clientes em regime de monopólio estão numa posição com muito poder político. Se um programador de um cliente propõe uma alteração e os utilizadores discordam, teoricamente podem recusar-se a descarregar a versão actualizada ou criar um fork sem ela, mas na prática é muitas vezes difícil para os utilizadores fazerem isso. E se uma alteração de protocolo desagradável for acompanhada de uma atualização de segurança necessária? E se a equipa principal ameaçar desistir se não conseguir o que quer? Ou, de forma mais branda, o que acontece se a equipa monopolista do cliente acabar por ser o único grupo com a maior experiência em protocolos, deixando o resto do ecossistema numa posição desfavorável para julgar os argumentos técnicos que a equipa do cliente apresenta, deixando à equipa do cliente muito espaço para promover os seus próprios objectivos e valores particulares, que podem não coincidir com a comunidade em geral?

A preocupação com a política do protocolo, particularmente no contexto das guerras OP_RETURN do Bitcoin de 2013-14, em que alguns participantes eram abertamente a favor da discriminação contra determinadas utilizações da cadeia, foi um fator contribuinte significativo para a adoção precoce pela Ethereum de uma filosofia multi-cliente, que visava dificultar a tomada desse tipo de decisões por um pequeno grupo. Preocupações específicas do ecossistema Ethereum - nomeadamente, evitar a concentração de poder na própria Fundação Ethereum - deram mais apoio a esta orientação. Em 2018, foi tomada a decisão de intencionalmente fazer com que a Fundação não fizesse uma implementação do protocolo Ethereum PoS (ou seja. o que atualmente se designa por "cliente de consenso"), deixando essa tarefa inteiramente a cargo de equipas externas.

Como é que os ZK-EVMs entrarão no nível 1 no futuro?

Atualmente, os ZK-EVM são utilizados em rollups. Isto aumenta a escala ao permitir que a execução dispendiosa de EVM aconteça apenas algumas vezes fora da cadeia, com todos os outros simplesmente verificando SNARKs postados na cadeia que provam que a execução de EVM foi computada corretamente. Permite também que alguns dados (nomeadamente assinaturas) não sejam incluídos na cadeia, poupando nos custos de gás. Isto dá-nos muitas vantagens em termos de escalabilidade, e a combinação de computação escalável com ZK-EVMs e dados escaláveis com <a href="https://hackmd.io/@vbuterin/sharding_proposal#ELI5-data-availability-sampling"> data availability sampling poderia permitir-nos escalar muito longe.

No entanto, a rede Ethereum atual também tem um problema diferente, que nenhuma quantidade de escalonamento da camada 2 pode resolver por si só: a camada 1 é difícil de verificar, ao ponto de não haver muitos utilizadores a gerir o seu próprio nó. Em vez disso, a maioria dos utilizadores confia simplesmente em fornecedores terceiros. Os clientes light como o Helios e o Succinct estão a dar passos no sentido de resolver o problema, mas um cliente light está longe de ser um nó totalmente verificador: um cliente light apenas verifica as assinaturas de um subconjunto aleatório de validadores chamado comité de sincronização, e não verifica se a cadeia segue realmente as regras do protocolo. Para chegarmos a um mundo em que os utilizadores possam realmente verificar se a cadeia segue as regras, teríamos de fazer algo diferente.

Opção 1: restringir a camada 1, forçar quase toda a atividade a deslocar-se para a camada 2

Poderíamos, com o tempo, reduzir o objetivo de gás por bloco da camada 1 de 15 milhões para 1 milhão, o suficiente para um bloco conter um único SNARK e algumas operações de depósito e levantamento, mas pouco mais, e assim forçar quase toda a atividade do utilizador a passar para os protocolos da camada 2. Tal projeto ainda poderia suportar muitos rollups em cada bloco: poderíamos usar protocolos de agregação fora da cadeia executados por construtores personalizados para reunir SNARKs de vários protocolos de camada 2 e combiná-los em um único SNARK. Nesse mundo, a única função do nível 1 seria ser uma câmara de compensação para os protocolos do nível 2, verificando as suas provas e, ocasionalmente, facilitando grandes transferências de fundos entre eles.

Esta abordagem poderia funcionar, mas tem vários pontos fracos importantes:

• É de facto incompatível com as versões anteriores, no sentido em que muitas aplicações existentes baseadas em L1 se tornam economicamente inviáveis. Os fundos dos utilizadores, até centenas ou milhares de dólares, podem ficar bloqueados à medida que as taxas se tornam tão elevadas que excedem o custo de esvaziar essas contas. Isto poderia ser resolvido permitindo que os utilizadores assinassem mensagens para optarem por uma migração em massa dentro do protocolo para um L2 à sua escolha (veja algumas ideias iniciais de implementação aqui), mas isto acrescenta complexidade à transição, e torná-la verdadeiramente barata o suficiente exigiria algum tipo de SNARK no nível 1 de qualquer forma. Eu geralmente sou um fã de quebrar a compatibilidade com versões anteriores quando se trata de <a href="https://hackmd.io/@vbuterin/selfdestruct"> coisas como o opcode SELFDESTRUCT, mas neste caso a troca parece muito menos favorável.
• Pode ainda não tornar a verificação suficientemente barata. Idealmente, o protocolo Ethereum deveria ser fácil de verificar, não só em computadores portáteis, mas também em telemóveis, extensões de browser e mesmo noutras cadeias. Sincronizar a cadeia pela primeira vez, ou depois de um longo período offline, também deve ser fácil. Um nó de portátil poderia verificar 1 milhão de gases em ~20 ms, mas mesmo isso implica 54 segundos para sincronizar após um dia offline (assumindo <a href="https://notes.ethereum.org/@vbuterin/single_slot_finality"> single slot finality aumenta os tempos das ranhuras para 32s) e, para telemóveis ou extensões de browser, demoraria algumas centenas de milissegundos por bloco e poderia ainda assim ser um consumo de bateria não negligenciável. Estes números são geríveis, mas não são ideais.
• Mesmo num ecossistema L2-first, há vantagens em que o L1 seja, pelo menos, um pouco acessível. Os Validiums podem beneficiar de um modelo de segurança mais forte se os utilizadores puderem retirar os seus fundos se verificarem que os novos dados sobre o Estado já não estão disponíveis. A arbitragem torna-se mais eficiente, especialmente para tokens mais pequenos, se o tamanho mínimo de uma transferência direta entre L2 economicamente viável for menor.

Por conseguinte, parece mais razoável tentar encontrar uma forma de utilizar ZK-SNARKs para verificar a própria camada 1.

Opção 2: SNARK - verifique a camada 1

Uma ZK-EVM de tipo 1 (totalmente equivalente ao Ethereum) pode ser utilizada para verificar a execução da EVM de um bloco Ethereum (camada 1). Poderíamos escrever mais código SNARK para verificar também o lado do consenso de um bloco. Este seria um problema de engenharia difícil: atualmente, os ZK-EVMs demoram minutos a horas a verificar os blocos Ethereum, e a geração de provas em tempo real exigiria um ou mais dos seguintes elementos: (i) melhorias no próprio Ethereum para remover os componentes hostis ao SNARK, (ii) grandes ganhos de eficiência com hardware especializado e (iii) melhorias arquitectónicas com muito mais paralelização. No entanto, não há nenhuma razão tecnológica fundamental para que não possa ser feito - e por isso espero que, mesmo que demore muitos anos, seja feito.

É aqui que vemos a intersecção com o paradigma multi-cliente: se utilizarmos ZK-EVMs para verificar o nível 1, que ZK-EVM utilizamos?

Vejo três opções:

1. ZK-EVM única: abandone o paradigma multi-cliente e escolha uma única ZK-EVM que utilizamos para verificar blocos.
2. Fechado multi ZK-EVM: acorde e consagre em consenso um conjunto específico de múltiplos ZK-EVMs, e tenha uma regra de protocolo de camada de consenso que um bloco precisa de provas de mais de metade dos ZK-EVMs nesse conjunto para ser considerado válido.
3. Open multi ZK-EVM: diferentes clientes têm diferentes implementações ZK-EVM, e cada cliente espera por uma prova que seja compatível com a sua própria implementação antes de aceitar um bloco como válido.

Para mim, (3) parece-me ideal, pelo menos até e a menos que a nossa tecnologia melhore ao ponto de podermos provar formalmente que todas as implementações ZK-EVM são equivalentes entre si, altura em que podemos simplesmente escolher a que for mais eficiente. (1) sacrificaria os benefícios do paradigma multi-cliente, e (2) fecharia a possibilidade de desenvolver novos clientes e levaria a um ecossistema mais centralizado. (3) tem desafios, mas esses desafios parecem menores do que os desafios das outras duas opções, pelo menos para já.

A implementação de (3) não seria muito difícil: poder-se-ia ter uma sub-rede p2p para cada tipo de prova, e um cliente que utilize um tipo de prova escutaria na sub-rede correspondente e esperaria até receber uma prova que o seu verificador reconhecesse como válida.

Os dois principais desafios de (3) são provavelmente os seguintes:

• O desafio da latência: um atacante malicioso pode publicar um bloco tardiamente, juntamente com uma prova válida para um cliente. É realista que demore muito tempo (mesmo que, por exemplo, 15 segundos) a gerar provas válidas para outros clientes. Este tempo seria suficientemente longo para criar um fork temporário e perturbar a cadeia durante alguns slots.
• Ineficiência de dados: uma das vantagens dos ZK-SNARKs é que os dados que só são relevantes para a verificação (por vezes chamados "dados de testemunha") podem ser removidos de um bloco. Por exemplo, depois de verificar uma assinatura, não precisa de manter a assinatura num bloco, pode apenas armazenar um único bit que diga que a assinatura é válida, juntamente com uma única prova no bloco que confirme que todas as assinaturas válidas existem. No entanto, se quisermos que seja possível gerar provas de vários tipos para um bloco, as assinaturas originais teriam de ser efetivamente publicadas.

O problema da latência pode ser resolvido se tiver cuidado ao conceber o protocolo de finalidade de ranhura única. Os protocolos de finalidade de ranhura única exigirão provavelmente mais de duas rondas de consenso por ranhura, pelo que se poderia exigir que a primeira ronda incluísse o bloco e apenas exigir que os nós verificassem as provas antes de assinar na terceira (ou última) ronda. Isto garante que existe sempre uma janela de tempo significativa entre o prazo de publicação de um bloco e a altura em que se espera que as provas estejam disponíveis.

A questão da eficiência dos dados teria de ser resolvida através de um protocolo separado para agregar os dados relativos à verificação. Para as assinaturas, podemos utilizar a agregação BLS, que o ERC-4337 já suporta. Outra categoria importante de dados relacionados com a verificação são as ZK-SNARKs utilizadas para a privacidade. Felizmente, estes tendem frequentemente a ter os seus próprios protocolos de agregação.

Também vale a pena mencionar que a verificação SNARK da camada 1 tem um benefício importante: o facto de a execução EVM na cadeia já não precisar de ser verificada por todos os nós permite aumentar consideravelmente a quantidade de execução EVM que tem lugar. Isto pode acontecer quer através de um grande aumento do limite de gás da camada 1, quer através da introdução de rollups consagrados, ou ambos.

Conclusões

Para que um ecossistema ZK-EVM multi-cliente aberto funcione bem, será necessário muito trabalho. Mas a boa notícia é que muito deste trabalho está a ser feito ou será feito de qualquer forma:

• Já temos várias implementações fortes de ZK-EVM. Estas implementações ainda não são do tipo 1 (totalmente equivalentes ao Ethereum), mas muitas delas estão a avançar ativamente nessa direção.
• O trabalho em clientes ligeiros como o Helios e o Succinct pode eventualmente transformar-se numa verificação SNARK mais completa do lado do consenso PoS da cadeia Ethereum.
• Os clientes provavelmente começarão a experimentar ZK-EVMs para provar a execução de blocos Ethereum por conta própria, especialmente quando tivermos clientes sem estado e não houver necessidade técnica de reexecutar diretamente cada bloco para manter o estado. É provável que se verifique uma transição lenta e gradual dos clientes que verificam os blocos Ethereum reexecutando-os para a maioria dos clientes que verificam os blocos Ethereum verificando as provas SNARK.
• É provável que os ecossistemas ERC-4337 e PBS comecem a trabalhar com tecnologias de agregação como BLS e agregação de provas muito em breve, a fim de poupar nos custos do gás. No que respeita à agregação BLS, os trabalhos já começaram.

Com estas tecnologias, o futuro afigura-se-lhe muito promissor. Os blocos Ethereum seriam mais pequenos do que atualmente, qualquer pessoa poderia executar um nó de verificação completa no seu computador portátil ou mesmo no seu telemóvel ou dentro de uma extensão de browser, e tudo isto aconteceria preservando os benefícios da filosofia multi-cliente do Ethereum.

Num futuro a longo prazo, é claro que tudo pode acontecer. Talvez a IA venha a sobrecarregar a verificação formal ao ponto de poder provar facilmente que as implementações ZK-EVM são equivalentes e identificar todos os erros que causam diferenças entre elas. Esse projeto pode até ser algo prático para começar a trabalhar agora. Se essa abordagem baseada na verificação formal for bem sucedida, será necessário criar mecanismos diferentes para garantir a descentralização política contínua do protocolo; talvez nessa altura o protocolo seja considerado "completo" e as normas de imutabilidade sejam mais fortes. Mas mesmo que esse seja o futuro a longo prazo, o mundo ZK-EVM multicliente aberto parece ser um passo natural que provavelmente acontecerá de qualquer forma.

A curto prazo, trata-se ainda de uma longa viagem. Os ZK-EVMs estão aqui, mas para que os ZK-EVMs se tornem verdadeiramente viáveis no nível 1, é necessário que se tornem do tipo 1 e que a comprovação seja suficientemente rápida para que possa ocorrer em tempo real. Com uma paralelização suficiente, isso é possível, mas ainda vai dar muito trabalho para chegar lá. As alterações de consenso, como o aumento do custo do gás do KECCAK, do SHA256 e de outras funções de hash pré-compiladas, também serão uma parte importante do cenário. Dito isto, os primeiros passos da transição podem acontecer mais cedo do que esperamos: assim que mudarmos para árvores Verkle e clientes sem estado, os clientes podem começar gradualmente a usar ZK-EVMs, e uma transição para um mundo "aberto multi-ZK-EVM" pode começar a acontecer por si só.

Declaração de exoneração de responsabilidade：

1. Este artigo foi reimpresso de[vitalik], Todos os direitos de autor pertencem ao autor original[vitalik]. Se houver objecções a esta reimpressão, contacte a equipa da Gate Learn, que tratará prontamente do assunto.
2. Declaração de exoneração de responsabilidade: Os pontos de vista e opiniões expressos neste artigo são da exclusiva responsabilidade do autor e não constituem um conselho de investimento.
3. As traduções do artigo para outras línguas são efectuadas pela equipa Gate Learn. A menos que seja mencionado, é proibido copiar, distribuir ou plagiar os artigos traduzidos.