ERC-621の理解:トークンの発行と削除の標準

キーストーン
• ERC-621はERC-20トークンの供給量を増減させるための標準化された方法を提供します。
• Dencunアップグレードにより、L2ネットワークでのトークン操作が低コスト化され、ミント/バーンがより頻繁に行われるようになります。
• トークンのライフサイクルを設計する際、ERC-621の理解は開発者やトレジャラーにとって依然として価値があります。
• ミントとバーンのイベントセマンティクスは、インデクサーやウォレットとの互換性を向上させます。
• セキュリティとガバナンスの観点から、アクセス制御やマルチシグ管理が重要です。
トークン供給量の伸縮性、つまり新しいトークンを発行(ミント)したり、既存のトークンを削除(バーン)したりできる能力は、ステーブルコイン、RWAプログラム、ロイヤリティポイント、そして多くのゲームアセットの運用において中心的な役割を果たします。ERC-621は、ERC-20トークンの供給量を増減させる方法を形式化し、ミントとバーンのセマンティクスを標準化することで、ツールの改善やウォレットの相互運用性を向上させるための初期の試みでした。コアなERC-20ほど広く採用されてはいませんが、トークンのライフサイクルを設計するチームや、トークンが提供する保証を評価するユーザーにとって、ERC-621を理解することは依然として価値があります。
この記事では、ERC-621が何をするのか、今日のエコシステムにおける一般的なERC-20拡張機能と比較してどうなのか、そして特に、EthereumのDencunアップグレード後の低コストなレイヤー2ネットワークへのミント/バーン操作の移行が進むにつれて、開発者やトレジャラーが注目すべき点について解説します。
- ERC-20参照:残高、総供給量、イベントに関する背景については、Ethereum.orgの正規のトークン標準を参照してください。参照:Ethereum.orgのERC-20。
- Dencunの文脈:メインネットの稼働により、ロールアップのデータ可用性コストが削減され、L2での高頻度なトークン操作がより安価になりました。参照:Ethereum FoundationのDencun発表。
リンク:
- ERC-20: https://ethereum.org/en/developers/docs/standards/tokens/erc-20/
- Dencun: https://blog.ethereum.org/2024/03/13/dencun-mainnet
ERC-621とは?
ERC-621は、ERC-20の拡張機能として提案されており、トークンコントラクトが標準化された関数とイベントのセマンティクスを通じて総供給量を増減できるようにします。本質的に、ミント(供給量の増加)とバーン(供給量の減少)がツール間で認識されるための合意された方法を提供します。
主要なアイデア:
- ミントは
totalSupplyを増加させ、アドレスにトークンをクレジットし、ゼロアドレス(address(0))から受信者へのTransferイベントを発行します。 - バーンは
totalSupplyを減少し、アドレスからトークンをデビットし、保有者からゼロアドレスへのTransferイベントを発行します。 - これらのセマンティクスは、ERC-20互換トークンがイベントレベルでミント/バーンをどのように表現することが期待されるかと一致しており、エクスプローラーやインデクサーとの互換性を向上させます。
参照:EIP-621 on eips.ethereum.org。
リンク:
ステータス注記:ERC-621はエコシステムの初期に提案され、今日では「ミント可能/バーン可能」な実践的なERC-20パターンほど参照されることは少なくなっています。それでも、そのイベントレベルの規約は、ミント/バーンをサポートする適切に実装されたERC-20によって広く従われています。
2024-2025年に供給量の伸縮性が重要である理由
- ステーブルコインとRWA:発行者は、新しい担保がオンボードされるときに定期的にミントし、償還が行われるときにバーンします。明確で監査可能なイベントセマンティクスは、透明性のために不可欠です。
- Dencun後のL2操作:ロールアップでの安価なバッチ操作は、アプリケーション固有のトークンのミント/バーンサイクルの頻度を高め、ガス代のペナルティを回避することを意味します。参照:EthereumのDencunロードマップページ。
- コンプライアンスとライフサイクル制御:トレジャリーチームは、ロールベースのミント、償還時のバーン、またはインシデント中に一時停止できるスケジュールされた排出を必要とすることがよくあります。
リンク:
- Dencunロードマップ:https://ethereum.org/en/roadmap/dencun/
ERC-621 vs. 今日の一般的なERC-20パターン
ERC-621は正式なミント/バーン拡張機能を定義していますが、多くの本番プロジェクトでは、広く監査されたERC-20ライブラリとアクセス制御を使用してミントとバーンを実装しています。
- OpenZeppelinのERC-20拡張機能:
- Burnable拡張機能により、トークン保有者(または承認された支出者)はトークンを破棄できます。参照:OpenZeppelin ERC20Burnable。
- ロールベースのアクセス制御は、ミントを
MINTER_ROLEまたはオーナーに制限するためによく使用されます。参照:OpenZeppelin AccessControl。
リンク:
- OpenZeppelin ERC20Burnable: https://docs.openzeppelin.com/contracts/5.x/api/token/erc20#ERC20Burnable
- OpenZeppelin AccessControl: https://docs.openzeppelin.com/contracts/5.x/api/access#AccessControl
一般的なOZパターンの利点:
- 広範な監査とコミュニティ利用による成熟したコード
- 柔軟なロール分離(例:
MINTER_ROLE、PAUSER_ROLE) - 一時停止可能または許可(EIP-2612)機能との容易な統合
厳密なERC-621とのトレードオフ:
- ERC-621は、供給量変更のための標準的な関数名とセマンティクスを目指しています。多くのトークンはこれらの正確な関数シグネチャを公開していませんが、インデクサーが依存するイベントセマンティクス(ゼロアドレスのミント/バーン)には準拠しています。
- 現在、明示的なERC-621インターフェースがなくても、ERC-20ミント/バーンイベントに対するツールのサポートはすでに強力です。
許可フローの参照:EIP-2612。
リンク:
- EIP-2612: https://eips.ethereum.org/EIPS/eip-2612
重要なイベントセマンティクス
トークンがERC-621の正確なインターフェースを実装していなくても、透明な供給量変更のために2つのERC-20互換パターンが重要です。
- ミント:
Transfer(address(0), to, amount)を発行 - バーン:
Transfer(from, address(0), amount)を発行
インデクサー、ウォレット、エクスプローラーは、これらのイベントに依存して、カスタム解析ロジックなしで供給量の変更を理解します。これはまさにERC-621が標準化しようとしたことです。参照:ERC-20トークン標準。
リンク:
最小限のモダンな実装パターン
以下は、一般的なツールを使用しながらERC-621セマンティクスに準拠した簡略化された例です。これは文字通りのERC-621関数シグネチャを実装していませんが、期待されるゼロアドレスのTransferイベントを発行し、安全のためにロールを使用しています。
// SPDX-License-Identifier: MIT
pragma solidity ^0.8.20;
import {ERC20} from "@openzeppelin/contracts/token/ERC20/ERC20.[sol](https://onekey.so/blog/ja/ecosystem/best-sol-wallets-in-2025-ultimate-guide-to-software-hardware-options/)";
import {ERC20Burnable} from "@openzeppelin/contracts/token/ERC20/extensions/ERC20Burnable.[sol](https://onekey.so/blog/ja/ecosystem/best-sol-wallets-in-2025-ultimate-guide-to-software-hardware-options/)";
import {AccessControl} from "@openzeppelin/contracts/access/AccessControl.[sol](https://onekey.so/blog/ja/ecosystem/best-sol-wallets-in-2025-ultimate-guide-to-software-hardware-options/)";
[contract](https://onekey.so/blog/ja/ecosystem/what-is-a-smart-contract/) ElasticToken is ERC20, ERC20Burnable, AccessControl {
bytes32 public constant MINTER_ROLE = keccak256("MINTER_ROLE");
constructor(string memory name_, string memory symbol_, [address](https://onekey.so/blog/ja/ecosystem/what-is-a-crypto-wallet-address/) admin) ERC20(name_, symbol_) {
_grantRole(DEFAULT_ADMIN_ROLE, admin);
_grantRole(MINTER_ROLE, admin);
}
function mint([address](https://onekey.so/blog/ja/ecosystem/what-is-a-crypto-wallet-address/) to, uint256 amount) external onlyRole(MINTER_ROLE) {
_mint(to, amount); // Emits Transfer([address](https://onekey.so/blog/ja/ecosystem/what-is-a-crypto-wallet-address/)(0), to, amount)
}
// ERC20Burnableから継承したバーン関数(保有者主導)
}
- ミントはロールによって制限され、ゼロアドレスの
Transferイベントを発行します。 - バーンは保有者または承認された支出者によるオプトインであり、ゼロアドレスへの
Transferを発行します。
OpenZeppelin参照:
- ERC20Burnable: https://docs.openzeppelin.com/contracts/5.x/api/token/erc20#ERC20Burnable
- AccessControl: https://docs.openzeppelin.com/contracts/5.x/api/access#AccessControl
セキュリティとガバナンスに関する考慮事項
- アクセス制御と職務分掌
MINTER、PAUSER、DEFAULT_ADMINに別々のロールを使用します。単一のEOAですべての権限を付与することは避けてください。- 単一キーのリスクを軽減するために、マルチシグまたはモジュールベースの管理を優先します。よく知られたアプローチは、管理ロールを専用のマルチシグの後ろに置くことです。参照:SafeのSafeとはに関するドキュメント。
- 一時停止とサーキットブレーカー
- 一時停止可能なコントラクトは、インシデントやオラクルの障害に対応するのに役立ちます。
- 監査とベストプラクティス
- アップグレード可能性、初期化、ロールの取り消しに関する確立されたセキュリティガイドラインに従ってください。参照:ConsenSys DiligenceによるEthereumスマートコントラクトベストプラクティス。
リンク:
- Safe概要:https://docs.safe.global/learn/what-is-safe
- スマートコントラクトベストプラクティス:https://consensys.github.io/smart-contract-best-practices/
L2とブリッジのニュアンス
- 正規トークン vs. ブリッジされたトークン
- L2でトークンが正規である場合、ミントは通常そのL2で直接行われ、その後ブリッジが他のネットワークの供給量を反映します。
- L1で正規である場合、L2表現でミントを許可されるべき者と、ブリッジコントラクトがその権限をどのようにゲートするかを検討してください。
- バッチ操作
- Dencun以降、はるかに安価になったロールアップでのコストを最小限に抑え、会計の明確性を向上させるために、バッチミント/償還を検討してください。参照:EthereumのDencun概要。
リンク:
ミントまたはバーン可能なトークンを評価する方法
ユーザーとインテグレーター向け:
- コードまたは検証済みのソースを読む
- ミントがロールによって制限されているか確認し、コントローラー(EOA、マルチシグ、DAO)を特定します。
- イベントセマンティクスを確認する
- 供給量変更のために、ゼロアドレスとの標準的な
Transferイベントを探します。
- 供給量変更のために、ゼロアドレスとの標準的な
- アップグレード可能性をレビューする
- アップグレード可能かどうか、誰が、どのようなプロセスでアップグレードできるかを理解します。
エクスプローラーとドキュメントの参照がここで役立ちます。
- ERC-20標準概要:https://ethereum.org/en/developers/docs/standards/tokens/erc-20/
- ERC-621提案の詳細:https://eips.ethereum.org/EIPS/eip-621
ERC-621を今日採用すべきか?
- ウォレットやミドルウェアがターゲットにできる、供給量管理のための明示的な関数シグネチャが必要な場合は、ERC-621は明確に名前が付けられたインターフェースを提供します。
- すでにOpenZeppelinパターンに依存している場合は、監査済みのライブラリと柔軟なロール設計の恩恵を受けながら、ERC-621の精神の重要な部分、つまり標準的なゼロアドレス
Transferイベントを満たしている可能性が高いです。 - どちらを選択するにしても、ミント/バーンポリシー(誰が、いつ、上限、監査プロセス)を文書化し、インテグレーターが理解できるようにしてください。
締めくくりの考えと実践的な推奨事項
ミントとバーンは、厳格なガバナンスを必要とする強力なレバーです。ERC-621の明示的なインターフェースを採用する場合でも、広く使用されているERC-20拡張機能に留まる場合でも、最も重要な側面は、標準化されたイベントセマンティクス、明確なロール設計、そして安全なキー管理です。特に2025年にL2での発行および償還活動が加速するにつれて、これらは重要になります。
運用上のセキュリティのため、ミントと管理キーは専用のコールドストレージに保管し、機密性の高い操作にはマルチシグ承認を要求してください。OneKeyハードウェアウォレットは、一般的なマルチシグ設定やdAppと統合された、EVMネットワーク全体でのトレジャリーおよび管理ロールの安全な署名者として機能できます。ハードウェアウォレットを使用して、ミント/バーンおよびロール管理トランザクションに共同署名することで、トークン操作の効率的なワークフローを維持しながら、単一障害点のリスクを軽減できます。






