optimistic-specs
optimistic-specs copied to clipboard
ethereum-optimism
Expose success of L1->L2 transactions in L2 state
Is your feature request related to a problem? Please describe. Currently, we emit an event when L1->L2 message execution throws an exception on L2. This allows users to attempt to replay their message, but not with a different gasLimit, which means that it is possible for a transaction to be always failing. Devs should be able to access this situation where the message was relayed to L2 successfully, but reverted.
Describe the solution you'd like
Instead of the successfulMessages mapping just storing a bool, we could instead store a struct:
struct XDomainMessageStatus {
bool relayed, // whether or not this message got successfully played on L2 yet
bool success // whether or not, if relayed, the message reverted
}
Where the relayed bool would be set to true so long as OVM_L2CrossDomainMessenger.relayMessage call is reached, and the success bool would be equal to that of the external call frame.
Describe alternatives you've considered We could also just have two mappings if backwards compatibility is a concern. Adding getter functions for each of the struct types would make porting to the new model quite easy for devs though.
I believe that this could actually be done in both directions, i.e. make the change to the OVM_L1CrossDomainMessenger as well. In the L1 case, another field could be added to the struct, address relayer, which says who played the message back to L1.
We need to also add a minimum gas limit to guarantee that this mapping is also set. Minimum is in the L1 cross domain messenger contract.
Actually utilizing/enforcing the L2->L1 gas would be a pre-requisite for using the XDomainMessageStatus laid out above in the OVM_L1CrossDomainMessenger as well.
I think this might be better as a discussion on the specs repo. We have several of these sort of issues that probably belong there, so I'll tackle moving them over.
Transferring over to specs repo. We realistically will not implement this within 0.5 but it makes sense to discuss as part of Bedrock.
Relevant related discussion: https://github.com/ethereum-optimism/optimistic-specs/discussions/112#discussioncomment-2446359
Current plan is to by default route L1-L2 transactions through a "messenger" (name might need changing) on L2, which would implement a replay logic. Every transaction would have enough "guaranteed gas" to be able to register for replay.
How that replay logic works has not been discussed yet. I expected we want to store a hash of the transaction data.
If we store a hash of (block_height, tx_data) instead, we could force the sender to include a proof that the tx reverted from the receipt. We can't exactly prove it reverted from out-of-gas (I think) though we can get clause if we require the cumulative used gas to be == the gas limit stored in the data.
Since we already have special processing for deposits in the execution engine, maybe it's not too much work to add custom info to the receipt regarding the execution result.
