ルーンズに関するお話（翻訳）

Runes
9.25.2023

出展：
A Japanese Translation of Casey Rodarmor’s article Runes
https://rodarmor.com/blog/runes/

ビットコイン用に新しい代替性のトークンプロトコルを作成することについては悪い点といい点があります。悪い点としては交換可能トークン、つまり代替性トークンは99.9%が詐欺やミームであり、それらはすぐに消えるようなことはないだろうということです。いい点としては、ビットコインに対して良い代替性トークンプロトコルを作成することは、トランザクション手数料収入、開発者の関心、そしてユーザーをビットコインに引き寄せるられるという期待ができる点です。他にも、このプロトコルがオンチェーンに対して負荷が小さく、責任あるUTXO管理を促進するようであれば、既存のプロトコルと比較してデメリットの軽減をするかもしれないという期待が持てます。
少なくともそのうちの1つであるBRC-20はすでにかなり人気がありますが、それはUTXOの増殖という望ましくない結果をもたらしています。

既存の交換可能トークンプロトコルは以下の通りです。
比較してみると、重要な違いがあります：

- 複雑さによる違い：プロトコルがどれほど複雑か/実装しやすいか/採用しやすいか　が異なります。
- ユーザーエクスペリエンスによる違い：ユーザーエクスペリエンスに悪影響を及ぼす実装の有無に違いがあります。特に、オフチェーンデータに依存するプロトコルはオンチェーンの負荷が軽くなりますが、その分複雑になります。ユーザーが自分自身のサーバーを実行するか、既存のサーバーを見つけてインタラクトする必要があります。
- ステートモデルによる違い：UTXOベースのプロトコルはビットコインにより自然にフィットします。これにより、「ジャンク」UTXOの作成を避けることによりUTXOセットの最小化を促進します。
- ネイティブトークンによる違い：プロトコル操作に必要なネイティブトークンを持つプロトコルは、抽出的なため不便で、あまり広く採用されていません。

ビットコインの既存の交換可能トークンプロトコルを比較すると：
- BRC-20：UTXOベースではなく、一部の操作に序数理論の使用を必要とするため、かなり複雑です。
- RGB：非常に複雑で、オフチェーンデータに依存し、長期間開発されているが採用されていない。
- Counterparty：一部の操作に必要なネイティブトークンを持ち、UTXOベースではありません。
- Omni Layer：一部の操作に必要なネイティブトークンを持ち、UTXOベースではありません。
- Taproot Assets：多少複雑で、オフチェーンデータに依存します。

これらの違いがあります。

さて。これらのを踏まえたうえでビットコインのシンプルでUTXOベースの交換可能トークンプロトコルはどのように見えるでしょうか？

1つあるのです。それは「ルーンズ」と呼ばれています！かっこいいですよね。

ルーンズはビットコインの救世主？

ルーンズの概要

ルーンの残高はUTXOによって保持されます。UTXOには任意の数のルーンが含まれることができます。

トランザクションには、ASCIIの大文字のRに続くデータプッシュを含む出力を含む場合、プロトコルメッセージが含まれます。プロトコルメッセージは、最初のデータプッシュ以降のすべてのデータプッシュとなります。

プロトコルメッセージが無効なトランザクションに入力されると、そのルーンはバーンされます。これにより、ルーンがどのように割り当てられたり作成されたりするかを変更する将来のアップグレードによって、古いクライアントが誤ってルーン残高を割り当てる状況が発生することを防ぎます。将来のアップグレードでのエラーを防ぐ、ということですね。

整数はプレフィックスのVarint（任意の数字）としてエンコードされます。Varintの先頭の1の数が、バイト数を決定します。

ルーンズの送金について

プロトコルメッセージの最初のデータプッシュは、整数のシーケンスとしてデコードされます。

これらの整数は、(ID、OUTPUT、AMOUNT)のタプルのシーケンスとして解釈されます。デコードされた整数の数が3の倍数でない場合、プロトコルメッセージは無効です。

以下補足です
- ID：割り当てるルーンの数値IDです。
- OUTPUT：それを割り当てる出力のインデックスです。
- AMOUNT：割り当てるルーンの量です。

IDはデルタ（更新履歴）としてエンコードされます。これにより、同じルーンの複数の割り当てが、フルルーンIDを繰り返すことなく行われます。例えば、次のタプル：

[(100, 1, 20), (0, 2 10), (20, 1, 5)]

は、次の割り当てを行います：
- ID 100、出力1、20ルーン
- ID 100、出力2、10ルーン
- ID 120、出力1、5ルーン

AMOUNT 0は「残りのすべてのルーン」の省略形です。

すべてのタプルの割り当てを処理した後、割り当てられていないルーンは、OP_RETURN出力がない場合に最初の非OP_RETURN出力に割り当てられます。また、余分な割り当ては無視されます。

また、プロトコルメッセージを含むOP_RETURN出力に割り当てられると、バーンされる可能性があります。

ルーンズの発行について

プロトコルメッセージに第二のデータプッシュを与えることもできます。
それを発行トランザクションといいます。発行トランザクションである第二のデータプッシュは、SYMBOL、DECIMALSの2つの整数としてデコードされます。整数がまだ残っている場合（不正な場合）、プロトコルメッセージは無効となります。

発行トランザクションは、割り当てタプルでID 0を使用して発行されたルーンの任意の量、最大で2^128 - 1を指定して発行することができます。

SYMBOLは、基数26でエンコードされた人間が読めるシンボルであり、序数名で使用されるものと類似しています。有効な文字はAからZまでです。

DECIMALSは、表示される発行されたルーンの小数点以下の桁数です。

SYMBOLがまだ割り当てられていない場合、それは発行されたルーンに割り当てられ、発行されたルーンは1から始まる次の利用可能な数値のルーンIDを受け取ります。

SYMBOLが既に割り当てられているか、またはBITCOIN、BTC、またはXBTである場合、新しいルーンは作成されません。 ID 0のルーンIDを使用した発行トランザクションの割り当ては無視されますが、他の割り当ては引き続き処理されます。

メモ

UTXOの残高を表示する際には、UTXOのネイティブなビットコイン残高は、ルーンIDゼロとシンボルBITCOIN、BTC、またはXBTで表示されます。

シンボルスクワットを回避するための試みは行われません。理由はプロトコルをシンプルに保つためです。シンボルスクワットを回避するための方法として、一定の長さ以上のシンボルの割り当てのみを許可し、その長さを時間の経過とともに減少させ、最終的にゼロになり、すべてのシンボルを許可する方法をとります。これにより、プロトコルの早い段階で短くて望ましいシンボルが割り当てられることを避けることができ、後に望ましいシンボルに対する競争を促進することができます。

ルーンズに対する懸念

懸念？そのようなものが存在すべきかどうかはわかりません。ルーンズは、可能な限りシンプルであり、オフチェーンデータに依存せず、ネイティブトークンを持たず、ビットコインのネイティブUTXOモデルにうまく収まります。このようなスキームは、より悪いオンチェーンフットプリントを持つ他のスキームからユーザーを引き寄せ、開発者とユーザーの興味をビットコインに向け、ビットコインそのものの採用を促進するかもしれません。

一方で、代替性トークンの世界にはスキャムはつきものなので、その懸念はあるかもしれません。そこだけはご了承を。