docs(yellowpaper): finish AVM Context definitions

[dbanks12]

Preview here

Just finishing AVM Context definitions and initialization (just for initial message calls - not nested ones).

I'm not really sure the best way to describe the world state here in a concise manner 🤔 Did my best here.

[jeanmon]

@dbanks12
Looks very good overall.
Just have look at my little suggestions.

[jeanmon]

The world state structure here is a memory snapshot of persistent data. Could you mention in this lifecycle when the snapshot is made, where modifications happen in memory and when the memory modifications are executed persistently? Maybe no need to describe all details on how we prevent conflicts, etc, but just the model when read and write are performed persistently vs. in memory.

Re-reading what you wrote, I realize it is actually pretty good. Maybe enhancing the above text with explicit mentions about memory changes vs persistent would be great.

[dbanks12]

@jeanmon I don't totally follow 🤔 World State is separate from memory. Something like SSTORE takes a word from memory and stores it into the world state. If a message call fails, any such modifications it made will be rolled back.

So when a caller encounters a nested call, it will take a world state snapshot. If the message call reverts, the caller will reject its world state updates by rolling back to that snapshot.

The circuit doesn't really care about any of this. The circuit just has a storage access trace. Even a reverted message call will have access trace entries for its SSTOREs, but the entire message call will be flagged as reverted, so the kernel knows not to consider those updates for when processing later reads/writes.

[dbanks12]

Snapshots of world state will not be stored in VM memory. In fact they won't even be handled by the VM circuit at all. They are really a higher-level concept that the AVM simulator will use to populate the state traces for each call. And the kernel or rollup circuits will need to know that when a revert happens it shouldn't consider any reverted state updates when validating state accesses that happen later (with higher sideEffectCounter).

[jeanmon]

When I used the word "memory" I meant a memory snapshot of the world state not the memory space of the VM circuit. Sorry for the misunderstanding, the discussion deviated far beyond the original scope. My point was to emphasize a bit more when the memory snapshot is made and when it is written persistently.
Let us align on a call.

[jeanmon]

In the VM circuit I can constrain that memory is initialized with 0 and flag type 0, so that any initial read at memory location (on which we did not write to) returns to zero. If Noir compiler can ensure that we never read from uninitialized memory, we can simply constrain the memory trace that the first memory operation per address is always a write. My point is that we can support both ways. We should just be on the same page with the noir team.

[dbanks12]

Flag type 0 means uninitialized, and I thought that any "loads" from an uninitialized cell would fail. Is that true? Could we get rid of the concept of uninitialized and just say that all cells start tagged as field and initialized to 0?

[jeanmon]

I think enforcing type field initialized with 0 is a bad trade-off. I would consider 2 options:

1. Forbid any uninitialized read
2. Allow read on memory of "uninitialized" words which work with any type and read 0

In the current VM circuit implementation, variant 2) is implemented.
My point is that the circuit should not have any difficulty to support these variants. That's why I would check with Noir team what is preferable.