Pruebas de conocimiento cero: sus aplicaciones en Solana

Introducción

Este es el segundo artículo de una serie introductoria sobre pruebas de conocimiento cero. Recomiendo ampliamente leer Pruebas de conocimiento cero: introducción a los fundamentos antes de este artículo, ya que proporciona el contexto necesario sobre la teoría, las matemáticas y la criptografía subyacentes que enmarcan este análisis. Este artículo presupone esos conocimientos. Por eso, si no conoces las pruebas de conocimiento cero, te recomiendo leer primero el artículo anterior. El objetivo de este artículo es brindarte los conocimientos necesarios para contribuir al debate sobre las pruebas de conocimiento cero en Solana e incluso comenzar a desarrollar primitivas de conocimiento cero nuevas e innovadoras.

Con estos nuevos conocimientos, por fin podemos preguntar: ¿qué son las pruebas de conocimiento cero? ¿Cómo se usan en Solana?

¿Qué son las pruebas de conocimiento cero?

Ahora que por fin contamos con la teoría, las matemáticas y la criptografía necesarias, corresponde preguntar: ¿qué es exactamente una prueba de conocimiento cero?

Una prueba de conocimiento cero es un proceso criptográfico mediante el cual una parte puede demostrarle a otra que una afirmación es verdadera sin revelar información adicional, salvo el hecho de que efectivamente lo es. Estas pruebas deben ser estadísticamente sólidas, completas y seguras frente a filtraciones de información.

Existen dos tipos de afirmaciones que podrías querer demostrar con conocimiento cero. A grandes rasgos:

• Afirmaciones sobre hechos (por ejemplo, este grafo específico admite una coloración con tres colores)
• Afirmaciones sobre conocimiento (por ejemplo, conozco la factorización de N)

En última instancia, la primera afirmación se refiere a una propiedad intrínseca del universo: algo que es fundamentalmente verdadero, como 1 + 1 = 2. La segunda se denomina prueba de conocimiento. Es decir, va más allá de simplemente demostrar que algo es cierto y depende de lo que sabe el Probador.

Como se mencionó antes, para demostrar estas afirmaciones, nuestras pruebas pueden ser interactivas o no interactivas. En una prueba interactiva de conocimiento cero, el Probador y el Verificador participan en una serie de rondas hasta que el Verificador queda convencido más allá de toda duda razonable. Zcash usa pruebas no interactivas de conocimiento cero para permitir que los usuarios realicen transacciones anónimas. 

En cambio, en las pruebas no interactivas de conocimiento cero, la prueba se entrega sin conexión y sin comunicación directa entre el Probador y el Verificador. Aquí, el Probador genera una prueba que contiene toda la información necesaria, y el Verificador puede verificarla de forma independiente sin ninguna interacción adicional. Filecoin usa pruebas no interactivas de conocimiento cero para demostrar que los usuarios almacenaron datos sin revelar los datos en sí. 

 zk-SNARKs y circuitos

Un zk-SNARK es un argumento de conocimiento sucinto, no interactivo. Estas pruebas de conocimiento cero son especialmente eficientes y compactas, o sucintas. Una prueba se considera sucinta si tanto su tamaño como el tiempo necesario para verificarla crecen más lentamente que el cálculo que se debe verificar. Por lo tanto, si queremos una prueba sucinta, no podemos hacer que el verificador realice trabajo en cada ronda de hashing, ya que el tiempo de verificación sería proporcional al cálculo. Las pruebas sucintas son posibles gracias a los polinomios y a la heurística de Fiat-Shamir.

Sin importar la complejidad de la afirmación que se intenta demostrar, los zk-SNARKs mantienen las pruebas pequeñas y permiten verificarlas con relativa rapidez. Esto hace que los zk-SNARKs sean tan atractivos para los rollups: ofrecen un método para demostrar que todas las transacciones de una L2 determinada son válidas, con una prueba lo bastante pequeña para verificarse en la L1. Protocolos como Mina van un paso más allá y usan pruebas recursivas, lo que les permite verificar todo el historial de la cadena mediante una prueba de tamaño constante. Pickles es el nuevo sistema de pruebas de Mina y su kit de herramientas asociado, el primer zk-SNARK implementado capaz de realizar composición recursiva sin una configuración de confianza. Ten en cuenta que, al hablar de composición recursiva, nos referimos a circuitos.

Los circuitos describen el cálculo que quieres demostrar. Son una secuencia de operaciones matemáticas que toma ciertas entradas para producir salidas. En las pruebas de conocimiento cero, los circuitos representan cálculos ejecutados correctamente sin revelar sus entradas. El flujo de trabajo general es el siguiente:

• Escritura y compilación del circuito — Debemos escribir y compilar el circuito. Podría ser tan sencillo como crear un circuito aritmético sobre un campo finito definido por el primo p = 7 y el cálculo x * y = z. La idea general es representar el cálculo que se demostrará como un conjunto de restricciones entre variables, reducirlas a ecuaciones polinómicas y escribir código que transforme todos los valores de una forma en una nueva estructura algebraica (es decir, un homomorfismo). El proceso de compilación produce varios artefactos, como el conjunto de restricciones definido por el circuito y un script o binario que se usará en los pasos posteriores
• Ceremonia de configuración de confianza — Según el tipo de zk-SNARK utilizado, puede ser necesario realizar una ceremonia para generar las claves de prueba y verificación
• Ejecución del circuito — Un circuito debe ejecutarse con el script o binario generado durante la compilación como si fuera un programa. El usuario introduce las entradas públicas y privadas, y luego se calculan los valores de todas las variables intermedias y de salida. El testigo, también conocido como traza, es el registro de todos los pasos del cálculo
• Generación de la prueba — Con la clave de prueba del segundo paso y el testigo del tercero, el probador puede generar una prueba de conocimiento cero que demuestre que se cumplen todas las restricciones definidas en el circuito, revelando únicamente el valor de salida. Esta prueba se envía al verificador
• Verificación de la prueba — El verificador comprueba que la prueba sea correcta para su salida pública mediante la prueba enviada y la clave de verificación

Ciertos tipos de zk-SNARKs, como Groth16, requieren una configuración de confianza para cada circuito. Esto puede ser un obstáculo, ya que tendrías que realizar una nueva ceremonia para cada programa nuevo. Otros zk-SNARKs, como PlonK, solo requieren una configuración de confianza universal, lo que simplifica todo el proceso. Otros tipos de pruebas de conocimiento cero, como los zk-STARKs, eliminan por completo la necesidad de una configuración de confianza.

zk-STARKs

Un zk-STARK es un argumento de conocimiento escalable y transparente. Los zk-STARKs fueron inventados por StarkWare y se propusieron por primera vez en este artículo de 2018 como alternativa a los zk-SNARKs. En esencia, permiten que las blockchains trasladen los cálculos a un único probador STARK fuera de la cadena y verifiquen su integridad mediante un Verificador STARK en la cadena. 

Los zk-STARKs se consideran de conocimiento cero porque las entradas utilizadas por el probador fuera de la cadena no se exponen a la blockchain, lo que preserva la privacidad del usuario. Son escalables porque trasladar los cálculos fuera de la cadena reduce considerablemente los costos de verificación de la L1. Sus pruebas también escalan de forma lineal, mientras que los zk-SNARKs solo lo hacen de forma cuasilineal. Además, los zk-STARKs no dependen de ceremonias complejas de configuración de confianza, que, según sus defensores, son susceptibles a residuos tóxicos: pruebas no válidas que los verificadores podrían aceptar si la ceremonia no se realizó correctamente. En su lugar, los zk-STARKs usan aleatoriedad verificable públicamente para configurar las interacciones entre probadores y verificadores. Además, estas pruebas solo puede generarlas un probador fuera de la cadena que haya ejecutado realmente el cálculo, junto con las entradas auxiliares que este requiere.

Los zk-STARKs resuelven las limitaciones de los zk-SNARKs al ser argumentos de conocimiento escalables y transparentes. También se basan en supuestos criptográficos mucho más sencillos y evitan por completo elementos como las curvas elípticas. En su lugar, dependen únicamente de hashes y de la teoría de la información, lo que los hace resistentes a la computación cuántica. Sin embargo, el tamaño de la prueba ronda varios cientos de kilobytes, lo que puede limitar su viabilidad en entornos con poco ancho de banda o almacenamiento, como las blockchains. Ten en cuenta que algunas configuraciones de prueba y zkVMs más complejas combinarán la demostración recursiva de zk-STARKs dentro de un zk-SNARK solo para el paso final de verificación.

ZK Compression

El problema del crecimiento del estado

Uno de los problemas más apremiantes de Solana es el crecimiento del estado. Para contextualizarlo, el estado de Solana se guarda en los discos de los nodos completos, dentro de Accounts DB. Es un almacén de clave-valor donde cada entrada de la base de datos se conoce como una cuenta. Cada cuenta tiene una dirección de 32 bytes y puede almacenar entre 0 y 10 MB de datos. Actualmente, almacenar 10 MB de datos cuesta cerca de 70 SOL, sin importar si se distribuyen en una cuenta de 10 MB o en mil cuentas de 10 KB. Cada día se agregan aproximadamente un millón de cuentas nuevas a la cadena. Según la publicación de Toly sobre el crecimiento del estado, esto eleva el estado total a más de 500 millones de cuentas. A medida que Solana crezca, esto planteará varios desafíos, principalmente un tamaño de snapshot sin límites, restricciones de ancho de banda de PCI, indexación de cuentas y una gestión costosa de la memoria y del disco. 

El snapshot completo actual mide alrededor de 70 GB, una cifra manejable con el hardware actual. Sin embargo, el crecimiento continuo provocará inevitablemente ineficiencias en la gestión del estado y posibles cuellos de botella. Conforme aumenta el tamaño del snapshot, se alarga considerablemente el tiempo necesario para realizar un arranque en frío de un sistema nuevo tras una falla de hardware. Esto podría ser perjudicial si se reinicia la red. 

El ancho de banda de Peripheral Component Interconnect (PCI) se refiere a la velocidad de transferencia de datos entre la CPU y dispositivos periféricos, como tarjetas gráficas, tarjetas de red y dispositivos de almacenamiento. PCI Express (PCIe) es un estándar de interfaz de alta velocidad diseñado para reemplazar el estándar PCI anterior y ofrecer mayores velocidades de transferencia. El ancho de banda PCI más reciente puede alcanzar 1 TB, o 128 GB/s. Aunque parece mucho, no lo es en el contexto de Solana. Si una transacción lee o escribe 128 MB, un ancho de banda PCI de 128 GB/s limitaría Solana a 1000 transacciones por segundo (TPS). Sin embargo, la mayoría de las transacciones accede a memoria reciente que ya se cargó y almacenó en caché en la RAM de un validador. Aun así, gestionar eficientemente la memoria de estado es crucial para mantener un alto rendimiento mientras Solana escala. De lo contrario, este ancho de banda puede convertirse rápidamente en un factor limitante.

Cada validador debe mantener un índice de todas las cuentas existentes. Esto se debe a que crear una cuenta nueva requiere demostrar que todavía no existe. Con un estado total superior a 500 millones de cuentas, incluso un índice mínimo (es decir, una clave de 32 bytes y un hash de datos de 32 bytes por entrada) necesitaría unos 32 GB de RAM. Este almacenamiento del estado es costoso y debe gestionarse con cuidado para evitar una degradación del rendimiento. A medida que el estado de Solana sigue creciendo, resulta crucial distinguir entre el uso de memoria rápida y costosa (es decir, RAM) para determinadas operaciones y memoria más lenta y económica (es decir, disco).

Transacciones y crecimiento del estado

Cada transacción de Solana debe especificar todas las cuentas que lee y en las que escribe. Actualmente, las transacciones tienen un límite de 1232 bytes y deben incluir lo siguiente:

• Encabezado (3 bytes)
• Firmas (64 bytes cada una)
• Direcciones de cuentas (32 bytes cada una)
• Datos de instrucciones (tamaño arbitrario)
• Blockhash reciente (32 bytes)

Cuando se ejecuta una transacción, ocurre lo siguiente:

• Comprobaciones básicas — Solo son válidas las transacciones recientes. Se realizan comprobaciones de deduplicación, estructura, comisiones y firmas
• Carga del programa — El bytecode del programa se carga según la dirección del programa y se instancia la Solana Virtual Machine (SVM)
• Carga de cuentas — Todas las cuentas referenciadas por la transacción se comprueban, se cargan del almacenamiento a la memoria y se pasan a la SVM
• Ejecución — Se ejecuta el bytecode del programa
• Sincronización — Las cuentas modificadas se vuelven a sincronizar con el almacenamiento

Este ciclo de vida plantea varios desafíos a medida que crece el estado. En particular, el estado en la cadena es costoso, y almacenar más cuentas en disco produce snapshots e índices más grandes. Además, no se accede con frecuencia a todas las cuentas, por lo que resulta ineficiente asumir un costo continuo de recursos por ellas.

Simplificación de la gestión del estado con ZK Compression

En lugar de almacenar todas las cuentas en disco y leerlas cuando sean necesarias, una transacción puede pasar los datos de la cuenta como parte de su carga útil. Podemos garantizar que los usuarios que envían transacciones proporcionen el estado correcto mediante árboles de Merkle. Las pruebas de Merkle permiten generar un compromiso sobre ciertos datos. Así, las pruebas pueden verificarse contra ese compromiso para validar que se proporcionó el estado correcto y que el usuario no miente sobre él. 

Aunque son seguras, estas pruebas pueden ser bastante grandes. Por ejemplo, si un árbol contiene 100 mil cuentas, la prueba mediría 544 bytes. Proporcionar pruebas para varias cuentas podría superar rápidamente el límite de 1232 bytes por transacción. Por suerte, podemos evitarlo usando sistemas de pruebas más eficientes. El uso de compromisos con pruebas de tamaño constante, como KZG o los compromisos de Pedersen, reduciría el tamaño de la prueba y haría más viable incluirla dentro del límite de la transacción.

ZK Compression es simplemente un mecanismo para resolver el problema del tamaño de las pruebas de Merkle: permite demostrar que un cálculo se realizó correctamente sin los costos asociados del almacenamiento en la cadena, aprovechando el ledger de Solana.

¿Qué es ZK Compression?

ZK Compression es una nueva primitiva que permite a los desarrolladores comprimir el estado en la cadena para reducir sus costos en varios órdenes de magnitud sin sacrificar seguridad, rendimiento ni componibilidad. Por ejemplo, crear 100 cuentas de tokens costaría actualmente ~0.2 SOL. Con ZK Compression, el costo se reduce 5000 veces, a ~0.00004. 

ZK Compression aprovecha las pruebas de conocimiento cero para validar las transiciones de estado sin exponer los datos subyacentes. Para ello, agrupa varias cuentas en una única raíz de Merkle verificable que se almacena en la cadena, mientras que los datos subyacentes se guardan en el ledger. Las pruebas de validez son pruebas sucintas de conocimiento cero que se usan para demostrar la existencia de n cuentas como hojas dentro de m árboles de estado, manteniendo un tamaño constante de 128 bytes. Estas pruebas se generan fuera de la cadena y se verifican en ella, lo que reduce la carga computacional general de Solana. ZK Compression usa Groth16, un reconocido zk-SNARK basado en emparejamientos, para su sistema de prueba.

Sin embargo, estas no son cuentas normales de Solana. Son cuentas comprimidas.

Modelo de cuentas comprimidas

El estado comprimido de ZK se almacena en cuentas comprimidas. Estas cuentas se parecen a las cuentas normales de Solana, pero tienen varias diferencias clave que mejoran la eficiencia y la escalabilidad:

• Identificación mediante hash — Cada cuenta comprimida puede identificarse mediante su hash
• Cambio del hash al escribir — Cualquier operación de escritura en una cuenta comprimida cambiará su hash
• Dirección opcional — Se puede establecer opcionalmente una dirección como ID único y permanente de la cuenta comprimida. Esto es útil para determinados casos de uso, como los NFT. El campo es opcional para evitar la sobrecarga computacional, ya que las cuentas comprimidas pueden referenciarse mediante su hash
• Árboles de estado dispersos — Todas las cuentas comprimidas se almacenan en árboles de Merkle. Solo la raíz de estado del árbol (es decir, la raíz de Merkle) se guarda en el espacio de cuentas de la cadena. Más concretamente, un árbol de estado es un árbol de Merkle concurrente basado en hashes de Poseidon

Las direcciones comprimidas derivadas de programas (PDA) pueden identificarse por su dirección única y persistente. Siguen una estructura similar a las cuentas PDA normales, con los campos Data, Lamports, Owner y Address. Sin embargo, a diferencia de las PDA normales, el campo Data incorpora la estructura AccountData con los campos Discriminator, Data y DataHash.

Nodos

Distintos tipos de nodos desempeñan funciones cruciales para permitir ZK Compression. Cualquiera puede ejecutar un nodo Photon RPC, un nodo Prover o un nodo Light Forester para conectarse a Devnet y Mainnet-Beta. Para el desarrollo local, el comando test-validator de la CLI de ZK Compression inicia un clúster de Solana de un solo nodo con todos los nodos pertinentes (es decir, Photon RPC y Prover), además de los programas del sistema, las cuentas y las funciones del entorno de ejecución.

Los nodos Photon RPC indexan los programas de compresión. Esto permite que los clientes lean y creen transacciones que interactúan con el estado comprimido. El indexador canónico de compresión se llama Photon y lo proporciona Helius. Este tipo de nodo puede ejecutarse localmente con una configuración mínima y debe apuntar a un RPC existente. 

Los nodos Prover se usan para generar pruebas de validez de inclusión en el estado. El endpoint getValidityProof de la especificación de la API RPC de ZK Compression permite obtener pruebas. Los nodos Prover pueden ejecutarse como nodos independientes o agruparse con otro RPC. Ten en cuenta que la implementación canónica de Photon RPC incluye un nodo Prover.

Los nodos Light Forester gestionan la creación, la rotación y la actualización de los árboles de estado compartidos y propiedad de programas. Están pensados para desarrolladores que quieran contar con una red de nodos Light Forester para mantener sus propios árboles de estado propiedad de programas.

Supuestos de confianza

Cualquiera puede ejecutar uno de los nodos mencionados, almacenar los datos sin procesar necesarios para generar pruebas y enviar transacciones. Esto introduce un supuesto de confianza que afecta la vitalidad del estado comprimido. En concreto, si los datos se pierden o se retrasan, no se pueden enviar transacciones a menos que se almacenen personalmente. Como solo se necesita un nodo honesto para proporcionar los datos y las pruebas se pueden verificar de manera autónoma, el problema radica en la vitalidad y la posible censura, no en la seguridad.

Además, el hecho de que el programa que verifica las cuentas comprimidas pueda actualizarse actualmente introduce otro supuesto de confianza. Esto permite modificar el programa para corregir problemas o adaptarlo a nuevos requisitos. Sin embargo, puede volverse inmutable o congelarse en el futuro, cuando alcance un estado estable y seguro.

Otro supuesto de confianza sobre la vitalidad es el uso de nodos Forester. Estos nodos mantienen el avance de las raíces de estado y gestionan las colas de anuladores. Para ello, las vacían y avanzan las raíces de estado de forma asíncrona. Aquí, los hashes de las cuentas se sustituyen por ceros para anularlos. Esta separación entre avance y anulación garantiza la finalidad instantánea de las transiciones del estado comprimido, mientras mantiene las transacciones dentro de los límites de tamaño de Solana. Como las colas de anuladores tienen un tamaño constante, los nodos Forester son esenciales para la vitalidad del protocolo. Una cola llena provocaría una falla de vitalidad en el árbol de estado asociado. Por suerte, los nodos Forester lo evitan vaciando las colas. Sin embargo, aún es necesario que alguien ejecute estos nodos para mantener la integridad y la vitalidad del protocolo. Sin ellos, ZK Compression solo podría admitir unas dos mil cuentas o direcciones.

Limitaciones 

Aunque no sea necesario ocultar nada, las pruebas de conocimiento cero convierten los problemas que requieren varios pasos computacionales en otros donde basta verificar una sola prueba para saber que los cálculos se ejecutaron correctamente. Estos cálculos no tienen que limitarse a comprobar si una hoja específica pertenece a un árbol determinado: pueden ser cualquier cálculo arbitrario. Sin embargo, esto tiene un costo.

Antes de usar ZK Compression, considera lo siguiente:

• Mayor tamaño de la transacción — ZK Compression requiere 128 bytes para la prueba de validez, además de los datos que se enviarán para leerlos o escribirlos en la cadena
• Mayor uso de unidades de cómputo — ZK Compression aumenta considerablemente el uso de unidades de cómputo (CU), ya que requiere ~100k CU para verificar la prueba de validez, ~100k CU para uso del sistema y ~6k CU por cada lectura o escritura de una cuenta comprimida
• Costo de estado por transacción — Cada operación de escritura incurre en un pequeño costo de red, ya que debe anular el estado anterior de la cuenta comprimida y agregar el nuevo estado comprimido al árbol de estado. Por lo tanto, es totalmente posible que el costo de por vida de una cuenta comprimida supere el de su equivalente sin comprimir si requiere numerosas actualizaciones de estado

Puede ser preferible usar una cuenta normal si:

• La cuenta se actualiza con frecuencia
• La cantidad de escrituras en la cuenta durante toda su vida útil será elevada (es decir, >1000x)
• La cuenta almacena una gran cantidad de datos a los que deben acceder las transacciones en la cadena

Beneficios

ZK Compression es una primitiva escalable, segura, eficiente y flexible que aborda directamente el problema del crecimiento del estado de Solana y admite una amplia variedad de aplicaciones y casos de uso. Podría decirse que su ventaja más evidente es la reducción de los costos de estado. ZK Compression permite que las aplicaciones escalen fácilmente a millones de usuarios. Para ello, almacena el estado de forma segura en el espacio más económico del ledger y minimiza el almacenamiento en la cadena mediante huellas digitales del estado. Si tomamos como ejemplo la acuñación de 10,000 cuentas de tokens y suponemos un precio de SOL de $130 USD, el costo sería de unos $2,600. ZK Compression lo reduce a menos de cincuenta centavos.

ZK Compression también se integra bien con las especificaciones actuales de Solana. Por ejemplo, la estructura de las cuentas comprimidas es casi idéntica a la de las cuentas normales de Solana. También admite innovaciones específicas de Solana, como el paralelismo. Es decir, dos transacciones bajo el mismo árbol de estado (es decir, compromiso) que accedan a cuentas comprimidas diferentes pueden ejecutarse en paralelo. Además, ZK Compression refuerza la componibilidad atómica síncrona. Por ejemplo, una transacción que enumera n cuentas comprimidas y m cuentas normales es una configuración totalmente válida. Una instrucción que referencia una cuenta comprimida puede llamar a otra instrucción o programa que referencia una cuenta normal. Esto se cumple incluso si las cuentas están comprimidas en árboles de estado diferentes. Si una instrucción falla, toda la transacción se revierte, y los cambios son visibles de una instrucción a la siguiente. Esto difiere de los rollups ZK, que no pueden llamarse entre sí de manera síncrona o atómica a menos que usen bloqueos. Naturalmente, esto justifica una comparación entre ZK Compression y los rollups.

ZK Compression no es un rollup

ZK Compression no es un rollup. Aunque ambos dependen de la misma tecnología, sus implementaciones son diferentes. Hay dos tipos de rollups:

• Rollups optimistas — Se supone que todas las transacciones son válidas durante un período determinado, y las pruebas de fraude se usan para demostrar cuáles son falsas dentro de ese plazo
• Rollups de conocimiento cero — Mediante pruebas de validez, se demuestra de inmediato si las transacciones son válidas o no

Todo el estado de un rollup de conocimiento cero se representa como una única raíz en la capa base (es decir, Ethereum). Esto ha dado lugar a varias afirmaciones de que ZK Compression es, de hecho, un rollup. Sin embargo, existen varias diferencias cruciales.

Considera un escenario con 500 transacciones en un rollup ZK. En este caso, todo el rollup se trata como un único circuito. Las 500 transacciones se verifican juntas y generan una sola prueba que confirma que la raíz de estado cambió de A a B. Una vez verificada, el contrato inteligente que gestiona las interacciones entre la L1 y la L2 actualiza la raíz de estado. En cambio, con ZK Compression, cada una de las 500 transacciones genera su propia prueba para verificar que los datos de la cuenta sean correctos. La propia SVM ejecuta estas transacciones, y las cuentas se tratan como cuentas «normales» una vez validada cada prueba.

Si clasificáramos ZK Compression como un rollup, implicaría que cualquier raíz de Merkle almacenada en Solana podría considerarse un rollup basado en validez. Si observamos todas las raíces de cNFT comprimidos que existen actualmente en Solana, hay alrededor de 4-5k rollups basados en validez, dependiendo de si contamos los árboles de Merkle sin acuñaciones.

Por lo tanto, queda claro que ZK Compression es una solución única adaptada a la arquitectura de Solana. Es una primitiva novedosa, distinta de los rollups ZK, que mejora la escalabilidad y la eficiencia sin la complejidad ni la separación de los rollups.

El futuro de ZK en Solana y la interoperabilidad

El estado actual de ZK en Solana

Una de mis primeras tareas de redacción en Helius fue cubrir la actualización v1.16 de Solana. Me entusiasmó mucho conocer la mejora en la compatibilidad del entorno de ejecución con las pruebas de conocimiento cero y la cubrí en el artículo. Sin embargo, estas mejoras se retrasaron. Cometí el error de volver a cubrirlas con más detalle en el artículo sobre la actualización v1.17, pero volvieron a retrasarse. Ni siquiera me molesté en incluirlas en el artículo sobre la actualización v1.18. Naturalmente, me decepcionó, y otros también expresaron su frustración. 

A pesar de este sentimiento, en Solana está surgiendo una comunidad pequeña pero incipiente de desarrolladores de ZK. Al principio, Light Protocol se centraba en la ejecución privada de programas mediante PSP (Private Solana Programs), antes de redefinir su enfoque hacia ZK Compression. Dark protocol también es un protocolo de privacidad futárquico desarrollado en Solana. No tiene un equipo central y las contribuciones se realizan mediante propuestas. Arcium, antes conocido como Elusiv, usa Multiparty computation eXecution Environments (MXE) para impulsar su propia red paralelizada de computación confidencial. Bonsol es un «coprocesador» de conocimiento cero que permite a los desarrolladores ejecutar cualquier imagen risc0 y verificarla en Solana (es decir, cómputo verificable fuera de la cadena). También han circulado tutoriales y listas de enlaces relacionados con pruebas de conocimiento cero.

Lo más destacado es que el ZK Token Proof Program verifica varias pruebas de conocimiento cero adaptadas para funcionar con compromisos de Pedersen y cifrado Twisted ElGamal sobre curve25519. Esto posibilita las transferencias confidenciales, que usan pruebas de conocimiento cero para cifrar los saldos y montos de las transacciones de tokens SPL. El objetivo es la confidencialidad, no el anonimato. El cifrado homomórfico permite realizar cálculos sobre datos cifrados sin descifrarlos. Para ello, las transferencias confidenciales usan el cifrado Twisted ElGamal para realizar operaciones matemáticas ocultas sobre el texto cifrado y protocolos Sigma para validar esas transferencias sin revelar información confidencial. Solo el titular de la cuenta que posee la clave de descifrado puede ver su saldo cifrado. Sin embargo, el Global Auditor System permite dar acceso de lectura selectivo para fines de cumplimiento y auditoría mediante claves de descifrado independientes. 

Actualmente, el ZK Token Proof Program es una función bloqueada debido a la aprobación de SIMD-0153: ZK ElGamal Proof Program. Esta nueva SIMD busca retirar el ZK Token Proof Program existente, diseñado específicamente para el programa SPL Token, y sustituirlo por un programa de pruebas de conocimiento cero más general e independiente de cualquier aplicación específica. La SIMD se integró con el apoyo tanto de Anza como del equipo de Firedancer.

Sin embargo, la situación está empezando a cambiar. Solana se está convirtiendo en un gigante de ZK, ya que estas mejoras por fin están llegando a Devnet y Mainnet-Beta. Ahora hay tres syscalls de ZK activas en Solana.

Syscalls de Poseidon

Poseidon es una familia de funciones hash diseñada específicamente para pruebas de conocimiento cero y se usa en proyectos como Zcash, Mina y Light Protocol. Poseidon es más eficiente desde el punto de vista computacional para las pruebas de conocimiento cero que las funciones hash tradicionales y generalizadas, como SHA-256. 

Las funciones hash de Poseidon son compatibles con el conocimiento cero porque:

• Ejecutan operaciones aritméticas de forma eficiente
• Requieren menos pasos para generar pruebas (es decir, tienen menor complejidad de circuito) gracias a su diseño compatible con la aritmética, su S-box optimizada y su bajo número de rondas
• Usan algoritmos que procesan secuencias de bits de cualquier longitud, lo que las hace extremadamente versátiles

Antes era demasiado costoso calcular hashes de Poseidon en una sola transacción. Sin embargo, esto cambia con la época 644 y la activación de la syscall de Poseidon (es decir, una llamada al sistema que recibe como entrada un segmento bidimensional de bytes y calcula como salida el hash de Poseidon correspondiente). Esto resulta emocionante porque ZK Compression depende del hashing de Poseidon para sus árboles de estado.

La syscall de Poseidon calcula hashes mediante la curva BN254 con los siguientes parámetros:

• S-boxes — Cajas de sustitución x5
• Entradas — 1 ≤ n ≤ 12
• Ancho — 2 ≤ t ≤ 13
• Rondas — 8 rondas completas y rondas parciales según t: [56, 57, 56, 60, 60, 63, 64, 63, 60, 66, 60, 65]

Su salida será el resultado del hash de Posiedon codificado en 32 bytes con el orden de bytes especificado.

Ten en cuenta que la variante específica usada aquí para la syscall es Poseidon con una S-box x5 y parámetros adaptados para la curva BN254. El crate light-poseidon facilitará el cálculo de estos hashes. El crate está auditado y es compatible con Circom.

Syscalls alt_bn128

alt_bn128 se refiere a la implementación de la curva elíptica Barreto-Naehrig (BN-128), una curva compatible con emparejamientos que permite realizar pruebas y cálculos de zk-SNARKs de forma eficiente. Esta curva es fundamental para varios sistemas de pruebas de conocimiento cero, incluido Groth16, que es el sistema del que depende ZK Compression para validar las transiciones de estado. Esta syscall reduce considerablemente el espacio necesario para cada prueba, lo que proporciona una optimización crucial de espacio y tiempo para realizar pruebas eficientes en la cadena. 

Las syscalls sol_alt_bn128_group_op calculan operaciones en la curva alt_bn128, como la suma de puntos en G1 (G1 se refiere simplemente a un grupo de puntos sobre una curva elíptica determinada), la multiplicación escalar en G1 y el emparejamiento:

• Entradas — Puntos y escalares serializados en formato big endian
• Operaciones — Suma de puntos en G1, multiplicación escalar en G1 y emparejamiento (1 punto en G1 y 1 punto en G2)
• Salidas — Puntos en G1 o resultados de emparejamiento serializados como un entero de 256 bits

Las syscalls sol_alt_bn128_compression comprimen o descomprimen puntos en los grupos G1 o G2 sobre la curva alt_bn128 y devuelven los puntos en formato big endian estándar.

Estas syscalls están activas actualmente en testnet y al parecer estarán disponibles en Devnet cuando se resuelvan los errores de la fase de recompilación de los programas cargados, de acuerdo con SIMD-0075: Secp256r1 Precompile. Esta propuesta busca simplificar los códigos de error de las syscalls alt_bn128 y de la syscall de Poseidon, para garantizar la coherencia y reducir el riesgo de fallas de consenso causadas por los distintos códigos de error que devuelven los validadores.

Las syscalls alt_bn128 pueden usarse para compromisos vectoriales normales con pruebas de tamaño constante, como los compromisos KZG. Por lo tanto, funcionarán con cualquier curva compatible con emparejamientos y no requerirán un circuito probador de ZK. 

Interoperabilidad

Solana es una cadena ZK. Es una blockchain de capa 1 de alto rendimiento, con comisiones bajas y compatibilidad en el entorno de ejecución para operaciones con curvas elípticas. La implementación y compatibilidad con syscalls relacionadas con pruebas de conocimiento cero fomentan la innovación y permiten desarrollar nuevas primitivas y aplicaciones, como ZK Compression, sobre Solana.

La introducción de las syscalls alt_bn128 reduce la brecha de componibilidad 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 facilitan la verificación de pruebas zk-SNARK dentro de los límites de gas de Ethereum. Por lo tanto, los contratos de Solidity que dependen de estas operaciones con curvas elípticas ahora podrían migrar con mayor facilidad a Solana, o incluso interoperar con ella.

SIMD-0075 es vital para las soluciones de interoperabilidad. Una vez que se implemente por completo, esta SIMD permitirá que proyectos como el próximo blobsream-solana (que transmite DA desde Celestia a Solana) usen la generación de pruebas fuera de la cadena y la verificación en la cadena para almacenar compromisos de Merkle. Sin estas syscalls, no sería posible verificar las pruebas Groth16 en Solana. Además, estas syscalls mejoran los puentes con confianza minimizada y la interoperabilidad, lo que permite que otras blockchains interactúen con Solana de forma fluida y segura.  

Toly tiene razón: con todas estas mejoras al entorno de ejecución de Solana, Solana es una L2 de Ethereum. Pronto, nada te impedirá enviar todos los bloques de Solana a un contrato puente de validación de datos en Ethereum. Y a la inversa, nada te impedirá enviar todos los bloques de Ethereum a un programa puente de validación de datos en Solana. La interoperabilidad bidireccional, acelerada por pruebas de conocimiento cero en lugar de puentes anticuados, representa un futuro prometedor y emergente para Solana.

Conclusión

Sin duda, las pruebas de conocimiento cero son una de las primitivas más potentes, si no la más potente, desarrolladas por los criptógrafos. Esto se vuelve evidente al examinar desde primeros principios la teoría, las matemáticas y la criptografía que sustentan este concepto, como hicimos en el primer artículo. Sus posibles aplicaciones son infinitas: desde una verdadera niebla de guerra para juegos en la cadena hasta demostrar que un conjunto de transacciones en una L2 produjo una transición de estado específica.

Esta serie de dos partes fácilmente podría haber ocupado más de cincuenta páginas adicionales para cubrir las complejidades del cifrado homomórfico, la programación de circuitos en Circom y el análisis de diferentes esquemas de compromiso. Sin embargo, el objetivo de estos artículos es enseñar los fundamentos de las pruebas de conocimiento cero para que puedas tomar estos nuevos conocimientos y aplicarlos ahora a Solana. 

Solana se está convirtiendo en un gigante de ZK. Desde el lanzamiento de ZK Compression hasta las distintas syscalls que se activarán próximamente, no se puede subestimar su importancia. Aunque primitivas como ZK Compression abstraen todas las complejidades de las pruebas de conocimiento cero para el desarrollador promedio, comprender los fundamentos es invaluable para impulsar el debate y su desarrollo en Solana. 

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

Recursos adicionales

• Introducción aproximada a cómo son posibles los zk-SNARKs, por Vitalik
• POSEIDON: una nueva función hash para sistemas de pruebas de conocimiento cero (versión actualizada)
• SIMD-0075: precompilación de Secp256r1
• Comprende la diferencia entre zk-SNARKs y zk-STARKs
• Documentación de ZK Compression