ERC-7683は変化しており、多くの説明はまだこの標準の旧バージョンを記述しています。 現在のERC-7683ドラフトは、リゾルバ中心の構造になっています。 すべてのクロスチェーン意図プロトコルを1つの共有エスクローコントラクト、1つのオークションシステム、1つの決済メカニズム、1つの認証モデル、または1つの宛先満足関数に強制するのではなく、プロトコルは独自の実行アーキテクチャを維持しつつ、共通のリゾルブ層を通じて注文をソルバーに公開できます。 この違いは重要です。 ERC-7683の注文は、定義された一連の要件を満たす対価として支払いを提供するものです。ソルバー（フィラーとも呼ばれます）はこれらの要件を評価し、必要な実行を決定し、資本またはガスをコミットし、注文を正しく満たした場合に支払いを期待します。 現在の設計では、プロトコルはリゾルバコントラクトと共に不透明なプロトコル固有のペイロードを公開できます。 このリゾルバは、ペイロードを以下の共通表現に変換します： • 実行ステップ • 変数 • 支払い • 明示的な仮定 これにより、プログラマブルなソルバーは、各ソルバーがすべての意図プロトコルに対して完全にカスタムロジックを実装する必要なく、注文が実際に何を要求しているかを標準化された方法で理解できます。 解決された実行モデルは、トークン支出要件、ガス要件、タイミング制約、依存関係、およびリバート動作を公開できます。 変数は、ソルバー支払いアドレス、支払いチェーン、実行出力、ステップ呼び出し元、オフチェーン証人、コントラクトクエリ、イベントクエリを表すことができます。 ERC-7683はまた、ERC-7930を通じて相互運用可能なアドレス表現を組み込んでおり、従来の20バイトEVMアドレスに頼るのではなく、アドレスにチェーンコンテキストをバインドします。 しかし、重要なセキュリティ境界があります。 ERC-7683の標準化は、基盤となる意図プロトコルを自動的に安全にするものではありません。 決済コントラクト、ブリッジ、メッセージ伝達システム、トークン、オークションメカニズム、オフチェーンサービス、オラクル、リソースロック、リプレイ保護、キャンセルロジック、返金動作、部分的満足は、解決された要件または仮定を通じて明示的に表現されない限り、プロトコル固有のリスクです。 したがって、リゾルバのセキュリティは極めて重要です。 リゾルバは、プロトコル固有のペイロードを正しく検証し、適切に動作するソルバーが何が起こるべきか、およびどの仮定のもとで支払いが利用可能になるかを理解できる表現を公開しなければなりません。 正しいリゾルバは、不安全な決済システムを安全にすることはできません。 また、準拠した注文形式はソルバーのリスクを除去しません。 フィラーは、承認やガス、資本、またはトランザクションをコミットした瞬間から、期待される支払いが最終的かつ使用可能になるまで経済的にリスクにさらされます。 ユーザーにとって、重要な検証ポイントは以下のとおりです： • オリジンチェーン • 入力資産 • 宛先チェーン • 受取人 • 期待される出力 • デッドライン • 認証範囲 • 署名されているトランザクションまたはタイプドデータ ERC-7683はOpen Intents Frameworkのようなより広範な意図システム内にも自然に組み込まれますが、両者は交換可能ではありません。 ERC-7683は主にソルバー向け注文解決の標準化レイヤーです。 OIFは、意図の生成、解決、履行、決済、集約および関連コンポーネントをカバーするより広範なインフラストラクチャフレームワークです。 最新のTokenToolHub研究では、現在のERC-7683設計と以前のドラフトとの違い、注文ライフサイクル、フィラー、リゾルバセキュリティ、実行ステップ、支払い、仮定、相互運用可能なアドレスおよび標準自体の外に残るソルバーのリスクについて詳細に解説しています。 フルアナリシス： https://t.co/VK5Yb4wvJ3