原文
ERC-8293: Counterfactual Rejection Event Log (CREL) — aartikamat (2026-06-15)
ERC-8293: 反実仮想拒否イベントログ (CREL)
概要
ERC-8293は、DEXプロトコルまたはフィルターが実行前に拒否した取引候補のためのオンチェーンイベントログを規定するものです。2つのイベントがあります。拒否時に発生する RejectionLogged と、拒否されたトークンが実際に何をしたかを記録するために、その後一定間隔で発生する OutcomeSampled です。これらのイベントを発行するプロトコルにより、外部の参加者はフィルターの精度を測定し、反実仮想分析を実行し、プロトコル間でフィルターの品質を比較できるようになります。
動機
DEXプロトコルやフィルターミドルウェアは、評価する候補トークンのほとんどを拒否しますが、それらの拒否をログに記録しません。承認された取引は完全なイベントメタデータを受け取ります。拒否された取引はオンチェーンに何も残りません。3つの結果として、以下の点が挙げられます。
- 独自のオフチェーンキャプチャシステムを構築しない限り、フィルターの精度を測定できません。
- 拒否理由がオンチェーンに表示されないため、プロトコル間でフィルターの品質を比較できません。
- プライベートなリプレイインフラストラクチャがないと、反実仮想結果分析（拒否されたトークンが取引されていたらどうなっていたか？）を実行できません。
RED-2400データセットは、このギャップの大きさを示しています。SolanaのDEX会場で49日間にわたって捕捉された6,660件の拒否イベントは、すべてオフチェーンの計測を通じて得られたものです。CRELは、この捕捉をイーサリアムにネイティブなものにします。
未解決の質問
OutcomeSampledのサンプリング間隔は仕様で固定すべきか、それとも実装ごとに設定可能とすべきか？- イベントスキーマは現在のドラフトのままでThe GraphやDuneのインデクサーと互換性があるか、それとも調整が必要か？
- これはDEXに依存しないものとすべきか、それともAMM形式の会場のみにスコープを限定すべきか？
スキーマと、サンプリングスケジュールを仕様に含めるべきか、実装者に任せるべきかについて意見を求めています。
1件の投稿 - 1名の参加者