EIP-8077: Relatório de Simulação de Nonce Gap – Fragmentação

Sumário executivo

Este relatório apresenta os resultados de uma simulação de Monte Carlo analisando a frequência de lacunas de nonce em um ambiente de mempool de blob fragmentado. Uma lacuna de nonce ocorre quando transações consecutivas de blob (tipo 3) do mesmo remetente são atribuídas a diferentes fragmentos no mesmo slot, potencialmente causando problemas de ordem de transação para proponentes de bloco.

Descoberta chave: Com a atribuição aleatória de fragmentos, uma percentagem significativa de transações de blob (até cerca de 36% nos piores cenários) é afetada por lacunas nonce. A frequência depende do número de fragmentos e da assimetria da distribuição da transação entre os remetentes. Isto destaca a necessidade de mecanismos aprimorados de anúncio de transações, conforme proposto no EIP-8077.

1. Motivação: Apoio ao EIP-8077

1.1 Escopo: Transações de Blob e Fragmentação de Mempool

Esta análise centra-se exclusivamente transações tipo 3 (transações blob) introduzido em EIP-4844. Examinamos especificamente a fragmentação do pool de memória do blob em vez do mempool de transação regular pelos seguintes motivos:

1. Tamanho do blob: cada blob tem 128 KB, significativamente maior que as transações regulares (normalmente <1 KB)
2. Consumo de largura de banda: A propagação de blob domina o uso da largura de banda da rede
3. Pressão de escalabilidade: À medida que a adoção de L2 cresce, a demanda por blobs aumenta, tornando a fragmentação de mempool essencial
4. Remetentes concentrados: as transações de blob vêm principalmente de sequenciadores L2 (Base, Optimism, Arbitrum, etc.), criando distribuições de remetentes altamente distorcidas

A fragmentação do mempool do blob permite que os nós assinem um subconjunto de blobs, reduzindo os requisitos de largura de banda e mantendo a conectividade da rede. No entanto, isso introduz o problema do intervalo de nonce que este estudo quantifica.

1.2 O Problema

EIP-8077 propõe estender o protocolo devp2p do Ethereum para incluir o endereço do remetente e informações de nonce em anúncios de transações. Este estudo de simulação fornece evidências quantitativas de por que esse aprimoramento é necessário.

Em um mempool de blob fragmentado, as transações de blob do mesmo remetente (por exemplo, um sequenciador L2) podem ser distribuídas em diferentes fragmentos ou chegar em momentos diferentes. Quando um proponente de bloco recebe transações de blob, ele precisa:

1. Ordenar transações corretamente por nonce para cada remetente
2. Identifique lacunas de uso único que tornaria as transações temporariamente inincluíveis
3. Priorizar a busca transações que preenchem lacunas em relação àquelas que criam novas

Sem informações de remetente e nonce nos anúncios, os nós devem:

• Buscar transações cegamente, arriscando lacunas nonce
• Use tentativa e erro ineficientes para preencher lacunas
• Manter grandes caches de hash de transações
• Perder oportunidades de busca seletiva por endereço de origem

1.3 Por que este estudo é importante

Esta simulação quantifica o escala do problema de lacuna de nonce em condições realistas:

• Até 36% das transações pode ser afetado por lacunas nonce em cenários de alta assimetria e muitos fragmentos
• A assimetria impacta significativamente a frequência de lacunas – redes com remetentes dominantes (principais sequenciadores L2 como Base, Optimism, Arbitrum) enfrentam taxas de gap mais altas
• Análise no mesmo slot concentra-se no que é importante para os proponentes – lacunas dentro de um período de construção de bloco único

Essas descobertas demonstram que à medida que o Ethereum cresce (mais fragmentos, maior rendimento), a busca inteligente de transações se torna crítica. Os metadados do EIP-8077 permitem que os nós tomem decisões informadas sobre quais transações buscar, reduzindo o desperdício de largura de banda e melhorando a consistência do mempool.

1.4 Principais implicações para EIP-8077

2. Parâmetros de Simulação

2.1 Parâmetros Configuráveis

2.2 Valores Derivados

2.3 Configurações de fragmentos

Seis configurações de fragmentos foram testadas:

2.4 Configurações de assimetria

Seis padrões de distribuição de remetentes foram modelados usando funções de decaimento exponencial P(i) = exp(-λ * i):

3. Metodologia

3.1 Distribuição de transações ao longo do tempo

As transações são distribuídas ao longo do período de simulação com padrões aleatórios e não periódicos para simular atividades de rede realistas:

1. Ruído de base aleatório: Cada slot começa com uma taxa de transação aleatória centrada em torno da média alvo
2. Explosões aleatórias: 200 rajadas de atividades aleatórias com duração variável (50-2.000 slots) e intensidade (1,2x-2,0x)
3. Calmarias aleatórias: 100 períodos aleatórios de baixa atividade com duração variável (100-1500 slots) e intensidade (0,3x-0,7x)
4. Limite de capacidade: todos os slots são limitados a MAX_TX_PER_SLOT

Figura 1: Taxa de transação durante o período de simulação de 30 dias mostrando rajadas e calmarias aleatórias (sem periodicidade artificial).

3.2 Distribuição do Remetente

A probabilidade de uma transação ser enviada pelo remetente i segue uma distribuição exponencial:

P(sender = i) = exp(-λ * i) / Σ exp(-λ * j)

Onde λ é a taxa de decaimento que controla a assimetria.

Figura 2: Distribuição de probabilidade mostrando como a frequência das transações varia entre os remetentes para diferentes níveis de assimetria.

Figura 3: Número absoluto de transações por remetente para cada tipo de distribuição.

3.3 Distância de transação entre o mesmo remetente

Um fator importante na frequência do intervalo de nonce é a frequência com que o mesmo remetente realiza múltiplas transações no mesmo slot. Isso depende da assimetria da distribuição.

Figura 4: Distribuição das distâncias dos slots entre transações consecutivas do mesmo remetente. Distribuições mais distorcidas resultam em distâncias mais curtas (mais pares no mesmo slot).

3.4 Atribuição de Fragmentos

Cada transação é atribuída a um fragmento uniformemente ao acaso:

shard = random.randint(0, num_shards - 1)

Isto modela um cenário em que a atribuição de fragmentos é independente da identidade do remetente.

3.5 Medição de Gap Nonce

Decisão Crítica de Design: contamos apenas intervalos de nonce entre transações consecutivas do mesmo remetente que ocorrem dentro do mesmo slot. Isso ocorre porque:

• Diferentes slots são construídos por diferentes proponentes
• Um proponente só se preocupa com lacunas de nonce dentro de seu próprio bloco
• As lacunas entre slots são irrelevantes para a construção de blocos

A métrica que medimos é:

Nonce Gap Frequency = (Shard Switches in Same-Slot Pairs) / (Total Transactions)

Isto representa o porcentagem de todas as transações envolvidas em um intervalo de nonce no mesmo slot.

4. Resultados

4.1 Mapa de calor de frequência de intervalo Nonce

Figura 5: Mapa de calor mostrando a frequência de intervalo de uso único (como porcentagem do total de transações) em todas as configurações de fragmentos e assimetria.

4.2 Resultados Numéricos

4.3 Padrões Chave

1. Padrão vertical (mais fragmentos): O aumento de fragmentos aumenta a frequência do intervalo, mas com retornos decrescentes
2. Padrão horizontal (mais assimetria): Maior assimetria aumenta drasticamente a frequência do intervalo
3. Pior caso: Assimetria muito alta + 32 fragmentos = aproximadamente 36% das transações afetadas
4. Melhor caso: Distribuição uniforme + 2 fragmentos = ~3,6% das transações afetadas

5. Análise

5.1 Por que a assimetria é importante

Ao contrário da nossa hipótese inicial, a assimetria afeta significativamente a frequência do intervalo nonce. Isso ocorre porque:

1. Distribuições distorcidas concentram transações entre menos remetentes
2. Remetentes concentrados têm mais pares consecutivos no mesmo slot
3. Mais pares no mesmo slot = mais oportunidades para lacunas nonce

Com distribuição uniforme, as transações de blob são espalhadas por 100 remetentes, tornando raros os pares consecutivos no mesmo slot do mesmo remetente. Com assimetria muito alta (refletindo uma rede dominada pelos principais sequenciadores L2 como o Base), alguns remetentes dominantes produzem muitos pares consecutivos no mesmo slot, cada um com uma probabilidade (N-1)/N de ser um gap.

5.2 Por que isso é compatível com EIP-8077

5.3 Implicações para Diferentes Condições de Rede

6. Conclusões

6.1 Principais conclusões

1. As lacunas de nonce são um problema significativo: até 36% das transações podem ser afetadas em cenários de alta assimetria e muitos fragmentos.

2. A distorção é um fator importante: Redes com remetentes de blob dominantes (principais sequenciadores L2 como Base, Optimism, Arbitrum) enfrentam taxas de gap substancialmente mais altas do que redes com distribuição uniforme de transações.

3. A fragmentação agrava o problema: Mais fragmentos = mais lacunas, seguindo a probabilidade (N-1)/N para cada par do mesmo slot.

4. A análise do mesmo slot é crítica: focar no que é importante para os proponentes (lacunas na janela de construção de blocos) fornece insights acionáveis.

6.2 Suporte para EIP-8077

Esta simulação fornece forte suporte quantitativo para EIP-8077:

• O problema é real: Uma percentagem significativa de transações é afetada por lacunas nonce
• O problema é escalonável: Piora à medida que Ethereum adiciona mais fragmentos/rendimento
• A solução é direcionada: Os metadados do remetente/nonce permitem a busca inteligente
• O benefício é mensurável: Os nós podem reduzir o desperdício de largura de banda e melhorar a eficiência da construção de blocos

6.3 Recomendações

1. Adote EIP-8077 para fornecer aos nós os metadados necessários para busca inteligente de transações de blob
2. Priorize os principais sequenciadores L2 ao buscar para manter sequências nonce completas para remetentes de blob de alto volume
3. Considere a atribuição de fragmentos com reconhecimento de remetente como uma estratégia complementar para reduzir lacunas ao nível do protocolo

7. Trabalho Futuro

• Simule o impacto dos metadados do EIP-8077 na eficiência de busca
• Modele diferentes estratégias de busca habilitadas pelas informações do remetente/nonce
• Analise padrões reais de transação da rede principal Ethereum para calibração de assimetria
• Considere cenários de rebalanceamento dinâmico de fragmentos
• Estude a interação com outras soluções de escalonamento (rollups, amostragem de disponibilidade de dados)

Apêndice: Estrutura do Código

O código pode ser encontrado aqui: eth-research/EIP-8077 em main · migalabs/eth-research · GitHub

A simulação é implementada em EIP-8077/simu.py com os seguintes componentes:

Parâmetros Configuráveis (no topo de EIP-8077/simu.py):

NUM_SLOTS = 216000        # 30 days worth of slots
AVG_TX_PER_SLOT = 14      # Target average transactions per slot
MAX_TX_PER_SLOT = 21      # Maximum transactions per slot
NUM_SENDERS = 100         # Number of unique senders

Dependências: numpy, matplotlib, aleatório