BiHelix RGB V0.11 버전 전망: 자산 발행 개요

저자: Zoom, Echo, BiHelix

소개

Nervos 공동 창립자 Cipher가 RGB++라는 이름의 제안을 발표하면서, 시장에서 RGB 원주율 프로토콜에 대한 논의와 열기가 날로 증가하고 있습니다. RGB는 LNP/BP 표준 협회가 만든 확장 가능하고 비밀스러운 비트코인 및 라이트닝 네트워크 스마트 계약 시스템으로, 비트코인 생태계 개발자들에게 큰 사랑을 받고 있으며, BTC 원주율 확장 프로토콜 중 큰 잠재력을 지닌 부분으로 여겨집니다. 비트코인 탈중앙화 금융(BTCfi)과 응용 프로그램(DApps)의 기반 인프라로서, RGB는 비트코인의 유용성을 단일 가치 저장 기능에서 더 넓은 분야로 확장하는 역사적인 이정표를 나타냅니다. 이 기술 혁신은 흥미진진할 뿐만 아니라, 전체 암호화폐 생태계에 새로운 발전 방향과 가능성을 가져올 것입니다.

2023년 말, RGB 원주율 팀 LNP/BP 표준 협회는 시장의 도전에 더 잘 대응하고 비트코인 생태계의 번영을 촉진하기 위해 RGB가 곧 업그레이드되어 v0.11 버전을 출시할 것이라고 발표했습니다. 본 기사는 RGB v0.11 프로토콜 업그레이드의 기능과 기술적 기초를 자세히 설명하며, RGB v0.11이 지원하는 자산 생성 기능과 거래 기능을 포괄적으로 개요합니다. 여기에는 신뢰할 수 있는 증명 합의, 확장성 최적화 및 핵심 보안 강화가 포함됩니다. 우리는 기존 합의 프로토콜과 비교하여 신념 증명의 기본 원리와 균형, 그리고 v0.11이 해제하는 가스 절약 및 처리량 증가의 정량적 기준을 심층적으로 연구했습니다.

RGB 자산 생성

현재 RGB 프로토콜 V0.11 버전에는 RGB20(토큰), RGB21(NFT), RGB25의 세 가지 자산 유형이 내장되어 있습니다. RGB20을 예로 들어, 우리는 현재 프로토콜의 구현 단계와 실행 권리에 대해 논의합니다.

1. 먼저, 계약의 발행자는 RGB20 프로토콜에 따라 RGB 토큰의 초기 상태를 설정해야 합니다. 예를 들어, 계약의 세부 사항: 자산의 이름, 초기 발행량, 총 공급량, 증발, 이름 변경, 파괴 등의 권한을 정의합니다.
2. 다음으로 계약 발행자는 초기 발행량을 수신할 UTXO를 지정해야 하며, 이를 통해 간단한 RGB 자산을 생성할 수 있습니다. 상태 변경은 자산 소유권 변경 권리에 적용될 수 있으며, 다른 유형의 권리에 적용될 수도 있습니다. 예를 들어:

• 증발 인터페이스: 계약이 증발 권한을 열 때, 이 자산의 증발을 수신할 주소를 지정해야 합니다. 물론 RGB20은 증발의 한도를 제한하며, 계약 발행자는 무한히 증발할 수 없습니다.
• 파괴 인터페이스: 계약 발행자는 하나 이상의 개인에게 토큰의 파괴 권한을 지정할 수 있습니다. RGB20은 P2P 거래를 사용하므로(거래 부분에서 소개할 예정), 사용자가 토큰을 블랙홀 주소로 보내 파괴하기는 어렵습니다.
• 이름 변경 인터페이스: 계약은 자산 이름을 업데이트할 수 있습니다.

RGB 계약 코드는 체인 외부에 저장되므로, 계약 발행자가 오픈 소스를 허가하지 않으면 사용자가 자산 정보를 검증하기 어렵습니다. RGB 계약이 한 번 발행되면, 사용자나 발행자 모두 계약 발행 시의 상태 정의를 준수해야 하며, 발행자의 악의적인 행동을 방지해야 합니다.

RGB 자산 전송

RGB의 거래 방식은 P2P(피어 투 피어) 전송을 채택하며, 이는 ETH와 큰 차이가 있습니다. 이 전송 방식은 양측 모두 온라인 상태여야 하며, 예를 들어 "A가 B에게 100 토큰을 보내고자 할 때"의 절차는 다음과 같습니다:

1. B는 100 토큰을 보내기 위해 송장을 생성합니다.
2. 수신자 A가 전송을 요청합니다.
3. B는 전송을 확인하고 서명합니다.
4. A는 거래를 방송합니다.
5. A와 B는 거래를 수락합니다.

이 과정에서 B는 이 송장을 A에게 보내고, A는 송장을 받은 후 송장 내용에 따라 100 토큰을 B에게 보내야 합니다. B는 100 토큰을 수신했음을 확인해야 성공으로 간주됩니다.

• Q: 왜 양측 모두 온라인이어야 하나요?
• A: 송장은 유효 기간이 있기 때문에, 일정 시간 동안 사용하지 않으면 무효가 되므로 A는 B의 송장을 받은 후 즉시 전송해야 합니다. B도 송장이 A에 의해 즉시 사용될 수 있도록 보장해야 하므로 송장을 생성합니다. 이는 양측이 송장의 유효 시간 내에 전송을 완료해야 함을 제약합니다.

그림: 라이트닝 네트워크 채널 거래

RGB가 사용하는 거래 채널은 라이트닝 네트워크와 통합되어 있으므로 거래 과정은 라이트닝 네트워크의 전송 과정을 참조할 수 있으며, "수신자가 다시 확인해야 하는" 단계가 추가되었습니다. 이러한 거래 단계는 수신자가 엉뚱한 피싱 코인을 받지 않도록 하여 사용자 지갑의 안전을 보호합니다.

RGB 자산 거래

RGB 자산 전송 과정의 기술적 포인트

1. 일회성 봉인

이 기술은 2016년 Peter Todd에 의해 처음 제안되었으며, 주된 의미는 "메시지에 봉인 라벨을 추가하여 이 메시지가 한 번만 사용될 수 있도록 보장하는 것"입니다. 메시지를 알기 위해서는 봉인 라벨을 제거해야 합니다.

간단한 방법은 공증된 제3자 서비스 서버를 설정하는 것입니다. 특정 봉인 라벨이 열리거나 잠길 때마다 공개 등록소에 인증서를 게시하여 누구나 자신이 관심 있는 봉인 라벨의 상태를 검증할 수 있도록 합니다.

신뢰할 수 있는 실체를 사용하지 않고 일회성 봉인의 기능을 구현하려면 비트코인의 UTXO를 봉인 라벨로 사용할 수 있습니다. 비트코인의 모든 UTXO는 한 번만 사용될 수 있기 때문입니다. 따라서 UTXO를 봉인 라벨로 사용하면 UTXO 생성 시 잠글 수 있고, 이를 사용할 때 열 수 있습니다.

RGB는 이러한 "일회성 봉인" 기술을 활용하여 RGB 자산의 정보, 계약의 상태 등을 UTXO 안에 "포장"합니다. UTXO가 사용될 때 자산의 소유권과 계약의 상태가 변경됩니다. 이는 RGB 거래가 발생할 때마다 실제로 발신자가 특정 계약(전송 권리가 정의된 계약)에 대해 상태 변경을 생성하는 것을 의미합니다.

2. 클라이언트 검증

RGB의 검증은 전통적인 "글로벌 합의" 검증과 다르며, "클라이언트 검증" 기술을 채택합니다. 전통적인 비트코인 검증 방식에서는 네트워크에 연결된 노드가 지속적으로 블록과 거래 풀의 거래를 다운로드하고 검증합니다(전체 노드). 이러한 노드는 전체 체인에서 UTXO 집합(블록체인에서 모든 미사용 출력의 집합)에 대한 실시간 업데이트를 유지하며, 새로운 거래를 볼 때 해당 거래의 모든 입력이 최신 상태의 UTXO 집합의 일부인지 검증하기만 하면 됩니다.

하지만 RGB의 경우, 전역적으로 전파되는 데이터가 없으므로 이러한 UTXO 집합의 전역 뷰가 없습니다. RGB 클라이언트는 거래를 수락한 후 거래의 최신 상태가 유효한지 검증할 뿐만 아니라 거래와 관련된 모든 이전 상태 변환에 대해서도 동일한 검증을 수행해야 하며, 이는 계약의 초기 상태까지 거슬러 올라가야 합니다. 이는 명백한 단점을 초래할 수 있습니다: 검증 시간이 길어질 수 있습니다. 하지만 이는 "거래 이력이 긴 자산에서만 발생하며", 데이터 공유 계층(자발적인 경우)을 통해 이 부분의 거래 이력 데이터를 미리 검증할 수 있습니다.

이는 동시에 명백한 장점을 가져옵니다: 클라이언트는 전역에서 발생하는 모든 거래를 알 필요도, 검증할 필요도 없습니다. 왜냐하면 자신 지갑과 관련된 거래만 알면 되기 때문입니다. 다른 거래를 검증할 필요가 없으므로, 각 클라이언트가 검증해야 할 데이터 양이 줄어들어 시스템 확장성이 명확히 향상됩니다. 클라이언트 검증의 완전한 체인 문제는 BiHelix가 제안한 재귀적 제로 지식 증명 솔루션으로 완전히 해결됩니다.

3. 결정론적 비트코인 약속

RGB는 "이중 지불"을 방지하기 위해 RGB 약속을 통해 이를 구현합니다. 이러한 약속은 다음을 필요로 합니다:

• 계약과 관련된 여러 상태 변환이 단일 비트코인 거래에 약속될 수 있어야 합니다.
• 각 계약의 상태 변환은 비트코인 거래에 한 번만 약속될 수 있습니다.

구현의 구체적인 방법은 다음과 같습니다:

1. 먼저, 특정 계약(또는 자산 ID)과 관련된 모든 상태 변환을 결정론적으로 집계하여 하나의 약속으로 만듭니다.
2. 그런 다음, 전송된 모든 자산의 약속을 집계하여 머클 트리를 만듭니다.
3. 최종 루트 해시 값이 최종 RGB 약속이 됩니다.
4. 다른 RGB와 관련이 없지만 동일하게 결정론적 비트코인 약속을 사용하는 프로토콜과의 호환성을 보장하기 위해, RGB 약속과 다른 프로토콜의 약속을 다시 집계해야 합니다(예: LNPBP-4 표준에 설명된 대로). 이렇게 얻어진 해시 값이 실제로 비트코인 거래에 삽입된 메시지가 됩니다.
5. 배치 처리로 비용 절감

이전 섹션에서 알 수 있듯이, 우리는 어떤 수의 상태 변화를 "포장"하여 단일 비트코인 약속 안에 넣을 수 있으며, 이론적으로 대규모 배치 처리를 구현할 수 있어 UTXO 서비스 공급자에게 더 많은 응용 시나리오를 제공합니다.

• 시나리오: A는 여러 사람에게 동시에 지불하고자 하며, B에게 RGB20 자산을 전송하고, C에게 RGB21 자산을 전송하며, D에게 계약의 소유권을 전송하고자 합니다.
• 결과: A는 B, C, D 각각에 대해 하나의 상태 변환을 생성하고, 모든 상태 변환을 동일한 비트코인 거래에 약속하기만 하면 됩니다. 더 많은 바이트를 차지할 필요가 없습니다. 이는 서로 다른 상태의 상태 변화가 하나의 약속 안에 포장되어 배치 처리가 이루어졌음을 의미합니다.* 각 RGB 지불의 체인 상 수수료 한계 비용은 매우 작을 수 있으며, 동일한 수수료가 임의의 수의 전송에 분산됩니다.*

여기에는 한계가 존재하는데, 즉 이러한 상태 변환 정보는 반드시 "동일한 UTXO" 안에 "포장"되어야 하며, 여러 개가 존재할 경우 이 거래의 입력을 늘려야 하므로 관련 비용도 증가합니다. 그러나 전통적으로 각 상태 변화가 하나의 거래를 필요로 하는 상황에 비해 이미 큰 개선이 이루어졌습니다.

5. 클라이언트 간의 통신

클라이언트 통신은 RGB 전송 구현 과정에서 일반적입니다. 발신자는 수신자(들)에게 "consignment"를 공유해야 하며, 이 데이터 구조는 전송 검증에 필요한 모든 정보를 포함하고 있으며, 계약의 초기 상태까지 추적할 수 있는 모든 상태 변환이 포함되어 있습니다. 이는 발신자로부터 통신 방식으로 수신자에게 전송되어야 합니다. 그러나 RGB 프로토콜에서는 통신 채널에 제한을 받지 않으며, 다양한 데이터 공유 방식이 있습니다. 일반적인 두 가지 데이터 공유 방법은 다음과 같습니다:

• Storm: 라이트닝 네트워크를 기반으로 한 점 대 점 즉시 통신 및 저장 시스템입니다.
• RGB 프록시 서버: 데이터 업로드 및 다운로드를 위한 표준화된 HTTP JSON-RPC 서버입니다. 사용자는 자신의 프록시 서버를 실행할 수 있으며, 제3자의 서버를 사용할 수도 있습니다. 제3자의 서버에 의존하는 것은 개인 정보 보호 및 검열 저항성에 영향을 미치지만, 보안성에는 영향을 미치지 않습니다.

클라이언트 통신 BiHelix는 자가 적응 통신 프로토콜을 제안하여 최적화하였습니다.

결론

현재 RGB v0.11 버전이 여전히 베타 단계에 있지만, 많은 RGB 생태계 프로젝트 팀이 이를 위해 적극적으로 기여하고 있으며, 함께 v0.11 버전의 세밀한 최적화를 추진하고 있음을 쉽게 알 수 있습니다.* RGB 생태계 프로젝트 및 RGB 프로토콜의 옹호자로서 BiHelix 팀은 RGB 프로토콜의 엔지니어링 및 상업적 실현을 위해 최선을 다하고 있습니다.* 라이트닝 네트워크와 RGB 프로토콜의 호환성을 가속화하고, 더 많은 고품질 응용 생태계 개발자를 적극적으로 유치하여 그들이 RGB 프로토콜을 깊이 배우고 적용하는 것이 최우선 목표입니다.

RGB 프로토콜이 점점 더 성숙해짐에 따라 자산 발행 기능 집합이 비트코인 생태계에 더 많은 혁신을 가져오고, 다시 한 번 전체 비트코인 생태계를 새로운 높이로 끌어올릴 것이라고 믿습니다. RGB 프로토콜이 비트코인 네트워크에서 널리 사용됨에 따라, 본 문서도 RGB의 메커니즘과 설계를 이해하는 데 필수적인 중요한 참고 자료가 될 것입니다. 이 활기찬 생태계에서 RGB의 전망은 밝으며, 비트코인의 진화를 위한 새로운 활력과 가능성을 주입하고 있습니다.