Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

test: multi-chain verifiable merkle tree #688

Conversation

md0x
Copy link
Contributor

@md0x md0x commented Oct 24, 2024

Changes proposed in this PR:

  • Add tests in hardhat to verify that a tree with mixed leaves (sorted by chain and mixed together) using different hashing functions is fully verifiable on the EVM.
  • Add equivalent tests for the SVM.

@@ -103,7 +179,7 @@ export const relayerRefundHashFn = (input: RelayerRefundLeaf | RelayerRefundLeaf
const abiCoder = new ethers.utils.AbiCoder();
const encodedData = abiCoder.encode(
[
"tuple(uint256 leafId, uint256 chainId, uint256 amountToReturn, address l2TokenAddress, address[] refundAddresses, uint256[] refundAmounts)",
"tuple( uint256 amountToReturn, uint256 chainId, uint256[] refundAmounts, uint256 leafId, address l2TokenAddress, address[] refundAddresses)",
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The order wasn't matching the one in EVM tests.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

ye, this is the thing I was trying to say in the call on Tuesday: we should make them match within the rust/solidity code! there is no reason from them not to match, its just extra complexity. I would suggest we update the rust to match the solidity ordering, even with differently named fields

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes, makes sense @chrismaree. I will work in the svm changes in a subsequent PR 👍

Signed-off-by: Pablo Maldonado <[email protected]>
@md0x md0x marked this pull request as ready for review October 24, 2024 14:44
@md0x md0x requested review from chrismaree and Reinis-FRP October 24, 2024 14:44
@@ -1,4 +1,5 @@
import { SignerWithAddress, seedContract, toBN, expect, Contract, ethers, BigNumber } from "../../../utils/utils";
import { buildRelayerRefundMerkleTree } from "../../svm/utils";
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

this is great, I really like this pattern that you have here being able to mix the EVM/SVM tests via the tree building logic.

amountToReturn: BigNumber.from(0),
l2TokenAddress: evmTokenAddress ?? randomAddress(),
refundAddresses: evmRelayers || [randomAddress(), randomAddress()],
refundAmounts: evmRefundAmounts || [BigNumber.from(randomBigInt()), BigNumber.from(randomBigInt())],
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

it's generally a code smell to have random numbers within unit tests but I think for this it's ok.

@@ -9,26 +15,19 @@ import {
TransactionMessage,
VersionedTransaction,
} from "@solana/web3.js";
import { MerkleTree } from "@uma/common/dist/MerkleTree";
Copy link
Contributor

@Reinis-FRP Reinis-FRP Oct 25, 2024

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

nit: better import from utils/MerkleTree.ts. Though under the hood its the same uma common package import, it might be better to import it consistently from one path

Signed-off-by: Pablo Maldonado <[email protected]>
@md0x md0x merged commit de9794d into master Oct 25, 2024
9 checks passed
@md0x md0x deleted the pablo/acx-3015-instructionsbundlers-add-multichain-test-to-check-if-its branch October 25, 2024 09:42
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants