ORC-20トークンを解説：オーディナルズエコシステムにおける新たな発行ルール
TechFlow厳選深潮セレクト
ORC-20トークンを解説：オーディナルズエコシステムにおける新たな発行ルール
orc20はbrc20のいくつかの制限を解除し、より多くの操作を定義している。
Web3業界の深掘り報道に専念し潮流を洞察*TechFlowはxiyuの許可を得て転載しています。
Ordinalsにおいて、JSONを使ってインスクリプションを鋳造し解釈するものは、ほぼ確実にインスクリプションを一時的な用途（草稿用紙）として使い捨てており、中央集権型サービスへの過度な依存というリスクを伴います。
1. 背景
BRC20には多くの制限があります。これには、通貨名が4文字に限定されること、アップグレード不可能であること、二重使用（ダブルスペンディング）のリスク、取引キャンセル不可などが含まれます。Orc20はこれらの制限を撤廃することを目指しており、ある意味BRC20のハードフォークと言えるでしょう。ここで何となく馴染み深い感じがしませんか？ BTCエコシステムで伝統的に繰り返されてきたフォークのパターンです。
2. Orc20とは何か？
ORC-20は、広く普及しているBRC-20オーダードトークン標準を改善するために、ビットコインネットワーク上のオーダードトークン機能を強化することを目的としたオープンな規格です。Orc20はBRC-20との下位互換性を持ちつつ、適応性、拡張性、セキュリティを向上させ、二重使用の可能性を排除します。
3. Orc20の変更点
3.1 初期供給量および最大鋳造量の変更が可能。これは進歩とは言えません。初期供給量と総量の固定は欠点ではなく、Orc20は単にOrdinals上での発行形態をより柔軟にしただけです。固定か柔軟かは選択の問題であり、優劣ではありません。
3.2 名前空間に固定制限がなく、任意の長さの名称を使用可能。命名は確かに課題でした。特にBRC20のほとんどすべての4文字単語が事前に鋳造され尽くされている現状では顕著です。
3.3 UTXOモデルを採用することで、取引中に二重使用が発生しないように保証。UTXOモデルについては各自検索してください。要するに、送金を行う際、残高も一つのトランザクションとしておつりアドレスに送られる仕組みです。これにより、ある程度ダブルスペンディング問題を緩和できます。
例えば、IDが1のORCを10000個持っている場合、これを2つの部分取引に分けて受信アドレスに送信できます。各取引には一意のnonceが必要です。ステップ1：受信者に送信イベントを記録し、受信アドレスに1000個（nonce=5）を送信。ステップ2：送信者自身に残高を戻すイベントを記録し、残りの残高を送信元に戻す（nonce=6）。この残高の返却が完了して初めて、取引が完了します。
3.4 取引のキャンセルが可能。「"op": "cancel"」を使用すれば、特定のnonceに関連する取引をキャンセルできます。
3.5 既に展開されたBRC20トークンをOrc20へ移行可能。ただし、移行操作はBRC20の展開者のみが実行可能です。
4. Orc20が追加したルール
4.1 id識別子、デフォルト値は1。識別子は同じ識別子を持つORC-20間で一意である必要があります。同じ識別子と同一IDを持つORC-20が2つ存在する場合、「第一原則」が適用され、後から登場したORC-20は無効となります。
4.2 nonceは各取引に関連付けられた一意識別子であり、送信者が部分取引を追跡できるようにするものです。各取引にnonceを含めることで、送信者は各部分取引が一意であることを保証でき、誤ってまたは悪意を持って複製されるリスクを防げます。そうでなければ取引の安全性が脅かされます。また、nonceがあれば、送信者は「キャンセル取引」を送る際に対応するnonceを指定することで、特定の部分取引をキャンセルできます。これにより、ORC-20トークン規格に追加のセキュリティと柔軟性がもたらされます。
4.3 「"op": "cancel"」、特定の部分取引をキャンセルする操作。
4.4 ugフィールド（アップグレード可否）：trueまたはfalse、デフォルト値はtrue。展開者が後からORC-20をアップグレードできるようにします。
4.5 wpフィールド（移行）：trueまたはfalse、デフォルト値はfalse。トークン移行を目的としており、一度設定すると逆戻りできません。元のBRC20の展開者のみが移行イベントを展開可能です。このラッパーは、元のBRC20のメタデータ（最大供給量や発行制限など）をコピーします。
4.6 Version（バージョン）：ORC-20をアップグレードする際に有用な情報です。通常、アップグレードのたびにバージョン番号を更新すべきであり、これにより異なるバージョンのコントラクトを識別でき、今後の開発・管理・利用が容易になります。
4.7 msg（メッセージ）：カスタムテキスト、メッセージ、宣言などを任意のサイズで設定可能。このフィールドは、トークンに関する情報を提供するために使用できます。たとえば、トークンの目的、ビジョン、使用シナリオなどです。これによりユーザーはトークンの価値と用途をよりよく理解でき、信頼性も高まります。
4.8 Custom Key（カスタムキー）。カスタム実装専用です。例：税金（強制取引手数料）、ロイヤリティ、鋳造者（特別な鋳造アドレス）、画像（トークンのイメージ）、tkid（トークンID）、url（トークン情報のURL）など。
これらのオプションフィールドは、特殊なニーズを持つトークンのカスタマイズに使用でき、標準的なORC-20プロトコルが提供しない特殊機能を拡張できます。例えば、税金は毎回の取引時に一定の手数料を徴収するために使え、ロイヤリティはオリジナルクリエイターに作品使用料を支払うために使えます。鋳造者は、特別なアドレスを指定して、そのアドレスにのみ代幣の鋳造権限を与えることも可能です。
5. Orc20の限界
5.1 複雑さ。ビットコインエコシステムのOrdinalsにおいては、シンプルさ自体が利点になり得ますが、BRC20がすでに発行問題を複雑化している上に、Orc20はさらにそれを複雑化しています。より多くの定義、煩雑な操作は、新たな問題を引き起こしやすくなります。例えば、移行操作により、同じトークンが2つ存在する状況が生まれます。
5.2 中央集権化。JSONを使う目的は検索を容易にすることですが、検索には必然的に中央集権型サービスが必要になります。これは現在のOrdinalsエコシステムにおいて、NFT以外のアプリケーションが抱える根本的な弱点です。
5.3 強制ロイヤリティ。つまり、取引市場におけるロイヤリティ徴収の仕組みを規則として組み込んだものです。私は、通貨にロイヤリティを設ける発想は本質を見誤っていると思います。NFTの場合、それは芸術品という属性を持ち、アーティストにロイヤリティを支払うのは理解できます。作者と所有者は、創作者と使用者という関係です。しかし、通貨の場合、保有者はむしろ投資家に近い立場です。投資家がプロジェクトに資金を提供した上で、さらにプロジェクト側にロイヤリティを支払うのは、理にかなっていないように思えます。
5.4 パス依存。分析すると、Orc20が行っているのは、ビットコイン上での発行方式をRC20に近づけようとしていることです。それならば、なぜERC20を使わないのかという疑問が生じます。
6. 結論
一言でまとめると、Orc20はBRC20のいくつかの制限を解除し、より多くの操作を定義したということです。
実際、Ordinals上で通貨を発行する場合の核心的競争力は規格ではなく、むしろ中央集権型サービスにあるのです。認証を含めたすべてのプロセスがチェーン上で完結して初めて、中央集権リスクを回避できるのです。
BRC20の最大の問題は制限が多いことではなく、中央集権サービスへの依存です。Orc20はこの問題を解決していません。Orc20はBRC20を競争相手と見なし、市場の奪取を狙っているのです。Orc20がOrdinalsエコシステムに与える影響は限定的であり、BRC20に対する影響もそれほど大きくはありません。
TechFlow公式コミュニティへようこそ
Telegram購読グループ：https://t.me/TechFlowDaily
Twitter公式アカウント：https://x.com/TechFlowPost
Twitter英語アカウント：https://x.com/BlockFlow_News
xiyu
