[블록체인] - Lightning Network

1. Lightning Network 필요성

 이전까지 비트코인은 블록이 10분에 한 개씩 채굴되는 반면, 트랜잭션은 그것보다 훨씬 더 빨리 많이 생성된다. 즉, 비트코인 사용자가 늘어남에 따라 트랜잭션의 수는 더 늘어날 것이고, 블록이 확정되는 시간보다 블록에 포함되길 기다리는 트랜잭션들이 네트워크 상에 더 많아지게 될 것이다.

 

 또한, 트랜잭션은 반드시 블록에 포함되어야 최종적으로 확정된다. 그런데 어떤 트랜잭션 블록에 포함될지는 전적으로 채굴자가 정한다. 채굴자는 자신의 이익을 최우선으로 하기 때문에, 일반적으로 transaction fee가 높은 트랜잭션을 우선적으로 블록에 넣는다. 이때문에 fee가 낮은 트랜잭션은 오랫동안 블록에 포함되지 못하는 상황이 발생할 수 있다.

 

 특히, transaction fee가 낮은 거래들은 카페에서 커피를 사먹거나 편의점에서 삼각김밥을 사먹는 소액결제 형태일 것이다. 이런 일상적인 거래를 위해 높은 transaction fee를 지불하는 것은 현실적이지 않다. 예를 들어 커피가 5,000원인데 수수료가 그보다 더 비싸지는 비효율적인 상황이 생길 수 있다.

 

 따라서 수많은 소액 트랜잭션을 모두 on-chain에 올리지 않고, 두 사용자 사이의 거래를 off-chain에 모아서 처리한 뒤 최종 정산 결과만 블록체인에 반영하자는 아이디어가 등장했다. 이 아이디어가 구현된 기술이 바로 Lightning Network이다.

---

2. Payment Channel

 Lightning Network는 기본적으로 peer-to-peer 네트워크이다. Lightning Network는 앞서 정의했듯이 소액 결제를 위한 Bitcoin 위에서 동작하는 off-chain 네트워크이다. 사용자 사이에는 payment channel이라는 것이 존재하고, 이를 통해 소액 결제들이 진행된다.

 

 그럼 payment channel은 무엇일까? payment channel은 다음과 같이 정의할 수 있다.

• Payment Channel: Lightning Network 위에 두 노드 사이의 경제적인 관계를 나타내는 통로

 이 payment channel을 통해 사토시(satoshi) 단위로 표현된 balance가 두 노드 사이에서 이동한다. 이 채널은 cryptographic 프로토콜로 관리된다. 이 암호화 프로토콜을 통해 부정행위를 방지할 수 있고, 두 노드가 서로를 신뢰하지 않아도 거래를 진행할 수 있게 해준다.

 

 앞서 정리했던 2-of-2 multisignature 주소를 기반으로 이루어지며, 이 주소를 통해 두 채널 참가자가 반드시 공동 서명을 해야만 자금을 이동시킬 수 있기 때문에 일방적인 부정 사용을 막을 수 있다.

 

 두 노드는  multisig address를 기반으로 채널을 생성하고, 채널 안에서 서로 협력하여 계속 새로운 상태(state)를 만들어낸다. 이때 LN에서는 트랜잭션의 sequence 번호만으로 상태 업데이트를 하는 것이 아니라, 각 업데이트마다 이전 상태를 무효화하고 새로운 상태를 유효하게 만드는 구조(commitment transaction + revocation key)를 사용하여 최신 balance 상태만이 유효하도록 만든다. 이러헥 하면 채널에서 이루어진 거래는 모두 Bitcoin on-chain에 기록할 필요 없이 off-chain에서 즉시 처리된다.

 

 그리고 가장 최신 상태는 항상 두 노드의 balance를 반영한 commitment transaction 형태로 존재하며, 어느 한쪽이 채널을 종료하고자 할 경우 이 최신 commitment transaction을 on-chain에 broadcast하여 블록체인에 반영한다. 이 과정이 바로 최종 정산이다.

 

 최종 정산을 진행하면, 이때 당시에 가장 최신 상태를 나타내는 commitment transaction만이 비트코인 시스템에 broadcast되며, 이때 청므으로 on-chain에 기록된다.

---

3. Payment channel 과정

 이 payment channel이 어떻게 두 사용자간 열리는지, 열리는 과정에서 어떤 정보가 오가는지 한 번 정리해 보려고 한다. 과정은 다음과 같다.

1. Alice가 새롭게 private key와 public key를 만들고 그녀가 channel을 만들고 싶어하는 대상인 Bob에게 open_channel이라는 메시지를 통해 알린다.
2. Bob은 똑같이 새로운 private key와 publick key를 만들고 자신의 public key를 accept_channel이라는 메시지에 담아 Alice에게 전달한다.
3. Alice는 이제 Bob의 public key와 자신의 public key를 이용해 multisig address를 만들고 채널을 열기 위해 100k satoshi를 이 multisig address로 보내는 funding transaction을 만든다.
   1. 주소: 2<PubKey Alice><PubKey Bob> 2 CHECKMULTISIG
4. .하지만, 이 funding transaction을 바로 broadcast 한다면 다음과 같은 문제가 발생할 수도 있다.
   1. Bob이 악의적인 의도를 갖고 funding transaction이 블록체인에 올라간 후에도 자신의 commitment transaction 서명을 제공하지 않을 경우, Bob도 해당  address의 돈을 사용할 수 없지만, Alice가 넣은 100k satoshi가 묶이게 된다.
5. 따라서, funding transaction을 broadcast하기 전에 반드시 안전장치가 필요하다.
6. 이를 위해 Alice는 funding transaction을 broadcast하지 않고, 해당 트랜잭션의 output과 함께 Bob이 commitment transaction을 만들 수 있도록 필요한 정보(Alice 서명 등)를 funding_created 메시지를 통해 Bob에게 전달한다.
7. funding transaction ID를 받은 Bob은 이제 이 multisig output을 input으로 사용하는 자신의 commitment transcation을 만들 수 있게 된다.
8. Bob은 commitment trtansaction을 만든 뒤, 이 트랜잭션에서 필요한 부분에 대해 자신의 서명을 funding_signed 메시지와 함께 Alice에게 전달한다.
9. 서명을 받은 Alice는 Bob이 보낸 서명을 이용해 Alice 버전의 commitment transaction을 완성한다.
10. 그와 동시에 향후 Bob이 응답하지 않거나 부정하게 행동하더라도 자신의 돈을 돌려받을 수 있도록 timelock이 부여된 안전한 commitment transaction(사실상 refund 역할 수행)을 보관한다.
11. 양측은 본인의 commitment transaciton을 상대방과 교환하지 않고 각자 보관한다.
12. 이후, funding transaction을 비트코인 네트워크에 broadcast한다.

 다음 그림을 통해 다시 한 번 확인해보자.

 그림에 대해서 설명하면 다음과 같다.

• on-chain 트랜잭션 쪽의 블록 내에 파란색은 funding transaction이다.
  • 이는 채널 개설 시 비트코인 on-chain에 broadcast하여 두 사용자 간 채널이 존재한다는 것을 알리는 것이다.
• 이후 off-chain 트랜잭션 쪽에서 소액 결제들이 일어난다.
• 새로운 결제가 발생할 때마다 두 사용자는 이전 commitment transcation을 revoke(무효화)하고 새로운 commitment transaction을 함께 생성하여 보관한다.
• 이제 더 이상 소액결제를 사용하지 않는다고 판단될 경우, 맨 마지막 commitment transaction을 on-chain 트랜잭션으로 broadcast하게 된다.
  • 이 트랜잭션이 블록에 포함되면 채널이 정산되고 닫힌다.

 

---

4. LN Cheating

 LN에서도 당연히 부정행위가 일어날 수 있다. 어떤 부정행위가 일어날 수 있는지 한 번 정리해 보려고 한다.

 

 비트코인 시스템 내에서는 누구든, 언제든지 트랜잭션을 broadcast할 수 있다. 글허기 때문에 LN에서 사용된 이전 버전의 commitment transaction 역시 이론적으로는 broadcast될 수 있다.

 

 LN에서 다음과 같이 돈을 주고 받았다고 가정해보자.

 즉, 현재 입장에서 Alice는 75K, Bob은 25K인 상태이다. 그런데 Alice가 현재 상태의 commitment transaction을 broadcast하지 않고 이전 상태였던 Alice 80K, Bob 20K 형태의 과거 commitment transaction을 broadcast한다면 어떻게 될까?

 

 Bob은 channel을 통해 Alice에게서 돈을 받았다고 생각하고 서비스나 물품을 제공했을 텐데, 위와 같은 상황이 벌어지게 된다면 Alice는 예전에 유리했던 잔액 상태를 사용해 공짜로 물건이나 서비스를 얻는 부정 행위를 시도하게 된 것이다.

 

 이러한 부정행위를 막기 위해 LN에서는 다음과 같은 방식을 도입했다.

• 누군가가 이전 상태의 commitment transcation을 broadcast하여 부정행위를 시도한다면, 상대 참여가자 이 트랜잭션을 처벌(penalty)할 수 있다.

 기존 비트코인 시스템에서는 부정행위자에게 직접적인 벌칙이 없고, 정직한 참여자를 늘리는 방식으로 네트워크를 유지해왔다면, LN에서는 이전 버전의 commitment transcation을 broadcast하는 행동 자체를 강하게 처벌하는 구조를 도입했다.

 

 위의 예시로 다시 설명하면, 만약 Alice가 오래된 commitment transcation을 broadcast했고 Bob이 이를 알아차린다면, Bob은 Alice가 시도한 commitment transaction이 revocation key를 통해 무효화도니 상태라는 점을 이용해 penalty transaction을 만들 수 있다. 이 penalty transaction을 통해 Bob은 Alice의 모든 balance를 자신 앞으로 가져올 수 있다. 즉, 최종적으로 Bob은 100 K 전체 금액을 가져갈 수 있다.

- Asymmetric Commitment Transaction

 이러한 cheating 방법을 막는 과정을 이해하기 위해서는 LN에서 commitment transaction의 비대칭성을 이해해야 한다. 위에서 payment channel 개설 과정에 대새서 정리할 때, Commitment transaction은 교환하지 않는다고 정리했다. 이 말은 즉, Commtiment transcation은 서로 동일할 피룡가 없다는 것이다.

 

 이해를 위해 아래 그림을 참고하자.

 위 그림은 Payment channel 내의 동일한 트랜잭션 번호를 가진 상태의 서로 다른 모습의 트랜잭션이다. 즉, 동일한 트랜잭션 번호를 가진다는 것은 그 당시 balance는 각각 똑같지만, 둘이 내용까지 동일할 필요는 없다는 것이다.

 

 위 그림에서 왼쪽은 Alice의 commitment transcation, 오른쪽은 Bob의 commitment transaction이라고 가정해보자. Alice가 Bob에게 10,000 satoshi를 지불한 뒤, 다시 60,000 satoshi는 본인에게(to_self), 80,000 satoshi는 상대방에게 보내는(to_remote) output을 생성한 것이다.

 

 Bob 입장에서는 80,000 satoshi를 본인 계좌로(to_self), 60,000 satoshi는 Alice의 계좌로(to_remote) 보내는 상태를 유지하는 것이다.

 

 즉, 동일한 채널 상태를 나타내더라도 Alice와 Bob이 보관하는 commitment transaction은 서로 반대 구조를 가지므로 반두시 두 개가 비대칭적으로 존재한다.

---

5. Prevent Cheating: Timelocked

 그럼 이제 cheating을 막기 위한 방법에 대해서 정리해 보려고 한다. 그 방법 중 하나가 바로 timelock을 거는 것이다. 즉, 위 그림을 활용해 설명하면, to_self로 가는 output에 timelock을 거는 것이다.

 

 동일하게 왼쪽이 Alice의 commitment tranasaction, 오른쪽이 Bob의 commitment transaction이라고 가정하면, 각자 보관하는 commitment transaction에서 본인에게 돌아오는 to_self output에는 항상 timelock이 걸려 있다.

 

 이 timelock의 길이는 LN 프로토콜에서 정해진 값이며, 사용자가 임의로 조절하는 것이 아니라 채널 설정 과정에서 자동으로 적용되는 값이다.

 

 만약 Alice가 Commitment #3(추가로 10,000 satoshi를 Bob에게 더 지불한 상태)까지 업데이트된 상황에서, 부정행위로 이전 상태인 Commitment #2를 broadcast한다고 가정해보자. timelock이 걸린 상태라면, Alice의 to_self output(60,000 satoshi)은 timelock이 걸려 있기 때문에 432(약 3일)이 지나야만 Alice가 이 금액을 실제로 사용할 수 있게 된다.

 

 즉, 이 3일의 지연 기간 동안 Bob이 Alice의 부정행위를 발견하기만 하면, Bob은 해당 commitment transaction에 포함된 revocation key를 이용해 Alice 금액 전체를 penalty로 가져갈 수 있게 되는 것이다. 반대로 이 기간 안에 Bob이 부정행위를 발견하지 못한면, Alice는 timelock이 지난 뒤 정상적으로 자신의 to_self_output을 사용할 수 있게 되고, 이 이후에는 처벌할 방법이 없다.

---

6. Prevent Cheating: Timelocked_Revocation Keys

 부정 행위에 대한 penalty를 부과하는 방법은 상대방이 보유하고 있는 모든 balance를 취하는 것이다. 그럼 위 상황에서 Alice가 Commitment #2를 broadcast했고, 그 상황을 Bob에게 발각되었앋면, Bob이 Alice가 보유한 60,000 satoshi를 가져와야 하는데, 그 방법이 바로 Revocation key를 활용하는 것이다.

 

 이전에, payment channel을 개설할 당시, public key를 주고 받는 다는 사실을 알고 있다. 즉, Alice와 Bob은 2-of-2 multsig address를 만들기 위해 이미 서로의 공개키는 알고 있는 상태이다.

 

 그 후, payment가 일어나서 commitment transaction을 업데이트하게 된다면, 이전 commitment transaction을 무효화(revoke)시켜야 한다. 이때 주고받는 정보가 바로 이전 commitment transaction에 대응되는 revocation_secret(=revocation 정보)이다.

 

 Revocation key는 상대방의 public key와 revocation_secret을 조합해 생성된다.

 

 즉, 위의 예시처럼 Alice가 commitment transaction #2를 broadcast하게 된다면, Bob은 이미 가지고 있는 Alice의 public key와 2번을 revoke할 당시 Alice가 건네준 revocation secret을 사용해 revocation key를 생성할 수 있다. 이를 통해 Bob은 Alice의 to_self_output(60,000 satoshi)를 즉시 가져오는 penalty를 부과할 수 있다.

 위의 그림이 timelock에 revocation key를 적용할 수 있는 to_remote with remote key 필드가 추가된 모습이다.

 

 그림으로 이해한 트랜잭션은 위와 같을 것이지만, output을 script로 나타내면 다음과 같을 것이다.

즉, 위 output script가 Alice 것이라면, 다음과 같은 상황들이 존재할 수 있다.

• 만약, Bob이 Penalty script를 발동시키고 싶다면, Bob이 input script로 제시해야 될 것은 순서대로 <revocationkey>, 1일 것이다.
  • 즉, IF와 1로 참임을 확인한 뒤에 revocation key와 revocationpubkey를 대조해 일치하면 Alice의  output을 사용할 수 있다.
• 만약, Alice가 정상적으로 output을 사용하려고 한다면, Alice는 차례대로 <서명>, 0일 것이다.
  • 먼저, 0이기 때문에 ELSE로 간 뒤, 현재 트랜잭션의 시간과 CHECKSEQEUNCEVERIFY를 해서 현재 트랜잭션 시간/블록이 더 크다면 이 output을 사용할 수 있다.
  • 따라서 서명과 <local_delayedpubkey>를 대조해 일치하면 사용가능하다.

---

7. 정리

 최종적으로 정리하면, commitment transaction은 두 개의 output이 존재한다.

• to_self
• to_remote

 이 output 중 to_self에 해당하는 output에는 timelock delay와 revocation secret이 추가로 존재한다.

 

 새로운 commitment transaction에 대해 서로가 서명을 교환하게 되면, 채널 참여자들은 직전 commitment transcation을 revoke(무효화)시키기 위해 그 직전 state에 대응되는 revocation secret을 상대방에게 전달하게 된다.

 

 만약 이렇게 revoke된 이전 commitment transcation이 다시 broadcast되는 부정행위가 발생한다면, 상대방은 이미 가지고 있는 revocation_secret과 public key를 조합해 revocation key를 생성할 수 있다.

 

 이를 통해 상대방은 to_self output을 penalty로 즉시 사용하여 해당 output에 포함된 모든 balance를 자신의 주소로 가져올 수 있게 한다.

 

+) 다음과 같은 궁금증이 생길 수도 있다. 만약 Alice가 부정행위를 저지르지도 않았는데 Bob이 revocation key를 제시해 Alice의 balance를 가져오려고 하면 어떻게 되지?

 

 이에 대한 답은 불가능하다이다. 그 이유는 revocation key를 사용한 penlaty spend는 오직 Alice가 이전 commitment transaction을 on-chain에 broadcast했을 때만 유효하게 작동하기 때문이다.

 

 즉, penlaty branch는 반드시 해당 old commitment transcation에서 생성된 to_self output이 실제 on-chain에 존재해야만 실행될 수 있다.

 

 Alice가 부정행위를 저지르지 않았다면, 그 old commitment transaction은 on-chain에 존재하지 않고, 따라서 Bob이 input script로 revocation key를 제시한다고 해도 spend할 대상 UTXO 자체가 존재하지 않는다. 결과적으로 Bob은 어떠한 방식으로도 미리 penlaty를 발동시킬 수 없다.