비트코인 자산 발행 프로토콜인 RGB의 실제 잠재력은 무엇입니까?
원저자: A Jian, Wu Shuo 블록체인
이 기사에서는 비트코인의 자산 발행 프로토콜인 RGB(오프체인 스마트 계약 시스템으로도 이해될 수 있음)에 대해 간략하게 설명하고 동일한 목표를 달성하려는 다른 프로토콜과 매우 다르다는 점을 지적합니다. 또는 유사한 기능 이러한 차이점으로 인해 RGB 프로토콜은 RGB 프로토콜보다 확장성이 훨씬 뛰어나고 프로그래밍 공간이 더 넓어집니다. RGB의 완성된 디자인을 소개하는 것 외에도 이러한 프로그래밍 가능성도 살펴보겠습니다.
RGB 프로토콜이란 무엇입니까?
비트코인으로 자산을 발행한다는 아이디어는 오랫동안 존재해 왔습니다. 그러나 비트코인 프로토콜에는 고유한 특성이 있습니다. 상태는 비트코인 UTXO(사용되지 않은 트랜잭션 출력)에 의해서만 표현됩니다. UTXO는 자체 단위(비트코인 가치)와 스크립트 공개 키(스크립트 공개 키)라는 두 가지 데이터만 전달합니다. 잠금 스크립트라고도 함), 자금 지출 조건을 프로그래밍하는 데 사용됩니다(예: 특정 공개 키의 서명 제공, 잠금 스크립트 프로그래밍을 허용하는 opcode는 다음과 같은 경우 비트코인 합의 규칙에 따라 결정됨). 임의의 보안 규칙을 구현하는 데 사용할 수 없습니다. 따라서 UTXO 내부에 다른 자산을 생성하는 것은 불가능합니다. 비트코인 스크립트는 이러한 자산에 대한 보안 검사를 프로그래밍할 수 없습니다. 이는 비트코인에서 자산을 발행하기 위한 모든 아이디어가 본질적으로 비트코인 블록 공간을 창의적으로 사용한다는 것을 의미합니다. 이는 오프체인 스마트 계약 시스템을 설계해야 하며 계약 상태를 변경하는 단계에 대한 정보가 필요하다는 것을 의미합니다. 예를 들어 계약 A는 매개변수를 변경하고 B는 일정량의 자산을 C로 전송합니다. - 블록체인에 업로드 , 이 정보를 수집함으로써 본 스마트 계약 시스템의 최신 상태를 얻을 수 있습니다.
대략적인 설계 아이디어는 계약 상태를 변경하는 단계의 정보를 비트코인 블록체인에 그대로 업로드하는 것입니다. 이는 확실히 작동할 수 있지만 몇 가지 문제에 직면하게 됩니다. (1) 완전한 정보가 업로드되므로 사용자가 계약 상태(예: 전송)를 변경해야 할 때 더 많은 블록 공간을 소비할 수 있습니다. 더 많은 온체인 처리 수수료를 지불해야 합니다. 특히 이러한 오프체인 계약 시스템이 비트코인보다 더 나은 프로그래밍 가능성을 갖기를 희망할 때, 프로그래밍 가능성의 증가는 더 많은 블록 공간을 소비하는 대가로 올 수 있습니다. 체인 외부의 스마트 계약.따라서 사용자는 오프 체인 계약 시스템의 최신 상태를 얻으려면 모든 비트코인 블록 데이터를 획득해야 하며, 즉 검증 비용이 더 높습니다.(3) 오프 체인 스마트 계약의 설계에 따라 계약 시스템의 경우 비트코인과 비슷하거나 더 나쁜 수준의 개인 정보 보호만 얻을 수 있으며, 더 많은 개인 정보 보호를 제공할 수 있다면 더 많은 블록 공간을 소비해야 할 수도 있습니다.
과거에는 Omni라는 널리 사용되는 프로토콜이 오프체인 계약 거래의 전체 정보를 업로드하지 않고 거래의 해시 값만 업로드했습니다. 이 접근 방식은 위의 문제 1을 해결하고 오프체인 계약 거래의 복잡성과 경제적 비용을 분리합니다. 그러나 사용자는 Omni 프로토콜의 최신 상태를 얻으려면 여전히 전체 비트코인 블록 데이터를 얻어야 합니다. 그렇지 않습니다. 개인 정보 보호가 특별히 강화된 것은 없습니다.
RGB는 일회용 씰이라는 새로운 패러다임을 사용합니다. 사용법은 매우 간단합니다. RGB에서는 각 계약의 모든 상태가 특정 비트코인 UTXO에 연결되어야 하며, 이 상태를 변경하려면 이 UTXO를 소비하고 이를 소비하는 거래가 블록체인의 확인을 받도록 해야 합니다. 또한 이를 소비하는 비트코인 거래는 변경된 상태에 첨부된 UTXO를 나타내기 위해 상태 전환 내용의 해시도 제공해야 합니다.
RGB 개발자에게 이 디자인은 번호가 매겨진 플라스틱 씰과 유사합니다. 제거되었는지 쉽게 알 수 있으며, 제거한 후에는 재사용할 수 없습니다. 그러나 또 다른 관점은 소지한 UTXO를 이 상태의 용기 또는 세라믹 돼지 저금통으로 보는 것이다. 돼지 저금통에 들어 있는 돈을 꺼내려면 돼지 저금통을 부수고 안에 있는 돈을 꺼내야 한다. 새 항아리에 담긴 돈.
이 설계는 전체 블록을 큰 쓰기판으로 취급했던 이전 프로토콜과 극명하게 대조됩니다: UTXO를 컨테이너로 사용한다는 것은 이 UTXO를 사용하지 않는 트랜잭션이 컨테이너의 계약 상태에 아무런 영향을 미칠 수 없다는 것을 의미합니다. 특정 계약의 특정 상태에서는 모든 블록의 데이터를 얻을 필요가 없습니다. 우리에게 필요한 것은 일련의 비트코인 트랜잭션, 이러한 비트코인 트랜잭션이 특정 블록에 존재한다는 증거, 그리고 이러한 비트입니다. 통화 교환(관련 비트코인 거래와의 일대일 쌍)이면 충분합니다. 체인으로 연결될 수 있는 이러한 데이터를 통해 이 계약의 초기 상태를 추적할 수 있으며 이 상태의 본질을 식별할 수 있습니다.
온체인 스마트 계약 시스템(예: 이더리움)에 익숙한 독자의 경우, 이 프로세스에 대해 이해하기 어려운 점 중 하나는 블록체인의 합의에 의존하지 않는다면(이는 블록체인의 초기 상태를 의미함) 계약 및 모든 상태 변경은 각 노드에서 확인됩니다. 이 스마트 계약 시스템의 보안은 어떻게 보장됩니까? 귀하가 수령한 자산이 귀하가 원하는 자산인지 확인하는 방법과 해당 자산이 불법적으로 발행되지 않았는지 확인하는 방법은 무엇입니까?
대답도 매우 간단합니다. 이를 클라이언트 측 유효성 검사라고 합니다. 직접 확인하면 됩니다. 온체인 계약 시스템에서 노드는 공개 상태 전환 규칙에 따라 각 상태 전환 작업을 확인하고 유효하지 않은 작업을 거부한 다음 초기 상태를 기반으로 최신 상태를 계산합니다. 그러나 상태 전이 규칙과 초기 상태가 알려져 있는 한 온체인 합의를 통한 검증만이 유일한 방법은 아니며, 사용자는 상태 전이의 각 단계가 초기에 정의된 상태 전이를 따르는지 여부를 에서 제공하는 정보를 기반으로 검증할 수 있습니다. 지불인.규칙. 이러한 방식으로 검증 당사자(자산의 수령자로 가정)도 불법적인 상태 전환을 감지하고 이를 수락을 거부할 수 있습니다.
마지막으로 RGB 프로토콜의 특성을 보여주기 위해 예를 사용합니다.
이제 Alice는 RGB 프로토콜에 따라 발행된 X 단위의 자산 Y를 보유하는 UTXO A를 소유하고 있으며 Z 단위의 Y를 Bob에게 전송하려고 합니다. 이 자산 배치는 Alice의 손에 도달하기 전에 총 5명의 이전 소유자(자산 발행자 포함)를 거쳤습니다. 따라서 Alice는 계약의 초기 상태, 상태 전환 규칙, 각 전송에 사용된 비트를 포함하여 이러한 4가지 상태 전환(이전 소유자가 처음 3개는 Alice에게 제공함)에 대한 증거를 Bob에게 제공해야 합니다. 비트코인 트랜잭션, 각 비트코인 거래소에서 커밋된 RGB 트랜잭션, 그리고 이러한 비트코인 트랜잭션이 특정 블록에 의해 확인되었다는 증거가 Bob에게 전송됩니다. Bob은 이 4개의 전송이 상태 전이 규칙에 따라 규칙을 위반하지 않는지 확인합니다. 계약을 체결한 후 수락 여부를 결정합니다. Alice가 RGB 트랜잭션을 구성할 때 Z는 X보다 작기 때문에 나머지 부분을 받기 위해 자신도 UTXO를 준비해야 합니다. 마지막으로 Alice는 이 RGB 거래의 해시 값을 UTXO A 비용이 드는 비트코인 거래에 삽입하여 결제를 완료합니다.
마지막으로, UTXO 컨테이너의 사용으로 인해 RGB 계약의 최신 상태는 자손이 없는 방향성 비순환 그래프의 점으로 표시될 수 있습니다(각 점은 UTXO 컨테이너에 저장된 상태를 나타냅니다). 또한 아래 그림의 소유자 P의 경우 계약의 초기 상태 G에서 자신에게 도달하는 프로세스, 즉 빨간색 원으로 표시된 프로세스만 알 수 있으며 회색 점에 대해서는 아무것도 알 수 없습니다.
RGB의 장점
멋진 검증 가능한 상태
위에서 언급한 바와 같이, 비트코인에 등장한 이전 자산 발행 프로토콜(오프체인 계약 시스템)에 비해 RGB는 검증(계약의 특정 상태) 비용을 크게 줄입니다. 거래 중에 수신자는 더 이상 계약 상태 변경에 대한 정보를 수집하기 위해 모든 블록을 탐색할 필요가 없으며 일련의 비트코인 거래와 이러한 거래소에서 약속한 RGB 거래 및 이러한 비트코인의 블록만 획득하면 됩니다. 거래에 증거(블록 헤더의 Merkle 증거를 기반으로 함)가 포함되어 있으면 지불인이 특정 자산의 특정 금액을 실제로 소유하고 있음을 확신할 수 있습니다.
이러한 검증 비용 절감은 또한 대규모 인프라 제공업체에 대한 사용자의 의존도(신뢰)를 크게 감소시킵니다. 이전 프로토콜에서는 높은 검증 비용으로 인해 사용자가 직접 계약의 최신 상태를 계산하기 어려웠으므로 사용자는 일부 공급자(예: 자신의 지갑에서 사용하는 계약 상태 공급자)를 신뢰해야 했습니다. 동시에 비용을 계산할 공급업체가 적기 때문에 공급업체가 중앙 집중화된다는 뜻이기도 합니다. 그러나 RGB에서는 사용자가 비트코인 라이트 클라이언트를 사용하여 비트코인과의 거래 부분을 확인하고 RGB 프로토콜을 사용하여 RGB 거래 부분을 확인하기만 하면 되며 이를 감당할 수 있습니다.
일부 온체인 계약 시스템에 비해 RGB도 더 가볍습니다. 이는 RGB가 계약의 특정 상태를 구체적으로 확인할 수 있다는 사실에 반영됩니다. UTXO를 기반으로 하지 않는 시스템에서는 UTXO와 같은 액세스를 제어하는 메커니즘이 없기 때문에 모든 거래가 모든 상태를 변경할 수 있습니다. 특정 상태를 구체적으로 검증하는 것은 거의 불가능하지만, 최신 상태를 모두 계산하면서 특정 상태를 판별하는 것 밖에는 불가능하다. 이런 의미에서 글로벌 상태로 표현되는 특성을 실제로는 균일 상태라고 해야 한다. 계약 간 교차 접근 기능을 제공하지만, 검증 비용이 더 높고 무신뢰를 얻기가 더 어려울 것이라고 판단합니다.
이러한 온체인 계약 프로토콜에 대한 주요 최적화 조치는 블록 헤더가 최신 상태(상태 루트)를 커밋하도록 요구하여 라이트 클라이언트가 이러한 커밋을 기반으로 전체 노드에서 얻은 계약의 특정 상태를 확인할 수 있도록 하는 것입니다. . 이는 이미 발생한 계산(풀노드에서 실행한 계산)을 재사용하는 방식으로 효율성도 매우 높기 때문에 무신뢰성을 고려하지 않는다면 RGB보다 효율적이라고 볼 수 있다. 그러나 이는 결국 라이트 노드가 기본적인 거래 확인 및 계약 상태 계산을 위해 풀 노드에 의존한다는 것을 의미합니다. 비트코인 라이트 클라이언트를 사용하는 RGB 지갑에서 신뢰 가정은 해당 비트코인 거래가 유효한 거래이고, 계약 상태와 관련된 부분은 클라이언트가 직접 검증했기 때문에 더욱 신뢰가 갑니다. 무료. . 단점은 검증 지연이 길고 더 많은 데이터를 보관해야 한다는 것입니다.
확장성
RGB의 확장성은 두 가지 측면에 반영됩니다.
1. 비트코인 거래에는 해시값만 내장되어 있습니다. 즉, 하나의 RGB 자산을 100개 부분(RGB)으로 나누어도 RGB 거래량에 제한이 없음을 의미합니다(계약의 맞춤 규칙 제외). 거래 자체는 매우 클 것입니다) 그리고 비트코인 거래에 포함되어야 하는 해시는 단 하나뿐입니다. 참고 6에서 언급했듯이 이러한 해시 값을 삽입하는 방법에는 두 가지가 있습니다. 하나는 OP_RETURN 출력을 사용하는 것인데, 이는 해시 값의 온체인 공간을 소비한다는 것을 의미하며, 다른 하나는 스크립트 공개 키 출력을 숨기는 것입니다. Taproot 커밋된 스크립트 트리에서 - 이는 온체인 공간을 소비하지 않습니다. 이는 또한 사용자가 프로그래밍 가능성을 위해 경제성을 희생할 필요가 없다는 것을 의미합니다. 온체인 수수료만 고려하면 됩니다.
2. RGB 계약의 최신 상태는 자손이 없는 방향성 비순환 그래프의 독립적인 지점입니다. 즉, 이러한 상태는 서로 영향을 주지 않고 독립적으로 변경될 수 있으며 동시성이 허용된다는 의미입니다. 이는 실제로 UTXO에서 상속된 기능입니다. 이는 한 브랜치에서 발생한 잘못된 변경(잘못된 트랜잭션)이 다른 브랜치에 영향을 미치지 않을 뿐 아니라 전체 계약이 중단되는 원인이 된다는 의미이기도 하므로 보안상의 이점으로도 볼 수 있습니다.
RGB의 확장성에 대해 비판을 받아온 한 가지 점은 각 전송마다 수신자가 초기 상태에서 지불자 상태까지 관련된 모든 거래를 확인해야 한다는 점입니다. 자산이 바뀌는 횟수가 늘어날수록 후속 수신자의 확인 부담이 커집니다. 점점 더 무거워질 것입니다. 이 비판은 사실이다. 그리고 이를 최적화한다는 것은 이미 발생한 작업을 재사용할 수 있는 방법도 찾아야 함을 의미합니다. SNARK와 같은 증명 시스템 기술은 이러한 솔루션을 제공할 것을 약속합니다.
자산 정의 및 관세 신고 메커니즘의 차별화
마지막 이점은 여전히 UTXO와 관련되어 있으며 UTXO의 잠금 스크립트 메커니즘을 어떻게 이해하는지에 따라 달라집니다.
잠금 스크립트를 사용하여 펀드의 잠금 해제 조건을 프로그래밍할 수 있으므로 보관 규칙을 구현할 수 있습니다. 예를 들어, 잠금 스크립트에 공개 키가 하나만 포함되어 있으면 해당 개인 키의 소유자만 이를 제어할 수 있다는 의미입니다. 그러나 이러한 보관 규칙은 비트코인 계약 프로토콜 프로그래밍의 기초이기도 합니다. 예를 들어 2/2 다중 서명 잠금 스크립트를 사용하는 UTXO는 라이트닝 채널이 될 수 있으며, 채널이 작동하는 동안 두 당사자는 온체인 형태의 변경 없이 거의 셀 수 없이 서로 지불할 수 있습니다. 자금. 즉, 이때 2/2 다중 서명 잠금 스크립트는 체인의 자금 형태를 변경하지 않고 양 당사자가 가치를 전송할 수 있는 가치 전송 메커니즘을 구성합니다.
이러한 메커니즘은 UTXO가 보유하는 비트코인 가치에 사용될 수 있으며, 당연히 UTXO가 보유하는 RGB 자산에도 사용될 수 있습니다. RGB 자산을 발행하고 이를 2/2 다중 서명 UTXO에 첨부함으로써 라이트닝 채널 메커니즘을 사용하여 이 자산을 서로 무제한으로 지불할 수 있습니다. 같은 방식으로 RGB 자산은 비트코인 스크립트를 기반으로 하는 다른 계약에 입력될 수도 있습니다.
여기서 UTXO 스크립트와 RGB 프로토콜은 기능적 차별화를 형성합니다. 전자는 가치 보관 및 가치 이전 규칙을 실현하는 데 전념하고 후자는 자산 정의에 중점을 둡니다. 따라서 자산의 보관과 자산의 정의는 분리될 수 있습니다. 이는 중요한 보안 개선이며 사람들이 다른 온체인 계약 시스템에서 추구하는 것입니다.
이미 RGB로 제작된 디자인
위의 특성은 실제로 UTXO 일회성 봉인 및 클라이언트 검증을 기반으로 하는 모든 프로토콜에 적용됩니다. 그러나 이를 기반으로 RGB 프로토콜이 더욱 설계되었습니다.
현재 RGB 프로토콜 개발에서 개발자는 특히 프로토콜의 개인 정보 보호에 대해 우려하고 있으므로 RGB는 두 가지 측면에서 개인 정보 보호를 강화합니다.
블라인드 UTXO. RGB 거래에서 수신자는 실제로 자산을 수신한 UTXO의 특성을 노출하지 않고 자산을 수신하기 위해 난독화된 UTXO 식별자만 사용하면 됩니다. 이는 다음 소유자에게 증거를 제공하는 수취인의 능력을 손상시키지 않는 동시에 후속 자산 수취인이 이전 자산 소유자의 감시로부터 자신을 방어할 수 있게 해줍니다.
방탄. 각 거래에서 특정 금액을 숨기는 데 사용할 수 있습니다. 그러나 후속 자산 소유자는 이전에 추가 발행이 발생하지 않았는지 계속 확인할 수 있습니다.
탐색할 수 있는 공간
이 섹션에서는 주로 프로그래밍 가능성과 관련하여 RGB 프로토콜이 계속 탐색할 수 있는 영역에 대해 논의하겠습니다.
현재 제안된 RGB 계약 템플릿(스키마)은 자산 발행에 중점을 두고 있습니다. 그러나 RGB는 클라이언트 측 유효성 검사 패러다임을 사용하므로 클라이언트 측 유효성 검사를 통해 보장할 수 있는 모든 기능을 실제로 추가할 수 있습니다. 이는 UTXO 구조에 의해서만 제한됩니다.
제한
UTXO를 기반으로 프로그래밍 가능성을 넓힐 수 있는 개념을 언약(Covenants)이라고 합니다. 제한 조항의 원래 의도는 일정 금액이 이체될 수 있는 목적지를 제한하는 것입니다. 이 기능을 사용하면 다음과 같은 많은 흥미로운 응용 프로그램을 프로그래밍할 수 있습니다.
비대화형 인출을 위한 자금 풀. 우리는 동일한 UTXO에 많은 사람들의 자금을 모으고 제한 조항을 사용하여 그들 중 누구라도 다른 사람의 도움 없이 자신의 자금을 인출할 수 있도록 보장할 수 있습니다. 이는 블록 공간에 대한 수요가 높을 때 사람들이 고위험 장소를 저렴한 비용으로 빠져나갈 수 있도록 돕는 효과를 가질 수 있습니다.
금고 계약. 자금은 먼저 어딘가에서 사용되어야 하며 자유롭게 사용되기 전에 타임 잠금을 거쳐야 하며, 타임 잠금 기간 동안 금고 소유자는 비상 키를 사용하여 이 프로세스를 중단하고 즉시 자금을 다른 장소로 이체할 수 있습니다. 이 장치는 자율 구금에 큰 도움이 될 수 있습니다.
현재 비트코인 스크립트에는 이 기능이 없으므로 비트코인 스크립트에 대한 제한을 활성화하려면 소프트 포크가 필요합니다.
그러나 자산 정의 및 보관 메커니즘의 차별화가 가져오는 이점 중 일부를 기꺼이 희생할 의향이 있는 한 RGB 자산에 대해 이러한 기능을 실험할 수 있으며 RGB 계약 수준에서 이러한 기능을 구현할 수 있습니다. 비트코인이 아닌 이를 사용하는 RGB 자산에는 작동하지 않지만 확실히 흥미로운 공간을 열어줄 것입니다.
제한 조항에 대한 기존 연구에서는 UTXO 기반 트랜잭션의 프로그래밍 공간을 넓히고 많은 기능을 제공할 수 있음을 보여줍니다. 그러나 이러한 연구는 기본적으로 비트코인을 기반으로 하며, 비트코인과 같은 프로토콜에서는 보다 보수적일 것입니다. RGB에서는 제한 조항의 핵심 기능(스크립트 수준에서 소비되는 트랜잭션을 읽는 기능)을 대담하게 일반화하여 보다 유연한 프로그래밍 가능성, 즉 교차 액세스 계약 기능을 제공할 수 있습니다.
교차 접근
최소한으로 제한적인 용어는 UTXO가 소비될 때 해당 스크립트가 지출 거래의 출력을 읽을 수 있음을 의미합니다. 그러나 완전히 일반화된 제약조건은 이를 소비한 트랜잭션의 모든 부분을 읽을 수 있음을 의미합니다. 이는 트랜잭션의 다른 입력도 읽을 수 있다는 의미이며, 동일한 계약에서 다른 입력이 나오도록 제한하지 않으면 다른 계약의 상태도 읽을 수 있다는 의미입니다.
RGB에서는 기본적으로 각 계약이 고유한 방향성 비순환 그래프가 있는 독립적인 우주입니다. 그러나 사용자가 동시에 두 가지 다른 계약 상태를 보유하는 것은 여전히 가능합니다. RGB 트랜잭션을 통해 두 계약의 자산을 동시에 지출할 수 있다면 이러한 교차 액세스 기능에 응용 프로그램이 있을 수 있습니다(아마도 트랜잭션 확인이 더 복잡해질 수 있음).
실제로 UTXO 유사한 구조(예: Nervos 네트워크)를 기반으로 하는 온체인 계약 시스템이 이미 있으며, 이를 사용하여 계약의 교차 액세스 기능을 달성합니다11. 이는 이전 비트코인 연구에서는 거의 다루지 않은 영역으로 열리는 매우 새로운 분야이며, 거기에는 몇 가지 놀라움이 묻혀 있을 수 있습니다.
결론적으로
이 글에서 독자들은 추론과 환상의 모든 과정에서 자주 언급되고 사용되는 개념이 있다는 것을 알게 될 것이다. 바로 UTXO이다. 이것이 바로 내 의도이다. UTXO를 이해하지 못하면 RGB와 같은 프로토콜 설계의 출발점을 이해할 수 없고, RGB 프로토콜 설계의 장점을 이해할 수 없으며, 사람들이 이를 사용하는 방식을 상상할 수도 없습니다. RGB 프로토콜의 특성은 UTXO의 일회성 봉인 형태에 의해 크게 형성됩니다. 이에 따라 비트코인 연구 분야에서 축적된 UTXO에 대한 연구는 RGB 연구에도 적용될 수 있다.
이는 또한 비트코인을 이해하지 못하는 사람들이 RGB를 이해하는 데 어려움을 겪는 이유를 설명합니다. 비트코인을 좋아하는 사람들은 RGB가 만든 디자인을 알아볼 것입니다.


