El anuncio de un upgrade suele llevarnos a buscar la fecha y las funciones nuevas. En Adapter, la versión 28 de Stellar, hay otro recorrido posible: abrir las propuestas y leer sus advertencias.
El anuncio de la Stellar Development Foundation decía que la mejora del consenso llegará por debajo y que no hace falta cambiar nada para beneficiarse. En ese mismo párrafo avisa que quienes consumen datos de ledger en crudo deben revisar las incompatibilidades. La salvedad estaba en el anuncio.
Un CAP, Core Advancement Proposal, es el documento con que se propone un cambio al protocolo de Stellar. Tiene autor, fecha, estado y un enlace a su discusión pública. Adapter reúne tres, con consecuencias distintas para quienes operan la infraestructura y quienes escriben contratos.
La guía de actualización publicó el calendario: versión estable de Stellar Core el 13 de agosto, votación de testnet el 27 y de mainnet el 16 de septiembre. Las dos votaciones estaban previstas para las 17:00 UTC. Se podía preparar la actualización con más de un mes de anticipación.
CAP-83: votar antes de recibir todas las transacciones
Los validadores pueden empezar a votar mientras reciben el conjunto de transacciones del siguiente ledger. CAP-83 permite descartarlo durante la fase de preparación si tarda demasiado o resulta inválido. Así el consenso puede avanzar cuando los datos demoran en llegar.
La sección Security Concerns describe un riesgo: un validador malicioso podría introducir hashes inválidos y forzar el cierre de un ledger vacío tras una demora.
El documento también explica cómo limita ese ataque. El atacante debe ganar la elección de líder. Además, el valor descartado queda registrado con su firma, para que los operadores puedan identificar al responsable y excluirlo de su quorum.
CAP-85: actualizar una flota de contratos de una vez
Un protocolo puede desplegar muchas copias del mismo contrato. Si las actualiza una por una, durante un tiempo conviven versiones distintas del código.
CAP-85 permite que esos contratos apunten a una referencia de código administrada por otro contrato. Cambiar esa referencia actualiza toda la flota de una vez. Es una forma del patrón conocido como beacon proxy.
Esa capacidad exige confiar en el administrador. El CAP advierte que puede modificar el ejecutable y acceder arbitrariamente a los contratos que dependen de él.
En su sección de seguridad, el documento desaconseja heredar una implementación administrada externamente sin examinar esa confianza. Sitúa la respuesta en la documentación y la educación: el protocolo no puede imponer relaciones de confianza entre contratos.
CAP-86: leer datos cuya estructura cambió
Un contrato actualizado puede necesitar añadir o quitar campos de sus datos. Las funciones existentes exigen que la estructura coincida con la esperada; si cambia, la lectura puede fallar.
CAP-86 incorpora funciones para crear y desempaquetar mapas dispersos que admiten campos ausentes o adicionales. Su motivación describe contratos que quedaron inutilizables por las restricciones de las funciones anteriores.
También deja una advertencia: si un contrato usaba aquel rechazo como validación, debe revisar esa comprobación al adoptar las funciones nuevas. Las funciones anteriores conservan su comportamiento. La actualización del protocolo no vuelve más permisivos todos los contratos ya desplegados.
Qué cambia para quien opera
CAP-83 introduce el tipo STELLAR_VALUE_EMPTY_TX_SET, cuyo txSetHash vale 0x0. La guía distingue a quienes necesitan manejarlo:
Indexadores, Galexie y sistemas de analítica que consumen datos de ledger en crudo: reconocer el tipo nuevo y tratar esos ledgers como vacíos.
Integraciones normales basadas en SDK: ese cambio de CAP-83 no exige una adaptación.
Contratos de cuenta personalizados: revisar el contexto de autorización si deben autorizar la creación de contratos con una referencia externa de CAP-85.
Para la infraestructura, la guía pidió instalar las versiones correspondientes de Stellar Core, Horizon, RPC y Galexie. Para los validadores, indicó preparar la votación antes del 9 de septiembre, con la actualización programada para el 16. Esa era una instrucción de preparación.
Los operadores de validador deben sincronizar sus relojes mediante NTP desde Protocol 28. La función que reduce el tiempo de cierre y su variación depende de esa sincronización; sin ella, el rendimiento puede deteriorarse.
CAP-85 y CAP-86 son capacidades de adopción voluntaria. Los equipos que quieran usarlas deben revisar sus contratos y el SDK actualizado; pueden mantener la compatibilidad sin adoptar esos patrones nuevos.
Qué podemos leer en la cifra de rendimiento
El 16 de septiembre, Chainspect anunció un promedio superior a 211 transacciones por segundo durante cien bloques consecutivos. El anuncio coincidió con el día de activación de mainnet.
El panel de Chainspect mostraba el 30 de septiembre un valor de 217,4 transacciones por segundo en «Max TPS (100 blocks)». Es el máximo registrado por esa métrica de cien bloques. El número no trae una atribución causal a CAP-83.
La sección Resource Utilization del CAP espera aumentar el rendimiento al acelerar el consenso. La guía explica que la descarga paralela de conjuntos de transacciones empieza desactivada por defecto y se habilita gradualmente.
Las discusiones también dejan cambios a la vista
Los tres CAP enlazan cuatro hilos públicos. En el de CAP-86, una objeción al nombre de las funciones terminó en la elección de sparse_map_*. En el de CAP-85, se discutieron las condiciones de la referencia externa y qué operaciones debía permitir.
CAP-83 enlaza otros dos. El hilo del valor SKIP contiene una preocupación sobre el tiempo que un atacante podría hacer perder a la red. El de las validaciones de voto presenta tres alternativas y la preferencia del autor por relajar las comprobaciones durante los mensajes de preparación.
En la lectura de esos hilos del 30 de septiembre, los comentarios del primero no tenían respuestas y en el segundo solo había escrito el autor. Esa diferencia importa al describir el proceso: publicar alternativas deja un razonamiento consultable, incluso cuando no aparece una conversación debajo.
La sección de seguridad de CAP-83 sí describe el ataque mediante hashes inválidos y sus mitigaciones. Leo una relación con la inquietud del hilo SKIP, aunque el documento no identifica esa sección como una respuesta al participante. La advertencia quedó escrita; la respuesta en el hilo no aparece.
Lo que el calendario y los documentos dejan comprobar
Quien cambia las reglas de un software que otros usan debe avisar y dejar por escrito sus riesgos. En Adapter podemos comprobar las fechas, las propuestas y las salvedades antes de adoptar sus funciones. Ese es el mínimo que cabe exigirle a una actualización.
El mismo panel de Chainspect registraba 94 validadores y un coeficiente de Nakamoto de 4. El indicador estima el mínimo de validadores independientes que tendrían que coludirse para comprometer la red. No identifica aquí a cuatro operadores concretos.
El acceso a los documentos permite revisar un cambio. Cuánto control está repartido entre quienes sostienen la red es una pregunta que sigue abierta al leer esa cifra.
