저자: Shew & Faust, geekweb3

< img src="https://img.jinse.cn/7180012_image3.png">

요약(더 길게):-

-RGB 프로토콜은 "기생 자산"이 비트코인 UTXO와 연관된 DyeCoin 및 Mastercoin의 아이디어와 부분적으로 유사한 아이디어를 활용합니다. ". 이는 오디널스 프로토콜처럼 전체 DA 데이터를 게시하는 대신 오프체인 거래 데이터의 커미트먼트 "약속"을 받아 비트코인 체인에 저장합니다. RGB 클라이언트는 비트코인 체인에 기록된 커미트먼트 값을 기반으로 다른 클라이언트가 제공한 과거 RGB 데이터가 유효한지 확인할 수 있습니다.

- 동시에 해시/커밋먼트만으로는 해시/커밋먼트 뒤에 있는 원본 이미지를 복원할 수 없으며, 외부 세계는 체인상의 커밋먼트 값에 해당하는 오프체인 데이터를 직접 관찰할 수 없어 프라이버시를 보호하고 인스크립션과 비교하여 커밋먼트만 넣는 방식입니다. 이는 프라이버시를 보호할 수 있으며, 인스크립션과 비교했을 때 체인에 커미트먼트만 넣으면 공간을 절약할 수 있습니다. 제3자 입장에서는 RGB 클라이언트가 실제로 무엇을 했는지 알 수 없습니다.

RGB는 또한 "일회성 실링"이라는 아이디어를 통해 RGB 자산의 소유권을 비트코인 UTXO와 연결함으로써 비트코인의 UTXO 일회성 지출 기능을 활용합니다. 이는 비트코인의 강력한 보안을 활용하여 RGB 자산이 "이중 지출/이중 지불"되는 것을 방지합니다(비트코인 UTXO가 이중 지출되지 않는 한, RGB 자산도 이중 지출되지 않습니다).

-하지만 비트코인 체인에서 구현된 스마트 계약 시스템인 RGB는 여러 클라이언트에 의존해 기록 데이터를 로컬에 저장하며, 여러 클라이언트(사용자)는 자신과 관련된 데이터만 저장하고 다른 사람의 자산은 볼 수 없습니다. 다른 사람의 자산을 볼 수 없습니다. 이러한 '데이터 사일로'는 프라이버시를 보호하지만, 장외 거래자들의 P2P 네트워크처럼 작동하기 때문에 대량 채택에 문제가 될 수 있습니다.

-RGB++의 아이디어는 RGB 자산의 소유 관계를 CKB 체인 상의 셀로 표현하는 것입니다. 원래 RGB 클라이언트에 로컬로 저장된 자산 데이터를 CKB 체인으로 이동하여 셀의 형태로 표현하고, 비트코인 UTXO와 매핑 관계를 설정하여 CKB가 RGB 자산의 공개 데이터베이스 및 오프체인 사전 결제 레이어로 작동하여 RGB 클라이언트를 대체하여 보다 안정적인 데이터 호스팅 및 RGB 계약 상호 작용을 달성할 수 있도록 합니다. 이러한 "아이소모픽 바인딩"은 다른 UTXO 기반 레이어2의 트렌드입니다.

-RGB 프로토콜 자체 RGB 프로토콜 자체는 대화형 전송 프로세스만 지원하며, 거래의 두 당사자는 자주 통신해야 하며, 이 모델은 Defi 시나리오를 지원하기 어렵고 RGB 자산 발행에 도움이 되지 않으며, CKB는 독립형 클라이언트를 대체하여 비대화형 RGB 거래를 실현할 수 있어 Defi 랜딩 및 에어드랍의 기능에 도움이 되며 CKB의 체인에있는 자산과 교차 체인 상호 작용이 필요없이 BTC 자산을 지원할 수 있습니다.

-RGB++는 기본적으로 프라이버시를 사용 편의성과 교환하는 동시에 RGB 프로토콜이 달성할 수 없는 시나리오를 도입합니다. 제품의 단순성과 기능을 중시하는 사용자라면 RGB++를 선호할 것이고, 프라이버시를 추구하고 보안을 직접 확인하려는 사용자라면 기존 RGB 프로토콜을 선호할 것이며, 이는 모두 사용자 자신의 트레이드오프에 달려 있습니다. (이론적으로 RGB++는 ZK 및 기타 방법을 통해 프라이버시 문제를 해결할 수도 있습니다)

RGB 프로토콜의 원리 및 장단점

RGB 프로토콜과 장점 및 단점

RGB 프로토콜 자체는 다소 복잡한 체계이므로 특정 RGB 자산 전송을 예로 들어 RGB 프로토콜의 작동 방식을 설명해 보겠습니다.

RGB 프로토콜의 요구 사항을 충족하는 TEST라는 토큰이 있다고 가정해 보겠습니다. 앨리스는 밥이 자신에게 100개의 TEST 토큰을 전송하기를 원하며, 즉 밥- Alice. 전송을 생성하려고 합니다.

RGB 프로토콜은 "일회성 캡슐화"라는 개념을 사용하여 밥이 앨리스에게 돈을 이체하지만 실제로는 밥이 비트코인 체인에서 UTXO A를 제어한다고 설명합니다. 실제로 밥은 비트코인 체인에서 UTXO A를 제어하며, UTXO A는 어떤 식으로든 일부 RGB 자산과 연관되어 있습니다.

밥이 UTXO A가 연관된 RGB 자산 중 일부를 앨리스에게 전송하고 싶다고 선언하면, UTXO A와 연관된 30개의 TEST 토큰을 가져와서 UTXO B로 전송하여 이를 연결할 수 있습니다. 앨리스는 UTXO B의 소유자이므로 연결된 30개의 TEST 토큰을 소유하게 됩니다.

(이미지 출처: Discoco Labs)

사실 비트코인 체인에 소유권이 기록되는 방식은 UTXO를 통해 이루어지며, UTXO B가 xx량의 RGB 자산을 제어할 수 있다고 말하는 것은 UTXO B의 소유자가 xx량의 RGB 자산을 제어할 수 있다고 말하는 것과 동일합니다! 이는 우리가 익숙한 계정 주소 모델과 일치하지 않으며, 비트코인과 같은 UTXO 퍼블릭 체인의 고유한 속성입니다.

이제 RGB 프로토콜의 워크플로우를 살펴보고 스타인코인, 마스터코인 등 비트코인 UTXO 기생 자산과 어떻게 다른지 이해해 보겠습니다.

1. RGB 프로토콜의 원칙에 따라 앨리스는 먼저 송금 거래에 대한 인보이스(청구서)를 발행하여 의사를 표시해야 합니다. 인보이스에는 다음 정보가 포함됩니다.

계약 id: 앨리스가 어떤 RGB 에셋 컨트랙트와 상호작용할지 선언합니다

계약 id: 앨리스가 어느 RGB 에셋 컨트랙트와 상호작용할지 선언합니다

계약 id: 앨리스가 어느 RGB 에셋 컨트랙트와 상호작용할지 선언합니다

컨트랙트 아이디. ">interface: 컨트랙트가 상호작용하는 모든 인터페이스를 밥에게 알려줍니다

operation: 앨리스가 밥에게 호출하라고 지시한 컨트랙트의 인터페이스 이름입니다

State: Bob이 수정해야 하는 컨트랙트의 상태, 이 경우 Bob이 앨리스에게 전송한 토큰 수

Seal (씰): 일회성 씰에 사용된 UTXO로, 간단히 말해 Alice가 Bob의 RGB 자산의 승인을 수락하기 위해 사용한 UTXO로 이해할 수 있습니다.

마지막으로 Alice는 다음 내용이 포함된 인보이스를 받습니다.

위 인보이스의 형식은 다음과 같습니다. >

2. /strong>앨리스가 위의 송장을 밥에게 보내면 밥은 송장 정보를 확인하고 앨리스의 의도대로 RGB 자산을 앨리스에게 전송하기 위해 새로운 RGB 트랜잭션을 생성합니다.

하지만 여기서 특히 주의해야 할 점은, 밥은 다음과 같이 노력해야 한다는 것입니다. 테스트 자산의 일부 소유권을 가지고 있다는 것을 증명해야 합니다. 이것이 필요한 이유는 RGB 프로토콜은 기본적으로 "자산의 상태를 전 세계적으로 볼 수 있는 기록이 없음"으로 설정되어 있으며, 이더리움의 경우처럼 모든 사람의 자산을 기록하고 처리하기 위해 공개 에스크로 계약을 사용하지 않기 때문입니다.

RGB 프로토콜에서는 각 클라이언트가 현재 잔액, 과거 출처 등 자신과 관련된 자산 데이터만 기록하며, 이는 클라이언트마다 대부분 일치하지 않습니다. 따라서 각 개인이 다른 사람의 자산 상태를 확인할 수 없으므로 P2P 거래에서 자산 증빙을 제시하는 것이 중요합니다.

생생한 비유를 들자면, 여러분과 상대방이 지폐로 거래를 하는데 상대방의 지폐가 자신이 직접 인쇄한 위조지폐인지 모르기 때문에 이 지폐가 어디서 구한 것인지, 몇 명이 손을 거쳐갔는지 명확하게 말해달라고 요청하면 상대방이 위조지폐로 속이고 있는 것인지 판단할 수 있다고 생각하시면 됩니다.

양측이 서로를 인정합니다. 대담하게 거래할 수 있으며, 각 RGB 거래는 관련 당사자만 인정하면 되므로 완전히 P2P(장외거래와 유사)입니다.

분명히 이 모델은 모든 사람의 자산 상태, 거래 기록을 외부 세계, 귀하 및 거래 상대방이 쉽게 알 수 없기 때문에 개인 정보를 보호할 수 있으며, 외부인이 무엇을 해야 할지 알기가 매우 어렵습니다. 지폐가 은행 송금보다 더 잘 익명화될 수 있다는 논리가 성립하는 셈입니다. 하지만 이는 사용자 경험에 불편함을 초래할 수도 있습니다.

앞서 설명한 앨리스와 밥의 사례에서 밥은 앨리스의 송장을 받고 그 의도를 파악한 후 로컬 고객의 과거 데이터에서 테스트 자산과 관련된 이체 내역을 선택해 새로 생성된 밥 -  앨리스 이체와 함께 앨리스에게 넘겨야 합니다. Alice는 새로 생성된 Bob -> Alice 전송과 함께 해당 자산 소유권 소스 뒤에 있는 새로운 RGB 거래/소유권 변경이 유효하고 오류가 없는지 확인하기 위해 Alice에게 전송합니다.

일반적으로 클라이언트 에 로컬로 저장된 데이터를 Stash "컬렉션"이라고 하며 RGB 에셋의 과거 데이터를 포함합니다. Stash는 RGB 에셋 컨트랙트의 로그 기록이라고 생각할 수 있습니다.

3.Alice는 Bob으로부터 데이터를 수신하고 새로 선언된 Bob- & gt; Alice 트랜잭션을 수신하면 유효성을 검증하고, 통과하면 "확인 서명"(Confirmation Signature)을 생성합니다. "

4. 밥은 앨리스의 확인 서명을 받고 밥 - 앨리스 트랜잭션에 해당하는 커밋을 파일에 넣습니다. 앨리스의 커미트먼트는 트랜잭션을 BTC 네트워크에 브로드캐스트하고, 이는 결국 BTC 체인에 기록되어 최종 트랜잭션이 됩니다.

("커미트먼트"). 커밋의 구조 다이어그램, 실제로는 머클 루트에 해당)

밥- 앨리스 전송이 UTXO B의 소유자에게 30개의 TEST 토큰을 가지고 있다고 선언하면, 앨리스는 자신이 UTXO B의 소유자임을 증명하는 한 해당 TEST 토큰을 사용할 수 있습니다.

5. 향후 앨리스가 다른 사람에게 TEST 토큰을 양도하고자 할 경우, 상대방은 이러한 TEST의 과거 출처를 제시할 때 비트코인 체인 상의 커밋 약속의 가치와 비교하여 앨리스가 제공하는 데이터가 체인에서 제공하는 데이터와 일치하는지를 검증할 수 있습니다. 앨리스가 제공한 데이터가 체인의 커미션 값과 일치할 수 있는지 여부를 확인합니다. 이를 통해 위조된 데이터를 방지할 수 있습니다.

RGB 프로토콜의 장점은 복잡한 스마트 컨트랙트 계산을 오프체인에서 지원할 수 있다는 것입니다. 기본적으로 계산 단계를 BTC 체인에서 벗어나 체인에만 커밋을 기록하고, 비트코인 UTXO와 RGB 자산 소유권 간의 연결을 오프체인에서 선언하는 동시에 프라이버시를 보호하고, 비트코인의 도움으로 RGB 자산의 소유권을 소각하고 변경할 수 있게 해줍니다.

모든 거래 신고는 관련 당사자가 검증하고 승인해야 하기 때문에 보안 모델은 관련 당사자가 합리적이라면 RGB 자산은 안전하다는 합리적 인간 가정에 기반합니다. 비트코인이 안전한 한 RGB 자산의 소유권은 "본질적으로 안전"합니다.

그러나 RGB 프로토콜의 결함도 분명합니다(앞서 사일로와 파편화된 스토리지 문제를 언급했습니다). 첫째, 다른 사람에게 송금하거나 상대방의 동의와 확인을 먼저 받으려면 기본적으로 두 당사자가 동시에 온라인 상태여야 하고

둘째, 데이터를 전 세계적으로 볼 수 있는 로그 방식이 부족하기 때문입니다. RGB의 계약서는 심지어 이상한 형식으로 발행되어, 계약서 사용자는 이메일이나 QR 코드를 스캔하여 퍼블리셔가 계약서에 포함된 인터페이스 기능을 미리 알려주기도 합니다. (현재 공식적인 라인은 웹사이트 첫 페이지나 트위터 피드 상단에 계약 코드를 넣어도 괜찮다는 것입니다.)

RGB 프로토콜의 컨트랙트 상태를 조금 더 살펴봅시다. RGB 프로토콜에서 컨트랙트의 초기 상태(제네시스)는 컨트랙트 생성 시 생성자에 의해 설정되며, RBG-20 컨트랙트의 토큰 이름, 총 토큰 수량 등이 설정됩니다. 이후 RGB 트랜잭션의 지속적인 진행에 따라 컨트랙트의 상태가 변화하는데, 이러한 컨트랙트 상태 진화는 비선형적이어서 방향성 비순환 그래프 DAG를 구성합니다.

(그림에서 소유자1의 시야는 파란색과 녹색 부분이고 소유자2의 시야는 파란색과 노란색 부분입니다)

예를 들어 밥이 앨리스에게 돈을 이체할 때, 컨트랙트 초기화부터 밥이 토큰을 받을 때까지의 이체 기록 중 상대적으로 데이터 경로가 좁은 부분만 표시됩니다. 앨리스는 이 경로의 일부에 포함된 거래 정보만 알 수 있으며, 다른 사람의 송금 정보는 알기 어렵습니다. 이는 RGB 사용자의 프라이버시를 보호하는 반면, 사용자가 RGB 컨트랙트의 글로벌 상태, 예를 들어 각 사람이 얼마나 많은 RGB 자산을 가지고 있는지 알기 어렵다는 단점도 있습니다. 이로 인해 많은 문제가 발생할 수 있습니다.

토큰을 받은 앨리스는 거래와 관련된 모든 데이터를 로컬에서 추적해야 합니다. (밥이 로컬 TEST 토큰 데이터를 삭제하고 사고로 인해 앨리스의 클라이언트 노드가 완전히 손상된 경우, 이 시점에서 앨리스의 자산은 영구적으로 동결되나요? 미리 백업하지 않았다면 앨리스의 TEST 자산 데이터를 저장할 다른 장소가 없기 때문입니다.)

이 문제는 본질적으로 DA와 데이터 스토리지 문제로 요약할 수 있습니다. 즉, 신뢰할 수 있고 전 세계적으로 가시적인 방식으로 전파할 수 없는 데이터를 RGB 프로토콜에 추가하여 궁극적으로 여러 클라이언트를 다음과 같이 만드는 것입니다. "데이터 사일로"가 됩니다. 한때 이더넷 생태계에서 각광받았으나 이후 사용되지 않게 된 플라즈마 솔루션 역시 DA 문제를 해결하지 못해 결국 사장되었습니다.

또한, RGB 프로토콜은 거래의 양측 간에 많은 통신이 필요하며, 많은 통신 단계가 중앙 집중식 시설에 의존하는데, 세부 사항이 미숙하고 심지어 관계자들은 이메일을 통해 통신할 수 있다고 말하기도 합니다.

RGB 프로토콜이 사용 편의성을 추구하는 롱테일 사용자에게 그다지 친화적으로 설계되지 않았다는 것은 비교적 분명하며, 자산이 많고 프라이버시를 더 많이 추구하는 대규모 사용자는 데이터 백업과 클라이언트 측 유지 관리를 기꺼이 수행하겠지만, 이러한 부담은 여전히 롱테일 사용자에게는 너무 과중한 부담입니다. 사용자에게는 이러한 부담이 여전히 너무 커서 대량 도입에 심각한 장벽이 될 수 있습니다. 현재까지도 경이로운 RGB 에셋은 등장하지 않았다는 의견이 지배적입니다.

아래 그림은 RGB 자산 전송의 흐름도로, 이를 통해 독자들이 전반적인 송금 프로세스에 대해 더 깊이 이해할 수 있도록 돕습니다.

요약하면, RGB 프로토콜은 비트코인 UTXO를 통해 RGB 자산의 소유권을 변경할 수 있으며, 비트코인 체인에 커밋값(Commitment)을 게시함으로써 오프체인 데이터를 클라이언트가 사적으로 조작할 수 없도록 보장합니다. 사실 RGB의 소위 "원타임 실링"은 비트코인의 강력한 보안을 통해 RGB 자산의 안전성을 보장하기 위해 체인 내 RGB 거래 신고를 통해 비트코인 UTXO와 RGB 자산의 소유권을 연계하는 것입니다. 그러나 DA 및 데이터 저장 문제로 인해 기존 RGB 프로토콜의 가용성과 UX가 상대적으로 떨어지고 데이터 손실로 인해 자산이 쉽게 동결(사용 불가)되는 문제가 있습니다.

RGB++: CKB 기반의 향상된 RGB 프로토콜

위 섹션에서 우리는 위와 같이 클라이언트 측 데이터 사일로와 컨트랙트 상태에 대한 글로벌 가시성을 확보할 수 없다는 점이 RGB 프로토콜의 사용 편의성에 영향을 미치는 가장 중요한 요인으로 작용하는 RBG 시스템의 장단점을 요약했습니다.

사실 RGB 프로토콜의 강점과 약점은 매우 분명하며, 높은 수준의 개인정보 보호와 보안을 갖춘 사람들은 자체 클라이언트를 실행하고 데이터를 백업하는 경향이 있지만, 롱테일 사용자는 이에 대한 인내심이 부족할 것입니다(예: 대부분의 라이트닝 네트워크 사용자는 클라이언트를 직접 실행하기보다는 타사 노드에 의존할 것입니다).

이러한 이유로 Nervos는 RGB의 자산 상태, 계약 발행, 거래 검증을 제3자 데이터 역할을 하는 CKB 퍼블릭 체인에 위임하려는 Cipher의 RGB++ 솔루션을 공동 설립했습니다. CKB는 제3자 데이터 호스팅 및 컴퓨팅 플랫폼 역할을 하며, 사용자가 자체 RGB 클라이언트를 실행할 필요가 없습니다.

CKB 자체가 확장된 UTXO 모델(셀)이기 때문에 RGB 자산의 오프체인 정보를 셀에 기록하고 셀과 비트코인 UTXO 간의 1대1 매핑 관계를 설정하여 CKB를 기반으로 RGB 자산의 데이터 호스팅 및 검증 솔루션을 실현할 수 있습니다. 그리고 사용 편의성 문제를 해결하기 위한 방법으로 기존 RGB 체계를 보완하는 향상된 검증 체계를 개발했습니다.

이 단락은 다소 복잡하게 느껴질 수 있으니, 좀 더 자세히 설명해드리겠습니다:

이 글의 앞부분에서 언급한 것처럼, RGB 프로토콜은 기본적으로 온체인 약속과 오프체인 선언을 발행하여 비트코인 UTXO와 RGB 자산 소유권을 연결합니다. 그러나 RGB 자산 콘트랙트의 데이터는 파편화되어 전 세계적으로 볼 수 없이 각기 다른 클라이언트에 로컬로 저장됩니다.

RGB++는 CKB의 확장 버전인 셀을 통해 비트코인 UTXO와 해당 RGB 자산 간의 매핑 관계를 CKB 체인에 직접 표시합니다. 표시되며, CKB 퍼블릭 체인은 사용자의 P2P 클라이언트를 대체하여 각 RGB 전송의 유효성을 확인합니다.

이렇게 전 세계에 표시되는 RGB 데이터 기록을 통해 RGB 프로토콜에서 구현하기 어려운 많은 시나리오를 더 쉽게 구현할 수 있습니다.

(RGB++ 트랜잭션 흐름, RGB 자산 정보를 셀에 기록한 다음 셀을 비트코인 UTXO와 연결하고, 마지막으로 CKB에서 발생하는 RGB++ 트랜잭션과 RGB++ 자산과 연결된 비트코인 UTXO를 약속에 포함시킨 다음 약속 값을 비트코인 체인에 기록)

얼른 EVM을 떠올리는 분들도 계실 텐데요, RGB의 상태와 검증을 EVM으로 처리할 수 있을까요? 정답은 '고통스럽다'입니다. RGB 자산은 본질적으로 비트코인 UTXO에 기생하며 비트코인 UTXO와 1대1 매핑 관계를 갖기 때문입니다. 비트코인 UTXO와 EVM 컨트랙트 데이터 간의 매핑 관계를 설정하려면 기술 구현이 원활하지 않으며, 차라리 UTXO 퍼블릭 체인을 직접 선택하는 편이 낫습니다.

그리고 이더의 '자산'은 피어 투 피어 공공재로, 하나의 컨트랙트에 수많은 사람의 자산 데이터가 기록되고 컨트랙트 컨트롤러가 절대적인 권한을 갖는 경우가 많습니다. <이러한 자산 처리 방식은 각 개인이 자신의 자산을 완전히 통제하고(지폐와 위챗페이의 차이를 생각해보세요), 자산 계약 소유자의 남용, 자산 계약의 버그로 인한 자금 손상, 데이터 손상 등 이더리움과 EVM 체인에 항상 존재했던 문제를 고려할 필요 없이 자산을 완전히 사유화하도록 설계된 비트코인 UTXO 및 RGB 프로토콜과 심각한 충돌을 일으킵니다. 문제는 자산 콘트랙트 소유자가 권한을 남용할 수 있고, 콘트랙트에 버그가 발생하여 자금이 손상될 수 있으며, 자산 콘트랙트의 데이터를 마이그레이션하는 데 어려움을 겪을 수 있다는 것입니다.

(긱웹3의 과거 기사에서: "기술계 유명인사가 말을 흔든다: 고성능 퍼블릭 체인은 새로운 일을 만들기 어렵고, 스마트 컨트랙트는 권력 분배를 포함한다")

따라서 비트코인의 UTXO와 오프체인 RGB 자산을 보다 원활하게 표현하려면 여전히 UTXO 체인을 이용하는 것이 가장 좋습니다. 그리고 CKB는 확장된 UTXO-셀을 지원하며, CKB VM의 명령어 세트는 비트코인의 공개-개인 키 검증 알고리즘을 포함한 다양한 암호화 알고리즘과 호환성이 높은 RISC-V를 기반으로 하므로 RGB++에서 제안하는 기술 솔루션을 구현하는 데 더 도움이 됩니다.

RGB++의 기술적 구현

RGB++는 CKB의 확장된 UTXO를 사용합니다. --셀을 사용합니다. 그리고 셀에는 다음 필드가 포함됩니다.

RGB+는 CKB 확장 UTXO -- Cell을 사용합니다. 왼쪽;">용량은 이 셀이 보유한 온체인 공간의 양을 나타내며, 데이터는 셀에 포함된 읽기 또는 수정 가능한 데이터 집합을 의미합니다.

Type은 이 셀이 바인딩된 프로그램 코드로, 데이터 데이터를 수정할 수 있는 조건을 제한합니다. 예를 들어 셀에 100개의 TEST 토큰에 대한 데이터가 있는데 다른 사람에게 110개의 TEST를 전송한다고 선언하는 경우, 이는 Type에 지정된 제한 조건을 충족하지 않으므로 거부됩니다.

반면, Lock은 비트코인 UTXO의 잠금 해제 스크립트와 유사한 셀의 소유권 유효성 검사 로직을 나타냅니다.

셀은 유형과 용량이라는 두 가지 필드가 추가된 UTXO의 업그레이드 버전으로 이해할 수 있으며, 셀의 소유권 변경과 마찬가지로 데이터 유형은 사용자 정의할 수 있으며, 비트코인 UTXO와 유사한 방식으로 이루어집니다. 잠금 해제 스크립트를 통해 달성할 수 있습니다.

반면 RGB++의 아이디어는 RGB 자산의 소유 관계를 CKB 체인의 셀로 표현하는 것입니다. 원래 RGB 클라이언트에 로컬로 저장되어 있던 에셋 데이터를 CKB 체인으로 이동하여 셀 형태로 표현함으로써 CKB가 RGB 에셋의 공용 데이터베이스 역할을 하도록 합니다. RGB 자산을 나타내는 셀은 비트코인 체인의 UTXO와 1대1 매핑 관계를 가지며, 이 매핑 관계는 셀의 잠금 필드에 직접 표시됩니다.

예를 들어, RGB 자산이 비트코인 UTXO A와 연관되어 있다고 가정하면 해당 매핑된 버전의 셀은 자체 소유권 검증 조건을 비트코인 UTXO A와 일치하도록 설정할 수 있습니다(즉, Lock 스크립트를 비트코인 UTXO A의 잠금 해제 조건으로 설정합니다.) 만약 여러분이 UTXO A의 컨트롤러라면 CKB에 매핑된 셀을 직접 조작할 수 있지만, 물론 CKB는 여러분이 UTXO A의 소유자임을 확인합니다.

CKB 체인은 비트코인 블록 헤더를 동기화하는 비트코인 라이트 노드를 구현할 것입니다. RGB 자산에 해당하는 셀에서 작동하도록 RGB 트랜잭션을 선언할 때, 자신이 비트코인 UTXO A의 컨트롤러임을 증명해야 합니다. 증명 단계는 두 단계입니다.

1. CKB 체인에 구현된 비트코인 라이트 노드에 증명합니다. 머클 증명을 제시해야 하는 비트코인 체인에 UTXO A가 존재함을 증명하는 노드;

2. 자신이 UTXO A의 소유자임을 증명하는 디지털 서명을 제시합니다.

RGB++ 시나리오에서는 프론트엔드에서 RGB 자산 전송을 선언하는 사용자가 CKB 체인에서 트랜잭션을 트리거하여 RGB 자산의 데이터를 기록하는 셀을 다시 작성하여 소유권을 변경합니다. 원래 셀을 소유한 것은 비트코인 UTXO 1의 컨트롤러였을 수 있으며, 소유권이 변경된 후에는 비트코인 UTXO 2의 컨트롤러가 셀의 새로운 소유자가 됩니다. 이는 모두 CKB 체인에서 확인할 수 있습니다.

여기 참고하세요. BTC 체인의 커밋과 관련된 워크플로는 여전히 BTC 메인넷에서 이루어지며, 이는 RGB++가 여전히 비트코인 체인에 커밋을 게시해야 한다는 것을 의미합니다 CKB에서 발생한 RGB 자산의 거래 기록과 연관되어 있습니다. 이 단계는 기존 RGB 프로토콜과 다르지 않습니다.

이를 통해 RGB 클라이언트의 데이터 사일로화 문제를 해결하고 컨트랙트 상태가 전역적으로 표시되지 않는 결함도 해결합니다. 동시에 RGB 컨트랙트를 CKB 체인에 직접 배포하여 RGB 셀이 참조할 수 있도록 전역적으로 표시할 수 있으므로 RGB 프로토콜 컨트랙트가 릴리스될 때 일련의 이상한 작업을 피할 수 있습니다.

요약하자면, CKB>는 셀 스크립팅을 사용하여 RGB 컨트랙트를 CKB 체인에 배포할 수 있는 방법을 제공합니다. strong>CKB는 셀 스크립트의 프로그래밍 가능성을 활용하여 먼저 RGB 전송의 개시자가 RGB 자산과 관련된 비트코인인 UTXO를 실제로 소유하고 있는지 확인하고, 이것이 확인되면 사용자가 전송을 통해 RGB 자산 데이터를 기록하는 셀을 다른 사람에게 전송할 수 있도록 허용합니다.

요약하자면, CKB는 RGB 자산의 퍼블릭 데이터 호스팅 플랫폼으로서 데이터 저장과 전 세계에 공개되는 컨트랙트 게시, 소유권 확인 및 계산을 제공합니다. 좀 더 간결하게 설명하자면, CKB는 RGB에서 클라이언트를 대체하고 그 과정에서 다른 문제를 해결합니다.

물론 RGB++를 사용하면 전 세계에서 볼 수 있는 데이터 게시가 가능하기 때문에 RGB 프로토콜에 비해 프라이버시는 불가피하게 감소하지만 사용 편의성이 크게 향상된다는 이점이 있습니다.

따라서 RGB++는 기본적으로 프라이버시와 사용 편의성을 교환하는 동시에 RGB 프로토콜에서는 불가능한 시나리오를 가능하게 합니다. 사용자가 제품의 단순성과 기능성을 중시한다면 RGB++를 선호할 것이고, 프라이버시와 보안을 중시한다면 기존 RGB 프로토콜을 선호할 것이며, 모든 것은 사용자의 선택에 달려 있습니다(이 아이디어는 Vitalik이 EtherChannel Layer2에 대해 언급할 때 표현한 것과 유사합니다). (보안을 원한다면 롤업을 사용하고, 저렴한 비용을 원한다면 밸리디움이나 옵티뮴과 같은 비롤업 솔루션을 사용해야 한다는 이더리움 레이어2에 대한 비탈릭의 의견과 비슷한 맥락입니다). 물론 RGB++ 백서에 따르면 사용자의 신원과 송금액을 숨기는 프라이버시 거래 체계를 CKB 체인에 구현하는 것도 가능합니다.

RGB++의 추가 기능

거래가 아닌 트랜잭션. 인터랙티브(매우 중요)

원래 RGB 프로토콜의 주요 문제 중 하나는 수취인이 RGB 전송 전에 자신의 UTXO 중 하나가 RGB 자산에 묶여 있음을 나타내는 메시지(앞서 언급한 수표)를 먼저 지불자에게 보내야 한다는 것이었습니다. 를 성공적으로 구현할 수 있습니다. 이러면 수취인과 송금인 사이에 여러 채널의 대화형 커뮤니케이션을 통해 공통의 거래를 완료해야 하므로 사용자의 이해가 어렵고 제품의 복잡성이 증가하게 됩니다. 대신 RGB++는 데이터 호스팅 및 컴퓨팅 플랫폼으로서 CKB의 특성을 활용하여 거래 상대방 간의 이체를 완료하기 위한 비동기식 비대화형 방법을 허용합니다.

A가 B에게 돈을 이체할 때, 수취인이 온라인으로 통신하거나 데이터를 제공할 필요 없이 B의 주소와 해당 주소로 이체할 것이라는 진술만 있으면 됩니다. 이후 수취인은 자산을 직접 수령할 수 있으며, CKB 체인의 스크립트 코드는 수취인이 송금인이 지정한 사람인지 확인합니다. 물론 이 모델은 대부분의 사람들이 익숙한 방식에 더 가깝고, 원래 RGB 프로토콜에서 지원하지 않는 에어드랍이나 보상 분배와 같은 모드도 실행할 수 있어 RGB 자산 분배가 용이합니다.

또한, RGB 프로토콜의 작동 방식은 원래 RGB 프로토콜에서는 개발이 거의 불가능한 대표적인 다대다 비대화형 트랜잭션 풀인 유니스왑과 같은 디파이 시나리오의 개발에는 당연히 불리한 반면, RGB++는 비대화형 트랜잭션을 구현하고 상태의 글로벌 가시성을 확인할 수 있으며, 셀을 빌려서 "조건을 만족하는 모든 사람이 상태를 수정할 수 있다"를 달성하면 원래 RGB 프로토콜의 개발은 불가능하지만 원래 RGB 프로토콜로도 개발이 가능하다는 점이 장점입니다. 조건을 충족하는 사람이라면 누구나 자신의 상태를 수정할 수 있는 '마스터 없는 계약'을 구현하기 위해 셀을 빌려온다면, 우리는 많은 디파이 시나리오를 실현할 수 있습니다.

물론 누구나 상태를 수정할 수 있는 주인 없는 컨트랙트는 여러 사람이 동시에 컨트랙트의 상태를 수정하려는 상태 경합/읽기/쓰기 충돌이 발생하기 쉽고, 이는 혼란을 초래할 수 있습니다. 이 문제를 해결하기 위해 RGB++는 인텐트 셀의 온체인 구현을 "시퀀서"로 사용하여 서로 다른 요청을 정렬할 계획입니다.

트랜잭션 폴딩(여러 트랜잭션에 대한 커밋 게시 집계)

트랜잭션 폴딩은 CKB를 온체인 Intent Cell로 사용하는 것으로 더 쉽게 이해할 수 있습니다. 이 아이디어는 CKB를 "오프체인 사전 결제 레이어"로 사용하여 여러 RGB 전송이 이루어질 때 트랜잭션 배치를 집계하여 트랜잭션 배치에 대한 커밋을 만든 다음 비트코인 체인에 한 번에 게시하는 것입니다.".

구체적으로 다음 순서도로 나타낼 수 있습니다:

BTC 자산은 체인을 거치지 않고 CKB 온체인 자산과 직접 상호 작용

RGB++는 비트코인 UTXO와 CKB 셀 간의 연결 매핑을 구현한 후 체인 전체에서 자산 없이 직접 상호 운용할 수 있습니다. RGB++ 트랜잭션 명세서를 통해 비트코인 UTXO를 다른 사람에게 양도할 수 있으며, 상대방은 CKB 자산의 소유권을 귀하에게 이전할 수 있습니다. 이 모델은 상상력의 여지가 많으며, 앞서 언급한 트랜잭션 폴딩(대량 거래)과 결합하면 이론적으로 BTC 자산 없이도 체인 간 BTC-CKB 온체인 자산 상호 운용성을 가능하게 할 수 있습니다.

요약

RGB++는 다른 RGB 클라이언트에 로컬로 저장된 자산 데이터를 가져와 CKB 체인의 셀에 직접 표현한 다음 비트코인 체인의 UTXO와 연결합니다. 사용자는 자신의 비트코인 계정/자산을 통해 CKB 체인에서 자신의 RGB++ 자산과 상호작용할 수 있습니다. 이 접근 방식은 보다 간결하며, 전송을 위해 두 당사자 간의 사전 커뮤니케이션이 필요하고, 글로벌 가시 상태를 지원하기 어렵고, 파편화된 데이터 저장, 스마트 콘트랙트와 디파이의 비친화성 등 RGB 프로토콜의 문제를 해결합니다.

RGB++는 BTC-CKB 간의 상호운용성을 달성하기 위해 자산을 교차 체인화할 필요가 없으며, RGB 자산과 Defi 시나리오의 결합을 용이하게 하여 RGB 프로토콜의 사용 편의성 문제를 크게 해결합니다. 그러나 높은 수준의 프라이버시를 추구하는 RGB 틈새 플레이어에게 RGB++는 본질적으로 프라이버시와 사용 편의성의 절충안이며, 모든 것은 사용자의 절충안에 달려 있습니다. 그러나 이론적으로 프라이버시 문제는 예를 들어 ZK를 도입하여 CKB 체인에서 해결할 수 있습니다.

전반적으로 RGB++는 비트코인 체인에서 결제/계산 레이어로서 CKB의 가능성을 보여주며, 이러한 사고방식은 앞으로 점점 더 많은 비트코인 레이어2 또는 자산 프로토콜에서 채택될 것입니다. 비트코인 체인의 제3자 결제 레이어 간의 경쟁이 곧 시작될 것으로 예상할 수 있습니다. 그리고 다년간의 기술 축적을 바탕으로 POW와 UTXO에 집중하고 있는 CKB가 이러한 모듈형 블록체인 경쟁에서 기술적 우위를 보여줄 수 있을 것입니다.