La entrada en escena de un gigante de la Web2 ha llevado al conocimiento del público el concepto de «Gateway», que hasta ahora se encontraba principalmente en contextos técnicos.
El 22 de septiembre, Puffer anunció una alianza con Google Cloud. Como socio clave de infraestructura, Google Cloud ejecutará Gateway a través de Puffer Preconf, dará soporte a la capa de ejecución de Puffer UniFi, ayudará a procesar transacciones y proporcionará preconfirmaciones de ejecución antes de que las transacciones se liquiden definitivamente en Ethereum.
Más destacable aún: Puffer UniFi se convertirá en el primer rollup en utilizar Google Cloud Gateway.
Sin embargo, si esto se interpreta únicamente como «otro gigante de Web2 que entra en Web3», podría pasarse por alto lo más interesante de esta colaboración.
Esto se debe a que Google Cloud no desempeña el papel periférico tradicional de proporcionar capacidad de cómputo, alojamiento de nodos o servicios en la nube a un proyecto de blockchain. Al contrario, está entrando directamente en la arquitectura de ejecución en tiempo real de Puffer UniFi y se convierte en una de las capas de Gateway que conectan el procesamiento de transacciones, Preconfirmation y la liquidación final en Ethereum.
Esto también plantea una pregunta más amplia: ¿qué está construyendo exactamente Puffer UniFi? ¿Por qué necesita Gateway? ¿Y por qué Google Cloud elegiría entrar en Ethereum desde esta capa relativamente baja?
Quizá la respuesta esté en la nueva etapa a la que están entrando las L2 de Ethereum.
I. Puffer UniFi: una respuesta para la segunda mitad de la era de los Rollups
Al entrar en 2026, la estrategia de Rollups de Ethereum se encuentra claramente en un momento delicado.
Desde que Vitalik Buterin inició la reflexión sobre el rumbo de las L2, la misión histórica de estas como herramientas para escalar Ethereum ha llegado a su fin, al menos en esta etapa, tanto en el mercado como en el debate público.
Una pregunta se vuelve cada vez más acuciante: cuando las L2 dejan de ser meras herramientas para aliviar la congestión de L1, ¿cómo deben definir su propia razón de ser? ¿Y cómo pueden volver a establecer con L1 relaciones más unificadas en materia de seguridad, ordenación, liquidez y componibilidad?
Puffer UniFi intenta ofrecer una de esas respuestas.
Puffer UniFi no ha optado por seguir operando un sistema de ordenación centralizado y relativamente independiente, sino por avanzar hacia Based Rollup: anclar de forma más directa el derecho de ordenación de los Rollups en Ethereum L1, permitir que el sistema de validadores de Ethereum participe en la ordenación y heredar, en última instancia, la seguridad y la neutralidad de Ethereum.
Esto no significa que las L2 hayan dejado de tener sentido.
Dicho con mayor precisión, a medida que se completa gradualmente la etapa dedicada a escalar sin más, los Rollups deben volver a definir su propuesta de valor: ¿seguirán existiendo como capas de ejecución generalistas o se convertirán en infraestructura de aplicaciones que coopera más estrechamente con Ethereum, en torno a aplicaciones, casos de uso y experiencias de usuario más definidos?
Hace cinco años, escalar Ethereum mediante L2 era una vía muy práctica y exitosa. Pero hoy, cinco años después, los activos y la liquidez están repartidos entre decenas de islas independientes, y los Rollups necesitan redefinir su posición; por ejemplo, podrían orientarse hacia aplicaciones con casos de uso y límites de negocio claros, como propone Vitalik.
La importancia de Based Rollup radica en su intento de reajustar esta relación.
La idea central no es complicada. Si los Rollups siguen dependiendo de Ethereum para la liquidación y la verificación de seguridad finales, el derecho de ordenación también puede volver más directamente a Ethereum L1, y el sistema de validadores de Ethereum puede encargarse de ordenar los Rollups. En teoría, esto no solo eliminaría la dependencia de los Rollups de un único secuenciador, sino que también permitiría lograr una componibilidad síncrona real entre L1 y L2.
En otras palabras, Based Rollup no propone «crear otra L2 más rápida», sino una respuesta más cercana al enfoque nativo de Ethereum: que escalar no implique fragmentarse y que el crecimiento de las L2 vuelva a reforzar la seguridad y el valor de L1.
En teoría, esta dirección es casi impecable. El problema es que una solución teóricamente óptima no se convierte automáticamente en un sistema utilizable en la práctica:
La primera limitación práctica es la velocidad. Ethereum L1 produce un bloque aproximadamente cada 12 segundos. Si la ordenación del Rollup sigue por completo el ritmo de L1, cada transacción debe esperar al menos un bloque de L1 para obtener una confirmación relativamente fiable. Quizá sea aceptable para una transferencia común, pero no puede compararse con la respuesta en menos de un segundo que ofrecen los secuenciadores centralizados en pagos instantáneos, libros de órdenes, contratos perpetuos o aplicaciones DeFi de alta frecuencia;
La segunda limitación es la carga de ejecución. Como es bien sabido, Ethereum lleva mucho tiempo esforzándose por reducir los requisitos para validar, con el objetivo de permitir que más nodos personales y hardware corriente participen en el consenso de la red. Sin embargo, los Based Rollups exigen que los validadores de L1 asuman directamente funciones como la ordenación de alta frecuencia y la ejecución de baja latencia. Esto puede elevar los requisitos de hardware, red y operación de los validadores, y generar nuevas presiones de centralización en la capa de ejecución;
La tercera limitación proviene de la estructura de incentivos. Para muchos equipos de L2, si migrar a una arquitectura Based implica mayor complejidad técnica sin ofrecer ingresos suficientes, mantener su propio secuenciador centralizado sigue siendo la opción más racional;
Por eso, el problema de Based Rollup nunca ha sido que su dirección sea equivocada, sino que aún le falta una capa de infraestructura práctica para ser realmente utilizable. Mientras el sistema esté totalmente sujeto al ritmo de 12 segundos de L1, será difícil conciliarlo con la velocidad. Y si se quiere conservar la neutralidad de la red principal y ofrecer una experiencia interactiva cercana a la de un secuenciador centralizado, sin volver a centralizar el sistema, es necesario introducir una nueva división de funciones en la capa de ejecución.
Esta es también la contradicción central que Puffer UniFi debe resolver.
En este contexto, Puffer Preconf se incorporó a la pila tecnológica central de Puffer UniFi. Como servicio de preconfirmación construido sobre EigenCloud (antes EigenLayer), mantiene el derecho de ordenación anclado en Ethereum L1, pero ya no exige que los validadores de L1 realicen personalmente toda la ordenación de alto rendimiento, la respuesta de baja latencia y la preconfirmación de ejecución.
En otras palabras, si Based Rollup responde a la pregunta de Puffer UniFi «¿de quién dependen en última instancia la ordenación y la liquidación?», Puffer Preconf resuelve esta otra: «antes de la liquidación final, ¿cómo pueden los usuarios disfrutar de una experiencia de ejecución en tiempo real y confiable?».
Y ese es precisamente el punto de partida para entender Gateway.
II. Ejecución en tiempo real: ¿por qué necesita Puffer UniFi Preconf?
Antes de entender Gateway, primero hay que comprender qué promete exactamente la Preconfirmation.
De hecho, en las principales L2, los usuarios suelen ver rápidamente la respuesta a sus transacciones porque primero un secuenciador centralizado ofrece una especie de garantía blanda y les indica que la transacción ya está en la cola. La interfaz también muestra enseguida el resultado de la ejecución, lo que hace que el usuario sienta que la transacción «ya está confirmada».
Pero, estrictamente hablando, esta respuesta rápida se basa sobre todo en la confianza depositada en un único secuenciador.
Si el secuenciador se cae, sufre retrasos, actúa de forma maliciosa o es objeto de censura, este tipo de compromiso suele carecer de restricciones económicas suficientemente sólidas y de mecanismos verificables de rendición de cuentas. En otras palabras, la «rapidez» de los Rollups tradicionales depende en gran medida de la reputación del propio secuenciador.
Para Puffer UniFi, esto claramente no es suficiente, y Puffer Preconf busca precisamente resolver este problema.
Intenta transformar la «confirmación rápida» de una confianza depositada en un único operador en un compromiso de ejecución respaldado por garantías económicas, compromisos firmados y mecanismos de responsabilidad. No se trata solo de hacer más rápido a Puffer UniFi, sino de hacer que esa «rapidez» sea confiable.
Para entender esta arquitectura, primero hay que comprender cómo se distribuyen las funciones.
En el diseño de Puffer Preconf, los validadores de L1 siguen siendo la fuente última del derecho de ordenación y el ancla de la seguridad y la neutralidad de Ethereum, pero no necesitan operar personalmente un sistema de ordenación de alto rendimiento ni asumir directamente todo el trabajo de ejecución de baja latencia. En cambio, mediante mecanismos de restaking y delegación, los validadores pueden encomendar este trabajo complejo a Gateway, un operador más especializado, que asume en su nombre las funciones de Sequencing y Execution Pre-Confirmation.
En otras palabras, quien asume realmente las responsabilidades de ordenación y preconfirmación es el nuevo actor: Gateway.
No es simplemente un nuevo nombre para el Sequencer centralizado tradicional, ni un «complemento de aceleración» añadido al Rollup. Se parece más a una capa de agentes de ejecución especializados que, bajo la soberanía de L1, reciben el encargo de asumir las funciones de ordenación y preconfirmación:
Por un lado, ayuda a los Proposers de L1 a ofrecer servicios de ordenación y preconfirmación de mayor rendimiento; por otro, mediante mecanismos como garantías, compromisos firmados, penalizaciones y distribución de ingresos, evita convertirse en otro nodo centralizado sin restricciones;
Gateway permite que los validadores no tengan que operar personalmente un sistema de ordenación de alto rendimiento, mientras que la titularidad última del derecho de ordenación sigue anclada en Ethereum L1.
Esto también explica por qué Puffer hace hincapié en Execution Pre-Confirmation y no solo en Inclusion Promise: Inclusion Promise se limita a garantizar que la transacción se incluirá en un bloque, mientras que Execution Preconfirmation aborda además la cuestión de si «la transacción se ejecutará conforme al estado prometido de antemano».
Esta diferencia es sumamente importante para las aplicaciones de alto valor en cadena.
Tomemos como ejemplo un DEX de contratos perpetuos. En estos casos, lo que más temen los usuarios no es que la orden no se incluya en un bloque, sino que, aunque se incluya, el precio final de ejecución, el orden de las operaciones o el estado de liquidación hayan cambiado. En este contexto, Execution Preconf puede garantizar que la orden se ejecute conforme al estado que el usuario vio al cursarla, en lugar de someterlo a deslizamientos adicionales o a resultados de ejecución imprevisibles.
La misma lógica se aplica a los libros centrales de órdenes limitadas en cadena, los flujos de órdenes institucionales, la liquidación de pagos, las liquidaciones de préstamos y la lectura en tiempo real del estado entre capas. Un CLOB necesita un orden de ejecución determinista y respuestas de baja latencia; el trading institucional requiere compromisos de estado sujetos a rendición de cuentas; los pagos y la distribución de salarios necesitan una experiencia de liquidación predecible; y los sistemas de liquidación deben reducir al mínimo las desviaciones de estado cuando los mercados son muy volátiles.
Por supuesto, todo compromiso firme debe ir acompañado de restricciones firmes. En arquitecturas como Puffer Preconf, la confiabilidad de Gateway no proviene de que se declare confiable, sino de que debe asumir consecuencias económicas por sus acciones. Hay al menos dos niveles de restricciones:
Gateway debe aportar una garantía para poder participar en la programación lookahead. Si un Gateway no envía a tiempo el batch a L1 durante el intervalo que le corresponde, un Gateway posterior puede enviarlo en su lugar y activar la penalización del primero;
Desde la perspectiva del usuario, si una transacción acompañada de una promesa de preconfirmación finalmente no se cumple, puede utilizar el recibo firmado de dicha promesa para reclamar una indemnización o solicitar un reembolso;
Cabe tener en cuenta que los mecanismos concretos de penalización evolucionan según la etapa de la red y la versión de la implementación. Por eso, es más preciso decir que el diseño de Puffer Preconf apunta a sustituir los compromisos blandos y carentes de restricciones de los secuenciadores centralizados tradicionales por garantías, recompensas, penalizaciones y responsabilidades vinculadas a firmas, en vez de afirmar que «Gateway ya está sujeto a slashing en todas las situaciones».
Además de la arquitectura técnica, hay otra cuestión ineludible: los incentivos.
Al fin y al cabo, en el modelo tradicional de Rollup, la mayor parte de los ingresos por ordenación va a parar al operador del Rollup; en una arquitectura puramente Based, esos ingresos tienden a fluir de manera más natural hacia los validadores de L1. Ninguno de los dos modelos está suficientemente equilibrado.
La propuesta de Puffer Preconf consiste en repartir las comisiones de preconfirmación y los ingresos relacionados con la ordenación entre distintos actores, como el operador de L2, Gateway, los validadores de L1 y el propio protocolo. De esta manera, los equipos de L2 no tienen que elegir entre «mantener una buena experiencia» y «volver a Ethereum»; los validadores de L1 tienen incentivos para participar en servicios de preconfirmación de mayor rendimiento, y Gateway se convierte en un nuevo actor económico que aporta capacidades de ejecución especializadas.
Lo importante aquí no es «volver a repartir el pastel», sino integrar en un mismo modelo económico de colaboración a varios actores cuyos intereses estaban en tensión. Así, las L2 pueden seguir recibiendo una parte de los ingresos, los validadores de L1 obtienen nuevos incentivos para participar y Gateway genera ingresos por sus servicios especializados, asumiendo responsabilidades mediante garantías, compromisos firmados y posibles mecanismos de penalización.
Llegados a este punto, resulta más fácil comprender la importancia de Puffer Preconf para Puffer UniFi.
La verdadera pregunta que surge a continuación es: ¿quién operará Gateway?
La incorporación de Google Cloud responde precisamente a esta pregunta.
III. De la arquitectura a la realidad: Google Cloud completa la pieza de Gateway de Puffer UniFi
Una vez entendidas las relaciones técnicas anteriores, se aprecia con mayor claridad la importancia de la colaboración entre Google Cloud y Puffer.
La participación de Google Cloud no se limita a una red de Preconf aislada: está entrando directamente en la arquitectura de ejecución en tiempo real de Puffer UniFi como Gateway.
Según el acuerdo anunciado por ambas partes, Google Cloud será un socio clave de infraestructura y operará Gateway a través de Puffer Preconf. Dará soporte al procesamiento de transacciones de la capa de ejecución de Puffer UniFi y ofrecerá Execution Preconfirmation antes de que las transacciones se liquiden finalmente en Ethereum.
Por eso, esta colaboración no debe entenderse simplemente como un «respaldo de un gigante de Web2 a Puffer Preconf». Para Puffer, su importancia radica sobre todo en que la infraestructura empresarial empieza a formar parte real de la arquitectura de ejecución de Puffer UniFi.
Al fin y al cabo, si Puffer UniFi quiere dar servicio a la próxima generación de DeFi, al trading institucional e incluso a los agentes de IA, la ejecución en tiempo real deberá hacer frente a cargas de transacciones reales, estabilidad de la infraestructura, rendimiento de la red y capacidad de funcionamiento continuo.
En otras palabras, el protocolo puede definir las reglas, pero alguien tiene que hacerlas funcionar de manera estable. La incorporación de Google Cloud como Gateway aporta precisamente esa pieza.
Y, ampliando un poco más la perspectiva, la importancia de Puffer UniFi no reside únicamente en convertirse en un nuevo Based Rollup: es, más bien, el lugar donde Puffer lleva primero toda esta arquitectura a un producto.
Más importante aún, si Puffer UniFi demuestra que Based Sequencing, Preconfirmation y Ethereum Settlement pueden coexistir en un entorno de producción real, habrá validado no solo un Based Rollup, sino una nueva arquitectura de Rollup nativa de Ethereum.
Para Puffer UniFi, Puffer Preconf es el módulo clave que permite la ejecución en tiempo real. Desde una perspectiva de infraestructura a más largo plazo, esta capacidad de Preconfirmation también podrá ofrecerse en el futuro a más Rollups.
Para los Rollups existentes, su atractivo se centra principalmente en dos aspectos.
En primer lugar, permite que los equipos de Rollup dejen de asumir por sí solos la carga operativa de los secuenciadores: el trabajo de Sequencing pasa a ser responsabilidad conjunta de Gateway y del sistema de validadores de L1. Al mismo tiempo, gracias a los mecanismos de distribución de ingresos, los equipos de Rollup pueden seguir participando en la captura de valor, en lugar de perder sin más todos los ingresos por ordenación.
En otras palabras, no se pide que los Rollups cedan por completo el pastel, sino que se rediseña el reparto de ingresos entre los propietarios de Rollup, Gateway, los validadores de L1 y el protocolo.
En segundo lugar, puede ofrecer garantías más sólidas de coherencia del estado. Para los usuarios comunes, un deslizamiento de unos centavos o unos dólares en una transacción quizá no sea muy perceptible. Pero en el caso de las órdenes institucionales, los libros de órdenes en cadena, las operaciones con derivados y las liquidaciones de gran volumen, que el precio visto al firmar coincida con el estado final de ejecución determina directamente si el sistema puede gestionar flujos de transacciones de mayor valor.
Por lo tanto, en la arquitectura general de Puffer UniFi, Puffer Preconf desempeña primero el papel de infraestructura de ejecución en tiempo real: ayuda a Based Rollup a resolver los problemas de baja latencia y de compromisos de ejecución confiables, e incorpora al proceso de ejecución capacidades especializadas de procesamiento de transacciones a través de Gateway.
Pero lo que Puffer UniFi busca validar no es solo la Preconfirmation en sí, sino si Based Sequencing, la ejecución en tiempo real, la componibilidad síncrona y Ethereum Settlement pueden combinarse de verdad en una arquitectura de Rollup de alto rendimiento y utilizable.
Desde esta perspectiva, Puffer UniFi no es un «campo de pruebas» para Puffer Preconf, sino la primera materialización en un producto de la visión integral de Puffer sobre la siguiente etapa de los Rollups.
Preconf es el módulo de ejecución en tiempo real; Gateway es la infraestructura especializada que hace posible esta capacidad, y la incorporación de Google Cloud acerca un paso más la arquitectura de Puffer UniFi a un entorno de producción real.
Conclusión
La era de los Rollups no llegará a su fin.
Sin embargo, ahora que las L2 han cumplido su primera misión histórica de «ayudar a escalar Ethereum», hacen falta nuevas propuestas, como Based Rollup, que ofrezcan una respuesta más acorde con la visión de largo plazo de Ethereum.
Esta es también la forma más precisa de entender Puffer UniFi y Preconf.
Con la incorporación de participantes externos de infraestructura como Google Cloud en calidad de Gateway, Puffer UniFi atiende las necesidades reales de ejecución de Rollups, Puffer Preconf proporciona el marco de preconfirmación y seguridad económica, y Gateway incorpora a la red procesamiento especializado de transacciones y ejecución de baja latencia. Finalmente, el estado se liquida en Ethereum.
Si Puffer UniFi logra demostrar que un Rollup puede ofrecer a la vez una experiencia de ejecución en milisegundos, Ethereum-native Settlement, componibilidad síncrona y una red de Gateway más abierta, lo que habrá validado no será solo un nuevo Based Rollup, sino una nueva posibilidad:
Las aplicaciones pueden tener su propio entorno de ejecución de alto rendimiento sin tener que abandonar Ethereum.
La capacidad de ejecución en tiempo real que ofrece Puffer Preconf también podría, una vez validada esta arquitectura, servir a más Rollups, proyectos DeFi, aplicaciones institucionales e incluso agentes de IA.
Al fin y al cabo, Make Ethereum Whole nunca ha sido solo un eslogan atractivo.
Estaremos atentos.
