BTC 반감기가 다가오고 있으며, Runes 프로토콜의 기본 설계 메커니즘과 한계를 해석합니다

저자: 십사군

서문

오랫동안 중단되었던 글을 다시 시작합니다. 저는 십사군입니다.

지난 반년 동안 필자는 ETH 생태계에서 BTC 생태계로 완전히 전환하였고, 응용 계층에서 체인 하부로 이동하였습니다. BTC, Merlin, Babylon, Xion 등의 L2 공공 체인 하부를 살펴보며, Ordinals, BRC20, Atomical, Runealpha, Runes 등의 명문 룬 프로토콜 소스 코드를 연구하였습니다.

약간의 성찰이 있었으니, 계속해서 출력을 이어가겠습니다. 필자는 기술적 관점에서 독특한 통찰력과 시장 가치를 제공할 것입니다.

1. Runes(룬)이란 무엇인가?

지난 1년 동안, Web3에서 가장 큰 서사는 명문 생태계의 폭발이었습니다. 최초의 출발점은 Ordinals로, BTC의 각 사토시에게 고유 번호를 부여하는 기술입니다. 더 읽어보려면: 비트코인 Ordinals 프로토콜과 BRC20 표준 해석 원리 혁신과 한계

그 핵심 창립자인 케이스는 작년 9월에 Runes의 기본 버전 코드를 제출했지만, 메인넷 출시가 지연되었습니다. 그래서 9월의 명문 열풍 속에서 RuneAlpha 등의 프로젝트가 해당 코드를 미리 포크하여 RunesAlpha 등의 프로토콜을 독립적으로 발행했습니다. 비록 일부 표절 논란이 있지만, 불과 몇 달 만에 수억의 총 시가 총액 증가로 Runes 프로토콜의 무한한 잠재력을 보여주었습니다.

Ordinals 프로토콜의 창립자인 케이스가 설계한 공식 정품 Runes 프로토콜은 2024년 4월 20일경 공식 발표될 예정입니다. BTC 메인넷에 직접上线되므로, 각 프로젝트 측은 Runes 자산을 발행하고, 각 지갑 및 NFT/FT 거래 시장은 Runes를 지원하기 위해 블록체인 산업에서 가장 어려운 도전 중 하나인 테스트넷 없이 메인넷으로 직접 돌진해야 합니다!

공식 트위터의 발언은 더욱 자신감이 넘칩니다~ 새로운 단어를 배워봅시다: Seppuku

본 글에서는 룬 프로젝트의 하부 필드 변천사를 체계적으로 정리하여, Runes와 BRC20, ARC20 등의 FT 프로토콜 간의 차이점을 근본적으로 이해할 수 있도록 하여, 비교 우열의 합리적 결정을 내릴 수 있도록 하겠습니다.

2. 비트코인에서 추가 정보를 어떻게 기록하는가?

비트코인에는 두 가지 주요한 체인 외 데이터가 체인에 부착되는 방식이 있습니다: 명각과 각인

2.1. 각인 기본 원리

Runes는 각인 기술을 사용하며, 이는 정보를 체인에 기록하는 간단하고 직관적인 방법입니다: 즉, 비트코인의 UTXO(미사용 거래)의 op-return 필드에 기록하는 것입니다. 이 기능은 Bitcoin Core 클라이언트 0.9 버전에서 시작되었습니다(2014년). OP-RETURN은 명확하고 검증 가능한 소비 불가능한 출력을 생성하여 데이터를 블록체인에 존재하게 합니다. 이는 UTXO의 출력과 유사하지만 소비될 수는 없습니다.

BTC의 블록체인 탐색기에서 쉽게 확인할 수 있으며, 해당 거래에는 op-return 정보가 부착되어 있습니다. 예를 들어 아래 그림과 같습니다:

여기서 출력 #3은 사실상 유리한 상태입니다. 비록 해당 UTXO의 출력 위치를 차지하고 있지만, 이는 닫힌 원형 사각형으로, 다시 전송되거나 소비될 수 없음을 나타냅니다. 따라서 이는 거래의 비고 구역과 같아 비트코인의 저장 공간에 남아 있으며, 거래 해시 구역 인덱스를 통해 찾을 수 있습니다.

세심한 분들은 왜 OPRETURN 뒤에 RUNETEST가 있는지 궁금할 수 있습니다. 이는 구체적인 내용을 디코딩한 결과입니다. 세부 사항 버튼을 클릭하면 52554e455f54455354와 같은 인코딩 문자열을 찾을 수 있으며, 이는 실제로 일련의 16진수 인코딩 데이터로, 디코딩하면 RUNE_TEST를 얻을 수 있습니다. 마찬가지로 세부 사항에는 다른 인코딩도 있으며, 최종적으로 디코딩하면 문자열이 되어 JSON 형식으로 Runes 자산의 배포, 주조, 발행 등의 의미를 나타냅니다.

2.2. 명각 기본 원리

사실 Ordinals/BRC20 등의 프로토콜에서 메타데이터를 체인에 삽입하는 것은 거래의 증인 데이터(witness data, witness field)에 기록됩니다. 이 명각 과정은 격리된 증인(Segregated Witness, SegWit)과 "Taproot로 지불"(Pay-to-Taproot, P2TR) 방식을 통해 구현되며, 제출(commit)과 공개(reveal) 두 단계, 즉 최종적으로 두 번의 거래로 완료됩니다.

사실 P2TR은 비트코인의 거래 출력 유형 중 하나로, 2021년 Taproot 업그레이드에서 도입되었습니다. 이는 다양한 거래 조건을 블록체인에 보다 "프라이빗"하게 저장할 수 있게 해줍니다. 프라이버시가 향상된 이유는 공개할 때만 구체적이고 완전한 내용을 볼 수 있기 때문입니다. 구체적으로 P2TR 주소를 생성할 때 스크립트 해시를 사용하며, 소비할 때 실제 스크립트(명문 데이터 포함)를 제공하므로, 명문 데이터를 업로드하기 위해서는 먼저 이 스크립트로 생성된 P2TR 주소의 UTXO(커밋 거래)를 생성해야 합니다. 그런 다음 이 UTXO를 소비할 때 증인 스크립트에서 실제 스크립트를 제공하여 명문 데이터를 체인에 업로드합니다(리빌 거래).

사실 Ordinals 프로토콜은 매우 이해하기 쉽습니다. 이 명각 과정(커밋, 리빌) 두 번의 거래가 체인에 올라간 후, Ordinals 프로토콜은 이 명문이 첫 번째 입력의 첫 번째 사토시에 바인딩되도록 정의합니다. 따라서 바인딩 과정이 명각이고, 바인딩 결과가 명문입니다.

2.3. 두 가지 데이터 상장 방안 비교

각인:

• 장점: 논리가 간단하고 직관적이며 명확하고, 거래 비용이 낮으며 전체 노드 메모리 풀을 차지하지 않을 수 있습니다.

• 단점: 80바이트 길이에 제한되며, 데이터 인코딩을 고도로 압축해야 합니다.

명각:

• 장점: 크기에 거의 제한이 없으며, 일정한 프라이버시 보호 능력이 있으며, 다양한 방식(시간 잠금, 작업 증명 등)이 있습니다.

• 단점: 거래가 두 번 체인에 올라가야 하므로 최종 비용이 높아지고, 커밋 지속 시간이 길어 전체 노드 메모리 풀에 큰 압력을 줍니다.

3. Runes 하부 설계 해석

Runes 프로토콜의 최초 코드는 케이스가 Ordinals 0.11 버전에 게시하였고, 최신 Ordinals는 이미 0.18 버전으로 발전하였습니다. 거대한 버전 변화는 우리가 최고 프로토콜의 설계 과정에 들어갈 기회를 제공합니다. 십사군이 예전에 해석한 ERC721/ERC3525/ERC3475 등의 표준을 확장하여 읽어보세요:

우리는 Runes의 시작점과 끝점 두 버전의 필드 변화를 살펴보며 Runes의 가치를 규명해봅시다.

3.1. Runes 0.11 버전 해석

최초의 Runes 전체 필드는 3개 부분으로 나뉘어 있습니다: edicts(자산 전송 정보), etching(자산 배포 정보), burn(소각).

구체적으로, 한 거래의 op_Return에 정보가 디코딩되어 edicts 정보를 올바르게 나타내면, 체인 외의 해석기가 해당 사용자의 자산이 전송되었음을 계산합니다. 여기서 output은 전송의 목표지입니다.

마찬가지로 etching의 내용도 자산 배포의 주요 정보를 직접적으로 나타냅니다. 우리는 ERC721과 비교할 수 있으며, 가장 큰 차이는 limit와 term이 mint의 수량과 mint 가능한 구간을 제한한다는 것입니다. 이러한 점이 명문, 룬 프로젝트와 이더리움 스마트 계약 발행 자산의 근본적인 차이입니다. 체인 상에 스마트 계약 검증이 부족하여 실시간 검증 능력이 떨어지므로, 특정 프로젝트 측이 체인 상의 자산을 발행하면서 새로운 명문 프로토콜을 운영하여 자신의 화이트리스트 Mint, 토큰 경제학 해방 속도, 로열티 납부 등의 기능을 커스터마이즈하면, 공감대가 부족해져 아무도 이 프로젝트에 참여하지 않게 됩니다. 따라서 명문 프로토콜(BRC20, Atomical, Runes) 등은 자산 발행 방식을 통일적으로 정의하고, 사용자 참여 mint 방식을 통일하여 공정한 발사를 지향하며, 사용자 참여를 완전히 개방하여 프로젝트 측의 자산 시장 인식 과도한 개입을 방지합니다.

프로젝트 측이 자산을 축적하여 시장을 통제하려고 해도, 막대한 가스 비용을 지불해야 하며, 이 과정은 사용자에게 감지되고 자유롭게 선택할 수 있습니다.

최초 버전의 Runes 프로토콜 설계는 이미 꽤 완벽했습니다. 따라서 발전된 RuneAlpha는 비록 모조품이지만 상당한 시장 규모를 차지하고 있으며, 누적 82만 거래 건수로 수수료만으로도 312 BTC를 소모했습니다.

사용자는 Runes 필드 자체의 설계를 통해 자산의 복합화, 분할을 쉽게 구현할 수 있으며, Runes 자산이 Ordinals, Atomical 등의 자산과 교차 프로토콜 복합화되면, op_Return의 다양한 언어 표현성을 활용하여 분할을 실현할 수 있습니다.

그렇다면 최신 Runes 프로토콜은 0.18에서 무엇을 구현하였고, 왜 이러한 필드가 필요했을까요?

3.2. Runes 0.18 버전 해석

Runes 0.18을 이해하는 것은 매우 어렵습니다. 테스트넷이 부족하여 기본적으로 케이스의 소스 코드에서만 논리를 확인할 수 있으며, 최종적으로 정리된 필드는 4가지 측면으로 나뉩니다:

먼저 edicts는 여전히 자산 전송 방향을 정의하며, RuneAlpha와 기본적으로 일치합니다. 차이점은 자산 기본 전송 방향을 수정하기 위한 pointer 매개변수가 추가되었다는 것입니다. 원래의 기본 전송 방향은 0위였으나, 이 매개변수가 추가되면 1 또는 다른 값으로 설정할 수 있습니다. 설계 이념은 여러 Runes 자산이 동시에 전송될 때 op_Return 인코딩 양을 줄여 최종적으로 사용자의 거래 비용을 낮추기 위함입니다.

둘째로, Mint 필드가 추가되었습니다. Mint가 edicts와 동급의 객체에 위치하므로, 한 거래에서 하나의 자산만 mint할 수 있다는 것을 의미합니다. 이는 이전 RunesAlpha와는 다릅니다. 그 당시 의도적으로 설계하여 한 거래에서 대량의 새로운 자산을 mint할 수 있었으므로, 기술적으로 자산을 다루는 사용자와 일반 사용자의 출발선이 균형을 이루게 되었습니다. 이제 모두 가스를 경쟁하여 확보해야 합니다.

자산 배포 방식의 거대한 변화

마지막으로 중요한 변화는 etching, 즉 자산 배포의 세부 설계입니다. 전체 필드 내용은 다음과 같습니다:

기본적으로 혼란스러울 정도로 복잡한 새로운 자산 배포 방식입니다. 자세히 설명하겠습니다~

첫째로, opReturn 인코딩 양을 줄이기 위한 설계가 큰 변화입니다. opReturn은 80바이트 길이에 제한되므로, 각 인코딩 공간을 소중히 여겨야 합니다. 따라서 케이스는 자산 ID의 변화를 도입했습니다. 이는 단순한 블록 높이 + 거래 순서 번호로 생성된 고유 ID 값에서 문자열 형태의 블록 높이 + 콜론 + 거래 순서 번호로 변경되었습니다. 비트코인 메인넷의 블록 높이가 80만 개 이상이므로, 최종 ID 인코딩이 절반으로 절약되었습니다. 이는 결코 작지 않으며, 대량 Mint 및 대량 전송 시 비용을 크게 줄일 수 있습니다.

둘째로, 참여자의 공정성을 보장하는 terms 필드입니다. 이제 자산 배포가 시작되는 Mint는 RunesAlpha와 같이 배포 자산 프로토콜의 거래가 체인에 올라간 블록 높이에 따라 시작되지 않고, 발행자가 지정한 높이와 오프셋을 시작 및 종료점으로 사용합니다. 이렇게 되면 사용자는 메모리 풀을 항상 주시하지 않아도 되며, 최신 Mint 기회를 탐색할 필요가 없습니다. 결국 프로젝트 측은 자산을 미리 배포한 후 일련의 운영 및 홍보 활동을 진행하여 사용자가 참여하게 할 수 있습니다. 구간 높이는 참여 시간을 측정하는 기준이 되며, cap은 총 mint 횟수로 자산 발행 규모를 추가로 제어합니다. 이제 무한정 mint가 아니라 제한된 발행이 되어 선착순으로 진행됩니다.

자산 발행 프로토콜로서, 발행자의 규모와 권리를 어떻게 제어할 것인지는 큰 도전입니다. 명문에 있어 가장 중요한 것은 자산 이름입니다. Runes에서 이름은 희소 자원으로, 반감기 주기에 따라 Runes 이름 길이 해방 규칙이 있습니다. 처음에는 긴 이름만 배포할 수 있으며, 시간이 지남에 따라 짧은 문자 수의 이름을 배포할 수 있습니다.

상상해보세요. 이름 길이 해방 주기가 올 때마다 도메인과 유사한抢注 열풍이 일어날 것입니다. 그렇다면 프로젝트 측이抢注되는 것을 어떻게 방지할까요?

이것이 Runes 이번 배포의 가장 중요한 변화인 배포 프로세스입니다. 이제 단순한 op_Return 거래가 아니라 명각이 됩니다. 앞서 언급했듯이, 명각 기술은 커밋과 리빌을 통해 일정한 프라이버시 보호를 수행할 수 있습니다. 새로운 버전의 프리마인은 이 역할을 맡아 커밋과 리빌 두 거래 간에 일정한 간격을 두어야 하며, 공개될 때 시장은 발행자가 사용할 이름을 알게 됩니다. 이때 다른 해커가 피싱 자산을 제작하려고 해도, 메모리 풀에서 해당 이름을 이미 보았더라도, 이 사전 제한을 넘지 못하게 됩니다. 이는 발행자가 이름에 대한 통제력을 보호합니다.

0.18 버전 마지막에는 turbo 필드가 추가되었습니다. 이는 현재로서는 명확한 공개 목적이 없으며, 이후 다른 프로토콜 레이어 변경에 참여하는 것을 의미합니다.

4. Runes 새로운 프로토콜을 어떻게 평가할 것인가

위의 하부 필드 해석을 통해, 십사군은 케이스가 자산 발행의 방식에 대한 통찰력이 정말 독특하다는 것을 느끼지 않을 수 없습니다. 불과 2개월 만에 시장의 요구와 문제점에 완벽하게 부합하는 프로토콜 내용을 설계하고 구현하였습니다. 이는 가격을 통해 가치를 측정하는 시장입니다. 명문 프로토콜은 처음에 완전히 차별화된 스마트 계약 모델로 많은 상상 공간을 열어주었으며, 진정한 공정한 mint는 많은 사용자가 BTC의 세계에 진입하게 하였고, BTC L2d 열풍을 더욱 촉발시켰습니다. 그러나 명문 프로토콜의 초기 거친 설계로 인해 저질 자산이 넘쳐나고, 거리에는 도용과 러그가 만연하여 명문 생태계가 더럽혀졌습니다. 룬의 출현은 더욱 높은 수준의 맞춤형 발행 관리를 통해 시장을 질서 있게 만들 것입니다. 또한 Runes 프로토콜은 Ordinals 프로토콜 자체에 내장되어 있으며, Ordinals의 사용자 기반을 활용하여 Runes 프로토콜의 발행이 처음부터 거인의 어깨 위에 서게 됩니다. FT 프로토콜로서의定位는 원래 Ordinals가 NFT로서 시장 운영 방식이 부족했던 상황을 보완합니다. 마지막으로, op_Return 방식을 사용하여 체인 상 데이터를 기록함으로써 Runes 자산은 거의 모든 기관과 재현 장부의 능력을 가질 수 있으며, 중앙 집중화 정도가 더욱 낮아져 Runes 자산은 BTC와 동등한 일정한 안전성을 갖추게 됩니다. Runes 프로토콜의 단점은 무엇일까요? 확실히 있습니다. 첫째는 시장 시기 문제입니다. 케이스가 BTC 반감기와 동기화하여 출시하기로 결정했지만, 긴박한 개발 시간으로 인해 심지어 어제도 프로토콜 내용을 변경하고 있었습니다. 이로 인해 시장에서 Runes 프로토콜에 첫 번째로 접속할 수 있는 기관이 점점 줄어들고 있습니다. 결과적으로 프로토콜 생태계는 더 많은 시간 동안 발효되어야 합니다. 둘째는 규칙의 복잡성입니다. 발행 관리 규칙이 이미 매우 복잡하지만, 이름의 변화로 인해 발행자가 처음 선택할 수 있는 이름이 길어졌습니다. 특수한 점 기호와 결합하여 Runes 프로토콜의 이름 최대 길이는 B•C•G•D•E•N•L•Q•R•Q•W•D•S•L•R•U•G•S•N•L•B•T•M•F•I•J•A•V와 같이 거의 55자의 길이가 되어, 이는 사용자가 피싱에 노출될 위험을 증가시키며, 모바일 단말기 플러그인 등에서 완전하게 표시하기도 어렵습니다. 마지막으로 미래 호환성 문제입니다. 현재 시장에서 뜨거운 Atomical 프로토콜은 이미 AVM 단계로 나아가고 있으며, 명문을 단순한 토큰 투기 단계에서 벗어나 BTC L2 또는 BVM의 서사로 나아가고 있습니다. 이 점에서 케이스는 다소 뒤처져 있으며, 룬 프로젝트가 발행 측면의 방식으로만 제한되는 것을 제한하고 있습니다. 본문 내용 참고 자료:

• Runes 프로토콜 인코딩 및 디코딩 분석: https://github.com/okx/js-wallet-sdk
• Runes 프로토콜 공식 소스 코드: https://github.com/ordinals/ord