RGB에서 RGB++로: 비트코인 레이어2 및 오프체인 결제 계층으로서의 CKB 잠재력 재조명

2024.02.20

RGB에서 RGB++로: 비트코인 레이어2 및 오프체인 결제 계층으로서의 CKB 잠재력 재조명

RGB++의 본질은 프라이버시를 사용 편의성과 교환하여 RGB 프로토콜로는 실현할 수 없는 시나리오를 가능하게 하는 것이다.

2024.02.20 - 01:23:57

RGB

Web3 심층 보도에 집중하고 흐름을 통찰

RGB++의 본질은 프라이버시를 사용 편의성과 교환하여 RGB 프로토콜로는 실현할 수 없는 시나리오를 가능하게 하는 것이다.

글 작성: Shew, Faust, Geek web3

자문: CyberOrange, Unipass

요약(상세): RGB 프로토콜은 BTC 확장성에 잠재력을 지닌 프로토콜로, 본질적으로 오프체인 컴퓨팅 시스템이다. 이는 라이트닝 네트워크와 유사한 개념을 채택하고 있다. 즉 사용자가 자신과 관련된 자산 변동 사항을 직접 검증하고 승인하며("Verify by yourself"), 거래 발신자가 승인한 결과나 커밋먼트를 비트코인 체인에 제출하는 방식이다.

RGB 프로토콜은 컬러드 코인 및 마스터코인(Mastercoin)과 일부 유사한 아이디어를 활용하여, 비트코인 UTXO에 "기생 자산(parasitic assets)"을 연결한다. RGB는 체인 외부의 거래 데이터 커밋먼트(commitment)를 비트코인 체인에 저장하지만, Ordinals 프로토콜처럼 완전한 DA(Data Availability) 데이터를 게시하지는 않는다. 비트코인 체인 상의 기록된 커밋먼트 값을 통해, RGB 클라이언트는 다른 클라이언트가 제공한 RGB 역사 데이터가 유효한지를 검증할 수 있다.
또한 해시/커밋먼트만으로는 원본 이미지(original pre-image)를 복원할 수 없으며, 외부에서는 체인 상의 커밋먼트 값에 해당하는 오프체인 데이터를 직접 관측할 수 없다. 이를 통해 프라이버시를 보호할 수 있으며, 인스크립션(Inscription)과 비교해 커밋먼트만 올리는 것이 공간을 절약한다. 제3자의 관점에서 보면, RGB 클라이언트가 정확히 무엇을 하고 있는지 알 수 없다.

또한 RGB는 비트코인 UTXO의 일회성 소비 특성을 활용하여, '일회용 실링(one-time seal)'이라는 개념을 통해 RGB 자산 소유권을 비트코인 UTXO에 연결한다. 이를 통해 비트코인의 강력한 보안성을 활용하여 RGB 자산의 '이중 지불(double spend)'을 방지할 수 있다. (비트코인 UTXO가 이중 지불되지 않는 한, RGB 자산도 이중 지불되지 않는다.)
그러나 RGB는 비트코인 체인 외부에서 구현된 스마트 계약 시스템으로, 각 클라이언트가 로컬에 역사 데이터를 보관해야 하며, 서로 다른 클라이언트(사용자)는 자신과 관련된 데이터만 저장하고 타인의 자산 상태를 볼 수 없다. 이러한 '데이터 고립'은 프라이버시를 보호하지만, 대규모 채택에 어려움을 초래하며 OTC 거래자들로 구성된 P2P 네트워크에 더 가깝다.
RGB++의 접근법은 CKB 체인의 Cell을 이용해 RGB 자산의 소유권 관계를 표현하는 것이다. 기존에 RGB 클라이언트 로컬에 저장되던 자산 데이터를 CKB 체인 위에서 Cell 형태로 표현하고, 이를 비트코인 UTXO와 1대1 매핑 관계를 설정함으로써 CKB가 RGB 자산의 공개 데이터베이스이자 오프체인 사전 정산 계층 역할을 하게 한다. 이를 통해 RGB 클라이언트를 대체하고, 보다 신뢰성 있는 데이터 호스팅과 RGB 계약 상호작용을 실현한다. 다른 UTXO 기반 레이어2(Layer2) 입장에서도 이러한 '동형 결합(homomorphic binding)'은 하나의 트렌드이다.

RGB 프로토콜 자체는 상호작용적인 전송 프로세스만 지원하므로, 거래 당사자 간 빈번한 통신이 필요하다. 이러한 모델은 DeFi 시나리오를 지원하기 어렵고, RGB 자산 발행에도 불리하다. CKB가 독립 클라이언트를 대체함으로써 비상호작용적인 RGB 거래를 가능하게 하여, DeFi 적용 및 에어드랍 등의 기능을 용이하게 하며, BTC 자산이 크로스체인 없이도 CKB 체인 자산과 상호작용할 수 있도록 한다.
RGB++은 본질적으로 편의성과 기능성에 프라이버시를 바꾸는 것으로, RGB 프로토콜이 달성하지 못했던 새로운 시나리오를 가능하게 한다. 제품의 단순성과 기능 완전성을 중시하는 사용자는 RGB++을 선호할 것이며, 반면 프라이버시와 '직접 검증'의 보안성을 추구하는 사용자는 기존 RGB 프로토콜을 선호할 것이다. 모든 것은 사용자의 선택에 달려 있다. (이론적으로 RGB++ 역시 ZK 등 방법을 통해 프라이버시 문제를 해결할 수 있다.)

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

RGB 프로토콜은 다소 복잡한 방식으로, 구체적인 RGB 자산 이체 사례를 들어 설명하겠다.

RGB 프로토콜 표준을 따르는 TEST라는 토큰이 있다고 가정하자. 앨리스(Alice)는 밥(Bob)에게 100개의 TEST 토큰을 받기를 원한다. 즉, Bob → Alice로의 토큰 이체를 생성하길 원한다.

여기서 먼저, RGB 프로토콜은 '일회용 패키징(one-time sealing)'이라는 개념을 사용한다는 것을 설명하겠다. 겉보기에 밥이 앨리스에게 송금한다고 하지만, 실제로는 밥이 비트코인 체인 상의 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 프로토콜에 따라 앨리스는 먼저 이체 거래를 위해 인보이스(invoice)를 발행하여 자신의 의도를 명시해야 한다. 인보이스에는 다음 정보가 포함된다:

계약 ID: 앨리스가 어떤 RGB 자산 계약과 상호작용할 것인지 선언
인터페이스: 밥이 계약의 모든 상호작용 인터페이스를 이해할 수 있도록 함
작업(operation): 앨리스가 밥에게 호출을 요청하는 계약 인터페이스 이름
상태(state): 밥이 수정해야 할 계약 상태, 여기서는 밥이 앨리스에게 보내는 토큰 수량
Seal(밀봉): 일회용 실링을 위한 UTXO로, 간단히 말해 앨리스가 밥의 RGB 자산 권한을 수령하기 위한 UTXO이다.

최종적으로 앨리스는 다음과 같은 인보이스 내용을 얻게 된다:

위 인보이스는 다음 형식을 따른다:

2. 앨리스는 위 인보이스를 밥에게 전송해야 한다. 밥은 인보이스 정보를 확인하고 앨리스의 의도에 따라 새로운 RGB 거래를 생성하여 RGB 자산을 앨리스에게 양도한다.

하지만 여기서 특히 주의해야 할 점은, 밥은 반드시 자신이 일부 TEST 자산 소유권을 가지고 있다는 것을 입증해야 한다는 것이다. 이렇게 하는 이유는 RGB 프로토콜이 '전역적으로 가시적인 자산 상태 기록'이 없기 때문이다. 이더리움처럼 공개 계약을 통해 모든 사람의 자산을 기록하고 처리하는 방식과 다르다.

RGB 프로토콜 하에서 각각의 클라이언트는 자신과 관련된 자산 데이터만 기록하며, 현재 잔액과 역사적 출처 등을 포함한다. 각 클라이언트가 기록하는 데이터는 기본적으로 일치하지 않는다. 따라서 누구도 다른 사람의 자산 상태를 확인할 수 없으므로, P2P 거래 시 자산 증명을 제시해야 한다.

생생한 비유를 들면, 당신과 상대방이 지폐로 거래를 하지만, 그 지폐가 상대방이 스스로 찍어낸 위조지폐인지 모른다는 것이다. 그래서 당신은 그 지폐가 어디서 왔는지, 얼마나 많은 사람이 거쳐왔는지 분명히 알려달라고 요구하며, 상대방이 위조지폐로 속이는지 여부를 판단하게 된다.

양측이 서로 인정하면 안심하고 자유롭게 거래할 수 있으며, 각 RGB 거래는 참여자들 간의 상호 승인만 있으면 되므로 완전한 P2P 방식이다(OTC와 유사).

분명히 이 방식은 프라이버시를 보호한다. 각자의 자산 상태와 거래 기록이 외부에 쉽게 노출되지 않으며, 당신과 거래 상대가 무엇을 했는지는 외부인이 알기 어렵다. 마치 현금이 은행 이체보다 익명성이 뛰어난 것과 같다. 그러나 이는 사용자 경험상 불편함을 초래하기도 한다.

앞서 언급한 앨리스와 밥의 사례에서, 밥이 앨리스의 인보이스를 받고 그 의도를 이해한 후, 로컬 클라이언트의 역사 데이터에서 TEST 자산과 관련된 과거 이체 기록을 선택하고, 새로 생성된 Bob → Alice 이체 거래와 함께 앨리스에게 제출하여 검증을 받아야 한다. 이를 통해 새로운 RGB 거래/소유권 변경의 자산 소유권 근거가 유효하고 오류가 없음을 증명한다.

일반적으로 클라이언트 로컬에 저장되는 데이터를 Stash('저장물')라 부르며, RGB 자산의 과거 데이터를 포함한다. 우리는 Stash를 RGB 자산 계약의 로그 기록으로 생각할 수 있다.

3. 앨리스가 밥에게서 데이터와 새로운 Bob→Alice 이체 거래를 받으면, 그 유효성을 검증한다. 검증에 성공하면 앨리스는 '확인 서명'을 생성하여 밥에게 돌려보낸다.

4. 밥이 앨리스의 확인 서명을 받으면, Bob → Alice 거래에 해당하는 Commitment(커밋먼트)를 BTC 네트워크에 방송하고, 최종적으로 BTC 체인에 기록하여 '최종성'을 갖도록 한다.

(커밋먼트의 구조도, 사실상 머클 루트임)

Bob → Alice 이체 거래에서 UTXO B의 소유자가 30개의 TEST 토큰을 가지게 된다고 선언한다면, 앨리스는 자신이 UTXO B의 소유자임을 입증하기만 하면 해당 TEST 토큰을 사용할 수 있다.

5. 미래에 앨리스가 TEST 토큰을 다른 사람에게 전송하려 할 때, 그 TEST의 역사적 출처를 제시하면, 상대방은 비트코인 체인 상의 커밋먼트 값을 기반으로 앨리스가 제공한 데이터가 체인 상의 커밋먼트 값과 일치하는지 검증할 수 있다. 이를 통해 데이터 위조를 방지할 수 있다.

RGB 프로토콜의 장점은 체인 외부에서 복잡한 스마트 계약 계산을 지원할 수 있다는 점이다. 본질적으로 계산 단계를 BTC 체인 외부로 이동시키고, 체인 상에는 커밋먼트만 기록함으로써 프라이버시를 보호하면서 동시에 체인 외부에서 비트코인 UTXO와 RGB 자산 소유권 간의 연관성을 선언하고, 비트코인을 통해 RGB 자산 소유권 변경을 각인하고 실현한다.

모든 거래 선언은 당사자가 검증하고 승인해야 하므로, 그 보안 모델은 '합리적 인간 가정(rational actor assumption)'에 기반한다. 당사자가 합리적이며 비트코인이 안전하다면, RGB 자산 소유권도 '기본적으로 안전'하다.

그러나 RGB 프로토콜의 단점도 명백하다(앞서 언급된 데이터 고립 및 조각화 저장 문제). 우선, 다른 사람에게 송금하려면 상대방의 동의와 확인을 먼저 받아야 하며, 양측은 거의 동시에 온라인 상태여야 한다.

둘째, 전역적으로 가시적인 데이터 기록 방식이 부족하여, RGB 계약의 배포조차 매우 특이한 형식을 취한다. 계약 사용자는 계약 게시자로부터 미리 계약에 포함된 인터페이스 기능을 알아야 하며, 구체적인 방법은 이메일이나 QR코드 스캔 등을 통해 가능하다. (공식 발표 내용을 보면, 계약 코드를 홈페이지 메인이나 트위터 상단에 게시하는 것도 가능할 듯하다.)

이제 RGB 프로토콜의 계약 상태에 대해 살펴보자. RGB 프로토콜 내에서 계약의 초기 상태(Genesis)는 생성자가 계약 생성 시 설정하며, 예를 들어 RBG-20 계약의 토큰 이름, 총량 등이다. 이후 계약 상태는 지속적인 RGB 거래 진행에 따라 변화하지만, 이러한 상태 진화는 비선형적이며 방향성 비순환 그래프(DAG)를 구성한다.

(도표에서 owner1의 시야 범위는 파란색과 녹색 부분, Owner2의 시야 범위는 파란색과 노란색 부분)

예를 들어 밥이 앨리스에게 송금할 때, 계약 초기화부터 밥이 토큰을 받은 부분까지의 이체 기록만 제시하며, 포함된 데이터 경로가 좁다. 앨리스도 이 경로 분기 내의 거래 정보만 알 수 있으며, 다른 사람들의 이체 정보를 알기는 어렵다. 이는 RGB 사용자의 프라이버시를 보호하지만, 부정적인 결과도 초래한다: 사용자가 RGB 계약의 전역 상태, 즉 각자가 보유한 RGB 자산 수량 등을 알기 어렵다. 이는 많은 문제를 야기한다.

예를 들어, Bob → Alice 이체 거래가 마지막 단계에 이르러 커밋먼트 값이 BTC 체인에 기록되어 되돌릴 수 없게 된 후, 밥은 로컬에서 일부 데이터를 삭제할 수 있다—만약 밥이 자신의 모든 TEST 토큰을 타인에게 넘겼다면, 로컬에 저장된 TEST 토큰 관련 데이터를 직접 삭제하여 저장 압박을 줄일 수 있다.

반면 수취인인 앨리스는 이번 거래와 관련된 모든 데이터를 로컬에 기록해야 한다. (만약 밥이 로컬의 TEST 토큰 데이터를 삭제했고, 앨리스의 클라이언트 노드가 사고로 완전히 손상되었다면, 앨리스의 자산은 영구적으로 동결되지 않을까? 앨리스의 TEST 자산 데이터를 저장하는 다른 장소가 없기 때문에, 사전에 백업하지 않았다면 그렇다.)

이것은 본질적으로 DA(Data Availability) 및 데이터 저장 문제로 귀결된다. 즉 RGB 프로토콜의 신규 데이터는 신뢰성 있고 전역적으로 가시적인 방식으로 전파되지 않으며, 결국 각 클라이언트는 '데이터 고립'이 된다. 과거 이더리움 생태계에서 번성했지만 이후 폐기된 Plasma 방식도 DA 문제를 해결하지 못해 실패했다.

또한 RGB 프로토콜은 거래 당사자 간 많은 통신을 필요로 하며, 많은 통신 단계가 중심화된 인프라에 의존하는데, 이 부분에 대한 세부 설명은 아직 미흡하며, 공식적으로는 이메일을 통한 통신도 가능하다고 말한다.

비교적 명백한 것은, RGB 프로토콜 설계는 사용 편의성을 추구하는 일반 사용자들에게 친숙하지 않다는 점이다. 많은 자산을 보유하고 프라이버시를 중시하는 대형 사용자들은 데이터 백업과 클라이언트 유지보수를 기꺼이 하지만, 장기적으로는 일반 사용자들에게 이러한 부담이 너무 크며, 대규모 채택에 심각한 장애가 된다. 현재까지도 현상급 RGB 자산은 등장하지 않았다고 대부분 생각한다.

아래 그림은 RGB 자산 이체 프로세스 다이어그램으로, 독자들이 전체 흐름을 더 깊이 이해할 수 있도록 도와준다.

간단히 말해, RGB 프로토콜은 비트코인 UTXO를 활용하여 RGB 자산의 소유권 변경을 실현하고, BTC 체인에 커밋먼트를 게시함으로써 오프체인 데이터가 클라이언트에 의해 임의로 조작되는 것을 방지한다. 실제로 RGB의所谓 '일회용 실링'은 오프체인 RGB 거래 선언을 통해 비트코인 UTXO와 RGB 자산 소유권을 연결함으로써 비트코인의 강력한 보안성을 활용해 RGB 자산 보안을 보장하는 것이다. 그러나 DA 및 데이터 저장 문제로 인해, 원본 RGB 프로토콜의 사용성과 UX는 낮으며, 데이터 손실로 인해 자산이 동결(사용 불가)되기 쉽다.

RGB++: CKB 기반 강화형 RGB 프로토콜

위에서 우리는 RBG 시스템의 장단점을 요약했다. 그 중 클라이언트의 데이터 고립 및 계약 상태의 전역 가시성 부족이 RGB 프로토콜의 사용성에 가장 큰 영향을 미친다.

사실 RGB 프로토콜의 장단점은 모두 명백하다. 프라이버시와 보안을 중시하는 사람들은 클라이언트를 직접 운영하고 데이터 백업을 철저히 하겠지만, 일반 사용자들은 그러한 인내심이 없다(예: 대부분의 라이트닝 네트워크 사용자는 직접 클라이언트를 운영하기보다 제3자 노드에 의존한다).

이러한 이유로 Nervos 공동창업자 Cipher는 RGB의 자산 상태, 계약 배포 및 거래 검증을 CKB 퍼블릭 체인에 위탁하는 RGB++ 방안을 제안했다. CKB는 제3자 데이터 호스팅 및 컴퓨팅 플랫폼 역할을 하며, 사용자가 더 이상 RGB 클라이언트를 직접 운영할 필요가 없다.

CKB는 확장된 UTXO 모델(Cell)을 기반으로 하므로, RGB 자산의 오프체인 정보를 Cell에 기록하고, Cell과 비트코인 UTXO 사이에 1대1 매핑 관계를 설정하여 CKB 기반의 RGB 자산 데이터 호스팅 및 검증 방안을 실현함으로써 사용성 문제를 해결하고, 기존 RGB 방안의 보완 강화책이 된다.

이 설명은 다소 복잡하게 들릴 수 있으니 추가로 설명하겠다:

앞서 언급했듯이, RGB 프로토콜은 본질적으로 체인 상 커밋먼트와 체인 외 선언을 통해 비트코인 UTXO와 RGB 자산 소유권을 연결한다. 그러나 RGB 자산 계약 데이터는 조각화되어 다양한 클라이언트 로컬에 분산 저장되며, 전역적으로 가시적인 뷰가 없다.

RGB++은 CKB의 확장형 UTXO—Cell을 통해 비트코인 UTXO와 대응하는 RGB 자산 간의 매핑 관계를 직접 CKB 체인 상에 표시하고, CKB 퍼블릭 체인이 사용자의 P2P 클라이언트를 대신하여 각 RGB 이체의 유효성을 검증한다.

이러한 전역적으로 가시적인 RGB 데이터 기록이 마련되면, RGB 프로토콜에서는 실현하기 어려웠던 많은 시나리오들이 더 쉽게 구현될 수 있다.

(RGB++의 거래 흐름: RGB 자산 정보를 Cell에 기록한 후, Cell과 비트코인 UTXO를 연결하고, 마지막으로 CKB에서 발생한 RGB++ 거래 및 RGB++ 자산과 연관된 비트코인 UTXO를 모두 커밋먼트에 포함하여 커밋먼트 값을 비트코인 체인에 기록함)

누군가는 즉시 EVM을 떠올릴지도 모른다. EVM으로 RGB 상태와 검증을 수행할 수 있을까? 답은 '매우 번거롭다'는 것이다. RGB 자산은 본질적으로 비트코인 UTXO에 기생하며, 비트코인 UTXO와 1대1 매핑 관계를 가진다. 비트코인 UTXO와 EVM 계약 데이터 사이에 매핑 관계를 설정하려면 기술적으로 매끄럽지 않으며, 차라리 UTXO 퍼블릭 체인을 직접 선택하는 것이 낫다.

또한 이더리움 상의 '자산'은 종종 풀 기반의 공공재이며, 하나의 계약이 무수한 사람들의 자산 데이터를 기록하고, 계약 제어자가 절대적인 권력을 가진다. 이러한 자산 처리 방식은 비트코인 UTXO 및 RGB 프로토콜과 심각하게 충돌한다. 후자의 설계 철학은 자산의 완전한 개인화로, 각자가 자신의 자산을 완전히 통제하는 것이다(위챗페이와 현금의 차이를 생각해보라). 이더리움과 EVM 체인에서 흔히 발생하는 자산 계약 소유자의 권한 남용, 계약 버그로 인한 자금 피해, 자산 계약 데이터 이전의 번거로움 등의 문제를 고려할 필요가 없다.

(Geek web3 과거 기사 발췌: <기술계 유명인 샹마: 고성능 퍼블릭 체인은 새롭게 부상하기 어렵고, 스마트 계약은 권력 배분을 포함>)

따라서 비트코인 UTXO와 오프체인 RGB 자산 간의 매핑 관계를 매끄럽게 표현하려면, 가장 좋은 선택은 UTXO 체인을 통하는 것이다. CKB는 확장형 UTXO—Cell을 지원하며, CKB VM의 명령어 집합은 RISC-V 기반이어서 EVM보다 다양한 암호 알고리즘과 호환하기 쉬우며, 비트코인의 공개/개인키 검증 알고리즘도 포함되어 있어 RGB++ 기술 방안을 실현하는 데 더 유리하다.

RGB++의 기술 구현

RGB++은 CKB의 확장형 UTXO—Cell을 사용한다. 하나의 Cell은 다음 필드를 포함한다:

Capacity는 이 Cell이 보유한 체인 상 공간 크기를 나타내며, data는 Cell 내부에 포함된 데이터셋으로, 읽거나 수정할 수 있다.

Type은 이 Cell에 연결된 프로그램 코드로, data 데이터의 수정 조건을 제한한다. 예를 들어, 당신의 Cell에 100개의 TEST 토큰 데이터가 있는데, 110개를 타인에게 보내겠다고 선언하면 Type에 규정된 제한 조건에 어긋나므로 거부된다.

Lock은 Cell의 소유권 검증 로직을 나타내며, 비트코인 UTXO의 잠금 해제 스크립트와 유사하다.

Cell을 업그레이드된 UTXO로 이해할 수 있으며, Type과 Capacity 두 필드가 추가되고, data는 사용자 정의 데이터 타입을 지원한다. Cell의 소유권 변경 방식은 비트코인 UTXO와 유사하게 잠금 해제 스크립트를 통해 이루어진다.

RGB++의 아이디어는 CKB 체인 상의 Cell을 사용해 RGB 자산의 소유권 관계를 표현하는 것이다. 원래 RGB 클라이언트 로컬에 저장되던 자산 데이터를 CKB 체인 상에서 Cell 형태로 표현하고, CKB가 RGB 자산의 공개 데이터베이스 역할을 하게 한다. 그리고 RGB 자산을 나타내는 Cell은 비트코인 체인 상의 UTXO와 1대1 매핑 관계를 가지며, 이 매핑 관계는 Cell의 Lock 필드에 직접 표시된다.

예를 들어, 어떤 RGB 자산이 비트코인 UTXO A와 연결되어 있다고 가정하자. 그러면 대응하는 매핑 Cell은 자신의 소유권 검증 조건을 비트코인 UTXO A와 일치하도록 설정할 수 있다(즉, Lock 스크립트를 비트코인 UTXO A의 잠금 해제 조건으로 설정). 만약 당신이 UTXO A의 제어자라면, CKB 상의 매핑 Cell을 직접 조작할 수 있으며, 물론 CKB는 당신이 UTXO A의 주인인지 검증한다.

CKB 체인은 비트코인의 라이트 노드를 구현하여 비트코인 블록 헤더를 동기화한다. 당신이 RGB 거래를 선언하여 RGB 자산에 해당하는 Cell을 조작할 때, 먼저 비트코인 UTXO A의 제어자임을 입증해야 한다. 입증 절차는 두 단계로 나뉜다: