Automatically merged updates to draft EIP(s) 3584 (#3593)

Hi, I'm a bot! This change was automatically merged because:

 - It only modifies existing Draft, Review, or Last Call EIP(s)
 - The PR was approved or written by at least one author of each modified EIP
 - The build is passing

EIPS/eip-3584.md

@@ -78,10 +78,11 @@ Additional validation rules for the above are that:
 All sorting is in increasing order.
 
 ### AccessListRoot
-An `AccessListRoot` is a *URN* encoding `Hash/Commitment` of the canonical `access_list` as well as the construction type (`sha256`), i.e.
+An `AccessListRoot` is a URN *like* encoding `Hash/Commitment` of the canonical `access_list` as well as the construction type ( `sha256` ) and serialization type ( `json` ), i.e.
 ```
-AccessListRoot := "urn:sha256:${ SHA256( access_list ) }"
+AccessListRoot := "urn:sha256:json:0x${ SHA256( access_list.toJSONString('utf8') ).toHexString() }"
 ```
+where `0x${ SHA256 (...)...}` is the `SHA256` hashed `32` bytes hex string as indicated by leading `0x`.
 
 ### Additional Block Validation
 Validating a new block requires an additional validation check that the block’s `AccessListRoot` matches the one generated by executing the block using the construction as defined by the `AccessListRoot` URN.
@@ -96,7 +97,9 @@ Even though `AccessListRoot` is currently specified to be a simple `sha256` hash
 * a tree structure (`merkle`/`verkle`). It will be a bit more expensive but will enable partial downloading, inspection and validation of the `access_list`. 
 * a normal `kate` commitment can also be generated to enable this partial capability and is recommended as validating partial fetch of access list chunks would be very simple. 
 
-So this AccessListRoot could evolve to `urn:merkle:...` or to `urn:kate:...` or to any other scheme as per requirement. And the idea of having the `AccessListRoot` as URN is to enable upgradation to these paths without affecting block structure.
+Also serialization of the `access_list` is currently specified as a normal `JSON String` dump and these parameters could vary from construction to construction, but for the sake of simplicity, it can always be `sha256` hashed to get a consistent `32` bytes hex string root.
+
+So this AccessListRoot could evolve to `urn:merkle:ssz:...` or to `urn:kate:...` or to any other scheme as per requirement. And the idea of having the `AccessListRoot` as URN *like* structure is to enable upgradation to these paths without affecting block structure.
 
 
 ### Future extensions of `access_list`