EIP-4844 consensus-specs review fixes
Co-Authored-By: terenc3t <terence@prysmaticlabs.com> Co-Authored-By: djrtwo <dannyjryan@gmail.com>
This commit is contained in:
protolambda
parent
8ec4773339
commit
45e207be4d
|
|
@ -110,7 +110,7 @@ The following gossip validation from prior specifications MUST NOT be applied if
|
|||
### Transitioning the gossip
|
||||
|
||||
See gossip transition details found in the [Altair document](../altair/p2p-interface.md#transitioning-the-gossip) for
|
||||
details on how to handle transitioning gossip topics for Bellatrix.
|
||||
details on how to handle transitioning gossip topics for EIP-4844.
|
||||
|
||||
## The Req/Resp domain
|
||||
|
||||
|
|
|
|||
|
|
@ -31,10 +31,7 @@
|
|||
|
||||
## Introduction
|
||||
|
||||
This upgrade adds transaction execution to the beacon chain as part of Bellatrix upgrade.
|
||||
|
||||
Additionally, this upgrade introduces the following minor changes:
|
||||
* Penalty parameter updates to their planned maximally punitive values
|
||||
This upgrade adds blobs to the beacon chain as part of EIP-4844.
|
||||
|
||||
## Custom types
|
||||
|
||||
|
|
@ -53,6 +50,11 @@ Additionally, this upgrade introduces the following minor changes:
|
|||
| `FIELD_ELEMENTS_PER_BLOB` | `4096` |
|
||||
| `BLS_MODULUS` | `52435875175126190479447740508185965837690552500527637822603658699938581184513` |
|
||||
|
||||
### Domain types
|
||||
|
||||
| Name | Value |
|
||||
| - | - |
|
||||
| `DOMAIN_BLOBS_SIDECAR` | `DomainType('0x0a000000')` |
|
||||
|
||||
## Preset
|
||||
|
||||
|
|
@ -91,11 +93,36 @@ class BeaconBlockBody(Container):
|
|||
sync_aggregate: SyncAggregate
|
||||
# Execution
|
||||
execution_payload: ExecutionPayload
|
||||
blob_kzgs: List[KZGCommitment, MAX_OBJECT_LIST_SIZE] # [New in EIP-4844]
|
||||
blob_kzgs: List[KZGCommitment, MAX_BLOBS_PER_BLOCK] # [New in EIP-4844]
|
||||
```
|
||||
|
||||
## Helper functions
|
||||
|
||||
### KZG core
|
||||
|
||||
KZG core functions. These are also defined in EIP-4844 execution specs.
|
||||
|
||||
#### `blob_to_kzg`
|
||||
|
||||
```python
|
||||
def blob_to_kzg(blob: Blob) -> KZGCommitment:
|
||||
computed_kzg = bls.Z1
|
||||
for value, point_kzg in zip(blob, KZG_SETUP_LAGRANGE):
|
||||
assert value < BLS_MODULUS
|
||||
computed_kzg = bls.add(
|
||||
computed_kzg,
|
||||
bls.multiply(point_kzg, value)
|
||||
)
|
||||
return computed_kzg
|
||||
```
|
||||
|
||||
#### `kzg_to_versioned_hash`
|
||||
|
||||
```python
|
||||
def kzg_to_versioned_hash(kzg: KZGCommitment) -> VersionedHash:
|
||||
return BLOB_COMMITMENT_VERSION_KZG + hash(kzg)[1:]
|
||||
```
|
||||
|
||||
### Misc
|
||||
|
||||
#### `tx_peek_blob_versioned_hashes`
|
||||
|
|
@ -120,9 +147,7 @@ def verify_kzgs_against_transactions(transactions: Sequence[Transaction], blob_k
|
|||
for tx in transactions:
|
||||
if opaque_tx[0] == BLOB_TX_TYPE:
|
||||
all_versioned_hashes.extend(tx_peek_blob_versioned_hashes(tx))
|
||||
return all_versioned_hashes == [
|
||||
kzg_to_versioned_hash(kzg) for kzg in blob_kzgs
|
||||
]
|
||||
return all_versioned_hashes == [ksg_to_version_hash(kzg) for kzg in blob_kzgs]
|
||||
```
|
||||
|
||||
## Beacon chain state transition function
|
||||
|
|
|
|||
|
|
@ -37,13 +37,13 @@ The specification of these changes continues in the same format as the network s
|
|||
|
||||
| Name | Value |
|
||||
| - | - |
|
||||
| `LIMIT_BLOBS_PER_SIDECAR` | `uint64(2**4)` (= 16) |
|
||||
| `MAX_BLOBS_PER_BLOCK` | `uint64(2**4)` (= 16) |
|
||||
|
||||
## Configuration
|
||||
|
||||
| Name | Value | Description |
|
||||
|------------------------------------------|-------------------------------|---------------------------------------------------------------------|
|
||||
| `MAX_REQUEST_BLOBS_SIDECARS` | `2**10` (= 1024) | Maximum number of blobs sidecars in a single request |
|
||||
| `MAX_REQUEST_BLOBS_SIDECARS` | `2**7` (= 128) | Maximum number of blobs sidecars in a single request |
|
||||
| `MIN_EPOCHS_FOR_BLOBS_SIDECARS_REQUESTS` | `2**13` (= 8192, ~1.2 months) | The minimum epoch range over which a node must serve blobs sidecars |
|
||||
|
||||
|
||||
|
|
@ -56,8 +56,7 @@ The specification of these changes continues in the same format as the network s
|
|||
class BlobsSidecar(Container):
|
||||
beacon_block_root: Root
|
||||
beacon_block_slot: Slot
|
||||
shard: uint64 # [ Forward compatibility ]
|
||||
blobs: List[Blob, LIMIT_BLOBS_PER_SIDECAR]
|
||||
blobs: List[Blob, MAX_BLOBS_PER_BLOCK]
|
||||
```
|
||||
|
||||
### `SignedBlobsSidecar`
|
||||
|
|
@ -117,12 +116,12 @@ Alias `sidecar = signed_blobs_sidecar.message`.
|
|||
- _[REJECT]_ the `sidecar.blobs` are all well formatted, i.e. the `BLSFieldElement` in valid range (`x < BLS_MODULUS`).
|
||||
- _[REJECT]_ the beacon proposer signature, `signed_blobs_sidecar.signature`, is valid -- i.e.
|
||||
```python
|
||||
domain = get_domain(state, DOMAIN_BLOBS_SIDECAR, blobs_sidecar.beacon_block_slot / SLOTS_PER_EPOCH)
|
||||
domain = get_domain(state, DOMAIN_BLOBS_SIDECAR, blobs_sidecar.beacon_block_slot // SLOTS_PER_EPOCH)
|
||||
signing_root = compute_signing_root(blobs_sidecar, domain)
|
||||
assert bls.Verify(proposer_pubkey, signing_root, signed_blob_header.signature)
|
||||
```
|
||||
where `proposer_pubkey` is the pubkey of the beacon block proposer of `blobs_sidecar.beacon_block_slot`
|
||||
- _[IGNORE]_ The sidecar is the first sidecar with valid signature received for the `(proposer_index, sidecar.beacon_block_root)` combination,
|
||||
- _[IGNORE]_ The sidecar is the first sidecar with valid signature received for the `(proposer_index, sidecar.beacon_block_slot)` combination,
|
||||
where `proposer_index` is the validator index of the beacon block proposer of `blobs_sidecar.beacon_block_slot`
|
||||
|
||||
Note that a sidecar may be propagated before or after the corresponding beacon block.
|
||||
|
|
@ -132,7 +131,7 @@ Once both sidecar and beacon block are received, `verify_blobs_sidecar` can unlo
|
|||
### Transitioning the gossip
|
||||
|
||||
See gossip transition details found in the [Altair document](../altair/p2p-interface.md#transitioning-the-gossip) for
|
||||
details on how to handle transitioning gossip topics for Bellatrix.
|
||||
details on how to handle transitioning gossip topics for this upgrade.
|
||||
|
||||
## The Req/Resp domain
|
||||
|
||||
|
|
@ -181,7 +180,6 @@ Request Content:
|
|||
(
|
||||
start_slot: Slot
|
||||
count: uint64
|
||||
shard: uint64
|
||||
)
|
||||
```
|
||||
|
||||
|
|
@ -195,8 +193,6 @@ Response Content:
|
|||
Requests blobs sidecars in the slot range `[start_slot, start_slot + count)`,
|
||||
leading up to the current head block as selected by fork choice.
|
||||
|
||||
The request and response format is forward-compatible with sharded sidecar sync, but MUST enforce `shard == 0` for now.
|
||||
|
||||
The response is unsigned, i.e. `BlobsSidecarsByRange`, as the signature of the beacon block proposer
|
||||
may not be available beyond the initial distribution via gossip.
|
||||
|
||||
|
|
@ -232,7 +228,7 @@ participating in the networking immediately, other peers MAY
|
|||
disconnect and/or temporarily ban such an un-synced or semi-synced client.
|
||||
|
||||
Clients MUST respond with at least the first blobs sidecar that exists in the range, if they have it,
|
||||
and no more than `MAX_REQUEST_BLOBS_SIDECARS` blocks.
|
||||
and no more than `MAX_REQUEST_BLOBS_SIDECARS` sidecars.
|
||||
|
||||
The following blobs sidecars, where they exist, MUST be sent in consecutive order.
|
||||
|
||||
|
|
|
|||
|
|
@ -28,7 +28,7 @@ This document represents the changes to be made in the code of an "honest valida
|
|||
|
||||
## Prerequisites
|
||||
|
||||
This document is an extension of the [Bellatrix -- Honest Validator](../altair/validator.md) guide.
|
||||
This document is an extension of the [Bellatrix -- Honest Validator](../bellatrix/validator.md) guide.
|
||||
All behaviors and definitions defined in this document, and documents it extends, carry over unless explicitly noted or overridden.
|
||||
|
||||
All terminology, constants, functions, and protocol mechanics defined in the updated [Beacon Chain doc of EIP4844](./beacon-chain.md) are requisite for this document and used throughout.
|
||||
|
|
@ -56,7 +56,6 @@ def is_data_available(slot: Slot, beacon_block_root: Root, kzgs: Sequence[KZGCom
|
|||
```python
|
||||
def verify_blobs_sidecar(slot: Slot, beacon_block_root: Root,
|
||||
expected_kzgs: Sequence[KZGCommitment], blobs_sidecar: BlobsSidecar):
|
||||
assert blobs_sidecar.shard == 0 # always zero, placeholder for future sharding
|
||||
assert slot == blobs_sidecar.beacon_block_slot
|
||||
assert beacon_block_root == blobs_sidecar.beacon_block_root
|
||||
blobs = blobs_sidecar.blobs
|
||||
|
|
@ -81,7 +80,7 @@ After retrieving the execution payload from the execution engine as specified in
|
|||
the blobs are retrieved and processed:
|
||||
|
||||
```python
|
||||
# execution_payload = xecution_engine.get_payload(payload_id)
|
||||
# execution_payload = execution_engine.get_payload(payload_id)
|
||||
# block.body.execution_payload = execution_payload
|
||||
# ...
|
||||
|
||||
|
|
|
|||
Loading…
Reference in New Issue