Yardstick, Protocolo de Stellar 26

Para el Protocolo 26, la letra Y nos lleva a Yardstick.

No fue una elección difícil. Una vara de medir es lo que buscas cuando la aproximación deja de ser suficiente. No acelera nada ni hace nada más ruidoso. Hace las cosas exactas. La usas cuando una línea debe caer en el lugar preciso, cuando una medición debe ser confiable, cuando el margen de error es cero.

Ese es el carácter de esta actualización. Donde Whisk trataba de velocidad y X-Ray de nueva visión, Yardstick trata de precisión: congelar lo que debe congelarse, manejar los números correctamente en los bordes y dar a los desarrolladores un control detallado sobre cosas que antes requerían soluciones alternativas o tolerancia al riesgo. Lo llamaremos Protocolo Stellar Yardstick (26), o simplemente Yardstick.

Yardstick se activó en mainnet el 6 de mayo de 2026 tras la votación de los validadores. Sigue la guía de actualización para lo último sobre lanzamientos de Stellar. Aquí tienes un resumen rápido de los cambios:

CAP-0077: Capacidad de congelar claves del libro mayor mediante configuración de red. El cambio estrella de Yardstick obtiene su propio nombre y su propia entrada de blog. Lee más sobre Quorum Freeze aquí. La versión corta:

A medida que las instituciones mueven capital real onchain, la pregunta no es solo si una red es rápida o barata, sino si tiene una respuesta gobernada cuando algo sale mal. Hasta ahora, la opción predeterminada de la industria ha sido la improvisación para emergencias. Ninguna L1 importante ha tenido una respuesta nativa del protocolo.

Quorum Freeze cambia eso para Stellar. Introduce configuraciones a nivel de protocolo que permiten a los validadores mantener una lista de claves del libro mayor congeladas. Cuando una clave está congelada, las transacciones de Stellar Smart Contract que la tocarían se rechazan; las ofertas clásicas afectadas se retiran del libro de órdenes. Una allow-list de transacciones explícitamente autorizadas puede eludir la congelación cuando sea necesario.

Lo que hace que esto sea diferente es el modelo de gobernanza detrás. El protocolo de consenso de Stellar, SCP, está desarrollado sobre confianza federada: validadores conocidos y responsables, con relaciones de confianza declaradas públicamente. Un Quorum Freeze es el resultado de ese proceso: identificable, observable y reversible. Para las instituciones reguladas, esa trazabilidad no es un extra agradable. Es el requisito previo para la infraestructura que realmente pueden respaldar.

CAP-0082: Funciones host verificadas para aritmética de enteros de 256 bits. Una de las cosas menos glamorosas pero realmente importantes que puede hacer una plataforma financiera es manejar números de borde sin fallar de forma catastrófica. Hasta ahora, la aritmética de enteros de 256 bits en Stellar Smart Contract hacía trap en overflow—abortando toda la transacción cuando un cálculo llegaba a su límite. Seguro en el sentido de que no produce resultados incorrectos, pero frágil: un contrato que cae en overflow simplemente muere, sin posibilidad de recuperarse.

CAP-0082 introduce variantes comprobadas de las funciones host existentes de enteros de 256 bits para tipos con y sin signo—sumar, restar, multiplicar y potencia. Estas devuelven el resultado, o Void si ocurrió overflow. Los contratos pueden inspeccionar el valor devuelto y decidir qué hacer.

Para desarrolladores que escriben lógica financiera—dimensionamiento de posiciones, cálculos de comisiones, cualquier cosa que implique números potencialmente grandes—esto es una mejora real. Las bibliotecas pueden detectar overflow y manejarlo por diseño, no por fallo. La aritmética sigue siendo barata (sucede a nivel del host), y los contratos se vuelven más robustos.

CAP-0078: Funciones host para realizar extensiones de TTL limitadas. Los contratos de Soroban gestionan la vida útil de sus entradas del libro mayor mediante extensiones de TTL—mantener los datos vivos cuesta XLM, y los contratos manejan eso mediante operaciones de TTL. Las funciones host existentes son toscas: no hay manera de decir “extender como máximo un día” o “extender exactamente a este objetivo pero respetar el máximo de la red”. Esa ambigüedad dificulta escribir políticas de renta equitativas, donde cada usuario paga de forma proporcional por el estado que usa en lugar de subvencionar accidentalmente los TTL largos de los demás.

CAP-0078 introduce funciones host de TTL v2 con parámetros explícitos extend_to, min_extension y max_extension. El host aplica los límites de TTL de la red y ajusta o rechaza extensiones según corresponda. Los contratos ahora pueden avanzar el estado en incrementos precisos, proporcionales al uso real.

CAP-0080: Funciones host para casos de uso ZK BN254 eficientes se basan en el trabajo de BN254 de X-Ray. Agrega nueve nuevas funciones host de Soroban: multiplicación multi-escalar de BN254, aritmética de campo escalar (sumar, restar, multiplicar, potencia, inversa) y comprobaciones de pertenencia a la curva tanto para puntos BLS12-381 como BN254. Esto mueve la aritmética ZK pesada a la capa del host, haciendo que la verificación de pruebas de NoirLang sea significativamente más barata que las implementaciones del lado Wasm. Si estás creando aplicaciones ZK en Soroban, esto es una reducción de costos directa.

CAP-0073: Permitir que SAC cree saldos de cuentas G permite que Stellar Asset Contract cree trustlines ilimitadas para cuentas G directamente, reflejando la semántica de ChangeTrustOp pero impulsado desde Soroban. También actualiza las transferencias de XLM de SAC para crear automáticamente entradas de cuenta al enviar suficiente XLM a una nueva dirección G. Con ello, puedes usar flujos de Soroban para manejar el onboarding clásico y las trustlines de forma nativa, lo que suaviza la UX y simplifica la lógica de la app cuando necesitas admitir tanto cuentas C como G.

CAP-0079: Funciones host para conversiones strkey de direcciones muxed agregan funciones host de conversión de strkey con soporte de primera clase para cuentas muxed, de modo que los contratos puedan convertir nativamente entre strkeys G…/M…/C… y objetos Address/MuxedAddress. Los protocolos cross-chain que ya hablan strkeys pueden trabajar con cuentas muxed sin escribir lógica de codificación personalizada.

Los incidentes ocurren en redes financieras en vivo. El mecanismo de congelación en Yardstick es la primera vez que Stellar tiene una manera onchain, impulsada por consenso, de responder a uno de forma rápida y limpia. Eso importa más de lo que podría parecer—la diferencia entre un hotfix y un mecanismo de cuarentena adecuado es la diferencia entre “lo parcheamos” y “la red lo manejó”.

El resto de la actualización es menos dramática pero igual de útil. La aritmética comprobada, el control preciso de TTL y las operaciones ZK más baratas son el tipo de mejoras que se acumulan—no hacen titulares, pero hacen de Stellar un lugar más confiable para desarrollar aplicaciones financieras serias.

Consulta la Guía de Actualización si aún no has actualizado. Si quieres moldear lo que viene después de Yardstick, la conversación siempre está abierta en Discord.