Update EIP-7685: exclude empty requests data in commitment

EIPS/eip-7685.md

@@ -45,30 +45,30 @@ Each request type will defines its own `requests` object using with its own
 
 #### 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:
+A requests hash list is computed by hashing the elements of the block requests list, but
+only ones where `request_data` is non-empty. Note we assume `request_type` has a size of
+one byte.
 
-```
-sha256(sha256(requests_0) ++ sha256(requests_1) ++ ...)
-```
+The commitment is then computed as the sha256 hash of the list of element hashes.
 
-Or in pseudocode:
 
 ```python
-def compute_requests_hash(requests):
+def compute_requests_hash(block_requests):
     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 +115,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.