저자: AdamISZ
출처: https://reyify.com/blog/lightning-unchained/
원문은 2025년 2월에 발표되었습니다.
라이트닝 네트워크에는 엔지니어들 사이에서는 널리 알려진 문제점이 하나 있는데, 사용자나 지갑 개발자들은 아마 고려조차 하지 않았을 겁니다(혹시 고려했을 수도 있고, 제가 틀렸기를 바랍니다!). 바로 라이트닝 네트워크 사용자들은 채널을 개설할 때 사용하는 UTXO를 공개적으로 노출해야 한다는 점입니다. 만약 이런 공개 의무가 없다면 사용자 개인정보 보호가 얼마나 더 강화될지 상상해 보세요.
라이트닝 네트워크의 온체인 취약점
이를 명확하게 설명하기 위해 잠시 다른 이야기를 해보겠습니다. 라이트닝 네트워크 작동 방식의 중요한 측면을 소개하는 것이 필요합니다. 먼저 short-channel-id 라는 것부터 시작해 보겠습니다.
" 채널 단축 ID "는 UTXO를 인코딩하는 8바이트 문자열입니다. 비트코인 프로토콜에서 UTXO는 (outpoint, index) 튜플로 표현될 수 있는데, 여기서 "출력 지점"은 UTXO를 생성한 트랜잭션의 식별자(txid)이고, "인덱스"는 해당 트랜잭션 출력 내에서 UTXO의 위치입니다. 이 방법은 모호성을 방지하지만 36바이트(32 + 4)를 사용합니다(인덱스를 나타내는 데 4바이트를 사용하는 것은 다소 과하지만, 일반적으로 통용되는 방식입니다). 나중에 살펴보겠지만, 라이트닝 네트워크 프로토콜 설계자들은 36바이트가 아닌 8바이트만을 사용하는 더욱 효율적인 인코딩 방식을 고안했습니다. 8바이트만 필요한 이유가 궁금하다면, UTXO를 식별하는 데 필요한 정보가 무엇인지 생각해 보세요. UTXO를 생성하는 데 필요한 정보는 블록 번호(UTXO가 생성된 블록), 트랜잭션 번호(블록에는 트랜잭션의 순서 목록이 포함됨), 그리고 트랜잭션 출력 중 하나입니다. 이 세 정수 각각에는 최댓값이 있으므로 각 정수에 대해 적절한 인코딩(각각 3, 3, 2바이트 사용)을 사용할 수 있습니다.
这样做有啥意思呢？来，我们再回想一下。“闪电网络”，我常常说，有两部分。第一部分是“闪电（通道）”，意味着两方之间的Poon-Dryja 式支付通道；第二部分是“网络”，意味着在多条首尾连接的通道（货币通路）中强制执行的哈希时间锁合约（HTLC）。这里的第二部分—— “网络” —— 就是关键。为了构造通路，你需要先知道这些通道存在（甚至还有更难的，你必须知道或者猜测这些通道内、在你需要的方向上，有多少잔액可用！）。为此，你必须让别人告诉你它们存在。这就是为什么我们要有“闪电网络gossip 协议”，这些消息中的绝大部分，都是在告诉对等节点：某些通道存在。
문제는 이겁니다. 상호 불신이 만연한 환경에서는 사람들이 거짓말을 할 수 있습니다. "나는 얼마든지 지어낼 수 있어. 1 BTC씩 송금할 수 있는 채널 1만 개를 찾았어. 여기 전체 목록이 있으니 직접 찾아봐…" 이런 식으로 말이죠. 이렇게 하면 시간 낭비만 되고 CPU가 쓸데없는 작업을 하게 될 뿐입니다. 결국에는 이 지도에 따라 "네트워크"에서 송금을 시도할 때마다 실패하는, 완전히 쓸모없는 채널 지도만 남게 될 수도 있습니다.
따라서 우리는 채널 단축 ID를 사용했습니다. 앞서 언급했듯이 이는 UTXO를 간결하게 표현한 것입니다. UTXO는 생성하는 데 비용이 듭니다. 블록체인 내 거래 수수료가 매우 낮을 때는 UTXO 하나를 생성하는 데 1~2 사토시/vB밖에 들지 않지만(오늘날 환율로 약 10~30센트), 생성하는 UTXO의 수가 늘어날수록 비용은 선형적으로 증가합니다. 게다가 10만 개의 UTXO를 빠르게 생성하려면 비용이 무한대가 될 수도 있습니다.
이는 잘 논의되지 않지만 매우 중요한 점이라고 생각합니다. 비트코인의 극도로 높은 해시율은 UTXO 생성 속도(초당 생성 가능한 UTXO 출력 수)를 자연스럽게 늦추어 UTXO 생성 비용을 비선형적일 뿐만 아니라 거의 특이점 한계에 가깝게 만듭니다. 이는 바로 공공 서비스를 구축할 때 필요한 강력한 DoS 공격 방어 수단입니다.
이제 질문에 답할 수 있습니다. UTXO는 브로드캐스트해야 하므로 압축적으로 인코딩해야 합니다. 채널이 10,000개 또는 100,000개에 달하는 경우, 전송해야 할 UTXO 데이터의 양이 엄청나게 많아지고, 각 UTXO가 36바이트를 필요로 한다면 현재(짧은 채널 ID 사용)보다 상황이 훨씬 악화될 것입니다.
문제 상세 내용
문제는 한마디로 '프라이버시'입니다. 전체 네트워크에 UTXO 보유량을 공개하는 것은 전 세계에 알리는 것과 마찬가지입니다. 특히 공개된 평문 IPv4/6 네트워크 주소를 통해 공개하는 경우(실제로 많은 "진지한" 노드들이 이렇게 합니다) 더욱 그렇습니다. 이는 사실상 스파이들이 블록체인 내에서의 활동을 분석하도록 유도하는 것과 같습니다. 사업상 리스크 은 아닐지라도, 보안상 심각한 리스크 입니다. 이러한 정보는 IP 주소와 같은 다른 정보와 교차 분석되어 사용자의 신원, 거주지, 보유 비트코인량 등을 파악하는 데 사용될 수 있습니다.
본질적으로 이것은 P2P 네트워크에서 흔히 발생하는 갈등의 또 다른 사례입니다. "흔한 갈등"이란 무엇일까요? 아주 간단합니다.
개방형 P2P 네트워크에서 자원을 보호하려면 시빌 공격에 대한 방어가 필요한데, 이는 사용자의 익명성 추구와 상충됩니다.
(역자 주: "시빌 공격"은 공격자가 손쉽게 여러 개의 신분을 만들어 피해자의 자원을 고갈시키는 행위를 의미하며, 이전 번역에서는 문자 그대로 "Sybil어택 공격"으로 번역되었습니다.)
이런 종류의 "일반적인 갈등"에 대한 "일반적인 해결책"이 있다면, 제 생각에는 사용자들이 P2P 네트워크 참여를 위해 희소한 자원을 사용하도록 요구하는 것입니다. (또 다른 "해결책"은 익명성을 강제하지 않는 것이지만, 이는 취약한 방법이며 결국 실패할 것입니다. - 이는 순전히 제 개인적인 관점 이지만, 바로 관점 때문에 자유롭게 공유하셔도 좋습니다.)
이러한 갈등과 해결 과정은 최근 토르 네트워크 서비스 중단 사태에서도 나타났습니다. 클론 서버들이 대량 리소스를 소모했고, 해결책은 작업증명(Proof-of-Work)이었습니다. 계산 루프 기반의 작업증명이 이 문제를 실제로 해결할 수 있을지는 나중에 다시 논의하도록 하겠습니다. 오늘은 라이트닝 네트워크의 가십 문제로 돌아가고 싶습니다!
좋습니다. 짧은 채널 ID는 UTXO를 바로 드러낼 겁니다. 이건 좋지 않다는 건 이미 알고 있죠. 그럼 어떻게 해야 할까요? 적어도 이렇게라도 해볼 수 있겠습니다.
저는 채널을 하나 가지고 있습니다. 제가 그 채널을 여는 데 사용한 UTXO의 가치가 X 사토시(또는 최소한 X 사토시)라는 것을 증명할 준비가 되어 있지만, 그 정도의 사토시를 가진 채널이 제 것인지는 알려드릴 생각이 없습니다.
우선 이 아이디어는 매우 매력적이지만, 영지식 증명(ZKP)에 익숙하지 않은 사람들에게는 다소 황당하게 들릴 수도 있습니다. 영지식 증명에 대해 자세히 알아보기 전에, 꽤 흥미로운 논리 문제를 하나 풀어보겠습니다.
UTXO가 실제로 채널을 여는 데 사용되었는지 여부는 공개적으로 알려진 사실인가요? 현재 P2WSH 출력을 사용하여 채널을 여는 시나리오에서는, 명백한 표시가 있더라도 채널을 닫을 때조차 이 사실이 드러나지 않습니다(라이트닝 네트워크 엔지니어 여러분, 제 의견에 오류가 있다면 언제든지 지적해 주시기 바랍니다). 탭루트 채널의 경우, 적어도 MuSig2의 개발 상황을 고려하면, 채널이 2-2 멀티시그니처로 생성되었다는 사실조차 드러내지 않을 것이며, 더 나아가 채널이라는 사실조차 드러내지 않을 것으로 예상됩니다. 다시 한번 말씀드리지만, 이 논의는 DoS 공격을 방지하기 위한 비용 부과에 관한 것이므로, "이것이 채널이다"라는 것을 증명하려는 시도는 본질에서 벗어난 것입니다. UTXO 소유권을 증명하는 것으로 충분합니다.
（不同意？没问题，我们想得再仔细一些。我声称存在一条通道，我公开它（或者说gossip 它）。为了支持我的声明，我给出一个通道短ID；这个通道短ID 指向区块链内的一个真实的UTXO ，但你怎么知道这个UTXO 真的指向一条通道呢？如果我就是要说谎，我只需要让这个UTXO “看起来像是一条通道”。如我们前面所说的，在有些情况下，所有的UTXO 看起来都会像通道（使用taproot 输出、MuSig2 得到广泛采用）。甚至，作为一个攻击者，我可以真的制作出一条真实的通道，然后让它完全不工作而不违反协议要求。在gossip 消息中使用通道短ID 来“证明一条通道” 的最终意义，只是“证明我创造了一个UTXO”。）
하지만 이 부분은 좀 더 자세히 논의해 볼 수 있습니다. 누가 비용을 부담해야 하며, 어떤 행동이 비용을 부담해야 할까요? 러스티 러셀은 이전 글에서 채널 레벨이 아닌 노드 레벨에서 비용을 부과하는 방안을 제안했습니다. (제가 거의 알지 못하는) 기술적인 어려움이 있긴 하지만, 제가 이 관점에 동의하는 주된 이유는 비용을 자신에게 이익이 되는 자원과 분리함으로써 각 채널의 실제 프라이버시를 더욱 향상시킬 수 있기 때문입니다. (예를 들어, 매우 큰 용량의 채널을 생성한 후 즉시 해당 채널의 존재를 증명하는 영지식 증명을 게시한다고 가정해 보겠습니다. 이는 "나는 최소 2 BTC 용량의 채널을 소유하고 있음을 증명한다"는 의미이지만, 바로 그 순간 2.2 BTC 상당의 UTXO가 온체인 나타납니다. 이는 단지 예시일 뿐이며, 제 말뜻을 이해하실 수 있을 것입니다.)
하지만 이야기는 여기서 끝나지 않습니다. "이 채널은 UTXO 채널일까요, 아닐까요?" 이 블로그의 댓글 섹션에서 더 자세한 내용을 확인할 수 있습니다.
네, 유용하다는 건 인정합니다. 하지만 ZKP 같은 걸로 그게 가능하기는 할까요?
그렇다면, 그것은 실제로 가능한 것일까요? 요약하자면, 우리가 증명해야 할 것은 다음과 같습니다.
특정 범위 내의 액면가를 가진 기존 UTXO 중 하나가 제 것입니다. 이것은 주계열 채널이라고 추측할 수 있지만, 그렇다고 "채널 유형"이 제한되는 것은 아닙니다(이상적으로는 유형을 알 필요조차 없습니다). 하지만 정확히 어떤 채널인지는 알려드리지 않겠습니다.
하지만 합리적인 범위 내에서 UTXO는 수십만 개에서 수천만 개에 이를 수도 있습니다. 과연 이것이 가능할까요? 당연히 그렇게 간단한 문제는 아닙니다.
저는 이 문제를 3년 동안 연구해 왔습니다. (물론, 라이트닝 네트워크에만 집중하는 것이 아니라 일반적인 개인정보 보호 및 스푸핑 방지 솔루션에 초점을 맞추고 있습니다.) 처음에는 "링 서명"에 집중했는데, 그러한 구조가 존재한다는 것을 알았지만 (증거의) 용량은 O(log N) (바이트 단위)일 가능성이 높았습니다. 문제는 증거 검증 시간과 계산 시간 모두 O(N)이라는 점입니다. 불릿프루프(Bulletproof) 역시 같은 문제를 가지고 있습니다. 유일한 문제는 머클 트리(Merkle tree)인데, 이는 앤드류 포엘스트라(Andrew Poelstra)가 제게 알려준 아이디어로, 머클 트리 증거의 검증 시간이 O(log N)이라는 것입니다. 거의 같은 시기(2022년)에 "커브 트리 (curve tree)"가 등장하여 이 두 가지를 결합했습니다. 불릿프루프를 사용하여 압축된 증거를 생성한 다음, (매우 특수한 secp-secq 곡선 루프를 사용하는) 머클 트리의 대수적 버전을 사용하여 검증 시간을 로그 스케일링할 수 있습니다. 실질적으로, 100만 개의 UTXO 세트에 대해 50~100밀리초 내에 증거를 검증할 수 있고( 제 코드 로 가능하며, 훨씬 더 빠를 것입니다!), 1~2초 내에 2~3kB 크기의 증거를 생성할 수 있습니다. 이 증거는 " 나는 이 100만 개의 UTXO 중 하나를 보유하고 있지만, 정확히 어떤 것인지는 알려주지 않겠다 "는 것을 증명합니다. 동일한 아이디어를 더욱 완벽하게 구현한 FCMP++ 프로젝트는 모네로 블록체인 온체인 구현되었습니다.
최근 JT Halseth는 동일한 문제를 해결하는 완전히 다른 접근 방식인 output-zero를 발표했습니다. 이 방법은 Bulletproofs 대신 zkSTARKs라는 다른 영지식 증명(ZKP)을 사용하고(구현 세부 사항은 risc0 참조), Groth16 래퍼를 사용하여 간결한 증명을 생성합니다.
관심 있으시다면, Delving Bitcoin 포럼에서 그의 프로젝트/아이디어에 대한 토론을 살펴보시는 것을 강력히 추천합니다.
현재 제가 정리한 내용은 다음과 같습니다(정확한지는 확신할 수 없습니다). output-zero의 가장 큰 장점은 O(1) 시간 복잡도(즉, 상수 시간)로 증거를 생성한다는 점입니다(Groth16 덕분입니다). 제가 기억하기로는 증거 크기는 약 260바이트입니다. 이는 제 방법(증거 크기 약 3kB)보다 훨씬 뛰어납니다. 하지만 제 테스트 결과( 여기 )와 저자의 설명을 바탕으로 판단했을 때, output-zero의 증거 생성 시간은 허용 가능한 수준이 아니라고 생각합니다. 저자는 다음과 같이 주장합니다. 라우팅 노드는 일반적으로 고성능 장치를 갖추고 있으며, 무엇보다 증명 작업은 실시간 작업이 아니므로 몇 분 정도 걸리는 것은 허용 가능하다는 것입니다(GPU 가속을 사용하면 훨씬 빠르겠지만, 제가 너무 구식 사고방식을 가지고 있는 것일 수도 있습니다. 이 장점을 고려할 필요는 없다고 생각합니다(이유는 모르겠지만요)). 검증의 경우, 두 ZKP 방법 모두 50~200밀리초가 소요됩니다. 실제로 증거 생성 시간이 10초를 넘는다면 이미 시대에 뒤떨어진 것으로 간주될 것이라고 생각합니다. 어쩌면 제가 틀렸을지도 모르겠습니다.
하지만 마지막으로, 제가 가장 흥미롭게 생각하는 점은 이러한 영지식 증명이 특정 채널 UTXO에 연결되어야 하는지에 대한 다양한 의견입니다. 위에서 언급한 Delving Bitcoin 포럼의 토론을 읽어보셨다면 저 역시 이 부분에 대해 확신이 서지 않는다는 것을 아실 겁니다. 채널 UTXO를 사용하지 않는 것이 개인정보 보호 측면에서 훨씬 좋다고 생각하지만, 다른 관점에서 보면 채널이 아닌 UTXO를 사용할 이유가 있을까요? (이미 채널에 유동성을 주입했는데, 사용하지 않을 이유가 없죠.) 게다가, 영지식 증명에서 채널 UTXO를 사용하려면, 해당 증명이 MuSig2 UTXO에서 생성되었다는 점을 뒷받침해야 합니다. 이는 영지식 증명 설계 시 고려해야 할 사항일 뿐만 아니라 (UTXO에 단일 소유자가 없는 경우 당연히 더 복잡해집니다), 누가 이 영지식 증명을 리소스 자격 증명으로 사용할 수 있고 또 사용해야 하는지에 대한 질문도 제기합니다. 여기서 ZKP가 어떻게 영향을 받을지에 대해서는, 예를 들어 출력 제로의 현재 설계 방식을 생각해 보십시오. 이 방식은...
hash(bitcoin-pubkey-1||bitcoin-pubkey-2)"키 미러"(동일한 UTXO를 반복해서 재사용하는 것을 방지하기 위해 사용되는 것으로, 일반적인 설계 방식과는 상당히 다릅니다. "키 미러는 개인 키의 되돌릴 수 없는 해시값입니다.")라는 측면에서 설명하자면, 대부분의 독자에게는 다소 복잡하게 느껴질 수 있지만, 관련된 불확실성을 보여주기 위한 예시일 뿐입니다.
(위에)
