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

cryptoAtwill · 2024-10-24T07:00:14Z

contracts/contracts/gateway/router/XnetMessagingFacet.sol

@@ -27,6 +27,7 @@ contract XnetMessagingFacet is GatewayActorModifiers {
    /// @dev It requires the caller to be the system actor.
    /// @param crossMsgs The array of cross-network messages to be applied.
    function applyCrossMessages(IpcEnvelope[] calldata crossMsgs) external systemActorOnly {
-        LibGateway.applyMessages(s.networkName.getParentSubnet(), crossMsgs);
+        LibGateway.applyTopDownMessages(s.networkName.getParentSubnet(), crossMsgs);


applyCrossMessages only handles topdown messages?

Yes, it is only used to apply top-down messages locally after they have been finalized in Fendermint.

cryptoAtwill · 2024-10-24T07:01:55Z

contracts/contracts/lib/CrossMsgHelper.sol

@@ -199,4 +203,8 @@ library CrossMsgHelper {

        return true;
    }
+
+    function validateCrossMessage(IpcEnvelope memory crossMsg) internal view returns (CrossMessageValidationOutcome)  {


caller why not just invoke LibGateway directly instead, it's internal anyways.

Raul has suggested a nice syntax sugar update. So I have added it after his comment.

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?

cryptoAtwill · 2024-10-24T07:07:39Z

contracts/contracts/lib/LibGateway.sol

-            revert NotRegisteredSubnet();
-        }
-
+    function commitTopDownMsg(Subnet storage subnet, IpcEnvelope memory crossMessage) internal {


feels like we just need the subnet id as the param

Agree. This also feels unsafe since this function could accidentally modify the subnet state, since it's passed with the storage modifier.

Yeah, I can pass the subnetID down, but then I would need to look up the subnet again with getSubnet(subnetId), since this function actually updates the subnet state (and has been).

cryptoAtwill · 2024-10-24T07:10:11Z

contracts/contracts/lib/CrossMsgHelper.sol

@@ -199,4 +203,8 @@ library CrossMsgHelper {

        return true;
    }
+
+    function validateCrossMessage(IpcEnvelope memory crossMsg) internal view returns (CrossMessageValidationOutcome)  {
+        return LibGateway.validateCrossMessage(crossMsg);


I still kind of feel CrossMessageValidationOutcome should not be exposed, unless different callers might handle the outcomes differently? Now every call of validateCrossMessage must handle the outcome, dont feel it's necessary though.

unless different callers might handle the outcomes differently? - that's exactly the case :)

cryptoAtwill · 2024-10-24T07:33:09Z

contracts/test/integration/L2PlusSubnet.t.sol

+        });
+
+        address[] memory nativeSubnetPath;
+        nativeSubnet = createNativeSubnet(nativeSubnetPath, rootNetwork.gatewayAddr, rootNetwork.id);


maybe call this nativeL2Subnet?

Why do we need to pass an empty address[] as the first argument?

@raulk Solved by using the parent route instead.

cryptoAtwill · 2024-10-24T07:43:20Z

contracts/test/integration/L2PlusSubnet.t.sol

+        IpcEnvelope memory crossMessage = TestUtils.newXnetCallMsg(
+            IPCAddress({subnetId: params.subnetL3.id, rawAddress: FvmAddressHelper.from(params.callerAddr)}),
+            IPCAddress({subnetId: params.root.id, rawAddress: FvmAddressHelper.from(params.recipientAddr)}),
+            params.amount,


the param amount could exceed the fundSubnet amount?

Good catch!

cryptoAtwill · 2024-10-24T07:46:48Z

contracts/test/integration/L2PlusSubnet.t.sol

+        // submit checkoint so the result message can be propagated to L2
+        submitBottomUpCheckpoint(
+            callCreateBottomUpCheckpointFromChildSubnet(params.subnetL3.id, params.subnetL3.gateway),
+            params.subnetL3.subnetActor


this should be subnetL2.subnetActor? The checkpoint should be propagated to L2 right? Not to L3 subnet actor.

params.subnetL3.subnetActor corresponds to the L2 subnet actor. I agree it can be confusing, but I'm building around the already existing TestSubnetDefinition.

I guess if you find it super confusing I can rename it. But it might affect a lot of files :)

cryptoAtwill · 2024-10-24T07:50:11Z

contracts/test/integration/L2PlusSubnet.t.sol

+        // this would normally submitted by releayer. It call the subnet actor on the L2 network.
+        submitBottomUpCheckpoint(
+            callCreateBottomUpCheckpointFromChildSubnet(params.subnetL3.id, params.subnetL3.gateway),
+            params.subnetL3.subnetActor


the params.subnetL3.subnetActor refers to the SubnetActorDiamond in L2?

cryptoAtwill · 2024-10-24T07:54:02Z

contracts/test/integration/L2PlusSubnet.t.sol

+    }
+
+    function createNativeSubnet(
+        address[] memory subnetPath,


shouldnt this be parent subnet id? How do you know the subnet path before it's created?

I think this is supposed to be the parent subnet path, but it seems redundant since we can just get it from parentId.path?

Yes, good catch. The parent id route can be used.

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

raulk · 2024-10-24T15:21:33Z

contracts/contracts/lib/LibGateway.sol

-            revert NotRegisteredSubnet();
-        }
-
+    function commitTopDownMsg(Subnet storage subnet, IpcEnvelope memory crossMessage) internal {


Agree. This also feels unsafe since this function could accidentally modify the subnet state, since it's passed with the storage modifier.

contracts/contracts/lib/LibGateway.sol

raulk · 2024-10-24T15:25:29Z

contracts/contracts/lib/LibGateway.sol

@@ -404,11 +444,20 @@ library LibGateway {
        // should increase the appliedNonce to allow the execution of the next message
        // of the batch (this is way we have this after the nonce logic).
        if (!crossMsg.to.subnetId.equals(s.networkName)) {
+            CrossMessageValidationOutcome outcome = validateCrossMessage(crossMsg);


@cryptoAtwill unfortunately Solidity's try/catch is profoundly crippled because it only works for cross-contract calls.

contracts/test/helpers/TestUtils.sol

raulk · 2024-10-24T16:20:47Z

contracts/test/helpers/TestUtils.sol

@@ -226,3 +226,31 @@ contract MockIpcContractPayable is IIpcHandler {

    receive() external payable {}
 }
+
+contract MockContractFailbackable {
+    // receive() external payable {}


Do you want to test this with receive as well?

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.

raulk · 2024-10-24T16:29:13Z

contracts/test/integration/L2PlusSubnet.t.sol

+        });
+
+        address[] memory nativeSubnetPath;
+        nativeSubnet = createNativeSubnet(nativeSubnetPath, rootNetwork.gatewayAddr, rootNetwork.id);


Why do we need to pass an empty address[] as the first argument?

raulk · 2024-10-24T16:30:33Z

contracts/test/integration/L2PlusSubnet.t.sol

+    }
+
+    function createNativeSubnet(
+        address[] memory subnetPath,


I think this is supposed to be the parent subnet path, but it seems redundant since we can just get it from parentId.path?

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.

cryptoAtwill reviewed Sep 27, 2024

View reviewed changes

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

karlem added 11 commits October 11, 2024 17:21

feat: add simple tests

b879ac3

feat: happy path with propagateAll

f303b92

feat: add more tests

f07c994

feat: check for proper path propagation

1cf9e7b

feat: added result paths to test

b0b80a8

feat: add extra test and emits

e7b074e

feat: add missing actor tests + refactor

1ee981b

feat: move validation

7265d02

feat: commit cross messages does not revert & fix tests

bffd270

feat: remove logs

809c09a

feat: fix tests

463ee74

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

karlem added 4 commits October 11, 2024 18:31

feat: fmt

444e209

feat: send across mixed token supplies

45bc2ac

feat: propagate top down automatically

2d61689

feat: fmt & lint

a46c496

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

karlem added 2 commits October 11, 2024 23:09

feat: add extra check

dd1fa55

feat: fix test & lint

349613b

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

feat: fix comments

c46d774

cryptoAtwill requested changes Oct 24, 2024

View reviewed changes

raulk reviewed Oct 24, 2024

View reviewed changes

karlem added 2 commits October 24, 2024 22:45

feat: fix comments

5897aa9

feat: change error message

51d3ab5

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

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

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

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

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

Choose a reason for hiding this comment

karlem Oct 24, 2024 • edited Loading

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

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 Oct 24, 2024

karlem commented Sep 26, 2024 •

edited

Loading

karlem Oct 24, 2024 •

edited

Loading