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

¿De qué trata este artículo?

La red de Solana alcanzó un hito importante con la adopción por supermayoría de la versión 1.17, la más reciente del cliente validador de Solana Labs. Tras la reciente interrupción de la red, los validadores se reiniciaron con la versión 1.17.20. Al momento de escribir este artículo, el ~68.6 % de los validadores ejecuta la versión 1.17.21 y el ~31.3 % ejecuta la versión 1.17.20.  Esta nueva versión incluye un conjunto de mejoras diseñadas para reforzar la eficiencia, la escalabilidad y los casos de uso de la red. Desde avances pioneros en pruebas de conocimiento cero hasta mejoras en el protocolo Gossip, la v1.17 marca un paso decisivo en el desarrollo continuo de Solana.

Este artículo incluye todo lo que necesitas saber sobre la actualización a la versión 1.17 del cliente validador de Solana Labs. Analizaremos el rigor de las pruebas de la v1.17, la reciente interrupción de la red y las nuevas funciones implementadas con esta actualización.

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

La v1.17 se ejecuta en testnet desde el 3 de octubre de 2023. Se ha sometido periódicamente a pruebas de estrés con grandes cargas de transacciones. Solana Labs también implementó algunos nodos canary de mainnet-beta con la v1.17 para monitorear la estabilidad de la versión en condiciones reales. Se han mantenido estables durante los últimos meses. Puedes consultar la actividad y el progreso anteriores de estos nodos canary en el canal #canaries-monitoring del Discord de Solana Tech. Además, a partir del 4 de diciembre de 2023, un pequeño subconjunto de nodos voluntarios de mainnet-beta se actualizó a la v1.17. 

Se desarrollaron varios fuzzers de runtime para ejecutar transacciones parcialmente aleatorias y detectar casos extremos o condiciones de carrera poco frecuentes. Estas transacciones se ejecutaron en varias versiones para garantizar un rendimiento uniforme. Auditores externos han auditado la v1.17 varias veces. Los informes se publicarán en el repositorio de auditorías de seguridad de Solana en GitHub a medida que estén disponibles.

Interrupción de febrero

El 6 de febrero de 2024, a las 9:53 UTC, mainnet-beta sufrió una interrupción que detuvo temporalmente la finalización de bloques. Esto afectó la actividad de la red durante aproximadamente cinco horas, hasta que el consenso se reanudó a las 14:55 UTC. La interrupción se debió a un error relacionado con la forma en que la red compilaba y almacenaba en caché el código de un programa para ejecutarlo. Afectó específicamente a versiones antiguas de los cargadores de programas.

La causa raíz se originó en la forma en que los validadores gestionaban el resultado compilado mediante compilación justo a tiempo (JIT) de los programas utilizados con frecuencia. Un nuevo sistema de caché destinado a optimizar este proceso introdujo accidentalmente el error crítico. Este nuevo sistema podía entrar en un ciclo infinito de recompilación con determinados programas heredados. Esto paralizó el mecanismo de consenso de Solana, ya que la mayoría de los validadores encontró el problema y no pudo seguir procesando transacciones.

La causa raíz se identificó rápidamente, ya que el error compartía varias similitudes con la reciente interrupción de devnet. Se modificó la versión 1.17.20 para solucionar el problema directamente y los validadores coordinaron el reinicio de la red. La corrección tuvo dos partes: una solución a corto plazo que impidió activar el ciclo infinito al dejar obsoletos los dos cargadores heredados capaces de provocarlo, y un ajuste más completo del nuevo sistema de caché de programas para evitar problemas similares en el futuro. 

El informe oficial, publicado originalmente por Anza, está disponible aquí.

ZK Token Proof Program

El lanzamiento de ZK Token Proof Program estaba previsto para la actualización 1.16. Sin embargo, su activación se retrasó debido a una auditoría exhaustiva. El calendario de activación de Feature Gates muestra el programa como Pendiente de activación en testnet con una versión mínima de 1.17.12. 

Transferencias confidenciales

Con la activación de ZK Token Proof Program, las transferencias confidenciales estarán disponibles por fin. Las transferencias confidenciales utilizan pruebas de conocimiento cero para cifrar los saldos y montos de transferencia de los tokens SPL. El objetivo general es la confidencialidad, no el anonimato. El cifrado homomórfico permite realizar cálculos sobre datos cifrados sin descifrarlos. Por ejemplo, los saldos pueden sumarse o restarse sin descifrar y volver a cifrar los montos especificados en estas operaciones. Así, estos cálculos se cifran del mismo modo que si se aplicaran sobre texto sin cifrar.

Las transferencias confidenciales utilizan el cifrado Twisted ElGamal y protocolos Sigma para realizar transacciones seguras y privadas sin revelar información sensible. 

Como información adicional:

• El cifrado Twisted ElGamal es una variante sencilla del esquema de cifrado ElGamal estándar en la que el texto cifrado se divide en un compromiso de Pedersen del mensaje cifrado y un identificador de descifrado que permite realizar operaciones matemáticas ocultas sobre el texto cifrado
• Los protocolos Sigma se utilizan para validar las transferencias confidenciales. Son una clase especial de pruebas de conocimiento cero en la que una parte (es decir, el probador) puede demostrarle a otra (es decir, el verificador) que conoce cierta información sin revelarla

Las transferencias confidenciales solo permiten que la cuenta que posee la clave de descifrado vea su saldo cifrado. Global Auditor System se implementa para situaciones que requieren una revisión de terceros, como verificaciones de cumplimiento o auditorías. Este sistema permite a los titulares de cuentas conceder acceso de lectura selectivo a cuentas específicas mediante claves de descifrado independientes. También incorpora una «clave de cifrado del auditor» para los mints con el fin de facilitar auditorías seguras.

Las transacciones utilizan parámetros cifrados para los montos del remitente, el destinatario y el auditor, junto con pruebas que garantizan la privacidad y la integridad. Los saldos de las cuentas se dividen en «Pendiente» y «Disponible» para evitar ataques de front-running. De lo contrario, un usuario malicioso podría enviar tokens a una cuenta para invalidar las pruebas generadas con el saldo cifrado.

Es importante señalar que las transferencias confidenciales requieren un nuevo par de claves. 

Compatibilidad con la línea de comandos

También está disponible la compatibilidad de la interfaz de línea de comandos (CLI) con las transferencias confidenciales mediante el crate spl-token. Una vez activado, el comando create-token se amplió para incluir el indicador –enable-confidential-transfers auto. Esto permite a los usuarios acuñar tokens con la extensión de transferencias confidenciales activada. También hay otros comandos útiles, como:

• configure-confidential-transfer-account: configura una cuenta preexistente para transferencias confidenciales. Solo el propietario puede configurar transferencias confidenciales para la cuenta
• deposit-confidential-tokens: deposita tokens de una cuenta no confidencial en una cuenta confidencial. Ten en cuenta que los tokens depositados dejarán de existir en el saldo no confidencial de la cuenta, ya que se habrán transferido por completo al saldo confidencial
• apply-pending-balance: mueve un saldo de «Pendiente» a «Disponible». Esto es necesario porque, cuando una cuenta recibe tokens confidenciales de una transferencia o un depósito, el saldo aparece como «Pendiente». Por lo tanto, los usuarios no tienen acceso inmediato a los fondos y deben aplicar el saldo pendiente
• transfer (con el indicador –confidential activado): transfiere tokens a otra cuenta configurada para transferencias confidenciales. Ten en cuenta que esta operación puede tardar más que una transferencia normal de tokens porque requiere varias transacciones dependientes
• withdraw-confidential-tokens: retira tokens del saldo confidencial de una cuenta y los pasa a su saldo no confidencial. Asegúrate de haber aplicado cualquier saldo pendiente antes de ejecutar este comando para retirar todos los tokens esperados
• update-confidential-transfer-settings: actualiza la configuración de transferencias confidenciales de un mint de tokens determinado. Permite establecer automáticamente políticas para aprobar transferencias confidenciales (es decir, el indicador –aprove-policy) y configurar la clave pública de un auditor (es decir, el indicador –auditor-pubkey). También incluye indicadores adicionales para especificar un blockhash, la autoridad de transferencia confidencial, archivos de configuración, datos del pagador de comisiones, la URL de JSON RPC, datos de la cuenta nonce, el formato de salida y el ID del programa de tokens

Compatibilidad 

Ten en cuenta que las siguientes combinaciones de extensiones no funcionan o no tiene sentido combinarlas con las transferencias confidenciales:

• Transferencia confidencial + No transferible
• Transferencia confidencial + comisiones (no funcionará hasta la versión 1.18)
• Transferencia confidencial + Transfer Hooks (esto se debe a que estas transferencias solo pueden ver las cuentas de origen o destino y, por tanto, no pueden actuar sobre el monto transferido)

Auditorías

Las transferencias confidenciales y, en general, Token-2022 Program se han sometido a auditorías exhaustivas de empresas como Halborn, Zellic, Trail of Bits, NCC Group y OtterSec (dos veces: la primera auditoría se centró en Token-2022, mientras que la segunda auditoría se enfocó específicamente en las transferencias confidenciales).

Syscalls de Poseidon

Poseidon es una familia de funciones hash optimizada para pruebas de conocimiento cero. La mayoría de los proyectos blockchain basados en ZK utilizan funciones hash de Poseidon, incluidos Zcash, Mina y Light Protocol de Solana. Actualmente, calcular hashes de Poseidon en Solana es demasiado costoso para hacerlo en una sola transacción. Las syscalls de Poseidon cambiarán esta situación. Su lanzamiento está previsto actualmente para la v1.17.5, pendiente de activación en testnet.

Explicación sencilla

Imagina que utilizas una calculadora avanzada que resuelve con eficiencia determinados tipos de acertijos usados en comunicaciones seguras. Esta calculadora toma fragmentos de información, los divide y los mezcla de una forma única. La información se mezcla para ocultar por completo el contenido original sin dejar de ser verificable.

Este proceso de mezcla utiliza un método especial que suma números y los eleva a determinados exponentes que forman parte de un conjunto específico de números definido con antelación. Este método garantiza que la mezcla se realice de forma exhaustiva y uniforme cada vez.

Poseidon hace exactamente lo mismo que esta calculadora avanzada. Estos tipos de funciones hash son muy eficaces para crear circuitos de conocimiento cero. Los circuitos son, en esencia, un conjunto de operaciones matemáticas. Representan matemáticamente cómo una parte (el probador) demuestra a otra (el verificador) que conoce cierta información sin revelarla. En términos generales, es como demostrar que sabes qué hay dentro de una caja sellada sin abrirla. Puedes demostrárselo a quien selló la caja mediante una serie de golpes o pasos. Estos golpes o pasos están diseñados para no revelar ningún detalle sobre el contenido de la caja ni sobre cómo abrirla. Solo pueden entenderse si has abierto la caja.

Esto resulta útil para las blockchains, ya que es muy importante mantener la privacidad de las transacciones y, al mismo tiempo, poder verificar su autenticidad. 

Características optimizadas para ZK

Las funciones hash de Poseidon se consideran optimizadas para el conocimiento cero por varias razones. En concreto:

• Poseidon está diseñado para ejecutar con eficiencia las operaciones aritméticas habituales en los cálculos de pruebas de conocimiento cero (es decir, suma, multiplicación y exponenciación)
• Los sistemas de pruebas de conocimiento cero requieren convertir la lógica computacional en una prueba criptográfica. El diseño de Poseidon produce circuitos menos complejos que otras funciones hash gracias a su compatibilidad con operaciones aritméticas, su S-box optimizada, sus parámetros personalizables y su bajo número de rondas (es decir, una secuencia de operaciones aplicada de forma iterativa a los datos de entrada o al estado interno de la función hash). Esto significa que se necesitan menos pasos para generar una prueba de un conjunto de datos determinado
• Las funciones hash de Poseidon se basan en una construcción de esponja. Es decir, Poseidon utiliza una clase de algoritmos que reciben una secuencia de bits de cualquier longitud y producen una salida de cualquier longitud. Esto facilita enormemente la integración de las funciones hash de Poseidon en distintas aplicaciones de conocimiento cero.

Comparación con las funciones hash tradicionales

La eficiencia computacional de Poseidon, diseñada para pruebas de conocimiento cero, ofrece una ventaja clara frente a las operaciones más generales y computacionalmente intensivas de las funciones hash tradicionales, como SHA-256. 

Aunque son seguras y confiables, las funciones hash tradicionales suelen generar circuitos más grandes y complejos dentro de las pruebas de conocimiento cero. Esto se debe a que estas funciones hash no se diseñaron originalmente teniendo en cuenta las restricciones específicas de los sistemas de pruebas de conocimiento cero. En las blockchains, las pruebas de conocimiento cero realizan sus cálculos dentro de campos finitos. Un campo finito es un conjunto de números en el que todas las operaciones aritméticas (suma, resta, multiplicación y división) se realizan módulo un número primo. Esto hace que los valores «vuelvan al inicio» dentro del conjunto y garantiza que cada operación permanezca en ese conjunto de números. 

Las funciones hash tradicionales, como SHA-256, dependen en gran medida de operaciones bit a bit y de secuencias predeterminadas de operaciones. Estas funciones no son compatibles directamente con las operaciones aritméticas utilizadas en campos finitos. Implementarlas en el contexto de un campo finito requeriría pasos adicionales, lo que aumentaría la complejidad del circuito.

Además, las funciones hash tradicionales suelen usar aritmética modular basada en potencias de 2. Esto difiere de la aritmética modular de los campos finitos utilizados en las pruebas de conocimiento cero, que suelen basarse en números primos. Esta incompatibilidad exigiría aún más pasos y aumentaría el tamaño y la complejidad del circuito.

El objetivo de construir una prueba de conocimiento cero es crear una representación matemática de la lógica computacional que demuestre el conocimiento de cierta información sin revelarla. Representar este conocimiento de forma sencilla y eficiente es fundamental para la escalabilidad de estas pruebas. Las funciones hash de la familia Poseidon responden directamente a estas necesidades mediante operaciones eficientes en campos finitos, lo que reduce de manera considerable los pasos necesarios para crear el circuito. El resultado es un circuito más pequeño y menos complejo. Las funciones hash tradicionales no están adaptadas a las necesidades de crear circuitos directamente, sino que están diseñadas para usos generales. 

La integración de las syscalls de Poseidon en la v1.17 representa un cambio hacia el uso de herramientas criptográficas especializadas para agilizar la generación y validación de pruebas de conocimiento cero en Solana. Esto permite procesar transacciones más rápido, reducir costos y mejorar la escalabilidad de los cálculos de conocimiento cero. Gracias también a la flexibilidad y capacidad de personalización de Poseidon, generar y validar pruebas de conocimiento cero en Solana ahora es mucho más sencillo.

Implementación específica

La v1.17 introduce la syscall sol_poseidon, una llamada al sistema que recibe un slice bidimensional de bytes y calcula como salida el hash de Poseidon correspondiente. Utiliza la curva BN254 y recibe los siguientes parámetros de Poseidon:

• S-boxes x^5 (es decir, cajas de sustitución)
• Entradas donde 1 ≤ n ≤ 12
• Ancho donde 2 ≤ t ≤ 13
• 8 rondas completas y rondas parciales según t: [56, 57, 56, 60, 60, 63, 64, 63, 60, 66, 60, 65]

Estos hashes de Poseidon se calcularán con el crate light-posiedon, que está auditado y es compatible con Circom. 

Ten en cuenta que en la siguiente sección analizamos la incorporación de syscalls alt_bn128. A BN254 se le llama coloquialmente BN128 (por los bits de seguridad), alt_bn128 o alt_bn_128. Aquí nos referimos a la misma curva.

Syscalls alt_bn128

La v1.16 propuso mejorar la compatibilidad del runtime con cálculos de conocimiento cero, específicamente con operaciones de curvas elípticas de 128 bits. Las syscalls alt_bn128, fundamentales para generar pruebas con eficiencia, debían lanzarse con la v1.16. Sin embargo, se retrasaron. El calendario de activación de Feature Gates prevé actualmente las syscalls alt_bn128 para la v1.17.15, pendientes de activación en mainnet-beta, y la compresión alt_bn128 para la v1.17.15, pendiente de activación en testnet.

Como información adicional para quienes tengan más interés, alt_bn128 se refiere a la implementación de la curva elíptica Barreto-Naehrig (BN-128). Es una curva elíptica específica compatible con emparejamientos que permite usar zk-SNARKs (argumentos de conocimiento sucintos, no interactivos y de conocimiento cero) de manera eficiente. Se considera «compatible con emparejamientos» porque permite realizar determinados cálculos y pruebas de conocimiento cero con mayor eficiencia. En Solana, las syscalls alt_bn128 permiten que los programas aprovechen esta curva para agilizar la verificación de pruebas de conocimiento cero y mejorar la seguridad y la privacidad. Añadir las syscalls g1 y g2 de alt_bn128 ayuda a facilitar la compresión de pruebas Groth16. Esto reduce de forma considerable el espacio necesario por prueba y optimiza el uso del espacio para los programas de Solana.

La incorporación de syscalls alt_bn128 ayuda a reducir la brecha de compatibilidad entre Solana y los contratos basados en Solidity que dependen de contratos precompilados para las operaciones con curvas elípticas especificadas en EIP-196, EIP-197 y EIP-198. Estas operaciones (bn256Add, bn256ScalarMult, bn256Pairing) permiten verificar zk-SNARKs dentro de los límites de gas de Ethereum. Ahora, los contratos de Solidity que dependen de estas operaciones con curvas elípticas pueden migrar a Solana o interoperar con ella con mayor facilidad.

Mejoras de Gossip

La v1.17 mejora la eficiencia de la propagación de mensajes de Gossip al optimizar la propagación de mensajes push y reducir la dependencia de las solicitudes pull. Agilizar las operaciones del protocolo Gossip ayuda a reducir el uso de recursos de los validadores de consenso.

Como contexto, el servicio Gossip de Solana es esencial para intercambiar información entre validadores. Esto incluye datos como alturas del ledger, información de contacto y votos de consenso. Utiliza mensajes «push» y «pull» para compartir y verificar información en toda la red. Este sistema de mensajería garantiza que todos los nodos se mantengan sincronizados. 

Tradicionalmente, AccountsHashVerifier envía los hashes de sus cuentas a Gossip. Sin embargo, ningún componente de la red obtiene estos datos, por lo que el proceso es redundante. Las operaciones históricas, como comparar los hashes de cuentas de Gossip con los valores de validadores conocidos, se eliminaron con la introducción de EpochAccountsHash.  El método RPC getHealth también se reescribió para que dejara de depender de los hashes de cuentas de Gossip. Lo analizaremos en la siguiente sección. Por tanto, desde la v1.17, nada obtiene los hashes de cuentas de Gossip. AccountsHashVerifier se modificó para dejar de enviar cuentas a Gossip y también se eliminaron las funciones responsables de enviar y obtener hashes de cuentas mediante Gossip.

getHealth 

Antes, la llamada RPC getHealth podía mostrar un estado incorrecto para un nodo determinado. Esto se debía a una discrepancia entre el comando CLI solana catchup y la llamada RPC getHealth, por la que un nodo podía aparecer al mismo tiempo como sincronizado y retrasado. Como resultado, algunos nodos en buen estado podían marcarse incorrectamente como defectuosos y eliminarse de los pools RPC.

Originalmente, el estado se determinaba comparando un slot local de hash de cuentas publicado en Gossip con los de otros nodos, mediante un valor de comparación predeterminado de 100 slots. Esto podía ser impreciso, sobre todo en nodos configurados con valores superiores a 100 slots. getHealth se reescribió para utilizar el último slot confirmado de forma optimista por el clúster (es decir, el último slot que todos los validadores han procesado y que una supermayoría ha confirmado, pero que aún no está finalizado). Esto permite una comparación más precisa, ya que el slot confirmado por el clúster puede compararse con el último banco confirmado de forma optimista para determinar cuánto se ha retrasado el nodo. El cambio ofrece una comprobación más granular, reduce la probabilidad de falsos negativos (es decir, nodos en buen estado marcados como defectuosos) y evita los efectos dominó causados por problemas que afecten a validadores conocidos. 

También se añadió el indicador –skip-health-check a los comandos wait-for-restart-window e exit para solucionar los problemas con getHealth. Esto permite a los validadores omitir la comprobación del estado de un nodo.

QUIC

La v1.17 introduce la capacidad de difundir shreds y realizar reparaciones mediante QUIC. Los endpoints QUIC de Turbine y reparación están desactivados actualmente porque no serán necesarios hasta que testnet haya migrado por completo a QUIC. Sin embargo, esto establece las bases para migrar estos protocolos a QUIC. Se fusionaron varios PR para introducir esta funcionalidad subyacente, entre ellos:

• Añadir desalojo diferido para reparar conexiones QUIC y evitar que el número de conexiones pendientes crezca sin límites
• Añadir métricas para monitorear el endpoint QUIC de Turbine
• Añadir métricas para monitorear la reparación del endpoint QUIC
• Evitar que las conexiones QUIC expiren debido a solicitudes de reparación poco frecuentes

Conexiones TPU asíncronas

La v1.17 introduce conexiones asíncronas del cliente TPU, lo que mejora considerablemente el mecanismo de caché de conexiones. Esta actualización está diseñada para reducir la latencia de las transacciones al permitir establecer conexiones en segundo plano con un tamaño predeterminado de cuatro conexiones en el pool. Las conexiones asíncronas del cliente TPU permiten procesar transacciones con mayor fluidez, sin los tiempos de espera asociados a las conexiones síncronas. 

Inicio simplificado de validadores y actualización del formato de snapshots

La v1.17 simplifica el proceso de inicio de los validadores al introducir un nuevo indicador y actualizar los formatos de archivo de snapshots compatibles. Esto permite iniciar los validadores más rápido, lo cual es importante porque reduce el tiempo de inactividad y contribuye a la resiliencia de la red.

La v1.17 introduce un nuevo indicador –use-snapshot-archives-at-startup. Este permite que los validadores agilicen el proceso de inicio al elegir entre snapshots locales, el estado local almacenado en disco o la opción automática que selecciona el más reciente de los dos. El indicador elimina la necesidad de procesar snapshots cuando el estado del disco es más reciente, lo que permite reinicios más rápidos.

Antes, Solana admitía varios formatos de compresión para los snapshots. Los formatos de archivo incluían bz2, gzip, zstd, lz4, tar y ninguno. Sin embargo, la última actualización limita las opciones a zstd e lz4 para mejorar la eficiencia y reducir la complejidad de mantenimiento. Los demás formatos quedaron obsoletos para el argumento –snapshot-archive-format, aunque los validadores aún pueden leer snapshots existentes en esos formatos para garantizar la compatibilidad con versiones anteriores. Esto simplifica por naturaleza la interfaz de línea de comandos de solana-validator e solana-ledger-tool. 

Conclusión

Gracias a las numerosas funciones implementadas y a la rápida resolución de la reciente interrupción de la red, la actualización v1.17 de Solana supone un gran avance. La actualización inaugura capacidades y compatibilidad sin precedentes con el conocimiento cero mediante el lanzamiento de ZK Token Program, las syscalls de Poseidon y las syscalls alt_bn128. Junto con las mejoras en los validadores y en la eficiencia de la red, esta actualización establece una base sólida para la siguiente versión. Es más pequeña que la v1.16 y está en línea con el objetivo de lanzar una nueva versión cada tres meses. Puedes consultar el calendario de lanzamiento de la versión 1.18 aquí.

Si llegaste hasta aquí, ¡gracias, anon! Introduce tu correo electrónico abajo para no perderte ninguna novedad sobre Solana. ¿Quieres profundizar más? Explora los artículos más recientes del blog de Helius y continúa hoy mismo tu recorrido por Solana.

Recursos adicionales

• Informe de la interrupción de Solana Mainnet Beta del 06-02-24
• Calendario de lanzamiento de la v1.17
• Poseidon: hashing optimizado para ZK
• Cuenta de Twitter de estado de Solana
• Los validadores de Solana adoptan la actualización v1.17