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

Cada nó da Ethereum executa um cliente de consenso e um cliente de execução. Até o momento, nenhum cliente de consenso ou execução representa mais de 2/3 da rede. Se um cliente com menos de 1/3 de participação em sua categoria tiver um bug, a rede simplesmente continuará normalmente. Se um cliente com participação entre 1/3 e 2/3 em sua categoria (portanto, Prysm, Lighthouse ou Geth) tiver um bug, a cadeia continuará adicionando blocos, mas interromperá a finalização dos blocos, dando tempo para que os desenvolvedores intervenham.

Uma transição importante que está por vir, pouco discutida, mas muito importante, na forma como a cadeia Ethereum é validada é o surgimento das ZK-EVMs. Os SNARKs que comprovam a execução do EVM já estão sendo desenvolvidos há anos, e a tecnologia está sendo usada ativamente por protocolos de camada 2 chamados ZK rollups. Alguns desses rollups de ZK estão ativos na rede principal hoje, e outros serão lançados em breve. Mas, em 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 se tornarão de fato um terceiro tipo de cliente Ethereum, tão importante para a segurança da rede quanto os clientes de execução e os clientes de consenso são hoje. E isso naturalmente levanta uma questão: como os ZK-EVMs vão interagir com a filosofia multicliente? Uma das partes mais difíceis já foi feita: já temos várias implementações de ZK-EVM que estão sendo ativamente desenvolvidas. Mas outras partes difíceis permanecem: como realmente criaríamos um ecossistema "multicliente" para a correção da prova ZK dos blocos Ethereum? Essa pergunta abre alguns desafios técnicos interessantes e, é claro, a questão iminente de saber se as compensações valem a pena ou não.

Qual foi a motivação original para a filosofia multicliente da Ethereum?

A filosofia multicliente da Ethereum é um tipo de descentralização e, assim como <a href="https://medium.com/@VitalikButerin/the-meaning-of-decentralization-a0c92b76a274"> descentralização em geral, é possível se concentrar nos benefícios técnicos da descentralização arquitetônica ou nos benefícios sociais da descentralização política. Em última análise, a filosofia multicliente foi motivada por ambos e atende a ambos.

Argumentos para a descentralização técnica

O principal benefício da descentralização técnica é simples: ela reduz o risco de que um bug em um software leve a um colapso catastrófico de toda a rede. Uma situação histórica que exemplifica esse risco é o bug de estouro de Bitcoin de 2010. Na época, o código do cliente Bitcoin não verificava se a soma dos resultados de uma transação não transbordava (chegava a zero ao somar acima do número inteiro máximo de^264-1) e, portanto, alguém fez uma transação que fez exatamente isso, dando a si mesmo bilhões de bitcoins. O bug foi descoberto em poucas horas, e uma correção foi feita às pressas e rapidamente implantada em toda a rede, mas se houvesse um ecossistema maduro na época, essas moedas teriam sido aceitas por bolsas, pontes e outras estruturas, e os invasores poderiam ter fugido com muito dinheiro. Se houvesse cinco clientes de Bitcoin diferentes, seria muito improvável que todos eles tivessem o mesmo bug e, portanto, teria havido uma divisão imediata, e o lado da divisão que tinha o bug provavelmente teria perdido.

Há uma desvantagem em usar a abordagem multicliente para minimizar o risco de bugs catastróficos: em vez disso, o senhor obtém bugs de falha de consenso. Ou seja, se o senhor tiver dois clientes, há o risco de que eles tenham interpretações sutilmente diferentes de alguma regra de protocolo e, embora ambas as interpretações sejam razoáveis e não permitam o roubo de dinheiro, a discordância faria com que a cadeia se dividisse ao meio. Uma divisão séria desse tipo aconteceu uma vez na história da Ethereum (houve outras divisões muito menores 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 um motivo para não ter várias implementações: se houver apenas um cliente, esse cliente não discordará de si mesmo. Seu modelo de como o número de clientes se traduz em risco pode ser mais ou menos assim:

Eu, obviamente, discordo dessa análise. O ponto crucial da minha discordância é que (i) os bugs catastróficos do estilo de 2010 também são importantes e (ii) o senhor nunca tem apenas um cliente. O último ponto ficou mais óbvio com a bifurcação do Bitcoin de 2013: uma divisão da cadeia ocorreu devido a uma discordância entre duas versões diferentes do cliente Bitcoin, uma das quais acabou tendo um limite acidental e não documentado sobre o número de objetos que poderiam ser modificados em um único bloco. Portanto, um cliente em teoria costuma ser dois clientes na prática, e cinco clientes em teoria podem ser seis ou sete clientes na prática - portanto, devemos nos arriscar e ir para o lado direito da curva de risco e ter pelo menos alguns clientes diferentes.

Argumentos para a descentralização política

Os desenvolvedores de clientes monopolistas estão em uma posição com muito poder político. Se um desenvolvedor de cliente propuser uma alteração e os usuários discordarem, teoricamente eles poderiam se recusar a fazer o download da versão atualizada ou criar uma bifurcação sem ela, mas, na prática, muitas vezes é difícil para os usuários fazerem isso. E se uma alteração desagradável no protocolo for acompanhada de uma atualização de segurança necessária? E se a equipe principal ameaçar desistir se não conseguir o que quer? Ou, de forma mais branda, e se a equipe monopolista do cliente acabar sendo o único grupo com o maior conhecimento de protocolo, deixando o restante do ecossistema em uma posição ruim para julgar os argumentos técnicos que a equipe do cliente apresenta, deixando a equipe do cliente com muito espaço para promover seus próprios objetivos e valores particulares, que podem não corresponder à comunidade mais ampla?

A preocupação com a política de protocolo, especialmente no contexto das guerras do Bitcoin OP_RETURN de 2013-14, em que alguns participantes eram abertamente a favor da discriminação contra determinados usos da cadeia, foi um fator que contribuiu significativamente para a adoção inicial da filosofia multicliente da Ethereum, que tinha como objetivo dificultar que um pequeno grupo tomasse esse tipo de decisão. Preocupações específicas do ecossistema Ethereum - ou seja, evitar a concentração de poder dentro da própria Fundação Ethereum - deram mais apoio a essa direção. Em 2018, foi tomada a decisão de fazer com que a Fundação não implementasse intencionalmente o protocolo Ethereum PoS (ou seja, o protocolo PoS da Ethereum). o que hoje é chamado de "cliente de consenso"), deixando essa tarefa inteiramente para equipes externas.

Como os ZK-EVMs entrarão na camada 1 no futuro?

Atualmente, os ZK-EVMs são usados em rollups. Isso aumenta o dimensionamento ao permitir que a execução cara do EVM ocorra apenas algumas vezes fora da cadeia, com todos os outros simplesmente verificando os SNARKs postados na cadeia que provam que a execução do EVM foi computada corretamente. Ele também permite que alguns dados (especialmente assinaturas) não sejam incluídos na cadeia, economizando nos custos de gás. Isso nos dá muitos benefícios 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 nos permitir escalar muito longe.

No entanto, a rede Ethereum hoje 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, a ponto de poucos usuários executarem seu próprio nó. Em vez disso, a maioria dos usuários simplesmente confia em provedores de terceiros. Os clientes light, como o Helios e o Succinct, estão tomando medidas para 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 de comitê de sincronização e não verifica se a cadeia realmente segue as regras do protocolo. Para chegarmos a um mundo em que os usuários possam realmente verificar se a cadeia segue as regras, teríamos que fazer algo diferente.

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

Com o tempo, poderíamos reduzir a meta de gás por bloco da camada 1 de 15 milhões para 1 milhão, o suficiente para que um bloco contenha um único SNARK e algumas operações de depósito e saque, mas não muito mais, e assim forçar quase toda a atividade do usuário a migrar para os protocolos da camada 2. Esse 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. Em um mundo assim, a única função da camada 1 seria ser uma câmara de compensação para os protocolos da camada 2, verificando suas provas e, ocasionalmente, facilitando grandes transferências de fundos entre eles.

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

• É de fato incompatível com as versões anteriores, no sentido de que muitos aplicativos existentes baseados em L1 tornam-se economicamente inviáveis. Fundos de usuários de até centenas ou milhares de dólares podem ficar presos, pois as taxas se tornam tão altas que excedem o custo de esvaziar essas contas. Isso poderia ser resolvido permitindo que os usuários assinassem mensagens para optar por uma migração em massa dentro do protocolo para uma L2 de sua escolha (veja algumas ideias iniciais de implementação aqui), mas isso aumenta a complexidade da transição e, para torná-la realmente barata o suficiente, seria necessário algum tipo de SNARK na camada 1. Em geral, sou adepto da quebra de compatibilidade com versões anteriores quando se trata de <a href="https://hackmd.io/@vbuterin/selfdestruct"> coisas como o opcode SELFDESTRUCT, mas, nesse caso, a troca parece muito menos favorável.
• Isso ainda pode não tornar a verificação barata o suficiente. O ideal é que o protocolo Ethereum seja fácil de verificar não apenas em laptops, mas também em telefones, extensões de navegador e até mesmo em outras cadeias. Sincronizar a cadeia pela primeira vez, ou depois de um longo tempo off-line, também deve ser fácil. Um nó de laptop poderia verificar 1 milhão de gás em ~20 ms, mas mesmo isso implica 54 segundos para sincronizar após um dia off-line (supondo que <a href="https://notes.ethereum.org/@vbuterin/single_slot_finality"> single slot finality aumenta o tempo dos slots para 32s) e, para telefones ou extensões de navegador, isso levaria algumas centenas de milissegundos por bloco e ainda poderia ser um consumo de bateria não desprezível. Esses números são gerenciáveis, mas não são ideais.
• Mesmo em um ecossistema que prioriza a L2, há vantagens em que a L1 seja pelo menos um pouco acessível. Os validiums podem se beneficiar de um modelo de segurança mais forte se os usuários puderem retirar seus fundos se perceberem que novos dados estaduais não estão mais sendo disponibilizados. A arbitragem se torna mais eficiente, especialmente para tokens menores, se o tamanho mínimo de uma transferência direta cross-L2 economicamente viável for menor.

Por isso, parece mais razoável tentar encontrar uma maneira de usar ZK-SNARKs para verificar a própria camada 1.

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

Um ZK-EVM tipo 1 (totalmente equivalente ao Ethereum) pode ser usado para verificar a execução do 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. Esse seria um problema de engenharia desafiador: atualmente, os ZK-EVMs levam de minutos a horas para verificar os blocos do Ethereum, e a geração de provas em tempo real exigiria um ou mais dos seguintes itens: (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 arquitetônicas com muito mais paralelização. No entanto, não há nenhuma razão tecnológica fundamental para que isso não possa ser feito e, portanto, espero que, mesmo que leve muitos anos, isso seja feito.

É aqui que vemos a interseção com o paradigma multicliente: se usarmos ZK-EVMs para verificar a camada 1, qual ZK-EVM usaremos?

Vejo três opções:

1. ZK-EVM único: abandonar o paradigma de vários clientes e escolher um único ZK-EVM que usamos para verificar os blocos.
2. Múltiplas ZK-EVM fechadas: concordar e consagrar em consenso um conjunto específico de múltiplas ZK-EVMs e ter uma regra de protocolo de camada de consenso segundo a qual um bloco precisa de provas de mais da metade das ZK-EVMs desse conjunto para ser considerado válido.
3. Open multi ZK-EVM: diferentes clientes têm diferentes implementações de ZK-EVM, e cada cliente aguarda uma prova que seja compatível com sua própria implementação antes de aceitar um bloco como válido.

Para mim, (3) parece ideal, pelo menos até e a menos que nossa tecnologia melhore a ponto de podermos provar formalmente que todas as implementações do ZK-EVM são equivalentes umas às outras, quando então poderemos escolher a que for mais eficiente. (1) sacrificaria os benefícios do paradigma multicliente 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 por enquanto.

Implementar (3) não seria muito difícil: pode-se ter uma sub-rede p2p para cada tipo de prova, e um cliente que usa um tipo de prova ouviria a sub-rede correspondente e esperaria até receber uma prova que seu verificador reconhecesse como válida.

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

• O desafio da latência: um invasor mal-intencionado poderia publicar um bloco com atraso, juntamente com uma prova válida para um cliente. Na realidade, levaria muito tempo (mesmo que, por exemplo, 15 segundos) para gerar provas válidas para outros clientes. Esse tempo seria longo o suficiente para criar uma bifurcação temporária e interromper a cadeia por alguns slots.
• Ineficiência de dados: um benefício dos ZK-SNARKs é que os dados que são relevantes apenas para a verificação (às vezes chamados de "dados de testemunha") podem ser removidos de um bloco. Por exemplo, depois de verificar uma assinatura, o senhor não precisa manter a assinatura em um bloco, basta armazenar um único bit dizendo que a assinatura é válida, juntamente com uma única prova no bloco confirmando 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 precisarão ser realmente publicadas.

O desafio da latência pode ser resolvido com cuidado ao projetar o protocolo de finalidade de slot único. Os protocolos de finalidade de slot único provavelmente exigirão mais de duas rodadas de consenso por slot e, portanto, pode-se exigir que a primeira rodada inclua o bloco e que os nós verifiquem as provas antes de assinar na terceira (ou última) rodada. Isso garante que uma janela de tempo significativa esteja sempre disponível entre o prazo para a publicação de um bloco e o momento em que se espera que as provas estejam disponíveis.

A questão da eficiência dos dados teria que ser resolvida por meio de um protocolo separado para agregar dados relacionados à verificação. Para assinaturas, poderíamos usar a agregação BLS, que o ERC-4337 já suporta. Outra categoria importante de dados relacionados à verificação são os ZK-SNARKs usados para privacidade. Felizmente, eles geralmente tendem a ter seus próprios protocolos de agregação.

Também vale a pena mencionar que a verificação da camada 1 pelo SNARK tem um benefício importante: o fato de que a execução do EVM na cadeia não precisa mais ser verificada por cada nó possibilita um grande aumento na quantidade de execução do EVM. Isso poderia acontecer aumentando muito o limite de gás da camada 1 ou introduzindo rollups consagrados, ou ambos.

Conclusões

Para que um ecossistema ZK-EVM multicliente aberto funcione bem, será necessário muito trabalho. Mas a notícia realmente boa é que grande parte desse trabalho está acontecendo ou acontecerá de qualquer forma:

• Já temos várias implementações fortes de ZK-EVM. Essas implementações ainda não são do tipo 1 (totalmente equivalentes ao Ethereum), mas muitas delas estão se movendo ativamente nessa direção.
• O trabalho em clientes leves, como Helios e Succinct, pode eventualmente se transformar em uma verificação SNARK mais completa do lado do consenso PoS da cadeia Ethereum.
• Os clientes provavelmente começarão a fazer experiências com 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. Provavelmente, teremos uma transição lenta e gradual dos clientes que verificam os blocos de Ethereum reexecutando-os para a maioria dos clientes que verificam os blocos de 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, em breve, para economizar nos custos de gás. No que diz respeito à agregação do BLS, o trabalho já começou.

Com essas tecnologias implementadas, o futuro parece muito bom. Os blocos do Ethereum seriam menores do que os atuais, qualquer pessoa poderia executar um nó de verificação completa em seu laptop ou até mesmo em seu telefone ou dentro de uma extensão de navegador, e tudo isso aconteceria preservando os benefícios da filosofia multicliente do Ethereum.

Em um futuro de longo prazo, é claro que tudo pode acontecer. Talvez a IA venha a sobrecarregar a verificação formal até o ponto em que possa 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 se começar a trabalhar agora. Se essa abordagem baseada em verificação formal for bem-sucedida, diferentes mecanismos precisarão ser implementados para garantir a descentralização política contínua do protocolo; talvez nesse ponto 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 aberto do ZK-EVM multicliente parece ser um passo natural que provavelmente acontecerá de qualquer maneira.

Em um prazo mais próximo, essa ainda é uma longa jornada. Os ZK-EVMs estão aqui, mas para que os ZK-EVMs se tornem realmente viáveis na camada 1, seria necessário que eles se tornassem do tipo 1 e que a comprovação fosse rápida o suficiente para que isso acontecesse em tempo real. Com paralelização suficiente, isso é possível, mas ainda será muito trabalhoso chegar lá. Mudanças no consenso, como o aumento do custo do gás do KECCAK, do SHA256 e de outros pré-compilados de funções hash, também serão uma parte importante do cenário. Dito isso, as primeiras etapas da transição podem acontecer mais cedo do que esperamos: assim que mudarmos para árvores Verkle e clientes sem estado, os clientes poderão começar a usar gradualmente os ZK-EVMs, e a transição para um mundo "multi-ZK-EVM aberto" poderá começar a acontecer por conta própria.

Isenção de responsabilidade：

1. Este artigo foi reimpresso de[vitalik], Todos os direitos autorais pertencem ao autor original[vitalik]. Se houver alguma objeção a essa reimpressão, entre em contato com a equipe do Gate Learn, que tratará do assunto imediatamente.
2. Isenção de responsabilidade: Os pontos de vista e opiniões expressos neste artigo são de responsabilidade exclusiva do autor e não constituem consultoria de investimento.
3. As traduções do artigo para outros idiomas são feitas pela equipe do Gate Learn. A menos que mencionado, é proibido copiar, distribuir ou plagiar os artigos traduzidos.