Pular para o conteúdo principal

Como funciona

O serviço de nomes PIVX (PiNS) permite registar nomes de domínio legíveis (como myname.pivx), alterar o endereço para o qual são resolvidos, transferi-los para outros titulares e colocá-los no mercado, associando-os de forma segura a endereços PIVX.

Como o PIVX é uma cadeia de blocos baseada em UTXO sem contratos inteligentes de uso geral, não consegue por si só manter um sistema de base de dados complexo como um registo de domínios. Para resolver isso, o PiNS usa uma arquitetura ao estilo rollup: as operações são executadas fora da cadeia, os dados ficam no PIVX e a segurança é ancorada na BNB Smart Chain.

O sistema é formado por cinco componentes interligados:

1. A cadeia de blocos PIVX: a camada de disponibilidade de dados​

Todas as ações do utilizador — registar um nome (REG), alterar um endereço (UPD), transferir a propriedade (CHG), colocar no mercado (LST), retirar da venda (ULT) ou comprar (BUY) — começam como uma transação nativa PIVX. A transação contém um comando de texto estruturado no campo memo (por exemplo, PiNS:1:REG:domain:address:pubkey:nonce:signature).

  • A cadeia PIVX é a fonte da verdade. Guarda permanentemente cada comando de domínio. Nenhuma alteração de estado pode ocorrer sem uma transação PIVX registada.

2. O nó registador: o sequenciador​

Um nó registador automático percorre a cadeia de blocos PIVX. Lê os comandos de domínio, verifica se o utilizador pagou a taxa correta e coloca as operações em fila. A cada 10 minutos o registador agrupa essas operações num único lote (batch).

3. SP1 zkVM: o motor de conhecimento zero (da Succinct)​

O lote de transações é enviado para a máquina virtual de conhecimento zero SP1 (zkVM). A zkVM executa um programa convidado em Rust especializado que funciona como árbitro rigoroso do protocolo. O gerador de provas verifica cada transação do lote:

  • As assinaturas são válidas e foram feitas pelos verdadeiros titulares dos domínios?
  • Os nonces são estritamente crescentes, para impedir ataques de repetição?
  • Os prefixos de domínio estão bem formados?
  • Uma transação BUY paga exatamente o preço indicado na transação LST?
  • A old_root transita corretamente para a new_root através de provas matemáticas de Merkle?

Se todas as regras forem cumpridas, a zkVM gera uma prova criptográfica ZK-SNARK (com Groth16). Essa prova é um certificado minúsculo que declara matematicamente: «Partindo da raiz de estado A, depois de 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 único chamado chave de verificação (vkey). A vkey é um hash de 32 bytes da estrutura do próprio programa convidado compilado. Se for alterada uma única linha do código de verificação, o programa compila para uma vkey completamente diferente.

4. O contrato na BNB Smart Chain: a âncora​

A prova ZK gerada e as suas entradas públicas são enviadas para o contrato inteligente PiNSAnchor na BNB Smart Chain. O contrato funciona como porta de liquidação.

  • A ligação criptográfica: dentro do contrato inteligente está guardada na cadeia a programVkey (o hash esperado de 32 bytes do programa convidado). Quando uma prova é submetida, o contrato encaminha-a juntamente com a programVkey para o SP1 Verifier Gateway da Succinct.
  • Validação chave-fechadura: a porta de verificação só aprova a prova se esta tiver sido gerada exatamente pelo programa convidado correspondente à programVkey registada.
  • Se a prova for válida e verificada contra a programVkey registada, o contrato atualiza a raiz de estado oficial e globalmente aceite para B e guarda-a no seu histórico.
  • Se uma única regra tiver sido violada, ou se a prova tiver sido gerada com um programa convidado modificado (o que daria uma vkey diferente), o contrato rejeita a transação, impedindo transições de estado não autorizadas.

Porquê a BNB Smart Chain​

A única função da cadeia âncora é guardar uma raiz e verificar uma prova, por isso o que importa é a rapidez com que um ponto de controlo se torna definitivo e a confiança que se pode ter em que assim permanecerá.

  • Tempos de bloco de cerca de 2 segundos, pelo que um lote fica ancorado quase logo que é provado e os indexadores convergem depressa num novo ponto de controlo.
  • Na prática não há reorganizações profundas, pelo que o ponto de controlo a que um indexador se sincronizou não lhe é retirado debaixo dos pés. Uma cadeia âncora com reorganizações profundas obrigaria os indexadores a desfazer estado que já tratavam como definitivo.
  • A verificação da prova tem um custo fixo e baixo na cadeia, independentemente do tamanho do lote: uma única verificação Groth16 cobre todas as operações do lote.

5. Indexadores distribuídos: os resolvedores​

Qualquer pessoa pode executar um nó indexador independente. Os indexadores percorrem a cadeia PIVX à procura de transações de domínio e o contrato na BNB Smart Chain à procura de pontos de controlo de raiz verificados. Aplicam as transações localmente, calculam a sua própria árvore de Merkle e verificam se a sua raiz local corresponde ao ponto de controlo na cadeia.

  • Assim se garante que todos os indexadores, onde quer que sejam executados, resolvem sempre os domínios para exatamente o mesmo endereço de destino (mantendo um estado unificado nas pontas distribuídas).