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

Introducción

Con Agave 4.3, Solana se prepara para lo que posiblemente sea la mayor actualización de protocolo hasta la fecha. El ciclo de lanzamiento de la versión 4.3 introducirá Alpenglow, el esperado nuevo mecanismo de consenso de Solana, y culminará con "Alpenswitch": la transición coordinada de la mainnet para dejar atrás TowerBFT.

Desde su lanzamiento, la arquitectura de consenso de Solana se ha basado en Proof of History y TowerBFT. Los validadores votan mediante el envío de transacciones que se procesan e incluyen en bloques junto con las transacciones normales de los usuarios. La finalidad se acumula a medida que esos votos se reúnen durante 32 slots, lo que da a Solana un tiempo de finalidad aproximado de 12,8 segundos, suponiendo slots de 400 milisegundos.

Proof of History (PoH) fue una de las innovaciones arquitectónicas que definieron a Solana desde su lanzamiento, gracias a su enfoque único para ordenar eventos y coordinar el tiempo. Su eventual retirada marca el fin de una era y muestra cuánto ha evolucionado el protocolo desde las tecnologías que originalmente lo distinguieron.

Alpenglow reemplaza 'PoH + TowerBFT' con Votor, un protocolo en el que los validadores intercambian votos fuera del flujo principal de transacciones. Agrega estos votos en certificados criptográficos. El diseño busca alcanzar la finalidad en ~150 milisegundos.

Para los usuarios y las aplicaciones que envían transacciones y leen el estado de las cuentas, hay poco o nada que migrar. Las transacciones y los mecanismos de comisiones no cambian. Los validadores y la infraestructura que consumen bloques, votos, streams o datos de compromiso experimentarán los mayores ajustes.

Las transacciones de voto desaparecen de los bloques, confirmed y finalized convergen en la práctica, y la infraestructura de streaming obtiene nueva información para distinguir bancos competidores dentro del mismo slot.

En este artículo veremos cómo funciona Alpenglow, incluidos los cambios que Votor introduce en la producción de bloques y la finalidad. También abordaremos otros cambios importantes que llegarán durante el ciclo de lanzamiento de Agave 4.3.

Implementación gradual: primero Votor, luego Rotor

Alpenglow se diseñó en torno a dos componentes principales: Votor, que reemplaza el mecanismo de votación y finalidad de Solana, y Rotor, que rediseña cómo se propagan los bloques por la red. Estos dos mecanismos se implementarán por etapas, empezando por Votor.

Agave 4.3 introduce Votor y conserva el protocolo actual de propagación de bloques, Turbine. Rotor quedó excluido explícitamente de SIMD-0326, la propuesta que regula la activación inicial de Alpenglow. Necesitará su propio SIMD antes de poder implementarse. La primera etapa cambia cómo los validadores alcanzan el consenso, pero todavía no modifica cómo se desplazan los datos de bloques por la red.

Votor

Votor reemplaza las transacciones de voto y el sistema de bloqueos de TowerBFT con un protocolo más directo entre validadores. Con TowerBFT, los validadores votan enviando transacciones que se incluyen en bloques y, con el tiempo, acumulan suficiente profundidad de bloqueo para que un bloque alcance la finalidad. Con Votor, los validadores intercambian directamente mensajes de voto firmados, y el protocolo agrega esas firmas en certificados compactos.

En lugar de esperar a que los votos se acumulen durante 32 slots, Votor puede finalizar un bloque después de una o dos rondas de votación. El protocolo busca una finalidad de ~150 milisegundos, frente a los ~12,8 segundos de TowerBFT.

Votor tiene dos rutas hacia la finalidad que operan de forma simultánea.

Si al menos el 80 % del stake certifica un bloque en la primera ronda, esos votos pueden agregarse en un Fast-Finalization Certificate y el bloque alcanza la finalidad de inmediato. Esta es la ruta rápida del protocolo y solo requiere una ronda de votación.

Si no se alcanza el umbral del 80 %, un bloque aún puede avanzar si más del 60 % del stake votó para certificarlo. Esto produce un Notarization Certificate que permite una segunda ronda de votación. Cuando más del 60 % del stake emite votos de finalización mediante la ruta de dos rondas, se forma un Finalization Certificate y el bloque alcanza la finalidad.

Por lo tanto, el protocolo completo tiene cinco tipos de voto: Notarization, Notarization Fallback, Skip, Skip Fallback y Final. Distintas combinaciones de estos votos producen certificados de certificación, respaldo, omisión o finalización. Estos certificados actúan como pruebas criptográficas compactas de que suficiente stake acordó el resultado de un slot.

Votor está diseñado para seguir avanzando con apenas un 60 % de stake honesto y receptivo. Esto permite que hasta un 20 % del stake actúe de forma adversaria mientras otro 20 % está desconectado o no responde. La compensación es deliberada: Alpenglow renuncia al umbral bizantino tradicional de un tercio de los diseños BFT a cambio de un modelo de resiliencia 20+20 con mayor tolerancia a validadores inactivos o no disponibles.

Votor también elimina el uso de Proof of History como reloj de consenso. En su lugar, los validadores usan temporizadores locales. Si un validador espera el tiempo suficiente sin recibir un bloque aceptable, puede emitir un voto de omisión y permitir que el consenso avance. Esto simplifica la relación entre el control del tiempo y el consenso frente a TowerBFT.

Rotor

Rotor no forma parte de Agave 4.3 y actualmente no hay una fecha de activación publicada. Por lo tanto, Turbine seguirá transportando los datos de bloques cuando se active Votor. Rotor, junto con el mecanismo de muestreo inteligente utilizado para seleccionar sus retransmisores, pasará más adelante por una propuesta y una implementación independientes.

Es importante señalar que esto no significa que Solana deba esperar a Rotor para lograr una finalidad inferior a un segundo. La implementación actual de Alpenglow busca una finalidad de ~150 ms con Votor en Agave 4.3, mientras Turbine sigue en funcionamiento. Rotor busca mejorar aún más la difusión de bloques y aumentar la eficiencia de la arquitectura general de Alpenglow, pero no es un requisito previo para el nuevo modelo de finalidad de Votor.

Se terminan las transacciones de voto

Una de las consecuencias más visibles de Alpenglow será la desaparición de las transacciones de voto de los bloques de Solana. Los validadores pagan comisiones de transacción por estos votos, y la red consume ancho de banda, capacidad de cómputo y espacio en el ledger para procesarlos y almacenarlos.

Históricamente, las transacciones de voto han representado cerca de tres cuartas partes de todas las transacciones registradas en cadena, aunque esta proporción ha disminuido con el aumento de la capacidad de los bloques. Si bien las transacciones de voto son económicas (5.000 lamports) y solo representan una pequeña fracción (~5 %) del cómputo total, aumentan el conteo bruto de transacciones y el tamaño del ledger de la red.

Con Alpenglow, los validadores intercambian directamente entre sí mensajes de voto firmados con BLS. El ConsensusPool de Agave registra los votos observados y agrega suficiente stake en los certificados que Votor utiliza para avanzar o finalizar el consenso.

Esto no significa que la evidencia de participación de los validadores desaparezca del ledger. Los bloques de Alpenglow incorporan un nuevo pie de bloque con información de consenso. En la implementación actual de Agave, BlockFooterV1 puede incluir el certificado de finalización más reciente, así como notar_reward_cert y skip_reward_cert. Los certificados de recompensas incluyen una firma BLS agregada y un mapa de bits que identifica a los validadores que votaron.

Los sistemas que actualmente determinan si un validador votó mediante la indexación de transacciones de Vote Program deberán usar en su lugar los certificados y los datos relacionados con votos de Alpenglow. Los flujos de transacciones existentes que solo filtran transacciones de voto podrán seguir funcionando en general; después de Alpenswitch, el filtro simplemente no tendrá nada que eliminar.

El cambio también crea una discontinuidad en las conocidas estadísticas de TPS de Solana. Cuando se active Alpenglow, las mediciones brutas de TPS que incluyen transacciones de voto caerán con fuerza, aunque la actividad de los usuarios permanezca sin cambios. Por lo tanto, los TPS sin votos son la métrica relevante para comparar la actividad antes y después de Alpenswitch. Eliminar las transacciones de voto acaba con una fuente histórica de confusión sobre el rendimiento real de Solana y facilitará las comparaciones con redes similares.

Eliminar las transacciones de voto devuelve cierta capacidad a los usuarios, pero no debe exagerarse el efecto, ya que los votos representan una parte relativamente pequeña de la carga de cómputo de la red.

Niveles de compromiso

Alpenglow también elimina una de las distinciones históricas de Solana: la diferencia entre el compromiso confirmed y finalized.

Actualmente, las aplicaciones eligen entre tres niveles de compromiso. processed ofrece la vista más reciente, pero no proporciona garantías para todo el clúster. confirmed significa que una supermayoría del stake votó por el bloque, lo que suele ocurrir en uno o dos slots. finalized proporciona finalidad determinista, pero con TowerBFT exige que el bloque alcance el bloqueo máximo de votos, lo que crea una diferencia aproximada de 32 slots entre la confirmación y la finalización. En general, se recomienda confirmed para solicitudes RPC sensibles a la latencia e finalized cuando se necesita una garantía más sólida.

En la práctica, confirmed ha demostrado ser extremadamente confiable: ningún bloque de Solana confirmado de forma optimista dejó de alcanzar la finalidad posteriormente. Sin embargo, la garantía del protocolo sigue siendo más débil. Un bloque confirmado aún no tiene finalidad determinista, y aplicaciones como puentes, exchanges y sistemas de liquidación que no toleran ese riesgo residual históricamente tuvieron que esperar a finalized.

Alpenglow elimina esta disyuntiva. Cuando Votor produce un certificado de finalización rápida o de finalización, el bloque alcanza la finalidad. Cuando Votor selecciona un banco finalizado como raíz, el validador actualiza al mismo tiempo su slot confirmado más alto, su raíz y su raíz de supermayoría más alta.

Para los desarrolladores, esto significa que confirmed y finalized apuntan en la práctica al mismo estado de consenso después de Alpenswitch. Las aplicaciones existentes no necesitan cambiar su configuración de compromiso el día de la activación, ya que la interfaz RPC sigue aceptando processed, confirmed y finalized, pero desaparece la diferencia de latencia entre los dos últimos.

La distinción entre las dos rutas de finalización de Votor es invisible para los consumidores RPC comunes. Tanto si un bloque alcanza el umbral del 80 % para la finalización rápida en una ronda como si finaliza mediante la ruta de dos rondas con un umbral del 60 %, el resultado visible externamente es el mismo.

Múltiples bloques candidatos

Otro cambio importante de Alpenglow afecta a los proveedores RPC, indexadores y demás infraestructura que consume datos de validadores. Un slot ya no puede tratarse como identificador único de un bloque.

Un slot de Solana es una ventana en la que un líder puede producir un bloque. Por su parte, un bank es la representación local del validador del estado generado al ejecutar un bloque candidato específico. Estos conceptos siempre han sido distintos y los bancos competidores no son nuevos, pero gran parte de la infraestructura de producción siempre trató los slots y los bloques como sinónimos.

Alpenglow hace que esa suposición sea cada vez menos segura.

Agave 4.3 amplía Geyser (la interfaz del validador utilizada para transmitir actualizaciones de cuentas, transacciones, entradas y bloques) con un nuevo identificador: bank_id. Los nuevos callbacks compatibles con bancos, incluidos update_account_for_bank, notify_transaction_for_bank, notify_entry_for_bank y notify_block_metadata_for_bank, asocian un evento con el banco específico que lo produjo. De manera similar, las notificaciones de estado delimitadas por banco incluyen un bank_id. Los callbacks anteriores se mantienen por compatibilidad en la versión 4.3, pero están obsoletos y se eliminarán en la próxima versión principal de Agave.

El punto importante es que bank_id identifica una instancia local de banco, no un bloque acordado globalmente. Agave crea los ID de banco a partir de un contador atómico local mantenido por el runtime del validador, por lo que no debe esperarse que dos validadores que reproducen el mismo bloque le asignen el mismo bank_id. Por lo tanto, la infraestructura debe usar (slot, bank_id) para separar streams competidores provenientes de un solo validador, pero debe usar el ID de bloque o blockhash al conciliar datos entre distintos validadores o conexiones.

Las etapas futuras de Alpenglow harán que tener varios bancos para un mismo slot sea una parte normal del funcionamiento de los validadores.

El ejemplo más claro es la transferencia rápida de liderazgo, uno de los componentes de Alpenglow que se implementará después de la activación inicial de Votor. Un líder puede comenzar a construir de forma optimista sobre el padre que espera que acepte el consenso. Si Votor decide que debe omitirse ese padre, el líder puede cambiarlo y reconstruir durante el resto de su ventana de liderazgo. Internamente, esto implica reemplazar un banco por otro para el mismo slot. Agave ya incluye el mecanismo UpdateParent necesario para representar este cambio. La transferencia rápida de liderazgo no forma parte de la activación inicial de Alpenglow en Agave 4.3 y se espera que se implemente durante la versión 4.4.

La equivocación del líder puede producir el mismo resultado general. Si un líder firma y distribuye dos bloques distintos para el mismo slot, es posible que los validadores deban conservar temporalmente ambos candidatos y analizarlos. Distintas partes de la red pueden ver esos candidatos en órdenes diferentes porque Votor es asíncrono y los validadores actúan sobre bloques, votos, certificados y temporizadores locales a medida que llegan.

Un cambio reciente redujo MAX_ALTERNATE_BLOCKS_PER_SLOT de 11 a 6. Por lo tanto, un validador necesita conservar como máximo siete bloques candidatos para un slot. Al final, el consenso reduce esos candidatos a un único historial. Con Votor, la certificación requiere más del 60 % del stake. Dos bloques en conflicto no pueden obtener certificados de certificación válidos sin que una cantidad considerable de stake vote por ambos. Bajo la suposición de Alpenglow de que menos del 20 % del stake actúa de forma bizantina, los certificados de certificación en conflicto son imposibles sin infringir las condiciones de seguridad del protocolo.

Para los consumidores de Geyser, la lección práctica es clara: deja de identificar el estado transitorio solo por slot. Los cambios de cuentas, las transacciones, las entradas y los metadatos de bloques deben rastrearse por (slot, bank_id) hasta que el consenso identifique el banco que prevalecerá. Si aparece otro banco para el mismo slot, sus eventos pertenecen a un estado candidato distinto y no deben sobrescribir silenciosamente los del primero.

Tickets de admisión de validadores

Actualmente, las transacciones de voto son el mayor costo de operar un validador de Solana. Con TowerBFT, los validadores pagan una comisión de transacción estándar cada vez que envían un voto, lo que suma cerca de 2 SOL por época. Alpenglow reemplaza las comisiones de transacción con una comisión que se cobra una vez por época a los validadores admitidos en el conjunto de consenso activo, conocida como ticket de admisión de validadores (VAT).

Las bases para esta transición ya están activas. El registro de claves públicas BLS, especificado en SIMD-0387, se activó en la mainnet en julio, seguido poco después por la función de VAT, SIMD-0357. Votor usa firmas BLS para poder agregar las firmas de muchos validadores en un único certificado compacto. Cada validador debe registrar una clave pública BLS en su cuenta de voto antes de poder participar en Alpenglow. Desde que se activó VAT, los validadores que no tienen una ya están excluidos del conjunto de votación.

Antes de Alpenglow, los validadores seguirán enviando transacciones de voto normales y pagando las comisiones asociadas. En esta etapa, VAT funciona principalmente como filtro de admisión. Los validadores elegibles deben tener una clave BLS y estar entre los 2.000 validadores aptos con mayor stake. VAT comienza cuando se habilita Alpenglow y desaparecen las transacciones de voto.

Cuando Alpenglow esté activo, la admisión se recalculará cerca de los límites de cada época. La cuenta de voto de un validador debe contener una clave BLS registrada y suficiente SOL para cubrir el ticket y la exención de renta. Si califican más de 2.000 cuentas, el sistema las clasifica por stake y admite a los validadores con mayor stake. Luego, el sistema descuenta el ticket directamente de la cuenta de voto de cada validador admitido y lo envía a la cuenta incineradora de Solana. Por lo tanto, los validadores deben mantener fondos en su cuenta de voto; con el sistema anterior, las comisiones de las transacciones de voto se descontaban de la cuenta de identidad del validador.

Las propuestas originales de Alpenglow y VAT especificaban un ticket de 1,6 SOL por época, cerca del 80 % de los aproximadamente 2 SOL que un validador gastaba antes en transacciones de voto. Esa cifra asumía el objetivo histórico de Solana de slots de 400 milisegundos. En cambio, SIMD-0525 ajusta VAT según la duración del slot. Los costos de admisión con slots de 200 milisegundos serán de 0,8 SOL.

VAT también cambia el destino de este costo. Actualmente, la comisión base de 5.000 lamports que paga una transacción de voto se divide en dos: el 50 % se quema y el 50 % va al líder del bloque. En cambio, VAT se envía por completo a la cuenta incineradora. Sin embargo, el propósito general de VAT no es hacer que SOL sea considerablemente más deflacionario. Busca conservar un costo económico para unirse al conjunto de consenso después de que desaparezcan las comisiones de las transacciones de voto.

Seguridad y preparación

Reemplazar el protocolo de consenso de una red activa es una operación de riesgo excepcionalmente alto. Por eso, Alpenglow tiene un proceso de pruebas y migración mucho más amplio que una activación habitual de una función de Agave, incluido un clúster de pruebas dedicado a la comunidad y un programa de recompensas por errores.

Desde mayo, los operadores de validadores ejecutan un Alpenglow Community Cluster dedicado, que ha crecido hasta superar los 100 nodos. Los operadores usan hardware y configuraciones de red reales para validadores, lo que permite probar Alpenglow con dispersión geográfica, variaciones de latencia, diferentes configuraciones de software, reinicios y errores operativos difíciles de reproducir en entornos controlados.

Uno de sus objetivos más importantes ha sido probar el propio Alpenswitch. En lugar de limitarse a comprobar si Votor funciona cuando un clúster ya ejecuta Alpenglow, los operadores han ensayado repetidamente la transición de TowerBFT al nuevo sistema de consenso.

Roger Wattenhofer

@TheWattenhofer

We just had the first successful Alpenswitch on our Alpenglow community cluster! The @solana finalization time improved 100x. Thanks to everybody participating. Watch it live: https://ag.validblocks.com/ https://ag-community-status.stakingfacilities.com/

9 may 2026, 6:59 p.m.

Alpenglow también pasó por una revisión adversaria específica. En agosto, Anza abrió una competencia de recompensas por errores de Alpenglow de dos semanas, con una bolsa de premios de hasta 50.000 SOL. A diferencia del programa permanente de Agave, la competencia se enfocó específicamente en el nuevo stack de consenso, incluidos Votor, la verificación de firmas y certificados BLS, la admisión de validadores y la ruta de migración de TowerBFT a Alpenglow. La participación fue considerable. Anza informó que recibió más de 300 propuestas y que distribuiría más de 25.000 SOL en recompensas.

La compatibilidad con Frankendancer terminará con la llegada de Alpenglow. Frankendancer siempre se concibió como un cliente de transición que combinaba los componentes de red y producción de bloques de Firedancer con componentes de Agave para la ejecución y el consenso. Admitir el nuevo sistema de consenso en esa arquitectura híbrida añadiría otra carga considerable de mantenimiento y seguridad, por lo que el equipo de Firedancer está centrando el desarrollo en el cliente Firedancer completo.

La recomendación compartida con los validadores indica que ni Frankendancer ni Firedancer completo serán compatibles con la breve ventana de migración de TowerBFT a Alpenglow. Por lo tanto, los operadores de Firedancer deben prepararse para transferir la operación a un validador Agave antes de Alpenswitch, permanecer en Agave durante la transición y volver a Firedancer cuando el clúster opere con normalidad bajo Alpenglow.

Cómo ocurre realmente Alpenswitch

Alpenglow no se activa en todas partes a una hora arbitraria. Cuando se activa su función, el protocolo define un límite de migración 5.000 slots después. TowerBFT sigue operando mientras los validadores superan este límite y buscan un bloque confirmado con suficiente solidez. Luego, los validadores firman con BLS el bloque génesis de Alpenglow seleccionado y distribuyen esos votos de génesis directamente entre sí.

La transición ocurre cuando al menos el 82 % del stake firma el mismo bloque génesis, lo que produce el certificado génesis de Alpenglow. Los validadores que reciben y verifican ese certificado desactivan TowerBFT después del bloque génesis e inicializan Votor desde el estado acordado. Luego, el certificado se propaga por el conjunto de validadores y hace que los nodos restantes crucen el límite.

Este certificado ofrece a los operadores de infraestructura una forma conveniente de determinar en qué lado de Alpenswitch se encuentra un clúster.

Agave 4.3 introduce un nuevo método RPC getAgGenesisCert. Antes de la migración, un nodo Agave 4.3 devuelve null. Después de que el clúster realiza el cambio, devuelve el certificado génesis de Alpenglow, incluido el bloque génesis y la firma BLS agregada. En cambio, un nodo antiguo que no admite el método devuelve Method not found. La CLI muestra la misma información mediante: solana alpenglow-genesis-info.

Por lo tanto, para los validadores, proveedores RPC y demás infraestructura que necesita reaccionar a la migración, es preferible comprobar la existencia del certificado génesis en lugar de asumir que Alpenglow se activó en una marca de tiempo específica.

Nuevas syscalls criptográficas

Agave 4.3 también amplía las herramientas criptográficas de la SVM con nuevas primitivas del runtime para operaciones cuyo costo hace que sea inviable ejecutarlas directamente en sBPF.

Las dos incorporaciones destacadas son el hashing SHA-512 y la exponenciación modular de enteros grandes. Ambas son aditivas y están controladas por funciones: los programas existentes no se ven afectados, mientras que los programas que decidan usarlas pueden delegar operaciones criptográficas costosas a implementaciones nativas optimizadas dentro del runtime del validador.

Exponenciación modular de enteros grandes

SIMD-0529: syscall ModExp para enteros grandes introduce sol_big_mod_exp, una syscall para calcular:

result = (base ^ exponent) mod modulus

La exponenciación modular es una operación fundamental para la verificación de firmas RSA, los acumuladores criptográficos, algunas funciones de demora verificable y otros protocolos basados en teoría de números. Implementarla con aritmética de enteros de precisión arbitraria directamente dentro de un programa SVM exige una enorme cantidad de cómputo, en especial con tamaños comunes de claves RSA, como 2048, 3072 y 4096 bits.

La nueva syscall traslada la aritmética costosa al runtime del validador. Los programas proporcionan la base, el exponente y el módulo como enteros sin signo little-endian, y reciben el resultado en la memoria proporcionada por el invocador. Al principio, cada operando tiene un límite de 512 bytes, suficiente para admitir enteros de hasta 4096 bits.

El caso de uso más evidente es la verificación RSA. Por ejemplo, un programa que verifica una firma RSA convencional puede invocar sol_big_mod_exp con el exponente público común 65537, en lugar de implementar por sí mismo la exponenciación de enteros grandes. La syscall se limita deliberadamente a la primitiva aritmética: los programas siguen siendo responsables del hashing, el padding RSA como PKCS#1 v1.5 o PSS, la validación de claves y cualquier separación de dominios específica del protocolo.

También puede realizar de manera eficiente la reducción modular de enteros grandes. Al pasar un exponente de 1, la operación se reduce a:

base mod modulus

Esto proporciona a los programas una primitiva nativa para reducir enteros mayores que los tamaños de palabra integrados de la SVM sin pagar el costo de una implementación genérica de enteros grandes.

El diseño es conceptualmente similar a la precompilación ModExp de Ethereum introducida por EIP-198, y su modelo de medición de cómputo sigue la fórmula de complejidad operativa de EIP-198. Sin embargo, no es compatible byte por byte con Ethereum. Solana expone la funcionalidad mediante una ABI de syscall nativa, usa entradas little-endian y exige que el módulo sea un entero impar mayor que uno; los módulos pares se rechazan.

Esto hace que la syscall resulte especialmente útil para la interoperabilidad sin obligar a Solana a adoptar la interfaz de precompilación de la EVM. Los programas que verifican pruebas, firmas o certificaciones basadas en supuestos criptográficos al estilo de Ethereum pueden reutilizar la misma aritmética subyacente y adaptar la forma de invocarla.

SHA-512

La segunda incorporación es mucho más sencilla, pero resulta útil de inmediato.

SIMD-0512: syscall Sha512 añade sol_sha512, lo que permite a los programas en cadena acceder directamente a la función hash SHA-512 mediante el runtime del validador. Su interfaz replica las syscalls sol_sha256, sol_keccak256 e sol_blake3 existentes de Solana, y devuelve el digest SHA-512 estándar de 64 bytes.

SHA-512 es una de las primitivas principales utilizadas por Ed25519, el esquema de firma que la propia Solana usa ampliamente. Tanto Agave como Firedancer ya dependen internamente de SHA-512, pero hasta este cambio los programas SVM no podían acceder directamente a esa implementación optimizada. Los programas que necesitaban SHA-512 tenían que implementar el algoritmo en software.

La diferencia en términos de cómputo es considerable. El SIMD estima que aplicar hashing a una entrada corta con una implementación sBPF cuesta miles de CU, mientras que realizar la misma operación mediante la syscall cuesta menos de 100 CU. sol_sha512 utiliza el mismo modelo general de costos de cómputo que la syscall SHA-256 existente de Solana.

En conjunto, las dos syscalls continúan una tendencia más amplia de la SVM: trasladar primitivas criptográficas comunes pero costosas desde programas individuales hacia operaciones estandarizadas y medidas en el runtime. Los programas siguen definiendo el protocolo criptográfico de nivel superior, pero el validador puede ejecutar los componentes costosos con mucha más eficiencia que una implementación sBPF.

Conclusión

El principal cambio de Agave 4.3 es Alpenglow, que reemplaza TowerBFT con Votor, elimina las transacciones de voto de los bloques, reduce la finalidad de segundos a milisegundos y transforma la forma en que los validadores y la infraestructura interactúan con el consenso.

Para la mayoría de los usuarios y desarrolladores de aplicaciones, gran parte de esta transición ocurrirá de manera invisible. Sin embargo, para los validadores, proveedores RPC, indexadores y equipos de infraestructura, Agave 4.3 marca el inicio de un cambio importante en la forma en que Solana alcanza el consenso.

Recursos adicionales

• Documento técnico de Alpenglow v1.2 (julio de 2026)
• Calendario de lanzamiento de Agave 4.3
• Calendario del seguimiento de activación de funciones
• Registro de cambios de Agave 4.3
• Pull requests de Agave 4.3
• Actualización de Alpenglow - Solana Foundation