Pular para o conteúdo principal

Fluxo de trabalho

O PIVX Naming Service (PiNS) permite aos usuários registrar, atualizar, listar e transferir nomes de domínio legíveis por humanos (como myname.pivx) e mapeá-los com segurança para endereços PIVX shielded (Sapling).

Como PIVX é um blockchain baseado em UTXO sem contratos inteligentes de uso geral, ele não pode executar nativamente um sistema de banco de dados complexo como um registro de domínio. Para resolver isso, o PiNS usa uma Arquitetura estilo Rollup que executa operações fora da cadeia, armazena dados em PIVX e ancora a segurança no Arbitrum.

O sistema é alimentado por cinco componentes interligados:

1. PIVX Blockchain: a camada de disponibilidade de dados​

Cada ação que um usuário realiza - registrar um nome (REG), atualizar um endereço (UPD), transferir propriedade (CHG), listar no mercado (LST), cancelar a listagem (ULT) ou comprar (BUY) - começa como uma transação nativa PIVX. A transação contém um comando de texto estruturado no campo do memorando de transação (por exemplo, PiNS:1:REG:domain:address:pubkey:nonce:signature).

  • A cadeia PIVX é a fonte da verdade. Ela armazena permanentemente todos os comandos do domínio. Nenhuma mudança de estado pode acontecer sem uma transação PIVX registrada.

2. O nó do registrador: o sequenciador​

Um nó registrador automatizado verifica o blockchain PIVX. Ele lê os comandos do domínio, verifica se o usuário pagou a taxa de transação correta e coloca as operações na fila. A cada 10 minutos, o registrador agrupa essas operações em um único Lote.

3. SP1 zkVM: O mecanismo de conhecimento zero (por Sucinto)​

O lote de transações é enviado para a Máquina Virtual de Conhecimento Zero SP1 (zkVM). O zkVM executa um programa convidado Rust especializado que atua como um árbitro de protocolo estrito. O provador verifica cada transação no lote:

  • As assinaturas são válidas e assinadas pelos verdadeiros proprietários do domínio?
  • Os nonces estão aumentando estritamente para evitar ataques de repetição?
  • Os prefixos de domínio estão formatados corretamente?
  • Uma transação BUY paga o preço exato especificado na transação LST?
  • O REG0__ faz a transição corretamente para o REG1__ usando provas matemáticas de Merkle?

Se todas as regras forem atendidas, o zkVM gera uma prova criptográfica ZK-SNARK (usando Groth16). Esta prova é um pequeno certificado que declara matematicamente: "Começando com a raiz de estado A, após aplicar este lote válido de transações, a nova raiz de estado é B."

Cada versão compilada deste programa convidado produz um identificador criptográfico exclusivo chamado Verification Key (vkey). O REG2__ é um hash de 32 bytes da própria estrutura do programa convidado compilado. Mesmo que uma única linha do código de verificação seja modificada, o programa será compilado em um REG3__ completamente diferente.

4. Contrato Inteligente de Arbitragem: A Âncora​

A prova ZK gerada e suas entradas públicas são enviadas para o contrato inteligente PiNSAnchor no Arbitrum. O contrato atua como porta de liquidação.

  • A ligação criptográfica: Dentro do contrato inteligente, o REG4__ (o hash esperado de 32 bytes do programa convidado) é armazenado na cadeia. Quando uma prova é enviada, o contrato encaminha a prova e o REG5__ para o Succinct SP1 Verifier Gateway.
  • Validação Key-Lock: O gateway de verificação só aprovará a prova se ela tiver sido gerada pelo programa convidado exato correspondente ao REG6__ registrado.
  • Se a prova for válida e verificada em relação ao REG7__ registrado, o contrato atualiza a raiz estatal oficial e globalmente aceita para REG8__ e a salva em seu histórico.
  • Se uma única regra foi violada ou se a prova foi gerada usando um programa convidado modificado (que produziria um REG9__ diferente), o contrato rejeita a transação, evitando transições de estado não autorizadas.

5. Indexadores Distribuídos: Os Resolvedores​

Qualquer um pode executar um Nó Indexador independente. Os indexadores verificam o blockchain PIVX em busca de transações de domínio e verificam o contrato Arbitrum em busca de pontos de verificação de raiz verificados. Eles aplicam as transações localmente, calculam sua própria Árvore Merkle e verificam se sua raiz local corresponde ao ponto de verificação do Arbitrum.

  • Isso garante que todos os indexadores, não importa onde sejam executados, sempre resolvam domínios para exatamente o mesmo endereço de destino (mantendo um único estado unificado nas extremidades distribuídas).