[블록체인] Lightning Network(1)

LN Introduction

LN은 2nd layer protocol이다. (그 자체가 P2P network)

블록체인이 가장 밑에 깔려있다면

bitcoin block chain을 이용해 새로운 서비스를 제공하는 것이 lightning network.

등장배경은 예시로 살펴보자.

Alice가 Bob의 커피가게에서 커피를 사는데 bitcoin으로 pay 하고 싶다.

Alice 입장에서는 수수료가 부담될 것이다. (커피값 절반이 될수도 있다)

Bob 입장에서는 Alice의 transaction이 confirm되는데 최소 10분은 걸릴텐데, 그 시간을 기다리라 하는 것은 무리가 있다.

이 문제점을 해결하기 위해 LN이 등장했다.

두 사람이 앞으로 계속 거래 하기로 약속하고 fund를 들어 놓는 방식이다.

(미용실이나 피씨방 정액권이랑 유사함)

이와 같이 처음, 마지막 transaction만 on-chain에 broadcast 한다.

LN으로
Alice의 수수료 문제를 해결할 수 있고

Bob은 instant payment로 transaction confirm문제를 해결 가능하다.

Payment Channel

두 node의 financial relationship.

여기서 두 node를 channel partner라고 한다.

각 node가 가지고 있는 금액을 Balance of fund라고 한다.

그리고 이 금액을 redistribute(재분배) 하기 위해

암호화 protocol을 사용한다.

금액이 실제로 이동하는게 아니라 redistribute기 때문에

양방향으로 움직일 수 있고 환불 개념도 존재하게 된다.

일종의 smart contract로 구현 되었다.

Ethereum만큼의 자유도를 제공하는 smart contract는 아니지만 제한된 형태로 재공한다. (turing complete 하지 않다)

Payment Channel Basics

payment channel은 2-of-2 multisignature address를 가진다.

즉 Alice, Bob 모두의 signature가 있어야 사용 가능한 곳에 돈을 넣는 것이다.

최초로 넣은 금액이 channel capacity이다.

재분배시 이동하는 금액을 flow라고 하는데, flow > capacity일 수 있다.

(환불하는 상황, 양뱡향 이동)

처음 그림에서 물건을 살때마다 off-chain transaction이 만들어지고

balance redistribute가 일어난다.

(이때 만들어지는 transaction이 commitment transaction이다)

그리고 이 transaction들은 network에 보내지 않는다.

즉 두 node간의 통신만 필요한 것이다 -> instatnt 하다

즉 이전에 만들어진 transaction은 지난 정보가 된다. (가장 마지막이 최신)

이걸 revoke(폐기) 시킨다고 한다.

하지만

1. block chain에 transaction을 폐기하는 방법이 존재하지 않는다.
   
   즉 revoke된 transaction은 없어지는게 아니고, broadcast를 막을수 있는 방법은 없다.
2. Alice가 이전(revoke된) transaction을 network에 뿌린다면?
   
   100만원 channel을 열고 70만원어치 커피를 마시고
   
   30만원만 사용했을때의 transaction을 boradcast 시키면 40만원의 이득을 보게 된다.

LN에는 이를 응징할 수 있는 transaction이 존재한다.(이후에 자세히)

정확히 revoke는 상대가 이전 transaction을 boradcast 시켰을때 응징할 수 있는 방법을 가지고 있는 상태를 말한다.

응징하게 되면 payment channel의 전체 금액을 가지게 된다.

Funding Transaction

최초의 transaction이다.

즉 이 transaction은 on-chain에 등록된다.

2-of-2 multisig output을 만드려면

Alice 입장에서 Bob의 public key가 필요하므로 요구한다.

(output : 0 의 locking script가 이렇게 생겼다)

2 <PubKey Alice> <PubKey Bob> 2 CHECKMULTISIG

---

만약 이 상태에서 Bob이 signature를 주지 않거나 사라지면?

Alice는 140,000 satoshi를 꺼내지 못한다.

그러므로 Alice에게 refund transaction이라는 안전장치가 필요하다.

(output : 0울 redeem 하려면 unlocking script는 이렇게 생겨야 한다)

<Alice Signature> <Bob Signature>

refund transaction은 사용하려는 목적이 아니다.

즉 network에 뿌리지 않는다.(broadcast 하지 않는다)

그리고 이를 위해서는 refund transaction에 대한 Bob의 signature가 필요하므로 Alice가 요구한다.

부가 설명

• open channel / accept channel
  
  A가 제안
  B가 accept (public key 전달)

• funding created / funding signed
  
  A가 funding transaction을 만들고
  
  B가 funding transaction sign
  
  + funding transaction에 대한 hash 전달
  
  + refund transaction에 대한 signature 요구
  

  • 이유: B가 refund transaction 서명을 주려면 refund transaction 내용을 알아야 한다
    
    그런데 refund transaction은 funding tx output을 redeem한다(이전 tx id hash를 알아야 한다)
    
    그러므로 funding tx hash를 알아야 한다.

• funding locked
  
  network에 broadcast
  
  confirm 된 상태

Commitment Transaction

Alice가 Bob의 커피 가게에서 커피를 3번 먹었다.

4개의 commitment transaction은 모두 하나의 transaction을 redeem하고 있다.

그러므로 4개중 하나의 transaction만 on-chain에 등록될 수 있다.

(의미적으로도 140,000원 중에 100,000 썼으면 40,000만 남는게 당연)

두개 다 broadcast 한다면 doouble spend상황이다.

Commmitment transaction은 파트너가 가지고 있는 transaction 내용은 같지만 형식이 다르다.

Commitment#2를 예시로 보면

첫번째 index는 to self

두번째 index는 to remote

to self는 cheating에 대비해 432block delay를 두게 된다.

(432 block은 약 3일)

즉 상대방의 cheating을 응징할 수 있는 기회가 3일동안 있는 것이다.

Commitment transaction을 생성하는 과정은 Penalty Transaction에서 같이 정리한다.

Penalty Mechanism

사실 commitment transaction에 조건이 하나 더 있다.

이 구조 때문에 응징하는 transaction이 가능하다.

Alice가 cheating 했을때,
to_self transaction이 3일동안 잠겨있는 동안

Bob은 remote key를 resolve할 수 있는 signature를 제시하면 해당 transaction을 사용할 수 있는 것이다. (delay 없이)

remote key는 일종의 public key라고 생각하면 되고

이전에 Alice가 Bob에게 remote key에 대한 signature(private key)를 미리 알려줘야 한다.

그럼 alice는 왜 signature를 알려주지? 의문이 들테니

약간의 스포를 하면 서로 약점을 노출해서 약속을 지키는 방식이다.

즉 transaction을 revoke할때 폐기 시키기로 약속하며 signature를 상대에게 알려주고

만약 내가 이를 어기고 revoke된 transaction을 boradcast 시킨다면 너가 이거 다 가져~ 하는 것이다.

Penalty Transaction

지금까지 내용과 함께

새로운 transaction(commitment#11)을 만드는 과정을 보자.

• commitment signed
  
  2-of-2 multisig는 2명의 signature가 필요하다.
  
  Alice가 Bob에게 자신의 서명을 보낸다.
  
  (commitment#11에 대한 서명)
• revoke and ack
  이때 이전 transaction을 revoke한다는 의미로
  
  Bob이 Alice에게 revokation secret(remote key secret)을 보낸다.
  
  (commitment#10의 remote key에 대한 서명)

마찬가지로

• commitment signed
  
  2-of-2 multisig는 2명의 signature가 필요하다.
  
  Bob이 Alice에게 자신의 서명을 보낸다.
  
  (commitment#11에 대한 서명)
• revoke and ack
  이때 이전 transaction을 revoke한다는 의미로
  
  Alice가 Bob에게 revokation secret(remote key secret)을 보낸다.
  
  (commitment#10의 remote key에 대한 서명)

서명을 보낸다는 의미는 message(transaction 내용)에 대한 서명을 하는 것이다

(과제를 해보면 이해가 잘된다)

다시 말해 revoke된 transaction을 사용하지 못하는거지, 소유하고 있다.

(사용하지 않는 것이 자신의 이익에 부합한다 -> 계속 나오는 bitcoin의 철학이다)

아래 그림에서 Alice가 commitment#1을 broadcast 하는 상황.

Alice의 commitment transaction은 다음과 같이 생겼다.

그러면 Bob이 응징하는 방법이 Penalty transaction을 만드는 것이다.

Transaction Fee

처음, 마지막 transaction에 대해서만 수수료를 내면 된다고 했는데

어디에 포함되어 있을까?

(교수님 설명)
정답은 Alice의 to_self transaction에 포함되어 있다.

Bob에게 돈을 주는 입장이니, Bob은 알아서 한다고 생각하고 Alice 입장을 생각하자.

Bob이 응답 없는 상황이고, 정산 transaction에서

Alice 잔액이 50,000

Bob은 90,000

-> 하지만 transaction fee로는 부족하다면 남은 돈을 챙길 수 없다???

그래서 Alice가 카페에 100번 갔다면 100씩 to_self로 10,000을 넣어놓고

여기서 적절한 fee를 책정한다..

---

(뇌피셜)

교수님은 commitment transaction output(to self)라고 하신 것 같은데 내 생각은 약간 다르다,, 잘못 들었을수도

fee = (input합 - output 합)이니까

input인 2-of-2에 포함되어 있지 않나?

EX)

input : 2-of-2 (550)

output : Alice(400), Bob(100)

fee : 50

Shutdown

3가지가 존재한다.

1. 정상적인 상황
   

   (정산) Final transaction
   

2. Alice, Bob중 한명이 응답이 없는 상황

   Bob이 갑자기 카페를 버리고 야반도주 해서 응답하지 않는 상황이고
   
   Alice의 잔액에는 50,000이 남아 있다면?
   

   그냥 최신 commitment를 broadcast하면 된다.

   1. 최신 commitment에 대한 revokation key를 Bob이 가지고 있지 않다. (응징 못함)

   2. 최신 commitment는 Alice가 마신 커피값에 대해 지불이 되어 있다.

      단, to_self(50,000, 환불된) 잔액을 사용하려면 3일 (432block)을 기다려야 한다.

3. Cheating을 응징하는 상황
   Alice가 cheating 한다면 모든 balance를 Bob이 가져간다.