RGB 및 RGB++ 프로토콜 디자인에 대한 몇 분간의 집중 강좌: 기본 지침

저자: Faust, geekweb3 & BTCEden.org의 공동창업자

RGB++ 및 관련 에셋의 출시로 RGB 및 RGB++ 프로토콜의 원리에 대한 논의가 점차 뜨거워지면서 더 많은 관심의 대상이 되었습니다. 하지만 RGB++를 이해하려면 RGB 프로토콜을 먼저 이해해야 한다는 것은 누구나 알고 있는 사실입니다.

원래 RGB 프로토콜은 기술 구조가 다소 모호하고 참고 문헌이 흩어져 있어 체계적이고 이해하기 쉬운 참고 문헌이 많지 않습니다. Geekweb3는 RGB와 RGB++에 대한 체계적인 설명을 두 차례 게시했습니다(블로그 게시물 참조). Geekweb3는 이전에 RGB와 RGB++에 대한 두 개의 체계적인 글을 게시한 적이 있지만(공개 번호의 역사를 확인할 수 있습니다), 커뮤니티 회원들의 피드백에 따르면 이전 글은 너무 길고 머리가 너무 아프다는 의견이 많았습니다.

이 글의 작성자는 더 많은 사람들이 RGB와 RGB++ 프로토콜을 더 빨리 이해할 수 있도록 하기 위해 홍콩 행사에서 즉흥적으로 몇 분 안에 읽을 수 있는 RGB와 RGB++에 대한 짧은 설명을 작성했으며, 더 많은 커뮤니티 애호가들이 RGB와 RGB++를 더 쉽고 직관적으로 이해할 수 있기를 희망하고 있습니다. RGB와 RGB++ 이해하기.

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

RGB 프로토콜은 특별한 종류의 P2P 자산 프로토콜로, 비트코인 체인 아래의 계산 시스템이며, 결제 채널과 유사합니다. 몇 가지 측면은 결제 채널과 유사합니다: 사용자가 직접 클라이언트를 실행하여 자신과 관련된 송금을 확인해야 합니다(Verify by yourself). 자산 수취인일지라도 자산 송금인의 이체 내역이 잘못되지 않았는지 확인해야만 이체 내역의 유효성을 검사할 수 있습니다. 이는 "대화형 전송"이라고 부르는 기존의 자산 송금 및 수신 형태에서 완전히 벗어난 것입니다.

왜 이것이 중요한가요? 그 이유는 RGB 프로토콜은 프라이버시 보호를 위해 비트코인이나 이더리움과 같은 기존 블록체인에서 사용되는 '합의 프로토콜'을 사용하지 않기 때문입니다(데이터가 합의 프로토콜을 거치게 되면 네트워크의 거의 모든 노드가 이를 관찰하게 되므로 프라이버시 보호에 좋은 방법이 아닙니다). 다수의 노드가 참여하는 합의 과정 없이 어떻게 자산 변경의 보안을 보장할 수 있을까요? 여기서는 "직접 확인"이라는 아이디어를 사용하여 사용자가 직접 클라이언트를 실행하고 자신과 관련된 자산 변경 사항을 직접 확인합니다.

앨리스를 아는 밥이라는 RGB 사용자가 있고, 앨리스가 밥에게 100개의 테스트 토큰을 전송하고 싶다고 가정해 보겠습니다. 앨리스가 "앨리스에서 밥으로" 전송 메시지를 생성한 후 전송 정보와 관련된 자산 데이터를 밥에게 보내야만 밥이 직접 확인하고 다음 프로세스에 들어가기 전에 올바른지 확인할 수 있으며, 이를 통해 최종적으로 유효한 RGB 전송이 됩니다. 따라서 RGB 프로토콜은 기존의 합의 알고리즘을 대체하여 사용자가 직접 데이터의 유효성을 검증할 수 있습니다.

그러나 합의가 없으면 서로 다른 RGB 클라이언트가 수신하고 저장하는 데이터는 일관성이 없으며, 모두가 자신과 관련된 자산 데이터만 로컬에 저장하고 다른 사람의 자산 상태에 대해서는 알 수 없으므로 개인 정보를 보호하는 동시에 "데이터 사일로". 누군가 100만 개의 테스트 토큰을 보유하고 있다고 주장하며 10만 개를 송금해달라고 한다면 어떻게 그를 신뢰할 수 있을까요?

RGB 네트워크에서는 누군가 여러분에게 돈을 송금하고 싶다면 먼저 자산의 출처를 역추적하여 최초 발행부터 여러 번 손을 바꾼 자산의 과거 출처를 보여주고, 송금하려는 토큰이 괜찮은지 확인해야 합니다. 이는 마치 출처를 알 수 없는 종이 돈을 받을 때와 마찬가지입니다. 출처를 알 수 없는 지폐를 받으면 위조를 피하기 위해 상대방에게 지폐의 출처와 지정된 발행자가 만든 지폐인지 여부를 물어봅니다.

(이미지 출처: Coinex)

위 과정은 비트코인 체인에서 이루어지며, 이 과정만으로는 RGB를 비트코인 네트워크와 직접 연결할 수 없습니다. 이에 대응하여 RGB 프로토콜은 "일회용 씰"이라는 개념을 사용하여 RGB 자산을 비트코인 체인의 UTXO에 바인딩하여, 비트코인 UTXO가 이중으로 소비되지 않는 한 바인딩된 RGB 자산에 대해 이중 결제가 발생하지 않도록 합니다. 이는 비트코인 네트워크를 통한 RGB 자산의 "재구성"을 방지합니다. 물론 이를 위해서는 OP_Return 옵코드와 함께 비트코인 체인에 커미트먼트가 게시될 필요가 있습니다.

RGB 프로토콜의 워크플로우를 간략히 소개합니다:

1. RGB 자산은 비트코인 UTXO에 묶여 있습니다.

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

2. 앨리스는 "Alice to Bob "의 RGB 자산 전송 데이터의 합계를 구성하고, 해당 자산의 출처를 Bob에게 전달하여 확인합니다.

3. 밥은 이 데이터가 정상임을 로컬에서 확인하고 앨리스에게 이 트랜잭션이 진행되었음을 알리는 승인 메시지를 보냅니다.

4. 앨리스는 "앨리스에서 밥으로" RGB 전송 데이터로 머클 트리를 생성하고 머클 루트를 비트코인 체인에 커밋으로 게시합니다. 머클 루트는 비트코인 체인에 커밋으로 게시되며, 이는 단순히 전송 데이터의 해시라고 생각할 수 있습니다.

5. 미래에 누군가 "앨리스에서 밥으로" 전송이 실제로 발생했는지 확인하고자 한다면, 머클 트리를 사용해 전송에 사용된 머클 루트와 동일하지 않은지 확인할 수 있습니다. 미래에 누군가가 "앨리스에서 밥으로" 전송이 실제로 발생했는지 확인하려면, 비트코인 체인에서 전체 "앨리스에서 밥으로" 전송을 가져온 다음, 비트코인 체인에서 해당 커밋(전송 데이터의 해시)이 있는지 확인하는 두 가지 작업을 수행해야 할 것입니다.

비트코인은 RGB 네트워크의 기록 로그 역할을 하지만 로그에는 거래 데이터의 해시/매시만 기록됩니다. 는 트랜잭션 데이터의 해시/머클 루트를 기록하며, 트랜잭션 데이터 자체는 기록하지 않습니다. 클라이언트 측 인증과 일회성 씰링으로 인해 RGB 프로토콜은 매우 안전하며, RGB 네트워크는 P2P, 합의가 필요 없는 형태의 동적 사용자 클라이언트로 구성되므로 거래 요청을 일부 한정된 수의 노드에 보내지 않고도 언제든지 거래 상대방을 변경할 수 있으므로 RGB 네트워크는 검열에 매우 강합니다. 는 검열에 매우 강하며, 이러한 형태의 조직은 이더와 같은 대규모 퍼블릭 체인보다 훨씬 더 검열에 강합니다.

(이미지 출처: BTCEden.org)

물론, 매우 높은 보안과 검열 방지, 프라이버시 보호에는 분명한 대가가 따릅니다. 사용자는 수만 번 손을 바꾸는 무언가를 보내는 상대방이 데이터를 확인하려면 자체 클라이언트를 실행하여 확인해야 합니다, 상대방이 오랜 이력을 가진 자산을 보내는 경우, 사용자도 모든 자산을 검증해야 합니다.

또한 각 거래에는 양측 간에 여러 번의 통신이 필요하며, 수신자는 발신자의 송금 요청을 승인하는 영수증을 보내기 전에 발신자의 자산 출처를 확인해야 합니다. 이 과정에서 두 당사자 간에 최소 세 개의 메시지가 생성됩니다. 이러한 종류의 '대화형 송금'은 대부분의 사람들이 익숙한 '비대화형 송금'과는 다릅니다. 다른 사람이 송금하고, 확인할 거래 데이터를 보내고, 확인 메시지를 받은 후 송금 절차를 완료한다고 상상해 보세요. 이체 프로세스를 완료하기 전에

또한 앞서 언급했듯이 RGB 네트워크에는 합의가 없으며 각 클라이언트는 섬과 같기 때문에 이더리움이나 솔라나의 Defi 프로토콜은 전 세계에서 볼 수 있고 데이터가 투명한 원장에 의존하므로 복잡한 스마트 컨트랙트 시나리오를 기존 퍼블릭 체인에서 RGB 네트워크로 마이그레이션하는 데 도움이 되지 않을 수 있습니다. 원장에 의존하기 때문입니다. 사용자 경험을 개선하고 위의 문제를 해결하기 위해 RGB 프로토콜을 최적화하는 방법은 무엇일까요? 이는 RGB 프로토콜이 해결할 수 없는 문제입니다.

RGB++: 클라이언트 인증, 최적의 호스팅이 되다

RGB++라는 프로토콜은 CKB를 통해 RGB 프로토콜에 대한 새로운 사고방식을 제시합니다, 카르다노, 퓨얼 및 기타 UTXO를 지원하는 퍼블릭 체인으로, 후자는 RGB 자산의 검증 및 데이터 저장 계층 역할을 하며, 사용자가 원래 수행한 데이터 검증 작업을 CKB와 같은 제3자 플랫폼/퍼블릭 체인으로 넘겨주는데, 이는 CKB를 신뢰하는 한 클라이언트 검증을 "제3자 탈중앙 플랫폼이 검증을 수행하는 것"으로 대체하는 것과 동일하다 할 수 있죠. 이는 클라이언트 측 검증을 "제3자 탈중앙화 플랫폼이 검증을 수행하는 것"으로 대체하는 것과 동일하며, CKB, 카르다노, 연료 및 기타 퍼블릭 체인을 신뢰하는 한, 이를 신뢰하지 않는 경우 기존 RGB 모드로 다시 전환할 수 있습니다.

RGB++와 기존 RGB 프로토콜은 이론적으로 서로 호환되며, 나 없이도 사용할 수 있는 경우가 아닙니다.

위에서 언급한 효과를 얻으려면 "...라는 방법을 사용해야 합니다. CKB와 카르다노와 같은 퍼블릭 체인에는 자체 확장 UTXO가 있으며, 이는 BTC 체인의 UTXO보다 더 프로그래밍이 가능합니다. "아이소모픽 바인딩"의 개념은 CKB, 카르다노, 퓨얼 체인의 확장 UTXO를 RGB 자산 데이터의 "컨테이너"로 사용하고, 이 컨테이너에 RGB 자산의 파라미터를 기록하여 블록체인에 직접 표시하는 것입니다. RGB 자산 트랜잭션이 발생할 때마다 해당 자산 컨테이너는 실체와 그림자의 관계처럼 유사한 특성을 나타낼 수 있으며, 이것이 바로 '아이소모픽 바인딩'의 본질입니다.

(RGB++, LightPaper 이미지 제공)

(RGB++, LightPaper 이미지 제공) LightPaper)

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

앨리스가 밥에게 30개의 토큰을 주고자 한다면, 이는 커밋으로 할 수 있는데, 이는 UTXO A와 연결된 RGB 토큰을 가져와 밥에게 30개, 자신이 관리하는 다른 UTXO에게 70개를 전송하는 문장에 해당합니다.

. "text-align: left;">이후 앨리스는 비트코인 체인에서 UTXO A를 소비하고 위의 진술을 게시한 다음, CKB 체인에서 트랜잭션을 시작하여 100개의 RGB 토큰을 담고 있는 UTXO 컨테이너를 소비하여 30개의 토큰(밥을 위한)과 70개의 토큰(앨리스가 통제하는)을 담고 있는 2개의 새로운 컨테이너를 생성합니다. 이 과정에서 앨리스 자산의 유효성과 거래 내역의 유효성을 검증하는 작업은 밥의 개입 없이 CKB 또는 카르다노 워킹 합의와 같은 네트워크 노드에 의해 수행됩니다. 이 시점에서 CKB와 카르다노는 비트코인 체인의 검증 및 DA 레이어 역할을 합니다.

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

모든 RGB 자산 데이터는 전 세계적으로 검증 가능하며 유동성 풀 및 자산 담보 계약과 같은 Defi 시나리오를 용이하게 하는 CKB 또는 카르다노 체인에 저장됩니다. 물론 위의 접근 방식은 프라이버시를 희생하기도 하는데, 이는 본질적으로 프라이버시와 제품 사용 편의성 사이의 절충점입니다. 최고의 보안과 프라이버시를 추구한다면 기존의 RGB 모델로 다시 전환할 수 있으며, 이에 신경 쓰지 않는다면 개인의 필요에 따라 RGB++ 모델을 채택할 수 있습니다. (사실, CKB와 카르다노와 같은 퍼블릭 체인의 강력한 기능 완성도를 통해 ZK로 프라이버시 거래를 달성할 수 있습니다)

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

RGB++ 프로토콜 하에서 사용자는 앞서 언급한 퍼블릭 체인의 UTXO 기능을 활용하고 셀의 잠금 해제 조건을 설정하기만 하면 체인을 거치지 않고도 자신의 비트코인 계정으로 직접 CKB/카드노 등과 같은 UTXO 체인에서 자신의 RGB 자산 컨테이너를 운영할 수 있습니다. 컨테이너의 잠금 해제 조건을 특정 비트코인 주소/비트코인 UTXO와 연결되도록 설정하기만 하면 됩니다. RGB 자산 거래의 양 당사자가 CKB의 보안을 신뢰하고 비트코인 체인에 자주 커밋할 필요가 없는 경우, 여러 번의 RGB 전송이 이루어진 후 하나의 커밋을 비트코인 체인에 보낼 수 있는데, 이를 "트랜잭션 붕괴"라고 합니다. 기능으로 사용 비용을 절감할 수 있습니다.

하지만 동형 바인딩에 사용되는 컨테이너가 UTD를 지원해야 한다는 점에 유의하세요. "를 지원해야 하며, 퍼블릭 체인의 UTXO 모델을 지원해야 하거나, 인프라의 유사한 특성을 가진 상태 저장소에서 EVM 체인은 적합하지 않으며, 많은 함정이 발생할 수 있습니다. (이 주제는 별도의 기사가 될 수 있으며, 더 많은 내용이 포함될 수 있으며, 관심 있는 독자는 geekweb3 이전 기사 "RGB++와 동형 바인딩: CKB, 카르다노, 연료가 비트코인 생태계를 강화하는 방법";"

통합적으로, 공개 체인/공개 체인을 구현하는 데 적합한 퍼블릭 체인/기능 확장 레이어의 동형 바인딩은 다음과 같은 특징을 가져야 합니다.

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

   <

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

3. 자산 상태를 저장할 수 있는 UTXO 관련 상태 공간이 있음;

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