Use esta página para ver quién hace qué cuando una transferencia circula por Rand. Probar es caro y verificar es barato, así que el trabajo se reparte siguiendo esa línea. Del lado del remitente se generan las pruebas. Los validadores solo las comprueban, las ordenan y votan. Un agregador, una vez activado, combinaría muchas pruebas en una sola. La figura sigue una transferencia desde la wallet hasta un bloque final; las secciones posteriores tratan cada rol por turno.
El recorrido de una transferencia
- La wallet construye la transferencia. Elige sus notas de entrada, obtiene sus testigos de Merkle, construye cuatro salidas y sella cada una en un sobre ML-KEM-768. Después calcula el vínculo (binding) de la transacción, un hash sobre todo salvo las pruebas (Transacciones).
- La wallet prueba por sí misma la autorización. Es una prueba de nivel 10 sobre la clave de gasto y una sal nueva, cuestión de segundos. Es la única prueba que toca la clave de gasto, y siempre se genera en la propia máquina de la wallet.
- La prueba del paquete se genera donde hay memoria para ella. Esta prueba de nivel 14 demuestra la propiedad, la pertenencia, los nullifiers y el balance, y alcanza un pico de unos 6 GB. La aplicación de escritorio y un teléfono con unos 8 GB la generan por sí mismos. Cualquier dispositivo con menos memoria delega el trabajo en un probador con el que esté emparejado: uno que usted ejecute, o el pool de los validadores en
prover.randprotocol.org. A cualquiera de los dos se le envían la clave de visualización y la sal, nunca la clave de gasto (Pruebas). - Un nodo RPC la comprueba. El nodo al que la wallet envíe la transacción recalcula el resumen del paquete, verifica ambas pruebas contra el vínculo, comprueba la comisión y solo entonces difunde la transacción a sus pares (Pruebas, Mempool).
- Los validadores la ordenan y la finalizan. El líder de la vista toma las transacciones que siguen siendo aplicables, primero la mejor comisión por KiB, y propone un bloque. Cada validador vuelve a verificar todas las pruebas del bloque y vota. El bloque se confirma cuando tres certificados de quórum se encadenan sobre él en vistas consecutivas, lo que exige que estén en línea 18 de los 26 validadores de chain 20 (Consenso).
- El bloque es final y cualquiera puede comprobarlo. Una transacción es final cuando
rand_getTransactiondevuelve un bloque. Un nodo que se sincroniza más tarde vuelve a verificar todos los certificados y todas las pruebas en lugar de confiar en las firmas.
Los roles
| rol | qué hace | ¿prueba? | qué ve | ejecuta |
|---|---|---|---|---|
| wallet | construye, autoriza y envía transferencias y llamadas; escanea la cadena con sus propias claves | siempre la prueba de autorización; la prueba del paquete cuando el dispositivo tiene la memoria | todo sobre sus propias notas | las aplicaciones de la página Clientes, o rand; en chain 20, Rand Wallet o rand v0.6.8 o posterior |
| probador delegado | genera la prueba del paquete para una wallet emparejada con él; la wallet comprueba cada respuesta antes de enviar nada | solo pruebas de paquete | la clave de visualización de la wallet emparejada: todo su historial, pasado y futuro; no puede gastar | rand-prover run, o rand-node run --prover |
| pool de probadores de los validadores | un probador delegado operado por cuatro hosts, dos validadores y dos máquinas que solo prueban, bajo un único nombre y una única clave, para wallets sin probador propio; sin comisión | solo pruebas de paquete | lo mismo que cualquier probador delegado, para cada wallet que se empareje con él | prover.randprotocol.org, huella RGTF-7HKJ-XZFV-GQ1J |
| nodo RPC (observador) | se sincroniza, vuelve a verificar cada prueba, sirve JSON-RPC, difunde las transacciones verificadas; no vota | no | solo campos públicos: compromisos, nullifiers, sobres sellados, pruebas | rand-node run |
| validador | todo lo que hace un observador, además de proponer en sus vistas y votar en HotStuff | no | solo campos públicos | rand-node run --validator |
| agregador | genera una prueba recursiva sobre una ventana de pruebas de paquete finalizadas y la envía para que un bloque la selle | sí, las pruebas más grandes de la red | solo campos públicos y pruebas | rand-node aggregate --watch, en una cadena con una sección aggregation |
Probar y validar son tareas distintas, y un validador no necesita hardware de prueba. Dos de los cuatro miembros del pool son validadores que además ejecutan un probador, como servicio; los otros dos son máquinas dedicadas a probar que no tienen ninguna clave de validador. Operar el pool no forma parte de validar. Los tamaños de cada rol, y la memoria de prueba medida por nivel, están en Hardware de validador y agregador.
Qué puede saber cada rol
La privacidad de una transferencia depende de quién posee cada clave, no de confiar en la red:
- Los validadores, los nodos RPC y el explorador ven lo que ve cualquier nodo: compromisos, nullifiers, sobres sellados, la comisión y las pruebas. No ven el monto, el activo, el remitente ni el destinatario.
- A un probador delegado, incluido el pool, se le envía la clave de visualización. Con ella puede leer todo el historial de la wallet emparejada. Nunca puede gastar, porque la prueba de autorización sobre la clave de gasto se genera en la máquina de la wallet. Emparejar el pool significa decidir mostrar ese historial a sus operadores. Si quiere mantenerlo privado, pruebe en su propio dispositivo o ejecute su propio probador.
- Un probador delegado no puede engañar a la wallet. La wallet lee el resumen de cada prueba que recibe, comprueba su tamaño y la verifica localmente, de modo que una prueba incorrecta nunca llega a un nodo.
Agregación: construida, no activa
Hoy cada bloque lleva todas las pruebas en bruto, unos 2,85 MB por transferencia, de modo que un bloque de 20 MiB contiene unas siete transferencias. La agregación de bloques es la respuesta del fullnode. Un agregador toma las pruebas de paquete de una ventana de bloques finalizados (rand_getUnsealed), genera una prueba recursiva que las verifica todas y la envía. El bloque que la incluye sella la ventana. Los validadores verifican entonces un solo agregado en lugar de N pruebas, y los nodos pueden descartar las pruebas en bruto cubiertas. Los agregadores están respaldados por una fianza y no requieren permiso, se ejecutan en máquinas de clase GPU y cobran la parte de prueba de los paquetes cubiertos más un subsidio de bloque en RAND nuevos.
Está construida e integrada, pero no está activa. Necesita una sección aggregation en el genesis, y chain 20 no tiene ninguna, por lo que rand_status informa todos los contadores de agregación en cero. Antes de poder activarla hay que volver a medir la forma de su paquete con el conjunto de restricciones actual, y hay que realizar un ejercicio de agregado falsificado contra el verificador de recursión. En una cadena con autorización dividida, además, solo sellaría las pruebas de paquete, no las pruebas de autorización (Pruebas).