Guía de actualización de Stellar Zipper, Protocolo 27

Esta guía está diseñada para ayudar a empresas y desarrolladores a prepararse para Zipper, Protocolo 27, proporcionando fechas clave e información sobre lanzamientos.

Mantente al día de todos los anuncios relacionados con Zipper en el Discord para Desarrolladores de Stellar, donde el ecosistema coordina y comparte información sobre la actualización.

Fechas clave

• 5 de junio: versión estable de Stellar Core
• 10 de junio: lanzamientos de RPC y Galexie
• 5-11 de junio: lanzamientos de SDK
• 12 de junio: lanzamiento de Horizon
• 18 de junio de 2026: actualización de Testnet
• 8 de julio de 2026: votación de actualización de Mainnet

A continuación encontrarás enlaces actualizados a todos los lanzamientos disponibles relevantes para el Protocolo 27. ¡Por favor, asegúrate de actualizar tu integración con Stellar antes de las actualizaciones para evitar fallas! En general, revisa las notas de la versión para instrucciones y requisitos específicos y, salvo indicación en contrario, elige la “Última versión”.

Infraestructura de Stellar

• Stellar Core
• Horizon
• RPC
• Galexie

SDKs

• Rust SDK
• JavaScript Base* (ver cambios incompatibles)
• JavaScript SDK (Guía de Migración)
• Go SDK (rpcclient & horizonclient & txnbuild)
• Java
• Python
• iOS
• PHP
• C# .NET
• Flutter
• Elixir Stellar SDK

A continuación hay un breve resumen de lo incluido en el Protocolo 27.

Delegación de autenticación para cuentas personalizadas (CAP-0071-01)

Qué hace. Agrega un mecanismo de protocolo de primera clase para que las cuentas personalizadas (contratos inteligentes) deleguen su lógica de autenticación a otras direcciones. Se introducen dos nuevas funciones de host: delegate_account_auth, que puede llamarse dentro de la función __check_auth de una cuenta personalizada para delegar la autenticación a una dirección especificada, y get_delegated_signers_for_current_auth_check, que devuelve la lista de direcciones de firmantes delegados incluidas en la entrada de autorización actual.

Un nuevo tipo de credencial, SOROBAN_CREDENTIALS_ADDRESS_WITH_DELEGATES, permite que todos los firmantes delegados y sus firmas (potencialmente anidadas) se agrupen en una sola entrada de autorización. Esto elimina la necesidad de una entrada de autorización separada por cada firmante delegado, reduce el tamaño de la transacción y simplifica la simulación. La delegación puede anidarse de forma recursiva, por lo que cualquier cuenta —incluidas las que tienen sus propios firmantes delegados— puede servir como delegada.

La carga útil de firma para este tipo de credencial usa un nuevo ENVELOPE_TYPE_SOROBAN_AUTHORIZATION_WITH_ADDRESS sobre, que vincula explícitamente la carga útil a la dirección de la cuenta de nivel superior, evitando la repetición de firmas entre cuentas.

Por qué importa. La capacidad subyacente —delegar la autenticación de una cuenta personalizada a otra dirección— ya existía en el protocolo, pero solo como un efecto secundario accidental del diseño del marco de autorización. En la práctica era difícil de usar: la simulación requería construir manualmente cargas útiles internas de autorización y ejecutar múltiples pasadas de simulación; cada firmante delegado necesitaba su propia entrada de autorización con su propio nonce, aumentando el costo de la transacción; y reenviar el contexto de autorización a los delegados inflaba innecesariamente el tamaño de la transacción. Zipper convierte la delegación en una característica adecuada, de primera clase, dramáticamente más simple de implementar correctamente.

A quién debería importarle. Los desarrolladores de Soroban que crean cuentas inteligentes —billeteras, esquemas multisig, abstracción de cuentas— verán el beneficio más directo. La delegación pasa de ser un apaño frágil a un patrón admitido y eficiente. Los tamaños de transacción se reducen, la simulación se simplifica y el código repetitivo en torno a la construcción de cargas útiles en gran medida desaparece.

Los desarrolladores que siguen la hoja de ruta más amplia de la abstracción de cuentas también deberían prestar atención. CAP-0071-01 es explícitamente fundamental para CAP-0072, que agrega autenticación basada en contratos a las cuentas clásicas de Stellar (G-). El mecanismo de delegación introducido aquí es el mismo del que dependerán funciones más visibles en futuros protocolos.

Los usuarios finales y los poseedores de billeteras se benefician indirectamente: las transacciones más baratas y diseños de cuenta más flexibles (recuperación social, claves de firma delegadas, multisig modular) se vuelven prácticos de construir.

Credenciales de dirección de Soroban vinculadas a la dirección (CAP-0071-02)

Qué hace. Introduce SOROBAN_CREDENTIALS_ADDRESS_V2, un nuevo tipo de credencial que usa la misma ENVELOPE_TYPE_SOROBAN_AUTHORIZATION_WITH_ADDRESS carga útil de firma introducida en CAP-0071-01. A diferencia del existente SOROBAN_CREDENTIALS_ADDRESS, la nueva carga útil incluye explícitamente la dirección del firmante, evitando ataques de repetición entre cuentas que comparten claves privadas cuando la carga útil de invocación no vincula de otro modo la dirección del firmante.

Los clientes tienen algo de tiempo para adoptar el nuevo tipo de credencial después de la actualización al Protocolo 27; no hay requisito de migrar de inmediato. El SOROBAN_CREDENTIALS_ADDRESS existente sigue siendo válido hasta la actualización al Protocolo 28.

Por qué importa. El tipo de credencial existente es seguro para la gran mayoría de los casos de uso —la vulnerabilidad que cierra es limitada, ya que requiere tanto claves privadas compartidas entre cuentas como una carga útil de invocación que no vincule la dirección del firmante—. Este CAP cierra esa brecha de forma no disruptiva, ofreciendo una ruta de migración en lugar de forzar un cambio inmediato.

A quién debería importarle. Los desarrolladores que crean aplicaciones donde varias cuentas pueden compartir claves, o que quieran adoptar una postura de seguridad más conservadora, deberían planear migrar a SOROBAN_CREDENTIALS_ADDRESS_V2 después de la actualización al Protocolo 27. Para los demás, esta es una mejora de baja urgencia a tener en cuenta.

CAP-0071-01 introduce dos nuevas funciones de host—delegate_account_auth y get_delegated_signers_for_current_auth_check—y un nuevo tipo de credencial, SOROBAN_CREDENTIALS_ADDRESS_WITH_DELEGATES. Estos son cambios aditivos; los contratos y los tipos de credenciales existentes siguen siendo válidos.

CAP-0071-02 introduce SOROBAN_CREDENTIALS_ADDRESS_V2, un nuevo tipo de credencial que usa una carga útil de firma vinculada a la dirección. El SOROBAN_CREDENTIALS_ADDRESS sigue siendo válido por ahora, pero deberías empezar a actualizar dependencias y usar los contenedores apropiados para prepararte. AddressV2 reemplazará a V1 en el Protocolo 28, así que tienes hasta esa actualización para completar esta migración.

@stellar/stellar-base se está consolidando en @stellar/stellar-sdk, por lo que será un único paquete en adelante. Quien esté importando stellar-base debería cambiar directamente esos imports a @stellar/stellar-sdk.