Este documento foi motivado pelo nosso trabalho no Especificação de consenso FOCIL 23, onde percebemos que o protocolo exigia uma consideração mais ponderada em torno das restrições de recursos, uma vez que certos detalhes não estavam explicitamente especificados no FOCIL Ethereum pesquisa post 14.

Pré-requisito

Antes de começarmos, assumimos a seguinte configuração para estabelecer uma linha de 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 a assumir a construção e lançamento a solo de blocos, onde o proponente não está a executar o MEV-Boost. Este é o primeiro componente chave a acertar, enquanto a API do Builder é uma consideração secundária
• Estamos a assumir uma configuração de staker a solo com requisitos típicos de computação, memória e largura de banda que pode facilmente seguir 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), que são responsáveis por restringir o próximo proponente do 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
• Nós, que estão a verificar e a seguir a cadeia. Proposers e attesters fazem parte dos nós que têm Ether em jogo

Cronologia

Assumimos a seguinte linha do tempo em que 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: Os Attesters e nós verificadores 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 a carga útil que deve satisfazer o requisito IL
• Slot n, t=4: Os Attesters para o slot n votam no bloco B, verificando a agregação IL comparando-a com suas visões locais de IL e confirmando se o bloco B é “válido”
  • Sobrecarregamos a palavra "válido" ao nos referirmos a um bloco, mas poderia significar "importável", "canônico" ou algo mais. Consulte a pergunta aberta para mais esclarecimentos

Intervalo 1: Comité IL Lança IL Local

Ator: Comité de Lista de Inclusão

Membros do comité IL recuperam uma lista de transações IL do cliente EL dado o cabeçalho (chamada CL → EL), depois assinam o IL local (transações + resumos) e libertam-no para a rede de gossip.

Considerações de Recursos

• A recuperar transações IL da mempool EL → CPU/MEM
• Assinando a lista de inclusão → CPU
• Carregar a lista de inclusão na rede de fofocas → Largura de banda (Carregar)

Ator: Nós (incluindo Verificadores)

Os nós que seguem a cadeia farão download do IL, verificam-no para anti-DOS (ainda não o importam para EL) e encaminham-no para outros pares. Os nós também importam o IL para a escolha do garfo e rastreiam quais ILs foram vistos usando uma cache aggreGate. Os atestantes e os nós que seguem a cadeia devem ter a mesma visão da cadeia.

Considerações sobre recursos

• A transferir 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 monitoriza ativamente a rede de fofocas IL, recolhe e agrega os ILs locais e, em seguida, no corte de agregação de IL (intervalo #2), o proponente atualiza o processo de construção de blocos com uma lista de transações IL a serem incluídas no 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 do Proponente

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 viu, o proponente precisará solicitar manualmente o bloco beacon ausente, importar o bloco e construir em cima desse bloco.

Conclusão

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

• Impacto na CPU do Comitê de IL: recuperação de transação de IL de EL & assinatura: embora haja demandas de recursos aqui, presume-se que isso seja relativamente barato e não seja uma preocupação principal.
• Impacto na largura de banda dos nós: Os nós que fazem download e upload de ILs podem usar toneladas de largura de banda, especialmente porque a pesquisa atualmente afirma que o tamanho da lista de inclusão é flexível/ilimitado. Isso introduz um potencial risco de DOS, já que um membro malicioso do comitê de IL poderia inundar a rede com um grande número de transações, mesmo que sejam inválidas. Os nós ainda fariam a disseminação das ILs antes de importá-las. Medidas contra DoS precisam ser consideradas cuidadosamente.

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

Ator: Propositor

O proponente atualiza o processo de construção de blocos 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 sobre Recursos

• Bloquear vista da lista de inclusão local → Nenhum

Conclusão

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

Intervalo 3: Proposer libera 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 beacon. Em seguida, todos os outros verificam o bloco.

Considerações de Recursos

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

Ator: Nós

Os nós recebem o bloco de farol e verificam-no. As novas etapas de verificação incluem a verificação da construção da lista de inclusão aggreGate e a confirmação de 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 ou não ser ignoradas devido a conflitos) será realizada no EL.

Considerações sobre recursos

• Verificando se a lista de inclusão está satisfeita em CL → CPU
• Verificação das condições da lista de inclusão em EL → CPU

Conclusão

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

Intervalo 4: Comité de Attesters

Ator: Attester

O atestante vota no bloco da beacon usando a regra de escolha de bifurcação LMD GHOST. Os atestantes só votarão em um bloco de beacon que satisfaça a função de avaliação da lista de inclusão, com base em observações do Intervalo 1.

Considerações de Recursos

• Attestadores votando para um bloco que satisfaça 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.

Sumário de Consideração de Recursos

Como visto acima, as preocupações mais significativas com os recursos giram em torno do upload, download e o potencial de spam de uma perspectiva do nó. Outra preocupação chave é o overhead nos nós para verificar e importar a lista de inclusão, bem como a necessidade do proponente de atualizar o processo de construção de blocos para satisfazer a lista de inclusão. Estes aspectos requerem uma consideração cuidadosa e um design para garantir eficiência e segurança.

Perguntas em Aberto

Com base no exposto, delineamos várias questões em aberto que influenciarão a forma como a especificação é escrita:

1. Bloco que não satisfaz 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 aos blobs e não pode ser importado?
   • Não deveria 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ê da lista de inclusão envia versões diferentes da lista de inclusão para nós diferentes, e todos eles são propostos em toda a rede, quais são as consequências dessa ação? Como esse comportamento poderia impactar negativamente o proponente construindo o próximo bloco?
3. Proponente já a construir numa cabeça diferente: Se o proponente construir numa cabeça diferente daquela enviada pelo comitê de inclusão, e assim precisar alterar a sua visualização da 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 na lista de inclusão: As transações na lista de inclusão local podem ser invalidadas de várias maneiras. Mesmo que essas transações sejam invalidadas, o bloco ainda deve ser capaz de satisfazer a função de avaliação. As transações podem ser invalidadas quando várias listas de inclusão se fundem umas com as outras ou com transações no bloco. Além da verificação típica de nonce, a abstração de conta introduz novas maneiras de invalidar transações, pois o saldo pode ser drenado com um nonce estático. Quanta simulação adicional um construtor de blocos precisa realizar devido à invalidação de transações e quanto isso afeta sua computação da CPU ainda está para ser visto tanto para atores MEV-Boost quanto para 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 está pronto para construir o aggreGate. Existem duas abordagens de design aqui, e vale a pena considerá-las mais a fundo. A primeira abordagem é 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 é 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é mesmo mais cedo. A questão é se a segunda abordagem justifica a otimização para permitir que o proponente libere o aggreGate da 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 [ethresear]. Todos os direitos autorais pertencem ao autor original [terence]. Se houver objeções a esta reedição, por favor entre em contato com o Gate Learnequipa e eles vão lidar com isso prontamente.
2. Isenção 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 equipa Gate Learn. Salvo indicação em contrário, é proibido copiar, distribuir ou plagiar os artigos traduzidos.