Anunciando el protocolo 23

Buen día y bienvenidos al blog de anuncio del Protocolo 23. El Protocolo 23 introduce ocho (!!) nuevas Propuestas de Avance Central (CAPs) a la red de Stellar, detalladas a continuación.

La votación en Mainnet ocurrirá el 3 de septiembre de 2025 a las 10am PST/GMT 17:00. El Protocolo 23 se activó en Testnet el 17 de julio de 2025.

Antes de sumergirnos en los detalles, aquí hay un resumen de alto nivel de lo nuevo en el Protocolo 23:

• SEP-0041: Ahora se pueden emitir eventos de Interfaz de Token de Soroban para todas las operaciones de Stellar que muevan valor en la red. Saber más revisando CAP-0067.
• Los costos de Soroban se reducen gracias a mover el estado de Soroban a RAM. Saber más en CAP-0062 y CAP-0066. Los costos también se reducen debido al caché de módulos descrito en CAP-0065.
• Ya no es necesario la restauración manual de entradas archivadas. Leer más en CAP-0062 y CAP-0066.
• La capacidad de CPU por ledger de Soroban ahora puede aumentarse significativamente, gracias a la ejecución de transacciones paralelas descrita en CAP-0063. La capacidad de lectura por ledger también ha aumentado significativamente, gracias nuevamente a CAP-0062 y CAP-0066.
• Se han añadido funciones de host más útiles a Soroban: getter ejecutable de contrato (CAP-0068) y conversiones de cadena/byte (CAP-0069).
• La configuración de red del Protocolo de Consenso de Stellar (SCP) ahora puede ser manipulada por los validadores, abriendo las puertas para reducir la latencia del ledger. Leer más en CAP-0070.

Profundizaremos un poco más en cada una de estas CAPs a continuación, y siempre puedes entrar en los detalles técnicos en GitHub. Encuentra toda la información relevante sobre la preparación para la votación en la Guía de Actualización del Protocolo 23 Guía de Actualización.

CAP-0062 introduce las características de rendimiento del archivo completo del estado (detallado en CAP-0057, actualmente en forma de borrador) llamado priorización del estado en vivo. La priorización del estado en vivo separará el estado archivado y el estado en vivo en dos bases de datos separadas: la lista de cubo de “Estado en Vivo” y la lista de cubo de “Archivo Caliente”.

La Lista de Cubo de Estado en Vivo se asemeja a la Lista de Cubo actual y contendrá todo el estado en vivo del ledger, incluyendo entradas “clásicas” de Stellar, entradas en vivo de Soroban, configuraciones de configuración de red, etc. La Lista de Cubo de Archivo Caliente almacenará entradas persistentes archivadas de Soroban. Los validadores almacenarán entradas de ambas bases de datos; ningún estado o entrada será eliminado de los validadores en este momento.

Hay beneficios significativos en implementar la priorización del estado en vivo antes del archivo completo del estado, incluyendo hacer la actualización a CAP-0057 mucho más suave con una menor probabilidad de interrupción de aplicaciones.

La implementación de CAP-0062 abre posibilidades para más optimizaciones, incluyendo aquellas introducidas en dos de nuestras otras CAPs del Protocolo 23: CAP-0065 y CAP-0066, descritas a continuación.

CAP-0063 define una nueva estructura de conjunto de transacciones que permite la ejecución paralela de transacciones de contratos inteligentes manteniendo un tiempo de ejecución limitado para conjuntos de transacciones, mejorando la velocidad y la eficiencia de CPU. También ajusta ligeramente la extensión TTL y la lógica de reembolso de tarifas; leer más aquí.

Actualmente, los validadores procesan transacciones de contratos inteligentes una a la vez en un conjunto de transacciones dado, usando solo un núcleo de CPU. Este CAP detalla cómo los validadores pueden ejecutar múltiples transacciones de contratos inteligentes simultáneamente, distribuyendo el trabajo a través de múltiples núcleos de CPU en paralelo. Los contratos inteligentes de Stellar fueron diseñados para el paralelismo desde el principio (gracias a CAP-0046: Datos de Contrato Inteligente), pero nada impedía a los validadores elegir conjuntos de transacciones amigables al paralelismo sobre los que no lo eran. Este CAP aborda esa imprevisibilidad introduciendo una nueva estructura a nivel de protocolo que permite que todos los conjuntos de transacciones se paralelicen de manera predecible.

CAP-0065 introduce un caché de módulos Wasm reutilizable que permite que todos los módulos Wasm desplegados y utilizables permanezcan analizados, validados y traducidos en memoria en todo momento, a través de todos los ledgers.

Antes de que un módulo Wasm pueda ejecutarse, pasa por algunos pasos costosos:

• Análisis: leer el bytecode y convertirlo en un formato estructurado
• Validación: asegurar que el módulo cumpla con las reglas requeridas (por ejemplo, límites de memoria, estructura de función, etc.)
• Traducción: convertir el Wasm en un formato ejecutable por la máquina virtual subyacente

Actualmente, Stellar almacena el resultado de este trabajo en un caché para cada módulo por transacción, lo que significa que el caché existe solo durante la duración de una transacción única y se descarta después. Incluso si el mismo módulo Wasm se usa repetidamente en un conjunto de transacciones o bloque, la red debe rehacer el proceso de análisis, validación y traducción cada vez.

Esta decisión de diseño se tomó inicialmente porque no había una forma clara de atribuir y cobrar tarifas por mantener un caché de mayor duración. Sin embargo, con CAP-0062, Soroban introduce una división entre el estado del ledger en memoria y en disco, permitiendo que el caché de módulos Wasm solo rastree contratos en vivo. Como resultado, el costo de almacenamiento en caché ahora puede vincularse directamente a los momentos en que un contrato entra en memoria a través de las acciones de carga o restauración. Las tarifas de los usuarios serán menores debido a la eliminación de los costos de análisis, validación y traducción durante la ejecución de la transacción.

CAP-0066 introduce el estado de Soroban en memoria, donde todas las entradas en vivo se almacenan en la memoria del validador. Esto elimina completamente las lecturas de disco de las invocaciones de contratos inteligentes, mejorando significativamente el rendimiento y reduciendo las tarifas. Además, esto introduce la restauración automática de entradas de Soroban.

Para lograr esto, CAP-0066 introduce un nuevo tipo de recurso para lecturas de Soroban que distingue entre lecturas en memoria y en disco. Gracias a CAP-0062, el estado en vivo de Soroban puede almacenarse completamente en memoria, eliminando la necesidad de acceso al disco durante la ejecución del contrato. Dado que todo el estado se almacena en memoria, tampoco hay ya un límite de bytes de lectura ni tarifa de lectura para el estado en vivo de Soroban (tenga en cuenta que los límites de entrada de lectura aún se aplican).

Hay cambios en los límites de recursos y tarifas asociados con este CAP; leer más sobre ellos en GitHub aquí.

CAP-0066 también introduce la restauración automática de entradas archivadas de Soroban a través de InvokeHostFunctionOp. Antes del Protocolo 23, los desarrolladores tenían que llamar explícitamente a una operación de restauración para volver a utilizar el estado archivado. Ahora, cada vez que se ejecuta InvokeHostFunctionOp, la red verifica automáticamente la huella y restaura cualquier entrada archivada que necesite antes de la ejecución del contrato. En la mayoría de los casos, ejecutar simulación o preflight detectará entradas caducadas e incluirlas en la huella. Las entradas archivadas que se restauran todavía se tratan como datos basados en disco: se aplican tarifas de alquiler, escritura y lectura.

CAP-0067 permite que las operaciones “clásicas” integradas emitan eventos de activos en el mismo formato que los eventos de transacciones de contratos inteligentes, unificando el flujo de eventos entre invocaciones de contratos inteligentes y operaciones integradas y permitiendo sistemas descendentes más simples.

Los cambios principales introducidos en este CAP son:

• Stellar Core ahora puede emitir eventos para todos los movimientos de activos de Stellar usando el formato de evento de Contrato de Activos de Stellar (SAC), como se define por SEP-0041: Interfaz de Token de Soroban. Hay algunas actualizaciones menores a la especificación SEP-0041 y la implementación de SAC, que puedes leer en GitHub.
• Este CAP también introduce soporte de cuenta multiplexada (cuenta M) en Soroban, junto con actualizaciones correspondientes al SAC para acomodarlo. Debido a que Soroban ahora tiene soporte para multiplexación, el uso de memos de transacción ya no es necesario y por lo tanto está prohibido.
• Este CAP permite a los operadores de infraestructura emitir eventos retroactivamente desde el ledger génesis. Los proveedores de infraestructura que retienen la historia completa y desean soporte completo para eventos de activos de stellar (por ejemplo, indexadores) necesitarán reingresar todos los datos históricos. Leer más aquí.

CAP-0068 propone una nueva función de host de contrato inteligente que recupera el ejecutable asociado con otra dirección de contrato. Actualmente, sin forma de hacer esto, es imposible determinar si un contrato es Wasm o integrado (el único contrato integrado hoy es el Contrato de Activos de Stellar (SAC)) y tomar decisiones basadas en ese conocimiento.

Este CAP habilita varios casos de uso importantes, incluyendo:

• Las cuentas personalizadas pueden hacer cumplir políticas de autorización vinculadas a contratos de confianza.
• Los contratos podrán distinguir entre instancias de SAC y tokens personalizados en la cadena, lo que ayuda a prevenir que los tokens de contrato se hagan pasar por los metadatos de un SAC, útil para puentes que envuelven tokens de Stellar en otras cadenas.
• Los contratos pueden fijar implementaciones exactas de sus dependencias, lo que significa que pueden evitar interactuar con versiones actualizadas o no confiables.

CAP-0069 propone dos nuevas funciones de host de Soroban que facilitan la conversión entre los tipos de cadena y bytes. Aunque las cadenas y los bytes son similares bajo el capó, convertir entre ellos hoy requiere soluciones complicadas e ineficientes, como enlazar a bibliotecas de asignación que de otro modo no serían necesarias. Proporcionar las dos nuevas funciones de host (bytes_to_string, que convierte un ByteObject en un StringObject, y string_to_bytes, que convierte un StringObject en un ByteObject) reduce el tamaño y la complejidad del contrato.

¡Aquí estamos en el último CAP del día, amigos!CAP-0070 introduce configuraciones de ajustes del libro mayor que permiten a la red de Stellar ajustar dinámicamente los tiempos de cierre del libro mayor, los tiempos de espera de nominación y votación, incrementos de tiempo de espera de nominación por ronda y incrementos de tiempo de espera de votación por ronda. Esto permite mejoras incrementales controladas al rendimiento del tiempo de bloque para ayudar a aumentar la escalabilidad, la resiliencia y la eficiencia sin actualizaciones disruptivas del protocolo.

Actualmente, la configuración codificada restringe las mejoras de rendimiento y previene que la red pruebe y adopte gradualmente tiempos de bloque más cortos. Con este CAP, esos parámetros son configurables, permitiendo un ajuste de rendimiento pequeño e incremental. Si el Protocolo 23 pasa y la red se actualiza, no habrá un efecto inmediato en el Protocolo de Consenso de Stellar (SCP), pero abrirá la puerta para cambios futuros.

Aunque estos no son cambios a nivel de protocolo, el Protocolo 23 también introduce algunas actualizaciones adicionales de las que los desarrolladores deben estar conscientes:

• Cambios en el tipo de entero XDR-JSON (leer más en la discusión de GitHub);
• Las especificaciones de contrato se extenderán para admitir eventos (leer más en esta discusión de GitHub).