• Encaminhar o título original：Descentralizando o rollup: Analisando a solução de sequenciador descentralizado da Aztec

Introdução: Desde que o Rollup se tornou proeminente, a descentralização do Sequencer sempre foi o foco da comunidade Ethereum/Celestia, e também é uma montanha difícil de atravessar no trabalho de desenvolvimento da Layer2. Nesse sentido, diferentes planos de Rollup propuseram ideias para a descentralização de nós, oferecendo uma gama extremamente ampla de imaginação para esse tópico.

O autor deste artigo toma como exemplo o conhecido projeto Aztec do ZKRollup e usa as duas propostas denominadas B52 e Fernet, recentemente propostas pelo Aztec Labs, como ponto de entrada, para analisar para os leitores como o ZKR realiza a descentralização dos nós sequenciadores.

Proposta B52: Esquema de sequenciador sem permissão

A proposta B52 pretende atingir os seguintes objetivos (idealmente):

1. Rede sequenciadora descentralizada, com nós L2 elegendo proponentes para cada rodada.

2. Rede descentralizada de provadores, com baixos requisitos de hardware para os nós de provadores.

3. O Rollup possui excelente resistência à censura em geral.

4. O valor MEV gerado em L2 é obtido pelos nós de L2.

5. Quando os blocos L2 são enviados para a camada DA, é possível obter uma finalidade relativamente eficaz. A finalidade irreversível requer a conclusão do envio da Prova de Validade.

6. Os Tokens L2 podem ter um modelo tokenômico decente.

7. Os dados de bloco e de transação do L2 são propagados na rede p2p do L2.

8. O L2 herda a segurança do L1.

(A proposta da B52 assume a estrutura de Rollup, o Proponente é essencialmente o Sequenciador)

Esse plano divide todo o processo de produção do bloco L2 em três estágios de tempo:

Janela de proposta de bloco (BPW) Janela de aceitação de bloco (BAW) Avanços de estado

Entre eles, o estágio BPW (Block Proposal) é o processo em que vários sequenciadores propõem blocos diferentes e competem, e o provador seleciona um bloco candidato para votar. BAW (Block Acceptance) é o processo no qual o provador constrói uma prova de validade para o bloco e a envia. Janela de proposta de bloco (fase de proposta de bloco): A BPW pode ser subdividida em três estágios - Proposta de bloco, Votação de bloco e Agregação.

(Proposta de bloco Diagrama de processo de janela)

Estágio de proposta de bloco (BP): qualquer pessoa no estágio pode coletar transações e transmitir seu próprio conteúdo de BP. O conteúdo do BP incluirá três partes: hash de ordem de txs, porcentagem de recompensa do provador, valor do token de gravação.

hash de ordem txs: O proponente seleciona o lote mais valioso de transações do pool de transações L2 (mempool), classifica-as e, em seguida, coloca o valor de hash dessas transações no bloco que está construindo. porcentagem de recompensa do provador: A porcentagem de recompensas de bloco que o Sequenciador compartilha com o Provador. quantidade de tokens queimados: A quantidade de L2 Native Tokens que o Proponente se propõe a queimar e, em seguida, enviar seu BP para a rede L2 p2p.

Fase de votação em bloco:

Depois que o Provador receber BPs propostos por diferentes Proponentes na rede p2p, ele votará no BP que lhe permite obter o maior número de recompensas. No entanto, a composição do voto é especial:

Voto={BlockHash, Index of Proof Tree}

BlockHash é o hash da proposta na qual o provedor deseja votar, e Index of Proof Tree é o valor do índice da folha da Proof Tree na qual o provedor deseja participar da construção (será explicado posteriormente)

Agregação: O Proponente coleta votos de Provedores no BP na rede p2p L2, agrega-os e os coloca no BP e os envia para L1 (cada BP geralmente contém apenas registros de votação relacionados a si mesmo).

Aqui, é necessário enfatizar o pré-requisito para que o BP seja selecionado e incluído no Rollp ledger:

Ter a maior pontuação:

SCORE(y) = NUM_PROVERS (x)^3 * BURN_BID(z)^2`

NUM_PROVERS (x) é o número de votos do Provador que esse BP recebeu, e BURN_BID é o número de Tokens L2 propostos para serem queimados por esse BP. Como quanto maior o BURN_BID, menos recompensas o proponente do BP receberá no final, esse valor deve ser definido adequadamente.

Ao mesmo tempo, esse BP precisa ser enviado à L1 antes do final da Janela de Proposta de Bloco, e a Prova de validade correspondente precisa ser carregada na L1 antes do final da Janela de Aceitação de Bloco.

Observação: Na pontuação do BP, o número de votos tem o maior peso, seguido pelo número de tokens de queima. Ao mesmo tempo, o esquema B52 permite que vários proponentes (na verdade, sequenciadores) concorram a uma cota válida de BP.

O esquema B52 exige apenas que o Proponente (sequenciador) especifique o número de tokens queimados em seu próprio BP (semelhante ao método EIP1559), sem precisar apostar tokens antecipadamente, o que pode tornar a rede mais livre de permissões (sem permissão de admissão) e também favorece a deflação de tokens nativa do L2.

Além disso, o BP não contém dados completos da transação, mas apenas o hash da sequência da transação, o que é semelhante ao esquema PBS da Ethereum, com o objetivo de evitar que o MEV seja espionado e antecipado por outros Proponentes.

Explicação detalhada da janela de aceitação de blocos:

(Diagrama esquemático da janela de aceitação de bloco, escrito como aceitação de prova na figura)

Após o término da janela de proposta de bloco, o provador precisa revelar seus dados completos de transação correspondentes ao seu BP. Se o BP no qual o Provador vota for selecionado (com a pontuação mais alta, que pode ser consultada por meio do contrato L1), ele precisará construir a Sub Árvore de Provas correspondente ao Índice da Árvore de Provas fornecido na votação.

Suponha que um bloco Aztec contenha 2^13=16384 quantidades de transações e que haja 2048 provadores, então cada provador constrói uma subárvore de prova composta de 2^3=8 transações. Em seguida, o provador transmite sua subárvore de prova construída para a rede L2 p2p. Depois de recebê-la, o proponente agregará todas as subárvores de prova em uma prova de bloco.

Em seguida, o Propsoer enviará a prova agregada ao contrato L1 Rollup, que verificará a exatidão dessa prova e os resultados correspondentes da transição de estado. Deve-se observar aqui que, se o provador deliberadamente não enviar a prova, ele não apenas deixará de receber os dividendos da recompensa do bloco prometidos pelo proponente, mas também será cortado, pois para se tornar um provador é necessário apostar tokens antecipadamente. Portanto, ao contrário do Proponente (Sequenciador), o Provador não é sem permissão.

Explicação detalhada dos adiantamentos do Estado:

Após o término da Janela de Aceitação do Bloco, o contrato de Rollup selecionará o bloco com a pontuação mais alta para ser incluído no registro do Rollup, e a recompensa do bloco será enviada ao Proponente (Sequenciador) e ao Provador na proporção previamente declarada pelo Proponente.

O esquema acima é o B52 da Aztec. No entanto, o autor deste artigo acredita que a proposta do B52 tem alguns problemas em potencial:

Primeiro problema: Suponha que a prova de validade de um bloco com a pontuação mais alta esteja incompleta. A solução apresentada na proposta é que, se o Proponente fornecer apenas 50% da prova, ele só poderá receber 50% da recompensa do bloco, garantindo assim que o Proponente não tenha incentivo para deliberadamente não enviar uma prova completa. Ao mesmo tempo, o provador também pode enviar a prova diretamente para o contrato.

De acordo com a descrição da proposta, é aceitável que um bloco não tenha uma prova de validade de transação completa. Na verdade, isso não é razoável porque: o zkrollup declara que o novo estado correspondente a esse bloco é válido somente quando a prova de validade é fornecida.

Se a prova agregada que o proponente finalmente envia a L1 não tiver a prova de uma determinada transação, é óbvio que a prova de transição de estado de todas as transações que ocorrem após essa transação é inválida (porque as transações são executadas em sequência e têm dependências de estado), e não podemos confirmar que o novo estado correspondente a esse bloco é válido.

Portanto, nesse momento, o mais razoável é entrar na janela de aceitação de blocos de espera infinita até que todas as provas de transação sejam enviadas.

Problema 2: Suponha que o bloco de maior pontuação seja um bloco ilegal (esse ponto não é explicado no plano do B52). O BP contém apenas o hash da sequência de transações, de modo que um proponente mal-intencionado poderia construir intencionalmente transações problemáticas, como transações de gasto duplo. Neste momento, é realmente necessário adicionar uma função ao contrato L1 que permita a qualquer pessoa enviar uma prova ilegal. Essa prova ilegal é usada para provar que o BP de maior pontuação é um bloco ilegal.

Além disso, esse tipo de relatório deve ser recompensado. Podemos dar todos os tokens de queima enviados ao contrato pelo proponente como recompensa ao nó que enviou a prova ilegal.

Pensamento interessante: Sobre os uncle blocks e o trabalho redundante do provador: O plano B52, na verdade, após cada rodada em que o BP mais alto e válido aparecer, tratará os outros BPs (que enviaram provas completas) nessa rodada como blocos de tio e distribuirá uma certa quantidade de recompensas de bloco de tio.

Na verdade, isso segue a prática do mecanismo de consenso ETH POW. Para evitar a concentração excessiva do poder de computação, é necessário alocar uma parte da recompensa do bloco para os proponentes dos blocos que não são adotados (mineradores), para proteger os interesses de pequenos pools de mineração/mineradores individuais e para evitar que o poder de mineração seja monopolizado por grandes pools de mineração. Portanto, a adoção do mecanismo de bloco de tio bem executado da Ethereum também é uma escolha muito inteligente.

A importância da proposta da B52 em termos de descentralização do Rollup: O Proponente é descentralizado e não exige um compromisso, e a barreira de entrada é baixa. No entanto, como isso exige a construção do bloco mais valioso por si só, bem como a coleta de votos de outros Provedores e a agregação de todas as Provas, o limite de hardware do Proponente não é tão baixo quanto descrito na proposta (por exemplo, a largura de banda pode não ser muito baixa).

Portanto, ela acabará se tornando uma rede mais centralizada, semelhante à Mev-Boost Builder, porque o proponente que pode eventualmente produzir o bloco é geralmente o Block Builder que é melhor em capturar MEV.

Ao mesmo tempo, o provador no esquema B52 precisa empenhar ativos, mas como ele só precisa gerar uma prova de subárvore, em comparação com as soluções que precisam gerar toda a prova de bloco, o grau de descentralização do provador será melhor (os requisitos de hardware podem ser reduzidos).

Liveness: A vivacidade geral da rede é boa, porque o L2 tem sua própria rede p2p para transmitir transações e votações/BP, e tanto o Sequencer quanto o Prover são relativamente descentralizados. Mas precisamos resolver os dois problemas mencionados acima: o primeiro é que o bloco de maior pontuação deve ser um bloco legal e o segundo é que precisamos esperar que a prova completa do bloco seja enviada para L1 antes de entrar em um novo estado. Portanto, é necessário um mecanismo de incentivo mais eficaz para evitar que toda a rede Rollup deixe de funcionar normalmente (pare) devido à falta de alguma prova de tx.

Resistência à censura: Se pudermos garantir que qualquer pessoa possa publicar propostas de bloco BP e que não apenas o proponente possa enviar provas de bloco, a rede terá boa resistência à censura.

Finalidade: A finalidade do L2 está intimamente relacionada à vivacidade da rede, porque a finalidade final verificada ainda precisa aguardar o envio da prova de bloco, mas, na verdade, o usuário também pode confiar no conteúdo do bloco correspondente ao BP de maior pontuação (desde que não contenha transações maliciosas).

Esse bloco será revelado no início da Block Acceptance Window, o que significa que, como usuário, o senhor só precisa aguardar o tempo da Block Proposal Window, e o bloco em que sua transação está localizada poderá ser adotado.

Herdar a segurança de L1: Como um L2 que atualiza o estado enviando uma prova de validade, ele pode herdar a segurança do L1.

Proposta Fernet: Apresentando o VDF para a seleção de proponentes

Visão geral do esquema Fernet: Utilizando o VDF em cada ciclo de geração de blocos, uma pontuação projetada é atribuída a diferentes nós do Comitê (a coleção de nós do Sequenciador), e o bloco proposto pelo Sequenciador com a maior pontuação final torna-se o bloco válido.

Em primeiro lugar, como participar do Comitê? Essencialmente, é necessário fazer um staking de 16 ETH em L1 e, depois que o processo de staking for concluído, aguardar 4 blocos de L1 antes de entrar no Comitê do Sequenciador. Para sair do Comitê Sequenciador, é necessário chamar a função Unstake no contrato L1, após o que são necessários 3 dias para recuperar o valor restante apostado.

A seguir, o que é VDF? A função de atraso verificável é uma função matemática que adere a características rigorosas de execução em série. Ele executa determinadas etapas computacionais e consome uma quantidade previsível de tempo. Denotamos o valor calculado pelo VDF como Score, que segue uma distribuição normal uniforme. Assim, uma vez que o Sequenciador calcula a Pontuação VDF, ele pode determinar a probabilidade de ser selecionado como um Proponente legítimo.

O cálculo do VDF para o Sequencer é o seguinte:

Score = VDF( privatekey , public inputs )

inputs públicos = { current block number , randao }

randao é um número aleatório usado para evitar que os sequenciadores calculem prematuramente seu VDF Score para todas as alturas de bloco futuras

Todo o processo da Fernet é dividido principalmente em três etapas:

1. Fase de proposta 2. Fase de comprovação 3. Finalização

Fase de proposta: PROPOSAL_PHASE_L1_BLOCKS = 2 blocos Ethereum (Esta fase terá a duração de 2 blocos L1)

No início dessa fase, cada sequenciador calculará seu próprio VDF Score na altura do bloco atual. Se o Sequenciador acreditar que sua Pontuação VDF tem probabilidade de ganhar o direito de produção desse bloco (supondo que a Pontuação satisfaça a distribuição normal), ele apresentará uma Proposta para o contrato L1 Rollup. A proposta inclui: o hash da sequência de transações, apontando para um bloco L2 anterior.

bloco não comprovado: O bloco que só enviou a Proposta para o conteúdo do bloco do contrato de Rollup. Em seguida, o Sequenciador precisa enviar o conteúdo do bloco correspondente ao bloco não comprovado e a prova do VDF para a rede L2 p2p.

Fase de prova: PROVING_PHASE_L1_BLOCKS= 50 blocos L1 (Essa fase durará 50 blocos L1, cerca de 10 minutos)

O provador recebe todas as transações correspondentes ao conteúdo do bloco da rede L2 p2p e cria uma prova para o bloco com a pontuação VDF mais alta. A construção da prova também adota um método de vários provadores cooperando em paralelo (semelhante ao esquema B52).

Portanto, o Sequenciador precisa finalmente agregar as Provas de várias transações diferentes em uma Prova de Bloco (incluindo a Prova VDF) e enviá-la ao contrato L1 Rollup. Qualquer pessoa pode enviar o conteúdo do bloco que já tenha enviado a prova do bloco para o contrato de rollup.

Finalização: Ele precisa enviar uma transação L1 para finalizar o bloco, um bloco que pode ser finalmente finalizado precisa atender a: conteúdo do bloco enviado e prova do bloco, o bloco anterior para o qual ele aponta deve ser finalizado. Com base nisso, ele também precisa ter a pontuação mais alta.

(No processo de bloqueio em estilo pipeline, assim que o estágio de proposta do bloco anterior termina, o estágio de proposta do próximo bloco começa, sem esperar que o estágio de prova do bloco anterior termine).

Mecanismo de geração de blocos de pipeline: vale ressaltar que a Fernet adota um mecanismo de geração de blocos de pipeline. Quando a fase de proposta do bloco N termina, a proposta para o bloco N+1 começa (semelhante ao que o Aptos e outras cadeias públicas fazem). No entanto, para o bloco N+1, ele precisa aguardar a finalização do bloco N para poder enviar a transação do Bloco Final de L1 e ser validado para se tornar o Bloco Final.

Possíveis vetores de ataque: Se o sequenciador com a maior pontuação de VDF não transmitir intencionalmente o conteúdo do bloco no L2 p2p, isso poderá levar à reorganização do bloco (reorg).

Cálculo da quantidade de blocos L2 para a reorganização: 1+PROVING_PHASE_L1_BLOCKS / PROPOSAL_PHASE_L1_BLOCKS =1+50/2=26 blocos

Solução: Introduzir um mecanismo de bloco não identificado para evitar que haja apenas um bloco candidato completo para cada slot L2 (slot de tempo de geração de bloco).

A importância da descentralização na Fernet: Os sequenciadores se juntam ao Comitê de Sequenciadores apostando 16 ETH, e o limite de entrada não é alto (mas também não é baixo). Os provadores não precisam de staking, mas se os provadores não gerarem provas, não haverá penalidade. Isso é basicamente o oposto do esquema do B52.

Liveness: A vivacidade geral da rede pode ser garantida porque o mecanismo VDF + uncle block pode assegurar que haja mais de um produtor de blocos em cada rodada.

MEV: A consideração do MEV é particularmente única. Esse esquema planeja introduzir o PBS, de modo que, depois que um sequenciador calcula uma pontuação VDF alta, ele pode abordar diretamente o Block Builder para construir um bloco mais valioso.

Resistência à censura: A Fernet também adotará um mecanismo PBS consistente com o Ethereum, portanto, essencialmente, o problema de resistência à censura da Fernet é equivalente ao problema de resistência à censura PBS do Ethereum.

Isenção de responsabilidade：

1. Este artigo foi reimpresso de[Geek Web3], Encaminhar o título original'ollup Decentralization: Analysis of Aztec's Decentralized Sequencer Solution',Todos os direitos autorais pertencem ao autor original[xhhh，EthStorage]. 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.