基本的なERCの解説
ERC-20
Ethereumのブロックチェーン上で使われるトークンの標準規格の一つ。この規格に従って作られたトークンは、「ERC-20トークン」と呼ばれるよ。要するに、ERC-20はトークンがどうやって振る舞うべきか、どんな機能を持っているべきかっていうルールを定めている。
例えば、トークンの総量を取得する機能や、誰かにトークンを送る機能、他の人があなたのトークンを使えるように許可する機能などが含まれている。これらの基本的な機能を備えていることで、ERC-20トークンはEthereumネットワーク上で広く交換されたり、ウォレットや取引所などのアプリケーションで使われる。
この文書は、スマートコントラクト内で使われるトークンのための標準APIを定義する標準について説明している。主な目的は、トークンを転送する基本機能と、トークンが他のオンチェーン第三者によって使用されることを承認する機能を提供すること。
この標準を採用することで、Ethereum上のトークンを他のアプリケーション、例えばウォレットや分散型取引所などで再利用できるようになる。
具体的には、トークンの名前やシンボル、小数点以下の桁数、総供給量などの基本情報を取得するための関数が含まれている。
また、トークンの転送や、他のアカウントが特定の量のトークンを転送することを許可するための機能も定められている。
重要なのは、トークン転送時に「Transfer」イベントが発生すること、また、トークンの使用を許可する際には「Approval」イベントが発生すること。これらのイベントはトランザクションの透明性を高めるのに役立つ。
標準の設計ではセキュリティ面も考慮されていて、特に「approve」関数を使う際のセキュリティ対策が述べられている。
具体的には、許可される量を変更する前に、まず許可量を0に設定することが推奨されている。これは、特定の攻撃手法を防ぐため。
この標準は、開発者がトークンを扱う際のガイドラインとして機能し、Ethereum上でのトークンの互換性と再利用性を高めることを目指しているんだ。
既に多くのERC20準拠のトークンがEthereumネットワークに展開されており、それぞれがガスの節約やセキュリティの向上など、異なる特徴を持っている。
主な関数定義
基本情報の取得
function name() public view returns (string): トークンの名前を返す。
function symbol() public view returns (string): トークンのシンボルを返す。
function decimals() public view returns (uint8): トークンが使用する小数点以下の桁数を返す。
function totalSupply() public view returns (uint256): 総トークン供給量を返す。
function balanceOf(address _owner) public view returns (uint256 balance): 特定のアドレスのトークン残高を返す。トークンの転送
function transfer(address _to, uint256 _value) public returns (bool success):
_valueの量のトークンを_toアドレスに転送し、成功したらtrueを返す。
function transferFrom(address _from, address _to, uint256 _value) public returns (bool success):
_fromから_toへ_valueの量のトークンを転送し、成功したらtrueを返す。この関数は、
トークンの所有者が別のアドレスにトークンを転送することを許可している場合に使用される。トークンの承認と許可
function approve(address _spender, uint256 _value) public returns (bool success): _spenderが_valueの量のトークンを転送することを許可する。
function allowance(address _owner, address _spender) public view returns (uint256 remaining): _spenderが_ownerから引き出すことができる残りのトークン量を返す。イベント
event Transfer(address indexed _from, address indexed _to, uint256 _value): トークンが転送されるたびにトリガーされるイベント。
event Approval(address indexed _owner, address indexed _spender, uint256 _value): approve関数が成功したときにトリガーされるイベント。ERC-721
これはユニークなトークン、つまり「ノンファンジブルトークン」(NFT) を作成するための規格。アート作品やコレクティブルなど、一点物のデジタルアイテムを表現するのに使われることが多い。
ERC-721スマートコントラクト内のすべてのNFTは、一意のuint256 IDによって識別されます。この識別番号は契約期間中変更されることがなく、コントラクトアドレスとuint256 tokenIdのペアは、イーサリアムチェーン上でその特定アセットをグローバルに一意に識別します。
いくつかのERC-721スマートコントラクトはIDを0から始めて新しいNFTが作成されるごとに1ずつ増やす方法を採用していますが、ID番号に一定のパターンを期待してはならず、IDを「ブラックボックス」として扱うべきです。NFTが無効化（破棄される）可能性がある点も重要です。さらに、UUIDやsha3ハッシュをuint256に直接変換できるため、uint256を使用することで多様な応用が可能になります。
注意事項
Solidity 0.4.20のインターフェース文法では、ERC-721標準の全ての側面を十分に表現することができない。そのため、ERC-721に準拠するコントラクトは、特定の変異性保証（関数が状態を変更するかどうかの指示）を含むインターフェースの要件を満たす必要がある。例えば、インターフェースのpayable関数は、コントラクト内でnonpayableとして実装される場合がある。
ERC721MetadataやERC721Enumerableを実装する場合、ERC721インターフェイスも実装しなければならない（SHALL）。ERC-721はERC-165インターフェイスの要件を含んでいる。
この仕様で関数が外部として指定されている場合、コントラクトがpublic visibilityを使っていても準拠していると見なされる。Solidityのバージョン0.4.20で、コントラクトを継承する前にインターフェイスを編集してpublicに変更することが回避策として提案されている。
this.*.selectorの使用はSolidityによって警告としてマークされる。
最後に、Solidityの新しいバージョンでこれらの注意事項をコードで直接表現できるようになった場合、このEIPは更新されて注意事項が削除される可能性がある。
ERC-1155
「マルチトークン標準」とも呼ばれる、イーサリアムのブロックチェーン上で様々な種類のトークンを扱うためのスマートコントラクトの規格の一つ。この規格は特にゲームやデジタル資産の取引、仮想世界（メタバース）でのアイテム管理などに適していて、ERC-20やERC-721といった既存のトークン標準に比べて、いくつかの大きな進歩を提供している。
ERC-1155は「単一コントラクトで複数のトークンタイプをサポートする」という点が大きな特徴。ERC-20は通貨やユーティリティトークンに特化していて、ERC-721は一意のデジタルアイテムやコレクティブル（NFT）に適している。これに対し、ERC-1155はこれらの機能を統合し、さらにそれらを拡張して、一つのコントラクト内で複数の異なるトークンタイプを管理できるようにし、効率性の向上した。
ゲーム内でプレイヤーが複数のアイテムを交換する場合、ERC-721を使っていると、各アイテムごとにトランザクションを行う必要がある。
しかし、ERC-1155を使えば、複数の異なる種類のアイテムを一つのトランザクションで送信することができる。これにより、トランザクションコストを削減し、ブロックチェーン上での操作をより効率的にすることが可能になる。
また、ERC-1155が「半不換性トークン」をサポートしていること。これは、完全にユニーク（不換性）であるNFTと、交換可能なトークンの特性を併せ持つトークンのこと。
例えば、ゲーム内の限定アイテムがあるとして、それぞれがユニークなシリアルナンバーを持ちつつも、同じ種類のアイテムとして交換可能な場合、それは半不換性トークンに分類される。これにより、より複雑で多様なデジタル資産の管理が可能になる。
さらに、セキュリティ面でもメリットがある。一つのコントラクトで複数のトークンタイプを管理することで、コードの重複を減らし、スマートコントラクトの開発と保守が容易になる。これにより、バグや脆弱性のリスクを減らすことができる。
ただし、ERC-1155は比較的新しい標準であり、既存のシステムやウォレット、取引所との互換性に関する課題もある。
また、複雑なトークンのロジックを一つのコントラクトに統合することで、そのコントラクト自体の複雑さが増し、理解や使用を難しくする可能性もある。
いいなと思ったら応援しよう！
