Skip to content

Update EIP-7942: Standardize unstable block reference field as unstable_root #10828

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

Open
wants to merge 1 commit into
base: master
Choose a base branch
from
+3 −3
Open

Update EIP-7942: Standardize unstable block reference field as unstable_root #10828

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
6 changes: 3 additions & 3 deletions EIPS/eip-7942.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -84,7 +84,7 @@ We make three main changes:

2. **Replace HLMD-GHOST with Longest Stable Chain fork choice rule.** We replace the HLMD GHOST with the longest chain as the fork choice rule. Our longest chain fork choice rule is very simple: it outputs the head of the chain with the most stable blocks. In case of a tie, the longest chain fork choice rule chooses the chain such that the leaf block has the largest slot number.

3. **Blocks carry a reference `u` to recent unstable blocks to preserve transaction continuity.** We additionally include a field `u` in a block b. Each proposer sets its `u` field as the hash of an unstable block. If there is no such unstable block, set `u` as None. The transactions in the unstable blocks should not conflict with the transactions in the longest chain. The transactions in `u` can also be finalized once block b (that includes `u`) is finalized.
3. **Blocks carry a reference `unstable_root` to recent unstable blocks to preserve transaction continuity.** We additionally include a field `unstable_root` in a block b. Each proposer sets its `unstable_root` field as the hash of an unstable block. If there is no such unstable block, set `unstable_root` as None. The transactions in the unstable blocks should not conflict with the transactions in the longest chain. The transactions in `unstable_root` can also be finalized once block b (that includes `unstable_root`) is finalized.

4. **Simplify the filtering rule and the justification process.** We simplify the filtering rule as it only considers the chain that justifies the last justified checkpoint. Additionally, the justification process only updates when a chain crosses the epoch boundary.

Expand Down Expand Up @@ -145,9 +145,9 @@ Modify `Preparing for a BeaconBlock`

To construct a `BeaconBlockBody`, a `block` (`BeaconBlock`) is defined with the necessary context for a block proposal:

##### unstable
##### unstable_root

Set `block.unstable` as the hash of the latest unstable block if such block exists. If none exists, set `unstable = None`. The transactions in `unstable` must not conflict with the stable chain and will be finalized once `block` is finalized.
Set `block.unstable_root` as the hash of the latest unstable block if such block exists. If none exists, set `block.unstable_root = None`. The transactions in `unstable_root` must not conflict with the stable chain and will be finalized once `block` is finalized.

#### Modification 4

Expand Down