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

Jump to bottom

EIP-4844: Move consensus layer part to consensus specs repository #4891

Merged
merged 1 commit into from
Mar 10, 2022
Merged

EIP-4844: Move consensus layer part to consensus specs repository #4891

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
104 changes: 5 additions & 99 deletions EIPS/eip-4844.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -206,106 +206,12 @@ Instead of embedding the full contents in the body, the contents of the blobs ar
This "sidecar" design provides forward compatibility for further data increases by black-boxing `is_data_available()`:
with full sharding `is_data_available()` can be replaced by data-availability-sampling (DAS) thus avoiding all blobs being downloaded by all beacon nodes on the network.

### BeaconBlockBody extension
Note that the consensus-layer is tasked with persisting the blobs for data availability, the execution-layer is not.

We add to the `BeaconBlockBody` a new object, `blob_kzgs: List[KZGCommitment, MAX_OBJECT_LIST_SIZE]`,
and update `BeaconBlock` and `SignedBeaconBlock` to reflect this updated `BeaconBlockBody`.

At the end of the `process_block` state-transition, the `BeaconBlock` and its contained `ExecutionPayload`
need to be cross-validated with `cross_validate(block.body)`.

```python
def cross_validate(body: BeaconBlockBody):
all_versioned_hashes = []
for tx in body.execution_payload.blob_transactions:
all_versioned_hashes.extend(tx.message.blob_versioned_hashes)
assert all_versioned_hashes == [
kzg_to_versioned_hash(kzg) for kzg in body.blob_kzgs
]
```

### BlobsSidecar

We introduce a `BlobsSidecar` container:

```python
class BlobsSidecar(Container):
beacon_block_root: Root
beacon_block_slot: Slot
blobs: List[Blob, MAX_OBJECT_LIST_SIZE]
```

Nodes broadcast the `SignedBeaconBlock` along with its corresponding
`BlobsSidecar` over the network instead of plain beacon blocks.

### Required blobs downloading

When a block is processed, it MUST verify the referenced blobs are available with `is_data_available`.

```python
def process_block(state: BeaconState, block: BeaconBlock) -> None:
is_data_available(block.slot, hash_tree_root(block), block.body.blob_kzgs) # assertion exception if not available.
```

The implementation of `is_data_available` is meant to change with later sharding upgrades.
Initially, it requires every verifying actor to retrieve the matching `BlobsSidecar`,
and verify the sidecar with `verify_blobs`.

```python
def is_data_available(slot: Slot, beacon_block_root: Root, kzgs: Sequence[KZGCommitment]):
sidecar = retrieve_blobs_sidecar(slot, beacon_block_root) # implementation dependent, raises an exception if not available
verify_blobs_sidecar(slot, beacon_block_root, sidecar)
```

```python
def verify_blobs_sidecar(slot: Slot, beacon_block_root: Root,
expected_kzgs: Sequence[KZGCommitment], blobs_sidecar: BlobsSidecar):
assert block_slot == blobs_sidecar.beacon_block_slot
assert beacon_block_root == blobs_sidecar.beacon_block_root
blobs = blobs_sidecar.blobs
assert len(kzgs) == len(blobs)
for kzg, blob in zip(expected_kzgs, blobs):
assert blob_to_kzg(blob) == kzg
```

Without the sidecar the block may be processed further optimistically,
but MUST NOT be considered valid until a valid `BlobsSidecar` has been downloaded.

### P2P changes

Full peer-to-peer specification is out of scope for this EIP, the consensus-specs expands on this instead.

In summary, the peer-to-peer layer changes involve:
- Along other consensus-layer upgrade modifications to `SignedBeaconBlock`, the `beacon_block` gossip topic is updated
and the `beacon_blocks_by_range/2/` and `beacon_blocks_by_root/2/` type tables are updated.
- Blobs sidecars are relayed through a new global GossipSub topic: `blobs_sidecar`
- Blobs sidecars are synced through ReqResp protocols:
`/eth2/beacon_chain/req/blobs_sidecars_by_range/1/` and `/eth2/beacon_chain/req/blobs_sidecars_by_root/1/`,
indexed by slot and beacon block root respectively.

### Block creation through Engine API

Blocks are created through the engine API, passing payload-attributes to start building an execution payload
after a forkchoice update.

*Note*: The final EIP design may return the blobs along with the execution payload, creating `engine_getPayloadV2`.

For encapsulation in the EIP draft phase, the blobs are retrieved separately, through `engine_getBlobV1`.

`engine_getBlobV1`:
- arguments:
- `payload ID (bytes8, DATA, hex string)`
- `versioned hash (bytes32, DATA, hex string)`
- returns:
```
BlobDetailsV1 {
kzg: Bytes48, DATA, hex string
blob: list of Bytes32, elements are DATA, hex string
}
```

Note that the execution-layer may lose and/or prune the Blob, resulting in an error upon calling `engine_getBlobV1`.
The consensus-layer should then build a new execution payload.
The `ethereum/consensus-specs` repository defines the following beacon-node changes involved in this EIP:
- Beacon chain: process updated beacon blocks and ensure blobs are available.
- P2P network: gossip and sync updated beacon block types and new blobs sidecars.
- Honest validator: produce beacon blocks with blobs, publish the blobs sidecars.

### Opcode to get versioned hashes

Expand Down