🔒🖼️ Nouveau post : Transactions de Cadre Chiffrées 🔒🖼️ tl;dr : Les transactions de cadre chiffrées s'appuient sur LUCID et EIP-8141 pour cacher les paramètres d'exécution (cible, calldata, montants) jusqu'à ce que l'ordre du bloc soit verrouillé. Ce design permet une exécution chiffrée dans le même slot, des transactions en texte clair/chiffrées entrelacées, et est compatible avec les schémas PQ pour l'avenir. 👇🧵

Les conceptions de mempool chiffrées aujourd'hui (par exemple, LUCID) retardent l'exécution jusqu'au prochain créneau et utilisent une voie dédiée en haut de bloc pour les transactions chiffrées. Ce post propose une exécution chiffrée dans le même créneau en séparant l'ordonnancement de l'exécution. Le constructeur s'engage à l'ensemble complet des transactions ordonnées avant que toute clé ne soit révélée, puis exécute cet ordonnancement engagé dans le même créneau.

Dans l'ePBS standard, l'enchérisseur s'engage sur un block_hash pré-calculé. Cela ne fonctionne pas ici car le résultat final dépend des transactions chiffrées qui sont révélées et de ce qu'elles déchiffrent. Au lieu de cela, l'enchère s'engage sur tx_ordering_root, verrouillant la liste complète des transactions avant la révélation. Les sorties dépendantes de l'exécution (state_root, BAL, reçus) ne se lient qu'après.

C'est la principale différence avec LUCID. Dans LUCID, les clés sont libérées pendant le slot N et l'exécution se fait en haut du bloc dans le slot N+1. Le prochain constructeur connaît déjà les transactions décryptées lorsqu'il place le reste du bloc. Ici, l'engagement se fait avant la révélation, l'exécution reste dans le même slot, et les txs chiffrés sont entrelacés avec du texte en clair dans un même ordre.

Chaque trame chiffrée tx a une trame publique VERIFY et une phase d'exécution chiffrée cachée. L'enveloppe s'engage à exec_params_binding = H(exec_params). La cible, le calldata, les montants, et éventuellement les frais de priorité restent cachés jusqu'à la révélation. Si une clé n'arrive pas avant la date limite de révélation du constructeur, la phase chiffrée est ignorée. VERIFY s'exécute toujours, le nonce est consommé, et l'expéditeur paie pour la partie publique. Les frais d'exécution cachés sont remboursés. L'ordre reste fixe, peu importe.

Le constructeur a toujours la discrétion sur les révélations proches de la date limite. Pour limiter cela, le design utilise une fusion de vue d'attesteur similaire à FOCIL : les attesteurs ne voteront pas pour une charge utile qui marque une révélation comme manquante s'ils ont observé la clé avant leur propre date limite de gel.

À propos du problème de l'option gratuite (autre) : Un expéditeur auto-décryptant peut observer l'ordre engagé et choisir de révéler uniquement lorsque la position est favorable, tenant ainsi effectivement une option gratuite sur l'exécution. Des mesures d'atténuation comme des frais supplémentaires sur les transactions chiffrées ou des pénalités de saut existent, mais je pense que davantage d'explorations sont nécessaires pour prendre des décisions finales.