Récupération sociale à guichet unique : comment les zk-SNARK réalisent-ils la séparation de la logique des transactions du portefeuille et des actifs ?

Auteur original : @Toni Wahrstätter

Date de sortie : 12 septembre 2023

Traduction : Institut de recherche DeBox

Préface

Vitalik recommande d’utiliser des zk-SNARK pour séparer les comptes logiques de trading des comptes détenant des actifs. Cela améliore la confidentialité, l’expérience utilisateur et la récupération sociale en un clic. Toni Wahrstätter, chercheur sur Ethereum, fournit une analyse détaillée de ce prototype de portefeuille, couvrant le flux de travail et les avantages.

Un grand merci à Matt pour les discussions intéressantes sur ce sujet et pour avoir développé cet outil pour analyser chaque contrat et le placer dans un arbre Merkle clairsemé qui simplifie le prototypage en éliminant le besoin de preuves zk sur l’arbre Patricia. Merci également à Vitalik pour sa contribution précieuse.

La gestion de plusieurs comptes peut être difficile pour diverses raisons, notamment les problèmes de récupération sociale, de confidentialité, de L2 et d’expérience utilisateur globale. L’utilisation d’une adresse furtive rend les choses plus compliquées car chaque interaction nécessite un nouveau compte. Vitalik recommande d’utiliser des zk-SNARK pour séparer les comptes logiques de trading des comptes détenant des actifs. Cela améliore la confidentialité, l’expérience utilisateur et la récupération sociale en un clic.

Pour ce qui suit, je vous recommande d’abord de consulter l’article « Trois transformations » de Vitalik pour obtenir un aperçu.

En un mot, ce que nous essayons de réaliser est le suivant :

**Récupération sociale à guichet unique sans compromettre la confidentialité. **

1. Méthode traditionnelle

Une implémentation simple mais compromettant la confidentialité ressemble à ceci :

1. L’utilisateur fournit une signature et une intention/commande au compte de détention d’actifs.
2. Le compte de dépôt patrimonial transmet la signature au compte de dépôt logique.
3. Le compte de dépôt logique dérive la clé publique de la signature et la compare à sa clé publique stockée.
4. Si la vérification est réussie, le compte logique informera le compte de dépôt d’actifs de poursuivre l’opération.
5. Le compte de dépôt d’actifs exécute les ordres de l’utilisateur.

L’inconvénient est que cela relie publiquement les comptes logiques et les comptes de détention d’actifs, compromettant ainsi la confidentialité.

2. Utilisez ZK-SNARK

En utilisant zk-SNARK, les utilisateurs peuvent prouver qu’ils sont autorisés à dépenser sans révéler le lien entre le compte de dépôt logique et le compte de dépôt d’actifs.

Le flux de travail est le suivant :

1. L’utilisateur construit localement un arbre Merkle et identifie les feuilles contenant son contrat.

1.1. Un arbre Merkle contient essentiellement les valeurs slot0 et slot1 de chaque contrat existant triées par date ou par nom.

1.2. Chaque utilisateur peut créer localement une arborescence Merkle basée sur le dernier état.

2. L’utilisateur construit une preuve zk pour prouver qu’il connaît le secret du compte de dépôt logique. Preuve en détail plus tard.

3. L’utilisateur envoie zk-proof au compte de dépôt d’actifs.

4. Certificat de vérification du compte de dépôt d’actifs, confirmant ce qui suit :

4.1 Les utilisateurs savent où se situe la logique.

4.2 L’utilisateur connaît une valeur secrète qui est hachée et mappée à la valeur stockée dans le compte de dépôt logique.

4.3 Les utilisateurs peuvent reconstruire l’état du compte, la racine de l’arborescence Merkle conservée dans la chaîne canonique (par exemple précompilée)

4.4 Utiliser des nombres aléatoires corrects (utilisés pour changer de clé dans les comptes de dépôt logiques).

Essentiellement, un utilisateur peut dire : « J’ai une autorisation prouvable du compte de dépôt logique pour effectuer cette action, et je connais l’emplacement de ce compte logique. »

avantage

• Expérience utilisateur : une clé privée ou une configuration multi-signature peut contrôler plusieurs comptes, même s’ils se trouvent sur des L2 différents.
• Restauration : les comptes peuvent être restaurés plus facilement avec une seule mise à jour du contrat.
• Confidentialité : aucun lien public entre les comptes.
• Compatibilité : cela contribue à populariser les portefeuilles Account Abstraction (AA) et d’autres fonctionnalités.

De plus, en ajoutant un autre contrat (agrégateur) entre la logique et le contrat de détention d’actifs, plusieurs preuves de différents comptes de détention d’actifs peuvent être fournies en une seule transaction, permettant au compte d’être traité presque comme un UTXO. Les agrégateurs pourront obtenir plusieurs certificats zk et les transmettre à leurs comptes de détention d’actifs respectifs pour vérification. Bien entendu, un tel agrégateur pourrait créer des liens – y compris en matière de confidentialité – entre les comptes de détention d’actifs individuels.

Il convient de noter qu’il ne s’agit pas nécessairement d’un choix entre utiliser les SNARK (et donc s’appuyer sur leur sécurité) et ne pas utiliser les SNARK du tout (et donc passer à côté de bonnes propriétés de confidentialité). Un compromis pourrait consister à utiliser une preuve SNARK pour ouvrir une fenêtre de temps dans le contrat de détention logique, suivie d’un court délai, après quoi le propriétaire du contrat de détention logique peut modifier la valeur slot0, plutôt que d’exiger une preuve SNARK pour dépenser et changer ainsi la logique de consommation. Le propriétaire actuel du contrat peut utiliser un délai avant l’ouverture de la fenêtre horaire pour empêcher les mises à jour des informations d’identification.

détails techniques

Le paramètre zk-SNARK comprend des éléments privés :

• Clé utilisée pour la vérification.
• L’adresse logique du compte de dépôt est l’adresse pointée par le compte de dépôt d’actifs.
• Branche Merkle pour identifier des valeurs d’état spécifiques.
• Un usage occasionnel qui permet la rotation des clés tout en invalidant les anciennes clés. Les éléments privés tels que la logique en clair contenant les adresses de contrat et les secrets ne sont pas rendus publics, mais sont utilisés pour lier de manière privée les comptes de dépôt logique et les comptes de dépôt d’actifs. En générant des preuves pour l’ensemble de l’État, il n’est pas nécessaire qu’une autorité centrale construise un arbre de Merkle pour soumettre des preuves.

1. Compte de dépôt logique

Un prototype de compte de dépôt logique pourrait ressembler à ceci :

solidité du pragma >=0,7,0 <0,9,0 ;

le contrat LogicHoldingAccount est propriétaire { uint256 public slot0 = 0x1234 ; // secret haché uint256 public nonce = 0 ; // garder une trace des changements clés adresse public propriétaire ;

function updateOwner(uint256 newValue) public onlyOwner { nonce += 1; slot0 = nouvelleValeur ;

• slot0 : la variable publique qui contient initialement la valeur de hachage. Seul le propriétaire connaît la préimage hachée.
• occasionnel : un compteur qui suit le nombre de mises à jour des informations sur le propriétaire. Cela garantit que les anciennes clés deviennent invalides.
• updateOwner(uint256 newValue) : Fonction qui met à jour la valeur et ajoute un nombre aléatoire.

Ce contrat suit la logique de dépenses actuelle du propriétaire (slot0) et permet les mises à jour via la fonction updateOwner.

2. Compte de dépôt

solidité du pragma >=0,7,0 <0,9,0 ;

contrat AssetHoldingAccount { uint256 public logicHoldingAccountHash = 1234…;

// Taille du champ scalaire, taille du champ de base, données de la clé de vérification, etc. // …

fonction verifyProof (uint [2] données d’appel _pA, uint [2] [2] données d’appel _pB, uint [2] données d’appel _pC, uint [2] calldata _pubSignals) la vue publique renvoie (bool val) { // Code assembleur Snarkjs pour la vérification de la preuve… // … }

// _pubSignaux [0] - la racine de l’arbre contract-slot0||nonce Merkle // _pubSignals [1] - la fonction d’adresse du détenteur de logique hased ute (adresse payable à, montant uint256, uint [2] données d’appel _pA, uint [2] [2] données d’appel _pB, uint [2] données d’appel _pC, uint [2] calldata _pubSignals) public { contractRootPrecompile.getRoot(block.number) uint256 spécifiéLogicHolder = _pubSignals [1] ; require(specifiedLogicHolder == logicHoldingAccountHash, “Non autorisé”);

bool validProof = verifyProof(_pA, _pB, _pC, _pubSignals) == true; if (validProof) { (bool success,) = to.call{value:amount}(“”); exiger (succès); } }

recevoir() externe payable {

Les comptes de détention d’actifs stockent des actifs tels que l’ETH et permettent aux utilisateurs de soumettre une preuve de retrait. En vérifiant que le spécifiéLogicHolder correspond au logicHoldingAccountHash, le propriétaire peut garantir que le contrat de détention d’actifs n’accepte que les preuves du contrat de détention logique autorisé, plutôt que tout contrat arbitraire.

Le secret fourni comme signal privé lors de la construction de la preuve garantit que seul le propriétaire du compte contenant la logique de dépenses peut accéder aux fonds du compte de dépôt d’actifs.

3.Circuit

Le circuit suivant a été développé en utilisant circom, le code complet peut être trouvé ici.

pragma cirque 2.0.2 ;

inclure “./modules/merkleTree.cicom”; inclure “./modules/commitmentHasher.cicom”;

modèle principal (niveaux) { racine d’entrée du signal ; logique d’entrée de signalHoldingAddressHash ; logique d’entrée de signalHoldingAddress ; secret d’entrée de signal ; entrée de signal occasionnelle ; chemin d’entrée du signalÉléments [levels] ; chemin d’entrée du signalIndices [levels] ; composant secretHasher = SecretHasher(); secretHasher.secret <== secret; hachage de composant = CommitmentHasher(); hasher.logicHoldingAddress <== logicHoldingAddress; hasher.secret <== secretHasher.hashedSecret; hasher.nonce <== occasionnel ; hasher.logicHoldingAddressHash === logicHoldingAddressHash; arborescence des composants = MerkleTreeChecker (niveaux); arbre.leaf <== hasher.commitment; arbre.root <== racine ; pour ( je = 0; je < niveaux; i++) { tree.pathElements [i] <== pathElements [i] ; tree.pathIndices [i] <== cheminIndices [i] ;

composant principal {public [root,logicHoldingAddressHash]} = Main(N);

Le circuit comporte au total 7 signaux, dont 2 publics, à savoir la racine de l’arbre Merkle et l’adresse de hachage du compte de dépôt logique (qui doit être hachée avant d’être encodée dans le contrat de détention d’actifs pour empêcher les observateurs d’agréger le compte) classe) selon la même logique que le compte titulaire).

en conclusion

Dans un monde où les utilisateurs doivent gérer plusieurs comptes, le besoin d’une fonctionnalité de récupération sociale à guichet unique devient de plus en plus important. Zk-SNARK peut être utilisé dans des portefeuilles qui implémentent une séparation logique/actif, permettant aux utilisateurs d’utiliser la « logique » du compte A pour dépenser à partir du compte B sans créer de lien entre les deux. Dans un premier temps, les preuves SNARK peuvent être utilisées pour des actions moins risquées que les dépenses en actifs. Par exemple, un bon point de départ pourrait être de permettre aux utilisateurs de lancer des « demandes de retrait ». Si le propriétaire du contrat de détention de logique ne soulève pas d’objections, l’utilisateur peut finaliser la demande après un certain temps.

De cette façon, le propriétaire du contrat de détention logique peut toujours intervenir, même si cela viole la vie privée, en cas d’événement inattendu.