FAQ Optimism (OP)
Last updated
Last updated
Optimism is a Layer 2 scaling solution for Ethereum that leverages rollup technology to bundle multiple transactions into batches before submitting them to Ethereum L1.
Sequencer: Orders and processes transactions before batching.
Proposer: Posts state roots and finalization data to L1.
Batcher: Sends compressed data batches to L1 for data availability.
RPC Nodes: Support horizontal scaling for high RPC traffic.
batcher_max_channel_duration: Controls the maximum duration a batch can stay open before being submitted.
Definition: Specifies the maximum duration (in L1 blocks) that a batcher can keep a channel open before submitting the batched transactions to L1.
Purpose: Ensures timely submission of transactions, balancing between cost efficiency and data availability.
Recommendation: Set this value considering the L1 block time (e.g., for Ethereum, ~12 seconds per block) and the desired frequency of batch submissions.
proposer_proposal_interval: Time interval for submitting state roots to L1.
Definition: Determines the time interval (in seconds) at which the proposer submits state roots to L1.
Purpose: Regular submissions help in maintaining the integrity of the rollup and facilitate L2 to L1 communication.
Recommendation: Align this interval with batcher_max_channel_duration to ensure synchronized operations and avoid redundant postings.
data_availability_type: Specifies how the rollup handles data availability (either blobs or calldata).
Definition: Indicates the method used for data availability in the rollup, either blobs or calldata.
Purpose: Determines how transaction data is stored and retrieved, impacting scalability and security.
Recommendation: Choose blobs for blob storage or calldata for embedding data directly in transactions, based on your application's requirements.
Bridging tokens between Layer 1 (Ethereum) and Layer 2 (Optimism) is essential for enabling asset movement across the two layers. The process involves both deposits (moving assets from L1 to L2) and withdrawals (returning assets from L2 to L1).
User Initiation: The user sends tokens to the L1 Standard Bridge contract.
Message Relaying: The L1 CrossDomain Messenger handles message transmission to L2.
L2 Credit: Tokens are minted or credited to the user’s L2 account upon message finalization.
User Initiation: The user initiates a withdrawal on L2.
Message Relaying: The L2 CrossDomain Messenger processes the request.
L1 Finalization: Tokens are released to the user's L1 account after the challenge period.
Tokens can be bridged using the OptimismPortalProxy.depositERC20Transaction method.
Ensure token approval before deposit.
Depositing and Withdrawing Tokens.
⚠ Important: The following parameters must be configured before rollup deployment and cannot be changed after deployment.
Batching Parameters
Max Number of Batches: Default is 300.
Max Batch Size: Set to 120,000 bytes.
Max Batches Per Sequence: Default is 300 but can be increased.
Setting batcher_max_channel_duration
Ensure both batcher_max_channel_duration and proposer_proposal_interval are synchronized to prevent excessive postings to L1.
Sequencer Rate Limits and Batch Size
Sequencer Rate Limit: Default rate settings can be modified based on traffic needs.
Batch Size: The batch size can be adjusted for both L1 and L2 throughput optimization.
For low-latency rollups (high-speed apps) → Lower values for batcher_max_channel_duration and proposer_proposal_interval.
For cost-efficient rollups (large batch processing) → Higher values for these parameters to batch more transactions per submission.
Users have reported intermittent errors when attempting to receive tokens from the Optimism faucet, especially during periods of high demand. These errors often occur due to:
Server Load: High traffic can temporarily overwhelm the faucet service.
Insufficient Funds: The faucet may be out of funds for distribution.
Rate Limits: Users might hit daily or IP-based rate limits.
Wait a few hours and retry the claim process.
Ensure the correct wallet network (L2) is selected.
Try alternative testnet faucets if available.
The batcher in the OP Stack is responsible for submitting L2 transaction data to L1 in a compressed format. To optimize performance and reduce costs, the batcher_max_channel_duration parameter controls how long a batch remains open before submission.
Default: 0 (disables batch duration tracking).
Recommended: Set to target 5 hours of batching, which corresponds to approximately 1500 L1 blocks (assuming a 12-second block time on Sepolia).
Adjust the batch size and interval based on network traffic patterns for cost optimization.
