Autor: NashQ, Celestia Researcher; Compilador: Faust, Geek Web3

Nota do tradutor: Para tornar o modelo Rollup mais fácil de entender e analisar, o pesquisador da Celestia, NashQ, dividiu o sequenciador Rollup (Sequencer) em duas entidades lógicas - agregador e gerador de cabeçalho. Ao mesmo tempo, ele dividiu o processo de ordenação da transação em três etapas lógicas: inclusão, ordenação e execução.

Sob a orientação desse pensamento analítico, as seis variantes importantes do Rollup soberano são mais claras e fáceis de entender. NashQ discutiu em detalhes a resistência à censura e a atividade de diferentes variantes de Rollup e também discutiu a configuração mínima do nó de cada variante de Rollup no estado de confiança minimizada (ou seja, para atingir o estado Sem confiança, quais tipos de usuários de Rollup devem executar pelo menos nó).

Embora este artigo analise o Rollup sob a perspectiva do Celestia, que é diferente da forma como a comunidade Ethereum analisa o modelo Rollup, considerando as muitas interconexões entre o Ethereum Rollup e o Celestia soberano Rollup, bem como a crescente influência deste último, é importante para Entusiastas do Ethereum, este artigo também vale a pena ler.

O que é Rollup?

Um Rollup é um blockchain que publica seus "dados de transação" para outro blockchain e herda seu consenso e disponibilidade de dados.

Por que usei propositadamente a palavra "dados de transação" em vez de "bloquear"? Isso envolve uma distinção entre blocos de rollup e dados de rollup, com os rollups mais compactos exigindo apenas dados de rollup como a primeira variante abaixo.

Um bloco Rollup é uma estrutura de dados que representa o ledger blockchain em uma certa altura de bloco. O bloco rollup consiste em dados rollup e cabeçalho rollup. Entre eles, os dados Rollup podem ser um lote de transações ou alterações de estado entre um lote de transações.

Variante 1: Rollup pessimista / Rollup baseado

A maneira mais fácil de construir um Rollup é permitir que os usuários publiquem transações em outro blockchain, que chamaremos de camada de consenso e disponibilidade de dados (DA-Layer), e eu simplesmente a chamarei de camada DA abaixo (Nota do tradutor: é semelhante à camada 1, que é frequentemente dita na comunidade Ethereum).

Na primeira variante Rollup que vou apresentar, os nodos da rede Rollup devem reexecutar as transações Rollup contidas na camada DA para verificar o estado final do ledger. Isso é Rollup pessimista!

Pessimistic Rollup é um Rollup que suporta apenas nós completos, e esses nós completos precisam reexecutar todas as transações contidas no ledger Rollup para verificar sua validade.

Mas, neste caso, quem atua como Sequenciador do Rollup? De fato, com exceção dos nós completos do Rollup, nenhuma entidade jamais executou as transações contidas no ledger do Rollup. De um modo geral, o sequenciador agrega os dados da transação e gera um cabeçalho Rollup. Mas o Rollup pessimista mencionado acima não tem cabeçalho Rollup!

Para facilitar a discussão, podemos dividir o sequenciador em duas entidades lógicas: Agregador Agregador e Gerador de cabeçalho. Para gerar um Rollup Header, você deve primeiro executar a transação, completar a transição de estado e então calcular o Header correspondente. Mas para um agregador, ele não precisa concluir uma transição de estado para prosseguir com a etapa de agregação.

Sorting Sequencing é o processo de "agregação + criação de cabeçalho de rollup".

A agregação é a etapa de agrupar os dados da transação em um lote. Um lote geralmente contém muitas transações (Nota do Tradutor: Lote é a parte dos dados no bloco Rollup diferente do Cabeçalho).

A etapa de geração do cabeçalho é o processo de criação de um Cabeçalho Rollup. Rollup Header são os metadados sobre o bloco Rollup, incluindo pelo menos o compromisso dos dados da transação no bloco (Nota do tradutor: O compromisso mencionado aqui se refere ao compromisso com a correção dos resultados do processamento da transação).

Através da perspectiva acima, pode-se ver quem é o responsável por cada parte do Rollup. Primeiro olhe para a parte do agregador Agregador. O Rollup pessimista mencionado acima não possui processo de geração de cabeçalho e os usuários publicam transações diretamente na camada DA, o que significa que a rede da camada DA atua essencialmente como um agregador.

Portanto, o Rollup pessimista é uma variante do Rollup que delega a etapa de agregação à camada DA, que não possui sequenciador Sequencer. Às vezes, esse tipo de rollup é chamado de "rollup baseado".

O Rollup baseado tem a mesma resistência à censura e atividade que a camada DA (a atividade mede a velocidade de feedback do sistema às solicitações do usuário). Se os usuários deste tipo de Rollup quiserem atingir um estado de confiança mínima (mais próximo de Trustless), eles devem executar pelo menos um light node da rede da camada DA e um full node da rede Rollup.

Variante 2: Agregação pessimista usando um agregador compartilhado

Vamos discutir a agregação pessimista usando um agregador compartilhado. Essa ideia foi sugerida por Evan Forbes em sua postagem no fórum sobre design de sequenciador compartilhado. Sua suposição chave é que um sequenciador compartilhado é a única maneira formal de sequenciar transações. Evan explica os benefícios dos sequenciadores compartilhados desta maneira:

"Para obter uma experiência de usuário equivalente à Web2, o sequenciador compartilhado pode fornecer geração rápida de Soft Commitments (garantias não muito confiáveis). Alterar) e a etapa de atualização do status do ledger Rollup pode ser realizada antecipadamente (mas Finalizar ainda não foi concluída neste momento).

Uma vez que os dados do bloco Rollup são confirmados e liberados para a camada base Base Layer (aqui deve se referir à camada DA), a atualização de status do ledger Rollup é finalizada e finalizada. "

A variante Rollup acima mencionada ainda pertence à categoria de Rollup pessimista, porque neste tipo de sistema Rollup existem apenas nós completos e nenhum nó leve. Cada nó Rollup deve executar todas as transações para garantir a validade da atualização do status do razão. Como esse tipo de Rollup não possui light nodes, ele não precisa de um Rollup Header, nem de um gerador de Header. (Nota do tradutor: Em geral, nós leves de uma blockchain não precisam sincronizar blocos completos, apenas recebem cabeçalhos de bloco)

Como não há etapa de geração de Rollup Header, o sequenciador compartilhado Rollup acima mencionado não precisa executar transações para atualizações de status (um pré-requisito para gerar Headers), mas inclui apenas o processo de agregação de dados da transação. Portanto, prefiro chamá-lo de agregador compartilhado agregador compartilhado.

Nesta variante, os usuários do Rollup precisam executar pelo menos nós leves da camada DA + nós leves da rede do agregador compartilhado + nós completos do Rollup em um estado de confiança minimizada.

Neste ponto, é necessário verificar o cabeçalho do agregador publicado (não o Rollup Header) através dos light nodes da rede do agregador compartilhado. Como mencionado acima, o agregador compartilhado realiza o trabalho de classificação das transações, contendo um compromisso criptográfico no cabeçalho do agregador publicado, correspondente ao Lote que ele liberou na camada DA.

Desta forma, o operador do nó Rollup pode confirmar que o batch Batch recebido da camada DA foi criado pelo agregador compartilhado e não por outros.

• Inclusão é o processo de inclusão de transações no blockchain.
• Ordenação de classificação refere-se ao processo de organização de transações no blockchain em uma ordem específica.
• Execução refere-se ao processo de processamento de transações no blockchain e conclusão de atualizações de status.

Como o agregador compartilhado cuida da inclusão e classificação, a resistência à censura do Rollup depende disso.

Se for assumido que L_ss é a atividade do agregador compartilhado e L_da é a atividade do DA-Layer, então a atividade do modelo Rollup é L = L_da && L_ss. Em outras palavras, se qualquer uma das duas partes tiver uma falha de vivacidade, o Rollup também terá uma falha de vivacidade.

Para simplificar, considerarei a vivacidade como um valor booleano. Se o agregador compartilhado falhar, o Rollup não poderá continuar a operar. Se a rede da camada DA falhar, o agregador compartilhado pode continuar a fornecer Soft Commitment para blocos Rollup. Mas, neste momento, os atributos do Rollup dependerão inteiramente da rede agregadora compartilhada, e os atributos desta última geralmente são muito inferiores aos da camada DA original.

Vamos explorar a resistência à censura do esquema Rollup acima:

Nesse esquema, a camada DA não pode revisar algumas transações específicas (Nota do tradutor: a revisão da transação geralmente pode se recusar a permitir que certas transações sejam carregadas na cadeia), ela só pode iniciar para todo o lote de transações enviadas pelo agregador compartilhado Revisão da transação (recusou-se a permitir que um lote seja incluído na camada DA).

No entanto, de acordo com o fluxo de trabalho Rollup, quando o agregador compartilhado envia o lote de transações Batch para a camada DA, ele já concluiu a classificação da transação e a ordem entre os diferentes lotes também foi determinada. Portanto, esse tipo de revisão da transação na camada DA não tem outro efeito senão atrasar a confirmação final do ledger do Rollup.

Em resumo, acredito que o objetivo da resistência à censura é garantir que nenhuma entidade possa controlar ou manipular o fluxo de informações dentro do sistema, enquanto a vivacidade envolve a manutenção da funcionalidade e disponibilidade do sistema, mesmo na presença de interrupções de rede e comportamento de confronto. Embora isso entre em conflito com a definição acadêmica atual, ainda usarei a definição do conceito que articulei.

Variante 3: Rollup pessimista baseado em Rollup baseado e agregador compartilhado

Embora o agregador compartilhado traga benefícios para os usuários e para a comunidade, devemos evitar o excesso de confiança nele e permitir que os usuários saiam do agregador compartilhado para a camada DA. Podemos combinar as duas variantes de Rollup introduzidas anteriormente, permitindo que os usuários enviem transações diretamente para a camada DA enquanto usam um agregador compartilhado.

Assumimos que a sequência final da transação Rollup depende da sequência da transação enviada pelo agregador compartilhado e das transações Rollup enviadas diretamente pelos usuários no bloco da camada DA. Chamamos isso de regra de seleção de bifurcação do Rollup.

Aqui, a agregação é dividida em duas etapas. Primeiro, um agregador compartilhado entra em ação, agregando algumas transações. Em seguida, a camada DA pode agregar o Batch enviado pelo agregador compartilhado e as transações enviadas diretamente pelo usuário.

A análise da resistência à censura neste ponto é um pouco mais complicada. Os nós de rede da camada DA podem revisar o lote enviado pelo agregador compartilhado antes que o próximo bloco da camada DA seja produzido. Depois de conhecer os dados da transação no lote, os nós da camada DA podem extrair o valor de MEV e primeiro usar a si mesmos no Rollup rede A conta inicia uma transação de execução inicial e a inclui primeiro no bloco da camada DA e, em seguida, inclui o lote enviado pelo agregador compartilhado Rollup.

Obviamente, a finalidade da ordem de transação garantida pelo compromisso suave do terceiro tipo de variante Rollup é mais frágil do que o segundo tipo de variante Rollup mencionado anteriormente. Nesse caso, o agregador compartilhado entregou o valor MEV aos nós da camada DA. A esse respeito, recomendo aos leitores que assistam à palestra de pesquisa sobre a exploração lucrativa do MEV censurado.

Atualmente, alguns esquemas de design surgiram para reduzir a capacidade dos nós da rede da camada DA de executar tais transações MEV, como a função "período da janela de reorganização", que atrasará a execução de transações enviadas diretamente à camada DA pelos usuários da rede Rollup . O Sovereign Labs descreve isso em detalhes em sua proposta de design chamada Baseado em Sequenciamento com Soft Confirmations, que introduz o conceito de um "sequenciador preferido".

Como o problema de MEV depende do esquema agregador escolhido por Rollup e das regras de seleção de fork de rollup, alguns esquemas não vazarão MEV para a camada DA e alguns esquemas vazarão parte ou todo o MEV para a camada DA, mas isso é outro assunto.

Quanto à vivacidade, esse esquema de rollup tem vantagens sobre os esquemas que permitem apenas que os agregadores compartilhados enviem transações para a camada DA. No caso de uma falha de atividade em um agregador compartilhado, os usuários ainda podem enviar transações para a camada DA.

Por fim, vamos falar sobre a configuração mínima de usuários Rollup sob minimização de confiança:

Pelo menos execute o nó leve da camada DA + nó leve do agregador compartilhado + nó completo do Rollup.

Neste ponto, ainda é necessário verificar o cabeçalho do agregador emitido pelo agregador compartilhado, para que o rollup full node possa distinguir os lotes de transações de acordo com as regras de seleção do fork.

Variante 4: Rollup com base otimista e gerador de cabeçalho centralizado

Vamos discutir uma variante chamada Rollup otimista baseado e um gerador de cabeçalho centralizado. Esta solução usa a camada DA para agregar transações Rollup, mas apresenta um gerador de cabeçalho centralizado para gerar cabeçalhos Rollup para habilitar nós leves Rollup.

Os nós de rollup light podem verificar indiretamente a validade das transações de rollup por meio de uma única rodada de prova de fraude. O light node ficará otimista sobre o gerador do Rollup Header e fará a confirmação final após o término do período da janela à prova de fraude. Outra possibilidade é que ele receba uma prova de fraude de um nó completo honesto de que o gerador de cabeçalho enviou dados incorretos.

Não vou entrar em detalhes de como uma prova de fraude de rodada única funciona aqui, pois isso está além do escopo deste artigo. A vantagem de uma única rodada de prova de fraude é que ela pode encurtar o período da janela à prova de fraude de 7 dias até certo ponto. O valor específico ainda não foi determinado, mas a ordem de grandeza é menor do que o rollup otimista tradicional. Os nós leves podem obter provas de fraude através da rede P2P composta por nós completos Rollup sem esperar pelo processo de disputa posterior, pois todos os critérios são fornecidos integralmente em uma única prova de fraude.

O modelo Rollup acima usa a camada DA como um agregador e herda sua resistência à censura. A camada DA neste ponto é responsável por conter e ordenar as transações. O gerador de Cabeçalho centralizado lerá a seqüência de transação Rollup da camada DA e construirá o Cabeçalho Rollup correspondente de acordo. O gerador de cabeçalho publicará o cabeçalho e o Stateroot na camada DA. Esses Stateroots são necessários ao criar provas de fraude. Resumindo, o agregador é responsável por incluir e classificar as transações, e o gerador de cabeçalho executará a transação para atualizar o estado para obter o Stateroot.

Suponha que a camada DA (que também atua como um agregador para Rollup neste ponto) seja suficientemente descentralizada e resistente à censura. Além disso, o gerador de cabeçalho não pode alterar a sequência de transações Rollup publicadas pelo agregador. Agora, se o gerador de cabeçalho for descentralizado, o único benefício é uma melhor vivacidade, mas as outras propriedades do Rollup são as mesmas da primeira variante do Rollup baseado.

Se o gerador de cabeçalho falhar na ativação, o rollup também falhará na ativação. Os nós leves não poderão acompanhar o progresso do ledger Rollup, mas os nós completos poderão. Neste ponto, o Rollup descrito na Variante 4 degenera no Rollup Baseado descrito na Variante 1. Aparentemente, a configuração mínima de confiança minimizada descrita pela Variante 4 é:

Nó de luz da camada DA + Nó de luz de rollup.

Variante 5: Rollup baseado em ZK e mercado descentralizado de provedores

Discutimos Rollup Pessimista (Rollup Baseado) e Rollup Otimista, agora é hora de considerar o ZK-Rollup. Recentemente, Toghrul fez uma palestra sobre a separação do agregador (Sequencer) e do gerador de cabeçalho (Prover) (Separação Sequencer-Prover em Zero-Knowledge Rollups). Nesse modelo, é mais fácil lidar com transações de publicação como dados Rollup em vez de State Diff, portanto, focarei no primeiro. A variante 5 é um Prover Market descentralizado baseado em zk-rollup.

Até agora, você deve estar familiarizado com o funcionamento do Rollup. A variante 5 delega a função de agregador aos nós da camada DA, que fazem o trabalho de incluir e classificar as transações. Vou citar a documentação do Sovereign-Labs, que tem uma boa explicação sobre o ciclo de vida de uma transação na variante 5:

O usuário publica um novo bloco de dados na cadeia L1 (camada DA). Uma vez que esses blocos de dados são finalizados na cadeia L1, é logicamente final (inalterável). Depois que os blocos da cadeia L1 entrarem no estágio de finalização (ou seja, eles não podem ser revertidos), os nós completos do Rollup farão a varredura desses blocos, processarão todos os blocos de dados relacionados ao Rollup em ordem e gerarão o último Stateroot raiz do estado Rollup . Neste ponto, do ponto de vista dos nós completos do Rollup, esses blocos de dados foram finalizados.

Neste modelo, o gerador do Header é atuado pelo Prover Market descentralizado.

O processo de trabalho do nó do provedor do Prover (um nó completo em execução no ZKVM) é semelhante ao de um nó completo normal do Rollup - verificando o blockchain da camada DA e processando todos os lotes de transações do Rollup em ordem - para gerar a prova de conhecimento zero correspondente e publicar na cadeia da camada DA. (Caso o sistema Rollup queira motivar o provador, este deve enviar a prova ZK gerada para a cadeia de camada DA, caso contrário não será possível determinar qual Provedor enviou a prova ZK primeiro). Uma vez que o comprovante ZK correspondente a um determinado lote de transações é liberado para a cadeia, o lote de transações é finalizado aos olhos de todos os nós do Rolup (incluindo os nós leves).

A variante 5 tem a mesma resistência à censura que a camada DA. O Prover Market descentralizado não pode revisar as transações Rollup, porque a camada DA já determinou a ordem padrão da transação, apenas para obter uma melhor atividade e criar um mercado de incentivos, portanto, o gerador Header (aqui se refere ao Prover) é uma mudança descentralizada.

A atividade aqui é L = L_da && L_pm (atividade do Prover). Se os incentivos do Prover Market forem inconsistentes ou houver uma falha ativa, o Rollup light node não será capaz de sincronizar o progresso do blockchain, mas o Rollup full node pode. Para o full node, isso é apenas um fallback para Rollup baseado/rollup pessimista. A configuração mínima para minimização de confiança aqui é a mesma do Rollup otimista, ou seja,

Nó de luz da camada DA + Nó de luz de rollup.

Variante 6: Rollup baseado em híbrido + Gerador de cabeçalho otimista centralizado + Provedor descentralizado

Ainda permitimos que os nós da camada DA atuem como agregadores de Rollup e delegamos a eles o trabalho de incluir e solicitar transações.

Como você pode ver na figura abaixo, tanto o ZK Rollup quanto o Optimistic Rollup usam o mesmo lote de transações ordenadas na camada DA como fonte do registro de Rollup. Esta é a razão pela qual podemos usar ambos os sistemas de prova ao mesmo tempo: o lote ordenado de transações na camada DA não é afetado pelo sistema de prova.

Vamos falar sobre a finalidade primeiro. Na perspectiva do nó completo do Rollup, quando o bloco da camada DA é finalizado, o lote de transações do Rollup contido nele é finalizado e não pode ser alterado. Mas nos preocupamos mais com a finalidade da perspectiva dos nodos de luz. Suponha que o gerador de Cabeçalho centralizado hipoteque alguns ativos, assine o Cabeçalho Rollup gerado e envie o Stateroot calculado para a camada DA.

Como a variante 4 anterior, o light node confiará com otimismo no gerador de cabeçalho, acreditará que o cabeçalho que emitiu está correto e aguardará a prova de fraude da rede de nodo completo. Caso o período da janela do fraud proof tenha terminado e a rede full node não tenha emitido o fraud proof, na perspectiva do nó Rollup light, o bloco Rollup é finalizado.

O ponto principal é que, se conseguirmos uma prova de ZK, não precisamos esperar que a janela de prova de fraude termine. Além de uma única rodada de provas de fraude, podemos substituir provas de fraude por provas ZK e descartar cabeçalhos falsos gerados por geradores de cabeçalho maliciosos!

Quando os light nodes recebem uma prova ZK para um lote de transações Rollup, o lote é finalizado.

Agora temos um Soft Commitment rápido e uma finalização rápida.

A variante 6 ainda tem a mesma resistência à censura que a camada DA porque é baseada na camada DA. Para vivacidade, teremos L = L_da && (L_op || L_pm), o que significa que adicionamos garantias de vivacidade. Se o gerador de Cabeçalho centralizado ou o Prover Market descentralizado tiver uma falha de atividade, podemos degenerar para o outro dos dois.

Nesta variante, a configuração mínima para minimização da confiança do usuário é:

Um nó de luz da camada DA + um nó de luz Rollup.

Resumo:

1. Dividimos o papel principal do Rollup - Sequencer em dois componentes lógicos:

Agregadores e geradores de cabeçalho.

2. Dividimos o trabalho do Sequencer em três processos lógicos: contenção, triagem e execução.

3. Rollup pessimista e rollup baseado são uma coisa.

4. De acordo com suas necessidades, você pode escolher diferentes soluções de agregador e gerador de cabeçalho.

5. Cada variante de Rollup apresentada neste post segue o mesmo padrão de design:

Finalmente, tenho alguns pensamentos. Por favor, pense sobre:

• Como o Rollup clássico (referindo-se ao Ethereum Rollup) é classificado nas variantes acima?
• Em todas as variantes, deixamos apenas o agregador responsável pela inclusão + classificação, e o gerador de cabeçalho para executar a transação. E se o agregador for responsável apenas por incluir transações e o gerador de cabeçalho for responsável por ordenar e executar transações? Considerando a introdução da etapa do leilão on-chain, podemos separar completamente essas três etapas?
• O que é produtor de cabeçalho compartilhado/mercado de produtor de cabeçalho?
• Quem capta o valor MEV? O usuário pode recuperá-lo?