Confiança e privacidade

O que pode verificar por si próprio

Nada disto exige confiar no operador:

• Todas as alterações de estado estão assinadas. O circuito verifica uma assinatura Ed25519 com a chave que a operação requer, pelo que um nome não pode mudar sem a chave do seu titular.
• Todos os lotes têm uma prova ZK. O contrato âncora não aceita uma raiz sem ela, e a prova é verificada contra a programVkey — um compromisso com o circuito compilado exato que você mesmo pode reconstruir.
• Todas as resoluções vêm com uma prova de Merkle. Pode confrontar o registo com uma raiz e a raiz com o contrato. Ver Verificar provas.
• Todas as raízes são deterministas. Qualquer indexador que reproduza os mesmos comandos tem de produzir a mesma raiz, pelo que uma discordância é imediatamente visível.
• As raízes formam uma cadeia, cada uma ancorada à altura do bloco PIVX que cobre.

Em que é preciso confiar

Uma lista curta e honesta — tudo o resto nesta página pode verificar por si:

1. O PIVX e a BNB Smart Chain funcionam conforme foram concebidos — as transações são definitivas e as cadeias não se reorganizam para além dos seus limiares de confirmação.
2. A criptografia padrão é sólida — SHA-256, Ed25519 e o sistema de provas SP1.
3. Um levantamento chega ao endereço que indicou. Montantes, comissões e obrigações são totalmente auditáveis publicamente; o destino é o único pormenor confirmado por si e não por um observador externo. Explicado em Saldos e levantamentos.

Porque é a replicação que torna o registador responsável

O registador publica o seu endereço de protocolo e a chave de visualização desse endereço. É deliberado e decisivo: com ambos, qualquer pessoa pode

1. percorrer o PIVX e decifrar todos os comandos e pagamentos desde a origem, por ordem canónica,
2. reproduzi-los com o indexador de código aberto,
3. calcular a raiz de estado de forma independente e
4. compará-la com a raiz ancorada na BNB Smart Chain.

Um registador que censure um comando pago, invente uma transferência, credite mal um saldo ou reordene operações produz uma raiz que todos os indexadores independentes contrariam. Não é preciso autorização nem acesso especial para verificar.

A propriedade que isto dá é a fraude fica à vista, não é impedida: um lote errado pode chegar à cadeia e ser desmentido depois. A recuperação é social, não automática.

Saldos e levantamentos

O dinheiro não passa diretamente do comprador para o vendedor. As receitas de uma venda são creditadas no saldo interno do vendedor, deduzida a comissão do serviço, as licitações perdedoras num nome disputado são devolvidas ao saldo, e o utilizador levanta quando quiser. Precisamente manter os fundos num saldo é o que torna os reembolsos possíveis: uma transação blindada não traz endereço de remetente, portanto não há para onde devolver automaticamente um pagamento errado.

Os pagamentos estão na cadeia e são atribuídos

O registador publica uma chave de visualização completa, e não apenas de entrada, pelo que os pagamentos de saída são tão visíveis como os de entrada. Cada pagamento traz um memo que nomeia a conta que liquida:

Payout #{id}: {gross} PIVX for pubkey '{pubkey}' (including the {fee}% service fee)

Isso torna todo o livro reconstruível por qualquer pessoa. Percorra o endereço de protocolo com a chave de visualização publicada e verá, para cada chave pública:

• todos os créditos que obteve — receitas de vendas e reembolsos, derivados do fluxo público de comandos
• todos os pagamentos que recebeu, atribuídos pelo memo, com o montante retirado do valor da nota
• a comissão do serviço aplicada a cada um

o que dá um saldo corrente que qualquer pessoa pode calcular por si:

balance(pubkey) = Σ(sale proceeds net of fee) + Σ(refunds) − Σ(payouts sent)    stays ≥ 0

Um pagamento sem obrigação correspondente, uma comissão incorreta ou um saldo levado a negativo seriam visíveis para qualquer observador. O registador não pode pagar-se a si próprio em silêncio, nem saltar uma obrigação, nem aplicar uma comissão diferente da publicada.

informação

Leia os montantes da nota, não do memo

O memo indica a obrigação bruta — o montante antes da comissão do serviço —, enquanto a nota transporta o montante líquido efetivamente pago. O valor de uma nota é criptográfico; o texto do memo é escrito pelo registador. Ao auditar, tire cada montante do valor da nota e trate o memo apenas como atribuição.

O que é confirmado pelo destinatário e não por um auditor

Um pormenor fica fora deste quadro, e é melhor dizê-lo com clareza do que deixá-lo implícito. Um levantamento é autorizado no site com a sua chave Ed25519, e esse pedido viaja por HTTPS e não pela cadeia. Um observador externo vê, portanto, que foi feito um pagamento de tamanho correto para a sua conta, mas não tem registo público de qual o endereço de destino que indicou.

Na prática, quem melhor pode verificar isso é você, e de imediato: sabe o que pediu e se os fundos chegaram. E a verificação não é uma questão de opinião: guarda o pedido que assinou, pelo que uma divergência pode ser demonstrada criptograficamente em vez de discutida.

	Confirmado por
Estado dos domínios	Qualquer observador, automaticamente — um indexador independente deteta uma raiz discordante sem que lho peçam
Montantes de pagamento, comissões, obrigações	Qualquer observador, a partir da chave de visualização publicada e da atribuição no memo
Destino do pagamento	O destinatário, contra o pedido que assinou

Encaminhar os levantamentos pelo transporte de memos levaria a última linha para a primeira categoria, a um custo de privacidade quase nulo, já que a chave de visualização e os memos que nomeiam a chave pública expõem essa ligação de qualquer maneira. Foi ponderado e posto de lado a favor de manter o levantamento como uma simples ação no site; continua a ser uma alteração futura razoável e não um defeito.

dica

Guarde os seus pedidos de levantamento assinados

Guarde o pedido assinado até confirmar que os fundos chegaram. É o que transforma um pagamento contestado em algo que consegue provar.

O que um indexador malicioso não consegue fazer

Não consegue falsificar um registo. As resoluções vêm com provas de Merkle, e uma raiz que o contrato âncora nunca aceitou é rejeitada pela verificação descrita em Verificar provas.

Não consegue esconder um registo. A ausência é provada, não afirmada: um terminal Blocked transporta consigo o registo completo que bloqueia, para que possa verificar a alegação em vez de a aceitar. Além disso, todo o histórico é rederivável a partir da cadeia com a chave de visualização pública.

Não consegue desaparecer. Cada comando vive no PIVX e o código é aberto. Qualquer pessoa pode reconstruir todo o registo desde o bloco de origem.

Resolução privada via Tor

Resolver pela rede aberta revela ao servidor que nomes consulta e quando. Por isso a API do indexador também é publicada como serviço oculto Tor:

http://indexer.pivxns3wsp3g6rtekzjwhqtcic2yhgngqg3ovod67hp3obt2ckmtcjyd.onion

No navegador Tor:

http://indexer.pivxns3wsp3g6rtekzjwhqtcic2yhgngqg3ovod67hp3obt2ckmtcjyd.onion/v1.0/resolve/richard.pivx

Na linha de comandos, com o Tor a correr localmente:

curl --socks5-hostname 127.0.0.1:9050 \
  http://indexer.pivxns3wsp3g6rtekzjwhqtcic2yhgngqg3ovod67hp3obt2ckmtcjyd.onion/v1.0/info

É a mesma API a devolver os mesmos dados, provas de Merkle incluídas, por isso não perde nada. O servidor nunca fica a saber o seu IP, e o seu operador vê apenas que usou o Tor.

dica

É a verificação que dispensa a confiança, não o transporte

O Tor protege a sua privacidade face ao indexador. Não torna o indexador honesto — disso tratam a prova de Merkle e a verificação da raiz na cadeia, e vale a pena executá-las independentemente da forma como se liga.