Actualización de Agave 4.2: todo lo que necesitas saber

Introducción

Con Agave 4.2, el cliente validador principal de Solana sigue abriendo nuevos caminos. Esta versión principal se centra en tres mejoras muy esperadas y controladas mediante mecanismos de activación: slots de 200 ms, una reducción del 90% en los depósitos de estado y transacciones de 4096 bytes mediante el nuevo formato de transacción v1. También incluye todas las funciones de Alpenglow antes de su activación prevista para la próxima versión, mientras que la transmisión XDP ahora está habilitada de forma predeterminada.

Actualizaciones destacadas

• Transacciones 3,3 veces más grandes con un nuevo estándar de transacción v1 *
• Reducción del 90% en el depósito de estado (renta) *
• Slots reducidos a 200 ms *
• Todas las funciones de Alpenglow completas
• Nuevas herramientas de gobernanza (relacionadas con SIMD)

* Mejoras controladas mediante mecanismos de activación

Transacciones más grandes (transacción v1)

El ciclo de lanzamiento de Agave 4.2 incluye la activación de una función para admitir transacciones más grandes, de hasta 4096 bytes, frente al antiguo límite de 1232 bytes. Definido formalmente en SIMD-0296: Mayor tamaño de transacción, el límite superior representa un aumento aproximado de 3,3 veces y se aplica exclusivamente al nuevo formato de transacción v1 introducido por SIMD-0385: Formato de transacción V1. Las transacciones heredadas y v0 siguen funcionando sin cambios y permanecen sujetas al límite actual de 1232 bytes.

Para los desarrolladores, esto ofrece mucho más que espacio adicional para datos de instrucciones. Las pruebas criptográficas, las aprobaciones multifirma, las listas extensas de cuentas y otras cargas útiles que antes no cabían en una sola transacción ahora pueden ejecutarse en una única operación atómica nativa del protocolo. El cambio no aumenta los límites de Solana para cómputo, cuentas, firmas ni cantidad de instrucciones.

El límite original de 1232 bytes provenía de la arquitectura de red anterior de Solana. Las transacciones se transmitían como datagramas UDP individuales y debían caber dentro de la unidad máxima de transmisión (MTU) mínima de IPv6, de 1280 bytes. Después de considerar el encabezado IPv6 de 40 bytes y el encabezado UDP de ocho bytes, quedaban 1232 bytes para la transacción. Mantener cada transacción en un solo paquete reducía la fragmentación y hacía más predecible la transmisión.

Hace tiempo que Solana migró de UDP a QUIC para la recepción de transacciones. Los streams QUIC no están restringidos a la carga útil de un solo datagrama de red, por lo que el antiguo límite de 1232 bytes ya no es necesario. Los clientes aún necesitan un límite superior explícito para el control de admisión, la asignación de memoria y la validación de consenso, pero ahora ese límite puede elegirse según los requisitos del runtime y de la aplicación, en lugar de la MTU de IPv6.

Las listas de cuentas suelen consumir una parte importante del tamaño disponible. Cada clave pública Ed25519 o dirección derivada de un programa ocupa 32 bytes, y una transacción debe identificar todas las cuentas que sus instrucciones leen o modifican. Antes, esto imponía un límite efectivo de unas 32 claves de cuenta completas. Para evitarlo, las transacciones V0 introdujeron las Address Lookup Tables (ALT), que reemplazan cada clave de 32 bytes por un índice de tabla de un solo byte y permiten que las transacciones alcancen el límite de 64 cuentas del runtime.

Aunque las ALT son una forma eficaz de compresión, también introducen complejidad. Las aplicaciones deben crear y administrar tablas de consulta onchain. Los servicios RPC y los indexadores que decodifican un mensaje v0 sin procesar deben reconstruir su lista completa de cuentas mediante los metadatos de la transacción o el estado de la tabla correspondiente. Esto crea un problema al analizar transacciones que hacen referencia a una ALT que ya se cerró y dejó de estar disponible onchain. 

Las transacciones v1 resuelven este problema para los desarrolladores, ya que son lo bastante grandes como para contener el conjunto completo de cuentas que actualmente admiten las ALT: 64 claves públicas completas que ocupan 2048 bytes. Por lo tanto, una aplicación que migre desde v0 puede resolver las entradas de su tabla de consulta e incluir las direcciones resultantes directamente en una transacción v1.

Además, los tamaños de transacción de 1232 bytes son especialmente restrictivos para funciones criptográficas como las pruebas de conocimiento cero y las implementaciones BLS que carecen de precompilaciones nativas. Estas cargas de trabajo pueden contener cientos o miles de bytes de datos de prueba o firma. Un límite de 4096 bytes cubre muchos de estos casos de uso criptográficos comunes. 

Especificación de la transacción V1

Una transacción v1 serializada comienza con el byte de versión 0x81. Le siguen un encabezado de mensaje de tres bytes con el estilo heredado, una máscara de configuración de transacción de 32 bits, un especificador de vigencia de 32 bytes, los recuentos de instrucciones y direcciones, el arreglo completo de direcciones de 32 bytes, los valores de configuración, los encabezados de instrucciones de tamaño fijo, las cargas útiles contiguas de las instrucciones y, finalmente, las firmas. 

VersionByte (u8)
LegacyHeader (u8, u8, u8) 
TransactionConfigMask (u32) -- Bitmask of which config requests are present.
LifetimeSpecifier [u8; 32]
NumInstructions (u8)
NumAddresses (u8)
Addresses [[u8; 32]] -- Length matches NumAddresses
ConfigValues [[u8; 4]] -- Length equal to the popcount (number of set bits)
  of TransactionConfigMask. See section TransactionConfigMask for details.
InstructionHeaders [(u8, u8, u16)] -- Length of NumInstructions. Values are
  (ProgramAccountIndex, NumInstructionAccounts, NumInstructionDataBytes)
InstructionPayloads [InstructionPayload] -- Length = NumInstructions.
  Each InstructionPayload is the concatenation of the following byte arrays:
    InstructionAccountIndexes [u8] -- Length = NumInstructionAccounts from the
    corresponding InstructionHeader
    InstructionData [u8] -- Length = NumInstructionDataBytes from the
    corresponding InstructionHeader
Signatures [[u8; 64]]

Los encabezados de instrucciones identifican explícitamente el índice de la cuenta del programa, la cantidad de cuentas de la instrucción y la longitud de sus datos. Esto permite conocer los límites del mensaje sin interpretar la carga útil de cada instrucción.

Las transacciones V1 siguen limitadas a 12 firmas, 64 direcciones de cuenta, 64 instrucciones y 255 índices de cuenta por instrucción. Las transacciones grandes aún deben respetar el límite de unidades de cómputo solicitado, el límite de datos de cuentas cargadas, las reglas de bloqueo de cuentas y la capacidad de ejecución disponible del bloque.

Los analizadores existentes no pueden tratar v1 como v0 con una longitud máxima mayor. Los indexadores, RPC, SDK y la infraestructura de firma que inspeccionan transacciones serializadas deben reconocer el prefijo 0x81 e implementar el nuevo orden de los campos. En particular, las firmas de v1 aparecen al final de la transacción, en lugar de preceder al mensaje como sucede en las transacciones heredadas y v0.

La transacción v1 reemplaza las instrucciones de configuración del programa Compute Budget por campos en el encabezado de la transacción. El valor inicial `TransactionConfigMask` puede declarar lo siguiente para la transacción:

• comisión de prioridad total en lamports
• límite de unidades de cómputo
• límite de tamaño de datos de cuentas cargadas
• tamaño de heap solicitado

Cada bit establecido identifica un valor de configuración adicional de cuatro bytes. La comisión de prioridad de 64 bits ocupa dos posiciones de la máscara. La máscara está diseñada para poder ampliarse en futuras versiones de transacciones.

Reducción del depósito de estado (renta)

Los elevados requisitos de depósito de estado, generalmente denominados “renta”, siguen siendo una de las principales fuentes de fricción de Solana para las aplicaciones que usan muchas cuentas. El nombre puede ser engañoso, ya que la renta no es una comisión de almacenamiento recurrente, sino un depósito reembolsable que una cuenta debe conservar mientras su estado permanezca onchain. Por lo general, los lamports pueden recuperarse al cerrar la cuenta, pero hasta entonces representan capital que un desarrollador o usuario debe aportar por adelantado y mantener inmovilizado.

Agave 4.2 introduce la implementación controlada mediante mecanismos de activación de SIMD-0437: Reducción incremental de lamports_per_byte a 696, que reduce la constante `lamports_per_byte` de 6960 a 696. Esto representa una reducción del 90% en la renta (o, con mayor precisión, en el mínimo exento de renta), aplicada mediante cinco mecanismos de activación independientes: 6960 → 6333 → 5080 → 2575 → 1322 → 696. 

Cuando se activa uno de los mecanismos, Agave actualiza la configuración de renta del Bank y publica el nuevo valor mediante el sysvar Rent. El despliegue por etapas permite que la red observe cómo responden las aplicaciones en cada nivel de precio y se detenga antes de la siguiente reducción si el crecimiento del estado o el uso de recursos de los validadores se vuelven preocupantes.

El mínimo exento de renta de una cuenta se calcula a partir del tamaño asignado a sus datos más una sobrecarga fija de almacenamiento de 128 bytes:

minimum_balance = (128 + account_data_size) × lamports_per_byte

Con este cambio, el mecanismo de renta no se modifica: las cuentas aún necesitan un saldo mínimo y ese saldo sigue siendo recuperable cuando se cierra la cuenta. Solo cambia la cantidad de SOL que debe depositarse.

Una cuenta estándar de SPL Token ocupa 165 bytes. Al incluir la sobrecarga de 128 bytes, su tamaño efectivo es de 293 bytes. La reducción del 90% en la renta disminuye el SOL necesario para una cuenta de este tipo de unos ~$0,16 a menos de 2 centavos. 

Esto tiene consecuencias especialmente importantes para los pagos con stablecoins, las distribuciones de tokens, los sistemas de fidelización y los airdrops directos. Una wallet no almacena tokens SPL directamente; por lo general, necesita una Associated Token Account (ATA) para cada mint. Cuando un destinatario aún no tiene la ATA necesaria, el remitente puede crearla junto con la transferencia, pero también debe financiar el saldo exento de renta del destinatario. Por lo general, este es un costo único de incorporación para cada par de wallet y mint, no un costo que se paga en cada operación posterior. Aun así, a gran escala puede ser lo bastante alto como para determinar si una empresa subsidia la incorporación o transfiere el costo a los usuarios.

Crecimiento del estado de Solana

La reducción por etapas es importante porque disminuir el depósito de estado también reduce la cantidad que un atacante debe inmovilizar para crear y conservar estado no deseado. El estado de Solana se replica, indexa, incluye en snapshots y mantiene en cada validador. Por eso, el crecimiento persistente del estado termina afectando los requisitos de disco, las operaciones de AccountsDB y, en última instancia, los costos operativos.

Según el análisis reciente de Solana Foundation, los archivos de almacenamiento de AccountsDB ocupan aproximadamente 495 GB de la asignación recomendada de 1 TB. Después de la reducción de renta prevista, agotar ese espacio disponible exigiría que un atacante comprometiera aproximadamente $17,2 millones en SOL. Duplicar a 2 TB la asignación de almacenamiento recomendada para validadores eleva a $51 millones el capital necesario para el atacante.

Tras considerar tanto la creación de nuevas cuentas como el cierre de cuentas antiguas, se determinó que el estado crecía aproximadamente 0,3 GB al día.

Un snapshot del estado tomado en la época 997 muestra que el consumo de estado está muy concentrado. Las cuentas de SPL Token representaban la categoría más grande, mientras que las cuentas de OpenBook y Serum ocupaban cerca del 30% del estado activo, como reflejo de la compleja arquitectura de los libros de órdenes onchain. El análisis también estimó que alrededor del 30% del espacio de SPL Token estaba asociado con activos al estilo de la plataforma de lanzamiento de tokens Pump.fun.

Medidas de seguridad

Para reducir de forma segura los depósitos de estado, se necesita una vía viable en la dirección opuesta. Sin cambios adicionales en el runtime, aumentar más adelante el mínimo exento de renta dejaría de inmediato las cuentas existentes por debajo del nuevo umbral. Las transacciones que bloquean esas cuentas para escritura podrían fallar incluso si no asignan estado adicional, lo que provocaría interrupciones generalizadas.

Aquí es donde SIMD-0392: Adaptación del runtime para aumentos de renta cambia la regla de saldo mínimo posterior a la ejecución para que las cuentas existentes puedan conservar sus condiciones anteriores cuando aumente la renta. Cuando una cuenta ya existe, no aumenta de tamaño y mantiene el mismo propietario, su mínimo permitido pasa a ser el menor de los siguientes valores:

1. el mínimo según la tarifa de renta actual
2. el saldo de la cuenta antes de la ejecución

Las cuentas nuevas deben seguir cumpliendo el mínimo exento de renta actual. Lo mismo se aplica a las cuentas que aumentan su tamaño asignado o cambian de propietario. Un saldo de cero sigue representando el cierre de la cuenta. Esto permite que el estado existente continúe operando con su depósito anterior, al tiempo que garantiza que el estado recién asignado pague la tarifa más reciente.

SIMD-0438: Protección ante el aumento del mínimo exento de renta agrega un mecanismo de activación de protección independiente que restablece `lamports_per_byte` al valor heredado de 6960. Su activación está prevista solo si la reducción de la renta provoca un crecimiento excesivo del estado u otro problema operativo importante. Como el mecanismo existe antes de que comiencen las reducciones, los desarrolladores principales no necesitarían diseñar, revisar e implementar un nuevo cambio de consenso en medio de un incidente emergente de crecimiento del estado.

En conjunto, los cinco mecanismos de reducción, las reglas para conservar las condiciones anteriores de SIMD-0392 y el mecanismo de respaldo de SIMD-0438 permiten revertir el despliegue en el nivel del protocolo. La red puede reducir el depósito de forma gradual, observar el comportamiento del estado activo y del almacenamiento de los validadores, detenerse en un valor intermedio o restaurar el requisito original sin obligar a aumentar de inmediato el saldo de todas las cuentas existentes.

Slots reducidos a 200 ms

Una de las mejoras de rendimiento más esperadas de Solana es la reducción del tiempo objetivo de los slots de 400 ms a 200 ms. El principal beneficio es una menor latencia. Con slots de 200 ms, la ventana de liderazgo de cuatro slots de Solana se reduciría de 1,6 segundos a 800 ms. Esto disminuiría los tiempos de confirmación y limitaría el tiempo durante el que un líder malicioso puede retrasar, reordenar o incluir transacciones de forma selectiva. Los slots más cortos también ofrecen a aplicaciones como los consumidores de oráculos y los creadores de mercado una temporización onchain más granular.

La propuesta está diseñada para conservar la economía y el rendimiento actuales de Solana. Los parámetros de inflación, los costos de Validator Admission Ticket con Alpenglow y los límites de trabajo por slot se ajustan de forma proporcional. Sin embargo, si los slots de 200 ms llegan antes que Alpenglow, los costos de votación de los validadores podrían duplicarse aproximadamente, ya que tendrían que votar con el doble de frecuencia.

Para conocer más detalles sobre los slots de 200 ms, consulta nuestra cobertura anterior en el análisis de Agave 4.1.

Otras actualizaciones destacadas

Está previsto activar varias mejoras menores pero destacadas durante el ciclo de lanzamiento de Agave 4.2.

Preparación para Alpenglow

Agave 4.2 incluye todas las funciones de Alpenglow, pero no activará el nuevo protocolo de consenso en mainnet. Los equipos principales de ingeniería usarán este ciclo de lanzamiento para realizar más pruebas, auditorías y tareas de refuerzo antes de la migración del consenso, ahora prevista para Agave 4.3. Por lo tanto, los validadores que ejecuten 4.2 ya incluirán la implementación completa de Alpenglow, incluido el motor de votación Votor y sus componentes de verificación de certificados BLS. 

Para ampliar la revisión de seguridad del código, Anza también organiza una competencia de recompensas por errores de Alpenglow con premios de hasta 50 000 SOL y un periodo de recepción de informes del 5 al 19 de agosto. Alpenglow había quedado excluido anteriormente del programa permanente de recompensas de Agave durante su desarrollo, la migración al monorepo y las auditorías internas. La competencia marca su incorporación al programa de recompensas y busca descubrir problemas que podrían haber escapado de revisiones anteriores.

Conversión de punto flotante a punto fijo en Stake Program

El ciclo de lanzamiento de Agave 4.2 también incluye la implementación controlada mediante un mecanismo de activación de SIMD-0391: Conversión de punto flotante a punto fijo en Stake Program. Esta reemplaza la aritmética de punto flotante IEEE-754 en los cálculos de calentamiento y enfriamiento de Stake Program por cálculos enteros deterministas de punto fijo. La principal motivación es la compatibilidad con la cadena de herramientas eBPF estándar, que no admite operaciones de punto flotante. La cadena de herramientas SBF de Solana puede emularlas mediante rutinas deterministas de punto flotante por software, pero esto es ineficiente e impide la migración de Stake Program hacia una implementación `no_std`.

La mayoría de las aplicaciones no requieren cambios. Sin embargo, los indexadores y las herramientas de staking que reproducen de forma independiente el stake efectivo, en activación o en desactivación deberán implementar las nuevas reglas de enteros cuando se active la función.

Nuevas herramientas de gobernanza

El ciclo de lanzamiento de Agave 4.2 también trae nuevas herramientas de gobernanza que se desarrollan desde el año pasado. Estas herramientas ofrecen un proceso onchain para que tanto los validadores como los stakers nativos indiquen su posición sobre decisiones económicas importantes y decisiones en el nivel del protocolo. 

Su componente central, svmgov, es un programa basado en Anchor que administra la creación de propuestas, el apoyo, la votación ponderada por stake y la finalización. Las ponderaciones de los votos provienen de un snapshot del stake específico de la época, generado por Node Consensus Network (NCN). Los operadores independientes generan el snapshot, alcanzan un consenso sobre una raíz de Merkle canónica y la publican onchain. Luego, los validadores demuestran su stake activo mediante pruebas de Merkle. 

Los validadores con al menos 100 000 SOL de stake activo pueden crear propuestas. Para avanzar en el proceso de votación, las propuestas necesitan el apoyo del 15% del stake del clúster. El repositorio de gobernanza también incluye una CLI de Rust y una interfaz web para votar y hacer seguimiento del apoyo.

Los documentos completos de las propuestas se encuentran en el repositorio independiente Solana Governance Proposals y están vinculados a un commit de Git específico. Mientras tanto, la cuenta onchain de la propuesta almacena el enlace, el estado del ciclo de vida y el recuento de votos. Al principio, los validadores votan con todo el stake que tienen delegado, pero cada delegador conserva la soberanía sobre su SOL. Un staker puede enviar una anulación para una cuenta de stake específica, lo que elimina ese stake del recuento del validador y lo reasigna según el voto del propio staker.

Las Solana Governance Proposals (SGP) buscan complementar los SIMD, no reemplazarlos. Una SGP responde a la pregunta de dirección sobre si la red debe adoptar un cambio, mientras que el SIMD asociado especifica cómo debe implementarse.

Tres SGP ya superaron la fase de apoyo y conformarán la primera ronda de votaciones de gobernanza con el nuevo sistema:

• SGP-0001: La Constitución de Solana propone ratificar un contrato social canónico de gobernanza que defina las funciones de los desarrolladores, validadores y stakers, y establezca formalmente el proceso de SGP.
• SGP-0002: Doble desinflación pide a la red duplicar la tasa anual de desinflación de SOL del 15% al 30%, sin cambiar la tasa de inflación terminal del 1,5%. Esto acortaría el tiempo estimado para alcanzar esa tasa terminal de aproximadamente 5,7 años a 2,8 años. 
• SGP-0003: Comisión por recursos e inclusión propone reemplazar la estructura actual de comisión base fija por una comisión de inclusión de 2500 lamports pagada al líder y una comisión separada por recursos, basada en las unidades de costo de transacción solicitadas, que se quemaría en su totalidad. La distribución de las comisiones de prioridad permanecería sin cambios.

Conclusión

Agave 4.2 es una de las versiones más importantes de Solana de los últimos tiempos. Los slots más rápidos de 200 ms acercan la red a una capacidad de respuesta en tiempo real. La reducción prevista del 90% en los depósitos de estado hace que crear cuentas sea mucho más asequible. Además, la transacción v1 de 4096 bytes ofrece mucho más espacio para instrucciones complejas, pruebas criptográficas y aplicaciones que usan muchas cuentas. En conjunto, estos cambios hacen que Solana sea más rápida, económica y expresiva tanto para desarrolladores como para usuarios.

Recursos adicionales

• Calendario de lanzamiento de Agave 4.2
• Calendario de seguimiento de mecanismos de activación
• Registro de cambios de Agave 4.2
• Pull requests de Agave 4.2