[Mastering the Lightning Network] 7 - 결제 채널 (Payment Channels)

7장에서는 결제를 위한 채널을 열고/닫기, 채널 상태 머신에 대한 내용을 설명한다.

 

라이트닝 네트워크에서의 라우팅 개념 없이, 1 대 1 채널 파트너간의 거래를 예로 설명한다.

• 라이트닝 네트워크는 Bitcoin 시스템을 사용하는 다른 방법
  • 라이트닝 네트워크는 "Layer-2 비트코인 프로토콜" 이며,
  • "비트코인을 사용하는 더 스마트한 방법" 또는 "비트코인 위에 있는 응용프로그램", 즉 SW 이다.

• 비트코인 소유권과 통제 (라이트닝 네트워크에서 사용하는 비트코인의 기능)
  • 비트코인을 "소유" 한다는 것은, 사용되지 않은 트랜젝션의 ouput이 있는 비트코인 주소의 개인키를 알고 있음을 의미한다.
  • 다중서명 주소
    • 지출에 대한 서명에 여러 개인 키가 필요한 경우에 사용됨.
    • K-of-N 방식, N 서명자 중 K개의 개인키를 이용해 금액을 사용 가능하다는 내용이며,
    • 예를 들어 1-of-10 이면, 10명이 동일한 개인 키의 사본을 가지고 있고, 그들중 누구나 독립적 사용가능.
  • 비 독립적 공동 소유권
    • LN에서 사용되는 2-of-2 방식에서는 서명자 모두 상대방의 서명을 받지 않고는 자금을 사용 할수 없다.
  • 잠김 및 사용 불가능한 비트코인 방지
    • 사고나 실수로 두 서명자 중 한명이 서명하지 않을 경우 자금을 못쓰게 되는 경우를 방지하는 것이 필요.

 

• 노드 연결
  • 노드의 개인/공개 키
    • LN의 모든 노드는 노드 공개키로 식별. (유니크한 주소라고 생각하면 될듯)
    • 노드 초기화 시 root 개인 키가 생성되어 노드의 지갑에 저장되고 (비공개, 비공유)
    • 개인키로 노드의 ID 역할을 하는 공개키를 파생.
  • 노드 네트워크 주소
    • 노드의 전체 주소(식별자)는 "공개키+아래 두 방식의 네트워주소 중 하나" 의 형태로 나타낸다.
    • TCP/IP
      • IPv4 + TCP 포트 번호
    • TCP/Tor
      • Tor "onion" 주소 + TCP 포트 번호
  • 노드 식별자
    • 공개키@Address:Port
    • TCP/IP:Port 사용 예
      • 02a1cebfacb2674143b5ad0df3c22c609e935f7bc0ebe801f37b8e9023d45ea7b8@172.16.235.20:9735
    • Onion 주소@Port 사용 예
      • 377f8e1c795255b4eb92e0fbeb120a7f52580ad8a4f13ec97f83b6dad697d6fe8@bvn23vo4ekj6hbp63aah5hja3cwgoyhrbv23ky4b542qsxdp4iudqlqd.onion:9735
  • Direct Peer로 연결하기 위해서 위의 노드 식별자 주소가 필요하다.

 

• 결제 채널 구축
  • 채널 관리를 위한 Peer 프로토콜은 BOLT #2에 정의되어 있다.
    • https://github.com/lightningnetwork/lightning-rfc/blob/master/02-peer-protocol.md
  • 채널 설정 메시지 flow

    • 

    • open_channel 메세지
      • Bob의 노드에 지불 채널 요청.
      • Bob이 확인 후 수락하거나 거부할 수 있는 채널 설정값 정보 포함.

      • [chain_hash:chain_hash]
        [32*byte:temporary_channel_id]
        [u64:funding_satoshis]
        [u64:push_msat]
        [u64:dust_limit_satoshis]
        [u64:max_htlc_value_in_flight_msat]
        [u64:channel_reserve_satoshis]
        [u64:htlc_minimum_msat]
        [u32:feerate_per_kw]
        [u16:to_self_delay]
        [u16:max_accepted_htlcs]
        [point:funding_pubkey]
        [point:revocation_basepoint]
        [point:payment_basepoint]
        [point:delayed_payment_basepoint]
        [point:htlc_basepoint]
        [point:first_per_commitment_point]
        [byte:channel_flags]
        [open_channel_tlvs:tlvs]

      • chain_hash
        • 채널이 사용되는 블록체인(예: 메인넷), 해당 블록체인 초기블록의 해시.
      • funding_satoshis
        • 채널 자금 (채널의 capacity)
      • channel_reserve_satoshis
        • 최소 잔액
      • push_msat
        • 채널 자금 조달 시 파트너에게 즉시 "push"하는 옵션 금액. 파트너에게 돈을 선물한다는 의미.
      • to_self_delay
        • 프로토콜에 대한 매우 중요한 보안 매개변수.
        • open_channel 메시지 내의 이 값은 응답자의 커밋 TX과 accept_channel 개시자의 커밋 TX에서 사용 됨.
        • 상대방이 커밋 TX에서 일방적으로 자금을 청구하기 위해 기다려야 하는 시간 (Locktime)을 각 당사자가 표현할 수 있도록 함.
        • B가 일방적으로 채널 close 시 정의된 시간 동안 자금에 손을 대지 않겠다고 약속하는 것.
      • funding_pubkey
        • 채널을 고정 할  2-of-2 다중서명에 사용 될 공개 키
      • x_basepoint
        • 약정, 취소, HTLC, 종료 트랜젝션에서 하위 키 파생하는데 사용되는 마스터 키.
    • accept_channel 메세지

      • [32*byte:temporary_channel_id]
        [u64:dust_limit_satoshis]
        [u64:max_htlc_value_in_flight_msat]
        [u64:channel_reserve_satoshis]
        [u64:htlc_minimum_msat]
        [u32:minimum_depth]
        [u16:to_self_delay]
        [u16:max_accepted_htlcs]
        [point:funding_pubkey]
        [point:revocation_basepoint]
        [point:payment_basepoint]
        [point:delayed_payment_basepoint]
        [point:htlc_basepoint]
        [point:first_per_commitment_point]
        [accept_channel_tlvs:tlvs]

      • funding_pubkey
        • 채널을 고정 할  2-of-2 다중서명에 사용 될 공개 키
      • minimum_depth
        • B의 노드가 확인 후 채널을 열고, 그리고 사용할 준비가 완료된 상태라고 예상하는 펀딩 TX에 대한 블록체인 검증 횟수.
      • A는 accept_channel 수신후 채널 구성에 필요한 정보를 갖추게 되며, 2-of-2 multisig 주소를 생성해야 한다.
    • Multisignature Address 생성
      • 펀딩 TX은 funding_satoshis를 A와 B의 funding_pubkey로 구성된 2-of-2 다중서명 output으로 보냄.
      • A node는 다음과 같이 multisignature script를 구성.
        • 2 <_'A_funding_pubkey'_> <_'B_funding_pubkey'_> 2 CHECKMULTISIG
        • funding 키의 순서는 합의된 정렬방식에 따라 배치되며, 이에 따라 동일한 FT output이 구성됨을 보장.
      • 스크립트는 P2WSH(Pay-to-Withness-Script-Hash) 비트코인 주소로  인코딩 됨.
        • 예> bc1q89ju02heg32yrqdrnqghe6132wek25p6sv6e564znvrvez7tq5zqt4dn02
    • Funding Transation (FT) 구성

      • 

      • A의 200,000 사토시 중 140,000을 funding하고 60,000을 A의 지갑으로 보내는 transation을 구성한다고 가정.
      • A는 이 거래를 바로 브로드캐스트 하지 않음. (B의 서명 없이는 회수 할 방법이 없기 때문)
    • Refund Transaction (RT) 구성
      • A는 FT을 구성한 직후 2-of-2 multisig를 A의 지갑으로 보내는 RT을 구성.

      • 

    • funding_created 메세지

      • [32*byte:temporary_channel_id]
        [sha256:funding_txid]
        [u16:funding_output_index]
        [signature:signature]

      • funding_txid
        • 펀딩 TX의 txID, 채널 확인되면 채널 ID를 생성하는데 사용.
      • funding_output_index
        • B은 transaction의 어떤 ouput이 2-of-2 다중서명 output인지 알고 있고, 이는 채널 ID를 구성하는데에도 사용됨.
    • A는 A의 서명에 해당하는 funding_pubkey(다중 서명에 사용한)를 보냄.
      • B가 자신의 커밋 TX을 생성하는데에도 필요 하므로..
    • funding_signed 메세지

      • [channel_id:channel_id]
        [signature:signature]

      • B는 FT의 ID와 output Index를 알고 있으며, channel_id는 아래와 같이 만들어 진다.
      • channel_id
        • funding TxID 하위 2바이트와 funding output index를 XOR 하여 만들어진 funding UTXO의 32바이트 표현.
      • signature
        • B는 refund tx을 위해 그의 2-of-2 multisig로 구성된 funding_pubkey 기반의 서명을 A에게 보내야함.
        1. B는 funding_signed 메세를 구성하여 A에게 보냄.
    • Broadcast Funding Transaction
      • A는 B가 보낸 서명이 유효한지 확인하고, 완료가 되면 refund tx까지 안전하게 생성되었다고 판단,
      • 펀딩 TX을 브로드캐스트하고, A와 B는 Bitcoin 블록체인에서 minimum_depth(ex: 6개 검증)을 기다림.
    • funding_locked 메시지
      • 펀딩 TX의 검증을 확인 후 funding_locked 메세지를 보내고 채널을 사용할 준비가 완료되었다고 판단함.

 

• 채널로 지불하기
  • 초기에는 채널을 open한 A에게 모든 사토시가 있고, A->B로만 지불이 가능.
  • A의 140,000 사토시 중, B에게 70,000 사토시를 지불하는 거래를 가정.
  • 펀딩 거래에서 할당한 잔액(Balance)을 A와 B가 분할하게 된다.

    • 

    • Commitment #0 - 첫 번째 CT은 A가 구성한 RT.
    • Commitment #1 - A와 B에게 70,000 사토시를 output 으로설정.
    • 각 CT은 언제든 네트워크에 브로드캐스트하여 채널을 닫는데 사용 가능하다.

 

• 이전 커밋 TX로의 부정행위 방지
  • 파트너가 최종 거래된 TX가 아닌 이전에 사용된 TX를 블록체인에 브로드캐스트 하는 것을 물리적으로 막을수는 없다.
  • 브로드캐스트하는 것을 그대로두면 해당 TX의 output으로 검증이 끝나면 상대방은 금전적 피해를 받게되고, 이를 방지할 매커니즘이 필요하다.
  • Revoking old 커밋 TX, 즉 이전 TX를 취소하는 방식이 사용된다.
    • 이는 패널티 매커니즘이며, 채널 파트너간 새로운 TX를 생성하기전 이전 TX를 취소하고, 취소에 대한 합의로써 취소를 증명할 수 있는 비밀키를 교환한다.
    • 이 비밀키를 사용하면 해당 TX내의 모든 자금은 부정행위를 시도한 상대방 파트너가 모든 자금을 가져가게 되는데,
    • 만약 파트너 한쪽이 이전 TX를 브로드캐스트해서 사기를 치려고한다면, 상대방은 이를 알아차리고 패널티 TX를 구성하고, 여기에 취소키를 포함하여 브로드캐스트하게 되면,
    • 비트코인 블록체인 시스템에 의해 패널티 TX가 받아들여지게 되고, 모든 자금은 사기꾼 피해자에게 돌아가는 매커니즘이다.
  • 위에서 언급된 매커니즘이 작동되기 위해서는 아래 두가지 장치들이 필요하다.
  • Delayed spending

    • 

       
    • 커밋 TX 보유 당사자에 대한 지불은 timelock 이 설정되는 반면, 상대방에 대한 지불은 즉시 사용가능.
    • 브로드캐스팅한 당사자에게 지연시간을 통해 자금을 잠그고, 상대방이 철회할 시간을 갖도록하는 매커니즘.
    • A의 tx에서 A의 60,000은 432 블록 동안 사용불가, B의 tx에서 B의 80,000이 사용 불가.
    • timelock은 채널 구성 메세지의 to_self_delay 필드에 의해 설정되며, 채널 파트너간의 협상에 의해 결정.
  • Revocation keys

    • 

       
    • 이전 커밋 TX에 대한 패널티 옵션을 해제하는데 사용.
    • 이전 TX를 사용 할 경우 채널 파트너가 패널티 tx을 생성하여 채널 자금을 모두 가져갈수 있음.
    • to_local output이 스크립트에 의해 두가지 소비 조건이 있음.
      • timelock 후 자체적으로 소비하거나, revocation key로 원격에서 즉시 소비하거나.

 

• Commitment Transaction (약정 거래)
  • 비대칭, 지연, 취소 가능한 약정에 대한 비트코인 스크립트.

  • OP_IF
        # Penalty transaction
        <revocationpubkey>
    OP_ELSE
        <to_self_delay>
        OP_CHECKSEQUENCEVERIFY
        OP_DROP
        <local_delayedpubkey>
    OP_ENDIF
    OP_CHECKSIG

  • <revocationpubkey>에 sign 할 수 있는 모든 사람이 output을 사용할 수 있도록 함.
    • remote 파트너 일방적으로 sign 할수 없고,
    • 한쪽이 의도적으로 패널티 tx를 할수 없도록 채널 각 파트너들의 정보를 기반으로 생성되며,
    • 대칭 및 비대칭 암호화를 사용.
    • 각 측은 초기 채널 협상메시지에 first_per_commitment_point, revocation_basepoint를 보냄.
    • revocation_basepoint는 채널 수명동안 static한 값이며, first_per_commitment_point를 기반으로 채널이 새로운 상태가 됨.
    • 위 정보를 가지고 각 채널 state를 위한 revocationpubkey가 다음 작업을 통해 파생된다.

    • revocationpubkey = revocation_basepoint * sha256(revocation_basepoint || per_commitment_point) + per_commitment_point * sha256(per_commitment_point || revocation_basepoint)

    • per_commitment_secret(per_commitment_point의 개인키)가 상대 파트너에게 공개되면,
    • 자체적으로 다음 작업 통해 revocationpubkey에 대한 개인키를 파생할 수 있음.

    • revocation_priv = (revocationbase_priv * sha256(revocation_basepoint || per_commitment_point)) + (per_commitment_secret * sha256(per_commitment_point || revocation_basepoint)) mod N

    • revocationpubkey = G*(revocationbase_priv * sha256(revocation_basepoint || per_commitment_point) + G*(per_commitment_secret * sha256(per_commitment_point || revocation_basepoint))
                                 = revocation_basepoint * sha256(revocation_basepoint || per_commitment_point) + per_commitment_point * sha256(per_commitment_point || revocation_basepoint))

    • revocationbase_priv는 revocation_priv와per_commitment_secret 모두 알고 있는 당사자에 의해서만 파생될수 있고, revocationpubkey에 서명하는데 사용될수 있다.
    • 이 작은 트릭이 라이트닝 네트워크에서 사용되는 공개키 기반 revocation 시스템을 안전하게 만듬.
  • <to_self_delay>에 의해 특정 블록 동안 잠기고, 지연 후 <local_delayedpubkey>에 sign 가능한 사람이 사용 가능 함.
  • to_remote output은 <remote_pubkey>에 대한 Pay-to-Withness-Publick-Key-Hash(P2WPKH)이며, 여기에 sigh할 수 있는 소유자가 사용 가능.

 

• Advancing the Channel State (채널의 거래 상태 진행)
  • A와 B는 commit_signed 및 revoke_and_ack 메세지를 교환하면서 채널 상태를 진행시킨다.
  • 채널 상태에 대한 업데이트가 있을때 파트너 중 한쪽에서 보낼수 있고, 상대는 revoke_and_ack로 응하여 이전 commit을 취소하고, 새것을 승인.
  • commit_signed 메시지

    • [channel_id:channel_id]
      [signature:signature]
      [u16:num_htlcs]
      [num_htlcs*signature:htlc_signature]

    • channel_id - 채널 식별자
    • signature - 새 약정에 대한 서명
    • num_htlcs - 해당 commitment에서 업데이트된 HTLC 수
    • htlc_signature - 업데이트 서명
  • A의 commit_signed 메세지에는 B에게 새 커밋 TX에 필요한 서명(2-of-2의 A의 파트)를 제공.
  • revoke_and_ack 메시지

    • [channel_id:channel_id]
      [32*byte:per_commitment_secret]
      [point:next_per_commitment_point]

    • channel_id
    • per_commitment_secret - 이전 TX 대한 revocation key를 생성하여, 취소하는데 사용.
    • next_per_commitment_secret - 나중에 취소할수 있도록, 새 commitment를 대한 revocation_pubkey를 빌드하는데 사용.

 

• Revoking and Recommitment (취소와 재약정)
  • A는 B에게 새 거래를 만들수있는 수단을 제공했고,
  • B는 A에게 이전 거래를 사용하지 않겠다고 약속한, 이전 거래를 취소 할수 있는 secret을 제공했다.
  • A는 이전 거래를 취소할 수있는 revocation key가 있는 경우에만 새 거래를 신뢰할 수 있고,
  • B의 관점에서 A에게 자신을 처벌할 수 있는 키를 제공하게 되었다.
  • B는 revoce_and_ack에 per_commitment_secret을 실어 A에게 제공했고,
  • 이 것으로 A는 패널티를 행사할 수 있는, 이전 거래에 대한 revocation signing key 구성하는데 사용한다.

 

• Cheating and Penalty (부정행위와 패널티)
  • 실제 A와 B 모두 부정 행위를 모니터링 해야함.
  • 블록체인에서 확인된 거래가 최근의 것인지 확인하고, 이전 거래이면 즉시 penalty tx를 구성하고 브로드캐스트 해야함.
  • penalty tx는 to_local 및 to_remote output을 모두 사용하여 채널 닫고, 모든 잔액을 부정행위자의 상대 파트너인 자신에게 보냄.

  • 

  • A가 Commitment #1을 브로드캐스트(부정행위를) 하기로 결정.

    • 

    • A는 432 블럭후에 70,000 sat 사용 가능하며, B가 3일 동안 모르기를 기도한다.
  • B의 모니터링에 의해 발각되고, B는 penalty tx를 구성하고 이를 브로드캐스트!

    • 

    • B는 A가 보낸 per_commitment_secret를 가지고 있고, revocation_pubkey에 대한 서명을 구성.
    • A가 432블럭을 기다리는 동안 B는 두 output을 즉시 사용 가능하게 된다.
    • B의 penalty tx에 의해 140,000 sat 모두 B의 지갑으로 직행.

 

• Closing the Channel (Cooperative Close) - 합의에 의한 채널 닫기

  • 

  • closing tx을 이용해 각 파트너들의 지값에 즉시 잔액을 지불하게 된다.
  • shutdown 메시지

    • [channel_id:channel_id]
      [u16:len]
      [len*byte:scriptpubkey]

    • channel_id
    • len
      • 1. 채널 파트너들이 잔액을 받게되는 지갑의 스크립트 길이
    • scriptpubkey
      • 대상 지값의 비트코인 스크립트. 표준 비트코인 주소 형식 (P2PKH, P2SH, P2WPKH, P2WSH, 등)
    • A가 B에게 보내는 메세지에 A의 비트코인 스크립트를 지정.
    • B는 이에 동의 할 시, 자신의 비트코인 스크립트를 실어 shutdown 메세지를 A에게 보냄.
  • closing_signed 메시지

    • [channel_id:channel_id]
      [u64:fee_satoshis]
      [signature:signature]

    • channel_id
    • fee_satoshis
      • 온체인 거래 수수료
    • signature
      • closing tx에 대한 보낸이의 서명
    • A가 보낸 메세지를 받은 B는자신의 서명된 메세지로 응답.
    • 수수료에 대해 협의가 되지 않을 경우 두 파트너가 동의 할때까지 메세지를 주고 받을 수 있음.
    • A가 제안한 것과 동일한 비용으로 closing_signed 메세지를 받으면 협상이 완료.
    • A는 closing tx에 서명하고 브로드캐스트하고 채널은 close.

  • 

  • closing tx는 A와 B가 동의한 마지막 거래와 유사 하지만, timelock과 패널티 revocation key가 없다.
  • 즉, 블록체인에서 검증이 끝난 후 바로 자금을 사용가능 하다.
  • 협의된 closing tx에 사용되는 주소는 각 채널에 대해 생성되지만, 채널간 협의하여 주소를 고정 할 수도 있음.