status-im
/
eth2.0-specs
mirror of https://github.com/status-im/eth2.0-specs.git
2
0
Fork 0
Code Issues Projects Releases Wiki Activity

PR feedback from @djrtwo

This commit is contained in:
Hsiao-Wei Wang 2022-07-15 23:37:32 +08:00
parent a205e9314d
commit 4176781123
No known key found for this signature in database
GPG Key ID: AE3D6B174F971DE4
4 changed files with 3 additions and 9 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

3
setup.py
View File

@ -209,9 +209,6 @@ def get_spec(file_name: Path, preset: Dict[str, str], config: Dict[str, str]) ->
elif source.startswith("class"):
class_name, parent_class = _get_class_info_from_source(source)
# check consistency with spec
if class_name != current_name:
print('class_name', class_name, 'current_name', current_name)
assert class_name == current_name
if parent_class:
assert parent_class == "Container"

2
specs/eip4844/beacon-chain.md
View File

@ -136,7 +136,7 @@ def verify_kzg_commitments_against_transactions(transactions: Sequence[Transacti
all_versioned_hashes = []
for tx in transactions:
if tx[0] == BLOB_TX_TYPE:
all_versioned_hashes.extend(tx_peek_blob_versioned_hashes(tx))
all_versioned_hashes += tx_peek_blob_versioned_hashes(tx)
return all_versioned_hashes == [kzg_commitment_to_versioned_hash(commitment) for commitment in kzg_commitments]
```

5
specs/eip4844/p2p-interface.md
View File

@ -107,7 +107,7 @@ Alias `sidecar = signed_blobs_sidecar.message`.
- _[REJECT]_ The KZG proof is a correctly encoded compressed BLS G1 Point -- i.e. `bls.KeyValidate(blobs_sidecar.kzg_aggregated_proof)
- _[REJECT]_ the beacon proposer signature, `signed_blobs_sidecar.signature`, is valid -- i.e.
```
```py
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)
@ -238,8 +238,6 @@ Clients MUST respond with blobs sidecars that are consistent from a single chain
After the initial blobs sidecar, clients MAY stop in the process of responding
if their fork choice changes the view of the chain in the context of the request.
# Design decision rationale
## Why are blobs relayed as a sidecar, separate from beacon blocks?
@ -250,4 +248,3 @@ thus avoiding all blobs being downloaded by all beacon nodes on the network.
Such sharding design may introduce an updated `BlobsSidecar` to identify the shard,
but does not affect the `BeaconBlock` structure.