Sequências = Agregador + Produtor de cabeçalho

• Título original encaminhado: Pesquisador da Celestia analisa 6 variantes de Rollup: Sequenciador=agregador+gerador de cabeçalho

Observação: Para facilitar a compreensão e a análise do modelo de rollup, o pesquisador da Celestia, NashQ, dividiu o sequenciador de rollup em duas entidades lógicas: o agregador e o produtor 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.

Guiados por esse pensamento analítico, as seis principais variantes do Sovereign Rollup são mais claras e fáceis de entender. A NashQ discutiu em detalhes a resistência à censura e a vivacidade de diferentes variantes do Rollup, bem como a configuração mínima de cada nó da variante do Rollup no estado de minimização da confiança (ou seja, para atingir um estado sem confiança, pelo menos quais tipos de nós os usuários do Rollup precisam executar).

Embora este artigo analise o Rollup a partir da perspectiva da 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 Sovereign Rollup, bem como a crescente influência deste último, vale a pena ler este artigo para os entusiastas do Ethereum.

O que é um Rollup?

Rollups são blockchains que publicam seus dados de transação em outro blockchain e herdam seu consenso e disponibilidade de dados.

Por que estou mudando "bloco" para "dados de transação" aqui? Vou explicar ao senhor a diferença entre um bloco de rollup e dados de rollup e mostrar que o rollup mínimo só precisa de dados de rollup com nossa primeira variante.

Um bloco de rollup é uma estrutura de dados que representa o blockchain em uma determinada altura. Ele consiste em dados de rollup e cabeçalho de rollup. E os dados de rollup são um lote de transações ou a diferença de estado entre os lotes de transações.

Variante 1: Rollup pessimista baseado

A maneira mais simples de criar um rollup começa com um usuário postando transações em outra blockchain. Chamaremos essa blockchain de camada de consenso e disponibilidade de dados, mas vou abreviá-la para DA-Layer em todos os diagramas a seguir. (Observação: semelhante à Layer1, frequentemente mencionada na comunidade Ethereum).

Em nossa primeira variante, cada nó de rollup deve reproduzir todas as transações na blockchain para verificar o estado mais recente. Acabamos de criar um Rollup pessimista!

Um rollup pessimista é um rollup que suporta apenas nós completos que reproduzem todas as transações no rollup para verificar sua validade.

Mas, nesse caso, quem é o sequenciador? Nenhuma entidade está realmente executando as transações além dos próprios nós completos de rollup. Normalmente, um sequenciador agregaria as transações e produziria um cabeçalho de rollup, mas não há cabeçalho nesse caso!

Para facilitar a discussão, dividimos o sequenciador em duas entidades lógicas: o agregador e o produtor de cabeçalho o diferenciam. Uma entidade deve estar ciente do estado (ou seja, deve executar o estado para computar o cabeçalho), mas o agregador não precisa entender o estado para poder agregá-lo.

Sequenciamento é o processo de agregação e produção de cabeçalhos.

A agregação é o processo de agrupar transações em um único lote. Um lote de transações consiste em uma ou mais transações. (Observação: Batch é a parte dos dados no bloco Rollup, exceto o Header).

A produção do cabeçalho é o processo de criação do cabeçalho do rollup.

O cabeçalho de rollup é um metadado sobre o bloco que, no mínimo, inclui um compromisso com as transações desse bloco. (Observação: o compromisso aqui se refere ao compromisso com a exatidão dos resultados do processamento da transação).

Pela perspectiva acima, podemos ver quem desempenha o papel de cada componente do Rollup. Vamos examinar primeiro a parte do agregador. O rollup pessimista mencionado anteriormente não tem um processo de produçã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.

Um Rollup Pessimista é uma variante do Rollup que delega a etapa de agregação à camada DA. Ele não tem um sequenciador. Às vezes, esse tipo de rollup é chamado de "rollup baseado".

O Rollup baseado tem a mesma resistência à censura e vivacidade que a camada DA (a atividade mede a velocidade de resposta do sistema às solicitações do usuário). Se os usuários desse tipo de Rollup quiserem atingir um estado de confiança mínima (mais próximo de Trustless), deverão executar pelo menos um nó DA-Layer light e um nó rollup full.

Variante 2: Rollup pessimista usando um Agregador Compartilhado

Vamos discutir a agregação pessimista usando agregadores compartilhados. Essa ideia foi proposta por Evan Forbes em sua publicação no fórum sobre o design de sequenciadores compartilhados. A principal premissa é que um sequenciador compartilhado é a única maneira formal de sequenciar transações. Evan explica os benefícios dos sequenciadores compartilhados da seguinte forma:

"Para desbloquear uma experiência de usuário equivalente à web2, os sequenciadores compartilhados [...] podem fornecer compromissos rápidos e flexíveis (observação: não é uma garantia muito confiável). Esses compromissos flexíveis fornecem alguma promessa arbitrária da ordem final das transações (ou seja, prometem que a ordem das transações não será alterada) e podem ser usados para criar versões atualizadas prematuramente do estado (mas a finalização ainda não foi concluída nesse momento).

Assim que os dados do bloco forem confirmados como publicados na camada de base (s/b referindo-se a DAlayer), o estado poderá ser considerado final."

Como ainda somos um rollup pessimista, só temos nós completos de rollup e nenhum nó leve. Cada nó precisa executar todas as transações para garantir a validade. Não há nós de luz nesse sistema, portanto, não há necessidade de um cabeçalho de rollup, também conhecido como produtor de cabeçalho. (Observação: de modo geral, um nó leve de uma blockchain não precisa sincronizar blocos completos, mas apenas receber cabeçalhos de blocos)

Como não há etapa de produção de cabeçalho de rollup, o sequenciador compartilhado de rollup mencionado acima não precisa executar transações para atualizações de status (um pré-requisito para a produção de cabeçalho), mas inclui apenas o processo de agregação de dados de transação. Por isso, prefiro chamá-lo de agregador compartilhado.

Nessa variante, os usuários do Rollup precisam executar pelo menos o seguinte em um estado de confiança minimizada:

Nó de luz da camada DA + nó de luz da rede agregadora compartilhada + nó completo de rollup.

Nesse momento, é necessário verificar o cabeçalho do agregador publicado (não referente ao cabeçalho de rollup) por meio do light node da rede de agregadores compartilhados. Conforme mencionado acima, o agregador compartilhado realiza a tarefa de classificação de transações. No cabeçalho do agregador publicado, ele contém um compromisso criptográfico, correspondente ao lote que publicou na camada DA.

Dessa forma, o operador do nó de rollup pode confirmar que o lote recebido da camada DA foi criado pelo agregador compartilhado e não por outros.

(Como o conteúdo contido acima é relativamente obscuro, o senhor pode ler o diagrama novamente)

A inclusão é o processo pelo qual uma transação é aceita no blockchain.

Ordenação é o processo de organizar as transações em uma sequência específica no blockchain.

A execução é o processo pelo qual as transações na blockchain são processadas e seus efeitos são aplicados ao estado da blockchain.

Como o agregador compartilhado controla a inclusão e a ordenação, herdamos sua resistência à censura.

Se presumirmos que L_ss é a vivacidade do agregador compartilhado e L_da é a vivacidade da camada DA, então a vivacidade desse esquema é L = L_da && L_ss. Em outras palavras, se um dos sistemas tiver uma falha de vivacidade, o rollup também terá uma falha de vivacidade.

Para simplificar, usarei a vivacidade como um booleano. Se o agregador compartilhado falhar, não poderemos prosseguir com o rollup. Se a camada DA falhar, poderemos continuar com os compromissos flexíveis do agregador compartilhado. Ainda assim, estaríamos contando com o consenso e a disponibilidade de dados do agregador compartilhado, o que seria pior do que a camada DA original.

Vamos continuar a explorar a resistência à censura da solução Rollup acima:

Nesse esquema, a camada DA não pode censurar transações específicas. (Observação: a revisão de transações muitas vezes pode se recusar a permitir que determinadas transações sejam carregadas na cadeia). Ele só pode censurar lotes inteiros de rollups que o agregador compartilhado já agregou. (rejeitando um lote a ser incluído na camada DA).

No entanto, de acordo com o fluxo de trabalho do Rollup, quando o agregador de compartilhamento envia o lote de transações para a camada DA, ele já concluiu o sequenciamento da transação e a ordem entre os diferentes lotes também foi determinada. Portanto, esse tipo de revisão de transação pela camada DA não tem outro efeito a não ser atrasar a finalização do livro-razão do Rollup.

Em resumo, acredito que o foco 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 da disponibilidade do sistema, mesmo na presença de interrupções na rede e ações adversárias. Embora isso entre em conflito com a definição acadêmica dominante atual, ainda assim usarei a definição do conceito que apresentei.

Variante 3: Rollup pessimista com agregação baseada e compartilhada

Embora a comunidade desfrute dos benefícios de um agregador compartilhado, queremos evitar depender dele e ter uma alternativa para a camada DA. Combinaremos os pedidos e permitiremos que os usuários enviem transações diretamente para a camada DA. Ele combina a agregação baseada e compartilhada.

Presumimos que a ordenação final será interpretada como todas as transações ordenadas pelo agregador compartilhado e, em seguida, todas as transações baseadas depois disso por bloco da camada DA. Chamamos isso de regra de escolha de garfo de rollups.

A agregação é um processo de duas etapas aqui. Primeiro, o agregador compartilhado assume a liderança, agregando algumas transações. Em seguida, a camada DA agrega os lotes e as transações já encomendados que o usuário enviou diretamente.

A análise da resistência à censura agora é mais complexa. O nó de rede da camada DA pode 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, o nó da camada DA pode extrair o valor MEV, iniciar uma transação de front-running com sua conta na rede Rollup e incluí-la no bloco da camada DA antes de incluir o lote enviado pelo agregador compartilhado do Rollup.

Aparentemente, a finalidade da ordem de transação garantida pelo compromisso flexível do terceiro tipo de variante de Rollup é mais frágil do que a do segundo tipo de variante de Rollup mencionada acima. Nesse caso, o agregador compartilhado entrega o valor MEV ao nó da camada DA. Com relação a isso, sugiro que os leitores assistam à palestra sobre a censura lucrativa do MEV.

No momento, surgiram algumas soluções de design para reduzir a capacidade dos nós de rede da camada DA de executar essas transações MEV, como a função "período de janela de reorganização", que atrasará as transações enviadas diretamente pelos usuários da rede Rollup para a camada DA. A Sovereign Labs detalhou isso em sua proposta de design denominada Based Sequencing with Soft Confirmations (Sequenciamento Baseado com Confirmações Suaves), em que é proposto o conceito de "sequenciador preferencial".

Como o MEV depende do esquema de agregador que o senhor escolher e da regra de escolha de bifurcação do rollup, alguns não vazarão nada e outros vazarão parte ou todo o MEV para a camada DA, mas esse é um assunto para outro dia.

Quanto à vivacidade, esse design de rollup tem uma vantagem sobre o simples fato de ter um agregador compartilhado. Se o agregador compartilhado tiver uma falha de vivacidade, o usuário ainda poderá enviar transações para a camada DA.

Por fim, vamos falar sobre a menor configuração de confiança minimizada: um light node de camada DA + light node de agregador compartilhado + full node de rollup.

Neste momento, ainda precisamos validar os cabeçalhos do agregador compartilhado para que nosso nó completo de rollup possa diferenciar os lotes de transações para sua regra de escolha de bifurcação.

Variante 4: Rollup otimista com base em um produtor de cabeçalho centralizado

Vamos começar a preparar alguns nós leves usando uma variante chamada rollup otimista baseado com um produtor de cabeçalho centralizado. Esse projeto usa a camada DA para agregar transações, mas introduzimos um produtor de cabeçalho centralizado para permitir nós leves de rollup.

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

Não entrarei em detalhes sobre como funcionam as provas de fraude de rodada única, pois isso fugiria ao escopo deste artigo. A vantagem aqui é que o senhor pode reduzir o tempo da janela de comprovação de fraude de 7 dias para um valor ainda a ser determinado, mas magnitudes menores. Os nós leves podem receber provas de fraude por meio da camada p2p sem precisar esperar por uma disputa, pois tudo é capturado em uma única prova.

Usamos a camada DA como agregador, herdando sua resistência à censura. Ele faz a inclusão e o pedido. O produtor de cabeçalho centralizado lerá a ordem canônica da camada DA e será capaz de construir um cabeçalho válido a partir dela. O produtor de cabeçalho centralizado postará as raízes do cabeçalho e do estado na camada DA. Essas raízes estatais são essenciais para criar uma prova de fraude contra esse compromisso. O agregador faz a inclusão e a ordenação, enquanto o produtor de cabeçalho faz a execução.

Supõe-se que a camada DA (que também atua como agregador do Rollup no momento) seja suficientemente descentralizada e tenha boa resistência à censura. Além disso, o produtor de cabeçalho não pode alterar a sequência de transações de rollup publicada pelo agregador. Agora, se o produtor do cabeçalho for descentralizado, o único benefício será uma melhor vivacidade, mas as outras propriedades do Rollup são as mesmas da primeira variante, o Based Rollup.

Se o produtor de cabeçalho tiver uma falha de vivacidade, o rollup também terá uma falha de vivacidade. O nó leve não poderá seguir a cadeia, enquanto os nós completos ainda poderão seguir a cadeia se for desejável, voltando a um rollup pessimista baseado, conforme descrito na variante 1. Obviamente, a configuração mínima para a minimização da confiança descrita na variante 4 é:

Nó de luz DA-Layer + nó de luz Rollup.

Variante 5: ZK-Rollup baseado em um mercado de provadores descentralizado

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

A esta altura, o senhor já deve estar familiarizado com o que faz um rollup baseado. A variante 5 delega a função de agregador aos nós da camada DA, que realizam o trabalho de inclusão e ordenação. Vou citar o documento da Sovereign-Labs, que faz um trabalho incrível ao explicar o ciclo de vida de seu projeto. Vou adaptá-lo um pouco para que ele se encaixe na variante 5.

Os usuários publicam um novo bloco de dados na cadeia L1. Assim que o blob é finalizado em L1, ele é logicamente final. Imediatamente após a finalização do bloco L1, os nós completos do rollup o examinam e processam todos os blobs de dados relevantes na ordem em que aparecem, gerando uma nova raiz de estado de rollup. Nesse ponto, o bloco é subjetivamente finalizado da perspectiva de todos os nós completos.

Nosso produtor de cabeçalho nesse projeto é o mercado descentralizado de provadores.

Os nós do provador (nós completos executados dentro de um ZKVM) executam praticamente o mesmo processo que os nós completos - examinando o bloco DA e processando todos os lotes em ordem - produzindo provas e postando-as na cadeia. (As provas precisam ser postadas na cadeia se o rollup quiser incentivar os provadores - caso contrário, é impossível dizer qual provador foi o primeiro a processar um determinado lote). Uma vez que uma prova para um determinado lote tenha sido postada na cadeia, o lote é subjetivamente final para todos os nós, incluindo os nós leves.

(Como há muitos conceitos envolvidos, o senhor pode examinar o diagrama esquemático novamente)

A variante 5 tem a mesma resistência à censura que a camada DA. O mercado descentralizado de provadores não pode censurar transações porque a camada DA determina a ordem canônica. Descentralizamos o produtor de cabeçalho apenas para melhorar a agilidade e criar um mercado de incentivos. A vivacidade aqui é L = L_da && L_pm (mercado do provador). Se os incentivos do mercado de provadores estiverem desalinhados, ou se houver uma falha de vivacidade, os nós leves não poderão seguir a cadeia, mas os nós completos de rollup ainda poderão seguir a cadeia, se desejável, voltando a um rollup pessimista baseado. A menor configuração de confiança minimizada está aqui, assim como no caso otimista, com um nó de luz da camada DA + um nó de luz de rollup.

Variante 6 : Rollup híbrido baseado em um produtor de cabeçalho otimista centralizado e um provador descentralizado

Ainda deixamos que os nós da camada DA atuem como agregadores para o Rollup e os delegamos para lidar com a inclusão e a classificação das transações.

Como o senhor pode ver na figura abaixo, tanto o ZK Rollup quanto o Optimistic Rollup usam os mesmos lotes de transações ordenadas na camada DA como a fonte do ledger de rollup. É por isso que podemos usar dois sistemas de prova ao mesmo tempo: os lotes de transações ordenadas na camada DA não são afetados pelo próprio sistema de prova.

Vamos falar sobre a finalidade. Do ponto de vista de um nó completo de rollup, o rollup é final quando a camada DA é final, pois só precisa executar as transações para essa variante. Mas nos preocupamos mais com a finalidade do nó de luz. Vamos supor que o produtor de cabeçalho centralizado faça alguma aposta, assine um cabeçalho e publique as raízes do estado calculado na camada DA.

Assim como na variante 4 anterior, os nós leves confiarão de forma otimista na execução e aguardarão uma prova de fraude de um nó completo honesto que mostre que o produtor do cabeçalho cometeu fraude. Após o término da janela de prova de fraude, o bloco de rollup é final a partir da perspectiva de um nó de luz de rollup.

O ponto principal é que, se conseguirmos obter uma prova ZK, não precisaremos mais esperar que a janela de prova de fraude termine. Além das provas de fraude de rodada única, podemos substituir as provas de fraude por provas ZK e descartar qualquer cabeçalho malicioso que tenha sido gerado pelo produtor de cabeçalho otimista!

Quando o light node receber o certificado ZK correspondente a um determinado lote de transação de rollup, o lote será finalizado.

Agora temos um compromisso rápido e suave e uma finalidade rápida.

A variante 6 ainda tem a mesma resistência à censura que a camada DA, pois é baseada nela. Para a vivacidade, teremos L = L_da && (L_op || L_pm ), o que significa que aumentamos nossa garantia de vivacidade. Se o produtor de cabeçalho centralizado ou o mercado de provadores tiver uma falha de vivacidade, podemos voltar ao outro esquema.

A menor configuração de confiança minimizada é um light node de camada DA + um light node de rollup.

Resumo:

1. Dividimos o sequenciador em duas entidades lógicas: o agregador e o produtor de cabeçalho

2. Dividimos o sequenciador em três processos lógicos: inclusão, ordenação e execução.

3. Os rollups pessimistas e os rollups baseados são uma coisa

4. Dependendo de suas necessidades, o senhor pode conectar agregadores e produtores de cabeçalho.

5. Cada variante de Rollup deste artigo seguiu esse padrão de design:
   

Por fim, tenho algumas reflexões. Por favor, pense sobre isso:

• Como os rollups clássicos se encaixam nisso? (referindo-se ao Rollup da Ethereum)
• Em todas as variantes, só fizemos o agregador fazer a inclusão + ordenação e a execução do produtor de cabeçalho. E se o agregador fizer apenas a inclusão e o produtor de cabeçalho fizer o pedido e a execução? Pense em leilões na cadeia. Podemos separar os três?
• O que é um mercado compartilhado de produtor de cabeçalho/produtor de cabeçalho?
• Quem recebe o MEV? E podemos recuperá-lo?

Isenção de responsabilidade：

1. Este artigo foi reimpresso de[Geek Web3], Encaminhar o título original'Celestia researcher analyzes 6 Rollup variants: Sequencer = aggregator + Header generator',Todos os direitos autorais pertencem ao autor original[NashQ, Celestia Researcher]. Se houver alguma objeção a essa reimpressão, entre em contato com a equipe do Gate Learn, que tratará do assunto imediatamente.
2. Isenção de responsabilidade: Os pontos de vista e opiniões expressos neste artigo são de responsabilidade exclusiva do autor e não constituem consultoria de investimento.
3. As traduções do artigo para outros idiomas são feitas pela equipe do Gate Learn. A menos que mencionado, é proibido copiar, distribuir ou plagiar os artigos traduzidos.