enhance: workflow

BEPs/BEP322.md

@@ -42,21 +42,18 @@ However, on BNB Smart Chain, there is no such specification yet. By
 introducing such a specification, it will resolve some problems as well
 as bring new benefits for the ecosystem.
 
-- Improve stability of network: currently validators are using different customized
-  implementations for MEV with different levels of quality, which
-  brings instability to the network. With a specification, it will
-  provide guidelines and standards to follow, minimizing the
-  instability issues.
-
-- Improve MEV economy by building MEV market: validators can only integrate with a single MEV provider
-  now, due to the lack of support on BSC clients. With this
-  specification, validators can integrate with multiple builders at
-  the same time.
-
-- Improve transparency: this specification will also bring transparency to
-  different stakeholders, including BNB delegators. With the
-  adoption of builders, it is probable that delegators can earn more
-  because builders are supposed to submit more profitable blocks.
+- **Improve stability**. Current validators are using different customized implementations for MEV with
+  different levels of quality, which brings instability to the network. With a specification, it will provide guidelines
+  and standards to follow, minimizing the instability issues.
+
+- **Improve economy**. The current situation is different mev provider has different architecture and APIs,
+  one validator finds it's hardly to integrate with multiple MEV providers simultaneously, also due to
+  the lack of support on BSC clients. So we put forward this specification to try to boost mining and delegating economy,
+  validators can easily get more extractable value from integrating with more MEV providers, delegators can earn more
+  rewards from validators.
+
+- **Improve transparency**. This specification would try to bring transparency into bsc mev market, expose profit 
+  distribution among stakeholders(validators, delegator, builders) to public.
 
 ## 3. Specification
 
@@ -87,44 +84,60 @@ lead to different designs for these two networks.
 
 #### 3.2.1 Overall Workflow
 
-During each block production interval, builders and validators will work together to propose a block.
-The overall workflow for proposing a block is as follows:
+Builders and validators collaborate to propose blocks during each production interval. Two interaction options exist 
+between them: one-round and two-round. In one-round, builders include transactions with their bids, allowing validators 
+to immediately seal a block without additional transaction requests. Conversely, in two-round, builders send bids 
+without transactions initially. If selected, validators retrieve transactions through another RPC call before sealing 
+the block. The two-round process is considered more time-consuming compared to the one-round interaction. 
 
-1) builders will submit bids to the current proposer or multiple registered validators.
+*One-round is the default option for trusted relationship,*
+*It's highly suggest to adopt two-round interaction for builders who* 
+*1. not trust validator;* 
+*2. don't care too much about latency or adopt chance.* 
 
-2) the proposer should respond successfully if the bid is successfully received.
+**One-round(recommended and default)** interaction:
 
-3) the proposer will select one bid from all bids according to the max value it can extract.
+<img src="./assets/bep-322/workflow_1round.png" alt="workflow" width="500"/>
 
-4) the proposer will ask the builder for full transactions if its bid is chosen, it also gives the builder its signature
-   as a receipt.
+1) Builder submits bids with transactions to the current or multiple registered proposers.
+2) Builder gets the idea if the bid is or not successfully received from proposers' responses.
+3) Proposer picks the max valuable bid from all received bids.
+4) Proposer executes the full transactions and verifies the gas.
+5) If the bid in invalid, the proposer will use local bid to do sealing, and then notify specified builder using issue
+   api (see later more details). or step-6.
+6) if the bid is valid, the proposer will seal the block, and then notifies specified builder asynchronously with 
+   own signature as a receipt. (optional for notification here if proxy is used)
 
-5) the builder should return the full transactions.
+**One-round with proxy(optional)** interaction:
 
-6) the proposer will execute the full transactions and verify the gas value.
+omit here, only difference is that proxy could append transfer transaction to pay builder fee, as seems as 
+**Two-round with proxy(optional)** below.
 
-7) the proposer will notify the builder if something is wrong (e.g., timeout to retrieve transitions from the builder,
-   or the proposed block is invalid).
+**Two-round(optional)** interaction:
 
-8) the proposer will seal a block using the transactions from the winning builder.
-   If there is no profitable bid compared to local or the transactions do not return in time,
-   the proposer can still seal a block using local transactions.
+<img src="./assets/bep-322/workflow_2round.png" alt="workflow" width="500"/>
 
-![workflow](./assets/bep-322/workflow_2round.png)
+1) Builder submits bids with transactions to the current or multiple registered proposers.
+2) Builder gets the idea if the bid is or not successfully received from proposers' responses.
+3) Proposer picks the max valuable bid from all received bids. 
+4) Proposer asks the builder for full transactions if its bid is chosen, it also gives the builder its signature
+   as a receipt. 
+5) The builder should return the full transactions.
+6) Proposer executes the full transactions and verify the gas value.
+7) if the bid is invalid, the proposer would use local mining result to do sealing, and then notify specified builder
+   using issue api (see later more details). or step-8.
+8) if the bid is valid, the proposer would seal the block.
 
-Meanwhile, a validator can run a proxy in front of it.
-The proxy will has its own wallet, which should be different from consensus wallet,
-and append a transfer transaction to send builder fee.
-The proxy can also filter bids and only forward the more profitable ones to a validator.
+tips: If there is no profitable bid compared to local or the transactions do not return in time, proposer can still 
+seal a block using local transactions.
 
-![workflow](./assets/bep-322/workflow_2round_proxy.png)
+**Two-round with proxy(optional)** interaction:
 
-In BSC, the time for producing a block is only 3 seconds. To reduce the latency, the following option is also supported
-in this specification. For step 1, a builder can also submit a bid with transactions, then at step 4 a proposer
-does not need to ask for transactions, and can send the receipt in an asynchronous way or even do not send it.
-This option can also use a validator proxy for payment. 
+<img src="./assets/bep-322/workflow_2round_proxy.png" alt="workflow" width="500"/>
 
-![workflow](./assets/bep-322/workflow_1round.png)
+Validator can run a proxy in front of it. The proxy will has its own wallet, which should be different from consensus
+wallet, and append a transfer transaction to send builder fee. The proxy can also filter bids and only forward the more
+profitable ones to a validator.
 
 Here, we would like to highlight some main differences between Ethereum
 Builder Specification here for the readers who are familiar with it.
@@ -177,7 +190,7 @@ timeout to retrieve transactions from the winning builder.
 Meanwhile, to reduce latency, the one round interaction (i.e., builders send bids and transactions together) 
 is suggested to be the default option for proposing blocks.
 
-![block timing](./assets/bep-322/block_timing.png)
+<img src="./assets/bep-322/block_timing.png" alt="block_timing" width="500"/>
 
 Secondly, a validator can choose to run a node with or without support for builder.
 The implementation should support a validator to turn on/off the feature
@@ -188,7 +201,7 @@ Meanwhile, for a validator it needs to interact with many builders at the same t
 A proxy can also be implemented to protect validators, e.g., hiding validator’s real
 IP information, protecting against DDoS, and others.
 
-![proxy_topology](./assets/bep-322/workflow_topology.png)
+<img src="./assets/bep-322/workflow_topology.png" alt="proxy_topology" width="500"/>
 
 ### 3.3 Payment & Economic Considerations