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 14 de agosto de 2025, con las CAPs activándose en Testnet el 30 de junio 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 disminuyen 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ódulo 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 en paralelo 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/bytes (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 obtener 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.

CAP-0062: Priorización del Estado Vivo de Soroban

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 vivo. La priorización del estado vivo separará el estado archivado y el estado vivo en dos bases de datos separadas: la “Lista de Cubo de Estado Vivo” y la “Lista de Cubo de Archivo Caliente”.

La Lista de Cubo de Estado Vivo se asemeja a la Lista de Cubo actual y contendrá todo el estado vivo del ledger, incluyendo entradas “clásicas” de Stellar, entradas vivas de Soroban, configuraciones 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 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: Programación de Transacciones Amigable con el Paralelismo

Este CAP define una nueva estructura de conjunto de transacciones que permite la ejecución paralela de transacciones de contratos inteligentes mientras mantiene un tiempo de ejecución limitado para los 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, utilizando 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 con el paralelismo sobre los que no lo son. 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: Caché de Módulo Reutilizable

CAP-0065 introduce un caché de módulo 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 (p. ej., 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 en una base por transacción, lo que significa que el caché existe solo por la duración de una única transacción 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 manera clara de atribuir y cobrar tarifas por mantener un caché más duradero. 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ódulo Wasm solo rastree contratos vivos. 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 subida o restauración. Las tarifas de usuario serán más bajas debido a la eliminación de costos de análisis, validación y traducción durante la ejecución de transacciones.

CAP-0066: Recurso de Lectura en Memoria de Soroban

CAP-0066 introduce el estado de Soroban en memoria, donde todas las entradas vivas 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 las lecturas de Soroban que distingue entre lecturas en memoria y en disco. Gracias a CAP-0062, el estado 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 o tarifa de lectura para el estado vivo de Soroban (nota que los límites de entrada de lectura aún 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 de Soroban archivadas a través del 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, siempre que se ejecute el 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 pre-vuelo 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: Eventos de Activos Unificados

Este CAP propuesto 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 utilizando 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 para cuentas multiplexadas (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 (p. ej., indexadores) necesitarán reingresar todos los datos históricos. Leer más aquí.

CAP-0068: Función de Host para Obtener Ejecutable para `Dirección`

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 manera 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:

• 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 cadena, lo que ayuda a prevenir que los tokens de contrato se hagan pasar por la 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: Funciones de Host para Conversión de Cadenas/Bytes

Este CAP propone dos nuevas funciones de host en Soroban que facilitan la conversión entre los tipos cadena y byte. Aunque las cadenas y los bytes son similares internamente, convertir entre ellos hoy en día 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 a un StringObject, y string_to_bytes, que convierte un StringObject a un ByteObject) reduce el tamaño y la complejidad del contrato.

CAP-0070: Parámetros de Tiempo SCP Configurables

Aquí estamos en el último CAP del día, ¡gente! CAP-0070 introduce configuraciones de ajustes de libro mayor que permiten a la red de Stellar ajustar dinámicamente los tiempos de cierre de libro mayor, los tiempos de espera de nominación y votación, los incrementos de tiempo de espera de nominación por ronda, y los 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 de protocolo disruptivas.

Actualmente, configuraciones codificadas restringen las mejoras de rendimiento y previenen que la red pruebe y adopte gradualmente tiempos de bloque más cortos. Con este CAP, esos parámetros son configurables, permitiendo ajustes de rendimiento pequeños e incrementales. 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 que los desarrolladores deben conocer:

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