[ZK Stack] - Cannot execute Seaport 1.6 fulfillment txs due to incorrect calldatasize/offset

[stephankmin]

Team or Project

Reservoir

Module Affected

• System contracts (era-system-contracts)
• Smart contracts (era-contracts)
• zkEVM (era-zk_evm)
• Server (zksync-era)
• Prover (era-boojum)
• Fee withdrawer (era-fee-withdrawer)
• Block Explorer (clock-explorer)
• Portal - Wallet + Bridge (dapp-portal)
• Other (please specify below)

Rust Version

1.82.0

Operating System

• Ubuntu
• MacOS
• Windows
• Other (Please specify below)

Issue Description

Hello,

We are trying to port Seaport 1.6 to zkEVM chains.

We've compiled and deployed the contracts to Abstract testnet and zkSync successfully. However, our txs are failing whenever we try to actually fulfill Seaport orders.

Here is the failed tx

Upon further investigation, the tx is failing when Seaport attempts an external call to the Conduit deployed at 0x21c61ff1bd7caad963e191d2c6ac8fd808916473.

We believe that incorrect callDataOffset and callDataSize are being passed into _callConduitUsingOffsets due to differences between zkEVM and EVM.

{
   "calls": [],
   "error": null,
   "from": "0xdd74064cf1294465d5ef1373e82f03bae76106f4",
   "gas": "0x415a7",
   "gasUsed": "0x91",
   "input": "0x00000000000000000000000000000000000000000000000000000000000000a02020dba91b30cc0006188af794c2fb30dd8520db7e2c088b7fc7c103c00ca494000000000000000000000000ee8810654add44297cb0508288f6c2050890fc81f3d63166f0ca56c3c1a3508fce03ff0cf3fb691e00000000000000000000000001000173c84b585f036dfe80bfefe59f60cfb3b185f58bc0069e83f98d2fa90ac5d2460186f7233c927e7db2dcc703c0e500b653ca82273b7bfad8045d85a470f3fb691e00000000000000000000000000000000000000000000000000000000000000050000000000000000000000000000000000000000000000000000000000000001",
   "output": "0x",
   "revertReason": "Unknown revert reason",
   "to": "0x21c61ff1bd7caad963e191d2c6ac8fd808916473",
   "type": "call",
   "value": "0x0"
}

The wrong calldata seems to be being passed to the Conduit, since it starts with empty bytes. We would expect the function selector to be 0x4ce34aa2.

Importantly, here is the call immediately preceding the above call, to the Keccak256 system contract at 0x0000000000000000000000000000000000008010.

{
   "calls": [],
   "error": null,
   "from": "0xdd74064cf1294465d5ef1373e82f03bae76106f4",
   "gas": "0x417de",
   "gasUsed": "0xc7",
   "input": "0x2020dba91b30cc0006188af794c2fb30dd8520db7e2c088b7fc7c103c00ca494000000000000000000000000ee8810654add44297cb0508288f6c2050890fc81f3d63166f0ca56c3c1a3508fce03ff0cf3fb691e00000000000000000000000001000173c84b585f036dfe80bfefe59f60cfb3b185f58bc0069e83f98d2fa90ac5d2460186f7233c927e7db2dcc703c0e500b653ca82273b7bfad8045d85a470",
   "output": "0xbad0eb74fa2e9e7ffc67162121c61ff1bd7caad963e191d2c6ac8fd808916473",
   "revertReason": null,
   "to": "0x0000000000000000000000000000000000008010",
   "type": "call",
   "value": "0x0"
}

The wrong calldata is a superset of the Keccak256 calldata, with 00000000000000000000000000000000000000000000000000000000000000a0 and f3fb691e00000000000000000000000000000000000000000000000000000000000000050000000000000000000000000000000000000000000000000000000000000001 appended to the beginning and end.

f3fb691e is the last 4 bytes of the msg.sender 0xf3d63166F0Ca56C3c1A3508FcE03Ff0Cf3Fb691e, so clearly the issue seems to be related to offsets.

I've attached the full calltrace for reference.

The only changes we've made so far are updating the contracts to derive correct zkSync create2 addresses.

Expected Behavior

Here is a successful call to fulfillAdvancedOrder on mainnet.

We expect the calldata for the external call to the Conduit to begin with a function selector of 0x4ce34aa2.

Current Behavior

The call to the Conduit (which handles token transfers on behalf of Seaport) is reverting, leading to an InvalidCallToConduit error

Failed tx on Abstract testnet

Repository Link (if applicable)

https://github.com/reservoirprotocol/zk-relay/blob/af573dfae761f7c3f664fd34aaba4cde3e821132/contracts/seaport-1.6/lib/Executor.sol#L447-L491

Additional Details

trace.json

Prior Research

• Yes, I searched for similar issues and did not find any matching ones.

[gleenai[bot]]

It appears that the issue you're encountering with the Seaport 1.6 implementation on zkEVM chains might be related to differences in how calldata is handled between zkEVM and Ethereum's EVM. This could be affecting the callDataOffset and callDataSize parameters, leading to incorrect data being passed to the Conduit contract.

Here are a few steps you might consider to troubleshoot and potentially resolve this issue:

1. Review Calldata Handling: Ensure that the way calldata is being calculated and passed in zkEVM matches the expectations of the Ethereum EVM. Differences in handling could lead to the issues you're seeing.

2. Contract and System Compatibility: Verify that all contracts and system components are compatible with zkEVM specifications. This includes checking for any known issues or limitations with calldata operations on zkEVM.

3. Testing and Simulation: Conduct thorough testing on lower environments or testnets to simulate the transactions and pinpoint where the discrepancies are occurring.

4. Consult Documentation and Community: Review the ZKsync documentation and community discussions for any similar issues or guidance on handling contract interactions in zkEVM. You might find insights or solutions that have worked for others in similar situations.

5. Update and Patch: If you identify specific issues with how calldata is handled or any other bugs, consider updating the contract code to handle these cases explicitly or applying patches if available.

For more detailed discussions and support from other developers, you can visit the ZKsync developers discussions on Github.

If these steps do not resolve the issue, it may be beneficial to reach out directly to the ZKsync support or development team for more targeted assistance.

Your feedback helps us serve you better. If this fully addresses your question, please give it a thumbs up. If it doesn't, please give it a thumbs down. This will inform the community and team so we can improve our support.

[uF4No]

Have you tried debugging the transaction with era-test-node? It might give you more details about the issue.

Looks like the repo you shared is private, could you share it?

[stephankmin]

Hey @uF4No thanks for getting back to me.

Yes we've tried debugging with era-test-node. Unfortunately, it's still difficult to debug the issue from the call trace:

14:39:11  INFO           Call(Mimic) 0xf3d63166f0ca56c3c1a3508fce03ff0cf3fb691e           0x    222282 (210)
14:39:11  INFO         Call(Normal) EthToken System Contract                             balanceOf(uint256)    242298 (792)
14:39:11  INFO           Call(Normal) Keccak                                               00000000    237951 (159)
14:39:11  INFO         Call(Normal) Msg Value System Contract                            0x    241389 (9530)
14:39:11  INFO           Call(Normal) EthToken System Contract                             transferFromTo(address, address, uint256)    236943 (7954)
14:39:11  INFO             Call(Normal) Keccak                                               00000000    232659 (159)
14:39:11  INFO             Call(Normal) Keccak                                               00000000    232155 (159)
14:39:11  INFO             Call(Normal) Keccak                                               00000000    231588 (159)
14:39:11  INFO             Call(Normal) Event writer                                         0x00000000    225666 (251)
14:39:11  INFO           Call(Mimic) 0xe04d5cb7115e4015b2d3fa17dc2e6f88392f873c           0x    216486 (210)
14:39:11  INFO         Call(Normal) ImmutableSimulator                                   getImmutable(address, uint256)    231147 (3287)
14:39:11  INFO           Call(Normal) Keccak                                               00000000    226989 (159)
14:39:11  INFO           Call(Normal) Keccak                                               00000000    226485 (159)
14:39:11  INFO         Call(Normal) Keccak                                               2020dba9    227430 (199)
14:39:11  INFO         Call(Normal) 0x21c61ff1bd7caad963e191d2c6ac8fd808916473           0x00000000  Revert: Unknown revert reason  225414 (145)
14:39:11  INFO   Call(Normal) System context                                       setTxOrigin(address)    4227608385 (427)
14:39:11  INFO   Call(Normal) EthToken System Contract                             transferFromTo(address, address, uint256)    4227606621 (2520)
14:39:11  INFO     Call(Normal) Keccak                                               00000000    4161549672 (159)
14:39:11  INFO     Call(Normal) Keccak                                               00000000    4161549168 (159)
14:39:11  INFO     Call(Normal) Keccak                                               00000000    4161548664 (159)
14:39:11  INFO     Call(Normal) Event writer                                         0x00000000    4161548034 (251)
14:39:11  INFO 

[popzxc]

Hey! It's hard to say what exactly goes wrong here, because the contract is pretty complex and relies heavily on the assembly.
As Antonio pointed out, the repository you linked seems to be private, so I looked at the verified code on the Abstract testnet instead.

One thought I have may be the msize-related differences. Could it be that some of the allocations are optimized away which affects the calculations for the offsets?

It might make sense to try deploying & running the contract without any optimizations to see if the problem persists. If it does, we may try to look into it, but ideally we would need a minimal reproducible example, since trying to learn a big & complex codebase may be too time-consuming to realistically help here.

[stephankmin]

hey @popzxc, that makes sense to try and deploy a non-optimized version. The msize differences definitely sound like it could be the issue.

I'll try reproducing with a non-optimized version and let you know what I find!