Todo lo que necesitas saber sobre la actualización v1.16 de Solana

¿De qué trata este artículo?

La red de validadores de Solana alcanzó con éxito una supermayoría en la adopción de la versión 1.16, la actualización más reciente del cliente validador de Solana Labs. Tras un exhaustivo periodo de auditoría, reforzado por el trabajo dedicado de voluntarios y nodos canary, este hito culmina casi diez meses de desarrollo riguroso.

En las siguientes secciones, analizaremos cómo se probó la v1.16 y el sistema de puertas de funciones de Solana, un marco que controla cómo se incorporan gradualmente nuevas funciones a la red. Después, veremos las nuevas funciones implementadas en la v1.16.

¿Cómo se probó la v1.16?

La v1.16 se sometió a pruebas rigurosas durante los últimos meses. La versión v1.16 se ejecuta en testnet desde el 7 de junio de 2023 y pasó por numerosas pruebas de estrés. Además, un pequeño grupo de nodos voluntarios se actualizó a la v1.16 a partir del 23 de agosto de 2023. Estos voluntarios pudieron identificar y resolver diversos problemas, como inicios lentos en nodos RPC y fallos de protección general. Solana Labs también implementó varios nodos canary en mainnet-beta. El objetivo era monitorear la estabilidad de los nodos v1.16 en condiciones reales. Para ver la actividad anterior y el progreso de estos nodos canary, visita el canal #canaries-monitoring en el Discord de Solana Tech.

Para detectar casos extremos o condiciones de carrera poco frecuentes, se usaron varios fuzzers de runtime para ejecutar transacciones parcialmente aleatorias. Estas transacciones se ejecutaron en distintas versiones del runtime para garantizar un rendimiento uniforme. La v1.16 también fue auditada exhaustivamente por Halborn. Los informes de auditoría se publican en este repositorio conforme están disponibles.

Puertas de funciones

Es importante señalar que algunas de las funciones que analizaremos en las siguientes secciones aún no están activas. En su lugar, las funciones se implementan poco a poco mediante un sistema de puertas de funciones. Se activan en determinadas épocas según su prioridad relativa y el orden en que se activaron en otras redes. Hasta ahora, la programación de activación de estas puertas ha sido ad hoc y se basa en una lista de criterios que puedes consultar aquí. En esencia, estas puertas deben activarse primero en testnet, después en devnet y, por último, en mainnet-beta. Para activar una función, un ingeniero con el par de claves de activación requerido envía una transacción que se procesa y activa la función en la siguiente época. Solo se debe activar una puerta de función a la vez en cada red para garantizar un rendimiento adecuado. Es importante señalar que algunas funciones pueden requerir un periodo de estabilización, lo que podría retrasar la activación de puertas con menor prioridad.

Este sistema de puertas de funciones garantiza que los cambios que rompan el consenso no hagan que un validador con una versión más reciente se bifurque de la cadena canónica y continúe produciendo bloques. Por ejemplo, un validador v1.14 no conoce las nuevas funciones de la v1.16 y podría provocar una caída de la red cuando surjan discrepancias. Un commit incorporado esta semana a la base de código de Solana recomienda que todos los cambios que rompan el consenso tengan un Documento de Mejora de Solana (SIMD). La plantilla de incidencias de puertas de funciones ahora incluirá una solicitud del SIMD correspondiente a la incidencia. Esto ayuda a estandarizar el proceso de desarrollo y aporta mayor transparencia a los nuevos cambios mediante documentación.

Transferencias confidenciales

Confidential Transfers, una función introducida por Token2022, utiliza pruebas de conocimiento cero para cifrar los saldos y los montos de las transacciones de tokens SPL. El objetivo principal de esta función es mejorar la privacidad del usuario mediante un reconocido énfasis en la confidencialidad, en lugar del anonimato.

Confidential Transfers aprovecha el cifrado Twisted ElGamal para realizar operaciones matemáticas con montos cifrados. Estas transferencias se validan mediante protocolos Sigma, una categoría especializada de pruebas de conocimiento cero en la que una parte (el probador) puede demostrarle a otra (el verificador) que conoce un secreto determinado sin revelarlo. Lee nuestro artículo ¿Qué es Token2022? para profundizar en las complejidades de Confidential Transfers.

Una función útil que acompaña el lanzamiento de Confidential Transfers es la incorporación de compatibilidad con la interfaz de línea de comandos (CLI). El comando create-token se amplió para incluir una bandera --enable-confidential-transfers, que permite acuñar tokens con transferencias confidenciales habilitadas. También se agregó el comando update-confidential-transfer-settings para permitir cambios dinámicos en la configuración de transferencias confidenciales de una emisión determinada. Esto permite actualizar la clave del auditor y la configuración de aprobación.

Mejor compatibilidad del runtime con pruebas de conocimiento cero

La versión v1.16 mejora las capacidades de conocimiento cero de Solana mediante una mayor compatibilidad del runtime con cálculos de conocimiento cero, específicamente con operaciones de curvas elípticas de 128 bits. La v1.16 incorpora syscalls alt_bn128, esenciales para generar pruebas de manera eficiente.

alt_bn128 hace referencia a una implementación específica de una curva elíptica usada para operaciones criptográficas y conocida como curva Barreto-Naehrig (BN-128). BN-128 es un tipo específico de curva elíptica compatible con emparejamientos que permite implementar de forma eficiente zk-SNARKs (argumentos de conocimiento sucintos, no interactivos y de conocimiento cero). Como dato adicional, una curva elíptica se considera «compatible con emparejamientos» si permite realizar determinados cálculos con mayor eficiencia. Por lo tanto, en nuestro caso, usar la curva BN-128 agiliza considerablemente el trabajo con matemáticas y pruebas de conocimiento cero.

Una syscall, o llamada al sistema, se usa para solicitar servicios al kernel del sistema operativo. En el contexto de Solana, una syscall permite que los programas que se ejecutan en la Solana Virtual Machine (SVM) interactúen con recursos externos.

Por lo tanto, una syscall alt_bn128 es una llamada que los programas de Solana pueden usar para interactuar con la altamente eficiente curva BN-128. Esto simplifica la verificación de pruebas de conocimiento cero y ofrece mejores funciones de seguridad y privacidad en Solana. También se agregaron recientemente las syscalls alt_bn128 g1 y g2, que permiten comprimir pruebas Groth16. Esto es importante porque este tipo de pruebas ocupa 256 bytes de datos de instrucción por prueba y los programas privados de Solana (PSP) actualmente necesitan verificar dos pruebas Groth16. Con la compresión g1 y g2, los bytes requeridos por prueba se pueden reducir a la mitad, hasta 128 bytes, algo crucial para aprovechar el espacio de forma eficiente.

Además, los contratos basados en Solidity enfrentan problemas de compatibilidad con Solana si contienen llamadas a los siguientes contratos precompilados para realizar operaciones de curvas elípticas:

• bn256Add - Realiza sumas en operaciones de curvas elípticas
• bn256ScalarMult - Realiza multiplicaciones escalares en operaciones de curvas elípticas
• bn256Pairing - Operaciones de emparejamiento de curvas elípticas para verificar zkSNARKs dentro del límite de gas del bloque

Estas operaciones están estandarizadas en Ethereum mediante EIP-196, EIP-197 y EIP-198. La incorporación de las syscalls alt_bn128 representa un gran avance para reducir la brecha de compatibilidad. Ahora, los contratos de Solidity que dependen de estas operaciones de curvas elípticas pueden migrar a Solana o incluso interoperar con ella más fácilmente.

La incorporación de la syscall alt_bn128 en la actualización v1.16 de Solana supone un gran avance en la capacidad de Solana para procesar pruebas de conocimiento cero de forma eficiente y segura. Consulta las siguientes solicitudes de incorporación de cambios si quieres obtener más información sobre las syscalls alt_bn128:

• Se agregaron syscalls alt_bn
• Se agregaron pruebas para la syscall alt_bn128 (y se corrigieron problemas relacionados)
• Función (syscall): agregar compresión altbn128 g1 y g2

Validadores

La actualización v1.16 reduce drásticamente el uso de RAM de los validadores. Antes, Solana dependía de la RAM para indexar las cuentas. Ahora, el sistema se reconfiguró para indexar las cuentas en disco de forma predeterminada, lo que reduce considerablemente el uso de RAM. Yanshu de Luganodes señala que, desde el lanzamiento de la v1.16, su validador funciona sin problemas con solo ~39 GB de RAM, frente a los ~120 GB de versiones anteriores:

La versión v1.16 también incorpora un sistema rediseñado de muestreo de pares para solicitudes pull de gossip. Este nuevo sistema reduce eficazmente el ancho de banda que usan los validadores durante el inicio. En versiones anteriores, los validadores podían enfrentar restricciones de ancho de banda debido al gran volumen de solicitudes pull de gossip. Esto podía ralentizar o incluso saturar el validador. La v1.16 resuelve este problema mediante una variable que registra el tiempo transcurrido desde la última solicitud. Esta variable permite medir los niveles de tráfico entrante y aplicar límites de frecuencia para evitar que el validador se sature durante el inicio.

Los validadores con stake que se retrasan respecto de la red ahora pueden alcanzar el estado actual aún más rápido gracias a la nueva función de solicitudes de reparación proporcionales al stake. Cuando un validador con un stake elevado se bifurca de la red, envía una solicitud de reparación. Ahora este validador recibirá shreds más rápido porque posee un stake elevado. Esto garantiza que el validador deje de estar bifurcado de la red y pueda seguir contribuyendo. Los validadores con stake tienen mayor prioridad que los nodos RPC para las solicitudes de reparación, ya que estos últimos no producen bloques.

El umbral de demora para emitir reparaciones de shreds también aumentó de 100 ms a 200 ms. Este cambio se realizó para reducir la cantidad de solicitudes de reparación de shreds que finalmente se entregarían mediante Turbine. Como dato adicional, Turbine es el mecanismo multicapa de propagación de bloques que Solana usa para transmitir entradas del ledger a todos los nodos. En este mecanismo, el clúster de Solana se divide en capas de nodos, y cada nodo de una capa determinada se encarga de propagar los datos a la siguiente capa. Este ajuste es crucial porque minimiza las solicitudes de reparación innecesarias, lo que mejora la eficiencia de la propagación de datos de Turbine.

Nunca había sido tan fácil operar tu propio validador. Si te interesa operar uno, Solana ofrece Capacitación para validadores de Solana, una serie de talleres para validadores disponible en su canal de YouTube.

Compatibilidad con cuentas redimensionables

Cuando implementas un programa en Solana, el espacio asignado siempre equivale al doble del tamaño del programa. La v1.16 te permite implementar programas con cuentas de datos redimensionables. Esto significa que puedes implementar tu programa con una cuenta más pequeña y ampliar su tamaño después, pagando la diferencia de memoria. La compatibilidad con cuentas redimensionables ofrece mayor flexibilidad y una mejor asignación de recursos a quienes desarrollan aplicaciones en Solana.

Hash de cuentas de época

En versiones anteriores, había problemas relacionados con los bloques y la verificación de todas las cuentas del estado. Si un validador pasaba un periodo prolongado sin interactuar con una cuenta determinada, podía tener una versión dañada de esa cuenta sin siquiera saberlo. Esto se debía a que el estado de la cuenta no se comparaba con el estado almacenado por otros nodos validadores, ya que no se realizaban transacciones que modificaran su estado.

La v1.16 resuelve este problema con la incorporación del hash de cuentas de época. Se trata de un hash de todas las cuentas que se genera al final de cada época, incluso si no se interactuó con ellas. El hash de cuentas de época permite que la red identifique y bifurque los nodos con datos dañados, lo que aumenta la integridad y la seguridad de Solana.

Ajuste del sistema

El ajuste del sistema es el proceso de optimizar el sistema operativo y las configuraciones de hardware de un validador para lograr un rendimiento óptimo. Con el lanzamiento de la v1.16, se eliminó solana-sys-tuner y ahora se recomiendan las pruebas manuales. Se eliminó porque, en versiones anteriores, las columnas TransactionStatus e AddressSignature de RocksDB no se limpiaban correctamente. Además, la compactación periódica, un proceso que recupera espacio de almacenamiento, estaba deshabilitada de forma predeterminada. Esto causaba un crecimiento ilimitado de estas columnas en los nodos que usaban la bandera --enable-rpc-transaction-history. Ahora, los validadores que usan esta bandera administrarán el espacio de almacenamiento con mayor eficiencia gracias al siguiente commit. Esta es una mejora importante que simplifica los requisitos de almacenamiento de los validadores al eliminar la necesidad de guardar estados de transacciones y firmas de direcciones innecesarios.

Conclusión

La versión v1.16 de Solana marca un hito importante que reúne diez meses de desarrollo. Su lento lanzamiento se debe a que se priorizó QUIC, por lo que estos avances en transferencias confidenciales, compatibilidad con conocimiento cero y optimizaciones para validadores llevaban mucho tiempo pendientes. Aun así, estas mejoras son verdaderamente revolucionarias. Esta versión aporta nuevos niveles de eficiencia y privacidad a Solana.

De cara al futuro, Solana Labs adoptará un ciclo de lanzamientos más ágil, con el objetivo de publicar una nueva versión aproximadamente cada tres meses. Estas versiones futuras serán mucho más pequeñas que la v1.16. Esto permitirá iterar con mayor rapidez y reducir el riesgo durante la implementación. Puedes consultar el calendario de lanzamiento de la v1.17 aquí. Promete ser otra versión muy esperada, con una compatibilidad aún mejor con conocimiento cero y la posible incorporación de syscalls Posidon.

Si llegaste hasta aquí, anónimo, ¡gracias! Con un ciclo de lanzamientos más ágil y una gran variedad de nuevas funciones y mejoras, el futuro de Solana se ve mejor que nunca. Ya seas desarrollador, inversionista, validador o entusiasta de Solana, ¡no pierdas de vista los próximos lanzamientos! Tu recorrido por Solana apenas comienza.

Recursos adicionales / Lecturas complementarias

• Calendario de activación de puertas de funciones
• Proceso de activación de puertas de funciones
• Auditorías de seguridad de Solana
• Solana Beach: página de validadores

‍