イーサリアムブロックチェーンは発売以来、開発者、企業、起業家を魅了し、
スマートコントラクトや分散型アプリケーションをローンチするユーザーの成長産業を生成してきました。
この記事では、
トークンを作成するための重要なフレームワークである
ERC-20規格について説明していきます。これはイーサリアムネットワークに特有のものですが、このフレームワークはバイナンスチェーンの
BEP-2のような他のブロックチェーン規格にも影響を与えています。
ERCとはEthereum Request for Commentsの略で、これは、イーサリアム上でのプログラミングの標準を概説する技術文書です。ビットコインのBIPと同様にプロトコル自体の改善を提案するEthereum Improvement Proposals（EIP）とは混同されません。ERCの目的は、アプリケーションと契約が相互作用しやすい規約を確立することです。
2015年にヴィタリック・ブテリン氏とファビアン・フォーゲルステラー氏によって執筆されたERC-20は、イーサリアムベースのトークンのための比較的シンプルなフォーマットを提案しています。このアウトラインに従うことで、開発者は車輪を再発明する必要はありません。その代わり、すでに業界全体で使用されている基盤を基に構築することができます。
なお、ERC-20規格はEIP（具体的にはEIP-20）として開発されましたが、普及のために当初の提案から数年後に開発し、何年経った現在でも“ERC-20”という名称が定着しています。
ETH（イーサリアムのネイティブ仮想通貨）とは異なり、ERC-20トークンは口座に保有されているわけではありません。トークンは、自己完結型データベースのような契約内にのみ存在します。これは、トークンのルール（名前、シンボル、分割可能性など）を指定し、ユーザーの残高をイーサリアムアドレスにマッピングするリストを保持します。
トークンを移動させるには、ユーザーはコントラクトにトランザクションを送信して、残高の一部を他の場所に割り当てるように依頼する必要があります。例えば、アリスが5,000個のバイナンスアカデミートークンをボブに送信したい場合、アリスはバイナンスアカデミートークンのスマートコントラクト内の関数を呼び出して、送信するように依頼します。
アリスの呼び出しは、トークン契約に対して0ETHを支払う通常のイーサリアムトランザクションと思われるものの中に含まれています。この呼び出しはトランザクションの追加フィールドに含まれており、アリスが何をしたいかを指定しています。
アリスは送信を行う前に、トランザクションを
ブロックに含まれるようにする場合、その中に表示された手数料を支払わなければなりません。もしアリスがETHを保持していない場合、トークンを送信する前にETHを入手する必要があります。
上記はイーサリアム上での実例です：誰かがBUSD契約にコールをしています。トークンが転送され、手数料が支払われているのがわかりますが、バリューフィールドには0ETHが送信されたことが示されています。
これでスピードアップしたので、次に一般的なERC-20契約の構造を理解するために、内部を見てみましょう。
ERC-20に準拠するためには、コントラクトにtotalSupply、balanceOf、transfer、transferFrom、approve、およびallowanceの6つの必須関数を含める必要があります。さらに、名前、シンボル、十進法などのオプション関数を指定することが可能です。これらの関数の名前から、何を行うのかが分かるかもしれません。もし分からなければ、分解するので安心してください。
以下は、イーサリアムのソリディティ言語で使用されている関数です。
totalSupply
関数totalSupply（）publicviewreturns（uint256）
ユーザによって呼び出された場合、上記の関数は、そのコントラクトが保持するトークンの総供給量を返します。
balanceOf
関数balanceOf（アドレス所有者）publicview returns（uint256バランス）
totalSupplyとは異なり、balanceOfはパラメータ（アドレス）を受け取ります。呼び出されると、そのアドレスのトークンの残高を返します。イーサリアムネットワーク上のアカウントは公開されているので、アドレスさえわかればどのユーザーの残高を照会することもできます。
transfer
関数transfer（address _to、uint256 _value）public returns（bool success）
transferは、あるユーザーから別のユーザーにトークンを転送し、転送先のアドレスと転送する金額を指定します。
呼び出されると、transferはイベント（この場合はイベントtransfer）と呼ばれるものをトリガーし、ブロックチェーンに参照を含めるように指示します。
transferFrom
関数transferFrom（address _from、address _to、uint256 _value）publicreturns（bool success）
TransferFrom関数は、分散型アプリケーションでより多くのプログラマビリティを可能にする、Transferに代わる有用な関数です。Transferと同様に、トークンを移動させる際に使用されますが、これらのトークンは必ずしもコントラクトを呼び出した人のためのものではありません。
要するに、誰か、あるいは別のコントラクトに、自身に代わって資金を送金する権限を与えることができます。使用例としては、サブスクリプションベースのサービスに支払いを行う場合が考えられますが、ここでは毎日/週/月に手動で支払いを行う必要はなく、プログラムに代行させることができます。
この機能は、Transferと同じイベントをトリガーします。
approve
関数 approve（address _spender, uint256 _value） public returns（bool success）
approveも、プログラミングの観点からは有用な関数です。この機能を使用すると、スマートコントラクトで残高から出金可能なトークンの数を制限することができます。この機能がなければ、コントラクトが誤動作を起こし（または悪用されて）、すべての資金が盗まれるリスクがあります。
サブスクリプションモデルの例をもう一度見てみましょう。膨大な量のバイナンスアカデミートークンを保持していて、ストリーミング
DAppに毎週の定期購入を設定したとします。あなたは昼夜問わず
バイナンスアカデミーのコンテンツを読むのに忙しいので、トランザクションを手動で作成するために毎週時間をかけたくないとします。
バイナンスアカデミートークンの残高は膨大で、サブスクリプションの支払いに必要な金額をはるかに超えています。DAppがすべてのリソースを消費しないようにするには、approveで制限を設定します。例えば、サブスクリプションの費用が毎週1バイナンスアカデミートークンだとします。approved値の上限を20トークンに設定しておけば、5ヶ月間、サブスクリプションの支払いが自動的に行われるようになります。
最悪の場合、DAppが全ての資金を出金しようとしたり、バグが発見された場合、20トークンしか損失しません。理想的ではないかもしれませんが、保有している全ての資金を失うよりは魅力的です。
approveは呼ばれるとapprovalイベントをトリガーします。Transferイベントと同様に、ブロックチェーンにデータを記入します。
allowance
関数 allowance（address _owner, address _spender） public view returns（uint256 remaining）
allowanceは
approveと組み合わせて使用することができます。
トークンを管理するためのコントラクト権限を付与した後、この権限を使用して出金可能なトークンの数を確認することができます。例えば、サブスクリプションがapprovedの20トークンのうち12トークンを使い切ってしまった場合、
allowance関数を呼び出すと合計8トークンが返還されます。
オプション関数
前述の関数は必須ですが、一方で、名前、シンボル、十進法を含める必要はありませんが、ERC-20コントラクトを少し整えることができます。具体的にはそれぞれ、人間が読める名前を追加したり、シンボルを設定したり（ETH、BTC、BNBなど）、トークンを分割できる十進法以下の桁数を指定することが可能です。例えば、通貨として使用されるトークンは、プロパティの所有権を表すトークンよりも分割しやすいという利点があります。
GitHubの
本例を見て、実際のコントラクトでこれらの要素を確認してみましょう
上記のすべての機能を統合することでERC-20のコントラクトが成立し、
総供給量の照会、残高の確認、資金の送金、他の
DAppsへのトークン管理許可の付与が可能となりました。
そして、ERC-20トークンの最大の魅力は、その柔軟性にあります。ここで規定されている規約は開発を制限するものではないので、関係者は追加機能を実装したり、必要に応じて特定のパラメータを設定することができます。
ステーブルコイン
ステーブルコイン（
法定通貨に連動するトークン）は、多くの場合、ERC-20トークン標準を使用します。先ほど参照したBUSD契約の取引はその一例であり、大半の主要なステーブルコインもこの形式で利用可能です。
典型的な法定通貨担保型のステーブルコインの場合、発行者はユーロやドルなどの準備金を保有し、その準備金の各ユニットに対してトークンを発行します。つまり、1つの金庫室に1万ドルが保管されている場合、発行者は1ドルで交換可能なトークンを1万個作成することができます。
技術的に言えば、イーサリアムでの実装は非常に簡単で、発行者は1万個のトークンでコントラクトを結ぶだけです。その後、ユーザーに配布し、後に法定通貨に比例した金額でトークンを使用できるようにします。
ユーザーはトークンを使用して、商品やサービスを購入したり、DAppsで使用したりと、さまざまなことができます。あるいは、発行者にすぐに交換を依頼することも可能です。その場合、発行者は
返却されたトークンを燃焼（使用不可にして）し、適切な金額の法定通貨を準備金から引き出します。
前述したように、このシステムを管理する契約は比較的単純なものです。しかし、ステーブルコインを実現するためには、物流や法令順守などの外的要因に多くの労力を要します。
セキュリティトークン
セキュリティトークンはステーブルコインに類似していて、コントラクトレベルでは同様に機能するため、両者は同一にすることも可能です。この区別は発行者のレベルで行われます。セキュリティトークンは、株式、債券、現物資産などの有価証券を表します。多くの場合（常にそうとは限りませんが）、保有者にビジネスや商品のある種の利害関係を付与します。
ユーティリティトークン
ユーティリティトークンは、現在最も一般的に使用されているトークンです。上記の2つとは異なり、これらは何のバックアップも受けていません。資産担保型トークンが航空会社の株式のようなものだとすれば、ユーティリティトークンはマイレージプログラムのようなもので、機能は提供するが外部的な価値はありません。また、ユーティリティトークンは、
ゲーム内通貨、分散型アプリケーションの燃料、ポイントなど、無数のユースケースに対応することができます。
イーサ（ETH）をマイニングすることは可能ですが、トークンはマイニングできません。しかし、新しいトークンが作成されるとトークンがマイニングされます。コントラクトが開始されると、開発者は計画やロードマップに従って供給を分配します。
一般的に、これは
イニシャルコインオファリング（ICO）、
イニシャルエクスチェンジオファリング（IEO）、またはセキュリティトークンオファリング（STO）を介して行われます。これらの頭字語のバリエーションに出くわすかもしれませんが、これらの概念は類似しています。投資家はコントラクトアドレスにイーサを送金し、その見返りに新しいトークンを受け取ります。収集したお金は、プロジェクトのさらなる開発資金として使用されます。ユーザーは、プロジェクトの発展に合わせて、トークンを（即座に、または後日に）使用したり、転売して利益を得ることを期待しています。
トークン配布は自動化する必要はありません。多くのクラウドファンディングイベントでは、様々なデジタル通貨（BNB、BTC、ETH、USDTなど）での支払いが可能で、各残高は、ユーザによって提供されたアドレスに割り当てられます。
ERC-20トークンの長所
互換性
ERC-20トークンは
互換性があり、各ユニットは別のユニットと交換可能です。もしあなたがバイナンスアカデミートークンを保有していた場合、特定のトークンを保有しているかどうかは問題ではありません。他の人のトークンと交換することも可能で、機能的には現金や金と同一の価値があります。
これは、トークンが何らかの通貨であることを目的としている場合には理想的で、識別可能な特性を保持するユニットは必要ないため、代替不可能になります。そして、トークンの価値が他のトークンよりも高値や低値になり、トークンの目的が損なわれてしまう可能性があります。
柔軟性
以前のセクションで説明したように、ERC-20トークンはカスタマイズ性が高く、さまざまな用途に合わせて調整することができます。例えば、ゲーム内通貨、ポイントプログラム、
デジタル収集品として使用したり、美術品や財産権を表すために使用することもできます。
人気
仮想通貨業界におけるERC-20の人気の高さは、それを設計図として使用する際に非常に説得力があるからです。新たにローンチしたトークンと互換性のある取引所、ウォレット、スマートコントラクトはすでに多数存在します。さらに、開発者のサポートとドキュメントも豊富です。
ERC-20トークンの短所
スケーラビリティ
多くの仮想通貨ネットワークと同様に、イーサリアムも成長痛の影響を受けないわけではありません。現在の形態では拡張性が悪く、ピーク時にトランザクションを送信しようとすると高額な手数料や遅延が発生します。ERC-20トークンを起動してネットワークが混雑した場合、そのユーザビリティに影響が及ぶ可能性があります。
詐欺
技術自体に問題はありませんが、トークンの起動のしやすさは、いくつかの点でマイナス面と考えられる可能性があります。ERC-20トークンの作成には最小限の労力で済み、誰にでも行うことができるということです。
そのため、投資対象には注意が必要です。ブロックチェーンプロジェクトを装った
ネズミ講などが数多く存在します。 投資をする前に
自分で調査をし、その機会が正当なものかどうかの結論を自身で出すようにしましょう。
ERC-20は最初の（現在、最も普及している）イーサリアムトークンの標準でしたが、それだけではありません。長年の間に、ERC-20を改良したものや、異なる目標を達成しようとするものなど、他にも多くの規格が登場してきました。
あまり一般的ではない標準の中には、
非代替性トークン（NFT）で使用されているものもあります。場合によっては、異なる属性を持つ固有な性質のトークンを保持することで、ユースケースが実際に利益を得ることもあります。一点物の芸術品やゲーム内資産などをトークン化したい場合は、これらの契約タイプのいずれかの方が魅力的かもしれません。
例えば、
ERC-721規格は、非常に人気の高いCryptoKitties DAppに使用されています。このような契約は、ユーザーが独自の非代替性トークンを作成し、
メタデータ（画像、説明など）をエンコードするための
APIを提供します。
ERC-1155規格は、ERC-721とERC-20の両方を改良したものと考えられ、ERC-1155は、同じコントラクトの中で、代替可能なトークンと非代替性トークンの両方をサポートする規格の概要を示しています。
ERC-223やERC-621のような他のオプションは、ユーザビリティの向上を目的としています。ERC-223は、偶発的なトークン転送を防ぐための保護手段を実装しています。ERC-621は、トークンの供給量を増減するための機能を追加しています。
ERC-20規格は何年にもわたって仮想資産分野を管理してきましたが、その理由は明確で、比較的簡単な操作で、誰でも幅広いユースケース（ユーティリティトークン、ステーブルコインなど）に合わせて単純なコントラクトを展開することが可能だからです。しかし、ERC-20は、他の標準規格で実現されている機能の一部を欠いています。後続の種類の契約が入れ替わるのかはまだ解明されていません。