🔒🖼️ 新しい投稿:暗号化フレームトランザクション 🔒🖼️ 要約すると、dr: 暗号化フレームトランザクションはLUCIDおよびEIP-8141を基盤に構築され、ブロックの順序がロックされるまで実行パラメータ(ターゲット、コールデータ、金額)を隠します。この設計により、同じスロットの暗号化実行、インターリーブされた平文/暗号化トランザクションが解放され、将来的にPQ方式と互換性があります。 👇🧵

現在の暗号化されたメンプール設計(例:LUCID)は、次のスロットへの実行を遅延させ、暗号化されたトランザクションのために専用のトップオブブロックレーンを使用します。本投稿では、順序と実行を分離して同じスロットで暗号化を実行することを提案します。 ビルダーはキーが公開される前に、順序付きトランザクションセット全体にコミットし、同じスロットでそのコミットされた順序を実行します。

標準的なePBSでは、建設業者は事前に計算されたblock_hashにコミットします。しかしここではそれがうまくいきません。なぜなら、最終的な結果はどの暗号化されたトランザクションが公開され、それが何に復号されるかによって決まるからです。 代わりに、ビッドは取引リスト全体をロックして公開前に取引リスト全体をtx_ordering_rootにコミットします。実行依存の出力(state_root、BAL、レシート)はその後にバインドします。

これがLUCIDとの大きな違いです。LUCIDでは、キーはスロットNで解放され、実行はスロットN+1のブロック上部で行われます。次のビルダーは、ブロックの残りの部分を置く際に復号された取引をすでに把握しています。 ここではコミットメントが公開前に行われ、実行は同じスロットに留まり、暗号化されたトランザクションは平文と一つの順序で交互に挿入されます。

各暗号化フレームtxには公開のVERIFYフレームと隠された暗号化実行フェーズがあります。エンベロープは exec_params_binding = H(exec_params)にコミットします。ターゲット、コールデータ、金額、そしてオプションで優先料金は公開されるまで隠されたままです。 もし鍵がビルダーの公開期限までに届かなければ、暗号化フェーズはスキップされます。VERIFYは実行され、ノンスは消費され、送信者は公開部分の費用を支払います。隠された処刑ガスは返金されます。注文は固定されたままです。

建築業者はカットオフ近くのリビールについて裁量権を持っています。これを制約するために、設計ではFOCILに似たアテスタービューマージが使われています。アテスターは、自分の凍結期限前にキーを観察した場合、開示が欠落とされるペイロードに投票しません。

(もう一つの)フリーオプション問題について:自己復号送信者はコミットされた順序を観察し、局面が有利な場合にのみ公開を選択することができ、実行時に実質的にフリーオプションを保持します。暗号化取引に追加料金やスキップペナルティなどの緩和策はありますが、最終的な判断にはさらなる調査が必要だと思います。