Resumen de Agave 2.0

El lanzamiento del cliente validador Agave v2.0 marca un hito significativo en el viaje de Solana hacia un ecosistema multi-cliente más robusto. Esta actualización introduce varias mejoras críticas para potenciar el rendimiento, la confiabilidad y la eficiencia de la red. Los cambios clave en esta actualización incluyen:

‍

• Refactorización extensa del código y optimizaciones
• Recompensas de época particionada
• Recompensando la tarifa de prioridad completa a los validadores
• El nuevo programador central ahora está activado por defecto
• El programa de prueba ZK ElGamal
• Get-Sysvar Syscall
• Obtener la llamada del sistema de participación de época
• MoveStake y MoveLamports
• Eliminación de métodos RPC obsoletos
• Cambio de nombres de cajones

‍

Ya sea que ejecute un validador, construya en la plataforma o use activamente Solana, esta descripción general exhaustiva de la actualización Agave 2.0 le proporcionará los conocimientos necesarios para comprender y aprovechar estas últimas innovaciones.

¿Qué hace que la versión 2.0 sea una actualización importante?

Ya no existe un solo 'validador de Solana'. Agave 2.0 abraza el nuevo mundo multi-cliente de Solana y marca una ruptura completa con el antiguoRepositorio de GitHub de Solana Labs. El repositorio de Solana Labs será archivado, y ya no se aceptarán nuevas solicitudes de extracción o problemas. Anteriormente, este repositorio reflejaba la actividad del repositorio de Agave. Los desarrolladores deben migrar todas las actividades alRepositorio de Anza Agave en GitHubsi aún no lo han hecho. ElProceso de migración de Solana Labs a Agavecomenzó el 1 de marzo y se realiza un seguimiento público en su GitHub.

‍

A medida que el ecosistema evoluciona, los operadores deben adaptarse a ejecutar uno o más clientes. Siguiendo este cambio, varias cajas están siendo renombradas, liberando el espacio de nombres para admitir múltiples clientes, especialmente Firedancer, administrados por equipos de desarrolladores independientes. Las cajas mantenidas por Anza ahora se prefijarán con "agave", lo que las hace fácilmente identificables como dependencias específicas de Anza dentro del entorno multi-cliente.

‍

‍

Las cajas afectadas son:

‍

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

‍

Como se detalla en nuestro Guía de transición anterior, la actualización 2.0 introduce varios cambios importantes, especialmente la eliminación de varios puntos finales obsoletos y en desuso: actualizaciones clave de las que todos los desarrolladores de Solana deberían estar al tanto en este momento. Los detalles completos de los cambios en RPC se incluyen al final de este artículo.

Implementación de características

En el momento de escribir, ~20.7% de validadores están ejecutando la versión 2.0.14. Las activaciones de gate de características en mainnet se han pausado temporalmente para permitir que la adopción de la v2.0 se alinee más estrechamente con las activaciones en testnet y devnet. Una vez que el clúster mainnet haya adoptado ampliamente la v2.0, se espera que las activaciones de gate de características se reanuden de acuerdo con elorden de activación programada.

‍

Las nuevas características completas discutidas en las siguientes secciones actualmente no están activas y se implementarán gradualmente durante el ciclo de vida 2.0 utilizando un sistema de puerta de funciones. Las características se activan en ciertas épocas según la prioridad relativa y el orden en que se activaron en los clústeres de la red de prueba y desarrollo.

‍

Recompensa de Tarifa de Prioridad Completa a los Validadores

Este altamente anticipado yactualización económica muy debatidase está implementando ahora siguiendo la propuesta,SIMD-0096, que pasó por una votación de gobernanza de validadores en mayo. La votación concluyó al final de la época 620, con la participación del 51,17% de la participación y el 77,77% votando a favor. La actualización con control de funciones cambiará fundamentalmente el manejo de la red.tarifas prioritarias. En lugar del modelo actual, que divide las tarifas con un 50% quemado y un 50% recompensado a los validadores, el nuevo modelo asignará el 100% de las tarifas prioritarias directamente a los validadores.

Arriba: Tarifas de prioridad semanales de Solana en valor USD (fuente)

‍

Si bien las tarifas de prioridad son técnicamente opcionales, se han convertido en una práctica estándar a medida que la actividad económica en Solana ha aumentado. Estas tarifas se calculan en micro-lamports (millonésimas de un lamport) por unidad de cálculo utilizando la fórmula:

‍

tarifa de priorización = precio de la unidad de cómputo (micro-lamports) x límite de la unidad de cómputo

‍

En el futuro, todas las tarifas prioritarias se otorgarán a los productores de bloques. Esto crea una alineación más fuerte de incentivos y reduce la probabilidad de que los validadores participen en acuerdos fuera del protocolo para la inclusión de transacciones, lo cual ha sido un problema en el pasado.

‍

Aunque eliminar las quemas de tarifas aumenta ligeramente la tasa de inflación neta de SOL, la emisión de nuevos tokens a través de recompensas por participación tiene un impacto mucho más significativo. Los lectores pueden consultar nuestra publicación anterior en el blog de Helius sobrePrograma de emisión e inflación de Solanapara obtener un desglose más detallado de estas dinámicas.

‍

Recompensas del período dividido

Recompensas de época particionadasapuntar a distribuirrecompensas de participación a través de múltiples bloques, aliviando los problemas de rendimiento relacionados con la concentración de la distribución de recompensas dentro del primer bloque de cada nueva época. El principal cuello de botella en este proceso es el requisito de escribir actualizaciones al creciente número de cuentas de participación activas en la red, que ahora suman aproximadamente 1,4 millones. \

Bajo este nuevo enfoque, el cálculo y la distribución de las recompensas de participación en el límite del ciclo se dividirán en dos fases distintas:

‍

• Fase de cálculo de recompensas: En esta fase, se calculan las recompensas de época para todas las cuentas de participación activas y la distribución se divide en partes programadas.
• Fase de distribución de recompensas: las recompensas de época precalculadas para las cuentas de participación activa se distribuyen en consecuencia.

‍

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

Cálculo de recompensas

Los cálculos de recompensa se realizarán en el primer bloque de la época. Una vez calculadas, las recompensas se dividen en segmentos de distribución almacenados en el banco, los cuales se distribuirán durante la fase de distribución de recompensas.

‍

Para minimizar el impacto en el tiempo de procesamiento de bloques durante la fase de distribución de recompensas y garantizar que cada bloque distribuye un subconjunto de las recompensas de manera determinista, se distribuirá un objetivo de 4.096 recompensas de participación por bloque. Para protegerse contra un crecimiento dramático en el número de cuentas de participación, el número de bloques está limitado al 10% de las ranuras totales en una época. Solo si se alcanza este límite de bloque, 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 de recompensas, a partir del segundo bloque de la época. Las distribuciones de recompensas ocurren en la parte superior del bloque antes del procesamiento normal de transacciones.

‍

Como resultado, los usuarios pueden ver que las recompensas se acreditan a sus cuentas de participación unos bloques más tarde que antes. Sin embargo, la experiencia general sigue siendo similar, ya que el tiempo prolongado del primer bloque en el límite de la época retrasaba previamente el acceso del usuario a las cuentas de participación. Un beneficio adicional de este enfoque es que las transacciones que no son de participación pueden seguir procesándose sin problemas, mientras que anteriormente quedaban bloqueadas durante la distribución de recompensas.

‍

Debido al número comparativamente bajo de cuentas de voto, aproximadamente 1,500, el mecanismo existente para distribuir las recompensas de voto en el primer bloque del límite de época permanecerá sin cambios. Solo las recompensas por participación se distribuirán en varios bloques.

‍

Central Scheduler está activado de forma predeterminada

Introducido por primera vez como una versión de características en la actualización v1.18, el programador central, anteriormente conocido como "el programador", no estaba habilitado de forma predeterminada y los operadores tenían que habilitarlo mediante el indicador —block-production-method central-scheduler al iniciar un validador. Ahora está activado de forma predeterminada. La implementación anterior del programador tenía varios problemas que podían afectar negativamente al rendimiento. Los cuellos de botella en el procesamiento de transacciones a menudo conducen a 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 gestionando su propia priorización y procesamiento de transacciones. En esta estructura revisada, el programador central es el único receptor de transacciones de la etapa SigVerify de la TPU. Construye una cola de prioridades e implementa un gráfico de dependencias, conocido como un prio-grafo, para gestionar mejor el procesamiento y la priorización de transacciones conflictivas. Este nuevo diseño de programador aumenta la escalabilidad y flexibilidad, permitiendo un aumento en el número de hilos sin las preocupaciones anteriores de conflictos de bloqueo aumentados. El lanzamiento inicial del programador central ha demostrado generar mejores recompensas, lo que resulta en ganancias mejoradas para muchos operadores. Nuestra publicación anterior de Helius sobre la actualización Solana v1.18 cubrió extensamentecómo funciona el programador central.

‍

Programa de prueba de ZK ElGamal

El programa ZK Token Proof, originalmente planeado para su inclusión en la versión 1.17, ahora está obsoleto y será reemplazado por uno más versátil e independiente de la aplicaciónPrograma de prueba de ZK ElGamal. El nuevo programa de Prueba ZK ElGamal conserva las partes del programa de Prueba de Token ZK que se aplican ampliamente en diferentes aplicaciones, como verificar la validez de una clave pública o el rango de valores encriptados dentro de un criptotexto ElGamal. Sin embargo, omite elementos específicos de la aplicación, como la validación de la prueba de conocimiento cero requerida para las instrucciones de transferencia de Token SPL. El nuevo programa de Prueba ZK ElGamal se incorporará a la lista de programas integrados en la dirección ZkE1Gama1Proof11111111111111111111111111111.

‍

Para obtener más información sobre el Programa de Prueba de Token ZK, lea nuestropublicación original en el blog de Helius.

Obtener llamada al sistema Sysvar

Las llamadas al sistema, o syscalls, solicitan servicios del núcleo del sistema operativo. En el contexto de Solana, una syscall permite que los programas que se ejecutan dentro de la Máquina Virtual Solana (SVM) interactúen con recursos y servicios externos.

‍

Los Sysvars exponen información del estado del clúster, como el hash del bloque reciente y las recompensas del epoch. Estas cuentas están pobladas en direcciones conocidas. Los programas pueden acceder a los Sysvars a través de una cuenta de Sysvar o consultarlos a través de una Syscall. Los programas en la cadena utilizan muchos Sysvars para una amplia gama de casos de uso, y ciertos Sysvars son esenciales para el funcionamiento de la red.

‍

La llamada al sistema Get-Sysvar, propuesta inicialmente enSIMD-127 por el ingeniero de Anza Joe Caulfield, introduce una interfaz unificada de llamadas al sistema para acceder a datos de Sysvar. Esta actualización permite la recuperación de datos de Sysvar previamente inaccesibles, incluidos SlotHashes y StakeHistory. Con esta nueva interfaz, los desarrolladores pueden acceder a fragmentos específicos de datos de Sysvar, como llamar SlotHashes::get_slot(slot)yStakeHistory::get_entry(epoch)—sin necesidad de duplicar estructuras de datos completas.

‍

La actualización también minimiza el exceso de carga al modificar las disposiciones de datos de Sysvar o agregar nuevos Sysvars. Anteriormente, cada nuevo Sysvar requería la adición de una correspondiente Syscall, creando una relación estrechamente acoplada que inflaba la interfaz de Syscall con el tiempo y complicaba el mantenimiento. Ahora, una sola llamada a sol_get_Sysvar Syscall servirá todas las interfaces de Sysvar, permitiendo la recuperación de datos consistente y eficiente desde cualquier Sysvar.

‍

La introducción de la nueva llamada al sistema simplifica el proceso de modificación y adición de nuevas variables del sistema. Reduce significativamente la complejidad y los requisitos de mantenimiento de la interfaz Syscall. Además, esta actualización allana el camino para ampliar el acceso del programa BPF a los datos de Sysvar, lo que permite que los programas en cadena lean más información de Sysvar sin afectar el tamaño de la transacción.

‍

GetEpochStake Syscall

El nuevoObtener la llamada de Syscall de GetEpochStakepresentará una característica muy solicitada para recuperar la participación delegada de una cuenta de votación para la época actual, proporcionando un método más eficiente y directo para recuperar esta información en la cadena de bloques.

‍

Actualmente, los programas no pueden acceder a datos en tiempo real sobre la participación delegada a cuentas de voto específicas para la época actual, lo que crea una barrera para casos de uso como la gobernanza de validadores y mecanismos de consenso secundarios. Habilitar la consulta en cadena de estos datos desbloqueará estas aplicaciones y allanará el camino para futuros casos de uso.

‍

Con GetEpochStake, los desarrolladores proporcionan una dirección de cuenta de voto de 32 bytes, y la llamada del sistema devolverá un entero u64 que representa la participación activa total delegada actualmente a esa cuenta de voto. Si la dirección proporcionada no corresponde a una cuenta de voto válida o no existe, la llamada del sistema simplemente devolverá 0.

‍

MoveStake y MoveLamports

Dos nuevas instrucciones del programa de participación, MoveStake y MoveLamports, se están introduciendo para facilitar las transferencias de valor entre cuentas de participación. Estas instrucciones, propuestas por primera vez en SIMD-0148, ayudar a los desarrolladores al permitir el movimiento de fondos entre cuentas con autoridades coincidentes sin el control de la autoridad de retiro.

‍

Anteriormente, los protocolos que gestionan los staking de los usuarios han enfrentado desafíos al dividir los staking entre varios validadores y al reasignarlos regularmente entre ellos. Cuando un protocolo divide el staking de un usuario para desactivarlo, debe financiar los lamports de exención de alquiler para la nueva cuenta. El protocolo no puede recuperar los lamports de exención de alquiler al fusionar estas cuentas divididas.

MoveStake: Esta instrucción permite mover la participación activa entre cuentas, transfiriéndola de una cuenta activa a otra o de una cuenta activa a una inactiva, reactivando así la cuenta. Si se mueve toda la delegación de la cuenta de origen, la cuenta de origen se vuelve inactiva. El saldo exento de alquiler permanece intacto en todos los escenarios y las reglas de delegación mínima se mantienen para las cuentas activas.

‍

MoveLamports: Mover los lamports excedentes de una cuenta activa o inactiva a otra cuenta activa o inactiva, donde "lamports excedentes" se refiere a los lamports que no son ni participación delegada ni necesarios para la exención de alquiler. MoveLamports permite tareas de mantenimiento como recuperar lamports de cuentas fusionadas y consolidar fondos no utilizados.

‍

Para agilizar la implementación, estos cambios no admiten la activación o desactivación de cuentas ni afectan a las cuentas de participación parcialmente activas. Estas nuevas instrucciones del programa no alteran la funcionalidad existente.

‍

Bonificación: La caja Solana-SVM

Con el lanzamiento de Agave 2.0 llega unnuevo crate solana-svmofreciendo a los desarrolladores acceso directo a los componentes principales de SVM a través de una API simplificada independiente del marco de validación completo. Esto abre el procesamiento de transacciones de alto rendimiento de Solana para aplicaciones más allá del validador, como servicios fuera de cadena, clientes ligeros, canales de estado y rollups.

‍

Al separar la API del resto del tiempo de ejecución, este paquete elimina la necesidad de componentes como instancias de Bank, reduciendo la sobrecarga operativa. Los desarrolladores ahora pueden aprovechar los mismos componentes robustos que admiten la red principal-beta de Solana para construir proyectos personalizados de SVM, como clientes ligeros, canales de estado, rollups y servicios fuera de la cadena. El núcleo de esta API es la estructura TransactionBatchProcessor, que permite a las aplicaciones procesar lotes de transacciones de Solana sanitizadas con el conjunto completo de componentes de Agave aguas abajo, incluido el cargador BPF, eBPF y la máquina virtual.

‍

Arriba: el procesador de lotes de transacciones (fuente de la imagen: Anza)

‍

Lea la inmersión profunda enNueva SVM API de Anzapara obtener detalles completos sobre este emocionante desarrollo.

‍

Endpoints de RPC eliminados

Se han eliminado varios puntos finales de RPC Agave v1 obsoletos y desaprobados. El equipo de desarrollo de Helius ha contactado a todos los clientes que utilizan estos puntos finales. A través del análisis interno, previamente hemos identificado un pequeño grupo de clientes que utilizan activamente los siguientes puntos finales, que están programados para ser eliminados:

‍

getRecentBlockhash, getConfirmedSignatureForAddresses2, getConfirmedTransaction, getConfirmedBlock, getStakeActivation, getFees

‍

Una vez más, recomendamos encarecidamente a todos los desarrolladores que comprueben las referencias a estas llamadas y las actualicen adecuadamente con los reemplazos sugeridos.

‍

Arriba: una lista completa de puntos finales de RPC v1 de Agave obsoletos y despreciados que se eliminarán

‍

N.B. El enfoque alternativo para obtener información de cuenta que se muestra en la imagen puede ser se encuentra aquí.

‍

Los cambios disruptivos del SDK incluyen:

‍

• Se eliminó el soporte para Borsh v0.9, por favor use v1 o v0.10 (#1440)
• La copia de rasgo ya no se deriva en Rent y EpochSchedule; Cambiar al uso de clone()
• solana-sdk: símbolos obsoletos) eliminado
• solana-programa: símbolos obsoletos eliminados

‍

Para los operadores de validadores, varios argumentos de validador obsoletos serán eliminados con el lanzamiento de Agave v2.0. Se puede encontrar una lista completa de estos. aquí.

‍

Conclusión

La actualización Agave 2.0 marca un avance significativo para Solana, incorporando numerosas implementaciones de funciones y optimizaciones de tiempo de ejecución. Esta versión continúa empujando los límites con nuevos Syscalls potentes, funcionalidad extendida y mantenimiento integral, incluyendo cambios de nombre de las cajas, eliminación de métodos RPC obsoletos y argumentos de validador simplificados. Agave 2.0 amplía las capacidades de Solana y perfecciona su rendimiento y usabilidad. Ya sea que seas un desarrollador, validador o usuario activo, la actualización Agave 2.0 abre emocionantes nuevas posibilidades para todos en el ecosistema de Solana.

‍

Recursos adicionales / Lecturas adicionales

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

Descargo de responsabilidad：

1. Este artículo es una reimpresión de [helius)]. Todos los derechos de autor pertenecen al autor original [Lostin]. Si hay objeciones a esta reimpresión, por favor contactar al Gate Learnequipo, y ellos lo manejarán rápidamente.
2. Aviso de responsabilidad: Las opiniones expresadas en este artículo son únicamente las del autor y no constituyen ningún consejo de inversión.
3. Las traducciones del artículo a otros idiomas son realizadas por el equipo de gate Learn. A menos que se mencione, está prohibido copiar, distribuir o plagiar los artículos traducidos.