Update EIP-7685: exclude empty requests data in commitment

EIPS/eip-7685.md

@@ -33,42 +33,46 @@ update on the execution block structure.
 
 #### Requests
 
-A `requests` object consists of a `request_type` prepended to an opaque byte
-array `request_data`.
+A `requests` object consists of a `request_type` prepended to an opaque byte array
+`request_data`. The `request_data` contains zero or more encoded request objects.
 
 ```
 requests = request_type ++ request_data
 ```
 
-Each request type will defines its own `requests` object using with its own
-`request_data` format.
+Each request type will defines its own `requests` object with its own `request_data` format.
 
 #### Block Header
 
-Extend the header with a new 32 byte value `requests_hash`.
+Extend the header with a new 32 byte commitment value `requests_hash`.
 
-The construction looks like:
+While processing a block, multiple `requests` objects with different `request_type`s will
+be produced by the system, and accumulated in the block requests list.
 
-```
-sha256(sha256(requests_0) ++ sha256(requests_1) ++ ...)
-```
+In order to compute the commitment, an intermediate hash list is first built by hashing
+all non-empty requests elements of the block requests list. Items with empty
+`request_data` are excluded, i.e. the intermediate list skips `requests` items which
+contain only the `request_type` (1 byte) and nothing else.
+
+Within the intermediate list, `requests` items must be ordered by `request_type` ascending.
 
-Or in pseudocode:
+The final commitment is computed as the sha256 hash of the intermediate element hashes.
 
 ```python
-def compute_requests_hash(requests):
+def compute_requests_hash(block_requests: Sequence[bytes]):
     m = sha256()
-    for r in requests:
-        m.update(sha256(r))
+    for r in block_requests:
+        if len(r) > 1:
+            m.update(sha256(r).digest())
     return m.digest()
 
 block.header.requests_hash = compute_requests_hash(requests)
 ```
 
 ### Consensus Layer
 
-Each proposal may choose how to extend the beacon chain types to include new EL
-request types.
+Each proposal may choose how to extend the beacon chain types to include new EL request
+types.
 
 ## Rationale
 
@@ -115,6 +119,12 @@ Within the same type, order is not defined. This is because the data of the
 request is opaque as far as this EIP is concerned. Therefore, it is to be
 determined by each request type individually.
 
+### Removing empty requests in commitment
+
+We exclude empty requests elements from the `requests_hash` commitment in order to get a
+stable 'empty' hash value that is independent of the blockchain fork. For a block with no
+requests data, the `requests_hash` is simply `sha256("")`.
+
 ## Backwards Compatibility
 
 No backward compatibility issues found.