feat(StateVariables): Only write if value is changed in public

[LHerskind]

We should only need to perform write operations in public if the value is different from the current one. Otherwise we are simply wasting resources.

There are multiple variations of this. Differing in how complex they are and the savings they support. Namely at what level we perform the "cleaning".

• At write level: Updating a struct of 4 elements where only 1 changed in a call should just write that 1 value. Can initially be done by the simulator and should be relatively straightforward for us to support in the kernels
• At call level: If the slot takes same value at end and start of a call it should not be doing a write in the call.
• At transaction level: If updating a value to an intermediate value and then setting in back at the end of the transaction should mean that the value is not emitting a state update to L1, the transaction itself is executed as if both updates happened. More complex as needs to go across kernels.
• At block level: Any value that ends in the same value that it started in a block should not emit a change. Meaning that if a transaction is increasing a balance by 10, and another later transaction is reducing the same transaction by 10, it should not emit any changes to L1. The block should have happened as if these changes happened.

The overall goal is:

• 1. reduce the number of writes that are done in a transactions/call such that you can do more complex stuff without running out of writes,
• 2. reduce the number of updates that need to emitted to L1 to cut cost generally.

As a note on this, it should also be considered if it is desired to keep posting diffs as now, or posting the public calls (from private -> public) instead.

[iAmMichaelConnor]

At call level: If the slot takes same value at end and start of a call it should not be doing a write in the call.

There's a slight complication to this one. If in the first 'frame' of a function foo, the slot is changed from 10 to 20, then an external function call is made, and then in the second 'frame' of function foo, the slot is changed from 20 back to 10, then the reads and writes do need to be passed to the public kernel circuit, because re-entrancy might happen. But they're transient reads and writes which can be 'squashed' by the kernel before the 'final' reads and writes are passed to the base rollup circuit.

[LHerskind]

@dbanks12 again relates to circuits and how we are collapsing state changes.

[LHerskind]

Disregarding the squishing/collapsing discussed above. The same goal but achieved entirely inside the public state should be possible for the case where we are overwriting a struct but not the entire thing? I think we right now might still be sending multiple write requests even if the values are unchanged?

[iAmMichaelConnor]

I haven't kept up with how public state is being serialised into "write requests" for the kernel to process, or serialised to L1.
I suppose we need to decide whether we want Aztec to publish intents or state diffs, and I guess that depends on whether we can do a based rollup design?

[LHerskind]

I suppose we need to decide whether we want Aztec to publish intents or state diffs

Yes. Which depends on how independent we make sequencing from proving, which depends on performance and costs of the proving system.