Este documento foi motivado pelo nosso trabalho no Gate.Especificação de consenso FOCIL 23, onde percebemos que o protocolo exigia mais consideração cuidadosa em torno das restrições de recursos, já que certos detalhes não foram explicitamente especificados no Post de pesquisa Ethereum FOCIL 14.

Pré-requisito

Antes de começarmos, pressupomos a seguinte configuração para estabelecer uma base limpa para nossas considerações:

• A configuração é baseada no hard fork Electra. Também faz sentido revisitar isso em cima do EIP-7732 (ePBS) para comparação
• Estamos assumindo a construção e lançamento de blocos solo, onde o proponente não está executando o MEV-Boost. Este é o primeiro componente chave para acertar, enquanto a API do Construtor é uma consideração secundária
• Estamos assumindo uma configuração de staker solo com requisitos de computação, memória e largura de banda típicos que você pode seguir facilmente na cadeia Ethereum hoje

Atores

Antes de prosseguirmos, assumimos que os seguintes atores fazem parte do protocolo e analisamos suas responsabilidades:

• Membros do comitê da Lista de Inclusão (IL), responsáveis por restringir o próximo proponente de slot por seu conjunto de transações da lista de inclusão
• O proponente, que é responsável por propor o próximo slot
• Atestadores, que estão atestando para o próximo slot para o cabeça da cadeia
• Nodes, que estão verificando e seguindo a cadeia. Proposers e Attesters fazem parte dos nós que apostaram Ether

Linha do tempo

Assumimos a seguinte linha do tempo na qual o comitê IL, o proponente e os atestadores realizam algumas ações honestas:

• Slot n-1, t=6: A comissão IL publica suas Listas de Inclusão locais (ILs) sobre um tópico global após aprender o conteúdo do bloco n-1
• Slot n-1, t=9: Attesters e nós de verificação honestos bloqueiam sua visão das ILs locais
• Slot n, t=0: O proponente de bloco para o slot n libera o bloco B, que inclui o payload que deve satisfazer o requisito IL
• Slot n, t=4: Attesters for slot n vote on block B, verifying the IL aggregation by comparing it to their local IL views and confirming whether block B is “valid”
  • Sobrecarregamos a palavra "válido" ao nos referirmos a um bloco, mas poderia significar "importável," "canônico" ou algo mais. Veja a pergunta aberta para mais esclarecimentos

Intervalo 1: Comitê de IL Libera IL Local

Ator: Comitê de Lista de Inclusão

Os membros do comitê de IL recuperam uma lista de transações de IL do cliente EL dado o chefe (chamada CL → EL), depois assinam a IL local (transações + resumos) e a liberam para a rede de fofocas.

Considerações de Recursos

• Recuperando transações IL da mempool EL → CPU/MEM
• Assinando a lista de inclusão → CPU
• Carregando a lista de inclusão para a rede de fofocas → Largura de banda (Upload)

Ator: Nodes (incluindo Attesters)

Nodes que seguem a cadeia irão baixar o IL, verificá-lo para anti-DOS (não importando-o para EL ainda), e encaminhá-lo para outros pares. Nós também importamos o IL na escolha de ramificação e rastreamos quais ILs foram vistos usando um cache aggreGate. Os atestadores e nós que seguem a cadeia devem ter a mesma visão da cadeia.

Considerações de Recursos

• Baixando o IL → Largura de Banda (Download)
• Encaminhando o IL → Largura de banda (Upload)
• Verificando o IL para anti-DOS → CPU/MEM
• Caching visto e aggreGate ILs → MEM

Ator: Proponente

O proponente para o próximo slot monitora ativamente a rede de fofocas IL e, coleta e agrega os ILs locais, então, no corte de agregação de IL (intervalo #2), o proponente atualiza o processo de construção de bloco com uma lista de transações de IL a serem incluídas para seu bloco. Isso requer uma chamada de CL para EL.

Considerações de Recursos

• Herda os mesmos custos que os nós que seguem a cadeia

Caso Limite de Proposição

Se o proponente do próximo slot observar um número suficiente de listas de inclusão com base em um hash pai que não tenha visto, o proponente precisará solicitar manualmente o bloco do beacon em falta, importar o bloco e construir em cima desse bloco.

Conclusão

Com base no acima, podemos identificar áreas potencialmente intensivas em recursos e focar nelas:

• Impacto da CPU do Comitê IL: recuperação de transação IL de EL e assinatura: embora haja demanda de recursos aqui, isso é presumido como relativamente barato e não uma preocupação maior.
• Impacto da largura de banda dos nós: Os nós que baixam e carregam ILs podem usar toneladas de largura de banda, especialmente a publicação atual de pesquisa afirma que o tamanho da lista de inclusão é flexível/ilimitado. Isso introduz um potencial risco de DOS, pois um membro malicioso do comitê IL poderia inundar a rede com um grande número de transações, mesmo que sejam inválidas. Os nós ainda fofocariam sobre o IL antes de importar os ILs. Medidas anti-DoS precisam ser consideradas cuidadosamente.

Intervalo 2: Os nós bloqueiam sua visão, o proponente importa transações IL

Ator: Proponente

O proponente atualiza o processo de construção de bloco com uma lista de transações de lista de inclusão. Este é um chamado CL → EL.

Considerações de Recursos

• Atualiza o processo de construção de blocos com uma lista de transações de lista de inclusão → CPU / MEM

Ator: Nós (incluindo Attesters)

Visualização da lista de inclusão de bloqueio. Pare de aceitar a lista de inclusão local a partir deste ponto.

Considerações de Recursos

• Visualização da lista de inclusão local bloqueada → Nenhuma

Conclusão

• Impacto na CPU do proponente: Importar as transações IL no processo de construção de blocos pode interromper o processo de construção de blocos, potencialmente sobrecarregando a CPU do cliente da camada de execução durante a simulação de transações. Isso pode se tornar complicado sob a abstração de contas, já que as transações podem se invalidar mutuamente. Isso deve ser analisado mais a fundo.

Intervalo 3: Proposer Lança Bloco

Ator: Proponente

O proponente recupera a carga de execução do cliente EL (chamada CL → EL) e a libera para a rede de gossip do bloco do farol. Em seguida, todos os outros verificam o bloco.

Considerações de Recursos

• Recuperando a carga útil do cliente EL → CPU/MEM

Ator: Nodos

Os nós recebem o bloco de farol e o verificam. As novas etapas de verificação incluem a verificação da construção do aggrEGate e a confirmação se a lista de inclusão satisfaz a função de avaliação, que será concluída no CL. A verificação das condições do IL (se podem ser ignoradas devido a conflitos ou não) será realizada no EL.

Considerações de recursos

• Verificando se a lista de inclusão é satisfeita em CL -> CPU
• Verificando as condições da lista de inclusão em EL → CPU

Conclusão

Os deveres adicionais para o proponente não parecem ser uma preocupação significativa. As novas etapas de verificação para nós — verificar se a lista de inclusão atende às condições satisfatórias — podem introduzir alguma carga adicional de CPU, mas não parece ser um grande problema.

Intervalo 4: Comitê Attester

Ator: Attester

O atestador vota para o bloco do farol usando a regra de escolha de fork LMD GHOST. Os atestadores só votarão em um bloco do farol que satisfaça a função de avaliação da lista de inclusão, com base nas observações do Intervalo 1.

Considerações de Recursos

• Attestadores votando por um bloco que satisfaz a função de avaliação da lista de inclusão → Sem custo adicional

Conclusão

Não há diferença em relação a hoje.

Resumo de Consideração de Recursos

Como visto acima, as preocupações mais significativas em relação aos recursos giram em torno do upload, download e potencial de spam de uma lista de inclusão do ponto de vista de um nó. Outra preocupação chave é a sobrecarga nos nós para verificação e importação da lista de inclusão, bem como a necessidade do proponente de atualizar seu processo de construção de blocos para satisfazer a lista de inclusão. Esses aspectos requerem consideração cuidadosa e design para garantir eficiência e segurança.

Perguntas Abertas

Com base no exposto, destacamos várias perguntas em aberto que influenciarão como a especificação será escrita:

1. Bloquear Não Satisfazendo a Função de Avaliação: Como deve ser tratado um bloco que falha na função de avaliação da lista de inclusão, e quais considerações de design entram em jogo para tais condições?
   • Deve ser tratado de forma semelhante a blobs e não pode ser importado?
   • Deveria não ser filtrado pela escolha do fork?
   • Deveria não ser válido na função de transição de estado?
2. Equívocos da Lista de Inclusão: Se um membro do comitê de lista de inclusão enviar diferentes versões da lista de inclusão para nós diferentes, e todas forem propagadas pela rede, quais são as consequências dessa ação? Como esse comportamento poderia impactar negativamente o proponente na construção do próximo bloco?
3. Proponente Já Construindo em uma Cabeça Diferente: Se o proponente construir em uma cabeça diferente daquela enviada pelo comitê de inclusão, e assim precisar mudar sua visão de cabeça, quais são as consequências dessa ação para a validade do bloco e o comportamento do proponente?
4. Invalidações de Transações da Lista de Inclusão: As transações da lista de inclusão local podem ser invalidadas de várias maneiras. Mesmo que essas transações sejam invalidadas, o bloco ainda deverá ser capaz de satisfazer a função de avaliação. As transações podem ser invalidadas à medida que várias listas de inclusão se fundem entre si ou com transações no bloco. Além da verificação de nonce típica, a abstração de conta introduz novas maneiras de invalidar transações, já que o saldo pode ser drenado com um nonce estático. Quanto mais simulação adicional um construtor de blocos precisa realizar devido à invalidação de transações e quanto isso afeta o poder de computação da CPU ainda está por ser visto tanto para os atores de MEV-Boost quanto para os construtores locais.
5. Observação do proponente da sub-rede do comitê de lista de inclusão: O proponente monitora a sub-rede do comitê de lista de inclusão para saber quando ela está pronta para construir o aggreGate. Existem duas abordagens de design aqui, e vale a pena considerá-las mais detalhadamente. A primeira abordagem é a de um proponente ganancioso, onde o proponente espera até t=9, reúne o maior número possível de ILs, envia-os para o EL e o EL atualiza seu bloco. A segunda abordagem é a de um proponente seletivo, onde o proponente espera até ter uma lista de inclusão suficiente para satisfazer a função de avaliação, envia-os para o EL e pode fazer isso em menos de t=9s ou até mais cedo. A questão é se a segunda abordagem justifica a otimização para permitir que o proponente libere o aggreGate de lista de inclusão mais cedo. A segunda abordagem pode ser adequada apenas para uma IL com seu próprio limite de gás dedicado.

Aviso Legal:

1. Este artigo é reproduzido a partir de [Gateethresear]. Todos os direitos autorais pertencem ao autor original [terence]. Se houver objeções a esta reimpressão, entre em contato com o Gate Learnequipe e eles lidarão com isso prontamente.
2. Aviso de Responsabilidade: As opiniões expressas neste artigo são exclusivamente do autor e não constituem qualquer conselho de investimento.
3. As traduções do artigo para outros idiomas são feitas pela equipe do Gate Learn. A menos que seja mencionado, copiar, distribuir ou plagiar os artigos traduzidos é proibido.