Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

chore: fix references of builder's comparision factor to boost factor #398

Merged
merged 1 commit into from
Dec 21, 2023
Merged

chore: fix references of builder's comparision factor to boost factor #398

Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
12 changes: 6 additions & 6 deletions apis/validator/block.v3.yaml
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -53,22 +53,22 @@ get:
payload, and receives valid responses from both the builder endpoint _and_ the paired
execution node. When these preconditions are met, the server MUST act as follows:

* if `exec_node_payload_value >= builder_comparison_factor * (builder_payload_value // 100)`,
* if `exec_node_payload_value >= builder_boost_factor * (builder_payload_value // 100)`,
then return a full (unblinded) block containing the execution node payload.
* otherwise, return a blinded block containing the builder payload header.

Servers must support the following values of the comparison factor which encode common
Servers must support the following values of the boost factor which encode common
preferences:

* `builder_comparison_factor=0`: prefer the execution node payload unless an error makes it
* `builder_boost_factor=0`: prefer the execution node payload unless an error makes it
unviable.
* `builder_comparison_factor=100`: default profit maximization mode; choose whichever
* `builder_boost_factor=100`: default profit maximization mode; choose whichever
payload pays more.
* `builder_comparison_factor=2**64 - 1`: prefer the builder payload unless an error or
* `builder_boost_factor=2**64 - 1`: prefer the builder payload unless an error or
beacon node health check makes it unviable.

Servers should use saturating arithmetic or another technique to ensure that large values of
the `builder_comparison_factor` do not trigger overflows or errors. If this parameter is
the `builder_boost_factor` do not trigger overflows or errors. If this parameter is
provided and the beacon node is not configured with a builder then the beacon node MUST
respond with a full block, which the caller can choose to reject if it wishes. If this
parameter is **not** provided then it should be treated as having the default value of 100.
Expand Down
Loading