비트코인 자산 발행 프로토콜 RGB의 진정한 잠재력은 어디에 있을까요?

저자: 아젠, 우설 블록체인

본 문서는 비트코인에서 자산 발행 프로토콜 RGB에 대한 간결한 설명을 제공하려고 시도하며(이를 체인 외 스마트 계약 시스템으로 이해할 수도 있습니다), 다른 유사한 기능을 구현하려는 프로토콜과의 차별점을 지적합니다. 이러한 차별점은 RGB 프로토콜의 확장성이 이들보다 훨씬 뛰어나게 하며, 더 넓은 프로그래밍 공간을 남겨둡니다. RGB의 이미 완료된 설계를 소개하는 것 외에도, 우리는 이러한 프로그래밍 가능성에 대해서도 탐구할 것입니다.

RGB 프로토콜이란 무엇인가?

비트코인에서 자산을 발행하는 아이디어는 오래전부터 존재해왔습니다. 그러나 비트코인 프로토콜은 고유한 특성을 가지고 있습니다: 그 상태는 오직 비트코인 UTXO("사용되지 않은 거래 출력")에 의해 표현됩니다; 하나의 UTXO는 두 가지 데이터만을 포함합니다: 그것의 자체 액면가(비트코인 가치)와 "스크립트 공개키"(또는 "잠금 스크립트")로, 이 자금의 사용 조건을 프로그래밍하는 데 사용됩니다. 예를 들어, 특정 공개키의 서명을 제공하는 것입니다. 잠금 스크립트를 프로그래밍하는 데 사용되는 연산 코드는 비트코인의 합의 규칙에 의해 제공되며, 임의의 보안 규칙을 구현하는 데 사용할 수 없습니다. 따라서 우리는 UTXO 내부에서 다른 자산을 생성할 수 없습니다 ------ 비트코인 스크립트는 이러한 자산의 보안 검사를 프로그래밍할 수 없습니다. 이는 비트코인에서 자산을 발행하는 모든 아이디어가 본질적으로 비트코인 블록 공간의 창의적 사용이라는 것을 의미합니다. 이는 우리가 체인 외 스마트 계약 시스템을 설계해야 하며, 계약 상태를 변경하는 단계 ------ 예를 들어, 계약 A가 매개변수를 변경하고 B가 특정 수량의 자산을 C에게 이전하는 ------ 정보를 블록체인에 업로드해야 함을 의미합니다. 이렇게 하면 이러한 정보를 수집하여 이 스마트 계약 시스템의 최신 상태를 얻을 수 있습니다.

하나의 대략적인 설계 아이디어는 계약 상태를 변경하는 단계의 정보를 원본 그대로 비트코인 블록체인에 업로드하는 것입니다. 이는 물론 작동할 수 있지만, 몇 가지 문제에 직면할 수 있습니다: (1) 전체 정보를 업로드했기 때문에 블록 공간을 많이 소모할 수 있으며, 사용자가 계약 상태를 변경해야 할 때(예: 송금) 더 많은 온체인 수수료를 지불해야 합니다. 특히, 우리가 이러한 체인 외 계약 시스템이 비트코인보다 더 나은 프로그래밍 가능성을 갖기를 원할 때, 프로그래밍 가능성의 증가는 더 많은 블록 공간을 소모하는 대가를 치를 수 있습니다; (2) 블록 내의 거의 모든 정보는 체인 외 스마트 계약을 변경할 수 있으므로, 사용자는 이 체인 외 계약 시스템의 최신 상태를 도출하기 위해 모든 비트코인 블록 데이터를 확보해야 하며, 즉 검증 비용이 더 높습니다; (3) 체인 외 스마트 계약 시스템의 설계에 따라, 비트코인과 유사한 수준의 프라이버시만을 얻을 수 있거나, 심지어 더 나쁜 프라이버시를 가질 수 있습니다; 만약 더 많은 프라이버시를 제공할 수 있다면, 더 많은 블록 공간을 소모해야 할 수도 있습니다.

과거에 사용량이 많았던 프로토콜인 "Omni"는 체인 외 계약 거래의 전체 정보를 업로드하지 않고 거래의 해시 값만 업로드합니다. 이러한 접근 방식은 위의 문제 1을 해결하여 체인 외 계약 거래의 복잡성과 경제적 비용을 분리했습니다; 그러나 사용자는 여전히 Omni 프로토콜의 최신 상태를 도출하기 위해 전체 비트코인 블록 데이터를 확보해야 하며, 또한 프라이버시를 특별히 강화하지도 않았습니다.

반면 RGB는 "일회성 봉인(single-use seals)"이라는 새로운 패러다임을 사용합니다. 그 사용법은 간단합니다: RGB는 각 계약의 각 상태가 특정 비트코인 UTXO에 부착되어야 한다고 요구합니다; 그리고 이 상태를 변경하려면 이 UTXO를 사용해야 하며, 이를 사용하는 거래가 블록체인에서 확인을 받아야 합니다; 또한, 이를 사용하는 비트코인 거래는 상태 전환 내용의 해시 값을 제공해야 하며, 이는 변경된 상태가 부착된 UTXO를 지정합니다.

RGB 개발자들은 이러한 설계가 번호가 매겨진 플라스틱 봉인과 유사하다고 생각합니다: 그것이 한 번 열렸는지 쉽게 알 수 있으며, 한 번 열리면 다시 사용할 수 없습니다. 그러나 다른 관점에서 보면, 부착된 UTXO를 이 상태의 용기 또는 도자기 저금통으로 간주할 수 있습니다 ------ 저금통의 돈을 꺼내려면 이 저금통을 깨야 하며, 그 안의 돈을 새로운 통으로 옮겨야 합니다.

이러한 설계는 이전의 전체 블록을 큰 쓰기판으로 간주하는 프로토콜과 뚜렷한 대조를 이룹니다: UTXO를 용기로 사용하면, 이 UTXO를 사용하지 않는 거래는 용기 내부의 계약 상태에 영향을 미치지 않으므로, 특정 계약의 특정 상태를 검증하기 위해 전체 블록 데이터를 확보할 필요가 없습니다. 우리가 필요한 것은 일련의 비트코인 거래, 이러한 비트코인 거래가 특정 블록에 존재하는 증거, 그리고 이러한 비트코인 거래가 약속한 RGB 상태 전환(관련 비트코인 거래와 일대일 대응)입니다. 이러한 데이터를 연결하여 우리는 이 계약의 초기 상태로 거슬러 올라갈 수 있으며, 이 상태의 본질을 식별할 수 있습니다.

체인 상 스마트 계약 시스템(예: 이더리움)에 익숙한 독자에게 이 과정이 이해하기 어려운 한 가지 이유는: 블록체인의 합의에 의존하지 않는 경우(이는 계약의 초기 상태와 매번 상태 변경이 모든 노드에 의해 검증됨을 의미함), 이러한 스마트 계약 시스템의 안전성은 어떻게 보장되는가? 자신이 받은 자산이 자신이 원하는 종류인지, 자산이 불법적으로 증가하지 않았는지 어떻게 보장하는가?

답은 간단합니다. "클라이언트 검증(client-side validation)"이라고 불립니다 ------ 자신이 검증하는 것입니다. 체인 상 계약 시스템에서 노드는 공개된 상태 전환 규칙에 따라 각 상태 전환 작업을 검증하고 무효 작업을 거부하여 초기 상태를 바탕으로 최신 상태를 계산합니다. 그러나 상태 전환 규칙과 초기 상태가 알려져 있다면, 블록체인 합의를 통해 검증하는 것이 유일한 방법은 아닙니다. 사용자는 지불자가 제공한 자료를 바탕으로 상태 전환의 각 단계가 최초 정의된 상태 전환 규칙을 준수하는지 스스로 검증할 수 있습니다. 이러한 방법을 통해 검증하는 쪽(자산 수신자라고 가정)은 불법적인 상태 전환을 발견하고 수용을 거부할 수 있습니다.

마지막으로, RGB 프로토콜의 특징을 보여주는 예를 들어보겠습니다:

현재, 앨리스는 UTXO A'를 소유하고 있으며, 이는 RGB 프로토콜에 따라 발행된 X 단위의 자산 Y를 보유하고 있습니다. 그녀는 Z 단위의 Y를 밥에게 이전하고 싶어합니다. 이 자산은 총 5명의 이전 소유자(자산 발행자를 포함하여)를 거쳐 앨리스에게 도달했습니다. 따라서 앨리스는 밥에게 이 4회의 상태 전환에 대한 증거를 제공해야 합니다(이 중 앞의 3회의 증거는 이전 소유자가 앨리스에게 제공한 것입니다), 초기 계약 상태와 상태 전환 규칙, 각 이전에 사용된 비트코인 거래, 각 비트코인 거래가 약속한 RGB 거래, 이러한 비트코인 거래가 특정 블록에서 확인된 증거를 함께 밥에게 전송합니다. 밥은 계약의 상태 전환 규칙에 따라 이 4회의 이전이 규칙을 위반하지 않았는지 검증한 후 수용 여부를 결정합니다. 앨리스가 RGB 거래를 구성할 때, Z가 X보다 작기 때문에 그녀는 남은 부분을 수령할 UTXO를 마련해야 합니다. 마지막으로, 앨리스는 이 RGB 거래의 해시 값을 UTXO A'를 사용하는 비트코인 거래에 삽입하여 이 결제를 완료합니다.

결국, UTXO 용기를 사용함으로써 RGB 계약의 최신 상태는 후손이 없는 방향성 비순환 그래프의 점으로 표현될 수 있습니다(각 점은 UTXO 용기 내에 저장된 상태를 나타냅니다). 그리고 아래 그림의 소유자 P에게는, 그는 계약의 초기 상태 G에서 자신의 상태에 도달하는 과정만 알게 되며, 즉 빨간 원으로 표시된 과정만 알게 되고, 회색 점에 대해서는 전혀 알지 못합니다:

RGB의 장점

검증 가능한 상태의 청량감

앞서 언급했듯이, 이전에 비트코인에서 나타난 자산 발행 프로토콜(체인 외 계약 시스템)과 비교할 때, RGB는 검증(특정 계약의 특정 상태)의 비용을 크게 줄였습니다. 거래 시, 수신자는 계약 상태가 변경된 정보를 수집하기 위해 모든 블록을 탐색할 필요가 없으며, 일련의 비트코인 거래와 이러한 거래가 약속한 RGB 거래, 그리고 이러한 비트코인 거래의 블록 포함 증거(블록 헤더의 머클 증거)를 확보하기만 하면 지불자가 실제로 특정 수량의 자산을 보유하고 있음을 확신할 수 있습니다.

이러한 검증 비용의 감소는 사용자들이 대규모 인프라 공급자에 대한 의존도(신뢰)를 크게 줄입니다. 이전 프로토콜에서는 검증 비용이 높아 사용자가 계약의 최신 상태를 스스로 계산하기 어려웠기 때문에, 사용자는 일부 공급자(예: 자신의 지갑이 사용하는 계약 상태 공급자)를 신뢰해야 했습니다; 또한, 이러한 계산 비용을 감당할 수 있는 공급자가 적기 때문에 공급자의 중앙화도 의미합니다. 그러나 RGB에서는 사용자가 비트코인 경량 클라이언트를 사용하여 비트코인 거래의 일부를 확인하고, RGB 프로토콜을 사용하여 RGB 거래의 일부를 확인함으로써 스스로 부담할 수 있습니다.

일부 체인 상 계약 시스템과 비교할 때, RGB는 또한 더 경량화된 것으로 보입니다. 이는 RGB가 특정 계약의 특정 상태를 검증할 수 있다는 점에서 나타납니다; 반면 UTXO에 기반하지 않은 시스템에서는 UTXO와 같은 접근 제어 메커니즘이 부족하기 때문에 임의의 거래가 임의의 상태를 변경할 수 있습니다. 따라서 특정 상태를 검증하는 것은 거의 불가능하며, 모든 최신 상태를 계산하는 동시에 특정 상태를 확인해야 합니다 ------ 이러한 의미에서 "전역 상태(global state)"라는 특성은 사실상 "통합 상태(uniform state)"라고 불려야 하며, 이는 계약 간의 교차 접근 특성을 제공하지만, 검증 비용이 더 높고 신뢰 없는 상태를 얻기 더 어렵다는 것을 의미합니다.

이러한 체인 상 계약 프로토콜에서 중요한 최적화 조치는 블록 헤더가 최신 상태("상태 루트")를 약속하도록 요구하여 경량 클라이언트가 이러한 약속을 바탕으로 전체 노드에서 특정 계약의 특정 상태를 검증할 수 있도록 하는 것입니다. 이는 이미 발생한 계산(전체 노드가 이미 수행한 계산)을 재사용하는 방법이며, 매우 효율적입니다. 따라서 신뢰 없는 상태를 고려하지 않는다면, RGB보다 더 효율적이라고 볼 수 있습니다. 그러나 이는 결국 경량 노드가 거래 기본 검증 및 계약 상태 계산에서 전체 노드에 의존한다는 것을 의미합니다. 반면 비트코인 경량 클라이언트를 사용하는 RGB 지갑에서는 신뢰 가정이 관련 비트코인 거래가 유효 거래라는 것이며, 계약 상태와 관련된 부분은 클라이언트가 직접 검증한 것입니다. 따라서 신뢰 없는 상태가 더 좋습니다. 단점은 검증 지연이 더 길고, 보관해야 할 데이터가 더 많다는 것입니다.

확장성

RGB의 확장성은 두 가지 측면에서 나타납니다:

1. 비트코인 거래에 삽입되는 것은 단지 해시 값 하나뿐입니다. 이는 RGB 거래의 크기(계약 사용자 정의 규칙 외에는) 제한이 없음을 의미합니다 ------ 심지어 RGB 자산을 100개로 나누더라도(RGB 거래 자체는 매우 클 것입니다), 비트코인 거래에 삽입해야 하는 것은 단지 해시 값 하나뿐입니다. 주석 6에서 언급했듯이, 이러한 해시 값을 삽입하는 방법은 두 가지가 있습니다: 하나는 OP_RETURN 출력을 사용하는 것이며, 이는 해시 값 하나의 온체인 공간을 소모합니다; 다른 하나는 Taproot 출력의 스크립트 공개키가 약속하는 스크립트 트리 내에 숨기는 것입니다 ------ 이는 온체인 공간을 소모하지 않습니다. 이는 또한 사용자가 프로그래밍 가능성을 위해 경제성을 희생할 필요가 없음을 의미합니다 ------ 온체인 수수료만 고려할 경우.

2. RGB 계약의 최신 상태는 후손이 없는 독립적인 점으로서 방향성 비순환 그래프에 있습니다 ------ 이는 이러한 상태가 독립적으로 변경될 수 있으며 서로 영향을 미치지 않음을 의미하며, 즉 병렬 처리를 허용합니다. 이는 사실상 UTXO에서 상속된 특성이기도 합니다. 이는 또한 한 분기에서 발생한 무효 변경(무효 거래)이 다른 분기에 영향을 미치지 않으며, 전체 계약이 멈추는 것을 초래하지 않기 때문에 안전성의 이점으로 간주될 수 있습니다.

RGB의 확장성에 대한 비판 중 하나는: 각 이전마다 수신자가 초기 상태에서 지불자 상태까지 관련된 모든 거래를 검증해야 한다는 것입니다 ------ 자산이 여러 번 이전될수록 후속 수신자의 검증 부담이 점점 더 커질 것입니다. 이 비판은 사실입니다. 이를 최적화하려면 이미 발생한 계산을 재사용하는 방법을 찾아야 합니다. 증명 시스템 기술(예: SNARKs)은 이러한 해결책을 제공할 가능성이 있습니다.

자산 정의와 보관 메커니즘의 분화

마지막 장점은 여전히 UTXO와 관련이 있으며, 우리가 UTXO의 잠금 스크립트 메커니즘을 어떻게 이해하느냐에 따라 달라집니다.

잠금 스크립트는 자금의 잠금 조건을 프로그래밍하는 데 사용될 수 있으므로, 보관 규칙을 구현할 수 있습니다. 예를 들어, 잠금 스크립트가 오직 하나의 공개키만 포함하고 있다면, 이는 해당 개인키의 소유자만이 이를 제어할 수 있음을 의미합니다. 그러나 이러한 보관 규칙은 비트코인 계약식 프로토콜 프로그래밍의 기초이기도 합니다. 예를 들어, 2-of-2 다중 서명 잠금 스크립트를 사용하는 UTXO는 하나의 라이트닝 채널이 될 수 있습니다; 채널이 작동하는 동안 양측은 거의 무수히 많은 상호 지불을 할 수 있으며, 자금의 온체인 형태는 변하지 않습니다. 다시 말해, 이 시점에서 2-of-2 다중 서명 잠금 스크립트는 자산의 온체인 형태를 변경하지 않고 가치를 이전할 수 있는 메커니즘을 구성합니다.

이러한 메커니즘은 UTXO가 담고 있는 비트코인 가치에 적용될 수 있으며, 자연스럽게 RGB 자산에도 적용될 수 있습니다. 우리는 RGB 자산을 발행하여 이를 2-of-2 다중 서명 UTXO에 부착함으로써 라이트닝 채널 메커니즘을 활용하여 양측 간에 무한히 상호 지불할 수 있습니다. 마찬가지로, RGB 자산은 비트코인 스크립트 기반의 다른 계약에도 포함될 수 있습니다.

여기서 UTXO의 스크립트와 RGB 프로토콜은 기능적으로 분화됩니다: 전자는 가치 보관 및 가치 이전 규칙을 구현하는 데 중점을 두고; 후자는 자산 정의에 집중합니다. 따라서 자산의 보관과 자산의 정의를 분리할 수 있습니다. 이는 중요한 안전성 향상이며, 다른 체인 상 계약 시스템에서 사람들이 추구하는 것입니다.

RGB가 이미 수행한 설계

위의 특성은 사실상 UTXO 일회성 봉인 및 클라이언트 검증에 기반한 모든 프로토콜에 적용됩니다. 그러나 이러한 기반 위에서 RGB 프로토콜은 추가적인 설계를 수행했습니다.

현재 RGB 프로토콜 개발에서 개발자들은 특히 프로토콜의 프라이버시를 강화하는 데 주목하고 있으며, 따라서 RGB는 두 가지 측면에서 프라이버시를 강화했습니다:

• 블라인드 UTXO. RGB 거래에서 수신자는 혼합된 UTXO 식별자만 사용하여 자산을 수령할 수 있으며, 실제 자산을 수령하는 UTXO의 특성을 노출할 필요가 없습니다. 이는 수신자가 다음 소유자에게 증거를 제공하는 능력에 전혀 손상을 주지 않으며, 후속 자산 수신자가 이전 자산 소유자의 엿보기에 저항할 수 있도록 합니다.

• 불렛프루프. 각 거래의 구체적인 금액을 숨기는 데 사용할 수 있습니다. 그러나 후속 자산 소유자는 여전히 이전에 발생한 증가가 없었음을 검증할 수 있습니다.

탐색 가능한 공간

이 부분에서는 RGB 프로토콜이 계속 탐색할 수 있는 공간에 대해 논의할 것이며, 주로 프로그래밍 가능성과 관련이 있습니다.

현재 제안된 RGB 계약 템플릿(schema)은 자산 발행에 집중되어 있습니다. 그러나 RGB가 "클라이언트 검증" 패러다임을 사용하기 때문에, 사실상 우리는 클라이언트 검증을 통해 보장할 수 있는 모든 특성을 추가할 수 있습니다 ------ 오직 UTXO 구조에 의해 제한됩니다.

제한 조항

UTXO 기반에서 프로그래밍 가능성을 확장할 수 있는 개념은 "제한 조항(covenants)"입니다. 제한 조항의 본래 의미는 자금이 전송될 수 있는 목적지를 제한하는 것입니다. 이러한 능력을 통해 우리는 흥미로운 응용 프로그램을 프로그래밍할 수 있습니다. 예를 들어:

• 비상호작용 인출의 자금 풀. 우리는 여러 사람의 자금을 동일한 UTXO에 모으고, 제한 조항을 사용하여 그들 중 누구도 다른 사람의 도움 없이 자신의 자금을 인출할 수 있도록 보장할 수 있습니다. 이는 블록 공간 수요가 급증할 때 사람들이 고위험 지역에서 저비용으로 탈출할 수 있도록 도와주는 역할을 할 수 있습니다.

• 금고 계약. 자금이 특정 장소로 먼저 사용되어야 하며, 일정 시간 잠금이 지나야 자유롭게 사용할 수 있도록 합니다; 그리고 시간 잠금 기간 동안 금고 소유자는 긴급 키를 사용하여 이 과정을 중단하고 자금을 즉시 다른 곳으로 이전할 수 있습니다. 이러한 장치는 자율 보관에 큰 도움이 될 수 있습니다.

현재 비트코인 스크립트는 이러한 능력이 없으므로, 비트코인 스크립트에서 제한 조항을 활성화하려면 소프트 포크가 필요합니다.

그러나 우리가 "자산 정의와 보관 메커니즘의 분화"에서 오는 일부 이점을 희생할 의향이 있다면, RGB 자산에서 이러한 특성을 실험할 수 있습니다. 우리는 RGB 계약 레이어에서 이러한 기능을 구현할 수 있습니다 ------ 비록 그것이 사용하는 RGB 자산에만 적용되지만(비트코인에는 적용되지 않음), 분명히 흥미로운 공간을 열 것입니다.

기존의 제한 조항 연구는 UTXO 기반 거래의 프로그래밍 공간을 확장하고 많은 특성을 제공할 수 있음을 보여줍니다. 그러나 이러한 연구는 기본적으로 비트코인을 기반으로 하며, 비트코인과 같은 프로토콜에서는 더 보수적일 수 있습니다. 그러나 RGB에서는 제한 조항의 핵심 능력 ------ 스크립트 레이어에서 자신을 사용하는 거래를 읽는 능력 ------을 더욱 일반화하여 더 유연한 프로그래밍 가능성을 제공할 수 있습니다: 계약 간의 교차 접근 능력입니다.

교차 접근

최소한의 제한 조항은 UTXO가 사용될 때, 그 스크립트가 사용 거래의 출력을 읽을 수 있게 합니다. 그러나 완전히 일반화된 제한 조항은: 그것이 자신을 사용하는 거래의 모든 부분을 읽을 수 있게 합니다. 이는 또한 거래의 다른 입력을 읽을 수 있다는 것을 의미하며, 만약 우리가 다른 입력이 반드시 동일한 계약에서 나와야 한다고 제한하지 않는다면, 이는 다른 계약의 상태를 읽을 수 있다는 것을 의미합니다.

RGB에서는 각 계약이 독립된 우주이며, 고유한 방향성 비순환 그래프를 가지고 있다고 가정합니다. 그러나 여전히 한 사용자가 두 개의 서로 다른 계약 상태를 동시에 보유하는 상황이 발생할 수 있습니다. 만약 RGB 거래가 두 종류의 계약에서 자산을 동시에 사용할 수 있도록 허용한다면, 이러한 교차 접근 능력은 응용 시나리오가 있을 수 있습니다(비록 거래 검증이 더 복잡해질 것이라고 상상할 수 있지만).

실제로 UTXO와 유사한 구조를 기반으로 한 체인 상 계약 시스템(예: Nervos Network)은 이를 사용하여 계약 간의 교차 접근 능력을 구현하고 있습니다. 이는 매우 새로운 분야로, 과거 비트코인 연구가 거의 다루지 않았던 분야로, 아마도 놀라운 것을 숨기고 있을지도 모릅니다.

결론

본 문서에서 독자는 "UTXO"라는 개념이 빈번하게 언급되고, 추론과 상상의 모든 과정에 관통하고 있음을 발견할 것입니다. 이것이 바로 제 의도입니다. 만약 당신이 UTXO를 이해하지 못한다면, RGB와 같은 프로토콜 설계의 출발점을 이해할 수 없으며, RGB 프로토콜 설계의 장점을 이해할 수 없고, 사람들이 그것을 사용하는 방식을 상상할 수 없습니다. RGB 프로토콜의 특성은 상당 부분 UTXO의 일회성 봉인 형태에 의해 형성됩니다. 따라서 비트코인 연구 분야에서 쌓인 UTXO에 대한 연구는 RGB 연구에 활용될 수 있습니다.

이는 또한 비트코인을 이해하지 못하는 사람들이 RGB를 이해하기 어려운 이유를 설명합니다. 반면 비트코인을 좋아하는 사람들은 RGB가 이미 수행한 설계를 인정할 것입니다.