원저자: Faust, Geek web3 및 BTCEden.org Lianchuang (X: @faustliu1997)

원본 출처:긱 웹3

RGB++ 및 관련 자산 발행이 인기를 끌면서 RGB 및 RGB++ 프로토콜의 원리에 대한 논의는 점점 더 많은 사람들의 관심 주제가 되었습니다. 그러나 RGB++를 이해하려면 먼저 RGB 프로토콜을 이해해야 한다는 사실은 모두가 알고 있습니다.

원래의 RGB 프로토콜은 기술적인 구조상 약간 모호하고 참고 자료가 분산되어 있어 아직까지 체계적이고 이해하기 쉬운 참고 자료가 많지 않습니다.Geek web3에서는 이전에 RGB 및 RGB++에 대한 체계적 해석 기사를 두 편 발표한 적이 있습니다. (저희 공식 계정의 이력을 보시면 알 수 있습니다.) 하지만 커뮤니티 회원들의 피드백에 따르면 앞서 언급한 글이 너무 길고 머리가 너무 아프다는 의견이 있습니다.

더 많은 사람들이 RGB 및 RGB++ 프로토콜을 더 빨리 이해할 수 있도록 이 기사의 저자는 홍콩 이벤트 기간 동안 서둘러 RGB 및 RGB++에 대한 짧은 현지어 해석을 완성했습니다. 몇 분 안에 읽을 수 있으며 도움이 되기를 바랍니다. 더 많은 커뮤니티 관심 독자는 RGB 및 RGB++를 더 잘, 더 직관적으로 이해할 수 있습니다.

RGB 프로토콜: 사용자가 직접 데이터 검증을 수행해야 함

RGB 프로토콜은 특별한 P2P 자산 프로토콜이자 비트코인 ​​체인 외부의 컴퓨팅 시스템으로, 사용자가 클라이언트를 직접 실행하고 전송 동작을 확인해야 한다는 점에서 결제 채널과 유사합니다(직접 확인). 단지 자산 수취인이라 할지라도 자산 발송인의 이체 명세서에 오류가 없는지 먼저 확인해야 이체 명세서가 효력을 발생합니다. 분명히 이는 자산을 보내고 받는 전통적인 형태와는 완전히 다르며, 우리는 이를 대화형 전송이라고 부릅니다.

왜 그럴까요? 그 이유는 개인 정보 보호를 보장하기 위해 RGB 프로토콜은 비트코인 ​​및 이더리움과 같은 기존 블록체인에서 합의 프로토콜을 채택하지 않기 때문입니다(데이터가 합의 프로토콜을 통과하면 네트워크의 거의 모든 노드에서 관찰됩니다). , 개인정보는 보장되지 않습니다. ). 다수의 노드가 포함된 합의 프로세스 없이 자산 변경이 안전한지 어떻게 보장할 수 있나요? 여기서는 클라이언트 검증(직접 검증)이라는 개념을 사용하는데, 클라이언트를 직접 실행하여 자신과 관련된 자산 변경 사항을 직접 검증해야 합니다.

Alice를 알고 있는 Bob이라는 RGB 사용자가 있고 Alice가 Bob에게 100개의 TEST 토큰을 전송하려고 한다고 가정합니다. Alice가 Alice to Bob의 이체 정보를 생성한 후 먼저 Bob에게 이체 정보와 관련된 자산 데이터를 보내고 후속 프로세스에 들어가기 전에 Bob이 직접 확인하여 올바른지 확인해야 합니다. 유효한 RGB 전송. 따라서 RGB 프로토콜을 사용하면 기존 합의 알고리즘을 대체하여 사용자가 데이터의 유효성을 직접 확인할 수 있습니다.

그러나 합의가 이루어지지 않고 서로 다른 RGB 클라이언트가 수신하고 저장하는 데이터가 일관성이 없습니다. 모든 사람은 자신의 자산 데이터를 로컬에만 저장하고 다른 사람의 자산 상태를 알 수 없습니다. 이는 개인 정보를 보호하는 동시에 데이터 섬을 형성합니다. 누군가가 1백만 개의 TEST 토큰을 가지고 있다고 주장하고 100,000개를 당신에게 전송하고 싶어한다면 어떻게 그를 믿을 수 있습니까?

RGB 네트워크에서 누군가가 귀하에게 돈을 이체하려는 경우 먼저 자산 증명을 제시하고 최초 발행부터 여러 번의 손 변경까지 자산의 과거 출처를 추적하고 토큰이 귀하에게 전송되는지 확인해야 합니다. 이것은 마치 수령할 때 정체불명의 지폐를 받았을 때, 위조화폐를 피하기 위해 상대방에게 그 지폐의 역사적 유래와 지정된 발행인이 제조했는지 여부를 설명해 달라고 요청하는 것과 같습니다.

(이미지 출처: 코인넥스)

위의 프로세스는 비트코인 ​​체인 외부에서 발생하며 이러한 프로세스만으로는 RGB가 비트코인 ​​네트워크와 직접 연결되는 것을 허용하지 않습니다. 이에 대해 RGB 프로토콜은 RGB 자산을 비트코인 ​​체인의 UTXO에 바인딩하기 위해 일회용 씰이라는 아이디어를 채택하고 있으며, 비트코인 ​​UTXO가 이중으로 소비되지 않는 한 바인딩된 RGB 자산은 두 배가 되지 않습니다. 비트코인 네트워크를 사용하여 RGB 자산의 재구성을 방지할 수 있습니다. 물론 이를 위해서는 비트코인 ​​체인에 대한 약속을 발행하고 OP_Return opcode를 사용해야 합니다.

다음은 RGB 프로토콜의 작업 흐름을 요약한 것입니다.

1. RGB 자산은 Bitcoin UTXO에 바인딩되어 있으며 Bob은 특정 Bitcoin UTXO를 소유하고 있습니다. Alice는 Bob에게 100개의 토큰을 전송하려고 합니다. Bob은 자산을 받기 전에 이러한 RGB 자산을 바인딩하는 데 사용해야 하는 Bob의 비트코인 ​​UTXO 중 어느 것을 Alice에게 미리 알려줍니다.

(이미지 출처: Geek web3/ Geek Web3)

• Alice는 이러한 자산의 과거 소스와 함께 Alice to Bob RGB 자산 전송 데이터를 구성하고 확인을 위해 Bob에게 제공합니다.

• Bob은 데이터가 정상임을 로컬에서 확인한 후 Alice에게 트랜잭션이 진행될 수 있다는 영수증을 보냅니다.

• Alice는 Alice to Bob의 RGB 전송 데이터를 Merkle Tree에 구축하고 Merkle Root를 비트코인 ​​체인에 Commitment로 게시합니다. 우리는 Commitment를 전송 데이터의 해시로 간단히 이해할 수 있습니다.

• 위에서 언급한 Alice to Bob의 전송이 실제로 발생했는지 미래에 확인하려는 사람은 두 가지 작업을 수행해야 합니다. 즉, 비트코인 ​​체인에서 Alice to Bob의 전체 전송 정보를 얻은 다음 여부를 확인해야 합니다. 비트코인 체인 커미트먼트(전송 데이터의 해시)에 해당 트랜잭션이 있습니다. 그게 전부입니다.

여기서 비트코인은 RGB 네트워크의 기록 로그 역할을 하지만 트랜잭션 데이터 자체가 아닌 트랜잭션 데이터의 해시/머클 루트만 로그에 기록됩니다. RGB 프로토콜은 클라이언트 검증과 일회성 봉인을 사용하므로 보안성이 매우 높으며, RGB 네트워크는 합의되지 않은 P2P 형식의 동적 사용자 클라이언트로 구성되어 있어 별도의 부담 없이 언제든지 상대방을 변경할 수 있습니다. 트랜잭션 요청은 제한된 수의 노드로 전송되므로 RGB 네트워크는 검열 저항성이 매우 뛰어나며 이러한 조직 형태는 이더리움과 같은 대규모 퍼블릭 체인보다 검열 저항성이 뛰어납니다.

(이미지 출처: BTCEden.org)

물론 극도로 높은 보안, 검열 저항, 개인 정보 보호에 대한 비용도 명백합니다: 사용자는 클라이언트를 실행하여 데이터를 직접 확인해야 합니다.상대방이 수만 번 손을 바꾸고 가지고 있는 일부 자산을 전송하면 오랜 역사를 갖고 있기 때문에 압박감 속에서도 모든 것을 검증해야 합니다.

또한 각 거래에는 두 당사자 간의 다중 통신이 필요하며, 수신자는 먼저 보낸 사람의 자산 출처를 확인한 후 보낸 사람의 이체 요청을 승인하기 위해 영수증을 보내야 합니다. 이 과정에서 두 당사자 간에 최소 3개의 메시지가 전달되어야 합니다. 이러한 종류의 대화형 이체는 대부분의 사람들에게 익숙한 비대화형 이체와 심각하게 일치하지 않습니다. 누군가가 귀하에게 돈을 이체하려면 거래 데이터를 보내 확인하고 받아야 한다는 것을 상상할 수 있습니까? 영수증을 받으셨나요? 메시지를 받은 후에만 송금 절차가 완료되나요?

또한, 우리는 RGB 네트워크가 합의가 없고 각 클라이언트가 섬이라는 점을 언급했습니다. 이는 Ethereum 또는 Solana의 Defi 프로토콜이 모두 A에 의존하기 때문에 전통적인 퍼블릭 체인의 복잡한 스마트 계약 시나리오를 RGB 네트워크로 마이그레이션하는 데 도움이 되지 않습니다. 전 세계적으로 공개되고 데이터가 투명한 원장. RGB 프로토콜을 최적화하고 사용자 경험을 개선하며 위의 문제를 해결하는 방법은 무엇입니까? 이는 RGB 프로토콜에서는 피할 수 없는 문제가 되었습니다.

RGB++: 클라이언트 검증이 낙관적인 호스팅이 됩니다.

RGB++라는 프로토콜은 RGB 프로토콜을 CKB, Cardano, Fuel 등 UTXO를 지원하는 퍼블릭 체인과 결합한 새로운 아이디어를 제시합니다. 후자는 RGB 자산에 대한 검증 레이어 및 데이터 저장 레이어 역할을 하며 원래 수행된 데이터를 변환합니다. 검증 작업은 CKB와 같은 제3자 플랫폼/퍼블릭 체인에 넘겨집니다. 이는 클라이언트 검증을 검증을 위한 제3자 분산형 플랫폼으로 대체하는 것과 같습니다. CKB, Cardano와 같은 퍼블릭 체인을 신뢰하는 한 , 연료 등을 신뢰하지 않는 경우 기존 RGB 모드로 다시 전환할 수도 있습니다.

RGB++와 원래 RGB 프로토콜은 이론적으로 서로 호환됩니다.

위에서 언급한 효과를 얻으려면 동형 바인딩이라는 아이디어를 사용해야 합니다. CKB 및 Cardano와 같은 퍼블릭 체인에는 BTC 체인의 UTXO보다 더 프로그래밍 가능한 자체 확장 UTXO가 있습니다. 동형 바인딩은 CKB, Cardano 및 Fuel 체인의 확장된 UTXO를 RGB 자산 데이터의 컨테이너로 사용하고, RGB 자산의 매개변수를 이러한 컨테이너에 기록하고, 이를 블록체인에 직접 표시하는 것입니다. RGB 자산 거래가 발생할 때마다 해당 자산 컨테이너도 엔터티와 그림자 간의 관계처럼 유사한 특성을 나타낼 수 있으며 이것이 동형 바인딩의 본질입니다.

(이미지 출처: RGB++ LightPaper)

예를 들어 앨리스가 비트코인 ​​체인에 100개의 RGB 토큰과 UTXO A를 소유하고 CKB 체인에도 UTXO가 있는 경우 이 UTXO는 RGB 토큰 잔액: 100으로 표시되며 잠금 해제 조건은 UTXO A와 관련됩니다. .

Alice가 Bob에게 30개의 토큰을 보내고 싶다면 먼저 Commitment를 생성할 수 있습니다. 해당 명령문은 UTXO A와 관련된 RGB 토큰 중 30개를 Bob에게 전송하고 70개를 그녀가 제어하는 ​​다른 UTXO에 전송하는 것입니다.

그 후, Alice는 비트코인 ​​체인에서 UTXO A를 소비하고 위의 설명을 게시한 다음 CKB 체인에서 거래를 시작하여 100개의 RGB 토큰을 운반하는 UTXO 컨테이너를 소비하고 두 개의 새로운 컨테이너를 생성합니다. 하나는 30개의 토큰(Bob에게)을 보유하고 다른 하나는 70개의 토큰을 보유합니다(Alice가 제어함). 이 과정에서 Alice 자산의 유효성과 거래 명세서의 유효성을 검증하는 작업은 Bob의 개입 없이 합의를 통해 CKB 또는 Cardano와 같은 네트워크 노드에 의해 완료됩니다. 이때 CKB와 Cardano는 비트코인 ​​체인 아래의 검증 레이어와 DA 레이어 역할을 합니다.

(이미지 출처: RGB++ LightPaper)

모든 사람의 RGB 자산 데이터는 CKB 또는 Cardano 체인에 저장됩니다. 이는 전 세계적으로 검증 가능한 특성을 가지며 유동성 풀 및 자산 서약 프로토콜과 같은 Defi 시나리오 구현에 도움이 됩니다. 물론 위의 접근 방식은 개인 정보 보호도 희생합니다. 핵심은 개인 정보 보호와 제품 사용 편의성 사이에서 균형을 맞추는 것입니다. 최고의 보안과 개인 정보 보호를 추구한다면 전통적인 RGB 모드로 다시 전환할 수 있습니다. 이 점에 주의하시면 안전하게 RGB++를 사용할 수 있습니다. 모드는 전적으로 개인의 필요에 따라 다릅니다. (실제로 CKB, Cardano 등 퍼블릭 체인의 강력한 기능적 완성도를 바탕으로 ZK를 사용하여 프라이빗 거래를 실현할 수 있습니다)

여기서는 RGB++가 중요한 신뢰 가정을 도입한다는 점을 강조해야 합니다. 사용자는 CKB/Cardano 체인 또는 합의 프로토콜에 의존하는 다수의 노드로 구성된 네트워크 플랫폼이 안정적이고 오류가 없다고 낙관해야 합니다. CKB를 신뢰하지 않는다면 원래 RGB 프로토콜의 대화형 통신 및 확인 프로세스를 따르고 클라이언트를 직접 실행할 수도 있습니다.

RGB++ 프로토콜에서 사용자는 비트코인 ​​계정을 사용하여 교차 체인 없이 CKB/Cardano와 같은 UTXO 체인에서 자신의 RGB 자산 컨테이너를 직접 운영할 수 있습니다. 위 공개 체인의 UTXO 특성을 사용하여 잠금 해제 조건을 설정하기만 하면 됩니다. 셀 컨테이너의 특정 비트코인 ​​주소/비트코인 UTXO와 연결되도록 설정하기만 하면 됩니다. RGB 자산 거래의 양쪽 당사자가 CKB의 보안을 신뢰한다면 그들은 비트코인 ​​체인에 커밋을 자주 게시할 필요조차 없습니다. 많은 RGB 전송이 완료된 후 그들은 비트코인 ​​체인에 커밋을 보낼 수 있습니다. 이것을 트랜잭션 폴딩.” 기능을 사용하면 사용 비용을 줄일 수 있습니다.

그러나 동형 바인딩에 사용되는 컨테이너에는 UTXO 모델을 지원하는 퍼블릭 체인이나 상태 저장과 유사한 특성을 가진 인프라가 필요하다는 점에 유의해야 합니다. EVM 체인은 적합하지 않으며 많은 함정에 직면하게 됩니다. (이 주제는 별도로 작성될 수 있으며 내용이 많습니다. 관심 있는 독자는 Geek Web3의 이전 기사를 참조할 수 있습니다.RGB++ 및 동형 바인딩: CKB, Cardano 및 Fuel이 비트코인 ​​생태계에 힘을 실어주는 방법；

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

• UTXO 모델 또는 유사한 상태 저장 체계를 사용합니다.

• 상당한 UTXO 프로그래밍 기능을 갖추고 있어 개발자가 잠금 해제 스크립트를 작성할 수 있습니다.

• 자산 상태를 저장할 수 있는 UTXO 관련 상태 공간이 있습니다.

• 비트코인 관련 브리지나 라이트 노드가 있습니다.