Alors que nous attendons le verdict du procès Storm, il est bon de se rappeler que les pools protégés ne sont que des mathématiques, et qu'ils ne sont pas si difficiles à comprendre. Tout le monde peut en mettre un en œuvre. Voici donc un fil avec l'intuition de base sur leur fonctionnement :

L'objectif est de construire un système où toutes les informations de chaque transaction restent entièrement privées pour les utilisateurs. Nous ne devrions rien attendre de moins de nos systèmes transactionnels. C'est le droit humain fondamental à la vie privée.

Le problème est que, si toutes les informations sont privées, comment la blockchain sait-elle que la transaction est valide ? Comment sait-elle que l'utilisateur a réellement les fonds qu'il compte envoyer ? Qu'il ne dépense pas deux fois ? La réponse évidente est : les zk-proofs. Mais est-ce vraiment si simple ?

Supposons que vous ayez un compte avec un solde de 10. Vous voulez envoyer 5 à la défense de Roman. Donc, vous faites une preuve zk qui montre que vous avez 10, et votre transaction envoie 5. Ça semble assez simple !

Mais attendez ! Lorsque vous avez fait une preuve d'avoir 10, cette preuve concernait un état dans le passé, avant le dernier bloc où votre tx a été inclus. Peut-être qu'entre-temps, vous avez dépensé toutes les pièces ! Comment pouvez-vous prouver que vous avez toujours 10, au dernier bloc ?

C'est en fait assez délicat, et c'est pourquoi les pools protégés ne fonctionnent pas vraiment avec les systèmes basés sur des comptes - il n'y a pas de moyen simple et fiable de prouver à une blockchain, en zk, l'état le plus récent en temps réel. La solution ? Utiliser des UTXO. Les célèbres "Unspent Tx Outputs" de Bitcoin.

Avec les UTXO, vous n'avez pas un compte unique et actualisable, vous avez des "billets" individuels qui ne peuvent être dépensés qu'une seule fois, en totalité (comme une vraie pièce). Les systèmes UTXO sont en général un peu ennuyeux à développer, mais cette propriété de "dépense unique" les rend très utiles pour les pools protégés.

Dans un système UTXO comme Bitcoin, lorsque vous allez dépenser un UTXO, tous les nœuds complets peuvent vérifier que l'UTXO existe (il a été créé dans le passé) et qu'il n'a pas encore été dépensé. C'est simple. Mais si toutes les données dans l'UTXO sont chiffrées, comment pouvons-nous vérifier cela ?

Non seulement les données sont chiffrées, mais nous ne voulons même pas révéler *quel* UTXO est dépensé. Si nous le faisions, alors celui qui vous a envoyé l'UTXO saurait quand vous l'avez dépensé. Dans un design idéal de pool protégé, AUCUNE information n'est divulguée par une transaction.

Le principe fondamental des pools protégés est d'introduire une valeur de "nullificateur" qui peut être révélée publiquement mais qui est dérivée de manière unique par le dépensier pour chaque UTXO. Pour dépenser l'UTXO, la blockchain vérifie que le nullificateur n'existe pas déjà. Cela garantit que chaque UTXO ne peut être dépensé qu'une seule fois.

Maintenant, nous pouvons revenir à notre zk-proof. Nous devons simplement prouver que le UTXO que nous dépensons existe réellement sur la chaîne, et que le nullificateur que nous avons révélé pour celui-ci est correctement dérivé du UTXO que nous dépensons. C'est tout !

En pratique, cela signifie que les systèmes de pools protégés conservent généralement deux arbres Merkle distincts. L'un contient les hachages des UTXO (les UTXO sont souvent appelés "notes", et leurs hachages "engagements de notes"), et l'autre contient les nullificateurs. Les deux arbres sont en ajout uniquement !

Lorsqu'une nouvelle note est créée, son hash est stocké dans l'arbre Merkle de la note. La note elle-même est chiffrée. Lorsqu'un utilisateur souhaite dépenser cette note, il calcule le nullificateur de la note et il réalise une preuve zk montrant que la note est dans l'arbre Merkle et que le nullificateur est correct.

Le nullificateur est révélé publiquement et la chaîne vérifie qu'il n'existe pas déjà dans l'Arbre des nullificateurs. Il est ensuite stocké là, de sorte que le billet ne puisse pas être dépensé à nouveau. Personne ne peut réellement dire quel billet est dépensé, puisque le billet original reste intact dans l'Arbre des billets !

Voilà, le design de base de tous les pools protégés aujourd'hui, y compris @Zcash, @TornadoCash, @penumbrazone, @namada, et plus encore. Bien sûr, il y a beaucoup plus à prendre en compte dans le design des pools protégés. Restez à l'écoute pour d'autres fils où nous plongerons plus profondément dans ces mécanismes.

@AThryver @0xkaiserkarel Une idée reçue commune et un usage potentiellement trompeur du terme "zk" ici. Voir