1여 년 전, 세 개의 Lightning Network 구현 팀이 협업하여 프로토콜 스택에 대한 공통 사양을 연구했습니다. 이제 그 사양과 Blockstream의 세 가지 구현이 모두 안정되고 사용 가능해졌기 때문에 프로토콜을 보다 개선하고, 새로운 기능을 추가하고, 간소화하고, 단점을 수정할 일만 남았습니다.
애초에 Lightning을 가능케 한 핵심 혁신 기술 중 하나는 새로운 상태(state)를 재협상하고 이전(old) 상태는 온체인으로 지불될 수 없도록 하는 오프체인 업데이트 메커니즘이었습니다. 이제, 우리는 새롭고 간소화된 레이어 2 프로토콜 eltoo의 업데이트 메커니즘에 대한 Blockstream의 최신 연구 논문을 발표하게 되어 기쁩니다.
eltoo의 운영 방식은?
오프체인 협상은 다수의 당사자들과 맺은 계약 협정으로, 지불은 최종 상태를 결정할 법원(이 경우 법원은 블록체인)에 사건을 제출하는 것으로 간주할 수 있습니다. 모든 업데이트는 오프체인으로 이루어지기 때문에, 온체인 법원이 최종 판결을 내리기 전에 논쟁의 모든 측면을 들을 수 있도록 해야 합니다. 한 참가자가 해당 계약의 정산을 시작하는 경우, 상대방에게 더욱 최신 상태를 제공할 기회를 주기 위해 최종 결제를 연기하는 매커니즘이 필요합니다. 법원은 결국 마지막으로 들은 상태를 지불하도록 결정할 때까지 새로운 상태를 계속 기다려야합니다. 놀랍게도, 레이어 2 프로토콜에 맞춰 제작된 이 블록체인을 생성하기 위한 대부분의 요구 조건은 이미 비트코인 블록체인으로 충족됩니다.
그림 1: 나중의 업데이트 거래를 이전 거래로 리바인드 하거나 설정 거래로 직접 리바인드하여 중간 상태를 건너 뛸 수 있는 방법을 보여주는 eltoo 프로토콜의 실행 사례. 블록체인에서는 마지막 정산 거래만 확인할 수 있음.
eltoo에서 모든 상태는 두 가지 거래 세트(계약의 아웃풋을 사용하고 새로운 아웃풋을 생성하는 업데이트 거래, 새로 생성된 업데이트 아웃풋을 사용하고 합의된 분배 방식에 따라 자금을 분할하는 정산 거래)로 나타납니다. 아웃풋에는 새로운 업데이트 거래를 즉시 첨부하거나 설정 가능한 시간 초과(timeout) 이후 정산 거래를 첨부할 수 있는 스크립트가 있습니다. 참가자가 시간 초과가 만료되기 전에 업데이트에 동의하면 이전 아웃풋을 사용하고 해당 결제를 이중 사용하여 새로운 업데이트 거래를 생성함으로써 이를 실질적으로 무효화합니다.
새로운 상태에 동의하기 위해 이전 상태를 반복적으로 무효화하면 긴 업데이트 거래 체인이 생성되고, 이는 결국 최신 정산 거래에 의해 종료될 것입니다. 그러나 여기에는 큰 단점이 있습니다. 정산을 하려면 블록체인에서 업데이트의 전체 체인을 리플레이해야 한다는 것입니다. 그 시점에서는 전체 프로토콜을 온체인으로 간단히 수행할 수 있었을 것입니다. eltoo의 핵심은 무엇보다도 최종 업데이트 거래를 계약 생성에 연결하며 중간 업데이트를 건너 뛸 수 있다는 것입니다. 이러한 업데이트의 단락 회로를 가능케 하기 위해, Blockstream은 일치하는 스크립트를 사용하여 거래 인풋을 거래 아웃풋에 바인딩할 수 있는 새로운 SIGHASH 플래그인 SIGHASH_NOINPUT을 제안합니다. 이전 업데이트-거래 아웃풋의 모든 아웃풋 스크립트는 이후의 인풋 스크립트와 일치하기 때문에 이후 업데이트를 모든 이전 업데이트에 바인딩할 수 있고, 따라서 중간 업데이트는 얼마든지 건너 뛸 수 있습니다. 이 보고서에는 스크립트 작성 방법에 대한 자세한 정보 등 프로토콜의 전체적인 구축 내용이 포함되어 있습니다.
Lightning 개선
위에서 제시한 것은 지불 채널의 엔드포인트가 반복적으로 잔액을 조정하고 HTLC 같이 보다 복잡한 구조를 해당 상태에 연결할 수 있는 업데이트 메커니즘입니다.
Lightning 원문 보고서의 주요 목적은 이러한 업데이트 메커니즘이었는데, 그렇다면 Blockstream은 Lightning을 이 제안으로 대체하려 하는 걸까요? 절대 그렇지 않습니다!
그림 2: Lightning Stack의 일부인 다양한 하위 프로토콜을 보여주는 다이어그램.
Lightning Network 사양은 더 이상 단일 프로토콜의 사양이 아니라 프로토콜의 전체 스택으로, 각각 고유한 책임을 수행합니다. eltoo의 목적은 Lightning 스택 전체를 대체하는 것이 아닙니다. 오히려, 스택의 다른 부분과 하위 호환성을 유지하는 원래의 업데이트 메커니즘에 대한 드롭인 대체품(drop-in replacement)입니다.
eltoo는 Lightning 원문 보고서에 제시된 메커니즘과는 근본적으로 다른 트레이드오프를 가지고 있습니다. 이를 LN-페널티라 부르겠습니다. LN-페널티는 부정 행위를 하는 당사자를 처벌하기 위해 페널티 시스템을 사용하는 반면, eltoo는 단순히 오프체인 계약의 합의된 최신 상태를 시행합니다. 이는 업데이트 메커니즘 위에 구축된 프로토콜의 적용 가능성과 안전성에 중요한 영향을 미칩니다.
이 가운데 일부는 부정 행위를 하는 당사자에 대한 대응을 조정하려면 eltoo에서는 모든 참가자들이 공통의 거래 세트를 공유한다는 사실에서 기인합니다. 이는 참가자가 거래에 액세스할 수 있는 비대칭성이 필요한 LN-페널티와는 대조적입니다. 이러한 변화로 인해 Lightning에서 유독한 정보라 불리는 것이 제거되었습니다. 유독한 정보는 구식 상태의 거래에서 비롯되고, 이것이 유출되면 자금 손실이 발생할 수 있습니다. 자금 손실은 당사자가 부정행위를 하는 경우뿐만 아니라 노드가 업데이트되지 않은 경우(예: 백업에서 복원할 때)에도 발생합니다. eltoo를 사용하면 합의된 상태만 정산할 수 있기 때문에 자금 손실은 더 이상 발생하지 않습니다 (즉, eltoo는 페널티가 없습니다).
이러한 새로운 패러다임에서는 참가자 데이터 관리도 간소화되었습니다. 더 이상 무효화 상태에 대한 해시 역상(preimage)을 저장할 필요가 없고, 연결되었던 정산 결제는 절대로 블록체인에 할당될 수 없기 때문에 무효화되었던 HTLC도 더 이상 저장할 필요가 없습니다. 저장이 필요한 것은 오직 최신 업데이트 거래, 해당 정산 거래, 해당 정산에서 사용하는 HTLC 뿐입니다. 또한 최신 업데이트 거래를 단순히 설정 아웃풋에 바인딩하고 정산 거래를 전송하기 전에 시간 초과를 만료시키도록 정산이 간소화되었습니다.
업데이트 아웃풋은 SIGHASH_SINGLE과 결합시킴으로써 정산 시점에 추가 인풋과 아웃풋을 업데이트 거래에 첨부할 수 있습니다. 이러한 변화가 중요치 않게 보일 수 있지만, 정산 시점에 업데이트 거래에 수수료를 첨부할 수 있어 미리 고정된 수수료를 지불할 필요가 없습니다. 현재의 구현에서는 거래를 온체인으로 확인하기 몇 달 전부터 고정 수수료에 동의하고 지불을 약속하기 때문에 수수료 시장의 변동을 예측해야만 합니다. 따라서 신중을 기하려다 엄청나게 과도한 수수료 계약으로 이어질 수도 있습니다. 수수료 거치를 선택하면 더 이상 수수료에 대해 동의할 필요가 없고, 수수료가 불충분한 것으로 확인될 경우에는 금액을 올릴 수도 있습니다.
노드가 피어(peer)에 처음 연결할 때 새로운 기능에 대한 지원을 신호로 보낼 수 있도록 하는 기능 플래그 덕분에 오늘날 네트워크 상에 eltoo를 점차적으로 도입할 수 있습니다. 완전히 새로운 네트워크를 가동시킬 필요가 없습니다.
Lightning 외의 활용
일반적인 레이어 2 업데이트 메커니즘인 eltoo는 Lightning 외의 다른 시스템에도 얼마든지 사용될 수 있습니다. 예를 들어, 현재 최대 일곱 명까지 참여할 수 있는, Schnorr 서명과 함께 사용하면 더 많은 사람들이 참여할 수 있는 다자간 오프체인 계약을 작성할 수 있습니다.
이러한 다자간 오프체인 계약 중 하나는 Burchert et al.이 제시한 채널 팩토리로, 단일 온체인 거래 외에 수많은 결제 채널에 자금을 지원하고 블록체인을 건드리지 않고도 결제 채널을 역동적으로 재정산(rebalance) 또는 재할당(reallocate)할 수 있는 확장 가능한 방법입니다.
eltoo의 구현
eltoo를 구현하려면 비트코인에 약간의 변화가 필요합니다: 서명에 SIGHASH_NOINPUT 플래그를 도입하는 것입니다. 이는 몇 달 전 Lightning 채널 보안을 위한 와치타워(watchtower)와 관련하여 처음 논의되었지만 공식적으로 제안되지는 않았습니다. 이제 공식 제안은 eltoo 보고서에서 확인하실 수 있습니다.
Blockstream은 커뮤니티가 이러한 제안을 고려하고 관련 토론에 참여하길 바랍니다. SIGHASH_NOINPUT의 사용에 대한 합의에 도달하여 향후 비트코인 스크립트의 소프트 포크에 받아들여지고 포함되기를 바랍니다. 그렇게 하면 더 많은 응용 프로그램에 사용할 수 있는 새로운 업데이트 메커니즘을 통합하여 Lightning Network를 보다 안정적이고 간단하게 만들 수 있을 것입니다.
1여 년 전, 세 개의 Lightning Network 구현 팀이 협업하여 프로토콜 스택에 대한 공통 사양을 연구했습니다. 이제 그 사양과 Blockstream의 세 가지 구현이 모두 안정되고 사용 가능해졌기 때문에 프로토콜을 보다 개선하고, 새로운 기능을 추가하고, 간소화하고, 단점을 수정할 일만 남았습니다.
애초에 Lightning을 가능케 한 핵심 혁신 기술 중 하나는 새로운 상태(state)를 재협상하고 이전(old) 상태는 온체인으로 지불될 수 없도록 하는 오프체인 업데이트 메커니즘이었습니다. 이제, 우리는 새롭고 간소화된 레이어 2 프로토콜 eltoo의 업데이트 메커니즘에 대한 Blockstream의 최신 연구 논문을 발표하게 되어 기쁩니다.
eltoo의 운영 방식은?
오프체인 협상은 다수의 당사자들과 맺은 계약 협정으로, 지불은 최종 상태를 결정할 법원(이 경우 법원은 블록체인)에 사건을 제출하는 것으로 간주할 수 있습니다. 모든 업데이트는 오프체인으로 이루어지기 때문에, 온체인 법원이 최종 판결을 내리기 전에 논쟁의 모든 측면을 들을 수 있도록 해야 합니다. 한 참가자가 해당 계약의 정산을 시작하는 경우, 상대방에게 더욱 최신 상태를 제공할 기회를 주기 위해 최종 결제를 연기하는 매커니즘이 필요합니다. 법원은 결국 마지막으로 들은 상태를 지불하도록 결정할 때까지 새로운 상태를 계속 기다려야합니다. 놀랍게도, 레이어 2 프로토콜에 맞춰 제작된 이 블록체인을 생성하기 위한 대부분의 요구 조건은 이미 비트코인 블록체인으로 충족됩니다.
그림 1: 나중의 업데이트 거래를 이전 거래로 리바인드 하거나 설정 거래로 직접 리바인드하여 중간 상태를 건너 뛸 수 있는 방법을 보여주는 eltoo 프로토콜의 실행 사례. 블록체인에서는 마지막 정산 거래만 확인할 수 있음.
eltoo에서 모든 상태는 두 가지 거래 세트(계약의 아웃풋을 사용하고 새로운 아웃풋을 생성하는 업데이트 거래, 새로 생성된 업데이트 아웃풋을 사용하고 합의된 분배 방식에 따라 자금을 분할하는 정산 거래)로 나타납니다. 아웃풋에는 새로운 업데이트 거래를 즉시 첨부하거나 설정 가능한 시간 초과(timeout) 이후 정산 거래를 첨부할 수 있는 스크립트가 있습니다. 참가자가 시간 초과가 만료되기 전에 업데이트에 동의하면 이전 아웃풋을 사용하고 해당 결제를 이중 사용하여 새로운 업데이트 거래를 생성함으로써 이를 실질적으로 무효화합니다.
새로운 상태에 동의하기 위해 이전 상태를 반복적으로 무효화하면 긴 업데이트 거래 체인이 생성되고, 이는 결국 최신 정산 거래에 의해 종료될 것입니다. 그러나 여기에는 큰 단점이 있습니다. 정산을 하려면 블록체인에서 업데이트의 전체 체인을 리플레이해야 한다는 것입니다. 그 시점에서는 전체 프로토콜을 온체인으로 간단히 수행할 수 있었을 것입니다. eltoo의 핵심은 무엇보다도 최종 업데이트 거래를 계약 생성에 연결하며 중간 업데이트를 건너 뛸 수 있다는 것입니다. 이러한 업데이트의 단락 회로를 가능케 하기 위해, Blockstream은 일치하는 스크립트를 사용하여 거래 인풋을 거래 아웃풋에 바인딩할 수 있는 새로운 SIGHASH 플래그인 SIGHASH_NOINPUT을 제안합니다. 이전 업데이트-거래 아웃풋의 모든 아웃풋 스크립트는 이후의 인풋 스크립트와 일치하기 때문에 이후 업데이트를 모든 이전 업데이트에 바인딩할 수 있고, 따라서 중간 업데이트는 얼마든지 건너 뛸 수 있습니다. 이 보고서에는 스크립트 작성 방법에 대한 자세한 정보 등 프로토콜의 전체적인 구축 내용이 포함되어 있습니다.
Lightning 개선
위에서 제시한 것은 지불 채널의 엔드포인트가 반복적으로 잔액을 조정하고 HTLC 같이 보다 복잡한 구조를 해당 상태에 연결할 수 있는 업데이트 메커니즘입니다.
Lightning 원문 보고서의 주요 목적은 이러한 업데이트 메커니즘이었는데, 그렇다면 Blockstream은 Lightning을 이 제안으로 대체하려 하는 걸까요? 절대 그렇지 않습니다!
그림 2: Lightning Stack의 일부인 다양한 하위 프로토콜을 보여주는 다이어그램.
Lightning Network 사양은 더 이상 단일 프로토콜의 사양이 아니라 프로토콜의 전체 스택으로, 각각 고유한 책임을 수행합니다. eltoo의 목적은 Lightning 스택 전체를 대체하는 것이 아닙니다. 오히려, 스택의 다른 부분과 하위 호환성을 유지하는 원래의 업데이트 메커니즘에 대한 드롭인 대체품(drop-in replacement)입니다.
eltoo는 Lightning 원문 보고서에 제시된 메커니즘과는 근본적으로 다른 트레이드오프를 가지고 있습니다. 이를 LN-페널티라 부르겠습니다. LN-페널티는 부정 행위를 하는 당사자를 처벌하기 위해 페널티 시스템을 사용하는 반면, eltoo는 단순히 오프체인 계약의 합의된 최신 상태를 시행합니다. 이는 업데이트 메커니즘 위에 구축된 프로토콜의 적용 가능성과 안전성에 중요한 영향을 미칩니다.
이 가운데 일부는 부정 행위를 하는 당사자에 대한 대응을 조정하려면 eltoo에서는 모든 참가자들이 공통의 거래 세트를 공유한다는 사실에서 기인합니다. 이는 참가자가 거래에 액세스할 수 있는 비대칭성이 필요한 LN-페널티와는 대조적입니다. 이러한 변화로 인해 Lightning에서 유독한 정보라 불리는 것이 제거되었습니다. 유독한 정보는 구식 상태의 거래에서 비롯되고, 이것이 유출되면 자금 손실이 발생할 수 있습니다. 자금 손실은 당사자가 부정행위를 하는 경우뿐만 아니라 노드가 업데이트되지 않은 경우(예: 백업에서 복원할 때)에도 발생합니다. eltoo를 사용하면 합의된 상태만 정산할 수 있기 때문에 자금 손실은 더 이상 발생하지 않습니다 (즉, eltoo는 페널티가 없습니다).
이러한 새로운 패러다임에서는 참가자 데이터 관리도 간소화되었습니다. 더 이상 무효화 상태에 대한 해시 역상(preimage)을 저장할 필요가 없고, 연결되었던 정산 결제는 절대로 블록체인에 할당될 수 없기 때문에 무효화되었던 HTLC도 더 이상 저장할 필요가 없습니다. 저장이 필요한 것은 오직 최신 업데이트 거래, 해당 정산 거래, 해당 정산에서 사용하는 HTLC 뿐입니다. 또한 최신 업데이트 거래를 단순히 설정 아웃풋에 바인딩하고 정산 거래를 전송하기 전에 시간 초과를 만료시키도록 정산이 간소화되었습니다.
업데이트 아웃풋은 SIGHASH_SINGLE과 결합시킴으로써 정산 시점에 추가 인풋과 아웃풋을 업데이트 거래에 첨부할 수 있습니다. 이러한 변화가 중요치 않게 보일 수 있지만, 정산 시점에 업데이트 거래에 수수료를 첨부할 수 있어 미리 고정된 수수료를 지불할 필요가 없습니다. 현재의 구현에서는 거래를 온체인으로 확인하기 몇 달 전부터 고정 수수료에 동의하고 지불을 약속하기 때문에 수수료 시장의 변동을 예측해야만 합니다. 따라서 신중을 기하려다 엄청나게 과도한 수수료 계약으로 이어질 수도 있습니다. 수수료 거치를 선택하면 더 이상 수수료에 대해 동의할 필요가 없고, 수수료가 불충분한 것으로 확인될 경우에는 금액을 올릴 수도 있습니다.
노드가 피어(peer)에 처음 연결할 때 새로운 기능에 대한 지원을 신호로 보낼 수 있도록 하는 기능 플래그 덕분에 오늘날 네트워크 상에 eltoo를 점차적으로 도입할 수 있습니다. 완전히 새로운 네트워크를 가동시킬 필요가 없습니다.
Lightning 외의 활용
일반적인 레이어 2 업데이트 메커니즘인 eltoo는 Lightning 외의 다른 시스템에도 얼마든지 사용될 수 있습니다. 예를 들어, 현재 최대 일곱 명까지 참여할 수 있는, Schnorr 서명과 함께 사용하면 더 많은 사람들이 참여할 수 있는 다자간 오프체인 계약을 작성할 수 있습니다.
이러한 다자간 오프체인 계약 중 하나는 Burchert et al.이 제시한 채널 팩토리로, 단일 온체인 거래 외에 수많은 결제 채널에 자금을 지원하고 블록체인을 건드리지 않고도 결제 채널을 역동적으로 재정산(rebalance) 또는 재할당(reallocate)할 수 있는 확장 가능한 방법입니다.
eltoo의 구현
eltoo를 구현하려면 비트코인에 약간의 변화가 필요합니다: 서명에 SIGHASH_NOINPUT 플래그를 도입하는 것입니다. 이는 몇 달 전 Lightning 채널 보안을 위한 와치타워(watchtower)와 관련하여 처음 논의되었지만 공식적으로 제안되지는 않았습니다. 이제 공식 제안은 eltoo 보고서에서 확인하실 수 있습니다.
Blockstream은 커뮤니티가 이러한 제안을 고려하고 관련 토론에 참여하길 바랍니다. SIGHASH_NOINPUT의 사용에 대한 합의에 도달하여 향후 비트코인 스크립트의 소프트 포크에 받아들여지고 포함되기를 바랍니다. 그렇게 하면 더 많은 응용 프로그램에 사용할 수 있는 새로운 업데이트 메커니즘을 통합하여 Lightning Network를 보다 안정적이고 간단하게 만들 수 있을 것입니