update format of BEP130

BEP130.md

@@ -1,29 +1,40 @@
+<pre>
+  BEP: 130
+  Title: Parallel Transaction Execution
+  Status: Draft
+  Type: Standards
+  Created: 2022-01-27
+  Author: setunapo
+</pre>
+
 # BEP-130: Parallel Transaction Execution
 
 - [BEP-130: Parallel Transaction Execution](#bep-130-parallel-transaction-execution)
   - [1. Summary](#1-summary)
   - [2. Abstract](#2-abstract)
-  - [3. Status](#3-status)
-  - [4. Motivation](#4-motivation)
-  - [5. Design Principle](#5-design-principle)
-    - [Compatiable](#compatiable)
-    - [None Intrusion & Decoupled](#none-intrusion--decoupled)
-    - [Configurable](#configurable)
-    - [Keep It Simple And Smart](#keep-it-simple-and-smart)
-  - [6. Specification](#6-specification)
-    - [6.1 Overview](#61-overview)
-      - [6.1.1 Workflow](#611-workflow)
-      - [6.1.2 Pipeline](#611-pipeline)
-    - [6.2 Initialize](#62-initialize)
-    - [6.3 Dispatcher](#63-dispatcher)
-    - [6.4 Slot Execution](#64-slot-execution)
-      - [6.4.1 State Of Slot](#641-state-of-slot)
-      - [6.4.2 Execution Stages In Slot](#642-execution-stages-in-slot)
-      - [6.4.3 Conflict Detection](#643-conflict-detection)
-      - [6.4.4 Transaction Redo](#644-transaction-redo)
-      - [6.4.5 Transaction Result Merge](#645-transaction-result-merge)
-    - [6.5 Handle System Contract](#65-handle-system-contract)
-    - [6.6 Block Mining and Sync](#66-block-mining-and-sync)
+  - [3. Motivation](#3-motivation)
+  - [4. Specification](#4-specification)
+    - [4.1 Design Principle](#41-design-principle)
+      - [Compatibility](#compatibility)
+      - [None Intrusion \& Decoupled](#none-intrusion--decoupled)
+      - [Configurable](#configurable)
+      - [Keep It Simple And Smart](#keep-it-simple-and-smart)
+    - [4.2 Overview](#42-overview)
+      - [4.2.1 Workflow](#421-workflow)
+      - [4.2.2 Pipeline](#422-pipeline)
+    - [4.3 Initialize](#43-initialize)
+    - [4.4 Dispatcher](#44-dispatcher)
+    - [4.5 Slot Execution](#45-slot-execution)
+      - [4.5.1 State Of Slot](#451-state-of-slot)
+      - [4.5.2 Execution Stages In Slot](#452-execution-stages-in-slot)
+      - [4.5.3 Conflict Detection](#453-conflict-detection)
+        - [Conflict Detection Items](#conflict-detection-items)
+        - [Conflict Window](#conflict-window)
+      - [4.5.4 Transaction Redo](#454-transaction-redo)
+      - [4.5.5 Transaction Result Merge](#455-transaction-result-merge)
+    - [4.6 Handle System Contract](#46-handle-system-contract)
+    - [4.7 Block Mining and Sync](#47-block-mining-and-sync)
+  - [5.  License](#5--license)
 
 ## 1. Summary
 
@@ -44,53 +55,50 @@ The dispatcher will dispatch the transactions in a block to the slots sequential
 
 Since the transactions can be executed in different slots concurrently, the performance of the block execution should be improved if there are not many conflicts between the different slots.
 
-## 3. Status
-
-This BEP is a draft.
+## 3. Motivation
 
-## 4. Motivation
-
-BSC is facing the challenge of huge traffic and the daily transaction volume had reached an all-time high of 16 million recently. The network always might get congested when there is a promotion activity happening on a popular dApp.
+BSC is facing the challenge of huge traffic and the daily transaction volume had reached an all-time high of 16 million recently. The network could get congested when there is a promotion activity happening on a popular dApp.
 
 Besides validators, full nodes also experienced difficulty to catch up the new blocks due to the heavy computing and storage load.
 
 The execution of the block transactions takes up most of the time when producing or synchronizing(in full sync mode) the blocks. For now, the transactions are executed sequentially. Introducing a parallel EVM execution mechanism can utilize the performance of multi-core processors and reduce the time of block execution which will improve the capacity of the whole network.
 
-## 5. Design Principle
+## 4. Specification
+
+
+### 4.1 Design Principle
 
 There are some principles that we will stick to when we design the parallel execution proposal.
 
-### Compatiable
+#### Compatibility
 
 It should not change the workflow of current BSC’s working process, e.g., consensus algorithm, storage format, contract opcode format, all of these component’s behavior should stay unchanged.
 
 In short, the parallel execution will produce the same result as the current sequential execution.
 
-### None Intrusion & Decoupled
+#### None Intrusion & Decoupled
 
 The implementation should be kept within the execution layer, it should not change the data structure or interface of other modules.
 
 And also, it should be decoupled. There are modules such as BlockProcessor, EVM Interpreter, StateDB, StateObject, ReceiptProcessor… within the execution layer. Parallel execution could introduce new modules, such as TxDispatcher, TxResultMerger, ConflictDetector, SlotState… they should be decoupled, no circular dependency.
 
-### Configurable
+#### Configurable
 
 The BSC node could configure its parallel execution parameters based on its hardware resources, since different hardware could have different best practice parameters.
 
 The parameters that can be configured could be: enable/disable, concurrent number, MaxQueueSize for each slot, dispatcher policy etc.
 
 These parameters can be configured on node startup or even at runtime.
 
-### Keep It Simple And Smart
+#### Keep It Simple And Smart
 
 The parallel execution could be very complicated, especially its execution pipeline, unorder execution & inorder commit, thread safe stateobject access, conflict detect algorithm…
 
 But design should keep it as simple as possible, complexity makes product unstable.
 
 And to achieve the best performance benefits, it should be smart on how to dispatch transactions to reduce transaction conflict and make the parallel execution slots workload balance.
 
-## 6. Specification
-
-### 6.1 Overview
+### 4.2 Overview
 
 The goal of this BEP is to improve the performance of block execution by executing the transactions concurrently to a certain extent.
 
@@ -105,27 +113,27 @@ A configured number of slots will be created on BSC node startup, which will rec
 
 The dispatcher will dispatch the transactions in a block to slots sequentially when there is a slot available.
 
-#### 6.1.1 Workflow
+#### 4.2.1 Workflow
 
 Here is the general workflow of the parallel execution. When a batch of transactions are received, no matter from P2P transaction pool or downloaded blocks, there will be a state processor to handle the transactions. If parallel is not enabled, the transactions will be processed sequentially as before, otherwise they will be handled by the parallel processor, the details will be explained later.
 
 ![workflow](./assets/bep-130/2_workflow.png)
 
-#### 6.1.2 Pipeline
+#### 4.2.2 Pipeline
 
 The parallel transaction execution would have a pipeline. The current design is for the initial phase, and it will be optimized to get the best performance.
 
 Let’s have an overview of the parallel pipeline first, with 8 concurrencies as an example.
 
 ![pipeline](./assets/bep-130/3_pipeline.png)
 
-### 6.2 Initialize
+### 4.3 Initialize
 
 The parallel initialization will be done on node startup, if parallel execution is enabled. The parallel slot pool will be created, each slot will have a SlotState structure to maintain its state. Then the slot will be waiting until it receives a new transaction execution request.
 
 ![init](./assets/bep-130/4_init.png)
 
-### 6.3 Dispatcher
+### 4.4 Dispatcher
 
 The dispatcher is responsible for dispatching the transactions in the block to the slots sequentially.
 
@@ -146,20 +154,20 @@ There are many factors that will be taken into consideration to make the decisio
 
 The dispatcher will try to make the best decision and select an available slot for the transaction, the dispatch algorithm’s target to make a balanced workload and with less state conflict.
 
-### 6.4 Slot Execution
+### 4.5 Slot Execution
 
 The slot is where transactions are executed. Transactions will be dispatched to slots sequentially by the dispatcher and executed sequentially in the same slot. Transactions dispatched to different slots can be executed concurrently.
 
 There is a pending transaction queue in the slot. When the slot is occupied, the dispatcher can still dispatch transactions to the pending queue of the slot.
 
-#### 6.4.1 State Of Slot
+#### 4.5.1 State Of Slot
 
 There are two states of a slot:
 
 1. Idle. The slot will be marked idle when there is no transaction executing or no pending transaction in the slot.
 2. Occupied. The slot will be marked occupied if it’s executing a transaction and there may be even pending transactions.
 
-#### 6.4.2 Execution Stages In Slot
+#### 4.5.2 Execution Stages In Slot
 
 Since transactions are executed concurrently in different slots, the state read by a slot could be changed by other slots, making the transaction's execution result invalid. The invalid transaction should be executed again based on the latest state.
 
@@ -180,7 +188,7 @@ Not every transaction will go through these five stages.
 3. For the majority of transactions, they likely need to wait for the previous transactions(TxIndex-1) to complete before it can do conflict detection.
 4. And for unlucky transactions, they waited and conflict detected, they need to be redo based on the latest world state. Since redo is based on the latest world state, it won’t conflict and can skip the conflict detection stage.
 
-#### 6.4.3 Conflict Detection
+#### 4.5.3 Conflict Detection
 
 After a transaction is executed in a slot, it needs to make sure the previous transaction is finalized, so that it can check if there is any state conflict, otherwise its execution result can not be confirmed.
 
@@ -203,26 +211,30 @@ Conflict window is an important structure to represent the transaction range tha
 
 ![conflict window](./assets/bep-130/7_conflict_window.png)
 
-#### 6.4.4 Transaction Redo
+#### 4.5.4 Transaction Redo
 
 If a conflict is detected, the conflicted execution result is not reliable and will be discarded. And the transaction needs to be redo based on the latest world state. The transaction redo will not have conflicts, since all of the previous transactions have been finalized now, it can get the fresh world state and all the state objects will be valid.
 
-#### 6.4.5 Transaction Result Merge
+#### 4.5.5 Transaction Result Merge
 
 The state changes of the transaction are kept within the execution slot. They need to be merged to the main StateDB once the transaction execution is done and the result is valid.
 
-### 6.5 Handle System Contract
+### 4.6 Handle System Contract
 
 System contracts are built in contracts to perform system level operations, such as gas fee reward, cross chain communication etc. These contracts are important components of the chain and their behavior may depend on the execution results of other transactions, so they can not be executed concurrently. Parallel transaction execution will not be applied to these system contracts, they will be executed sequentially as before.
 
 Since most of the transactions in a block are not system contracts, parallel execution still can work for most of the transactions.
 
-### 6.6 Block Mining and Sync
+### 4.7 Block Mining and Sync
 
 There are two different phases of transaction execution: block mining and block sync.
 
 For the mining phase, the block is under mining and the transactions to be executed are gathered from the P2P transactions pool. There would be invalid transactions, because of bad nonce, block gas limit reached etc. These invalid transactions will not be put into the block. The concurrently executed transaction would have no idea what its transactions index in the block is or which transaction is the previous transaction until the block is mined.
 
 For the sync phase, the block is supposed to be confirmed, the transactions in the block are determined.
 
-Parallel transaction execution will support both of the two phases, but there could be some differences for implementation.
+Parallel transaction execution will support both of the two phases, but there could be some differences for implementation.
+
+##  5.  License
+
+All the content are licensed under [CC0](https://creativecommons.org/publicdomain/zero/1.0/).