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

Resumen de Agave 2.0

El lanzamiento del cliente validador Agave v2.0 marca un hito importante en el camino de Solana hacia un ecosistema más robusto y con múltiples clientes. Esta actualización incorpora varias mejoras cruciales para impulsar el rendimiento, la confiabilidad y la eficiencia de la red. Los principales cambios incluyen:

• Amplias refactorizaciones y optimizaciones de la base de código
• Recompensas de época particionadas
• Entrega de la comisión de prioridad completa a los validadores
• El nuevo planificador central ahora está activado de forma predeterminada
• El programa ZK ElGamal Proof
• Syscall Get-Sysvar
• Syscall GetEpochStake
• MoveStake y MoveLamports
• Eliminación de métodos RPC obsoletos
• Cambios de nombre de crates

Ya sea que operes un validador, desarrolles en la plataforma o uses Solana activamente, este resumen completo de la actualización Agave 2.0 te dará la información necesaria para entender y aprovechar estas innovaciones recientes.

¿Qué hace que Agave 2.0 sea una actualización de versión principal?

Ya no existe un único «validador de Solana». Agave 2.0 adopta el nuevo mundo multicli­ente de Solana y marca una separación definitiva del antiguo repositorio de GitHub de Solana Labs. El repositorio de Solana Labs se archivará y dejará de aceptar nuevas solicitudes de incorporación de cambios o incidencias. Antes, este repositorio reflejaba la actividad del repositorio de Agave. Si aún no lo han hecho, los desarrolladores deben migrar todas sus actividades al repositorio de GitHub de Anza Agave. El proceso de migración de Solana Labs a Agave comenzó el 1 de marzo y su progreso se registra públicamente en GitHub.

A medida que el ecosistema evoluciona, los operadores deben adaptarse para ejecutar uno o más clientes. Como parte de este cambio, se están renombrando varios crates para liberar el espacio de nombres y admitir múltiples clientes, en especial Firedancer, administrados por equipos de desarrollo independientes. Los crates mantenidos por Anza ahora llevarán el prefijo "agave", lo que permitirá identificarlos fácilmente como dependencias específicas de Anza dentro del entorno multicli­ente.

‍Los crates afectados son: 

• solana-validator
• solana-ledger-tool
• solana-watchtower
• solana-install
• solana-geyser-plugin-interface
• solana-cargo-registry

Como explicamos en nuestra guía de transición anterior, la actualización 2.0 introduce varios cambios incompatibles. El más destacado es la eliminación de varios endpoints obsoletos y descontinuados, cambios clave que todos los desarrolladores de Solana ya deberían conocer. Al final de este artículo se incluyen todos los detalles de los cambios en RPC.

Implementación de funciones

Al momento de escribir este artículo, alrededor del ~20.7% de los validadores ejecuta la versión 2.0.14. Las activaciones mediante puertas de funciones en mainnet están pausadas temporalmente para que la adopción de v2.0 se alinee mejor con las activaciones en testnet y devnet. Una vez que el clúster de mainnet haya adoptado v2.0 de forma generalizada, se espera que las activaciones se reanuden según el orden de activación programado. 

Las nuevas funciones completas que se analizan en las siguientes secciones aún no están activas. Se implementarán gradualmente durante el ciclo de vida de 2.0 mediante un sistema de puertas de funciones. Las funciones se activan en determinadas épocas según su prioridad relativa y el orden en que se activaron en los clústeres de testnet y devnet.

Entrega de la comisión de prioridad completa a los validadores

Esta esperada y muy debatida actualización económica se está implementando tras la propuesta SIMD-0096, que se sometió a una votación de gobernanza de validadores en mayo. La votación terminó al final de la época 620, con la participación del 51.17% del stake y un 77.77% de votos a favor. La actualización, controlada mediante una puerta de funciones, cambiará de forma fundamental la gestión de las comisiones de prioridad en la red. En lugar del modelo actual, que quema el 50% de las comisiones y entrega el otro 50% a los validadores, el nuevo modelo asignará el 100% de las comisiones de prioridad directamente a los validadores.

Aunque las comisiones de prioridad son técnicamente opcionales, se han convertido en una práctica estándar a medida que aumentó la actividad económica en Solana. Estas comisiones se calculan en microlamports (millonésimas de un lamport) por unidad de cómputo mediante la fórmula:

‍comisión de priorización = precio por unidad de cómputo (microlamports) x límite de unidades de cómputo

En adelante, todas las comisiones de prioridad se entregarán a los productores de bloques. Esto alinea mejor los incentivos y reduce la probabilidad de que los validadores participen en acuerdos fuera del protocolo para incluir transacciones, algo que ha causado problemas anteriormente.

Aunque dejar de quemar comisiones aumenta ligeramente la tasa de inflación neta de SOL, la emisión de nuevos tokens mediante recompensas de staking tiene un impacto mucho mayor. Para consultar un desglose más detallado de estas dinámicas, puedes leer nuestra publicación anterior del blog de Helius sobre el calendario de emisión e inflación de Solana.

Recompensas de época particionadas

Las recompensas de época particionadas buscan distribuir las recompensas de stake entre varios bloques. Esto reduce los problemas de rendimiento asociados con concentrar la distribución de recompensas en el primer bloque de cada nueva época. El principal cuello de botella de este proceso es la necesidad de escribir las actualizaciones en la creciente cantidad de cuentas de stake activas de la red, que ahora suman aproximadamente 1.4 millones.

Con este nuevo enfoque, el cálculo y la distribución de las recompensas de stake en el límite de la época se dividirán en dos fases distintas:

• Fase de cálculo de recompensas: En esta fase se calculan las recompensas de época de todas las cuentas de stake activas y la distribución se divide en segmentos programados.
• Fase de distribución de recompensas: Las recompensas de época precalculadas se distribuyen entre las cuentas de stake activas correspondientes.

Para facilitar y supervisar el proceso, una cuenta Sysvar, EpochRewards, rastreará y verificará las recompensas durante toda la fase de distribución. La Sysvar EpochRewards registra si la fase de distribución de recompensas está en curso y la información necesaria para reanudarla al iniciar desde una instantánea. 

Cálculo de recompensas

Las recompensas se calcularán en el primer bloque de la época. Después del cálculo, se dividirán en segmentos de distribución almacenados en el banco, que se repartirán durante la fase de distribución de recompensas.

Para minimizar el impacto en el tiempo de procesamiento de los bloques durante la fase de distribución y garantizar que cada bloque distribuya un subconjunto de recompensas de forma determinista, se distribuirán 4,096 recompensas de stake por bloque como objetivo. Para protegerse frente a un crecimiento drástico de la cantidad de cuentas de stake, el número de bloques se limita al 10% del total de slots de una época. Solo si se alcanza este límite de bloques se permite que las cuentas por partición superen el objetivo de 4,096.

Distribución de recompensas

La distribución de recompensas comienza inmediatamente después de la fase de cálculo, a partir del segundo bloque de la época. Las recompensas se distribuyen al inicio del bloque, antes del procesamiento normal de transacciones.

Como resultado, los usuarios podrían ver las recompensas acreditadas en sus cuentas de stake algunos bloques más tarde que antes. Sin embargo, la experiencia general seguirá siendo similar, ya que el prolongado tiempo del primer bloque en el límite de la época retrasaba anteriormente el acceso de los usuarios a las cuentas de stake. Otro beneficio de este enfoque es que las transacciones no relacionadas con staking pueden continuar procesándose sin interrupciones, mientras que antes quedaban bloqueadas durante la distribución de recompensas.‍

Debido a la cantidad relativamente baja de cuentas de voto, aproximadamente 1,500, el mecanismo actual para distribuir las recompensas de voto en el primer bloque del límite de la época no cambiará. Solo las recompensas de stake se distribuirán entre varios bloques.

El planificador central ahora está activado de forma predeterminada

El planificador central se presentó por primera vez como una función de la actualización v1.18. Antes se conocía como «el planificador», no estaba habilitado de forma predeterminada y los operadores debían activarlo con la marca --block-production-method central-scheduler al iniciar un validador. Ahora está activado de forma predeterminada. La implementación anterior del planificador tenía varios problemas que podían perjudicar el rendimiento. Los cuellos de botella en el procesamiento de transacciones solían generar fluctuaciones o inconsistencias en el orden y la priorización de las transacciones.

La implementación más reciente reemplaza el modelo anterior de cuatro hilos bancarios independientes, cada uno encargado de su propia priorización y procesamiento de transacciones. En esta estructura revisada, el planificador central es el único receptor de las transacciones procedentes de la etapa SigVerify de la TPU. Crea una cola de prioridad y utiliza un gráfico de dependencias, conocido como prio-graph, para gestionar mejor el procesamiento y la priorización de transacciones en conflicto. El diseño del nuevo planificador mejora la escalabilidad y la flexibilidad. Permite aumentar la cantidad de hilos sin las preocupaciones anteriores sobre el incremento de los conflictos de bloqueo. Se ha demostrado que la implementación inicial del planificador central genera mejores recompensas, lo que aumenta los ingresos de muchos operadores. Nuestra publicación anterior de Helius sobre la actualización de Solana v1.18 explicó en detalle cómo funciona el planificador central.

Programa ZK ElGamal Proof

El programa ZK Token Proof, cuya inclusión se planeó originalmente para la versión 1.17, ahora está descontinuado y será reemplazado por un programa ZK ElGamal Proof más versátil e independiente de las aplicaciones. El nuevo programa ZK ElGamal Proof conserva las partes del programa ZK Token Proof que se aplican de forma general a distintas aplicaciones, como la verificación de la validez de una clave pública o del rango de valores cifrados en un texto cifrado ElGamal. Sin embargo, omite elementos específicos de las aplicaciones, como la validación de pruebas de conocimiento cero necesaria para las instrucciones de transferencia de SPL Token. El nuevo programa ZK ElGamal Proof se incorporará a la lista de programas integrados en la dirección ZkE1Gama1Proof11111111111111111111111111111

Para obtener más información sobre el programa ZK Token Proof, lee nuestro artículo original en el blog de Helius.

Syscall Get-Sysvar

Syscalls, o llamadas al sistema, solicitan servicios al kernel del sistema operativo. En el contexto de Solana, una Syscall permite que los programas ejecutados en la Solana Virtual Machine (SVM) interactúen con recursos y servicios externos. 

Sysvars exponen información sobre el estado del clúster, como el hash de bloque reciente y las recompensas de época. Estas cuentas se completan en direcciones conocidas. Los programas pueden acceder a las Sysvars mediante una cuenta Sysvar o consultarlas mediante una Syscall. Los programas on-chain usan muchas Sysvars para una amplia variedad de casos de uso, y algunas son esenciales para el funcionamiento de la red.

La Syscall Get-Sysvar, propuesta inicialmente en SIMD-127 por el ingeniero de Anza Joe Caulfield, introduce una interfaz Syscall unificada para acceder a datos de Sysvar. Esta actualización permite recuperar datos de Sysvar que antes eran inaccesibles, incluidos SlotHashes y StakeHistory. Con esta nueva interfaz, los desarrolladores pueden acceder a fragmentos específicos de datos de Sysvar, por ejemplo mediante llamadas a SlotHashes::get_slot(slot) y StakeHistory::get_entry(epoch), sin tener que duplicar estructuras de datos completas.

La actualización también minimiza la sobrecarga al modificar la disposición de los datos de Sysvar o agregar nuevas Sysvars. Antes, cada nueva Sysvar requería agregar una Syscall correspondiente. Esto creaba una relación estrechamente acoplada que ampliaba la interfaz Syscall con el tiempo y complicaba su mantenimiento. Ahora, una sola Syscall sol_get_Sysvar servirá a todas las interfaces Sysvar, lo que permitirá recuperar datos de cualquier Sysvar de forma uniforme y eficiente.

La nueva Syscall simplifica el proceso de modificar y agregar nuevas Sysvars. Reduce considerablemente la complejidad y los requisitos de mantenimiento de la interfaz Syscall. Además, esta actualización abre el camino para ampliar el acceso de los programas BPF a los datos de Sysvar. Así, los programas on-chain podrán leer más información de Sysvar sin afectar el tamaño de las transacciones.

Syscall GetEpochStake

La nueva Syscall GetEpochStake incorporará una función muy solicitada para recuperar el stake delegado a una cuenta de voto durante la época actual. Proporcionará un método on-chain más eficiente y directo para obtener esta información.

Actualmente, los programas no pueden acceder a datos en tiempo real sobre el stake delegado a cuentas de voto específicas durante la época actual. Esto supone un obstáculo para casos de uso como la gobernanza de validadores y los mecanismos de consenso secundarios. Permitir la consulta on-chain de estos datos habilitará estas aplicaciones y abrirá el camino para futuros casos de uso.

Con GetEpochStake, los desarrolladores proporcionan una dirección de cuenta de voto de 32 bytes y la syscall devuelve un entero u64 que representa el stake activo total delegado actualmente a esa cuenta de voto. Si la dirección proporcionada no corresponde a una cuenta de voto válida o no existe, la Syscall simplemente devuelve 0.

MoveStake y MoveLamports

Se incorporan dos nuevas instrucciones al programa de stake, MoveStake y MoveLamports, para facilitar las transferencias de valor entre cuentas de stake. Estas instrucciones, propuestas inicialmente en SIMD-0148, ayudan a los desarrolladores porque permiten mover fondos entre cuentas con autoridades coincidentes sin el control de la autoridad de retiro.

Anteriormente, los protocolos que gestionaban el stake de los usuarios enfrentaban dificultades al dividirlo entre varios validadores y volver a delegarlo periódicamente. Cuando un protocolo divide el stake de un usuario para desactivarlo, debe financiar los lamports necesarios para la exención de renta de la nueva cuenta. El protocolo no puede recuperar esos lamports al fusionar las cuentas divididas.

MoveStake

MoveStake: Esta instrucción permite mover stake activo entre cuentas. Puede transferirlo de una cuenta activa a otra o de una cuenta activa a una inactiva, lo que reactiva esta última. Si se mueve toda la delegación de la cuenta de origen, esta queda inactiva. El saldo exento de renta no se modifica en ningún caso y se mantienen las reglas de delegación mínima para las cuentas activas.

MoveLamports

MoveLamports: Mueve los lamports excedentes de una cuenta activa o inactiva a otra cuenta activa o inactiva. Los "lamports excedentes" son aquellos que no forman parte del stake delegado ni son necesarios para la exención de renta. MoveLamports permite realizar tareas de mantenimiento, como recuperar lamports de cuentas fusionadas y consolidar fondos no utilizados.

Para simplificar la implementación, estos cambios no permiten activar o desactivar cuentas ni afectan las cuentas de stake parcialmente activas. Estas nuevas instrucciones del programa no modifican las funciones existentes.

Extra: el crate Solana-SVM

El lanzamiento de Agave 2.0 incluye un crate solana-svm completamente nuevo que ofrece a los desarrolladores acceso directo a los componentes principales de SVM mediante una API simplificada e independiente del framework completo del validador. Esto permite aprovechar el procesamiento de transacciones de alto rendimiento de Solana en aplicaciones ajenas al validador, como servicios off-chain, clientes ligeros, canales de estado y rollups.

Al desacoplar la API del resto del entorno de ejecución, este crate elimina la necesidad de componentes como las instancias de Bank, lo que reduce la sobrecarga operativa. Los desarrolladores ahora pueden aprovechar los mismos componentes robustos que respaldan la mainnet-beta de Solana para crear proyectos SVM personalizados, como clientes ligeros, canales de estado, rollups y servicios off-chain. El núcleo de esta API es la estructura TransactionBatchProcessor, que permite a las aplicaciones procesar lotes de transacciones de Solana depuradas con el conjunto completo de componentes posteriores de Agave, incluidos BPF Loader, eBPF y la máquina virtual.

Consulta el análisis detallado de la nueva API de SVM de Anza para conocer todos los detalles de este interesante avance.

Endpoints RPC eliminados 

Se eliminaron varios endpoints RPC obsoletos y descontinuados de Agave v1. El equipo de DevRel de Helius se comunicó con todos los clientes que usan estos endpoints. Mediante un análisis interno, identificamos previamente a un pequeño grupo de clientes que usan activamente los siguientes endpoints, cuya eliminación está prevista:

• getRecentBlockhash
• getConfirmedSignatureForAddresses2
• getConfirmedTransaction
• getConfirmedBlock
• getStakeActivation
• getFees

Nota: El enfoque alternativo para getAccountInfo que aparece en la imagen se puede consultar aquí.

Los cambios incompatibles del SDK incluyen:

• Se eliminó la compatibilidad con Borsh v0.9; usa v1 o v0.10 (#1440)
• Ya no se deriva el trait Copy en Rent y EpochSchedule; cambia a clone()
• solana-sdk: se eliminaron los símbolos descontinuados) 
• solana-program: se eliminaron los símbolos descontinuados

Para los operadores de validadores, varios argumentos descontinuados se eliminarán con el lanzamiento de Agave v2.0. Puedes consultar una lista completa aquí.‍

Conclusión

La actualización Agave 2.0 representa un avance importante para Solana, con numerosas implementaciones de funciones y optimizaciones del entorno de ejecución. Este lanzamiento continúa ampliando los límites con nuevas y potentes Syscalls, funciones extendidas y un mantenimiento integral que incluye cambios de nombre de crates, la eliminación de métodos RPC descontinuados y la simplificación de los argumentos del validador. Agave 2.0 amplía las capacidades de Solana y perfecciona su rendimiento y facilidad de uso. Ya seas desarrollador, validador o usuario activo, la actualización Agave 2.0 abre nuevas y emocionantes posibilidades para todos en el ecosistema de Solana.

Recursos adicionales

• Calendario de lanzamiento de Agave v2.0
• Registro de cambios de Agave v2.0
• Versiones de Agave