Proof Of Concept for Merkle Tree validation #592
Conversation
WalkthroughThis pull request introduces the Changes
Possibly related PRs
Suggested reviewers
Warning There were issues while running some tools. Please review the errors and either fix the tool’s configuration or disable the tool if it’s a critical failure. 🔧 golangci-lint (1.62.2)Error: can't load config: the Go language version (go1.23) used to build golangci-lint is lower than the targeted Go version (1.24) ✨ Finishing Touches
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. 🪧 TipsChatThere are 3 ways to chat with CodeRabbit:
Note: Be mindful of the bot's finite context window. It's strongly recommended to break down tasks such as reading entire modules into smaller chunks. For a focused discussion, use review comments to chat about specific files and their changes, instead of using the PR comments. CodeRabbit Commands (Invoked using PR comments)
Other keywords and placeholders
CodeRabbit Configuration File (
|
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 2
🧹 Nitpick comments (4)
contracts/dev/lib/common (1)
106-106: Update help message to include the new 'merkle' option.The error message for invalid options should be updated to include 'merkle' in the list of valid options.
- echo "Invalid option. Use 'group_messages', 'identity_updates', 'nodes', or 'nodes_v2'." + echo "Invalid option. Use 'group_messages', 'identity_updates', 'nodes', 'nodes_v2', 'rates_manager', or 'merkle'."pkg/payerreports/merkle/merkle_test.go (1)
79-95: Good end-to-end proof verification test.The test correctly validates that a multi-proof can be verified against the contract.
Consider adding a negative test case where verification should fail, such as with a modified root or tampered proof.
pkg/payerreports/merkle/merkle.go (2)
68-68: Remove or replace debug printing.
Thefmt.Println("valueIndices", valueIndices)could clutter logs in production. Consider removing it or switching to a structured logger if you need visibility.- fmt.Println("valueIndices", valueIndices) + // log.Debug("valueIndices", "valueIndices", valueIndices)
82-89: Potential performance improvement.
findTreeIndexuses a linear scan through all leaves. For large input sizes, consider indexingleavesbyValueIndexin a map to reduce lookups from O(n) to O(1).
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro
⛔ Files ignored due to path filters (1)
go.sumis excluded by!**/*.sum
📒 Files selected for processing (11)
contracts/dev/deploy-local(1 hunks)contracts/dev/generate(1 hunks)contracts/dev/lib/common(2 hunks)contracts/pkg/standardmerkletree/StandardMerkleTree.go(1 hunks)contracts/src/StandardMerkleTree.sol(1 hunks)go.mod(1 hunks)pkg/blockchain/merkle.go(1 hunks)pkg/config/options.go(1 hunks)pkg/payerreports/merkle/merkle.go(1 hunks)pkg/payerreports/merkle/merkle_test.go(1 hunks)pkg/testutils/config.go(3 hunks)
⏰ Context from checks skipped due to timeout of 90000ms (4)
- GitHub Check: abis
- GitHub Check: Build pre-baked anvil-xmtpd
- GitHub Check: Lint-Go
- GitHub Check: Test (Node)
🔇 Additional comments (26)
go.mod (1)
24-24:❓ Verification inconclusive
Verify the dependency usage and maintenance status.
The addition of
github.com/FantasyJony/openzeppelin-merkle-tree-goappears to be a third-party wrapper around OpenZeppelin's Merkle tree implementation.
🏁 Script executed:
#!/bin/bash # Check if and how the dependency is used in the codebase rg -A 2 -B 2 "FantasyJony/openzeppelin-merkle-tree-go" --type go # Check the dependency's GitHub repo for stars, issues, and last commit gh repo view FantasyJony/openzeppelin-merkle-tree-go --json stargazerCount,createdAt,updatedAt,isArchived,openIssuesCount,forkCountLength of output: 1646
Action Required: Verify Dependency Maintenance
- The dependency usage is confirmed in
pkg/payerreports/merkle/merkle.govia the import of"github.com/FantasyJony/openzeppelin-merkle-tree-go/standard_merkle_tree".- The GitHub API query for maintenance details encountered an error due to the unsupported field (
openIssuesCount). Please re-run the query omitting this field (e.g., usingstargazerCount,createdAt,updatedAt,isArchived,forkCount) to validate the repository’s maintenance status.- Manually verify that the repository is active (check for recent commits, non-archived status, etc.) to ensure it remains a safe dependency to rely on.
contracts/dev/deploy-local (1)
35-35: Deployment command for StandardMerkleTree is properly structured.The forge deployment command follows the consistent pattern used for other contracts in this file.
pkg/config/options.go (1)
17-17: Config option for Merkle contract address follows proper conventions.The new field follows the same naming convention and tagging pattern as other contract address fields, maintaining consistency in the configuration structure.
contracts/dev/generate (1)
54-54: StandardMerkleTree added to default contract list for binding generation.The addition of "StandardMerkleTree" to the default contract list ensures Go bindings will be generated for it, which is necessary for interacting with the contract from Go code.
This change aligns with the PR objective of implementing Merkle Tree validation support.
pkg/testutils/config.go (4)
60-60: Good improvement to error reporting.Including the actual file name in the error message provides better context for debugging.
66-66: Good improvement to error reporting.Including the actual file name in the error message provides better context for debugging.
92-93: Note inconsistency in JSON structure of StandardMerkleTree.The StandardMerkleTree contract uses a different JSON structure (direct "deployedTo" field) compared to other contracts which use nested address structures.
Consider whether this inconsistency is intentional or if the JSON structure should be standardized across all contracts.
120-123: Contract address integration looks good.Properly adds the Merkle contract address to the contracts options using the existing pattern.
contracts/dev/lib/common (3)
28-43: Chain name mapping looks good.Clean implementation of chain ID to name mapping with appropriate default case.
99-104: Good implementation of StandardMerkleTree deployment.The deployment follows the same pattern as the nodes case.
8-26:❓ Verification inconclusive
Good implementation of contract verification function.
The function correctly handles contract verification with proper error checking.
Note that the implementation key construction assumes a specific naming convention where the first letter is lowercase. Ensure this convention is consistently followed across all contracts.
🏁 Script executed:
#!/bin/bash # Check if the impl_key naming convention is consistently followed in other contract JSON files # Look for implementation keys in JSON files cd config find . -type f -name "*.json" | xargs grep -l "Impl" | xargs cat | grep -o '"[a-zA-Z]*Impl"'Length of output: 213
Action Required: Manual Verification of Naming Convention in Contract JSON Files
The implementation of the contract verification function looks solid with proper error handling. However, our automated check was unable to locate a "config" directory, so we couldn’t verify that the naming convention for implementation keys is consistently applied in the JSON files. Please manually confirm that all contract JSON files (or their equivalent configuration files) follow the required key pattern (i.e., the first letter in lowercase followed by the rest of the name and the "Impl" suffix).
- Verify that the directory containing the JSON configuration files is correctly referenced in the code.
- Manually inspect the JSON files to ensure that keys generated (e.g., "myContractImpl" for contract "MyContract") match the expected pattern.
pkg/payerreports/merkle/merkle_test.go (4)
14-28: Good test setup for the verifier.The function properly sets up the test environment with appropriate cleanup.
42-50: Good test for tree building.The test properly verifies that a tree can be built from inputs and that it has a valid root.
52-57: Good test for empty input validation.The test correctly verifies that an error is returned when attempting to build a tree with empty inputs.
59-77: Good multi-proof generation tests.The tests effectively verify that multi-proofs can be generated for valid indices and that errors are returned for invalid indices.
pkg/blockchain/merkle.go (3)
15-19: Well-structured MerkleCaller struct.The struct contains all necessary components with clear field names.
21-38: Good implementation of the MerkleCaller constructor.The function correctly initializes the contract and handles errors appropriately.
40-54: Clean implementation of VerifyMultiProof method.The method correctly passes the context and extracts the necessary data from the MultiProof object.
contracts/src/StandardMerkleTree.sol (4)
7-9: Custom errors look good.
UsingEmptyProof()andInvalidIndex()as custom errors is a concise way to convey what is going wrong in the function. No issues here.
11-29: Consider handling potentially duplicate or out-of-order indices.
The code checks whether eachindexis within[offset, offset + accounts.length]. However, if your use case requires preventing duplicate indices or enforcing strictly ascending index order, you might want to add those checks, or document that duplicate indices are acceptable.
31-33: Empty leaves check is correct.
Reverting with a customEmptyProoferror whenleaves.length == 0aligns with best practices. This appropriately handles calls with no data.
37-39: Leaf hashing strategy seems standard.
Double hashing theabi.encode(index, account, amount)is a common approach in Merkle-based designs. If performance is a concern, consider verifying whether the secondkeccak256()is strictly necessary, but this form is typically fine for ensuring uniform leaf hashing.pkg/payerreports/merkle/merkle.go (3)
29-40: Initialization and validation logic looks good.
Returning an error on empty inputs ensures this tree is constructed only under valid conditions. Building values withbuildValues(inputs)exemplifies a clean separation of concerns.
58-62: Confirm descending sort requirement.
Usingreturn treeIndexX > treeIndexYsorts the slice in descending order ofTreeIndex. Make sure this is intended, rather than the more common ascending sort.
91-101: Index usage clarity.
buildValuesstores the Go array index as auint256in the tree. If your tree logic requires offsets or other indexing logic, ensure these match the rest of your code. Otherwise, this approach is fine.contracts/pkg/standardmerkletree/StandardMerkleTree.go (1)
1-3: No direct concerns for generated bindings.
This file is auto-generated, so manual changes could be overwritten. Keeping it up to date with ABI changes is the only key requirement here.
| func buildInputs(numInputs int) []merkle.PayerReportInput { | ||
| inputs := make([]merkle.PayerReportInput, numInputs) | ||
| for i := range numInputs { | ||
| inputs[i] = merkle.PayerReportInput{ | ||
| PayerAddress: testutils.RandomAddress(), | ||
| Amount: big.NewInt(int64(testutils.RandomInt32())), | ||
| } | ||
| } | ||
|
|
||
| return inputs | ||
| } |
There was a problem hiding this comment.
Fix the loop syntax in the buildInputs function.
There's a syntax error in the loop. In Go, range on an integer doesn't work as expected.
Fix the loop syntax:
func buildInputs(numInputs int) []merkle.PayerReportInput {
inputs := make([]merkle.PayerReportInput, numInputs)
- for i := range numInputs {
+ for i := 0; i < numInputs; i++ {
inputs[i] = merkle.PayerReportInput{
PayerAddress: testutils.RandomAddress(),
Amount: big.NewInt(int64(testutils.RandomInt32())),
}
}
return inputs
}📝 Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.
| func buildInputs(numInputs int) []merkle.PayerReportInput { | |
| inputs := make([]merkle.PayerReportInput, numInputs) | |
| for i := range numInputs { | |
| inputs[i] = merkle.PayerReportInput{ | |
| PayerAddress: testutils.RandomAddress(), | |
| Amount: big.NewInt(int64(testutils.RandomInt32())), | |
| } | |
| } | |
| return inputs | |
| } | |
| func buildInputs(numInputs int) []merkle.PayerReportInput { | |
| inputs := make([]merkle.PayerReportInput, numInputs) | |
| for i := 0; i < numInputs; i++ { | |
| inputs[i] = merkle.PayerReportInput{ | |
| PayerAddress: testutils.RandomAddress(), | |
| Amount: big.NewInt(int64(testutils.RandomInt32())), | |
| } | |
| } | |
| return inputs | |
| } |
| func (t *PayerReportTree) GetMultiProof(offset int, count int) (*MultiProof, error) { | ||
| if offset+count > t.numInputs { | ||
| return nil, fmt.Errorf("offset + count is greater than the number of inputs") | ||
| } | ||
| leaves := t.tree.Entries() | ||
| valueIndices := make([]int, count) | ||
| for i := range count { | ||
| valueIndices[i] = offset + i | ||
| } |
There was a problem hiding this comment.
Correct the loop syntax error.
Go does not support for i := range count when count is an integer. This line will fail to compile. You likely intended a basic for-loop.
A suitable fix might be:
- for i := range count {
+ for i := 0; i < count; i++ {📝 Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.
| func (t *PayerReportTree) GetMultiProof(offset int, count int) (*MultiProof, error) { | |
| if offset+count > t.numInputs { | |
| return nil, fmt.Errorf("offset + count is greater than the number of inputs") | |
| } | |
| leaves := t.tree.Entries() | |
| valueIndices := make([]int, count) | |
| for i := range count { | |
| valueIndices[i] = offset + i | |
| } | |
| func (t *PayerReportTree) GetMultiProof(offset int, count int) (*MultiProof, error) { | |
| if offset+count > t.numInputs { | |
| return nil, fmt.Errorf("offset + count is greater than the number of inputs") | |
| } | |
| leaves := t.tree.Entries() | |
| valueIndices := make([]int, count) | |
| for i := 0; i < count; i++ { | |
| valueIndices[i] = offset + i | |
| } |
neekolas
force-pushed
the
03-05-proof_of_concept_for_merkle_tree_validation
branch
from
085fcab to
1a6c589
Compare
There was a problem hiding this comment.
Actionable comments posted: 3
♻️ Duplicate comments (1)
pkg/payerreports/merkle/merkle.go (1)
52-54:⚠️ Potential issueCorrect loop syntax error.
This code will not compile in Go. The loop statementfor i := range count {}is invalid whencountis an integer. Switch to a standard for-loop.- for i := range count { + for i := 0; i < count; i++ {
🧹 Nitpick comments (6)
pkg/blockchain/merkle.go (1)
44-53: Add error context.
If the call toMultiProofVerifyfails, consider wrapping or logging the returned error to provide more context for troubleshooting.contracts/dev/lib/common (5)
8-26: Enhance error handling for the verification process.The
forge_verify_contractfunction has good error handling for the address retrieval but doesn't validate the success of the actual verification command. This could lead to situations where verification failures are not properly reported.function forge_verify_contract() { chain_name=$(get_chain_name) contract_name=$1 impl_key="$(echo ${contract_name:0:1} | tr '[:upper:]' '[:lower:]')${contract_name:1}Impl" deployed_address="$(jq -r ".addresses.$impl_key" config/${chain_name}/${contract_name}.json)" if [ -z "$deployed_address" ]; then echo "Failed to get deployed address for $contract_name" exit 1 fi forge verify-contract \ --verifier=blockscout \ --verifier-url=${VERIFIER_URL} \ --chain-id=${chain_id} \ --compiler-version 0.8.28 \ $deployed_address \ $contract_name + if [ $? -ne 0 ]; then + echo "Failed to verify contract $contract_name" + exit 1 + fi }
8-26: Add file existence check before extracting JSON configuration.The function assumes the contract configuration file exists and is properly formatted, which might lead to cryptic errors if the file is missing or malformed.
function forge_verify_contract() { chain_name=$(get_chain_name) contract_name=$1 impl_key="$(echo ${contract_name:0:1} | tr '[:upper:]' '[:lower:]')${contract_name:1}Impl" + config_file="config/${chain_name}/${contract_name}.json" + if [ ! -f "$config_file" ]; then + echo "Configuration file not found: $config_file" + exit 1 + fi + deployed_address="$(jq -r ".addresses.$impl_key" config/${chain_name}/${contract_name}.json)" if [ -z "$deployed_address" ]; then echo "Failed to get deployed address for $contract_name" exit 1 fi
28-43: Add validation for chain_id in the get_chain_name function.The function relies on
$chain_idbeing set as a global variable but doesn't validate its existence or format. This could lead to unexpected behavior if the variable is unset or malformed.function get_chain_name() { + if [ -z "$chain_id" ]; then + echo "ERROR: chain_id is not set" >&2 + return 1 + fi + case $chain_id in 31337) echo "anvil_localnet" ;; 241320161) echo "xmtp_testnet" ;; 84532) echo "base_sepolia" ;; *) echo "unknown" ;; esac }
8-26: Verify availability of required commands.The
forge_verify_contractfunction relies on external commands likejqwithout checking if they're available. This could lead to cryptic failures if these dependencies are missing.function forge_verify_contract() { + # Check for required dependencies + if ! command -v jq &> /dev/null; then + echo "Error: jq is required but not installed. Please install jq to continue." + exit 1 + fi + chain_name=$(get_chain_name) contract_name=$1 impl_key="$(echo ${contract_name:0:1} | tr '[:upper:]' '[:lower:]')${contract_name:1}Impl" deployed_address="$(jq -r ".addresses.$impl_key" config/${chain_name}/${contract_name}.json)"
28-43: Document the purpose of each supported chain ID.The
get_chain_namefunction maps specific chain IDs to names without documenting what each network represents. Adding comments would improve maintainability.function get_chain_name() { case $chain_id in - 31337) + 31337) # Anvil local development network echo "anvil_localnet" ;; - 241320161) + 241320161) # XMTP testnet echo "xmtp_testnet" ;; - 84532) + 84532) # Base Sepolia testnet echo "base_sepolia" ;; *) echo "unknown" ;; esac }
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro
⛔ Files ignored due to path filters (1)
go.sumis excluded by!**/*.sum
📒 Files selected for processing (11)
contracts/dev/deploy-local(1 hunks)contracts/dev/generate(1 hunks)contracts/dev/lib/common(2 hunks)contracts/pkg/standardmerkletree/StandardMerkleTree.go(1 hunks)contracts/src/StandardMerkleTree.sol(1 hunks)go.mod(1 hunks)pkg/blockchain/merkle.go(1 hunks)pkg/config/options.go(1 hunks)pkg/payerreports/merkle/merkle.go(1 hunks)pkg/payerreports/merkle/merkle_test.go(1 hunks)pkg/testutils/config.go(3 hunks)
🚧 Files skipped from review as they are similar to previous changes (7)
- go.mod
- contracts/dev/deploy-local
- pkg/config/options.go
- contracts/dev/generate
- pkg/payerreports/merkle/merkle_test.go
- contracts/src/StandardMerkleTree.sol
- pkg/testutils/config.go
⏰ Context from checks skipped due to timeout of 90000ms (3)
- GitHub Check: abis
- GitHub Check: Test (Node)
- GitHub Check: Build pre-baked anvil-xmtpd
🔇 Additional comments (5)
pkg/blockchain/merkle.go (2)
21-38: Validate contract address.
Consider adding an explicit check or validation step forcontractsOptions.MerkleContractAddressbefore binding the contract, to handle scenarios where it might be empty or invalid.
40-43: Check for nil proof structure.
Ensure thatproofis notniland appropriately handle or log an error if critical fields are missing or undefined.pkg/payerreports/merkle/merkle.go (2)
58-62: Verify sorting order.
Currently, the comparison function sorts in descending order (treeIndexX > treeIndexY). Confirm that this reversed ordering is intentional, as it might lead to unexpected multi-proof generation.
78-79: Ensure root size is 32 bytes.
The cast[32]byte(t.Root())assumes the returned slice is 32 bytes long. Confirm that the root truly has a length of 32 bytes to avoid potential panics or data truncation.contracts/pkg/standardmerkletree/StandardMerkleTree.go (1)
1-235: Auto-generated code acknowledged.
This file is automatically generated. Typically, manual changes are discouraged and might be overwritten. No further concerns.
| merkle) | ||
| echo "⧖ Deploying StandardMerkleTree to chainId ${chain_id} using RPC ${RPC_URL}" | ||
| forge create --broadcast --legacy --json --rpc-url $RPC_URL --private-key $PRIVATE_KEY "$2:$3" > config/anvil_localnet/$3.json | ||
| echo -e "\033[32m✔\033[0m StandardMerkleTree deployed. Deployment details in contracts/config/anvil_localnet/$3.json\n" | ||
|
|
||
| ;; |
There was a problem hiding this comment.
🛠️ Refactor suggestion
Add error handling for the merkle deployment case.
Unlike other deployment cases using forge script, the merkle case uses forge create without checking for potential failures.
merkle)
echo "⧖ Deploying StandardMerkleTree to chainId ${chain_id} using RPC ${RPC_URL}"
- forge create --broadcast --legacy --json --rpc-url $RPC_URL --private-key $PRIVATE_KEY "$2:$3" > config/anvil_localnet/$3.json
+ forge create --broadcast --legacy --json --rpc-url $RPC_URL --private-key $PRIVATE_KEY "$2:$3" > config/anvil_localnet/$3.json || BUILD_FAILED=true
+ if [[ -n "${BUILD_FAILED:-}" ]]; then
+ echo "Failed to deploy StandardMerkleTree contract"
+ exit 1
+ fi
echo -e "\033[32m✔\033[0m StandardMerkleTree deployed. Deployment details in contracts/config/anvil_localnet/$3.json\n"
;;📝 Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.
| merkle) | |
| echo "⧖ Deploying StandardMerkleTree to chainId ${chain_id} using RPC ${RPC_URL}" | |
| forge create --broadcast --legacy --json --rpc-url $RPC_URL --private-key $PRIVATE_KEY "$2:$3" > config/anvil_localnet/$3.json | |
| echo -e "\033[32m✔\033[0m StandardMerkleTree deployed. Deployment details in contracts/config/anvil_localnet/$3.json\n" | |
| ;; | |
| merkle) | |
| echo "⧖ Deploying StandardMerkleTree to chainId ${chain_id} using RPC ${RPC_URL}" | |
| forge create --broadcast --legacy --json --rpc-url $RPC_URL --private-key $PRIVATE_KEY "$2:$3" > config/anvil_localnet/$3.json || BUILD_FAILED=true | |
| if [[ -n "${BUILD_FAILED:-}" ]]; then | |
| echo "Failed to deploy StandardMerkleTree contract" | |
| exit 1 | |
| fi | |
| echo -e "\033[32m✔\033[0m StandardMerkleTree deployed. Deployment details in contracts/config/anvil_localnet/$3.json\n" | |
| ;; |
| forge create --broadcast --legacy --json --rpc-url $RPC_URL --private-key $PRIVATE_KEY "$2:$3" > config/anvil_localnet/$3.json | ||
| echo -e "\033[32m✔\033[0m StandardMerkleTree deployed. Deployment details in contracts/config/anvil_localnet/$3.json\n" | ||
|
|
||
| ;; | ||
| *) | ||
| echo "Invalid option. Use 'group_messages', 'identity_updates', 'nodes', or 'nodes_v2'." |
There was a problem hiding this comment.
🛠️ Refactor suggestion
Update the help message to include the new 'merkle' option.
The error message for invalid options doesn't include the new 'merkle' option, which could confuse users.
- echo "Invalid option. Use 'group_messages', 'identity_updates', 'nodes', or 'nodes_v2'."
+ echo "Invalid option. Use 'group_messages', 'identity_updates', 'nodes', 'nodes_v2', 'rates_manager', or 'merkle'."📝 Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.
| echo "Invalid option. Use 'group_messages', 'identity_updates', 'nodes', or 'nodes_v2'." | |
| echo "Invalid option. Use 'group_messages', 'identity_updates', 'nodes', 'nodes_v2', 'rates_manager', or 'merkle'." |
|
|
||
| merkle) | ||
| echo "⧖ Deploying StandardMerkleTree to chainId ${chain_id} using RPC ${RPC_URL}" | ||
| forge create --broadcast --legacy --json --rpc-url $RPC_URL --private-key $PRIVATE_KEY "$2:$3" > config/anvil_localnet/$3.json | ||
| echo -e "\033[32m✔\033[0m StandardMerkleTree deployed. Deployment details in contracts/config/anvil_localnet/$3.json\n" | ||
|
|
||
| ;; |
There was a problem hiding this comment.
🛠️ Refactor suggestion
Consider using dynamic config path for merkle deployment.
The merkle deployment case hardcodes the config path to anvil_localnet instead of using the chain name derived from the chain ID, which could cause issues when deploying to other networks.
merkle)
echo "⧖ Deploying StandardMerkleTree to chainId ${chain_id} using RPC ${RPC_URL}"
- forge create --broadcast --legacy --json --rpc-url $RPC_URL --private-key $PRIVATE_KEY "$2:$3" > config/anvil_localnet/$3.json
+ chain_name=$(get_chain_name)
+ mkdir -p config/$chain_name
+ forge create --broadcast --legacy --json --rpc-url $RPC_URL --private-key $PRIVATE_KEY "$2:$3" > config/$chain_name/$3.json
echo -e "\033[32m✔\033[0m StandardMerkleTree deployed. Deployment details in contracts/config/anvil_localnet/$3.json\n"
;;📝 Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.
| merkle) | |
| echo "⧖ Deploying StandardMerkleTree to chainId ${chain_id} using RPC ${RPC_URL}" | |
| forge create --broadcast --legacy --json --rpc-url $RPC_URL --private-key $PRIVATE_KEY "$2:$3" > config/anvil_localnet/$3.json | |
| echo -e "\033[32m✔\033[0m StandardMerkleTree deployed. Deployment details in contracts/config/anvil_localnet/$3.json\n" | |
| ;; | |
| merkle) | |
| echo "⧖ Deploying StandardMerkleTree to chainId ${chain_id} using RPC ${RPC_URL}" | |
| chain_name=$(get_chain_name) | |
| mkdir -p config/$chain_name | |
| forge create --broadcast --legacy --json --rpc-url $RPC_URL --private-key $PRIVATE_KEY "$2:$3" > config/$chain_name/$3.json | |
| echo -e "\033[32m✔\033[0m StandardMerkleTree deployed. Deployment details in contracts/config/anvil_localnet/$3.json\n" | |
| ;; |
Summary
I wanted to put together a proof of concept for the Merkleized Payer Reports.
This uses OpenZeppelin's MerkleProof library to verify the proofs onchain, and a community-created Go library to generate them offchain.
The community library is pretty sparsely maintained, so I'm not sure it's the right long-term fit. Of course we could fork it and commit improvements back upstream.
Key challenges
1,2, and3, might be scattered all over the tree, requiring a lot more intermediate hashes to build a proof than if they were siblingsMultiProofsSummary by CodeRabbit
New Features
Chores
Tests