Preconfirmaciones: La nueva tarea del proposer
Last updated
Last updated
Autor - - Abr '25
El auge de las L2s ha fragmentado tanto la liquidez como la base de usuarios de Ethereum. Los desarrolladores deben elegir entre múltiples cadenas para desplegar sus productos, y aunque han surgido soluciones de interoperabilidad, aún no logran ofrecer una experiencia de usuario fluida y unificada.
Ethereum opera con bloques de 12 segundos, durante los cuales los validadores deben revisar la mempool, seleccionar transacciones, construir el bloque, proponerlo y esperar confirmación. Para maximizar la inclusión de transacciones rentables, los proponentes de bloque suelen esperar hasta el último instante para cerrarlo, corriendo el riesgo de perder la oportunidad de proponerlo. Las preconfirmaciones o preconfs surgen como una posible solución a este problema, ofreciendo a los usuarios garantías tempranas sobre la inclusión y ejecución de sus transacciones sin necesidad de depender de L2s.
Al permitir confirmaciones casi instantáneas, las preconfs podrían mejorar significativamente la experiencia del usuario, reduciendo la incertidumbre y evitando la competencia extrema por la inclusión en bloques. Sin embargo, su implementación plantea nuevas preguntas: ¿Pueden las preconfs mejorar la experiencia de usuario en Ethereum sin comprometer la seguridad y la descentralización? ¿O introducirán nuevos desafíos en la estructura de incentivos de la red?
Un buen ejemplo para entenderlas es el pago con tarjeta de crédito: cuando un usuario realiza una compra, recibe una notificación inmediata de que el pago fue realizado, aunque en su aplicación aún figure como "en proceso". Al mismo tiempo, el comerciante recibe una confirmación de pago, lo que le permite entregar el producto o servicio con la seguridad de que la transacción será validada, incluso si los bancos tardan unos días en liquidarla.
En el ecosistema blockchain, el concepto de preconf ya ha sido adoptado en cierta medida, especialmente en la interacción con distintas L2s. Tomemos como ejemplo Arbitrum: su secuenciador centralizado verifica las transacciones en apenas 250 ms, mucho más rápido que los 12 segundos que requiere Ethereum. Sin embargo, tras enviar los batches de transacciones a la Layer 1, Arbitrum debe esperar dos épocas antes de que estas sean consideradas inmutables. Al igual que en nuestro ejemplo, las transacciones en L2s son confirmadas casi de inmediato para ambas partes, pero su liquidación final tarda más tiempo.
La integración de las preconfs en la capa principal de Ethereum (o based preconfs) busca ofrecer una experiencia similar a la de un secuenciador centralizado, pero dentro de un entorno descentralizado y seguro.
La idea detrás de una preconf es sencilla: un usuario declara su intención de realizar una acción futura. Por ejemplo, Alice quiere enviar 100 USD a Bob en el slot n+2. En este escenario, un proposer hace una promesa: garantizará que la transacción se incluirá en el bloque que le corresponde proponer, sin importar qué ocurra. A cambio, recibe una comisión por este compromiso.
Si el proposer incumple su promesa, el usuario podría slashear al validador responsable y recibir una compensación. Este mecanismo introduce una capa de confianza garantizada por incentivos económicos y penalizaciones onchain.
Para integrar las preconfs basadas en la red principal, se requiere una infraestructura onchain con dos elementos clave:
Proposer slashing: Los proposers deben poder aceptar condiciones adicionales de slashing en caso de incumplimiento.
Estos mecanismos permitirían traer la experiencia de confirmaciones rápidas a Ethereum sin comprometer su seguridad ni descentralización. Desde que se propuso la idea de las preconfs, diversos investigadores y la comunidad en general han mostrado gran entusiasmo por su potencial. ¿Por qué? Porque podrían:
Mejorar la experiencia de usuario y situar a Ethereum a la altura de otras L1s o sidechains en términos de velocidad y usabilidad.
Favorecer la composabilidad, permitiendo que protocolos y aplicaciones interactúen con mayor eficiencia, por ejemplo, habilitando operaciones crosschain.
Beneficiar económicamente a los proposers, ya que recibirían incentivos adicionales por garantizar la inclusión de transacciones.
Para lograrlo, los proposers registrados pueden ejecutar Bolt, permitiendo recibir solicitudes de preconf de los usuarios, confirmarlas y luego transmitir esta información a los relayers y builders. Estos, a su vez, deben generar bloques que cumplan con dichos compromisos, asegurando así que las transacciones preconfirmadas sean efectivamente incluidas en la cadena.
Ahora que comprendemos el concepto general de las preconfs, es importante destacar que no todas son iguales. En blockchain, que un usuario intente realizar una acción no garantiza que esta se ejecute con éxito. ¿Cuántas veces hemos escuchado de alguien que intentó mintear un NFT, pero su transacción nunca pasó?
Existen dos tipos principales de preconfs:
Inclusion Preconfs: Un compromiso más débil que solo garantiza que una transacción será incluida en un bloque, pero sin asegurar que se ejecute. Es decir, la transacción estará en la cadena, pero podría fallar al momento de ejecutarse.
State Preconfs: Un compromiso más fuerte que no solo garantiza la inclusión de la transacción en un bloque, sino también su ejecución y estado resultante. En este caso, la transacción se confirma y se procesa con éxito.
Si bien podría parecer que todas las preconfs deberían ejecutarse sin problemas, en la práctica no todas las transacciones son iguales. Algunas acciones, como transferir tokens, mintear un NFT de colección ilimitada o asignar un subdominio en ENS, dependen solo de la red para procesarse y no enfrentan incertidumbres externas.
Sin embargo, operaciones como hacer un swap, mintear un NFT de edición limitada o pagar un préstamo en DeFi dependen de factores externos, como el price feed de los oráculos o la BaseFee en un bloque específico. En estos casos, una preconf de inclusión podría no ser suficiente para garantizar que la transacción se ejecute exitosamente.
Las preconfs en L2s han surgido como una necesidad para mejorar la experiencia del usuario y garantizar que las transacciones sean rápidas, predecibles y verificables. A diferencia de las preconfs en L1, donde la prioridad suele ser la inclusión de la transacción en un bloque, en L2s las preconfs deben garantizar tanto la inclusión como la ejecución.
En los modelos tradicionales de L2s centralizadas, como Arbitrum y Optimism, los sequencers determinan el orden de las transacciones antes de enviarlas a Ethereum. Esto permite tiempos de respuesta muy rápidos (en el orden de los 250 ms), pero introduce un problema fundamental: los sequencers son centralizados, lo que conlleva riesgos de censura, manipulación y captura de valor del MEV.
En los Based Rollups, las preconfs funcionan bajo el modelo de State Preconfs, lo que significa que no solo garantizan la inclusión de una transacción, sino que también aseguran su ejecución y el estado resultante. Los Based Rollups solucionan esto haciendo a los proponentes L1 de Ethereum responsables de las preconfs en los L2. El mecanismo de preconfs en Based Rollups funciona de la siguiente manera:
Los proposers de L1 deben comprometerse con condiciones de slashing (penalizaciones económicas) para garantizar que las preconfs sean respetadas.
El próximo sequencer en la lista de Ethereum (determinado por la agenda de proposers de Ethereum) otorga preconfs para las transacciones de la L2.
Si ningún validador incluye las transacciones preconfirmadas, el sequencer responsable puede forzarlas on-chain cuando le toque proponer un bloque en Ethereum.
Las preconfs en L2s (no solo en Based Rollups) podrían desbloquear nuevos casos de usos como composabilidad entre rollups debido a que un proposer podría crear preconfs para múltiples L2s al mismo tiempo, garantizando que las transacciones entre estas sean ejecutables en su totalidad.
La introducción de las preconfs en Ethereum no solo impacta la experiencia del usuario, sino que también plantea desafíos económicos y de incentivos dentro del ecosistema. Como cualquier nuevo mecanismo de inclusión y ejecución de transacciones, las preconfs abren preguntas clave sobre cómo:
¿Quién determinará el orden de las preconfs?
¿Quién capturará el valor?
¿Qué mecanismo se utilizará? ¿FCFS, Auctions?
¿Qué impacto tendrá en la cadena de suministro del MEV?
Porque recordemos, no es lo mismo una transacción en la que solo el usuario tiene un rol importante (ej, Alice quiere transferir USDC a Bob) a una en donde más usuarios desean realizar la misma acción (ej, hacer un swap en la pool ETH/USDC en un AMM).
Además, el momento en que se realiza una transacción también influye en su costo. No es lo mismo ejecutar una operación cuando la Base Fee es baja que hacerlo en un slot n+10, donde podría haberse desatado una guerra de fees.
Al día de hoy, cuando un usuario intenta realizar una transacción se puede calcular cuánto ETH deberá pagar por su transacción utilizando la fórmula:
$$ \text{Transaction fee} = \text{Units of gas used} \times \text{(Base fee + Priority fee)} $$
En donde:
Gas limit: El máximo número de unidades de gas a utilizar siendo 21,000 la menor unidad de gas requerida.
Base fee: Es el costo mínimo por unidad de gas que se debe pagar para que una transacción sea procesada. Se ajusta dinámicamente en cada bloque según la demanda de la red.
Priority fee: Es un pago adicional que los usuarios pueden incluir como incentivo para que los proposers prioricen su transacción.
A diferencia del Priority Fee, que es opcional, la Base Fee es un costo obligatorio determinado por el protocolo Ethereum. Se ajusta en cada bloque de acuerdo con el nivel de congestión de la red. Si la demanda es alta, el Base Fee aumenta; si la demanda es baja, disminuye. Su cálculo se basa en la siguiente ecuación:
$$ \text{Next base fee} = \text{Current base fee} \times \text{112.5} \% $$
Si bien se podría considerar un fee mínimo para las inclusion preconfs que pueden ser fácilmente ejecutadas (como una transferencia de USDC), cuando se trata de una State preconf, un precio atractivo en el slot n podría volverse desfavorable en el slot n + 32, afectando las ganancias del proposer si no puede priorizar transacciones más beneficiosas. Entonces, los validadores deben:
Ofrecer precios en las preconfs de forma correcta
Mantener la información de las transacciones privadas (para evitar frontrunnings o sandwichs attacks)
Conseguir que las transacciones no solo sean incluidas, sino ejecutadas.
Las preconfs introducen una nueva capa de negociación y captura de valor en la cadena de suministro del MEV. Su implementación no solo redefine cómo se priorizan las transacciones, sino que también podría reforzar ciertas dinámicas que han llevado a la centralización de los block builders en Ethereum.
Uno de los aspectos más relevantes es el flujo de órdenes (OF), ya que las preconfs podrían generar un nuevo mercado de incentivos en el que algunos validadores prefieran recibir comisiones extra por priorizar ciertas transacciones en L1, mientras que otros podrían establecer acuerdos exclusivos con L2s. Esto abre la posibilidad de que un Flujo de Órdenes Exclusivo (EOF) favorezca a ciertos builders sobre otros, consolidando aún más el mercado.
Para evitar que las preconfs contribuyan a una mayor centralización, el mecanismo que las sustente debería garantizar que la inclusión de transacciones tanto de L1 como de L2 genere más MEV que priorizar solo un tipo de flujo de órdenes:
$$ \text{MEV(A+B) > MEV(A) + MEV(B)} $$
Por otro lado, aunque mantener la información de las transacciones privadas (evitando frontrunnings o sandwichs attacks) pueda parecer una tarea más complicada, los proposers podrían ofrecer garantías de privacidad en sus transacciones al utilizar esquemas como RPC privados garantizando que sus transacciones no sufrirán frontrunning o incluso, esquemas de Subastas del Flujo de Órdenes (OFA) devolviendo a los usuarios un porcentaje del MEV que sus transacciones generen.
A pesar de que muchos researchers han explorado mecanismos para distribuir la construcción de bloques entre diferentes validadores y mitigar la concentración del MEV, las dinámicas de mercado han dictado un camino distinto.
El objetivo de SUAVE es reducir la concentración del flujo de órdenes exclusivo (EOF) y el cross-chain MEV, permitiendo que cualquier validador pueda añadir preconfs dentro de sus bloques sin revelar información crítica sobre las transacciones. De esta manera, se busca equilibrar el acceso al MEV, mitigar la influencia de los builders más grandes y fomentar una mayor descentralización en la construcción de bloques.
Las preconfs tienen el potencial de transformar la experiencia del usuario en Ethereum, reduciendo los tiempos de confirmación en L1 y reforzando las garantías de seguridad en los bloques producidos por L2s. Sin embargo, su implementación plantea desafíos clave, especialmente en torno a los incentivos económicos que impulsarán su adopción y sostenibilidad.
Para que las preconfs sean una solución efectiva y equitativa, será fundamental desarrollar mecanismos que no solo optimicen su funcionamiento, sino que también eviten una mayor centralización en la producción de bloques, asegurando que Ethereum siga siendo una red abierta y descentralizada.
Las preconfs fueron como un mecanismo que garantiza la inclusión de una transacción en un bloque específico, evitando que los usuarios compitan en una guerra de gas para ser procesados en el momento exacto en que el bloque se produce.
proposer forced inclusions: Los proposers deben tener la capacidad de forzar la inclusión de transacciones onchain, por ejemplo, a través de .
Aunque el concepto de preconfs puede parecer técnicamente complejo, ya ha sido probado en la práctica. El 13 de junio del 2024 ocurrieron las primeras preconfs en una y, más recientemente, durante Edge City, se llevó a cabo la en el bloque 21,180,697, donde se minteó un NFT.
El creciente interés en esta tecnología ha impulsado el desarrollo de soluciones como , un protocolo que permite a los proposers comprometerse con los usuarios (a través de EigenLayer) y reducir el tiempo de confirmación de transacciones en Ethereum a menos de un segundo mediante preconfs.
Con el auge de los , se ha propuesto una solución más segura: hacer que los proposers de Ethereum L1 sean los responsables de las preconfs en L2s. Los Based Rollups utilizan una estructura donde los proposers de Ethereum L1 pueden actuar como sequencers descentralizados, eliminando la necesidad de un operador centralizado. Para garantizar que las preconfs sean verificables y confiables, estos proposers deben optar por condiciones de slashing, asegurando que cumplan sus compromisos.
Para poder solucionar el punto uno y tres, se introduce el concepto de (TFE). Mientras que el tradicional garantiza que en una transacción digital ambas partes obtengan lo acordado o ninguna lo haga, TFE añade la dimensión temporal. Esto significa que: a) el usuario busca garantizar que su transacción sea ejecutada llegado el bloque correspondiente y b) el proposer busca recibir una compensación justa sin perder MEV.
Esto incentivaría un modelo donde los validadores prefieran incluir transacciones diversas en lugar de alinearse con un solo tipo de flujo de órdenes, mitigando la “censura” de ciertas transacciones en ciertos (especialmente en escenarios en donde aún con , exista lugar para escoger qué transacciones será incluidas).
Actualmente, más del 95% de los bloques en Ethereum son y tomando en cuenta que las preconfs podrían representar un mercado económico significativo, estas mismas están añadiendo una gran presión de centralización en la cadena de suministro del MEV que podría hacer que tan solo un builder acapara más del 50% de los bloques, o que tan solo dos builders produzcan más del 95%.
Para abordar este problema, Flashbots está desarrollando , una plataforma descentralizada que permitirá la construcción de bloques de manera privada, utilizando (TEEs).
