nervosnetwork / fiber Goto Github PK

Refer to protocol design v0.4

The points i try to optimize are as follows:

1. Simplify on-chain interactions when unilateral closing channel
   There are 5 stages in design v0.4: opening -> closing -> clearing -> finalized -> transfer-assets. When unilateral closing channel, 4 types of transactions and at least 4 transactions need be constructed and submitted.
   I think it's possible to optimize it to: opening -> closing -> settlement, simplify the interaction flow.

2. Reduce on-chain data usage

Here are the details:

Open channel

- inputs
    - capacity provide cell
        - capacity: 100 CKB
        - lockscript: A
    - capacity provide cell
        - capacity: 200 CKB
        - lockscript: B
    - other cells to provide channel cell capacity and tx fee
- outputs
    - channel cell
        - typescript: PCT
            - args: channel-id
        - lockscript: anyone-can-unlock
        - data
            - fixed
                - pubkey_hashes: [pubkey_hash of A, pubkey_hash of B]
                - closing_period: 1000
            - dynamic
                - state: OPENING
                - version: 0
                - balances: [100 CKB, 200 CKB]
                - remaining_update_times: [5, 5]
    - asset cell
        - capacity: 300 CKB
        - lockscript: PCL

The differences from v0.4:

1. Remove asset field. Because we already have asset cell, i think it's better to get asset-info from asset cell.
2. Change challenge_period and clear_period to closing_period, closing_period >= max(challenge_period, clear_period).
3. Change update_time_limit and update_times to remaining_update_times.

Unilateral close channel

-header_deps
  - header_contains_htlc0_proof_cell
- cell_deps
  - htlc0_proof_cell 
- inputs
    - old channel cell
        - data
            - dynamic
                - state: OPENING
                - version: 0
                - balances: [100 CKB, 200 CKB]
                - remaining_update_times: [5, 5]
- outputs
    - new channel cell
        - data
            - dynamic
                - state: CLOSING
                - version: 100
                - balances: [160 CKB, 100 CKB]
                - htlcs_merkle_root
                - proved_htlcs: 0x01
                - remaining_update_times: [4, 5]
- witnesses
    - UnilateralCloseChannel
        - data
            - channel_id
            - version: 100
            - balances: [50 CKB, 100 CKB]
            - htlcs_merkle_root
                - htlc0_merkle_proof
                  - to: 0
                  - amount: 110 CKB
                  - lock
                  - preimage_timeout: 100
        - signatures
        - submitter_signature of A

The differences from v0.4:

1. Channel_cell_data will not record htlcs-info, but record htlcs_merkle_root and proved_htlcs(in case of duplicated proved_htlc) instead. proved_htlcs records which htlcs have been proved by proof_cell, and the data type is bitmap(e.g. we have 8 htlcs, and htlcs[0, 2] have been proved, then the proved_htlcs is one byte 0x05).
2. When submitting off-chain commitment, participant should include htlcs-prove-data(header_deps, cell_deps), and all-proved-htlcs will be settled directly(pay attention to tx_outputs/channel_cell_data/balances).

Counterparty update channel

-header_deps
 - header_contains_htlc1_proof_cell
- cell_deps
 - htlc1_proof_cell 
- inputs
   - old channel cell
       - data
           - dynamic
               - state: CLOSING
               - version: 100
               - balances: [160 CKB, 100 CKB]
               - htlcs_merkle_root
               - proved_htlcs: 0x01
               - remaining_update_times: [4, 5]
- outputs
   - new channel cell
       - data
           - dynamic
               - state: CLOSING
               - version: 100
               - balances: [160 CKB, 120 CKB]
               - htlcs_merkle_root
               - proved_htlcs: 0x03
               - remaining_update_times: [4, 4]
- witnesses
 - htlc1_merkle_proof
   -  to: 1
   - amount: 20 CKB
   - lock
   - preimage_timeout: 100
 - submitter_signature of B

The differences from v0.4:

1. Participant B submitted htlc1_merkle_proof (Participiant A not submitted for B). And htlc1 was directly settled in this transaction(pay attention to tx_outputs/channel_cell_data/balances).

Settle channel

- inputs
    - assets cell
        - capacity: 300 CKB 
        - lock: PCL
    - old channel cell
        - since: after  closing period 
        - data
            - dynamic
                - state: CLOSING
                - version: 100
                - balances: [160 CKB, 120 CKB]
                - htlcs_merkle_root
                - proved_htlcs: 0x03
                - remaining_update_times: [4, 4]
- outputs
    - asset cell 0
        - capacity: 180 CKB
    - asset cell 1
        - capacity: 120 CKB
- witnesses
  - htlc2_merkle_proof
    -  to: 1
    - amount: 20 CKB
    - lock
    - preimage_timeout: 100

The differences from v0.4:

1. After closing period, participant can settle channel.
2. Unproved_htlcs(should refund) can be settled here. If assets cell are exhausted(all unproved_htlcs have been settled), the channel cell can be destroyed. Otherwise, tx ouputs should keep channel cell for the remaining unsettled unproved_htlcs.

There are 2 reasons that I think a unidirectional channel may be better than bidirectional channel in real life.

1. The amount we pay or receive usually quite differ for a specific role.
2. The online assumption for normal users are too strong. For most users who will run their clients on mobile devices, it's hard to remain online. Though we can involve watchtower, the process will be more complicated.

With a modification from bidirectional channel to unidirectional channel, we'll lose the ability to reuse a channel to do both pay and receive, but what we get are:

• A can create a channel to pay B without interaction with B. A can just create the channel with a layer 1 tx and send the new commitment to B to finish the payment.
• B can withdraw partial balance from the channel without interaction with A, e.g. B got 11 CKB in a channel, he can withdraw 11 CKB with latest commitment(which concludes signature of A and B's balance 11 CKB) by a layer 1 tx.

Then the use case will be:

• Users open their clients(e.g. a mobile phone crypto wallet), they do the payment, then they get offline.
• Receivers (normally service providers) keep online, they receive the commitment with HTTP request, verify the payment and provide their service. They don't even need to put the private key in the backend. An address is enough to receive.

modification details:

• We specify the payer and receiver in the channel data. And only allow the balance flow from payer to receiver.
• Remove the signature for receiver in create channel transactions.
• Receiver can withdraw from channel directly by providing the latest commitment.
• Only payer can close the channel. The challenge process is the same as bidirectional channel since the payer may use a outdated commitment to close.