半均質化資産から見た碑文

著者：jolestar、出典：著者のTwitter @jolestar

碑文は技術的に単純で粗雑であり、技術者は初めて見たとき、これは一体何なんだ、と疑問符の絵文字が浮かぶはずです。

しかし、スマートコントラクトの碑文を解析する日々を経て、要約すると、それは実際には半均質資産（SFT）として理解することができます。

もともと、オーディナルインスクリプションは、コンテンツと同様にcontent_typeを含む一意のIDを持つNFT式として理解することができ、任意のデータ型に埋め込むことができます。BRC20プロトコルでは、コンテンツにJSONを埋め込むことでFTを定義しています。 FTはNFTにおける典型的なSFT表現であり、私たちは「シート」を単位とする碑文の取引に慣れています。

また、FTはJSONをコンテンツに埋め込む典型的なSFT表現です。

そして、SFTのシナリオは？これは、前回のDeFiセッションで全員が深く考察したことです。例えば、ゲームの小道具を表現したり、中間のFTの値で希少性を表現したり、債券やクーポン、あらゆるお札の表現にも使えます。しかし、前サイクルではその特性が十分に生かされず、SFT型の資産はあまり作られなかった。そして今、碑文が火を噴き、この種の資産が完全に作成されつつあるが、どのように活用できるのだろうか？

インスクリプションの現在のスケーラビリティのジレンマ

インスクリプションがSFTとしての強みを生かすには、その使用のためのシナリオを作成し、インスクリプションのプロトコルを拡張しなければなりません。すでにいくつかのチームは、例えばBRC20にさらに多くのopコマンドを追加するなど、碑文プロトコルを拡張することでこれを実現しようとしています。しかし、いったんインスクリプション・プロトコルが市場に広く受け入れられると、複数のインデクサの実装が存在することになります。 プロトコルを拡張するためには、複数のインデクサがチェーンの下でコンセンサスを得て、コンセンサスのアップグレードを達成しなければなりません。このアップグレードの難易度は、L1コンセンサスのアップグレードの難易度に劣らず、スケーラビリティの要求を満たすことは非常に困難であることは明らかです。

そして、このスケーラビリティの要求のために、業界は実際に一連の成熟したプログラム、つまりスマートコントラクトを作り上げた。ブロックチェーンのスマート・コントラクト仮想マシン・モデルは、ソフトウェア・エンジニアリング・コミュニティ全体が考え出した最もスケーラブルなモデルです。1.インデクサーにスマート・コントラクトを導入する。

インデクサにスマート・コントラクトを導入する

インデクサにスマート・コントラクトを導入することは、スマート・インデクサ、またはモジュール型ブロックチェーンの実行層と呼ぶことができます。Mingwenのモデルは、L1をDAとし、シーケンサーを導入せず、L1のブロックを介して直接トランザクションをソートする、DAファーストのソブリンロールアップとして理解することができ、インデクサは当然、実行レイヤーとして理解することができる。このモデルについては、「インスクリプションはバグか、それとも機能か」という記事で説明している。 Rooch氏もこの方向性を模索しており、What Should Bitcoin's Layer2 Do?

私たちはこのシナリオのためのサンプルゲーム「Bitcoin Plants」を作っています。Roochにはビットコインのステートが一杯あるので、スマートコントラクトでOrdinalsのInscriptionを読み取ることができ、ユーザーはあるInscriptionを種としてゲーム内で植物を育てることができ、その植物はユーザーによって定期的に水や灌漑をする必要があり、そうすると実をつけることができます。この植物は碑文にバインドされており、ユーザーがビットコイン上の碑文を譲渡すると、植物も譲渡されます。この単純な例は、実行レベルのスマートコントラクトを通じてL1のインスクリプションの使用シナリオを作成する方法を示している。詳細はgithub issue https://github.com/rooch-network/rooch/issues/1214。

また、Ethscriptionsは同様の路線でファセットVMを構築していることが確認されており、業界の友人たちもこの方向性を見ているようです。

スマートコントラクトを通したインスクリプションの表現

どちらかというと、ビットコインにあるのはスマートコントラクトがないからで、開発者はJSONをインスクリプションする方法を考え出しました。なぜ他のスマートコントラクトチェーンはいまだにJSONを書いているのか？最も理解できないのは、ロールアップL2にJSONを書くことだ。そのJSONは最終的にL1にロールアップされるのに、なぜL2に書きに行くのだろうか？L2は自然にL1碑文のインデクサーになるべきではないのか？しかし、そうはいっても、碑文を弾こうとするユーザーの熱意を止めることはできない。

1.半均質な資産であるため、FTほど流動性は高くないが、市場の立ち上げ期には有利である。

2.各チェーンのFTよりも資産発行の敷居が低く、認知コストが低い。各チェーンでの資産発行には一般的にスマートコントラクトの導入が必要で、認知も主にコントラクトアドレスによるため、初心者には敷居が高い。そして、インスクリプションの波は基本的にこの敷居を最小限に抑えている。

3.その公正な発行モデルは、ビットコイン上では、Gasがマイナーの鉱山をリースすることによるPoW発行モデルとして理解できます。

では、なぜスマートコントラクトを使って、これらの機能をすべて備えたインスクリプションプロトコルを実装しないのでしょうか？そこで今週、私はMoveを使ってMovescriptionsプロトコルを実装してみました。

まず第一に、これはMoveで表現されたセミホモジニアスアセットプロトコルであり、そのデータ構造ベースのアセット表現はこのようなプロトコルを表現するのに理想的です。

1.タイプは、BRC20から借用したグローバルにユニークな名前であるtickで表現されます。

2.valueは、FTのバランス、またはNFT内部のキー値を表現するために使用できます。

3.メタデータはどのようなタイプのデータにも添付できます。

第二に、PoWによる資産の配布をサポートしています。デプロイ者は難易度を指定することで、資産の分配がより公平で分散化されたものになるように設定できます。他のチェーンのGasが低すぎるため、Gasを燃やすことによる魔女攻撃を防ぐことが難しい。

そして、このようなスマートコントラクトによる碑文は、私はスマート碑文と呼んでいますが、最終的にはスマートコントラクトを必要とするところまで進化します。 このような碑文は、当然ながらスマートコントラクトの状態であり、インデクサに依存しないため、FOCGのような様々なアプリケーションシナリオと組み合わせやすい。この実験に興味のある方は、@movescriptionをフォローし、github https://github.com/movescriptions/movescriptionsをご覧いただきたい。現在のRoochバージョンのコントラクトは初期に完成しており、PoW配布が実装され、他のMove chainバージョンも進行中です。

開発者にとってのInscriptionsの意味

InscriptionsはBitcoinでのランダムな実験として始まり、今ではパブリックチェーンを席巻しています。その将来は不確かであり、それをどう見るかについて多くの意見の相違がありますが、それが市場の興味深いところです。そこで、さらにランダム性を追加して、開発者が行動できるようにしよう。ユーザーに使い方のわからないJSONの束を書き込ませる代わりに、スマートコントラクトと組み合わせられないか試してみよう。もしうまくいけば、FOGCやAWを立ち上げるための起爆剤になるかもしれない。