BAL (EIP-7928) é frequentemente considerado a "pré-condição para execução paralela" nas discussões sobre Glamsterdam. Este termo não significa que todas as transações vão ser imediatamente executadas em paralelo; indica, sim, que as relações de acesso ao estado passam de pressupostos implícitos para restrições explícitas e verificáveis. Só com estas restrições claramente definidas é possível garantir um agendamento estável.
Esta camada de restrição está diretamente associada aos objetivos de atualização descritos no Glamsterdam Upgrade Overview e complementa o mecanismo ePBS (EIP-7732): o ePBS define os limites de colaboração para produção de blocos, enquanto o BAL estabelece os limites das restrições de execução. O artigo O impacto de Glamsterdam nas DApps demonstra como as alterações nesta camada condicionam as expectativas de desempenho das aplicações e a cadência de libertação.
O que é o BAL (EIP-7928)?
BAL significa Block-Level Access Lists, que registam as contas e os slots de armazenamento acedidos durante a execução do bloco, podendo também incluir resultados do estado após a execução. O objetivo não é substituir o motor de execução, mas sim proporcionar deteção de conflitos antecipada e entradas de preparação de dados mais claras.
A execução tradicional em série garante consistência, mas atinge rapidamente limites de eficiência sob cargas elevadas. Para viabilizar execução paralela, é essencial responder à questão: "Que transações entram em conflito entre si?" O valor do BAL reside em transferir a deteção de conflitos do runtime para uma fase planeada antes da execução. Segundo o roadmap da Ethereum.org e o EIP-7928, o BAL é uma proposta fundamental para a atualização Glamsterdam.
Porque é que a Ethereum necessita de Block-Level Access Lists?
À medida que os blocos se tornam mais complexos, se as relações de leitura/escrita do estado só forem detetadas dinamicamente durante a execução, os clientes não conseguem planear antecipadamente os percursos de execução. Mesmo com hardware robusto, a eficiência pode ser prejudicada por conflitos de rollback e reprogramações sucessivas.
As block-level access lists reduzem a probabilidade de "conflitos descobertos apenas durante a execução". Com restrições claras logo à partida, os clientes podem preparar dados, repartir tarefas e isolar conflitos, minimizando flutuações aleatórias de desempenho. Para funções como serviços de indexação e nodos de arquivo, que efetuam leituras intensivas do estado, o conhecimento prévio das relações de acesso também permite otimizar o planeamento de I/O.
| Fase de execução |
Sem restrições prévias |
Com restrições BAL |
| Momento de deteção de conflitos |
Rollback durante a 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 |
Esta tabela evidencia que o BAL altera a "disponibilidade da informação", e não apenas o throughput final.
Como é que o BAL permite identificar conflitos e otimizar o agendamento?
Os clientes utilizam a access list para decidir: dividir transações em "conjuntos paralelizáveis" e manter "percursos que exigem execução sequencial". Mesmo sem paralelismo total, os segmentos com poucos conflitos podem ser otimizados primeiro, ampliando progressivamente o âmbito de execução paralela.
Do ponto de vista da engenharia, o BAL não proporciona um pico imediato de desempenho, mas melhora a previsibilidade do comportamento de execução. Para as equipas de operações de nodos, a previsibilidade é frequentemente mais valiosa do que picos de curto prazo, por ter impacto direto nos SLA e na resposta a incidentes. As variações nas taxas de conflito e rollback em testnet são métricas essenciais para avaliar a eficácia do BAL.
| Fase de agendamento |
Sem restrições prévias |
Com restrições BAL |
| Preparação pré-execução |
Baseada em estimativas |
Pré-agrupamento via access list |
| Gestão de conflitos |
Rollbacks frequentes em runtime |
Isolamento antecipado de conflitos |
| Estabilidade dos resultados |
Altamente variável |
Resultados mais previsíveis |
| Monitorização de operações |
Difícil definir thresholds |
Possibilidade de métricas estruturadas |
Figura 1. Ilustração do mecanismo BAL: como as block-level access lists facilitam a deteção de conflitos e o agendamento da execução paralela.
Qual é a relação entre o BAL e a execução paralela?
O BAL não substitui a execução paralela; é a sua camada pré-requisito. Para viabilizar execução paralela, é necessário que a implementação do cliente, as estratégias de agendamento e a gestão do estado funcionem em conjunto. Sem restrições estruturais, o paralelismo forçado tende a aumentar a incerteza.
Em síntese, o BAL transforma a execução paralela de um conceito teórico num objetivo concretizável. Responde à questão "os pré-requisitos estão reunidos?", não "já se atingiu o desempenho máximo?". Mesmo com estratégias de paralelismo mais agressivas, as restrições de acesso do BAL continuam essenciais para a gestão de conflitos.
O que representa o BAL para programadores e equipas de aplicações?
Os programadores devem analisar mais atentamente os padrões de acesso ao estado. Soluções com escritas frequentes no mesmo estado, dependências complexas entre contratos ou acoplamento de transações em lote podem apresentar novos comportamentos de execução sob estas restrições. É fundamental testar os percursos de execução das aplicações antes do lançamento, não apenas realizar testes funcionais.
As equipas de produto devem ajustar a comunicação sobre desempenho. As melhorias na experiência do utilizador após a atualização podem não ser lineares, sobretudo durante a adaptação do ecossistema. A abordagem prudente passa por métricas faseadas: validar estabilidade, taxas de falha e percentis de latência—não apenas médias. As reposições de métricas e as libertações faseadas devem alinhar-se com a estrutura de adaptação da aplicação.
Quais os limites de implementação e desafios do BAL?
O primeiro desafio é garantir consistência entre clientes. Diferentes clientes de execução podem interpretar as access lists e estratégias de agendamento de forma distinta, exigindo convergência contínua através de comparações em testnet e regressão cruzada, com instantâneos de métricas datados.
O segundo desafio é o custo de aprendizagem do ecossistema. Se as equipas de desenvolvimento ignorarem a estrutura de acesso ao estado, podem surgir desvios de desempenho após a atualização; contratos legados podem não estar otimizados para acesso, exigindo ferramentas e tempo para migração.
O terceiro desafio é atualizar os sistemas de monitorização. As equipas de operações necessitam de novas métricas relacionadas com restrições de acesso para identificar se os problemas advêm da preparação de dados, conflitos de agendamento ou limitações do motor de execução. Sem monitorização adaptada, o valor do mecanismo não é totalmente realizado. Para a Node Upgrade Preparation Checklist, os registos BAL e taxas de rollback de conflito devem integrar os critérios de aceitação. No contexto da Comparação Glamsterdam vs. Dencun/Fusaka, estes desafios constituem riscos específicos de alterações estruturais e não se resolvem apenas com experiência em upgrades de capacidade.
Resumo
O BAL (EIP-7928) torna explícitas as relações de acesso ao estado, estrutura a deteção de conflitos e transfere o agendamento de uma lógica reativa para um planeamento verificável. Embora não determine, por si só, o sucesso da atualização, é fundamental para a execução paralela estável e constitui o mecanismo central de restrição na camada de execução Glamsterdam.
Perguntas Frequentes
O BAL (EIP-7928) é execução paralela?
Não. O BAL é a camada de restrição pré-requisito para execução paralela, servindo de base para a deteção de conflitos. A execução paralela depende também da implementação do cliente e das estratégias de agendamento.
Porque é que o BAL afeta o desempenho real?
Ao tornar explícitas as relações de acesso ao estado com antecedência, os clientes podem preparar dados e agrupar tarefas mais cedo, reduzindo rollbacks de conflitos em tempo de execução e melhorando a estabilidade do processo.
Qual a divisão de responsabilidades entre BAL e ePBS (EIP-7732)?
O ePBS define os limites de colaboração na produção de blocos, enquanto o BAL estabelece os limites das restrições de execução. Cada mecanismo opera numa camada distinta e ambos são complementares em Glamsterdam.
Como devem as equipas de DApp reagir à introdução do BAL?
Rever padrões de acesso ao estado e percursos de transações de alta frequência, reforçar os testes de comportamento de execução antes e após a atualização e atualizar a monitorização de desempenho e thresholds de alerta, evitando pressupostos ultrapassados.
O BAL garante execução paralela para todas as transações?
Não. O BAL proporciona deteção de conflitos e entradas para agendamento, mas transações com muitos conflitos continuam a ser processadas em série. O grau de paralelismo depende dos padrões de acesso, implementação do cliente e características da carga da rede.
