diff --git a/docs/launch-arbitrum-chain/01-a-gentle-introduction.mdx b/docs/launch-arbitrum-chain/01-a-gentle-introduction.mdx index 8ee5d47a4..7b2ff7c63 100644 --- a/docs/launch-arbitrum-chain/01-a-gentle-introduction.mdx +++ b/docs/launch-arbitrum-chain/01-a-gentle-introduction.mdx @@ -43,20 +43,20 @@ Arbitrum's protocols address this challenge by offloading some of the Ethereum n ### What key features should I consider? -| Feature | Description | -| --------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | -| Dedicated throughput | More info | -| EVM+ compatibility | EVM compatability + more languages like Rust programs supported | -| Account abstraction | Account abstraction | -| Gas & Tokens | Custom gas token or Native ETH | -| Data availability | Rollup (ETH DA), AnyTrust, Alt-DA | -| Fast confirmations | Fast withdrawals | -| Security & validation | BoLD, Permissioned validators, Challenge period enforced on L1 | -| Safety Features | Force-inclusion & customizable governance | -| MEV | Timeboost | -| Cost | Data posting costs | -| Infrastructure | Hardware requirements | -| Interop | TBD | +| Feature | Description | +| --------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | +| Dedicated throughput | More info | +| EVM+ compatibility | EVM compatability + more languages like Rust programs supported | +| Account abstraction | Account abstraction | +| Gas & Tokens | Custom gas token or Native ETH | +| Data availability | Rollup (ETH DA), AnyTrust, Alt-DA | +| Fast confirmations | Fast withdrawals | +| Security & validation | BoLD, Permissioned validators, Challenge period enforced on L1 | +| Safety Features | Force-inclusion & customizable governance | +| MEV | Timeboost | +| Cost | Data posting costs | +| Infrastructure | Hardware requirements | +| Interop | TBD | ### How do Arbitrum chains help the Ethereum ecosystem? diff --git a/docs/launch-arbitrum-chain/partials/config-anytrust.mdx b/docs/launch-arbitrum-chain/partials/config-anytrust.mdx index 759918984..c020ceb1c 100644 --- a/docs/launch-arbitrum-chain/partials/config-anytrust.mdx +++ b/docs/launch-arbitrum-chain/partials/config-anytrust.mdx @@ -9,8 +9,8 @@ ## Cons of using AnyTrust -- **Introduced trust assumptions**: Relies on the DAC's honesty and availability, which adds a layer of trust not present in full trustless rollups. This could be a risk if committee members collude or fail. -- **Reduced decentralization and security guarantees**: Lacks the full trustlessness, permissionlessness, and censorship resistance of Rollups, as not all data is posted to Ethereum by default. This makes it less suitable for high-value DeFi or applications requiring Ethereum-level security. -- **Potential for fallback mode issues**: If the DAC quorum isn't met, the chain reverts to Rollup mode, which could increase costs temporarily and introduce delays similar to standard Rollups. +- **Introduced trust assumptions**: Relies on the DAC's honesty and availability, which adds a layer of trust not present in full trustless rollups. This trust assumption could be a risk if committee members collude or fail. +- **Reduced decentralization and security guarantees**: Lacks the full trustlessness, permissionlessness, and censorship resistance of Rollups, as not all data is posted to Ethereum by default. This lack of data posting makes it less suitable for high-value DeFi or applications requiring Ethereum-level security. +- **Potential for fallback mode issues**: If the DAC cannot come to a quorum, the chain reverts to Rollup mode, which could increase costs temporarily and introduce delays similar to standard Rollups. - **Liquidity and adoption changes**: May face lower liquidity or ecosystem integration compared to rollup-based chains like Arbitrum One, potentially limiting interoperability for certain dApps. - **Not optimal for all use cases**: For applications handling significant financial value or needing maximum security, the trade-offs in decentralization could outweigh the benefits. diff --git a/docs/launch-arbitrum-chain/partials/config-bold.mdx b/docs/launch-arbitrum-chain/partials/config-bold.mdx new file mode 100644 index 000000000..74092701a --- /dev/null +++ b/docs/launch-arbitrum-chain/partials/config-bold.mdx @@ -0,0 +1,8 @@ +BoLD (Bounded Liquidity Delay) is a dispute resolution protocol that enables permissionless validation, allowing anyone to propose, challenge, and defend chain states by bonding `ETH`, with disputes resolved in a fixed-time window (typically around 7-14 days, depending on the chain). For Arbitrum chains, BoLD is available as an optional upgrade via the Nitro stack, enhancing decentralization and security while setting states to a parent chain like Ethereum or Arbitrum One. + +| Feature | Pros | Cons | +| ----------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | +| Validation & Decentraliation | - Enables permissionless validation, allowing anyone to propose and defend states, increasing relsilience and inclusivity
- Supports trustless bonding pools, letting groups pool `ETH` to participate without high individual capital barriers, promoting broader decentralization | - High bond requirements (e.g., potentially thousands of `ETH` for assertions) may centralize participation to well-funded entities, limiting smaller validators.
- No built-in protocol-level incentives for validators could lead to free-riding, where parties rely on others to defend the chain. | +| Security & Dispute Resolution | - Mitigates delay attacks by enforcing a bounded dispute window (e.g., ~7 days plus grace periods), ensuring predictable resolution even against multiple malicious challengers.
- Enhances withdrawal security to the parent chain by limiting indefinite delays, and includes features like Delay Buffer for censorship resistance.
- A single honest party can win disputes against any number of dishonest ones, with audited code for reliability. | - Disputes can still delay all withdrawals (up to ~14 days total), impacting user experience and liquidity.
- For lower-TVL Arbitrum chains, high bonds might need adjustment, trading off security against centralization risks or vulnerability to spam.
- Potential censorship risks for L3 Arbitrum chains (e.g., parent chain is censored, delays could extend up to 50 days in extreme cases, though mitigated). | +| Economics & Incentives | - Bonds deter actors, with honest parties refunded plus a 1% defender's bounty and gas reimbursements, plus potential service fees (3-4% annualized `ETH` yield) from chain owners.
- Fixed costs and resource ratios prevent dishonest parties from inflating expenses for honest validators. | - Significant capital lockup in bonds creates opportunity costs and risks (e.g., loss if proven wrong), potentially prohibitive for smaller chains.
- KYC requirements for fee eligibility may exclude some participants, like those in sanctioned regions.
- Operational costs for onchain proofs and disputes (gas, computation), add complexity and expenses. | +| Implementations & Maturity | - Modular upgrade for Arbitrum chains
- Community testing via testnets and visualizers available for easier adoption | - Increased protocol complexity may require additional tooling and expertise to manage.
- Reliance on parent chain for final proofs; issues there could affect Arbitrum chain disputes. | diff --git a/docs/launch-arbitrum-chain/partials/config-force-inclusion.mdx b/docs/launch-arbitrum-chain/partials/config-force-inclusion.mdx new file mode 100644 index 000000000..22e1f76dd --- /dev/null +++ b/docs/launch-arbitrum-chain/partials/config-force-inclusion.mdx @@ -0,0 +1,13 @@ +Force inclusion in Arbitrum refers to a mechanism that allows users to bypass the Sequencer by submitting transactions directly to the Delayed Inbox contract on Ethereum. After a waiting period, typically around 24 hours, it is possible to force the transaction for inclusion on the Arbitrum chain. This mechanism is designed primarily as a safeguard for rare scenarios, such as sequencer downtime or potential censorship. + +## Pros + +- **Guarantees transaction inclusion and liveness**: Even if the Sequencer is unresponsive, malicious, or censoring transactions, force inclusion ensures your transaction is eventually processed, maintaining the chain's operational continuity. +- **Enhances censorship resistance**: It mitigates risks of transaction censorship by allowing direct submission to Layer 1, aligning with Ethereum's decentralized principles and providing a trustless way to interact with the chain. +- **Permissionless and protective**: Anyone can use it to enforce inclusion, protecting against sequencer failures without needing to rely on centralized components. + +## Cons + +- **Significant delay**: There's a mandatory waiting period of approximately 24 hours before force inclusion is triggerable, making it much slower than the near-instant processing via the Sequencer. +- **Higher costs and inefficiency**: Submitting directly to Layer 1 incurs full Ethereum gas fees, which are typically more expensive than Layer 2 transactions. Force inclusion **is not optimal** for regular use—it's intended only for rare, emergency scenarios. +- **Security vulnerabilities**: It can be exploited in certain attacks, such as the QueueCut attack, potentially leading to double-spending or fund losses in cross-chain scenarios. diff --git a/docs/launch-arbitrum-chain/partials/config-l1-challenge-period.mdx b/docs/launch-arbitrum-chain/partials/config-l1-challenge-period.mdx new file mode 100644 index 000000000..0ead2a789 --- /dev/null +++ b/docs/launch-arbitrum-chain/partials/config-l1-challenge-period.mdx @@ -0,0 +1,9 @@ +Configuring the challenge period on L1 means deploying your Arbitrum chain as a Layer 2 rollup that settles directly to Ethereum, where assertions are posted, challenged, and confirmed using L1 contracts and block numbers. A Layer 2 configuration contrasts with a Layer 3 configuration, where the chain settles to Arbitrum, and the challenge period runs on the L2. The default challenge period is 6.4 days, but it can be customized via the `confirmPeriodBlocks` parameter during deployment or post-deployment by the chain owner. + +| Feature | Pros | Cons | +| --------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | +| Security | - Directly inherits Ethereum's full L1 security model, with no dependency on an intermediary L2's assumptions or potential vulnerabilities.
- Challenges are resolved on the most decentralized and tested layer, reducing risks from L2-specific issues | - No significant cons here; L1 offers the highest baseline security, though custom shorter periods could theoretically reduce time for fraud detection. | +| Costs | - Avoids compounded fees from an L2 intermediary, potentially simplifying long-term economics for high-security needs | - Higher operational costs: Posting transaction blobs and resolving challenges uses expensive L1 gas (e.g., calldata fees on Ethereum are higher)
- Less suitable for cost-sensitive applications, as L2 settlement can reduce data availability and posting expenses. | +| Finality & Withdrawal times | Faster overall finality for withdrawals directly to L1: ~7 days default challenge period
- Simpler path to Ethereum mainnet settlement, beneficial for users needing quick access to L1 liquidity | - Still requires a ~7 day wait for standard withdrawals, which can feel slow compared to zero-knowledge rollups or optimized AnyTrust setups
- No benefit from L2's faster block times for intra-layer operations | +| Customization & Flexibility | - Challenge period is easily customizable (e.g., via `Rollup.setConfirmPeriodBlocks`) to balance security and speed, using reliable L1 block timing
- Suitable for applications requiring high-value transfers or strict L1 alignment | - Less flexibility in leveraging L2-specific features (e.g., cheaper data availability committees in AnyTrust mode)
- Customization options are similar to L2 settlement, but adjustments may incur higher gas costs on L1 | +| Overall usability | - Ideal for projects prioritizing maximum decentralization and direct Ethereum integration, avoiding "security stacking" risks | - May limit scalability for high-throughput apps due to L1 congestion or costs; L3 setups on L2 can offer better performance for specialized use cases | diff --git a/docs/launch-arbitrum-chain/partials/config-permissioned-validators.mdx b/docs/launch-arbitrum-chain/partials/config-permissioned-validators.mdx new file mode 100644 index 000000000..93bc88e16 --- /dev/null +++ b/docs/launch-arbitrum-chain/partials/config-permissioned-validators.mdx @@ -0,0 +1,15 @@ +By default, Arbitrum chains can use permissioned validators, where only pre-approved entities can participate in validation (e.g., challenging state assertions). This model contrasts with permissionless validation, enabled via protocols like BoLD, which opens validation to anyone. + +## Pros + +- **Enhanced control and security in trusted environments**: Permissioned validators allow the chain owner to select and vet participants, reducing risks from unknown or malicious actors, which is ideal for enterprise or private chains where trust among validators is present, minimizing the chance of spam or uncoordinated attacks. +- **Regulatory compliance and privacy**: Easier to implement access controls, such as restricting who can read chain data or participate, which helps with legal requirements (e.g., KYC for validators) in regulated industries like finance. +- **Simpler setup and lower operational overhead**: Without needing to support open participation, the chain can operate with fewer nodes, potentially leading to faster consensus, reduced complexity in dispute resolution, and lower costs for maintaining the network. Permissioned validation is beneficial for smaller or specialized Arbitrum chains focused on specific use cases. +- **Established and proven model**: Permissioned validation mirrors the initial setup of chains like Arbitrum One, providing a reliable baseline without requiring additional protocols like BoLD for permissionless features. + +## Cons + +- **Vulnerability to delay attacks**: In permissioned systems, malicious validators can exploit the challenge window by repeatedly posting false claims, forcing honest validators to spend resources on defenses and delaying confirmations or withdrawals. This potential exploitation could raise costs and risks of liveness issues. +- **Centralization risks**: The system relies on a limited set of trusted validators; if they collude, fail, or are compromised, the integrity of the chain could be at risk. This centralization could make the chain less appealing to users who value trustlessness. +- **Limited robustness against adversaries**: Unlike permissionless models, where any honest party can defend the chain, permissioned validation depends on the availability and honesty of the approved set. A single point of failure (e.g., if validators go offline) could halt progress. +- **Potentially for reduced adoption**: Developers or users seeking Ethereum-like decentralization might prefer permissionless options, limiting the chain's appeal in open ecosystems. Enabling permissionless later (via BoLD) requires upgrades and community/DAO approval, adding complexity. diff --git a/docs/launch-arbitrum-chain/partials/config-timeboost.mdx b/docs/launch-arbitrum-chain/partials/config-timeboost.mdx new file mode 100644 index 000000000..06aee62c8 --- /dev/null +++ b/docs/launch-arbitrum-chain/partials/config-timeboost.mdx @@ -0,0 +1,8 @@ +Timeboost is an optional transaction ordering policy that is configurable on any Arbitrum chain, including Arbitrum (Orbit) chains. It replaces the First-come, First-served (FCFS) ordering by introducing a sealed-bid, second-price auction for an "express lane." This express lane gives the auction winner a temporary time advantage (default: 200ms) for submitting transactions ahead of others, allowing the chain owner to capture Maximal Extractable Value (MEV) from activities like arbitrage or liquidations. + +| Feature | Pros | Cons | +| -------------------------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | +| Revenue and MEV Capture | Captures MEV (e.g., from arbitrage or backrunning) as auction revenue for the chain owner, potentially generating significant income. Revenue can be redistributed to users, apps, or burned, creating new value accrual paths. Flexible bid tokens (e.g., any `ERC-20`) allow customization. | Revenue isn't guaranteed; it depends on MEV volume—if your Arbitrum chain has low activity, auctions may yield little or nothing. Setup/maintenance costs (e.g., auctioneer infrastructure) could exceed benefits. | +| Network performance and spam reduction | Reduces spam and congestion by shifting searcher resources from hardware-based latency races to auctions, potentially lowering network stress and improving overall efficiency. Maintains industry-leading block times (250ms) and protects against harmful MEV via private mempool. | Introduces a ~200ms delay for non-express lane transactions (increasing average response time to ~450ms), which could slightly degrade UX for regular users during active auction rounds. Express lane transactions may drop if not sequenced within ~1.25 seconds, adding minor reliability risks. | +| User and ecosystem impact | Preserves strong UX with minimal changes for most users; enables new models like searchers reselling express lane access, potentially boosting ecosystem innovation. Socializes MEV benefits back to the chain (e.g., via DAO), reducing negative externalities from searcher competition. | Risk of centralized dominance: well-funded entities might monopolize auctions, though mitigated by competitive bidding and short advantage (200ms). This centralization could enable new MEV strategies (e.g., front-running liquidations), potentially harming users or protocols in some cases. Adds friction for latency-sensitive features like onchain limit order books, potentially widening spreads or increasing risks for market makers. | +| Flexibility and Implementation | Fully optional and customizable (e.g, adjust delays, auction cadence); works with decentralized sequencers and reverts to FCFS if needed. Ideal for Arbitrum chain owners seeking control over ordering policies. Requires continuous bidding, which may not suit spontaneous MEV opportunities, and lacks reordering or full control for winners, limiting utility in some scenarios. Potential for secondary markets adds complexity and requires ongoing monitoring for risks like collusion or abuse. Bid deposits tie up liquidity (with a withdrawal delay of ~2 minutes). | diff --git a/src/components/FloatingHoverModal/index.js b/src/components/FloatingHoverModal/index.js index 18cb10719..af39fddc0 100644 --- a/src/components/FloatingHoverModal/index.js +++ b/src/components/FloatingHoverModal/index.js @@ -26,6 +26,11 @@ import ConfigHardware from '@site/docs/launch-arbitrum-chain/partials/config-har import ConfigRollup from '@site/docs/launch-arbitrum-chain/partials/config-rollup.mdx'; import ConfigAnytrust from '@site/docs/launch-arbitrum-chain/partials/config-anytrust.mdx'; import ConfigFastwithdrawals from '@site/docs/launch-arbitrum-chain/partials/config-fast-withdrawals.mdx'; +import ConfigTimeboost from '@site/docs/launch-arbitrum-chain/partials/config-timeboost.mdx'; +import ConfigBold from '@site/docs/launch-arbitrum-chain/partials/config-bold.mdx'; +import ConfigPermissionedValidators from '@site/docs/launch-arbitrum-chain/partials/config-permissioned-validators.mdx'; +import ConfigL1ChallengePeriod from '@site/docs/launch-arbitrum-chain/partials/config-l1-challenge-period.mdx'; +import ConfigForceInclusion from '@site/docs/launch-arbitrum-chain/partials/config-force-inclusion.mdx'; // Static content mapping const contentMap = { @@ -37,6 +42,11 @@ const contentMap = { 'config-rollup': ConfigRollup, 'config-anytrust': ConfigAnytrust, 'config-fast-withdrawals': ConfigFastwithdrawals, + 'config-timeboost': ConfigTimeboost, + 'config-bold': ConfigBold, + 'config-permissioned-validators': ConfigPermissionedValidators, + 'config-l1-challenge-period': ConfigL1ChallengePeriod, + 'config-force-inclusion': ConfigForceInclusion, }; // MDX components for proper rendering