Anagram Build pasa la mayor parte de nuestro tiempo investigando nuevas primitivas criptográficas y aplicando estas primitivas en productos específicos. Uno de nuestros proyectos de investigación recientes nos llevó al ámbito de Verifiable Compute (VC); nuestro equipo aprovechó esta investigación para crear un nuevo sistema de código abierto llamado Bonsol. Elegimos esta área de investigación dada la aparición de casos de uso efectivos que permite VC y los esfuerzos concertados en varios L1 para optimizar la rentabilidad y escalabilidad de VC.

En este blog, tenemos dos objetivos.

• Primero, queremos asegurarnos de que obtenga una mejor comprensión del VC como concepto y los posibles productos que habilita en el ecosistema Solana.
• En segundo lugar, queremos presentarte nuestra última creación, Bonsol.

¿Qué es Verifiable Compute, de todos modos?

El término 'Verifiable Compute' puede que no aparezca en las presentaciones de inversión de startups en mercados alcistas, pero el término 'Conocimiento Cero' sí. Entonces, ¿qué significan estos términos?

La Computación Verificable (VC) está ejecutando una carga de trabajo específica de una manera que produce una certificación de su funcionamiento que puede ser verificada públicamente sin volver a ejecutar la computación. El Conocimiento Cero (ZK) es la capacidad de demostrar una afirmación sobre datos o una computación sin revelar todos los datos o las entradas a la computación. Los términos están algo confundidos en el mundo real, ZK es algo así como un término incorrecto. Tiene más que ver con seleccionar la información que debe hacerse pública para demostrar una afirmación al respecto. VC es un término más preciso y es el objetivo general en muchas arquitecturas de sistemas distribuidos existentes.

¿Cómo nos ayuda el VC a construir mejores productos criptográficos?

Entonces, ¿por qué queremos agregar sistemas de VC o ZK, además de plataformas como Solana y Ethereum? Parece que la respuesta se centra más en la seguridad para el desarrollador. El desarrollador de un sistema actúa como mediador entre la confianza de los usuarios finales en una caja negra y las funciones técnicas que hacen que esa confianza sea objetivamente válida. Al utilizar técnicas ZK/VC, el desarrollador puede reducir la superficie de ataque en los productos que está construyendo. Los sistemas VC desplazan el locus de confianza al sistema de prueba y a la carga de trabajo computacional que se está probando. Esta es una inversión de confianza similar a la que ocurre al pasar de un enfoque típico de cliente/servidor web2 a un enfoque de blockchain web3. La confianza pasa de depender de las promesas de una empresa a confiar en el código fuente abierto y en los sistemas criptográficos de la red. No existen sistemas verdaderamente de confianza cero desde la perspectiva del usuario, y sostengo que, para los usuarios finales, todo parece una caja negra.

Por ejemplo, al utilizar un sistema de inicio de sesión ZK, un desarrollador tendrá menos responsabilidad en el mantenimiento de una base de datos segura y una infraestructura que en un sistema que verifique que se logren algunas propiedades criptográficas. Las técnicas de VC se están aplicando en muchos lugares donde se necesita consenso para asegurar que lo único necesario para crear consenso es que las matemáticas sean válidas.

Si bien existen muchos ejemplos prometedores de uso de VC y ZK en la naturaleza, muchos de ellos actualmente dependen del desarrollo en curso en todos los niveles del conjunto de software criptográfico para hacerlo lo suficientemente rápido y eficiente como para ser utilizado en producción.

Como parte de nuestro trabajo aquí en Anagram, tenemos la oportunidad de hablar con una multitud de fundadores/desarrolladores de criptomonedas para comprender dónde se está ralentizando la innovación de productos en el software de criptomonedas. Históricamente, nuestras conversaciones nos han ayudado a identificar una tendencia interesante. Específicamente, un grupo de proyectos está trasladando activamente la lógica del producto en cadena fuera de la cadena porque se está volviendo demasiado costoso, o necesitan agregar una lógica empresarial más exótica. Así que al final, estos desarrolladores se encuentran tratando de encontrar sistemas y herramientas para equilibrar las partes en cadena y fuera de la cadena de los productos que están desarrollando, los cuales se están volviendo cada vez más poderosos. Aquí es donde el VC se convierte en una parte crítica del camino a seguir para ayudar a conectar los mundos en cadena y fuera de cadena utilizando métodos sin confianza y verificables.

¡Vamos! Entonces, ¿cómo funcionan los sistemas VC/ZK hoy en día?

Las funciones VC y ZK ahora se realizan principalmente en capas de cálculo alternativas (también conocidas como rollups, sidechains, relays, oráculos o coprocesadores) disponibles a través de una devolución de llamada al tiempo de ejecución del contrato inteligente. Para habilitar este flujo de trabajo, muchas de las cadenas L1 tienen esfuerzos en progreso para proporcionar atajos fuera del tiempo de ejecución del contrato inteligente (por ejemplo, syscalls o precompiles) que les permiten hacer cosas que de otra manera serían demasiado costosas en la cadena.

Hay algunos modos comunes de los sistemas actuales de VC. Mencionaré los cuatro principales de los que tengo conocimiento. En todos los casos menos el último, las pruebas ZK se realizan fuera de la cadena, pero es el lugar y el momento en que se verifican las pruebas lo que le da a cada uno de estos modos su ventaja.

Verificación totalmente en cadena

Para sistemas de prueba de VC y ZK que pueden producir pruebas pequeñas, como Groth16 o algunas variedades de Plonk, la prueba se envía a la cadena y se verifica en la cadena utilizando código previamente implementado. Estos sistemas son ahora muy comunes, y la mejor manera de probarlos es utilizando Circom y un verificador Groth16 en Solana o EVM. La desventaja es que estos sistemas de prueba son bastante lentos. También suelen requerir aprender un nuevo lenguaje. Para verificar un hash de 256 bits en Circom, en realidad necesitas manejar manualmente cada uno de esos 256 bits. Hay muchas bibliotecas que te permiten simplemente llamar a funciones hash, pero detrás de escena, necesitas reimplementar estas funciones en tu código Circom. Estos sistemas son excelentes cuando el elemento ZK y VC de tu caso de uso es más pequeño, y necesitas que la prueba sea válida antes de que se tome alguna otra acción determinista. Bonsol entra en esta primera categoría actualmente.

Verificación fuera de la cadena

La prueba se envía a la cadena para que todas las partes puedan ver que está allí y luego utilizar el cálculo fuera de la cadena para verificarla. En este modo, puedes admitir cualquier sistema de demostración, pero como la prueba no ocurre en la cadena, no obtienes el mismo determinismo para cualquier acción que dependa de la presentación de la prueba. Esto es bueno para sistemas que tienen algún tipo de ventana de desafío donde las partes pueden "objetar" e intentar demostrar que la prueba es incorrecta.

Redes de verificación

La prueba se envía a una red de verificación, y esa red de verificación actúa como un oráculo para llamar al contrato inteligente. Obtienes el determinismo, pero también necesitas confiar en la red de verificación.

Verificación Síncrona En Cadena

El cuarto y último modo es bastante diferente; en este caso, la prueba y verificación ocurren al mismo tiempo y completamente en cadena. Aquí es donde el L1 o un contrato inteligente en el L1 realmente puede ejecutar un esquema ZK sobre las entradas de usuario que permiten probar la ejecución sobre datos privados. No hay muchos ejemplos extendidos de esto en la naturaleza, y por lo general, los tipos de cosas que se pueden hacer con esto están limitados a operaciones matemáticas más básicas.

Recap

Los cuatro de estos modos se están probando en varios ecosistemas de cadenas, y veremos si surgen nuevos patrones y cuál patrón se vuelve dominante. Por ejemplo, en Solana, no hay un claro ganador, y el panorama de VC y ZK está muy temprano. El método más popular en muchas cadenas, incluida Solana, es el primer modo. La verificación completamente en cadena es el estándar de oro, pero como se discutió, viene con algunas desventajas. Principalmente la latencia y limita lo que pueden hacer tus circuitos. A medida que nos sumergimos en Bonsol, verás que sigue el primer modo con un ligero giro.

¡Presentamos Bonsol!

EntrarBonsol, un nuevo sistema VC nativo de Solana que hemos construido y compartido en Anagram. Bonsol permite a un desarrollador crear un ejecutable verificable sobre datos privados y públicos e integrar los resultados en contratos inteligentes de Solana. Tenga en cuenta que este proyecto depende de la popular cadena de herramientas RISC0.

Este proyecto fue inspirado por una pregunta realizada por muchos de los proyectos con los que trabajamos semanalmente: "¿Cómo puedo hacer esta cosa con datos privados y demostrarlo en la cadena?" Si bien la "cosa" difería en cada caso, el deseo subyacente era el mismo: minimizar sus dependencias centralizadas.

Antes de sumergirnos en los detalles del sistema, comencemos ilustrando el poder de Bonsol con dos casos de uso separados.

Escenario uno

Una Dapp que permite a los usuarios comprar boletos para sorteos en piscinas de varios tokens. Las piscinas se "decantan" una vez al día de una piscina global de tal manera que la cantidad de dinero en la piscina (las cantidades de cada token) están ocultas. Los usuarios pueden comprar acceso a rangos cada vez más específicos de los tokens en la piscina. Pero hay un truco: una vez que un usuario compra el rango, se vuelve público para todos los usuarios al mismo tiempo. El usuario debe decidir entonces si compra el boleto. Pueden decidir que no vale la pena la compra, o pueden asegurar una participación en la piscina comprando un boleto.

Bonsol entra en juego cuando se crea el pool y cuando el usuario paga por el rango para que se conozca. Cuando se crea/desembalsa el pool, el programa ZK toma las entradas privadas de la cantidad de cada token a desembalsar. Los tipos de tokens son entradas conocidas, y la dirección del pool es una entrada conocida. Esta prueba es una prueba de selección aleatoria del pool global en el pool actual. La prueba contiene un compromiso con los saldos también. El contrato en la cadena recibirá esta prueba, la verificará y mantendrá los compromisos de manera que cuando finalmente se cierre el pool y los saldos se envíen desde el pool global a los propietarios de los boletos de rifa, puedan verificar que las cantidades de tokens no se modificaron desde la selección aleatoria al principio del pool.

Cuando un usuario compra una “apertura” de los rangos de saldo de tokens ocultos, el programa ZK toma los saldos reales de tokens como entradas privadas y produce un rango de valores que se comprometen junto con la prueba. Una entrada pública de este programa ZK es la prueba de creación de pool previamente comprometida y sus salidas. De esta manera, se verifica todo el sistema. La prueba anterior debe validarse en la prueba de rango, y los saldos de tokens deben hash a la misma valor comprometido en la primera prueba. La prueba de rango también se compromete a la cadena y, como se dijo anteriormente, hace que el rango sea visible para todos los participantes.

Si bien hay muchas formas de lograr este tipo de sistema de boletos de rifa, las propiedades de Bonsol hacen que sea bastante fácil tener muy poca confianza en la entidad que organiza la rifa. También destaca la interoperabilidad de Solana y el sistema VC. El programa Solana (contrato inteligente) juega un papel crucial en intermediar esa confianza porque verifica las pruebas y luego permite que el programa tome la siguiente acción.

Escenario dos

Bonsol permite a los desarrolladores crear una primitiva que es utilizada por otros sistemas. Bonsol contiene la noción de despliegues, donde un desarrollador puede crear algún programa ZK y desplegarlo a los operadores de Bonsol. Los operadores de la red de Bonsol actualmente tienen algunas formas básicas de evaluar si una solicitud de ejecución para uno de los programas ZK será económicamente ventajosa. Pueden ver información básica sobre cuánto cálculo tomará el programa ZK, los tamaños de entrada y la propina que ofrece el solicitante. Un desarrollador puede desplegar una primitiva que creen que muchas otras Dapps querrán utilizar.

En la configuración de un programa ZK, el desarrollador especifica el orden y el tipo de entradas requeridas. El desarrollador puede lanzar un InputSet que preconfigura algunas o todas las entradas. Esto significa que pueden configurar algunas de las entradas de manera que puedan crear primitivas que ayuden a los usuarios a verificar cálculos sobre conjuntos de datos muy grandes.

Por ejemplo, supongamos que un desarrollador crea un sistema que, dado un NFT, puede demostrar en cadena la transferencia de propiedad incluyó un conjunto específico de billeteras. El desarrollador puede tener un conjunto de entrada preconfigurado que contiene un montón de información de transacciones históricas. El programa ZK busca a través del conjunto para encontrar a los propietarios coincidentes. Este es un ejemplo artificial y se puede hacer de muchas maneras.

Consideremos otro ejemplo: un desarrollador puede escribir un programa ZK que puede verificar que una firma de par de claves proviene de un par de claves o conjunto jerárquico de pares de claves sin revelar las claves públicas de esos pares de claves autoritativos. Digamos que esto es útil para muchas otras Dapps y que utilizan este programa ZK. El protocolo brinda al autor de este programa ZK una pequeña propina por el uso. Dado que el rendimiento es crítico, los desarrolladores tienen incentivos para hacer que sus programas sean rápidos para que los operadores quieran ejecutarlos, y los desarrolladores que intenten copiar el trabajo de otro desarrollador necesitarán cambiar el programa de alguna manera para poder implementarlo, ya que hay una validación del contenido del programa ZK. Cualquier operación agregada al programa ZK afectará el rendimiento, y si bien definitivamente no es infalible, esto puede ayudar a garantizar que los desarrolladores sean recompensados por la innovación.

Arquitectura Bonsol

Estos casos de uso ayudan a describir para qué es útil Bonsol, pero echemos un vistazo a su arquitectura actual, su modelo de incentivos actual y su flujo de ejecución.

La imagen de arriba describe un flujo desde un usuario que necesita realizar algún tipo de cómputo verificable, esto suele ser a través de una dapp que necesita que el usuario realice alguna acción. Esto tomará la forma de una Solicitud de Ejecución que contiene información sobre el programa ZK que se está ejecutando, las entradas o conjuntos de entradas, el tiempo en el cual se debe demostrar el cómputo y la propina (que es cómo los Relays se pagan). Los relés recogen la solicitud y deben competir para decidir si desean reclamar esta ejecución y comenzar a demostrar. Según las capacidades específicas de los operadores de relés, pueden optar por rechazar esto porque la propina no lo vale o el zkprogram o las entradas son demasiado grandes. Si deciden que desean realizar este cálculo, deben ejecutar un reclamo sobre él. Si son los primeros en obtener el reclamo, entonces su prueba será aceptada hasta cierto tiempo. Si no logran producir la prueba a tiempo, otros nodos pueden reclamar la ejecución. Para reclamar, el Relé debe apostar una cierta cantidad, actualmente codificada en la mitad de la propina, que será reducida si no logran producir una prueba correcta.

Bonsol se construyó con la tesis de que más cómputo se trasladará a una capa donde se atestigua y verifica en la cadena, y que Solana será una cadena "predeterminada" para VC y ZK pronto. Las transacciones rápidas de Solana, el cómputo barato y la creciente base de usuarios la convierten en un lugar excelente para probar estas ideas.

¿Fue fácil construir esto? ¡Diablos no!

Esto no quiere decir que no hubiera desafíos para construir Bonsol. Para llevar la prueba Risco0 y verificarla en Solana, necesitamos hacerla más pequeña. Pero no podemos hacerlo sin sacrificar las propiedades de seguridad de la prueba. Por lo tanto, usamos Circom y envolvemos el Risc0 Stark que puede estar en ~200kb y lo envolvemos en una prueba Groth16 que siempre termina siendo de 256 bytes. Afortunadamente, Risc0 proporcionó algunas herramientas incipientes para esto, pero agrega mucha sobrecarga y dependencias al sistema.

A medida que comenzamos a construir Bonsol y a usar las herramientas existentes para envolver a los Stark con el Snark, buscamos formas de reducir las dependencias y aumentar la velocidad. Circom permite la compilación del código Circom en C++ o wasm. Primero intentamos compilar el circuito Circom en un archivo wasmu producido por el LLVM. Esta es la forma más rápida y eficiente de hacer que las herramientas Groth16 sean portátiles y rápidas. Elegimos wasm debido a su portabilidad, ya que el código C++ dependía de la arquitectura de la CPU x86, lo que significa que los nuevos Macbooks o servidores basados en Arm no podrán usarlo. Pero esto se convirtió en un callejón sin salida para nosotros en la línea de tiempo con la que teníamos que trabajar. Debido a que la mayoría de nuestros experimentos de investigación de productos tienen un límite de tiempo hasta que demuestren su valor, tuvimos de 2 a 4 semanas de tiempo de desarrollo para probar esta idea. El compilador llvm wasm simplemente no podía manejar el código wasm generado. Con más trabajo, podríamos haber superado esto, pero probamos muchas banderas de optimización y formas de hacer que el compilador llvm funcionara como un complemento wasmer para precompilar este código en llvm, pero no tuvimos éxito. Debido a que el circuito Circom tiene alrededor de 1,5 millones de líneas de código, puede imaginar que la cantidad de Wasm se volvió enorme. A continuación, nos centramos en intentar crear un puente entre C++ y nuestra base de código de retransmisión Rust. Esto también sufrió una rápida derrota, ya que C++ contenía un código ensamblador específico de x86 con el que no queríamos jugar. Con el fin de llevar el sistema al público, terminamos simplemente arrancando el sistema de una manera que hace uso del código C++ pero elimina algunas de las dependencias. En el futuro, nos gustaría ampliar otra línea de optimización en la que estábamos trabajando. Eso fue para tomar el código C++ y compilarlo en un gráfico de ejecución. Estos artefactos de C++ de la compilación Circom son en su mayoría aritmética modular sobre un campos finitoscon un número primo muy grande como generador. Esto mostró algunos resultados prometedores para artefactos de C++ más pequeños y simples, pero se necesita más trabajo para hacer que funcione con el sistema Risc0. Esto se debe a que el código C++ generado tiene alrededor de 7 millones de líneas de código, y el generador de gráficos parece alcanzar los límites del tamaño de la pila, y aumentarlos parece producir otras fallas que no hemos tenido tiempo de determinar. Aunque algunas de estas vías no dieron resultado, pudimos hacer contribuciones a proyectos OSS y esperamos que en algún momento esas contribuciones se incorporen al proyecto principal.

El próximo conjunto de desafíos es más en el espacio de diseño. Una parte esencial de este sistema es poder tener entradas privadas. Esas entradas deben provenir de algún lugar, y debido a limitaciones de tiempo, no pudimos agregar un sistema de encriptación MPC elegante para permitir que las entradas privadas estén en el sistema en un bucle cerrado. Entonces, para abordar esta necesidad y desbloquear a los desarrolladores, agregamos la noción de un servidor de entrada privada que debe validar al solicitante, que es validado por una firma de una carga útil, y servírselo. A medida que extendemos Bonsol, planeamos implementar un sistema de desencriptación de umbral MPC mediante el cual los nodos de retransmisión pueden permitir que el reclamante desencripte las entradas privadas. Toda esta discusión sobre entradas privadas nos lleva a una evolución de diseño que planeamos poner a disposición en el repositorio de Bonsol. Eso es Bonsolace, que es un sistema más simple que le permite como desarrollador demostrar fácilmente estos programas zk en su propia infraestructura. En lugar de externalizar a la red probadora, puede demostrarlo usted mismo y verificarlo en el mismo contrato que usa la red probadora. Este caso de uso es para casos de uso de datos privados de alto valor donde el acceso a los datos privados debe minimizarse a toda costa.

Una última nota sobre Bonsol que no hemos visto en otros lugares que utilizan Risc0 es que forzamos un compromiso (hash) sobre los datos de entrada en el programa zk. Y realmente verificamos en el contrato que las entradas a las que el probador tuvo que comprometerse coincidan con lo que el usuario esperaba y envió al sistema. Esto conlleva cierto costo, pero sin él significa que el probador podría hacer trampa y ejecutar el programa zk sobre entradas que el usuario no especificó. El resto del desarrollo de Bonsol se ajustó al desarrollo normal de Solana, pero debe destacarse que intencionalmente probamos algunas ideas nuevas allí. En el contrato inteligente estamos utilizando flatbuffers como el único sistema de serialización. Esta es una técnica algo novedosa que nos gustaría ver desarrollada y convertida en un marco de trabajo porque se presta muy bien para la generación automática de SDK que son multiplataforma. Una última nota sobre Bonsol es que actualmente necesita una precompilación para funcionar de manera más eficiente, esta precompilación está programada para llegar en Solana 1.18, pero hasta entonces estamos trabajando para ver si los equipos están interesados en esta investigación y mirando más allá de Bonsol hacia otras tecnologías.

Concluyendo

Más allá de Bonsol, el equipo de construcción de Anagram está investigando profundamente en muchos lugares dentro del dominio de VC. Proyectos como Jolt, zkllvm, spartan 2, Binius son proyectos que estamos siguiendo, junto con empresas que trabajan en el espacio de Encriptación Homomórfica Total (FHE), si no sabes qué es eso, mantente atento ya que lo cubriremos en algún momento.

Por favor, revisa el repositorio Bonsol y crea un problema para los ejemplos que necesitas o cómo quieres ampliarlo. Es un proyecto muy temprano y tienes la oportunidad de dejar tu huella.

Si estás trabajando en proyectos interesantes de VC, te animamos a que lo hagasaplica aquí para el programa Anagram EIRdonde junto al equipo de Anagram podrás probar tu tesis, construir una empresa y abordar los problemas más grandes posibles. Siéntete libre de contribuir o hacer cualquier pregunta.

Descargo de responsabilidad：

1. Este artículo es una reimpresión de [Anagrama], Todos los derechos de autor pertenecen al autor original [austbot]. Si hay objeciones a esta reimpresión, por favor contacte al Gate Learnequipo y lo resolverán rápidamente.

2. Descargo de responsabilidad: Las opiniones expresadas en este artículo son únicamente las del autor y no constituyen consejos 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.