feat(node-api): Get proof for execution fee recipient #1831
Conversation
WalkthroughThe recent updates enhance blockchain proof handling by introducing a new endpoint for retrieving execution fee recipients and refining existing mechanisms for fetching execution numbers. Key changes include updated request and response types, improved routing paths for clarity, streamlined mock interfaces, and enhanced functionalities for managing execution payloads. These enhancements aim to streamline interactions and improve usability for users engaging with blockchain data. Changes
Sequence Diagram(s)sequenceDiagram
participant Client
participant API
participant Handler
participant DB
Client->>API: GET /bkit/v1/proof/execution_fee_recipient/{block_id}
API->>Handler: GetExecutionFeeRecipient(c)
Handler->>DB: Fetch execution payload for block_id
DB-->>Handler: Return execution payload
Handler-->>API: Return ExecutionFeeRecipientResponse
API-->>Client: Send response with fee recipient details
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 as PR comments)
Additionally, you can add 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: 1
Review details
Configuration used: CodeRabbit UI
Review profile: ASSERTIVE
Files selected for processing (6)
- mod/node-api/handlers/proof/execution_fee_recipient.go (1 hunks)
- mod/node-api/handlers/proof/execution_number.go (3 hunks)
- mod/node-api/handlers/proof/routes.go (1 hunks)
- mod/node-api/handlers/proof/types/request.go (1 hunks)
- mod/node-api/handlers/proof/types/response.go (3 hunks)
- mod/node-api/handlers/proof/types/types.go (2 hunks)
Additional comments not posted (17)
mod/node-api/handlers/proof/types/request.go (3)
26-26: LGTM!The comment update for the
BlockProposerRequeststructure to reflect the new endpoint format/proof/block_proposer/{block_id}is clear and consistent.
31-35: LGTM!The renaming of
BlockExecutionRequesttoExecutionNumberRequestand the comment update to reflect the new endpoint/proof/execution_number/{block_id}enhance clarity and specificity.
37-39: LGTM!The introduction of the
ExecutionFeeRecipientRequeststructure with the endpoint/proof/execution_fee_recipient/{block_id}expands the API's capabilities effectively.mod/node-api/handlers/proof/routes.go (3)
37-37: LGTM!The path update for fetching the block proposer to
eth/v1/proof/block_proposer/:block_idenhances readability and aligns with common naming conventions.
42-44: LGTM!The path update for fetching block execution details to
eth/v1/proof/execution_number/:block_idprovides a clearer indication of the type of information being retrieved.
46-48: LGTM!The introduction of the route
eth/v1/proof/execution_fee_recipient/:block_idexpands the API's capabilities effectively.mod/node-api/handlers/proof/execution_number.go (1)
Line range hint
29-62:
LGTM!The renaming of
GetBlockExecutiontoGetExecutionNumberand the updates to internal elements improve clarity and specificity. The function handles errors appropriately and logs relevant information.mod/node-api/handlers/proof/execution_fee_recipient.go (3)
1-21: LGTM!The license information and package declaration are correct.
23-27: LGTM!The import statements are necessary for the functionality of the
GetExecutionFeeRecipientfunction.
29-67: LGTM!The function
GetExecutionFeeRecipientis well-structured and handles errors appropriately.mod/node-api/handlers/proof/types/types.go (3)
Line range hint
1-22:
LGTM!The license information and package declaration are correct.
24-27: LGTM!The import statements are necessary for the functionality of the interfaces defined in the file.
67-70: LGTM!The enhancement to the
ExecutionPayloadHeaderinterface is necessary for retrieving the fee recipient address from the execution payload header.mod/node-api/handlers/proof/types/response.go (4)
Line range hint
1-22:
LGTM!The license information and package declaration are correct.
24-25: LGTM!The import statements are necessary for the functionality of the response types defined in the file.
51-53: LGTM!The renaming of the response type from
BlockExecutionResponsetoExecutionNumberResponseenhances the semantic clarity.
69-85: LGTM!The new response type
ExecutionFeeRecipientResponseis necessary for providing detailed information regarding execution fee recipients associated with specific blockchain blocks.
There was a problem hiding this comment.
Actionable comments posted: 1
Review details
Configuration used: CodeRabbit UI
Review profile: ASSERTIVE
Files selected for processing (11)
- contracts/src/eip4788/interfaces/IBeaconVerifier.sol (1 hunks)
- mod/node-api/backend/types.go (1 hunks)
- mod/node-api/handlers/proof/execution_fee_recipient.go (1 hunks)
- mod/node-api/handlers/proof/execution_number.go (3 hunks)
- mod/node-api/handlers/proof/merkle/beacon_state.go (1 hunks)
- mod/node-api/handlers/proof/merkle/block_proposer.go (1 hunks)
- mod/node-api/handlers/proof/merkle/constants.go (1 hunks)
- mod/node-api/handlers/proof/merkle/execution_fee_recipient.go (1 hunks)
- mod/node-api/handlers/proof/merkle/execution_number.go (4 hunks)
- mod/node-api/handlers/proof/routes.go (1 hunks)
- mod/node-api/handlers/proof/types/types.go (4 hunks)
Additional comments not posted (28)
mod/node-api/handlers/proof/routes.go (3)
37-39: LGTM!The route
bkit/v1/proof/block_proposer/:block_idaligns with the new naming convention and improves clarity.
42-44: LGTM!The route
bkit/v1/proof/execution_number/:block_idaligns with the new naming convention and improves clarity. The handlerh.GetExecutionNumberis appropriately updated.
46-48: LGTM!The new route
bkit/v1/proof/execution_fee_recipient/:block_idexpands the API functionality by allowing retrieval of the execution fee recipient. The handlerh.GetExecutionFeeRecipientis appropriately introduced.mod/node-api/handlers/proof/merkle/beacon_state.go (1)
28-32: LGTM!The function name
ProveBeaconStateInBlockimproves clarity by explicitly indicating its purpose related to the beacon state. The updated signature enhances readability and maintains the underlying logic.contracts/src/eip4788/interfaces/IBeaconVerifier.sol (1)
3-3: LGTM!The removal of the
SSZmodule import suggests a shift in dependencies, likely indicating that the functionality provided bySSZis no longer required within the context of this interface. The overall structure of the interface remains intact.mod/node-api/handlers/proof/execution_number.go (5)
29-31: Update function comments to reflect new functionality.The comments accurately describe the updated functionality of the function.
34-34: Function signature update is appropriate.The function signature has been updated to
GetExecutionNumber, which aligns with the new focus on execution numbers.
35-35: Update request validation type.The request validation now uses
types.ExecutionNumberRequest, which is appropriate for the updated functionality.
48-48: Update logging statement.The logging statement has been updated to "Generating execution block number proof," which aligns with the new functionality.
Line range hint
62-67:
Update response type.The response type has been updated to
types.ExecutionNumberResponse, which is appropriate for the updated functionality.mod/node-api/handlers/proof/execution_fee_recipient.go (5)
29-31: Function comments are clear and descriptive.The comments accurately describe the functionality of the function.
34-34: Function signature is appropriate.The function signature is clear and follows the pattern used in the codebase.
35-37: Request validation is appropriate.The request validation uses
types.ExecutionFeeRecipientRequest, which matches the functionality of the function.
48-48: Logging statement is clear and informative.The logging statement "Generating execution fee recipient proof" accurately describes the action being taken.
62-67: Response type is appropriate.The response type
types.ExecutionFeeRecipientResponsematches the functionality of the function.mod/node-api/handlers/proof/types/types.go (2)
24-27: New imports are appropriate.The new imports
fastsszandgethprimitivesare necessary for the updated functionality.
66-68: New methodGetFeeRecipient()is appropriate.The new method
GetFeeRecipient()in theExecutionPayloadHeaderinterface is necessary for retrieving the fee recipient address.mod/node-api/handlers/proof/merkle/constants.go (4)
47-49: LGTM! Improved clarity by renaming the constant.The renaming from
ExecutionPayloadNumberGIndexDenebStatetoExecutionNumberGIndexDenebStateenhances clarity by specifying that the constant pertains to the execution number.
51-54: LGTM! Improved clarity by renaming the constant.The renaming from
ExecutionPayloadNumberGIndexDenebBlocktoExecutionNumberGIndexDenebBlockenhances clarity by specifying that the constant pertains to the execution number.
56-59: LGTM! New constant is well-defined.The new constant
ExecutionFeeRecipientGIndexDenebStateis well-defined and follows the existing naming conventions.
61-64: LGTM! New constant is well-defined.The new constant
ExecutionFeeRecipientGIndexDenebBlockis well-defined and follows the existing naming conventions.mod/node-api/handlers/proof/merkle/execution_number.go (3)
53-53: LGTM! Improved specificity in function call.The function call has been updated from
ProveStateInBlocktoProveBeaconStateInBlock, enhancing the specificity and aligning with the function's intent.
91-91: LGTM! Improved clarity with renamed constant.The constant reference has been updated from
ExecutionPayloadNumberGIndexDenebStatetoExecutionNumberGIndexDenebState, enhancing clarity.
115-115: LGTM! Improved clarity with renamed constant.The constant reference has been updated from
ExecutionPayloadNumberGIndexDenebBlocktoExecutionNumberGIndexDenebBlock, enhancing clarity.mod/node-api/handlers/proof/merkle/block_proposer.go (1)
56-56: LGTM! Improved specificity in function call.The function call has been updated from
ProveStateInBlocktoProveBeaconStateInBlock, enhancing the specificity and aligning with the function's intent.mod/node-api/handlers/proof/merkle/execution_fee_recipient.go (2)
75-105: LGTM!The code changes are approved.
35-69: LGTM! But verify thenolintdirective.The code changes are approved.
However, ensure that the
nolintdirective is necessary and does not suppress any critical linting issues.mod/node-api/backend/types.go (1)
Line range hint
48-59:
Verify the impact of removingconstraints.SSZRootable.The removal of the
constraints.SSZRootableinterface might impact components relying on its functionality.
There was a problem hiding this comment.
Actionable comments posted: 6
Outside diff range comments (2)
contracts/src/eip4788/BeaconVerifier.sol (2)
Line range hint
186-210: LGTM! Consider adding inline comments.The function
proveExecutionNumberInBeaconBlockcorrectly verifies the block number in the latest execution payload header in the beacon state in the beacon block. Adding inline comments would improve readability.
Line range hint
153-185: LGTM! Consider adding inline comments.The function
proveValidatorPubkeyInBeaconBlockcorrectly verifies the validator pubkey in the registry of beacon state. Adding inline comments would improve readability.
Review details
Configuration used: CodeRabbit UI
Review profile: ASSERTIVE
Files selected for processing (9)
- contracts/src/eip4788/BeaconVerifier.sol (6 hunks)
- contracts/src/eip4788/SSZ.sol (3 hunks)
- contracts/src/eip4788/interfaces/IBeaconVerifier.sol (4 hunks)
- contracts/test/eip4788/SSZ.t.sol (1 hunks)
- mod/node-api/handlers/proof/merkle/constants.go (2 hunks)
- mod/node-api/handlers/proof/merkle/execution_fee_recipient.go (1 hunks)
- mod/node-api/handlers/proof/merkle/execution_number.go (5 hunks)
- mod/node-api/handlers/proof/types/response.go (3 hunks)
- mod/node-api/handlers/proof/types/types.go (4 hunks)
Additional comments not posted (24)
contracts/test/eip4788/SSZ.t.sol (2)
29-39: LGTM! Verify the correctness of expected values.The addition of the
test_addressHashTreeRootfunction is approved. Ensure that the expected values for the hash tree roots are correct.Verification successful
Let's correct the script to find and search within Solidity files.
Let's search for the expected hash values within the function
test_addressHashTreeRootto verify their correctness.
Let's modify the script to include more lines of context around the found instances to capture the exact expected values.
Verify the correctness of expected values
The expected values in the
test_addressHashTreeRootfunction appear to be correct based on the provided addresses:
The first expected value correctly concatenates
hex"1234567890ABCDEF"with 24 zero bytes.The second expected value is a valid 32-byte hex string.
Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash # Description: Verify the correctness of expected values in the new test function. # Test: Search for the expected values in the new test function. Expect: Correct values. rg --type solidity -A 5 $'test_addressHashTreeRoot'Length of output: 83
Script:
#!/bin/bash # Description: Verify the correctness of expected values in the new test function. # Find all Solidity files and search for the test function `test_addressHashTreeRoot`. fd -e sol -x rg 'test_addressHashTreeRoot' {}Length of output: 101
Script:
#!/bin/bash # Description: Verify the correctness of expected values in the new test function. # Find all Solidity files and search for the expected hash values within the function `test_addressHashTreeRoot`. fd -e sol -x rg 'bytes32 expected =' {}Length of output: 151
Script:
#!/bin/bash # Description: Verify the correctness of expected values in the new test function. # Find all Solidity files and search for the expected hash values within the function `test_addressHashTreeRoot`, including more context lines. fd -e sol -x rg 'bytes32 expected =' -A 3 {}Length of output: 818
16-25: LGTM! Verify the correctness of expected values.The changes to the
test_uint64HashTreeRootfunction are approved. Ensure that the expected values for the hash tree roots are correct.mod/node-api/handlers/proof/types/types.go (2)
64-66: LGTM! Verify the usage of the new method.The addition of the
GetFeeRecipientmethod to theExecutionPayloadHeaderinterface is approved. Ensure that the method is used correctly throughout the codebase.Verification successful
The
GetFeeRecipientmethod is correctly integrated and utilized across the codebase.The method
GetFeeRecipientis found in multiple files, including method definitions, function calls, and test cases, indicating it is well-integrated and utilized in various contexts. Ensure that it continues to be used correctly in future updates.
mod/state-transition/pkg/core/types.gomod/payload/pkg/builder/types.gomod/node-api/handlers/proof/execution_fee_recipient.gomod/node-api/handlers/proof/types/types.gomod/payload/pkg/builder/payload.gomod/execution/pkg/engine/types.gomod/engine-primitives/pkg/engine-primitives/requests_test.gomod/engine-primitives/pkg/engine-primitives/requests.gomod/consensus-types/pkg/types/payload_header_test.gomod/consensus-types/pkg/types/payload_header.gomod/consensus-types/pkg/types/genesis_test.gomod/consensus-types/pkg/types/payload.gomod/consensus-types/pkg/types/payload_test.goScripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash # Description: Verify the usage of the new `GetFeeRecipient` method. # Test: Search for the usage of the new method. Expect: Correct usage. rg --type go -A 5 $'GetFeeRecipient'Length of output: 10265
Line range hint
24-38:
LGTM! Verify the impact of removing the constraint.The removal of the
constraints.SSZMarshallableRootableconstraint from theBeaconStateinterface is approved. Ensure that this change does not negatively impact the functionality.mod/node-api/handlers/proof/merkle/constants.go (4)
47-49: LGTM! The renaming clarifies the semantic relevance.The renaming of the constant
ExecutionPayloadNumberGIndexDenebStatetoExecutionNumberGIndexDenebStateis approved.
51-55: LGTM! The renaming clarifies the semantic relevance.The renaming of the constant
ExecutionPayloadNumberGIndexDenebBlocktoExecutionNumberGIndexDenebBlockis approved.
57-60: LGTM! The addition enhances the module's capability.The addition of the constant
ExecutionFeeRecipientGIndexDenebStateis approved.
62-66: LGTM! The addition enhances the module's capability.The addition of the constant
ExecutionFeeRecipientGIndexDenebBlockis approved.contracts/src/eip4788/interfaces/IBeaconVerifier.sol (4)
14-16: LGTM! New event declaration is consistent.The new event
ExecutionFeeRecipientGIndexChangedfollows the pattern of existing events and provides necessary information.
29-32: LGTM! New function declaration is consistent.The new function
executionFeeRecipientGIndexfollows the pattern of existing getter functions and provides necessary information.
72-83: LGTM! New function declaration is consistent.The new function
verifyCoinbasefollows the pattern of existing verification functions and provides necessary information.
34-36: LGTM! Visibility modifier improves clarity.The addition of the
externalvisibility modifier to the functiongetParentBeaconBlockRootAtimproves clarity and consistency.mod/node-api/handlers/proof/types/response.go (3)
31-32: LGTM! Updated endpoint path improves clarity.The updated endpoint path for
BlockProposerResponseimproves clarity and consistency.
50-52: LGTM! Renaming and updated endpoint path improve clarity.The renaming of
BlockExecutionResponsetoExecutionNumberResponseand the updated endpoint path improve clarity and specificity.
68-86: LGTM! New type declaration is consistent.The new type
ExecutionFeeRecipientResponsefollows the pattern of existing response types and provides necessary information.mod/node-api/handlers/proof/merkle/execution_number.go (3)
54-54: LGTM! Updated function call improves clarity.The updated call to
ProveBeaconStateInBlockin the functionProveExecutionNumberInBlockimproves clarity and consistency.
92-92: LGTM! Updated index improves clarity and correctness.The updated index
ExecutionNumberGIndexDenebStatein the functionProveExecutionNumberInStateimproves clarity and correctness.
116-116: LGTM! Updated index improves clarity and correctness.The updated index
ExecutionNumberGIndexDenebBlockin the functionverifyExecutionNumberInBlockimproves clarity and correctness.contracts/src/eip4788/SSZ.sol (5)
35-41: LGTM!The function
uint64HashTreeRootcorrectly converts auint64value to a little-endian format and returns its hash tree root.
43-49: LGTM!The function
addressHashTreeRootcorrectly converts anaddressto abytes32representation using the first 20 bytes.
Line range hint
50-68: LGTM!The function
toLittleEndiancorrectly converts auint256value to a little-endian format using bitwise operations.
Line range hint
69-130: LGTM!The function
verifyProofcorrectly verifies a Merkle proof against a given root and leaf using inline assembly for efficiency.
Line range hint
7-34: LGTM!The function
validatorPubkeyHashTreeRootcorrectly calculates the hash tree root of a validator's public key using inline assembly to call the SHA256 precompile.contracts/src/eip4788/BeaconVerifier.sol (1)
68-76: LGTM!The function
setExecutionFeeRecipientGIndexcorrectly allows the contract owner to update theexecutionFeeRecipientGIndexand uses theonlyOwnermodifier to restrict access.
There was a problem hiding this comment.
Actionable comments posted: 0
Review details
Configuration used: CodeRabbit UI
Review profile: ASSERTIVE
Files selected for processing (1)
- mod/node-api/backend/mocks/beacon_state.mock.go (1 hunks)
Additional comments not posted (6)
mod/node-api/backend/mocks/beacon_state.mock.go (6)
Line range hint
20-20:
Verify the impact of removingRunAndReturninBeaconState_HashTreeRoot_Call.The
RunAndReturnmethod inBeaconState_HashTreeRoot_Callhas been removed. Ensure that any existing tests or code that rely on this method are updated accordingly.Verification successful
No impact found from removing
RunAndReturninBeaconState_HashTreeRoot_Call.The
RunAndReturnmethod inBeaconState_HashTreeRoot_Callhas been removed, and there are no references toBeaconState_HashTreeRoot_Callin the codebase. This indicates that the removal does not affect existing tests or code.Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash # Description: Verify the impact of removing `RunAndReturn` method in `BeaconState_HashTreeRoot_Call`. # Test: Search for the usage of `RunAndReturn` in `BeaconState_HashTreeRoot_Call`. Expect: No occurrences of the old method. rg --type go -A 5 'BeaconState_HashTreeRoot_Call.*RunAndReturn'Length of output: 65
Script:
#!/bin/bash # Description: Verify the impact of removing `RunAndReturn` method in `BeaconState_HashTreeRoot_Call`. # Test: Search for any references to `BeaconState_HashTreeRoot_Call` in the codebase. rg --type go 'BeaconState_HashTreeRoot_Call'Length of output: 44
Line range hint
16-16:
Verify the impact of removingBeaconState_HashTreeRoot_Call.The type
BeaconState_HashTreeRoot_Callhas been removed. Ensure that any existing tests or code that rely on this type are updated accordingly.Verification successful
Verification successful: No issues found.
The type
BeaconState_HashTreeRoot_Callhas been removed and there are no references to it in the codebase, including comments or documentation. This indicates that its removal does not impact any existing tests or code.Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash # Description: Verify the impact of removing `BeaconState_HashTreeRoot_Call` type. # Test: Search for the usage of `BeaconState_HashTreeRoot_Call`. Expect: No occurrences of the old type. rg --type go -A 5 'BeaconState_HashTreeRoot_Call'Length of output: 49
Script:
#!/bin/bash # Description: Verify if there are any references to `BeaconState_HashTreeRoot_Call` in comments or documentation. # Search for any references to `BeaconState_HashTreeRoot_Call` in Go comments. rg --type go -A 5 '//.*BeaconState_HashTreeRoot_Call' # Search for any references to `BeaconState_HashTreeRoot_Call` in markdown files. rg --type md 'BeaconState_HashTreeRoot_Call'Length of output: 100
Line range hint
17-17:
Verify the impact of removingHashTreeRootinBeaconState_Expecter.The
HashTreeRootmethod inBeaconState_Expecterhas been removed. Ensure that any existing tests or code that rely on this method are updated accordingly.
Line range hint
15-15:
Verify the impact of removingHashTreeRoot.The
HashTreeRootmethod has been removed from theBeaconStatestructure. Ensure that any existing tests or code that rely on this method are updated accordingly.
Line range hint
19-19:
Verify the impact of removingReturninBeaconState_HashTreeRoot_Call.The
Returnmethod inBeaconState_HashTreeRoot_Callhas been removed. Ensure that any existing tests or code that rely on this method are updated accordingly.Verification successful
The removal of the
Returnmethod inBeaconState_HashTreeRoot_Calldoes not impact the current codebase. No references toBeaconState_HashTreeRoot_Callwere found, indicating that it is not used in the existing code or tests.Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash # Description: Verify the impact of removing `Return` method in `BeaconState_HashTreeRoot_Call`. # Test: Search for the usage of `Return` in `BeaconState_HashTreeRoot_Call`. Expect: No occurrences of the old method. rg --type go -A 5 'BeaconState_HashTreeRoot_Call.*Return'Length of output: 59
Script:
#!/bin/bash # Description: Verify the broader impact of removing `Return` method in `BeaconState_HashTreeRoot_Call`. # Test: Search for all references to `BeaconState_HashTreeRoot_Call` in the codebase. rg --type go 'BeaconState_HashTreeRoot_Call'Length of output: 44
Script:
#!/bin/bash # Description: Verify the broader impact of removing `Return` method by checking references to `BeaconState_HashTreeRoot_Call` class/struct. # Test: Search for any references to `BeaconState_HashTreeRoot_Call` class/struct in the codebase. rg --type go 'BeaconState_HashTreeRoot_Call'Length of output: 44
Line range hint
18-18:
Verify the impact of removingRuninBeaconState_HashTreeRoot_Call.The
Runmethod inBeaconState_HashTreeRoot_Callhas been removed. Ensure that any existing tests or code that rely on this method are updated accordingly.Verification successful
Verify the impact of removing
RuninBeaconState_HashTreeRoot_Call.The
Runmethod inBeaconState_HashTreeRoot_Callhas been removed, and there are no references to this method elsewhere in the codebase. Therefore, its removal does not impact any existing code or tests.Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash # Description: Verify the impact of removing `Run` method in `BeaconState_HashTreeRoot_Call`. # Test: Search for the usage of `Run` in `BeaconState_HashTreeRoot_Call`. Expect: No occurrences of the old method. rg --type go -A 5 'BeaconState_HashTreeRoot_Call.*Run'Length of output: 56
Script:
#!/bin/bash # Description: Verify the impact of removing `Run` method in `BeaconState_HashTreeRoot_Call`. # Test 1: Search for any usage of `Run` method in the codebase. rg --type go 'Run(' # Test 2: Search for any references to `BeaconState_HashTreeRoot_Call` in the codebase. rg --type go 'BeaconState_HashTreeRoot_Call'Length of output: 125
Script:
#!/bin/bash # Description: Verify the impact of removing `Run` method in `BeaconState_HashTreeRoot_Call`. # Test 1: Search for any usage of `Run` method in the codebase with corrected regex pattern. rg --type go 'Run\(' # Test 2: Search for any references to `BeaconState_HashTreeRoot_Call` in the codebase. rg --type go 'BeaconState_HashTreeRoot_Call'Length of output: 42340
Also new function added in BeaconVerifier contract to allow verifier.
Summary by CodeRabbit
New Features
Enhancements
Bug Fixes