feat: support l2 plus

[karlem]

Part of #1080

This PR focuses on:

Integration Tests in Solidity (L3-Level Testing)

• Write and run integration tests to cover the following scenarios:
  • Happy Path Scenarios:
    • From root to L3. - DONE
    • From L3 to root. - DONE
    • Between sibling L3 nodes. - DONE
  • Failure Scenarios:
    • Errors at the destination. - DONE
    • Errors midway through execution. Not sure this is really an issue.
  • Edge Case Testing:
    • Supply source mismatches. - This should really not be an issue - as the only cross net messages allowed are Call kind. (not trasfers)
    • Non-existent destinations. - DONE
  • Ensure all error cases propagate correctly. - DONE

Improvements

• Improved visibility by adding new events into the cross-message propagation process. A cross-message ID has been added to each event for better tracking and transparency:
  • CheckpointCommitted
  • NewBottomUpMessage
  • MessageStoredInPostbox
  • MessagePropagatedFromPostbox
• Automated cross-message propagation from the postbox. Previously, this process required an external caller to propagate the message, but now the IPC automatically propagates them after a checkpoint has been committed or after top-down messages have been applied.
• Added a check to verify that the destination address is indeed a contract and not an EOA (Externally Owned Account).
• Changed the behavior when applying messages: instead of reverting when a message is invalid, a result receipt is returned. This ensures that one invalid message does not disrupt the entire checkpoint submission process.
• Extracted message validation into a separate function to ensure validation is completed before committing the message. The validation function does not revert since reversion is only desirable when the message is directly triggered by a user. In scenarios where the message originates from a different subnet (e.g., in the form of a checkpoint), reversion is not appropriate. For the same reason, the commit functions (top-down, bottom-up) should also not revert, as they are triggered by automatic postbox propagation. Instead, validation is performed beforehand.

[raulk]

Some minor comments.

[cryptoAtwill]

is there a reason why it's not reverted? Feels like it's an error that should be handled instead of introducing root = 0 as invalid subnet. Probably in some use cases root: 0, route: [] is a valid use case.

[raulk]

Sounds like this needs multi-return? SubnetID + bool?

[karlem]

The problem here is that if I revert, I lose control elsewhere. The method is also used invalidateCrossMessage, where reverting is not desirable. Additionally, commonParent method here returns the empty subnet ID instead of reverting. But I understand your point—if this were deployed on Ethereum, the root could be zero. Would returning a boolean (indicating whether it was found or not) help?

[cryptoAtwill]

@karlem Another question I have is regarding nonce. Say a bottom up message is created in L3, the nonce will be set by the local network. Then in L2, will the cross network message nonce change? If so, then the id (keccak) will change too?

[raulk]

Some initial comments.

[raulk]

Why?

[karlem]

Because it was labeled as a top-down message, but the path (from, to) made it a bottom-up message, the test was incorrect. Since we now have checks ensuring that top-down messages are indeed top-down (as a parent can't send a message to itself), this would cause a revert.

[karlem]

@karlem Another question I have is regarding nonce. Say a bottom up message is created in L3, the nonce will be set by the local network. Then in L2, will the cross network message nonce change? If so, then the id (keccak) will change too?

Hmm that's a good point. I will think about how to mitigate this.

[karlem]

@cryptoAtwill should be ready for another review :)