Skip to content

[ACP-194] update named-block label definitions #214

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 2 commits into
base: main
Choose a base branch
from
Open

[ACP-194] update named-block label definitions #214

Changes from all commits
Commits
Show all changes
2 commits
Select commit Hold shift + click to select a range
b311c09
update named-block label definitions
ARR4N Jun 19, 2025
724696b
fix: current C-Chain support of named blocks
ARR4N Jun 26, 2025
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
20 changes: 13 additions & 7 deletions ACPs/194-streaming-asynchronous-execution/README.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -403,15 +403,21 @@ In particular, the API method `eth_getBlockReceipts` MUST return the receipts co
#### Named blocks

The Ethereum Mainnet APIs allow for retrieving blocks by named parameters that the API server resolves based on their consensus mechanism.
Other than the _earliest_ (genesis) named block, which MUST be interpreted in the same manner, all other named blocks are mapped to SAE in terms of the _execution_ status of blocks and MUST be interpreted as follows:
C-Chain does not currently differentiate between _pending_, _safe_, and _finalized_ labels.
This ACP removes support for _finalized_, and modifies the meanings of _latest_ and _safe_, which MUST each be resolved as:

* _pending_: the most recently _accepted_ block;
* _latest_: the block that was most recently _executed_;
* _safe_ and _finalized_: the block that was most recently _settled_.
* _latest_: the block that was most recently _executed_; and
* _safe_: the block that was most recently _settled_.

> [!NOTE]
> The finality guarantees of Snowman consensus remove any distinction between _safe_ and _finalized_.
> Furthermore, the _latest_ block is not at risk of re-org, only of a negligible risk of data corruption local to the API node.
The interpretation of _latest_ with respect to execution instead of consensus creates APIs that give the illusion of synchronous execution.
This is useful for integration with existing tooling, especially wallets.
The block number returned by APIs MUST, similarly, correspond to _latest_.

Unlike Ethereum's treatment of the _safe_ label (denoting a degree of safety against re-org) under this ACP, safety is absolute and with respect to hard-drive corruption on a specific node, which could result in invalid state.
Such corruption is rare, and waiting for a _safe_ block is therefore only necessary for the most sensitive of applications.
Similar guarantees can also be achieved by comparing a block's post-execution state root across multiple trusted nodes—all would have to be corrupted in the exact same way for such a check to result in a false negative.

The finality guarantees of Snowman consensus obviate the need for a _finalized_ label.

### Observations around transaction prioritisation

Expand Down