오프체인 전송: 비트코인 자산 프로토콜의 진화之路
서론
비트코인(BTC) 기반의 자산 발행은 오랫동안 핵심 이슈로 주목받아 왔다. 2011년 등장한 컬러드 코인(Colored Coins)에서 최근 각광받는 Ordinal 프로토콜에 이르기까지 BTC 커뮤니티는 끊임없이 새로운 플레이어와 합의를 만들어내고 있지만, 오랜 시간 살아남는 사례는 극소수에 불과하다. 그러나 야심 찬 Lightling Labs가 Taproot Assets 위에 스테이블코인을 구축하겠다고 발표하고, Tether도 RGB를 활용해 비트코인 1층(Layer1)에서 USDT를 발행하겠다고 밝히면서 상황이 변화하고 있다.
이는 과거 OmniLayer(Mastercoin)가 BTC 생태계의 중심이었던 시대가 지났음을 의미하며, 클라이언트 검증(Client-Side Validation, CSV) 기반의 자산 프로토콜이 본격적으로 대두되고 있음을 보여준다. 이러한 CSV 자산 프로토콜은 기존의 BTC 자산 방식과 달리 확장성까지 겸비하고 있다는 점에서 주목할 만하다. 하지만 BTC 생태계 내 다양한 자산 프로토콜들 사이에서 그 차이점은 무엇이며, 어떻게 선택하고 기회를 포착해야 할까? 본 글은 비트코인 역사 속 자산 프로토콜의 흐름을 되짚으며, 미래의 가능성도 조망하고자 한다.
컬러드 코인(Colored Coins)
컬러드 코인 개념은 현재 eToro의 CEO인 Yoni Assia가 2012년 3월 27일 작성한 "bitcoin 2.X (aka Colored bitcoin)"라는 제목의 글에서 처음 제안되었다. 그는 비트코인이 HTTP처럼 인터넷의 기반이 되듯, 기반 기술로서 완벽하다고 주장하며, 이를 재활용해 Colored Coins라는 토큰 프로토콜을 설계했다.
Yoni Assia는 이를 통해 BTC 2.0 경제를 창출하고자 했다. 즉, 어떤 커뮤니티라도 다양한 통화를 생성할 수 있도록 하자는 것이다. 비트코인을 기반 기술로 사용하여 거래 정산과 이중지불 방지를 실현하려는 이 아이디어는 당시로서 매우 혁신적이었다.
컬러드 코인은 비트코인 네트워크 위에서 자산을 발행하는 프로토콜로, 일정량의 비트코인을 "색칠(colored)"해 해당 자산을 표시한다. 이렇게 표시된 비트코인은 여전히 비트코인으로 기능하지만, 동시에 다른 자산이나 가치를 나타낸다. 그렇다면 이 개념은 실제로 어떻게 비트코인 위에서 구현될 수 있을까?
2014년 7월 3일, ChromaWay는 개선된 주문 기반 색상 부여 프로토콜(EPOBC, Enhanced Proof-of-Burn Coloring)을 개발했다. 이는 개발자가 컬러드 코인을 쉽게 제작할 수 있도록 도왔으며, Bitcoin Script의 OP_RETURN 기능을 최초로 활용한 프로토콜이기도 하다.
최종적인 구현 결과는 아래 이미지와 같다:
이 방식은 매우 간단하지만, 동시에 여러 문제점을 동반한다:
1. 동질화 토큰과 최소 바인딩 값
창세 트랜잭션에서 특정 컬러드 코인에 1000 sat를 바인딩하면, 해당 자산의 최소 분할 단위는 1 sat가 된다. 즉, 이 자산은 최대 1000개까지 분할 가능하다(단, 실제론 먼지 공격(dust attack) 방지를 위해 제한됨. 예: 과거에는 546 sat, 이후 Ordinal 시대에는 더 높은 수치 적용).
2. 검증 문제
컬러드 코인의 진위와 소유권을 확인하기 위해서는 자산의 창세 트랜잭션부터 현재 UTXO까지 전 거래 이력을 추적 검증해야 한다. 따라서 전용 지갑, 전체 노드(full node), 심지어 블록 탐색기(explorer)까지 별도 개발이 필요하다.
3. 잠재적인 마이너 검열 리스크
ColoredTransaction은 output에 메타데이터 정보를 기록한다는 특징 때문에 마이너의 검열 가능성을 열어둔다.
결국 컬러드 코인은 자산 추적 시스템에 가깝다. 비트코인의 검증 규칙을 활용해 자산 이동을 추적하지만, 특정 출력(txout)이 특정 자산을 나타냄을 증명하려면 자산 생성부터 현재까지의 전체 이력 체인이 필요하다. 이는 긴 증명 체인이 요구되므로 검증이 비효율적이다. 이를 해결하기 위해 당시 OP_CHECKCOLORVERIFY 제안이 있었으나, 결국 통과되지 못했다.
암호화 산업 최초의 ICO: Mastercoin
Mastercoin의 초창기 개념은 J.R. Willett이 제안했다. 2012년 그는 "The Second Bitcoin Whitepaper"라는 백서를 발표하며, 기존 비트코인 블록체인 위에 새로운 자산 또는 토큰을 생성하는 개념을 설명했고, 이것이 바로 후에 'MasterCoin'이라 불리게 된 프로젝트였다. 이후 이름은 Omni Layer로 변경된다.
Mastercoin 프로젝트는 2013년 초기 토큰 판매(현재 우리가 말하는 ICO 또는 초기 토큰 판매)를 진행해 수백만 달러를 성공적으로 모금했으며, 이는 역사상 최초의 ICO로 평가된다. Mastercoin의 가장 유명한 응용 사례는 USDT(테더)로, 가장 잘 알려진 법정화폐 스테이블코인인 USDT는 원래 Omni Layer 위에서 발행되었다.
사실 Mastercoin의 아이디어는 Colored Coins보다 더 먼저 나왔다. 여기서 두 번째로 다루는 이유는 Colored Coins에 비해 Mastercoin이 상대적으로 무거운(heavyweight) 솔루션이기 때문이다. Mastercoin은 완전한 노드 계층을 구축해 스마트 계약과 같은 더 복잡한 기능을 제공하는 반면, Colored Coins는 UTXO에 '색칠'하거나 표시해 다른 자산을 표현하는 데 집중하며 더 단순하고 직접적이다.
Colored Coins와 가장 큰 차이점은, Mastercoin은 체인 상에서 다양한 유형의 거래 행위만을 게시하고, 관련 자산 정보는 기록하지 않는다는 점이다. 대신 Mastercoin 노드는 비트코인 블록을 스캔해 오프체인(off-chain) 노드 내에서 상태 모델 데이터베이스를 유지 관리한다.
Colored Coins에 비해 더 복잡한 로직을 수행할 수 있으며, 체인 상에서 상태를 기록하거나 검증하지 않기 때문에 거래 간 연속성이(지속적인 색칠) 요구되지 않는다.
그러나 Mastercoin의 복잡한 로직을 실현하기 위해선 사용자가 오프체인 데이터베이스의 상태를 신뢰하거나, 직접 Omni Layer 노드를 실행해 검증해야 한다.
요약
Mastercoin과 Colored Coins의 가장 큰 차이는 프로토콜에 필요한 모든 데이터를 체인 상에 유지하지 않고, BTC의 합의 시스템을 '기생'하여 자신의 거래 게시 및 순서 정렬을 실현하고, 상태는 오프체인 데이터베이스에서 관리한다는 점이다.
OmniBolt의 관련 정보에 따르면, Omni Layer는 테더(Tether)에 새로운 UBA(UTXO 기반 자산) 프로토콜을 제안하고 있으며, Taproot 업그레이드를 활용해 자산 정보를 tapleaf에 인코딩함으로써 조건부 결제 등의 기능을 구현할 계획이다. 동시에 OmniBolt은 스타크(Stark)를 OmniLayer의 라이트닝 네트워크 인프라에 도입하고 있다.
클라이언트 검증(Client Side Validation) 개념
클라이언트 검증 개념을 이해하려면 시간을 Colored Coins와 Mastercoin이 등장한 직후인 2013년으로 되돌려야 한다. Peter Todd는 이 해에 Disentangling Crypto-Coin Mining: Timestamping, Proof-of-Publication, and Validation라는 글을 발표했다. 제목만 보면 클라이언트 검증과 관련 없어 보이지만, 자세히 읽어보면 이것이 클라이언트 검증의 원조 사상임을 알 수 있다.
Peter Todd는 비트코인과 암호학의 초기 연구자로, 비트코인의 작동 방식을 더 효율적으로 만들 방법을 끊임없이 탐구해왔다. 그는 타임스탬프 개념을 기반으로 더 복잡한 클라이언트 검증 개념을 개발했으며, 이후 언급될 "single use seal" 개념도 제안했다.
Peter Todd의 사상을 따라가며 먼저 비트코인이 실제로 어떤 문제를 해결하는지 살펴보자. Peter Todd에 따르면, 비트코인은 세 가지 문제를 해결한다:
-
게시 증명(Proof-of-publication)
게시 증명은 본질적으로 이중지불 문제를 해결한다. 예를 들어 Alice가 자신의 비트코인을 Bob에게 보내려 할 때, 서명을 통해 거래를 전송했더라도 Bob은 물리적으로 그 존재를 반드시 알 수 없다. 따라서 누구나 거래를 게시하고 조회할 수 있는 공개 장소가 필요하다.
-
거래 순서 결정(Order consensus)
컴퓨터 시스템에서는 우리가 경험하는 물리적 시간이 존재하지 않는다. 분산 시스템에서는 일반적으로 램포트 시계(Lamport clock)와 같은 분산 시계를 사용하는데, 이는 물리적 시간을 측정하는 것이 아니라 거래의 순서를 결정하는 데 사용된다.
-
거래 검증(Validation)(선택 사항)
BTC 상의 검증은 서명과 비트코인 이체 금액 검증을 의미한다. 그러나 Peter Todd는 이 검증이 BTC 위에 토큰 시스템을 구축하는 데 필수적이지 않으며, 단지 최적화 옵션일 뿐이라고 주장한다.
여기까지 읽으면 앞서 언급한 OmniLayer를 떠올릴 수 있다. OmniLayer는 상태 계산과 검증을 BTC에 맡기지 않았지만, 동시에 BTC의 보안성을 재사용하고 있다. 반면 Colored Coins는 상태 추적을 BTC에 위임했다. 이 두 사례는 검증이 반드시 체인 상에서 이루어질 필요는 없다는 것을 입증한다.
클라이언트 검증은 어떻게 거래를 효과적으로 검증하는가?
먼저 검증이 필요한 항목은 무엇인지 살펴보자:
-
상태(거래 로직 검증)
-
입력 TxIn이 유효한가?(이중지불 방지)
BTC 상에 발행된 자산은 매번 거래 시 관련된 전체 거래 이력을 검증해야 입력이 소비되지 않았고 상태가 올바름을 보장할 수 있다. 이는 매우 비효율적이며, 어떻게 개선할 수 있을까?
Peter Todd는 검증의 초점을 바꿔 이 과정을 단순화할 수 있다고 본다. 출력이 이중지불되지 않았는지 확인하는 대신, 거래 입력이 게시되었고 다른 입력과 충돌하지 않는지에 초점을 맞추는 것이다. 각 블록의 입력을 정렬하고 머클 트리를 사용하면, 해당 입력의 전체 체인 상 이력이 아닌 일부 데이터만으로도 더 효율적으로 검증이 가능하다.
Peter Todd가 제안한 commitment tree 구조는 다음과 같다:
CTxIn -> CTxOut -> <merkle path> -> CTransaction -> <merkle path> -> CT= xIn
그러나 우리는 어떻게 체인 상에 이러한 commitment tree를 저장할 수 있을까? 여기서 '일회용 봉인(single use seal)' 개념이 등장하게 된다.
일회용 봉인(Single Use Seal)
Single use seal은 클라이언트 검증을 이해하는 핵심 개념 중 하나로, 화물 컨테이너를 보호하기 위한 실제 세계의 물리적 일회용 봉인과 유사하다. Single use seal은 고유한 객체로, 한 메시지에 대해서만 정확히 한 번 봉인할 수 있다. 요약하자면, 일회용 봉인은 이중지불을 방지하기 위한 추상적 메커니즘이다.
SealProtocol의 경우, 세 가지 요소와 두 가지 동작이 있다.
기본 요소:
-
l: seal(봉인)
-
m: message(메시지)
-
w: witness(증인)
기본 동작: 두 가지 기본 동작이 있다:
-
Close(l,m) → w: 메시지 m에 대해 봉인 l을 닫아 증인 w를 생성.
-
Verify(l,w,m) → bool: 봉인 l이 메시지 m에 대해 닫혔는지 검증.
single use seal의 구현에서 보안성은 공격자가 두 개의 서로 다른 메시지 m1과 m2를 찾아 동일한 봉인에 대해 Verify 함수가 true를 반환하게 하는 것을 불가능하게 해야 한다.
우선 일회용 봉인(Single-Use Seal)은 어떤 자산이나 데이터가 단 한 번만 사용되거나 잠금되는 것을 보장하는 개념이다. 비트코인 환경에서는 이는 일반적으로 UTXO(미사용 거래 출력)가 단 한 번만 소비될 수 있음을 의미한다. 따라서 비트코인 거래의 출력은 일회용 봉인으로 간주할 수 있으며, 이 출력이 다른 거래의 입력으로 사용될 때, 그 봉인은 "깨지거나" "사용"된다.
BTC 위의 CSV 자산의 경우, 비트코인 자체가 일회용 봉인의 "증인(witness)" 역할을 한다. 왜냐하면 비트코인 거래를 검증하기 위해 노드는 각 입력이 유효하고 아직 소비되지 않은 UTXO를 참조하는지 확인해야 하기 때문이다. 만약 거래가 이미 사용된 UTXO를 이중지불하려고 시도하면, 비트코인의 합의 규칙과 네트워크의 정직한 노드들이 그 거래를 거부할 것이다.
좀 더 간단히 설명할 수 없을까?
single use seal은 임의의 블록체인을 하나의 데이터베이스로 간주하고, 어떤 메시지의 커밋먼트를 특정 방식으로 그 데이터베이스에 저장하며, 해당 항목이 소비되었는지 또는 미소비 상태인지 관리하는 것이다.
네, 정말 이 정도로 간단하다.
이상에서 클라이언트 검증 자산은 다음과 같은 특징을 갖는다:
-
오프체인 데이터 저장: 클라이언트 검증 자산의 거래 이력, 소유권 및 기타 관련 데이터는 대부분 오프체인에 저장된다. 이는 체인 상의 데이터 저장 수요를 크게 줄이고, 프라이버시 향상에도 기여한다.
-
커밋먼트 메커니즘: 자산 데이터는 체외에 저장되지만, 이 데이터의 변경이나 이전은 커밋먼트(commitments)를 통해 체인 상에 기록된다. 이러한 커밋먼트는 체인 상 거래가 체외 상태를 참조할 수 있게 하며, 체외 데이터의 무결성과 변조 방지를 보장한다.
-
체인 상 증인(필수는 아님, BTC 아닐 수 있음): 대부분의 데이터와 검증은 체외에서 이루어지지만, 체인 상에 임베드된 커밋먼트를 통해 클라이언트 검증 자산은 여전히 기반 체인의 보안성(게시 증명, 거래 순서 정렬)을 활용할 수 있다.
-
검증 작업은 클라이언트에서 수행: 대부분의 검증 작업은 사용자 장치에서 완료된다. 즉, 전 네트워크 노드가 모든 거래의 검증에 참여할 필요가 없으며, 관련 당사자만 거래의 유효성을 검증하면 된다.
클라이언트 검증 자산을 사용하는 사람들은 다음 점에 유의해야 한다:
체외에서 거래하고 클라이언트 검증 자산을 검증할 때, 자산의 개인키를 제시하는 것 외에도 해당 자산의 전체 머클 경로 증명을 함께 제시해야 한다.
클라이언트 검증(CSV)의 선구자: RGB
RGB 개념은 2015년 이후 커뮤니티의 유명인사인 Giacomo Zucco에 의해 제안되었다. 이더리움의 부상과 ICO의 난립 시기에, 많은 사람들이 비트코인 외에서 Mastercoin, Colored Coins 프로젝트와 같이 새로운 시도를 해왔다.
Giacomo Zucco는 이러한 프로젝트들에 실망했다. 그는 이들이 모두 비트코인만큼 우수하지 못하며, 이전의 비트코인 위 토큰 구현 방식이 모두 부적절하다고 생각했다. 그러던 중 Peter Todd를 만나게 되었고, 그의 클라이언트 검증(Client-Side-Validation) 아이디어에 매료되어 RGB 개념을 제안하게 되었다.
RGB는 이전 자산 프로토콜과의 차이점 외에도, 튜링 완전한 계약 실행 엔진을 위한 실행 VM을 추가했다. 또한 계약 데이터의 보안을 보장하기 위해 Schema와 Interface를 설계했다. Schema는 이더리움의 스마트 계약과 유사하게 계약의 내용과 기능을 선언하며, Interface는 구체적인 기능을 구현하는 역할을 한다(프로그래밍 언어의 interface와 동일).
이러한 계약의 schema는 VM 실행 시 예상치 못한 행동을 제한한다. 예를 들어 RGB20과 RGB21은 각각 동질화 토큰과 비동질화 토큰의 거래에 대한 제한을 담당한다.
RGB의 커밋먼트 메커니즘: PerdersenHash
커밋먼트 메커니즘 측면에서 RGB는 Perdersen 해시를 채택했다. 장점은 값을 커밋하면서도 공개하지 않을 수 있다는 점이다. Pedersen 해시를 사용해 머클 트리를 구성하면, 내부 값을 숨기는 프라이버시 보호 머클 트리를 만들 수 있다. 이러한 구조는 일부 익명 암호화폐 프로젝트와 같은 특정 프라이버시 보호 프로토콜에 활용될 수 있다. 그러나 CSV 자산에는 적합하지 않을 수 있으며, 이후 Taproot Assets와의 비교에서 언급될 것이다.
RGB의 가상머신 설계: Simplicity → AluVM
RGB의 목표는 단순한 클라이언트 검증 자산 프로토콜을 구현하는 데 그치지 않고, 튜링 완전한 가상머신 실행 및 계약 프로그래밍까지 확장하는 것이다. 초기 RGB 설계에서 Simplicity라는 프로그래밍 언어를 사용한다고 밝혔는데, 이 언어는 표현식을 실행할 때 실행 증명을 생성하며, 계약 코드에 대한 형식적 검증(formal verification)이 용이해 버그를 피하기 쉬운 특징이 있었다. 그러나 이 언어의 개발은 성과를 얻지 못하고 결국 난관에 봉착했으며, 이는 당시 RGB 프로토콜 전반의 개발 지연으로 이어졌다. 결국 RGB는 Maxim이 개발한 AluVM을 사용하기 시작했는데, 이는 어떠한 미정의 동작(undefined behavior)도 피하는 것을 목표로 하며, 원래의 Simplicity와 유사하다. 새로운 AluVM은 향후 Contractum이라는 프로그래밍 언어로 현재 사용 중인 Rust를 대체할 예정이라고 한다.
RGB의 레이어2 확장 방향: 라이트닝 네트워크 vs 사이드체인?
클라이언트 검증 자산은 오프체인에서 안전하게 연속 거래를 보장할 수 없다. 왜냐하면 여전히 L1에 의존해 거래 게시와 순서 정렬을 수행하기 때문이다. 따라서 L2 확장 솔루션이 없을 경우, 거래 속도는 L1 증인의 블록 생성 속도에 제한을 받는다. 즉, 비트코인 상에서 직접 RGB 거래를 수행하면 엄격한 보안 요구 하에 두 관련 거래 사이의 최대 간격은 10분(BTC 블록 생성 시간)이 된다. 대부분의 경우 이러한 거래 속도는 받아들이기 어렵다.
RGB와 라이트닝 네트워크
라이트닝 네트워크의 원리는 간단히 말해, 거래 당사자 간에 체외에서 일련의 계약(커밋 거래)을 체결하는 것이다. 이를 통해 어느 한쪽이 계약을 위반할 경우, 피해를 입은 당사자가 그 계약(커밋 거래)을 BTC 네트워크에 제출해 자금을 회수하고 상대방을 처벌할 수 있도록 보장한다. 즉, 라이트닝 네트워크는 프로토콜과 게임 이론 설계를 통해 오프체인 거래의 보안성을 보장한다.
RGB는 RGB 자체에 맞는 지불 채널 계약 규칙을 설계해 자신의 라이트닝 네트워크 인프라를 구축할 수 있지만, 라이트닝 네트워크 자체의 복잡성이 매우 높아 이러한 시설을 구축하는 것은 쉬운 일이 아니다. 반면 Lightnling Labs는 이 분야에서 오랜 기간 개발을 진행해 왔으며, LND는 시장 점유율 90% 이상을 차지하고 있다.
RGB의 사이드체인 Prime
LNP-BP는 현재 RGB 프로토콜의 유지 관리자로, Maxim은 2023년 6월 **Prime**이라는 클라이언트 검증 자산 확장 방안을 발표했다. 그는 기존의 사이드체인과 라이트닝 네트워크 확장 방안이 개발 측면에서 너무 복잡하다고 비판했다. Maxim은 Prime 외의 확장 방식으로 NUCLEUS 멀티노드 라이트닝 채널과 Ark/Enigma 채널 팩토리가 있다고 말하며, 이 두 방식은 2년 이상의 개발 기간이 필요하다고 했다. 반면 Prime은 1년 만에 완료할 수 있다고 주장했다.
Prime은 전통적인 블록체인 설계가 아니라 클라이언트 검증을 위한 모듈화된 증명 게시 계층으로, 네 가지 구성 요소로 이루어져 있다:
-
타임스탬프 서비스
최대 10초 만에 거래 순서의 최종 확정. -
증명(proof)
PMT 형태로 저장되며, 블록 헤더와 함께 생성·게시됨. -
일회용 봉인
이중지불 방지를 보장하는 추상적 일회용 봉인 프로토콜. 비트코인 상에서 구현하면 UTXO에 연결하는 방식으로, 현재의 RGB 설계와 유사. -
스마트 계약 프로토콜
샤딩 계약-RGB (교체 가능)
여기서 볼 수 있듯, RGB 거래 확인 시간 문제를 해결하기 위해 Prime은 타임스탬프 서비스를 활용해 오프체인 거래를 신속하게 확인하고, 거래와 ID를 블록에 포함시킨다. 동시에 Prime 상의 거래 증명을 PMT로 병합한 후, 체크포인트(checkpoint) 방식으로 BTC에 앵커링할 수 있다.
Taproot 기반의 CSV 자산 프로토콜: Taproot Assets
Taproot Assets는 Taproot를 기반으로 한 CSV 자산 프로토콜로, 비트코인 블록체인 상에서 클라이언트 검증 자산을 발행하고, 라이트닝 네트워크를 통해 즉시, 대용량, 저비용으로 거래할 수 있도록 한다. Taproot Assets의 핵심은 비트코인 네트워크의 보안성과 안정성, 그리고 라이트닝 네트워크의 속도, 확장성, 저비용을 활용하는 것이다. 이 프로토콜은 Lightnling Labs의 CTO roasbeef가 설계 및 개발했으며, roasbeef는 이 세상에서 유일하게 비트코인 클라이언트(BTCD)와 라이트닝 네트워크 클라이언트(LND)를 직접 주도 개발한 비트코인 개발자로, BTC에 대한 이해도가 매우 깊다.
Taproot 거래는 자산 스크립트의 루트 해시만을 포함하므로, 외부 관찰자는 해당 거래가 Taproot Assets 관련인지 식별하기 어렵다. 해시 자체가 범용적이기 때문에 임의의 데이터를 나타낼 수 있기 때문이다. Taproot 업그레이드를 통해 비트코인은 스마트 계약(TapScript) 기능을 획득했다. 이를 기반으로 Taproot Assets의 자산 인코딩은 ERC20 또는 ERC721과 유사한 토큰 정의를 생성하는 것과 같다. 이로써 비트코인은 자산 정의 기능뿐 아니라 스마트 계약 작성 능력도 갖추게 되어, 비트코인 상의 토큰 스마트 계약 인프라의 초석을 마련했다.
Taproot Assets 인코딩 구조는 다음과 같다:
이미지 출처: Lightning Labs CTO roasbeef
같은 CSV 자산 프로토콜임에도 불구하고, Taproot Assets는 RGB 설계보다 훨씬 간결하며, 현재 BTC 생태계의 발전(Taproot 업그레이드, PSBT 등)을 최대한 활용한다. 응용 확장성 측면에서 Taproot Assets와 RGB의 가장 큰 차이점은 실행 VM이다. Taproot Assets는 BTC 원생 기본과 동일한 TaprootScriptVM을 사용한다. 최근 몇 년간 BTC 인프라에 대한 많은 연구가 TapScript를 기반으로 진행되었지만, BTC의 느린 업그레이드 속도로 인해 즉시 적용되지 못하고 있다. Taproot Assets는 이러한 새로운 아이디어들의 실험장이 될 가능성이 크다.
Taproot Assets와 RGB의 차이점은 무엇인가?
1. 거래 검증과 경량 노드 친화성
Taproot Assets는 sum tree 구현 덕분에 검증 효율과 보안성이 높다(소유 증명만으로 상태 검증 및 거래가 가능하며, 모든 입력 거래 이력을 탐색할 필요 없음). 반면 RGB는 pedersen 커밋을 사용해 입력의 유효성을 효과적으로 검증할 수 없어 입력 거래 이력을 역추적해야 하며, 거래가 복잡해질수록 부담이 커진다. Merkle sum 설계는 Taproot Assets가 경량 노드 검증을 쉽게 구현할 수 있게 하며, 이는 기존의 BTC 기반 자산 프로토콜에서는 존재하지 않았던 기능이다.
2. 실행 VM
Taproot Assets는 Taproot 업그레이드에 부응해 탄생했으며, 사용하는 TaprootScriptVM은 Taproot 업그레이드 후 비트코인이 자체적으로 갖춘 스크립트 실행 엔진이다. 또한 사용하는 vPSBT는 BTC의 PSBT를 변형한 것으로, Taproot Assets의 지불 채널 메커니즘이 개발 완료되면 현재 LND의 모든 인프라를 즉시 재사용할 수 있으며, Lightnling Labs의 기존 제품들도 활용할 수 있다(LND는 라이트닝 네트워크 시장 점유율 90% 이상). 최근 핫한 BitVM 제안도 TaprootScript를 기반으로 하며, 이론적으로 이러한 모든 개선 사항이 궁극적으로 Taproot Assets를 지원할 수 있다.
반면 RGB는 VM과 검증 규칙(SCHEMA)이 자체 체계를 이루고 있어 어느 정도 폐쇄적인 소규모 생태계라 할 수 있다. RGB 기반의 개발은 자신들의 생태계 내에서만 운영되며, 비트코인 생태계와의 연계는 우리가 생각하는 것만큼 밀접하지 않다. Taproot 업그레이드 예시를 들면, RGB와 Taproot 업그레이드의 유일한 관계는 체인 상 커밋 데이터를 Witness의 TapLeaf에 인코딩하는 것뿐이다.
3. 스마트 계약
현재 RGB의 구현 설계에서 계약과 VM은 매우 중요한 부분으로 강조되고 있다. 반면 Taproot Assets에서는 아직 스마트 계약의 모습을 찾을 수 없다. 다만 현재 RGB에서도 글로벌 상태 수정이 각 독립 계약 샤딩(UTXO)과 어떻게 동기화되는지에 대한 설명이 부족하다. 또한 Pedersen 커밋은 자산 총량만 보장할 수 있고, 다른 상태가 조작되었는지 어떻게 보장할 수 있는지는 아직 명확하지 않다. Taproot Assets는 설계가 간결하지만 현재 상태 저장은 자산 잔고에 국한되어 있으며, 더 많은 상태 정보를 포함하지 않아 스마트 계약이라고 말하기는 어렵다. 다만 Lightning Labs에 따르면 내년에 Taproot Assets가 스마트 계약 설계에 집중할 예정이라고 한다.
4. 동기화 센터
앞서 언급한 클라이언트 검증 자산의 기본 원칙에 따르면, 증명(proof)과 개인키 소유가 동등하게 중요하다. 그러나 증명이 사용자 클라이언트에 계속 남아 있으면 분실되기 쉽다. 이를 어떻게 해결할까? Taproot Assets에서는 universe를 통해 이런 문제를 피할 수 있다. Universe는 하나 이상의 자산을 포괄하는 공개 감사 가능한(MS-SMT) 시스템이다. 일반적인 Taproot 자산 트리와 달리, Universe는 Taproot 자산을 호스팅하지 않는다. 대신 하나 이상의 자산 이력의 하위 집합을 커밋한다.
RGB에서는 이 역할을 Storm이 맡고 있으며, 오프체인 증명 데이터를 P2P 방식으로 동기화 저장한다. 그러나 RGB 개발팀의 역사적 이유로 현재 각 팀의 증명 형식은 상호 호환되지 않는다. RGB 생태계 팀 DIBA는 이 문제를 해결하기 위해 carbonado를 개발하겠다고 밝혔지만, 현재 진행 상황은 불투명하다.
5. 공학적 구현
Taproot Assets가 사용하는 모든 라이브러리는 오랜 기간 검증된 것이다. Lightnling Labs는 자체 비트코인 클라이언트(BTCD), 라이트닝 네트워크 클라이언트(LND), 그리고 다수의 wallet lib 구현체를 보유하고 있기 때문이다. 반면 RGB 구현에 사용되는 라이브러리는 대부분 자체 정의된 것으로, 산업 표준 관점에서 보면 아직 실험실 단계에 머물러 있다.
비트코인 확장의 미래 전망
여기까지 살펴보면, 클라이언트 검증 자산 프로토콜이 프로토콜의 범주를 넘어 계산 확장 방향으로 나아가고 있음을 알 수 있다.
많은 사람들이 미래에 비트코인은 디지털 골드로 존재하고, 다른 체인들이 애플리케이션 생태계를 구축할 것이라고 말한다. 그러나 이에 대해 나는 다른 견해를 갖고 있다. 비트코인 포럼에서 많은 논의는 다양한 알트코인(alt-coin)과 그 짧은 생명에 관한 것이다. 이러한 알트코인의 빠른 소멸은 그들을 중심으로 형성된 자본과 노력이 모두 거품으로 돌아가는 결과를 낳았다. 우리는 이미 비트코인이라는 강력한 합의 기반을 가지고 있으므로, 애플리케이션 프로토콜을 위해 새로운 L1을 구축할 필요는 없다. 우리가 해야 할 일은 이 가장 강력한 인프라를 어떻게 잘 활용해 더 오래 지속되는 탈중앙화 세계를 구축하는지다.
더 적은 체인 상 계산, 더 많은 체인 상 검증
애플리케이션 설계 측면에서 보면, 비트코인은 초기부터 체인 상 계산을 핵심 목표로 삼기보다 검증 중심의 설계 철학을 선택했다(Turing completeness and state for smart contract). 블록체인의 본질은 복제 상태 머신(replicated state machine)인데, 만약 체인의 합의가 체인 상 계산에 두어진다면, 네트워크 내 모든 노드가 그 계산을 반복하는 것이 합리적이고 확장 가능한 방법인지 의문이다. 검증 중심이라면 오프체인 거래의 유효성을 검증하는 것이 BTC 확장에 가장 적합한 방안일 수 있다.
검증이 어디서 발생하는가? 이것이 중요하다
비트코인 위의 프로토콜 개발자들에게 있어, 비트코인을 어떻게 핵심 검증 수단으로 활용할지, 혹은 검증을 오프체인으로 옮기는 방법, 안전한 설계 방안 등을 고민하는 것은 프로토콜 설계자의 몫이며, 체인 자체와 연관될 필요도 없고 있어서도 안 된다. 따라서 검증 방식의 설계는 BTC의 다양한 확장 방안을 파생시킨다.
검증 기반의 관점에서 우리는 세 가지 확장 방향을 가진다:
-
검증이 체인 상에서 발생(OP-ZKP)
TaprootScriptVM 내에서 직접 OP-ZKP를 구현한다면, BTC 자체에 ZKP 검증 기능을 추가하는 것이며, 이에 Covenant 설계와 결제 프로토콜을 결합하면 BTC의 보안성을 계승하는 Zk-Rollup 확장 방안을 만들 수 있다. 그러나 이더리움에 검증 계약을 배포하는 것과 달리, BTC의 업그레이드 자체가 느리고, 이러한 비범용적이며 향후 업그레이드가 필요한 op-code를 추가하는 것은 극히 어려운 일이다.
-
검증이 반 체인 상에서 발생(BitVM)
BitVM의 설계는 일반적인 거래 로직 서비스를 위한 것이 아니며, Robin linus도 BitVM의 미래는 다양한 사이드체인 간 자유로운 교차 체인 시장임을 밝혔다. BitVM 방식을 반 체인 상에서 발생한다고 말하는 이유는 대부분의 검증 계산이 체인 상에서 발생하지 않고 오프체인에서 이루어지기 때문이다. 그러나 BTC의 Taproot를 중심으로 설계하는 중요한 이유는 필요한 순간 TapScriptVM을 활용해 계산 검증을 수행할 수 있도록 하기 위함이며, 이는 이론적으로 BTC의 보안성을 계승하기 위한 것이다. 이 과정에서 검증 신뢰 체인이 생성되는데, n명의 검증자 중 한 명만 정직하더라도 된다는 Optimistic Rollups 모델과 유사하다.
BitVM은 체인 상 오버헤드가 크지만, ZK 사기 증명을 사용해 효율을 향상시킬 수 있을까? 답은 부정적이다. 왜냐하면 ZK 사기 증명의 구현은 체인 상에서 ZKP를 검증할 수 있어야 하기 때문이며, 이는 다시 OP-ZKP 방안의 난관으로 돌아가기 때문이다.
-
검증이 체인 외에서 발생(Client-Side-Validation, Lightning Network)
검증이 완전히 체인 외에서 발생한다면, 이는 앞서 논의한 CSV 자산 프로토콜과 라이트닝 네트워크를 의미한다. 앞선 논의에서 CSV 설계는 공모 조작(collusion)을 완전히 배제할 수 없음을 보여주었다. 우리가 할 수 있는 것은 암호학과 프로토콜 설계를 통해 이러한 악의적 공모의 피해 범위를 통제 가능한 수준으로 줄이고, 이로 인한 이익이 없는 상태로 만드는 것이다.
체인 외 검증의 장점과 단점은 매우 명확하다. 장점은 체인 상 자원 사용이 극히 적고 확장 잠재력이 매우 크다는 점이다. 단점은 거의 불가능하게 BTC의 보안성을 완전히 재사용할 수 없다는 점으로, 이는 체인 외에서 수행할 수 있는 거래 유형과 방식에 극심한 제약을 준다. 또한 체인 외 검증은 데이터가 모두 체인 외에 있으며 사용자가 직접 보관해야 함을 의미하므로, 소프트웨어 실행 환경의 보안성과 안정성에 더 높은 요구를 한다.
확장 진화의 추세
현재 이더리움에서 유행하는 레이어2는 패러다임상 Layer1이 Layer2의 계산 유효성을 검증하는 방식이다. 즉, 상태 계산은 Layer2로 하향되지만 검증은 여전히 Layer1에 남아있다. 미래에는 검증 계산 역시 체인 외로 하향시켜 기존 블록체인 인프라의 성능을 더욱 해방시킬 수 있을 것이다.
TechFlow 공식 커뮤니티에 오신 것을 환영합니다
Telegram 구독 그룹:https://t.me/TechFlowDaily
트위터 공식 계정:https://x.com/TechFlowPost
트위터 영어 계정:https://x.com/BlockFlow_News
@wooooer
