Ethereum no liquida las operaciones de forma instantánea, pero una nueva infraestructura de Puffer pretende que las aplicaciones puedan ofrecer esa sensación al usuario. La compañía ha anunciado un sistema en el que operadores como Google Cloud garantizan el resultado de una transacción antes de que la red principal complete su liquidación, respaldando esa promesa con garantías económicas.
La red UniFi de Puffer sería la primera en utilizar este mecanismo. Tanto UniFi como Puffer Preconf, el servicio encargado de emitir las garantías anticipadas, seguían en fase de pruebas el 23 de septiembre, según explicó a CryptoSlate el consejero delegado de la empresa, Amir Forouzani. Todavía no está acreditado cómo funcionarán con clientes que muevan dinero real.
Una confirmación antes de la liquidación definitiva
Ethereum trabaja con intervalos de 12 segundos para proponer bloques, que son los lotes en los que se registran las transacciones. La inclusión en uno de esos bloques supone un paso hacia la finalización, pero la confirmación más sólida, conocida como finalización, suele tardar varios minutos. Revertir un registro ya finalizado exigiría un fallo grave en la seguridad de la red y tendría un coste económico muy elevado.
Las aplicaciones deben decidir cuánto tiempo esperan antes de permitir que el usuario actúe. Muchas funcionan sobre redes adicionales, conocidas como rollups, que procesan las operaciones por separado y envían después la información a Ethereum para su liquidación. En ese intervalo, el operador que ordena las transacciones puede ofrecer una confirmación temprana.
La propuesta de Puffer añade una responsabilidad financiera explícita a esa confirmación. Forouzani puso como ejemplo el intercambio de 1 ETH por 2.600 USDC: la pasarela no solo prometería incluir la operación, sino también que el usuario recibiría el resultado previsto. La diferencia es relevante. Garantizar la inclusión de una transacción no asegura que el intercambio se ejecute en las condiciones esperadas.
La compañía afirma que sus tiempos de transacción están configurados en 50 milisegundos, una vigésima de segundo. Ese dato corresponde a la configuración de su sistema y no demuestra, por sí solo, que sea la velocidad que experimentarían los clientes cuando el servicio opere con fondos reales. Ethereum seguiría necesitando su propio tiempo para alcanzar la finalización.
El colateral debe cubrir el coste de equivocarse
El mecanismo se apoyaría en colateral: activos comprometidos por el operador que podrían ser confiscados si incumple sus reglas. Según Forouzani, una preconfirmación fallida supondría para la pasarela una penalización de 1 ETH. La amenaza de perder ese activo pretende alinear el incentivo del operador con la promesa que hace y desincentivar que garantice operaciones que no puede completar.
Sin embargo, aún quedan por aclarar aspectos importantes. Si una aplicación libera 100 dólares en monedas estables basándose en una promesa que después falla, el usuario necesitaría saber si será compensado, quién asumirá el pago y cuánto tardará en recibirlo. El anuncio de Puffer señala que la penalización protege a las partes afectadas, pero las respuestas de la empresa no detallaron quién recibiría el ETH confiscado ni cómo se calcularía y abonaría la compensación.
También importa el tamaño del fondo de garantías. Si un operador respalda muchas promesas con el mismo colateral, varios fallos podrían reclamarlo al mismo tiempo. Además, el valor de una penalización de 1 ETH varía frente al dólar. Las aplicaciones tendrían que comparar los activos disponibles con las pérdidas potenciales que asumirían al aceptar una confirmación anticipada.
Una decisión que seguirá correspondiendo a las aplicaciones
Google Cloud operaría una de las pasarelas. Forouzani indicó que otra asumiría las transacciones si la primera dejara de estar disponible, aunque el funcionamiento de ese relevo con clientes reales todavía debe demostrarse. La primera fase tampoco incluiría delegación por parte de los validadores de la capa base de Ethereum: la garantía inicial procedería de las pasarelas y la red principal se encargaría de la liquidación posterior.
Puffer incluyó la penalización por confiscación en una fase posterior de su documento técnico de julio de 2025, y no se ha establecido cuándo sería exigible bajo el diseño actual. Forouzani afirmó que no se habían producido fallos, pero no aportó el número de transacciones ni el periodo observado.
En la práctica, será cada aplicación la que decida cuándo mostrar un saldo como disponible o permitir una compra. Una operación pequeña podría aceptar una promesa temprana, mientras que una transferencia de mayor importe podría exigir una confirmación más fuerte. El sistema de Puffer ofrece otra opción para reducir la espera, pero su utilidad dependerá de que las condiciones de responsabilidad y compensación estén definidas antes de que el usuario dé por concluida una operación.
