Saltar al contenido principal

Cómo funciona

El servicio de nombres de PIVX (PiNS) permite registrar nombres de dominio legibles (como myname.pivx), cambiar la dirección a la que resuelven, transferirlos a otros titulares y publicarlos en el mercado, asociándolos de forma segura a direcciones de PIVX.

Como PIVX es una cadena de bloques basada en UTXO sin contratos inteligentes de propósito general, no puede ejecutar por sí misma un sistema de base de datos complejo como un registro de dominios. Para resolverlo, PiNS emplea una arquitectura de tipo rollup: las operaciones se ejecutan fuera de la cadena, los datos se guardan en PIVX y la seguridad se ancla en BNB Smart Chain.

El sistema se compone de cinco piezas interconectadas:

1. La cadena de bloques de PIVX: la capa de disponibilidad de datos​

Toda acción del usuario —registrar un nombre (REG), cambiar una dirección (UPD), transferir la propiedad (CHG), publicar en el mercado (LST), retirar de la venta (ULT) o comprar (BUY)— comienza como una transacción nativa de PIVX. La transacción lleva un comando de texto estructurado en el campo memo (por ejemplo, PiNS:1:REG:domain:address:pubkey:nonce:signature).

  • La cadena de PIVX es la fuente de verdad. Almacena permanentemente cada comando de dominio. Ningún cambio de estado puede producirse sin una transacción de PIVX registrada.

2. El nodo registrador: el secuenciador​

Un nodo registrador automático escanea la cadena de bloques de PIVX. Lee los comandos de dominio, comprueba que el usuario pagó la tarifa correcta y encola las operaciones. Cada 10 minutos el registrador agrupa esas operaciones en un único lote (batch).

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

El lote de transacciones se envía a la máquina virtual de conocimiento cero SP1 (zkVM). La zkVM ejecuta un programa huésped en Rust especializado que actúa como árbitro estricto del protocolo. El generador de pruebas comprueba cada transacción del lote:

  • ¿Son válidas las firmas y las hicieron los verdaderos titulares de los dominios?
  • ¿Son los nonces estrictamente crecientes, para impedir ataques de repetición?
  • ¿Están bien formados los prefijos de dominio?
  • ¿Paga una transacción BUY exactamente el precio indicado en la transacción LST?
  • ¿Pasa old_root correctamente a new_root mediante pruebas matemáticas de Merkle?

Si se cumplen todas las reglas, la zkVM genera una prueba criptográfica ZK-SNARK (con Groth16). Esa prueba es un certificado diminuto que declara matemáticamente: «Partiendo de la raíz de estado A, tras aplicar este lote válido de transacciones, la nueva raíz de estado es B».

Cada versión compilada de este programa huésped produce un identificador criptográfico único llamado clave de verificación (vkey). La vkey es un hash de 32 bytes de la estructura del propio programa huésped compilado. Si se modifica una sola línea del código de verificación, el programa compila a una vkey completamente distinta.

4. El contrato en BNB Smart Chain: el ancla​

La prueba ZK generada y sus entradas públicas se envían al contrato inteligente PiNSAnchor en BNB Smart Chain. El contrato actúa como pasarela de liquidación.

  • El vínculo criptográfico: dentro del contrato inteligente se almacena en la cadena la programVkey (el hash esperado de 32 bytes del programa huésped). Cuando se presenta una prueba, el contrato la reenvía junto con la programVkey a la pasarela verificadora SP1 de Succinct.
  • Validación llave-cerradura: la pasarela verificadora solo aprobará la prueba si la generó exactamente el programa huésped que corresponde a la programVkey registrada.
  • Si la prueba es válida y se verifica contra la programVkey registrada, el contrato actualiza la raíz de estado oficial y aceptada globalmente a B y la guarda en su historial.
  • Si se ha violado una sola regla, o si la prueba se generó con un programa huésped modificado (lo que daría una vkey distinta), el contrato rechaza la transacción e impide transiciones de estado no autorizadas.

Por qué BNB Smart Chain​

La única tarea de la cadena ancla es almacenar una raíz y verificar una prueba, así que lo que importa es con qué rapidez un punto de control se vuelve definitivo y con cuánta confianza se puede dar por hecho que seguirá siéndolo.

  • Tiempos de bloque de unos 2 segundos, de modo que un lote queda anclado casi en cuanto se demuestra y los indexadores convergen deprisa en un nuevo punto de control.
  • En la práctica no hay reorganizaciones profundas, así que a un indexador no se le retira de debajo el punto de control al que se ha sincronizado. Una cadena ancla con reorganizaciones profundas obligaría a los indexadores a deshacer un estado que ya trataban como firme.
  • La verificación de la prueba tiene un coste en cadena fijo y bajo, sea cual sea el tamaño del lote: una única verificación Groth16 cubre todas las operaciones del lote.

5. Indexadores distribuidos: los resolutores​

Cualquiera puede ejecutar un nodo indexador independiente. Los indexadores rastrean la cadena de PIVX en busca de transacciones de dominio y el contrato en BNB Smart Chain en busca de puntos de control de raíz verificados. Aplican las transacciones localmente, calculan su propio árbol de Merkle y comprueban que su raíz local coincide con el punto de control en la cadena.

  • Así se garantiza que todos los indexadores, allá donde se ejecuten, resuelvan siempre los dominios a exactamente la misma dirección de destino (manteniendo un estado unificado en los extremos distribuidos).