[Mastering the Lightning Network] 8 - 라우팅 (Routing on a Network of Payment Channels)

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

by zNine 2022. 4. 11. 12:44

728x90

라이트닝 네트워크에서의 라우팅에 대한 내용이다.

Routing a Payment
- 게임 스트리밍을 하며 기부금을 받은 Dina의 예를 들어 설명.
- 모든 팬 개개인과 별도의 채널을 유지하지 않고 팁을 받을 수 있고, 팬-to-Dina까지 라우팅 할 자금이 있는 채널이 존재하는 한, 해당 팬으로부터 팁을 받을 수 있음.
- Fan에서 Dina까지의 경로에 있는 노드는 라우팅 노드라고 하는 중개자.
- 라우팅 노드는 라우팅하는 동안 자금을 훔치거나 잃을 수 없으며, 라우팅 수수료를 부과 할 수 있음.
- Onion 라우팅을 사용함으로 중개 노드는 앞뒤 노드만 인식 할 수 있으며, 지불의 발/수신자를 알 수 없음

Routing vs Pathfinding
- 라우팅과 경로찾기를 분리해서 생각하는 것이 중요.
- Pathfinding
  - 발신자 A와 수신자 B를 연결하는, 결제 채널로 구성된 연속적인 경로를 찾고 선택하는 과정.
  - 지불 노드가 다른 노드에서 gossip하는 채널 공지를 수집해 채널 그래프를 조사하여 경로 찾기를 수행.
- Routing
  - 선택한 경로를 통해 A부터 B까지 지불 전달을 시도하는 일련의 상호작용. (경로에서 지불을 보내는 프로세스)
Payment Channel 네트워크 생성
- Alice가 Dina에게 10,000sat를 지불하기를 원함. (직접 연결된 채널X)
- 직접 채널을 열수 있으나, 온체인 수수료가 듬.
- 기존의 열린 채널(Bob과)을 통해 보낼 수 있음.
- 라우팅의 물리적인 예
  - Alice가 Dina에게 금화 10개를 준다고 가정.
  - Dina에게 직접 주는것이 불가능하여, Bob과 Chan에게 도움을 요청하기로 결정.
- A는 B에게 다음과 같은 계약서를 내밀수 있다.
  - 당신이 Chan에게 금화 10개를 전달하면 내가 당신에게 금화 10개를 주겠다.
  - 이 경우, Bob이 계약 위반을 감수 해야함. (전달 여부를 확인 할수 없음)
- 계약 개선
  - 당신이 Chan에게 금화 10개를 전달했음을 나에게 증명할 수 있다면, 금화 10개를 당신에게 주겠다.
  - Bob이 계약에 서명해야 될 이유가 없고, A가 주기로한 금화 10에 대한 계약 위반을 감수해야함.
- 추가 개선
  - 당신이 Chan에게 금화 11개를 전달했다는 것을 증명할 수 있다며 당신에게 12개의 금화를 주겠다.
  - A는 Dina에게 10개, 수수료로 2개를 사용
- 계약 이행에 대한 신뢰문제가 여전히 있기 때문에 모든 당사자는 에스크로 서비스를 사용하기로 결정.
- 교환이 시작될때 A는 12개의 금화를 에스크로에 "lock up" 할수 있고, B가 C에게 11개 전달에 대한 증명 후에만 B에게 지급.
- 영수증(지불 증명)은 D만 아는 비밀형태이며, 다른 사람이 추측하지 못하는 충분히 큰 난수.
- D는 난수 생성기에서 secret value R를 생성하고, 아래와 같은 SHA-256 해시를 포함한 계약서에 commit.
  - H = SHA-256(R
- payment hash
  - payment secret의 hash 값
- payment secret
  - payment를 "unlock" 할수 있는 비밀값
- D는 payment secret의 hash값을 계산해 이메일이나 문자등의 외부 채널을 통해 A에게 보냄.
- A는 payment secret을 모르지만 secret hash를 지불 증거로 사용하도록 계약을 다시 작성
  - 나 A는 당신이 나에게 "057596.."으로 해싱된 유효한 메시지를 보여준다면 12개의 금화를 줄 것 입니다. 이 메세지는 D와 유사한 계약을 맺어야하는 C와 비슷한 계약을 맺음으로써 얻을수 있습니다. 지불을 보장하기 위해 당신이 다음 계약을 설정하기 전까지, 12개의 금화를 신뢰할 수있는에스크로에 제공하겠습니다.
  - B가 C에게 전달하지 않는것(A 보호)과, A가 B에게 지불하지 않는것(B 보호)을 막고, D가 D의 secret hash를 통해 지불 받았음을 보장.
- B과 A가 계약에 동의하고, B이 에스크로로부터 A가 12개의 금화를 예치했다는 메세지를 받은 후, B은 C와 유사한 계약을 협상.
- B는 1개의 금화를 수수료로 받기 때문에, C가 D에게 지불했다는 증거를 보여줄 때만 11개 화를 C에게 전달.
- C는 D에게 10개 지불한 것을 증명하면 수수료를 요구하고, 11개의 금화를 받을 것으로 예상.
- B와 C의 계약 내용
  - 나 B는 당신이 나에게 "057596.."으로 해싱된 유효한 메시지를 보여준다면 11개의 금화를 줄 것 입니다. 이 메세지는 D와 비슷한 계약을 맺음으로써 얻을수 있습니다. 지불을 보장하기 위해 당신이 다음 계약을 설정하기 전까지, 11개의 금화를 신뢰할 수있는에스크로에 제공하겠습니다.
- C는 B가 11개를 예치했다는 메세지를 받으면, D와 유사한 계약을 진행.
  - 나 C는 당신이 나에게 "057596.."으로 해싱된 유효한 메시지를 보여준다면 10개의 금화를 줄 것 이며, 당신이 비밀을 공개한 후 환불 받을 수 있도록 10개 금화를 에스크로에 제공하겠습니다.
- 현재 계약과 예치된 코인은 다음과 같음. A-to-B: 12 coins, B-to-C: 11 coins, C-to-D 10 coins.
- D는 C에게 secret을 보내고, C는 D의 secret이 "057596…"으로 해시되는지 확인하고, 지불 증명을 가지게 되었으므로 에스크로 서비스에게 10개를 D에게 줄것을 지시.
- C는 B에게 secret을 전달. B는 확인하고 11개를 C에게 주라고 지시.
- B는 A에게 secret을 전달. A는 확인하고 12개를 B에게 주라고 지시.
- But, D가 secret 공개를 거부하면? A,B,C가 예치한 금액 상환은?
  - timelock이라하는 기한을 계약에 추가하여 해결.
  - 특정 기한까지 이행하지 않으면 계약이 만료되고 예치한 사람에게 돈을 반환하도록 계약을 수정.
- 다시 수정한 A와 B의 계약
  - B는 계약서에 서명한 후 24시간 이내에 secret을 공개할 수 있고, 기한까지 제공하지 않으면 A의 예치금을 환불되며 계약을 무효화 됩니다.
- B는 24시간 이내에 지불 증명을 받아야하고, C가 결제에 성공하더라도 24시간 이후에 받으면 계약이 무효화되니, C에게는 더 짧은 기한을 주어야 함.
  - C는 계약서에 서명한 후 22시간 이내에 secret을 공개할 수 있고, 기한까지 제공하지 않으면 A의 예치금을 환불되며 계약을 무효화 됩니다.
- C와 D의 계약 역시
  - D는 계약서에 서명한 후 22시간 이내에 secret을 공개할 수 있고, 기한까지 제공하지 않으면 A의 예치금을 환불되며 계약을 무효화 됩니다.
- 일련의 계약을 통해 24시간 후 A부터 D까지 지불이 되거나, 실패하고 모든 사람이 환불 되거나, 성공하거나 실패하거나이며 중도가 없음.
  - 라이트닝 네트워크에서는 이를 "all or nothing" 속성 원자성?이라 부름.
- 에스크로가 신뢰할 수 있고 충실하게 임무를 수행하는 한 과정에서 누구도 코인은 잃지 않음.
- 제3자 에스크로 없이 비트코인 블록체인에서 Bitcoin 스크립트를 사용해 참가자간의 계약을 설정하고,
- fairness(공정성) 프로토콜을 구현하는 smart contract로 에스크로를 대체 할수 있음.
Fairness Protocol (공정성 프로토콜)
- 비트코인의 혁신은 암호화 기본 요소를 사용해 제3자에 대한 신뢰를 신뢰할 수 있는 프로토콜로 대체하는 "Fairness Protocol"을 구현하는 능력.
- Trustless operation (무신뢰 운영)
  - 라우팅 참가자는 서로를 신뢰할 필요가 없음. 부정행위로부터 보호하기 위해 프로토콜을 신뢰함.
- Atomicity (원자성)
  - 지불이 성공하거나 실패하여 모두에게 환불됨. 중개자가 라우팅된 지불을 수집하고 다음 홉으로 전달하지 않을 가능성이 없으며, 속이거나 훔칠수 없음.
- Multihop (멀티홉) 보안
  - 시스템 보안은 단일 지불 채널의 지불과 마찬가지로 라우팅되는 지불에 대해 종단간 확장됨.
HTLC (Hash-Time-Lock-Contract)
- 지불을 잠금 해제하는 비밀로 해시 preimage를 사용. 수신자는 임의의 비밀번호를 생성하고 해시를 계산.
- 해시는 지불 조건이되며, 비밀이 공개되면 모든 참가자는 들어오는 지불을 받을수 있음.
- 위 3 공정성 특성(기능)을 모두 제공.
HTLC를 이용한 팁 사례 다시 보기
- A가 D에게 50,000sat를 라이트닝 지불을 통해 주려고 함.
- D는 라이트닝 인보이스를 생성할 수 있는 사이트가 있다고 가정.
- A는 사이트를 통해 50,000sat를 입력하고, D의 노드는 라이트닝 인보이스 형식으로된 50,000sat에 대한 인보이스를 생성.
- Hash, the first part of HTLC
  - 암호화 해시 알고리즘을 사용해 무작위로 생성된 secret에 적용.
  - secret을 알면 지불을 상환 할수 있으며,
  - 암호화 해시 기능은 secret preimage를 추측하는 것은 불가능하지만, 누구나 해시를 쉽게 확인할 수 있으며, 지불 조건을 풀수있는 preimage는 하나만 있음.
  - 아래 그림에서 A가 인보이스를 받았고, D의 노드는 인보이스 안에 payment hash를 인코딩.
  - D의 secret을 payment preimage라고 함.
  - payment hash(H)는 지불을 D로 라우팅하는데 사용할 수 있는 식별자 역할.
  - payment preimage(R: secret)는 결제가 완료되면 영수증 및 결제 증명서 역할.
  - D의 preimage는 D의 노드에서 생성된 난수이며 이를 R이라고 하며, 아래와 같이 R의 암호화 해시를 계산.
    - H = SHA-256( R )
  - 암호화 해시 함수의 사용은 무신뢰 작업을 보장하는 요소 중 하나이며, 라우팅 노드는 아무도 비밀을 추측하거나 위조할 수 없다는 것을 알기때문에 서로를 신뢰할 필요가 없음.
- HTLC 비트코인 스크립트
  - 위에서 나왔던 A의 계약을 HTLC로 구현하는 방법
    - "0575...f6b3으로 해시하는 유효한 메시지를 표시할 수 있는 경우 Alice는 Bob에게 12개의 금화를 상환합니다 . Bob은 계약서에 서명한 후 24시간 이내에 비밀을 보여줄 수 있습니다. 밥이 이 시간까지 비밀을 제공하지 않으면 앨리스의 보증금은 에스크로 서비스에 의해 환불되고 계약은 무효화됩니다."
    - ```
    # To remote node with revocation key
    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
            # To local node via HTLC-success transaction.
            OP_HASH160 <RIPEMD160(payment_hash)> OP_EQUALVERIFY
            2 OP_SWAP <local_htlcpubkey> 2 OP_CHECKMULTISIG
        OP_ELSE
            # To remote node after timeout.
            OP_DROP <cltv_expiry> OP_CHECKLOCKTIMEVERIFY OP_DROP
            OP_CHECKSIG
        OP_ENDIF
    OP_ENDIF
```
- Payment Preimage and Hash 검증
  - HTLC의 핵심은 수취인이 payment preimage를 알고 있는 경우 지불이 이루어질수 있는 해시.
  - A는 지불을 특정 payment hash로 잠그고, B은 자금을 청구하기 위해 payment preimage를 제시해야 함.
  - 비트코인 시스템은 B의 payment preimage를 해시하고 결과를 A가 잠그기위해 사용한 payment hash와 비교해 올바른지 확인할수 있음.
    - OP_SHA256 <H> OP_EQUAL
  - A는 위의 잠근 스크립트를 <H> 대신 D가 제공한 해시 값 "0575..f6b3"을 사용해 50,200sat를 지불하는 거래 output을 생성할 수 있고,
  - 이 거래에 서명하고 Bob에게 제공 할수 있음.
  - A는 B에게 50,200sat를 제안,
    - OP_SHA256 0575…f6b3 OP_EQUAL
  - B는 D의 secret을 알기 전까지 HTLC를 사용할 수 없고, HTLC를 사용하는 것은 B이 D에 대한 지을 완료하는 것을 조건으로 함.
  - B이 D의 secret을 갖게 되면 B은 secret preimage값 R을 포함하는 잠금해제 스트립트와 함께 이 output을 보낼수 있음.
    - 잠금 스크립트와 결합된 잠금해제 스크립트
    - <R> OP_SHA256 <H> OP_EQUAL
    - 비트코인 스크립트 엔진은 다음과 같이 검증
      
      R은 스택으로 push
      
      OP_SHA256 연산자는 스택에서 R을 꺼내 해싱하고, 결과 H~R~을 스택에 push
      
      OP_EQUAL 연산자는 H와 H~R~을 비교해서 동일하면 결과는 TRUE, 스크립트가 완료되고 지불이 확인됨.
  - A-to-D로 HTLC 확장
    - A는 B에게 50,200sat를 위한 HTLC를 주었고, B는 C에게 50,100sat를 위한 HTLC를 줄 수 있음.
    - B는 C이 secret을 알려주지 않고는 HTLC를 사용할수 없다는 것을 알고 있고,
    - 이것이 HTLC의 종단간 원자성을 보장하기 때문에 매우 중요한 포인트임!!
      
      HTLC를 사용하려면 secret을 공개해야하고, 그러면 다른 사람들도 HTLC를 사용할 수 있음.
      
      모두 HTLC를 사용할수 있거나, 아무도 사용할수 없거나, 원자성!!
    - A의 HTLC는 B가 C에게 준 것보다 100sat가 많기 때문에 지불이 완료되면 B은 라우팅 수수료로 100sat를 받게됨.
    - C는 50,000sat HTLC를 D로 확장, HTLC를 사용하라면 D가 secret을 브로드캐스트 해야하며, C이 B의 HTLC를 사용하는데 사용할 수 있음. (수수료는 100sat)
  - Secret 역전파(Back-Propagating)
    - D가 C으로부터 50,000 HTLC를 받으면 이제 돈을 받을수 있음
      
      이때, D는
      
      이 HTLC를 온체인에 커밋하고 지출거래의 secret을 공개하여 사용할 수 있고, (온체인 수수료 발생)
      
      C에게 secret을 알려 채널 balance를업데이트할 수 있음.
    - D는 C에게 secret을 보내고 D에게 50,000sat의 라이트닝 지불을 반영하도록 채널 balance를 업데이트하는데 동의.
      
      D의 채널 balance가 50,000에서 100,000으로 업데이트되고, C의 잔고가 200,000에서 150,000으로 감소.
    - C는 secret을 알고 D에게 500,000 지불했으며, B의 50,100 HTLC를 받을수 있는 secret이 있기 때문에,
    - B에게 50,100 라이트닝 지불을 반영하도록, 즉 채널 balance를 업데이트 할수 있도록 B에게 secret을 보냄.
    - 이제 B도 secret을 보유, 이것을 사용해 A의 HTLC를 사용할수 있으며, 온체인에 브로드캐스트하는 대신 A-B 채널 balance를 업데이트.
    - A는 secret을 받고, 50,200을 정산, secret은 D가 특정 payment hash에 대해 지불 받았음을 증명하는 영수증으로 사용될수 있음.
    - 최종 채널 balance는 아래와 같이 지불 수수료를 같이 반영.
  - Signature Binding: HTLC 도난 방지
    - 위 내용대로 A,B,C가 HTLC를 생성하면 secret(R)을 아는 사람이 HTLC를 사용할 수 있는 위험이 있음.
    - 처음에 D만 secret을 알고 있고, D는 C가 제공한 HTLC만 사용해야 하지만, 위의 예시대로라면 A, B가 제공한 HTLC를 모두 사용할수 있음.
    - 해결책으로 HTLC 스크립트에 특정 수신자를 바인딩하는 추가 조건이 있어야하고, 수신자의 공개키와 일치하는 서명을 요청해 이를 방지할 수 있음.
    - 지정된 수신자만 해당 공개키와 일치하는 서명을 생성할 수 있으므로.
      
      OP_SHA256 < H > OP_EQUALVERIFY < Bob's Pub > OP_CHECKSIG
      
      위 HTLC를 사용하려면 B의개인키 서명과 R (payment preimage) 가 포함된 잠금 해제 스크립트를 제시해야 함.
      
      < Bob's Sig > < R >
    - 잠금 해제와 잠금 스크립트는 아래와 같이 스크립팅 엔진에 의해 결합 & 검증됨.
      
      < Bob's Sig > < R > OP_SHA256 < H > OP_EQUALVERIFY < Bob's Pub > OP_CHECKSIG
      
      < Bob's Sig > stack 에 push
      
      R 을 stack 에 push
      
      OP_SHA256 이 R을 pop 해서 해시, 결과(H~R~)를 stack 에 push
      
      H 를 stack 에 push
      
      OP_EQUALVERIFY 가 H, H~R~ 을 pop 해서 비교, 다를 경우 실행이 중지되고, 같을 경우 계속,
      
      < Bob's Pub > stack 에 push
      
      OP_CHECKSIG 가 < Bob's Pub >, < Bob's Sig > 를 pop 해서 서명 확인 후 결과 (TRUE or FALSE)를 stack 에 push
  - Hash 최적화
    - OP_SHA256 < H > OP_EQUALVERIFY
    - OP_ 연산자는 바이너리로 인코딩되며, 연산자는 1바이트로 표현됨.
      
      a8 0575965b3b44be51e8057d551c4016d83cb1fba9ea8d6e986447ba33fe69f6b3 88
    - 위와 같이 hash의 길이가 대부분을 차지.
    - 온체인 브로드캐스트 시 바이트수를 최적화 할 필요가 있음.
    - SHA-256 알고리즘에 다른 해시함수를 추가. 즉, 이중 해시를 하는 OP_HASH160 (RIPEMD160 알고리즘 사용)를 제공.
      
      32바이트 --> 20바이트
      
      R = "Dinas secret" H256 = SHA256(R) H256 = 0575965b3b44be51e8057d551c4016d83cb1fba9ea8d6e986447ba33fe69f6b3 H160 = RIPEMD160(H256) H160 = 9e017f6767971ed7cea17f98528d5f5c0ccb2c71 --------------------------------------------------------------------------- OP_HASH160 <H160> OP_EQUALVERIFY --------------------------------------------------------------------------- a9 9e017f6767971ed7cea17f98528d5f5c0ccb2c71 88
      
      위 최적화를 통해 아래와 같은 스크립트가 생성됨.
      
      OP_HASH160 < RIPEMD160(payment_hash) > OP_EQUALVERIFY
  - HTLC Cooperative and Timeout Failure
    - 어떤 채널이 오프라인 되거나, 협력에 실패하면? 결제에 실패하면?
    - 협력 실패
      
      HTLC는 경로의 모든 참가자에 의해 해제되며, balance를 변경하지 않고, commitment tx에서 HTLC output을 제거.
    - Timelock
      
      실패가 발생하면 모든 참가자는 채널 파트너와 협력하여 HTLC를 풀거나,
      
      일방적으로 timelock 환불 tx를 온체인에 브로드캐스트해서 돈을 돌려 받을수 있음.
      
      ... OP_DROP < cltv_expiry > OP_CHECKLOCKTIMEVERIFY OP_DROP OP_CHECKSIG ...
      
      OP_CHECKLOCKTIMEVERIFY 는 줄여서 OP_CLTV
      
      VERITY 접미사는 연산자가 TRUE or FALSE 를 출력 없이 실패하면 중단하거나 성공 시 계속한다는 의미.
      
      OP_CLTV 는 <cltv_expiry> 블록 높이에 도달하지 않은 경우 스크립트가 더 이상 진행되지 않게하는 "게이트키퍼" 역할.
      
      OP_DROP 은 스크립트 스택의 top을 삭제. (이전 스크립트에서 남은 항목이 있을수 있기 때문)
      
      위 스크립트에서, 스택이 정리되면 OP_CHECKSIG가 확인할 수 있는 공개키와 서명이 남아있어야 함.
    - Timelock 감소
      
      HTLC 가 A부터 D까지 확장됨에 따라 HTLC의 각 time-locked 환불 조항 다른 cltv_expiry 값을 같게 됨.
      
      각 홉에 대한 차이를 cltv_expiry_delta라고 하며 각 노드에 의해 설정되고, gossip 프로토콜로 네트워크에 알림.
      
      ex> A는 HTLC에 현재 블록 높이 +500으로 설정. B는 +450, C는 +400 으로 설정.
      
      경합 상태를 방지하고, HTLC 체인이 목적지에서 출발지로(역방향으로) 풀리도록 함.

728x90

저작자표시 비영리 변경금지

'IT.About > 라이트닝 네트워크' 카테고리의 다른 글

[Mastering the Lightning Network] 10 - Onion Routing (0)	2022.04.21
[Mastering the Lightning Network] 9 - 채널 운영과 결제 전달(Channel Operation and Payment Forwarding) (0)	2022.04.12
[Mastering the Lightning Network] 7 - 결제 채널 (Payment Channels) (0)	2021.12.28
[Mastering the Lightning Network] 6 - 라이트닝 네트워크 아키텍쳐 (0)	2021.12.28
[Mastering the Lightning Network] 5 - 라이트닝 네트워크 노드 운영하기 (1)	2021.12.24