곧 다가올 BTC 반감기: 룬 프로토콜의 기본 설계 메커니즘과 한계에 대한 설명

저자: XIV 준

서문

오랜 휴식 끝에 마침내 쟁기질을 재개하고, 저 XIV 준이 돌아왔습니다.

지난 6개월 동안 저는 이더리움 생태계에서 비트코인 생태계로, 그리고 애플리케이션 계층에서 체인의 하위 계층으로 완전히 전환하여 비트코인, 멀린, 바빌론, 시온 등과 같은 L2 퍼블릭 체인의 하위 계층을 살펴보고 오디널, brc20, 원자, 룬알파, 룬 등과 같은 새겨진 룬의 프로토콜 소스 코드를 연구해왔습니다.

저자가 기술적인 관점에서 바라본 룬에 대한 통찰과 시장 가치에 대해 이야기합니다.

1, 룬(룬)이란 무엇인가요?

지난 1년간 웹3.0의 가장 큰 화두는 비트코인 사토시마다 고유 일련번호를 부여하는 기술인 오디널스(Ordinals)로 시작된 인스크립션 생태계의 폭발적인 성장으로, 이를 확장해 '비트코인 오디널스 프로토콜과 BRC20 표준 원칙의 혁신과 한계에 대한 해석'으로 읽을 수 있습니다.

이 프로토콜의 핵심 창립자인 케이시는 작년 9월 룬 프로토콜의 기본 버전을 제출했습니다. 9월 룬 코드의 기본 버전을 제출했지만 온라인 메인 네트워크의 출시가 지연되어 9월 비문 붐에서 룬알파와 다른 프로젝트가 코드의 포크, 룬알파와 다른 프로토콜의 별도 문제, 일정량의 표절이 있지만 몇 달 만에 룬 프로토콜의 총 시장 가치에서 수억 달러의 성장도 프로토콜의 무한한 잠재력을 보여 주었다.

룬즈 프로토콜의 잠재력은 어떤가요?

오디널스 프로토콜의 창립자 케이시 디자인에 따르면, 2024.4.20경에 룬즈 프로토콜의 공식 버전이 공식적으로 발표될 예정입니다. 그리고 비트코인의 메인넷에서 직접적으로, 모든 종류의 프로젝트 당사자들이 룬 자산을 발행하고 싶어하고, 모든 종류의 지갑, NFT/FT 거래 시장이 룬을 지원하기를 원한다면 블록체인 업계에서 가장 어려운 도전 중 하나인 테스트 네트워크 없이 직접 메인넷을 스프린트하는 방법에 직면하게 될 것입니다!

그리고 공식 트위터 성명은 매우 자신감이 넘칩니다 ~ 부수적으로 새로운 단어를 배우십시오 : 셉푸쿠

이 기사는 룬 프로젝트의 기본 필드 변경 사항을 체계적으로 정리하여 모든 사람들이 Runes와 Brc20, Arc20 및 기타 FT 프로토콜의 차이점을 근본적으로 이해하고 합리적인 의사 결정 참여의 장단점을 비교할 수 있도록 합니다. 2. 비트코인에 추가 정보는 어떻게 기록되나요?

비트코인에서 체인에 첨부되는 오프체인 데이터에는 비문과 에칭이라는 두 가지 주류가 있습니다

2.1, 에칭 기본 원리

룬은 체인에 정보를 기록하는 간단하고 직관적인 방법인 에칭 기술을 사용합니다: 즉, oop-return 필드에 있는 UTXO(미사용 거래)의 bitc에 기록하는 함수에서 비트코인 코어 클라이언트 버전 0.9('14년)에서 활성화된 OP-RETURN은 명시적으로 검증 가능한 비소비성 유형의 출력을 생성하여 데이터가 블록체인에 존재할 수 있도록 하며, 이는 UTXO의 출력과 유사하지만 소비 가능하지는 않습니다.

다음 이미지에서와 같이 트랜잭션에 연산 반환이 첨부되어 있는 것을 btc의 블록체인 브라우저에서 쉽게 확인할 수 있습니다.

여기에서 출력 #3 는 실제로는 스트레이이며, 해당 utxo의 출력 위치를 차지하지만 폐쇄 루프 둥근 사각형이므로 다시 소비를 위해 전송할 수 없으므로 트랜잭션의 도켓처럼 비트코인 스토리지에 남아 있으며, 트랜잭션의 해시 영역을 통해 인덱싱하여 찾을 수 있습니다.

주의를 기울이면 왜 RUNE_TEST 뒤에 OP_RETURN이 있는지 알 수 있습니다. 이것은 디코딩된 결과의 특정 내용이며, 버튼의 세부 정보를 열려면 가리키면 52554e455f54455354 이러한 코딩된 문자열, 실제로 16진수로 인코딩된 데이터 문자열, 디코딩된 RUNE_TEST를 얻기 위해 디코딩된 52554e455f54455354 이러한 코드화된 문자열, 사실 버튼의 세부 정보와 같은 방식으로 디코딩된 RUNE_TEST를 얻으려면 디코딩된 문자열, 실제로 6진수 인코딩 데이터의 문자열, 디코딩된 6진수인코딩된 문자열, 즉 디코딩된 문자열을 찾을 수 있습니다. TEST도 마찬가지로 세부 정보에 다른 인코딩이 있으며, 최종 디코딩 후 문자열(아마도 json 형식)이 되어 Runes 에셋 배포, 캐스팅, 배포 등을 반영합니다.

2.2, 기본 원칙의 비문

실제로 Ordinals/brc20 및 기타 프로토콜은 체인에 메타데이터를 삽입하기 위해 트랜잭션 증인 데이터(증인 데이터, 증인 필드)에 기록되며, 이 비문은 분리된 증인(Segregated Witness, SegWit)과 분리된 증인(SegWit) 과정을 통해 비문을 새깁니다. 분리된 증인(SegWit)과 '페이 투 탭루트'(Pay-to-Taproot, P2TR) 방식으로 비문을 새기는 이 과정은 제출(커밋)과 공개(공개) 두 단계로 이뤄지며, 최종적으로 2번의 트랜잭션이 완료되어야 비문 새기기가 완료됩니다.

사실 P2TR은 2021년 탭루트 업그레이드에서 도입된 비트코인의 거래 출력의 한 종류로, 다양한 거래 조건을 보다 '비공개' 방식으로 블록체인에 저장할 수 있으며, 프라이버시가 강화된 이유는 공개되어야만 전체 내역을 볼 수 있기 때문입니다. 이렇게 프라이버시가 강화된 이유는 공개될 때만 전체 세부 정보를 볼 수 있기 때문입니다. 구체적으로, 스크립트 해시를 사용하여 p2tr 주소를 생성하고, 지출 시점에 실제 스크립트(비문 데이터가 포함된)가 제공되므로 비문 데이터를 업로드하기 위해서는 이 스크립트로 생성된 p2tr 주소로 지불하는 utxo를 생성해야 하고(커밋 트랜잭션), utxo가 소비되면 실제 스크립트를 증인 스크립트로 제공하여 비문 데이터를 체인에 업로드해야 합니다(리플 트랜잭션). 위로 (공개 트랜잭션).

사실, 오디널스 프로토콜은 이해하기 매우 쉽습니다. 즉, 이 비문 프로세스(커밋, 공개)가 완료된 후 두 트랜잭션이 모두 체인에 업로드되면 이 비문이 첫 번째 샛의 첫 번째 입력에 바인딩되도록 오디널스 프로토콜이 정의되어 있습니다. 따라서 바인딩하는 과정이 비문이고 결과에 대한 바인딩이 비문입니다.

2.3, 체인 프로그램에서 두 데이터 비교

에칭:  

• 장점: 직관적인 논리가 간단하고 트랜잭션 비용이 낮으며 전체 노드 메모리 풀을 차지하지 않고도 사용할 수 있습니다.

• 단점: 길이가 80바이트로 제한되며, 고도로 압축된 데이터 인코딩이 필요합니다.

설명:

• 장점: 거의 무제한의 크기, 일부 개인정보 보호, 다양한 플레이 방식(시간 잠금, 작업 증명) 등

• 단점: 트랜잭션을 2번 체인화해야 하므로 최종 비용이 높고, 커밋 생존 시간이 길며, 전체 노드 메모리 풀에 대한 압력이 높아집니다.

3, 룬스 기본 설계 해석

룬스 프로토콜 초기 코드는 오디널스 0.11 버전에서 공개되었으며, 최신 오디널스는 0.18 버전으로 발전하여 많은 변화가 있었지만 최상위 합의 를 해석한 14개의 예시처럼, 규칙에 따라 룬의 값을 해석하기 위해 룬의 시작과 끝을 두 가지 버전의 필드 변경 사항으로 나누어 살펴볼 수도 있습니다.

3.1, 룬 0.11 버전 해석

초기 룬 전체 필드는 칙령(자산 이전 정보), 에칭(자산 배치 정보), 소각(파괴)의 세 부분으로 나뉩니다.

{   "edicts": // 자산 이전 정보    "id":  "id":     . "id":  "1000c82970852",                    전송 수량     "output": 0  // 첫 번째 출력에 바인딩  }           . ;],  "에칭": { // 자산 배치 정보 // 최소 분할 가능 단위 "분할 가능성": 1, //최소 분할 가능 단위  nbsp; "limit": 1000, //각 민트의 금액  //각 민트의 금액  //각 민트의 금액  //각 민트의 금액    //각 민트의 금액 "symbol":  "C",  //약어    "term":  150  //발행 가능한 블록 수  },    "burn":   "소각": the nbsp;false // 정보 소각}

특히, op_Return의 트랜잭션이 정보 다음에 칙령을 제시하도록 디코딩된 정보가 형식이 올바른 경우 파서 아래의 체인, 사용자의 자산이 출력의 전송을 전송하도록 계산되어 대상의 전송이 전송됩니다.

에칭의 내용도 배포된 자산의 주요 정보를 직접 표현한 것이며, ERC721과 비교할 수 있으며, 가장 큰 차이점은 민트 수와 민트 간격을 제한하는 제한 및 용어에 있습니다. 그리고이 점은 비문, 룬 프로젝트와 이더 리움 스마트 계약 발행 자산의 근본적인 차이점이며, 체인에 대한 스마트 계약 검증이 부족하여 실시간 검증 기능이 적기 때문에 체인에서 자산을 발행하는 프로젝트 당사자도 자신의 화이트리스트 민트, 토큰 경제 방출 속도, 로열티 지불 및 기타 기능을 사용자 정의하기 위해 새로운 비문 프로토콜 세트를 실행하면 합의가 부족하고 사람들이 프로젝트에 참여할 수 있도록 비문 프로토콜 (brc20, 원자, 룬) 등을 통합하여 자산 발행 방식을 정의하고 사용자가 민트에 참여하는 방식을 통합하여 공정 출시의 개념으로 사용자가 프로젝트에 참여할 수 있도록 완전히 개방하여 자산 시장에 대한 인식에 대한 과도한 간섭의 프로젝트 측면을 더욱 제거합니다.

프로젝트 측이 축적된 자산을 싹쓸이하여 시장을 통제하더라도 막대한 가스 가격을 지불해야 하며, 그 과정에서 사용자가 인식하고 자유롭게 선택할 수 있습니다.

실제로 룬 프로토콜 설계의 원래 버전은 상당히 완벽했기 때문에 룬알파의 진화는 모방품이라고 해도 시장 규모를 많이 차지하고 누적 거래량 82W, 수수료만 312 BTC를 소비했습니다.

사용자는 룬 필드 자체의 설계를 사용하여 자산의 복리, 분할을 쉽게 달성하고 룬 자산이 병기 조사에 연결되면 시장을 통제 할 수 있지만 시장을 통제하는 데 사용할 수 없으므로 시장을 통제하는 데 사용할 수 없습니다. 룬 자산이 오디날, 오토매틱 등과 함께 프로토콜에 결합된 후에도 op_Return의 다양한 언어적 표현력을 통해 분할할 수 있습니다.

0.18의 최신 Runes 프로토콜 구현은 무엇이며, 이러한 필드를 구현할 때 고려해야 할 사항은 무엇인가요?

3.2, Runes 0.18 버전의 해석

Runes 0.18을 이해하려면 테스트 네트워크가 없기 때문에 기본적으로 케이시의 소스 코드를 통해서만 로직을 볼 수 있으며, 최종적으로 필드를 네 가지 측면으로 나누어 정리했습니다.

pub struct Runestone. {  pub edicts: Vec<Edict , pub etching: Option<Etching ,  pub ,pub 민트: 옵션 룬아이디 , pub 포인터: 옵션 u32 ,}pub struct Edict { .  pub id: RuneId,  pub amount: u128,  pub output: u32,}

첫째, 칙령은 여전히 정의된 정의의 자산 전송 방향과 runeAlpha는 기본적으로 동일하며, 차이점은 자산 전송의 기본 방향을 수정하는 데 사용되는 하나 이상의 포인터 매개 변수가 있으며, 원래 기본 전송은 0 번째이며,이 매개 변수를 사용하여 1 또는 기타로 설정할 수 있으며, 디자인 개념은 op_Return을 줄이기 위해 시간에서 전송할 때 동시에 다양한 Runes 자산에 적응하는 것입니다. 코딩의 양을 줄이고 궁극적으로 사용자의 트랜잭션 비용을 줄일 수 있습니다.

두 번째로, 새로운 민트 필드는 그의 민트가 과 칙령과 같은 동일한 수준의 객체에 배치되어 트랜잭션이 자산을 발행 할 수 있다는 것을 의미하는 이전 RunesAlpha와 다른 의도적 인 설계로 인해 거래가 많은 수의 새로운 자산을 발행하여 자산을 치는 기술과 일반 유저들이 자산을 타격할 수 있는 출발선은 모두가 GAS를 얻기 위해 싸워야 합니다.

자산 배치가 극적으로 변화했습니다

마지막으로, 더 중요한 변화는 자산 배치의 세부 설계인 에칭이며, 전체 필드 내용은 다음과 같습니다 :

pub 구조 에칭 { // 자산 배치 정보 pub 분할가능성: 옵션<u8>, //최소 분할 단위: pub premine: 옵션<u128> gt;,  //사전 채굴할 블록 수 pub rune: 옵션<룬>,  //룬 자산 이름  룬; pub 스페이서: 옵션<u32 //룬 자산 이름 점 구분자 pub 기호: 옵션<문자 // 룬 자산 이름 점 구분자; // 약어 pub 용어:옵션<용어 // 계열 필드에 대한 캐스팅 규칙 pub 터보: bool, // 시리즈 필드의 캐스팅 규칙. 터보, 에셋이 후속 테스트 릴리스 변경에 포함되는지 여부}pub 구조 조건 {  // ; 캐스팅 규칙을 위한 시리즈 필드  pub 금액: 옵션<u128&t;,// 단일 민트 개수 제한 pub 캡: 옵션<. u128>,  // 총 민트 개수 제한 pub height: (Option<u64>, Option<u64>),.  // 발행 가능한 블록 높이  pub offset: (Option<u64&t;, , // 오프셋, 끝 발행의 끝점} 
기본적으로 어지러운, 실제로 새로운 자산 방식의 매우 복잡한 배포, 우리가 자세히 보자 ~ 
우선, 더 큰 변화의 포인트는 op_Return 인코딩 디자인의 양을 줄이기 위해, 결국, op_Return 제한 각 인코딩 공간의 80 바이트의 길이를 소중히 여겨야한다. 그래서 케이시는 비트코인 메인 네트워크가 80W 블록 높이만 넘기 때문에 고유 ID 값에 의해 생성된 단순한 블록 높이 + 거래 일련 번호에서 블록 높이 + 콜론 + 거래 일련 번호의 문자열 형식으로 자산 ID를 변경했기 때문에 최종 ID 코딩을 절반으로 절약하고 일괄 민트, 일괄 전송 시나리오를 비용의 기하 급수적으로 감소시키지 마십시오. 
둘째, 참가자의 공정성을 보장하는 것은 조건 필드이며, 이제 자산 시작 민트의 배포는 시작의 블록 높이 체인에 거래의 자산 계약 배포를 기반으로 더 이상 런알파가 아니라 지정된 높이와 오프셋의 발행자를 시작과 끝으로 배포합니다. 이러한 방식으로 사용자는 메모리 풀을 항상 주시하지 않더라도 피싱 코티지 프로젝트에 빠지는 것에 대해 너무 걱정할 필요가 없으며, 최신 발행 기회를 활용할 수 있습니다. 결국 프로젝트 소유자는 먼저 자산을 미리 배포한 다음 일련의 운영 및 홍보 활동을 통해 궁극적으로 사용자가 참여할 수 있도록 하고, 참여 시간의 척도로서 간격 높이에 더해 총 발행 횟수를 제한하여 더 이상 무제한 발행이 아닌 선착순 발행으로 자산 발행 규모를 더욱 제어할 수 있습니다. 
자산 공개 계약으로서 발행자의 규모와 권익을 통제하는 방법은 비문의 경우 가장 중요한 것은 자산의 이름이며, 이름의 룬은 희소 자원이며, 룬 이름 길이 공개 규칙의 절반 주기가 수반되며, 시작은 이름이 길수록 더 많은 시간을 배포 할 수 있으며, 더 적은 수의 캐릭터의 이름을 배포 할 수 있기 전에 더 길수록 배포 할 수 있습니다. 
이름 길이 릴리스 주기가 발생할 때마다 도메인 이름과 유사한 로보콜이 계속 발생할 것으로 예상되는데, 프로젝트 측에서 로보콜을 피하려면 어떻게 해야 할까요? 
이번 룬의 배포에서 가장 중요한 변화는 더 이상 op_Return 트랜잭션이 아니라 앞서 언급했듯이 커밋 및 공개를 통한 비문 기술이 일정 수준의 개인 정보를 보호하기 위해 수행 할 수 있으며, 새로운 버전의 프리 마인이이 역할을 맡는 것이며, 커밋 및 공개 두 거래의 요구 사항은 동일한 개인 정보 보호 기능을 갖습니다. 두 개의 트랜잭션이 일정 간격을두고 공개 한 다음 시장이 이름을 사용하는 발행자 만 알고있을 때 공개되며, 이때 다른 해커가 피싱 자산을 만들고 싶어도 메모리 풀의 마스터가 이름을보고 모방하더라도이 사전의 한계를 통과 할 수 없으므로이 자녀는 권력의 통제 이름 발행자를 보호 할 수 없습니다. 
버전 18의 끝에는 새로운 터보 필드도 있으며, 당분간은 명확한 공개 역할이 없으며, 도덕은 나중에 다른 프로토콜 계층 변경에 참여하는 것입니다. 
4, 룬 새 버전의 계약을 평가하는 방법 
기본 필드에 대한 위의 해석을 통해 14 신사는 또한 연극의 자산 발행에 대한 케이스가 정말 통찰력이 있다고 느낄 수밖에 없으며, 단지 2 개월, 시장 수요의 고통에 가까운 계약의 설계 및 구현을 할 수 있습니다. 
이것은 가치를 측정하기 위해 가격을 보는 시장, 완전히 차별화 된 스마트 계약 모델로 처음에 비문 프로토콜은 많은 상상력을 열었고, 실제 공정 민트는 또한 많은 수의 사용자가 실제로 btc의 서클에 들어가게했으며 btcL2d 붐을 더욱 촉발 시켰습니다. 하지만 초기에 비문 프로토콜의 허술함으로 인해 품질이 낮은 자산이 떠돌았고, 불법 복제와 불법 복제물로 가득한 거리로 인해 비문 생태계는 황폐해졌습니다. 룬의 등장과 더 높은 수준의 맞춤형 유통 관리는 시장에 질서를 가져올 것입니다. 
그리고 룬 프로토콜은 오디널스 프로토콜 자체에 내장되어 오디널스의 사용자 기반을 활용함으로써 룬 유통이 처음부터 거대 기업과 어깨를 나란히 할 수 있게 해줍니다. FT로서의 포지셔닝은 대체 불가능한 토큰으로서의 오디널스의 부족한 시장성을 보완합니다. 
마지막으로, 온체인 데이터를 기록하기 위해 op_Return을 사용하면 거의 모든 기관의 원장을 복제할 수 있으며, 중앙화 정도가 더욱 낮아져 룬 자산이 비트코인과 동등한 수준의 보안 성능을 갖출 수 있습니다. 
룬 프로토콜의 단점은 무엇인가요? 
첫 번째는 시장 출시 시기인데, 케이시는 비트코인 반감기와 동시에 출시하기로 했지만 개발 기간이 매우 촉박하고 어제까지도 프로토콜의 내용을 변경하고 있어 시장에서 룬즈 프로토콜을 처음 접하는 기관이 점점 줄어들고 있어 프로토콜의 생태계가 발효되는 데 시간이 더 필요할 것입니다. 
둘째, 규칙의 복잡성인데, 이미 배포 관리를 위해 충분히 복잡하지만 이름 변경으로 인해 배포자는 더 긴 이름을 선택할 수 있게 되었으며, 특수 점 표기법과 결합하여 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비트 길이로, 사용자가 피싱당할 위험을 위장하고 증폭시킵니다. 그리고 모바일 플러그인 측에서 전체 인터페이스를 보여주기도 어렵습니다. 
마지막으로 향후 호환성 문제, 동일한 시장 핫 원자 프로토콜, 레이아웃이 이제 AVM 단계로 이동하여 단순한 토큰 투기 단계를 없애고 더 나아가 btc L2 또는 BVM 내러티브에 대한 비문,이 점은 케이스가 약간 후퇴했다고 말해야하지만 룬 프로젝트는 배포 수준으로만 플레이를 제한합니다.