Troubleshooting dApps Built on Orb3

🛠️ Troubleshooting: Building dApps on Orb3 with Arbitrum

Building decentralized applications (dApps) on Orb3, which utilizes Arbitrum technology, involves understanding how gas works and addressing common issues. Here's a guide to help developers navigate these aspects effectively.

Understanding Gas on Arbitrum in Orb3:

• Fees Collection: Fees on Orb3 chains using Arbitrum are collected on Layer 2 (L2) in ETH.

• Transaction Fee Components: A transaction fee includes both an L1 component, compensating the Sequencer for posting transactions on L1, and an L2 component covering the cost of operating the L2 chain. The L2 gas price adjusts responsively to chain congestion (See EIP 1559).

Creating Retryable Tickets and Debugging Issues:

• Common Errors: When creating retryable tickets, transactions might revert on L1 due to errors like InsufficientValue or InsufficientSubmissionCost.

• Debugging: Use etherscan's Parity VM trace support to pinpoint the error causing the transaction to revert. Check the "Raw Traces" tab for the "output" field of the last subtrace to find the custom error signature.

Computing the L1 Portion of Gas Fee:

• L1 Fee Calculation: The L1 fee is determined by compressing the transaction's data and multiplying the size by ArbOS's current calldata price. This can be queried via the getPricesInWei method of the ArbGasInfo precompile.

Handling Retryable Tickets and Submission Fees:

• Calculating Submission Fee: The submission fee, proportional to the size of the L1 calldata, can be queried using Inbox.calculateRetryableSubmissionFee. Insufficient fees will cause the transaction to revert on L1.

Submitting Retryable Tickets:

• Recommended Method: Use Inbox.createRetryableTicket for most cases. For advanced users, Inbox.unsafeCreateRetryableTicket is available but requires a deep understanding of its implications.

Understanding Custom Transaction Types and Hardhat Usage:

• Custom Transaction Support: Arbitrum uses non-standard EIP-2718 typed transactions. Hardhat v2.12.2 or newer supports these custom types for Arbitrum.

Dealing with Gas Estimation Variations:

• Gas Estimate Changes: The eth_estimateGas RPC returns a value covering both L1 and L2 components. Changes in the L1 calldata price can make it appear as if the gas limit is fluctuating.

Handling "429 Too Many Requests" Error:

• Rate Limits on Public RPCs: Offchain Labs limits requests on its public RPCs to prevent DOS attacks. Consider running your own node or using a third-party provider if you encounter rate limits.

Understanding Block Numbers and Timestamps:

• Arbitrum's Block Number Behavior: block.number and block.timestamp on Arbitrum reflect the L1 block number and timestamp but are updated on a slight delay.

Final Considerations for dApp Developers:

• No Special Libraries Required: For web3.js or ethers.js, no special npm libraries are needed.

• Transaction Finality: Use eth_getBlockByNumber() with different strings like "latest", "safe", or "finalized" for varying degrees of finality.