라이트닝 네트워크 시리즈 (2)
Indirect Payment via Multi-Hop HTLC
최준우(Joon-Woo Choi), 정희원(Heewon Chung)
Seoul Nat’l Univ. Blockchain Academy Decipher(@decipher-media)
Reviewed by 최지혁(Jihyeok Choy)
[라이트닝 네트워크 시리즈]
1. Direct Payment via Lightning Channel
2. Indirect Payment via Multi-Hop HTLC
3. Topology of Lightning Network
4. Attacks on Lightning Network
[목차]
- Introduction
- Multi-Hop Payment via Hashed-Time Lock Contract
1) Why Multi-Hop HTLC?
2) Life cycle of a Multi-Hop HTLC
3) Atomicity of HTLC for Multi-Hop Payment - Routing on Lighting Network
1) Phase 1: Broadcasting Channel Information
2) Phase 2: Choosing a Route
3) Phase 3: Sending the Payment Data using Onion Routing - Outro
1. Introduction
이전 1편에서는 두 당사자가 직접적으로 거래를 하기 위해 라이트닝 채널(Lightning Channel)을 생성하고, 거래를 주고받는 과정을 살펴보았다. 본 2편에서는 채널을 생성하지 않고도 거래를 주고받을 수 있는 방법을 다룬다. 채널을 따로 생성하지 않고 거래를 주고받으려면 송신자는 이미 생성되어 있는 다른 채널을 이용해야 한다. 즉, 송신자가 이미 생성되어 있는 채널들을 통해 중간자들을 거쳐서 수신자까지 이를 수 있다면 추가적인 채널 생성 없이도 거래를 주고받을 수 있다. 이를 문제없이 가능케 해주는 것이 Multi-Hop Hashed-TimeLock Contract(이하 HTLC)이다. Multi-Hop HTLC는 multi-hop payment와 HTLC의 합성어이다. 본 편에서는 이들이 무엇이며 왜 필요한지, 그리고 송신자는 수신자까지 이르는 경로를 어떻게 파악하여 송금할 수 있는지에 대해서 살펴볼 것이다.
2. Multi-Hop Payment via Hashed-Time Lock Contract
1) Why Multi-Hop HTLC?
이전 편에서 살펴본 라이트닝 채널은 Alice와 Bob 둘 사이만의 일이었다. 만약 Alice가 Bob이 아닌 Charlie와도 거래를 하고 싶다면 어떻게 해야 할까? 가장 간단한 방법은 Alice가 Charlie와의 채널도 여는 것이다. 그러나 이렇게 거래하고자 하는 모든 사용자와 채널을 열게 된다면 n명의 사용자가 있을 때 채널의 개수는 O(n²)가 될 것이다. 추가로 하나의 채널에 대해 funding tx와 commitment tx, closing tx가 발생되기 때문에 사용자의 수 제곱에 비례하여 트랜잭션이 생성된다. 물론 거래가 발생할 때마다 트랜잭션이 하나씩 발생하는 것보다는 채널을 한 번 열어놓고 채널을 통해 여러 번 거래를 주고받는 것이 더 효율적이기는 하다.
하지만 라이트닝 네트워크가 성공적으로 정착되어 많은 사람들이 참여하게 되는 경우, 위 방법처럼 모든 사람들과 채널을 개설하여 거래를 하게 된다면 네트워크에 상당히 많은 부하를 주게 될 것이다. 이러한 문제를 보완하고자 많은 사람들과 더 효율적인 방법으로 모든 사람과 거래를 하기 위하여 고안된 방법이 multi-hop payment이다. 만약 Alice가 Charlie에게 라이트닝 네트워크를 이용하여 송금을 하고 싶은데 채널이 열려 있지 않은 상황을 가정해보도록 하자. 그리고 마침 Alice와 Bob 사이에 채널이 이미 열려있고 Bob과 Charlie 사이에도 채널이 열려있는 상황을 가정해보자.
이상적인 시나리오는 Alice가 Bob에게 송금을 하면, Bob은 Charlie에게 같은 금액을 송금해주는 것이다. 만약 Bob이 중간에서 전달하지 않는다면 Charlie는 Alice가 보낸 돈을 받지 못한다. 따라서 Alice → Bob, Bob → Charlie 간의 송금이 atomic하게 이루어져야 하는데, atomic 하다는 이야기는 Alice → Bob, Bob → Charlie 두 송금 과정이 모두 이루어지거나 모두 이루어지지 않아야 한다는 의미다.
이러한 atomicity를 보장하게 해주는 것이 Hashed-Time Lock Contract (이하, HTLC)이다. HTLC는 해시와 timelock을 이용한 contract이다. (라이트닝 채널의 commitment tx의 output에 걸려있는 timelock과 혼동하지 않도록 주의하자.) 구체적으로 설명을 하면, 어떤 해시값 H(x)에 대해 ‘해시값 H(x)의 preimage인 x를 특정 시간 내에 제시하면 output을 unlock하여 돈을 가져갈 수 있다‘라는 스크립트이다.
2) Life cycle of a Multi-Hop HTLC
Alice는 1 BTC를 Charlie에게 송금하는 예제를 통해 multi-hop payment 과정을 알아보겠다. 이 예제에서는 Alice는 송금자, Charlie는 수신자, Bob은 중간 전달자이다.
(1) Phase 1: Making HTLCs for Multi-Hop Payment
먼저 Charlie는 랜덤한 값 x를 생성하여 그것의 해시인 H(x)를 Alice에게 전송한다. 참고로 Alice와 Charlie는 채널 형성이 안 되어 있을 뿐이지 p2p 네트워크 프로토콜을 통해 연결이 되어 있고, 서로의 ip 주소도 알고 있다. 즉 채널 형성이 안 되어 있는 것과 네트워크 연결이 안 되어 있는 것은 전혀 다른 문제이기 때문에 Charlie는 Alice와의 채널이 열려있지 않더라도 그녀에게 H(x)를 전송할 수 있다.
Bob의 역할은 Alice의 돈을 Charlie에게 전달해주는 역할이기 때문에 라이트닝 네트워크에서 중요한 역할을 한다. 라이트닝 네트워크가 의미있고 원활하게 유지되기 위해서는 중간 전달자 노드들의 많은 유입과 유지가 필수적인 요건이다. 이를 위해서 중간자로서 거래를 전달할 때마다 일정 금액을 가져갈 수 있도록 설계가 되어 있다. 라이트닝 네트워크 상에서 중간자들이 수수료를 책정하는 방식이 있지만, 여기서는 편의상 Bob이 0.1 BTC를 수수료로 취한다고 하겠다.
Charlie로부터 H(x)를 받은 송금자 Alice는 아래 그림과 같이 Bob 사이에 ‘t₁ 시간 내에 자물쇠 H(x)를 풀 수 있는 preimage x를 주면, 1.1 BTC를 주겠다’라는 HTLC를 생성한다.
Bob은 Alice로부터 전달받은 contract 정보를 바탕으로, 아래 그림과 같이 Charlie와 열린 채널을 이용해 비슷한 HTLC를 생성한다. Bob과 Charlie 간 생성되는 HTLC의 구체적인 내용은 ‘t₂ 시간 내에 자물쇠 H(x)를 풀 수 있는 preimage x를 주면, 1 BTC를 주겠다’라는 contract이다. 이때 Bob은 본인의 수수료 몫 0.1 BTC는 제한 만큼을 송금액으로 설정하였으며, Bob이 Charlie로부터 x를 받는 것이 Alice가 Bob으로부터 x를 받는 것보다 더 먼저이기 때문에 시간 t₂는 t₁ 보다 작게 설정되어야 한다.
모든 중간자들이 HTLC를 차례차례 생성하여 수신자까지 HTLC가 만들어지면, multi-hop payment를 위한 HTLC 생성 과정이 완료된다.
(2) Phase 2: Carrying Out HTLCs for Multi-Hop Payment
HTLC 계약 이행은 수신자인 Charlie로부터 시작된다. Charlie는 x와 H(x)를 만든 장본인이므로 Bob에게 preimage x를 제시할 수 있다. Charlie는 t₂ 만큼의 시간이 흐르기 전에 x를 제시한다.
Bob과 Charlie 사이에는 ‘t₂ 시간 내에 자물쇠 H(x)를 풀 수 있는 preimage x를 주면, 1 BTC를 주겠다’라는 contract가 걸려있었고, Charlie는 t₂ 만큼의 시간이 흐르기 전에 x를 제시하였으므로, contract 조건에 따라 자동으로 Charlie에게 1 BTC가 Bob으로부터 전송된다. 즉, Bob에게서는 1 BTC만큼 차감시키고 Charlie에게는 1 BTC만큼 증가시킨 commitment tx를 새로 작성하고 서명을 주고받는다.
마찬가지로 Bob은 t₁ 만큼의 시간이 지나기 전에 Charlie로부터 전달받은 x를 Alice에게 제시한다.
Alice와 Bob 사이에도 ‘t₁ 시간 내에 자물쇠 H(x)를 풀 수 있는 preimage x를 주면, 1 BTC를 주겠다’라는 contract가 걸려있었기 때문에 contract 조건에 따라 자동으로 Bob에게 1.1 BTC가 Alice로부터 전송된다.
결과적으로 Alice는 원하던 대로 Charlie에게 1 BTC를 전송할 수 있게 되었고, Bob은 수수료 0.1 BTC를 얻을 수 있다.
[Note]
위 예시의 t₁, t₂는 랜덤하게 정해지지 않는다. 각 노드는 cltv_expiry_delta(이하 Δ)라는 값을 설정하고 있는데, 이는 바로 다음 차례의 전달자로부터 preimage를 받기 위해 기다릴 수 있는 시간이다. 즉, 만약 Alice의 Δ값이 144블록이라면 그녀는 누구와 HTLC를 맺든 간에 preimage를 받기 위해 144블록을 기다릴 수 있다는 것이다. 그러나 multi-hop payment에서는 hop-by-hop으로 HTLC가 풀려야 한다. 즉 위 예시에서 Bob과 Charlie 간의 HTLC가 풀려야 Alice와 Bob간의 HTLC가 풀릴 수 있다. 따라서 Alice는 본인의 Δ에 Bob과 Charlie 간에 걸린 timelock만큼을 더 기다려야만 한다. 그러므로 위 예시에서 각 hop별 HTLC의 timelock이 설정될 때, t₁ = (Δ of Bob), t₂ = (Δ of Alice) + (Δ of Bob)으로 설정된다.
3) Atomicity of HTLC for Multi-Hop Payment
기본적으로 HTLC에는 timelock이 걸려있기 때문에, 위 예제에서 Alice와 Bob 간의 HTLC의 경우 t₁ 시간 동안 Bob이 preimage x를 제시하지 못한다면 Alice에게 다시 1.1 BTC가 환불된다. (기술적으로 더 정확한 표현으로는 Alice가 다시 가져갈 수 있다.) 따라서 어떤 원인이었든 간에 HTLC에 명시된 시간 내에 preimage가 제시되지 않으면 해당 HTLC는 없었던 일이 된다.
마찬가지로 Charlie와 Bob은 HTLC를 t₂ 시간에 대해서 HTLC를 체결했기 때문에 Charlie는 Bob에게 x를 t₂ 시간 내에 주지 않는다면, Bob과 Charlie와의 HTLC는 취소될 것이다. Bob은 Charlie로부터 x를 받지 못했고, 해시의 역상저항성으로 인해 H(x)로부터 x를 알아내는 것은 암호학적으로 불가능하기 때문에 Bob은 x를 알 수 없다. 따라서 Bob도 Alice에게 x를 제시할 수 없어서 Alice와 Bob 간의 HTLC도 취소된다. 즉 multi-hop payment 상 모든 HTLC가 time-out으로 취소된다.
반대로 Charlie가 Bob에게 t₂ 시간 내에 x를 제시하였다면, Bob은 Alice에게 t₁ 시간 내에 x를 제시할 수 있다. 특별한 이유가 없지 않는 한 Bob은 x를 Alice에게 제시하여 Charlie에게 보낸 금액을 Alice로부터 돌려받고 싶을 것이다. 따라서 Alice와 Bob 간의 HTLC도 이행된다. 즉 multi-hop payment 상의 모든 HTLC가 이행되는 것이다.
어떠한 경우든지 HTLC를 이용한 multi-hop payment은 atomicity가 보장된다. 위 예시에서는 중간자가 Bob 하나였지만, 일반성을 잃지 않고 중간자가 여럿으로 늘어나더라도 atomicity가 보장된다.
3. Routing on Lighting Network
앞선 내용에서 HTLC를 활용한 multi-hop payment의 과정을 알아보았다. 그렇다면 어떤 채널들을 건너 multi-hop payment의 루트를 정할 것인지 어떻게 결정할까?
1) Phase 1: Broadcasting Channel Information
우선 라이트닝 네트워크의 모든 노드들은 각자의 채널을 다른 모든 노드들에게 브로드캐스팅하여 전파한다.(다시 한번 채널의 유무와 네트워크 연결의 유무는 다른 문제임을 주의하자.) 어떤 노드와 채널을 형성하였고 얼마만큼의 자금을 담보로 형성하였는지에 대한 정보를 알리는 것이다. 이 밖에 수수료, timelock 등 기타 multi-hop payment를 형성하는 데에 필요한 정보 또한 같이 포함시켜 알린다. 하지만 채널의 잔액은 알리지 않는다. 예를 들어 Alice와 Bob과의 채널을 열 때 5 BTC를 담보로 하여 열었다고 하자. 그런데 다른 어떤 multi-hop payment가 이 채널을 거쳐 지나가고 있는 중일 수 있다. 1 BTC 만큼의 Payment가 지나가고 있는 중이라면, Alice → Bob으로 전송될 수 있는 5 BTC 중 1 BTC는 이미 다른 루트에 의해 사용 중인 것이다. 남은 4 BTC만 추가로 전송할 수 있는 상태이지만 이 채널의 balance를 알리는 것이 아니라 5 BTC라는 채널의 capacity만을 알린다. 채널의 balance를 알리면 어디서부터 어디까지 얼마만큼의 금액이 이동하고 있는지 노출될 수 있다는 프라이버시에 대한 염려 때문이다.
2) Phase 2: Choosing a Route
따라서 라이트닝 네트워크에 참여하는 각 노드는 라이트닝 네트워크의 전체 토폴로지를 파악하고 있다. 그러므로 송신자는 수신자의 ip 주소만 알고 있으면, 이미 파악하고 있는 라이트닝 네트워크 토폴로지 상으로 어떻게 수신자까지 도달할 수 있는지 라우팅(routing)을 할 수 있다. 이때 수신자까지 여러 개의 루트를 식별했다면, 어떤 루트를 통해 multi-hop payment를 진행할 것인지 선택하는 것은 전적으로 송신자의 몫이다. 송신자는 식별한 루트 상의 capacity만을 보고 라우팅을 했으므로 실제 채널의 balance보다 큰 금액을 송금할 수도 있다. 또는 채널이 그 사이에 끊어져있을 수도 있고, 중간자가 제대로 전달을 안 해줄 수도 있다. 이러한 경우 해당 루트를 통해 진행하려던 거래는 fail이 된다. 수신자까지 무사히 도달할 때까지 송신자는 계속 라우팅을 시도해야 한다.
3) Phase 3: Sending the Payment Data using Onion Routing
라이트닝 네트워크에서는 프라이버시를 보호하기 위해 onion routing을 도입하였다. Onion routing은 1990년대 미 해군 연구소 소속의 Paul Syverson, Michael G. Reed, David Goldschlag에 의해 고안된 익명 통신 프로토콜이다.
송신자 Alice가 메시지 M을 중간 전달자 Bob, Charlie를 거쳐 Dave에게 전달한다고 하자. 이때 메시지 M은 다음과 같이 암호화된다.
Alice로부터 C₁를 전달받은 Bob은 본인의 개인키 sk_Bob로 C₁를 복호화하면 다음과 같이 INFO_Bob과 C₂를 얻을 수 있다.
Bob은 INFO_Bob를 참고하여 복호화한 메시지 C₂를 Charlie에게 전달한다.
Charlie는 Bob과 마찬가지로 본인의 개인키 sk_Charlie로 전달받은 메시지 C₂를 복호화하고, INFO_Charlie를 참고하여 Dave에게 복호화한 메시지 C₃를 전달한다. Dave는 C₃를 본인의 개인키 sk_Dave로 복호화하여 원래 메시지 M을 얻는다.
따라서 송신자의 메시지 M은 오직 수신자만이 본인의 개인키로 복호화하여 확인할 수 있다. 중간 전달자들은 오직 누구로부터 메시지가 왔는지와 누구에게 메시지를 전달해야 하는 지만 확인할 수 있고, 그 외의 정보는 알 수 없다. 또한 각 중간자들은 암호화된 형태의 메시지만을 전달하기 때문에 다음 차례의 누군가가 중간자인지, 수신자인지도 알 수 없다. 즉 송신자와 수신자를 알 수 없는 것이다. 그뿐만 아니라 얼마의 금액이 전송되고 있는 지도 추측하기 어렵다. HTLC의 계약 형성 과정을 떠올려보면, 전달자는 다음 차례의 전달자와 HTLC를 계약해야 하기 때문에 송금액을 알 수 있다고 생각할 수도 있다. 그러나 송신자가 지정한 대로 다음 차례의 전달자와 HTLC를 형성하기 때문에 송금액을 알 수 없다. 만약 송신자가 지정해준 금액을 바탕으로 송금액이 얼마인지 추측하려고 해도, 각 전달자는 루트에 누가 속해있는지 모르는 데다가 책정한 수수료도 제각기 다르기 때문에 매우 어렵다.
결론적으로 라이트닝 네트워크에서는 onion routing 덕분에 중간자들은 1) 누가 송금하는지, 2) 누가 수신하는지, 3) 얼마의 금액이 전송되고 있는지 알 수 없다.
4. Outro
지금까지의 1, 2편을 통해 라이트닝 네트워크를 이해하기 위한 기본적인 개념들을 살펴보았다. 이실직고하자면 실상은 이렇게 간단하지 않다. 라이트닝 네트워크에 대해서 더 자세하게 제대로 알리고 싶으나, 필자의 전달력의 한계로 인해 앞으로 이어질 ‘3. 라이트닝 네트워크의 토폴로지’와 ‘4. 라이트닝 네트워크에 대한 공격’ 편을 이해하기에 무리가 없는 정도의 아주 개괄적인 수준으로만 서술하였음을 양해 부탁드린다. 대신 라이트닝 네트워크에 대해 더 자세히 알고 싶으신 독자분들께서는 아래 두 링크를 참고하시면 좋을 것 같다. 필자 개인적으로는 라이트닝 네트워크에 대해 알아가는 과정에서 참고했던 글들 중 가장 정확하고 상세하게 서술한 글이기 때문이다.
이어지는 편에서는 라이트닝 네트워크의 토폴로지가 매우 중앙화되어 있다는 것을 여러 지표와 실험들을 인용하여 서술할 것이며, 마지막 네 번째 편에서는 라이트닝 네트워크를 공격하는 시나리오들을 살펴볼 것이다.
