Research Area: Introduce Nonce with each Consensus Influencing Event

[tynes]

We should consider introducing a nonce with each log that influences consensus. This would allow for an optimization within the proof programs where they no longer need to observe and filter all logs to guarantee that they have the full set of logs. A witness can be used to populate the logs and the program can check that the nonces all line up to guarantee that the complete set of logs are present within the program.

There are currently 2 logs that impact consensus:

• TransactionDeposited from the OptimismPortal
• ConfigUpdated from the SystemConfig

TransactionDeposited

We could have a nonce on L1 and on L2 and keep them up to date, this could be generally useful to know how many deposits have yet to be processed by offchain software. If we want to hold the invariant that $$L1nonce <= L2nonce$$ then we would need to add the number of deposits inbound in the L1 attributes transaction, since there would be a race condition with upgrading the contracts for existing chains if we simply incremented on L2. This would require a new deposit version and the accumulator would in the L1 attributes transaction would only count deposits that are of the new version

ConfigUpdated

I think that these events can be removed completely from consensus given we follow the pattern designed in https://github.com/ethereum-optimism/specs/issues/122 and a generic form of this