Skip to content

Latest commit

 

History

History
7 lines (4 loc) · 2.31 KB

development-update-2.md

File metadata and controls

7 lines (4 loc) · 2.31 KB

Development Update #2

Since my last update, I created a detailed project plan and roadmap, which can be found here and here. Shortly after I posted these, a new statelessness roadmap was published which proposes replacements for the access lists I was planning to focus on for my project. I decided to proceed with my project in its current form for now, but certain parts may change in the coming weeks so that it fits in better with the new roadmap e.g. perhaps doing some analysis on the new ideas for access lists rather than solely EIP-3586.

My first task was to create an experimental fork of py-evm that publishes access lists in the form laid out by EIP-3586. I thought this would be a good thing to start with as a way to learn what an implementation of the evm looks like, and how changes to the protocol are implemented. First, this involved identifying where existing versions of the access lists were implemented. I chose to use the EIP-2930 typed transaction version of the access lists for this - there were some existing tests for the 2930 lists that I thought I could work off, and it was less obvious to me how I could use the 2929 lists. I set up some tests under the london fork VM that mocked a number of typed transactions with tx-level lists, and then modified the chain logic so that the collated block-level access list is populated from the transaction level lists before the block is published. The changes that I implemented can be seen here. Note that this is very much prototype/research code to help with my project and it is ugly :) The goal of this work was to have a testable version of this EIP so that I could check my understanding of the block lists, and to eventually act as a testbed/sanity-check for my experiments on how the witness proofs will work with them.

The access-list object that is included in the header acts as the ‘document’ or ‘canonical access list’ as laid out in the EIP. The next step here would be to store this list somewhere else in the block and place a hash of it in the header. This is what I will be working until the next development update. The specific hash method was not decided on in the EIP, and will depend on the witness proofs.