eth_getProof | Ethereum

Ethereum API method that returns a Merkle proof for a specific account, contract storage, or both for a given block. Merkle proofs enable users to verify the existence and authenticity of data within a Merkle trie, a data structure that helps in optimizing and securing data retrieval in blockchains.

​

Parameters

• address — Ethereum address of the account for which the proof is requested.

• array — the array of 32-byte storage keys that need to be proven and included. See eth_getStorageAt.

• quantity or tag — the integer of a block encoded as hexadecimal or the string with:

  • latest — the most recent block in the blockchain and the current state of the blockchain at the most recent block. A chain reorganization is to be expected.
  • safe — the block that received justification from the beacon chain. Although this block could be involved in a chain reorganization, it would necessitate either a coordinated attack by the majority of validators or an instance of severe propagation latency.
  • finalized — the block accepted as canonical by more than 2/3 of the validators. A chain reorganization is extremely unlikely, and it would require at least 1/3 of the staked ETH to be burned.
  • earliest — the earliest available or genesis block
  • pending — the pending state and transactions block. The current state of transactions that have been broadcast to the network but have not yet been included in a block.

​

Response

• balance — represents the account balance. Refer to eth_getBalance.
• codeHash — indicates the code hash associated with the account. For a simple account without any code, the value will be 0xc5d2460186f7233c927e7db2dcc703c0e500b653ca82273b7bfad8045d85a470.
• nonce — refers to the account’s nonce. See eth_getTransactionCount.
• storageHash — represents the SHA3 hash of the StorageRoot. All storage data will provide a Merkle proof that starts with this rootHash. This hash serves as the starting point for obtaining a Merkle proof for all storage entries linked to the account.
• accountProof — an array of RLP-serialized Merkle trie nodes, starting with the stateRoot node and following the path of the SHA3 (address) as the key, which can be used to verify the existence and authenticity of data within the trie.
• storageProof — contains the requested storage entries in an array, with each entry being an object that includes the following properties:
  • key — the requested storage key
  • value— the value associated with the storage key
  • proof — an array of RLP-serialized Merkle trie nodes, starting with the storageHash node and following the path of the SHA3 (key), which can be used to verify the existence and authenticity of data within the trie.

​

eth_getProof code examples

The following examples retrieve the Merkle proof for the USDT contract.

const ethers = require("ethers");

// Create a ChainstackProvider instance for Ethereum mainnet
const chainstack = new ethers.ChainstackProvider("mainnet");

async function getProof() {
  // Get the storage slot hash (value = keccak256(storage address + slot index))
  const storageSlotHash =
    "0x9c7fca54b386399991ce2d6f6fbfc3879e4204c469d179ec0bba12523ed3d44c";

  // Define the contract address for USDT
  const contractAddress = "0xdac17f958d2ee523a2206206994597c13d831ec7";

  // Get the Merkle proof of USDT's smart contract using a custom JSON-RPC call
  const proof = await chainstack.send("eth_getProof", [
    contractAddress,
    [storageSlotHash],
    "latest",
  ]);

  const block = await chainstack.send("eth_getBlockByNumber", [
    "latest",
    false,
  ]);
  // The state root is crucial for Merkle verification
  const stateRoot = block.stateRoot;

  console.log("state root:", stateRoot);
  console.log(proof);
}

getProof();

​

Use case

A use case for the eth_getProof method can be when a decentralized application (DApp) interacts with a smart contract on the Ethereum blockchain. The DApp needs to verify the state of the contract’s storage variables without downloading the entire blockchain data. By using eth_getProof, the DApp can request Merkle proof for specific storage slots in the contract. This proof can then be used to cryptographically verify the authenticity and accuracy of the storage data, ensuring the DApp is working with the correct contract state.