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,56 @@ 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:
+During each block production interval, builders and validators will work together to propose a block. There are two options
+for the interaction from proposing a block to sealing a block between builders and validators, 
+one is one-round interaction, and the other is two-round interaction. One-round means that builders send bids with 
+transactions together, and validators could directly seal a block using the bid rather than asking for transactions later. 
+Two-round means that builders send bids without transactions first, if it is picked, validators will retrieve transactions 
+by another rpc call and then seal a block, which suffers more from time-consuming.
 
-1) builders will submit bids to the current proposer or multiple registered validators.
+**One-round(recommended and default)** interaction:
 
-2) the proposer should respond successfully if the bid is successfully received.
+![workflow](./assets/bep-322/workflow_1round.png)
 
-3) the proposer will select one bid from all bids according to the max value it can extract.
+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)
 
-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.
+**One-round with proxy(optional)** interaction:
 
-5) the builder should return the full transactions.
+omit here, only difference is that proxy could append transfer transaction to pay builder fee, as seems as 
+**Two-round with proxy(optional)** below.
 
-6) the proposer will execute the full transactions and verify the gas value.
+**Two-round(optional)** interaction:
 
-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).
+![workflow](./assets/bep-322/workflow_2round.png)
 
-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.
+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.
 
-![workflow](./assets/bep-322/workflow_2round.png)
+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.
 
-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.
+**Two-round with proxy(optional)** interaction:
 
 ![workflow](./assets/bep-322/workflow_2round_proxy.png)
 
-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. 
-
-![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.