Encaminhe o título original: Descompactando a próxima geração de Ethereum L2s (III): Rollups nativos

Nos últimos dois anos, a Ethereum comprometeu-se totalmente com um roadmap centrado em rollups. Esta estratégia envolve bloquear ETH em contratos de ponte, executar transações off-chain e usar provas - quer provas de fraude ou provas de conhecimento zero (ZKPs) - para verificar o estado da camada 2 (L2) e lidar com levantamentos.

No entanto, há um desafio significativo: o Ethereum não valida nativamente a execução do EVM, obrigando as rollups a implementar independentemente seus próprios sistemas de prova na cadeia para validar as transições de estado.

O Ethereum frequentemente passa por hard forks que podem modificar o EVM, o que significa que as equipes de rollup devem assumir a responsabilidade de manter e atualizar suas implementações personalizadas. Isso frequentemente requer a formação de um conselho de segurança ou a adoção de um sistema de governança de votação baseado em tokens para gerenciar as atualizações de seus contratos de ponte e mecanismos de prova.

Na nossa série anterior, exploramos baseados em rollups e booster rollups. Agora, estamos voltando nossa atenção para mergulhar mais profundamente no conceito de rollups nativos.

Baseado, Impulsionador, Nativo... Qual é a diferença?

Pode haver muita confusão entre as definições de rollups baseados, rollups impulsionadores e rollups nativos. Na série anterior, abordamos os rollups baseados e os rollups impulsionadores, por isso é recomendado verificar esses antes de ler este artigo. No entanto, vamos rapidamente lembrá-lo sobre esses três tipos.

Os Rollups baseados utilizam o conjunto de validadores L1 para a sequência de transações, promovendo a descentralização, mas potencialmente afetando a capacidade devido aos tempos de bloco L1 relativamente longos, como 12 segundos. No entanto, estão sendo feitos esforços para melhorar essa experiência com técnicas de pré-confirmação, permitindo que os usuários se beneficiem de uma finalização de transação muito mais rápida à medida que a comunidade continua a inovar.

Booster Rollups escalam a execução e o armazenamento imitando o processamento L1 no L2, permitindo que as aplicações cresçam sem terem de ser redesenhadas. Embora esta abordagem ofereça escalabilidade, introduz uma complexidade adicional em comparação com os rollups tradicionais, exigindo esforços de engenharia mais sofisticados para desenvolver e manter.

Os Rollups Nativos utilizam a própria função de transição de estado (STF) da L1 na camada de aplicação como verificador de transições de estado. No entanto, embora o Optimism, Arbitrum e outros rollups operem em ambientes equivalentes ao EVM, eles frequentemente incluem modificações personalizadas que podem ser complexas - ou até mesmo inviáveis - de implementar diretamente no Ethereum.

Os rollups nativos, antes conhecidos como rollups consagrados, foram discutidos em detalhes em vários documentos. Além disso, o termo "rollup canônico" foi brevemente utilizado por @apolynya. No entanto, 'consagrado' foi eventualmente substituído por 'nativo' para indicar que os rollups equivalentes ao EVM existentes poderiam potencialmente atualizar para este modelo. O termo 'nativo' foi proposto por@danrobinsone um contribuidor anónimo do Lido.

Como funcionam os rollups nativos?

A proposta nativa de rollup introduz o EXECUTE precompile, projetado para atuar como um verificador para transições de estado de rollup. Esse precompilado permitiria que as equipes de rollup o usassem em seus contratos verificadores, fornecendo uma base para sistemas de prova e permitindo que os rollups herdem a validação nativa do Ethereum.

Uma vez que este novo pré-compilado é algo semelhante ao conceito de “EVM em EVM”, ele será atualizado através do processo de hard-fork da Ethereum sob seu consenso social. Isso garante que as alterações na EVM sejam espelhadas no pré-compilado, permitindo que os rollups herdem a validação da Ethereum e aliviando as equipes de rollup de responsabilidades de governança como conselhos de segurança ou multisigs, tornando os rollups inerentemente mais seguros para os usuários.

A função de pré-compilação EXECUTE atua como um verificador para as transições de estado EVM, permitindo que os rollups utilizem a infraestrutura nativa do Ethereum na camada de aplicação. Ele valida as transições usando entradas como pre_state_root, post_state_root, trace e gas_used, aproveitando um mecanismo de precificação de gás semelhante ao EIP-1559.

Os validadores podem fazer cumprir a correção das transições de estado do rollup através de re-execução ou provas SNARK, dependendo das necessidades de escalabilidade do rollup. Além disso, um atraso de um slot é incorporado para mitigar os riscos de centralização, como a competição de prova impulsionada por MEV.

O pré-compilado simplifica o desenvolvimento de rollup, permitindo rollups "sem confiança" em termos de sistemas de prova. Se combinado com um design de rollup baseado, onde tanto o sequenciamento quanto os sistemas de prova são gerenciados pelo Ethereum, essa estrutura poderia alcançar total falta de confiança, frequentemente referida como um "rollup de ultrassom". Ele melhora a composabilidade com potencial para liquidação em tempo real, incentivando assim designs de rollup mais componíveis e seguros.

A pré-compilação proposta comporta-se de forma semelhante ao EVM, re-executando transações rollup para verificar a correção. Isso contradiz a principal vantagem dos rollups, que é a execução off-chain com apenas provas de validade enviadas ao Ethereum. Em vez disso, a pré-compilação essencialmente espelha o que o Ethereum já faz, não adicionando nenhum valor em termos de aliviar a carga computacional do L1.

A escolha de um verificador semelhante ao EVM em vez de verificadores zk decorre da atual imaturidade da tecnologia ZK. Mesmo os zkVMs amplamente utilizados mostraram vulnerabilidades, e a rápida evolução das ZKPs torna arriscado e inflexível codificar especificamente verificadores zk na cadeia. Em vez disso, o Ethereum prioriza a diversidade e neutralidade, permitindo a experimentação com vários clientes zk sem ficar preso a um único verificador.

No entanto, isso não significa que o precompile falhe em contribuir para a escalabilidade do Ethereum. Enquanto o Ethereum garante sua segurança mantendo os verificadores de zk-proof off-chain, ele alavanca esse precompile para validar zk-proofs submetidos pelos rollups. Isso permite que os validadores do Ethereum evitem emular totalmente todas as transações de rollup do início ao fim. Em vez disso, ao confiar em zk-proofs off-chain, a rede mantém suas garantias de segurança enquanto se esforça para alcançar escalabilidade em termos de execução.

Quais são os principais benefícios dos rollups nativos?

Com rollups nativos, grande parte do trabalho complexo pode ser tratado por uma precompilação, tornando coisas como provas de fraude ou verificações SNARK muito mais simples. Isso significa menos código para escrever e manter, e sem a necessidade de sistemas adicionais como redes de prova ou conselhos de segurança.

A verificação SNARK on-chain é cara, por isso muitos zk-rollups liquidam transações com menos frequência para economizar custos. O precompilado EXECUTE poderia ajudar a reduzir esses custos agrupando várias provas juntas usando a recursão SNARK. Essa abordagem permite que os rollups validem transações de forma mais eficiente, tornando a verificação off-chain mais acessível.

Garantir a operação sem bugs em rollups tradicionais é desafiador e muitas vezes requer verificações extensivas. Muitas equipes mitigam riscos empregando sequenciamento centralizado para evitar a criação de blocos maliciosos. A execução nativa via pré-compilação, no entanto, poderia permitir um mecanismo de sequenciamento mais seguro e sem permissões. Essa abordagem pode permitir que os rollups herdem não apenas a segurança, mas também a fungibilidade de ativos do L1, já que as transações são validadas diretamente dentro do ambiente confiável do Ethereum.

Existem muitos rollups que são compatíveis com o EVM, mas quase nenhum deles é equivalente ao EVM: acompanhar as mudanças na blockchain principal frequentemente requer um sistema de grupo ou de votação para atualizar rollups, o que pode ser arriscado. Os rollups nativos podem ser atualizados automaticamente com a blockchain principal, mantendo tudo sincronizado sem a necessidade de regras ou votantes adicionais.

Para zk-rollups, atingir tempos de prova de ultra-baixa latência, como 100ms, é uma tarefa de engenharia altamente desafiadora. Rollups nativos, por comparação, poderiam permitir um cronograma de prova mais 'relaxado', estendendo-o para um slot completo. Essa abordagem reduz a pressão para gerar provas instantaneamente, potencialmente melhorando a confiabilidade e a integração com L1.

Todos os rollups serão nativos?

Todas as pilhas rollup atuais, como a Pilha OP e a Pilha Arbitrum Orbit, têm o potencial de se transformar em "rollups nativos," herdando diretamente as características de segurança do Ethereum. Esta atualização faria com que os usuários ficassem mais felizes devido à segurança aprimorada e as equipes de rollup mais satisfeitas por eliminar a necessidade de conselhos de segurança. Enquanto isso, as equipes de rollup podem continuar a competir oferecendo uma camada de sequenciamento compartilhada eficiente, ainda capturando taxas de sequenciador e maximizando o MEV.

No entanto, nem todos os rollups farão a transição para serem nativos. Algumas características L2 são inerentemente incompatíveis com rollups nativos, incluindo tipos de transação exclusivos, métodos distintos de contabilidade de gás e pré-compilações não encontradas na blockchain L1 principal. A variedade de VMs entre os rollups L2, cada um compartilhando uma base de segurança comum, é uma das fortalezas do ecossistema L2 atual, como @EclipseFNDsendo um rollup SVM, @movementlabsxyzsendo um rollup MoveVM, ou @Starknetsendo um rollup CairoVM.

Como observado por @doganeth_en, futuros rollups serão divididos em três categorias: rollups empresariais, rollups focados em desempenho e rollups nativos 'alinhados'.

As empresas estarão concentradas em gerir, sequenciar e possuir os seus rollups, perfeito para empresas que desejam ter controlo semelhante ao web2 sobre a ordem das transações, execução e aplicações.

Rollups focados no desempenho usarão a liquidação do Ethereum, mas dependerão de disponibilidade de dados alternativos para obter alto desempenho, como @megaeth_labsusar @eigen_dapara disponibilidade de dados. Menos descentralizados, esses rollups impulsionam $ETHutilidade mas compromisso em alguns recursos do Ethereum.

Os rollups nativos serão totalmente integrados à infraestrutura do Ethereum e oferecerão: descentralização ao nível do Ethereum, execução compartilhada com acesso direto ao estado e verificação mais barata de prova ZK fora da cadeia. Esses rollups contribuem para os efeitos de rede do Ethereum, potencialmente compartilhando receitas, mas a sustentabilidade depende de incentivos econômicos naturais.

Conclusão

Os rollups nativos representam um avanço importante na estratégia rollup-centric do Ethereum, oferecendo uma abordagem mais alinhada com a infraestrutura do Ethereum. Ao introduzir a pré-compilação EXECUTE, os rollups nativos simplificam a governança, eliminando a dependência de multisigs, conselhos de segurança ou sistemas de votação baseados em tokens. Essa abordagem não apenas aprimora a segurança, mas também permite que os rollups dimensionem de forma mais eficiente usando zk-proofs off-chain, garantindo tanto a minimização de confiança quanto a escalabilidade.

Embora a proposta tenha grandes promessas, ela não está isenta de desafios. A maioria dos rollups existentes, apesar de serem rotulados como equivalentes ao EVM, muitas vezes incluem modificações ligeiras no EVM. Como resultado, a transição para um modelo de rollup nativo poderia introduzir custos adicionais de desenvolvimento para rollups com implementações personalizadas do EVM.

No entanto, os rollups nativos oferecem um caminho convincente para integrar a segurança e flexibilidade do Ethereum com o design de rollup. Ao promover a alinhamento com o L1, eles incentivam a inovação ao reduzir a fragmentação, tornando o ecossistema do Ethereum mais coeso e resiliente para o futuro.

Se ainda não o fez, certifique-se de verificarparte Ieparte IIda nossa série Rollups 2.0 que se concentram em rollups baseados e rollups de impulso, respetivamente. No nosso próximo post, iremos aprofundar o conceito de rollups gigagas e explorar como esta abordagem inovadora ao design de rollup poderia empurrar os limites da escalabilidade do Ethereum e melhorar ainda mais o ecossistema rollup.

Aviso legal:

1. Este artigo é reproduzido de [2077 Pesquisa]. Encaminhe o título original: Descompactando a próxima geração de Ethereum L2s (III): Rollups nativos. Todos os direitos autorais pertencem ao autor original [2077 Research]. Se houver objeções a esta reimpressão, por favor entre em contato com o Gate Learnequipa e eles vão tratar disso prontamente.
2. Aviso de responsabilidade: As opiniões expressas neste artigo são exclusivamente do autor e não constituem qualquer conselho de investimento.
3. As traduções do artigo para outros idiomas são feitas pela equipe de Aprendizado da gate. Copiar, distribuir ou plagiar os artigos traduzidos é proibido, a menos que mencionado.