Saltar al contenido principal

Flujo de trabajo

El servicio de nombres PIVX (PiNS) permite a los usuarios registrar, actualizar, enumerar y transferir nombres de dominio legibles por humanos (como myname.pivx) y asignarlos de forma segura a direcciones PIVX shielded (Sapling).

Debido a que PIVX es una cadena de bloques basada en UTXO sin contratos inteligentes de propósito general, no puede ejecutar de forma nativa un sistema de base de datos complejo como un registro de dominio. Para resolver esto, PiNS utiliza una Arquitectura estilo Rollup que ejecuta operaciones fuera de la cadena, almacena datos en PIVX y ancla la seguridad en Arbitrum.

El sistema está alimentado por cinco componentes interconectados:

1. PIVX Blockchain: la capa de disponibilidad de datos​

Cada acción que realiza un usuario (registrar un nombre (REG), actualizar una dirección (UPD), transferir propiedad (CHG), cotizar en el mercado (LST), eliminar de la lista (ULT) o comprar (BUY) comienza como una transacción nativa PIVX. La transacción contiene un comando de texto estructurado en el campo de nota de transacción (por ejemplo, PiNS:1:REG:domain:address:pubkey:nonce:signature).

  • La cadena PIVX es la fuente de la verdad. Almacena permanentemente cada comando de dominio. No se pueden producir cambios de estado sin una transacción PIVX registrada.

2. El nodo registrador: el secuenciador​

Un nodo de registro automatizado escanea la cadena de bloques PIVX. Lee los comandos del dominio, verifica que el usuario pagó la tarifa de transacción correcta y pone en cola las operaciones. Cada 10 minutos, el registrador agrupa estas operaciones en un solo Lote.

3. SP1 zkVM: el motor de conocimiento cero (por Succinct)​

El lote de transacciones se envía a la Máquina virtual de conocimiento cero (zkVM) SP1. El zkVM ejecuta un [programa invitado Rust] especializado (https://github.com/PIVX-Ninja/pivx-name-prover) que actúa como un estricto árbitro de protocolo. El probador verifica cada transacción del lote:

  • ¿Las firmas son válidas y están firmadas por los propietarios reales del dominio?
  • ¿Los nonces aumentan estrictamente para evitar ataques de repetición?
  • ¿Están los prefijos de dominio formateados correctamente?
  • ¿Una transacción BUY paga el precio exacto especificado en la transacción LST?
  • ¿El REG0__ hace la transición correctamente al REG1__ usando pruebas matemáticas de Merkle?

Si se cumplen todas las reglas, zkVM genera una prueba criptográfica ZK-SNARK (usando Groth16). Esta prueba es un pequeño certificado que declara matemáticamente: "Comenzando con la raíz del estado A, después de aplicar este lote válido de transacciones, la nueva raíz del estado es B".

Cada versión compilada de este programa invitado genera un identificador criptográfico único llamado Clave de verificación (vkey). El REG2__ es un hash de 32 bytes de la propia estructura del programa invitado compilado. Si se modifica incluso una sola línea del código de verificación, el programa compila en un REG3__ completamente diferente.

4. Contrato inteligente Arbitrum: el ancla​

La prueba ZK generada y sus entradas públicas se envían al contrato inteligente PiNSAnchor en Arbitrum. El contrato actúa como puerta de entrada a la liquidación.

  • El vínculo criptográfico: dentro del contrato inteligente, el REG4__ (el hash de 32 bytes esperado del programa invitado) se almacena en la cadena. Cuando se envía una prueba, el contrato envía la prueba y el REG5__ al Succinct SP1 Verifier Gateway.
  • Validación de bloqueo de teclas: el portal de verificación solo aprobará la prueba si fue generada por el programa de invitado exacto que coincide con el REG6__ registrado.
  • Si la prueba es válida y se verifica con el REG7__ registrado, el contrato actualiza la raíz estatal oficial aceptada globalmente a REG8__ y la guarda en su historial.
  • Si se violó una sola regla, o si la prueba se generó utilizando un programa invitado modificado (lo que produciría un REG9__ diferente), el contrato rechaza la transacción, evitando transiciones de estado no autorizadas.

5. Indexadores distribuidos: los solucionadores​

Cualquiera puede ejecutar un Nodo indexador independiente. Los indexadores escanean la cadena de bloques PIVX en busca de transacciones de dominio y escanean el contrato Arbitrum en busca de puntos de control raíz verificados. Aplican las transacciones localmente, calculan su propio árbol Merkle y verifican que su raíz local coincida con el punto de control de Arbitrum.

  • Esto garantiza que todos los indexadores, sin importar dónde se ejecuten, siempre resuelvan dominios en la misma dirección de destino exacta (manteniendo un único estado unificado en los extremos distribuidos).