Presentamos Adapter, Protocolo 28 en Stellar

La próxima actualización de la red de Stellar, el Protocolo 28—Adapter—, ya viene en camino. Es un lanzamiento enfocado en creadores: la mayor parte de lo que incluye les facilita la vida a quienes escriben contratos inteligentes en Stellar, mientras que un cambio bajo el capó ayuda a la red a alcanzar consenso más rápido a medida que sigue escalando.

Esto es lo que trae Adapter, por qué importa y qué sucede después.

Consenso más rápido, incluso bajo carga (CAP-83)

Cada pocos segundos, los validadores en la red de Stellar acuerdan el siguiente libro mayor. Hoy, parte de ese proceso requiere que los validadores reciban un conjunto completo de transacciones antes de poder avanzar—y compartir esos conjuntos de transacciones por toda la red toma tiempo.

CAP-83 permite que los validadores comiencen a votar antes de que llegue por completo el conjunto de transacciones, y les da una forma clara y explícita de descartar un conjunto que llegue tarde o sea inválido en lugar de quedarse esperando. En la práctica, eso significa que el consenso sigue avanzando incluso cuando los datos de transacciones se propagan lentamente, lo que mejorará el rendimiento y ayudará a que la red funcione sin problemas a escala y a bajo costo. Las mejoras de rendimiento completas se incorporarán gradualmente después del mainnet a medida que se habilite de forma gradual la descarga paralela de conjuntos de transacciones.

Por qué te debería importar: Esta es una mejora entre bastidores—no necesitas cambiar nada para beneficiarte a medida que se implemente—, pero es fundamental. Un proceso de consenso más rápido y resiliente es lo que permite que Stellar siga creciendo sin volverse más lenta. (Los equipos que consumen directamente datos crudos del libro mayor deberían ver la sección “Cambios incompatibles” de la guía de actualización, ya que el cambio añade un nuevo tipo de valor que querrán manejar.)

Actualizaciones atómicas para flotas de contratos (CAP-85)

Muchos protocolos despliegan muchas copias del mismo contrato—una “flota” que comparte el mismo código subyacente. Cuando ese código compartido necesita una actualización (por ejemplo, para enviar una corrección de seguridad), el administrador tiene que actualizar cada instancia una por una. Para flotas grandes, eso no puede hacerse en una sola transacción, lo que deja una ventana en la que algunos contratos ejecutan el código nuevo y otros siguen con el código antiguo.

CAP-85 introduce un ejecutable gestionado externamente: los contratos pueden apuntar a una referencia de código compartida y actualizable, propiedad de otro contrato. Actualiza esa única referencia y todos los contratos que apunten a ella se actualizan de una vez—atómicamente, sin importar cuán grande sea la flota.

Por qué te debería importar: Este es el equivalente en Stellar del patrón “beacon proxy” que los desarrolladores conocen de otras cadenas. Hace que gestionar implementaciones grandes sea dramáticamente más seguro y menos propenso a errores, y elimina el riesgo de que una actualización parcial deje contratos en estados inconsistentes.

Datos de contrato compatibles con la migración (CAP-86)

Al evolucionar los contratos, sus estructuras de datos a menudo necesitan cambiar—añadiendo un campo, eliminando uno no usado o ampliando una interfaz compartida. Hoy, las funciones estándar del host que leen y escriben estas estructuras rechazan cualquier cosa que no coincida con la forma exacta esperada, lo que hace que evolucionar los datos de un contrato en producción sea sorprendentemente difícil y, en algunos casos conocidos, ha dejado contratos atascados.

CAP-86 añade nuevas funciones de host “dispersas” que manejan con gracia campos faltantes o extra en lugar de fallar. Eso les da a los desarrolladores una forma estándar y admitida de migrar los datos del contrato a un nuevo esquema con el tiempo.

Por qué te debería importar: Si mantienes contratos que esperas actualizar a lo largo de su vida, esto hace que los cambios de esquema sean seguros y rutinarios en lugar de una fuente de roturas. Lo obtendrás recompilando contra un SDK actualizado—sin cambios en cómo escribes contratos. Cuando salgan las versiones de tu SDK para el Protocolo 28, asegúrate de revisar la documentación de migración para más detalles.

Adapter es, ante todo, un lanzamiento para creadores. Dos de sus tres cambios (CAP-85, CAP-86) apuntan directamente a hacer que los contratos inteligentes de Soroban sean más fáciles de crear, actualizar y escalar—reduciendo la cantidad de contratos que tienes que desplegar, haciendo las actualizaciones atómicas y seguras, y permitiendo que los datos del contrato evolucionen sin romperse. El tercero (CAP-83) refuerza la capa de consenso sobre la que se apoya todo lo demás.

En conjunto, continúan una línea constante en las actualizaciones recientes del protocolo: hacer de Stellar una plataforma más capaz y más amigable para desarrolladores para aplicaciones financieras reales, sin comprometer la velocidad y el bajo costo por los que es conocida la red.

El Protocolo 28 se despliega en un cronograma fijo. Los hitos principales:

13 de agosto de 2026 — Versión estable de Stellar Core disponible.

13-21 de agosto de 2026 — Versiones estables adicionales (infraestructura y SDKs) disponibles.

27 de agosto de 2026, 1700 UTC — Voto de actualización de la testnet.

16 de septiembre de 2026, 1700 UTC — Voto de actualización de la mainnet.

Si operas infraestructura, un validador, o desarrollas en Stellar, hay pasos que tendrás que seguir para estar listo. Todo lo que necesitas—la cronología completa, enlaces de lanzamiento e instrucciones de preparación para validadores, operadores de infraestructura, usuarios de SDK, billeteras, exchanges, emisores, on/off-ramps y protocolos—está en la Guía de Actualización del Protocolo 28.

Para mantenerte al día con todos los anuncios relacionados con Adapter, únete al Discord para Desarrolladores de Stellar, donde el ecosistema coordina la actualización en el canal #protocol-next.