Skip to content

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

Draft
TucksonDev wants to merge 4 commits into
feat/mel-validation-changesfrom
feat/mel-osp-changes
Draft

[DO NOT MERGE] [MEL] Changes to OSP contracts#432
TucksonDev wants to merge 4 commits into
feat/mel-validation-changesfrom
feat/mel-osp-changes

Conversation

@TucksonDev
Copy link
Copy Markdown
Contributor

@TucksonDev TucksonDev commented May 19, 2026

!! 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).

Pending work

  • Add GetEndParentChainBlockHash opcode
  • OneStepProverHostIo: executeReadInboxMessage flow
  • Analyze extra flows or opcodes needed for the message extraction function
  • Allow for bigger Preimages

Nitro reference PRs

@TucksonDev TucksonDev marked this pull request as draft May 19, 2026 09:53
Comment thread src/osp/OneStepProverHostIo.sol Dismissed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants