status-im/EIPs
2
0
Fork 0
mirror of https://github.com/status-im/EIPs.git synced 2025-02-22 03:38:09 +00:00
Code Issues Projects Releases Wiki Activity

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

Browse Source 
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
This commit is contained in:
g11tech 2021-05-27 16:16:31 +05:30 committed by GitHub
parent df4190c8fb
commit a697e669ec
No known key found for this signature in database
GPG Key ID: 4AEE18F83AFDEB23
1 changed files with 6 additions and 3 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

9
EIPS/eip-3584.md
View File

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