Esta página recoge la justificación de cada decisión de diseño importante de Rand: la propiedad que debe ofrecer un componente, el supuesto bajo el cual la ofrece y el coste que se acepta a cambio. Se compiló el 29 de septiembre de 2026 a partir de este sitio, del resumen del whitepaper y del nodo completo de referencia (github.com/randprotocol/fullnode: su README, docs/ y docs/superpowers/specs/). Cada respuesta cita el documento en el que se enuncia la justificación; las rutas se refieren al repositorio fullnode, salvo que comiencen por randprotocol.org.
Estado. Rand funciona sobre una testnet operada por el equipo fundador, y el protocolo no ha sido auditado de forma independiente. Varias de las decisiones siguientes se implementan por etapas a lo largo de los cortes de la cadena. Todas las cifras son mediciones del nodo en ejecución en el momento de la compilación; se espera que cambien y deben volver a medirse antes de citarse.
Primitivas criptográficas
1. ¿Por qué ML-KEM-768 (Kyber) para el cifrado de notas?
El texto en claro de una nota se cifra para su destinatario en un sobre que permanece indefinidamente en el libro mayor público. Por lo tanto, su confidencialidad es una propiedad irrevocable (pregunta 8): un adversario que obtenga en cualquier momento posterior un ordenador cuántico criptográficamente relevante podría descifrar todos los sobres históricos sellados con un KEM de curva elíptica, puesto que el algoritmo de Shor resuelve el logaritmo discreto en tiempo polinómico. ML-KEM está estandarizado en NIST FIPS 203 y su seguridad se reduce a Module-LWE, problema para el que no se conoce ningún algoritmo cuántico eficiente. El conjunto de parámetros 768 (categoría 3 de NIST) se eligió como compromiso entre el margen de seguridad y la clave de encapsulación de 1.184 bytes que debe llevar cada dirección. El sobre es ML-KEM-768 combinado con ChaCha20-Poly1305: 1.348 bytes, o 1.860 bytes con el campo de memo fijo.
Fuente: randprotocol.org (sección poscuántica); README de fullnode; docs/shielded.md §2
2. ¿Por qué compromisos Poseidon2 y no Pedersen?
Los compromisos de Pedersen son perfectamente ocultadores, pero solo computacionalmente vinculantes, y su carácter vinculante se reduce al supuesto del logaritmo discreto, que un adversario cuántico rompe; un adversario capaz de calcular logaritmos discretos puede abrir un compromiso a un valor distinto. Dado que un compromiso publicado hoy debe seguir siendo sólido y ocultador durante toda la vida del libro mayor, el esquema debe apoyarse en supuestos que se creen válidos frente a adversarios cuánticos, lo que en la práctica significa una función hash. Poseidon2 es un hash orientado a la aritmetización definido sobre el cuerpo Goldilocks, de modo que evaluarlo dentro del STARK cuesta pocas restricciones. El mismo hash instancia el compromiso de la nota, el árbol de Merkle de profundidad 32 y el nullifier.
Fuente: randprotocol.org (sección poscuántica); docs/shielded.md §1–2
3. ¿Por qué dos funciones hash: BLAKE3 y Poseidon2?
Las dos funciones están optimizadas para modelos de coste distintos. Poseidon2 se usa siempre que un hash debe evaluarse dentro de una prueba —notas, el árbol de compromisos, nullifiers y las tablas internas de la zkVM— porque su coste se mide en restricciones. BLAKE3 se usa siempre que no interviene ninguna prueba y domina el rendimiento nativo: hashes de bloque, la raíz de estado sobre el árbol, el conjunto de nullifiers, el registro de validadores y la tabla de programas, y las direcciones de los validadores (el resumen BLAKE3 de la clave pública). Poseidon2 es comparativamente lento en una CPU; BLAKE3 es comparativamente costoso de aritmetizar. Cada una se usa solo donde se aplica su modelo de coste.
Fuente: README de fullnode (fila de firmas / hashes); docs/architecture.md
4. ¿Por qué Dilithium2 (ML-DSA) para las firmas de los validadores?
Las firmas de consenso aportan una propiedad renovable (pregunta 8): una ruptura posterior del esquema permite falsificar mensajes futuros, pero no invalida retroactivamente los bloques ya finalizados, de modo que el esquema podría, en principio, sustituirse antes de que exista un adversario cuántico. No obstante, se adoptó un esquema basado en retículos desde el génesis para que los votos de consenso, las cofirmas de los guardianes del puente y el registro de validadores compartan un único tipo de clave poscuántica. El nodo implementa el conjunto de parámetros Dilithium2 de la ronda 3 (el crate crystals-dilithium), que difiere del ML-DSA-44 final de FIPS 204; las claves públicas ocupan 1.312 bytes y las firmas 2.420 bytes.
Fuente: docs/superpowers/specs/2026-09-19-pq-cosignature-bridge.md §2; randprotocol.org
5. ¿Por qué un STARK transparente (FRI sobre Goldilocks) y no un SNARK?
La elección se deriva de tres requisitos. Primero, ausencia de configuración de confianza (trusted setup): la solidez descansa únicamente en la resistencia a colisiones de una función hash, no en una cadena de referencia estructurada ni en una curva compatible con emparejamientos. Segundo, solidez poscuántica plausible: el argumento no hace ningún supuesto de logaritmo discreto ni de emparejamientos. Tercero, compatibilidad con el esquema de compromisos basado en hashes de la pregunta 2. El coste es el tamaño de la prueba: una prueba de bundle ocupa aproximadamente 1,3 MB, de 300 a 600 veces el tamaño de una transacción protegida de Zcash o Monero. Este coste se aceptó y se aborda por separado mediante la agregación a nivel de bloque (preguntas 31 y 34).
Fuente: randprotocol.org; docs/block-space.md §1; docs/zkvm.md
6. ¿Por qué el perfil FRI de 80 consultas en lugar del de 27?
El perfil de producción (80 consultas, factor de expansión 8, 20 bits de prueba de trabajo de grinding) ofrece aproximadamente 86 bits de solidez demostrable, frente a unos 42 bits del perfil de 27 consultas, con 2,75 veces el tamaño de la prueba. El tiempo de verificación apenas cambia: de 809 ms a 838 ms en frío, y aproximadamente 16 ms en caliente. Se dio prioridad a la solidez demostrable sobre el tamaño de la prueba, y el coste en tamaño se trasladó al diseño de espacio de bloque y de agregación.
Fuente: docs/block-space.md §1, §3
7. ¿Por qué la afirmación poscuántica se formula por primitiva y no como «128 bits en todo el protocolo»?
Los borradores anteriores afirmaban una seguridad poscuántica de 128 bits para el protocolo en su conjunto. Esa afirmación es incompatible con la cota de Brassard–Høyer–Tapp, según la cual un adversario cuántico encuentra colisiones en un hash de 256 bits en unas 2^85 consultas, por lo que se retiró en lugar de matizarse. El artículo enuncia ahora la seguridad por primitiva y por función —un hash de transcripción de 384 bits, hashes de 256 bits usados solo donde se exige resistencia a preimagen, Dilithium2, ML-KEM-768 y FRI sobre un cuerpo de extensión— bajo los supuestos Module-LWE y Module-SIS, con las funciones hash modeladas como oráculos aleatorios cuánticos. El hash de transcripción del nodo es actualmente Poseidon2; la documentación lo recoge como una brecha de configuración abierta.
Fuente: randprotocol.org (sección poscuántica)
8. ¿Qué es la clasificación «irrevocable frente a renovable» y por qué condiciona las decisiones?
Una propiedad de seguridad es irrevocable si un adversario que adquiere una nueva capacidad en cualquier momento futuro puede vulnerarla retroactivamente para datos ya publicados; la confidencialidad de las notas y el carácter ocultador de los compromisos son de este tipo, por lo que deben ser resistentes a ataques cuánticos en el momento de la publicación. Una propiedad es renovable si se restablece en cada uso, de modo que un esquema puede sustituirse antes de que la amenaza se materialice; las firmas y la solidez de las pruebas son de este tipo. Cada elección de primitiva de esta sección se deriva de clasificar la propiedad que protege.
Fuente: randprotocol.org (sección poscuántica)
El pool protegido
9. ¿Por qué un modelo de notas/UTXO, sin cuentas ni saldos?
Un libro mayor basado en cuentas publica los saldos por construcción; ocultarlos exige cifrar el estado y demostrar enunciados sobre los textos cifrados, lo cual es sustancialmente más caro. Un pool de notas almacena solo compromisos y nullifiers, ninguno de los cuales revela un propietario ni un importe, de modo que el estado público no contiene información de saldos. La única excepción es el registro de validadores, cuyos pesos de stake deben ser públicos para que las réplicas concuerden en la composición del quórum (pregunta 29).
Fuente: docs/shielded.md §1–2; docs/staking.md §1
10. ¿Por qué la dirección ocupa ~1,6 KB?
Una dirección protegida consta del campo de propietario pk de 32 bytes y de la clave de encapsulación ML-KEM-768 de 1.184 bytes que el remitente necesita para sellar el sobre; codificada en base58, resultan aproximadamente 1.667 caracteres. La longitud es consecuencia directa del KEM poscuántico. Un diseño aprobado (direcciones protegidas cortas, 2026-09-17) sustituye la dirección por un identificador de receptor de unos 256 bits que se resuelve en un registro actualizable, firmado con la clave de gasto y servido por el explorador, de modo que la clave de encapsulación se obtiene en lugar de transcribirse.
Fuente: docs/shielded.md §1; docs/superpowers/specs/2026-09-17-short-shielded-address.md
11. ¿Por qué se deriva toda clave de una única clave de gasto de 256 bits?
Todo el resto del material de claves es una función determinista de un único secreto sk: la clave de visualización nk = H(NK, sk), el campo de propietario pk = H(PK, nk), el nullifier H(NF, nk, cm), la clave de visualización saliente y la clave de desencapsulación de ML-KEM, cada una con su propio separador de dominio. Por lo tanto, el archivo de claves almacena solo sk, una copia de seguridad es un único valor, y volver a escanear el árbol desde la hoja 0 recupera todas las notas. Como no existe una segunda copia desde la que recuperar, la wallet se niega a sobrescribir un archivo de claves existente.
Fuente: docs/shielded.md §1
12. ¿Por qué un bundle de forma fija de 4 entradas y 4 salidas?
Una forma fija hace que todos los bundles tengan el mismo tamaño y la misma estructura, con independencia de lo que muevan. Cada bundle publica exactamente cuatro nullifiers y cuatro compromisos; las ranuras no utilizadas son notas ficticias de valor cero, y la salida de cambio se publica incluso cuando su valor es cero, ya que la ausencia de una salida de cambio distinguiría la transacción. La especificación original era de 2 entradas y 2 salidas, siguiendo a Sapling. Se amplió a 4 entradas y 4 salidas con el bundle de activo oculto, de modo que las ranuras 0–1 transportan un activo privado y las ranuras 2–3 transportan RAND para la comisión; cuatro ranuras en lugar de tres permiten que una transferencia de tokens financie su comisión con hasta dos notas de RAND.
Fuente: docs/shielded.md §2; docs/superpowers/specs/2026-09-19-hidden-asset-bundle-design.md §3
13. ¿Por qué una sola prueba mueve cualquier activo (RAND, zUSD, tokens RPL)?
Antes de la cadena 14, una transferencia de tokens llevaba dos paquetes, uno para la comisión en RAND y otro para el activo, lo que requería dos pruebas y revelaba a cualquier observador qué token se había movido. El programa invitado de activo oculto recibe el identificador del activo como entrada privada, de modo que una transferencia de zUSD es indistinguible de un pago en RAND. El programa invitado cabe en el nivel 14 (aproximadamente 100 s y 5,7 GB de memoria) solo porque lee sus entradas en un bucle y fusiona la comprobación de pertenencia al árbol de Merkle; una implementación completamente desenrollada requiere el nivel 16 (aproximadamente 400 s y 21 GB), lo que excede la memoria de una máquina de 16 GB.
Fuente: docs/superpowers/specs/2026-09-19-hidden-asset-bundle-design.md §1–3
14. ¿Por qué la comisión es pública y se paga al proponente?
Una comisión pública es coherente con el registro público de stake y hace que la admisión sea barata: un nodo puede comprobar el mínimo de comisión antes de realizar cualquier verificación. La prueba del paquete impone la ecuación de balance Σ entradas = Σ salidas + comisión + quema, de modo que la comisión se paga a partir de notas ocultas sin revelar cuáles. El coste aceptado es que el importe de la comisión puede revelar la clase de transacción (transferencia o llamada a un programa).
Fuente: docs/superpowers/specs/2026-09-11-shielded-pool-design.md (rulings table); docs/fees.md §1
15. ¿Por qué los depósitos (mint, bridge attest) tienen un importe público?
El valor que entra en el pool debe contabilizarse públicamente, y la atestación del puente es la evidencia pública de que se produjo un bloqueo correspondiente en la cadena de origen. La visibilidad resultante se limita al paso de entrada, análogo a una transacción de transparente a blindada (t-to-z) en Zcash; los gastos posteriores de la nota depositada permanecen ocultos.
Fuente: docs/superpowers/specs/2026-09-11-shielded-pool-design.md; docs/shielded.md (what is public table)
16. ¿Por qué el memo es un campo fijo de 512 bytes?
Un campo de longitud fija garantiza que el libro mayor no revele si hay un memo presente ni su longitud: en una cadena con memo habilitado, cada sobre que crea una nota, incluidos los señuelos y el cambio, ocupa exactamente 1.860 bytes. El memo viaja únicamente dentro del sobre cifrado, nunca en la nota, el compromiso ni la prueba, y solo pueden leerlo las partes que ya pueden descifrar la nota. Un memo mal formado se decodifica como un memo vacío, de modo que no puede volver irrecuperable la propia nota.
Fuente: docs/shielded.md §2; docs/superpowers/specs/2026-09-26-address-sharing-and-memo-design.md
17. ¿Por qué la generación de pruebas es local, y cómo evita el probador delegado romper esa propiedad?
La propia prueba es la autorización de gasto: un paquete no lleva firma ni campo de remitente, por lo que la clave de gasto nunca necesita salir de la wallet. La prueba de un paquete de nivel 14 requiere aproximadamente 5,7 GB de memoria, lo que excede lo que pueden ofrecer los teléfonos y los navegadores; de ahí el probador delegado. La autorización dividida (programa invitado de paquete v3, parámetro de génesis hc_auth) separa los dos papeles: el probador recibe únicamente la clave de visualización nk y produce la prueba del paquete, mientras que la wallet produce una pequeña prueba de autorización de nivel 10 usando sk. Un probador puede, por tanto, construir la prueba de un paquete, pero no puede autorizar un gasto (pregunta 36).
Fuente: docs/prover.md §1; docs/shielded.md (split authorisation); docs/superpowers/specs/2026-09-28-delegated-proving-design.md
18. ¿Por qué una ventana de anclas de 256 bloques?
Una prueba se construye contra una raíz concreta del árbol de compromisos (su ancla), y construir la prueba de un paquete de nivel 14 toma aproximadamente 100 s. El libro mayor debe, por tanto, aceptar anclas que tengan varios minutos de antigüedad en el momento del envío. La ventana era de 64 bloques en la especificación original y se amplió a 256 bloques al reducirse el intervalo entre bloques, manteniendo su duración en tiempo real por encima del tiempo de generación de la prueba.
Fuente: docs/shielded.md; docs/superpowers/specs/2026-09-11-shielded-pool-design.md
La zkVM y el cómputo confidencial
19. ¿Por qué RV32I como ISA del programa invitado (y no RV64)?
Una palabra de 32 bits se descompone exactamente en cuatro fragmentos de byte, y el primo de Goldilocks p = 2^64 − 2^32 + 1 es lo bastante grande como para que el producto de dos valores de 32 bits nunca desborde el cuerpo. RV64 duplicaría el número de columnas de fragmentos en las tablas de la ALU y de memoria. RISC-V es además un objetivo existente de los compiladores de uso general, de modo que los programas invitados son binarios compilados corrientes y no programas en un lenguaje diseñado a medida.
Fuente: docs/zkvm.md §2; research/docs/01-isa.md (‘Why RV32, not RV64’)
20. ¿Por qué Goldilocks y no un cuerpo de 256 bits?
Goldilocks es un primo de 64 bits cuya aritmética se traduce eficientemente en instrucciones nativas de CPU de 64 bits, y cuyo grupo multiplicativo tiene un subgrupo grande de orden potencia de dos, como exige FRI. Junto con las palabras de 32 bits, mantiene estrecha cada fila de la traza, lo que hace viable la generación de pruebas con el perfil de producción en un portátil. La solidez que se pierde al trabajar sobre un cuerpo pequeño se recupera extrayendo los desafíos de FRI de un cuerpo de extensión.
Fuente: docs/zkvm.md §2; randprotocol.org (performance section)
21. ¿Por qué niveles de gas en lugar de medir el gas por código de operación?
El gas por código de operación existe en Ethereum porque cada nodo reejecuta cada transacción y la duración de la ejecución no está acotada de antemano. En Rand ningún nodo ejecuta un programa: el remitente lo ejecuta una sola vez, fuera de la cadena, y los nodos verifican un único STARK cuyo coste de verificación depende solo del nivel, no del cómputo realizado. La terminación la impone el nivel, ya que una ejecución que no se detiene en 2^t ciclos no admite ninguna prueba en el nivel t. El precio es un mínimo fijo más una estimación de gas acotada por la cabecera, y la capacidad del bloque es un presupuesto de bytes. El gas aparece únicamente dentro de los programas invitados intérpretes de EVM y sBPF, como estado privado, donde es necesario para reproducir la semántica de la cadena de origen.
Fuente: docs/fees.md §3–4; docs/superpowers/specs/2026-09-28-gas-model-design.md
22. ¿Por qué la traza se divide en nueve tablas unidas por buses LogUp?
Una única tabla monolítica rellenaría cada fila hasta el ancho de la operación más ancha. Separar la traza en nueve tablas (CPU, memoria, ALU, rango, nibble, Poseidon2, programa, entrada y pública), cada una rellenada solo hasta su propia altura, mantiene pequeña la traza total. Los argumentos LogUp establecen las relaciones de multiconjunto entre las tablas. Las tablas de Keccak y SHA-256 son opcionales y solo se incluyen cuando el programa invitado invoca la llamada al sistema correspondiente.
Fuente: docs/zkvm.md §5
23. ¿Por qué una llamada a un programa publica solo ocho palabras de salida?
Una llamada a un programa es una prueba de que código público se ejecutó correctamente sobre entradas privadas; el libro mayor registra únicamente el recibo. Ocho palabras de 32 bits bastan para vincular un resultado, un compromiso o una decisión, y un tamaño de salida fijo garantiza que la forma del recibo no revele nada sobre el programa. Por ahora, las salidas son solo datos: un programa no puede transferir valor por sí mismo.
Fuente: randprotocol.org/usecases (platform note); docs/confidential.md
24. ¿Por qué existe un sobre de entradas de llamada?
Quien realiza una llamada y conserva las entradas privadas puede demostrar después sobre qué se calculó esa llamada. El sobre de entradas de llamada hace esto duradero al almacenar las entradas, cifradas, junto a la llamada, donde un auditor designado puede descifrarlas con una clave. Esto extiende la divulgación selectiva (confidencial para el mercado, abierta para un regulador designado) de los pagos a la ejecución de programas.
Fuente: docs/confidential.md (‘Call input envelopes’)
25. ¿Por qué un cambio en el conjunto de restricciones es una bifurcación dura?
Cada nodo vuelve a verificar cada prueba durante la sincronización, y una prueba es válida solo con respecto al conjunto de restricciones (AIR) bajo el cual se produjo. Un cambio en el AIR modifica, por tanto, el conjunto de cadenas válidas, y se introduce en un corte de génesis en lugar de adoptarse nodo por nodo.
Fuente: docs/architecture.md (‘Why a constraint-set change is a hard fork’)
26. ¿Por qué el emulador es la referencia y no el AIR?
El emulador es la especificación legible de la máquina y el AIR es una codificación de esa especificación como restricciones polinómicas. Cuando ambos discrepan, el AIR está, por definición, en error. Esto sitúa la definición normativa en el artefacto que resulta más práctico de auditar para las personas.
Fuente: docs/zkvm.md §5
Consenso y el nodo
27. ¿Por qué HotStuff BFT encadenado?
HotStuff encadenado proporciona finalidad determinista: con quórums ponderados por stake de más de dos tercios, un bloque es final una vez que se han formado tres certificados de quórum consecutivos sobre él, y un bloque final nunca se reorganiza. El intervalo medido entre bloques es de 1,2 s y el tiempo hasta la finalidad de aproximadamente 3,6 s. Los usuarios institucionales a los que se dirige requieren una finalidad de liquidación sobre la que puedan registrar asientos, algo que una cadena con finalidad probabilística no ofrece.
Fuente: fullnode README; randprotocol.org (performance section); docs/architecture.md §6
28. ¿Por qué la verificación de pruebas queda fuera del bucle de consenso?
Un nodo verifica cada STARK cuando admite la transacción (aproximadamente 32 ms en caliente), antes de retransmitirla, de modo que la verificación nunca se sitúa en la ruta crítica de la propuesta de bloques. El intervalo entre bloques queda así determinado por la latencia del consenso y no por el tamaño de la prueba. Las comprobaciones se ordenan por coste, verificando el STARK en último lugar, de modo que una transacción mal formada se rechaza antes del paso más costoso.
Fuente: randprotocol.org; docs/architecture.md (‘How it works’)
29. ¿Por qué el registro de validadores es público cuando todo lo demás es blindado?
Todas las réplicas deben acordar qué validadores pueden proponer y qué votos constituyen un quórum, lo que exige que los pesos de stake sean públicos. El registro contiene, por tanto, los importes de stake en claro. El vínculo con la titularidad permanece oculto: una fianza se financia a partir de una nota blindada y un retiro se paga a una de ellas, y ninguna de las dos operaciones revela de quién es la nota.
Fuente: docs/staking.md §1
30. ¿Por qué un nodo que se sincroniza vuelve a ejecutar cada bloque en lugar de confiar en los certificados?
Un nodo que se incorpora tarde verifica cada certificado de quórum, vuelve a verificar cada bundle y cada prueba de llamada, y compara los recibos resultantes antes de aceptar la cadena. Dado que la validez se establece mediante las pruebas y no únicamente mediante firmas, este procedimiento no está expuesto a los ataques de largo alcance que afectan a las cadenas protegidas solo por firmas. Se descartó podar las pruebas del historial porque eliminaría esta garantía.
Fuente: docs/architecture.md; docs/aggregation.md (introducción)
31. ¿Por qué mantener el límite de bloque en 4 MiB cuando una prueba supera 1 MB?
Con un límite fijo, el tamaño del bloque no puede crecer; cuando la demanda supera la capacidad, lo que se limita es el rendimiento (a tres transferencias shielded por bloque con el perfil de 80 consultas). Se consideró que un límite de rendimiento es un modo de fallo más seguro que un crecimiento ilimitado del bloque. La solución elegida es la agregación a nivel de bloque, una prueba recursiva por bloque, en lugar de elevar el límite o reducir el nivel de solidez.
Fuente: docs/block-space.md §1, §6
32. ¿Por qué la testnet poda el historial a un día?
Un certificado de quórum que contiene 18 firmas Dilithium2 ocupa aproximadamente 44 KB y se almacena dos veces por bloque. Con bloques mayormente vacíos cada 1,4 s, esto suponía aproximadamente 6,6 GB por nodo y día; los discos de los nodos se llenaron y la cadena perdió el quórum en la altura 248,953. Los nodos completos de la testnet ahora conservan un día de historial, un único nodo de archivo conserva todo el historial, y los nodos de mainnet lo conservarán todo. El estado del libro mayor —el árbol, el conjunto de nullifiers, el registro y los programas— nunca se poda.
Fuente: docs/superpowers/specs/2026-09-24-history-pruning-design.md
33. ¿Por qué libp2p?
El nodo utiliza TCP con Noise y Yamux, gossipsub para transacciones y votos, Kademlia con una lista de arranque para el descubrimiento de pares, mDNS en redes locales y solicitud-respuesta para la sincronización de bloques. Se trata de componentes estándar y ampliamente desplegados, de modo que el nodo hereda la puntuación de pares, la reconexión y las actualizaciones de transporte en lugar de mantener sus propias implementaciones.
Fuente: fullnode README (fila de redes)
Mercado de pruebas y agregación
34. ¿Por qué la agregación de pruebas a nivel de bloque?
El espacio de bloque crece linealmente con el número de bundles si cada uno incluye su propia prueba de aproximadamente 1,3 MB. Un único STARK recursivo por bloque, que verifica las N pruebas de bundle, mantiene constante en N el coste de la prueba en la cadena. Los validadores verifican entonces una sola prueba agregada (aproximadamente 16 ms en caliente) en una CPU, de modo que el hardware convencional sigue pudiendo validar, mientras que los agregadores con GPU compiten en un mercado independiente y sin permisos por la parte de las comisiones destinada a la generación de pruebas y por un subsidio de bloque.
Fuente: docs/aggregation.md §1
35. ¿Por qué tres roles: validador, agregador y prover delegado?
Los tres roles tienen requisitos de hardware distintos y son remunerados por partes distintas. Un validador ordena y verifica transacciones en una CPU y se remunera con la parte de las comisiones destinada a la verificación. Un agregador produce la prueba recursiva del bloque en una GPU y se remunera con la parte destinada a la generación de pruebas y con el subsidio. Un prover delegado produce una única prueba de bundle para un remitente cuyo dispositivo no puede hacerlo (un teléfono o un navegador) y es remunerado de forma privada por ese remitente. Separar los roles mantiene económica la validación y hace competitiva la generación de pruebas.
Fuente: docs/prover.md §1
36. ¿Por qué un prover delegado no puede robar fondos?
Con la autorización dividida, el prover recibe la clave de visualización nk pero no la clave de gasto sk. La prueba de bundle se compromete con c = H(AUTH, nk || salt), y la prueba de autorización independiente de la wallet demuestra el conocimiento de sk para el mismo c. Sin sk, el prover puede calcular la prueba de bundle pero no puede producir una autorización válida, y la wallet verifica la prueba devuelta antes de enviarla.
Fuente: docs/shielded.md (autorización dividida); docs/prover.md §8
El puente y zUSD
37. ¿Por qué bloquear USDT/USDC en sus cadenas de origen en lugar de emitir una nueva stablecoin?
La emisión nativa en Rand haría que la capacidad de reservas dependiera de las decisiones de despliegue de los emisores, que escapan al control del proyecto. Bloquear USDT y USDC en Ethereum, BSC, Tron y Solana obtiene reservas de las cadenas en las que estos activos ya circulan y no introduce ningún emisor nuevo: cada unidad de zUSD es un derecho sobre USDT o USDC mantenidos en un contrato de custodia legible públicamente.
Fuente: randprotocol.org (sección de reservas)
38. ¿Por qué un conjunto de guardianes t-de-n, y por qué decirlo con claridad?
La atestación es la única prueba de la que dispone Rand de que se produjo un bloqueo en otra cadena, por lo que debe estar firmada por un grupo con umbral; una atestación válida requiere firmas de más de dos tercios de los guardianes. La suposición de confianza resultante se enuncia de forma explícita. La garantía efectiva es la más débil entre la solvencia de las reservas y la integridad del puente; una coalición de t guardianes puede autorizar la emisión sin un bloqueo correspondiente; y la exposición está acotada por la custodia mantenida en cada cadena. Esta suposición fue originalmente el argumento en contra de construir un puente. No se retira, sino que se acepta a cambio de capacidad de reservas.
Fuente: randprotocol.org (sección de reservas, «What this costs»)
39. ¿Por qué una cofirma Dilithium2 junto a la atestación ECDSA?
Las cadenas de origen no ofrecen ningún verificador de firmas de retículo, por lo que las liberaciones en esas cadenas siguen protegidas por ECDSA clásico, con una exposición acotada por la custodia y los límites. Todo mensaje que el libro mayor de Rand acepta de los guardianes —depósitos y rotaciones del conjunto de guardianes— debe llevar además un quórum de firmas Dilithium2 de esos mismos guardianes. Por tanto, la vía de emisión es poscuántica aunque los extremos externos no lo sean. Las cofirmas se transmiten junto con la atestación y no exigen ningún cambio en los contratos desplegados.
Fuente: docs/superpowers/specs/2026-09-19-pq-cosignature-bridge.md §1
40. ¿Por qué el factor de cegamiento de la nota de depósito se deriva en lugar de elegirse?
Antes, el compromiso de la nota de depósito no quedaba determinado hasta que un relayer enviaba la atestación, de modo que dos relayers podían enviar la misma atestación con notas distintas. Derivar el factor de cegamiento r de forma determinista a partir de la atestación fija el compromiso, de manera que los envíos concurrentes colisionan en un único compromiso y el depósito no puede emitirse dos veces.
Fuente: docs/bridge.md (F1, chain 14)
41. ¿Por qué el USDT bloqueado en Tron puede salir como USDT en Ethereum?
zUSD es fungible: cada unidad es un derecho sobre la reserva agregada, no sobre la cadena por la que entró. Desacoplar la entrada de la salida permite que la liquidez se desplace allí donde se demanda, siempre que la cadena de destino disponga de reservas suficientes. El artículo sobre la stablecoin demuestra que el invariante S ≤ Σ_c R_c, es decir, que la oferta total está acotada por la suma de las reservas por cadena, se preserva en cada transición de estado.
Fuente: randprotocol.org (sección de reservas)
42. ¿Por qué el shielding oculta la distribución pero no la cantidad?
La oferta total de zUSD es pública en el registro de tokens y la reserva de cada cadena es un saldo público, de modo que cualquiera puede verificar la solvencia; lo que se oculta es la distribución de las tenencias entre los propietarios. Se aplica una limitación: los cuatro saldos de reserva no pueden observarse de forma atómica en un único instante, por lo que, para esas cadenas, la comprobación detecta la insolvencia a posteriori en lugar de impedirla.
Fuente: randprotocol.org (sección de reservas)
43. ¿Por qué una quema es la única transacción que nombra su activo?
Una quema libera un activo concreto en una cadena concreta, por lo que el contrato de custodia debe saber de qué activo y de qué cadena se trata. Toda otra transacción transfiere un activo no identificado. La quema también lleva la comisión del puente, porque es la única transacción del puente cuyo remitente es el beneficiario.
Fuente: docs/architecture.md; docs/shielded.md §2
Cumplimiento y divulgación
44. ¿Por qué claves de visualización en lugar de «privado frente a todos»?
Los reguladores no han aceptado sistemas de privacidad en los que la divulgación depende de la cooperación de la parte investigada, como ilustra el caso de Tornado Cash. Por ello, Rand trata la divulgación como un objeto del protocolo. El titular, o un intermediario regulado, conserva una clave de visualización; un auditor puede descifrar las transacciones indicadas en una solicitud legal; y el objetivo de diseño son claves con alcance limitado que revelen contraparte e importe sin revelar la estrategia de negociación. Para aplicaciones como la nómina, esta auditabilidad es un requisito y no una limitación.
Fuente: randprotocol.org/usecases (sección de regulación; caso de nóminas)
45. ¿Por qué la clave de visualización saliente es independiente de la entrante?
La separación permite que un remitente demuestre lo que pagó sin obtener acceso al historial del destinatario, y a la inversa. La clave de visualización saliente ovk descifra los sobres que la wallet ha enviado; la clave de desencapsulación ML-KEM descifra los sobres que se le han enviado; y una clave por transacción divulga exactamente una salida a un tercero.
Fuente: docs/shielded.md §1–2
Limitaciones conocidas
46. ¿Qué filtran hoy las pruebas y por qué está documentado?
La revisión del 2026-09-27 constató que, con el guest v1 (chains 14–15), cada prueba de bundle revela qué ranuras de entrada contienen notas reales y el peso de Hamming de cada índice de hoja gastada. La causa es doble: los totales LogUp por tabla se publican sin cegamiento, y el flujo de control del guest se bifurca según si una entrada es ficticia. La solución es un guest sin ramificaciones (v2), que se seleccionará en el próximo génesis. El hallazgo se publica porque la red es una testnet y la documentación sirve como su registro de auditoría.
Fuente: docs/shielded.md («What the proofs leak today»)
47. ¿Por qué el crecimiento del estado tiene un precio inferior al debido?
Ethereum fija precios a las escrituras de almacenamiento porque el estado almacenado impone un costo permanente a cada nodo. Rand fija actualmente el precio del crecimiento del árbol de compromisos, del conjunto de nullifiers y del almacenamiento de programas únicamente mediante la tarifa de despliegue por palabra y la tarifa fija por paquete. Esto es adecuado para una testnet, pero está registrado como una cuestión abierta de tarificación que debe resolverse antes de mainnet-beta; su resolución no requiere medición por opcode.
Fuente: docs/fees.md §3 (caveats)
48. ¿Por qué aún no se ha completado ninguna auditoría independiente?
El protocolo se encuentra en desarrollo activo en una testnet operada por el equipo, y se esperan nuevos conjuntos de restricciones y cortes de cadena antes de que el diseño sea estable. El sitio web lo indica en cada página. Las rondas de auditoría interna (v3–v5) se publican en docs/consensus.md y en las especificaciones de diseño, de modo que la auditoría externa que eventualmente se realice cuente con un registro completo sobre el cual trabajar.
Fuente: randprotocol.org (footer); docs/consensus.md