feat: support l2 plus #1157

karlem · 2024-09-26T16:32:51Z

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.

contracts/contracts/gateway/GatewayMessengerFacet.sol

raulk

Some minor comments.

contracts/contracts/gateway/GatewayMessengerFacet.sol

contracts/contracts/gateway/router/CheckpointingFacet.sol

contracts/contracts/lib/AssetHelper.sol

contracts/contracts/gateway/router/XnetMessagingFacet.sol

contracts/contracts/lib/CrossMsgHelper.sol

cryptoAtwill · 2024-10-24T07:04:12Z

contracts/contracts/lib/SubnetIDHelper.sol

    function down(SubnetID calldata subnet1, SubnetID calldata subnet2) public pure returns (SubnetID memory) {
        if (subnet1.root != subnet2.root) {
-            revert DifferentRootNetwork();
+            return SubnetID({root: 0, route: new address[](0)});


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.

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

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?

contracts/contracts/lib/LibGateway.sol

contracts/contracts/lib/CrossMsgHelper.sol

contracts/test/integration/L2PlusSubnet.t.sol

cryptoAtwill · 2024-10-24T09:27:11Z

@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.

contracts/contracts/errors/IPCErrors.sol

contracts/contracts/lib/LibGateway.sol

contracts/test/helpers/TestUtils.sol

raulk · 2024-10-24T16:26:15Z

contracts/test/integration/L2GatewayDiamond.t.sol

                IPCAddress({
                    subnetId: gatewayDiamond.getter().getNetworkName().getParentSubnet(),
                    rawAddress: FvmAddressHelper.from(receipient)
                }),
+                IPCAddress({subnetId: id, rawAddress: FvmAddressHelper.from(address(this))}),


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.

contracts/test/integration/L2PlusSubnet.t.sol

karlem · 2024-10-24T20:53:19Z

@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 · 2024-10-28T14:40:30Z

@cryptoAtwill should be ready for another review :)

cryptoAtwill

LGTM. But I do have a few follow up questions though:

Does it work in calibration with a live 3 level network? Is there a testnet we can try or planned?
propagateAll is called in the parent as part of bottom up checkpoint. Bottom up checkpoint is already quite gas costly, not sure if this will burst the gas even more.

cryptoAtwill · 2024-11-19T12:06:25Z

contracts/contracts/lib/CrossMsgHelper.sol

@@ -131,6 +135,22 @@ library CrossMsgHelper {
        return keccak256(abi.encode(crossMsg));
    }

+    /// @notice Returns a deterministic hash for the given cross message. The hash remains the same accross different networks
+    /// because it doesn't include the network-specific nonce.
+    function toDeterministicHash(IpcEnvelope memory crossMsg) internal pure returns (bytes32) {


I guess most of the time this is ok, but will this cause conflict if say someone sends the same message twice?

It might collide, but it is only for logging so it should not matter.

cryptoAtwill · 2024-11-19T12:14:36Z

contracts/contracts/lib/LibGateway.sol

+    /// `Call` cross-messages also trigger receipts if they are successful.
+    /// @param arrivingFrom - the immediate subnet from which this message is arriving
+    /// @param crossMsg - the cross message to be executed
+    /// @param expectTopDownOnly - whether the message should be top-down only. Reverts if it is not.


I think I was misled by the comment here. The idea is whether the message should be top-down only. Reverts if this flag is true but the crossmsg is actually bottom up?

Reverts if it's both - not only top down :)

karlem · 2024-11-20T09:29:08Z

Does it work in calibration with a live 3 level network? Is there a testnet we can try or planned?

It should. Whether is Calibration or not.

propagateAll is called in the parent as part of bottom up checkpoint. Bottom up checkpoint is already quite gas costly, not sure if this will burst the gas even more.

We don't really have any other option here. I don't think we really optimise for gas efficiency at this stage. Moving forward we might re-write the contracts L2+ as native actors to make it cheaper.

cryptoAtwill

I think this is no longer correct: https://github.com/consensus-shipyard/ipc/pull/1157/files#diff-71559bfe927afaf1a3980c01ffe9f4d15c77d58650b2d850bbae821de9c009d0R49.

This implicitly assumes the token behind envelop.value is the native token in the origin subnet. If say I want to trigger transfer from address A to address B in L1 and I'm sending from L3, why should I attach that amount in msg.value?

It comes back to the definition of envelop.value, is it just the native token transfer in the target subnet. If this is the case, it does not make sense to have this check.

karlem · 2024-11-27T20:10:15Z

@cryptoAtwill The issue was resolved by not using or supporting native token transfers in the Call message.

cryptoAtwill reviewed Sep 27, 2024

View reviewed changes

contracts/contracts/gateway/GatewayMessengerFacet.sol Show resolved Hide resolved

karlem force-pushed the support-l2-plus branch from 7696425 to 463ee74 Compare October 11, 2024 15:21

karlem changed the title ~~Support l2 plus~~ feat: support l2 plus Oct 11, 2024

karlem marked this pull request as ready for review October 11, 2024 20:03

karlem requested a review from a team as a code owner October 11, 2024 20:03

cryptoAtwill reviewed Oct 15, 2024

View reviewed changes

contracts/contracts/gateway/GatewayMessengerFacet.sol Outdated Show resolved Hide resolved

raulk reviewed Oct 16, 2024

View reviewed changes

cryptoAtwill requested changes Oct 24, 2024

View reviewed changes

raulk reviewed Oct 24, 2024

View reviewed changes

karlem force-pushed the support-l2-plus branch from 0d896a7 to ff75e79 Compare October 28, 2024 14:35

karlem requested review from raulk and cryptoAtwill October 28, 2024 14:35

cryptoAtwill approved these changes Nov 19, 2024

View reviewed changes

cryptoAtwill force-pushed the support-l2-plus branch from e28e275 to ff75e79 Compare November 26, 2024 06:16

cryptoAtwill requested changes Nov 27, 2024

View reviewed changes

karlem added 11 commits November 27, 2024 20:25

feat: add simple tests

23dcfce

feat: happy path with propagateAll

112fd17

feat: add more tests

7edddeb

feat: check for proper path propagation

da3b2f0

feat: added result paths to test

0e1a273

feat: add extra test and emits

cf20f3c

feat: add missing actor tests + refactor

2c3410e

feat: move validation

866f759

feat: commit cross messages does not revert & fix tests

e4be237

feat: remove logs

3521d4e

feat: fix tests

c64e9f3

karlem added 13 commits November 27, 2024 20:26

feat: fmt

532e696

feat: send across mixed token supplies

6d75b2e

feat: propagate top down automatically

6cd57e6

feat: fmt & lint

8246dec

feat: add extra check

bfc1362

feat: fix test & lint

c078f8a

feat: fix comments

5a52eac

feat: fix comments

c6fe15a

feat: change error message

993db02

feat: make sure ID is the same cross network & fix down func

891ca15

feat: update from comments

c8546a0

feat: do not move funds with call kind

e0586e4

feat: rebase fixes

e514fdb

karlem force-pushed the support-l2-plus branch from a7c17ee to e514fdb Compare November 27, 2024 20:08

karlem added 2 commits November 27, 2024 21:11

feat: fmt

8c0942c

feat: storage layout

1585e1b

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

feat: support l2 plus #1157

feat: support l2 plus #1157

karlem commented Sep 26, 2024 •

edited

Loading

raulk left a comment

cryptoAtwill Oct 24, 2024

raulk Oct 24, 2024

karlem Oct 24, 2024

cryptoAtwill commented Oct 24, 2024

raulk left a comment

raulk Oct 24, 2024

karlem Oct 24, 2024

karlem commented Oct 24, 2024

karlem commented Oct 28, 2024

cryptoAtwill left a comment

cryptoAtwill Nov 19, 2024

karlem Nov 20, 2024

cryptoAtwill Nov 19, 2024

karlem Nov 20, 2024

karlem commented Nov 20, 2024

cryptoAtwill left a comment •

edited

Loading

karlem commented Nov 27, 2024

feat: support l2 plus #1157

Are you sure you want to change the base?

feat: support l2 plus #1157

Conversation

karlem commented Sep 26, 2024 • edited Loading

raulk left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

cryptoAtwill commented Oct 24, 2024

raulk left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

karlem commented Oct 24, 2024

karlem commented Oct 28, 2024

cryptoAtwill left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

karlem commented Nov 20, 2024

cryptoAtwill left a comment • edited Loading

Choose a reason for hiding this comment

karlem commented Nov 27, 2024

karlem commented Sep 26, 2024 •

edited

Loading

cryptoAtwill left a comment •

edited

Loading