AVM: spec header access

[dbanks12]

No description provided.

[fcarreiro]

Some notes on this, from other people:

From David: Regarding HEADERMEMBER, it is really the least-specced opcode at this time. [We should look into what it should do] I think what we want is for HEADERMEMBER to do the following:

• Internally to the simulator, retrieve the entire header at the specified block (use the getHeader db call - will need to add this to an interface in our "HostStorage")
• Return to the user the requested word/member from that header
• Indicate whether a header actually exists at that block number (can actually check this just by checking that the provided block index is less than the current block number)

Note: we probably also need to trace the entire header (although I didn't add that to the trace struct in the spec)! That is because the current plan is for the VM circuit to accept the entire header as a public input, and then hash it to an archive leaf. The kernel will get a list of archive leaves to membership check.

From Lasse: For a lot of the state in there, seems somewhat nasty to make membership proofs available. e.g., if I can have transaction that need to provide a membership proof in historical state, then only archive nodes can satisfy it. So a lot of these cases you would do in private anyway. So it might just be specifying the actual values. That way you could have airdrops or whatever where you are specifying that it uses a given root or whatever. So in my mind, it is GET_MEMBER_OF_HISTORICAL_HEADER, if that makes sense.

From Maddiaa: We will split header member into 6 opcodes each representing the root of a different state tree @ block number that is the input

1. l1 to l2 messages tree root
2. note hash tree root
3. nullifier tree root
4. contract tree root
5. public data tree root
6. archive tree root
   I have decided to do this as this is what i envision David was going for whenever this opcode was added to the spec, to have a way to access the roots of these trees ( contained in the header ).

Why:
Adding these opcodes covers the intended functionality, and having them bespoke for each state access should be functionally easier to prove.

Could this change in the future:
Most of these membership proofs could be done in private, and the result of the proof provided to a user function, this design will be cheaper for application devs, so in the future it may be the canonical route to accessing this functionality, we can remove it in time if that decision is made. I do not think the opcode implementation will take too long to perform.

[fcarreiro]

We've decided to deprioritize this one for a while.