minimal ePBS with forward inclusion lists and PTC #1
+2,157
−0
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
terencechain
reviewed
Aug 7, 2023
terencechain
reviewed
Aug 7, 2023
terencechain
reviewed
Aug 7, 2023
Also notice that the DA issue only happens if all the transactions are invalidated in the same slot
terencechain
reviewed
Aug 9, 2023
Notice that the whole thing is broken by the construct if index < len(validators) else.
terencechain
reviewed
Aug 9, 2023
- Added handlers for execution payloads and checks inclusion lists availability on consensus blocks
| if slot > message_block.slot: | ||
| return False | ||
| (ancestor_root, is_ancestor_full) = get_ancestor(store, message_root, slot) | ||
| return (root == ancestor_root) and (is_payload_preset == is_ancestor_full) |
There was a problem hiding this comment.
Suggested change
| return (root == ancestor_root) and (is_payload_preset == is_ancestor_full) | |
| return (root == ancestor_root) and (is_payload_present == is_ancestor_full) |
terencechain
reviewed
Oct 4, 2023
manav2401
reviewed
Oct 18, 2023
| - Proposer for slot N submits a signed block and in parallel broadcasts pairs of `summaries` and `transactions` to be included at the beginning of slot N+1. `transactions` are just list of transactions that this proposer wants included at the most at the beginning of N+1. `Summaries` are lists consisting on addresses sending those transactions and their gas limits. The summaries are signed, the transactions aren't. An honest proposer is allowed to send many of these pairs that aren't committed to its beacon block so no double proposing slashing is involved. | ||
| - Validators for slot N will consider the block for validation only if they have seen at least one pair (summary, transactions). They will consider the block invalid if those transactions are not executable at the start of slot N and if they don't have at least 12.5% higher `maxFeePerGas` than the current slot's `maxFeePerGas`. | ||
| - The builder for slot N reveals its payload together with a signed summary of the proposer of slot N-1. Along the summary, the builder includes a list of transactions indices (in strictly increasing order) of the previous payload of slot N-1, that satisfy some entry in the signed inclusion list summary. The payload is considered only valid if the following applies | ||
| - For each index `i` in the payload's `inclusion_list_exclusions`, check that the ith transaction `tx[i]` of the payload for `N-1` satisfies some transaction `T[i]` of the current inclusion list. Here `T[i]` is the first entry in the payload's inclusion list that is satisfied by `tx[i]`. This `T[i]` is removed from the inclusion list summary. |
There was a problem hiding this comment.
It should be payload of "last full block" here instead of N-1 I believe.
There was a problem hiding this comment.
correct, I was trying to keep it simple in the description, but yeah, it has to be of the parent payload. Hopefully the forkchoice and beacon-chain changes do reflect this :)
This was referenced Feb 5, 2024
g11tech
reviewed
Feb 12, 2024
|
|
||
| *Note:* This specification is built upon [Deneb](../../deneb/beacon-chain.md) and is under active development. | ||
|
|
||
| This feature adds new staked consensus participants called *Builders* and new honest validators duties called *payload timeliness attestations*. The slot is divided in **four** intervals as opposed to the current three. Honest validators gather *signed bids* from builders and submit their consensus blocks (a `SigneddBeaconBlock`) at the beginning of the slot. At the start of the second interval, honest validators submit attestations just as they do previous to this feature). At the start of the third interval, aggregators aggregate these attestations (exactly as before this feature) and the honest builder reveals the full payload. At the start of the fourth interval, some honest validators selected to be members of the new **Payload Timeliness Committee** attest to the presence of the builder's payload. |
There was a problem hiding this comment.
Suggested change
| This feature adds new staked consensus participants called *Builders* and new honest validators duties called *payload timeliness attestations*. The slot is divided in **four** intervals as opposed to the current three. Honest validators gather *signed bids* from builders and submit their consensus blocks (a `SigneddBeaconBlock`) at the beginning of the slot. At the start of the second interval, honest validators submit attestations just as they do previous to this feature). At the start of the third interval, aggregators aggregate these attestations (exactly as before this feature) and the honest builder reveals the full payload. At the start of the fourth interval, some honest validators selected to be members of the new **Payload Timeliness Committee** attest to the presence of the builder's payload. | |
| This feature adds new staked consensus participants called *Builders* and new honest validators duties called *payload timeliness attestations*. The slot is divided in **four** intervals as opposed to the current three. Honest validators gather *signed bids* from builders and submit their consensus blocks (a `SignedBeaconBlock`) at the beginning of the slot. At the start of the second interval, honest validators submit attestations just as they do previous to this feature). At the start of the third interval, aggregators aggregate these attestations (exactly as before this feature) and the honest builder reveals the full payload. At the start of the fourth interval, some honest validators selected to be members of the new **Payload Timeliness Committee** attest to the presence of the builder's payload. |
There was a problem hiding this comment.
had to read this like 10 times to find it
g11tech
reviewed
Feb 12, 2024
|
|
||
| ## Genesis | ||
|
|
||
| ### Modified `initialize_beacon_statre_from_eth1` |
There was a problem hiding this comment.
Suggested change
| ### Modified `initialize_beacon_statre_from_eth1` | |
| ### Modified `initialize_beacon_state_from_eth1` |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Eventually this PR will become a full ePBS implementation. Main ingredients are
Some design notes as the PR advances will be put in this file
EDIT: some items are outdated as we finalize the design of ILs. For example we will commit the summary to the beacon block and gossip only the transactions, this simplifies a bit some of the containers in this PR that are currently signed envelopes.