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 de lanzamientos.

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

Fechas clave

• 5 de junio: lanzamiento 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 para la 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 de Stellar antes de las actualizaciones para evitar rupturas. En general, revisa las notas de versión para instrucciones y requisitos específicos y, salvo que se indique lo contrario, elige la “Última versión”.

Infraestructura de Stellar

• Stellar Core
• Horizon
• RPC
• Galexie

SDKs

• Rust SDK
• JavaScript Base* (ver cambios de ruptura)
• JavaScript SDK
• Go SDK (rpcclient & horizonclient & txnbuild)
• Java
• Python
• iOS
• PHP
• C# .NET
• Flutter
• Elixir Stellar SDK

Lo siguiente es un breve resumen de lo que incluye 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 (contrato inteligente) deleguen su lógica de autenticación a otras direcciones. Se introducen dos nuevas funciones del host: delegate_account_auth, que puede llamarse dentro de la __check_auth función 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 incorporadas 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 aquellas con sus propios firmantes delegados— puede servir como delegada.

La carga útil de firma para este tipo de credencial utiliza un nuevo ENVELOPE_TYPE_SOROBAN_AUTHORIZATION_WITH_ADDRESS envoltura, 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 de autorización internas y ejecutar múltiples pasadas de simulación; cada firmante delegado requería 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 hinchaba innecesariamente el tamaño de la transacción. Zipper convierte la delegación en una función adecuada, de primera clase, que es dramáticamente más simple de implementar correctamente.

A quién debería importarle. Los desarrolladores de Soroban que estén creando cuentas inteligentes —billeteras, esquemas multisig, abstracción de cuentas— verán el beneficio más directo. La delegación pasa de ser un parche frágil a un patrón admitido y eficiente. Los tamaños de las transacciones se reducen, la simulación se simplifica y el código repetitivo alrededor de la construcción de cargas útiles prácticamente desaparece.

Los desarrolladores que sigan la hoja de ruta más amplia de 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 protocolos futuros.

Los usuarios finales y los titulares de billeteras se benefician de forma indirecta: 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 desarrollar.

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

Qué hace. Introduce SOROBAN_CREDENTIALS_ADDRESS_V2, un nuevo tipo de credencial que utiliza la misma ENVELOPE_TYPE_SOROBAN_AUTHORIZATION_WITH_ADDRESS carga útil de firma introducida en CAP-0071-01. A diferencia del 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 por otros medios 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 es necesario migrar de inmediato. El SOROBAN_CREDENTIALS_ADDRESS tipo permanece 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 estrecha y 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 una manera no disruptiva, ofreciendo una ruta de migración en lugar de forzar un cambio inmediato.

A quién debería importarle. Los desarrolladores que creen aplicaciones donde varias cuentas puedan compartir claves, o que deseen 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 el resto, esta es una mejora de baja urgencia a tener en cuenta.

CAP-0071-01 introduce dos nuevas funciones del 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 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 ligada a dirección. El SOROBAN_CREDENTIALS_ADDRESS tipo de credencial sigue siendo válido por ahora, pero deberías empezar a actualizar dependencias y usar los wrappers 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 solo paquete en adelante. Quien esté importando stellar-base directamente debería cambiar esas importaciones a @stellar/stellar-sdk.