Saltar al contenido principal

La cadena de pruebas

Los dominios se registran por lotes. Cada lote espera unos 10 minutos. Cada lote produce una prueba. Esas pruebas forman una cadena de transiciones de estado desde el origen:

genesis_root (empty tree -- known constant)
  |  +-- "richard.pivx" registered at block 100,
  |  +-- "john.pivx" registered at block 110,
  |  ... (could be more registration/update commands)
  |  ! Proof 1 is generated
  |  old_root = genesis_root --> new_root_1
  |  +-- "richard.pivx" put his name on marketplace at block 200,
  |  +-- "sam.pivx" registered at block 250,
  |  ... (could be more registration/update commands)
  |  ! Proof 2 is generated
  |  old_root = new_root_1 --> new_root_2 (= current root)

El old_root de cada prueba debe ser igual al new_root de la prueba anterior. El old_root de la primera prueba debe ser igual a la raíz de origen conocida (un árbol de Merkle disperso vacío).

Verificar la cadena​

Un verificador comprueba todo el historial de registros en cinco pasos:

  1. Obtener la clave de verificación de SP1, derivada de forma determinista del binario del programa huésped
  2. Descargar todas las pruebas desde la API
  3. Verificar cada prueba SP1 con esa clave de verificación
  4. Comprobar la cadena: genesis == P1.old_root, P1.new_root == P2.old_root, ..., PN.new_root == current_root
  5. Comprobación puntual en la cadena: buscar cualquier txid comprometido en un nodo de PIVX y confirmar que el memo, el importe y el bloque coinciden

Si todas las comprobaciones pasan, todo el historial de registros es correcto: no hace falta confiar en el indexador.

La tubería de pruebas​

El escáner y el generador de pruebas funcionan de forma independiente:

PIVX Blockchain
       |
   PiNS Registrar Scanner  (validates, captures SMT state)
       |
    Database               (status: "pending")
       |
   SP1 Prover              (generates ZK proof, verifies it)
       |
    Database               (status: "proved")
       |
   New checkpoint published
       |
   Indexer syncs to the checkpoint   
       |
   API Server   (GET /v1.0/resolve/{name})

El escáner nunca se queda bloqueado esperando a que se genere una prueba. El demonio generador consulta por su cuenta los registros pendientes y puede ejecutarse en hardware aparte.