출처: bytewon CKB
비트코인 순수주의자들은 이렇게 생각할 수 있습니다: 그냥 조용히 디지털 금이 되면 좋지 않나요? 왜 토큰이 있어야 하나요? 왜 USDT여야만 하는가? 하지만 자산 보안에 특히 관심이 많으신 분이라면 이더리움이 다운되면 어떻게 될까, 탈중앙 금융은 누가 이를 잡을 수 있을까를 고민해 보셔야 합니다. 또한 토큰 솔루션은 비트코인 프로토콜과 호환되며 원래 기능을 방해하지 않으므로 마음에 들지 않으면 토큰 클라이언트를 다운로드하지 않으면 큰 영향을 받지 않습니다.
비트코인에서 토큰을 발행하는 이유는 무엇인가요?
비트코인에서 토큰을 발행하여 실제 자산 거래를 체인으로 전송하는 데 사용한다는 아이디어는 2010년경 비트코인 커뮤니티에서 등장했습니다. 커뮤니티의 초기 논의에서는 부동산, 주식, 법정화폐, 기타 자산 등 실물 자산을 비트코인으로 옮겨 탈중앙화된 거래를 하는 것을 구상했습니다. 하지만 법적인 요인으로 인해 부동산이나 주식과 같은 자산을 옮기는 것은 그리 쉬운 일이 아닙니다. 집의 디지털 자산 토큰을 다른 사람에게 지급하더라도 정부가 이를 인정하지 않거나 실물 부동산 증서를 자동으로 대체할 수 있으며, 각종 세금을 납부해야 할 수도 있습니다. 게다가 규제에 따라 체인에서 거래할 수 없습니다.
따라서 더 매력적인 접근 방식은 스테이블코인으로 알려진 법정화폐에 연동된 토큰을 발행하는 것입니다. 스테이블코인은 NFT와 달리 여전히 대체 가능한 토큰이지만, 기존 비트코인과는 차별화됩니다. 토큰으로 등장할 때 그 가치는 토큰이 나타내는 실물 자산의 가격에 따라 결정되며, 더 이상 원래 디지털 화폐의 가격이 없습니다(디지털 화폐의 가격이 자산 가격에 비해 너무 높게 상승하면 자산을 버리는 것이 나쁘지 않습니다). 이것이 보통 비트코인의 토큰이 사토시(Satoshi)로 표시되는 이유입니다.
디지털 화폐를 자산으로 사용하는 토큰에는 두 가지 주요 문제가 있습니다.
비트코인에서 실제 자산을 표현하는 방법
비트코인의 매우 제한된 스크립팅 언어에서 복잡한 거래 규칙과 계약을 설정하는 방법.
이 두 가지 사항을 염두에 두고 다음 콘텐츠에서는 현재 사용 가능한 주요 비트코인 자산 발행 솔루션에 대한 개요를 제공하고 데이터 가용성, 자산 사업자, 표현력, 확장성 등의 측면에서 비교합니다.
비트코인 최초의 토큰: 컬러 코인
비트코인에서 토큰 프로토콜을 처음 고안한 사람은 알려져 있지 않으며, 비트코인 포럼이나 커뮤니티에서의 토론에서 아이디어가 나왔을 수 있습니다. 컬러 코인 프로젝트는 2012년 요니 아시아가 비탈릭 부테린, 리오르 하킴, 메니 로젠펠드, 로템 레프와 함께 컬러 코인 백서[1]를 작성하면서 시작되었으며, 2013년에 출시되었습니다. 프로젝트는 2013년에 시작되었습니다.
컬러 코인은 사토시를 특별한 코인으로 표시하고 해당 사토시에 자산에 대한 정보를 기록하는 방식으로 작동하며, 이를 컬러링이라고 합니다. 사토시를 다른 색상으로 염색하고 다른 태그를 붙일 수 있지만, 같은 색상의 코인은 여전히 서로 구별할 수 없습니다(예: 달러로 염색한 사토시 여러 개는 여전히 동질적입니다). 이전 프로토콜은 태그를 추가하기 위해 첫 번째 입력 UTXO nSequence의 트랜잭션에서 nSequence 필드를 사용했습니다. 그러나 nSequence의 저장 한도는 4바이트에 불과했기 때문에 이후 토큰 설계는 기본적으로 더 많은 데이터를 저장할 수 있는 OP_RETURN 필드로 전환했습니다.
컬러코인은 비트코인 최초의 토큰 프로젝트였기 때문에 여전히 회자되고 있습니다. 하지만 프로젝트 자체는 제대로 진행되지 않았고 대중적으로 채택되지 못하면서 점차 잊혀져갔습니다. 당시 스테인코인이 직면했던 문제는 비트코인의 기능이 아직 이 다소 미래지향적인 아이디어를 지원할 수 없었고, 아이디어를 시작하고 효율적이고 일관되게 실행하는 것이 어려웠다는 점입니다. 그래서 비탈릭은 스타인코인 프로젝트 이후 비트코인의 반대편에 서서 스마트 콘트랙트에 집착하게 된 것일지도 모릅니다.
스테인코인은 사토시 형태로 존재하기 때문에 검증은 전체 체인을 다운로드해야 하는 UTXO의 검증과 동일합니다. 이 문제는 나중에 클라이언트 측 검증을 통해 해결될 것입니다.
OP_RETURN: 상대방 및 옴니 레이어로 토큰 보내기
다이드 코인과는 달리, 상대방[2] 및 Omni Layer[3](USDT의 기반 프로토콜)는 사토시를 직접 염색하지 않고 대신 트랜잭션에 0의 값으로 UTXO를 설정하고 UTXO의 OP_RETURN에 메타데이터를 저장합니다. OP_RETURN은 최대 80바이트까지 저장할 수 있으며 OP_RETURN 태그가 붙은 UTXO는 사용할 수 없으므로 실제 토큰은 OP_RETURN에 기록되는 i의 값입니다. 실제 토큰은 일반적으로 시스템에서 전송할 수 있는 최저값인 0.00000546 BTC인 OP_RETURN에 기록된 i번째 출력이며, 토큰의 가치가 BTC에 묶여 있지 않으므로 0.00000546 BTC 이상을 전송할 필요가 없습니다.
이 프로젝트에 대한 검증은 메타데이터가 저장되는 온체인에서 필요합니다.
옴니 레이어는 오랫동안 이더리움 체인에서 활동하다가 최근에야 비트코인 생태계로 돌아와 BTC-USDT 출시를 준비했습니다. 거래 상대방이 비트코인의 일부를 담보로 맡기고 자체 토큰인 XCP를 보유하고 있습니다[4]. 최근 NFT를 하고 있는 것 같습니다.
OP_RETURN에 대한 자세한 내용은 다음을 참조하십시오:
비트코인 OP RETURN 메타데이터 분석[5]
USDT 전송을 위한 OP_RETURN 수동 구성[6]
사이드체인으로 비트코인 앵커링: 루트스탁 및 Liquid 네트워크
루트스탁[7] 및 Liquid 네트워크[8]는 2017년경에 등장한 사이드체인 솔루션으로, 양방향 페그를 사용하여 비트코인을 사이드체인으로 교환하고 EVM 호환 사이드체인에서 다양한 디파이와 디앱을 사용할 수 있습니다. 토큰(RSK는 RBTC, Liquid는 L-BTC)을 보유하고 있으며, 주로 BTC로 이더리움 생태계를 구축하고자 하는 사람들을 대상으로 합니다.
루트스탁에서 토큰을 발행하는 것은 이더에서 토큰을 발행하는 것과 동일하며, 비트코인 체인으로 이뤄지는 채굴을 제외한 나머지 기능, 즉 스마트 컨트랙트 코드와 같은 나머지는 솔리디티로 작성된 이더 생태계에 맞춰진 사이드체인이라고 할 수 있습니다. 스마트 콘트랙트 코드도 솔리디티로 작성됩니다. 따라서 여기의 토큰은 RBTC 위에서 발행되며 BTC와 직접 연결되지 않습니다.
이 글은 주로 퍼블릭 체인에 초점을 맞추고 있으며, 리퀴드 네트워크는 얼라이언스 체인이므로 여기서는 자세히 다루지 않겠습니다.
RSK에 대한 자세한 내용은 다음을 참조하세요:
앞서 언급한 프로젝트 중 일부는 사라졌고(예: 다이 코인), 일부는 비트코인으로 가장하여 이더 생태계를 팔아치우기도 했습니다. 이는 주로 이더가 비트코인의 생태계를 수용하고 있기 때문입니다. 이더가 자본을 수용한 이후에는 디파이와 디앱이 시장을 지배하기 때문에 이를 활용하지 않는 디파이 프로젝트가 우위를 점하기가 더 어려워지기 때문입니다. 이더리움의 토큰은 ERC-20과 같은 표준을 따르는 계약을 통해 발행되고 거래됩니다. 비트코인 생태계는 지난 2년 동안 토큰 표준 BRC-20이 등장한 BitVM과 같이 컨트랙트 기능을 개방하기 시작했습니다.
비트코인에서 스마트 컨트랙트 구현: RGB
2016년에 탄생한 RGB(Really Good for Bitcoin)[13]는 처음에 염료 코인으로 설계되었습니다. 경쟁자로 설계되었습니다. 하지만 비슷한 도전에 직면하면서 비트코인에서 스마트 콘트랙트를 활성화하는 방향으로 방향을 전환했습니다. 헤어스타일링 토큰보다는 스마트 컨트랙트 실행에 초점을 맞추고 있지만, 가상 머신인 알루브이엠의 한계로 인해 2024년부터는 전체 컨트랙트 기능이 제한될 예정입니다.
RGB의 생각은 오프체인으로 가져갈 수 있는 데이터와 스마트 콘트랙트 코드를 비트코인 외부에서 처리하고, 머클 루트는 거래 검증과 토큰 발행의 약속(커밋)을 제공하고 비트코인 체인은 거래 약속의 검증과 최종성만 수행하여 이중 지출이 없음을 증명하는 것입니다. 이중 지출이 없습니다.
RGB는 클라이언트 측 검증과 일회성 실러 기술을 모두 사용하여 토큰을 나타내는 UTXO를 표시하지 않는 것으로 유명합니다. 이 두 가지 개념은 2013년 피터 토드가 처음 소개했고[14], 지아코모 주코와 맥심 오를로브스키가 이를 기반으로 RGB 프로토콜을 설계했습니다.
클라이언트 측 검증을 사용하면 트랜잭션에 사용된 데이터와 코드를 오프체인에 보관하고 공개적으로 게시하지 않으며, 일부 데이터는 트랜잭션에 관여하지 않은 다른 당사자가 모르게 트랜잭션의 두 당사자 사이에서만 비공개적으로 교환할 수 있습니다. 오프체인 상태는 비트코인의 도움으로 유지되며, 블록체인은 상태의 순서를 증명하는 타임스탬프로 기능합니다.
그리고 클라이언트 측 인증의 가장 일반적인 형태인 일회용 도장은 일회용 인감의 디지털 버전입니다. 씰입니다. 각 UTXO는 한 번만 사용할 수 있다는 점을 활용하여 체인 아래로 내려가는 상태에 대한 정보를 하나의 UTXO에 기록합니다. 따라서 어느 시점에 UTXO가 소비되면 상태가 업데이트되었음을 알 수 있으며, 업데이트된 상태 정보는 새로 생성된 UTXO에 기록됩니다. 이 오프체인 상태 정보는 USDT 토큰의 소유권 또는 컨트랙트에 있는 토큰의 수일 수 있습니다.
예를 들어 앨리스가 밥에게 USDT를 전송하려고 할 때, 이 USDT는 비트코인 체인에 존재하지 않고 오프체인에서 정보가 유지되지만 앨리스가 관리하는 UTXO에 연결됩니다. 해당 정보는 UTXO를 생성한 트랜잭션의 OP_RETURN 필드에 0 값으로 저장됩니다. 따라서 앨리스만 USDT를 사용할 수 있으며, 밥은 해당 USDT가 어떤 UTXO에 보관되어 있는지, 유효한지, 거래가 합법적인지 거래 체인을 통해 추적할 수 있습니다. 이렇게 하면 앨리스가 트랜잭션을 시작하여 해당 USDT의 커미션 정보를 밥이 관리하는 UTXO로 전송하면 밥은 자신이 해당 정보를 받았는지 확인할 수 있습니다.
RGB는 오프체인 상태이므로 라이트닝 네트워크에서도 작동할 수 있으며, 커미션을 체인에 올려놓기만 하면 됩니다. 또는 라이트닝 네트워크에서 작동할 수 있습니다. 탭루트 업그레이드 후 RGB는 탭루트 트랜잭션에 프로미스를 삽입할 수 있으며, 이를 통해 보다 유연한 방식으로 비트코인 체인에 프로미스를 삽입할 수 있습니다.
RGB에 대한 자세한 정보는 RGB 청사진[15]을 참조하세요.
스마트 컨트랙트가 아닌 토큰: 탭루트 자산
스마트 컨트랙트가 아닌 토큰: 탭루트 자산
Taproot Asset은 라이트닝 네트워크 데몬(LND)[16]의 팀에서 개발한 프로젝트입니다. 원칙적으로는 RGB와 유사하지만 복잡한 스마트 컨트랙트는 지원하지 않고 토큰만 지원합니다(여기 탭루트 항목[17]의 설명을 참조하세요).
클라이언트 사이드 검증, RGB, 탭루트에 대한 자세한 내용은 다음을 참조하세요:
클라이언트 측 검증 [18]
오프체인 트랜잭션. 비트코인 자산 프로토콜의 진화[19]
상대방 대 RGB 대 TARO[20]
모든 사토시를 다르게 만들기: 오디널 및 비문
케이시 로다모어는 2023년 초에 오디널 프로토콜[21]을 출시했습니다. 이 프로젝트는 원래 사토시에 번호를 매겨 각 사토시에 고유 일련번호를 부여하고 이를 통해 분류하는 아이디어에서 시작되었습니다. 이 아이디어는 스타인코인과 같은 시기에 나온 것으로, 작년에야 다시 소개되었습니다. 세그윗과 탭루트 기능의 추가 덕분에 구현이 그리 어렵지 않으며, 오디날은 모든 사토시를 서로 다르게 만들어 비트코인 체인에서 직접 NFT를 발행할 수 있게 해줍니다.
인스크립션[22]도 이러한 NFT 프로젝트 중 하나입니다. NFT 데이터는 이전 프로젝트에서 사용하는 OP_RETURN 필드 대신 트랜잭션의 증인 데이터에 저장되며, 최대 4MB 크기의 메타데이터를 허용합니다. 이더리움의 NFT와 달리 인스크립션은 메타데이터와 이미지를 포함해 온체인에 저장됩니다.
오디날에 대한 자세한 내용은 다음을 참조하세요:
오디널: 이더리움과 비트코인 맥시멀리스트의 공통점?[23]
더 얼티밋 비트코인 오디날 및 비문 가이드[24]
양방향 바인딩: RGB++ 동형 바인딩
RGB++ 동형 바인딩이 무엇인가요? 왼쪽;">RGB++[25]는 원래 BTC와 CKB(Nervos 네트워크[26]의 기반) 간의 동형 바인딩 프로토콜로 등장했지만, 현재는 CKB와 BTC뿐만 아니라 이론적으로 두 UTXO 체인 사이에도 적용될 수 있는 광범위한 적용 범위를 가지고 있습니다. 이론적으로 이 프로토콜을 사용하여 두 UTXO 체인을 함께 묶을 수 있는 한, CKB와 BTC에 국한되지 않습니다.
RGB++는 RGB의 클라이언트 측 검증과 일회용 씰 아이디어를 한 단계 더 발전시켰습니다. 앞서 언급했듯이 RGB 프로토콜의 가장 큰 문제점은 데이터가 사용자가 로컬에 저장한다는 점입니다. 사용자가 실수로 데이터를 잃어버리면 백업도 없고 데이터를 되찾을 방법도 없습니다. 또한 사용자는 자신의 토큰과 관련된 데이터만 저장하기 때문에 다른 데이터를 확인하기가 더 어렵습니다. 동형 바인딩 레이어의 해결책은 토큰을 비트코인 UTXO의 OP_RETURN 필드에 바인딩하는 것뿐만 아니라 해당 비트코인 거래 정보를 CKB 체인의 거래에 바인딩하는 것입니다(CKB 셀의 잠금 스크립트 [27]에서 특수 IB-lock-script를 사용하여 달성됨). CKB 체인의 거래가 합법적인지 여부를 판단할 때, 잠금 스크립트는 CKB의 BTC 라이트 클라이언트의 데이터를 사용하여 해당 UTXO가 소비되었는지, 소비된 후 새로 생성된 UTXO가 현재 토큰 거래의 정보(서명이 포함되지 않은 정보의 일부)에 바인딩되어 있는지 확인합니다.
RGB++ 관심 기능 :
데이터 가용성 문제는 양방향 바인딩을 통해 해결됩니다: CKB 셀 커밋은 UTXO의 OP_RETURN 필드에 바인딩되고, UTXO 정보는 CKB 트랜잭션의 출력 셀에 바인딩됩니다.
라이트닝 네트워크 및 Fiber. 네트워크(CKB 기반 라이트닝 네트워크)
다중 자산 지원
모든 UTXO 체인에 연결 가능
다중 자산 지원
RGB++에 대한 자세한 내용은 다음을 참조하세요:
RGB++는 모든 UTXO 체인에 바인딩 가능
모든 UTXO 체인에 바인딩 가능RGB++ 프로토콜 라이트 페이퍼[28]
RGB, RGB++ 및 클라이언트 측에 대한 궁극적인 가이드 검증[29]
각 프로젝트의 강점과 한계를 보다 명확하게 파악하기 위해 위의 항목을 아래 표에 정리하여 비교했습니다. 중점적으로 살펴볼 메트릭은 다음과 같습니다.
데이터 가용성 아이소모픽 체인은 사이드체인과 비슷하지만, 체인 아래의 데이터 가용성은 다른 방식보다 약합니다. 강도의 순서는 온체인 ≥ 동형 체인 ≥ 사이드 체인 & gt; 오프 체인;
자산 운반자: BTC와 직접 연결된 토큰 체계가 그렇지 않은 토큰 체계보다 성능이 우수합니다.
BTC와 직접 연결된 토큰 체계가 그렇지 않은 토큰 체계보다 성능이 우수합니다.
대체성: 이는 프로젝트의 기본 토큰이 상호 교환 가능한지 여부를 의미하며, 프로젝트가 추가 프로토콜을 추가하여 달성할 수 있는 NFT 발행을 지원하지 않는다는 것을 의미하지 않습니다.
표현성: 복잡한 스마트 컨트랙트를 처리할 수 있는 능력.
이 문서에 언급된 일부 링크:[1]https://docs.google.com/document/d/1AnkP_ cVZTCMLIzw4DvsW6M8Q2JC0lIzrTLuoWu2z1BE/edit?pli=1&tab=t.0#heading=h.pr8n14cpqri5
[2] https. //www.counterparty.io/
[3] https://www.omnilayer.org/
[4] https://x.com/ 상대방xcp;
[5] https://arxiv.org/pdf/1702.01024
[6] https://juejin.cn/post/6844903769327534088
[7] https://rootstock.io/
[8] https://liquid.net/
[9] https://www.wbtc.network/
[10] https://liquid.net/ left;">[10] https://eprint.iacr.org/2022/684.pdf
[11] https://wiki.moneyonchain.com/getting- started/what-do-i-need-to-know-first
[12] https://dev.rootstock.io/resources/faqs/
[13] https://rgb.tech/
[14] https://petertodd.org/2013/disentangling-crypto- 코인 채굴
[15] https://rgb-org.github.io/
[16] https:// docs.lightning.engineering/
[17] https://bitcoinops.org/en/topics/client-side-validation/
[18] https://bitcoinops.org/en/topics/client-side-validation/
[ 19] https://mirror.xyz/0x5CCF44ACd0D19a97ad5aF0da492AC0388469DfE9/h7XChxETK-cBfGdc0sTq_cCuWeo13-sp1j-g0ZYoYdc
[20] https://mandelduck.medium.com/counterparty-vs-rgb-vs-taro-8cd707d544f7
[ 21] https://docs.ordinals.com/
[22] https://ordinals.com/inscriptions
[23] https://blog.kraken.com/crypto-education/ordinals-a-common-ground-for-ethereum-and-bitcoin-maximalists
< p style="text-align: 왼쪽;">[24] https://www.nervos.org/knowledge-base/guide_to_inscriptions [25] https://www.rgbppfans.com/
[26] https://www.nervos.org/
[27 https://docs.nervos.org/docs/tech-explanation/cell
[28] https://github.com/utxostack/ RGBPlusPlus-design/blob/main/docs/light-paper-en.md
[29 ] https://www.nervos.org/knowledge-base/ ULTIMATE_GUIDE_TO_RGB_RGBPP_및_클라이언트_사이드_검증
Hui Xin
Brian
Joy