BAL (EIP-7928) é amplamente reconhecido como a "pré-condição para execução paralela" nas discussões sobre Glamsterdam. Isso não significa que todas as transações passarão a ser executadas em paralelo de imediato; na verdade, indica que as relações de acesso ao estado deixam de ser suposições implícitas e passam a ser restrições explícitas e verificáveis. Só com essas restrições claramente estabelecidas é possível garantir um agendamento estável.
Essa camada de restrição está diretamente conectada aos objetivos do upgrade descritos na Visão geral do upgrade Glamsterdam e complementa o mecanismo ePBS (EIP-7732): enquanto o ePBS define os limites para a colaboração na produção de blocos, o BAL estabelece as fronteiras para as restrições de execução. O impacto de Glamsterdam nos DApps mostra como as mudanças na camada de restrição afetam tanto o desempenho esperado das aplicações quanto a cadência de liberações.
O que é BAL (EIP-7928)?
BAL, ou Block-Level Access Lists, registra as contas e slots de armazenamento acessados durante a execução do bloco e pode incluir também resultados de estado após a execução. O objetivo não é substituir o motor de execução, mas oferecer detecção de conflitos antecipada e dados claros para preparação.
A execução serial tradicional garante consistência, mas rapidamente atinge limites de eficiência sob alta demanda. Para viabilizar a execução paralela, é preciso primeiro responder: "Quais transações entram em conflito entre si?" O BAL se destaca ao antecipar a detecção de conflitos, transferindo-a do tempo de execução para uma fase de planejamento anterior. Segundo o roteiro da Ethereum.org e o EIP-7928, o BAL é peça central do upgrade Glamsterdam.
Por que a Ethereum precisa de Block-Level Access Lists?
Com o aumento da complexidade dos blocos, se as relações de leitura/gravação de estado forem reveladas apenas dinamicamente durante a execução, os clientes terão dificuldades para planejar a execução com antecedência. Mesmo com hardware robusto, a eficiência pode ser prejudicada por conflitos de rollback e replanejamento recorrente.
As listas de acesso em nível de bloco reduzem a chance de "identificar conflitos só na execução". Com restrições claras desde o início, os clientes conseguem preparar dados, dividir tarefas e isolar conflitos, minimizando oscilações de desempenho. Para serviços de indexação e nós de arquivo, que fazem leituras intensas de estado, conhecer previamente as relações de acesso também otimiza o planejamento de I/O.
| Estágio de execução |
Sem pré-restrições |
Com restrições BAL |
| Momento da detecção de conflito |
Rollback durante execução |
Previsão antes da execução |
| Preparação de dados |
Carregamento dinâmico |
Pré-agrupamento possível |
| Estratégia de agendamento |
Baseada em experiência |
Baseada em regras |
A tabela mostra que o BAL transforma a "disponibilidade de informações", não apenas o throughput final.
Como o BAL auxilia na identificação de conflitos e otimização do agendamento?
Com a lista de acesso, clientes podem tomar decisões fundamentais: separar transações em "conjuntos paralelizáveis" e identificar "caminhos que exigem serialização". Mesmo sem paralelismo total, é possível otimizar segmentos de baixo conflito primeiro, ampliando gradualmente o escopo paralelizável.
Do ponto de vista da engenharia, o BAL não gera picos de desempenho isolados, mas aprimora a previsibilidade da execução. Para equipes de operação de nós, previsibilidade é mais valiosa que picos de curto prazo, pois impacta diretamente SLAs e resposta a incidentes. Taxas de conflito e rollback em testnets são métricas essenciais para avaliar o BAL.
| Estágio de agendamento |
Sem pré-restrições |
Com restrições BAL |
| Preparação pré-execução |
Baseada em estimativas |
Pré-agrupamento pela lista de acesso |
| Tratamento de conflitos |
Rollbacks frequentes em execução |
Isolamento antecipado de conflitos |
| Estabilidade dos resultados |
Alta variabilidade |
Resultados mais previsíveis |
| Monitoramento de operações |
Difícil definir limites |
Métricas estruturadas possíveis |
Figura 1. Ilustração do mecanismo BAL: como as listas de acesso em nível de bloco viabilizam a detecção de conflitos e o agendamento de execução paralela.
Qual a relação entre BAL e execução paralela?
O BAL não substitui a execução paralela, mas é a camada fundamental para sua implementação. Para alcançar a execução paralela, é preciso alinhar implementação do cliente, estratégias de agendamento e gerenciamento de estado. Sem essas restrições, o paralelismo forçado aumenta a incerteza.
Em resumo, o BAL torna a execução paralela um objetivo engenheirável, respondendo se os pré-requisitos estão presentes — não se o desempenho máximo já foi atingido. Mesmo com estratégias paralelas mais agressivas, as restrições do BAL continuam essenciais para o controle de conflitos.
O que muda para desenvolvedores e equipes de aplicações?
Desenvolvedores precisam observar mais atentamente os padrões de acesso ao estado. Projetos com gravações frequentes no mesmo estado, dependências complexas entre contratos ou transações em lote podem apresentar novos comportamentos de execução. As aplicações devem ser testadas quanto aos caminhos de execução antes do lançamento, não apenas em verificações funcionais.
Equipes de produto devem ajustar a comunicação de desempenho. Melhorias na experiência do usuário após o upgrade podem não ser lineares, especialmente durante a adaptação do ecossistema. A abordagem prudente é usar métricas em fases: confirmar estabilidade, taxas de falha e percentis de latência — não só médias. Redefinições de métricas e liberações em etapas devem acompanhar o framework de adaptação da aplicação.
Quais são os limites de implementação e desafios do BAL?
O primeiro desafio é garantir consistência entre clientes. Diferentes clientes de execução podem interpretar listas de acesso e estratégias de agendamento de maneiras distintas, exigindo convergência contínua via testnets e regressão entre clientes, com instantâneos de métricas.
O segundo desafio é o custo de aprendizado do ecossistema. Se equipes de desenvolvimento ignorarem estruturas de acesso ao estado, desvios de desempenho podem surgir após o upgrade; contratos legados podem não seguir padrões amigáveis a acesso, exigindo ferramentas e tempo para migração.
O terceiro desafio é atualizar sistemas de monitoramento. Equipes de operações precisam de métricas relacionadas a restrições de acesso para identificar se problemas vêm da preparação de dados, conflitos de agendamento ou gargalos de execução. Sem monitoramento atualizado, o mecanismo não entrega seu valor total. Para a Checklist de preparação de upgrade de nó, logs do BAL e taxas de rollback de conflitos devem entrar nos critérios de aceitação. Na Comparação Glamsterdam vs. Dencun/Fusaka, esses desafios são riscos estruturais e não podem ser resolvidos apenas com experiência em upgrades de capacidade.
Resumo
O BAL (EIP-7928) organiza a ordem de execução ao tornar explícitas as relações de acesso ao estado, estruturar a detecção de conflitos e transformar o agendamento de reativo em planejamento verificável. Embora não determine sozinho o sucesso do upgrade, ele é fundamental para a execução paralela estável e é um mecanismo central de restrição na camada de execução Glamsterdam.
Perguntas Frequentes
O BAL (EIP-7928) é a execução paralela propriamente dita?
Não. O BAL é a camada de restrição essencial para a execução paralela, servindo de base para a detecção de conflitos. A execução paralela depende também da implementação do cliente e das estratégias de agendamento.
Por que o BAL impacta o desempenho real?
Ao explicitar as relações de acesso ao estado com antecedência, os clientes podem preparar dados e agrupar tarefas antes, reduzindo rollbacks de conflitos em tempo de execução e aumentando a estabilidade.
Como se dividem as responsabilidades entre BAL e ePBS (EIP-7732)?
O ePBS define os limites de colaboração na produção de blocos, enquanto o BAL define os limites das restrições de execução. Cada um atua em uma camada distinta e ambos são complementares em Glamsterdam.
Como equipes de DApp devem agir diante do BAL?
Revisar padrões de acesso ao estado e caminhos de transações de alta frequência, reforçar testes de comportamento de execução antes e depois do upgrade, e atualizar monitoramento de desempenho e limites de alerta para não depender de suposições antigas de execução.
O BAL garante que todas as transações serão processadas em paralelo?
Não. O BAL oferece detecção de conflitos e entradas para agendamento, mas transações com alto conflito ainda precisam ser processadas em série. O grau de paralelismo depende dos padrões de acesso, da implementação do cliente e das características do tráfego da rede.
