From e77961e82a1b210dcd5151ce9879054500dbefc9 Mon Sep 17 00:00:00 2001 From: forcodedancing Date: Fri, 17 Nov 2023 20:44:13 -0600 Subject: [PATCH] add more contents, refine some sentences --- BEPs/BEP322.md | 33 +++++++++++++++++++++------------ 1 file changed, 21 insertions(+), 12 deletions(-) diff --git a/BEPs/BEP322.md b/BEPs/BEP322.md index 8db073f6..de1f47f8 100644 --- a/BEPs/BEP322.md +++ b/BEPs/BEP322.md @@ -30,8 +30,8 @@ economic considerations for real adoptions. ## 2. Motivation -The specification is defined in [Ethereum Builder API -Specification](https://github.com/ethereum/builder-specs), and it has been supported by almost all the mainstream +The [Ethereum Builder API +Specification](https://github.com/ethereum/builder-specs) has been supported by almost all the mainstream Ethereum consensus clients. Nowadays, the inclusion rate of blocks from builders is [about 90%](https://dune.com/ChainsightAnalytics/mev-after-ethereum-merge) (based on the statistics of October 2023). @@ -60,9 +60,8 @@ as bring new benefits for the ecosystem. ### 3.1 BSC Trust Model Before we move on to the design of Builder Specification, let's have an -analysis of the BSC trust model and compare it to Ethereum, for it will -affect how the design works and differentiate the designs in these two -networks. +analysis of the BSC trust model and compare it to Ethereum. It will +lead to different designs for these two networks. - Validators are more trustworthy in BNB Smart Chain. In BSC, the validators should delegate a lot of BNB (more than 10 thousand in @@ -116,6 +115,10 @@ The overall workflow is as follows: timeout to retrieve transitions from the builder, or the proposed block is invalid). +For step 4, a builder can also submit a bid with transactions, then at step 7 a proposer +does not need to ask for transactions and can send the receipt in an asynchronous way. +This option is also supported in this specification. + Here, we would like to highlight some main differences between Ethereum Builder Specification here for the readers who are familiar with it. @@ -137,7 +140,7 @@ Builder Specification here for the readers who are familiar with it. conducted using coinbase reward (for reward to builders) and token transfer (for fee to validators). In BSC, the coinbase reward will be transferred to the system contract for later distribution to - all delegators. A different way is proposed in this proposal, a + all delegators. A different way is proposed in this proposal; a validator and a builder can do the payment settlement via the receipts which contain the validator's signatures through off-chain or on-chain (e.g., smart contracts). It will be further @@ -171,8 +174,8 @@ timeout to retrieve transactions from the winning builder. ![block timing](./assets/bep-322/block_timing.png) -Secondly, a validator can choose to participate in or not. The -implementation should support a validator to turn on/off the feature +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 based on its choice. ### 3.3 Payment & Economic Considerations @@ -196,7 +199,7 @@ For the payment between builders and validators, a builder can settle with validators via the receipts (when asking for full transactions from a builder, a receipt with a validator's signature must be disclosed to the builder) off-chain or on-chain (e.g., smart contracts). Because the -builder fee is paid by validators (not all the delegators), validators +builder fee is paid by validators (not all the delegators), so validators can evaluate and increase the commission rate if needed. For the payment, we propose the following smart contract interfaces if @@ -293,7 +296,8 @@ for payment settlement. "builder_address": "builder address", "consensus_address": "validator consensus address", }, - "signature": "signature of the message" + "signature": "signature of the message", + "return_transactions": "the builder should transactions back or not" } @@ -401,7 +405,7 @@ api is timeout-ed, a validator can notify the builder. - + @@ -487,7 +491,12 @@ find the most profitable bid. "transaction_merkle_root": "merkle root of transactions", "transaction_count": "total count of transactions" }, - "signature": "signature of the message" + "signature": "signature of the message", + "transactions": [ //optional + {}, + {}, + {} + ] }
Path/bsc/v1/builder/issues/bsc/v1/builder/issue