ERC-827 の探求：transfer と approval ロジックの拡張

イーサリアムのエコシステムは、長らく代替不可能なトークン（fungible tokens）の標準として ERC-20 に依存してきました。アプリケーションが進化するにつれて、開発者は従来の transfer と approve のパターンよりもリッチなトークンインタラクションを求めるようになりました。ERC-827 は、コミュニティ提案の拡張として登場し、「transfer-and-call」および「approve-and-call」といったセマンティクスをトークンコントラクトに直接組み込むことを目指しました。これにより、トークンの送金と同時に、受け取り側のコントラクトでロジックを実行できるようになります。このアイデアは現代のユーザビリティのニーズを先取りしていましたが、セキュリティと互換性に関する重要な問題も提起し、今日のプロトコルがトークンコールバックにどのようにアプローチするかに影響を与えました。

この記事では、ERC-827 が何を解決しようとしたのか、それが明らかにしたセキュリティ上のトレードオフ、注目を集めた実用的な代替案、そしてウォレットの UX とセキュリティ（特にハードウェアウォレット）が安全なトークン承認ワークフローにどのように適合するのかを探ります。

ERC-827 が解決しようとしたこと

従来の ERC-20 は、価値の移動と意図を分離しています。

• transfer は送信者から受領者へトークンを移動します。
• approve は、承認された支出者が送信者のトークンを使用するための上限額を設定します。
• transferFrom は、承認された支出者がその上限額を使用することを可能にします。

このモデルは機能しますが、単一ステップの「支払いと実行」フローを必要とする dapp にとっては扱いにくい場合があります。ERC-827 は、単一のトランザクションで価値を移動させ、かつターゲットコントラクトでコードを呼び出すトークン関数を提案しました。概念的には、「トークンを dapp に送金し、その受け取り関数をアトミックに呼び出す」または「コントラクトを承認し、その承認をすぐに呼び出して使用する」といったシナリオを可能にするものでした。

標準規格である ERC-20 の詳細については、Ethereum EIPs サイトの仕様を参照してください：ERC‑20。

コールバックが魅力的な理由

コールバック形式のトークンインタラクションは、UX を改善し、摩擦を軽減します。

• 受領者が直ちにロジックを実行する、単一トランザクションでの支払い。
• フローが適切に設計されていれば、承認の誤りや古い承認額が減少します。
• 呼び出し側と呼び出し先の間の意図のシグナルがより明確になります。特にオンチェーンサービスにおいては重要です。

これらの動機がなくなったわけではありません。開発者は依然としてアトミックな「支払いと実行」セマンティクスを求めています。しかし、ERC-827 が提案したように、それをトークンコントラクトに直接実装することは、顕著なリスクを表面化させました。

ERC-827 を後退させたセキュリティ上の落とし穴

資産の移動と任意の外部呼び出しをバンドルすることは、以下のようなリスクをもたらす可能性があります。

• リエントランシーのリスク： 状態が部分的に更新されている間に信頼できないコントラクトを呼び出すと、複雑な制御フローが発生する可能性があります。リエントランシーと緩和策に関する ConsenSys Diligence の概要を参照してください：Known Attacks: Reentrancy。
• 予期しない副作用： トークンコントラクトは、最小限の価値台帳ではなく、実行ハブとなり、バグの表面積が増加します。
• 互換性の懸念： 受領側の多様な動作とフォールバックセマンティクスは、異なる dapp やチェーン間でのコンポーザビリティを複雑にします。

これらのトレードオフのため、コミュニティはコアトークンロジックを最小限に保ち、「transfer-and-call」セマンティクスを適切に定義された拡張機能または個別のプロトコルに押し出すパターンに移行しました。

開発者が現在使用している実績のある代替案

いくつかの標準規格とパターンは、ERC-20 コントラクトに過負荷をかけることなく、人間工学的なメリットを捉えています。

• ERC‑677 (transferAndCall)： 単一の関数と受領者インターフェースを追加する実用的な拡張機能で、オラクルやブリッジで広く使用されています。仕様：EIP‑677。
• ERC‑1363 (Payable Token)： transfer と approval の両方のフローに対応する、よりリッチなコールバックインターフェースです。仕様：EIP‑1363。
• Permit (ERC‑2612)： オフチェーンで署名された承認で、承認の摩擦を軽減し、不要なオンチェーントランザクションを回避します。仕様：EIP‑2612。
• Permit2： 主要な DEX が上限額管理を一元化し、承認リスクを軽減するために使用する、強化され、コンポーザブルな承認システムです。ドキュメント：Uniswap Permit2。
• 型付き構造化データ署名 (EIP‑712)： メタトランザクションとパーミットのための署名の安全性と UX を向上させます。仕様：EIP‑712。

これらのアプローチにより、開発者は「支払いと実行」フローを実現しつつ、関心の分離を維持し、トークンコントラクトのリスクを軽減できます。

コールバックセマンティクスが必要な場合の設計ガイダンス

値の送金または承認時の即時実行がプロトコルにメリットをもたらす場合：

• 任意の呼び出しをトークンに埋め込むよりも、ERC‑677 または ERC‑1363 の受領者を優先してください。
• 外部コントラクトとやり取りする際にリエントランシーを軽減するために、ReentrancyGuard と構造化された状態更新を使用してください。参照：OpenZeppelin ReentrancyGuard。
• トークンコントラクトは最小限に保ってください。複雑なロジックは、専門のモジュールまたは受領者コントラクトに押し出してください。
• 承認を合理化し、「無限承認」の落とし穴を回避するために、Permit (ERC‑2612) または Permit2 を検討してください。
• ウォレットとダッシュボードでのより安全な UX のために、型付きデータ署名 (EIP‑712) を使用してください。

一般的なトークン設計と実装の詳細については、OpenZeppelin ERC‑20 ドキュメントを参照してください：OpenZeppelin ERC‑20。

2025 年のビルダーが気にかけること

アカウント抽象化が成熟し続けるにつれて、プロジェクトはパーミットスタイルの承認、バッチ処理、ユーザーフレンドリーなセッションキーを組み合わせて、安全性を犠牲にすることなく dapp をよりスムーズにしています。高度なフローを統合する場合は、ウォレットとツールが現在サポートしているエコシステム標準に合わせる価値があります。アカウント抽象化仕様を参照してください：EIP‑4337。

ウォレット UX：承認、意図、そして安全性

どの拡張機能を採用するにしても、トークン承認とコールバックは、明確なユーザーの意図と堅牢な署名 UX を要求します。

• 署名する前に、メソッド、支出者、金額、およびリスクを表示してください。
• 可能であれば、時間制限付きまたは金額制限付きの承認を優先し、無制限の承認は避けてください。
• 署名の混乱を減らすために、承認には EIP‑712 型付きデータを使用してください。
• 広範で長期的な承認ではなく、スコープと期間を制限するセッションアーキテクチャを検討してください。

ハードウェアウォレットは、物理的な確認を要求し、トランザクションの詳細を明確に表示することで、フィッシングや悪意のある承認のリスクを軽減します。ERC‑677、ERC‑1363、または Permit を使用して構築しているチームにとって、この追加レイヤーは、ユーザーが意図せずに未知のコントラクトに強力な権限を付与する可能性を低減します。

OneKey ユーザーおよびインテグレーターへの注意

コールバックベースの送金またはパーミットスタイルの承認に依存する製品を構築している場合、それらを透明な署名エクスペリエンスと組み合わせることが不可欠です。OneKey は以下を提供します。

• イーサリアムおよび EVM ネットワーク向けのオフライン、ハードウェア強制署名。
• 支出者のアドレス、トークン量、およびメソッドを提示する明確な署名サポート。
• 承認と送金が表示される方法を監査するためのオープンソースファームウェアとツール。

これらの機能により、ユーザーはセキュリティを損なうことなく、「transfer-and-call」または「approve-and-call」フローを安全に承認しやすくなります。dapp が ERC‑677、ERC‑1363、または Permit を実装している場合は、明確な署名と制限付きの承認を優先し、ユーザーにハードウェアウォレットで各承認を確認するように奨励してください。

結論

ERC‑827 は、トークンの移動と即時実行を連携させるという実際のニーズを捉えました。コミュニティの対応は、ERC‑677 および ERC‑1363 のような軽量な拡張機能、および Permit と EIP‑712 を介したより安全な承認フローを優先することで、バランスの取れた前進を提供します。2025 年には、成功する戦略は、トークンコアを最小限に保ち、標準化された受領者インターフェースを使用し、UX のためにパーミットと型付きデータに依存し、信頼できる署名のためにハードウェアウォレットに頼ることです。

ビルダーは、ウォレットとセキュリティツールがすでにサポートしている標準を採用してください。ユーザーは、承認を慎重に管理し、OneKey のようなハードウェアウォレットで確認することで、複雑なトークンワークフローでの露出を最小限に抑えてください。

参考文献：

• ERC‑20：EIP‑20
• ERC‑677：EIP‑677
• ERC‑1363：EIP‑1363
• Permit (ERC‑2612)：EIP‑2612
• 型付きデータ署名：EIP‑712
• アカウント抽象化：EIP‑4337
• リエントランシー ガイダンス：ConsenSys Diligence: Known Attacks
• OpenZeppelin ERC‑20 ドキュメント：OpenZeppelin Contracts
• Permit2 の概要：Uniswap Docs