BEP-322: Builder API Specification for BNB Smart Chain

BEPs/BEP322.md

@@ -0,0 +1,355 @@
+<pre>
+	BEP: 322
+	Title: Builder API Specification for BNB Smart Chain
+	Status: Draft
+	Type: Standards
+	Created: 2023-11-15
+</pre>
+
+# BEP-322: Builder API Specification for BNB Smart Chain
+
+<!-- TOC -->
+
+- [BEP-322: Builder API Specification for BNB Smart Chain](#bep-322-builder-api-specification-for-bnb-smart-chain)
+  - [1. Summary](#1-summary)
+  - [2. Motivation](#2-motivation)
+  - [3. Background](#3-background)
+    - [3.1 BSC Trust Model](#31-bsc-trust-model)
+    - [3.2 BSC Consensus](#32-bsc-consensus)
+  - [4 Workflow](#4-workflow)
+    - [4.1 Definition](#41-definition)
+    - [4.2 One-Round Interaction (default)](#42-one-round-interaction-default)
+    - [4.3 Two-Round Interaction (optional)](#43-two-round-interaction-optional)
+    - [4.4 APIs](#44-apis)
+      - [4.4.1 Builder APIs](#441-builder-apis)
+        - [4.4.1.1 Issues Report](#4411-issues-report)
+      - [4.4.2 Validator APIs](#442-validator-apis)
+        - [4.4.2.1 Bid Block](#4421-bid-block)
+  - [5. Further Discussion](#5-further-discussion)
+    - [5.1 Implementation Consideration](#51-implementation-consideration)
+    - [5.2 Payment \& Economic Considerations](#52-payment--economic-considerations)
+    - [5.3 Builder Registration](#53-builder-registration)
+  - [6. References](#6-references)
+  - [7. License](#7-license)
+
+<!-- /TOC -->
+
+## 1. Summary
+
+This BEP introduces a suite of interaction processes and API specifications to establish a fairer and more transparent
+MEV framework on the BNB Smart Chain. Participants can follow this specification to collaborate on building and
+proposing blocks.
+
+## 2. Motivation
+
+The Ethereum MEV market is thriving, with
+the [Ethereum Builder API Specification](https://github.com/ethereum/builder-specs&#41) widely supported by
+mainstream consensus clients. As of October 2023, the inclusion rate of blocks from builders is
+approximately [90%](https://dune.com/ChainsightAnalytics/mev-after-ethereum-merge&#41),
+indicating a robust ecosystem.
+
+The BNB Smart Chain MEV market still remains at a Wild West stage. The absence of PBS adoption results in a chaotic
+landscape with different architectures and API standards. Nowadays, validators face significant hurdles when attempting
+to integrate with multiple MEV providers concurrently. Moreover, the absence of native support from the BSC clients
+further
+exacerbates the instability of MEV services. To tackle these issues, this BEP puts forward compliant guidelines and
+standards with the following aims:
+
+- **Improve Stability**: Unified specifications for both validators and MEV providers to enhance integration and
+  stabilize the market.
+
+- **Improve Economy**: A unified architectural specification increases speculators' costs, fostering a healthy market
+  competition. Validators can extract more value by integrating with multiple MEV providers, which benefits delegators
+  as well.
+
+- **Improve Transparency**: This specification aims to bring transparency to the BSC MEV market, exposing profit
+  distribution among stakeholders to the public.
+
+## 3. Background
+
+Before delving into the specification, let's analyze the BSC trust model and its distinctive consensus protocol.
+
+### 3.1 BSC Trust Model
+
+Validators in the BNB Smart Chain are considered more trustworthy, as it requires substantial BNB delegation and must
+maintain a high reputation. This stands in contrast to Ethereum, where becoming a validator is relatively easier.
+As of the end of 2023, there were approximately 40 validators on BSC (with more expected to join) and a total of
+20 million BNB staked. In Ethereum, the barrier to becoming a validator is very low (i.e., 32 ETH), leading to over
+800,000 Ethereum validators according
+to [Nasdaq](https://www.nasdaq.com/articles/the-most-pressing-issue-on-ethereum-is-validator-size-growth).
+
+Meanwhile, in the Ethereum MEV architecture, the 'relay' role is expected to be trusted by both builders and validators.
+However, in BSC, validator misbehavior results in reputation damage and un-delegations, reducing the need for
+introducing
+another trusted role. In this specification, we eliminate the 'relay' role. However, this adjustment should not
+compromise
+the security and trust model for the MEV market between builders and validators.
+
+### 3.2 BSC Consensus
+
+In Ethereum, a block header is transferred from a builder to a validator for signing, allowing the block to be
+broadcasted
+to the network without disclosing the transactions to the validator. In contrast, in BSC, creating a valid block header
+requires executing transactions and system contract calls (such as transferring coinbase and depositing to the validator
+set contract), rendering it impossible for builders to broadcast the block.
+
+## 4 Workflow
+
+### 4.1 Definition
+
+- **Builder**: the party that specializes in the construction of BSC execution payloads using transactions received from
+  users and searchers (trusted by searchers and users for fair inclusion).
+
+- **Proposer**: the party that signs and submits a block to the network, often referred to as the validator.
+
+- **Mev-sentry**: the party that runs in front of a validator to proxy requests and enhance network security.
+
+- **Bid**: used by a builder to do competitive bidding for a block space. A bid should include the following
+  information:
+    - **block_number**. The height of the block.
+    - **parent_hash**. The hash of the parent block.
+    - **gas_fee**. The total gas fee of the bid.
+    - **builder_fee**. The fee that the builder would like to take from the validator.
+
+### 4.2 One-Round Interaction (default)
+
+Builders and validators collaborate to propose blocks during each block production interval. Two interaction options
+exist
+between them: one-round and two-round. With one-round, builders include transactions with their bids, allowing
+validators
+to immediately seal a block without additional transaction retrieves. *One-round is the default option for trusted
+relationship*.
+
+<img src="https://raw.githubusercontent.com/bnb-chain/BEPs/473fb9e9372cbd0fc58d2d58a0e5d79fab1e5552/BEPs/assets/bep-322/workflow_1round.png" alt="workflow" width="500"/>
+
+1) Builders submit bids with transactions to the in-turn validator.
+2) The validator picks the most valuable bid from all received within a predefined time.
+3) The validator executes the full transactions and verifies the bid (gas received is the same as what claimed in the
+   bid,
+   even with the potential illegal transactions).
+4) If the bid turns out to be invalid, the proposer will use a locally mined block and also report detailed errors to
+   the
+   builder. The validator may blacklist the builder for some time or forever if the builder offers invalid bid.
+5) The validator seals the final block.
+
+In practical settings, opting for a **One-round with MEV-Sentry (optional)** configuration stands out as the optimal
+solution
+for ensuring both security and efficient payment processes. Subsequently, we will delve into the specific role that
+MEV-Sentry can fulfill in the upcoming section.
+
+### 4.3 Two-Round Interaction (optional)
+
+Two-round interaction involves builders sending 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. *It's suggested to adopt two-round interaction for builders who do not fully
+trust validator and are not concerned about the additional latency caused by one extra round of communication.*
+
+<img src="https://raw.githubusercontent.com/bnb-chain/BEPs/473fb9e9372cbd0fc58d2d58a0e5d79fab1e5552/BEPs/assets/bep-322/workflow_2round.png" alt="workflow" width="500"/>
+
+1) Builders submit bids without transactions to the in-turn validator.
+2) The validator picks the most valuable bid from all received bids within a predefined time.
+3) The Validator asks the builder for corresponding transactions related to the chosen bid, and also gives the builder
+   its signature as a receipt. The builder should return the full list of transactions.
+4) The validator executes the transactions and verifies the bid (gas received is the same as what is claimed in the bid,
+   even with potential illegal transactions).
+5) If the bid turns to be invalid, the proposer will use a locally mined block and also report detailed errors to the
+   builder. The validator may blacklist the builder for some time or forever if the builder offers invalid transactions.
+6) The validator seals the final block.
+
+There are some **edge cases** should be elaborated:
+
+- If there is no profitable bid compared to local work, the validator should use locally mined block.
+
+- In two-round interaction, if the validator cannot receive the full list of transactions before timeout, the
+  validator should use the locally mined block too, and 1) notify the builder using issue report API; 2) blacklist
+  the builder for a while or even forever.
+
+- If a builder finds that its transactions are stolen by a validator, the builder should 1) refuse to send bids
+  to the validator, 2) disclose the steal to public channels for social influences if necessary.
+
+**Two-Round with MEV-Sentry(optional)** interaction:
+
+A MEV-Sentry can be used for validators to provide several functionalities. The sentry has its own wallet,
+which should be different from the validator's consensus wallet, and append a transfer transaction to send builder fee.
+It can also filter bids and only forward the more profitable ones to a validator. Meanwhile, a validator needs to
+interact with many builders at the same time, sentry helps to hide the validator’s real IP
+information and protect against DDoS and other threats. Therefore, it is highly suggested for validators to run such a
+layer
+in front of itself in real adoption.
+
+<img src="https://raw.githubusercontent.com/bnb-chain/BEPs/473fb9e9372cbd0fc58d2d58a0e5d79fab1e5552/BEPs/assets/bep-322/workflow_2round_proxy.png" alt="workflow" width="1000"/>
+
+After introducing the overall interactions, we would like to highlight some main differences between Ethereum
+Builder Specification here for the readers who are familiar with it.
+
+- As mentioned in the background, the BSC trust model and consensus are different from Ethereum, it is justifiable for
+  builders to
+  send transactions to validators after receiving the receipt signature. In case a builder finds a validator stealing
+  transactions, it can 1) not submit bids to evil validators anymore, 2) reveal evidence to the public channels
+  (e.g., Discords, Github, blogs) for social influence.
+
+- In Ethereum, the fee settlement between builders and validators is conducted using the 'coinbase' reward (for reward
+  to
+  builders)
+  and token transfer (for the 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 validator can run an MEV-Sentry
+  to append a transfer transaction for payment. It will be further discussed in the later section.
+
+### 4.4 APIs
+
+The following APIs are introduced on Builder and BSC client sides, to implement the aforementioned workflows.
+The full specification of these APIs are defined
+in [a repo with swagger and smart contracts](https://github.com/bnb-chain/builder-specs).
+
+#### 4.4.1 Builder APIs
+
+The following APIs should be implemented on Builder.
+
+##### 4.4.1.1 Issues Report
+
+This API is used to report issues to a builder. For example, if a validator finds that a builder's transactions are
+invalid or the transaction API is timeout-ed, a validator can notify the builder.
+
+Request:
+
+```json
+{
+  "jsonrpc": "2.0",
+  "method": "mev_reportIssue",
+  "params": [
+    {
+      "validator": "validator address",
+      "bidHash": "hash of the bid",
+      "error": {
+        "code": -38001,
+        "message": "response message"
+      }
+    }
+  ],
+  "id": 1
+}
+```
+
+Response:
+
+```json
+{
+  "jsonrpc": "2.0",
+  "result": null,
+  "id": 1
+}
+```
+
+#### 4.4.2 Validator APIs
+
+The following APIs should be implemented on the validator side or BSC clients.
+
+##### 4.4.2.1 Bid Block
+
+This API is used by the builder to submit its bid for the current block production. In general, a proposer will use the
+`gas_fee` and `builder_fee_value` (`profit = gas_fee * validator_commission_rate - builder_fee_value`) to find the most
+profitable bid.
+
+Request:
+
+```json
+{
+  "jsonrpc": "2.0",
+  "method": "mev_sendBid",
+  "params": [
+    {
+      "bid": {
+        "block_number": 123456,
+        "parent_hash": "the hash of the parent block",
+        "txs": [
+          "the transactions in the bid"
+        ],
+        "gasUsed": 100,
+        "gasFee": 100000000000,
+        "builderFee": 100000000000
+      },
+      "signature": "the signature of the bid"
+    }
+  ],
+  "id": 64
+}
+```
+
+Response:
+
+```json
+{
+  "jsonrpc": "2.0",
+  "result": "the bid hash",
+  "id": 64
+}
+```
+
+## 5. Further Discussion
+
+### 5.1 Implementation Consideration
+
+With a shorter block time of 3 seconds in BSC compared to Ethereum's 12 seconds, designing for time efficiency becomes
+crucial. Validators must set a cut-off time to stop receiving new bids, and a timeout to retrieve transactions from
+the winning builder. To be more flexible, validators can choose to run a node with or without support for builders,
+so a switch should be considered to turn on/off the feature based on its choice.
+
+<img src="https://raw.githubusercontent.com/bnb-chain/BEPs/473fb9e9372cbd0fc58d2d58a0e5d79fab1e5552/BEPs/assets/bep-322/block_timing.png" alt="block_timing" width="500"/>
+
+### 5.2 Payment & Economic Considerations
+
+A part of BSC's consensus protocol operates as follows: Block proposers initiate transactions by transferring block
+rewards to the validator set contract. During the breathing block at midnight each day, block rewards are distributed to
+delegators and validators based on the staked amounts. **This distribution mechanism is also applicable to MEV income.**
+
+Without changing bsc consensus rule, the following approaches can be taken for the payment from users to builders,
+off-chain or on-chain solutions can be considered:
+
+- Users can subscribe to builders' service. For example, users can pay builder service every month based on different
+  levels of prices.
+
+- Users can insert a transfer transaction into his/her bundles to pay the builder.
+
+For the payment between builders and validators:
+
+- A validator can run a proxy and append transfer transactions to pay builders. If a validator does not append the
+  transfer transaction, a builder can still use the receipt (with the validator’s signature) to ask for settlement using
+  other approaches.
+
+- A validator and a builder can negotiate other off-chain and on-chain approaches that are out of the scope of the
+  specification.
+
+Furthermore, let's also discuss what will happen if a builder or a validator misbehaves.
+
+- If a builder wins a bid and does not return the full list of transactions to a validator, the validator can easily
+  detect this
+  and stop service for the builder. Eventually, the builder will get no income from block production and users
+  will also leave the builder.
+
+- If a validator steals transactions from a builder when there is potential value. The victim builder can detect this.
+  It can stop sending bids to the validator and post evidence (i.e., the signature from a validator) about the
+  misbehavior. The validator will lose the income from the builder and even more builders.
+
+### 5.3 Builder Registration
+
+While this specification doesn't detail the registration process for builders with validators, it does propose a
+promising solution: employing a smart contract for builder registration. In BSC, one smart contract can be implemented
+to provide the following functionalities:
+
+- a validator can register its information (e.g., consensus address, proxy URL) for participation.
+- a builder can deposit some amount of BNB for participation.
+- a builder can register to validators by providing its information (e.g., builder address).
+
+With this kind of smart contract, builders and validators can discover each other easily. It also provides transparency
+for all related stakeholders. An [example](#6-references) is presented to demonstrate such a smart contract.
+
+## 6. References
+
+* [BSC Builder Specs](https://github.com/bnb-chain/builder-specs)
+* [Example Smart Contracts](https://github.com/bnb-chain/builder-specs/examples)
+
+## 7. License
+
+The content is licensed under
+[CC0](https://creativecommons.org/publicdomain/zero/1.0/).