IT.About/라이트닝 네트워크

[Mastering the Lightning Network] 9 - 채널 운영과 결제 전달(Channel Operation and Payment Forwarding)

zNine 2022. 4. 12. 17:57
728x90
반응형

  • 이 장에서는 지불 채널과 HTLC(해시 시간 잠금 계약)을 다룬다.
    • HTLC가 각 지불 채널에서 어떻게 관리되는지,
    • HTLC가 채널 상태에 어떻게 커밋되는지,
    • 채널 잔액(balace) 업데이트를 위한 정산이 어떻게 되는지
  • 로컬(단일 채널) vs 라우팅(다중 채널)
    • 프로토콜 디자인을 유지하기 위해 단일 홉, 멀티 홈 상관없이 모든 형태의 라이트닝 결제는 HTLC를 사용함
  • .HTLC로 지불 전달 및 약정 업데이트 (Forwarding Payments and Updating Commitments with HTLCs)
    • Alice는 Bob과 Chan을 통해 HTLC로 Dina에게 지불
    • HTLC 와 Commitment Message 흐름
      • 채널 파트너간 HTLC 확약을 위한 메시지 흐름
      •  
    • HTLC로 결제 전달 (Forwarding Payments with HTLCs)
      • Alice 와 Bob 각각 70,000sat 잔액이 있는 지불 채널로 시작
      • 새 거래전 CT
      • HTLC 추가
        • A는 B이 Dina에게 50,200sat 전달에 대한 HTLC를 수락하기를 원한다고 할 때, A는 지불 해시 금액을 포함한 HTLC 정보를 B에게 보내야함.
        • HTLC를 추가하기 위해 A는 update_add_htlc 메세지를 B에게 전송하여 위에서 보았던 flow를 진행하게 된다.
        • updateadd_HTLC 메시지 
          • [channel_id:channel_id]
[u64:id]
[u64:amount_msat]
[sha256:payment_hash]
[u32:cltv_expiry]
[1366*byte:onion_routing_packet]
            • channel_id
              • HTLC를 추가하려는 채널
            • id
              • HTLC 카운터, 0부터 시작해서 증가됨
            • amount_msat
              • 밀리사토시, (이 예에서는 50,200,000 밀리사토시(=50,200 사토시)
            • payment_hash
              • D의 인보이스에서 제공된 결제 해시, H=RIPED160(SHA-256( R ))
            • cltv_expiry
              • HTLC의 만료 시간
            • onion_routing_packet
              • B에게 HTLC를 전달할 위치를 알려주는 onion 암호화 경로.
      • 약정 거래의 HTLC (HTLC in Commitments Transactions) 
        • # Revocation (1)
OP_DUP OP_HASH160 <RIPEMD160(SHA256(revocationpubkey))> OP_EQUAL
OP_IF
    OP_CHECKSIG
OP_ELSE
    <remote_HTLCpubkey> OP_SWAP OP_SIZE 32 OP_EQUAL
    OP_IF
        # Redemption (2)
        OP_HASH160 <RIPEMD160(payment_hash)> OP_EQUALVERIFY
        2 OP_SWAP <local_HTLCpubkey> 2 OP_CHECKMULTISIG
    OP_ELSE
        # Refund (3)
        OP_DROP <cltv_expiry> OP_CHECKLOCKTIMEVERIFY OP_DROP
        OP_CHECKSIG
    OP_ENDIF
OP_ENDIF
        • OP_IF 문의 첫 번째 절은 A가 해지 키를 사용해 금액을 요구할 수 있음 ( CT가 취소될 경우  A는 전체 채널 잔액을 가져오는 패널티 TX에서 이 output 을 요구하는 취소키를 갖게 됨)
        • 두 번째, preimage(payment secret, 여기서는 D의 secret)이 공개될 경우, 이것으로 금액을 요구할 수 있고, 이는 곳 D에게 지불을 전달했음을 의미.
        • 세 번째, HTLC가 만료되는 경우, A에게 환불한다
      • HTLC Output에 대한 새로운 약정 (New Commitment with HTLC Output)
        • B는 A에게 받은 메세지의 내용으로 Commitment#3을 구성.
          • HTLC output에 50,200sat, 그리고 이 output은 A의 잔액에서 나오므로 A의 새 잔액은 19,800sat가 됨.
      • Alice 커밋
        • update_add_htlc를 보낸 직후 채널의 새 상태를 커밋하여 B의 HTLC를 안전하게 추가할 수 있게 한다.
        • A는 새 약정과 그안의 HTLC에 대한 서명과 함께 commit_signed 메세지를 B에게 보낸다. 
          • [channel_id:channel_id]
[signature:signature]
[u16:num_htlcs]
[num_htlcs*signature:htlc_signature]
            • num_htlcs
              • 미결 상태인 HTLC의 수, 여기서는 A가 제공한 1개의 HTLC.
            • htlc_signature
              • HTLC output들을 위한 서명이 담겨있는 서명의 배열.
        • 이제 B은 새로운 서명된 CT이 가지게 되었음
        • Bob은 새 약정을 인정하고, 기존 약정을 취소
          • revoke_and_ack를 보냄 
            • [channel_id:channel_id]
[32*byte:per_commitment_secret]
[point:next_per_commitment_point]
          • A가 B의 이전 약정을 사용할 때, 패널티 TX를 만들기 위한 해지 키를 구성할 수 있도록하는 per_commitment_secret을 보냄
          • B은 A도 이전 약정을 취소했는지 확인해야 함.
          • A 역시 새 HTLC를 포함하는 CT를 구성했지만 아직 B의 서명이 없음.
        • Bot 커밋
          • B이 A에게 서명을 제공(commit_signed)하고, 채널 상태는 A에 새 서명된 약정이 있음이 표시
          • A는 이전 약정을 취소하고, revoke_and_ack를 B에게 보냄. 채널 상태는 A가 이전 커밋을 취소
    • 다중 HTLC (Multiple HTLCs)
      • 어느 시점에서든 A와 B은 단일 채널에 수십, 수백 개의 HTLC를 보유할 수 있으며, 각 HTLC는 추가output으로 제공되고, CT에 추가 됨.
      • 따라서 약정 TX에는 항상 채널 파트너 잔액에 대한 두 개의 output과 HTLC당 하나씩 ouput이 있음.
      • 여러 HTLC 커밋이 동시에 전송될 수 있도록 HTLC 서명을 위한 배열이 있음(commit_signed 메세지)
      • 채널에서 허용되는 최대 HTLC 수는 최대 비트코인 TX 크기에 의해 483개로 설정.
        • 최대값을 보류중인 HTLC에만 해당(충족되거나, 타임아웃/오류로 인한 실패는 CT에서 제거 됨)
    • HTLC 이행 (HTLC Fulfillment)
      • 이제 B과 A는 추가 HTLC output이 있는 새 약정 TX를 갖고 있으며, 채널 업데이트를 위한 주요 과정을 완료하였음.
      • 아직은 A가 B에게 50,200sat를 보냈다는 것이 반영하지 않았음
      • HTLC 전파 (HTLC Propagation)
        • B는 A와 했던 과정과 동일한 방식으로 50,100sat에 대해 Chan과 함께 HTLC를 설정하고, CT를 구성.
        • C는 D와 동일한 작업을 수행. (50,000sat 제공, 커밋, 취소)
        • D는 HTLC의 최종 수신자(payment secret을 아는) 이므로, C와 함께 HTLC를 즉시 수행할 수 있음!
      • Dina는 Chan과 함께 HTLC를 수행
        • D는 update_fulfill_htlc 메세지를 C에게 전송하여 HTLC를 정산할 수 있다.
        • update_fulfill_htlc 
          • [channel_id:channel_id]
[u64:id]
[32*byte:payment_preimage]
            • channle_id
              • HTLC가 커밋된 채널 ID
            • id
              • HTLC의 ID (0 ~ N)
            • payment_preimage
              • 결제가 이루어지고 HTLC를 상환했음을 증명하는 비밀. (D가 A에 대한 인보이스의 지불 해시를 생성하기 위해 해시된 R값)
        • C는 메세지를 받은 즉시 R로 지불 해시가 생성되는지 확인한다.
          • H = RIPEMD160(SHA-256( R ))
        • H가 HTLC의 지불 해시와 일치하면, 이것으로 지불 채널 체인을 따라 Alice에게 전달되어 D에 대한 지불의 일부였던 모든 HTLC가 해결 됨.
      • Bob은 Alice와 함께 HTLC를 완료
        • B이 A에게 update_fulfill_htlc를 보낼때 D가 보낸 payment_preimage가 포함.
        • A는 B에게서 받은 payment_preimage를 확인하고, D가 돈을 받았음을 확인.
        • 이제 A와 B는 CT에서 HTLC를 제거하고, 채널 잔액을 업데이트할 수 있음.
        • HTLC가 제거되고, 잔액이 업데이트된 Commitment#4를 생성.
        • 다음으로 A는 commit_signed를 전송하여 새 약정에 서명하고, B는 revoke_and_ack를 보내 이전 약정을 취소.
        • 마지막으로 B이 commit_signed 메세지로 A의 새 약정에 서명하고, A는revoke_and_ack로 이전 약정을 취소
    • 에러 or 만료로 인한 HTLC 제거
      • HTLC를 이행할 수 없는 경우 동일한 약정 및 취소 프로세스를 사용해 채널 약정에서 제거할 수 있음.
      • update_fulfill_htlc 대신 B은 update_fail_htlc 또는 update_fail_malformed_htlc를 보냄.
      • update_fail_htlc 메시지 
        • [channel_id:channel_id]
[u64:id]
[u16:len]
[len*byte:reason]
      • 위의 프로세스와 거의 동일한 방식으로 진행되며, 두 파트너는 HTLC를 제거하고, 새 CT를 생성하고, 서명, 취소 단계를 거침.
      • 잔액은 HTLC가 없는 상태로 돌아가 A에게 HTLC 값을 환불함.
    • 현지 결제하기 (A가 B에게 커피값을 지불 할 때)
      • A는 B의 상점 페이지에서 커피를 주문
      • B's shop은 지불 해시가 포함된 송장을 display
      • A는 해당 지불 해시에서 HTLC를 구성
      • A는 update_add_htlc를 사용해 B에게 HTLC를 제공
      • A와 B은 약정 CT에 HTLC를 추가하여 약정 및 취소를 교환
      • B은 payment preimage와 함께 update_fulfill_htlc를 A에게 보냄
      • A와 B은 HTLC를 제거하고, 채널 잔액을 업데이트하는 약정 및 취소를 교환
728x90
반응형
저작자표시 비영리 변경금지