유동성의 예술: 우리는 어떤 비트코인 오프체인 확장 네트워크가 필요한가?
저자: Ben, Discoco Labs 창립자
서론
오랫동안 저는 한 가지 질문에 대해 고민해 왔습니다. 바로 비트코인 네이티브 확장성의 핵심 논리는 무엇인가 하는 것입니다.
라이트닝 네트워크를 심층적으로 연구하고, 라이트닝 네트워크 위에서 논託관형(비커스터디얼) 서비스를 구현하려는 과정에서 우리는 몇 가지 불협화음을 느꼈습니다. 양자 채널은 이론상 가장 강력한 거래 처리 능력을 갖지만, 실제 운영 및 사용 시 예상보다 훨씬 많은 문제가 발생합니다. 현재 라이트닝 네트워크는 초기 설계 목표였던 마이크로 페이먼트 분야에서도 기대 이하의 성과를 보이고 있으며, 그 핵심 원인은 유동성에 있습니다. 지금도 수많은所谓 유동성 개선 인프라가 등장하고 있지만, 여전히 실질적인 효과는 기대에 못 미치고 있습니다.
본 글을 작성하는 중에도 업계에서 잘 알려진 라이트닝 네트워크 셀프 커스터디 지갑인 Mutiny Wallet이 운영 종료를 발표했으며, 함께 협력하던 유동성 제공업체(LSP) 역시 서비스를 중단했습니다. 셀프 커스터디 지갑과 LSP 간의 협업 모델은 오랫동안 라이트닝 네트워크의 미래 방향으로 여겨져 왔기에, 이러한 상황은 다시 한번 그 미래에 대한 우려를 낳고 있습니다. 따라서 이번 기회를 통해 본문은 유동성 확장을 중심으로 채널 네트워크의 진화 과정과 미래 전망을 탐구하고자 합니다.
1. 현재 라이트닝 네트워크의 문제점은 무엇인가?
비트코인은 블록 용량이 제한되어 있고 메인넷 블록 생성 시간이 평균 약 10분으로 비교적 길기 때문에, 전 세계적인 P2P 현금 시스템이라는 목표와는 큰 격차가 존재합니다. 이를 해결하기 위해 우리는 반드시 필요로 하는 확장성 솔루션이 있습니다. 즉, 블록 공간 점유율이 작고 신속한 결제가 가능하며, 비트코인 네이티브 기반의 솔루션입니다. 그래서 등장한 것이 바로 라이트닝 네트워크입니다.
라이트닝 네트워크는 체인 상 자산을 잠그고, 체인 하에서 커밋 트랜잭션 교환만으로도 거래가 완료된 것으로 간주합니다. 이것이 바로 즉시 결제라고 주장하는 이유입니다. 비트코인 메인넷 결제가 평균 10분의 확인 시간에 의존하는 것과 비교하면, 소액 결제 시나리오에서는 명백히 가장 큰 문제를 해결했다고 볼 수 있습니다.
하지만 라이트닝 네트워크의 실제 발전과 사용 과정에서 여러 문제들이 점차 드러났으며, 본문은 다음과 같은 네 가지 핵심 문제를 요약합니다:
1.1 노드 유지 관리의 어려움
현재의 라이트닝 네트워크는 P2P 형벌 거래 게임 모델(Punishment Transaction Game Model)을 기반으로 합니다. 채널 생애 주기 동안 상대방이 자신에게 불리한 오래된 상태를 체인에 올릴지 항상 감시하기 위해 WatchTower가 항상 온라인이어야 하며, 사용자가 직접 노드를 운영해야 합니다. 또한 사용자는 형벌용 개인키와 커밋 트랜잭션 데이터를 로컬에 저장해야 하므로, 노드 운영의 진입 장벽과 교육 비용이 매우 높습니다.
1.2 높은 상호작용성
라이트닝 네트워크에서 상호작용성(interactivity)란 일반적으로 거래 과정에서 사용자가 수행해야 하는 일련의 상호작용을 의미합니다. 여기에는 서명, 커밋 트랜잭션 교환, 형벌 개인키 교환이 포함됩니다. 예를 들어 체인 하 상태 업데이트마다 거래 당사자 양측이 동시에 온라인 상태여야 하며 새로운 커밋 트랜잭션에 서명하여 교환해야 하므로, 사용자에게 매우 엄격한 상호작용 요구 조건을 가집니다. 더불어 다자간 상호작용 시 HTLC, 멀티홉(Multi-hop) 등의 복잡성도 극복하기 어렵습니다.
1.3 자본 효율성 저하
양자 채널의 LN-Panelty 메커니즘은 일종의 사용자 스스로 은행 계좌를 열고 준비금까지 들고 있어야 한다는 것을 의미합니다. 대표적인 문제는 수취 시에도 채널 내 유동성을 확보해야 한다는 점이며, 자본 효율성이 매우 낮습니다. 또한 가장자리에 위치한 많은 채널들의 유동성은 충분히 활용되지 못합니다.
1.4 채널 관리 비용 증가
P2P 채널에서는 유동성 불균형 현상이极易하게 발생하며, 사용자는 서브마린 스왑(Submarine Swap), 채널 스플라이싱(Channel Splicing) 등의 도구를 의존해 유동성을 보충해야 합니다. 하지만 이러한 기술들은 모두 기존 FundingTx를 조정하기 위해 추가적인 체인 상 트랜잭션이 필요합니다. 결국 모든 조정 수단은 비용이 크며, 특히 수수료가 상승할 때 사용자가 무시할 수 없을 정도의 부담을 느끼게 됩니다.
Layer2 기술을 이용해 저렴한 거래를 하고 있다고 생각하는 사용자가 갑자기 메인넷 체인 상 수수료 몇 건을 부담해야 하는 어색한 상황을 상상해 보십시오. 이 어색함은 메인넷 체인 상 수수료가 더 높아질수록 더욱 두드러지며, 일명 "수수료 어쌔신"이라고 할 수 있습니다.
이러한 문제들로 인해 라이트닝 네트워크의 실제 채택률에서도 명백한 결과가 나타났습니다: 사용자 성장이 정체되고 있으며, 신규 사용자의 대부분은 커스터디형 솔루션을 선택하고 있습니다. 아래 통계 그래프에서 이를 명확히 확인할 수 있습니다.
라이트닝 네트워크 신규 사용자 중 커스터디형 지갑과 논託관형 지갑 선택 비율
이러한 상황이 발생하는 이유는 쉽게 이해할 수 있습니다. 대부분의 일반 사용자에게 노드와 채널을 직접 관리하라는 것은 너무 어려운 요구사항이기 때문입니다.
2. 우리가 필요한 비트코인 오프체인 확장 네트워크란?
라이트닝 네트워크 백서 발췌
라이트닝 네트워크 백서에 따르면, 전 세계 모든 사람이 매년 두 번씩 채널을 개설하고 폐쇄한다면, 결국 비트코인 블록 용량이 133MB까지 증가해야 합니다. 현재 비트코인 메인넷의 블록 크기는 단 1MB이며, 격리위트(SegWit)를 사용하는 P2TR 주소를 적용해도 최대 4MB에 불과하므로, 그 차이는 매우 큽니다. 게다가 실제로 유동성 조정 기술(서브마린 스왑, 채널 스플라이싱 등)은 모두 추가적인 체인 상 트랜잭션이 필요하므로, 라이트닝 네트워크가 직면한 블록 공간 부족 문제는 현실 상황에서 더욱 심각해집니다.
따라서 현재의 라이트닝 네트워크는 단기간 내 대규모 C엔드 사용자 수요를 만족시키기 어렵고, 비트코인 블록 용량의 제약으로 인해 장기적으로도 확장성 측면에서 명백한 한계를 갖고 있음을 알 수 있습니다.
문제는 자연스럽게 따라옵니다. 우리는 과연 어떤 비트코인 오프체인 확장 네트워크를 필요로 하는가?
2.1 라이트닝 네트워크의 현재 상황
라이트닝 네트워크의 현재 한계를 이해하기 위해 먼저 그 설계 원리를 되짚어볼 필요가 있습니다.
현재의 라이트닝 네트워크 모델은 일반적으로 LN-Panelty라고 불리며, 이는 형벌 거래 기반의 양자 채널 모델을 말합니다. 이 모델의 보안성은 사용자가 로컬에 저장한 상대방을 견제하는 트랜잭션과 형벌 개인키에 의존하며, 비트코인 체인 상 활동을 항상 모니터링함으로써 거래 상대방의 행동을 감시할 수 있도록 보장합니다.
이러한 모델 설계 하에서는 사용자 스스로 노드를 운영하는 것이 피할 수 없는 선택이며, 로컬 저장과 WatchTower 기능은 필수적입니다. 앞서 이미 반복해서 언급하였습니다.
자본과 통신 효율 측면에서 보면, 현재 라이트닝 네트워크에서 일반적인 패턴은 하나의 LSP 슈퍼노드가 중앙에서 유동성을 제공하고, 사용자들이 이 슈퍼노드와 채널을 맺는 것입니다. 이는 본래의 P2P 메쉬 모델에서 벗어난 것이며, 자연스러운 진화 과정에서 결국 고전적인 허브앤스포크(Hub-and-Spoke) 모델로 회귀한 것입니다.
다음 그림에서 좌측은 이상적인 라이트닝 네트워크이며, 우측은 실제 현재의 모습입니다.
2.2 이상적인 C엔드용 오프체인 확장 네트워크의 특성
그렇다면 이제 C엔드 사용자가 진정으로 필요로 하는 비트코인 오프체인 확장 네트워크가 가져야 할 특성을 상상해 봅시다:
-
P2P 모델을 채택하지 않으며, 사용자가 직접 노드를 운영할 필요 없이 보안성과 편의성을 유지
-
상호작용 측면에서, 결제 시 상대방이 온라인이 아니거나 비동기식 조작도 가능
-
자본 효율성을 높이면서도 논託관형(Non-Custodial) 요구를 충족
-
저렴하고 효율적인 유동성 관리 메커니즘 제공, 또는 아예 사용자 스스로 유동성을 관리할 필요 없음
이러한 목표를 바탕으로 본문은 독자들과 함께 비트코인 오프체인 확장 네트워크의 미래 방향을 탐구하고자 합니다.
3. BTC 네이티브 확장의 진화 경로
우선 현재 라이트닝 네트워크 설계의 핵심 메커니즘인 "LN-Panelty"에서 상태 업데이트 메커니즘의 기반이 다음 두 가지에 있다는 점을 명확히 해야 합니다:
-
커밋 트랜잭션 저장 및 지속적인 모니터링
-
다자간 협업을 위한 멀티홉 메커니즘(HTLC/PTLC)
이러한 요소들이 현재 라이트닝 네트워크 설계의 기초를 이루며, 노드 설계의 복잡성을 초래합니다. 즉:
-
복잡한 암호화 통신 상호작용
-
로컬 커밋 트랜잭션 및 형벌 개인키 저장
-
채널 생애 주기 동안 중단 없이 작동하는 WatchTower
이러한 문제들은 "LN-Penalty"를 대체할 수 있는 더 가벼운 상태 업데이트 메커니즘을 고민하게 만듭니다. 이러한 맥락에서 BIP118(SIGHASH_ANYPREVOUT)이 가능한 대안으로 제시되었습니다.
3.1 LN-Symmetry: 상태 업데이트에 버전 메커니즘 도입
BIP118은 SIGHASH_ANYPREVOUT 서명 방식을 도입하는데, 이는 트랜잭션 입력이 이전 출력을 완전히 지정할 필요 없이, 서명을 변경하지 않고도 선행 트랜잭션을 업데이트할 수 있게 합니다. 이러한 설계는 "LN-Penalty" 대비 노드 간 암호화 통신 복잡도와 저장 요구를 크게 줄일 수 있습니다. SIGHASH_ANYPREVOUT는 논문 eltoo: A Simple Layer2 Protocol for Bitcoin에서 제안되었으며, 최근 라이트닝 네트워크 개발 논의에서 이 개선안을 기반으로 한 모델은 "LN-Symmetry"라고 불립니다.
비록 LN-Symmetry가 로컬 커밋 트랜잭션 저장 부담을 줄였지만, 여전히 모니터링 요구를 완전히 제거하지는 못합니다. Eltoo는 커밋 트랜잭션과 개인키 서명을 교환할 필요가 없지만, 누군가 오래된 상태를 체인에 공개하려 할 경우, 다른 쪽은 실시간으로 모니터링하여 최신 상태 트랜잭션을 신속히 공개해 오래된 상태를 대체해야 합니다. 이 과정에서 WatchTower는 여전히 필요하며, 목적은 형벌에서 상태 대체로 바뀌었을 뿐입니다. 사용자는 여전히 자신의 노드를 운영해야 합니다.
또한 LN-Symmetry는 여전히 다자간 협업을 위한 HTLC/PTLC 메커니즘이 필요하며, 기존 라이트닝 네트워크 노드 설계와 마찬가지로 심각한 통신 부담을 안고 있습니다.
결국 전체적으로 볼 때, LN-Symmetry는 현재 라이트닝 네트워크의 사용자 경험을 다소 개선했지만, 우리가 추구하는 목표까지는 아직 멀었습니다.
더 나은 개선을 위해 본문은 다음 단계의 방향을 제시합니다: Shared UTXO.
3.2 CoinPool: 다자 채널의 상호작용성과 유동성 요구 감소
Shared UTXO 개념을 처음 소개한 논문은 CoinPool: efficient off-chain payment pools for Bitcoin입니다. 이 논문의 핵심 목표는 SIGHASH_ANYPREVOUT의 버전 업데이트 메커니즘 하에서 다자간 상호작용 문제를 추가로 해결하는 것입니다.
LN-Symmetry 설계에서는 Eltoo가 도입한 새로운 상태 업데이트 메커니즘을 통해 점대점 채널의 상태 관리를 확실히 단순화했습니다. 그러나 다자간 협업 시에는 여전히 상호작용의 복잡성이 존재하며, 특히 멀티홉 결제(HTLC/PTLC)에서는 각 당사자 간 긴밀한 조율과 반복적인 암호화 통신이 필요합니다.
CoinPool의 혁신은 Shared UTXO 모델을 활용해 여러 참여자가 버전 관리가 가능한 동일한 UTXO 위에서 협업할 수 있도록 했다는 점입니다. 이를 통해 다양한 참여자들은 복잡한 HTLC/PTLC 메커니즘에 의존하지 않고도 동일한 UTXO의 상태를 공동으로 약속하고 관리할 수 있습니다. 주요 이점은 다음과 같습니다:
-
다자 채널의 상호작용 복잡성 크게 감소: 모든 참여자가 동일한 UTXO를 공유하므로, 해당 UTXO의 버전 업데이트에 대한 공동 서명만으로 합의에 도달할 수 있으며, 반복적인 체인 상 트랜잭션이나 복잡한 체인 하 상호작용이 필요 없습니다. 이를 통해 다자 채널 관리가 훨씬 효율적으로 변합니다.
-
체인 하 업데이트 메커니즘의 직접성 향상: 이 설계 하에서 체인 하 상태 업데이트는 다자 공동 서명을 통해 특정 버전의 UTXO를 확인하는 방식으로 전환됩니다. 이는 상태 업데이트 프로세스를 단순화할 뿐 아니라, 당사자 간 의존성과 잠재적 충돌점을 줄입니다.
-
독립적인 유동성 요구 제거: Shared UTXO 모델을 통해 다수 참여자는 동일한 유동성 풀을 공유하며, 각 참여자가 자체적으로 충분한 유동성을 유지할 필요가 없습니다. CoinPool 설계에서 유동성 요구는 크게 감소하거나 재분배될 수 있습니다. 참여자들은 공유 UTXO 내 유동성을 활용해 결제를 완료할 수 있으므로, 각자 채널에 많은 자금을 묶어둘 필요가 없습니다. 이는 자금 활용 효율을 높일 뿐 아니라 개별 참여자의 자금 부담을 줄입니다.
CoinPool 설계는 Shared UTXO를 통해 다자 채널의 상호작용 복잡성을 합리적인 수준으로 낮추며, 시스템의 보안성과 효율성을 유지합니다. 더욱 중요한 것은, 각 참여자의 독립적인 유동성 요구에 대한 의존도를 줄여 다자 협업에 더 가볍고 유연한 해결책을 제공하며, 기존 LN 모델의 다자 상호작용 및 유동성 관리 한계를 돌파합니다.
그러나 이렇게 명백한 장점을 지닌 방안이 왜 아직 대규모로 채택되지 않았을까요? 문제의 근원은 어디에 있을까요?
3.3 왜 CoinPool은 실제로 시행되지 않았는가?
비록 CoinPool은 많은 장점을 지녔으며 이상적인 확장 모델로 여겨지지만, 필요한 소프트포크 업그레이드가 너무 많아서 아마 우리의 생애 동안 비트코인 네트워크에 적용되기 어려울 것입니다. CoinPool이 소프트포크 업그레이드를 필요로 하는 부분은 주로 다음 두 가지입니다:
3.3.1 상태 업데이트 메커니즘 업그레이드
CoinPool은 Eltoo 설계를 기반으로 하며, 상태 업데이트 메커니즘을 위한 소프트포크 업그레이드 필요성을 물려받았습니다. 즉, 비트코인 네트워크가 새로운 서명 방식인 SIGHASH_ANYPREVOUT(APO)을 활성화하도록 업그레이드되어야 합니다. 그러나众所周知, 비트코인의 소프트포크 업그레이드는 진행 속도가 매우 느리므로, CoinPool이 의존하는 기술은 현실에 적용되기 어렵습니다.
3.3.2 Shared UTXO는 계약 간소화 메커니즘 필요
앞서 설명했듯이, Shared UTXO의 각 상태 업데이트는 해당 UTXO 특정 버전을 공유하는 모든 참여자의 서명을 수집해야 합니다. 이 과정에서 한쪽이 오프라인 상태가 되면 전체 시스템이 정지하게 되며, 블록체인 용어로는 시스템의 '생동성(liveness)'이 매우 낮다고 표현합니다. 이 문제를 해결하기 위해 시스템은 협조 없이도 낮은 비용으로 Shared UTXO를 업데이트할 수 있는 메커니즘이 필요합니다.
CoinPool 논문에서는 OP_MERKLESUB를 제안하며, 머클 트리 구조를 통해 특정 참여자의 상태를 검증하고 업데이트하는 방법을 제시합니다. 이 설계 아이디어는 이론적으로는 가능하지만, 머클 트리를 기반으로 한 다른 계약들과 마찬가지로 논리 구현이 복잡하며, 범용적이고 재사용 가능한 계약을 만들기 어렵다는 문제가 있습니다. 예를 들어 **OP_TAPLEAFUPDATEVERIFY(TLUV)** 같은 계약 등이 그렇습니다. 또한 OP_EVICT처럼 협조하지 않는 참여자를 Shared UTXO에서 직접 추방하는 기능은 너무 단일화되어 있어, 비트코인 네트워크 업그레이드를 통과할 가능성도 낮습니다.
이러한 제안된 계약 중, OP_CheckTemplateVerify(CTV)가 점점 주목받고 있습니다. 머클 트리를 직접 구성하고 검증하는 것과 달리, CTV는 사전 정의된 트랜잭션 템플릿을 통해 지출을 제한합니다. CTV는 구현이 간단할 뿐 아니라, 하나의 체인 상 UTXO를 통해 일련의 체인 하 UTXO들을 커밋 체인으로 연결할 수 있습니다. 이러한 체인 상에서 커밋된 체인 하 UTXO가 바로 Virtual UTXO(VTXO) 개념의 기원입니다.
이러한 계약 중 CTV의 보급 요청이 가장 큽니다. 단순하면서도 범용적이기 때문입니다. CTV의 강력한 기능은 CoinPool과 같은 아이디어를 실현할 수 있을 뿐 아니라 롤업(Rollup)에도 활용할 수 있습니다. OP_CAT을 통해 ZKP-MerkleState를 검증하고 스크립트 내에서 해당 Layer2 상태를 커밋하는 Shared UTXO를 상상해 본다면, 진정한 의미의 비트코인 ZK-Rollup 방안을 구축할 수 있을 것입니다.
결론적으로, CoinPool의 시행이 직면한 주요 문제는 가벼운 상태 업데이트 메커니즘인 APO와 Shared UTXO를 위한 오퍼코드 도입이 필요하다는 점이며, 이 둘 모두 비트코인 소프트포크 업그레이드가 필요합니다. 그래서 CoinPool 논문이 발표된 지 오랜 세월이 지났음에도 여전히 종이상의 방안으로 남아 있습니다.
3.4 Bitcoin Clique: 오프체인 더블스펜드 방지 원시 연산 2-AS
앞서 CoinPool 모델 논의에서, APO 메커니즘은 소프트포크 업그레이드가 이루어져야만 실현 가능하다는 점을 알았으며, 단기간 내 달성하기 어렵다는 사실을 인지했습니다. 그렇다면 비트코인 소프트포크 업그레이드에 의존하지 않는 새로운 오프체인 더블스펜드 방지 원시 연산이 있다면, 실현 문제는 크게 해결될 수 있습니다.
SIGHASH_ANYPREVOUT의 핵심 역할은 체인 하 상태 업데이트 시 더블스펜드를 방지하는 메커니즘을 제공하는 것입니다. 이 아이디어를 바탕으로, 동등한 암호학적 원시 연산을 찾는다면 체인 하 상태 업데이트 문제를 해결할 수 있으며, 비트코인 오퍼코드 업데이트 요구도 회피할 수 있습니다. 논문 Bitcoin Clique의 등장은 새로운 희망을带来了. 이 논문은 새로운 암호학적 원시 연산인 2-shot-adaptor-signature(2-AS)를 도입하여, 체인 하 더블스펜드 방지를 위한 새로운 해결책을 제시합니다.
2-AS는 Schnorr 어댑터 서명 기반의 암호학적 원시 연산이며, 2-AS를 이해하려면 우선 Schnorr 서명과 어댑터 서명에 대해 어느 정도 이해해야 합니다.
3.4.1 Schnorr 서명
Schnorr 서명은 선형성(linearity) 특성을 가지며, 여러 서명을 하나로 집합할 수 있습니다. 간단히 말해, 두 개의 서명 $S_1$과 $S_2$가 있다면 덧셈으로 하나의 서명 $S=S_1+S_2$를 만들 수 있으며, 검증 시 대응 공개키도 $P = P_1 + P_2$로 집합할 수 있습니다.
3.4.2 어댑터 서명
어댑터 서명은 Gen, PSign, PVrfy, Adapt, Extract 등의 기본 단계를 가집니다. 2-AS를 이해하는 데 특히 중요한 것은 Psign과 Extract 단계입니다.
본문은 암호학적 측면보다는 용도 측면에서 어댑터 서명을 이해하는 데 중점을 둡니다. 간단히 말해, 두 주체가 공동으로 서명을 확인하려 할 때, 상대방의 어댑터를 서명 일부로 사용하며, 어댑터는 일반적으로 공개키-개인키 쌍의 공개키 부분입니다. 이후 어댑터의 개인키, 즉所谓 비밀을 가진 쪽은 Psign에서 남긴 부분 서명을 Adapt를 통해 완성할 수 있습니다. 만약 여기까지만이라면 MuSig과 비슷하지 않을까요? 그러나 어댑터 서명의 독특한 점은 Extract에 있습니다. 즉, 완전한 서명이 공개되면, 어댑터 서명을 시작한 Psign 측은 완전한 서명, 이전의 부분 서명, 그리고 어댑터(공개키)를 통해 대응하는 비밀(개인키)을 추출할 수 있습니다.
3.4.3 두 가지의 융합: 2-AS
이제 Schnorr 서명과 어댑터 서명의 특성을 이해했으므로, 두 가지를 결합한 마법인 2-AS를 살펴봅시다.
VTXO가 있고, 체인 하에서 그것이 더블스펜드될 경우 몰수되도록 보장하고자 한다면, 다음과 같이 설계할 수 있습니다:
-
먼저 몰수 가능한 출력을 가지는 형벌 출력(penalty output)을 만들어야 하며, 이 출력을 해제할 수 있는 공개키는 형벌 공개키여야 합니다. 사용자가 더블스펜드를 시도할 경우 서비스 제공자가 이를 몰수할 수 있도록 보장합니다.
-
거래 상대방 간 협업을 통해 어댑터 서명으로 체인 하 거래를 확인하며, 사용자가 동일한 입력을 두 번 사용할 경우 해당 출력은 서비스 제공자에게 몰수됩니다.
-
사용자가 매번 상태를 업데이트할 때마다 형벌 출력을 위한 공개키를 생성해야 하며, 이 형벌 공개키는 미리 결정된 두 쌍의 공개키를 Schnorr 서명 기술로 덧셈한 것으로 구성됩니다.
따라서 매번 거래 전에 이후에 사용할 공개키-개인키 쌍을 미리 확인하고 형벌 출력을 미리 생성합니다. 더블스펜드가 발생하면, 서비스 제공자는 두 번의 어댑터 서명을 통해 해당 형벌 출력의 개인키를 최종적으로 획득할 수 있습니다.
3.4.4 Bitcoin Clique의 장단점
Bitcoin Clique 방안도 완벽하지 않습니다. 그 단점은 체인 하 상태 업데이트 시, 새로운 형벌 공개키를 구성하기 위한 2-AS 키를 지속적으로 교환해야 한다는 점입니다. 또한 이 방안은 CoinPool 설계를 기반으로 하며, 매번 2-AS 키를 교환하고 새 버전의 UTXO에 검증 서명을 하기 위해 상태 업데이트 시 모든 사람이 온라인 상태여야 합니다. 즉 통신의 복잡성과 상호작용성이 여전히 매우 높습니다.
가장 중요한 점은 이 모델이 StateChain과 유사한 설계라는 것입니다. 매번 체인 하에서 특정 UTXO의 소유권을 이전하는 것이므로, 2-AS와 같은 double-spend-prevent signatures를 사용하는 시스템은 체인 하 결제에서 잔돈을 찾을 수 없습니다. 이로 인해 응용 시나리오가 매우 제한됩니다.
또한 쉬운 조작이 가능한 SharedUTXO 메커니즘과 소프트포크 업그레이드가 필요 없는 체인 하 더블스펜드 방지 원시 연산이 있다고 하더라도, 여전히 모든 참여자가 UTXO의 새 상태를 업데이트할 때 온라인 상태여야 하며, 심지어는 체인 하 네트워크의 일부 사람에게만 영향을 주는 업데이트라도 관련 없는 사람들이 온라인으로 참여하는 것은 불합리합니다. 또한 유동성 요구를 완전히 제거하는 것도 우리가 원하는 바가 아닙니다. 유동성 윤활이 없는 결제 방안은 잔돈 처리가 불가능하며, 탈퇴 문제로 인해 모든 사람의 금액 단위가 반드시 동일해야 합니다.
따라서 현재로서는 채널 구조가 아닌, 동적 금액을 지원하고 UTXO 기반의 체인 하 확장 방안은 존재하지 않습니다. 이더리움도 이 경로에서 오랫동안 고통받았으며, 이를 플라즈마 함정(Plasma trap)이라고 부릅니다. 관련 연구는 논문 Lower Bounds for Off-Chain Protocols: Exploring the Limits of Plasma을 참고하시기 바랍니다.
문제점과 교훈을 요약하면:
-
동적 금액 결제(잔돈 처리 가능)를 보장하기 위해 유동성 윤활 필요: 채널 설계를 유지해야 하며, 동시에 탈퇴 문제도 피할 수 있습니다.
-
모든 참여자가 동기화되어 온라인 상태일 필요성 감소: 체인 하 네트워크에서 상태 업데이트 시마다 모든 사용자가 온라인이기를 바라지 않으며, Shared UTXO 업데이트는 관련된 사람들만 온라인에서 협업하면 됩니다.
이러한 인식을 바탕으로 본문은 더 최적화된 방안을 계속 탐색합니다.
3.5 채널 팩토리와 가상 채널
앞선 논의에서 우리는 채널 설계를 유지할 필요가 있을 뿐 아니라, Shared UTXO가 제공하는 체인 하 저비용 이점을 활용해야 한다는 것을 인식했습니다. 이때 라이트닝 네트워크 분야에서 오랫동안 논의되어온 개념이 우리의 시야에 들어옵니다. 즉, 채널 팩토리(Channel Factory)입니다.
이전에 언급했듯이, 체인 상 UTXO에 의해 커밋된 체인 하 UTXO는 Virtual UTXO(VTXO)라고 불립니다. 만약 이 체인 하 VTXO를 채널의 FundingTx로 사용한다면, 우리는 새로운 개념인 가상 채널(Virtual Channel)을 얻게 됩니다. 그러면 이 Shared UTXO 내부의 체인 하 가상 채널은 Virtual HTLC로 연결됩니다. 모든 것이 체인 하로, 완전히 "가상화"됩니다. 이는 이상적인 해결책처럼 보입니다: 대부분의 기능을 체인 하에서 구현하며 유동성 조정 등을 포함합니다. 라이트닝 네트워크 확장은 마침내 해결되는 듯합니다.
하지만 정말로 이처럼 아름다운 현실일까요?
Shared UTXO의 특성을 계승하기 때문에, 채널 팩토리는 개설 및 폐쇄 시 여러 사용자의 협업이 필요합니다. 만약 어느 한 사용자가 적시에 협조하지 못한다면(예: 오프라인 또는 무응답), 전체 채널 팩토리 기능에 영향을 줄 수 있습니다. 채널 팩토리는 여러 당사자가 공동으로 상태 업데이트에 서명하기 때문에, 한쪽의 비동기화나 악의적 행위로 인해 다른 사용자가 채널을 원활히 종료하고 자금을 인출하지 못할 수 있습니다.
또한 이러한 설계의 문제점도 명확합니다. 이를 통해 채널 개폐 비용은 낮췄지만, 채널 간 보안 모델은 여전히 커밋 트랜잭션과 HTLC에 의존합니다. 따라서 통신 및 상호작용 문제는 여전히 존재하며, 심지어 이 방안의 구현 복잡성은 현재의 LN-Panelty보다 더 높을 수 있습니다.
3.6 ARK JoinPool과 일시 채널
이전의 채널 팩토리 사례를 돌아보면, 다음과 같은 결론을 얻을 수 있습니다: Shared UTXO 기반 채널 설계에서 고전적인 "LN-Panelty" 채널 설계를 계속 따르지 말아야 하며, 동시에 채널 설계의 장점을 유지해야 한다:
-
유동성이 제공하는 동적 금액;
-
탈퇴가 용이함.
이에 따라 JoinPool을 활용한 일시 채널 설계가 등장하게 되었으며, 이는 바로 ARK 프로토콜입니다.
3.6.1 JoinPool: 일부 참여자만 업데이트에 참여
앞서 언급했듯이, CoinPool은 다자 간 체인 하 협업 확장에 잠재력을 보여주며, 유동성, 멀티홉, HTLC 등 복잡하고 오류가 발생하기 쉬운 설계가 필요 없다는 점입니다. 그러나 CoinPool 모델의 가장 큰 문제는 사용자 온라인 요구입니다: 체인 하 상태 업데이트 시 Shared UTXO 내 모든 사용자가 온라인 상태여야 하며, 일부 사용자의 상태가 변경되지 않았더라도 여전히 온라인에서 검증하고 서명을 제공해야 합니다. 이 요구는 사용자가 직접 노드를 운영해야 하는 문제를 피할 수 없게 만듭니다.
이 문제를 해결하기 위해 새로운 모델인 JoinPool이 제안되었습니다. JoinPool의 Shared UTXO 개념은 다음과 같습니다: 사용자가 체인 하 상태를 업데이트할 필요가 있을 때, 그들은 해당 UTXO의 새 상태를 나타내는 Shared UTXO에 함께 합류하는 것입니다. 이를 통해 다른 사용자가 거래를 실행할 때도 관련 없는 사용자가 온라인일 필요가 없다는 문제를 해결합니다. 즉, JoinPool 기반 설계에서는 사용자가 거래가 필요할 때만 온라인 상태여야 합니다.
하지만 우리는 모두 알고 있습니다. 라이트닝 네트워크 노드를 지속적으로 운영해야 하는 이유는 사용자 개인키를 온라인 상태로 유지해 서명을 보장해야 할 뿐 아니라, 각 채널 구성원이 WatchTower를 통해 상대방이 자신에게 불리한 커밋 트랜잭션을 체인에 올리는지 지속적으로 감시해야 하기 때문입니다. 이것이 우리가 해결해야 할 두 번째 문제입니다.
3.6.2 WatchTower 책임 이전: 사용자가 직접 노드를 운영할 필요 없음
고전적인 LN-Panelty 설계에서 각 사용자는 상대방이 오래된 상태를 체인에 올릴 경우 이를 처벌하기 위해 자체 WatchTower를 구성해야 합니다. 이런 구형 모델에서는 모든 사용자의 거래 상대방이 동등한 라이트닝 노드였으며, 매번 거래 참여 시 서로 다른 노드와 채널을 개설해 거래할 수 있었습니다. 그러나 ARK에서는 모든 사용자가 ASP(ARK Service Provider)와 상호작용하며, 다른 사용자와 직접 상호작용하지 않습니다.
ASP 입장에서, 사용자의 체인 하 VTXO가 거래되면, 즉시 포기 거래(Waiver Transaction)에 서명합니다. 이는 이상적으로 사용자의 체인 하 VTXO가 체인 상에 올라가지 않고, 계속해서 다음 거래로 인용되어야 하기 때문입니다. 만약 VTXO가 체인 하에서 거래되었는데 동시에 체인 상에서 제출된다면, 이는 사용자가 VTXO를 더블스펜드했다는 것을 의미하며, ASP는 사용자가 체인 하에서 서명한 포기 거래를 사용해 체인 상에 올라간 자금을 몰수합니다. ASP는 역사상 모든 등장한 VTXO를 모니터링하여, 체인 하에서 이미 사용된 VTXO가 체인 상에서 악의적으로 탈퇴하는 것을 방지합니다.
이를 통해 WatchTower 운영 책임이 일반 사용자에서 운영자(operator)로 이전되었습니다. 라이트닝 네트워크와 비교하면, 이 모델은 거대한 개선입니다: 마침내 일반 사용자가 자신의 노드를 직접 운영하지 않아도 자산 보안을 보장할 수 있게 된 것입니다.
다른 방안들이 사용자 노드 운영 최적화 측면에서의 요약:
-
라이트닝 네트워크 노드 클라우드 호스팅
일부 방안은 클라우드 플랫폼에서 라이트닝 네트워크 노드를 운영해 사용자의 노드 운영 진입 장벽을 낮추려 합니다. 그러나 이러한 방안은 본질적으로 라이트닝 네트워크의 보안 가정을 위반합니다. 라이트닝 네트워크 기술에서 개인키와 커밋 트랜잭션 저장은 많은 시나리오에서 동일하게 중요합니다. 따라서 단순히 원격 개인키를 사용하는 것은 보안을 보장할 수 없습니다.
본질적으로 이 방안은 양자 간 게임 상황을 나, 거래 상대방, 클라우드 호스팅 업체라는 삼자 간 게임 상황으로 변화시킵니다. 내가 상대방과 거래 후 상태가 체인에 올라가기 전에, 클라우드 호스팅 업체가 나의 클라우드 노드 내 커밋 트랜잭션을 일방적으로 삭제할 수 있으며, 이때 상대방은 자신에게 유리한 상태를 체인에 올릴 수 있습니다. 이러한 라이트닝 네트워크 클라우드 노드 호스팅 방안에서는 클라우드 플랫폼과 거래 상대방이 공모해 악행을 저지를 위험이 존재합니다.
-
CRAB 및 Sleepy CRAB
Aumayr 등이 제안한 CRAB(Channel Resistant Against Bribery) 프로토콜은 추가적인 담보와 광부 인센티브 메커니즘을 결합해 오프라인 상태에서도 지급 채널의 보안을 보장합니다. 이 메커니즘은 제3자 WatchTower에 대한 의존도를 줄입니다. 그러나 이러한 담보 메커니즘은 "입금 유동성" 문제를 더욱 악화시킵니다. 사용자가 체인 하 네트워크에 가입할 때 거래 목적과 무관한 더 많은 자금을 묶어야 하기 때문입니다. 보안은 확보되지만, 자금의 유동성과 효율성이 희생됩니다. 또한 이 방안은 여전히 사용자가 직접 노드를 운영해야 하며, 단지 온라인 요구를 낮춘 것에 불과합니다.
3.6.3 일시 채널: 사용자가 직접 채널 유동성을 관리할 필요 없음
누군가는 물을 수 있습니다. 왜 ASP 서비스 제공자는 JoinPool 채널에 유동성을 주입해주려 할까요? 사용자가 ARK 네트워크 기반 VTXO를 사용하려면, 먼저 자신의 UTXO를 운영자와 함께 멀티시그 주소에 예치해야 하며, 이는 일종의 FundingTx와 유사하며, 그 대가로 VTXO를 받습니다. 본질적으로 사용자의 매 체인 하 거래는 운영자의 자금을 사용하는 것이지만, 이전에 사용자와 운영자가 멀티시그한 자금을 양도하는 것입니다.
ARK 채널이 일시 채널이라 불리는 이유는 단방향성과 일회성 자금 투입이라는 두 가지 특징 때문입니다.
-
단방향성: 단방향 채널 내에서 자금은 지정된 발신자로부터 수신자로만 이전됩니다.
-
일회성 자금 투입: ARK 채널은 자금을 한 번만 투입하면 됩니다. 자금 투입 후에는 채널 유동성을 계속 관리할 필요가 없습니다.
이러한 일시 채널 설계 하에서, 자금 투입 후 채널은 재균형 등의 조정이 필요 없습니다. 라이트닝 네트워크와 비교하면, 사용자는 더 이상 채널 유동성을 신경 쓸 필요가 없으며, 유동성 제공자도 채널 유동성을 관리할 필요가 없습니다. 채널 내 유일한 변화는 사용자의 탈퇴 이벤트뿐입니다.
3.6.4 ARK 프로토콜 요약
위 내용을 종합하면, ARK 프로토콜 설계가 라이트닝 네트워크 대비 사용자 경험 측면에서 놀라운 진보를 이뤘음을 명확히 알 수 있습니다:
-
사용자가 직접 노드를 운영할 필요 없음
-
사용자가 직접 채널 유동성을 관리할 필요 없음, 입금 유동성 문제 없음
-
비동기 상호작용 지원, 양측 동시 온라인 불필요
4. 비트코인 네이티브 확장 패러다임의 변화
앞선 연구를 통해 우리는 Shared UTXO 기반의 여러 체인 하 확장 방안을 탐색했습니다. Shared UTXO의 설계 목적은 유동성 문제를 해결하는 것이었지만, 프로토콜의 진화에 따라 예상했지만 감히 기대하지 못했던 많은 장점들이 우연히 발견되었습니다.
이는 비트코인 체인 하 확장이 새로운 발전 방향으로 접어들었음을 의미하며, 기존 라이트닝 네트워크 모델과 비교해 패러다임 전환을 나타냅니다:
-
P2P 모델에서 신뢰 불필요한 operator 도입으로의 전환
체인 하 확장 네트워크의 논리는 초기 라이트닝 네트워크의 "사용자 대 사용자" 양자 게임 모델에서 점차 "사용자 대 operator" 간 게임 모델로 진화하고 있습니다. 다른 점은 사용자가 이 제3자 operator를 신뢰할 필요가 없다는 것입니다.
-
사용자가 직접 노드 인프라를 운영해 자산 보안을 보장할 필요 없음
기존의 LN-Penalty 모델과 CRAB 등의 최신 연구는 사용자가 직접 담보를 제공해 자금 보안을 보장하고, 채널 생애 주기 동안 온라인 상태를 유지하며 노드를 운영하도록 요구합니다. 그러나 미래의 방안은 더 이상 이러한 작업이 필요하지 않습니다. 더욱 중요한 것은 이러한 프로세스가 여전히 논託관형(non-custodial)을 유지하며, 사용자가 항상 자산에 대한 통제권을 보유한다는 점입니다.
-
유동성 관리 책임이 사용자에서 operator로 이전
고전적인 LN-Penalty 모델과 개선 설계에서는 사용자가 채널 내 유동성을 직접 조정해야 하며, 특히 유동성 불균형 시 그러합니다. 이는 일반적으로 일정한 전문 지식이 필요하며, LSP(유동성 서비스 제공자)의 도움 없이는 조작이 복잡합니다. 그러나 유동성 관리 책임이 제3자 operator로 이전됨에 따라, 사용자는 더 이상 유동성 관리에 대해 걱정할 필요가 없습니다. 이는 사용자 경험을 크게 단순화하며 네트워크 가입 장벽을 제거합니다.
-
자본 효율성과 잠재력 극대화
새로운 프로토콜 설계는 모두 P2POOL 모델로 나아가고 있으며, 자본 효율성 측면에서 현재의 라이트닝 네트워크와 근본적인 차이를 지닙니다. LN-Penalty 모델에서 각 사용자는 라이트닝 채널을 개설할 때 직접 유동성을 제공해야 하지만, 이 채널의 유동성은 대부분의 시간 동안 유휴 상태입니다(지불이
TechFlow 공식 커뮤니티에 오신 것을 환영합니다
Telegram 구독 그룹:https://t.me/TechFlowDaily
트위터 공식 계정:https://x.com/TechFlowPost
트위터 영어 계정:https://x.com/BlockFlow_News
@blapta
