라이트닝 네트워크에 대한 심층 해석: HTLC 작동 방식 및 다중 홉 결제 구현 방식

以太坊爱好者

特邀专栏作者

2021-09-15 11:29

이 기사는 약 5719자로, 전체를 읽는 데 약 9분이 소요됩니다

이 기사에서는 HTLC가 어떻게 작동하는지 설명하고 예제를 사용하여 라이트닝 네트워크에서 다중 홉 결제가 구현되는 방법을 보여줍니다.

그림

이전 기사에서 결제 채널이 작동하는 방식과 결제가 안전하게 이루어지도록 하는 다양한 방법에 대해 자세히 설명했습니다. 그러나 이러한 기능은 사용 가능한 결제 채널 네트워크를 지원하기에 충분하지 않습니다. 각 채널의 모든 참여자가 정직하고 신뢰할 수 있다고 확신하더라도 여러 채널을 통한 결제도 안전하다는 보장은 없습니다. 그래서 "HTLC(Hash-Time Lock-Contract)" 스마트 계약이 필요합니다. 이 기사에서는 HTLC가 어떻게 작동하는지 설명하고 예제를 사용하여 라이트닝 네트워크에서 다중 홉 결제가 구현되는 방법을 보여줍니다.

해시 시간 잠금 계약(HTLC)

HTLC의 구조는 복잡하지 않지만 매우 효율적입니다. 이를 통해 명시적인 "만료 시간"으로 결제를 생성할 수 있습니다. 짐작하셨겠지만 HTLC 계약은 해시 확인과 만료 확인의 두 부분으로 구성됩니다.

H = Hash(R)

해시 값(해시)부터 시작하겠습니다. HTLC로 결제 거래를 생성하려면 먼저 비밀 값 R을 생성한 다음 해당 해시 값을 계산합니다. 모든 단어, 숫자는 이 비밀 값으로 사용할 수 있습니다. 왜냐하면 해시 함수에서는 모두 데이터 묶음의 조합이며 차이가 없기 때문입니다.

이 해시 값 H는 트랜잭션 출력의 잠금 스크립트에 배치됩니다. 이와 같이 H에 해당하는 비밀값을 아는 사람만이 이 출력을 사용할 수 있다. 그리고 R은 소위 "preimage"입니다.

HTLC의 두 번째 부분은 만료 시간 확인입니다. 비밀 값이 제 시간에 공개되지 않으면 지불은 사용되지 않으며 보낸 사람은 모든 자금을 돌려받습니다.

누군가에 대한 HLTC 결제 거래를 생각해 봅시다.
HASH160 EQUAL
IF
# 제공된 R이 H의 사전 이미지인지 확인
CHECKSIG
ELSE
# R을 공개한 사람이 거래의 원래 수령인인지 확인
CHECKLOCKTIMEVERIFY
# 타임록이 만료되었는지 확인
CHECKSIG
ENDIF

# 거래의 원래 보낸 사람이 자금 반환을 요청하는지 확인하십시오.

올바른 R(해시값 H의 사전 이미지)이 공개된 후 IF 프로세스에 들어가 결제 거래 초기에 R을 제공한 사람이 결제 대상인지 여부를 추가로 확인합니다. 이 출력을 사용할 때 수신자는 매우 간단한 잠금 해제 스크립트를 제공합니다.

잠금 해제 스크립트에서 제공하는 R이 잘못된 경우 ELSE 프로세스로 이동하여 먼저 시간 잠금이 해제되었는지 여부를 확인합니다. 시간 잠금이 해제된 경우 보낸 사람은 모든 자금을 복구할 수 있습니다. 자금 인출을 위한 잠금 해제 스크립트는 비슷하지만 유일한 차이점은 ELSE 프로세스에 들어가려면 잘못된 비밀 값을 제공해야 한다는 것입니다.

물론 이것은 일반적인 시간 고정 지불을 나타내는 HTLC의 매우 기본적인 구현일 뿐입니다. 예를 들어 IF 프로세스에서 공개 키 확인을 제거하여 비밀 값 R을 아는 사람은 누구나 이 출력을 사용할 수 있도록 스크립트에 다른 조건을 얼마든지 추가할 수 있습니다. 미리 설정된 여러 개인 키의 서명을 잠금 해제할 수 있습니다.CHECKLOCKTIMEVERIFY여담으로, 이 경우 우리가 사용하는 opcode는CHECKSEQUENCEVERIFY, 이 opcode는 절대값을 사용하여 시간 잠금을 정의합니다. 즉, "이 출력은 블록 #546212까지 탭할 수 없습니다"와 같은 의미입니다. 라이트닝 네트워크에서는 또 다른 시간 잠금이 사용되며, 보다 "유연한" 것입니다.

, 상대 값을 사용합니다. 즉 "이 출력을 사용하는 트랜잭션이 온체인된 후 1000 블록 동안 사용할 수 없습니다." 사용).

라이트닝 네트워크 사례

그림

이미지 설명

그림

이미지 설명

- 라이트닝 네트워크의 지불 경로에 대한 단계별 분석 -
Eric은 비밀 값 R을 생성하고 해시를 Alice에게 보냅니다(그는 다른 사람에게 R을 공개하지 않음).
Alice는 이 해시 값을 사용하여 HTLC를 생성하고 다음 10블록으로 시간 잠금을 설정하고 출력량은 1.003btc입니다. 이 추가 0.003 btc는 결제 채널 체인의 중간 당사자에 대한 수수료입니다. 따라서 Alice는 이제 HTLC로 1.003 btc를 잠그고 HTCL의 특정 조건은 다음과 같이 평이한 언어로 표현됩니다. 앨리스에게 반환됩니다." 이 약정 트랜잭션으로 인해 그들 사이의 채널 균형도 변경됩니다. 이제 Bob은 채널에 2 btc, Alice는 0.997 btc, 1.003 btc는 HTLC에 잠겨 있습니다.
밥이 여기 오면 앨리스의 커밋 트랜잭션을 마음대로 처분할 수 있습니다(이 HTLC 트랜잭션은 둘 사이의 채널을 통해 전송됩니다). 그는 자신과 Carol 사이의 채널에 HTLC 출력을 생성하고 양은 1.002, 시간 잠금은 9 블록으로 설정하고 Alice가 제공하는 해시 값을 사용합니다. Bob은 Carol이 돈을 받고 싶다면 이 HTLC를 잠금 해제하기 위해 비밀 값 R을 찾아야 한다는 것을 알고 있습니다. 일단 그녀가 그렇게 하면 그는 이 R을 알게 될 것이므로 Alice의 HTLC를 잠금 해제하고 1.003 btc를 얻을 수도 있습니다. Carol이 이 비밀 값 R을 찾지 못하면 Bob과 Alice는 시간 잠금이 해제된 후 돈을 돌려받을 수 있습니다. Bob이 보낸 자금의 양은 그가 받을 수 있는 금액보다 0.001 btc 적었으며, 이는 그가 청구한 수수료 금액입니다. 채널에서 Bob과 Carol의 잔액은 다음과 같습니다. Carol은 2btc를 소유하고 Bob은 0.998 btc를 소유하며 1.002 btc는 HTLC에 고정됩니다.
Carol은 Bob이 보낸 커밋 트랜잭션을 얻은 후 동일한 작업을 수행하고 Bob이 제공한 것과 동일한 해시 값을 사용하여 시간 잠금을 8 블록으로 설정하고 금액은 1.001 btc인 Diana와의 채널에서 HTLC를 생성했습니다. Diana가 8 블록 내에서 비밀 값 R을 공개할 수 있다면 그녀는 HTLC를 잠금 해제하고 1.001 btc를 얻을 수 있으며, 이에 따라 Carol도 비밀 값을 알고 Bob이 그녀에게 준 HTLC를 잠금 해제하고 1.002 btc를 얻고 0.001 btc를 얻습니다. Carol과 Diana 채널의 잔액은 다음과 같습니다. Diana는 2btc를 소유하고 Carol은 0.999 btc를 소유하며 1.001 btc는 HTLC에 고정됩니다.
마지막으로 Diana가 채널을 통해 Eric에게 HTLC(잠금과 동일한 해시 값 사용)를 보낼 때 값을 1 btc로 설정하고 시간 잠금을 7 블록으로 설정합니다. Diana와 Eric의 채널 잔액은 다음과 같습니다. Eric은 2btc를 소유하고 Diana는 1 btc를 소유하며 1 btc는 HTLC에 고정됩니다.
이제 우리는 이 지불 방식의 끝에 도달했습니다. Eric은 이 비밀 값 R을 소유하고 있으며 이 R의 해시 값은 모든 HTLC 커밋 트랜잭션에 사용됩니다. Eric은 Diana가 보낸 HTLC를 잠금 해제하고 1 btc를 얻을 수 있으며 Eric이 자금을 돌려받은 후 Diana도 이 R을 알게 됩니다. Diana와 Eric 간의 채널 잔액은 다음과 같습니다. Eric은 3 btc를 소유하고 Diana는 1 btc를 소유합니다.
Diana는 비밀을 받은 후 Carol이 보낸 HTLC를 잠금 해제하는 데도 사용하여 1.001 btc를 얻고 비밀 값을 Carol에게 공개했습니다. 채널의 잔액은 다음과 같습니다. Diana는 3.001 btc, Carol은 0.999 btc입니다.
Carol은 비밀 값 R을 받은 후 Bob이 보낸 1.001 btc를 잠금 해제했기 때문에 Bob도 비밀 값을 알고 있었습니다. 채널의 잔액은 다음과 같습니다. Carol은 3.002 btc, Bob은 0.998 btc

결국 Bob은 비밀 값 R을 사용하여 Alice와의 채널에서 1.003 btc를 얻습니다. 따라서 채널의 잔액은 다음과 같습니다. Bob은 3.003 btc를 소유하고 Alice는 0.997을 소유합니다.

그런 과정을 거친 후 Alice는 그들 사이에 다른 직접 연결 채널을 열지 않고 Eric에게 1 btc를 지불했습니다. 전체 지불 체인에서 아무도 다른 사람을 신뢰할 필요가 없으며 중개 서비스로 인해 0.001 btc도 얻습니다. 어느 시점에서 결제가 중단되더라도 자금이 여전히 잠겨 있고 시간이 지나면 회수할 수 있기 때문에 아무도 손실을 입지 않습니다.

명확한 결함

이 예에서는 전체 프로세스가 원활하고 방해받지 않지만 실생활에서는 소위 "머피의 법칙"과 같습니다. 따라서 우리는 라이트닝 네트워크의 "보호" 메커니즘을 고려해야 합니다.

실용적인 관점에서 볼 때 지불 체인이 길수록 결국 자금이 전달되지 않을 가능성이 커집니다. 일부 참가자는 채널을 닫거나 일부 노드는 오프라인 상태가 됩니다. 두 가지 가능한 오류 시나리오를 고려해 보겠습니다.

그림

이미지 설명

- 채널이 폐쇄되어 자금을 전달할 수 없습니다 -

Diana는 비밀 값을 받으면 즉시 자금을 인출하고 비밀 값을 Carol에게 공개합니다. Carol도 Bob이 보낸 HTLC에서 자금을 돌려받기를 원하지만 Bob은 응답하지 않습니다.위험을 피하기 위해 그녀는 채널을 닫고 자신의 손에 있는 마지막 커밋된 트랜잭션(즉, Bob이 보낸 HTCL 출력)을 보냅니다. 거래 전) 비트코인 네트워크에 브로드캐스트하고 비밀 값을 알고 있기 때문에 자금을 돌려받을 수 있습니다. 이 시점에서 Bob은 여전히 3일 동안 Alice로부터 돈을 돌려받을 수 있습니다(Carol의 트랜잭션이 온체인에 있었기 때문에 Bob은 R의 가치를 쉽게 알 수 있습니다). 그렇지 않으면 Alice는 타임록이 잠금 해제되는 즉시 자금을 인출할 수 있습니다.

참가자가 어떤 이유로 네트워크를 떠나더라도 TA 자신만 자금을 잃을 수 있는 반면 다른 모든 사람의 자금은 안전하다는 것을 알 수 있습니다.

경로 변경

그림

이미지 설명

그림

이미지 설명

- 다른 경로를 사용하는 경우 Alice -

그림

이미지 설명

- Alice가 이전 결제를 "취소"하여 이제 새 결제를 안전하게 보낼 수 있습니다.

결제 금액

Alice가 첫 번째 지불을 "취소"했을 때 이제 새 지불을 시작하는 것이 안전하지만 이것이 그녀의 첫 번째 지불 자금이 여전히 잠겨 있다는 사실을 변경하지 않으며 충분한 돈이 없을 수 있습니다. 두 번째 지불을 시작합니다. 이것이 라이트닝 네트워크를 사용할 때 HTLC로 지불할 때 금액이 더 작아야 하는 이유입니다. 커밋 트랜잭션이 연결되지 않기 때문에 금액을 여러 개의 작은 금액으로 나눌 수 있습니다. 이러한 방식으로 경로가 실패할 때마다 자금의 작은 부분만 동결됩니다(즉, 마지막으로 전송된 것).

전송 프로토콜

라이트닝 네트워크의 또 다른 중요한 기능: 이 경로에 대한 모든 정보는 완전히 익명입니다. TA는 어느 참여자에게나 자신과 관련된 부분만 알고 있다는 뜻인데, 예를 들어 Carol의 경우 지불은 Bob이 Diana에게 돈을 이체하는 것과 같고 그녀는 Bob이 Alice에게서 돈을 이체할 것이라는 것을 알지 못합니다. Diana가 계속해서 Eric에게 자금을 이체할 것인지는 알려지지 않았습니다.

Lightning Network는 Sphinx 다중 암호화 프로토콜을 사용합니다. Lightning Network를 사용할 때 Alice는 지불 경로의 끝에서 시작하여 네트워크의 모든 부분에 암호화 계층을 적용합니다. 그녀는 Eric의 공개 키를 사용하여 Eric의 메시지를 암호화합니다. 이 암호화된 메시지는 Diana에게 보내는 메시지에 포함되며 전체 메시지는 Diana의 공개 키로 다시 암호화됩니다. 그런 다음 Diana에게 보내는 메시지는 Carol에게 보내는 메시지에 중첩되고 전체 메시지는 Carol의 공개 키로 다시 암호화됩니다. 이것을 반복하여 다음 사람에게 넘겨줄 수 있는 소식을 받아보세요. 이런 식으로 Bob은 메시지의 가장 바깥쪽 계층만 해독하고 자신을 위한 콘텐츠를 가져온 다음 메시지를 Carol에게 전달할 수 있습니다. Carol도 같은 작업을 수행합니다. 지나가는 사람마다 지불 금액, 커미션 금액, 타임 락 내용 등 절대적으로 필요한 정보만 공개됩니다.

사람들이 메시지의 길이에서 사슬의 길이를 유추하지 않도록 하기 위해 메시지의 길이는 항상 동일합니다. 마치 사슬에 20명이 참여하는 것처럼 말입니다. 마지막 사람을 포함하여 모두가 같은 크기의 이미지를 얻습니다. 자신 외에 20명의 다른 사람이 있다고 생각합니다.

Lightning Network의 이점 및 적용 시나리오

물론 라이트닝 네트워크의 이점은 많은 사람들이 생각하는 것처럼 확장성만 있는 것은 아닙니다. 라이트닝 네트워크가 가져올 가능성에 대해 생각해 봅시다.
즉각적인 거래. 라이트닝 네트워크를 사용하면 거래가 거의 즉각적으로 이루어집니다. 그래서 비트코인으로 커피를 사는 것이 가능해졌습니다.
교환 차익 거래. 현재 한 거래소에서 다른 거래소로 자금을 이체하고 거래가 확인될 때까지 3~6 블록을 기다리는 것이 불편합니다. 거래소에서 라이트닝 네트워크를 사용할 수 있다면 사용자는 즉시 자금을 이체하고 차익 거래에 참여할 수 있습니다. 또한 거래소는 자금을 저장하기 위해 더 이상 콜드 월렛이 필요하지 않으므로 도난 위험이 크게 줄어듭니다.
소액 결제. 소액 결제에는 비트코인 블록체인 수수료가 너무 높습니다. 같은 금액 또는 그보다 적은 금액을 이체하기 위해 0.001 btc를 기꺼이 지불하는 사람은 상상하기 어렵습니다. 라이트닝 네트워크를 사용하면 원하는 금액을 즉시 이체할 수 있습니다. 예를 들어 네트워크 수수료를 MB 단위로 지불할 수 있습니다.
금융 스마트 계약 및 거래. 금융 계약은 대기 시간에 매우 민감하며 종종 많은 계산이 필요합니다. 대부분의 부담을 블록체인에서 제거함으로써 우리는 블록체인에 모든 것을 기록하지 않고도 매우 복잡한 거래 및 계약을 생성할 수 있는 기회를 갖게 됩니다.
은둔. 라이트닝 네트워크에서 거래는 비트코인 블록체인보다 더 비공개적입니다. 결제 체인의 참가자가 거래의 출처와 목적지를 모르기 때문입니다.