From 94ce5da1f4711f961e8517d5d5464f2e695a4053 Mon Sep 17 00:00:00 2001 From: MoD Date: Fri, 29 Nov 2024 18:42:57 +0200 Subject: [PATCH 1/6] State Channels Abstraction Protocol --- ERCS/erc-7824.md | 146 ++++++++++++++++++++++++++++++++++++++++++ ERCS/erc-7825.md | 160 +++++++++++++++++++++++++++++++++++++++++++++++ 2 files changed, 306 insertions(+) create mode 100644 ERCS/erc-7824.md create mode 100644 ERCS/erc-7825.md diff --git a/ERCS/erc-7824.md b/ERCS/erc-7824.md new file mode 100644 index 0000000000..f3630ca3b4 --- /dev/null +++ b/ERCS/erc-7824.md @@ -0,0 +1,146 @@ +--- +eip: 7824 +title: ERC for Exit Format in State Channels +description: A standard for defining outcomes and asset allocations in state channels using the Exit Format. +author: State Channels (@statechannels), Layer-3 Foundation (@layer-3), Louis Bellet (@mod) +discussions-to: https://ethereum-magicians.org/c/ercs/57 (Coming soon) +status: Draft +type: Standards Track +category: ERC +created: 2024-11-22 +--- + +## Abstract + +This ERC defines a standard **Exit Format** for specifying outcomes and asset allocations in state channels. The Exit Format supports diverse token types (native tokens, ERC20, and others) and accommodates both simple and advanced allocation mechanisms. The standard ensures interoperability and clarity in the distribution of locked assets upon channel finalization, particularly in protocols like Nitro. + +## Motivation + +State channels rely on clear and interoperable methods for redistributing locked assets when a channel closes. Current implementations lack a standardized format for defining these outcomes, leading to inefficiencies and integration challenges. This ERC introduces a unified **Exit Format** that can be adopted across state channel implementations, improving compatibility and simplifying on-chain interactions. + +## Specification + +### Key Structs and Enums + +#### `Outcome` +Defines the result of asset redistribution upon channel closure. + +```solidity +struct Outcome { + SingleAssetExit[] singleAssetExits; // Array of asset-specific exits +} +``` + +#### `SingleAssetExit` +Represents allocations for a single asset. + +```solidity +struct SingleAssetExit { + address asset; // Asset type (e.g., native token or ERC20) + bytes assetMetadata; // Metadata for non-standard assets + Allocation[] allocations; // Distribution rules for this asset +} +``` + +#### `Allocation` +Details how an asset is distributed. + +```solidity +struct Allocation { + bytes32 destination; // Address or channel ID receiving the funds + uint256 amount; // Amount to allocate + uint8 allocationType; // Type of allocation (e.g., simple or guarantee) + bytes metadata; // Additional data for advanced allocations +} +``` + +### Allocation Types + +1. **Simple Allocation (`allocationType = 0`)** + Basic asset transfer to external addresses or channels. + +2. **Guarantee Allocation (`allocationType = 1`)** + Conditional transfer based on secondary channels or other criteria. + +```solidity +enum AllocationType { + Simple, + Guarantee +} +``` + +### Advanced Metadata Example: Guarantees + +For `Guarantee` allocations, the `metadata` encodes the following structure: + +```solidity +struct Guarantee { + bytes32 left; // Left participant in the guarantee + bytes32 right; // Right participant in the guarantee +} +``` + +### Example Usage + +#### Example 1: Simple ETH Allocation +"5 ETH to Alice, 5 ETH to Bob." + +```solidity +SingleAssetExit ethExit = SingleAssetExit({ + asset: address(0), // Native token (ETH) + assetMetadata: "", + allocations: [ + Allocation({ + destination: 0x...AliceAddress, + amount: 5 ether, + allocationType: AllocationType.Simple, + metadata: "" + }), + Allocation({ + destination: 0x...BobAddress, + amount: 5 ether, + allocationType: AllocationType.Simple, + metadata: "" + }) + ] +}); +``` + +#### Example 2: Guaranteed Allocation +Guarantee that funds can only be moved to a secondary channel. + +```solidity +Allocation({ + destination: 0x...ChannelID, + amount: 10 ether, + allocationType: AllocationType.Guarantee, + metadata: abi.encode(Guarantee({left: 0x...Alice, right: 0x...Bob})) +}); +``` + +## Rationale + +The Exit Format standardizes asset redistribution logic across state channel implementations, reducing ambiguity and improving interoperability. By supporting both simple and advanced allocations, it addresses a wide range of use cases, from basic payments to complex virtual channel setups. + +## Backwards Compatibility + +This ERC introduces new structs and enums for use in state channel contracts. It is designed to be forward-compatible with existing protocols like Nitro. Implementations not using this standard will need to adapt their on-chain logic to parse Exit Format structures. + +## Test Cases + +1. **Simple Allocation Test** + - Verify that simple allocations transfer the correct amounts to specified destinations. +2. **Guarantee Allocation Test** + - Test reclaiming funds from a guarantee allocation with valid and invalid metadata. +3. **Multi-Asset Exit Test** + - Validate proper handling of multiple asset types in a single `Outcome`. + +## Security Considerations + +- **Metadata Integrity:** Ensure that metadata for advanced allocations (e.g., guarantees) is properly validated. +- **Replay Protection:** Verify that channel IDs and participant signatures prevent unauthorized updates or disputes. +- **Overflow Handling:** Implement safeguards against overflow in allocation calculations. + +## Copyright + +Copyright and related rights waived via [CC0](../LICENSE). diff --git a/ERCS/erc-7825.md b/ERCS/erc-7825.md new file mode 100644 index 0000000000..478f67286e --- /dev/null +++ b/ERCS/erc-7825.md @@ -0,0 +1,160 @@ +--- +eip: 7825 +title: State Channel Standard data types and interfaces +description: A standard for implementing interoperable state channels on Ethereum using the State Channel Protocol, integrated with ERC-4337 for enhanced account abstraction. +author: State Channels (@statechannels), Layer-3 Foundation (@layer-3), Louis Bellet (@mod) +discussions-to: https://ethereum-magicians.org/c/ercs/57 (Coming soon) +status: Draft +type: Standards Track +category: ERC +created: 2024-11-22 +requires: 4337 7824 +--- + +## Abstract + +This ERC standardizes data types for state channels (Also known as Nitro Protocol), enabling efficient off-chain state execution and on-chain dispute resolution. Integrated with ERC-4337 account abstraction, it leverages the capabilities of programmable wallets and plugins to enhance functionality, including custom state channel validators using NitroApps. The proposal defines essential structs and interfaces for Nitro-based state channels, supporting interoperability across Ethereum-based systems. + +## Motivation + +State channels offer a mechanism for off-chain execution, improving scalability and reducing transaction costs. However, existing implementations are not standardized and lack native support for account abstraction. By integrating State Channel Protocol with ERC-4337, this ERC enables advanced wallet functionality, custom plugins for state validation, and seamless interoperability across Ethereum-compatible systems. + +## Specification + +### Structs + +The State Channel Protocol defines the following key structs: + +#### `FixedPart` +Defines immutable parameters of the state channel: + +```solidity +struct FixedPart { + address[] participants; // List of participant addresses + uint48 channelNonce; // Unique channel identifier + address appDefinition; // Address of the application-specific contract + uint48 challengeDuration; // Challenge duration in seconds +} +``` + +#### `VariablePart` +Defines the dynamic parameters of a channel's state: + +```solidity +struct VariablePart { + ExitFormat.SingleAssetExit[] outcome; // Asset distribution upon channel finalization + bytes appData; // Application-specific data + uint48 turnNum; // State version number + bool isFinal; // Flag for instant finalization +} +``` + +#### `SignedVariablePart` +Represents a signed state update: + +```solidity +struct SignedVariablePart { + VariablePart variablePart; + Signature[] sigs; // Participant signatures +} +``` + +#### `Outcome` +Describes asset distribution after channel finalization: + +```solidity +struct Outcome { + SingleAssetExit[] singleAssetExits; +} + +struct SingleAssetExit { + address asset; // Asset type (native or ERC20) + bytes assetMetadata; // Metadata for exotic assets + Allocation[] allocations; // Distribution of funds +} + +struct Allocation { + bytes32 destination; // Destination (channel ID or external address) + uint256 amount; // Allocation amount + uint8 allocationType; // Type (0 = simple, 1 = guarantee) + bytes metadata; // Additional data for guarantees +} +``` + +### Interfaces + +#### `IForceMoveApp` +Defines the application-specific execution rules: + +```solidity +interface IForceMoveApp { + function stateIsSupported( + FixedPart calldata fixedPart, + RecoveredVariablePart[] calldata proof, + RecoveredVariablePart calldata candidate + ) external view returns (bool, string memory); +} +``` + +#### `IAdjudicator` +Handles on-chain dispute resolution: + +```solidity +interface IAdjudicator { + function challenge( + bytes32 channelId, + FixedPart calldata fixedPart, + SignedVariablePart[] calldata proof, + SignedVariablePart calldata candidate + ) external; + + function finalize(bytes32 channelId) external; +} +``` + +### Integration with ERC-4337 + +#### Benefits +1. **Custom Validation Plugins:** State validation logic can be implemented as NitroApps and used as account abstraction plugins, enabling diverse use cases (e.g., payment channels, virtual channels). +2. **Programmable Wallets:** Wallets using ERC-4337 can interact directly with Nitro-based state channels. +3. **Interoperability:** Unified standard for account abstraction and state channels across Ethereum. + +#### Example +```solidity +contract NitroAccount is IAccount { + function validateUserOp( + UserOperation calldata userOp, + bytes32 userOpHash, + uint256 missingAccountFunds + ) external override returns (uint256) { + // Validate state updates using NitroApp logic + } +} +``` + +## Rationale + +This ERC builds on the modularity of Nitro Protocol and the flexibility of ERC-4337, creating a unified standard for state channel implementations. By decoupling execution rules from core protocol logic, it ensures adaptability for various applications while maintaining a secure and efficient dispute resolution process. + +## Backwards Compatibility + +This ERC depends on ERC-4337 and assumes its availability for account abstraction functionality. Legacy state channel implementations without Nitro compatibility will require adaptation. + +## Test Cases + +1. **Channel Initialization:** + - Deploy a channel with two participants and verify the `FixedPart` parameters. +2. **State Update:** + - Submit a valid `SignedVariablePart` and ensure it is accepted by the `IAdjudicator`. +3. **Dispute Resolution:** + - Simulate a challenge and verify proper execution of the `finalize` function. + +## Security Considerations + +- **Signature Validation:** Ensure that all state updates are cryptographically signed by the required participants. +- **Replay Protection:** Use unique `channelNonce` values to prevent replay attacks. +- **Application Logic Safety:** Carefully audit application-specific logic to avoid vulnerabilities. + +## Copyright + +Copyright and related rights waived via [CC0](../LICENSE). From 4a9ed5446e3cb647e5c8be47900477ea99a38e14 Mon Sep 17 00:00:00 2001 From: Max Pushkarov Date: Thu, 12 Dec 2024 19:17:37 +0200 Subject: [PATCH 2/6] fix: resolve errors and warnings from linters --- ERCS/erc-7824.md | 6 +++--- ERCS/erc-7825.md | 8 ++++---- 2 files changed, 7 insertions(+), 7 deletions(-) diff --git a/ERCS/erc-7824.md b/ERCS/erc-7824.md index f3630ca3b4..d62c90b7e3 100644 --- a/ERCS/erc-7824.md +++ b/ERCS/erc-7824.md @@ -1,9 +1,9 @@ --- eip: 7824 title: ERC for Exit Format in State Channels -description: A standard for defining outcomes and asset allocations in state channels using the Exit Format. +description: Outcomes and asset allocations definition in state channels using the Exit Format. author: State Channels (@statechannels), Layer-3 Foundation (@layer-3), Louis Bellet (@mod) -discussions-to: https://ethereum-magicians.org/c/ercs/57 (Coming soon) +discussions-to: https://ethereum-magicians.org/c/ercs/57 status: Draft type: Standards Track category: ERC @@ -12,7 +12,7 @@ created: 2024-11-22 ## Abstract -This ERC defines a standard **Exit Format** for specifying outcomes and asset allocations in state channels. The Exit Format supports diverse token types (native tokens, ERC20, and others) and accommodates both simple and advanced allocation mechanisms. The standard ensures interoperability and clarity in the distribution of locked assets upon channel finalization, particularly in protocols like Nitro. +This ERC defines a standard **Exit Format** for specifying outcomes and asset allocations in state channels. The Exit Format supports diverse token types (native tokens, ERC-20, and others) and accommodates both simple and advanced allocation mechanisms. The standard ensures interoperability and clarity in the distribution of locked assets upon channel finalization, particularly in protocols like Nitro. ## Motivation diff --git a/ERCS/erc-7825.md b/ERCS/erc-7825.md index 478f67286e..0dbce7417b 100644 --- a/ERCS/erc-7825.md +++ b/ERCS/erc-7825.md @@ -1,19 +1,19 @@ --- eip: 7825 title: State Channel Standard data types and interfaces -description: A standard for implementing interoperable state channels on Ethereum using the State Channel Protocol, integrated with ERC-4337 for enhanced account abstraction. +description: Interoperable state channels on Ethereum using State Channel Protocol, integrated with ERC-4337 for enhanced account abstraction. author: State Channels (@statechannels), Layer-3 Foundation (@layer-3), Louis Bellet (@mod) -discussions-to: https://ethereum-magicians.org/c/ercs/57 (Coming soon) +discussions-to: https://ethereum-magicians.org/c/ercs/57 status: Draft type: Standards Track category: ERC created: 2024-11-22 -requires: 4337 7824 +requires: 4337, 7824 --- ## Abstract -This ERC standardizes data types for state channels (Also known as Nitro Protocol), enabling efficient off-chain state execution and on-chain dispute resolution. Integrated with ERC-4337 account abstraction, it leverages the capabilities of programmable wallets and plugins to enhance functionality, including custom state channel validators using NitroApps. The proposal defines essential structs and interfaces for Nitro-based state channels, supporting interoperability across Ethereum-based systems. +This ERC standardizes data types for state channels (Also known as Nitro Protocol), enabling efficient off-chain state execution and on-chain dispute resolution. Integrated with [ERC-4337](./eip-4337.md) account abstraction, it leverages the capabilities of programmable wallets and plugins to enhance functionality, including custom state channel validators using NitroApps. The proposal defines essential structs and interfaces for Nitro-based state channels, supporting interoperability across Ethereum-based systems. ## Motivation From e3b85444d56aa736dff2b510c43a2925b9214516 Mon Sep 17 00:00:00 2001 From: Danylo Patsora Date: Mon, 13 Jan 2025 22:50:59 +0200 Subject: [PATCH 3/6] fix: titles & description --- ERCS/erc-7824.md | 2 +- ERCS/{erc-7825.md => erc-7842.md} | 6 +++--- 2 files changed, 4 insertions(+), 4 deletions(-) rename ERCS/{erc-7825.md => erc-7842.md} (96%) diff --git a/ERCS/erc-7824.md b/ERCS/erc-7824.md index d62c90b7e3..9e245e2651 100644 --- a/ERCS/erc-7824.md +++ b/ERCS/erc-7824.md @@ -1,6 +1,6 @@ --- eip: 7824 -title: ERC for Exit Format in State Channels +title: Exit Format in State Channels description: Outcomes and asset allocations definition in state channels using the Exit Format. author: State Channels (@statechannels), Layer-3 Foundation (@layer-3), Louis Bellet (@mod) discussions-to: https://ethereum-magicians.org/c/ercs/57 diff --git a/ERCS/erc-7825.md b/ERCS/erc-7842.md similarity index 96% rename from ERCS/erc-7825.md rename to ERCS/erc-7842.md index 0dbce7417b..3302a8320f 100644 --- a/ERCS/erc-7825.md +++ b/ERCS/erc-7842.md @@ -1,7 +1,7 @@ --- -eip: 7825 -title: State Channel Standard data types and interfaces -description: Interoperable state channels on Ethereum using State Channel Protocol, integrated with ERC-4337 for enhanced account abstraction. +eip: 7842 +title: State Channel Data Types & Interfaces +description: Interoperable state channels using State Channel Protocol, integrated with ERC-4337 for enhanced account abstraction. author: State Channels (@statechannels), Layer-3 Foundation (@layer-3), Louis Bellet (@mod) discussions-to: https://ethereum-magicians.org/c/ercs/57 status: Draft From 175b0d20ce03c9adaec5032a771d18a5d14df488 Mon Sep 17 00:00:00 2001 From: Danylo Patsora Date: Tue, 14 Jan 2025 13:35:18 +0200 Subject: [PATCH 4/6] remove test cases --- ERCS/erc-7824.md | 9 --------- ERCS/erc-7842.md | 16 ++++------------ 2 files changed, 4 insertions(+), 21 deletions(-) diff --git a/ERCS/erc-7824.md b/ERCS/erc-7824.md index 9e245e2651..26108ee5a1 100644 --- a/ERCS/erc-7824.md +++ b/ERCS/erc-7824.md @@ -126,15 +126,6 @@ The Exit Format standardizes asset redistribution logic across state channel imp This ERC introduces new structs and enums for use in state channel contracts. It is designed to be forward-compatible with existing protocols like Nitro. Implementations not using this standard will need to adapt their on-chain logic to parse Exit Format structures. -## Test Cases - -1. **Simple Allocation Test** - - Verify that simple allocations transfer the correct amounts to specified destinations. -2. **Guarantee Allocation Test** - - Test reclaiming funds from a guarantee allocation with valid and invalid metadata. -3. **Multi-Asset Exit Test** - - Validate proper handling of multiple asset types in a single `Outcome`. - ## Security Considerations - **Metadata Integrity:** Ensure that metadata for advanced allocations (e.g., guarantees) is properly validated. diff --git a/ERCS/erc-7842.md b/ERCS/erc-7842.md index 3302a8320f..c56783478b 100644 --- a/ERCS/erc-7842.md +++ b/ERCS/erc-7842.md @@ -112,6 +112,10 @@ interface IAdjudicator { } ``` +## Rationale + +This ERC builds on the modularity of Nitro Protocol and the flexibility of ERC-4337, creating a unified standard for state channel implementations. By decoupling execution rules from core protocol logic, it ensures adaptability for various applications while maintaining a secure and efficient dispute resolution process. + ### Integration with ERC-4337 #### Benefits @@ -132,22 +136,10 @@ contract NitroAccount is IAccount { } ``` -## Rationale - -This ERC builds on the modularity of Nitro Protocol and the flexibility of ERC-4337, creating a unified standard for state channel implementations. By decoupling execution rules from core protocol logic, it ensures adaptability for various applications while maintaining a secure and efficient dispute resolution process. - ## Backwards Compatibility This ERC depends on ERC-4337 and assumes its availability for account abstraction functionality. Legacy state channel implementations without Nitro compatibility will require adaptation. -## Test Cases - -1. **Channel Initialization:** - - Deploy a channel with two participants and verify the `FixedPart` parameters. -2. **State Update:** - - Submit a valid `SignedVariablePart` and ensure it is accepted by the `IAdjudicator`. -3. **Dispute Resolution:** - - Simulate a challenge and verify proper execution of the `finalize` function. ## Security Considerations From e5b6887708d2248271d3afb7ad9423af6e93ebb1 Mon Sep 17 00:00:00 2001 From: Sazonov Nikita <35502225+nksazonov@users.noreply.github.com> Date: Tue, 14 Jan 2025 15:36:34 +0200 Subject: [PATCH 5/6] feat(erc7824): explain ExitFormat in abstract --- ERCS/erc-7824.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/ERCS/erc-7824.md b/ERCS/erc-7824.md index 26108ee5a1..0c13711a99 100644 --- a/ERCS/erc-7824.md +++ b/ERCS/erc-7824.md @@ -12,7 +12,7 @@ created: 2024-11-22 ## Abstract -This ERC defines a standard **Exit Format** for specifying outcomes and asset allocations in state channels. The Exit Format supports diverse token types (native tokens, ERC-20, and others) and accommodates both simple and advanced allocation mechanisms. The standard ensures interoperability and clarity in the distribution of locked assets upon channel finalization, particularly in protocols like Nitro. +This ERC defines a standard (named **Exit Format**) for specifying outcomes, asset allocations and metadata in state channels. The Exit Format supports diverse token types (native tokens, ERC-20, and others) and accommodates both simple and advanced allocation mechanisms. The standard ensures interoperability and clarity in the distribution of locked assets upon channel finalization, particularly in protocols like Nitro. ## Motivation From 91042450e1a347331e8294f1fc16416365439bc6 Mon Sep 17 00:00:00 2001 From: Max Pushkarov Date: Tue, 14 Jan 2025 17:22:32 +0200 Subject: [PATCH 6/6] refactor: rewrite Motivationa and Rationale sections --- ERCS/erc-7824.md | 25 ++++++++++++++++++++---- ERCS/erc-7842.md | 51 +++++++++++++++++++++++++++++++++++++++++++++++- 2 files changed, 71 insertions(+), 5 deletions(-) diff --git a/ERCS/erc-7824.md b/ERCS/erc-7824.md index 0c13711a99..814ead487a 100644 --- a/ERCS/erc-7824.md +++ b/ERCS/erc-7824.md @@ -16,7 +16,9 @@ This ERC defines a standard (named **Exit Format**) for specifying outcomes, ass ## Motivation -State channels rely on clear and interoperable methods for redistributing locked assets when a channel closes. Current implementations lack a standardized format for defining these outcomes, leading to inefficiencies and integration challenges. This ERC introduces a unified **Exit Format** that can be adopted across state channel implementations, improving compatibility and simplifying on-chain interactions. +State channels require a standardized and interoperable mechanism for redistributing locked assets upon closure. Without a common format, current implementations face inefficiencies and integration challenges, hindering the broader adoption of state channels in diverse applications. + +The proposed Exit Format addresses these issues by unifying asset redistribution logic across state channel implementations. This standard provides a clear framework for defining outcomes, supporting both simple transfers and advanced allocation scenarios such as conditional guarantees. By adopting this format, developers can ensure compatibility between different state channel protocols, streamline on-chain interactions, and reduce ambiguity in asset distribution. ## Specification @@ -56,10 +58,10 @@ struct Allocation { ### Allocation Types -1. **Simple Allocation (`allocationType = 0`)** +1. **Simple Allocation (`allocationType = 0`)** Basic asset transfer to external addresses or channels. -2. **Guarantee Allocation (`allocationType = 1`)** +2. **Guarantee Allocation (`allocationType = 1`)** Conditional transfer based on secondary channels or other criteria. ```solidity @@ -120,7 +122,22 @@ Allocation({ ## Rationale -The Exit Format standardizes asset redistribution logic across state channel implementations, reducing ambiguity and improving interoperability. By supporting both simple and advanced allocations, it addresses a wide range of use cases, from basic payments to complex virtual channel setups. +The technical choices in the **Exit Format** were driven by the need for a standardized and interoperable mechanism to handle asset redistributions in state channels. Below is an explanation of the rationale behind these choices: + +### Supporting Multiple Allocation Types + +- **Simple Allocations:** A basic mechanism (`allocationType = 0`) supports straightforward transfers of assets, ensuring compatibility with the majority of use cases in state channels. +- **Guarantee Allocations:** By introducing conditional transfers (`allocationType = 1`), the format accommodates more complex scenarios like guarantees or escrow mechanisms, which are vital for advanced state channel designs. + +### Emphasis on Extensibility and Forward Compatibility + +The use of metadata fields and modular allocation types ensures that the standard can evolve to accommodate new use cases and innovations in state channels without breaking existing implementations. Encoding advanced logic (e.g., guarantees) in the `metadata` field decouples the standard from specific allocation mechanisms, enabling developers to define custom logic while maintaining compliance with the Exit Format. + +Including metadata explicitly requires developers to validate the integrity and correctness of additional fields, ensuring security in advanced allocation mechanisms. Explicit attention to replay protection and overflow handling aligns with best practices in Ethereum development, minimizing the risk of security vulnerabilities. + +### Compatibility with Existing Protocols + +The Exit Format builds upon the asset allocation mechanisms in existing protocols like Nitro, ensuring backward compatibility. This minimizes the effort required to integrate the standard into current implementations and facilitates interoperability across different state channel frameworks. ## Backwards Compatibility diff --git a/ERCS/erc-7842.md b/ERCS/erc-7842.md index c56783478b..3936f4158b 100644 --- a/ERCS/erc-7842.md +++ b/ERCS/erc-7842.md @@ -17,7 +17,56 @@ This ERC standardizes data types for state channels (Also known as Nitro Protoco ## Motivation -State channels offer a mechanism for off-chain execution, improving scalability and reducing transaction costs. However, existing implementations are not standardized and lack native support for account abstraction. By integrating State Channel Protocol with ERC-4337, this ERC enables advanced wallet functionality, custom plugins for state validation, and seamless interoperability across Ethereum-compatible systems. +State channels offer a mechanism for off-chain execution, improving scalability and reducing transaction costs. However, existing implementations are not standardized and lack native support for account abstraction. By integrating the State Channel Protocol with ERC-4337, this proposal enables advanced wallet functionality, custom plugins for state validation, and seamless interoperability across Ethereum-compatible systems. + +Despite their promise, state channels face several challenges that have limited their broader adoption. These include scalability constraints, usability challenges, economic inefficiencies, and difficulties in integrating with existing infrastructure. This proposal addresses these challenges and provides a comprehensive solution for state channel networks. Specifically, it aims to: + +1. Overcoming scalability limitations. +Distributed ledgers are constrained by on-chain transaction throughput, high gas costs, and latency. By enabling transactions to occur off-chain while retaining the security of on-chain enforcement, state channels offer a pathway to scalability. This protocol further enhances scalability by enabling virtual channels, allowing participants to transact privately and directly, even when they do not share a direct channel. + +2. Simplifying state channel usability. +Naive state channel designs restrict interactions to the participants who opened the channel and limit capital exchange to predefined amounts. These constraints complicate the user experience and limit the broader applicability of state channels. This proposal simplifies usability by introducing flexible, modular rules that adapt to a wide range of applications, from simple payments to complex state transitions. + +3. Reducing economic overhead. +Recovering funds in existing state channel implementations often involves substantial gas costs, especially in adversarial scenarios. This proposal minimizes these costs through efficient dispute resolution mechanisms and careful allocation of assets via virtual channels. By doing so, the protocol ensures that the cost of recovering funds is economically viable for all participants. + +This proposal aims to provide a comprehensive solution for state channel networks. By integrating with ERC-4337, it leverages the power of account abstraction to enhance wallet functionality and enable custom state validation logic. This approach ensures interoperability across Ethereum-based systems and sets the foundation for a more scalable and user-friendly blockchain ecosystem. + +## Rationale + +The rationale for the technical choices in this protocol stems from the need to balance scalability, security, and usability while addressing the inherent limitations of naive state channel designs. Each decision reflects a trade-off that optimizes performance for practical use cases. + +### Efficiency through Off-Chain Transactions + +On-chain operations in distributed ledgers are costly and slow, primarily due to gas fees and block confirmation delays. To mitigate this, the protocol minimizes on-chain interactions by enabling off-chain state updates. This approach amortizes the cost of opening and closing transactions over an effectively unlimited number of off-chain operations, reducing the load on the underlying ledger. + +### Virtual Channels for Indirect Transactions + +Direct state channels restrict interactions to pre-established connections, which is infeasible in large, dynamic networks. By introducing virtual channels, the protocol enables indirect transactions between two participants through shared intermediaries. This eliminates the need for intermediaries to participate in every transaction, thereby enhancing scalability and reducing network costs. + +### Cryptographic Commitments + +To maintain trust in an adversarial environment, all state updates must be verifiable and binding. The protocol achieves this by requiring participants to sign each state cryptographically. Only the latest supported state, validated by a support proof, is considered valid. This ensures tamper-proof and transparent state updates. + +### Challenge and Adjudication Mechanism + +Disputes are an inevitable part of decentralized systems. The adjudicator contract resolves disputes by enforcing the latest supported state while allowing a timeout period for participants to present counterproofs. This design ensures that disputes are resolved securely without locking funds indefinitely, striking a balance between user experience and asset protection. + +### Guarantee Mechanisms for Asset Allocation + +Virtual channels rely on funds allocated from pre-existing ledger channels to ensure liquidity during transactions. Guarantees reserve specific amounts for these channels, allowing funds to be allocated safely without risking intermediary assets. This approach ensures that funds are both secure and available for transactions. + +### Economic Security + +For the protocol to be viable, the cost of dispute resolution must remain significantly lower than the value of the protected assets. By optimizing gas usage and leveraging efficient data structures like support proofs, the protocol reduces the economic burden of disputes, ensuring its practicality across various applications. + +### Modular and Application-Specific Design + +Different use cases demand flexibility in how channels manage assets and state updates. To support diverse applications, the protocol defines customizable rules that can be tailored to specific scenarios, ranging from simple payment channels to complex application logic like game rules or incentive systems. + +### Improved Network Efficiency + +Naive state channel designs scale poorly as participant numbers grow, leading to quadratic increases in network costs and reduced responsiveness. The protocol addresses this by using intermediaries strategically and optimizing for minimal communication rounds, achieving O(1) rounds in special cases. This improves scalability and reduces operational overhead. By prioritizing simplicity and practical utility, this protocol achieves a robust and scalable solution for state channel networks. It not only addresses the shortcomings of earlier approaches but also sets the foundation for further innovation in off-chain scaling solutions. ## Specification