🔒🖼️ Nueva publicación: Transacciones 🔒🖼️ cifradas de tramas Resumen: dr: Las transacciones de tramas cifradas se basan en LUCID y EIP-8141 para ocultar parámetros de ejecución (destino, datos de llamada, cantidades) hasta después de que se bloquee el orden del bloque. Este diseño desbloquea ejecución cifrada en la misma ranura, transacciones intercaladas de texto plano/cifrado y es compatible para el futuro con esquemas PQ. 👇🧵

Los diseños actuales de mempool cifrados (por ejemplo, LUCID) retrasan la ejecución a la siguiente ranura y utilizan un carril dedicado en la parte superior del bloque para las transacciones cifradas. Esta publicación propone la ejecución cifrada en la misma ranura separando el orden de la ejecución. El constructor se compromete con el conjunto completo de transacciones ordenadas antes de que se revele cualquier clave, y luego ejecuta ese orden comprometido en la misma ranura.

En el ePBS estándar, la oferta del constructor se compromete a una block_hash precalculada. Eso no funciona aquí porque el resultado final depende de qué mensajes cifrados se revelen y a qué cifran descifrados. En su lugar, la puja 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) solo se vinculan después.

Esta es la diferencia clave con LUCID. En LUCID, las claves se liberan durante la ranura N y la ejecución ocurre en la parte superior del bloque en la ranura N+1. El siguiente constructor ya conoce las transacciones descifradas al colocar el resto del bloque. Aquí, el compromiso ocurre antes de la revelación, la ejecución permanece en el mismo espacio y los textos cifrados se intercalan con texto plano en un solo orden.

Cada trama cifrada tiene una trama VERIFY pública y una fase de ejecución cifrada oculta. El sobre se compromete a exec_params_binding = H(exec_params). Target, datos de llamadas, importes y, opcionalmente, la tarifa prioritaria permanecen ocultos hasta que se revelen. Si una clave no llega antes de la fecha límite de revelación del constructor, se omite la fase cifrada. VERIFY sigue ejecutándose, el nonce se consume y el remitente paga por la parte pública. Se reembolsa el gas de ejecución oculta. El pedido se mantiene fijo igualmente.

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

Sobre el problema de la opción libre (otra): Un remitente autodescifrante puede observar el orden comprometido y elegir revelar solo cuando la posición sea favorable, manteniendo efectivamente una opción libre en la ejecución. Existen mitigaciones como tasas adicionales por mensajes cifrados o penalizaciones por saltarse, pero creo que hacen falta más exploraciones para tomar decisiones finales.