Celestia Researcher: Interpretação de 4 Novos Esquemas de Rollup

Autor Original: NashQ, Celestia

Compilação: Link, "Geek web3"

Introdução: Este artigo é composto pelos discursos dispersos do pesquisador da Celestia, NashQ, sobre a análise do modelo Rollup, incluindo 4 novas variantes do Rollup. Anteriormente, no artigo "Análise de Rollup sob a perspectiva de Celestia: resistência à censura e atividade de 6 variantes", ele listou 6 modelos Rollup diferentes, e este artigo é baseado em seu modelo Rollup de 4 categorias recentemente abstraído.

Anteriormente, o NashQ dividia o Sequencer em dois módulos: agregador + Header Producer. A partir do ciclo de vida das instruções de transação, explicava o princípio de operação do Rollup soberano da Celestia, discutia a anticensura e a atividade de diferentes variantes do Rollup e a experiência do usuário A configuração mínima sob a premissa de minimizar a confiança (ou seja, para obter Trustless, quais tipos de nós Rollup os usuários devem executar pelo menos).

Variante 7: Rollup baseado + Produtores de vários cabeçalhos + "MEV de protocolo mais alto"

Nesta variante Rollup, os usuários da rede Rollup publicam diretamente os dados da transação nos blocos da camada DA e, em seguida, o Header Producer é responsável pela classificação da transação e o MEV é extraído por ele. Obviamente, o processo de agregação/inclusão de transações do Rollup Variante 7 é o mesmo do Based Rollup introduzido anteriormente, que é de responsabilidade da camada DA (os usuários enviam transações diretamente para a camada DA), mas a ordem das transações é diferente da Baseada Rollup e os nós da camada DA não são responsáveis A classificação é de responsabilidade do HP (Header Producer).

O seguinte assume que existem três HPs que competem entre si e obedecem ao protocolo de alocação de MEV denominado "protocolo mais alto MEV". Este protocolo foi proposto pelo Skip Protocol do ecossistema Cosmos. Ao contrário do esquema Ethereum PBS, o Block Builder precisa pagar uma "gorjeta" adicional ao Validador da rede blockchain, e o bloco construído pelo Builder com mais dicas será ser adotado pelos Validadores. Ao mesmo tempo, o protocolo SKIP propôs o conceito de "MEV soberano", com a intenção de permitir que todos os validadores e comunidades na rede pública de cadeia tenham autonomia para alocar MEV e resolver o problema que os construtores em Ethereum PBS estão se tornando cada vez mais mais centralizado devido ao efeito flywheel (mas este não é o cerne deste artigo).

Na variante Rollup apresentada neste artigo, diferentes Header Producers precisam declarar o valor da gorjeta no Batch Header criado por eles mesmos, sendo que o Batch Header emitido pelo HP que mais paga gorjetas é aceito automaticamente pelos nós Rollup (através do ledger escrito no código do nó O algoritmo de seleção de bifurcação é feito automaticamente).

Além disso, o Batch Header liberado pela HP deve ser capaz de corresponder ao Batch completo da transação na camada DA.

Se houver um erro no cabeçalho emitido pela HP, por exemplo, o Stateroot do resultado da execução da transação está incorreto ou uma transação no lote não está incluída (transação perdida), o nó completo do Rollup honesto transmitirá a prova de fraude para o nó leve . Mas geralmente (otimisticamente), os light nodes podem aceitar o Header emitido pela HP e acreditar que não há problema com ele.

Análise de resistência à censura: Existem 2 pontos neste Rollup que podem conduzir a revisão da transação. A primeira existe na camada DA, que pode censurar o conteúdo da transação e rejeitar transações envolvendo determinados usuários. O segundo lugar ainda existe na camada DA, que pode revisar o cabeçalho enviado pela HP e se recusar a incluir um determinado cabeçalho, para que possa conspirar com o cabeçalho para monopolizar o MEV por meio de ataques de revisão.

Ao mesmo tempo, a HP é responsável pela ordenação das transações. Devido à existência de provas de fraude (pode ser direcionada para a situação em que a HP perde transações), a própria HP muitas vezes não lança ataques de censura, mas pode subornar os nós da camada DA para fazer isso (ou executar algumas camadas DA por si só) nó). A solução para isso é estender o período da janela para que a sequência de transações do Rollup seja finalizada, de forma que o Cabeçalho rejeitado pelos nós maliciosos da camada DA possa ser incluído na cadeia por nós honestos da camada DA antes do final do período da janela, aumentando assim a revisão do nó da camada DA A dificuldade do ataque.

**Atividade:**L = L_da && ( L_hp1 || L_hp2 || L_hp3 )

Se a camada DA tiver uma falha de atividade, o Rollup também terá uma falha de atividade. Com base nisso, o Rollup falhará na ativação somente quando todos os HPs falharem na ativação.

Variante 8: ZK Rollup do Agregador Compartilhado + Provedor Descentralizado

A variante 8 usa o agregador compartilhado Shared Aggregator (SA) para inclusão + classificação de transações. SA publica a sequência de transações Batch para a camada DA. Depois que a sequência de transações é enviada para a camada DA, a ordem das transações não será alterada teoricamente.

Antes que o Batch seja enviado para a camada DA, o agregador compartilhado SA pode primeiro transmitir o Batch+ SA Header para o full node e o Prover, e transmitir o SA Header para o light node, mas o Batch que não está na camada DA é ainda instável neste momento e pode ser bloqueado a qualquer momento. substitua.

Deve-se observar que o cabeçalho emitido pelo agregador compartilhado SA não é o mesmo que o cabeçalho do lote emitido pela HP. O SA Header contém provas criptográficas para garantir que o Lote lido pelo nó Rollup da camada DA seja realmente gerado pelo SA, não falsificado por outros.

O Provedor lê o batch da transação Batch da camada DA (ele também pode ser sincronizado diretamente com o agregador compartilhado), gera um ZK Proof+Batch Header e o publica na camada DA. Obviamente, Prover desempenhou o papel de HP.

Para os light nodes do Rollup, após o recebimento do ZKProof, a sequência de transações contida neste Batch é finalmente confirmada. Claro, o Prover também pode transmitir ZKP através da rede Rollup p2p sob a cadeia da camada DA, para que possa ser recebido por nós leves mais rapidamente, mas neste momento o ZKP não foi enviado para a camada DA e não tem " finalidade".

• **Resistência à censura: **Na variante 8, a camada DA não pode realizar ataques de censura em certas transações específicas, mas pode conduzir apenas ataques de revisão em todo o lote de transações enviadas pelo agregador compartilhado. Ao mesmo tempo, os agregadores compartilhados podem se recusar a empacotar as transações de certos usuários.
• **Atividade: **L = L_da && L_sa && L_pm. Nesta variante, se alguma peça apresentar falha de vivacidade, o Rollup terá falha de vivacidade. Se o Prover falhar, os light nodes não conseguirão sincronizar efetivamente o andamento do ledger Rollup. No entanto, como o nó completo sincroniza todos os lotes de sequência de transações, ele pode acompanhar o progresso do registro. Neste momento, todos os nós não serão afetados e todos os nós leves falharão, o que é equivalente à situação de Rollup Baseado usando um agregador compartilhado apresentado anteriormente.
• **Configuração mínima para minimização de confiança: **Light Node da camada DA + Light Node de rede do agregador compartilhado + Rollup Light Node

Variante 9: Agregador compartilhado + Provedor descentralizado + ZK-Rollup com vários DAs

A variante 9 é, na verdade, baseada na variante 8 acima, mas possui mais de uma camada DA, o que pode melhorar efetivamente a atividade do Rollup. Na Variante 9, o agregador compartilhado SA pode publicar a sequência de transações Batch em qualquer camada DA, e pode escolher diferentes camadas DA para publicar dados de acordo com suas próprias necessidades, para que possa otimizar dinamicamente os parâmetros relevantes do Rollup, como: custo de dados, segurança, vivacidade, latência da transação e finalidade.

De acordo com as necessidades da parte do projeto Rollup, o Rollup mais barato, mais seguro, mais ativo e de velocidade de liquidação pode ser personalizado, e a camada DA com a maior taxa de transferência pode ser selecionada. De um modo geral, os lotes de uma determinada altura de bloco Rollup (como o 10.000º) não precisam existir em diferentes camadas DA ao mesmo tempo, mas, se existirem, seus conteúdos devem ser consistentes. Se dois lotes com a mesma altura e conteúdo diferente aparecerem em diferentes camadas DA, isso significa que o agregador compartilhado bifurca intencionalmente o ledger.

Aqui, escolhemos o mesmo Prover Market descentralizado da Variant 8, onde o Prover atua como Header Producer e libera Batch Header e ZKProof. Neste ponto, o Provedor precisa competir por meio do mecanismo de leilão de gorjetas mencionado na Variante 7 (proposto pelo Protocolo SKIP).

A velocidade de liquidação da transação (velocidade de confirmação final) da Variante 9 é afetada pela camada DA com a geração de blocos mais rápida.

Resistência à censura: os agregadores compartilhados podem se envolver em ataques de censura, mas com mais camadas DA opcionais, a possibilidade de ataques de censura relacionados às camadas DA é reduzida.

**活性：**L = ( L_da1 || L_da2) && L_sa && L_pm。

A variante 9 foi mais ativa do que a variante anterior. Contanto que nem todas as redes da camada DA sofram falhas ao vivo, tudo funcionará bem.

Configuração mínima para minimização de confiança: nós leves de diferentes camadas DA + nós leves da rede agregadora compartilhada + nós leves de Rollup.

Obviamente, quanto mais camadas DA adotarmos, mais nós leves teremos que executar. Mas os benefícios de fazer isso podem superar os custos.

Variante 10: Dois ZK-Rollups+Provedor descentralizado, cada um com um nó leve na cadeia (pode ser ligado)

A Variante 10 é uma extensão da Variante 5 para criar 2 ZK-Rollups que podem ser uma ponte entre si. Comparada com a Variante 5 (Based Rollup+ZKP+Decentralized Prover), a Variante 10 tem uma função de retransmissor adicional, que agrupa Batch Header+ZK-Proof em uma transação. Desde que esta transação seja enviada para o nodo leve Rollup1 em execução no Rollup2, pode-se provar que uma certa altura de Batch é válida. Obviamente, o Rollup2 também requer nós leves executando a camada DA.

Este é um pré-requisito para manter a confiança entre as pontes da cadeia no mínimo. Mas se for cross-chain de Ethereum Rollup (Sci Rollup baseado em contrato inteligente) para Ethereum, não há necessidade de executar o nó leve da camada DA do Rollup, porque a camada DA é o próprio Ethereum. Isso é muito diferente do Rollup soberano da Celestia, cujos Rollups se estendem entre si e devem executar os nós de luz da camada DA da outra parte.

Quando o Relayer envia uma transação cross-chain, ela será processada pelo Aggregator 2 e HP2 do Rollup2. Adicionamos ambos ao gráfico para entender como os nós do Rollup2 processam as transações nos Rollups.

O Relayer do Rollup2 obterá o Batch Header e o ZKP do Rollup 2 e os enviará de volta ao Rollup1. Rollup 1 também tem um nó de luz Rollup 2 e um nó de luz de camada DA.

Podemos tornar o modelo mais simplificado. Suponha que dois Rollups usem o mesmo agregador compartilhado e o Header Producer, ou seja, as camadas DA que eles usam se sobrepõem.

Neste caso, o Relayer pode ser banido diretamente. Como o Batch Header e o ZK Proof foram publicados pela HP na mesma camada DA, dados como o Header e o ZKP de outro Rollup podem ser lidos diretamente na camada DA e não precisam mais ser passados para o agregador compartilhado por meio do Retransmissor.

Obviamente, o Rollup usando a mesma camada DA não precisa depender do Relayer (muitas pontes de cadeia cruzada dependem de nós de retransmissão). Isso pode resolver o problema de segurança da ponte cross-chain (deste ponto de vista, o cross-span entre SC Rollups de Ethereum é mais seguro do que o cross-chain entre diferentes cadeias públicas).

Neste momento, **configuração mínima de minimização de confiança: **Da camada light node + Rollup light node.