Skip to content

Commit e8061db

Browse files
Merge pull request #2799 from OffchainLabs/tw-567-arb-chain-config-pt-5
docs: tw567-arbitrum-chain-config-pt-5
2 parents b3e7bb7 + 9a0728e commit e8061db

File tree

8 files changed

+118
-5
lines changed

8 files changed

+118
-5
lines changed

docs/launch-arbitrum-chain/01-a-gentle-introduction.mdx

Lines changed: 5 additions & 5 deletions
Original file line numberDiff line numberDiff line change
@@ -46,15 +46,15 @@ Arbitrum's protocols address this challenge by offloading some of the Ethereum n
4646
| Feature | Description |
4747
| --------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
4848
| Dedicated throughput | <FloatingHoverModal href="/launch-arbitrum-chain/partials/config-dedicated-throughput.mdx">More info</FloatingHoverModal> |
49-
| EVM+ compatibility | EVM compatability + more languages like Rust programs supported |
50-
| Account abstraction | Account abstraction |
49+
| EVM+ compatibility | <FloatingHoverModal href="/launch-arbitrum-chain/partials/config-evm-compatibility.mdx">EVM compatability</FloatingHoverModal> + <FloatingHoverModal href="/launch-arbitrum-chain/partials/config-other-language-support.mdx">more languages like Rust programs supported</FloatingHoverModal> |
50+
| Account abstraction | <FloatingHoverModal href="/launch-arbitrum-chain/partials/config-account-abstraction.mdx">Account abstraction</FloatingHoverModal> |
5151
| Gas & Tokens | <FloatingHoverModal href="/launch-arbitrum-chain/partials/config-custom-gas-token.mdx">Custom gas token</FloatingHoverModal> or <FloatingHoverModal href="/launch-arbitrum-chain/partials/config-native-eth.mdx">Native ETH</FloatingHoverModal> |
5252
| Data availability | <FloatingHoverModal href="/launch-arbitrum-chain/partials/config-rollup.mdx">Rollup (ETH DA)</FloatingHoverModal>, <FloatingHoverModal href="/launch-arbitrum-chain/partials/config-anytrust.mdx">AnyTrust</FloatingHoverModal>, <FloatingHoverModal href="/launch-arbitrum-chain/partials/config-alt-da.mdx">Alt-DA</FloatingHoverModal> |
5353
| Fast confirmations | <FloatingHoverModal href="/launch-arbitrum-chain/partials/config-fast-withdrawals.mdx">Fast withdrawals</FloatingHoverModal> |
54-
| Security & validation | BoLD, Permissioned validators, Challenge period enforced on L1 |
55-
| Safety Features | Force-inclusion & customizable governance |
54+
| Security & validation | BoLD, Permissioned validators, <FloatingHoverModal href="/launch-arbitrum-chain/partials/config-challenge-period-l1.mdx">Challenge period enforced on L1</FloatingHoverModal> |
55+
| Safety Features | Force-inclusion & <FloatingHoverModal href="/launch-arbitrum-chain/partials/config-customizable-governance.mdx">customizable governance</FloatingHoverModal> |
5656
| MEV | Timeboost |
57-
| Cost | Data posting costs |
57+
| Cost | <FloatingHoverModal href="/launch-arbitrum-chain/partials/config-data-posting-costs.mdx">Data posting costs</FloatingHoverModal> |
5858
| Infrastructure | <FloatingHoverModal href="/launch-arbitrum-chain/partials/config-hardware.mdx">Hardware requirements</FloatingHoverModal> |
5959
| Interop | TBD |
6060

Lines changed: 17 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,17 @@
1+
Arbitrum chains support account abstraction (AA) primarily through `ERC-4337`, a standard that enables smart contract wallets without requiring changes to the underlying Ethereum protocol, and more recently via `EIP-7702` integrated in the ArbOS 40 upgrade. This upgrade allows externally owned accounts (EOAs) to temporarily behave like smart contract accounts, embedding custom logic for transaction validation, execution, and features such as batching operations or gas sponsorship. In practice, `ERC-4337` introduces components like `UserOperations` (pseudo-transactions), `bundlers` (to package and submit them), `paymasters` (for gas fee handling), and an `EntryPoint` contract, making wallets more programmable and user-friendly. `EIP-7702` complements this by adding a new transaction type that delegates EOA execution to smart contract code for a single transaction, enhancing flexibility on Arbitrum's low-cost L2 environment while maintaining compatibility with Ethereum's Pectra upgrade.
2+
3+
## Pros of Account Abstraction on Arbitrum Chains
4+
5+
- **Enhanced User Experience and Onboarding**: Simplifies wallet interactions by eliminating seed phrases, enabling social recovery, multi-factor authentication, and gasless transactions, making Web3 more accessible for non-technical users and reducing barriers on Arbitrum's efficient L2.
6+
- **Improved Security and Flexibility**: Allows programmable logic for custom validation, preventing private key exposure, enabling self-sovereign recovery, and supporting features like fraud monitoring or multi-ownership, which is particularly secure in Arbitrum's Rollup architecture.
7+
- **Transaction Efficiency**: Supports batching multiple actions (e.g., approve and transfer in one atomic call) and gas sponsorship by apps, reducing costs and steps; on Arbitrum, this leverages low fees and fast confirmations for high-volume use cases like DeFi or gaming.
8+
- **Multi-Chain Compatibility**: Maintains the same wallet address across EVM-compatible chains like Arbitrum and others, easing cross-chain interactions and preventing fund loss from address mismatches.
9+
- **No Permanent Changes Required**: With `EIP-7702`, EOAs can "borrow" smart account features temporarily without migration, fostering innovation like composable flows and interoperability with Arbitrum's Stylus MultiVM for Rust-based contracts.
10+
11+
## Cons of Account Abstraction on Arbitrum Chains
12+
13+
- **Infrastructure Complexity**: Relies on additional components like `bundlers`, `paymasters`, and `EntryPoints`, which can fragment wallet experiences, require extra setup, and introduce dependencies on third-party services.
14+
- **Gas Overhead**: Verification of signatures and authorization logic adds minor gas costs, potentially offsetting some efficiency gains, though mitigated on Arbitrum's low-fee environment.
15+
- **Security Risks**: Delegated contracts must be validated to avoid malicious exploits; incomplete abstraction (e.g., `ERC-4337` acts more as a relayer) may not eliminate vulnerabilities like replay attacks if not implemented carefully.
16+
- **Adoption Barriers**: Requires widespread ecosystem support from dApps, wallets, and providers; inconsistent implementations across chains could lead to user confusion or limited interoperability.
17+
- **Not Full Protocol-Level Abstraction**: Depends on higher-layer infrastructure rather than core consensus changes, limiting depth compared to potential future upgrades and potentially increasing reliance on centralized elements like relayers.
Lines changed: 17 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,17 @@
1+
Arbitrum (Orbit) chains, as optimistic Rollups, use a challenge period (typically 6.4 days on mainnet chains like Arbitrum One, though customizable in Orbit chains) during which assertions about the L2 state—such as batched transactions—are posted to Ethereum (L1) and remain open to dispute. This process enables a validator that suspects an invalid state transition or fraudulent batch to initiate a challenge by submitting fraud proofs to L1 smart contracts. The enforcement on L1 involves the entire dispute resolution process occurring on Ethereum mainnet: assertions occur on L1, challenges trigger an interactive protocol, and if no valid challenge succeeds by the end of the period, the assertion is confirmed, enabling finality for actions like asset withdrawals or cross-layer messages. This protocol leverages Ethereum's consensus and security without requiring immediate onchain verification for every L2 transaction, assuming optimism (i.e., batches are presumed correct unless proven otherwise).
2+
3+
## Pros of Having the Challenge Period Enforced on Layer 1
4+
5+
- **High Security and Fraud Deterrence**: Relies on Ethereum's robust consensus and economic incentives (e.g., staking and slashing) to make fraudulent assertions costly and detectable, ensuring only valid states achieve finality while protecting against malicious sequencers or validators.
6+
- **Permissionless Validation**: Anyone can participate as a challenger on L1, promoting decentralization and reducing reliance on centralized entities, with the period providing ample time to respond to threats like DoS attacks or L1 consensus failures.
7+
- **Cost Efficiency for L2 Operations**: Offloads heavy computation to L2 while using L1 only for disputes, enabling lower fees and higher throughput on Arbitrum chains without compromising on Ethereum's security model.
8+
- **Finality Assurance**: Once the period passes without challenges, L2 states achieve L1-equivalent finality, supporting reliable cross-layer interactions and protecting against reversion of confirmed batches.
9+
- **Customizability**: In setups like Arbitrum chains (Orbit), the period can be adjusted (e.g., shorter for lower-risk chains), balancing security with specific use case needs while still enforcing via L1 contracts.
10+
11+
## Cons of having the challenge period enforced on L1
12+
13+
- **Withdrawal and Finality Delays**: Users must wait the entire period (e.g., 6.4 days) for L2-to-L1 exits or messages, leading to poor user experience and capital inefficiency compared to faster alternatives like ZK Rollups.
14+
- **Potential for Extended Disputes**: In case of challenges, resolution can add further delays (up to another period or more), and malicious actors could exploit this to disrupt the chain temporarily.
15+
- **Economic and Operational Overhead**: Challengers need to monitor and stake on L1, which can be resource-intensive; additionally, the fixed length (like 6.4 days) may not be optimal for all batches, potentially making low-value transactions overly secure at the cost of efficiency.
16+
- **Vulnerability to L1 Issues**: Depends on Ethereum's stability; events like network congestion, high gas fees, or consensus failures could hinder timely challenges, though the challenge period's design is to outlast such issues.
17+
- **Lack of Dynamism in Standard Setup**: The uniform application across all assertions ignores variables like sequencer reputation or batch value, leading to unnecessary delays.
Lines changed: 17 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,17 @@
1+
Arbitrum chains (as L2 or L3 solutions settling on Ethereum or Arbitrum), feature customizable governance, which refers to the ability for chain creators to define and implement their own governance protocols tailored to specific project needs. This flexibility contrasts with public chains like Arbitrum One, which is governed by the decentralized Arbitrum DAO using the `$ARB` token for proposals, voting, and upgrades. Custom governance can include setting up unique DAO structures, tokenomics, voting mechanisms (e.g., delegation, proportional weighting), treasury management, and even specialized roles like a Security Council for emergencies, all enforced through smart contracts. It allows for progressive decentralization, where chains start with centralized elements (e.g., a "chain owner" role for upgrades and bug fixes) and evolve toward community-driven models, potentially integrating features like time-delayed proposals for user opt-outs or compatibility with Ethereum upgrades.
2+
3+
## Pros of Customizable Governance on Arbitrum Chains
4+
5+
- **Tailored Flexibility and Experimentation**: Enables projects to customize governance to fit unique use cases, such as optimizing security models, resource management, or execution environments, fostering innovation and scalability in a multi-chain ecosystem.
6+
- **Progressive Decentralization**: Allows gradual transfer of control from initial centralized roles (e.g., chain owners) to community governance via tokens like `$ARB`, reducing centralization risks while supporting necessary upgrades, bug fixes, and Ethereum compatibility.
7+
- **Community Empowerment and Fairness**: Distributes decision-making to diverse stakeholders through airdrops, delegations, and voting, ensuring ecosystem-aligned changes with built-in protections like review periods and asset withdrawal options.
8+
- **Emergency Handling and Security**: Incorporates customizable elements like a Security Council for rapid responses to vulnerabilities, balancing speed with decentralization through elections and constitutional constraints.
9+
- **Evolvability**: The system can self-modify, allowing the DAO to refine governance (e.g., minimizing centralized roles) as technology and risks evolve, promoting long-term adaptability.
10+
11+
## Cons of Customizable Governance on Arbitrum Chains
12+
13+
- **Residual Centralization Risks**: Features like the Security Council introduce permissioned elements that can bypass full community processes, potentially enabling rapid changes without broad input, though mitigated by oversight.
14+
- **Complexity in Implementation**: Customizing governance requires careful design of smart contracts and processes, which could lead to vulnerabilities if not properly audited, and relies on L1 enforcement for upgrades, adding layers of dependency.
15+
- **Initial Power Imbalances**: Early token distributions (e.g., airdrops) might concentrate influence among stakeholders, despite efforts to mitigate Sybil attacks, affecting fairness in nascent chains.
16+
- **Emergency Procedure Vulnerabilities**: Quick actions in crises could risk misuse or lack of transparency, even with requirements for reports and constitutional adherence.
17+
- **Slower Full Decentralization**: The need for progressive steps and community consensus can delay complete decentralization, especially for L2 chains tied to Ethereum's constraints, compared to more rigid but immediate models.

0 commit comments

Comments
 (0)