Runesプロトコルおよび「公開インスクリプション」発行メカニズムに関する拡張ディスカッション
TechFlow厳選深潮セレクト
Runesプロトコルおよび「公開インスクリプション」発行メカニズムに関する拡張ディスカッション
Runesプロトコルは、2024年のビットコイン半減期（ブロック高840000）に合わせて、今年4月下旬にメインネットへ上線する予定です。
Web3業界の深掘り報道に専念し潮流を洞察執筆：MiX
編集：Faust，Geek web3
2024年3月2日、Runesエコシステムのインフラプロジェクト「Rune alpha」の創設者がGitHub上の公開イシューを通じて、Runesプロトコルの創設者Caseyと議論を交わしました。両者はRunesプロトコルにおける「公開エッチング（公開刻印）」メカニズムの拡張方法について議論し、以下のトピックを取り上げました。
-
「公開エッチング」における事前予約の禁止要件を緩和すべきか？
-
「公開エッチング」方式で発行されたRunesトークンには管理権が存在しないという見解
-
インスクリプションNFTとファンゴウFT（同質性トークン）が連携する新たな発行メカニズムの提案
ビットコイン派生資産プロトコルへの強い関心から、本稿の執筆者は上記のRunesに関する最新議論を踏まえ、RunesとOrdinalsプロトコルの歴史的経緯および類似した資産発行方式について探求的に考察し、皆様のビットコインエコシステム理解に役立つことを願っています。
Runesプロトコルとは何か
いわゆるRunesプロトコルとは、ビットコインネットワーク上でファングルートークン（FT）を発行するためのプロトコルであり、Ordinalsの創設者CaseyがOrdinalsスキームの発表後に新たに構築した同質性トークン方式です。ビットコインのUTXO特性に基づき設計されており、全体的な設計思想は非常にシンプルです。
特筆すべきは、Runesプロトコルはビットコインの半減期（ブロック高840000）に合わせ、2024年4月下旬にメインネットへリリースされる予定であることです。現時点では、Runesプロトコルは最適化やバージョンアップの段階にあります。
Runesの原理を簡単に解説する前に、まずその経緯と、「公開エッチング」という概念が何を意味するのかを確認しましょう。
Runesの提唱者Caseyは当初、同質性トークンプロトコルを作成する考えはありませんでした。2022年12月、CaseyはOrdinalsプロトコルを発表し、NFTデータをビットコインチェーンに永久保存することを目指しました。つまり、NFTのメタデータを「インスクリプション」として、ビットコイン取引のwitnessデータ（主にデジタル署名情報を含む）に記録することで、テキストや画像などの任意のコンテンツを特定のサトシに刻印できるようにしたのです。
（出典：https://yishi.io/a-beginner-guide-to-the-ordinals-protocol/）
その後、歴史の歯車が動き始めます。2023年3月8日、匿名開発者@domodataは、典型的なNFT発行プロトコルであるOrdinalsを応用し、BRC-20という同質性トークンの標準を迂回的に構築しました。これは、インスクリプション形式でビットコインチェーンにアップロードされる派生資産データに対して、統一されたフォーマットと属性（トークン名、供給量、1回あたりの最大鋳造量など）を規定し、インデクサーがこれらの情報を解析・追跡することで、BRC-20トークンのウォレットアカウントと保有額を表示する仕組みです。
ここで重要なのは、BRC-20の発行はNFT発行プロトコルであるOrdinalsに依存しているため、初期発行メカニズムがNFTのミントプロセスと類似しており、「先着順」の特性を持つ点です。誰が最初にミントしたかで所有権が決まり、イーサリアムのERC-20のようにプロジェクト側が資産コントラクトを展開し、分配ルールを自由に設定できるのとは根本的に異なります。
このFair Launch（公平なローンチ）の特性により、多くの人々が同質性トークンの初期発行に公平に参加できるようになり、プロジェクト側による事前確保やロックアップもありません。誰もが資産発行直後に参加可能です。これにより、BRC-20はすぐにビットコインチェーン上での派生資産発行ブームを引き起こし、現在のブルマーケットの起点ともなりました。したがって、本稿で焦点を当てる「公開エッチング」という発行方式は、Runesプロトコルにとって極めて重要なのです。
しかし、BRC-20は多くの問題も引き起こしました。BRC-20資産の操作ごとに、ビットコインチェーン上で特定の取引を発行する必要があります。BRC-20資産の人気に伴い、ビットコインのUTXOデータセットは急速に膨張し、BTCコア開発者たちからもBRC-20に対する公開的な疑問が呈されました。
Ordinalsの創設者Casey自身もBRC-20を批判しており、Ordinals上に構築されたFT資産を認めません。しかし、BRC-20の人気を見て、たとえ99%のトークンが詐欺や話題作りであったとしても、これらはカジノのように消えることはないと認識しています。
同時に、BRC-20はビットコインチェーン上に「過剰な痕跡」を残し、ノードにデータ負担を強いている一方で、オンチェーンデータの「軽量化」を実現する資産プロトコルが登場すれば、BRC-20の問題を緩和できるかもしれません。
そこでCaseyはビットコインのために「より優れた同質性トークンプロトコル」を構築すると決定し、2023年9月25日にRunesプロトコルの初期構想を発表しました。
技術的には、RunesプロトコルはビットコインのUTXOと付加情報に基づいて構築されています。各取引のトリガー時には、チェーン外で生成されたデジタル署名情報をオンチェーンに提出する必要があり、その署名情報に特定フォーマットのメッセージを含めることができます。RunesプロトコルはOP_RETURNオペコードを使用して「特定メッセージ」をマークし、それらのメッセージがRunes資産の変更に関連する情報となります。
BRC-20プロトコルと比較して、Runesには多くの利点があります。特に重要なのは以下の通りです。
1. 取引手順が簡素化され、不要なUTXOが生成されないため、ビットコインノードの「負担軽減」に貢献します。また、BRC-20の送金取引は1つの受取人と1種類のトークンのみサポートするのに対し、Runesは複数の受取人に同時に送金でき、複数のRunesトークンを一度に転送できます。
2.資産データの保存とインデックスがより簡潔：BRC-20のデータはJSON形式で特定取引のwitnessデータ内に保存され、BRC-20はアカウントモデルに基づくため、資産残高は特定のアカウントに関連付けられます。一方、Runesプロトコルのデータは特定取引のOP_RETURNフィールドに保存され、資産記録方式はUTXOモデルを採用しており、ビットコインチェーンのUTXOと「同型バインド」が可能です。
あるユーザーのRunes資産状況を確認する際、そのユーザーが所有するRunes資産とバインドされた特殊なUTXOを検証するだけで済みます。一部の情報を遡って計算する必要はありますが、BRC-20のようにビットコインチェーン全体のUTXOセットをスキャンする必要はなく、この軽量な方式はデータインデックスに優しいです。
3. UTXO機能拡張レイヤとの互換性：RunesはUTXOに基づく設計により、CKB、Cardano、FuelなどUTXOベースの機能拡張レイヤと良好に互換できます。RGB++のような「UTXO同型バインド」を通じて、これらの機能拡張レイヤがRunesにスマートコントラクト機能を提供することが可能です。
技術的な概要を簡単に述べた後、本稿の冒頭に戻り、発行メカニズムについて再考します。CaseyはRunesトークンのために「固定総量」と「公開エッチング」という2つの発行方式を設計しています。
1. 固定総量とは、発行者がすべてのRunesトークンを直接エッチングし、その後分配を行う方式で、比較的中央集権的です。
2. 公開エッチングとは、Runesトークンの発行パラメータを設定し（例：特定のブロック高またはタイムスタンプを指定）、その期間中にユーザーがミントした量が最終的な総供給量となる方式です。
2つの発行方式は対象とするユースケースとメカニズムが大きく異なりますが、以下では「公開エッチング」に焦点を当てます。
実際、SondotpinはRunesのIssues#124においてすでにこのテーマを議論しており、Caseyもそれを承認しています。
そして、Issues#165の内容は以下の通りです。
-
Sondotpin：現行の公開発行では、プロジェクト側／発行者が事前にRunesトークンを予約できないため、優れたトークノミクス設計の機会が制限されている。
-
Casey：以前のIssues#124を参照してください。この要件を緩和し、発行者が発行時に合理的な方法でトークンを配分できるようにすることを検討しています。パラメータを超えて設定することも可能にする予定です。その場合、関連情報はRunesトークンの詳細ページで明確に表示されます。
-
Sondotpin：例えば2段階の「公開エッチング」を行い、各段階で異なるパラメータを設定するような多次発行メカニズムは可能でしょうか？
-
Casey：私はこのようなやり方を好んでいません。なぜなら、Runesトークン自体には「管理者」が存在しないため、発行権限を特別な権限を持つ単一の主体に委ねるべきではないからです。ただし、トークン発行時にインスクリプションを追加し、そのインスクリプションを基に新しいトークンを発行することで、同じ資産として2回の発行を実現することは可能です。あるいは、プリマイニングを行い、他の分配方法で発行するという選択肢もあります。
将来CTV（Check Template Verify）機能が正常にアクティベートされれば、プロトコル側のサポートが不要となり、CTVによって条件テンプレートを事前に設定し、条件達成時にエアドロップや公開エッチングを実行できるようになります。
CaseyとSonPinの議論を中心に、個人的な見解：
1. プロジェクト初期におけるTokenの事前確保は確かに必要
初期段階でプロジェクトが自立的に運営を開始するには、コアチームのモチベーションを維持し、コミュニティを形成するために一定量のTokenを確保する必要があります。今回の議論に基づきプロトコルを実装できれば、「公開エッチング」の公平性と大衆参加の価値を補完でき、より多くの実質的価値を持つプロジェクトが「公開エッチング」を通じてRunesエコシステムに参画できるようになります。
2. 事前確保の有無や方法は、発行者自身が証明する手段に委ねられる
実際、CaseyはYouTubeの動画で繰り返し、同質性トークンの99.9%は詐欺であり、「世界を変える」といった高尚な言葉を使うべきではないと述べています。これはギャンブルと投機に満ちた業界だと正直に認め、誠実さこそが全員にとって良いと主張しています。IT'S JUST FOR FUN!
issue#124から#165にかけて、Caseyが同質性トークンの利用シーンに対してより多くの受け入れを見せていることがわかります。「公開エッチング」方式自体に疑問の余地はありませんが、その上で事前確保メカニズムを追加することは、選択肢と自己証明の手段を発行者に与えるものであり、良貨が悪貨に駆逐されるのを防ぐ有効な方法でもあります。
3. インスクリプションNFTとファンゴウFTにはさらなる革新の余地がある
Caseyが提唱する、インスクリプションNFTとファンゴウFTが連携する多段階発行メカニズムの構想は非常に興味深いものです。背景知識として、OrdinalsとRunesはどちらもCaseyが設計したプロトコルであり、平行関係にあると言えますが、GitHub上では「Ord」という1つのプロジェクトとして統合されており、技術的にも同期ブロック処理などの基盤ロジックを共有しています。
現在注目のRunestoneやRunecoinなどのプロジェクトも、インスクリプションとファンゴウを組み合わせた革新の一例です。Runecoinは主流のインスクリプションによるプリマイニング方式で、RSICインスクリプションを保有することで継続的にプロジェクトのファンゴウをマイニングでき、4月下旬のRunesプロトコルリリース後にFTが分配されます。今後さらに多くのプロジェクトが新しさを追求し、新たなプレイスタイルを生み出すことを期待しています。
4. 「公開エッチング」方式で発行されたRunesトークンには所有権が存在しない
Caseyは元々「Runeには所有権がない」と述べていましたが、筆者はこれは「公開エッチング」方式で発行されたRunesトークンに特有の性質だと考えます。SonPinが提案する2段階「公開エッチング」方式では、必然的に極めて高い権限を持つアドレスが必要となり、これはCrypto分野が望む方向とは言えません。
たとえば、プロジェクトRunecoinは21,000枚のRSICインスクリプションNFTを発行した後、すぐに親インスクリプションを中本聡アドレスに送金し、誰も再利用できなくしました。これは技術的に増発しないことを約束する行為であり、この行動は大きな称賛を集め、一般ユーザーからの支持を高めました。
PS：親インスクリプションとは？BTCでのインタラクションは遅くガス代も高いため、大量の処理を行う場合、効率向上のため通常「親インスクリプション」を事前に設定します。この親インスクリプションの取引内で複数の子インスクリプションを一括処理することで、ストレージ容量と処理時間を節約できます。
最後に、Caseyが言及したCTV（Check Template Verify）について説明します。
CTVはビットコインのプロトコルアップグレード案の一つで、ユーザーが取引作成時に将来の取引テンプレートを指定できるようにすることで、ビットコインネットワークのスマートコントラクト機能やロック機能を強化することを目指しています。CTVのアクティベーションにより、信頼できるエアドロップやオープンエッチングなど、より複雑な取引タイプがプロトコルの明示的なサポートなしに実現可能になります。
このCTV提案はビットコインネットワークのプログラマビリティと柔軟性を高めるものであり、今回の議論で言及されたように、UTXOのアンロック条件テンプレートを作成することで、Runesにさらなる遊びの幅を提供する可能性があります。たとえば、「Runesプロトコル＋CTV」により、10人のユーザーがCTV技術を共同使用してファンゴウをミントし、将来的なビットコイン支払い取引の条件などを事前設定することが可能になります。
TechFlow公式コミュニティへようこそ
Telegram購読グループ：https://t.me/TechFlowDaily
Twitter公式アカウント：https://x.com/TechFlowPost
Twitter英語アカウント：https://x.com/BlockFlow_News
@MixWeb3
