Actualización de Agave v2.2: todo lo que necesitas saber

Actualizaciones destacadas del ciclo de lanzamiento de Agave 2.2 

• Amplias optimizaciones de rendimiento
• Aumento del 20 % en los límites de bloque, de 50M a 60M CUs
• Introducción de Accounts Lattice Hash (ALH)
• Verificación de firmas Secp256r1 (pospuesta desde el ciclo de lanzamiento de Agave 2.1)
• Despliegue y ejecución de programas SBPFv1, v2 y v3
• Eliminación de la restricción del invocador de CPI
• Loader-v4

Cada sección de este artículo es independiente, por lo que puedes explorar fácilmente los temas que más te interesan. Ya sea que operes un validador, desarrolles o participes activamente como usuario, esta guía completa de Agave 2.2 ofrece la información clave que necesitas para aprovechar al máximo las últimas mejoras.

Implementación de funciones

Al momento de escribir este artículo, el 19.8 % del stake total ejecuta Agave v2.2.*, lo que demuestra un fuerte apoyo a su adopción en toda la red. Las activaciones de funciones en mainnet se pausaron temporalmente durante el periodo de actualización y se espera que se reanuden poco después, según la secuencia de activación prevista.

La mayoría de las funciones principales introducidas en Agave 2.2 están actualmente restringidas y aún no están activas en mainnet. Se habilitarán progresivamente durante el ciclo de lanzamiento 2.2 mediante el sistema de activación de funciones de Solana. El momento de activación depende de la prioridad de cada función y de su orden de implementación en los clústeres de testnet y devnet. Consulta el seguimiento de activación de funciones de Agave para ver las últimas novedades.

Aumento de los límites de bloque a 60M CUs

Anza estableció un objetivo ambicioso para 2025: duplicar el espacio de bloque disponible en Solana. Como parte de este esfuerzo, está previsto incluir SIMD-0256: Increase Block Limits to 60M en la próxima versión 2.2 de Solana, lo que representa un aumento del 20 % sobre el límite de bloque actual.

Esto continúa una actualización anterior que aumentó los límites de bloque de 48 millones a 50 millones de unidades de cómputo (CUs). Después de ese cambio, los tiempos de bloque se mantuvieron sistemáticamente por debajo del objetivo de 400 ms. Los datos recientes muestran que los bloques alcanzan habitualmente el límite de 50M CUs, lo que indica que la red está lista para seguir escalando.

Nota: algunos bloques aparecen con una ocupación del 104 % debido a una constante codificada en la lógica de informes del panel de Firedancer.

Los demás límites del protocolo no cambian con esta actualización:

• El presupuesto de cómputo por cuenta y por bloque se mantiene en 12 millones de CUs.
• El cómputo máximo por transacción sigue limitado a 1.4 millones de CUs.
• El límite de cómputo agregado para transacciones de voto por bloque se mantiene en 36 millones de CUs.
• La asignación máxima de datos de cuentas nuevas por bloque sigue limitada a 100 MB.

Aumentar los límites de bloque afecta directamente la experiencia del usuario: un mayor rendimiento de la red reduce la mediana de las comisiones por transacción y aumenta la probabilidad de procesar transacciones correctamente durante periodos de congestión.

Desafíos al aumentar los límites de bloque

Al aumentar el rendimiento, conviene elevar los límites de bloque de forma cuidadosa y gradual, ya que deben resolverse dos desafíos clave:

1. Preparación de la infraestructura

La infraestructura general del ecosistema debe avanzar al mismo ritmo que las optimizaciones del cliente principal. En concreto, la capa de escritura no puede superar a la capa de lectura (por ejemplo, nodos RPC, indexadores y servicios de archivo) sin perjudicar la experiencia del usuario.

2. Propagación oportuna de bloques

Otro cuello de botella está en la entrega de bloques desde el nodo líder al resto del clúster. Los bloques mucho más grandes podrían hacer que los tiempos de distribución superen el objetivo de 400 ms, especialmente en condiciones de alta carga.

Un desafío urgente es la etapa de retransmisión de la Unidad de Validación de Transacciones (TVU), mediante la cual los shreds se distribuyen por todo el clúster. Los validadores grandes se acercan a 150,000 paquetes salientes por segundo (PPS) debido al agresivo factor de distribución de 200 de Turbine (es decir, cada nodo se encarga de retransmitir shreds a otros 200 nodos). Si esto se gestiona de manera ineficiente, puede generar acumulaciones de shreds, transferencias erráticas entre líderes y vistas de estado inconsistentes en toda la red.

Para resolverlo, los ingenieros de Anza están rediseñando el flujo de distribución de bloques. El equipo trabaja actualmente en la transición a XDP (eXpress Data Path), que permite omitir el kernel al exponer la gestión de paquetes directamente al espacio de usuario. Este enfoque elimina costosas copias intermedias y permite que el software del validador se comunique directamente con la tarjeta de interfaz de red (NIC).

Accounts Lattice Hash (ALH)

Para que Solana pueda admitir miles de millones de cuentas, necesita un enfoque más escalable para calcular el hash del estado global de las cuentas. El nuevo Accounts Lattice Hash (ALH) reemplazará los hashes de cuentas anteriores basados en Merkle por una alternativa más eficiente y escalable basada en hashing homomórfico. Esto permite crear un hash nuevo a partir de hashes existentes sin tener que recalcularlo desde cero.

Actualmente, Solana mantiene dos hashes del estado de las cuentas:

• Epoch Accounts Hash (EAH): una raíz de Merkle de todo el estado de las cuentas, calculada una vez por época.
• Accounts Delta Hash (ADH): una raíz de Merkle de las cuentas modificadas dentro de un solo bloque, recalculada en cada bloque.

Ambos dependen de ordenar las cuentas por clave pública y construir árboles de Merkle, lo que genera problemas de rendimiento y escalabilidad, especialmente a medida que crece el conjunto de cuentas. El modelo de dos hashes surgió como una solución intermedia: EAH era preciso (incluía todo el estado de las cuentas), pero poco frecuente; ADH era frecuente, pero parcial (solo incluía las cuentas modificadas). Lo ideal sería que cada bloque contuviera un hash completo y actualizado de todo el estado de las cuentas, sin el costo adicional de recalcular un árbol de Merkle.

Accounts Lattice Hash: cómo funciona

ALH logra este objetivo mediante una función de hashing homomórfica que permite actualizaciones incrementales. En lugar de reconstruir un árbol de Merkle cada vez, ALH simplemente suma o resta hashes de cuentas individuales (LtHashes) a medida que se escribe en las cuentas. El resultado final es un único hash de 2048 bytes que resume el estado de todas las cuentas. Lo más importante es que puede actualizarse bloque a bloque sin tener que recalcularse desde cero.

Este enfoque ofrece una complejidad O(n), una mejora considerable frente a la complejidad O(n log n) de los árboles de Merkle. Permite que cada bloque incluya un hash de todo el estado de las cuentas sin recalcularlo a un alto costo.

Integración y hashes retirados

La implementación abarca tres SIMDs independientes, cada uno con su propia activación de funciones durante el ciclo de lanzamiento de Agave 2.2.

• SIMD-0215: Accounts Lattice Hash
• SIMD-0220: Las instantáneas usan Accounts Lattice Hash
• SIMD-0223: Eliminación de Accounts Delta Hash

Con estos cambios, Accounts Lattice Hash reemplaza tanto a ADH como a EAH. ALH se integrará en el hash del banco de cada bloque, lo que permitirá calcular el hash del estado completo con la frecuencia de los bloques, en lugar de hacerlo una vez por época.

Rendimiento y concesiones

El cambio a ALH ofrece importantes ventajas de rendimiento para los validadores, ya que elimina el hashing basado en Merkle en cada bloque. Esto agilizará el consenso y la generación de instantáneas. Por ejemplo, los validadores ya no tendrán que ordenar cuentas ni reconstruir árboles durante la finalización de bloques o la generación de instantáneas: las actualizaciones de ALH son simples operaciones aditivas.

Sin embargo, este enfoque no admite pruebas de inclusión ni exclusión, a diferencia de los árboles de Merkle o Verkle. Aunque esto afecta ciertos casos de uso de verificación criptográfica, como clientes ligeros y la Verificación de Pagos Simplificada (SPV), se considera que la concesión vale la pena por las enormes mejoras de eficiencia. Puedes consultar aquí un análisis sobre métodos alternativos para las pruebas de inclusión.

Integración de instantáneas

Como calcular el Accounts Lattice Hash inicial es costoso, el valor de ALH ahora persiste en las instantáneas del validador y se restaura al iniciar, si está disponible. Las instantáneas reflejarán el formato actualizado de ALH en lugar de los Snapshot Hashes basados en Merkle, lo que alinea aún más el modelo de almacenamiento y hashing de Solana con este nuevo diseño.

Verificación nativa de firmas Secp256r1

Solana está agregando soporte nativo para verificar firmas de curva elíptica secp256r1, una actualización fundamental que permite la compatibilidad on-chain con Passkeys, el estándar WebAuthn y modelos avanzados de abstracción de cuentas, incluida la autenticación de dos factores (2FA). Esta actualización lleva al entorno Web3 la autenticación sin contraseña, que ya es habitual en Web2, y mejora la seguridad y facilidad de uso de las aplicaciones on-chain.

Esta función se había programado inicialmente para Agave 2.1, pero se pospuso hasta la versión 2.2. Para obtener más información, consulta nuestro análisis completo de la verificación de firmas Secp256r1 en la actualización de Agave 2.1.

Error de alineación de precompilados

Poco después de la implementación inicial de Agave 2.2, se descubrió un error crítico en la implementación de los programas precompilados Secp256r1 y Ed25519. El error se activaba con la nueva marca de vista `--transaction-structure`, que expone diseños de transacciones sin procesar sin garantizar su alineación. Los precompilados asumían incorrectamente una alineación de 2 bytes para los datos de instrucciones, lo que provocaba resultados de ejecución inconsistentes entre productores de bloques y validadores. Esto generaba discrepancias en el hash del banco y obligaba a los líderes a abortar, lo que causaba una pérdida de disponibilidad. El problema se reportó por primera vez el 9 de abril y se corrigió rápidamente el 11 de abril. El error no afectó los fondos de los usuarios. Puedes consultar más detalles en el análisis de causa raíz publicado poco después.

Despliegue y ejecución de programas SBPFv1, v2 y v3

Solana Berkeley Packet Filter (SBPF) es una máquina virtual personalizada diseñada para ejecutar programas de Solana de forma eficiente y segura. Es una bifurcación basada en Rust de extended Berkeley Packet Filter (eBPF), creado inicialmente para Linux. 

Las actualizaciones de Solana Berkeley Packet Filter (SBPF) son esenciales para mejorar el rendimiento, reforzar la seguridad y ofrecer nuevas capacidades a los desarrolladores de aplicaciones. Agave 2.2 sienta las bases para el mantenimiento a largo plazo y las mejoras de rendimiento al introducir un sistema formal de control de versiones para la máquina virtual SBPF, descrito por primera vez en SIMD-0161. Este cambio permite desplegar y ejecutar programas SBPFv1 (SIMD-0166), SBPFv2 (SIMD-0173, SIMD-0174) y SBPFv3 (SIMD-0178, SIMD-0179, SIMD-0189). Así se establece un marco sostenible para hacer evolucionar por etapas el entorno de ejecución de programas sin requerir nuevos despliegues en toda la red.

Hasta ahora, todas las actualizaciones de SBPF debían introducirse mediante activaciones globales de funciones, lo que dificultaba la evolución del entorno de ejecución y hacía casi imposible coordinar los despliegues. El control de versiones resuelve esto al desacoplar el comportamiento del programa del entorno de ejecución global y vincularlo a una etiqueta de versión por programa, codificada en el campo e_flags del encabezado del archivo Executable and Linkable Format (ELF). Este enfoque permite lo siguiente:

Comportamiento explícito del entorno de ejecución

Cada programa indica la arquitectura del conjunto de instrucciones que espera (es decir, una versión de SBPF). El entorno de ejecución del programa modifica su comportamiento según esta versión.

Implementación controlada

Las activaciones de funciones habilitarán de forma independiente el despliegue y la ejecución de nuevas versiones de SBPF, mientras retiran gradualmente las anteriores. Los conjuntos completos de cambios se agrupan en distintas versiones de SBPF, lo que hace que las actualizaciones sean más claras y fáciles de gestionar.

Retiro gradual

Con el tiempo, se podrá retirar la compatibilidad con versiones anteriores de SBPF cuando queden obsoletas, lo que simplificará la lógica de la máquina virtual. Este proceso será lento para que los desarrolladores tengan tiempo suficiente de migrar o volver a desplegar sus programas y adaptarlos a las versiones más recientes.

Discriminador de versión

Actualmente, el protocolo trata como SBPF v0 cualquier valor de e_flags distinto de 0x0020, lo cual es válido en el sistema existente. Sin embargo, este enfoque no permite admitir varias versiones de SBPF y debe actualizarse.

Cuando se active la primera función que habilite una nueva versión de SBPF, el protocolo cambiará la forma en que interpreta e_flags y asignará directamente el valor al número de versión de SBPF correspondiente. Con este sistema, 0x0000 representará SBPF v0, 0x0001 representará SBPF v1, y así sucesivamente.

Eliminación de la restricción del invocador de CPI

El ciclo de lanzamiento de Agave 2.2 incluye una mejora muy esperada que elimina una restricción histórica sobre las invocaciones entre programas (CPI). Actualmente, cualquier programa invocado mediante CPI debe ser pasado explícitamente por el invocador como una cuenta de instrucción. Esto complica la construcción de transacciones y genera una carga de cómputo considerable, especialmente con CPI profundamente anidadas. Sin embargo, esta restricción es puramente histórica y no es necesaria para el protocolo actual.

SIMD-0163 elimina esta restricción al permitir que las instrucciones CPI hagan referencia a cuentas de programa directamente desde la lista de cuentas de nivel superior de la transacción, en lugar de exigir que esas cuentas se pasen de forma recursiva por cada nivel de invocación. Este cambio ofrece las siguientes ventajas:

• Reduce enormemente el uso de CUs al evitar la serialización y deserialización redundantes de las cuentas de programa (excepto en los programas loader-v3, que almacenan su ejecutable en una cuenta separada), un proceso especialmente costoso por su gran tamaño (binarios de ~10 MB).
• Simplifica la construcción de transacciones al eliminar la necesidad de pasar las cuentas de los programas invocados por las pilas de instrucciones.
• Mejora la capacidad de composición y facilita la creación de arquitecturas de programas modulares y profundamente anidadas.

Compatibilidad con versiones anteriores

Los programas existentes no se verán afectados, a menos que quieran aprovechar este cambio. En ese caso, pueden hacer una de las siguientes cosas:

Los programas que tienen codificado estáticamente el programa invocado y solo lo necesitan como cualquier cuenta de instrucción para cumplir la restricción impuesta por el entorno de ejecución pueden recibir un marcador de posición como NativeLoader1111111111111111111111111111111, para no desplazar los índices de las demás cuentas de instrucción.

Todos los demás programas existentes que llamen dinámicamente a lo que se pase en una cuenta de instrucción específica tendrán que actualizarse y volver a desplegarse para beneficiarse de la eliminación de la restricción.

Esta optimización no compromete la seguridad. La función de "visibilidad diferida" garantiza que los programas no puedan invocar a otros que se hayan agregado, modificado o eliminado dentro de la misma transacción.

Loader-v4

Agave 2.2 incorpora compatibilidad con Loader-v4, un mecanismo de despliegue de programas más ágil y flexible diseñado para reemplazar a Loader-v3. Loader-v4, habilitado mediante SIMD-0167, simplifica la gestión de cuentas de programa, mejora los flujos de actualización e introduce funciones de seguridad fundamentales para programas activos, especialmente los que operan en entornos de alto riesgo, como DeFi.

Funciones clave de Loader-v4:

Modelo de una sola cuenta: Loader-v4 elimina la necesidad de cuentas proxy y búferes separados para los datos del programa. Ahora, una sola cuenta representa cada programa.

Modo de mantenimiento

Ahora los programas pueden ponerse en un "modo de mantenimiento" no ejecutable sin cerrarse ni volver a desplegarse de forma permanente. Esto conserva la dirección original del programa y permite que los desarrolladores pausen la ejecución (por ejemplo, en caso de un exploit) sin renunciar a la dirección.

Cambio de tamaño arbitrario

Loader-v4 permite aumentar o reducir el tamaño de los binarios de los programas después del despliegue, lo que aporta más flexibilidad para asignar recursos y recuperar fondos bloqueados.

Uso opcional de búferes

A diferencia de Loader-v3, que siempre exigía una cuenta de búfer externa para los nuevos despliegues, Loader-v4 hace que los búferes sean opcionales. Ahora los programas pueden volver a desplegarse directamente en la cuenta principal del programa, lo que reduce a la mitad los fondos que deben bloquearse durante la carga.

Despliegues parciales

Loader-v3 exigía volver a cargar los binarios completos del programa con cada actualización. En cambio, Loader-v4 admite cargas parciales y permite que los desarrolladores apliquen parches únicamente a secciones específicas de un programa. Esto resulta especialmente útil para actualizaciones menores.

Migración fluida desde Loader-v3

Los programas desplegados con Loader-v3 pueden migrarse a Loader-v4 sin cambiar su dirección de programa. Esto se facilita mediante una nueva instrucción Migrate en Loader-v3. Esta acción retrasará la visibilidad, por lo que el programa no estará disponible durante el resto del slot actual.

Tras activar Loader-v4, se activará por separado una función para deshabilitar los nuevos despliegues en Loader-v3. Los programas existentes de Loader-v3 seguirán funcionando, pero se espera que todos los despliegues futuros usen Loader-v4.

Al finalizar un programa loader-v4, se puede indicar una dirección de la siguiente versión, posiblemente para formar una lista enlazada. Esto ofrece una alternativa a volver a desplegar programas y permite que las interfaces de usuario presenten una lista de versiones finalizadas entre las cuales elegir.

Los mecanismos para gestionar autoridades y cerrar cuentas no cambian en Loader-v4. Todo esto estará disponible mediante el nuevo subcomando program-v4 de la CLI.

Conclusión

Agave 2.2 representa un hito importante para el protocolo Solana. Ofrece mejoras fundamentales del entorno de ejecución y nuevas capacidades que amplían la frontera técnica de la red. Esta versión incorpora varios cambios clave: un aumento del 20 % en la capacidad de los bloques, la integración de Accounts Lattice Hash (ALH) para calcular hashes de estado de forma escalable, múltiples mejoras para el desarrollo de programas y compatibilidad con la verificación de firmas Secp256r1, esencial para habilitar integraciones criptográficas de uso masivo. En conjunto, estas mejoras aumentan el rendimiento, optimizan la experiencia del desarrollador y refuerzan la capacidad de la red para admitir una gama más amplia de aplicaciones.

Ya sea que desarrolles programas, operes validadores o interactúes con la red, Agave 2.2 ofrece mayor rendimiento, flexibilidad y resiliencia para Solana.

Recursos adicionales

• Repositorio del cliente Agave
• Calendario de lanzamiento de Agave v2.2
• Registro de cambios de Agave v2.2
• Solicitudes de cambios etiquetadas de Agave v2.2