Enquanto aguardamos o veredicto no julgamento da Storm, é bom lembrar que os pools protegidos são apenas matemática, e não são assim tão difíceis de entender. Qualquer um pode implementar um. Então aqui está um tópico com a intuição básica de como eles funcionam:

O objetivo é construir um sistema onde toda a informação em cada transação permaneça totalmente privada para os utilizadores. Não devemos esperar menos dos nossos sistemas transacionais. Este é o direito humano fundamental à privacidade.

O problema é que, se toda a informação é privada, como é que a blockchain sabe que a transação é válida? Como é que sabe que o utilizador realmente tem os fundos que pretende enviar? Que não está a gastar em duplicado? A resposta óbvia é: zk-proofs. Mas será mesmo tão simples?

Suponha que você tenha uma conta com um saldo de 10. Você quer enviar 5 para a defesa do Roman. Então, você faz uma zk-proof que mostra que você tem 10, e sua transação envia 5. Parece fácil o suficiente!

Mas espere! Quando você fez uma prova de ter 10, essa prova se referia a algum estado no passado, antes do último bloco onde sua tx foi incluída. Talvez desde então, você tenha gasto todas as moedas! Como você pode provar que ainda tem 10, no último bloco?

Isto é, na verdade, bastante complicado, e é por isso que os pools protegidos não funcionam realmente com sistemas baseados em contas - não há uma maneira direta e confiável de provar a um blockchain, em zk, o estado mais recente em tempo real. A solução? Usar UTXOs. Os famosos "Unspent Tx Outputs" do Bitcoin.

Com UTXOs, você não tem uma única conta atualizável, você tem "notas" individuais que só podem ser gastas uma vez, na íntegra (como uma moeda real). Os sistemas UTXO são meio irritantes de desenvolver em geral, mas essa propriedade de "gastar uma vez" torna-os muito úteis para pools protegidos.

Num sistema UTXO como o Bitcoin, quando você vai gastar um UTXO, todos os nós completos podem verificar se o UTXO existe (ele foi criado no passado) e se ainda não foi gasto. Isso é simples. Mas se todos os dados no UTXO estiverem encriptados, como podemos verificar isso?

Não só os dados estão encriptados, como também não queremos revelar *qual* UTXO está a ser gasto. Se o fizéssemos, quem lhe enviou o UTXO saberia quando você o gastou. Numa concepção ideal de pool protegido, NENHUMA informação é divulgada por uma transação.

O truque fundamental das pools protegidas é introduzir um valor de "nullificador" que pode ser revelado publicamente, mas é derivado de forma única pelo gastador para cada UTXO. Para gastar o UTXO, a blockchain verifica se o nullificador já não existe. Isso garante que cada UTXO só pode ser gasto uma vez.

Agora podemos voltar à nossa zk-proof. Temos simplesmente que provar que o UTXO que estamos a gastar realmente existe na cadeia, e que o nullifier que revelámos para ele é corretamente derivado do UTXO que estamos a gastar. É isso!

Na prática, isso significa que os sistemas de pool protegidos normalmente mantêm duas árvores de Merkle distintas. Uma contém os hashes dos UTXOs (os UTXOs são frequentemente referidos como "notas", e seus hashes como "compromissos de nota"), e a outra contém os anuladores. Ambas as árvores são apenas de adição!

Quando uma nova nota é criada, seu hash é armazenado na árvore Merkle da nota. A nota em si é encriptada. Quando um usuário vai gastar essa nota, ele calcula o nullifier da nota e faz uma prova zk mostrando que a nota está na árvore Merkle e que o nullifier está correto.

O anulador é revelado publicamente e a cadeia verifica se já não existe na Árvore de Anuladores. Ele é então armazenado lá, para que a nota não possa ser gasta novamente. Ninguém consegue realmente saber qual nota está sendo gasta, uma vez que a nota original permanece intacta na Árvore de Notas!

Aí está, o design básico de todas as pools protegidas hoje, incluindo @Zcash, @TornadoCash, @penumbrazone, @namada, e mais Claro que há muito mais envolvido no design de pools protegidas. Fique atento para mais tópicos onde vamos explorar mais a fundo essas mecânicas.

@AThryver @0xkaiserkarel Conceito errôneo comum e uso potencialmente enganoso do termo "zk" aqui. Veja