🔒🖼️ Nueva publicación: Transacciones de Marco Encriptadas 🔒🖼️ tl;dr: Las transacciones de marco encriptadas se basan en LUCID y EIP-8141 para ocultar los parámetros de ejecución (destino, calldata, montos) hasta que se bloquea el orden del bloque. Este diseño desbloquea la ejecución encriptada en el mismo slot, transacciones en texto plano/encriptadas entrelazadas, y es compatible con esquemas PQ en el futuro. 👇🧵

Los diseños de mempool encriptados hoy en día (por ejemplo, LUCID) retrasan la ejecución hasta el siguiente slot y utilizan un carril dedicado en la parte superior del bloque para transacciones encriptadas. Esta publicación propone la ejecución encriptada en el mismo slot separando el ordenamiento de la ejecución. El constructor se compromete al conjunto completo de transacciones ordenadas antes de que se revele cualquier clave, y luego ejecuta ese ordenamiento comprometido en el mismo slot.

En el ePBS estándar, la oferta del constructor se compromete a un block_hash precomputado. Eso no funciona aquí porque el resultado final depende de qué txs encriptados se revelan y a qué se decriptan. En su lugar, la oferta se compromete a tx_ordering_root, bloqueando la lista completa de transacciones antes de la revelación. Las salidas dependientes de la ejecución (state_root, BAL, recibos) se vinculan solo después.

Esta es la diferencia clave con LUCID. En LUCID, las claves se liberan durante el slot N y la ejecución ocurre al principio del bloque en el slot N+1. El siguiente constructor ya conoce las transacciones desencriptadas al colocar el resto del bloque. Aquí, el compromiso ocurre antes de la revelación, la ejecución permanece en el mismo slot y las txs encriptadas se entrelazan con texto plano en un mismo orden.

Cada marco tx cifrado tiene un marco público de VERIFICACIÓN y una fase de ejecución cifrada oculta. El sobre se compromete a exec_params_binding = H(exec_params). El objetivo, calldata, montos y, opcionalmente, la tarifa de prioridad permanecen ocultos hasta la revelación. Si una clave no llega antes de la fecha límite de revelación del constructor, se omite la fase cifrada. VERIFICACIÓN aún se ejecuta, el nonce se consume y el remitente paga por la parte pública. El gas de ejecución oculta se reembolsa. El orden permanece fijo independientemente.

El constructor aún tiene discreción sobre las revelaciones cerca del límite. Para restringir esto, el diseño utiliza una fusión de vista de atestadores similar a FOCIL: los atestadores no votarán por una carga útil que marque una revelación como faltante si observaron la clave antes de su propio plazo de congelación.

Acerca del problema de la opción gratuita (otra): Un remitente autodesencriptante puede observar el orden comprometido y elegir revelar solo cuando la posición es favorable, manteniendo efectivamente una opción gratuita sobre la ejecución. Existen mitigaciones como tarifas adicionales en transacciones encriptadas o penalizaciones por omisiones, pero creo que se necesitan más exploraciones para tomar decisiones finales.