One sub-component of "State Expiry" and the underlying changes to the storage layout within the trie are that code will now be chunked and stored within the trie itself.
One thing that we want to verify is that tracking code chunk access will indeed be relatively trivial. Write a quick POC in a client that tracks code chunk access using something like the bitfield approach suggested by Vitalik on the call. (see call recording about 20-30 minutes into the call). Is it indeed trivial to implement? Are there any hidden complexities?
Suggested methodology for this would probably be to run a modified client, though it is possible the necessary information is available through the transaction tracing APIs as well.
One sub-component of "State Expiry" and the underlying changes to the storage layout within the trie are that code will now be chunked and stored within the trie itself.
https://notes.ethereum.org/@vbuterin/verkle_tree_eip#Code
One thing that we want to verify is that tracking code chunk access will indeed be relatively trivial. Write a quick POC in a client that tracks code chunk access using something like the bitfield approach suggested by Vitalik on the call. (see call recording about 20-30 minutes into the call). Is it indeed trivial to implement? Are there any hidden complexities?
Suggested methodology for this would probably be to run a modified client, though it is possible the necessary information is available through the transaction tracing APIs as well.