Rollups estão na moda

Rollups estão na moda na comunidade Ethereum e estão prestes a ser a principal solução de escalabilidade para Ethereum no futuro previsível.

Mas o que exatamente é essa tecnologia, o que você pode esperar dela e como poderá usá-la? Este post tentará responder a algumas dessas perguntas-chave.

Histórico: O que é o dimensionamento da camada 1 e da camada 2?

Existem duas maneiras de dimensionar um ecossistema blockchain. Primeiro, você pode fazer com que o próprio blockchain tenha uma capacidade de transação maior .

O principal desafio dessa técnica é que blockchains com "blocos maiores" são inerentemente mais difíceis de verificar e provavelmente se tornarão mais centralizados.

Para evitar tais riscos, os desenvolvedores podem aumentar a eficiência do software cliente ou, de forma mais sustentável, usar técnicas como sharding para permitir que o trabalho de construção e verificação da cadeia seja dividido em vários nós; o esforço conhecido como "eth2" está atualmente construindo esta atualização para Ethereum.

Em segundo lugar, você pode alterar a maneira como usa o blockchain . Em vez de colocar todas as atividades diretamente na blockchain, os usuários realizam a maior parte de suas atividades fora da cadeia em um protocolo de "camada 2".

Existe um contrato inteligente on-chain, que tem apenas duas tarefas: processar depósitos e saques e verificar provas de que tudo o que acontece fora da cadeia está seguindo as regras.

Existem várias maneiras de fazer essas provas, mas todas compartilham a propriedade de que verificar as provas na cadeia é muito mais barato do que fazer o cálculo original fora da cadeia.

Canais Estaduais vs Plasma vs Rollups

Os três principais tipos de dimensionamento da camada 2 são canais de estado , plasma e rollups.

Eles são três paradigmas diferentes, com diferentes pontos fortes e fracos e, neste ponto, estamos bastante confiantes de que todo dimensionamento da camada 2 se enquadra aproximadamente nessas três categorias (embora existam controvérsias de nomenclatura nas bordas, por exemplo, consulte "validium" ).

Como funcionam os canais?

Veja também: https://www.jeffcoleman.ca/state-channels e statechannels.org

Imagine que Alice está oferecendo uma conexão de internet para Bob, em troca de Bob pagar a ela $ 0,001 por megabyte. Em vez de fazer uma transação para cada pagamento, Alice e Bob usam o seguinte esquema de camada 2.

Primeiro, Bob coloca $ 1 (ou algum equivalente em ETH ou stablecoin) em um contrato inteligente. Para fazer seu primeiro pagamento a Alice, Bob assina um "bilhete" (uma mensagem off-chain), que simplesmente diz "$ 0,001" e o envia para Alice.

Para fazer seu segundo pagamento, Bob assinaria outro bilhete que diz "$ 0,002" e o enviaria para Alice. E assim sucessivamente para quantos pagamentos forem necessários. Quando Alice e Bob terminam a transação, Alice pode publicar o tíquete de maior valor para a cadeia, embrulhado em outra assinatura dela mesma.

O contrato inteligente verifica as assinaturas de Alice e Bob, paga a Alice o valor do bilhete de Bob e devolve o restante a Bob.

Se Alice não quiser fechar o canal (por dolo ou falha técnica), Bob pode iniciar um período de desistência (por exemplo, 7 dias); se Alice não fornecer um ingresso dentro desse prazo, Bob receberá todo o seu dinheiro de volta.

Essa técnica é poderosa: pode ser ajustada para lidar com pagamentos bidirecionais, relacionamentos de contratos inteligentes (por exemplo, Alice e Bob fazendo um contrato financeiro dentro do canal) e composição (se Alice e Bob tiverem um canal aberto e Bob e Charlie também, Alice pode interagir sem confiança com Charlie).

Mas há limites para o que os canais podem fazer.

Os canais não podem ser usados para enviar fundos fora da cadeia para pessoas que ainda não são participantes. Os canais não podem ser usados para representar objetos que não tenham um proprietário lógico claro (por exemplo, Uniswap).

E os canais, especialmente se usados para fazer coisas mais complexas do que simples pagamentos recorrentes, exigem que uma grande quantidade de capital seja bloqueada.

Como funciona o plasma?

Veja também: o papel Plasma original e o Plasma Cash .

Para depositar um ativo, um usuário o envia para o contrato inteligente que gerencia a cadeia Plasma. A cadeia Plasma atribui a esse ativo um novo ID exclusivo (por exemplo, 537).

Cada cadeia Plasma tem um operador (pode ser um ator centralizado, um multisig ou algo mais complexo como PoS ou DPoS). A cada intervalo (pode ser de 15 segundos, ou uma hora, ou qualquer coisa intermediária), o operador gera um "lote" que consiste em todas as transações do Plasma recebidas fora da cadeia.

Eles geram uma árvore Merkle, onde em cada índice X na árvore, há uma transação que transfere o ID do ativo X se tal transação existir, caso contrário, essa folha é zero. Eles publicam a raiz Merkle desta árvore para encadear.

Eles também enviam a ramificação Merkle de cada índice X para o proprietário atual desse ativo. Para retirar um ativo, um usuário publica a ramificação Merkle da transação mais recente que envia o ativo para ele.

O contrato inicia um período de contestação, durante o qual qualquer pessoa pode tentar usar outras filiais da Merkle para invalidar a saída, provando que (i) o remetente não era o proprietário do ativo no momento em que o enviou ou (ii) enviou o ativo para outra pessoa em algum momento posterior.

Se ninguém provar que a saída é fraudulenta por (ex.) 7 dias, o usuário pode retirar o ativo.

O plasma oferece propriedades mais fortes do que os canais: você pode enviar ativos para participantes que nunca fizeram parte do sistema e os requisitos de capital são muito menores.

Mas isso tem um custo: os canais não requerem nenhum dado para entrar na cadeia durante a "operação normal", mas o Plasma exige que cada cadeia publique um hash em intervalos regulares.

Além disso, as transferências do Plasma não são instantâneas: é preciso aguardar o término do intervalo e a publicação do bloco.

Além disso, o Plasma e os canais compartilham uma fraqueza fundamental em comum: a teoria do jogo por trás de por que eles são seguros se baseia na ideia de que cada objeto controlado por ambos os sistemas tem algum "proprietário" lógico.

Se esse proprietário não se importa com seu ativo, pode ocorrer um resultado "inválido" envolvendo esse ativo. Isso é bom para muitos aplicativos, mas é um obstáculo para muitos outros (por exemplo, Uniswap).

Mesmo os sistemas em que o estado de um objeto pode ser alterado sem o consentimento do proprietário (por exemplo, sistemas baseados em contas, nos quais você pode aumentar o saldo de alguém sem o consentimento deles) não funcionam bem com o Plasma.

Isso tudo significa que uma grande quantidade de "raciocínio específico da aplicação" é necessária em qualquer implantação realista de plasma ou canais, e não é possível fazer um sistema de plasma ou canal que simule apenas o ambiente ethereum completo (ou "o EVM") . Para contornar esse problema, chegamos a ... rollups.

Rollups

Veja também: EthHub em rollups otimistas e rollups ZK .

Plasma e canais são esquemas "completos" da camada 2, pois tentam mover os dados e a computação para fora da cadeia.

No entanto, questões fundamentais da teoria dos jogos em torno da disponibilidade de dados significam que é impossível fazer isso com segurança para todos os aplicativos. O plasma e os canais contornam isso confiando em uma noção explícita de proprietários, mas isso os impede de serem totalmente gerais.

Os rollups, por outro lado, são um esquema de camada 2 "híbrido".

Os rollups movem a computação (e o armazenamento de estado) para fora da cadeia, mas mantêm alguns dados por transação na cadeia .

Para melhorar a eficiência, eles usam uma série de truques sofisticados de compactação para substituir dados por computação sempre que possível.

O resultado é um sistema em que a escalabilidade ainda é limitada pela largura de banda de dados do blockchain subjacente, mas em uma proporção muito favorável: enquanto uma transferência de token ERC20 da camada de base Ethereum custa ~ 45.000 gás, uma transferência de token ERC20 em um rollup leva 16 bytes de espaço na cadeia e custa menos de 300 gás.

O fato de os dados estarem on-chain é fundamental (observação: colocar os dados "no IPFS" não funciona, porque o IPFS não fornece consenso sobre se um determinado dado está ou não disponível; os dados devem ir para um blockchain).

Colocar dados na cadeia e ter consenso sobre esse fato permite que qualquer pessoa processe localmente todas as operações no rollup, se desejar, permitindo detectar fraudes, iniciar retiradas ou iniciar pessoalmente a produção de lotes de transações.

A falta de problemas de disponibilidade de dados significa que um operador mal-intencionado ou offline pode causar ainda menos danos (por exemplo, eles não podem causar um atraso de 1 semana), abrindo um espaço de design muito maior para quem tem o direito de publicar lotes e tornando os rollups muito mais fáceis raciocinar sobre.

E o mais importante, a falta de problemas de disponibilidade de dados significa que não há mais necessidade de mapear ativos para proprietários, levando à principal razão pela qual a comunidade Ethereum está muito mais entusiasmada com rollups do que com as formas anteriores de escalonamento da camada 2: rollups são totalmente de uso geral, e pode-se até executar um EVM dentro de um rollup, permitindo que os aplicativos Ethereum existentes migrem para rollups quase sem necessidade de escrever nenhum novo código .

OK, então como exatamente funciona um rollup?

Existe um contrato inteligente on-chain que mantém uma raiz de estado : a raiz Merkle do estado do rollup (ou seja, os saldos da conta, código do contrato, etc., que estão "dentro" do rollup).

Qualquer pessoa pode publicar um lote , uma coleção de transações em um formato altamente compactado junto com a raiz do estado anterior e a nova raiz do estado (a raiz do Merkle após o processamento das transações).

O contrato verifica se a raiz do estado anterior no lote corresponde à raiz do estado atual; em caso afirmativo, ele alterna a raiz do estado para a nova raiz do estado.

Para oferecer suporte a depósitos e retiradas, adicionamos a capacidade de ter transações cuja entrada ou saída está "fora" do estado de rollup.

Se um lote tiver insumos de fora, a transação que envia o lote também precisa transferir esses ativos para o contrato de rollup. Se um lote tiver saídas para o exterior, ao processar o lote, o contrato inteligente iniciará essas retiradas.

E é isso! Exceto por um detalhe importante: como saber se as raízes pós-estado nos lotes estão corretas?

Se alguém puder enviar um lote com qualquer raiz pós-estado sem consequências, poderá simplesmente transferir todas as moedas dentro do rollup para si mesmo.

Essa questão é fundamental porque há duas famílias muito diferentes de soluções para o problema, e essas duas famílias de soluções levam a dois tipos de rollups.

Rollups otimistas vs rollups ZK

Os dois tipos de rollups são:

1. Rollups otimistas , que usam provas de fraude : o contrato rollup mantém o controle de todo o seu histórico de raízes de estado e o hash de cada lote.

   
   

   Se alguém descobrir que um lote tinha uma raiz pós-estado incorreta, poderá publicar uma prova para a cadeia, provando que o lote foi calculado incorretamente.

   
   

   O contrato verifica a prova e reverte esse lote e todos os lotes posteriores a ele.

   
   

2. ZK rollups , que usam provas de validade : cada lote inclui uma prova criptográfica chamada ZK-SNARK (por exemplo, usando o protocolo PLONK ), que prova que a raiz pós-estado é o resultado correto da execução do lote.

   
   

   Não importa quão grande seja o cálculo, a prova pode ser verificada rapidamente na cadeia.

Existem compensações complexas entre os dois tipos de rollups:

Em geral, minha opinião é que, no curto prazo, rollups otimistas provavelmente vencerão para computação EVM de propósito geral e rollups ZK provavelmente vencerão para pagamentos simples, câmbio e outros casos de uso específicos de aplicativos, mas no Os rollups ZK de médio a longo prazo vencerão em todos os casos de uso à medida que a tecnologia ZK-SNARK for aprimorada.

Anatomia de uma prova de fraude

A segurança de um rollup otimista depende da ideia de que, se alguém publicar um lote inválido no rollup, qualquer outra pessoa que esteja acompanhando a cadeia e detectando a fraude possa publicar uma prova de fraude, provando ao contrato que esse lote é inválido e deve ser revertido.

Uma prova de fraude alegando que um lote era inválido conteria os dados em verde: o próprio lote (que poderia ser verificado contra um hash armazenado na cadeia) e as partes da árvore Merkle necessárias para provar apenas as contas específicas que foram lidas e/ ou modificado pelo lote.

Os nós da árvore em amarelo podem ser reconstruídos a partir dos nós em verde e, portanto, não precisam ser fornecidos.

Esses dados são suficientes para executar o lote e calcular a raiz pós-estado (observe que isso é exatamente o mesmo que os clientes sem estado verificam blocos individuais).

Se a raiz pós-estado calculada e a raiz pós-estado fornecida no lote não forem iguais, o lote é fraudulento.

É garantido que, se um lote foi construído incorretamente e todos os lotes anteriores foram construídos corretamente , é possível criar uma prova de fraude mostrando que o lote foi construído incorretamente.

Observe a alegação sobre lotes anteriores: se houver mais de um lote inválido publicado no rollup, é melhor tentar provar que o primeiro é inválido. Também é garantido que, se um lote foi construído corretamente, nunca será possível criar uma prova de fraude mostrando que o lote é inválido.

Como funciona a compactação?

Uma transação Ethereum simples (para enviar ETH) leva aproximadamente 110 bytes. Uma transferência ETH em um rollup, no entanto, leva apenas ~ 12 bytes:

Parte disso é simplesmente uma codificação superior: o RLP da Ethereum desperdiça 1 byte por valor no comprimento de cada valor. Mas também existem alguns truques de compressão muito inteligentes que estão acontecendo:

• Nonce : o objetivo deste parâmetro é evitar replays. Se o nonce atual de uma conta for 5, a próxima transação dessa conta deve ter o nonce 5, mas uma vez que a transação for processada, o nonce na conta será incrementado para 6, portanto, a transação não poderá ser processada novamente.

  
  

  No rollup, podemos omitir totalmente o nonce, porque apenas recuperamos o nonce do pré-estado; se alguém tentar reproduzir uma transação com um nonce anterior, a verificação da assinatura falharia, pois a assinatura seria verificada nos dados que contêm o novo nonce superior.

  
  

• Preço do gás : podemos permitir que os usuários paguem com uma faixa fixa de preços do gás, por exemplo. uma escolha de 16 poderes consecutivos de dois.

  
  

  Alternativamente, poderíamos apenas ter um nível de taxa fixa em cada lote, ou até mesmo mover o pagamento de gás totalmente para fora do protocolo de rollup e fazer com que os transatores paguem aos criadores do lote para inclusão por meio de um canal.

  
  

• Gás : poderíamos, de forma semelhante, restringir o gás total a uma escolha de potências consecutivas de dois. Como alternativa, poderíamos ter apenas um limite de gás apenas no nível do lote.

  
  

• Para : podemos substituir o endereço de 20 bytes por um índice (por exemplo, se um endereço for o 4527º endereço adicionado à árvore, basta usar o índice 4527 para se referir a ele.

  
  

  Adicionaríamos uma subárvore ao estado para armazenar o mapeamento de índices para endereços).

  
  

• Valor : podemos armazenar o valor em notação científica. Na maioria dos casos, as transferências precisam apenas de 1 a 3 dígitos significativos.

  
  

• Assinatura : podemos usar assinaturas agregadas BLS , que permite que muitas assinaturas sejam agregadas em uma única assinatura de ~ 32-96 bytes (dependendo do protocolo).

  
  

  Essa assinatura pode então ser verificada em todo o conjunto de mensagens e remetentes em um lote de uma só vez.

  
  

  O ~0,5 na tabela representa o fato de que há um limite de quantas assinaturas podem ser combinadas em um agregado que pode ser verificado em um único bloco e, portanto, grandes lotes precisariam de uma assinatura por ~100 transações.

Um importante truque de compactação específico para rollups ZK é que, se uma parte de uma transação for usada apenas para verificação e não for relevante para calcular a atualização de estado, essa parte pode ser deixada fora da cadeia.

Isso não pode ser feito em um rollup otimista porque esses dados ainda precisariam ser incluídos na cadeia caso precisassem ser verificados posteriormente em uma prova de fraude, enquanto em um rollup ZK o SNARK comprovando a correção do lote já prova que qualquer dado necessário para a verificação foi fornecido.

Um exemplo importante disso são os rollups de preservação de privacidade: em um rollup otimista, o ZK-SNARK de aproximadamente 500 bytes usado para privacidade em cada transação precisa ir para a cadeia, enquanto em um rollup ZK, o ZK-SNARK cobrindo todo o lote já não deixa nenhum duvido que os ZK-SNARKs "interiores" sejam válidos.

Esses truques de compactação são essenciais para a escalabilidade dos rollups; sem eles, os rollups seriam talvez apenas uma melhoria de ~ 10x na escalabilidade da cadeia de base (embora existam alguns aplicativos específicos de computação pesada onde até mesmo rollups simples são poderosos), enquanto com truques de compactação o fator de escala pode ultrapassar 100x por quase todas as aplicações.

Quem pode enviar um lote?

Há várias escolas de pensamento sobre quem pode enviar um lote em um rollup otimista ou ZK.

Geralmente, todos concordam que, para poder enviar um lote, o usuário deve fazer um grande depósito; se esse usuário enviar um lote fraudulento (por exemplo, com uma raiz de estado inválido), esse depósito será parcialmente queimado e parte dado como recompensa ao provador da fraude. Mas além disso, existem muitas possibilidades:

• Anarquia total : qualquer um pode enviar um lote a qualquer momento. Esta é a abordagem mais simples, mas tem algumas desvantagens importantes.

  
  

  Particularmente, existe o risco de vários participantes gerarem e tentarem enviar lotes em paralelo, e apenas um desses lotes pode ser incluído com sucesso.

  
  

  Isso leva a uma grande quantidade de esforços desperdiçados na geração de provas e/ou gás desperdiçado na publicação de lotes na cadeia.

  
  

• Sequenciador centralizado : existe um único ator, o sequenciador , que pode enviar lotes (com exceção para retiradas: a técnica usual é que um usuário pode primeiro enviar uma solicitação de retirada e, se o sequenciador não processar essa retirada no próximo lote, então o usuário pode enviar um lote de operação única).

  
  

  Este é o mais "eficiente", mas depende de um ator central para viver.

  
  

• Leilão do sequenciador : é realizado um leilão (por exemplo, todos os dias) para determinar quem tem o direito de ser o sequenciador do dia seguinte.

  
  

  Esta técnica tem a vantagem de angariar fundos que podem ser distribuídos por ex. um DAO controlado pelo rollup (consulte: leilões MEV )

  
  

• Seleção aleatória do conjunto PoS : qualquer um pode depositar ETH (ou talvez o próprio token de protocolo do rollup) no contrato rollup, e o sequenciador de cada lote é selecionado aleatoriamente de um dos depositantes, com a probabilidade de ser selecionado proporcional ao valor depositado.

  
  

  A principal desvantagem dessa técnica é que ela leva a grandes quantidades de bloqueio desnecessário de capital.

  
  

• Votação DPoS : há um único sequenciador selecionado com um leilão, mas se eles tiverem um desempenho ruim, os detentores de tokens podem votar para expulsá-los e realizar um novo leilão para substituí-los.

Lotes divididos e provisão de raiz de estado

Alguns dos rollups atualmente desenvolvidos estão usando um paradigma de "lote dividido", onde a ação de enviar um lote de transações de camada 2 e a ação de enviar uma raiz de estado são feitas separadamente.

Isso tem algumas vantagens importantes:

1. Você pode permitir que muitos sequenciadores em paralelo publiquem lotes para melhorar a resistência à censura, sem se preocupar que alguns lotes sejam inválidos porque algum outro lote foi incluído primeiro.

   
   

2. Se uma raiz de estado for fraudulenta, você não precisará reverter todo o lote; você pode reverter apenas a raiz do estado e esperar que alguém forneça uma nova raiz do estado para o mesmo lote.

   
   

   Isso dá aos remetentes da transação uma melhor garantia de que suas transações não serão revertidas.

Portanto, em suma, existe um zoológico bastante complexo de técnicas que tentam equilibrar entre compensações complicadas envolvendo eficiência, simplicidade, resistência à censura e outros objetivos.

Ainda é muito cedo para dizer qual combinação dessas ideias funciona melhor; o tempo vai dizer.

Quanto dimensionamento os rollups oferecem?

Na cadeia Ethereum existente, o limite de gás é de 12,5 milhões e cada byte de dados em uma transação custa 16 gás.

Isso significa que, se um bloco não contém nada além de um único lote (diremos que um rollup ZK é usado, gastando 500k de gás na verificação de prova), esse lote pode ter (12 milhões / 16) = 750.000 bytes de dados.

Conforme mostrado acima, um rollup para transferências ETH requer apenas 12 bytes por operação do usuário, o que significa que o lote pode conter até 62.500 transações.

Em um tempo médio de bloqueio de 13 segundos , isso se traduz em ~4807 TPS (em comparação com 12,5 milhões / 21000 / 13 ~= 45 TPS para transferências de ETH diretamente no próprio Ethereum).

Aqui está um gráfico para alguns outros exemplos de casos de uso:

O ganho máximo de escalabilidade é calculado como (custo de gás L1) / (bytes no acúmulo * 16) * 12 milhões / 12,5 milhões.

Agora, vale lembrar que esses números são excessivamente otimistas por alguns motivos. Mais importante ainda, um bloco quase nunca conteria apenas um lote, pelo menos porque existem e haverá vários rollups.

Em segundo lugar, os depósitos e retiradas continuarão a existir. Em terceiro lugar, no curto prazo , o uso será baixo e, portanto, os custos fixos dominarão. Mas mesmo com esses fatores levados em consideração, espera-se que ganhos de escalabilidade de mais de 100x sejam a norma.

Agora, e se quisermos ir acima de ~1000-4000 TPS (dependendo do caso de uso específico)? Aqui é onde entra a fragmentação de dados eth2 .

A proposta de sharding abre um espaço de 16 MB a cada 12 segundos que pode ser preenchido com qualquer dado, e o sistema garante consenso sobre a disponibilidade desses dados. Esse espaço de dados pode ser usado por rollups.

Esses ~ 1398k bytes por segundo são uma melhoria de 23x nos ~ 60 kB/seg da cadeia Ethereum existente e, a longo prazo, espera-se que a capacidade de dados cresça ainda mais.

Portanto, rollups que usam dados fragmentados eth2 podem processar coletivamente até ~100k TPS e ainda mais no futuro.

Quais são alguns desafios ainda não totalmente resolvidos em Rollups?

Embora o conceito básico de um rollup seja agora bem compreendido, temos certeza de que eles são fundamentalmente viáveis e seguros, e vários rollups já foram implantados na rede principal, mas ainda existem muitas áreas de design de rollup que não foram bem exploradas, e alguns desafios em trazer grandes partes do ecossistema Ethereum para rollups para aproveitar sua escalabilidade.

Alguns dos principais desafios incluem:

• Integração do usuário e do ecossistema - poucos aplicativos usam rollups, rollups não são familiares para os usuários e poucas carteiras começaram a integrar rollups.

  
  

  Comerciantes e instituições de caridade ainda não os aceitam para pagamentos.

  
  

• Transações de rollup cruzado - movimentação eficiente de ativos e dados (por exemplo, saídas do oráculo) de um rollup para outro sem incorrer na despesa de passar pela camada base.

  
  

• Incentivos de auditoria - como maximizar a chance de que pelo menos um nó honesto realmente esteja verificando totalmente um rollup otimista para que eles possam publicar uma prova de fraude se algo der errado?

  
  

  Para rollups de pequena escala (até algumas centenas de TPS), isso não é um problema significativo e pode-se simplesmente confiar no altruísmo, mas para rollups de maior escala é necessário um raciocínio mais explícito sobre isso.

  
  

• Explorando o espaço de design entre plasma e rollups - existem técnicas que colocam alguns dados relevantes para atualização de estado na cadeia, mas não todos , e há algo útil que possa resultar disso?

  
  

• Maximizando a segurança de pré-confirmações - muitos rollups fornecem uma noção de "pré-confirmação" para UX mais rápido, onde o sequenciador fornece imediatamente uma promessa de que uma transação será incluída no próximo lote e o depósito do sequenciador é destruído se eles quebrarem seu palavra.

  
  

  Mas a segurança econômica desse esquema é limitada devido à possibilidade de fazer muitas promessas para muitos atores ao mesmo tempo. Esse mecanismo pode ser melhorado?

  
  

• Melhorando a velocidade de resposta para sequenciadores ausentes - se o sequenciador de um rollup ficar off-line repentinamente, seria valioso recuperar-se dessa situação de forma mais rápida e barata, saindo em massa de forma rápida e barata para um rollup diferente ou substituindo o sequenciador.

  
  

• ZK-VM eficiente - gerando uma prova ZK-SNARK de que o código EVM de uso geral (ou alguma VM diferente para a qual os contratos inteligentes existentes podem ser compilados) foi executado corretamente e tem um determinado resultado.

Conclusões

Os rollups são um novo e poderoso paradigma de escalonamento de camada 2 e espera-se que sejam a pedra angular do escalonamento do Ethereum no futuro de curto e médio prazo (e possivelmente também a longo prazo).

Eles viram uma grande empolgação da comunidade Ethereum porque, ao contrário das tentativas anteriores de dimensionamento da camada 2, eles podem oferecer suporte ao código EVM de uso geral, permitindo que os aplicativos existentes migrem facilmente.

Eles fazem isso fazendo um compromisso importante: não tentando sair totalmente da cadeia, mas deixando uma pequena quantidade de dados por transação na cadeia.

Existem muitos tipos de rollups e muitas opções no espaço de design: pode-se ter um rollup otimista usando provas de fraude ou um rollup ZK usando provas de validade (aka. ZK-SNARKs).

O sequenciador (o usuário que pode publicar lotes de transações na cadeia) pode ser um ator centralizado, um free-for-all ou muitas outras opções intermediárias.

Rollups ainda são uma tecnologia em estágio inicial e o desenvolvimento continua rapidamente, mas eles funcionam e alguns (principalmente Loopring , ZKSync e DeversiFi ) já estão em execução há meses. Espere um trabalho muito mais emocionante para sair do espaço cumulativo nos próximos anos.