[DO NOT MERGE] [MEL] Changes to OSP contracts

[TucksonDev]

!! WIP - DO NOT MERGE !!

Note

This is a preliminary version, and can completely change, based on changes in the design or the implementation of the feature in nitro.

This PR builds on top of #427 and contains changes to support MEL in the OSP contracts.

Key changes

• Changes related to Assertions handling and the GlobalState can be read in [DO NOT MERGE] [MEL] Changes to Rollup contracts #427
• The State Transition Function (STF) contains now one step that is executed in the first place: message extraction. This step involves reading all parent chain blocks (from the one where the previous assertion was created up to the nextParentChainBlockHash defined in the configuration of the previous assertion), and extract all child chain messages (batches and delayed messages) from them
• Additionally, the way messages are accounted has changed: instead of using "batch number" and "position in batch", there's now one general counter for messages that have been extracted MsgCount and one counter for messages that have been executed ExecutedMsgCount
• Thus, the ExecutionContext doesn't rely on maxInboxMessagesRead and the bridge contract anymore, and instead uses the nextParentChainBlockHash. The GlobalState already contains the MELState hash, which contains the information about the message counters and accumulators.
• We now need to be able to pass a MELState as part of the proof for certain opcodes, so a helper function is added to the Deserialize library.
• A new opcode GetEndParentChainBlockHash (0x8033) is added.
  • We need this opcode since the Machine needs to be able to obtain what’s the boundary of parent chain blocks to extract messages from.
  • Pre-MEL, validators would feed the Machine with the inbox messages needed for the replay binary to complete the block production process.
  • Post-MEL, however, the message extraction process is included in the replay-binary. Thus, the Machine needs to be able to obtain the boundary through an opcode and then extract the messages from the block preimages on its own. It will then use this boundary to verify whether the MELState is at the correct target parent chain block.
• Deprecate the READ_INBOX_MESSAGE opcode
  • Pre-MEL, validators would feed the Machine with the inbox messages needed for the replay binary to complete the block production process. Since these were external host inputs (gathered by validators offchain), we needed a way to prove that a certain message was part of the inboxes
  • Post-MEL, however, the message extraction process is included in the replay-binary. Messages are extracted from parent chain blocks (they are either batches or delayed messages), and we include the hash of the final parent chain block from the assertion config with GetEndParentChainBlockHash. Thus, all prior block hashes are provable with their preimages, and all messages contained in those blocks are then legit. Only ReadPreImage is needed for that. The MELState hash is also included in the GlobalState (provable with GetGlobalState and SetGlobalState), and any intermediate changes to the MELState are provable by the internal wasm instructions that modify them (which are all included as opcodes in the OSP contracts).
  • Tests and CI flow fixes are in [DO NOT MERGE] [MEL] Update rollup, challenge and osp tests #435

Pending work

• Add GetEndParentChainBlockHash opcode
• OneStepProverHostIo: executeReadInboxMessage flow
• Analyze extra flows or opcodes needed for the message extraction function
• Allow for bigger Preimages
• Fix e2e tests (once a nitro version is ready)

Nitro reference PRs

• BoLD with MEL changes nitro#4643

[rauljordan]

Shouldn't this talk to the rollup contract to verify the parent assertion of the challenge has the correct parent chain block hash that is claimed in the inputs here?

[TucksonDev]

Hey @rauljordan , that function is writing the targetParentChainBlockHash available in the ExecutionContext to the Machine. The ExecutionContext is created when calling EdgeChallengeManager.confirmEdgeByOneStepProof(), and it takes the nextParentChainBlockHash from the prevAssertion (here). The prevAssertion is included in the challenge by both contenders, and its config is passed and validated against the on-chain assertion in that same function (so it can be trusted).

Let me know if this answers your question, or if I'm missing something 🙏 .