Desarrolladores

Rand es de código abierto. El nodo completo, el explorador, el puente, la investigación sobre pruebas y los clientes de wallet viven cada uno en su propio repositorio en GitHub. Lea el código, ejecute las pruebas, envíe parches. Esta página es el mapa: dónde vive cada componente, con qué está construido, hasta dónde ha llegado el sistema de pruebas y dónde se detiene hoy.

Repositorios

La pila

Rust de extremo a extremo. Rand es su propia cadena: un nodo HotStuff BFT con una capa de difusión gossip libp2p, un pool de notas totalmente blindado como libro mayor, firmas y cifrado de notas poscuánticos, y el zkVM de Rand para la computación confidencial, todo en el repositorio fullnode. El sistema de pruebas en sí es la parte bajo investigación activa, más abajo.

Una relación para todos los programas

La relación de ejecución universal R_exec del whitepaper existe como código: rand_zkvm, una máquina RV32IM probada bajo un único STARK por lotes sobre Plonky3 en el cuerpo Goldilocks. Demuestra que alguna traza ejecutó el programa hc hasta estas salidas públicas sobre entradas comprometidas mediante un H_IN con sal, y nada acerca del programa es jamás un parámetro del verificador. Publicar un programa confidencial significa registrar un hash, nunca generar un circuito a medida.

El sistema de pruebas es transparente, sin configuración de confianza (trusted setup) ni curva de emparejamiento, y su supuesto es una función hash resistente a colisiones. Se espera que todo otro componente que toque pruebas converja en este crate en lugar de desarrollar el suyo propio. El crate vive en zkp-circuits/research y está incorporado (vendored) en el nodo completo en el conjunto de restricciones 8 (circuits aeacf31, fullnode v0.6.7 y v0.6.8). Las tablas y mediciones siguientes describen el conjunto de restricciones 5 (hito M4.2) salvo que una línea nombre un conjunto posterior; están tomadas de docs/zkvm.md, docs/zkvm-milestones.md y docs/confidential.md del nodo completo a fecha de 2026-09-13, y las mediciones se citan tal como se midieron en un portátil Apple Silicon, no como objetivos.

Ocho tablas en buses con nombre, una novena bajo demanda

Un compromiso, una apertura FRI. Las tablas nunca se llaman entre sí; intercambian hechos a través de buses LogUp con nombre (PROGRAM, PROGRAM_WORD, MEMORY, ALU, POSEIDON2, INPUT_DIGEST, INPUT_READ, KECCAK y las consultas de rango y de nibble) y el verificador comprueba que cada bus se equilibra globalmente. El grado máximo de restricción de cada tabla está fijado por una prueba bajo el tope de 8 que permite el factor de expansión (blowup) de FRI.

Desde entonces han llegado tres conjuntos de restricciones. El conjunto 6 añadió una tabla public obligatoria para la entrada pública de un programa en el momento del despliegue, vinculada al digest sin sal H_PUB, y una tabla opcional sha256 junto a keccak. El conjunto 7 (chain 16) ciega cada terminal LogUp en un nuevo bus BLIND y fija un suelo de 2⁷ filas en cada tabla declarada, y añade la llamada al sistema POSEIDON2_LEN, acotada por longitud. El conjunto 8 (chain 18) añade una columna GAS a la tabla cpu y un valor público, el GAS_LIMIT declarado.

Qué revela una prueba

Público: el hash de código hc (ocho palabras de digest en el circuito), el compromiso de entrada con sal H_IN (ocho palabras), el nivel de gas y ocho palabras de salida. Desde el conjunto de restricciones 6 también H_PUB, el digest de la entrada pública, y desde el conjunto de restricciones 8 el límite de gas declarado. La cabecera de la prueba declara las alturas de las tablas Keccak y SHA-256, de modo que muestra si una llamada calculó hashes y, por encima del suelo de 2⁷, aproximadamente cuántos.

Oculto: las entradas privadas (H_IN lleva sal, por lo que es tan ocultante como vinculante); cada palabra de instrucción, porque el verificador comprueba hc y nunca el programa; cada valor de registro y de memoria; cada bifurcación tomada; el recuento exacto de ciclos y el gas exacto usado; y qué llamadas al sistema se ejecutaron, salvo lo que muestran las alturas de las dos tablas de hash.

El nivel es público en cada prueba porque el tamaño de un STARK ya revela la altura de su traza; ocultar el índice no aportaría nada. hc es vinculante, no ocultante: véase dónde se detiene hoy.

Medido, en el conjunto de restricciones 5

Portátil Apple Silicon, compilación release. La división de tablas de bytes de M2.3 fue lo que redujo el tiempo de prueba; el perfil de 80 consultas fue lo que volvió a aumentar el tamaño de la prueba. La clave del verificador es independiente del contenido del programa, indexada por nivel y por las alturas de programa, entrada y keccak declaradas en la prueba, de modo que un nodo calienta una sola clave y la reutiliza.

Los conjuntos posteriores movieron los tamaños. Bajo el constraint set 7, una prueba de tier 10 ocupa 1.367.688 bytes en el perfil de producción, y una prueba de tier 10 que incluye Keccak ocupa 3.283.898 (medido el 2026-09-28). Desde la chain 17, una transferencia lleva dos pruebas: la prueba del bundle de tier 14, de aproximadamente 1,49 MB, y la prueba de autorización de tier 10, de aproximadamente 1,37 MB y unos 7 s de tiempo de prueba. El genesis de la chain 20 fija un bloque de 20 MiB y un límite de prueba de 4 MiB, y una llamada no puede superar el tier 14.

Tres destinos, un circuito

Solo RISC-V se ejecuta de forma nativa. Los programas de Solidity y de Solana se ejecutan en un guest intérprete dentro de la misma relación, con su bytecode como entrada, o bien se traducen fuera de la cadena a programas RISC-V cuyas salidas coinciden con las del intérprete palabra por palabra. Los opcodes costosos requieren tablas de coprocesador dedicadas en lugar de una simulación bit a bit.

Hitos

El hito 1 demostró la máquina de propósito general. El hito 3 la convirtió en un pool protegido: una transferencia con pertenencia dentro del circuito se prueba bajo R_exec, y el verifier comprueba hc sin ver nunca una palabra del programa. El hito 4 es la compatibilidad: su loader, el compromiso de entrada y la tabla de Keccak se publicaron como los constraint sets 4 y 5, y la tabla de SHA-256 con el set 6. Los guests intérpretes de EVM y sBPF, la toolchain rand-guest y los dos traductores están construidos. La transferencia ERC-20 se ha probado, en una máquina de 128 GB; la prueba de SPL Token, en el tier 20, no. El hito 5 es la VM de recursión que sustenta la agregación de bloques, que está construida y desactivada en todas las cadenas. Los constraint sets 7 y 8 siguieron a las revisiones de septiembre y al modelo de gas.

Fases del pool protegido

El libro mayor del fullnode se incorporó en tres fases, cada una un hard fork (docs/shielded.md §7). S1 sustituyó el libro mayor de cuentas por un pool de notas; S3 devolvió el bridge como notas y se incorporó primero; S2 añadió el staking encima. Las tres están en main y en la cadena actual.

Cada fila bajo S2 es una bifurcación dura (hard fork) del trabajo v0.5. Se tomaron juntas como una única cadena nueva, la cadena 14, cortada el 2026-09-20 a partir de la compilación b3c594c y etiquetada v0.5 ese mismo día tras un viaje de ida y vuelta de zUSD en vivo a través de los endpoints de origen desplegados. La cadena 15, activa desde el 2026-09-26 con v0.5.8 y posteriores, incorporó todo ello, con las correcciones de las auditorías v4 y v5 sujetas al génesis activadas: un faucet con lista de permitidos y presupuesto por época, activación diferida de bonos, un tope al peso del stake, registros ligados al génesis, consensus_domain 1, las reglas de bridge v2 y el tope del registro de tokens, comisión de registro quemada y cota de 2⁶³ para las notas. La cadena 20, activa desde el 2026-10-01 06:17 UTC con v0.6.8 (c9c9bd3c), una bifurcación dura (hard fork) de la cadena 19, conserva todo ello y añade el trabajo de las versiones v0.6, enumerado a continuación.

Versiones desde v0.5

Cada versión es una etiqueta de git con una entrada en el CHANGELOG.md del fullnode. Una versión que cambia el consenso, el formato de red o una clave del verificador se publica con una cadena nueva; las demás se despliegan sobre la cadena en vivo nodo por nodo.

Dónde se detiene hoy

Desviaciones respecto del whitepaper, expuestas en lugar de suavizadas. Cada una se registra en la documentación propia del crate, junto con el hito que la cierra.

• hc es vinculante pero no ocultante: no lleva sal, de modo que un programa adivinado puede confirmarse y dos despliegues del mismo programa son enlazables. Lo que M3.4 eliminó es que el verificador conserve el programa completo en claro.
• Una wallet compilada antes del 2026-09-21 pide testigos a su nodo, y una solicitud de testigo nombra la hoja que está a punto de gastarse. Un rand actual conserva su propia copia del árbol y nunca los pide; el nodo sigue sirviendo rand_getWitness para las wallets más antiguas.
• Los depósitos son públicos en la frontera: una emisión del faucet, una nota de génesis y un depósito del puente llevan su importe en claro (desde la chain 14, una emisión y una nota de génesis llevan además su apertura, de modo que la clave del propietario también es pública), la misma visibilidad de un salto que tiene en cualquier parte un depósito de transparente a blindado.
• El conocimiento cero es estadístico, no perfecto. Esa es la propiedad que realmente ofrece el FRI ocultante de Plonky3 0.7, y el crate lo dice.
• El hash de la transcripción es Poseidon2 con constantes de ronda de desarrollo, no el SHA3-384 / BLAKE3-384 de los papers. Un cambio de configuración, no una reescritura.
• Con 80 consultas FRI, una prueba de bundle ocupaba unos 1,42 MB en las chains 14 y 15 (unos 1,3 MB hasta la chain 13). Desde la chain 17 una transferencia lleva unos 2,85 MB de prueba: la prueba del bundle, de unos 1,49 MB, y la prueba de autorización, de unos 1,37 MB. En una chain por defecto, con bloques de 4 MiB y un tope de prueba de 2 MiB, una prueba que contiene Keccak supera el tope de prueba sin remedio; el génesis de la chain 20 fija bloques de 20 MiB y un tope de prueba de 4 MiB (las chains 13 a 16 fijan 8 MiB).
• La cabecera de una prueba de llamada no está oculta. Declara el nivel y las alturas de las tablas de Keccak y SHA-256, de modo que muestra si una llamada calculó un hash. Las llamadas confirmadas en la chain 15 antes del mínimo del prover de v0.6 exponían más: una tabla privada de menos de 2⁷ filas podía leerse a partir de la prueba. El mínimo del prover de v0.6 lo cerró para las llamadas nuevas, y el conjunto de restricciones 7 con hardening_v6 lo convirtió en regla de la chain desde la chain 16 en adelante.
• Una llamada tiene un tope de nivel 14, con a lo sumo 2¹² filas de Keccak (128 permutaciones) y 2¹³ filas de SHA-256 (128 compresiones), y bajo hardening_v6 no puede desplegarse un programa de más de 8180 palabras. Los guests intérpretes de EVM y sBPF y las imágenes traducidas de ERC-20 y SPL Token superan todos ese límite.
• Quien posee el testigo lo ve todo. ZK protege la vista del verificador, no la del prover. Desde la chain 17 una wallet puede entregar la prueba del bundle a un rand-prover emparejado sin entregar la clave de gasto, pero ese prover sigue teniendo la clave de visualización y ve las notas. El backend CUDA se ejecutó por primera vez en hardware el 2026-09-28 y aún no tiene ninguna medición en producción.

Estructura del repositorio

El workspace de Cargo del fullnode, tal como figura en su README y en su directorio crates/.

Especificado, aún no entregado

Estos componentes se describen en los papers o en la documentación del fullnode, pero no están en funcionamiento: o bien no figuran en los repositorios, o bien están construidos y activados en ninguna chain. Se enumeran para que la brecha entre la especificación y el código sea legible y no deba inferirse.

Compilar y probar

Flujo de trabajo estándar de Rust en cada repositorio. El fullnode es un único workspace de Cargo con un toolchain fijado y una suite de pruebas de clúster que inicia nodos reales sobre TCP. Su compilación requiere que el repositorio circuits esté clonado junto a él, en un directorio llamado circuits, en el commit desde el que se sincronizaron los crates incluidos (aeacf31 para v0.6.7 y v0.6.8). El zkVM es un crate independiente en zkp-circuits con su propio toolchain fijado y una demostración que narra qué revela una llamada confidencial y qué no.

El fullnode:

git clone https://github.com/randprotocol/fullnode.git
git clone https://github.com/randprotocol/zkp-circuits.git circuits   # the sibling directory must be named circuits
git -C circuits checkout "$(sed -n 's/^circuits: //p' fullnode/crates/randprotocol-zkvm/guests-compiled/PROVENANCE.md)"
cd fullnode

# Rust 1.98.1 is pinned by rust-toolchain.toml; first build pulls RocksDB and Plonky3, 10 to 20 minutes
cargo build --release        # target/release/rand-node, target/release/rand, target/release/rand-prover

# All crates; release because STARK proving is slow in debug. One to two hours, mostly proving
cargo test --release

# One machine, two validators
scripts/local-testnet.sh
target/release/rand --rpc http://127.0.0.1:8545 status

El zkVM de investigación, en zkp-circuits/research:

# Toolchain is pinned by rust-toolchain.toml; the first build pulls Plonky3
cargo build --release

# Narrated demo: thirteen proofs, one at production FRI parameters (~6-7 min)
cargo run --release

# Emulator, per-table constraints, cheating provers, ZK, end-to-end, viewing keys, compiled guests (395 tests, ~17 min)
cargo test

La suite del fullnode, medida en v0.6.1 en una máquina de 16 vCPU: core 521 pruebas, node 373, client 117, la suite de prover tramposo 116, los engaños de paquetes ocultos 21 (75 min), el flujo de la wallet 6 (53 min), el clúster 26 (44 min) y la puerta de extremo a extremo de zUSD 2 (51 min). Las pruebas de producción de la VM de recursión quedan fuera y requieren la memoria indicada más arriba.

Running a node explica cómo unirse al testnet público con la compilación; el génesis del testnet, los pares de arranque y los scripts de ejecución se incluyen en el directorio deploy/ del fullnode, y la página de descarga tiene la versión corta.

Contribuir

El fullnode está licenciado bajo la GNU General Public License v3.0 (GPL-3.0-only); antes era Apache-2.0. Abra issues para errores y propuestas de diseño en el repositorio que toque el cambio. Los pull requests son bienvenidos: ejecute cargo fmt && cargo clippy antes de enviar y mantenga los cambios acotados. Los issues del fullnode son el lugar para empezar.

La arquitectura, el circuito de privacidad, la prueba del token de comisión y el compromiso de la seguridad poscuántica están documentados en el whitepaper de la página de papers. El directorio docs/ del propio repositorio del fullnode es la fuente contra la que se verifica cada página de esta documentación.