de Anúncios
O co-fundador da Ethereum, Vitalik Buterin, compartilhou sua reflexão sobre um aspecto “pouco discutido, mas ainda assim muito importante” do ecossistema Ethereum em uma recente postagem no blog neste fim de semana.
O post intitulado “Como a filosofia multicliente da Ethereum irá interagir com os ZK-EVMs?” focado nos desafios técnicos, trade-offs e soluções potenciais para criar um ecossistema multicliente para ZK-EVMs.
O problema multicliente com Zk-EVMs
Vitalik acredita que os ZK-EVMs evoluirão para se tornar uma parte essencial do processo de segurança e verificação da camada 1 da Ethereum no futuro. A tecnologia Zero Knowledge (ZK) permite que os desenvolvedores comprovem a autenticidade de uma transação ou mensagem sem revelar nenhuma informação adicional. Assim, permite que uma parte convença a outra de que uma mensagem é verdadeira sem revelar nenhum conhecimento além da validade da mensagem.
No entanto, a natureza de aplicação da privacidade da tecnologia ZK pode atrapalhar o cenário EVM mais amplo, já que os clientes Ethereum diferem sutilmente na implementação de regras de protocolo, de acordo com o co-fundador da Ethereum.
Os protocolos da camada 2 em rollups ZK usaram com sucesso as provas ZK e ajudaram a dimensionar o Ethereum agrupando várias transações em uma única prova. No entanto, à medida que os ZK-EVMs evoluem para verificar a execução na Mainnet, “os ZK-EVMs de fato se tornam 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”.
Ver ZK-EVMs como um terceiro tipo de cliente Ethereum levanta a seguinte questão de Vitalik,
“Como nós realmente criaríamos um ecossistema “multicliente” para provar a exatidão dos blocos Ethereum do ZK?”
À medida que o ecossistema cresce, Vitalik deseja manter os benefícios da “filosofia multicliente” e, ao mesmo tempo, aproveitar os recursos dos ZK-EVMs para melhorar a escalabilidade, segurança e descentralização da rede Ethereum.
Os principais desafios técnicos do uso da tecnologia ZK com vários clientes estão relacionados à latência e ineficiência de dados, de acordo com Vitalik. Além disso, clientes Ethereum individuais lidam com provas de conhecimento zero de maneira diferente devido a interpretações específicas de regras de protocolo ou implementações ZK-EVM.
Soluções multicliente ZK-EVM
Apesar desses desafios, Vitalik acredita que criar um ecossistema ZK-EVM multicliente aberto é viável e benéfico para a segurança e a descentralização da Ethereum.
Abaixo está uma representação visual dos vários clientes usados nas camadas de consenso e execução do ecossistema Ethereum.
Vitalik argumentou que ter vários clientes aumenta a segurança e a descentralização da rede, reduzindo o risco de um único bug catastrófico em uma implementação, o que poderia levar ao colapso de toda a rede. Além disso, uma filosofia multicliente ajuda a evitar a concentração de poder dentro de uma equipe de desenvolvimento ou organização, promovendo a descentralização política.
Vitalik apresentou três possíveis soluções para o problema, conforme mostrado abaixo.
- “Single ZK-EVM: abandone o paradigma multicliente e escolha um único ZK-EVM que usamos para verificar blocos.
- Multi ZK-EVM fechado: concordar e consagrar em consenso um conjunto específico de múltiplos ZK-EVMs e ter uma regra de protocolo de camada de consenso de que um bloco precisa de provas de mais da metade dos ZK-EVMs naquele conjunto para ser considerado válido .
- Open multi ZK-EVM: diferentes clientes têm diferentes implementações de ZK-EVM, e cada cliente espera por uma prova compatível com sua própria implementação antes de aceitar um bloco como válido.”
No contexto dos ZK-EVMs, Vitalik apóia a ideia de um ecossistema ZK-EVM multicliente aberto. Diferentes clientes têm diferentes implementações de ZK-EVM, e cada cliente espera por uma prova compatível com a sua 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…”
No entanto, uma vez que a tecnologia melhorou a ponto de as implementações ZK-EVM serem um tanto padronizadas, Vitalik argumentou que a solução será escolher a opção mais eficiente. Ele acredita que os “desafios [for option 3] parecem menores que os desafios das outras duas opções, pelo menos por enquanto.”
Vitalik também acenou com a cabeça para o recente avanço rápido na IA, afirmando que o progresso na IA poderia “sobrecarregar” o desenvolvimento de implementações ZK-EVM de comprovação.
“No futuro a longo prazo, é claro que tudo pode acontecer. Talvez a IA sobrecarregue a verificação formal a ponto de provar facilmente a equivalência das implementações do ZK-EVM e identificar todos os bugs que causam diferenças entre eles.”
