Skip to content

Commit

Permalink
chore: fmt without content change
Browse files Browse the repository at this point in the history
  • Loading branch information
@reneecok
reneecok committed Nov 28, 2023
1 parent 8ecf2e8 commit c0797d1
Showing 1 changed file with 103 additions and 143 deletions.
246 changes: 103 additions & 143 deletions BEPs/BEP322.md
View file
Original file line number Diff line number Diff line change
Expand Up @@ -25,63 +25,48 @@
## 1. Summary

In Ethereum, a [builder](https://github.com/ethereum/builder-specs) orders transactions from users/searchers and submits
them to consensus
layer clients for proposing new blocks. This BEP introduces a builder
api specification for running builders on BNB Smart Chain. This
specification mainly defines the communication workflow and the
application interfaces between builders and validators, as well as the
economic considerations for real adoptions.
them to consensus layer clients for proposing new blocks. This BEP introduces a builder api specification for running
builders on BNB Smart Chain. This specification mainly defines the communication workflow and the application interfaces
between builders and validators, as well as the economic considerations for real adoptions.

## 2. Motivation

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).
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 [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). 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
- 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.

## 3. Specification

### 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. 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
general) and maintain a high reputation. Misbehaviour will lead to
reputation damage and un-delegations. Currently, there are about
40 validators (more validators are coming) with 20M BNB staked, including active and inactive
ones. In Ethereum, the barrier to becoming a validator is very
low (i.e., 32 ETH), and there are more than [800 thousand Ethereum
validators](https://www.nasdaq.com/articles/the-most-pressing-issue-on-ethereum-is-validator-size-growth).
It means that a validator can be anyone, and it can enter or quit
easily. That's quite different from BSC.

- Meanwhile, the relay role in Ethereum Builder API is supposed to be
trusted by both builders and validators. In BSC, the necessity of
introducing another trusted role is not that much. In this
specification, we don't utilize relay; however, it is still
workable to add relay between builders and validators.
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. 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 general) and maintain a high reputation. Misbehaviour will lead to reputation damage and
un-delegations. Currently, there are about 40 validators (more validators are coming) with 20M BNB staked,
including active and inactive ones. In Ethereum, the barrier to becoming a validator is very low (i.e., 32 ETH),
and there are more
than [800 thousand Ethereum validators](https://www.nasdaq.com/articles/the-most-pressing-issue-on-ethereum-is-validator-size-growth).
It means that a validator can be anyone, and it can enter or quit easily. That's quite different from BSC.

- Meanwhile, the relay role in Ethereum Builder API is supposed to be trusted by both builders and validators.
In BSC, the necessity of introducing another trusted role is not that much. In this specification,
we don't utilize relay; however, it is still workable to add relay between builders and validators.

### 3.2 Workflow

Expand All @@ -106,147 +91,125 @@ The overall workflow for proposing a block is as follows:
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).

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.
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.

![workflow](./assets/bep-322/workflow_2round.png)

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.
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.

![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.
This option can also use a validator proxy for payment.

![workflow](./assets/bep-322/workflow_1round.png)

Here, we would like to highlight some main differences between Ethereum
Builder Specification here for the readers who are familiar with it.

- In Ethereum, a block header is passed from a builder to a validator
for sign, and then a block can be broadcast to the network
without revealing the transactions to a validator. In BSC, to
generate a valid block header, transactions in the block should be
executed as well as several system contract calls (e.g., transfer
coinbase, deposit to the validator set contract), it is not possible for a
builder to do these. Meanwhile, as mentioned in the previous
section, the trust model in BSC is different to Ethereum; it is
workable 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., chatting groups, github, blogs) for
social influence.

- In Ethereum, the fee settlement between builders and validators is
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
validator can run a proxy to append transfer transaction for payment.
It will be further discussed in the later section.
Here, we would like to highlight some main differences between Ethereum Builder Specification here for the readers
who are familiar with it.

- In Ethereum, a block header is passed from a builder to a validator for sign, and then a block can be broadcast
to the network without revealing the transactions to a validator. In BSC, to generate a valid block header,
transactions in the block should be executed as well as several system contract calls (e.g., transfer coinbase,
deposit to the validator set contract), it is not possible for a builder to do these.
Meanwhile, as mentioned in the previous section, the trust model in BSC is different to Ethereum, it is workable
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., chatting groups, github, blogs) for social influence.

- In Ethereum, the fee settlement between builders and validators is 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 validator can run a proxy
to append transfer transaction for payment. It will be further discussed in the later section.

#### 3.2.2 Edge Cases

For the two-way and multiple round communication between builders and
validators, there could be some special cases.
For the two-way and multiple round communication between builders and validators, there could be some special cases.

- If the validator cannot receive full transactions before timeout,
the validator should 1) notify the builder using issue api (see
later more details), 2) refuse the builder's bids for a while or
even forever.
- If the validator cannot receive full transactions before timeout, the validator should
1) notify the builder using issue api (see later more details),
2) refuse the builder's bids for a while or even forever.

- If a validator finds the transactions from a builder is invalid,
the validator should 1) notify the builder using api calls, 2)
refuse the builder's bids for a while or even forever.
- If a validator finds the transactions from a builder is invalid, the validator should
1) notify the builder using api calls,
2) refuse the builder's bids 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.
- 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.

#### 3.2.3 Implementation Considerations

Firstly, on BSC, the blocking time is only 3 seconds, which means a
validator must set a cut-off time to stop receiving new bids, and a
timeout to retrieve transactions from the winning builder.
Meanwhile, to reduce latency, the one round interaction (i.e., builders send bids and transactions together)
Firstly, on BSC, the blocking time is only 3 seconds, which means a validator must set a cut-off time to stop receiving
new bids, and a 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)

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.
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.

Thirdly, as mentioned earlier, a proxy can be used for payment by appending transfer transactions.
Meanwhile, for a validator it needs to interact with many builders at the same time.
A proxy can also be implemented to protect validators, e.g., hiding validator’s real
IP information, protecting against DDoS, and others.
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)

### 3.3 Payment & Economic Considerations

On BNB Smart Chain, the coinbase reward must be distributed to the block
proposer (i.e., a validator) and transferred to a system contract.
Without changing the consensus rule, these following approaches can be
taken for payment.
On BNB Smart Chain, the coinbase reward must be distributed to the block proposer (i.e., a validator) and
transferred to a system contract. Without changing the consensus rule, the following approaches can be taken for
payment.

For payment from users to builders, off-chain or on-chain solutions can
be considered.
For 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 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.
- 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 validator’s signature) to ask for settlement using other approaches.
- 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 validator’s signature) to ask for settlement
using other approaches.

- A validator and a builder can negotiate other off-chain on-chain approaches which are out of scope of the
specification.

Furthermore, let's also discuss what will happen if a builder or a
validator misbehaves.
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 full 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, consequently users will also leave the builder.
- If a builder wins a bid and does not return full 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,
consequently 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 and stop
sending bids to the validator, and also can 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.
- If a validator steals transactions from a builder when there is potential value. The victim builder can detect this
and stop sending bids to the validator, and also can 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.

### 3.4 APIs

Following APIs are introduced on Builder and BSC client sides, to
implement the aforementioned workflows. The full specification of these
APIs is defined in [a repo with swagger and smart
contracts](https://github.com/bnb-chain/builder-specs).
Following APIs are introduced on Builder and BSC client sides, to implement the aforementioned workflows.
The full specification of these APIs is defined
in [a repo with swagger and smart contracts](https://github.com/bnb-chain/builder-specs).

#### 3.4.1 Builder APIs

The following APIs should be implemented on Builder.

##### 3.4.1.1 Retrieve Transactions

This api is used by the validator to ask for full transactions once a
builder's bid is chosen. The request body will be treated as a receipt
for payment settlement.
This api is used by the validator to ask for full transactions once a builder's bid is chosen.
The request body will be treated as a receipt for payment settlement.

<table>
<tr>
Expand Down Expand Up @@ -328,10 +291,8 @@ for payment settlement.

##### 3.4.1.2 Notify Issues

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 txs
api is timeout-ed, a validator can notify the builder.

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 txs api is timeout-ed, a validator can notify the builder.

<table>
<tr>
Expand Down Expand Up @@ -391,10 +352,9 @@ The following APIs should be implemented on the validator side or BSC clients.

##### 3.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.
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.

<table>
<tr>
Expand Down Expand Up @@ -478,9 +438,9 @@ An [example](#5-references) is presented to demonstrate such a smart contract.

### 4.2 Proxy for Validator

As mentioned earlier, a proxy can be used for validators to provide several functionalities,
including payment to builders, filtering bids, protection of DDoS, and so on.
Therefore, it is highly suggested for validators to run such a layer in real adoption.
As mentioned earlier, a proxy can be used for validators to provide several functionalities, including payment to builders,
filtering bids, protection of DDoS, and so on. Therefore, it is highly suggested for validators to run such a layer in
production.

## 5. References

Expand Down

0 comments on commit c0797d1

Please sign in to comment.