元の記事 - Casey Rodarmor
コンパイル - 毎日
昨日、Ordinals の作成者 Casey Rodarmor が投稿しましたブログ、新しい代替トークン (FT) プロトコル Runes が導入されました。
ビットコインにFTが必要かどうかについて、Casey Rodarmor氏そのツイートFT には 2 つの側面があることを意味します。一方で、FT の 99.99% は「クソ」であり詐欺であり、ビットコインの純度を損なうものですが、他方では、FT は多額の手数料収入、開発者、ユーザーをビットコイン エコシステムにもたらしています。 「人々はトークンを愛しており、それらはサイバーパンクカジノのようなものであるため、（サイバー）セキュリティ予算に関する懸念が完全に軽減されるまで、手数料収入は多額となり継続する可能性があります。」
同氏は、BRC-20、RGB、TaprootなどのFTプロトコルがすでに登場していると付け加えた。単純なオンチェーン プロトコルと比較して、RGB や Taproot などのプロトコルは複雑であり、ユーザー エクスペリエンスに課題を引き起こす可能性があります。 BRC-20 は非常にシンプルで、オフチェーンのデータ ストレージと取得インフラストラクチャを必要とする RGB/Taproot に比べて優れたユーザー エクスペリエンスを提供できますが、BRC 20 トークンの問題は、「ガベージ UTXO」を生成し、ビット コイン スペースを占有することです。
Rodarmor氏は、Runesはビットコインにより自然に適合し、「ジャンクUTXO」の作成を回避することでUTXOコレクションの最小化を促進するUTXOベースのプロトコルであると述べた。
以下の内容は Casey Rodarmor のブログ投稿からのものであり、Odaily によって編集されました。
ビットコイン用に新しい Fungible Token (FT) プロトコルを作成することが良いアイデアかどうかはわかりません。 FT の 99.9% は詐欺とミームです。しかし、カジノがすぐになくなるわけではないようであるのと同じように、それらもすぐにはなくなるわけではないようです。
ビットコイン用の優れた FT プロトコルを作成すると、多額の取引手数料収入、開発者の注目、ユーザーのビットコインへの注目がもたらされる可能性があります。さらに、プロトコルのオンチェーン フットプリントが小さく、責任ある UTXO 管理を奨励する場合、既存のプロトコルと比較して害が軽減される可能性があります。例えば、現在人気のBRC-20はジャンクUTXOが大量に発生する原因となっています。
既存の FT プロトコルを比較すると、いくつかの重要な違いがあることがわかります。
複雑さ: 契約はどの程度複雑ですか?実装は簡単ですか?採用しやすいですか？
ユーザー エクスペリエンス: ユーザー エクスペリエンスに悪影響を与える実装の詳細はありますか?特に、オフチェーン データに依存するプロトコルは、オンチェーンのフットプリントが軽いものの、大幅な複雑性をもたらし、ユーザーが独自のサーバーを実行するか、既存のサーバーを検出して操作する必要があります。
状態モデル: UTXO ベースのプロトコルはビットコインにより自然に適合し、「ジャンク」UTXO の作成を回避することで UTXO セットの最小化を促進します。
ネイティブ トークン: プロトコルの動作に必要なネイティブ トークンを含むプロトコルは扱いにくく、撤回可能であり、当然のことながらあまり広く採用されていません。
上記の次元に基づいて、ビットコインエコシステム内の既存の FT プロトコルの比較結果は次のとおりです。
BRC-20: UTXO に基づいておらず、一部の操作で順序論の使用が必要なため非常に複雑です。
RGB: 非常に複雑で、オフチェーン データに依存しており、長い間開発されてきましたが、採用されていません。
カウンターパーティ: UTXO ベースではなく、特定の操作に必要なネイティブ トークンを持っています。
オムニ レイヤー: UTXO ベースではなく、特定の操作に必要なネイティブ トークンがあります。
Taproot Assets: 少し複雑で、オフチェーン データに依存します。
ビットコインの場合、優れたユーザー エクスペリエンスを備えたシンプルな UTXO ベースの FT プロトコルはどのようなものになるでしょうか?次に、「Runes」と呼ばれる非常にクールなソリューションを紹介したいと思います。
（1。概要
ルーン残高は UTXO に保持され、UTXO には任意の数のルーンを含めることができます。
トランザクションのスクリプト公開キーに OP_RETURN とそれに続く ASCII 大文字の R を含むデータ プッシュが含まれる出力が含まれている場合、トランザクションにはプロトコル メッセージが含まれます。プロトコル メッセージはすべて、最初のメッセージの後にプッシュされるデータです。
無効なプロトコル メッセージを含むトランザクションに入力されたルーンは破棄され、将来のアップグレードでルーンの割り当てまたは作成方法を変更できるようになり、古いクライアントによるルーン残高の誤った割り当てが回避されます。
整数はプレフィックス varint としてエンコードされ、varint の先頭の数値によってバイト単位の長さが決まります。
(2) 譲渡
プロトコル メッセージ内の最初のデータ プッシュは、一連の整数にデコードされます。
これらの整数は、(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 出力に割り当てることで焼き付けることができます。
(3)発行
プロトコル メッセージに 2 番目のデータ プッシュがある場合、それは発行トランザクションです。 2 番目のデータ プッシュは 2 つの整数、SYMBOL と DECIMALS にデコードされます。さらに整数が残っている場合、プロトコル メッセージは無効になります。
発行トランザクションは、割り当てタプルの ID 0 を使用して、最大 2^128 - 1 までの任意の数の発行ルーンを作成できます。
SYMBOL は、人間が判読できる 26 ビットの基本エンコード記号で、通常の衛星名で使用される記号に似ています。有効な文字は A ～ Z のみです。
DECIMALS は、発行されたルーンを表示するときに使用する小数点以下の桁数です。
SYMBOL がまだ割り当てられていない場合は、公開されたルーンに割り当てられ、公開されたルーンは次に利用可能な数値のルーン ID (1 から始まる) を受け取ります。
SYMBOL がすでに割り当てられている場合、または BITCOIN、BTC、または XBT である場合、新しいルーンは作成されません。ルーン ID 0 を使用した発行トランザクション割り当ては無視されますが、他の割り当ては引き続き処理されます。
(4) 注意事項
UTXO 残高を表示する場合、UTXO のネイティブ ビットコイン残高はルーン ID 0 とシンボル BITCOIN、BTC、または XBT で表示できます。
プロトコルをシンプルに保つために、(Runes) はシンボル占有を回避するメカニズムを採用していません。実際、シンボルの結合を回避する効率的かつ簡単な方法は、一定の長さを超えるシンボルの割り当てのみを許可することです。この長さは時間の経過とともに減少し、最終的にはゼロになり、すべてのシンボルが許可されます。これにより、プロトコルの早い段階で短い理想的なシンボルを割り当てることが回避され、後発者が理想的なシンボルを求めて競争することが奨励されます (そのような競争が理にかなっている場合)。
最後に書きます
このソリューションは本当に市場で機能するのでしょうか?わからない。
可能な限りシンプルで、オフチェーン データに依存せず、ネイティブ トークンがなく、ビットコインのネイティブ UTXO モデルに完全に適合します。このようなスキームは、オンチェーンのフットプリントが劣悪な他のスキームからユーザーを引き付け、開発者とユーザーの注意をビットコインに向けて、ビットコイン自体の採用を促す可能性があります。
一方、FTの世界は、欺瞞と貪欲の完全に救いようのない深淵であるため、洗い流される可能性があります。
