PR feedback from @djrtwo

presets/mainnet/eip4844.yaml

@@ -5,4 +5,4 @@
 # `uint64(4096)`
 FIELD_ELEMENTS_PER_BLOB: 4096
 # `uint64(2**4)` (= 16)
-MAX_BLOBS_PER_BLOCK: 16
+MAX_BLOBS_PER_BLOCK: 16

setup.py

@@ -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"

specs/eip4844/beacon-chain.md

@@ -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]
 ```
 

specs/eip4844/p2p-interface.md

@@ -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.
-