원저자: Ben (X: @wooooer)
머리말
BTC를 기반으로 한 자산 발행은 항상 뜨거운 주제였습니다. 2011년에 처음 등장한 Colored Coins부터 최근 인기를 끌고 있는 Ordinal 프로토콜에 이르기까지 BTC 커뮤니티에는 항상 새로운 플레이어와 합의가 등장하고 있지만 남아 있는 것은 거의 없습니다. 그러나 야심찬 Lightling Labs가 Taproot 자산을 기반으로 하는 스테이블 코인을 구축하려는 계획을 발표하면서 Tether도 비트코인 레이어에서 USDT 발행을 위해 RGB를 선택할 것이라고 발표했습니다.
이는 한때 유명했던 OmniLayer(Mastercoin)가 더 이상 BTC 생태계에서 가장 큰 플레이어가 아니라는 것을 의미합니다.클라이언트 측 검증(CSV) 자산 프로토콜이 모든 사람의 시야에 들어오기 시작했습니다.기존 BTC 자산 프로토콜과의 차이점은 또한 BTC의 속성을 확장하기 위해 가져옵니다. 그러나 BTC 생태계의 수많은 자산 프로토콜 앞에서 사람들은 그들의 차이점이 무엇인지 묻지 않을 수 없습니다.너무 많은 자산 프로토콜 앞에서 우리는 어떻게 기회를 선택하고 찾아야 할까요? 이 기사를 통해 모든 사람이 BTC의 역사에 등장한 자산 프로토콜을 검토하고 BTC 자산 프로토콜 개발의 미래를 탐색할 수 있기를 바랍니다.
컬러 동전: 컬러 동전
Colored Coins의 아이디어는 현재 eToro의 CEO인 Yoni Assia가 다음과 같은 제목의 기사에서 처음 작성했습니다.bitcoin 2.X (aka Colored bitcoin)기사가 발표되었습니다. 기사에서는 HTTP가 네트워크의 기초인 것처럼 기본 기술인 비트코인도 완벽하다고 믿습니다. 따라서 토큰 프로토콜 Colored Coins는 BTC의 재사용을 기반으로 설계되었습니다.
Yoni Assia는 모든 커뮤니티가 여러 통화를 생성할 수 있는 방식으로 BTC 2.0 경제를 창출하기를 희망합니다. 거래를 청산하고 이중 지불을 방지하기 위한 기본 기술로 비트코인을 사용하는 이 방법은 의심할 여지 없이 당시에는 매우 대담한 아이디어였습니다.
컬러드 코인(Colored Coins)은 비트코인을 기반으로 자산을 발행하기 위한 프로토콜로, 해당 자산을 표현하기 위해 특정 수의 비트코인을 색칠하는 접근 방식입니다. 이러한 토큰화된 비트코인은 기능적으로는 여전히 비트코인이지만, 또 다른 자산이나 가치를 나타내기도 합니다. 하지만 그러한 아이디어가 비트코인에서 어떻게 구현될 수 있을까요?
2014년 7월 3일 ChromaWay는 개발자가 컬러 코인을 생성하는 프로세스를 단순화하는 EPOBC(Enhanced Fill-Order-Based Colouring Protocol)를 개발했습니다. 이는 비트코인 스크립트의 OP_RETURN 기능을 채택한 최초의 프로토콜이었습니다.
최종 효과는 아래 그림에 나와 있습니다.
이 구현은 매우 간단하지만 많은 문제도 발생합니다.
1. 대체 가능한 토큰 및 최소 바인딩 값
제네시스 거래에서 염색 코인에 1000 sat이 결속되어 있는 경우, 염색 코인의 최소 분할 단위는 1 sat입니다. 이는 자산이나 토큰을 최대 1,000주까지 분할하거나 배포할 수 있음을 의미합니다(그러나 이는 단지 이론적일 뿐이며 더스트 공격을 방지하기 위한 것입니다. 예를 들어 올해 SAT는 546 SAT로 설정되어 있으며 이후에는 순서가 더 높음).
2. 검증 문제
컬러 코인의 진위 여부와 소유권을 판단하기 위해서는 해당 자산의 최초 거래부터 현재 UTXO까지 검증 과정을 추적해야 합니다. 따라서 지갑을 특별히 개발하고 풀노드, 심지어 브라우저까지 지원하는 것이 필요합니다.
3. 잠재적인 채굴자 검열 위험
ColoredTransaction의 특성이 더 명확하기 때문에, 즉 메타데이터 정보가 출력에 기록되므로 채굴자 검토의 가능성이 높아집니다.
컬러 코인은 실제로 비트코인의 확인 규칙을 사용하여 자산 전송을 추적하는 자산 추적 시스템입니다. 그러나 특정 출력(txout)이 특정 자산을 나타낸다는 것을 증명하려면 자산의 출처부터 현재까지 완전한 전송 체인이 제공되어야 합니다. 이는 거래의 적법성을 확인하려면 긴 일련의 증명이 필요할 수 있음을 의미합니다. 이 문제를 해결하기 위해 원래 누군가가 제안했습니다.OP_CHECKCOLORVERIFY비트코인에서 컬러 코인 거래의 정확성을 직접 검증하는 데 도움을 주기 위해 제안이 통과되지 않았습니다.
암호화폐 업계 최초의 ICO: Mastercoin
Mastercoin의 원래 개념은 JR Willett이 제안했습니다. 2012년에 그는"The Second Bitcoin Whitepaper"백서는 나중에 MasterCoin으로 알려지게 된 비트코인의 기존 블록체인에서 새로운 자산이나 토큰을 생성하는 개념을 설명했습니다. 나중에 Omni Layer로 이름이 바뀌었습니다.
Mastercoin 프로젝트는 2013년에 초기 토큰 판매(현재는 ICO 또는 초기 코인 판매라고 함)를 실시했으며 역사상 최초의 ICO로 간주되는 수백만 달러를 성공적으로 모금했습니다. Mastercoin의 가장 유명한 애플리케이션은 Tether(USDT)로, 가장 잘 알려진 합법적인 스테이블 코인이며 원래 Omni Layer에서 발행되었습니다.
사실 마스터코인이라는 아이디어는 컬러코인보다 먼저 등장했는데 여기서 두 번째로 논의하는 이유는 컬러코인에 비해 마스터코인이 상대적으로 무거운 솔루션이기 때문입니다. MasterCoin은 더 복잡한 기능(예: 스마트 계약)을 제공하기 위해 완전한 노드 레이어를 구축하는 반면, Colored Coins는 더 간단하고 더 간단하며 주로 다른 자산을 나타내기 위해 Bitcoin UTXO를 채색하거나 표시하는 데 중점을 둡니다.
Colored Coins과 가장 큰 차이점은 Mastercoin이 체인에 다양한 유형의 거래 행위만 게시하고 관련 자산 정보를 기록하지 않는다는 것입니다. Mastercoin 노드에서는 상태 모델의 데이터베이스가 Bitcoin 블록을 스캔하여 오프체인 노드에 유지됩니다.
컬러 코인에 비해 완성할 수 있는 논리는 더 복잡합니다. 그리고 상태가 체인에 기록되고 검증되지 않기 때문에 거래 간의 연속성(지속적인 색상)에 대한 요구 사항이 없습니다.
그러나 Mastercoin의 복잡한 논리를 구현하려면 사용자는 노드에 있는 오프체인 데이터베이스의 상태를 신뢰하거나 Omni Layer 노드가 스스로 확인할 수 있도록 허용해야 합니다.
요약하다:
Mastercoin과 Colored Coins의 가장 큰 차이점은 프로토콜에 필요한 모든 데이터를 체인에서 유지하도록 선택하지 않고 대신 BTC 합의 시스템을 기생하여 자체 트랜잭션 게시 및 정렬을 구현한 다음 상태를 유지한다는 점입니다. 오프체인 데이터베이스. .
OmniBolt에서 제공한 관련 정보에 따르면 Omni Layer는 TEDA에 새로운 UBA(UTXO 기반 자산) 자산 프로토콜을 제안하고 있으며 Taproot를 사용하여 조건부 결제와 같은 기능을 달성하기 위해 자산 정보를 tapleaf로 업그레이드하고 컴파일할 것입니다. 동시에 OmniBolt는 OmniLayer의 Lightning Network 시설에 Stark를 도입하고 있습니다.
클라이언트 측 유효성 검사 아이디어
클라이언트측 검증의 개념을 이해하려면 컬러코인과 마스터코인이 등장한 2년차인 2013년으로 돌아가야 합니다. Peter Todd는 해당 연도에 다음과 같은 기사를 발표했습니다.Disentangling Crypto-Coin Mining: Timestamping, Proof-of-Publication, and Validation. 글의 이름은 클라이언트 측 검증과 아무 관련이 없는 것 같지만, 자세히 읽어보면 이것이 클라이언트 측 검증에 대한 가장 초기의 계몽 아이디어라는 것을 알 수 있습니다.
Peter Todd는 비트코인과 암호화의 초기 연구자였으며 항상 비트코인이 더 효율적으로 작동하는 방식을 만드는 방법을 찾고 있었습니다. 그는 타임스탬프 개념을 기반으로 보다 정교한 클라이언트 측 유효성 검사 개념을 개발했습니다. 아울러 그는 후술할 일회용 봉인 개념도 제안했다.
이제 Peter Todd의 생각을 따라 BTC가 실제로 어떤 종류의 문제를 해결하는지 먼저 이해해 보겠습니다. Peter Todd에 따르면 BTC는 총 세 가지 문제를 해결한 것으로 보입니다.
출판 증명
증명 공개의 본질은 이중지불 문제를 해결하는 것입니다.예를 들어 Alice는 일부 비트코인을 Bob에게 전송하려고 합니다. 비록 그녀가 거래에 서명하고 Bob에게 전송했지만 Bob은 그러한 전송이 존재한다는 것을 반드시 알지는 못합니다. 육체적으로. . 따라서 거래를 게시할 공개 장소가 필요하며 모든 사람이 그곳에서 거래를 쿼리할 수 있습니다.
거래 주문(주문 합의)
컴퓨터 시스템에는 우리가 일반적으로 경험하는 물리적 시간이 없습니다. 분산 시스템에서 이 시간은 일반적으로 분산 시계 램버입니다. 이 시계는 물리적 시간을 측정하는 것이 아니라 트랜잭션 순서를 지정합니다.
거래 검증(선택 사항)
BTC 검증은 서명 및 BTC 이체 금액 검증에 관한 것입니다. 그러나 Peter Todd는 BTC 위에 토큰 시스템을 구축하는 데 이러한 검증이 필요하지 않으며 단지 최적화 옵션일 뿐이라고 믿습니다.
이 내용을 보면 실제로 앞서 언급한 Ominilayer를 생각하신 것입니다.OminiLayer 자체는 상태 계산 및 검증을 BTC에 넘기지 않고 BTC의 보안도 재사용합니다. 컬러 코인은 상태 추적을 BTC에 넘겨줍니다. 이 두 가지의 존재는 검증이 반드시 온체인에서 이루어질 필요가 없다는 것을 입증했습니다.
그렇다면 클라이언트 측 확인은 어떻게 효과적으로 거래를 확인합니까?
먼저 확인해야 할 사항을 살펴보겠습니다.
1. 상태(트랜잭션 로직 검증)
2. 입력된 TxIn이 유효한지 확인합니다. (이중 지출 방지를 위해)
비트코인에 게시된 자산을 찾는 것은 쉽습니다. 각 거래는 참조된 입력이 소비되지 않았는지, 상태가 올바른지 확인하기 위해 전체 관련 거래 내역을 확인해야 합니다. 이는 매우 불합리한데 어떻게 개선해야 할까요?
Peter Todd는 검증의 초점을 변경함으로써 이 프로세스를 단순화할 수 있다고 믿습니다. 이 접근 방식은 출력이 이중 지출되지 않았는지 확인하는 대신 거래 입력이 게시되었고 다른 입력과 충돌하지 않는지 확인하는 데 중점을 둡니다. 각 블록의 입력을 정렬하고 Merkle 트리를 사용하면 각 검증에 해당 입력의 전체 온체인 기록이 아닌 데이터의 작은 부분만 필요하기 때문에 이 검증을 보다 효율적으로 수행할 수 있습니다.
Peter Todd가 제안한 커밋 트리 구조는 다음과 같습니다.
CTxIn -> CTxOut ->
하지만 그러한 헌신 트리를 체인에 어떻게 저장합니까? 그래서 여기서 일회용 씰의 개념을 소개할 수 있습니다.
일회용 씰
클라이언트측 검증을 이해하는 핵심 개념 중 하나는 일회용 봉인입니다. 이는 실제 배송 컨테이너를 보호하는 데 사용되는 물리적 일회용 봉인과 유사합니다. 일회용 봉인은 메시지에서 정확히 한 번만 닫을 수 있는 고유한 개체입니다. 즉, 원샷 씰은 이중 지출을 방지하기 위해 사용되는 추상적인 메커니즘입니다.
SealProtocol에는 세 가지 요소와 두 가지 작업이 있습니다.
기본 요소:
l： seal,즉, 봉인하다
m： message,정보
w：witness,증인
기본 작업: 두 가지 기본 작업이 있습니다.
Close(l,m) → w: 메시지 m의 봉인 l을 닫고 증인 w를 생성합니다.
Verify(l, w,m) → bool: 메시지 m에서 씰 l이 닫혀 있는지 확인합니다.
보안 측면에서 일회용 봉인을 구현하면 공격자가 두 개의 서로 다른 메시지 m 1 과 m 2 를 찾는 것을 허용할 수 없으며 동일한 봉인에 대해 확인 기능이 true를 반환하게 됩니다.
우선, Single-Use Seal은 특정 자산이나 데이터를 한 번만 사용하거나 잠그는 것을 보장하는 개념입니다. 비트코인의 맥락에서 이는 일반적으로 UTXO(사용되지 않은 거래 출력)가 한 번만 사용될 수 있음을 의미합니다. 따라서 비트코인 거래의 출력은 일회성 봉인으로 간주될 수 있으며, 이 출력이 다른 거래의 입력으로 사용되면 봉인이 깨졌거나 사용된 것입니다.
BTC의 CSV 자산의 경우 비트코인 자체가 단일 인장의 증인 역할을 합니다. 이는 비트코인 거래를 검증하기 위해 노드가 거래에 대한 각 입력이 유효하고 사용되지 않은 UTXO를 참조하는지 확인해야 하기 때문입니다. 거래가 이미 소비된 UTXO를 이중 지출하려고 시도하는 경우 비트코인의 합의 규칙과 네트워크 전체의 정직한 노드는 거래를 거부합니다.
더 간단해질 수 있나요?
일회용 씰은 모든 블록체인을 데이터베이스로 취급하는 것이며, 특정 메시지의 약속을 어떤 방식으로든 이 데이터베이스에 저장하고 이에 대한 소비 또는 소비 예정 상태를 유지합니다.
예, 아주 간단합니다.
요약하면, 고객이 검증한 자산은 다음과 같은 특징을 가지고 있습니다.
오프체인 데이터 저장:고객이 검증한 자산은 대부분 거래 내역, 소유권 및 기타 관련 데이터가 오프체인에 저장되어 있습니다. 이는 온체인 데이터 저장 요구 사항을 크게 줄이고 개인 정보 보호를 향상하는 데 도움이 됩니다.
헌신 메커니즘:자산 데이터는 오프체인에 저장되지만 이 데이터에 대한 변경 또는 전송은 약속을 통해 온체인에 기록됩니다. 이러한 약속은 온체인 트랜잭션이 오프체인 상태를 참조할 수 있도록 하여 오프체인 데이터의 무결성과 변조 불가능성을 보장합니다.
온체인 증인(반드시 BTC일 필요는 없음):대부분의 데이터와 검증은 오프체인이지만 고객이 검증한 자산은 온체인에 포함된 약속을 통해 기본 체인의 보안(증명 발행, 거래 주문)을 계속 활용할 수 있습니다.
작업 클라이언트가 완료되었는지 확인합니다.대부분의 확인 작업은 사용자의 장치에서 수행됩니다. 이는 모든 네트워크 노드가 각 거래를 확인하는 데 참여할 필요가 없으며 관련된 참가자만 거래의 유효성을 확인하면 된다는 것을 의미합니다.
클라이언트 측 자산 확인을 사용하는 경우 주목해야 할 또 다른 사항이 있습니다.
오프체인 거래 및 고객이 확인한 자산 검증 시, 자산을 보유하고 있는 개인 키를 제시해야 할 뿐만 아니라 해당 자산의 전체 메르켈 경로에 대한 증거도 제시해야 합니다.
클라이언트측 검증(CSV)의 선구자: RGB
RGB의 개념은 2015년 이후 커뮤니티에서 잘 알려진 Giacomo Zucco에 의해 제안되었습니다. 이더리움의 등장과 ICO의 확산으로 인해 ICO 이전에는 많은 사람들이 비트코인 외부에서 다음과 같은 작업을 시도했습니다. Mastercoin 및 Colored Coins 프로젝트.
Giacomo Zucco는 실망감을 표시했습니다. 그는 이러한 프로젝트가 비트코인보다 열등하다고 생각하며, 비트코인에 토큰을 구현하는 이전 방식이 부적절하다고 믿습니다. 그 과정에서 그는 Peter Todd를 만났고 Peter Todd의 Client-Side-Validation 아이디어에 매료되었습니다. 그러더니 프로포즈를 하기 시작했다RGB아이디어.
RGB와 이전 자산 프로토콜의 가장 큰 차이점은 앞서 언급한 클라이언트 측 자산 검증 기능 외에도 Turing-complete 계약 실행 엔진을 구현하기 위해 실행 VM도 추가한다는 것입니다. 또한 계약 데이터의 보안을 보장하기 위해 Schema 및 Interface도 설계되었습니다. 스키마는 계약의 내용과 기능을 선언하는 이더리움과 유사하며, 인터페이스는 프로그래밍 언어의 인터페이스와 마찬가지로 특정 기능의 구현을 담당합니다.
이러한 계약의 스키마는 vm이 실행될 때 예상되는 동작을 초과하지 않는 동작을 제한하는 역할을 합니다(예: RGB 20 및 RGB 21). 이는 각각 대체 가능 토큰 및 대체 불가능 토큰의 거래에 대한 일부 제한을 담당합니다.
RGB의 커밋 메커니즘 PerdersenHash
커밋 메커니즘의 관점에서 볼 때 RGB는 Perdersen 해싱을 사용합니다. 공개하지 않고도 가치를 약속할 수 있다는 장점이 있습니다. Pedersen 해시를 사용하여 Merkle 트리를 구축한다는 것은 그 안에 값을 숨기는 개인 정보 보호 Merkle 트리를 생성할 수 있음을 의미합니다. 이 구조는 일부 익명 암호화폐 프로젝트와 같은 특정 개인 정보 보호 프로토콜에서 사용될 수 있습니다. 하지만 나중에 Taproot Assets과의 비교에서 언급할 CSV 자산에는 적용되지 않을 수 있습니다.
RGB 가상 머신 설계 단순성 → AluVM
RGB의 목표는 클라이언트 검증 자산 프로토콜을 구현하는 것뿐만 아니라 Turing-complete 가상 머신 실행 및 계약 프로그래밍으로 확장하는 것입니다. RGB 초기 설계에서는 Simplicity라는 프로그래밍 언어를 사용한다고 주장했는데, 이 언어의 특징은 표현식 실행 시 실행 증명을 생성해 자신이 작성한 계약을 형식화하기 쉽게 할 수 있다는 점이다. 버그 방지). 그러나 언어의 발전은 이상적이지 않았고 결국 난관에 부딪혔다. 이는 궁극적으로 그해 전체 RGB 프로토콜의 어려움으로 직접 이어졌습니다. 마지막으로 RGB는 원래 Simplicity와 유사하게 정의되지 않은 동작을 방지하는 것을 목표로 Maxim이 개발한 AluVM이라는 VM을 사용하기 시작했습니다. 새로운 AluVM은 현재 사용되는 Rust를 대체하기 위해 앞으로 Contractum이라는 프로그래밍 언어를 사용할 것이라고 합니다.
RGB 레이어 2 확장 방향: 라이트닝 네트워크인가, 사이드 체인인가?
보안을 보장하면서 클라이언트 측 검증 자산을 오프체인에서 지속적으로 거래할 수 있는 방법은 없습니다. 클라이언트가 검증한 자산은 트랜잭션 게시 및 순서 지정을 위해 여전히 L1에 의존하기 때문에 L2 확장 계획이 없는 경우 트랜잭션 속도는 여전히 L1 증인의 블록 생성 속도에 의해 제한됩니다. 이는 엄격한 보안 요구 사항에 따라 RGB 거래가 비트코인에서 직접 수행되는 경우 두 관련 거래 사이의 시간이 최대 10분(BTC의 블록 시간) 떨어져야 함을 의미합니다. 이러한 거래 속도가 대부분의 경우 용납될 수 없다는 것은 의심의 여지가 없습니다.
RGB 및 라이트닝 네트워크
간단히 말해서, 라이트닝 네트워크의 원칙은 거래의 두 당사자가 오프체인에서 여러 계약(커밋 거래)에 서명하여 어느 한쪽이 계약을 위반할 경우 불쾌한 당사자가 계약을 변경할 수 있도록 보장하는 것입니다(커밋 거래). )을 BTC에 제출하여 정산, 자신의 자금을 인출하고 상대방을 처벌합니다. 즉, 라이트닝 네트워크는 프로토콜과 게임 설계를 통해 오프체인 거래의 보안을 보장합니다.
RGB는 RGB에 적용되는 결제채널 계약 내용을 자체적으로 설계하여 자체적인 라이트닝 네트워크 시설을 구축할 수 있으나 라이트닝 네트워크의 복잡성이 매우 높아 이 시설을 구축하는 것이 쉽지 않습니다. 그러나 Lightnling 연구소는 수년 동안 이 분야에 종사해 왔으며 LND는 90% 이상의 시장 점유율을 차지하고 있습니다.
RGB 사이드체인 프라임
LNP-BP현재 RGB 프로토콜의 관리자로서 Maxim은 2023년 6월 **이라는 제안을 발표했습니다.Prime**의 고객은 자산 확장 계획을 확인하고, 기존 사이드 체인 및 라이트닝 네트워크 확장 계획이 개발 측면에서 너무 복잡하다고 비판합니다.Maxim그는 Prime 외에 다른 확장 방법으로는 NUCLEUS 다중 노드 라이트닝 채널과 Ark/Enigma 채널 팩토리가 있으며 둘 다 2년 이상의 개발이 필요하다고 믿습니다. 하지만 Prime은 완료하는 데 1년밖에 걸리지 않습니다.
Prime은 전통적인 의미의 블록체인 디자인이 아니라 클라이언트 검증을 위해 설계된 모듈식 증명 게시 레이어로, 다음 네 부분으로 구성됩니다.
타임스탬프 서비스:거래 순서는 10초 안에 완료될 수 있습니다.
입증하다:PMT 형태로 저장하여 블록헤더와 함께 제작, 출시됩니다.
일회용 씰:추상적인 일회성 봉인 프로토콜은 이중 지출을 방지하는 데 충분합니다. 비트코인에서 구현되면 현재 RGB 디자인과 유사하게 UTXO에 바인딩될 수 있습니다.
스마트 계약 계약:샤딩 계약-RGB(교체 가능)
실제로 RGB 거래 확인 시간 문제를 해결하기 위해 Prime은 타임스탬프 서비스를 사용하여 오프체인 거래를 신속하게 확인하고 거래 및 ID를 블록에 로드한다는 것을 알 수 있습니다. 동시에 프라임의 거래 증명은 PMT를 통해 추가로 병합된 다음 체크포인트와 같은 방식으로 BTC에 고정될 수 있습니다.
Taproot 기반 CSV 자산 프로토콜: Taproot Assets
Taproot Assets는 비트코인 블록체인에서 클라이언트 검증 자산을 발행하는 데 사용되는 Taproot 기반의 CSV 자산 프로토콜입니다. 이러한 자산은 라이트닝 네트워크를 통해 대량, 낮은 수수료로 즉시 거래될 수 있습니다. Taproot Assets의 핵심은 라이트닝 네트워크의 속도, 확장성 및 저렴한 수수료로 비트코인 네트워크의 보안 및 안정성을 활용합니다. 이 프로토콜은 Lightnling 연구소의 CTO인 Roasbeef가 설계하고 개발했으며, Roasbeef는 비트코인 클라이언트(BTCD)와 라이트닝 네트워크 클라이언트(LND)의 개발을 직접 주도하고 BTC에 대한 깊은 이해를 갖고 있는 오데일리의 유일한 비트코인 개발자일 것입니다. .
탭루트 트랜잭션은 자산 스크립트의 루트 해시만 전달하므로 해시 자체가 보편적이고 임의의 데이터를 나타낼 수 있기 때문에 외부 관찰자가 탭루트 자산이 관련되어 있는지 식별하기 어렵습니다. Taproot 업그레이드를 통해 비트코인은 스마트 계약(TapScript) 기능을 얻었습니다. 이를 바탕으로 Taproot Assets의 자산 코딩은 ERC 20 또는 ERC 721과 유사한 토큰 정의를 생성하는 것과 동일합니다. 이러한 방식으로 비트코인은 자산 정의 기능뿐만 아니라 스마트 계약 작성 기능도 갖추고 있어 비트코인을 위한 토큰 스마트 계약 인프라의 프로토타입을 마련했습니다.
Taproot Assets의 인코딩 구조는 다음과 같습니다.
Lightning Labs CTO Roasbeef의 이미지
또한 CSV 자산 프로토콜인 Taproot Assets는 RGB보다 단순한 디자인을 가지고 있습니다. 그리고 Taproot 업그레이드, PSBT 등 BTC 생태계의 현재 진행 상황을 최대한 활용합니다. 애플리케이션 확장성 측면에서 Taproot Assets와 RGB의 가장 큰 차이점은 실행 VM입니다. Taproot Assets는 BTC의 기본 기본값과 동일한 TaprootScriptVM을 사용합니다. 최근에는 TapScript를 기반으로 BTC에 대한 많은 인프라 연구가 진행되고 있으나, BTC의 업그레이드 속도가 느리기 때문에 단기간 내에 적용할 수는 없으며, Taproot Assets가 이에 대한 테스트 필드가 될 것으로 예상됩니다. 미래에는 신선한 아이디어.
Taproot 자산과 RGB의 차이점은 무엇입니까?
1. 거래 검증 및 라이트 노드 친화성
Taproot Assets는 Sum Tree 구현으로 검증 효율성과 보안성이 높습니다(모든 거래 내역을 순회하고 입력할 필요 없이 보유 증명만으로 상태 검증 및 거래 수행이 가능함). RGB에서 사용하는 Pedersen Commitment로 인해 입력의 유효성을 효과적으로 검증할 수 없으므로 RGB에서 입력 거래 내역을 추적해야 하며 파생 거래는 이후 단계에서 매우 큰 부담이 됩니다. Merkel sum의 설계를 통해 Taproot Assets는 BTC 기반의 이전 자산 프로토콜에서는 사용할 수 없는 라이트 노드 검증을 쉽게 구현할 수 있습니다.
2. VM 실행
Taproot Assets는 Taproot 업그레이드에 대응하여 탄생했으며, 그것이 사용하는 TaprootScriptVM은 Taproot 업그레이드 후 비트코인과 함께 제공되는 스크립트 실행 엔진이며, 사용된 vPSBT는 BTC의 PSBT의 복제본입니다. Taproot Assets 메커니즘이 완성되면 현재의 모든 LND 인프라는 물론 이전 Lightning Labs 제품(현재 LND가 Lightning Network의 90% 이상을 차지함)을 즉시 재사용할 수 있습니다. 최근 인기 있는 BitVM 제안은 모두 TaprootScript를 기반으로 하며 이론적으로 이러한 모든 개선 사항은 결국 Taproot 자산에 도움이 될 수 있습니다.
그러나 RGB의 경우 VM 및 검증 규칙(SCHEMA)이 독립적이며 어느 정도 상대적으로 폐쇄적인 소규모 생태계입니다. RGB 기반 구성은 자체 생태계 내에서만 작동할 수 있으며 비트코인 생태계와의 관계는 모든 사람이 상상하는 것만큼 가깝지 않습니다. Taproot 업그레이드의 후속 작업을 예로 들면, RGB와 Taproot 업그레이드 사이의 유일한 관계는 온체인 커밋 데이터를 Witness의 TapLeaf로 인코딩하는 것입니다.
3. 스마트 계약
현재 RGB 구현 설계에서는 계약과 VM이 크게 강조되는 부분이다. 그러나 Taproot Assets에는 아직 스마트 계약이 없습니다. 그러나 현재 Global State의 RGB 수정이 어떻게 각 독립 계약 샤드(UTXO)와 동기화되는지는 설명되지 않았습니다. 게다가 Pedersen은 총 자산 수만 보장할 수 있다고 약속하며, 다른 주에서는 변조를 식별하는 방법에 대한 설명이 더 이상 없는 것 같습니다. Taproot Assets의 경우 디자인은 간단하지만 현재는 자산 잔고만 상태 저장용으로 저장되어 있고 더 이상 상태가 없으므로 당분간 스마트 계약에 대해 이야기할 수 없습니다. 그러나 Lightning Labs에 따르면 Taproot Assets는 내년에 스마트 계약 설계에 중점을 둘 것입니다.
4. 동기화 센터
앞서 언급한 클라이언트 측에서 검증된 자산의 기본 원칙을 통해 개인 키를 보유하는 것만큼 Proof를 보유하는 것도 중요하다는 점을 알 수 있지만, Proof가 항상 사용자 클라이언트에 있다면 쉽게 분실될 수 있으므로 어떻게 해야 할까요? ?모직물? Taproot Assets에서는 유니버스를 통해 이러한 문제를 피할 수 있습니다. 유니버스는 하나 이상의 자산을 포함하는 공개 감사 가능(MS-SMT)입니다. 일반 Taproot 자산 트리와 달리 유니버스는 Taproot 자산을 호스팅하는 데 사용되지 않습니다. 대신 유니버스는 하나 이상의 자산 기록의 하위 집합을 커밋합니다.
RGB의 이 부분을 담당하는 사람은 Storm이며, 이는 p2p를 통해 오프체인 증명 데이터를 동기화하고 저장하지만, RGB 개발팀의 역사적 이유로 인해 현재 이들 팀의 증명 형식은 호환되지 않습니다. RGB 생태 팀 DIBA는 현재 개발할 것이라고 밝혔습니다.carbonado이 문제를 해결하기 위해 노력하고 있지만 진행 상황은 아직 명확하지 않습니다.
5. 프로젝트 시행
Taproot Assets에서 사용하는 모든 라이브러리는 시간 테스트를 거쳤습니다. 왜냐하면 Lightning 연구소에는 자체 비트코인 클라이언트(BTCD), 라이트닝 네트워크 클라이언트(LND) 및 다수의 지갑 라이브러리 구현이 있기 때문입니다. 반면, RGB 구현에 사용되는 대부분의 libs는 자체 정의되어 있으며, 산업 표준 관점에서 볼 때 RGB 구현은 아직 실험실 단계에 있습니다.
BTC 확장의 미래에 대한 간략한 토론
토론의 이 시점에서 모든 사람들은 클라이언트 검증 자산 프로토콜이 프로토콜 범위에서 벗어나 컴퓨팅 확장으로 이동하기 시작했다는 것을 발견했습니다.
많은 사람들은 비트코인이 미래에 디지털 금으로 존재할 것이라고 말하고, 다른 체인은 응용 생태계를 만들 것이라고 말합니다. 그러나 나는 이에 대해 다른 견해를 가지고 있습니다. BTC 포럼과 마찬가지로 다양한 알트코인과 그 짧은 수명에 대한 많은 토론이 있습니다. 이러한 알트코인의 급속한 소멸은 한때 이를 둘러싼 자본과 노력을 거품으로 만들었습니다. 우리는 이미 비트코인과 같은 강력한 합의 기반을 갖추고 있으므로 애플리케이션 프로토콜을 위한 새로운 L1을 구축할 필요가 없습니다. 우리가 해야 할 일은 가장 강력한 인프라인 비트코인을 어떻게 잘 활용하여 장기적으로 탈중앙화된 세상을 구축하는 것입니다.
온체인 계산 감소, 온체인 검증 증가
애플리케이션 설계 관점에서 비트코인은 오랫동안 온체인 컴퓨팅을 핵심 목표로 삼지 않고 검증에 기반을 둔 설계 철학을 선택해 왔습니다.Turing completeness and state for smart contract). 블록체인의 본질은 복제된 상태 기계인데, 체인의 합의가 체인에서 계산된다면 네트워크의 모든 노드가 이러한 계산을 반복하도록 하는 것이 합리적이고 확장 가능한 접근 방식이라고 말하기는 어렵습니다. 검증이 주요 초점이라면 오프체인 거래의 유효성을 검증하는 것이 BTC 확장에 가장 적합한 솔루션일 수 있습니다.
확인은 어디서 이루어지나요? 그것은 중요하다
비트코인을 기반으로 하는 프로토콜 개발자의 경우 키 검증을 위해 비트코인을 사용하는 방법, 심지어 검증을 오프체인에 두는 방법, 보안 솔루션을 설계하는 방법은 실제로 프로토콜 설계자의 몫이므로 그렇게 할 필요가 없습니다. 체인 자체와 관련이 없어야 합니다. 따라서 검증을 달성하는 방법은 BTC에 대한 다양한 확장 계획으로 이어질 것입니다.
따라서 검증 구현의 관점을 기반으로 우리는 세 가지 확장 방향을 가지고 있습니다.
1. 검증은 온체인(OP-ZKP)에서 이루어집니다.
OP-ZKP를 TaprootScriptVM에서 직접 구현하는 것은 BTC 자체에 ZKP 검증 기능을 추가하는 것과 같으며, 일부 Covenant 설계 합의 프로토콜을 사용하면 BTC의 보안을 상속할 수 있는 Zk-Rollup 확장 솔루션을 만들 수 있습니다. 하지만 이더리움에 검증 계약을 배포하는 것과 달리 BTC 자체의 업그레이드는 느리고, 보편적이지 않고 후속 업그레이드가 필요할 수 있는 op-code를 추가하는 것은 어려울 수밖에 없습니다.
2. 검증은 하프체인(BitVM)에서 이루어집니다.
BitVM의 설계는 일반적인 거래 논리를 제공하지 않을 운명이며, Robin Linus는 또한 BitVM의 미래는 다양한 사이드체인을 위한 무료 크로스체인 시장 역할을 하는 것이라고 밝혔습니다. BitVM의 솔루션이 하프체인에서 발생하는 이유는 대부분의 경우 이러한 검증 계산이 체인에서 발생하지 않고 오프체인에서 발생하기 때문입니다. 그러나 BTC의 Taproot를 중심으로 설계하는 중요한 이유는 필요할 때 계산 검증을 위해 TapScriptVM을 사용할 수 있기 위함이며, 이는 이론적으로 BTC의 보안을 상속받기 위함이기도 합니다. 이 과정에서 검증 신뢰 체인도 생성되는데, 예를 들어 n명의 검증자 중 하나가 정직하다면, 즉 Optimistic Rollups가 생성됩니다.
BitVM의 온체인 오버헤드는 엄청나지만 ZK 사기 방지를 사용하여 효율성을 높일 수 있습니까? 대답은 아니요입니다. 왜냐하면 ZK 사기 증명의 구현은 ZKP가 체인에서 검증될 수 있다는 사실을 기반으로 하기 때문입니다. 이는 OP-ZKP 체계의 딜레마로 돌아갑니다.
3. 검증은 오프체인(클라이언트측 검증, 라이트닝 네트워크)에서 이루어집니다.
검증은 완전히 오프체인, 즉 이전에 설명한 CSV 자산 프로토콜과 라이트닝 네트워크에서 이루어집니다. 앞선 논의에서 볼 수 있듯이, CSV 설계에서는 담합 변조 발생을 완전히 방지할 수는 없지만, 우리가 할 수 있는 것은 암호화 및 프로토콜 설계를 활용하여 이러한 악의적인 공모 피해의 범위를 통제 가능한 범위 내로 유지하는 것입니다. 이 행동을 수익성이 없게 만듭니다.
오프체인 검증의 장점과 단점도 매우 분명하며, 장점은 체인에서 리소스를 거의 차지하지 않고 확장 가능성이 크다는 것입니다. 단점은 BTC의 보안을 완전히 재사용하는 것이 거의 불가능하다는 점이며, 이는 수행할 수 있는 오프체인 거래의 유형과 방법을 크게 제한합니다. 그리고 오프체인 검증은 데이터가 오프체인에 있고 사용자가 직접 보관한다는 것을 의미하므로 소프트웨어 실행 환경의 보안과 소프트웨어의 안정성에 대한 요구 사항이 더 높습니다.
확장과 진화의 추세
패러다임 관점에서 볼 때, 현재 이더리움에서 널리 사용되는 Layer 2는 Layer 1을 사용하여 Layer 2의 계산 유효성을 확인합니다. 즉, 상태 계산은 Layer 2로 푸시되지만 확인은 여전히 Layer 1에 유지됩니다. 앞으로는 검증 계산을 오프체인으로 푸시하여 현재 블록체인 인프라의 성능을 추가로 출시할 수도 있습니다.
References
Assia, Y. (n.d.). Colored Bitcoin. Retrieved from https://yoniassia.com/coloredbitcoin/
CryptoAdventure. (n.d.). A Brief History of Colored Coins: What Made Them Special. Retrieved from https://cryptoadventure.com/a-brief-history-of-colored-coins-what-made-them-special/
Bitcoil. (n.d.). BitcoinX.pdf. Retrieved from https://bitcoil.co.il/BitcoinX.pdf
Mastering Bitcoin. (n.d.). Chapter 9. Retrieved from https://www.8btc.com/books/261/master_bitcoin/_book/9/9.html
Livera, S. (n.d.). Episode 501. Retrieved from https://stephanlivera.com/episode/501/
Gradually Then Suddenly. (n.d.). Pay Me in Bitcoin Theory. Retrieved from https://graduallythensuddenly.xyz/pay-me-in-bitcoin-theory/
Coinmonks. (n.d.). ZK-Rollups on Bitcoin. Retrieved from https://medium.com/coinmonks/zk-rollups-on-bitcoin-ce35869b940d
Burtey, N. (n.d.). Twitter Post. Retrieved from https://twitter.com/nicolasburtey/status/1703705962664669225
Burtey, N. (n.d.). Twitter Post. Retrieved from https://x.com/nicolasburtey/status/1703710347889127585?s=20
Bosworth, A. (n.d.). Twitter Post. Retrieved from https://twitter.com/alexbosworth/status/1703423563288473769
BitcoinShooter. (n.d.). Video Title (in English if available). Retrieved from https://www.youtube.com/watch?v=9fz34ef5GSk&ab_channel=BitcoinShooter
Bitcoin Magazine. (n.d.). RGB: Magic Client Contracts on Bitcoin. Retrieved from https://bitcoinmagazine.com/technical/rgb-magic-client-contracts-on-bitcoin
Bitcrab.eth. (n.d.). Article Title (in English if available). Retrieved from https://mirror.xyz/bitcrab.eth/T3gIfKepjfs3YUiRWTgCTqS6gc8LaC5z7lYKQY-HLEE
Todd, P. ( 2016). OpenTimestamps Announcement. Retrieved from https://petertodd.org/2016/opentimestamps-announcement
Bitcoin Optech. (n.d.). Client-Side Validation. Retrieved from https://bitcoinops.org/en/topics/client-side-validation/
Todd, P. ( 2016). Commitments and Single-Use Seals. Retrieved from https://petertodd.org/2016/commitments-and-single-use-seals
Todd, P. ( 2014). Setting the Record: Proof of Publication. Retrieved from https://petertodd.org/2014/setting-the-record-proof-of-publication
Bitcoin Magazine. (n.d.). The Long Road to SegWit: How Bitcoin's Biggest Protocol Upgrade Became Reality. Retrieved from https://bitcoinmagazine.com/technical/the-long-road-to-segwit-how-bitcoins-biggest-protocol-upgrade-became-reality
Linux Foundation. ( 2015). Mailing List Post Title (if applicable). Retrieved from https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-December/011865.html
Zucco, G. (n.d.). Chapter 2: About Eidoo. Retrieved from https://medium.com/@giacomozucco83/chapter-2-about-eidoo-ab0f9d3bdb59
Trust Machines. (n.d.). What is the RGB Protocol on Bitcoin?. Retrieved from https://trustmachines.co/learn/what-is-the-rgb-protocol-on-bitcoin/
Linux Foundation. ( 2023). Mailing List Post Title (if applicable). Retrieved from https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2023-May/021719.html
Salvatoshi. (n.d.). Twitter Profile. Retrieved from https://twitter.com/salvatoshi
Merkle. (n.d.). Website or Article Title (if applicable). Retrieved from https://merkle.fun/
Muneeb. (n.d.). Twitter Post. Retrieved from https://twitter.com/muneeb/status/1712853971948229042
Nakamoto Institute. (n.d.). Appcoins are Snake Oil. Retrieved from https://nakamotoinstitute.org/mempool/appcoins-are-snake-oil/
Todd, P. ( 2013). Disentangling Crypto Coin Mining. Retrieved from https://petertodd.org/2013/disentangling-crypto-coin-mining
