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

Introducción

Con Agave 4.4, el cliente validador principal de Solana se apoya en la implementación de Alpenglow, simplifica la validación de bloques, agiliza el cálculo de recompensas de staking y reduce el SOL necesario para almacenar programas y datos de cuentas. Estos cambios mejoran la eficiencia diaria y siguen sentando las bases para la ejecución asíncrona. La reciente reducción de los tiempos objetivo de slot a 200 ms acorta las épocas a cerca de un día, lo que permite activar feature gates con mayor rapidez.

Actualizaciones destacadas del ciclo de lanzamiento de Agave 4.4

• Permitir pagadores de comisiones no válidos: Un paso clave para habilitar la ejecución asíncrona
• Cambio automático del tamaño de los programas: Reembolsa la renta sobrante durante las actualizaciones de programas
• Estandarización de shreds: El protocolo ahora exige conjuntos FEC de 32 shreds de datos y 32 de codificación
• Limpieza del stake inactivo: Excluye el stake inactivo de los cálculos de recompensas
• Reducción de la renta: Las últimas tres etapas planificadas de la reducción del 90 % en los depósitos de estado

Permitir pagadores de comisiones no válidos

Se espera que el feature gate de SIMD-0290: Relajar la restricción del pagador de comisiones se active durante el ciclo de lanzamiento de Agave 4.4. Esto cambia lo que ocurre cuando un bloque contiene una transacción cuyo pagador de comisiones no supera la validación, por ejemplo, porque no tiene suficiente SOL. Antes, incluir una transacción de este tipo invalidaba todo el bloque. Con las nuevas reglas de consenso, la transacción permanece en el bloque y los validadores omiten su ejecución sin modificar el estado de las cuentas.

El saldo de un pagador de comisiones puede cambiar a medida que se ejecutan transacciones anteriores. Por lo tanto, exigir que cada transacción tenga un pagador de comisiones válido obliga a los validadores a ejecutar algunas transacciones previas antes de determinar si un bloque es válido. Tratar los fallos del pagador de comisiones como transacciones omitidas elimina esta dependencia específica.

Esto sienta las bases para la ejecución asíncrona, en la que los validadores pueden acordar los bloques y el orden de las transacciones antes de completar la ejecución. La ejecución continúa por separado y aplica las transacciones acordadas al estado de las cuentas. Solana avanza hacia este diseño para permitir futuras mejoras, como tiempos de bloque más cortos y varios proponentes de bloques simultáneos.

Agave representa estas transacciones omitidas como operaciones nulas: no ejecutan instrucciones ni pagan comisiones. Aun así, consumen capacidad del bloque de acuerdo con todos los presupuestos de recursos solicitados o predeterminados, lo que limita cuántas puede incluir un líder. La implementación también conserva la capacidad del líder para filtrarlas durante la producción de bloques, aunque los validadores pueden aceptarlas al reproducir un bloque.

SIMD-0290 se aplica específicamente a las transacciones que usan un blockhash reciente como indicador de vigencia. Las transacciones con nonce duradero requieren un tratamiento adicional, abordado por separado en SIMD-0297: Relajar la restricción de transacciones con nonce no válidas. El cambio es totalmente retrocompatible: todas las transacciones y bloques válidos anteriormente seguirán siendo válidos.

Cambio automático del tamaño de los programas al actualizarlos

Agave 4.4 incluirá la activación de un feature gate para SIMD-0433: Loader V3: ajustar los datos del programa a la longitud de ELF, que hace que las actualizaciones de programas cambien automáticamente el tamaño de la cuenta donde se almacena el código compilado del programa.

Loader v3 (es decir, el loader predeterminado actual para implementar y actualizar programas de Solana) almacena el binario ELF compilado de un programa en una cuenta ProgramData, junto con metadatos como su autoridad de actualización. Antes, los desarrolladores solo podían ampliar esta cuenta, nunca reducirla. Por lo tanto, actualizar a un binario más pequeño dejaba espacio sin usar, y el SOL necesario para mantener ese espacio exento de renta permanecía bloqueado en la cuenta.

Con este cambio, la instrucción Upgrade ajusta el tamaño de la cuenta al encabezado de metadatos más la longitud del nuevo ELF. Un binario más pequeño libera los lamports sobrantes en la cuenta de excedentes de la actualización, el destinatario designado para los fondos restantes. Un binario más grande amplía automáticamente la cuenta, lo que elimina el paso de extensión independiente para las actualizaciones habituales. Las cuentas ProgramData y de búfer ya deben contener suficientes lamports para cumplir el nuevo requisito de renta; de lo contrario, la actualización falla.

Por lo tanto, los desarrolladores que adopten binarios más pequeños podrán recuperar SOL durante su próxima actualización. También se elimina cualquier capacidad adicional reservada previamente. Para las actualizaciones invocadas mediante CPI, sigue aplicándose el límite de crecimiento de cuentas de 10 KiB: los aumentos mayores requieren una extensión previa o una instrucción de actualización de nivel superior. Antes de actualizar, los desarrolladores deben revisar el destino de su cuenta de excedentes para garantizar que los reembolsos lleguen al destinatario previsto.

Este cambio incentiva a los desarrolladores a actualizar a bibliotecas y frameworks más nuevos y eficientes, como Pinocchio. También reduce el espacio que ocupan los programas en Accounts DB.

Estandarización de shreds

Agave 4.4 incluye reglas más estrictas para la propagación de bloques de Solana, descritas en SIMD-0317: Exigir 32 shreds de datos + 32 shreds de codificación. Esto estandariza la estructura que usan los validadores para distribuir y reconstruir los datos de los bloques.

Solana distribuye bloques mediante Turbine, que divide los datos de los bloques en shreds y los retransmite a través de capas de validadores. Los shreds se agrupan en conjuntos de corrección de errores hacia adelante (FEC), que combinan shreds de datos con shreds de codificación que contienen información de recuperación. Con un conjunto de 32 shreds de datos y 32 de codificación construido correctamente, un receptor puede reconstruir los datos originales a partir de 32 de los 64 shreds, lo que ayuda a tolerar la pérdida de paquetes.

Cada shred también incluye una prueba de Merkle que lo vincula con la raíz de Merkle del conjunto, autenticada mediante la firma del líder. Para un conjunto de 64 shreds, esa prueba tiene seis entradas, correspondientes a los seis niveles entre una hoja y la raíz. La verificación del tamaño de la prueba de Agave exige el tamaño esperado para esta estructura fija de 32:32.

Los clientes ya producen 32 shreds de datos y 32 shreds de codificación por conjunto, pero históricamente los validadores receptores han aceptado configuraciones más flexibles. SIMD-0317 elimina esa diferencia al convertir la estructura fija de 32:32 en un requisito del protocolo. Esto simplifica la validación: un receptor puede determinar los límites válidos de los índices de shreds sin esperar a que un shred de codificación revele las dimensiones del conjunto.

La estructura fija también simplifica la detección de equivocación, cuando un líder distribuye versiones contradictorias de los mismos datos. Dos shreds que pertenecen al mismo conjunto FEC, con raíces de Merkle diferentes y firmas válidas del líder, aportan evidencia de ese conflicto. Por lo tanto, estandarizar el formato reduce la complejidad de implementación y facilita la identificación de equivocaciones.

Exclusión del stake inactivo en los cálculos de recompensas

El ciclo de lanzamiento de Agave 4.4 incluirá la activación de un feature gate para SIMD-0599: Eliminar el stake inactivo de las delegaciones de stake, que simplifica la forma en que los validadores gestionan las cuentas de stake inactivas durante la distribución por particiones de las recompensas de época al inicio de cada época. Las cuentas de stake inactivas pueden contener SOL por encima del mínimo requerido para estar exentas de renta, pero no tienen stake activo ni en proceso de activación. Su SOL no está delegado o ya completó su desactivación.

Estas cuentas no obtienen recompensas del protocolo, pero incluirlas puede afectar la cantidad de particiones de distribución de recompensas y el hash de retícula usado para rastrear el estado de las cuentas. Cada cliente validador debe reproducir este comportamiento con precisión, lo que añade complejidad innecesaria al código crítico para el consenso.

El cambio excluye el stake que estuvo inactivo durante la época recompensada y conserva el stake en activación, activo y en desactivación. Por lo tanto, una cuenta de stake que pasa a estar inactiva al comienzo de una nueva época aún recibe las recompensas obtenidas durante la época anterior, en la que estaba en proceso de desactivación.

Mayor reducción de la renta

Se espera que Agave 4.4 incluya las últimas tres activaciones de la reducción gradual de la renta de Solana. Según el plan descrito en SIMD-0437, el saldo mínimo requerido por byte de almacenamiento de una cuenta disminuye de los 6,960 lamports originales a 696 en cinco pasos (es decir, una reducción del 90 %).

Cada activación tiene su propio feature gate, lo que permite que la red evalúe su impacto en la creación de cuentas y el crecimiento del estado antes de continuar.

Reducir este requisito disminuye el capital que los desarrolladores y usuarios deben comprometer al crear cuentas de tokens, PDA y otros estados en cadena. Esto resulta especialmente útil para las aplicaciones que financian la creación de cuentas en nombre de los usuarios, como los servicios de pago a gran escala.

Las estimaciones de Ghost indican que se pueden recuperar más de 3 millones de SOL (~$300 millones). Se han desarrollado varias herramientas para ayudar a los usuarios a recuperar el SOL excedente de sus cuentas.

Conclusión

Los principales cambios de Agave 4.4 se apoyan en Alpenglow y avanzan con mejoras muy esperadas en las recompensas de staking, la implementación de programas y los costos de las cuentas. En conjunto, mantienen el impulso de Solana hacia una red más rápida y accesible. Lo siguiente será Breakpoint London, seguido de Agave 4.5.

Recursos adicionales

• Calendario de lanzamiento de Agave 4.4
• Calendario de seguimiento de feature gates
• Registro de cambios de Agave 4.4
• Pull requests de Agave 4.4