2月1日、CoinのWeb3ウォレットは、BRC-20やEVMなどの様々な碑文プロトコルをサポートする碑文マーケットプレイスを正式に開始した。数日前、OKXもARC-20、Runes、Doginalsやその他の碑文プロトコルのサポートを発表し、碑文市場全体の注目を集めるきっかけとなった。このような背景の中、碑文プロトコルの複雑さと新規性により、様々なセキュリティ問題が頻発している。これはユーザーの資産の安全を脅かすだけでなく、碑文エコシステム全体の健全な発展にも悪影響を及ぼしています。
これを受けて、Beosinのセキュリティチームは、主流の碑文プロトコルを調べ上げ、その使用目的、実装方法、碑文資産の保護方法をユーザーに理解してもらえるようにしました。
BRC-20のようなビットコインのパブリックチェーン碑文の最初の出現から、碑文のための新しいプロトコルが無限に存在し、ほぼ毎日新しいプロジェクトが現れる現在の碑文エコシステムに至るまで、碑文エコシステムは新しい碑文、新しいプロジェクトが爆発的に増加しています。そして新しいプロジェクトが登場することで、碑文の発展は急上昇したと言える。ETHパブリックチェーンのEthscriptionプロトコル、BTCパブリックチェーンのARC-20プロトコル、BSCパブリックチェーンのBSC-20やその他のプロトコル、PolygonパブリックチェーンのPRC-20やその他のプロトコルなど、さまざまな一般的なパブリックチェーンも碑文エコシステムに参加しています。これらのプロトコルはすべて、それぞれのパブリックチェーン上で碑文を公開するために作成されました。次のセクションでは、さまざまなプロトコルがどのように実装されているのか、またどのような使用例があるのかを説明します。
BTCはUTXOモデルを採用しており、トランザクションはUTXO(Unspent Transaction Outputの略)単位で送金されます。UTXOモデルは、最終状態を記録せずにトランザクションイベントを記録するという点で、イーサなどのパブリックチェーンのアカウントモデルとは異なります。特定のユーザーが何枚のビットコインを持っているかを計算するには、そのユーザーのアドレスのUTXOをすべて合計します。Ordinalsは、ビットコインの最小単位であるサトシ(sats)に番号を付けるための体系的なプロトコルであり、各UTXO(複数のサトシを含む)内の各サトシに固有の番号を割り当てます。Ordinalsはまた、テキスト、画像、オーディオ、ビデオなどでサトシを書き込む機能をサポートしており、そのため、ビットコインNFTと呼ぶおなじみのイーサリアムの非均質トークンNFTと同様に、各サトシを一意にすることができます。BRC-20の創設者たちは、Ordinalsプロトコルに基づく別のアイデアを思いつきました。Ordinalsプロトコルは各Satoshiに異なる "プロパティ "を与えることでBitcoin NFTを作成できるため、統一された "フォーマット "と "プロパティ "を与えることでBitcoin NFTを作成できる。"均質化されたトークン"、すなわちビットコインFTを作成するために。
BRC-20は、Ordinalsプロトコルを使用して、統一されたJSON形式のテキストデータをBRC-20トークンの帳簿であるSatoshiに書き込み、トークンの保有と移動を解析します。
上記はBRC-20の3つの規格で、opフィールドは実行されるオペレーションを示し、デプロイ(展開)、ミント(mint)、トランスファー(transfer)があり、tickは操作を行う必要があるトークンの名前、maxはトークンの総発行量、limはトークンあたりの最大造幣数、amtは操作が必要なトークンの数を示す。
link: https://twitter.com/blockpunk2077/status/1725513817982136617
2.ARC-20
ARC-20は現在もビットコイン・パブリックチェーン上のインスクリプション・プロトコルであり、BRC-20プロトコルと同様に、UTXO内部に標準化されたデータを書き込むことで実装されますが、ARC-20プロトコルは、データの中でARC-20トークンの数を指定する必要がなく、代わりにUTXOの中でサット(satoshi、ビットコインの最小単位)を使ってARC-20トークンの数を表し、1サット=1ARC-20トークンというルールになっていることです。
ARC-20プロトコルも、BRC-20プロトコルと同様に、デプロイメント、ミンティング、トランスファーの3段階に分かれています。デプロイメント段階では、UTXOに標準トークン名、トークンの総数、ミンティング制限、ブロック情報、画像情報などを記入する必要があります。ミンティング段階では、ユーザーがUTXOにトークン名を記入する必要があり、このUTXOのサット数がARC-20トークンのUTXOのサット数は、鋳造されたARC-20トークンの数であり、トークンの名前とともにUTXOのサット数ではありません。一旦ユーザーがARC-20トークンを鋳造したら、ユーザーはトークンを他のアドレスに送ることができ、トークンを送るときにUTXOにデータを記入する必要はありません。代わりに、ユーザーはトークンを保持しているUTXOを他のアドレスに直接転送するだけです。
リンク: ;https://twitter.com/blockpunk2077/status/1725513817982136617
ARC-20トークンを照会する際に必要なインデックスは1つだけで、オフラインのインデックス作成サーバーがトークン登録情報を読み取ることができます。鋳造やトランザクションの送金と同様に、サーバーが資金移動関係を計算する必要はなく、トークンを保有するUTXOのサット数を直接読み取ることで、クエリーアドレスが所有するARC-20トークンの数を取得できます。
BRC-20とARC-20について学んだ後、なぜ誤って他のアドレスにインスクリプション資産を転送したり、「燃やしたり」する人がいるのかを知る必要があります。
BRC-20やARC-20のようなBTCインスクリプション・プロトコルはUTXOトランザクションに基づいているため、インスクリプション・トランザクションは実際にはBTCトランザクションに付随しており、ユーザーはインスクリプションを十分に理解しないまま通常のBTC送金を行い、今あるUTXOやその他のUTXO資産を他のアドレスに移してしまう可能性があります。UTXOと他のUTXOが融合・分割され、意図しないアドレスに送信され、その結果、碑文資産が誤った方向に移動したり、「燃やされたり」して、不可逆的な損害が生じます。
3.Ethscription
Ethscriptionは、イーサ上でデータを作成し共有するために使用されるプロトコルです。EthscriptionはEther上でデータを作成・共有するためのプロトコルであり、いくつかのinscriptionはトークン発行のためのスマートコントラクトの代替としてこのプロトコルを使用し、ユーザーへのコストを非常に低いレベルに抑えるソリューションです。
イーサリアムは、トランザクションを送信する際にcalldataブロックを提供します。これは、通常のETH送金では空白のままであり、スマートコントラクトへの呼び出しであれば、呼び出し関数の署名と各パラメータのデータとして指定されます。Ethscriptionプロトコルは、calldataブロックを利用して、通常のETH送金が送信される際に、それに意味を持たせるための標準データを追加します。
Ethscriptionはこの標準データをどのように指定しているのでしょうか?
まず、画像データでEthscriptionを作成したい場合、画像(画像サイズは96KBに制限されています)を(data:image/png;base64,...)形式でBase64エンコードされたデータのURIに変換する必要があります。次に、そのURIを16進数文字列に変換します。Ether経由でターゲットのアドレスに通常の転送トランザクションを送信し、calldataに上記の16進数文字列を次のように入力します:
こうすることで、0xf1bfアドレスがEthscriptionを所有し、同じcalldataで後から作成されたEthscriptionは無効とみなされます。
Ethscriptionを転送するには、Ethscription所有者は受信アドレスに通常の転送を送り、Ethscriptionを作成したトランザクションのハッシュでcalldataを埋める必要がある。Ethscription, as follows:
4.EVMブロックチェーンの碑文
BSC Chain、イーサリアム、ポリゴンなどのEVMブロックチェーンには、共通の碑文焼付け方法があります。データブロックを使って固定フォーマットのデータを保存する方法であり、上記のcalldataに標準フォーマットのテキストデータを書き込んで画像データを保存する方法とは異なる。
BSCチェーンに銘刻を書き込む場合、銘刻フォーマットはBRC20の銘刻フォーマットに似ています。例えば、銘刻フォーマットは次のようになります:data:,{"p":"_", "op":"_", "tick":"_", "amt":"_"}ここで、pフィールドはpフィールドはプロトコル名、例えばbsc-20、bnbs-20、ltc-20、bep-20、drc-20、nrc-20、src-20など、opフィールドはオペレーション、通常は「mint」、tickフィールドはトークン名、amtフィールドはトークンの数を表す。amtフィールドはトークンの数を表す。
bnbsトークンを例にとると、通常の転送がターゲットアドレスに送信される限り、calldataをデータで満たすことがわかります:{"p": "bsc-20", "op": "mint", "tick": "bnbs", "amt"bnbs トークンの鋳造が完了すると、以下のようになる。この時点で、0x22efアドレスには1000個のbnbsトークンがある。
次はトークンの送金ですが、これも上記と同じです。受信アドレスに通常の転送を送信し、bnbs トークンを作成したトランザクションのハッシュを calldata に記入する必要があります。7176026_image3.png">
イーサリアム、ポリゴンや他のチェーンも基本的に同じですが、一点に注意を払う必要があり、上記のBSCチェーンの内容は、evmチェーン上の碑文の作成の唯一のケースではなく、異なるevmチェーンまたは異なるプロトコルの間に記入されたテキストデータのフィールドです。異なるevmチェーンや異なるプロトコルの間では、記入されるテキスト・データ・フィールドやトークンの転送方法に違いがあるかもしれない。 しかし、これらのタイプのアプローチでは、すべてEVMチェーンのcalldata属性を使用してこれを実現します。
まとめ
この投稿では、複数のチェーンでのインスクリプションの実装の原則について説明しました。要約すると、導入されたインスクリプションは、いくつかのパブリックチェーンシステムの機能を使って、所定の基準に従ってオフライン情報をブロックチェーンに保存し、オフラインサーバーを通じて識別して表示するプロセスです。導入されたこれらのインスクリプションはいずれもスマートコントラクトを使用しておらず、ユーザーは参加する際に取引にかかる多くの追加コストを削減することができますが、ユーザーはインスクリプションの誤譲渡や誤焼却を回避するために、インスクリプションプロトコルの実装を十分に理解する必要があり、その結果、資産を失うことになります。