Channel Factories 通道工廠

Problem with Traditional Channel Opening:

Assume 10 people want to open channels with each other:

  Channels needed: 10 x 9 / 2 = 45 channels
  On-chain TXs needed: 45
  Assume fee per TX: 10,000 sats
  Total cost: 450,000 sats

As participants increase:
  - 20 people: 190 channels -> 1,900,000 sats
  - 100 people: 4,950 channels -> 49,500,000 sats
  - Scalability is very poor!

Channel Factory Solution:

  10 people share one Factory
  On-chain TXs needed: 1 (open) + 1 (close)
  Total cost: ~20,000 sats (huge savings!)

  Factory can create any channel configuration internally
  No additional on-chain transactions needed

Channel Factory Layer Structure:

Layer 1: Funding Transaction

  Inputs: Each participant's UTXO
  Output: N-of-N multisig address

  Alice: 1 BTC --+
  Bob: 1 BTC ----+--> [3-of-3 multisig] = 3 BTC
  Carol: 1 BTC --+

Layer 2: Allocation Transaction

  Spends Layer 1 multisig output
  Creates multiple channel outputs

  3 BTC --> Alice-Bob channel: 1 BTC
        --> Bob-Carol channel: 1 BTC
        --> Alice-Carol channel: 1 BTC

  These channels are "virtual" - not on-chain!

Layer 3: Commitment Transactions

  Each channel has its own commitment TX
  Normal Lightning channel mechanics

Key Points:
  - Only Layer 1 TX goes on-chain
  - Layers 2 and 3 are off-chain state
  - Can force any layer on-chain if needed
  - State updates require all participants' signatures

Factory State Updates:

Scenario: Alice wants to open new channel with Dave

Current State:
  Factory: Alice, Bob, Carol, Dave
  Channels: Alice-Bob, Bob-Carol, Carol-Dave
  Balance allocation: 1 BTC each

Update Flow:
  1. Alice proposes new allocation state
  2. All 4 people sign new allocation TX
  3. Old state is revoked
  4. New state takes effect

New State:
  Channels: Alice-Bob, Bob-Carol, Carol-Dave, Alice-Dave
  Each channel allocated 0.8 BTC (total unchanged)

Challenges:
  - All participants must be online and agree
  - Anyone refuses -> cannot update
  - Coordination cost increases with more participants
  - This is Factory's main limitation

Eltoo + Channel Factory:

Using SIGHASH_ANYPREVOUT:

Update TX #1 --+
Update TX #2 --+--> Any can spend Funding TX
Update TX #3 --+
   ...
Update TX #N ----> Latest state

Settlement TX ----> Final settlement

Flow:
  1. Anyone broadcasts any old Update TX
  2. Others can broadcast newer Update TX
  3. Only latest state takes effect
  4. Settlement TX completes settlement

Benefits:
  - No need to store revocation keys
  - State can update infinitely
  - Offline participants won't be punished
  - Perfect for multi-party protocols

Channel Factory Challenges:

1. Coordination Problem
   - All participants must be online to update
   - One offline -> everyone stuck
   - Malicious participant can block updates
   - Need incentive mechanism for cooperation

2. Exit Cost
   - Single exit requires closing entire Factory
   - Or expensive on-chain split
   - May need "virtual" exit mechanism

3. Capital Efficiency
   - Funds locked in Factory
   - Cannot use for channels outside Factory
   - Need to balance internal/external liquidity

4. Soft Fork Dependency
   - Best implementation needs SIGHASH_ANYPREVOUT
   - Or similar covenant support
   - Not yet activated on Bitcoin

5. Complexity
   - Multi-layer transaction structure
   - Complex state management
   - High implementation and audit difficulty

Possible Mitigations:
  - Small-scale Factory (5-10 people)
  - Trust assumptions (e.g., within enterprise)
  - Incentive mechanisms (deposit/reputation)
  - Backup exit paths