• CAP-83 apunta a condiciones de datos más lentas, mientras que CAP-85 y CAP-86 mejoran las actualizaciones de Soroban y la migración de datos de contratos para los desarrolladores.

  • El cronograma prevé una votación en testnet para el 27 de agosto, seguida de una votación en mainnet el 16 de septiembre para una implementación más amplia en toda la red.

  • La propuesta se centra en la resiliencia de la infraestructura y el mantenimiento de los desarrolladores, ya que Stellar respalda aplicaciones financieras y de tokenización.

El Protocolo 28 de Stellar introduce mejoras de infraestructura enfocadas en el rendimiento del consenso, el mantenimiento de Soroban y las migraciones de contratos a medida que el uso de la red continúa expandiéndose.

El adaptador se centra en el rendimiento central de la red

Scopuly afirma que la actualización próxima fortalece la infraestructura de Stellar bajo la expansión de aplicaciones financieras. El proveedor de la billetera señala tres cambios relacionados con el consenso y Soroban. Esos cambios apuntan a la resiliencia de la red, el mantenimiento de contratos y los flujos de trabajo de los desarrolladores.

https://twitter.com/scopuly/status/2089218979688525949?s=20

CAP-83 aborda situaciones en las que los datos de transacciones llegan lentamente a los validadores. La propuesta permite que los validadores sigan avanzando bajo esas condiciones. Este enfoque busca respaldar un rendimiento de red más consistente durante los retrasos.

Ese enfoque cobra cada vez más relevancia a medida que la actividad de transacciones se expande en Stellar. La red se describe como procesando ya millones de transacciones. Por lo tanto, su infraestructura enfrenta demandas mayores debido al crecimiento de la actividad de las aplicaciones.

CAP-83 difiere de las otras propuestas al enfocarse directamente en el comportamiento del consenso. CAP-85 y CAP-86, en cambio, se concentran en el desarrollo de contratos inteligentes. Juntos, los cambios abarcan tanto las operaciones de red como el mantenimiento de la aplicación.

Las actualizaciones de Soroban apuntan a mejorar la eficiencia de los desarrolladores

CAP-85 permite que múltiples contratos Soroban que comparten código común se actualicen juntos. Esto podría simplificar el mantenimiento en despliegues de contratos más grandes. Los desarrolladores evitarían gestionar cada contrato relacionado como una actualización separada.

Las actualizaciones coordinadas también pueden reducir la complejidad operativa para aplicaciones más grandes. Esto importa cuando varios contratos dependen del mismo código subyacente. Un proceso unificado puede hacer el mantenimiento futuro más llevadero.

CAP-86 aborda otro desafío para los desarrolladores relacionado con migraciones de datos de contratos. Las aplicaciones a menudo necesitan que sus estructuras de datos evolucionen a medida que el software se desarrolla. La propuesta busca simplificar esos cambios sin interrumpir las aplicaciones existentes.

Por lo tanto, las dos propuestas de Soroban abordan diferentes necesidades de mantenimiento. CAP-85 se centra en las actualizaciones coordinadas de código entre contratos. CAP-86 se centra en evolucionar los datos del contrato preservando la continuidad de la aplicación.

El calendario de gobernanza establece los próximos hitos

El proceso de actualización incluye una votación en la red de pruebas programada para el 27 de agosto. Luego, se programa una votación de actualización para la red principal (mainnet) el 16 de septiembre. Estas votaciones representan los próximos puntos de control de gobernanza para los cambios propuestos.

La implementación en la red de pruebas (Testnet) proporciona un entorno para evaluar las modificaciones propuestas. Los desarrolladores y los participantes de la red pueden examinar el comportamiento antes de que se considere la red principal (mainnet). Esto crea una etapa de pruebas antes del despliegue a nivel de producción.

La justificación más amplia se centra en la creciente infraestructura financiera de Stellar. Scopuly señala los activos del mundo real tokenizados y la participación institucional. Esas aplicaciones pueden requerir un consenso confiable y una gestión flexible de contratos.

Por lo tanto, la propuesta representa una preparación de infraestructura más que una única función independiente. Sus tres componentes abordan a los validadores, los contratos inteligentes y los datos de la aplicación. Si se aprueban, los cambios respaldarían el desarrollo continuo de Stellar en torno a casos de uso institucionales.