• Encaminhe 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 Sequenciador sempre foi um foco da comunidade Ethereum/Celestia, e também é uma montanha difícil de atravessar no trabalho de desenvolvimento da Layer2. A este respeito, diferentes planos de Rollup propuseram ideias para a descentralização de nós, fornecendo uma gama extremamente vasta de imaginação para este tópico.

O autor deste artigo toma como exemplo o conhecido projeto Aztec do ZKRollup e utiliza as duas propostas denominadas B52 e Fernet recentemente propostas pelos 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 autorização

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

1. Rede sequenciadora descentralizada, com nós L2 a elegerem proponentes para cada ronda.

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

3. Rollup com uma 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 submetidos à camada DA, é possível obter uma finalidade relativamente eficaz. O carácter definitivo irreversível exige a conclusão da apresentação da prova de validade.

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

7. Tanto o bloco L2 como os dados da transação são propagados na rede p2p do L2.

8. L2 herda a segurança de L1.

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

Este plano divide todo o processo de produção de blocos L2 em três fases temporais:

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

Entre elas, a fase BPW (Block Proposal) é o processo em que vários Sequenciadores propõem blocos diferentes e competem, e o Provador selecciona um bloco candidato para votar. BAW (Block Acceptance) é o processo em que o Provador constrói uma Prova de Validade para o bloco e submete-a. Janela de proposta de bloco (fase de proposta de bloco): A BPW pode ainda ser subdividida em três fases - Proposta de bloco, Votação de bloco, Agregação.

(Proposta de bloco Diagrama de processo de janela)

Fase de proposta de bloco (BP): qualquer pessoa nesta fase pode recolher transacções e transmitir o seu próprio conteúdo BP. O conteúdo do BP incluirá três partes: hash da ordem dos txs, percentagem de recompensa do provador, montante do token de gravação.

txs order hash: O proponente selecciona o lote mais valioso de transacções da pool de transacções L2 (mempool), ordena-as e, em seguida, coloca o valor hash dessas transacções no bloco que está a construir. percentagem de recompensa do provador: A percentagem de recompensas do bloco que o Sequenciador partilha com o Provador. quantidade de tokens queimados: A quantidade de L2 Native Tokens que o Proponente se propõe queimar, depois envia o seu BP para a rede L2 p2p.

Fase de votação em bloco:

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

Vote={BlockHash, Index of Proof Tree}

BlockHash é o hash da proposta em que o provador quer votar, e Index of Proof Tree é o valor do índice da folha da Proof Tree em que o provador quer participar na construção (será explicado mais tarde)

Agregação: O Proponente recolhe os votos dos Provedores no BP na rede p2p L2, agrega-os e coloca-os no BP, e submete-os a L1 (cada BP geralmente só contém registos de votação relacionados com ele próprio).

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

Ter a pontuação mais elevada:

PONTUAÇÃO(y) = NÚMERO DE PROVEDORES (x)^3 * LICENÇA DE QUEIMADURA(z)^2`

NUM_PROVERS (x) é o número de votos do Provador que este BP recebeu e BURN_BID é o número de fichas L2 propostas para serem queimadas por este BP. Porque quanto mais elevado for o BURN_BID, menos recompensas o proponente do PN receberá no final, pelo que este valor deve ser definido de forma adequada.

Ao mesmo tempo, este PN deve ser apresentado ao L1 antes do final da janela de proposta de bloco e a prova de validade correspondente deve ser carregada no L1 antes do final da janela de aceitação do bloco.

Nota: Na pontuação do BP, o número de votos tem o maior peso, seguido do número de fichas de queimadura. Ao mesmo tempo, o sistema B52 permite que vários proponentes (na realidade, sequenciadores) concorram a uma quota válida de BP.

O esquema B52 apenas requer que o Proponente (sequenciador) especifique o número de tokens queimados no seu próprio BP (semelhante ao método EIP1559) sem ter de apostar tokens antecipadamente, o que pode tornar a rede mais sem permissões (sem permissão de admissão), e é também conducente à 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 do Ethereum, com o objetivo de evitar que o MEV seja espreitado e antecipado por outros Proponentes.

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

(Diagrama esquemático da Janela de Aceitação de Blocos, escrito como Aceitação de Provas na figura)

Após o fim da janela de proposta de bloco, o provador tem de revelar os seus dados de transação completos correspondentes ao seu BP. Se o BP em que o Provador vota for selecionado (tendo a pontuação mais elevada, que pode ser consultada através do contrato L1), tem de construir a Sub Árvore de Provas correspondente ao Índice da Árvore de Provas dado aquando da votação.

Suponha que um bloco Aztec contém 2^13=16384 quantidades de transacções e que existem 2048 provadores, então cada provador constrói uma subárvore de provas composta por 2^3=8 transacções. Em seguida, o provador transmite a sua subárvore de prova construída para a rede L2 p2p. Depois de a receber, o proponente agregará todas as árvores de sub-provas numa prova de bloco.

Em seguida, o Propsoer submeterá a prova agregada ao contrato L1 Rollup, que verificará a correção desta prova e os resultados correspondentes da transição de estado. Deve ter em conta que se o provador não apresentar deliberadamente a prova, não só não receberá os dividendos da recompensa do bloco prometidos pelo proponente, como também será reduzido, uma vez que para se tornar provador é necessário apostar tokens antecipadamente. Por conseguinte, ao contrário do Proponente (Sequenciador), o Provador não é desprovido de permissões.

Explicação pormenorizada dos adiantamentos do Estado:

Após o fim da Janela de Aceitação de Blocos, o contrato de Rollup seleccionará o bloco com maior pontuação para ser incluído no livro de Rollup, e a recompensa do bloco será enviada para o Proponente (Sequenciador) e para o Provador na proporção previamente declarada pelo Proponente.

O esquema acima é o B52 da Aztec. No entanto, o autor deste artigo considera que a proposta B52 tem alguns problemas potenciais:

Primeiro problema: Suponha que a prova de validade de um bloco com a pontuação mais elevada está incompleta. A solução dada na proposta é que, se o proponente só apresentar 50% da prova, só pode receber 50% da recompensa do bloco, garantindo assim que o proponente não tem qualquer incentivo para não apresentar deliberadamente uma prova completa. Ao mesmo tempo, o provador pode também submeter diretamente a prova ao contrato.

De acordo com a descrição da proposta, é aceitável que um bloco não tenha uma prova completa da validade da transação. De facto, isto não é razoável porque: o zkrollup declara o novo estado correspondente a este bloco como válido apenas quando a prova de validade é dada.

Se a prova agregada que o proponente finalmente submete a L1 não tem a prova de uma determinada transação, é óbvio que a prova de transição de estado de todas as transacções que ocorrem depois desta transação é inválida (porque as transacçõ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 este bloco é válido.

Por conseguinte, neste 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 apresentadas.

Problema 2: Suponha que o bloco com maior pontuação é um bloco ilegal (este ponto não é explicado no plano B52). O BP contém apenas o hash da sequência da transação, pelo que um proponente malicioso poderia intencionalmente construir transacções problemáticas, tais como transacções de gasto duplo. Neste momento, é efetivamente necessário acrescentar uma função ao contrato L1 que permita a qualquer pessoa apresentar uma prova ilegal. Esta prova ilegal é utilizada para provar que o BP com maior pontuação é um bloco ilegal.

Além disso, este tipo de relatório deve ser recompensado. Podemos dar todos os tokens de combustão enviados para o contrato pelo proponente como recompensa ao nó que submeteu a prova ilegal.

Um pensamento interessante: Sobre os blocos de tio e o trabalho redundante do provador: O plano B52 irá, de facto, após cada ronda em que apareça o BP mais alto e válido, tratar os outros BPs (que submeteram provas completas) nessa ronda como uncle blocks e distribuir uma certa quantidade de prémios uncle block.

De facto, isto segue a prática do mecanismo de consenso ETH POW. Para evitar uma concentração excessiva do poder de computação, é necessário atribuir uma parte da recompensa do bloco aos proponentes dos blocos que não são adoptados (mineiros), a fim de proteger os interesses dos pequenos agrupamentos de mineiros/minas individuais e evitar que o poder de mineração seja monopolizado pelos grandes agrupamentos de mineiros. Por conseguinte, a adoção do mecanismo de blocos do tio do Ethereum, que tem um bom desempenho, é também uma escolha muito inteligente.

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

Por conseguinte, acabará por se tornar uma rede mais centralizada, semelhante ao Mev-Boost Builder, porque o proponente que pode eventualmente produzir o bloco é frequentemente o Block Builder que é melhor na captura de MEV.

Ao mesmo tempo, o provador no esquema B52 precisa de penhorar activos, mas como só precisa de gerar a prova da sub-árvore, em comparação com as soluções que precisam de gerar toda a prova do 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 a sua própria rede p2p para transmitir transacções e votações/BP, e tanto o Sequencer como o Prover são relativamente descentralizados. Mas temos de resolver os dois problemas acima referidos: o primeiro é que o bloco com maior pontuação tem de ser um bloco legal e o segundo é que temos de esperar que a prova completa do bloco seja submetida a L1 antes de entrar num novo estado. Por conseguinte, é necessário um mecanismo de incentivo mais eficaz para evitar que toda a rede do Rollup deixe de funcionar normalmente (pare) devido à falta de alguma prova tx.

Resistência à censura: Se conseguirmos garantir que qualquer pessoa pode publicar propostas de blocos BP, e garantir que não só o Proponente pode submeter provas de blocos, então a rede terá uma boa resistência à censura.

Finalidade: A finalidade do L2 está intimamente relacionada com a vivacidade da rede, porque a finalidade final verificada ainda precisa de esperar pela submissão do Block Proof, mas na verdade também pode confiar no conteúdo do bloco correspondente ao BP com maior pontuação (desde que não contenha transacções maliciosas).

Este bloco será revelado no início da Janela de Aceitação de Bloco, o que significa que, como utilizador, só precisa de esperar pelo tempo da Janela de Proposta de Bloco, e o bloco onde se encontra a sua transação pode ser adotado.

Herdar a segurança de L1: Como um L2 que actualiza o estado através da apresentação de uma prova de validade, pode herdar a segurança de L1.

Proposta Fernet: Introdução do 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 dentro 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 é que se pode aderir ao Comité? Essencialmente, requer o staking de 16 ETH em L1 e, depois de concluído o processo de staking, aguarde 4 blocos L1 antes de se juntar ao 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 montante restante em jogo.

Em seguida, o que é o VDF? A função de atraso verificável é uma função matemática que obedece a características rigorosas de execução em série. Executa determinados passos computacionais e consome uma quantidade previsível de tempo. Denotamos o valor calculado pelo VDF como a Pontuação, que segue uma distribuição normal uniforme. Assim, quando o Sequenciador calcula a Pontuação VDF, pode determinar a probabilidade de ser selecionado como um Proponente legítimo.

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

Pontuação = VDF( privatekey , public inputs )

entradas públicas = { current block number , randao }

randao é um número aleatório utilizado para evitar que os sequenciadores calculem prematuramente a sua pontuação VDF para todas as alturas de bloco futuras

Todo o processo de produção de Fernet divide-se essencialmente em três fases:

1. Fase de proposta 2. Fase de prova 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 desta fase, cada sequenciador calcula o seu próprio VDF Score na altura atual do bloco. Se o Sequenciador acreditar que a sua Pontuação VDF é suscetível de ganhar o direito de produção deste bloco (assumindo que a Pontuação satisfaz a distribuição normal), apresentará uma Proposta para o contrato L1 Rollup. A proposta inclui: o hash da sequência da transação, que aponta para um bloco L2 anterior.

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

Fase de prova: PROVING_PHASE_L1_BLOCKS= 50 blocos L1 (Esta fase terá a duração de 50 blocos L1, cerca de 10 min)

O Provador recebe todas as transacções correspondentes ao Conteúdo do Bloco da rede L2 p2p e constrói uma Prova para o bloco com uma Pontuação VDF mais elevada. A construção da prova também adopta um método de múltiplos provadores que cooperam em paralelo (semelhante ao esquema B52).

Por conseguinte, o Sequenciador deve finalmente agregar as provas de várias transacções diferentes numa prova de bloco (incluindo a prova VDF) e submetê-la ao contrato L1 Rollup. Qualquer pessoa pode apresentar os conteúdos de bloco que já tenha apresentado a prova de bloco ao contrato de rollup.

Finalização: Precisa de submeter uma transação L1 para Finalizar o bloco, um bloco que pode ser finalmente Finalizado precisa de satisfazer: Conteúdo do Bloco submetido e Prova do Bloco, o bloco anterior para o qual aponta tem de ser Finalizado. Nesta base, deve também ter a pontuação mais elevada.

(No processo de blocagem em pipeline, assim que termina a fase de proposta do bloco anterior, inicia-se a fase de proposta do bloco seguinte, sem esperar que termine a fase de prova do bloco anterior).

Mecanismo de geração de blocos em pipeline: É de salientar que a Fernet adopta um mecanismo de geração de blocos em 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, precisa de esperar que o bloco N finalize antes de poder submeter a transação do Bloco Final de L1 e ser validado para se tornar o Bloco Final.

Potenciais vectores de ataque: Se o sequenciador com a pontuação VDF mais alta não transmitir intencionalmente o conteúdo do bloco no L2 p2p, isso pode levar à reorganização do bloco (reorg).

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

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

O significado da descentralização na Fernet: Os sequenciadores juntam-se ao Comité de Sequenciadores apostando 16 ETH, e o limiar de entrada não é elevado (mas também não é baixo). Os Provedores não precisam de fazer staking, mas se os Provedores não gerarem Provas, não há penalização. É basicamente o oposto do esquema B52.

Vivacidade: A disponibilidade global da rede pode ser garantida porque o mecanismo VDF + bloco tio pode assegurar que haja mais de um produtor de blocos em cada ronda.

MEV: A consideração do MEV é particularmente singular. Este esquema planeia introduzir o PBS, pelo que, depois de um Sequenciador calcular uma pontuação VDF elevada, pode abordar diretamente o Block Builder para construir um bloco mais valioso.

Resistência à censura: A Fernet também adoptará um mecanismo PBS consistente com o Ethereum, portanto, essencialmente, a questão da resistência à censura da Fernet é equivalente à questão da resistência à censura PBS do Ethereum.

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

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