Análise de pesquisa original da Web3.com Ventures

0xPeixe-ilósofo

Introdução

“zk-Rollups” provavelmente tem sido a palavra da moda mais quente da Web 3 do ano. Com o lançamento da mainnet “baby alpha” do zk-Sync v2.0 nos últimos dias, essa empolgação atingiu seu ápice [1]. Mas por trás de todas essas palavras da moda, a que “zk-Rollups” realmente se refere? E onde o zk-Sync entra em cena? Neste artigo, tentarei me aprofundar nos princípios e práticas do zk-Rollups, explicitar as principais características técnicas do zk-Sync v2.0 como um projeto e explorar as potenciais implicações futuras para essa tecnologia tão esperada.

Princípios do zk-Rollups

Por que precisamos de zk-Rollups em primeiro lugar? Claro, Ethereum é ótimo. Mas em seu estado atual, a rede é fundamentalmente uma deseconomia de escala. À medida que a atividade da rede aumenta, os preços do gás se tornam proibitivamente caros, principalmente se houver um aumento repentino da atividade da rede de uma só vez. À medida que o Ethereum ganha popularidade em uso e tração nos últimos anos, sua atual escalabilidade limitada se tornou o calcanhar de Aquiles da rede.

É aqui que entram os “rollups” — os rollups do Ethereum são essencialmente um “plugin” que fornece ao Ethereum magnitudes extras de escalabilidade e, portanto, corrige sua deseconomia de escala inerente. A intuição por trás da ideia é simples. Imagine que você tem 5 itens que precisa carregar do ponto A ao ponto B. A maneira “normal” de fazer isso seria carregar o Item 1, carregar o Item 2, etc., um após o outro. Mas isso é obviamente lento e trabalhoso. Um “rollup” é essencialmente “rolar” todos os 5 itens em uma única bolsa, permitindo que você faça uma única viagem em vez de 5.

Mas há duas ressalvas:

  1. Como podemos ter certeza de que o rollup pode “encaixar” tudo?

  2. Como podemos garantir que o rollup não seja falsificado?

zk-Rollups são um dos principais tipos de tecnologias de rollup (o outro é o Optimistic Rollups) alavancando “provas de conhecimento zero” para resolver esses dois problemas. Para resolver esses problemas, um zk-Rollup agrupará um certo número de transações, fará a computação na L2 e enviará as mudanças de estado e uma “prova de validade” para um verificador na L1 mostrando que as computações foram feitas com integridade. Essa “prova de validade” ocorre na forma de uma “Prova de Conhecimento Zero”, uma maneira matemática de dizer a alguém que você sabe algo sem dizer a ele o que você sabe.

Um exemplo simples de uma Prova de Conhecimento Zero é um autoclassificador de código (para dever de casa de CS). O autoclassificador é um "verificador" que lhe dá um monte de casos de teste gerados aleatoriamente, e você é um "provador" que deve ser capaz de passar em todos os casos de teste para provar que você tem o código correto. Durante todo esse tempo, você não compartilha seu código com o autoclassificador diretamente. E voilà, você acabou de conduzir uma "Prova de Conhecimento Zero", provando que você sabe algo sem dizer o que você sabe. [2]

O autoclassificador de código acima usa uma “Prova de Conhecimento Zero interativa”, onde o autoclassificador e o provedor de código “interagem” diretamente um com o outro. Em contraste, a maioria dos zk-Rollups usa uma prova não interativa matematicamente mais complicada (como um zk-SNARK, ou Zero Knowledge Succinct Noninteractive ARgument of Knowledge), que economiza tempo e espaço em comparação a uma prova interativa. Embora os detalhes técnicos dos zk-SNARKs estejam além do escopo deste artigo, o princípio subjacente da aprovação de casos de teste é o mesmo.

O Santo Graal dos zk-Rollups é uma Máquina Virtual Ethereum de Conhecimento Zero (zk-EVM) que permite que os desenvolvedores transfiram qualquer contrato inteligente Ethereum sem modificação para uma cadeia zk-Rollup. Mas isso é difícil. Como cada “problema” requer diferentes conjuntos de “casos de teste”, desenvolver um “algoritmo de prova” que pode resolver todos os casos de teste imagináveis ​​é um gargalo técnico das Provas de Conhecimento Zero e zk-Rollups.

Como o próprio Vitalik Buterin afirma:

Em geral, minha opinião é que, no curto prazo, os rollups otimistas provavelmente vencerão na computação EVM de uso geral e os rollups ZK provavelmente vencerão em pagamentos simples, trocas e outros casos de uso específicos de aplicativos, mas, no médio e longo prazo, os rollups ZK vencerão em todos os casos de uso, à medida que a tecnologia ZK-SNARK melhora. [3]

Assim, historicamente, os zk-Rollups foram apenas tecnologias estabelecidas para casos de uso específicos de aplicações, onde os “casos de teste” são bem definidos e limitados em escopo. No entanto, vários projetos estão avançando rapidamente em direção ao “castelo na colina” — um algoritmo zk-Rollup genérico compatível com EVM. [4]

zk-Sync v2.0

O zk-Sync v2.0 é apenas um dos muitos projetos atualmente em andamento no desenvolvimento de um zk-EVM (outros incluem StarkNet, Polygon Hermez e Scroll). Ao contrário do zk-Sync v1.0, que exigia que os usuários reconstruíssem grandes seções de suas bases de código para portar do EVM para o zk-Sync, no zk-Sync v2.0 os programadores podem implementar seus aplicativos com poucas ou nenhuma alteração — ou como o zk-Sync pode gostar de alegar.

Na prática, nem todos os zk-EVMs são criados iguais. Há uma compensação distinta entre componibilidade (quão próximo ele está dos contratos EVM originais) e desempenho (quão rápido os zk-Rollups serão executados) [6]. Dentro dessa compensação, o zk-Sync escolheu otimizar completamente o desempenho, sacrificando assim a componibilidade.

Na perspectiva de Vitalik Buterin, existem quatro tipos distintos de zk-EVMs, resumidos no gráfico a seguir:

Como Vitalik afirma, em seu estado atual, o zk-Sync v2.0 é um zk-EVM Tipo 4, que é capaz de compilar contratos escritos em Solidity e linguagens de alto nível usando seu próprio compilador, que é distinto do EVM. Como o zk-Sync tem controle total sobre o design de seu compilador, eles são capazes de otimizar agressivamente a velocidade e o rendimento. O custo disso é que alguns DApps e cadeias de ferramentas de depuração EVM podem ser incompatíveis com o zk-Sync v2.0. Essencialmente, o zk-Sync é o mesmo car shell do Ethereum, mas com um mecanismo trocado [5].

De fato, em sua documentação de desenvolvedor, a Matter Labs afirma que, embora as operações de “leitura” de contratos inteligentes possam ser integradas sem nenhuma alteração no código, as operações de “gravação” de contratos inteligentes precisam de “código adicional” devido a “diferenças fundamentais entre L1 e L2” [6]. Na verdade, isso é um pouco enganoso. Não é tanto devido a uma “diferença fundamental” entre L1 e L2, mas mais por causa do tipo de zk-Rollup que a Matter Labs decidiu buscar — o rollup Tipo 4. Como o zk-Sync é fundamentalmente um rollup Tipo 4 que usa um compilador e bytecode diferentes, isso significa que os contratos inteligentes têm endereços diferentes, e a infraestrutura do depurador que depende da análise do bytecode pode não funcionar no zk-Sync v2.0 [7].

No futuro, o zk-Sync pode adicionar mais suporte nativo para byte-code EVM, permitindo que o sistema faça uma transição lenta para um rollup Tipo 3 que suporte uma gama mais ampla desses "casos extremos". Mas para que o zk-Rollup Tipo 4 ou Tipo 3 do zk-Sync tenha sucesso em comparação com o rollup Tipo 2 da Polygon Hermez e Scroll Labs, que essencialmente troca velocidade por compatibilidade mais ampla, deve haver duas pré-condições importantes. Primeiro, há apenas uma pequena fração de projetos sem importância que são incompatíveis com o compilador personalizado do zk-Sync. Segundo, há uma diferença qualitativa na velocidade de execução do zk-Sync em comparação com um zk-EVM Tipo 2.

Infelizmente, eu pessoalmente acredito que é improvável que esse seja o caso. Qualquer ecossistema de desenvolvimento avançado depende de uma infraestrutura de “andaime” madura, incluindo ferramentas de depuração e teste convenientes e modularizadas. Se, como Vitalik postula, uma grande parte das ferramentas de depuração nativas de EVM não puderem ser portadas para o zk-Sync devido a diferenças no bytecode, então o zk-Sync terá que desenvolver seu próprio conjunto de ferramentas de teste e depuração. Essa é uma sobrecarga extra que pode, em última análise, dificultar a velocidade de adoção do zk-Sync como uma solução L2, em comparação com seus concorrentes zk-EVM Tipo 2 mais componíveis, como Polygon Hermez e Scroll.

O futuro para zk-Rollups

Com muitos jogadores competitivos na batalha por zk-EVMs, pode-se argumentar que é apenas uma questão de tempo até que vejamos um zk-EVM totalmente funcional. Mas o que vem a seguir? Uma estrada só é útil enquanto houver prédios na estrada; a força de longo prazo de um zk-Rollup vem dos projetos que usam essa solução.

No momento, DeFi, GameFi e aplicativos móveis são os principais beneficiários da infraestrutura zk-Rollup. Tanto DeFi quanto GameFi são fundamentalmente economias de escala, pois prosperam em um ambiente onde há muitas pessoas os usando. Aplicativos móveis, como carteiras móveis, também abrem as comportas para o consumidor em massa que é muito preguiçoso (ou não pode pagar) por um PC de mesa. Usar zk-Rollups para essas situações, portanto, faz muito sentido.

Mas isso não é de forma alguma o limite da utilidade dos zk-Rollups. Se alguma coisa, isso é apenas o começo. Os zk-Rollups são para o Ethereum o que o 5G é para a Internet. Assim como o 5G pode habilitar um novo mundo de aplicativos e sistemas de IoT, os zk-Rollups também podem abrir as comportas para uma “Blockchain das Coisas”, permitindo que os aparelhos digitais do nosso mundo físico — geladeiras, relógios, semáforos e tudo — sejam integrados com contratos inteligentes protegidos no Ethereum.

Um dos maiores argumentos contra a IoT é que ela permitirá que a Big Tech invada nossa vida cotidiana. Mas com um “Blockchain of Things”, podemos aproveitar as conveniências da IoT sem nos preocupar com nossos aparelhos inteligentes sendo comprometidos em um banco de dados centralizado. Em vez de conveniência OU privacidade, podemos ter conveniência E privacidade. Esse é o mundo que o zk-Rollups pode nos prometer.

🐦 @0xfishylosopher

📅 31 de outubro de 2022

Estas informações são puramente educacionais e não devem ser tomadas como aconselhamento financeiro. Todas as opiniões expressas são do autor e não são necessariamente endossadas pela Web3.com Ventures.

Referências

[1] https://blog.matter-labs.io/baby-alpha-has-arrived-5b10798bc623

[2] Adaptado de https://pages.cs.wisc.edu/~mkowalcz/628.pdf

[3] https://vitalik.ca/general/2021/01/05/rollup.html

[4] https://www.coindesk.com/tech/2022/07/20/the-sudden-rise-of-evm-compatível-zk-rollups/

[5] https://cryptobriefing.com/the-race-scale-ethereum-zkevm-rollups/

[6] https://docs.zksync.io/dev/contracts/#porting-smart-contracts

[7] https://vitalik.ca/general/2022/08/04/zkevm.html