Runesプロトコルの基盤設計メカニズムと限界を深く解読する

1. ルーン(の概要

過去一年、web3分野で最も注目されたホットトピックは間違いなく铭文エコシステムの爆発です。その起源はOrdinalsプロトコルに遡ります。この技術はビットコインの各サトシにユニークなシリアル番号を与えます。Ordinalsの核心開発者であるcaseyは昨年9月にRunesプロトコルの基礎コードを提出しましたが、正式にはオンラインになっていませんでした。これにより、一部のプロジェクトはこのコードを早期にフォークし、RunesAlphaなどのプロトコルを発行しました。議論はあるものの、わずか数ヶ月で数億ドルの時価総額の増加もRunesプロトコルの巨大な可能性を示しています。

公式版のRunesプロトコルは、2024年4月20日頃にビットコインメインネットで正式にローンチされる予定です。これは、プロジェクトチーム、ウォレットプロバイダー、およびNFT/FT取引プラットフォームにとって重大な課題を意味します。テストネットなしでメインネットに直接適合させる方法です。

この記事では、Runesプロジェクトの基盤となるフィールドの進化を体系的に整理し、読者がRunesとBrc20、Arc20などのFTプロトコルの違いを根本的に理解できるようにし、理性的な評価と参加を促します。

! [Runesプロトコルの基礎となる設計メカニズムと制限の詳細な分析])https://img-cdn.gateio.im/webp-social/moments-4396aa45df590316218e4c76904c11b0.webp(

) 2. ビットコインチェーン上のデータ記録方法

ビットコインには、オフチェーンデータをオンチェーンに追加するための主に二つの方法があります：刻印とエッチング。

2.1 エッチングの基本原理

Runesはエッチング技術を採用しており、これは情報を直接チェーンに記録する方法です。具体的には、データをビットコインのUTXO（未使用トランザクション出力）のop-returnフィールドに書き込むことです。この機能は2014年にBitcoin Coreクライアントの0.9バージョンから始まりました。OP_RETURNは、検証可能だが消費不可能な出力を作成し、データをブロックチェーンに保存することを可能にします。

ビットコインブロックエクスプローラーでは、取引に添付されたop-return情報を簡単に見ることができます。例えば、ある取引の出力#3は、再度転送または消費できないことを示す閉じた円形矩形かもしれません。これは取引のメモ欄のようなもので、ビットコインのストレージスペースに永続的に保存され、取引ハッシュインデックスを介して見つけることができます。

####2.2碑文の基本

Ordinals/brc20などのプロトコルは、メタデータを取引の証人データに埋め込みます。このプロセスは、隔離証人と「Taprootに支払う」（P2TR）方式を通じて実現され、提出と暴露の2つの段階が含まれ、2回の取引を完了する必要があります。

P2TRはビットコイン2021年のTaprootアップグレードで導入された取引出力タイプであり、異なる取引条件をよりプライベートに保存することを可能にします。具体的には、P2TRアドレスはスクリプトハッシュを使用して生成され、消費時には実際のスクリプト（インスクリプトデータを含む）を提供します。したがって、インスクリプトデータをアップロードするには、まずこのスクリプトによって生成されたP2TRアドレスへの支払いを生成するUTXO（取引を提出）を作成し、そのUTXOを消費する際に、ウィットネススクリプト内で実際のスクリプトを提供することで、インスクリプトデータをチェーン上にアップロードします（取引を公開）。

Ordinalsプロトコルでは、インスクリプションはこの2つの取引が完了した後、最初の入力の最初のサトシにバインドされます。

2.3 2つのデータオンチェーンソリューションの比較

エッチング：

• 利点：論理がシンプルで直感的、取引コストが低く、全ノードのメモリプールを占有しない。
• 欠点：80バイトの長さ制限を受け、高度な圧縮データエンコードが必要です。

刻ま れた：

• 利点：サイズにほとんど制限がなく、一定のプライバシー保護能力を持ち、さまざまなプレイスタイル（例：タイムロック、プルーフ・オブ・ワーク）をサポートしています。
• 欠点：2回のオンチェーン取引が必要で、最終的なコストが高く、フルノードのメモリプールに大きな負担をかけます。

! [ルーンプロトコルの基礎となる設計メカニズムと制限の詳細な分析]###https://img-cdn.gateio.im/webp-social/moments-71b84def7979d41a2400449fdc5edcee.webp(

) 3. ルーンの基礎となるデザインの分析

3.1 ルーン 0.11バージョン

初期のRunesプロトコルのフィールドは、三つの部分に分かれています：edict（資産移転情報）、etching（資産展開情報）、およびburn（廃棄）。

op_Returnの情報が正しい形式のedicts情報としてデコードされると、オフチェーンパーサーはユーザー資産の移転状況を計算し、outputフィールドが移転先を指定します。

エッチングの内容は、資産のデプロイメントに関する主要な情報を定義しています。ERC721と比較して、主な違いは、limitとtermフィールドが鋳造数量と鋳造可能な範囲を制限している点です。これは、铭文、符文プロジェクトとイーサリアムのスマートコントラクトによる資産発行との根本的な違いを反映しています。チェーン上でのスマートコントラクトの検証が不足しているため、铭文プロトコルは資産の発行とユーザーの鋳造参加の方法を統一的に定義し、公平なローンチを実現しています。

! [ルーンプロトコルの基礎となる設計メカニズムと制限の詳細な分析]###https://img-cdn.gateio.im/webp-social/moments-1a8ad9f747fe4a9f9b3ba8b4f0d8b33b.webp(

)# 3.2 ルーン 0.18バージョン

最新版Runesプロトコルフィールドは四つの側面に分かれています：

1. edicts：資産移転の方向を定義し、デフォルトの移転方向を変更するために新しいpointerパラメータを追加し、複数のRunes資産を同時に転送する状況に適応し、コーディング量と取引コストを削減します。

2. ミント：新しいフィールド、1回の取引で1つの資産しか鋳造できないように制限し、技術者と一般ユーザーのスタートラインを平衡させました。

3. エッチング：資産のデプロイ方法に重大な変化が生じました。主な変更点は次のとおりです：

   • アセットIDを文字列形式に変更し、コーディングスペースを節約します。
   • termsフィールドにheightとoffsetパラメーターを導入し、発行者が鋳造の開始点と終了点を指定できるようにします。
   • capパラメータは総発行回数を制御します。
   • 名前の長さのリリースルールを導入し、希少なリソースを制御します。
   • コミットとリビールの技術を採用して展開し、プライバシー保護を提供します。

4. turbo：新しいフィールド、将来のプロトコル層の変更のために予約されています。

! [ルーンプロトコルの基礎となる設計メカニズムと制限の詳細な解釈]###https://img-cdn.gateio.im/webp-social/moments-a3fbbb22d01d9b7871f626a8836cec4f.webp(

) 4. Runes新プロトコル評価

価値：

• 市場のニーズに合致し、インスクリプションエコシステムにおける劣悪な資産の横行という問題を解決しました。
• Ordinalsプロトコルを組み込み、既存のユーザー基盤を持つ。
• FTプロトコルとして、Ordinalsの市場運用における不足を補いました。
• op_Returnを使用してオンチェーンデータを記録し、柔軟な帳簿機能と高いセキュリティを提供します。

短所：

• 市場のタイミングには課題があり、厳しい開発時間がエコシステムの初期発展に影響を及ぼす可能性があります。
• ルールが複雑で、資産名の長さの問題はユーザーがフィッシングされるリスクを高める可能性があります。
• 未来の互換性に懸念があり、他のプロトコルに比べてL2やBVMにおける展開がやや遅れている。

! [ルーンプロトコルの基礎となる設計メカニズムと制限の詳細な解釈]###https://img-cdn.gateio.im/webp-social/moments-76e02af769fcbb0515c5486c267f20dd.webp(