RGB++와 동형 바인딩: CKB, 카르다노, 퓨얼이 BTC를 강화하는 방법

위와 같은 문제에 대해 RGB++의 해결책은 사용자가 클라이언트 측 자체 검증 모드와 서드파티 호스팅 모드를 자유롭게 전환할 수 있도록 하는 것입니다. 사용자는 데이터 검증 및 저장, 스마트 컨트랙트 호스팅 등의 부담을 CKB에 맡길 수 있으며, 물론 사용자는 CKB, 즉. POW 퍼블릭 체인이 신뢰할 수 있으며, 많은 자산을 보유하는 등 보안과 프라이버시를 더 중요하게 생각하는 특정 사람들은 원래의 RGB 모델로 돌아갈 수도 있습니다. 여기서 강조하고 싶은 것은 이론적으로 RGB++와 오리지널 RGB 프로토콜은 서로 호환이 가능하다는 점이며, 나 아니면 안 된다는 것이 아니라는 점입니다.

( RGB++ 프로토콜 상호 작용 순서도 [축약 버전])

이전 글 "RGB에서 RGB++로: CKB가 비트코인을 강화하는 방법에서 이전 게시물 "RGB에서 RGB++로: CKB가 비트코인의 에코 자산 프로토콜을 강화하는 방법"에서 RGB++의 "동형 바인딩"에 대해 간략하게 다루었으므로 여기서 다시 한 번 간략하게 살펴보겠습니다.

CKB에는 셀이라는 자체 확장 UTXO가 있으며, BTC 체인에 있는 UTXO보다 훨씬 더 프로그래밍할 수 있습니다. "아이소모픽 바인딩"은 CKB 체인의 셀을 RGB 자산 데이터의 "컨테이너"로 사용하고, RGB 자산의 주요 파라미터를 셀에 기록하는 것입니다.

이미지 src="https://img.jinse.cn/7197083_image3.png">

RGB 자산은 비트코인 UTXO에 바인딩되어 있기 때문에 자산의 논리적 형태에서 UTXO의 특성을 갖습니다. UTXO의 특성을 가진 셀은 자연스럽게 RGB 자산의 '컨테이너'로 적합합니다. RGB 자산 트랜잭션이 발생할 때마다 해당 셀 컨테이너는 엔티티와 그림자 사이의 관계와 같은 유사한 특성을 나타낼 수 있으며, 이것이 바로 "동형 바인딩"의 본질입니다.

예를 들어 앨리스가 비트코인 체인에 100개의 RGB 토큰과 UTXO A를 소유하고 있고, 동시에 CKB 체인에 "RGB 토큰 잔액: 100"이라는 레이블이 붙은 셀이 있으며, 잠금 해제 조건이 다음과 연관되어 있다고 가정해봅시다. UTXO A가 연관되어 있습니다.

예를 들어 앨리스가 밥에게 30개의 토큰을 주고 싶다면, 앨리스는 커밋을 할 수 있는데, 이는 UTXO A와 연결된 RGB 토큰 30개를 밥에게, 70개를 자신이 관리하는 다른 UTXO에게 전송한다는 진술입니다.

그 후 앨리스는 비트코인 체인에서 UTXO A에 돈을 쓰고, 위의 진술을 한 다음 "RGB 토큰 잔액: 100"이라는 라벨이 붙은 CKB 체인에서 트랜잭션을 개시합니다. 그런 다음 CKB 체인에서 100개의 RGB 토큰을 보유한 셀 컨테이너를 소비하는 트랜잭션이 시작되어 30개의 토큰을 보유한 컨테이너(밥용)와 70개의 토큰을 보유한 컨테이너(앨리스의 통제 하에 있는) 두 개의 새로운 컨테이너가 생성됩니다. 이 과정에서 앨리스 자산의 유효성과 거래 내역의 유효성을 검증하는 작업은 밥이 개입할 필요 없이 CKB 네트워크 노드들이 합의를 통해 수행하며, 이때 CKB는 비트코인 체인에서 검증 및 DA 레이어 역할을 합니다.

이는 이더 ERC-20 콘트랙트에서 사용자가 콘트랙트의 상태가 변경될 때마다 클라이언트 측 유효성 검사를 실행할 필요가 없는 것과 유사합니다. 노드 네트워크에서 클라이언트 측 검증을 대체할 수 있습니다. 또한 모든 사람의 RGB 자산 데이터는 글로벌 검증이 가능한 CKB 체인에 저장되므로 유동성 풀이나 자산 담보 계약과 같은 Defi 시나리오를 쉽게 구현할 수 있습니다.

이것은 실제로 중요한 신뢰 가정을 도입합니다. 사용자는 합의 프로토콜에 의존하는 다수의 노드로 구성된 네트워크 플랫폼인 CKB 체인이 신뢰할 수 있고 오류가 없을 것이라고 낙관하는 경향이 있습니다. CKB를 신뢰하지 않는다면 원래 RGB 프로토콜의 대화형 통신 및 검증 프로세스를 따라 직접 클라이언트를 실행할 수도 있습니다.

물론 RGB++ 클라이언트를 직접 실행하여 다른 사람의 에셋 히스토리의 출처를 확인하고자 하는 경우에는 CKB 체인에서 RGB 에셋 컨테이너 셀과 관련된 히스토리를 확인하면 됩니다. CKB 라이트 노드를 실행하고 머클 증명과 CKB 블록 헤더를 수신하기만 하면 네트워크에서 악의적인 공격자가 수신한 히스토리 데이터가 변조되지 않았는지 확인할 수 있습니다. 여기서 CKB는 다시 히스토리 데이터 저장 레이어 역할을 한다고 할 수 있습니다.

단순히 말해, 이소모픽 바인딩은 RGB뿐만 아니라 룬, 아토믹 등과 같은 UTXO 기능을 가진 다양한 자산 프로토콜에도 적용되며, 사용자 클라이언트에 로컬로 저장된 자산 상태와 히스토리 데이터, 그리고 해당 스마트 컨트랙트를 모두 CKB 또는 카르다노 및 기타 UTXO 유형의 퍼블릭 체인에 저장 및 호스팅합니다. 위와 같은 UTXO형 자산 프로토콜은 자산의 형태와 상태를 보여주는 '컨테이너'로서 CKB나 카르다노의 UTXO 모델을 사용할 수 있어 스마트 컨트랙트와 같은 시나리오와 쉽게 매칭할 수 있습니다.

그리고 동형 바인딩 프로토콜에 따라 사용자는 크로스 체인을 사용할 필요 없이 자신의 비트코인 계정으로 직접 CKB와 같은 UTXO 체인에서 RGB 자산 컨테이너를 운영할 수 있으며, 셀의 UTXO 기능을 활용하여 셀 컨테이너의 잠금 해제 조건을 특정 비트코인 주소/비트코인 UTXO와 연결되도록 설정하기만 하면 됩니다. 셀 기능에 대해서는 이전 RGB++ 과학 글인 geekweb3에서 이미 설명했으므로 여기서는 반복하지 않겠습니다.

이미지 src="https://img.jinse.cn/7197085_image3.png">

RGB 자산 거래의 양 당사자가 CKB의 보안을 신뢰하고 비트코인 체인에 커밋을 자주 게시할 필요가 없는 경우, 많은 RGB의 집합을 전송할 수 있습니다. 이를 "트랜잭션 폴딩"이라고 하며, 사용 비용을 절감할 수 있습니다.

그러나 동형 바인딩에 사용되는 "컨테이너"는 종종 UTXO 모델을 지원하는 퍼블릭 체인 또는 상태 저장 측면에서 유사한 특성을 가진 인프라가 필요하며, 이는 기술 구현에 많은 구멍이 있는 EVM 체인에는 분명히 적합하지 않다는 점에 유의하는 것이 중요합니다. 우선, 위에서 언급했듯이 RGB++는 "CKB 체인에서 자산 컨테이너의 크로스 체인 조작이 필요하지 않기 때문에" 기본적으로 EVM 체인에서 구현이 불가능하고, 억지로 구현하더라도 비용이 매우 높을 수 있으며,

또한 RGB++ 프로토콜에서는 클라이언트를 실행하거나 자산 데이터를 CKB 체인에 저장할 필요가 없습니다. 클라이언트를 실행하거나 에셋 데이터를 로컬에 저장할 필요가 없습니다. ERC-20을 사용하여 모든 사람의 자산 잔액을 컨트랙트에 기록하는 경우, 누군가 클라이언트 측 자체 검증으로 돌아가서 다른 사람의 자산 출처를 확인하겠다고 제안하면 자산 컨트랙트와 상호작용하는 모든 거래 기록을 스캔해야 할 수 있으며, 이는 매우 스트레스가 될 수 있습니다.

단적으로 말하자면, ERC-20과 같은 자산 컨트랙트는 모든 사람의 자산 상태를 한데 묶어두기 때문에 그 중 한 사람의 자산 변동 내역을 개별적으로 확인하려면, 마치 공용 채팅방에서 왕강에게 누가 메시지를 보냈는지 확인하려면 채팅방 전체를 뒤져서 메시지 기록을 넘겨야 하는 것처럼 매우 어렵습니다. 공개 채팅방에서 누가 왕강에게 메시지를 보냈는지 알고 싶으면 채팅방 전체를 살펴봐야 하는 것과 마찬가지입니다. 반면 UTXO는 일대일 비공개 채팅 채널과 같아서 대화 내역을 쉽게 확인할 수 있습니다.

요약하자면, 동형 바인딩을 구현하기에 적합한 퍼블릭 체인/기능 확장 레이어는 다음과 같은 특징을 가져야 합니다.

1. UTXO 모델 또는 유사한 상태 저장 체계 사용;

   <><

2. 개발자가 잠금 해제를 스크립팅할 수 있는 실질적인 UTXO 프로그래밍 가능성;

3. 자산 상태를 저장하기 위한 UTXO 관련 상태 공간의 존재;

4. 비트코인 관련 브리지 또는 라이트 노드의 존재;

물론, 저희는 또한 동형 결합에 사용되는 퍼블릭 체인이 강력한 보안성을 갖기를 바라며, 다른 한편으로는 사용자가 서명 알고리즘을 다시 변경할 필요 없이 BTC의 서명 체계로 다른 퍼블릭 체인에서 자신의 동형 결합 UTXO를 직접 잠금 해제할 수 있도록 해당 퍼블릭 체인에서 UTXO를 잠금 해제하는 조건이 프로그래밍이 가능해야 한다는 점도 희망하고 있습니다.

현재 CKB의 UTXO 잠금 스크립트는 프로그래밍이 가능하며, 다른 퍼블릭 체인의 서명 체계와 공식적으로 호환됩니다. 아이소모픽 바인딩의 경우, CKB 네트워크는 기본적으로 위의 기능을 준수하지만 다른 UTXO 기반 퍼블릭 체인은 어떻게 될까요? 저희는 연료와 카르다노를 예비적으로 살펴본 결과, 이론적으로 동형 바인딩을 지원할 수 있다고 생각합니다.

Fuel: UTXO 기반 이더 운영 롤업

Fuel은 UTXO 기반 이더 운영 롤업으로, 이더 레이어2 생태계에 사기 증명 개념을 도입한 선구자이기도 합니다. 일반적인 UTXO 기능 지원의 경우, 퓨얼과 BTC는 본질적으로 동일합니다.

인퓨얼은 내부 UTXO를 다음 세 가지 카테고리로 나눕니다:

입력 코인:

연료 콘트랙트는 스마트 콘트랙트의 상태를 처리하는 방식과 프로그래밍 형식 측면에서 솔리디티 콘트랙트와 이념적으로 동일하다는 점을 언급할 필요가 있습니다. 다음 그림은 사용자가 increment_counter 함수를 호출하면 1씩 증가하는 카운터를 포함하는 연료의 스웨이 언어로 작성된 카운터 컨트랙트를 보여줍니다.

스웨이 컨트랙트를 작성하는 로직이 일반적인 솔리디티 컨트랙트와 유사하다는 것을 알 수 있습니다. 먼저 컨트랙트의 ABI를 제공하고, 컨트랙트의 상태 변수를 제공한 다음, 컨트랙트의 구체적인 구현을 제공합니다. 모든 코드 작성 과정에는 Fuel의 UTXO 시스템이 관여하지 않습니다.

이미지 src="https://img.jinse.cn/7197087_image3.png">

따라서 Fuel의 컨트랙트 프로그래밍 경험은 CKB나 Cardanao와 같은 UTXO 기반 프로그래밍 언어와는 다르며, Fuel은 EVM 스마트 컨트랙트 프로그래밍 개발에 더 가까운 경험을 제공합니다. . 또한 개발자는 스웨이 언어를 사용하여 잠금 해제 스크립트를 구성하여 특수 서명 알고리즘 검증 로직 또는 다중 서명과 같은 복잡한 잠금 해제 로직을 구현할 수 있습니다.

기본적으로 Fuel 내에서 동형 바인딩을 구현하는 것은 가능하지만 다음과 같은 문제가 있습니다.

Fuel은 스마트 컨트랙트 설계 측면에서 BTC 또는 CKB와 Cardano, RGB, Atomicals 등에 적합하기보다는 EVM 체인에 더 가까운 스웨이 언어를 사용합니다. UTXO형 자산 발행자의 경우, 하나의 스마트 콘트랙트를 특별히 Fuel에 구축하고 다른 스마트 콘트랙트를 CKB와 같은 체인에서 사용하는 것은 상당히 복잡합니다.

카다노: POS 기반 eUTXO 퍼블릭 체인

카다온은 UTXO 모델을 사용하는 또 다른 블록체인이지만, 연료와 달리 레이어1 퍼블릭 체인입니다. 카르다노는 시스템 내 eUTXO(확장 UTXO)를 지칭하기 위해 eUTXO라는 용어를 사용합니다. UTXO 프로그래밍 모델입니다. CKB와 달리, 카르다노 내의 eUTXO는 다음과 같은 구조를 포함합니다:

Script: UTXO가 잠금 해제될 수 있는지 확인하고 상태 전환을 수행하는 스마트 콘트랙트;

Redeemers:

Redeemers:사용자가 제공한 데이터로, UTXO의 잠금을 해제하는 데 사용되며 일반적으로 비트코인의 증인과 유사한 서명된 데이터입니다.

Datum:스마트 컨트랙트의 상태 공간입니다. 자산 상태와 같은 데이터를 저장할 수 있으며,

거래 컨텍스트:거래의 입력 파라미터 및 결과와 같은 UTXO 거래의 컨텍스트 데이터(UTXO 체인의 거래 계산 과정은 체인에서 직접 수행되며 결과는 체인에 제출됩니다). 검증을 위해 체인 위로 올라갑니다. 검증을 통과하면 트랜잭션 결과가 체인에 업로드됩니다)

개발자는 CKB와 유사한 플루터스코어 언어를 사용하여 카르다노 체인에서 UTXO를 프로그래밍할 수 있습니다. 마찬가지로 개발자는 잠금 해제 스크립트와 상태 업데이트를 위한 일부 함수를 작성할 수 있습니다.

카다노의 UTXO 프로그래밍 모델과 UTXO 기반 경매 프로세스를 소개합니다. 경매가 끝나기 전에 사용자가 오퍼를 낼 수 있어야 하는 자산 경매 DAPP을 구현해야 한다고 가정해 보겠습니다.구체적으로 사용자가 자신의 UTXO를 소비하고, 이 경매로 UTXO를 계약한 다음 새로운 경매 UTXO를 생성하고, 누군가 더 높은 오퍼를 내면 새로운 경매 계약 UTXO를 생성할 뿐만 아니라 이전 사람에게 환불 UTXO도 생성하는 구체적인 흐름은 다음과 같습니다. 그림:

위와 같은 경매 프로세스를 구현하기 위해서는 오퍼를 낸 사람과의 현재 경매 최고가 등 몇 가지 상태를 경매 스마트 컨트랙트 UTXO에 저장할 필요가 있습니다. 아래 그림은 플루투스코어 내부의 상태 선언을 보여주는데, bBidder와 bAmount에는 경매 오퍼와 오퍼를 낸 사람의 지갑 주소가 표시되어 있음을 확인할 수 있습니다. 그리고 경매 매개변수 안에는 경매에 대한 기본 정보가 들어 있습니다.

이미지 src="https://img.jinse.cn/7197090_image3.png">

사용자가 이 UTXO를 보내면 컨트랙트 내 상태를 업데이트할 수 있습니다. 아래 그림은 옥션 컨트랙트 내의 구체적인 상태 업데이트와 비즈니스 로직을 보여줍니다. 예를 들어, 사용자의 오퍼를 확인하고 현재 경매가 진행 중인지 확인하는 로직이 있습니다. 물론 플루터스코어는 순수 함수형 프로그래밍 언어인 하스켈로 되어 있기 때문에 대부분의 개발자는 그 의미를 직접 확인할 수 없을 수도 있습니다.

카다노에서 아이소모픽 바인딩을 구성하는 것은 가능하며, 데이터텀을 사용하여 자산 상태를 저장하고. 비트코인 관련 서명 알고리즘과 호환되도록 특정 스크립트를 작성할 수 있습니다. <하지만 심각한 문제는 대부분의 프로그래머가 플루터스 코어를 사용한 컨트랙트 프로그래밍에 익숙하지 않을 수 있으며, 프로그래밍 환경이 설정하기 어렵고 개발자에게 친숙하지 않다는 것입니다.

요약

아이소모픽 바인딩을 사용하려면 체인에 다음과 같은 속성이 필요합니다.

1. UTXO 모델 사용

2. 개발자가 잠금 해제 스크립트를 작성할 수 있는 상당한 UTXO 프로그래밍 가능성을 가짐

3. 자산 상태를 저장하는 UTXO 관련 상태 공간 존재

4. 스마트 컨트랙트 또는 기타 수단을 통해 비트코인 라이트 노드를 실행하도록 지원 가능

연료는 동형 바인딩과 호환되지만 스마트 컨트랙트 프로그래밍 아이디어의 특수성으로 인해 약간의 부담이 있으며, 카르다온은 컨트랙트 프로그래밍에 하스켈 프로그래밍 언어를 사용하기 때문에 대부분의 개발자가 빠르게 속도를 내기 어렵습니다. 이러한 이유로 RISC-V 명령어 집합을 사용하고 UTXO 프로그래밍의 기능 측면에서 더 균형 잡힌 CKB가 동형 바인딩에 더 적합한 기능 확장 계층이 될 수 있습니다.