You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Adopt EIP-7688: Forward compatible consensus data structures
EIP-4788 exposes the beacon root to smart contracts, but smart contracts
using it need to be redeployed / upgraded whenever the indexing changes
during a fork, even if that fork does not touch any used functionality.
This problem expands further to bridges on other blockchains, or even
into wallet apps on a phone that verify data from the beacon chain
instead of trusting the server. It is quite unrealistic to expect such
projects to all align their release cadence with Ethereum's forks.
EIP-7688 fixes this by defining forward compatibility for beacon chain
data structures. Electra `Profile` retain their Merkleization even when
rebased to `StableContainer` definitions from future forks, enabling
decentralized protocols to drop the requirement for trusted parties to
periodically upgrade beacon state proof verifiers. (+1 squashed commit)
Squashed commits:
[8b92f7b0f] Adopt EIP-7688: Forward compatible consensus data structures
EIP-4788 exposes the beacon root to smart contracts, but smart contracts
using it need to be redeployed / upgraded whenever the indexing changes
during a fork, even if that fork does not touch any used functionality.
This problem expands further to bridges on other blockchains, or even
into wallet apps on a phone that verify data from the beacon chain
instead of trusting the server. It is quite unrealistic to expect such
projects to all align their release cadence with Ethereum's forks.
EIP-7688 fixes this by defining forward compatibility for beacon chain
data structures. Electra `Profile` retain their Merkleization even when
rebased to `StableContainer` definitions from future forks, enabling
decentralized protocols to drop the requirement for trusted parties to
periodically upgrade beacon state proof verifiers.
Copy file name to clipboardExpand all lines: specs/deneb/p2p-interface.md
+11-4
Original file line number
Diff line number
Diff line change
@@ -14,6 +14,7 @@ The specification of these changes continues in the same format as the network s
14
14
-[Constant](#constant)
15
15
-[Preset](#preset)
16
16
-[Configuration](#configuration)
17
+
-[Custom types](#custom-types)
17
18
-[Containers](#containers)
18
19
-[`BlobSidecar`](#blobsidecar)
19
20
-[`BlobIdentifier`](#blobidentifier)
@@ -66,6 +67,12 @@ The specification of these changes continues in the same format as the network s
66
67
|`MIN_EPOCHS_FOR_BLOB_SIDECARS_REQUESTS`|`2**12` (= 4096 epochs, ~18 days) | The minimum epoch range over which a node must serve blob sidecars |
67
68
|`BLOB_SIDECAR_SUBNET_COUNT`|`6`| The number of blob sidecar subnets used in the gossipsub protocol. |
68
69
70
+
### Custom types
71
+
72
+
| Name | SSZ equivalent | Description |
73
+
| - | - | - |
74
+
|`KZGCommitmentInclusionProof`|`Vector[Bytes32, KZG_COMMITMENT_INCLUSION_PROOF_DEPTH]`| Merkle branch of a single `blob_kzg_commitments` list item within `BeaconBlockBody`|
75
+
69
76
### Containers
70
77
71
78
#### `BlobSidecar`
@@ -79,7 +86,7 @@ class BlobSidecar(Container):
79
86
kzg_commitment: KZGCommitment
80
87
kzg_proof: KZGProof # Allows for quick verification of kzg_commitment
0 commit comments