BRC-20の行方 ORC-20の登場 マーケットを掴めるか？

ordinalsでは、碑文をjsonでキャストして、それを解読する人は、碑文をわら半紙として使っている確率が高く、すべて中央集権的なサービスに頼りすぎている危険性がある。

1.コンテキスト
brc20には多くの制約があり、コイン名に4文字しか使えない、アップグレードができない、二重消費リスクがある、取引のキャンセルができない、などの制約がある。 ここでは、少し馴染みのない、btcの生態系祖先のフォークモデルをご覧ください。
2.ORC20とは何ですか？
ORC-20は、人気のあるBRC-20 ordered token standardを改善するために、Bitcoinネットワーク上のorder tokenの機能を強化するために設計されたオープンスタンダードです。orc20はBRC-20と下位互換性があり、適応性、拡張性、セキュリティを向上させ、二重支出の可能性を排除しています。
3. orc20の変更点
3.1 初期供給量と最大鋳造量を変更することができる。
これは改善ではないと思います、初期供給量と総量を固定することはデメリットではありません。orc20はオーディナルのミンティング形式をより柔軟にしただけです、固定と柔軟は単なる選択であり、良い悪いというものではありません。
3.2 名前空間に固定的な制限はなく、どんな大きさの名前でも使用できる。
特にbrc20の4文字単語の大半は事前に鋳造されているため、ネーミングは本当に苦痛なポイントである。
3.3 トランザクション中に二重消費がないようにするために、UTXOモデルを使用する。
utxoモデルとは何かというと、これは自分で検索すればわかるのですが、トランザクションを送信する際に、残高もトランザクションとして変更先のアドレスに送信するものです。 これは二重消費の問題に対する適切な解決策となり得る。
例えば、IDが1のORC10,000枚を2つの部分トランザクションに分割して、受取アドレスに送信する。 ステップ1：受信側への送信イベント（nonce 5）を記録して1000を受信側アドレスに送信し、ステップ2：送信側への送信イベント（nonce 6）を記録して残額を送信者に送り返し、残額の送信が完了したときのみトランザクションが完了する。
3.4 トランザクションのキャンセルを許可する
op」：「cancel」を使用し、nonceを使用したトランザクションをキャンセルする。
3.5 配置されたbrc20コインのorc20への転送を許可する。
転送コマンドを操作できるのは、brc20の配備者だけです。
4.orc20の新ルー
4.1 id識別子、デフォルトは1。識別子は同じ識別子を共有するORC-20間でユニークでなければならず、もし同じ識別子と同じidを持つ2つのORC-20があれば、「第1の原則」が適用され、2番目のORC-20は無効となる。
4.2 nonceは、各トランザクションに関連付けられた一意の識別子であり、送信者がそのトランザクションの一部を追跡することができる。 各トランザクションにnonceを含めることで、送信者は各部分トランザクションが一意であり、トランザク ションのセキュリティを損なうような偶発的または悪意あるコピーができないことを保証できる。 nonceがあれば、送信者は、キャンセルトランザクションを送信する際に対応するnonceを指定することによって、特定の部分トランザクションをキャンセルすることもできる。 これは、ORC-20トークン標準に、セキュリティと柔軟性の付加的なレベルを加えるものである。
4.3 "op": "cancel"、特定の部分トランザクションをキャンセルする操作。
4.4 ug フィールド、upgradeable or not: true または false、デフォルトは true、導入者は ORC-20 を後でアップグレードすることができる。
4.5 wp field, migration: true or false, default is false. トークンの移行に使用され、元に戻すことはできない。 オリジナルのBRC-20のデプロイ者のみがマイグレーションイベントをデプロイできる。 ラッパーは、オリジナルの BRC-20 のメタデータをコピーします。例えば、同じ最大供給量と発行制限です。
4.6 バージョン：バージョン：ORC-20 をアップグレードする際に役立つ情報です。 通常、バージョン番号はアップグレードごとに更新されるべきで、これにより契約の異なるバージョンを識別することができ、その後の開発、管理、利用が容易になります。
4.7 msg: メッセージ：カスタム・テキスト、メッセージ、宣言で、大きさは問わない。 このフィールドは、トークンの目的、ビジョン、使用シナリオなど、トークンに関する情報を提供するために使用することができます。 これにより、ユーザはトークンの価値や用途をより理解しやすくなり、トークンに信頼性が加わります。
4.8 Custom Key. カスタム実装にのみ使用される。例：tax - ロイヤリティなどの必須取引税；mint - 特別なミントアドレス；image - トークン画像；tkid - トークンID；url - トークン情報用URL.
これらのオプションフィールドは、標準のORC-20プロトコルで提供されない特別な機能を拡張して、特別なトークンのニーズをカスタマイズするために使用することができます。 例えば、税金は各取引に手数料を請求するために使用することができ、ロイヤリティはオリジナルのクリエイターの作品に請求するために使用することができる、などです。 鋳造者は、トークンを鋳造する許可を与えるために、特別なアドレスを指定することができる、など。
5.ORC20の限界
5.1 複雑さ
ビットコインのエコシステムである序列に基づけば、シンプルであることは利点と言えるが、orc20はbrc20の複雑さに加えて、コイン発行の問題をさらに複雑にしている。 定義が増え、操作が煩雑になると、より多くの問題が発生する傾向があります。 例えば、移動操作では、コインを2枚持ってきてしまう。
5.2 中心性
jsonを使用する目的は検索を容易にすることであり、検索は必然的に中央集権的なサービスを使用することになります。これは、nftの他のアプリケーションを除いて、現在のordinalsエコシステムの当然の欠点です。
5.3 強制的なロイヤリティ
おそらく、取引市場が徴収するロイヤリティの形式をルールに落とし込むのだろう。 コインでロイヤリティを徴収するのは、作者が考えていないことだと思います。 nftとして、自身のプロパティは芸術作品であり、アーティストにロイヤリティを支払うのは理解できますし、作者とホルダーは、創造と使用者の関心事です。 しかし、コイン上では、ホルダーはもっと投資家に近いはずで、プロジェクトにお金を投資し、プロジェクトオーナーにロイヤリティを支払わなければならず、合理的であるとは思えない。
5.4 パス依存性、解釈の仕方によって
orc20が行っていることは、ビットコインの払い出し先をrc20に近づけていることがわかります。 そのため、なぜarc20を使わないのか、という疑問が湧いてくる。
6.まとめ
一言で言えば、orc20はbrc20の制限を取り除き、より多くのオペレーションを定義しています。
実際、オーディナルでコインを発行するコアコンピタンスは中央集権的なサービスであり、この規格ではありません。 中央集権化のリスクを防ぐ唯一の方法は、チェーン上に配置されたすべての認証をクローズドループで形成することです。
brc20の最大の問題は、制限が多すぎることではなく、中央集権に依存していることです。orc20はこの問題を解決していません。orc20はbrc20を競合として扱っており、市場を獲得することを目的としています。