ERC 1155 NFT スマート コントラクトのセキュリティ分析

ERC 1155 NFT スマート コントラクトのセキュリティ分析

ERC 1155 NFT スマート コントラクト PlatoBlockchain データ インテリジェンスのセキュリティ分析。垂直検索。あい。

読み取り時間: 5

暗号通貨トークンについて聞いたことがあるはずです。 そこにあるさまざまなトークンは、web3 エコシステムで重要な役割を果たします。 これらのトークンは、暗号通貨における所有権、富、信頼性、および権限を表しています。 面白いのは、暗号通貨のトークンを作成できることです。 

これらのトークンは、転送、残高チェックなどのさまざまなアクションのためのさまざまな機能を含むスマート コントラクトです。スマート コントラクトを作成することで、トークンを作成できます。 それでも、トークンが安全であることを保証し、それに信頼感を与えるために、ERC 20 は スマートコントラクト標準 ERC 721 は、非代替トークン (NFT) の作成に使用されるスマート コントラクト標準です。

ERC 20 と ERC 721 は、トークン作成用のスマート コントラクト プロトコルとして広く受け入れられています。 それらは、トークンに安全で信頼できる環境を提供します。 そして、これらのプロトコルは改善され続け、改善され続けています。 その方向への一歩は、トークン用の新しい ERC 1155 スマート コントラクト プロトコルの作成につながります。 それが何であるか見てみましょう。

1. ERC 1155 とは?

20 や 721 などのすべての ERC は、NFT のさまざまな状況に適合するスマート コントラクトを作成するための単なる標準です。 ERC 721 があり、USDT や DAI などの代替トークンは ERC 20 規格に準拠しています。 ERC 1155 は、ERC 20 および ERC 721 の機能と特性を含む標準の XNUMX つです。

複数の商品を作成するプログラムを作成するとします。 たとえば、金という名前のトークン、銀という名前の別のトークン、および 3 人のキングを作成したい場合、ロジックでは、金と銀の数が多い方がキングになります。 王は一人しか存在できません。 これは単純なプロトコルですが、これを作成するには、資産のためだけに 721 つのコントラクトをデプロイする必要があります。XNUMX つはゴールド トークン用、もう XNUMX つはシルバー用、もう XNUMX つはキング用で、ERC XNUMX になります。それらすべての異なるトークンをリストする XNUMX つのコントラクト?

これは、ERC 1155 が解決するそのような問題の 1155 つです。 ブロックチェーンに必要なトークンごとにコントラクトをデプロイする必要はありません。 これはそのような ERC 3 コントラクトの例の 1155 つです。 いくつかの代替可能、いくつかの代替不可能な、複数のアセットを備えたこのタイプのシステムが必要な場所を推測してください。 答えは web3 ゲームです。 ERC XNUMX は、WebXNUMX ゲーム開発者にオンチェーン トランザクションのスケーラビリティとスムーズな開発を可能にします。

1.1 ERC 1155 のトークン ID

さまざまな ERC 20 トークンの残高を確認する方法を知っておく必要があります。 balanceOf(address _owner) 関数を使用すると、そのアドレスが保持するトークンの数を取得できます。 しかし、ERC 1155 はさまざまなトークンを扱うため、さまざまなトークンにさまざまな ID を提供する必要があります。 トークンに関連するほぼすべての関数は、tokenId (照会したい資産) と知りたいアドレスの少なくとも XNUMX つのパラメーターを取ります。

たとえば、コントラクトに金、銀、王の 3 つのトークンがあるとします。 特定のアドレスがそのプロトコルでどれだけのゴールドを持っているかを知るには、関数 balanceOf(住所 _オーナー、 単位256 _id) スマート コントラクト。 gold の tokenId が 1 に指定されているとします。 残高の(0x4Bf9DeCE75Bc7C4a9054d5b3BB13D53543eE4096、1).

2 スマート コントラクト ERC 1155 の監査ガイドライン

ERC 1155 はしばらく前から存在しており、一部の機能は通常の ERC 20 または ERC 721 プロトコルでは利用できません (バッチ転送など)。 また、ERC 1155 は市場空間であまり普及していないため、この分野は多くの開発者にとってあまり調査されていません。 QuillAudits は、ERC 1155 で BUIDL を検討しているプロトコルに関する重要な洞察を共有しているため、自らを保護することで、より安全な web3 エコシステムの作成を支援できます。 

2.1 ERC 1155 受信機インターフェース

ERC 1155 コントラクトがアセットを他のコントラクトに転送する場合、これは一般に web3 ゲーム プロトコルの要件です。トークンのトランザクションを成功させるには、受信コントラクトに ERC1155Receiver インターフェイスを含めることが重要です。

ERC 1155 レシーバー インターフェイスに含まれる XNUMX つの機能は次のとおりです。

  • onERC1155Received(オペレーター、送信元、ID、値、データ)
  • onERC1155BatchReceived(オペレーター、送信元、ID、値、データ)

両方の関数はほとんど同じ機能を持っています。唯一の違いは、後者が一度に複数のトランザクションを処理する場合であるため、バッチという名前です。パラメータと戻り値にはわずかな違いがあります。 ただし、ここでは onERC1155Recieved についてのみ説明します。 

この関数は、ミントまたは転送プロセスの外で呼び出してはなりません。 転送を受け入れるには、転送が許可されている場合、bytes4(keccak256(“onERC1155Received(address,address,uint256,uint256,bytes)”)) を返す必要があります。

パラメータを見る: -

  1. operator:- 転送を開始したアドレス (つまり、msg.sender) 
  2. from:- 以前にトークンを所有していたアドレス
  3. id:- 転送されるトークンの ID 
  4. value:- 転送されるトークンの数 
  5. data:- 指定された形式のない追加データ 

2.2 承認()関数がない?

ERC 20 または ERC 721 を使用したことがある場合は、承認されたトークンを所有者の残高から取得することを一部のアドレスに許可する、approve() 関数に出くわしたことでしょう。 たとえば、A が B が 100 トークンの DAI を取得することを承認したい場合、A は承認関数を呼び出して、B が 100 DAI トークンを受け取る資格があることを伝え、後で B がその金額で取引を行うことができます。

しかし、ERC 1155 には 承認する 単一トークンの関数。 私たちは setApprovalForAll(アドレス演算子、bool 承認済み) この関数は所有者によって呼び出され、使用者のアドレスまたはトークンを承認したいアドレスであるアドレス パラメーター演算子を受け取ります。 したがって、を呼び出すことはできません 承認する トークンの ERC 1155 リストから単一のトークンを機能または承認しますが、代わりに、すべてのトークン アクセスが一度に承認されます。 開発チームはこれを認識する必要があります。 これを無視すると、大規模な損失につながり、プロトコルが危険にさらされる可能性があります。

2.3 定期的なチェック

上記の 1155 つのセクションでは、ERC XNUMX 関連の固有のチェックのうちの XNUMX つを調査しました。 このセクションでは、あまり深い説明を必要としない定期的なチェックについて説明します。

  1. ID に注意してください:- ERC 1155 で動作するすべての外部関数またはインターフェイスは、トークン ID を入力として受け取るように指定する必要があります。
  2. Burn/Mint:- これらの関数が呼び出されるたびに、指定されたトークン ID の残高と totalSupply のみを変更する必要があります。
  3. ERC 20 の類似性:- 多くのプロパティは、ERC 20 トークン標準に似ています。 ERC 20 のセキュリティ ガイドラインを確認することも、この問題に役立ちます。
  4. 再入口:- 説明したように、ERC 1155 は転送ロジックでサポートされているインターフェイスをチェックします。 したがって、結果として生じる可能性のあるさまざまなシナリオが存在する可能性があります 再突入の脆弱性. 該当する関数に非再入可能ガード修飾子を保持することをお勧めします。

3. まとめ

Web3 エコシステムでは、セキュリティと機能を強化するために、通常の標準で継続的な開発が行われています。 ERC 1155 はその方向への一歩です。 しかし、新しい標準がリリースされると、プロトコルのあまり一般的ではない標準に関する知識のギャップが生じ、セキュリティ対策のためのサンプル スペースが小さくなるというリスクが伴います。 そんな時こそ、QuillAudits と専門家チームの出番です。 私たちは、プロトコルが侵害される可能性のあるさまざまな方法に取り組み、分析し、発見し、信じられないほどの結果でクライアントのプロトコルを保護します. 私たちの Web サイトにアクセスして、Web3 プロジェクトを保護してください!

17 ビュー

タイムスタンプ:

より多くの クイルハッシュ