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

BEPs/BEP-592.md

@@ -0,0 +1,141 @@
+<pre>
+  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.
+</pre>
+
+# BEP-592: Non-Consensus Based Block-Level Access List
+
+## Table of Contents
+- [BEP-592: Non-Consensus Based Block-Level Access List](#bep-592-non-consensus-based-block-level-access-list)
+  - [Table of Contents](#table-of-contents)
+  - [1. Summary](#1-summary)
+  - [2. Status](#2-status)
+  - [3. Motivation](#3-motivation)
+  - [4. Specification](#4-specification)
+    - [4.1 Parameters](#41-parameters)
+    - [4.2 Data Structure](#42-data-structure)
+    - [4.3 BAL Generation](#43-bal-generation)
+    - [4.4 BAL Propagation and bsc/3 P2P Protocol](#44-bal-propagation-and-bsc3-p2p-protocol)
+    - [4.5 BAL Storage](#45-bal-storage)
+    - [4.6 BAL Execution](#46-bal-execution)
+  - [5. Rationale](#5-rationale)
+    - [5.1 Why not include the slot value in BAL?](#51-why-not-include-the-slot-value-in-bal)
+    - [5.2 Why not define a new block header element for BAL?](#52-why-not-define-a-new-block-header-element-for-bal)
+    - [5.3 Any incentive/slash for a validator to generate BAL?](#53-any-incentiveslash-for-a-validator-to-generate-bal)
+  - [6. Forward Compatibility](#6-forward-compatibility)
+  - [7. Backward Compatibility](#7-backward-compatibility)
+  - [8. License](#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:
+
+<img src="assets/BEP-592/bal-asset-1.png" style="width: 40%;" alt="Block layout with BAL">
+
+The BAL data structure is defined as follows:
+
+```go
+// 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      // sign 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](https://creativecommons.org/publicdomain/zero/1.0/).
+