Sequências = Agregador + Produtor de cabeçalhos

• Título original enviado: Investigador do Celestia analisa 6 variantes de Rollup: Sequenciador=agregador+gerador de cabeçalhos

Nota: Para facilitar a compreensão e análise do modelo de Rollup, o investigador da Celestia, NashQ, dividiu o Sequenciador de Rollup em duas entidades lógicas - o Agregador e o Produtor de Cabeçalhos. Ao mesmo tempo, dividiu o processo de ordenação das transacções em três etapas lógicas: inclusão, ordenação e execução.

Guiados por este pensamento analítico, as seis grandes variantes do Sovereign Rollup são mais claras e mais fáceis de compreender. A NashQ discutiu em pormenor a resistência à censura e a vivacidade das 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 que tipos de nós os utilizadores do Rollup precisam de executar).

Embora este artigo analise o Rollup a partir da perspetiva 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, este artigo também é extremamente útil para os entusiastas do Ethereum.

O que é um Rollup?

Os rollups são blockchains que publicam os seus dados de transação noutra blockchain e herdam o seu consenso e disponibilidade de dados.

Porque é que estou a mudar "bloco" para "dados de transação"? Deixe-me explicar-lhe a diferença entre um bloco de rollup e os dados de rollup e mostrar-lhe que o rollup mínimo só precisa de dados de rollup com a nossa primeira variante.

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

Variante 1 : Rollup pessimista baseado

A forma mais simples de construir um rollup começa com um utilizador a lançar transacções noutra blockchain. Chamaremos a esta cadeia de blocos a camada de consenso e disponibilidade de dados, mas abreviá-la-ei para camada DA em todos os diagramas seguintes. (Nota: semelhante ao Layer1 frequentemente referido na comunidade Ethereum).

Na nossa primeira variante, cada nó de rollup deve reproduzir todas as transacções na cadeia de blocos para verificar o estado mais recente. Acabámos de criar um Rollup pessimista!

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

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

Para facilitar a discussão, dividimos o sequenciador em duas entidades lógicas: o agregador e o produtor de cabeçalhos diferenciam-no. Uma entidade deve ter conhecimento do estado (ou seja, deve executar o estado para computar o cabeçalho), mas o agregador não precisa de compreender o estado para o poder agregar.

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

A agregação é o processo de agrupar transacções num único lote. Um lote de transacções é composto por uma ou mais transacções. (Nota: Lote é a parte dos dados no bloco de Rollup exceto o Cabeçalho).

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

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

Através da perspetiva acima, podemos ver quem desempenha o papel de cada componente do Rollup. Vejamos primeiro a parte do agregador. O rollup pessimista mencionado anteriormente não tem um processo de produção de cabeçalhos e os utilizadores publicam transacções diretamente na camada DA, o que significa que a rede da camada DA funciona essencialmente como um agregador.

Um Rollup Pessimista é uma variante do Rollup que delega a etapa de agregação na camada DA. Não dispõe de um sequenciador. Por vezes, este tipo de rollup é designado por "rollup com base".

O Rollup baseado tem a mesma resistência à censura e a mesma vivacidade que a camada DA (a atividade mede a velocidade de resposta do sistema aos pedidos dos utilizadores). Se os utilizadores deste tipo de Rollup quiserem atingir um estado de confiança mínima (mais próximo de Trustless), devem executar pelo menos um nó DA-Layer light e um nó rollup full.

Variante 2: Rollup pessimista usando um agregador partilhado

Vamos discutir a agregação pessimista utilizando agregadores partilhados. Esta ideia foi proposta por Evan Forbes no seu post no fórum sobre o design de sequenciadores partilhados. O pressuposto principal é que um sequenciador partilhado é a única forma formal de sequenciar transacções. Evan explica os benefícios dos sequenciadores partilhados desta forma:

"Para desbloquear uma experiência de utilizador equivalente à da Web2, os sequenciadores partilhados [...] podem fornecer compromissos rápidos e flexíveis (nota: não é uma garantia muito fiável). Estes compromissos flexíveis fornecem uma promessa arbitrária da ordem final das transacções (ou seja, prometem que a ordem das transacções não será alterada) e podem ser utilizados para criar versões prematuramente actualizadas do estado (mas a finalização ainda não foi concluída neste momento).

Logo que se confirme que os dados do bloco estão registados na camada de base (s/b referente a DAlayer), o estado pode ser considerado definitivo.

Como ainda somos um rollup pessimista, só temos nós completos de rollup e nenhum nó leve. Cada nó tem de executar todas as transacções para garantir a validade. Não existem nós de luz neste sistema, pelo que não há necessidade de um cabeçalho de enrolamento, também conhecido como produtor de cabeçalho. (Nota: De um modo geral, um nó ligeiro de uma cadeia de blocos não necessita de sincronizar blocos completos, mas apenas recebe cabeçalhos de blocos)

Como não existe uma etapa de produção de cabeçalho de rollup, o sequenciador partilhado de rollup acima mencionado não precisa de executar transacções para actualizações de estado (um pré-requisito para a produção de cabeçalho), mas apenas inclui o processo de agregação de dados de transação. Por isso, prefiro chamar-lhe um agregador partilhado.

Nesta 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 partilhada + nó completo de rollup.

Nesta altura, é necessário verificar o cabeçalho do agregador publicado (não referente ao cabeçalho de rollup) através do nó de luz da rede de agregadores partilhados. Como já foi referido, o agregador partilhado assume a tarefa de ordenação das transacções. No cabeçalho do agregador publicado, contém um compromisso criptográfico, correspondente ao lote que publicou na camada DA.

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

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

A inclusão é o processo pelo qual uma transação é aceite na cadeia de blocos.

A ordenação é o processo de organizar as transacções numa sequência específica na cadeia de blocos.

A execução é o processo pelo qual as transacções na cadeia de blocos são processadas e os seus efeitos são aplicados ao estado da cadeia de blocos.

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

Se assumirmos que L_ss é a vivacidade do agregador partilhado e L_da é a vivacidade da camada DA, então a vivacidade deste esquema é L = L_da && L_ss. Por outras palavras, se um dos sistemas tiver uma falha de vivacidade, o rollup também tem uma falha de vivacidade.

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

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

Neste esquema, a camada DA não pode censurar transacções específicas. (Nota: A revisão das transacções pode muitas vezes recusar-se a permitir que certas transacções sejam carregadas na cadeia). Só pode censurar lotes completos de rollup que o agregador partilhado já tenha agregado. (rejeitando um lote para ser incluído na camada DA).

No entanto, de acordo com o fluxo de trabalho do Rollup, quando o agregador de partilha submete o lote de transacções à camada DA, já completou a sequenciação das transacções e a ordem entre os diferentes lotes também foi determinada. Por conseguinte, este tipo de revisão da transação pela camada DA não tem outro efeito senão atrasar a finalidade do livro-razão do Rollup.

Resumindo, creio que o objetivo da resistência à censura é garantir que nenhuma entidade possa controlar ou manipular o fluxo de informação dentro do sistema, enquanto a vivacidade envolve a manutenção da funcionalidade e da disponibilidade do sistema, mesmo na presença de falhas na rede e de acções adversas. Embora isto entre em conflito com a atual definição académica dominante, continuarei a utilizar a definição do conceito que enunciei.

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

Embora a comunidade usufrua dos benefícios de um agregador partilhado, queremos evitar depender dele e queremos ter um recurso à camada DA. Combinaremos as encomendas e permitiremos que os utilizadores submetam transacções diretamente à camada DA. Combina a agregação baseada e partilhada.

Partimos do princípio de que a ordenação final será interpretada como todas as transacções ordenadas pelo agregador partilhado e, em seguida, todas as transacções baseadas em cada bloco da camada DA. Chamamos-lhe a regra de escolha do garfo de rollups.

A agregação é um processo em duas etapas. Primeiro, o agregador partilhado assume a liderança, agregando algumas transacções. Em seguida, a camada DA agrega os lotes já encomendados e as transacções que o utilizador submeteu diretamente.

Atualmente, a análise da resistência à censura é mais complexa. O nó de rede da camada DA pode rever o lote apresentado pelo agregador partilhado antes de ser produzido o bloco seguinte da camada DA. Depois de conhecer os dados da transação no lote, o nó DA-Layer pode extrair o valor MEV, iniciar uma transação de front-running com a sua conta na rede Rollup e incluí-la no bloco DA-Layer antes de incluir o lote submetido pelo agregador partilhado Rollup.

Aparentemente, o carácter definitivo da ordem de transação garantido pelo compromisso flexível do terceiro tipo de variante de rollup é mais frágil do que o do segundo tipo de variante de rollup acima referido. Neste caso, o agregador partilhado entrega o valor MEV ao nó da camada DA. A este respeito, sugiro aos leitores que assistam à palestra sobre a censura lucrativa do MEV.

Atualmente, surgiram algumas soluções de conceção para reduzir a capacidade dos nós da rede da camada DA para executar essas transacções MEV, como a função "período de janela de reorganização", que atrasará as transacções apresentadas diretamente pelos utilizadores da rede Rollup à camada DA. A Sovereign Labs descreveu isto em pormenor na sua proposta de conceção designada Sequenciação baseada com confirmações suaves, onde é proposto o conceito de "sequenciador preferencial".

Uma vez que o MEV depende do esquema de agregação que escolher e da regra de escolha de bifurcação do rollup, alguns não libertarão nenhum MEV e outros libertarão algum ou todo o MEV para a camada DA, mas isso é assunto para outro dia.

Quanto à vivacidade, esta conceção de rollup tem uma vantagem sobre o simples facto de ter um agregador partilhado. Se o agregador partilhado tiver uma falha de vivacidade, o utilizador ainda pode submeter transacções à camada DA.

Finalmente, vamos falar sobre a configuração mais pequena de confiança minimizada: um nó de luz DA-Layer + nó de luz agregador partilhado + nó completo de rollup.

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

Variante 4: Rollup otimista baseado com um produtor de cabeçalhos centralizado

Vamos começar a cozinhar alguns nós leves usando uma variante chamada rollup otimista baseado com um produtor de cabeçalho centralizado. Esta conceção utiliza a camada DA para agregar transacções, mas introduzimos um produtor de cabeçalhos centralizado para permitir nós leves de rollup.

Os nós Rollup light podem verificar indiretamente a validade das transacções Rollup através de uma única ronda de prova de fraude. O nó de luz terá uma atitude otimista em relação ao gerador do cabeçalho de rollup e fará uma confirmação final após o fim do período da janela de prova de fraude. Outra possibilidade é que receba uma prova de fraude de um nó completo honesto, sabendo que o gerador de cabeçalhos submeteu dados incorrectos.

Não vou entrar em pormenores sobre o funcionamento das provas de fraude de ronda única, uma vez que isso iria ultrapassar o âmbito deste artigo. A vantagem aqui é que pode reduzir o tempo de janela de prova de fraude de 7 dias para um valor, que ainda está por determinar, mas magnitudes menores. Os nós de luz podem receber provas de fraude através da camada p2p sem necessidade de esperar por uma disputa, uma vez que tudo é capturado numa única prova.

Utilizamos a camada DA como agregador, herdando a sua resistência à censura. Efectua a inclusão e a encomenda. O produtor de cabeçalhos centralizado lerá a ordem canónica da camada DA e será capaz de construir um cabeçalho válido a partir daí. O produtor de cabeçalhos centralizado enviará as raízes do cabeçalho e do estado para a camada DA. Estas raízes estatais são essenciais para criar uma prova de fraude contra este compromisso. O agregador faz a inclusão e a ordenação, enquanto o produtor de cabeçalhos faz a execução.

Assume-se que a camada DA (que também actua como agregador do Rollup neste momento) é suficientemente descentralizada e tem boa resistência à censura. Além disso, o produtor de cabeçalhos não pode modificar a sequência de transacções de rollup publicada pelo agregador. Agora, se o produtor do cabeçalho for descentralizado, o único benefício é uma melhor vivacidade, mas as outras propriedades do Rollup são as mesmas da primeira variante, o Rollup baseado.

Se o produtor de cabeçalhos tiver uma falha de vivacidade, o rollup também tem uma falha de vivacidade. O nó leve não poderá seguir a cadeia, enquanto os nós completos poderão ainda seguir a cadeia se for desejável, recorrendo a um rollup pessimista baseado como 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: Baseado no ZK-Rollup com um mercado de provadores descentralizado

Já discutimos o Rollup Pessimista (Rollup Baseado) e o Rollup Otimista, agora é altura de considerar o ZK-Rollup. Recentemente, Toghrul fez uma apresentação sobre a separação entre o agregador (Sequencer) e o produtor de cabeçalhos (Prover) (Sequencer-Prover Separation in Zero-Knowledge Rollups). Neste modelo, a publicação de transacções como dados de Rollup em vez de State Diff é mais fácil de tratar, pelo que me concentrarei nos primeiros. A variante 5 é um zk-rollup baseado num mercado de provadores descentralizado.

Neste momento, já deve estar familiarizado com o que faz um rollup baseado. A variante 5 delega o papel de agregador nos nós da camada DA, que efectuam o trabalho de inclusão e ordenação. Vou citar o documento da Sovereign-Labs que faz um trabalho fantástico ao explicar o ciclo de vida da sua conceção. Irei adaptá-lo ligeiramente para que se adapte à variante 5.

Os utilizadores colocam um novo bloco de dados na cadeia L1. Assim que a bolha é finalizada em L1, ela é logicamente final. Imediatamente após a finalização do bloco L1, os nós completos do rollup percorrem-no e processam todos os blobs de dados relevantes pela ordem em que aparecem, gerando uma nova raiz de estado do rollup. Neste ponto, o bloco é subjetivamente finalizado na perspetiva de todos os nós completos.

O nosso produtor de cabeçalho nesta conceção é o mercado descentralizado de provadores.

Os nós Prover (nós completos que correm dentro de uma ZKVM) executam aproximadamente o mesmo processo que os nós completos - percorrendo o bloco DA e processando todos os lotes por ordem - produzindo provas e colocando-as na cadeia. (As provas precisam de ser colocadas na cadeia se o rollup quiser incentivar os provadores - caso contrário, é impossível dizer qual foi o primeiro provador a processar um determinado lote). Assim que uma prova para um determinado lote tiver sido colocada na cadeia, o lote é subjetivamente final para todos os nós, incluindo os nós ligeiros.

(Como há muitos conceitos envolvidos, pode voltar a ver o diagrama esquemático)

A variante 5 tem a mesma resistência à censura que a DA-Layer. O mercado descentralizado de provadores não pode censurar as transacções porque a camada DA determina a ordem canónica. Descentralizámos o produtor de cabeçalhos apenas para melhorar a vivacidade e para criar um mercado de incentivos. A vivacidade aqui é L = L_da && L_pm (mercado do provador). Se os incentivos do mercado do provador estiverem desalinhados, ou se tiver uma falha de vivacidade, os nós ligeiros não poderão seguir a cadeia, mas os nós completos do rollup poderão ainda seguir a cadeia, se tal for desejável, voltando a um rollup pessimista baseado. A configuração de confiança minimizada mais pequena está aqui, tal como no caso otimista com um nó de luz DA-Layer + um nó de luz rollup.

Variante 6 : Rollup híbrido baseado num produtor de cabeçalhos otimista centralizado e num provador descentralizado

Continuamos a permitir que os nós da camada DA actuem como agregadores para o Rollup e delegamos-lhes a responsabilidade de tratar da inclusão e ordenação das transacções.

Como se pode ver na figura abaixo, tanto o Rollup ZK como o Rollup Otimista utilizam os mesmos lotes de transacções ordenadas na camada DA como fonte do ledger de rollup. É por isso que podemos utilizar dois sistemas de prova ao mesmo tempo: os lotes de transacções ordenadas na camada DA não são afectados pelo próprio sistema de prova.

Falemos de finalidade. Do ponto de vista de um nó completo de rollup, o rollup é final quando a camada DA é final, uma vez que só precisa de executar as transacções para esta variante. Mas o que nos interessa mais é o carácter definitivo do nó de luz. Vamos supor que o produtor centralizado de cabeçalhos faz uma aposta, assina um cabeçalho e envia as raízes do estado calculado para a camada DA.

Tal como na variante 4 anterior, os nós leves confiam optimisticamente na execução e aguardam uma prova de fraude de um nó completo honesto que mostre que o produtor do cabeçalho cometeu fraude. Após a janela de prova de fraude ter terminado, o bloco de rollup é final na perspetiva de um nó de luz de rollup.

O ponto-chave é que, se conseguirmos obter uma prova ZK, já não temos de esperar que a janela de prova de fraude termine. Para além das provas de fraude de ronda única, podemos substituir as provas de fraude por provas ZK e rejeitar qualquer cabeçalho malicioso que tenha sido gerado pelo produtor otimista de cabeçalhos!

Quando o nó de luz recebe o certificado ZK correspondente a um determinado lote de transacções de rollup, o lote é finalizado.

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

A variante 6 continua a ter a mesma resistência à censura que a camada DA, na qual se baseia. Para a vivacidade, teremos L = L_da && (L_op || L_pm ), o que significa que aumentámos a nossa garantia de vivacidade. Se o produtor centralizado de cabeçalhos ou o mercado de provadores tiverem uma falha de vivacidade, podemos recorrer ao outro esquema.

A configuração de confiança minimizada mais pequena é um nó de luz DA-Layer + um nó de luz rollup.

Resumo:

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

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 das suas necessidades, pode ligar agregadores e produtores de cabeçalhos.

5. Cada variante de Rollup neste artigo seguiu este padrão de design:
   

Por fim, tenho algumas reflexões. Pense nisso:

• Como é que os rollups clássicos se enquadram nisto? (referindo-se ao Ethereum Rollup)
• Em todas as variantes, apenas fizemos com que o agregador fizesse a inclusão + ordenação e o produtor de cabeçalhos a execução. E se o agregador só fizer a inclusão e o produtor de cabeçalhos fizer a encomenda e a execução? Pense nos leilões na cadeia. Poderíamos separar os três?
• O que é um mercado partilhado de produtores de cabeças de gado/produtores de cabeças de gado?
• Quem recebe o MEV? E podemos recuperá-lo?

Declaração de exoneração de responsabilidade：

1. Este artigo foi reimpresso a partir de[Geek Web3], Encaminhar o título original'Celestia researcher analyzes 6 Rollup variants: Sequencer = aggregator + Header generator',Todos os direitos de autor pertencem ao autor original[NashQ, Celestia Researcher]. Se houver objecções a esta reimpressão, contacte a equipa da Gate Learn, que tratará prontamente do assunto.
2. Declaração de exoneração de responsabilidade: Os pontos de vista e opiniões expressos neste artigo são da exclusiva responsabilidade do autor e não constituem um conselho de investimento.
3. As traduções do artigo para outras línguas são efectuadas pela equipa Gate Learn. A menos que seja mencionado, é proibido copiar, distribuir ou plagiar os artigos traduzidos.