enhance: workflow

BEPs/BEP322.md

@@ -84,16 +84,20 @@ 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. 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.
+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. 
+
+*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.* 
 
 **One-round(recommended and default)** interaction:
 
-![workflow](./assets/bep-322/workflow_1round.png)
+<img src="./assets/bep-322/workflow_1round.png" alt="workflow" width="500"/>
 
 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.
@@ -111,7 +115,7 @@ omit here, only difference is that proxy could append transfer transaction to pa
 
 **Two-round(optional)** interaction:
 
-![workflow](./assets/bep-322/workflow_2round.png)
+<img src="./assets/bep-322/workflow_2round.png" alt="workflow" width="500"/>
 
 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.
@@ -129,7 +133,7 @@ seal a block using local transactions.
 
 **Two-round with proxy(optional)** interaction:
 
-![workflow](./assets/bep-322/workflow_2round_proxy.png)
+<img src="./assets/bep-322/workflow_2round_proxy.png" alt="workflow" width="500"/>
 
 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
@@ -186,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
@@ -197,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