原文

ERC-8339: Two-Phase Asset Transfers — mdaus (2026-07-15)

皆さん、こんにちは。

私は二段階転送の標準を提案しています。送信者が転送を開始すると、資産はエスクローにロックされ、指定された受取人に紐付けられます。そして、受取人が承認するまで何も決済されません。誰かが承認するまで、送信者はいつでも取り消すことができます。期限を過ぎると、送信者は取り戻すことができます。

ドラフト: Add ERC: Two-Phase Asset Transfers by muhammadaus · Pull Request #1882 · ethereum/ERCs · GitHub

問題点

通常の転送は一方的です。送信者が行動し、受取人は何もせず、トランザクションが着地した瞬間に、誤入力されたアドレスやポイズニングされたアドレスが資金を所有してしまいます。アドレス帳やスマートウォレットはそれらを使用する人々を助けますが、根本的な原因は、受取人が発言権を持たないことにあります。

この標準が規定するもの

  • 標準エスクローインターフェース (ITwoPhaseEscrow) と、以下のライフサイクル: initiateTransferacceptTransfer (受取人のみ) → 決済、さらに revokeTransfer (送信者、保留中はいつでも) および reclaimExpired (送信者、期限切れ後)。
  • この標準は、ネイティブETHおよび既存のあらゆるERC-20、ERC-721、またはERC-1155トークンと連携し、各トークンが既に持つ承認および転送メカニズムのみを使用します。資産コントラクトの変更は一切不要です。1つのエスクローデプロイと1つのウォレット統合で、あらゆる資産クラスをカバーします。ERC-165を介して検出可能です。
  • 必須の第二要素。送信者は使い捨てのsecp256k1鍵を生成し、受取人がアドレスが本当に自分のものであることを確認した後でのみ、オフチェーンで受取人に渡します。承認には、受取人自身の鍵と、その秘密鍵で作成された署名が必要です。これにより、受取人による承認だけでは防げない唯一のケースを防ぎます。それは、誤ったアドレスにいるアクティブな見知らぬ人が、保留中の転送を見て承認してしまうケースです。これは必須です。なぜなら、ユーザーはそのリスクを誤って判断する際に、オプションのシークレットを省略してしまうからです。第二要素を望まない送信者は、転送IDと一緒にシークレットを渡すだけで済みます。

トークンネイティブなインターフェースは、このドラフトには含まれていません。新しくデプロイされるトークンは、同じライフサイクルを直接組み込むことができ、それによってユーザーにとって物事が容易になります。承認ステップなし、外部コントラクトなしです。これは現実的な選択肢であり、別のフォローアップERCとして標準化することを提案します。エスクローが最初に提案されるのは、それが今日すでに存在するあらゆる資産と連携できるためです。

最もフィードバックを求めている設計上の決定

明白なシークレット設計(ハッシュを保存し、受取人が生のプリイメージを提出する)は、メムプール (Mempool)で破綻します。リビールコードはコールデータ内にあり、承認がブロードキャストされた瞬間に、トランザクションがリバートされたとしても、すべてのメムプール (Mempool)ウォッチャーに公開されます。誤って間違ったアカウントから提出した受取人は、シークレットを公開してしまい、何も得られません。

そのため、このドラフトでは代わりに署名によってシークレットを証明します。シークレットは秘密鍵です。受取人はそれを使って keccak256(abi.encode(chainid, escrow, transferId, msg.sender)) に署名します。生の鍵がオンチェーンに現れることは、マイニングされてもリバートされてもありません。観測された署名はリプレイできず(呼び出し元のアカウントを指名するため)、鍵に逆変換することもできません。コストは1つのecrecoverです。

先行技術

ERC-1996 (Holdable Token)、ERC-2020、およびERC-5528は、トークン拡張として関連分野に触れましたが、停滞しました。このドラフトは、代わりにエスクローを標準化することで異なり、ネイティブETHと、既存のあらゆるトークンを、それらへの変更なしにカバーし、メムプール (Mempool)セーフな第二要素を指定します。

グループへの質問

  1. 推奨される有効期限範囲(10分から7日間)は妥当なデフォルトでしょうか?
  2. 署名ベースの承認証明に見落としている欠陥はありますか?

参照実装(Foundry、完全なテストスイート)はPRのassetsディレクトリにあります。フィードバックを歓迎します。

1投稿 - 1参加者

トピック全文を読む