Skip to content

[WIP] YAS 226 L2 to L1 Message Passer#42

Merged
ben-chain merged 11 commits intomasterfrom
feat/YAS226/l2-to-l1-message-passer
Mar 18, 2020
Merged

[WIP] YAS 226 L2 to L1 Message Passer#42
ben-chain merged 11 commits intomasterfrom
feat/YAS226/l2-to-l1-message-passer

Conversation

@ben-chain
Copy link
Copy Markdown
Collaborator

Description

Covers YAS 226, L2 to L1 message passer.

Questions

  • The ovmL2ToL1MessagePasserAddress is hardcoded, right now to a joke address, within the EM, and then stored again in constants.ts for off-chain handling.
    • Is is fine to hardcode this way? Might be hard to hunt down in the future, idk.
    • What should the value be? I guess main concern is avoiding collisions with precompiles implemented in the future?
  • Since the message passer is being deployed within the EM constructor now anyway, it is arguable. that we could just add it as a feature to the EM itself. Notably, a question is: would/should the L2ToL1MessagePasser show up in the state tree the. same as another contract?

Metadata

Fixes

  • Fixes YAAS 226

Blockers

  • N/A

Contributing Agreement

Copy link
Copy Markdown

@willmeister willmeister left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looks good! 👍

Left a comment re: general yul call consistency with ExecutionManager.sol, including revert pass-through.

As for the questions:

  1. I like the idea of passing in the l2ToL1MessagePasserOvmAddress in the constructor so as to give us more flexibility in the future. If it doesn't need to be immutable, why not make it configurable? Definitely open to reconsider if there is a good reason.

  2. I'm thinking it should probably not be in the state tree unless there's a good reason. It seems like a contract we'll always need a handle on, not one that we can and should generically invoke. I don't have a very strong opinion on this, though.

Comment on lines +26 to +47
// bitwise right shift 28 * 8 bits so the 4 method ID bytes are in the right-most bytes
bytes32 methodId = keccak256("ovmCALLER()") >> 224;
address addr = executionManagerAddress;

address theCaller;
assembly {
let callBytes := mload(0x40)
calldatacopy(callBytes, 0, calldatasize)

// replace the first 4 bytes with the right methodID
mstore8(callBytes, shr(24, methodId))
mstore8(add(callBytes, 1), shr(16, methodId))
mstore8(add(callBytes, 2), shr(8, methodId))
mstore8(add(callBytes, 3), methodId)

// overwrite call params
let result := mload(0x40)
let success := call(gas, addr, 0, callBytes, calldatasize, result, 500000)

if eq(success, 0) {
revert(0, 0)
}
Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This looks good, but a few suggestions:

  • No need to shift or mstore8 the methodId since the call doesn't take any params. Just pass the first 4 bytes
  • Can get rid of the result and arbitrary return data size in favor of returndatacopy and returndatasize
  • Can add revert reason if it does revert

Copy link
Copy Markdown

@willmeister willmeister Mar 17, 2020

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
// bitwise right shift 28 * 8 bits so the 4 method ID bytes are in the right-most bytes
bytes32 methodId = keccak256("ovmCALLER()") >> 224;
address addr = executionManagerAddress;
address theCaller;
assembly {
let callBytes := mload(0x40)
calldatacopy(callBytes, 0, calldatasize)
// replace the first 4 bytes with the right methodID
mstore8(callBytes, shr(24, methodId))
mstore8(add(callBytes, 1), shr(16, methodId))
mstore8(add(callBytes, 2), shr(8, methodId))
mstore8(add(callBytes, 3), methodId)
// overwrite call params
let result := mload(0x40)
let success := call(gas, addr, 0, callBytes, calldatasize, result, 500000)
if eq(success, 0) {
revert(0, 0)
}
bytes32 methodId = keccak256("ovmCALLER()");
address addr = executionManagerAddress;
address theCaller;
assembly {
let callBytes := mload(0x40)
mstore(callBytes, methodId)
let success := call(gas, addr, 0, callBytes, 4, 0, 0)
let result := callBytes
returndatacopy(result, 0, returndatasize)
if eq(success, 0) {
revert(result, returndatasize)
}
theCaller = mload(result)

@karlfloersch
Copy link
Copy Markdown
Contributor

The ovmL2ToL1MessagePasserAddress is hardcoded

Hmm the question of whether to make the precompile address hardcoded vs configurable is a tricky one. The reason is because this very well might not be our only precompile. If we assume that we end up making a number of precompiles then it would be nice to have a somewhat robust system for setting them all up. Feel like this requires some more thought, and it also might be clearer once we continue building out the system.

Personally I'm down for either hardcoded or in the constructor at this point & probably favor minimal work because whatever we do now will likely have to change down the line.

L2ToL1MessagePasser show up in the state tree the. same as another contract?

Agreed with @willmeister that it probably shouldn't! But definitely can cross that bridge when we come to it.

@ben-chain ben-chain merged commit 71d7985 into master Mar 18, 2020
@gakonst gakonst deleted the feat/YAS226/l2-to-l1-message-passer branch March 18, 2021 15:01
gakonst added a commit that referenced this pull request Apr 12, 2021
snario pushed a commit that referenced this pull request Apr 14, 2021
InoMurko referenced this pull request in omgnetwork/optimism May 25, 2021
smartcontracts added a commit that referenced this pull request Aug 21, 2022
Fixes Spearbit issue 42, saves gas by removing extra SLOADs.
@github-actions github-actions bot mentioned this pull request Sep 20, 2022
protolambda pushed a commit that referenced this pull request Jun 16, 2023
bap2pecs pushed a commit to babylonlabs-io/optimism that referenced this pull request Jul 31, 2024
---------

Co-authored-by: KonradStaniec <konrad.staniec@gmail.com>
cuiweixie pushed a commit to cuiweixie/optimism that referenced this pull request Oct 22, 2025
theochap pushed a commit that referenced this pull request Dec 10, 2025
* feat: System config update event parsing

* clean up enum
Zena-park added a commit to tokamak-network/optimism that referenced this pull request Dec 30, 2025
Zena-park added a commit to tokamak-network/optimism that referenced this pull request Dec 30, 2025
theochap pushed a commit that referenced this pull request Jan 15, 2026
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.

3 participants