Jason Dev
About
라이트닝 네트워크 이해하기
published: 2023-11-26
bitcoin
lightning network
htlc
commitment transaction
payment channel

라이트닝 네트워크(Lightning Network)는 비트코인의 확장성 문제를 해결하기 위해 개발된, 레이어 2 결제 프로토콜이다. 이 네트워크는 블록체인 상에서 모든 거래를 처리하는 대신, 사용자 간에 개설된 지불 채널을 통해 수많은 작은 거래들을 실시간으로 처리하고, 최종적으로 만들어진 잔고만 블록체인에 기록하는 방식으로 작동한다.

라이트닝 네트워크 활용 예

두 노드 간에 거래가 빈번한 경우

바이낸스와 업비트 두 거래소 간에는 하루에도 수많은 비트코인 전송이 발생한다. 업비트에서 바이낸스로 보내는 경우도 많겠지만 그 반대의 경우도 많을 것으로 예상된다. 비트코인을 전송할 때마다 트랜잭션 수수료가 발생하는데 각 거래소 입장에서는 이 비용이 아쉬울 수 있다. 수기로 각자 장부를 작성하는 방법도 있겠지만 거래되는 금액에 비해 서로 간의 신뢰가 부족하다. 이럴 때 라이트닝 네트워크를 사용한다면 서로 신뢰하지 않고도 매우 낮은 수수료로 비트코인을 전송할 수 있다.

만약 업비트에서 바이낸스로 보내는 경우와 그 반대의 경우가 균등하게 분포되어 있다면 효율은 극대화된다. 이상적으로는 수개월 혹은 수년 간 비트코인 온체인 수수료를 거의 지불하지 않고 채널을 유지할 수도 있다. 만약 어느 한 쪽에서 전송하는 금액이 다른 경우에 비해 훨씬 많다면 효율은 떨어지겠지만 전체적인 비용은 여전히 라이트닝 네트워크를 사용하는 편이 나을 수 있다.

작은 거래가 많이 발생하는 경우

카페는 많은 고객들로부터 입금을 받는다. 몇 천원짜리 입금을 위해 비트코인 트랜잭션 수수료를 추가로 지불할 고객은 거의 없다. 라이트닝 네트워크를 사용한다면 몇 천원짜리 거래도 부담 없이 전송할 수 있다. 각 고객이 카페와 (아래에서 살펴볼)지불 채널을 개설할 필요는 없다. 지불 채널이 직접적으로 연결되어 있지 않더라도 다른 노드를 통해 서로 연결되는 경로가 있다면 두 노드 간에 비트코인을 전송할 수 있다.

카페에 비트코인 결제를 도입하기 위해 반드시 필요한 요소 중에 하나는 빠른 속도다. 커피 결제를 위해 10분을 기다리는 것은 누구도 납득할 수 없다. 라이트닝 네트워크를 사용한다면 단 몇 초 만에 결제를 완료할 수 있다.

라이트닝 네트워크의 주요 개념

지불(payment) 채널

두 노드는 지불 채널을 개설할 수 있다. 세 개 이상의 노드가 하나의 지불 채널을 개설할 수는 없다. 기술적으로 지불 채널은 두 노드 간의 2-of-2 다중 서명으로 만들어진다. 이를 위해 주로 P2WSH 형식이 사용된다. 이렇게 만들어진 P2WSH 주소의 비트코인은 두 노드가 모두 서명해야 사용될 수 있다.

만약 하나의 노드가 연락 두절이 되더라도 다른 노드는 정해진 시간을 기다린 후 자금을 사용할 수 있다. 하나의 노드가 사라졌다고 하더라도 채널을 개설할 때 서명을 받아놓은 Commitment 트랜잭션이 있기 때문이다.

Commitment 트랜잭션

라이트닝 네트워크의 기술적인 부분을 이해하기 위해서는 라이트닝 네트워크가 만들어내는 트랜잭션을 이해해야 한다. 라이트닝 네트워크는 모든 거래를 비트코인 온체인에 기록하지 않으면서도 어떻게 신뢰가 필요 없는(trustless) 시스템을 만들었을까? 그것은 각 노드가 원한다면 언제라도 비트코인 온체인에 전송할 수 있는 서명된 트랜잭션을 들고 있기 때문이다. 잔고가 정확하게 명시되어 있는 서명된 트랜잭션을 들고 있기 때문에 상대 노드를 신뢰하지 않고도 거래를 할 수 있다. 이렇게 잔고 정보를 담고 있는 트랜잭션을 Commitment 트랜잭션이라고 한다.

라이트닝 네트워크에서 각 노드는 자신과 연결된 모든 채널에 대한 Commitment 트랜잭션을 들고 있다. Commitment 트랜잭션에는 두 노드 간의 잔고 정보가 들어 있으며 각 노드는 각자 자신만의 Commitment 트랜잭션을 들고 있다. 예를 들어, A-B 채널에서는 A와 B가 각각 Commitment 트랜잭션을 들고 있다. 거래가 진행되면서 수정되는 잔고를 반영하기 위해 Commitment 트랜잭션도 계속해서 수정된다. 거짓이 없다면 A와 B의 Commitment 트랜잭션에는 같은 잔고 정보가 담기게 된다.

A, B 두 노드가 각각 100sats(사토시)씩 납입해서 채널을 개설했다고 해보자. 2-of-2 다중 서명으로 이루어진 P2WSH 주소에 200sats가 입금되어 있다. A가 들고 있는 Commitment 트랜잭션은 다음과 같다.

  • 입력: P2WSH 주소의 200sats
  • 출력1: A에게 100sats
    • 일정 잠금 시간(to_self_delay) 동안 사용할 수 없다
    • 만약 B가 철회 서명(revocation_sig)을 들고 있다면 B가 자금을 가져갈 수 있다
  • 출력2: B에게 100sats
    • 조건 없이 즉시 사용할 수 있다

A가 이 내용으로 B에게 서명해달라고 했을 때 B 입장에서는 서명을 안할 이유가 없다. B는 즉시 자금을 사용할 수 있으므로 A에게 불리한 내용이기 때문이다.

철회 서명 덕분에 상대방이 나쁜 의도로 오래된 Commitment 트랜잭션을 제출했을 때 대응할 수 있다. 만약 현재 잔고가 A는 50sats, B는 150sats인데, A가 이전 Commitment 트랜잭션(A는 100sats, B는 100sats)을 제출했다면 B는 철회 서명을 사용해서 200sats 모두를 가져갈 수 있다. 새로운 Commitment 트랜잭션을 만드는 과정에서 항상 이전 Commitment 트랜잭션에 대한 철회 서명을 서로 주고 받는다.

B가 들고 있는 Commitment 트랜잭션도 A/B 순서만 다를 뿐 같은 내용으로 되어있다.

위 출력1의 스크립트 내용은 아래와 같다.

OP_IF
// 철회 서명이 있다면 자금을 사용할 수 있다.
<revocation_pubkey>
OP_ELSE
// 일정 시간 후 A가 자금을 사용할 수 있다.
`to_self_delay`
OP_CHECKSEQUENCEVERIFY
OP_DROP
<pubkey_of_A>
OP_ENDIF
OP_CHECKSIG

자금이 이동하는 과정에서 Commitment 트랜잭션이 수정 되는데 이때 HTLC가 사용된다.

HTLC(Hashed Time Locked Contract)

A-B, B-C 채널이 있다고 가정해보자. A와 C 사이에는 직접적인 채널이 없다. A가 C에게 비트코인을 보내기 위해서는 B의 도움이 필요하다. B는 약간의 수수료를 받고 A를 도와 C에게 비트코인을 전달할 수 있다.

A가 C에게 비트코인을 전달하기 위해서는 연결된 경로를 찾는 과정이 필요하다. 이 글에서는 그에대한 내용을 다루지는 않는다. 한 가지 중요한 사실은 중간 경로에 있는 노드들은 비트코인이 누구에게서 누구에게로 전달되는지 모른다는 것이다. 라이트닝 네트워크의 높은 privacy 수준을 엿볼 수 있는 부분이다.

A가 C에게 자금을 보내기 위해서는 두 채널의 Commitment 트랜잭션을 수정해야 한다. 두 채널 모두 양쪽 노드의 잔고가 100sats라고 가정하고, A가 C에게 50sats를 보내는 상황을 살펴보자.

먼저 C는 자신만 알고 있는 preimage라는 것을 생성한다. 그리고 preimage의 해시값인 preimage_hash를 A에게 전달한다.

HTLC of A-B

A는 B에게 다음과 같은 내용으로 수정된 Commitment 트랜잭션에 서명해달라고 요청한다.

  • 입력: P2WSH 주소의 200sats
  • 출력 1: A에게 49sats
    • 일정 잠금 시간(to_self_delay) 동안 사용할 수 없다
    • 만약 B가 철회 서명(revocation_sig)을 들고 있다면 B가 자금을 가져갈 수 있다
  • 출력 2: B에게 100sats
    • 조건 없이 즉시 사용할 수 있다
  • 출력 3: 만약 B가 preimage를 제시하면 B가 51sats를 가져간다
    • 만약 B가 철회 서명(revocation_sig)을 들고 있다면 B가 자금을 가져간다
    • 만약 일정 잠금 시간이 지나면 A가 자금을 가져간다

A는 수수료로 1sats를 사용하고 있다.

출력 2에서 기존 B의 잔고는 변함이 없다. B는 preimage가 무엇인지는 모르지만 만약 알게된다면 51sats를 얻게되니 B 입장에서는 서명을 안할 이유가 없다.

여기서 출력 3이 HTLC 출력이다. A는 일정 잠금 시간 동안 자신의 자금을 잠그고 그 시간 안에 B가 제대로 일을 해준다면 C에게는 50sats를 보내고 B에게는 수수료로 1sats를 준다.

B도 비슷한 내용으로 A에게 서명을 받는다. 아래는 B의 수정된 Commitment 트랜잭션에서 HTLC 출력(출력 3)의 스크립트 내용이다.

// 철회 서명을 제시하면 자금을 사용할 수 있다.
OP_DUP OP_HASH160 <RIPEMD160(SHA256(revocation_pubkey))> OP_EQUAL
OP_IF
OP_CHECKSIG
OP_ELSE
<remote_htlc_pubkey> OP_SWAP OP_SIZE 32 OP_EQUAL
OP_IF
// 만약 preimage를 제시하면 자금을 사용할 수 있다.
OP_HASH160 <RIPEMD160(preimage_hash)> OP_EQUALVERIFY
2 OP_SWAP <local_htlc_pubkey> 2 OP_CHECKMULTISIG
OP_ELSE
// 만약 일정 시간 동안 preimage를 제시하지 못하면 A가 자금을 사용한다.
OP_DROP <cltv_expiry> OP_CHECKLOCKTIMEVERIFY OP_DROP
OP_CHECKSIG
OP_ENDIF
OP_ENDIF

HTLC of B-C

B가 수수료 1sats를 벌기 위해서는 preimage를 알아내야 한다. 이를 위해 B는 C와의 거래를 시작한다.

B는 C에게 다음과 같은 내용으로 수정된 Commitment 트랜잭션에 서명해달라고 요청한다.

  • 입력: P2WSH 주소의 200sats
  • 출력 1: B에게 50sats
    • 일정 잠금 시간(to_self_delay) 동안 사용할 수 없다
    • 만약 C가 철회 서명(revocation_sig)을 들고 있다면 C가 자금을 가져갈 수 있다
  • 출력 2: C에게 100sats
    • 조건 없이 즉시 사용할 수 있다
  • 출력 3: preimage를 제시한 사람에게 50sats
    • 만약 C가 철회 서명(revocation_sig)을 들고 있다면 C가 자금을 가져간다
    • 만약 일정 잠금 시간이 지나면 B가 자금을 가져간다

C는 preimage를 들고 있으므로 서명을 안할 이유가 없다. C도 비슷한 내용으로 B에게 서명을 받는다.

C가 preimage를 B에게 전송하면서 B-C 사이의 HTLC 거래는 마무리 단계에 접어든다. B와 C는 Commitment 트랜잭션에서 HTLC 출력을 제거하고 출력1과 출력2의 잔고를 다음과 같이 수정한다. 아래는 B의 수정된 Commitment 트랜잭션이다.

  • 입력: P2WSH 주소의 200sats
  • 출력1: B에게 50sats
    • 일정 잠금 시간(to_self_delay) 동안 사용할 수 없다
    • 만약 C가 철회 서명(revocation_sig)을 들고 있다면 C가 자금을 가져갈 수 있다
  • 출력2: C에게 150sats
    • 조건 없이 즉시 사용할 수 있다

이렇게 수정된 Commitment 트랜잭션에 B와 C가 모두 서명하면 B-C 사이의 HTLC 거래는 마무리된다. 결과적으로 B-C 지불 채널의 잔고가 수정됐다.

이제 B도 preimage 값을 획득했다. B가 preimage를 A에게 전송하면서 A-B 사이의 HTLC 거래는 마무리 단계에 접어든다. A와 B는 Commitment 트랜잭션에서 HTLC 출력을 제거하고 출력1과 출력2의 잔고를 다음과 같이 수정한다. 아래는 A의 수정된 Commitment 트랜잭션이다.

  • 입력: P2WSH 주소의 200sats
  • 출력1: A에게 49sats
    • 일정 잠금 시간(to_self_delay) 동안 사용할 수 없다
    • 만약 B가 철회 서명(revocation_sig)을 들고 있다면 B가 자금을 가져갈 수 있다
  • 출력2: B에게 151sats
    • 조건 없이 즉시 사용할 수 있다

A가 C에서 50sats를 보내기 전 잔고는 A는 100sats, B는 200sats, C는 100sats 였다. 50sats 전송 완료 후 잔고는 A는 49sats, B는 201sats, C는 150sats가 됐다.

채널 종료 및 기타 예외 상황

채널 종료는 크게 협력적 종료(cooperative close)와 비협력적 종료로 나눌 수 있다. 협력적인 종료 상황에서는 양쪽이 현재 잔고에 동의한 후 (Commitment 트랜잭션에 있는)시간 잠금과 같은 조건 없이 즉시 자금을 가져갈 수 있는 새로운 트랜잭션을 생성한다. 채널 생성 시 만든 P2WSH 주소를 입력으로 하면서 현재 잔고에 해당하는 비트코인을 각 출력에 넣는다.

한 쪽 노드가 연락이 안되거나 비협조적인 경우 다른 쪽 노드는 비협력적 종료를 할 수 있다. 누구든 채널을 종료하고 싶다면 현재 들고 있는 Commitment 트랜잭션을 비트코인 온체인에 전송하면 된다. 단, 시간 잠금 만큼 대기해야 한다는 제약이 있다.

만약 A가 자신에게 100sats가 할당된 오래된 Commitment 트랜잭션을 비트코인 온체인에 전송했다면, B는 미리 받아놓은 철회 서명을 이용해서 A-B 채널에 있는 모든 자금(200sats)을 가져갈 수 있다.

만약 C가 자신만 50sats를 받으면 된다는 생각으로 preimage를 B에게 보내지 않는다면 어떻게 될까? C는 50sats를 받기 위해 HTLC가 포함된 Commitment 트랜잭션을 온체인에 전송한다. 트랜잭션이 블록에 포함되면 곧바로 HTLC 출력을 입력으로 사용하는 트랜잭션을 전송한다. 이때 이 트랜잭션에는 preimage가 포함되며 B도 preimage를 확인하게 된다. B는 획득한 preimage를 이용해서 A와의 HTLC 처리를 마무리 할 수 있다. (만약 C가 preimage가 포함된 트랜잭션을 빨리 전송하지 않으면 cltv_expiry에 의해 B가 자금을 사용할 수 있다)

라이트닝 네트워크의 특징

지금까지 살펴본 내용으로 라이트닝 네트워크의 특징을 정리하면 다음과 같다.

  • 즉시 결제: 라이트닝 네트워크는 거의 실시간으로 거래를 처리한다. 일단 채널이 설정되면 사용자들은 인터넷을 통해 데이터가 전송되는 속도 만큼 빠르게 결제할 수 있다.
  • 중개자 없는 직접 거래: 중개자 없이 당사자 간에 직접 거래를 처리한다.
  • 다중 경로 결제: 라이트닝 네트워크의 사용자는 여러 채널을 통해 거래를 보낼 수 있다. 이것은 사용자가 네트워크 내의 다른 사용자와 직접 채널을 갖고 있지 않아도 거래를 보낼 수 있게 한다.
  • 블록체인 부담 감소: 라이트닝 네트워크 내의 모든 결제는 블록체인에 기록되지 않고, 오직 채널을 열고 닫는 등의 일부 거래만 블록체인에 기록된다.
  • 무기한 채널 유지: 두 당사자가 협력한다면 채널은 무기한으로 열릴 수 있다. 이는 블록체인에 대한 부담을 줄이고 채널을 열고 닫는 비용을 더 긴 기간에 걸쳐 분산시킬 수 있다.
  • 빠른 협력적 종료: 양 당사자가 협력한다면 채널은 즉시 종료될 수 있다.
  • 라우팅 정보 암호화: 결제 라우팅 정보는 중간 노드가 출발지와 목적지를 알지 못하게 중첩 암호화된다.
  • 낮은 수수료: 거래 수수료가 낮아서 비트코인 트랜잭션 수수료 보다 작은 금액의 거래도 부담이 없다.

댓글 삭제 시 메일 주소가 필요합니다