BEP-592: Non-Consensus Based Block-Level Access List

[zzzckck]

  BEP: 592
  Title: Non-Consensus Based Block-Level Access List
  Status: Draft
  Type: Standards
  Created: 2025-06-30
  Description: A non-consensus block-level access list mechanism that preloads storage data to accelerate block execution and improve network throughput.

BEP-592: Non-Consensus Based Block-Level Access List

Table of Contents

• BEP-592: Non-Consensus Based Block-Level Access List
  • Table of Contents
  • 1. Summary
  • 2. Status
  • 3. Motivation
  • 4. Specification
    • 4.1 Parameters
    • 4.2 Data Structure
    • 4.3 BAL Generation
    • 4.4 BAL Propagation and bsc/3 P2P Protocol
    • 4.5 BAL Storage
    • 4.6 BAL Execution
  • 5. Rationale
    • 5.1 Why not include the slot value in BAL?
    • 5.2 Why not define a new block header element for BAL?
    • 5.3 Any incentive/slash for a validator to generate BAL?
  • 6. Forward Compatibility
  • 7. Backward Compatibility
  • 8. License

1. Summary

This BEP introduces Block-Level Access Lists (BAL) - metadata attached to blocks that enables concurrent preloading of storage data during block import. By caching frequently accessed accounts and storage slots, BAL reduces block execution latency and improves overall network throughput.

2. Status

Draft

3. Motivation

The primary objective is to enhance BSC's performance by providing access lists during the mining phase. With shorter block intervals and increasing throughput demands, faster block importing becomes crucial for several key stakeholders.

BAL addresses this by enabling concurrent data preloading, benefiting key network participants:

• MEV Builders: Earlier bid simulation with reduced latency
• Fast Finality: Accelerated validator voting improves stability
• Validators: More time for block mining, espcially the first consecutive block
• Full Nodes: Faster chain synchronization and catch-up

4. Specification

4.1 Parameters

The following constants define the operational parameters for BAL:

Constant	Value	Description
MAX_BAL_BYTES	1048576	Maximum BAL size in bytes (1MB)
DEFAULT_HISTORICAL_BAL	360000	Default blocks to persist BAL data (~3.1 days)

4.2 Data Structure

BAL preserves existing block structures by attaching as an optional component at the block's end, maintaining full backward/forward compatibility. The layout of the block content with BAL can be described by the fowllowing diagram:

The BAL data structure is defined as follows:

// StorageAccessItem is a single storage key that is accessed in a block.
type StorageAccessItem struct {
	TxIndex uint32 // index of the first transaction in the block that accessed the storage
	Dirty   bool   // true if the storage was modified in the block, false if it was read only
	Key     common.Hash
}

// AccountAccessListEncode & BlockAccessListEncode are for BAL serialization.
type AccountAccessListEncode struct {
	TxIndex      uint32 // index of the first transaction in the block that accessed the account
	Address      common.Address
	StorageItems []StorageAccessItem
}

type BlockAccessListEncode struct {
	Version  uint32         // Version of the access list format
	Number   uint64      // number of the block that the BAL is for
	Hash     common.Hash // hash of the block that the BAL is for
	SignData []byte // validator signed data for BAL
	Accounts []AccountAccessListEncode
}

Key components:

• SignData: 65-byte validator signature using consensus key
• Version: Protocol upgrade support (starts at zero)
• Encoding: RLP format following BSC standards (SSZ considered for future versions)

4.3 BAL Generation

Validators are responsible for generating BAL content during block creation. As validators execute transactions sequentially to create a block, they have complete knowledge of the accounts and storage slots that the block will access. Validators maintain these access lists, sign, encode and attach the result to the end of the block. BAL may contain partial access information due to size constraints, the size of RLP encoded BAL content should not exceed MAX_BAL_BYTES.

4.4 BAL Propagation and bsc/3 P2P Protocol

BAL data will be propagated along with the block as an optional part. But the BAL will only be propagated to peers which supports bsc/3 p2p protocol. The bsc/3 protocol extends bsc/2 with BAL processing capabilities, ensuring backward compatibility.

4.5 BAL Storage

BAL storage is optional due to its size and primary use for block import acceleration. Nodes may choose retention policies, with a default of DEFAULT_HISTORICAL_BAL blocks.

4.6 BAL Execution

BAL v0 operates as a non-consensus optimization - no validation required. Nodes parse incoming BAL data and preload specified accounts/storage into cache concurrently with block processing, accelerating execution without affecting consensus safety.

5. Rationale

5.1 Why not include the slot value in BAL?

Excluding slot values maintains size efficiency. A typical block with 200 transactions accessing 50 slots each would require 320KB just for keys. Including values would also require MPT proofs for verification, dramatically increasing BAL size and negating performance benefits.

5.2 Why not define a new block header element for BAL?

The current approach prioritizes simplicity and compatibility. While header integration remains possible for future versions, attaching BAL as optional data maintains backward compatibility while delivering immediate performance benefits.

5.3 Any incentive/slash for a validator to generate BAL?

No incentive or penalty mechanisms exist initially - BAL generation is voluntary. Malicious BAL construction has limited impact due to its non-consensus nature, size constraints, and use solely for optimization. The design relies on validators' natural incentive to improve network performance.

6. Forward Compatibility

BAL's version field enables seamless protocol evolution. Future versions can introduce new features, encoding schemes (like SSZ), or structural enhancements while maintaining compatibility with v0 implementations.

7. Backward Compatibility

BAL maintains complete backward compatibility by operating as optional block metadata. Non-supporting nodes continue normal operation without consensus or validation impact, ensuring smooth network-wide deployment.

8. License

The content is licensed under CC0.

[zzzckck]

reference:
https://github.com/ethereum/EIPs/blob/master/EIPS/eip-7928.md
https://ethresear.ch/t/block-level-access-lists-bals/22331

[octavio12345300]

List