Blockscout
SupportWebsiteGithubDiscord
  • Blockscout Open-Source Explorer
  • 💡About BlockScout
    • Features
      • Ethereum Bytecode Database Microservice
      • Blockscout Redesign
    • Chains Using Blockscout
    • Partners & Integrations
      • RaaS Providers
      • Vera: Verifier Alliance
        • Adding your chain to the Vera database
        • Programmatic verification via the API
    • News & Media
      • Newsletter & Blog
    • Funding
      • L2 Funding Proposal
        • Aux Funding Images
    • Roadmap
  • 🙎Using Blockscout
    • Getting Started
      • Glossary of Terms
      • Main Menu
      • Blocks
      • Transaction Types
      • Beacon Chain Withdrawal Views
    • My Account
      • Watch list
      • Private tags
      • Public tags
      • API keys
      • Custom ABI
      • Verified addresses
        • Copy and Sign Message
      • For developers
    • Dappscout Apps Marketplace
      • DApp Integration
    • Swapscout
      • Earn Merits when using Swapscout
    • Revokescout
    • Autoscout Explorer Launchpad
    • CSV Exports
    • Token Support
      • ERC-1155 Support
    • Merits
      • Streak rewards
      • Activity Pass
      • Leaderboard
      • Badges
      • FAQs
  • 👩‍💻Developer Support
    • For Web3 Developers
    • Link to Blockscout
    • Blockscout APIs
      • Requests & Limits
      • REST API Endpoints
        • Stats API
        • Interpreter API
      • JSON RPC & ETH Compatible RPC Endpoints
        • Account
        • Block
        • Contract
        • Logs
        • Stats
        • Token
        • Transaction
        • ETH RPC API
      • GraphQL in Blockscout
    • Smart Contract Verification
      • Blockscout UI
      • Blockscout smart-contract verification API
      • Hardhat Verification Plugin
        • Sourcify Plugin for Hardhat
      • Foundry Verification
      • Sourcify Verification
      • OpenZeppelin Contract Verification
      • Automate verifications with Catapulta
      • Verification via thirdweb
      • Interacting with Smart Contracts
    • Integrate Merits
    • Chainscout chains list
  • 🏃‍♂️Setup and Run Blockscout
    • General Overview
      • Separate Indexer, Web App, and API
      • Umbrella Project Organization
      • Indexer Architecture Overview
      • ShareLock
      • EVM Version Information
    • Requirements
      • General Backend Requirements / Blockscout Backend Prerequisites
      • Backend/Frontend Compatibility Matrix
      • Hardware & Hosting Requirements
      • Database Storage Requirements
      • Client Setting Requirements
      • Node Tracing / JSON RPC Requirements
      • L2 -> L1 JSON-RPC Method Requests
    • ☑️ENV Variables
      • Backend ENVs: Common
      • Backend ENVs: Chain-Specific
      • Backend ENVs: Integrations
      • Frontend ENVs: Common
        • ENVs
        • Deprecated ENVs
      • Deprecated Backend ENVs
        • Previous ENV Variable Home Page
    • Deployment
      • ⭐Manual Deployment Guide
        • Ubuntu Setup
        • MacOS setup
      • ⭐Docker-compose Deployment
      • ⭐Kubernetes Deployment
      • Rollup Deployment
      • 🌟Cosmos-based chains
      • 🍀Upgrade Guide (v7.0 & v8.0)
      • Frontend Migration
        • All-In-One Container
        • Separate Frontend
        • Customized Backend
        • Proxy Setup
        • FAQs
      • Manual Deployment (backend + old UI)
        • Manual cleaning an instance from the previous deployment
      • Terraform Deployment
      • Ansible Deployment (AWS Cloud)
        • Overview
        • Prerequisites
        • AWS Permissions & Settings
          • Creating a Secret Key Pair
          • Login with AWS CLI
          • Creating an AWS certificate for SSL
          • Manually Cleaning Terraform Related Instances
        • Variables
        • Deploying the Blockscout Infrastructure
        • Deploying Blockscout
        • Destroying Provisioned Infrastructure
        • Common Additional Tasks
        • Common Errors and Questions
        • AWS Marketplace (deprecated)
          • Overview
          • CloudFormation Template
          • Prerequisites & Install Parameters
          • Install from AWS Marketplace
          • AWS EC2 archive node setup with OpenEthereum (formerly Parity)
          • Updating & Redeploying in AWS
          • Customizing CSS
    • Microservices
      • Blockscout ENS (BENS) Name Service Integration
      • Smart Contract Verification
    • Configuration Options
      • Automating Restarts
      • Branding Configs
      • Circle CI Updates
      • Charts and Stats
      • CSS Configuration & Presets
      • Exchange Rates
      • Front-end Config Files
      • haproxy Settings for Blockscout.com
      • Internationalization
      • Logger Configs
      • Memory Usage
      • Metrics
      • My Account Settings
      • Sorting and Pagination
      • Tracing
      • Reown Project ID for contract Read/Write
    • Indexing
      • How do I fix indexer timeouts?
      • How do I update memory consumption to fix indexer memory errors?
    • Testing
    • DB schema
  • FAQs
    • User FAQs
    • Developer FAQs
  • 🧩Resources
    • EaaS: Hosting with Blockscout
    • Contributing to Blockscout
    • Bug Bounty Program
    • Media kit
    • Release Notes
      • v5.3.0: 10/23/23
      • v5.2.0: 6/20/23
      • v5.1.0: 2/13/23
      • v5.0.0: 1/11/23
    • Discord Channel
    • Discussion
    • GitHub Repo
Powered by GitBook
LogoLogo

Privacy and Terms

  • Privacy Notice
  • Terms and Conditions

Copyright © Blockscout Limited 2023-2024

On this page
  • Arbitrum Rollups
  • L1 JSON-RPC method details
  • Optimism Rollups
  • Optimism L1 fetchers
  • zkSync Rollups
  • L1 interaction process
  • L1 interaction summary
  • L1 JSON-RPC method details
  • Polygon zkEVM L1 fetchers
  • Scroll L1 fetchers
  • Shibarium L1 fetchers

Was this helpful?

Export as PDF
  1. Setup and Run Blockscout
  2. Requirements

L2 -> L1 JSON-RPC Method Requests

Last updated 20 days ago

Was this helpful?

This page documents the requirements for various rollup types when requesting data from the L1 node.

Layer 2 (L2) chains interact with their Layer 1 (L1) counterparts in different ways depending on the rollup type and information required. Blockscout's chain-specific fetchers interact with the L1 node to gather information crucial for tracking the rollup's state, batches, confirmations, and cross-chain messages.

The following standard L1 JSON-RPC methods are utilized. Frequency and triggers for these calls are described for each chain below.

L1 JSON-RPC Method
Purpose

eth_getLogs

Discover L1 events (Batches, Confirmations, Executions, Messages, Keysets)

eth_getBlockByNumber

Get L1 Block Timestamps, Chain Head/Safe Block info

eth_getTransactionByHash

Get L1 Tx Calldata (Batches), Get L1 Tx Originator (L1->L2 Messages)

eth_call

Get Keyset Creation Block from SequencerInbox contract (Used infrequently for Arbitrum chains only)


Arbitrum Rollups

L1 JSON-RPC method details

Method: eth_getLogs

Used periodically to poll for specific L1 events emitted by Arbitrum contracts. The polling intervals are generally configurable (INDEXER_ARBITRUM_BATCHES_TRACKING_RECHECK_INTERVAL and INDEXER_ARBITRUM_TRACKING_MESSAGES_ON_L1_RECHECK_INTERVAL for new events, faster polling for historical catch-up).

  • Events Polled:

    • SequencerBatchDelivered (from SequencerInbox contract): To discover new L1 batches containing L2 block data. Polled periodically by the batch tracking worker (TrackingBatchesStatuses).

    • SendRootUpdated (from Outbox contract): To discover L2 block confirmations. Polled periodically by the batch tracking worker.

    • OutBoxTransactionExecuted (from Outbox contract): To discover L2-to-L1 message executions on L1. Polled periodically by the batch tracking worker.

    • MessageDelivered (from Bridge contract): To discover L1-to-L2 message initiations on L1. Polled periodically by the L1 message tracking worker (TrackingMessagesOnL1).

    • SetValidKeyset (from SequencerInbox contract): To retrieve details about AnyTrust Data Availability Committee keysets. This is triggered on-demand when processing an AnyTrust batch that references a keyset hash not yet seen in the database.


Method: eth_getBlockByNumber

  • Fetching Timestamps:

    • Called frequently in response to processing events found via eth_getLogs. When a relevant event (like batch delivery, confirmation, or message execution) is found in a log, this method is called for the corresponding L1 block number to get its timestamp. This happens in batches triggered by the periodic log polling.

  • Fetching Chain Head/Safe Block:

    • Called periodically (driven by recheck_interval) with tags "latest" and "safe" to determine the current L1 chain head and the safe block for reorg protection and determining finality. Used by batch, confirmation, and execution workers.

    • Called once during initialization to determine the starting point if not explicitly configured.


Method: eth_getTransactionByHash

Called in response to processing events found via eth_getLogs:

  • Fetching Batch Calldata:

    • When a SequencerBatchDelivered event is processed, this method is called for the L1 transaction hash associated with the event to retrieve the transaction's input data (calldata). This calldata contains essential batch information, especially for non-blob batches.

  • Fetching L1->L2 Message Originator:

    • When a MessageDelivered event (for an L1->L2 message) is processed, this method is called for the L1 transaction hash to retrieve the originator (from) address.


Method: eth_call

Used less frequently than the other calls.

  • Fetching Keyset Creation Block:

    • When processing an AnyTrust batch referencing a previously unknown keyset hash, an eth_call is made to the SequencerInbox contract's getKeysetCreationBlock function to determine the L1 block where the keyset became active. This is triggered on-demand during batch processing.


Optimism Rollups

Optimism L1 fetchers

Method calls are described for each of the Optimism-based fetchers including Deposit, DisputeGame, OutputRoot, TransactionBatch and WithdrawalEvent.

Indexer.Fetcher.Optimism.Deposit

  • eth_getLogs (driven by INDEXER_OPTIMISM_L1_ETH_GET_LOGS_RANGE_SIZE for catchup mode) - one request per block in realtime mode

  • eth_getBlockByNumber for each block within eth_getLogs response to get block timestamp. Batch request is used, so one batch request per one eth_getLogs call

Indexer.Fetcher.Optimism.DisputeGame

  • call to OptimismPortal's respectedGameType() public getter (every 60 seconds)

  • call to DisputeGameFactory's gameCount public getter (every 60 seconds)

  • call to DisputeGameFactory's gameAtIndex public getter (max 50 items per batch request) and the corresponding batch calls to extraData, resolvedAt, status public getters for each dispute game

  • call to DisputeGameFactory's resolvedAt public getter (max 50 items per batch request) for max 1000 last unresolved games

  • call to DisputeGameFactory's status public getter (max 50 items per batch request) for max 1000 last resolved games

Indexer.Fetcher.Optimism.OutputRoot

  • eth_getLogs (driven by INDEXER_OPTIMISM_L1_ETH_GET_LOGS_RANGE_SIZE for catchup mode) - one request per block in realtime mode

Indexer.Fetcher.Optimism.TransactionBatch

  • eth_getBlockByNumber (batch RPC calls containing up to INDEXER_OPTIMISM_L1_BATCH_BLOCKS_CHUNK_SIZE requests per batch in catchup mode starting from the start block defined in SystemConfig contract) - one request per block in realtime mode

Indexer.Fetcher.Optimism.WithdrawalEvent

  • eth_getLogs (driven by INDEXER_OPTIMISM_L1_ETH_GET_LOGS_RANGE_SIZE for catchup mode) - one request per block in realtime mode

  • eth_getBlockByNumber for each block within eth_getLogs response to get block timestamp. Batch request is used, so one batch request per one eth_getLogs call


zkSync Rollups

L1 interaction process

Blockscout's zkSync-specific fetchers verify zkSync batch status and transitions (Committed, Proven, Executed) recorded on the L1.

L1 interaction summary

L1 calls are infrequent and only triggered to confirm L1 state transitions suggested by the L2 node.

  • L1 interaction is driven by the BatchesStatusTracker. This tracker performs periodic checks based on the INDEXER_ZKSYNC_BATCHES_STATUS_RECHECK_INTERVAL ENV variable setting.

  • Each check phase (:check_committed, :check_proven, :check_executed) first queries the L2 node via RPC (zks_getL1BatchDetails).

  • If (and only if) the L2 query indicates a new L1 transaction hash associated with a batch's status change (commit, prove, or execute), the corresponding L1 RPC method (eth_getTransactionReceipt or eth_getTransactionByHash) is called for that specific transaction hash.

L1 JSON-RPC method details

Method: eth_getTransactionReceipt

Purpose: Retrieves the receipt of an L1 transaction suspected of changing a batch's status (commit or execute). The fetcher specifically looks for event logs within the receipt (BlockCommit or BlockExecution events) to confirm which batches were affected by that single L1 transaction.

Frequency:

  • Called conditionally by the BatchesStatusTracker process.

  • This tracker runs in a loop with a configurable INDEXER_ZKSYNC_BATCHES_STATUS_RECHECK_INTERVAL.

  • Within this loop, it first checks the L2 RPC (zks_getL1BatchDetails) for the oldest uncommitted/unexecuted batch.

  • If the L2 RPC response indicates a new commit or execute L1 transaction hash associated with that batch, then eth_getTransactionReceipt is called on the L1 node for that specific transaction hash.

  • It does not poll L1 constantly; the call is triggered only when a potential status change is detected via L2 RPC data during the periodic check.


Method: eth_getTransactionByHash

Purpose: Retrieves the details of an L1 transaction suspected of proving one or more zkSync batches. The fetcher needs the transaction's input (calldata) to decode the list of batches proven in that single L1 transaction.

Frequency:

  • Called conditionally by the BatchesStatusTracker process, similar to eth_getTransactionReceipt. It also runs within the tracker's periodic INDEXER_ZKSYNC_BATCHES_STATUS_RECHECK_INTERVAL.

  • The tracker checks the L2 RPC (zks_getL1BatchDetails) for the oldest unproven batch. If the L2 RPC response indicates a new prove L1 transaction hash, then eth_getTransactionByHash is called on the L1 node for that specific transaction hash to retrieve its calldata.

  • Like the receipt fetch, this is triggered by potential changes detected via L2 RPC during the periodic check, not through constant L1 polling.


Polygon zkEVM L1 fetchers

Method calls are described for each of the zkEVM-based fetchers including BridgeL1, BridgeL1Tokens, and TransactionBatch.

Indexer.Fetcher.PolygonZkevm.BridgeL1

  • eth_getLogs (max 1000 blocks in a range per request for catchup mode) - one request per block in realtime mode

  • eth_getBlockByNumber for each block within eth_getLogs response to get block timestamp (batch request is used with max 50 items per request)

  • eth_getBlockByNumber to get latest block (every block time in seconds, divided by 2)

  • one batch request (with calls to symbol() and decimals() getters of token contracts) per one eth_getLogs call

Indexer.Fetcher.PolygonZkevm.BridgeL1Tokens

  • one batch request (with calls to symbol() and decimals() getters of token contracts) per one set of logs taken in realtime mode from the L2 block

Indexer.Fetcher.PolygonZkevm.TransactionBatch

  • a batch call of zkevm_batchNumber, zkevm_virtualBatchNumber, zkevm_verifiedBatchNumber requests per INDEXER_POLYGON_ZKEVM_BATCHES_RECHECK_INTERVAL seconds

  • a batch call of zkevm_getBatchByNumber requests per INDEXER_POLYGON_ZKEVM_BATCHES_CHUNK_SIZE zkEVM batches


Scroll L1 fetchers

Method calls are described for each of the Scroll-based fetchers including Batch and BridgeL1.

Indexer.Fetcher.Scroll.Batch

  • eth_getLogs (driven by INDEXER_SCROLL_L1_ETH_GET_LOGS_RANGE_SIZE for catchup mode) - one request per block in realtime mode

  • eth_getBlockByNumber for each block within eth_getLogs response to get block timestamp (batch request is used with max 50 items per request)

  • eth_getBlockByNumber to get latest block (every block time in seconds, divided by 2)

Indexer.Fetcher.Scroll.BridgeL1

  • eth_getLogs (driven by INDEXER_SCROLL_L1_ETH_GET_LOGS_RANGE_SIZE for catchup mode) - one request per block in realtime mode

  • eth_getBlockByNumber for each block within eth_getLogs response (taking into account SentMessage events only) to get block timestamp (batch request is used with max 50 items per request)

  • eth_getBlockByNumber to get latest block (every block time in seconds, divided by 2)

Shibarium L1 fetchers

Method calls are described for each of the Scroll-based fetchers including L1 and RollupL1ReorgMonitor.

Indexer.Fetcher.Shibarium.L1

  • three eth_getLogs requests per chunk for catchup mode (max 1000 blocks in a chunk) - three requests per block in realtime mode

  • eth_getBlockByNumber for each block within eth_getLogs responses (taking into account deposit events only) to get block timestamp (batch request is used with max 50 items per request)

  • eth_getBlockByNumber to get latest block (every block time in seconds, divided by 2)

Indexer.Fetcher.RollupL1ReorgMonitor

  • eth_getBlockByNumber to get latest block (every block time in seconds, divided by 2)

🏃‍♂️
Arbitrum
Optimism
Scroll
Shibarium
zkSync
Polygon zkEVM