Introdução: Desde que o Rollup se tornou popular, a descentralização do Sequencer sempre foi o foco da comunidade Ethereum/Celestia, e também é uma montanha intransponível na pesquisa e desenvolvimento do Layer2. A esse respeito, diferentes esquemas de Rollup propuseram ideias sobre a descentralização de nós, fornecendo um espaço de imaginação extremamente amplo para esse tópico.
O autor deste artigo toma como exemplo o conhecido projeto ZKRollup Aztec, e usa as duas propostas denominadas B52 e Fernet propostas recentemente pelo Aztec Labs como ponto de partida para analisar como o ZKR realiza a descentralização dos nós do sequenciador para os leitores.
Proposta B52: Esquema de sequenciador sem permissão
A proposta B52 pretende alcançar o seguinte (idealmente):
Rede sequenciadora descentralizada, os próprios nós L2 elegem cada rodada de proponentes
Rede de provador descentralizada, baixos requisitos de hardware para nós de provador
Rollup tem boa resistência à censura como um todo.
O valor MEV gerado por L2 é adquirido pelos nós L2
Quando o bloco L2 é submetido à camada DA, uma finalidade mais efetiva pode ser obtida, e a finalidade irreversível tem que aguardar o envio do ValidityProof (prova de validade)
L2 Token pode ter um bom modelo econômico
Tanto os blocos L2 quanto os dados de transação são propagados na rede L2 p2p
L2 herda a segurança de L1
Este esquema 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 Blocos (BAW)
Adiantamentos estatais
Entre eles, o estágio BPW (block proposto) é um processo no qual vários sequenciadores Seuqnecer propõem diferentes blocos e competem, e o Prover seleciona um bloco candidato para dar uma votação.
BAW (Block Acceptance) é o processo no qual o Provedor constrói uma Prova de Validade para um bloco e a envia.
Janela de proposta de bloco (fase de proposta de bloco):
O BPW pode ser subdividido em três etapas: Proposta em Bloco, Votação em Bloco, Agregação.
Qualquer pessoa na fase de Block Proposal (BP) pode coletar transações e transmitir seu próprio conteúdo de BP. O conteúdo do BP conterá três partes: hash do pedido txs, porcentagem de recompensa do provador, valor do token de queima
txs order hash: O proponente seleciona e classifica o lote de transações mais valioso do pool de transações L2 (mempool) e, em seguida, coloca o valor de hash desse lote de transações no bloco que ele constrói.
porcentagem de recompensa do provador: a porcentagem de recompensa do bloco compartilhada pelo sequenciador para o provador
quantidade de token de queima: O número de Token Nativo L2 proposto pelo Proponente para ser destruído e, em seguida, envia o BP proposto para a rede L2 p2p
Etapa de votação em bloco:
Depois que o Provedor receber o BP proposto por diferentes Proponentes na rede p2p, ele votará no BP que pode lhe render a maior recompensa. No entanto, a composição do voto é muito especial:
Vote={BlockHash, Índice da Árvore de Provas}
BlockHash é o hash da Proposta que o Provedor irá votar, e Index of Proof Tree é o valor do índice folha da Proof Tree que o Proof Tree irá construir (explicado mais adiante)
Agregação de agregação: O Proponente coleta os votos dos Provedores para BP na rede L2 p2p, os agrega e os coloca no BP, e os envia para L1 (cada BP geralmente contém apenas registros de votação relacionados a ele mesmo).
Aqui, é necessário enfatizar os pré-requisitos para que o BP seja selecionado e incluído no livro Rollp:
Ter a pontuação mais alta:
SCORE(y) = NUM_PROVERS (x)^3 * BURN_BID(z)^2
NUM_PROVERS (x) é o número de votos do Prover obtido pelo BP, e BURN_BID é o número de Tokens L2 propostos para serem destruídos pelo BP. Uma vez que quanto maior for o BURN_BID, menor será a recompensa que o proponente do BP receberá no final, portanto, esse valor deve ser definido corretamente.
Ao mesmo tempo, o BP precisa ser submetido ao L1 antes do final da Janela de Proposta de Bloco, e o respectivo comprovante de validade deve ser carregado no L1 antes do final da Janela de Aceitação do Bloco.
Nota: No cálculo das pontuações de BP, o número de votos representa a maior proporção, seguido pelo número de fichas de queima. Ao mesmo tempo, o esquema B52 permite que vários proponentes (na verdade, sequenciadores) concorram por uma cota efetiva de BP
O esquema B52 exige apenas que o Proponente (sequenciador) especifique o número de tokens de gravação em seu próprio BP (semelhante ao método de EIP1559) sem tokens de participação antecipadamente, o que pode tornar a rede mais sem permissão (sem permissão de acesso) e é também benéfico para L2 Native Token produz deflação.
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 motivo é semelhante ao esquema Ethereum PBS, que visa impedir que o MEV seja espionado por outros proponentes.
Explicação detalhada da Janela de aceitação do bloco (fase de aceitação do bloco):
Após o término da Janela de Proposta de Bloco, o Provedor precisa revelar os dados completos da transação correspondente ao seu PN. Caso seja selecionado o PB votado pelo Provedor (a maior pontuação pode ser consultada através do contrato L1), ele deverá construir a SubProof Tree correspondente ao Índice de Proof Tree dado durante a votação.
Assumindo que o bloco do Aztec contém 2^13=16384 transações e há 2048 provadores, então cada provador constrói uma árvore de subprova que consiste em 2^3=8 transações. Em seguida, o provador transmite a árvore de subprova construída por ele mesmo para In the L2 p2p rede. Depois que o proponente o receber, ele agregará todas as árvores de subprovas em uma prova em bloco.
Em seguida, o Proponente envia a prova agregada ao contrato L1 Rollup, e o contrato verificará a exatidão da prova e os resultados da transição de estado correspondente. Ressalte-se aqui que se o Provedor deixar deliberadamente de apresentar a comprovação, não só não conseguirá obter o dividendo de recompensa em bloco prometido pela Proponente, como também será cortado, pois para se tornar Provedor precisa penhor Token com antecedência. Portanto, ao contrário do Proposer (Sequencer), o Prover não é sem permissão.
Explicação detalhada dos Avanços de Estado (estágio de avanço de estado):
Após o término da Janela de Aceitação de Bloco, o contrato de Rollup selecionará um bloco com a maior pontuação para ser incluído no livro Rollup, e enviará a Recompensa de bloco ao Proponente e Provedor respectivamente de acordo com a proporção declarada pelo Proponente (Sequenciador) em avançar.
A descrição acima é a solução B52 da Aztec. No entanto, o autor deste artigo acredita que existem alguns problemas potenciais com a proposta B52:
Questão 1: Se a prova de validade do bloco com maior pontuação estiver incompleta. A solução dada na proposta é que, se o Proponente fornecer apenas 50% da prova, ele poderá obter apenas 50% das recompensas do bloco, de modo a garantir que o Proponente não tenha motivação para deliberadamente não enviar uma prova completa. Ao mesmo tempo, o Provedor também pode enviar a prova diretamente ao contrato.
De acordo com a descrição da proposta, é aceitável aceitar um bloco sem comprovação de validade de transações completas. Na verdade, isso não é razoável: porque: zkrollup apenas declara que o novo estado correspondente a este bloco é válido quando a prova de validade é fornecida.
Se a prova agregada enviada pelo proponente para L1 estiver faltando a prova de uma determinada transação, é óbvio que as provas de transição de estado de todas as transações que ocorrem após essa transação são inválidas (porque as transações são executadas sequencialmente e possuem dependências de estado), nós Também é impossível confirmar se o novo estado correspondente a este bloco é válido.
Portanto, neste momento, o caminho razoável deve ser entrar na Janela de Aceitação de Blocos que aguarda infinitamente até que todos os comprovantes da transação sejam enviados.
Questão 2: **Se o bloco com maior pontuação for um bloco ilegal (isso não é explicado no esquema B52). **BP contém apenas o hash da sequência da transação, portanto, um proponente mal-intencionado pode, na verdade, construir deliberadamente transações problemáticas, como transações de gasto duplo. Então, neste momento, é realmente necessário adicionar uma função no contrato L1 para que qualquer pessoa possa enviar uma prova ilegal, usada para provar que o BP com maior pontuação é um bloco ilegal.
E esse tipo de relatório deve ser recompensado, podemos recompensar o token de queima enviado pelo proponente do contrato ao nó repórter que enviou a prova ilegal.
**Pensamento interessante:**Sobre tios bloqueados e trabalho de provador redundante: o esquema B52 realmente usará outros BPs (que enviaram provas completas) que aparecem nesta rodada como tios depois que o BP com a pontuação mais alta em cada rodada aparecer. bloco, atribua uma certa recompensa de bloco de tio.
Na verdade, isso segue a abordagem do mecanismo de consenso ETH POW. Para evitar a concentração excessiva de poder de computação, é necessário alocar uma parte das recompensas de bloco para proponentes de blocos não aceitos (mineradores) para proteger os interesses de pequenos pools de mineração/mineradores individuais e evitar O poder de computação é monopolizado por grandes pools de mineração. Portanto, também é uma escolha muito inteligente adotar o mecanismo de bloco tio que o Ethereum tem bom desempenho.
O significado da proposta B52 em termos de descentralização do Rollup: O proponente é descentralizado e não requer penhor, e o limite de entrada é baixo; mas porque você mesmo precisa construir os blocos mais valiosos e precisa coletar votos de outros Proponentes e agregar todas as Provas. Na verdade, o limite de hardware do Proponente não é tão baixo quanto declarado na proposta (por exemplo, a largura de banda pode não ser muito baixa).
Portanto, acabará se tornando uma rede relativamente centralizada, semelhante ao Mev-Boost Builder, porque o proponente que pode finalmente gerar blocos geralmente é o Block Builder que é melhor na captura de MEV.
Ao mesmo tempo, o Prover no esquema B52 precisa penhorar ativos, mas como apenas a prova de subárvore precisa ser gerada, em comparação com os esquemas que precisam gerar completamente toda a prova de bloco, **O grau de descentralização do Provedor será melhor (os requisitos de hardware podem ser reduzidos). **
Liveness ativo: O Liveness geral da rede é bom, porque o L2 tem sua própria rede p2p para transmitir transações e votos/BP, e o Sequencer e o Prover são relativamente descentralizados. Mas precisamos resolver os dois problemas que mencionamos acima. Um é que o bloco com a maior pontuação deve ser um bloco legal, e o segundo é que ele precisa 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 funcione mal (downtime) devido à falta de uma determinada parte da prova tx.
**Resistência à censura: **Se pudermos garantir que qualquer pessoa pode publicar a proposta de bloqueio BP e garantir que não apenas o proponente possa enviar a prova de bloqueio, a rede terá boa resistência à censura.
**Finalidade: **A finalidade do L2 está intimamente relacionada com a vivacidade da rede, pois a finalidade final verificada ainda precisa aguardar o envio do Block Proof, mas na verdade você também pode confiar no conteúdo do bloco correspondente a um BP com a pontuação mais alta (desde que não contenha transações maliciosas).
Este bloco será revelado no início da Janela de Aceitação de Bloco, o que significa que como usuário, você só precisa aguardar uma Janela de Proposta de Bloco, e o bloco onde a transação que você enviou pode ser aceita.
Herdar segurança L1: Como um L2 que atualiza seu status enviando prova de validade, pode herdar a segurança de L1.
Proposta Fernet: Apresentar VDF para selecionar Proponente legal
Introdução do esquema Fernet: Através do VDF, em cada rodada do ciclo de geração de blocos, uma pontuação estimada é definida para diferentes nós no Comitê (ou seja, o conjunto de nós do Sequencer), e o bloco proposto pelo Sequencer com o maior pontuação final se tornará peça válida.
**Primeiro, como ingressar no Comitê? Na verdade, você precisa prometer 16 ETH em L1, **e aguardar 4 blocos L1 após a conclusão da operação de penhora e, em seguida, ingressar no Comitê do Sequenciador. Quanto à saída do Sequencer Committee, você precisa chamar a função Unstake no contrato L1 e, em seguida, poderá recuperar o valor restante de sua promessa após mais 3 dias.
Então, o que é um VDF? A função de atraso verificável é uma função de atraso verificável. Esta função matemática satisfaz características de execução serial estritas. Ela executará algumas etapas de cálculo e consumirá pelo menos um período de tempo previsível. Registramos o valor calculado pelo VDF como Score, que satisfaz uma distribuição normal uniforme, portanto, após o Sequencer calcular o VDF Score, ele pode julgar a probabilidade de ser selecionado como proponente legal. **
O VDF do sequenciador é calculado da seguinte forma:
entradas públicas = { número do bloco atual , randao }
randao é um número aleatório usado para evitar que o Sequencer calcule sua própria Pontuação VDF em todas as alturas de bloco futuras com antecedência
Todo o processo da Fernet é dividido principalmente em 3 etapas:
Proposta Fase 2. Prova Fase 3. Finalização
**Fase da proposta:**PROPOSTA_PHASE_L1_BLOCKS = 2 blocos Ethereum (esta fase durará 2 blocos L1)
No início desta etapa, cada sequenciador usará o VDF para calcular seu VDF Score correspondente na altura do bloco atual. Se o Sequencer achar que seu VDF Score provavelmente ganhará o direito de produzir um bloco desta vez (supondo que o Score satisfaça uma distribuição normal), ele enviará um contrato Rollup da Proposta para L1. A proposta contém: o hash da sequência da transação, apontando para qual bloco L2 anterior.
bloco não comprovado: Somente o conteúdo do bloco da Proposta para o contrato Rollup é enviado. Em seguida, **Sequencer precisa enviar o conteúdo do bloco correspondente ao bloco não comprovado e a prova de VDF para a rede L2 p2p. **
ProvingFase: PROVING_PHASE_L1_BLOCKS= 50 blocos L1 (esta fase manterá 50 blocos L1, cerca de 10 min)
O Provedor recebe todas as transações correspondentes no Conteúdo do Bloco da rede L2 p2p e criará a Prova para os blocos com maior VDF Score. A construção da prova também adota o método de vários provadores colaborando em paralelo (semelhante ao esquema B52).
Portanto, o Sequencer precisa agregar Proofs correspondentes a várias transações diferentes em um Block Proof (incluindo VDF Proof) no final e enviá-lo ao contrato Rollup de L1. Qualquer pessoa pode enviar Conteúdo de Bloco que tenha enviado Prova de Bloco para o contrato Rollup.
Finalização: é necessário enviar uma transação L1 para Finalizar o bloco.Um bloco que pode ser finalizado precisa ser satisfeito: Conteúdo do Bloco e Prova do Bloco são enviados, e o bloco anterior apontado deve ser Finalizado. Com base no cumprimento das condições acima, você também deve ter a pontuação mais alta.
Mecanismo de produção de blocos pipeline: Note-se que a Fernet adota um mecanismo de produção de blocos pipeline. Terminada a fase de Proposta do bloco N, inicia-se a Proposta do bloco N+1 (Aptos e outras cadeias públicas também têm práticas semelhantes) . Mas para o N+1º bloco, ele precisa esperar que o Nº bloco seja finalizado antes de poder enviar a transação L1 Final Block e passar na verificação para se tornar um Final Block.
Dimensões potenciais de ataque: Se o Sequenciador com o VDF Score mais alto deliberadamente não transmitir o Conteúdo do Bloco em L2 p2p, isso pode levar à reorganização do bloco.
Cálculo do número de blocos L2 em reorganização: 1+PROVING_PHASE_L1_BLOCKS / PROPOSTA_PHASE_L1_BLOCKS =1+50/2=26 blocos
Solução: Aumente o mecanismo de bloco tio para evitar ter apenas um bloco candidato completo para cada L2slot (slot de geração de bloco).
A importância da Fernet em termos de descentralização: o Sequencer se junta ao Sequencer Committee comprometendo-se com 16 ETH, e o limite de entrada não é alto (mas não baixo). O Provedor não exige nenhum penhor, mas não há penalidade se o Provedor não gerar Prova. Isso é basicamente o oposto do esquema B52.
**Vivabilidade ativa: **A vivacidade da rede geral pode ser garantida, porque o mecanismo de bloco VDF+uncle pode garantir que haja mais de um produtor de bloco em cada rodada.
**MEV: **As considerações do MEV são as mais especiais.O plano planeja introduzir o PBS, para que depois de calcular uma alta pontuação VDF como um sequenciador, você possa encontrar diretamente um construtor de bloco para construir um bloco mais valioso.
**Resistência à censura: **Fernet também adotará o mesmo mecanismo PBS do Ethereum, então, em essência, o problema anti-censura de Fernet é equivalente ao do PBS do Ethereum.
Ver original
O conteúdo serve apenas de referência e não constitui uma solicitação ou oferta. Não é prestado qualquer aconselhamento em matéria de investimento, fiscal ou jurídica. Consulte a Declaração de exoneração de responsabilidade para obter mais informações sobre os riscos.
Analisando a proposta B52 da Aztec Labs: como o ZK-Rollup realiza a descentralização dos nós do sequenciador?
Autor: 0xhhh, EthStorage
Editor: Fausto, Geek web3
Introdução: Desde que o Rollup se tornou popular, a descentralização do Sequencer sempre foi o foco da comunidade Ethereum/Celestia, e também é uma montanha intransponível na pesquisa e desenvolvimento do Layer2. A esse respeito, diferentes esquemas de Rollup propuseram ideias sobre a descentralização de nós, fornecendo um espaço de imaginação extremamente amplo para esse tópico.
O autor deste artigo toma como exemplo o conhecido projeto ZKRollup Aztec, e usa as duas propostas denominadas B52 e Fernet propostas recentemente pelo Aztec Labs como ponto de partida para analisar como o ZKR realiza a descentralização dos nós do sequenciador para os leitores.
Proposta B52: Esquema de sequenciador sem permissão
A proposta B52 pretende alcançar o seguinte (idealmente):
Rede sequenciadora descentralizada, os próprios nós L2 elegem cada rodada de proponentes
Rede de provador descentralizada, baixos requisitos de hardware para nós de provador
Rollup tem boa resistência à censura como um todo.
O valor MEV gerado por L2 é adquirido pelos nós L2
Quando o bloco L2 é submetido à camada DA, uma finalidade mais efetiva pode ser obtida, e a finalidade irreversível tem que aguardar o envio do ValidityProof (prova de validade)
L2 Token pode ter um bom modelo econômico
Tanto os blocos L2 quanto os dados de transação são propagados na rede L2 p2p
L2 herda a segurança de L1
Este esquema divide todo o processo de produção do bloco L2 em três estágios de tempo:
Entre eles, o estágio BPW (block proposto) é um processo no qual vários sequenciadores Seuqnecer propõem diferentes blocos e competem, e o Prover seleciona um bloco candidato para dar uma votação.
BAW (Block Acceptance) é o processo no qual o Provedor constrói uma Prova de Validade para um bloco e a envia.
Janela de proposta de bloco (fase de proposta de bloco):
O BPW pode ser subdividido em três etapas: Proposta em Bloco, Votação em Bloco, Agregação.
Qualquer pessoa na fase de Block Proposal (BP) pode coletar transações e transmitir seu próprio conteúdo de BP. O conteúdo do BP conterá três partes: hash do pedido txs, porcentagem de recompensa do provador, valor do token de queima
txs order hash: O proponente seleciona e classifica o lote de transações mais valioso do pool de transações L2 (mempool) e, em seguida, coloca o valor de hash desse lote de transações no bloco que ele constrói.
porcentagem de recompensa do provador: a porcentagem de recompensa do bloco compartilhada pelo sequenciador para o provador
quantidade de token de queima: O número de Token Nativo L2 proposto pelo Proponente para ser destruído e, em seguida, envia o BP proposto para a rede L2 p2p
Etapa de votação em bloco:
Depois que o Provedor receber o BP proposto por diferentes Proponentes na rede p2p, ele votará no BP que pode lhe render a maior recompensa. No entanto, a composição do voto é muito especial:
Vote={BlockHash, Índice da Árvore de Provas}
BlockHash é o hash da Proposta que o Provedor irá votar, e Index of Proof Tree é o valor do índice folha da Proof Tree que o Proof Tree irá construir (explicado mais adiante)
Agregação de agregação: O Proponente coleta os votos dos Provedores para BP na rede L2 p2p, os agrega e os coloca no BP, e os envia para L1 (cada BP geralmente contém apenas registros de votação relacionados a ele mesmo).
Aqui, é necessário enfatizar os pré-requisitos para que o BP seja selecionado e incluído no livro Rollp:
Ter a pontuação mais alta:
SCORE(y) = NUM_PROVERS (x)^3 * BURN_BID(z)^2
NUM_PROVERS (x) é o número de votos do Prover obtido pelo BP, e BURN_BID é o número de Tokens L2 propostos para serem destruídos pelo BP. Uma vez que quanto maior for o BURN_BID, menor será a recompensa que o proponente do BP receberá no final, portanto, esse valor deve ser definido corretamente.
Ao mesmo tempo, o BP precisa ser submetido ao L1 antes do final da Janela de Proposta de Bloco, e o respectivo comprovante de validade deve ser carregado no L1 antes do final da Janela de Aceitação do Bloco.
Nota: No cálculo das pontuações de BP, o número de votos representa a maior proporção, seguido pelo número de fichas de queima. Ao mesmo tempo, o esquema B52 permite que vários proponentes (na verdade, sequenciadores) concorram por uma cota efetiva de BP
O esquema B52 exige apenas que o Proponente (sequenciador) especifique o número de tokens de gravação em seu próprio BP (semelhante ao método de EIP1559) sem tokens de participação antecipadamente, o que pode tornar a rede mais sem permissão (sem permissão de acesso) e é também benéfico para L2 Native Token produz deflação.
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 motivo é semelhante ao esquema Ethereum PBS, que visa impedir que o MEV seja espionado por outros proponentes.
Explicação detalhada da Janela de aceitação do bloco (fase de aceitação do bloco):
Após o término da Janela de Proposta de Bloco, o Provedor precisa revelar os dados completos da transação correspondente ao seu PN. Caso seja selecionado o PB votado pelo Provedor (a maior pontuação pode ser consultada através do contrato L1), ele deverá construir a SubProof Tree correspondente ao Índice de Proof Tree dado durante a votação.
Assumindo que o bloco do Aztec contém 2^13=16384 transações e há 2048 provadores, então cada provador constrói uma árvore de subprova que consiste em 2^3=8 transações. Em seguida, o provador transmite a árvore de subprova construída por ele mesmo para In the L2 p2p rede. Depois que o proponente o receber, ele agregará todas as árvores de subprovas em uma prova em bloco.
Em seguida, o Proponente envia a prova agregada ao contrato L1 Rollup, e o contrato verificará a exatidão da prova e os resultados da transição de estado correspondente. Ressalte-se aqui que se o Provedor deixar deliberadamente de apresentar a comprovação, não só não conseguirá obter o dividendo de recompensa em bloco prometido pela Proponente, como também será cortado, pois para se tornar Provedor precisa penhor Token com antecedência. Portanto, ao contrário do Proposer (Sequencer), o Prover não é sem permissão.
Explicação detalhada dos Avanços de Estado (estágio de avanço de estado):
Após o término da Janela de Aceitação de Bloco, o contrato de Rollup selecionará um bloco com a maior pontuação para ser incluído no livro Rollup, e enviará a Recompensa de bloco ao Proponente e Provedor respectivamente de acordo com a proporção declarada pelo Proponente (Sequenciador) em avançar.
A descrição acima é a solução B52 da Aztec. No entanto, o autor deste artigo acredita que existem alguns problemas potenciais com a proposta B52:
Questão 1: Se a prova de validade do bloco com maior pontuação estiver incompleta. A solução dada na proposta é que, se o Proponente fornecer apenas 50% da prova, ele poderá obter apenas 50% das recompensas do bloco, de modo a garantir que o Proponente não tenha motivação para deliberadamente não enviar uma prova completa. Ao mesmo tempo, o Provedor também pode enviar a prova diretamente ao contrato.
De acordo com a descrição da proposta, é aceitável aceitar um bloco sem comprovação de validade de transações completas. Na verdade, isso não é razoável: porque: zkrollup apenas declara que o novo estado correspondente a este bloco é válido quando a prova de validade é fornecida.
Se a prova agregada enviada pelo proponente para L1 estiver faltando a prova de uma determinada transação, é óbvio que as provas de transição de estado de todas as transações que ocorrem após essa transação são inválidas (porque as transações são executadas sequencialmente e possuem dependências de estado), nós Também é impossível confirmar se o novo estado correspondente a este bloco é válido.
Portanto, neste momento, o caminho razoável deve ser entrar na Janela de Aceitação de Blocos que aguarda infinitamente até que todos os comprovantes da transação sejam enviados.
Questão 2: **Se o bloco com maior pontuação for um bloco ilegal (isso não é explicado no esquema B52). **BP contém apenas o hash da sequência da transação, portanto, um proponente mal-intencionado pode, na verdade, construir deliberadamente transações problemáticas, como transações de gasto duplo. Então, neste momento, é realmente necessário adicionar uma função no contrato L1 para que qualquer pessoa possa enviar uma prova ilegal, usada para provar que o BP com maior pontuação é um bloco ilegal.
E esse tipo de relatório deve ser recompensado, podemos recompensar o token de queima enviado pelo proponente do contrato ao nó repórter que enviou a prova ilegal.
**Pensamento interessante:**Sobre tios bloqueados e trabalho de provador redundante: o esquema B52 realmente usará outros BPs (que enviaram provas completas) que aparecem nesta rodada como tios depois que o BP com a pontuação mais alta em cada rodada aparecer. bloco, atribua uma certa recompensa de bloco de tio.
Na verdade, isso segue a abordagem do mecanismo de consenso ETH POW. Para evitar a concentração excessiva de poder de computação, é necessário alocar uma parte das recompensas de bloco para proponentes de blocos não aceitos (mineradores) para proteger os interesses de pequenos pools de mineração/mineradores individuais e evitar O poder de computação é monopolizado por grandes pools de mineração. Portanto, também é uma escolha muito inteligente adotar o mecanismo de bloco tio que o Ethereum tem bom desempenho.
O significado da proposta B52 em termos de descentralização do Rollup: O proponente é descentralizado e não requer penhor, e o limite de entrada é baixo; mas porque você mesmo precisa construir os blocos mais valiosos e precisa coletar votos de outros Proponentes e agregar todas as Provas. Na verdade, o limite de hardware do Proponente não é tão baixo quanto declarado na proposta (por exemplo, a largura de banda pode não ser muito baixa).
Portanto, acabará se tornando uma rede relativamente centralizada, semelhante ao Mev-Boost Builder, porque o proponente que pode finalmente gerar blocos geralmente é o Block Builder que é melhor na captura de MEV.
Ao mesmo tempo, o Prover no esquema B52 precisa penhorar ativos, mas como apenas a prova de subárvore precisa ser gerada, em comparação com os esquemas que precisam gerar completamente toda a prova de bloco, **O grau de descentralização do Provedor será melhor (os requisitos de hardware podem ser reduzidos). **
Liveness ativo: O Liveness geral da rede é bom, porque o L2 tem sua própria rede p2p para transmitir transações e votos/BP, e o Sequencer e o Prover são relativamente descentralizados. Mas precisamos resolver os dois problemas que mencionamos acima. Um é que o bloco com a maior pontuação deve ser um bloco legal, e o segundo é que ele precisa 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 funcione mal (downtime) devido à falta de uma determinada parte da prova tx.
**Resistência à censura: **Se pudermos garantir que qualquer pessoa pode publicar a proposta de bloqueio BP e garantir que não apenas o proponente possa enviar a prova de bloqueio, a rede terá boa resistência à censura.
**Finalidade: **A finalidade do L2 está intimamente relacionada com a vivacidade da rede, pois a finalidade final verificada ainda precisa aguardar o envio do Block Proof, mas na verdade você também pode confiar no conteúdo do bloco correspondente a um BP com a pontuação mais alta (desde que não contenha transações maliciosas).
Este bloco será revelado no início da Janela de Aceitação de Bloco, o que significa que como usuário, você só precisa aguardar uma Janela de Proposta de Bloco, e o bloco onde a transação que você enviou pode ser aceita.
Herdar segurança L1: Como um L2 que atualiza seu status enviando prova de validade, pode herdar a segurança de L1.
Proposta Fernet: Apresentar VDF para selecionar Proponente legal
Introdução do esquema Fernet: Através do VDF, em cada rodada do ciclo de geração de blocos, uma pontuação estimada é definida para diferentes nós no Comitê (ou seja, o conjunto de nós do Sequencer), e o bloco proposto pelo Sequencer com o maior pontuação final se tornará peça válida.
**Primeiro, como ingressar no Comitê? Na verdade, você precisa prometer 16 ETH em L1, **e aguardar 4 blocos L1 após a conclusão da operação de penhora e, em seguida, ingressar no Comitê do Sequenciador. Quanto à saída do Sequencer Committee, você precisa chamar a função Unstake no contrato L1 e, em seguida, poderá recuperar o valor restante de sua promessa após mais 3 dias.
Então, o que é um VDF? A função de atraso verificável é uma função de atraso verificável. Esta função matemática satisfaz características de execução serial estritas. Ela executará algumas etapas de cálculo e consumirá pelo menos um período de tempo previsível. Registramos o valor calculado pelo VDF como Score, que satisfaz uma distribuição normal uniforme, portanto, após o Sequencer calcular o VDF Score, ele pode julgar a probabilidade de ser selecionado como proponente legal. **
O VDF do sequenciador é calculado da seguinte forma:
Pontuação = VDF (chave privada, entradas públicas)
entradas públicas = { número do bloco atual , randao }
randao é um número aleatório usado para evitar que o Sequencer calcule sua própria Pontuação VDF em todas as alturas de bloco futuras com antecedência
Todo o processo da Fernet é dividido principalmente em 3 etapas:
**Fase da proposta:**PROPOSTA_PHASE_L1_BLOCKS = 2 blocos Ethereum (esta fase durará 2 blocos L1)
No início desta etapa, cada sequenciador usará o VDF para calcular seu VDF Score correspondente na altura do bloco atual. Se o Sequencer achar que seu VDF Score provavelmente ganhará o direito de produzir um bloco desta vez (supondo que o Score satisfaça uma distribuição normal), ele enviará um contrato Rollup da Proposta para L1. A proposta contém: o hash da sequência da transação, apontando para qual bloco L2 anterior.
bloco não comprovado: Somente o conteúdo do bloco da Proposta para o contrato Rollup é enviado. Em seguida, **Sequencer precisa enviar o conteúdo do bloco correspondente ao bloco não comprovado e a prova de VDF para a rede L2 p2p. **
ProvingFase: PROVING_PHASE_L1_BLOCKS= 50 blocos L1 (esta fase manterá 50 blocos L1, cerca de 10 min)
O Provedor recebe todas as transações correspondentes no Conteúdo do Bloco da rede L2 p2p e criará a Prova para os blocos com maior VDF Score. A construção da prova também adota o método de vários provadores colaborando em paralelo (semelhante ao esquema B52).
Portanto, o Sequencer precisa agregar Proofs correspondentes a várias transações diferentes em um Block Proof (incluindo VDF Proof) no final e enviá-lo ao contrato Rollup de L1. Qualquer pessoa pode enviar Conteúdo de Bloco que tenha enviado Prova de Bloco para o contrato Rollup.
Finalização: é necessário enviar uma transação L1 para Finalizar o bloco.Um bloco que pode ser finalizado precisa ser satisfeito: Conteúdo do Bloco e Prova do Bloco são enviados, e o bloco anterior apontado deve ser Finalizado. Com base no cumprimento das condições acima, você também deve ter a pontuação mais alta.
Mecanismo de produção de blocos pipeline: Note-se que a Fernet adota um mecanismo de produção de blocos pipeline. Terminada a fase de Proposta do bloco N, inicia-se a Proposta do bloco N+1 (Aptos e outras cadeias públicas também têm práticas semelhantes) . Mas para o N+1º bloco, ele precisa esperar que o Nº bloco seja finalizado antes de poder enviar a transação L1 Final Block e passar na verificação para se tornar um Final Block.
Dimensões potenciais de ataque: Se o Sequenciador com o VDF Score mais alto deliberadamente não transmitir o Conteúdo do Bloco em L2 p2p, isso pode levar à reorganização do bloco.
Cálculo do número de blocos L2 em reorganização: 1+PROVING_PHASE_L1_BLOCKS / PROPOSTA_PHASE_L1_BLOCKS =1+50/2=26 blocos
Solução: Aumente o mecanismo de bloco tio para evitar ter apenas um bloco candidato completo para cada L2slot (slot de geração de bloco).
A importância da Fernet em termos de descentralização: o Sequencer se junta ao Sequencer Committee comprometendo-se com 16 ETH, e o limite de entrada não é alto (mas não baixo). O Provedor não exige nenhum penhor, mas não há penalidade se o Provedor não gerar Prova. Isso é basicamente o oposto do esquema B52.
**Vivabilidade ativa: **A vivacidade da rede geral pode ser garantida, porque o mecanismo de bloco VDF+uncle pode garantir que haja mais de um produtor de bloco em cada rodada.
**MEV: **As considerações do MEV são as mais especiais.O plano planeja introduzir o PBS, para que depois de calcular uma alta pontuação VDF como um sequenciador, você possa encontrar diretamente um construtor de bloco para construir um bloco mais valioso.
**Resistência à censura: **Fernet também adotará o mesmo mecanismo PBS do Ethereum, então, em essência, o problema anti-censura de Fernet é equivalente ao do PBS do Ethereum.