eth_getBlockByHash - zkSync RPC Method

Returns information about a block by hash on zkSync Era.

Why zkSync? Build on Matter Labs' flagship zkEVM powering the Elastic Network of interoperable hyperchains with ZK Stack modular framework, hyperchain interoperability, native account abstraction, and $1.9B in tokenized real-world assets.

When to Use This Method

eth_getBlockByHash is essential for ZK developers, RWA tokenization teams, and builders launching custom L2/L3 chains:

• Block verification using deterministic hash lookup: Retrieve block data by its unique, immutable hash on zkSync Era
• Chain reorganization handling: Track blocks reliably by hash during reorgs on Matter Labs' flagship zkEVM powering the Elastic Network of interoperable hyperchains
• Cross-chain bridge finality verification: Confirm block existence by its canonical hash for RWA tokenization ($1.9B, 25% market share), hyperchain deployment via ZK Stack, and cross-chain DeFi
• Deterministic queries when block number may change: Ensure consistent results for applications that need stable references regardless of chain state

Common Use Cases

1. Verify a Specific Block from a Transaction's blockHash Field

When a transaction response includes blockHash, use eth_getBlockByHash to retrieve the full parent block. This cross-references the transaction's context and confirms which block it was included in on zkSync Era.

import { JsonRpcProvider } from 'ethers';

const provider = new JsonRpcProvider('https://api-zksync-era-mainnet-full.n.dwellir.com/YOUR_API_KEY');

async function verifyBlockFromTx(txHash) {
  const tx = await provider.getTransaction(txHash);
  if (!tx || !tx.blockHash) return null;

  const block = await provider.getBlock(tx.blockHash);
  console.log(`Transaction ${txHash} in block #${block.number}`);
  console.log(`Block hash: ${block.hash}`);
  console.log(`Block timestamp: ${new Date(block.timestamp * 1000).toISOString()}`);
  return block;
}

verifyBlockFromTx('0xc4c7231ab3f1d8feaaf4e2b9933696e37095d0af84cb6cc70f48493b38f3a731');

2. Cross-Reference Blocks During Chain Reorganization

During a chain reorganization, block numbers can shift but block hashes remain unique identifiers. Use eth_getBlockByHash to verify the canonical chain state and detect whether a previously observed block has been orphaned on Matter Labs' flagship zkEVM powering the Elastic Network of interoperable hyperchains.

from web3 import Web3

w3 = Web3(Web3.HTTPProvider('https://api-zksync-era-mainnet-full.n.dwellir.com/YOUR_API_KEY'))

def verify_block_still_canonical(block_hash):
    block = w3.eth.get_block(block_hash)
    if block is None:
        print(f'Block {block_hash} has been pruned or orphaned')
        return False
    print(f'Block {block_hash} still canonical at height #{block.number}')
    return True

# Check a known block hash
verify_block_still_canonical('0x896c63ec4c3bcacb3367166437ae2b90530df268c3e7b870fb9138f98b0b060c')

3. Audit Block Data by Known Hash Reference

For compliance and audit workflows, store block hashes as permanent references. Re-querying eth_getBlockByHash with a stored hash guarantees you retrieve the exact same block data, even months later on zkSync Era.

package main

import (
    "context"
    "fmt"
    "log"

    "github.com/ethereum/go-ethereum/common"
    "github.com/ethereum/go-ethereum/ethclient"
)

func main() {
    client, _ := ethclient.Dial("https://api-zksync-era-mainnet-full.n.dwellir.com/YOUR_API_KEY")

    knownHash := common.HexToHash("0x896c63ec4c3bcacb3367166437ae2b90530df268c3e7b870fb9138f98b0b060c")
    block, err := client.BlockByHash(context.Background(), knownHash)
    if err != nil || block == nil {
        log.Fatal("Block not found: may be pruned from node")
    }

    fmt.Printf("Audited block #%d\n", block.Number().Uint64())
    fmt.Printf("Hash: %s\n", block.Hash().Hex())
    fmt.Printf("Transactions: %d\n", len(block.Transactions()))
}

Best Practices

• Hash-based lookups are more reliable during chain reorgs than number-based: A block hash uniquely identifies one canonical block, while a block number may shift to a different block after a reorg
• Store block hashes in your database for future verification: Persisting the hash alongside related records enables deterministic re-querying for audits and data integrity checks
• Handle null results gracefully: Blocks can be pruned by the node, especially on non-archive endpoints; your application should treat a null response as a missing or unavailable block
• For L2 optimistic rollups, verify the L1 anchor hash separately: The hash on the L2 chain references a different block space than the L1 anchor; validate both independently for full finality confidence

Code Examples

Error Handling

Related Methods

• eth_getBlockByNumber - Get block by number
• eth_blockNumber - Get latest block number