Blog V God : Comprendre les portefeuilles et autres cas d'application

Auteur : Vitalik Buterin ; Compilateur : Bulu a dit

Dans l'article Les trois transitions, Vitalik Buterin, le fondateur d'Ethereum, a clairement élaboré sur le "réseau principal (ci-après dénommé L1) + chaîne croisée de couche 2 (ci-après dénommée cross-L2) support"" "La sécurité du portefeuille" et la "confidentialité" sont des valeurs importantes en tant que fonctions nécessaires de la pile de l'écosystème. Ils ne doivent pas être simplement des composants supplémentaires, et un portefeuille séparé fournit des fonctions connexes.

Et cet article, a souligné Vitalik Buterin, se concentrera sur un problème technique clé : comment lire plus facilement les données L1 depuis L2 ; ou lire les données L2 depuis L1 ; ou comment lire plus facilement les données L2 depuis une L2 Lire les données depuis une autre L2 . **

Vitalik Buterin a souligné que la clé pour résoudre les problèmes ci-dessus réside dans la manière de réaliser la séparation des actifs et des magasins de clés. Cette technologie a également des cas d'utilisation très précieux dans des domaines autres que la mise à l'échelle, tels que la mobilité des actifs entre L1 et L2.

** Quel est le but de faire cela ? **

Une fois que L2 sera devenu courant, les utilisateurs pourront posséder des actifs sur plusieurs L2 et éventuellement L1 également.

Une fois que les portefeuilles de contrats intelligents seront devenus courants, les "clés" désormais courantes ne seront plus utilisées.

Une fois que ces deux choses se produisent en même temps, les utilisateurs auront besoin d'une méthode qui ne nécessite pas un grand nombre de transactions pour changer les clés de différents comptes.

En particulier, nous avons besoin d'un moyen de traiter les adresses "contrefactuelles" (également appelées "adresses hypothétiques") : les adresses qui ne sont pas encore "enregistrées" sur la chaîne de quelque manière que ce soit, mais qui doivent encore recevoir et conserver des actifs en toute sécurité. .

En fait, nous nous appuyons tous sur ce « paramétrage contrefactuel » des adresses : lorsqu'un utilisateur utilise Ethereum pour la première fois, l'utilisateur peut générer une adresse ETH, et d'autres peuvent payer sur ce compte sans avoir à s'inscrire sur la blockchain. l'adresse (mais vous devrez payer des frais de transaction, vous devrez donc détenir des ETH).

Pour les comptes externes (EOA), en effet, toutes les adresses partent de l'adresse du « paramètre contrefactuel ».

Les adresses "définies de manière contrefactuelle" sont toujours possibles avec les portefeuilles de contrats intelligents, en grande partie grâce à CREATE2, qui vous permet d'avoir une adresse ETH qui ne peut être créée que par un code de contrat intelligent qui correspond à un remplissage de hachage spécifique.

△ Algorithme de calcul d'adresse EIP-1014 (CREATE2).

Cependant, l'introduction des portefeuilles de contrats intelligents apporte également de nouveaux défis : **Les clés d'accès peuvent changer. ** Ce changement est que l'adresse est la valeur de hachage de l'initcode, qui ne peut contenir que la clé de vérification initiale du portefeuille, et la clé de vérification actuelle sera stockée dans le stockage du portefeuille, mais l'enregistrement de stockage ne sera pas automatiquement transféré vers une autre L2.

Si un utilisateur dispose d'adresses sur de nombreux L2, seule l'architecture Separation of Asset and Key Storage Architecture peut aider les utilisateurs à modifier leurs clés.

La structure de cette architecture divisée est que chaque utilisateur dispose (i) d'un "contrat de stockage de clés" (soit sur L1, soit sur une chaîne L2 spécifique) qui stocke les clés de vérification pour tous les portefeuilles et les règles de changement de clés, et (ii) des "contrats de portefeuille " sur L1 et de nombreuses chaînes L2, qui obtiennent des clés de vérification via des lectures inter-chaînes.

Il existe deux manières d'implémenter l'architecture de séparation des ressources et du stockage des clés :

** Version allégée (c'est-à-dire ne vérifie que les clés mises à jour) ** : chaque portefeuille stocke la clé de vérification localement et contient une fonction appelable pour vérifier la preuve inter-chaîne de l'état actuel du magasin de clés et mettre à jour le stockage local. L'authentification clé pour correspondre. L'appel de cette fonction pour obtenir la clé d'authentification actuelle à partir du magasin de clés est requis lors de la première utilisation du portefeuille sur un L2.

• **Avantages : **L'utilisation de preuves inter-chaînes est plus prudente et il n'y aura pas de coûts d'exploitation du réseau trop élevés. Tous les actifs ne peuvent être utilisés qu'avec la clé actuelle, la sécurité est donc toujours garantie.
• **Inconvénients : **Besoin de changer la clé de vérification, le changement de clé en chaîne doit être effectué sur le keystore et chaque portefeuille qui a été initialisé, et peut consommer beaucoup de Gas Fee.

Version complète (c'est-à-dire que chaque transaction est vérifiée) : chaque transaction nécessite une preuve inter-chaîne indiquant la clé actuelle dans le magasin de clés.

• Avantages : La complexité du système est faible et le magasin de clés est mis à jour rapidement.
• **Inconvénients : **Le coût d'exploitation du réseau d'une seule transaction est élevé et il n'est pas facile d'être compatible avec ERC-4337. ERC-4337 ne prend actuellement pas en charge la lecture d'objets modifiables dans les contrats lors de la vérification.

**Qu'est-ce que la preuve croisée ? **

Afin de démontrer la complexité des preuves inter-chaînes, nous avons sélectionné l'un des scénarios d'application les plus complexes pour démontrer et expliquer ce principe technique.Ce scénario d'application complexe est le suivant : la clé est stockée sur un L2, et le portefeuille est sur une autre L2. Si le magasin de clés du portefeuille est sur L1, seule la moitié de cette conception est nécessaire.

Supposons que le magasin de clés est sur Linea et que le portefeuille est sur Kakarot. Le processus de certification complet de la clé de portefeuille doit inclure :

• Preuve de la racine d'état actuelle de Linea, étant donné la racine d'état actuelle d'Ethereum connue de Kakarot.
• Preuve de la clé actuelle dans le magasin de clés, compte tenu de la racine d'état actuelle de Linea.

Il y a deux principales questions d'implémentation épineuses ici : "Quel type de preuve doit être utilisé ? (Est-ce une preuve de Merkle ? Ou autre chose ?)" et "Comment L2 apprend-il la racine d'état L1 la plus proche ?" Ou, "L1 Comment apprendre la racine d'état de L2?"

Alors, dans les deux cas, quel est le délai entre le moment où un événement se produit d'un côté et le moment où l'autre partie est en mesure d'apporter la preuve ?

**Quels sont les schémas de preuve dont nous disposons ? **

Vous avez le choix entre cinq méthodes principales :

• Preuve de Merkle
• Général ZK-SNARK
• Certificat à usage spécial (par exemple, en utilisant KZG)
• Verkle proof, entre KZG et ZK-SNARK, compte tenu à la fois de l'effort d'infrastructure et du coût
• aucune preuve, repose sur la lecture directe de l'état

En termes de travaux d'infrastructure requis et de coûts d'utilisation, ils peuvent être grossièrement classés comme suit :

"Agrégation" fait référence à l'agrégation de toutes les preuves fournies par les utilisateurs dans chaque bloc en une seule grande méta-preuve, en les fusionnant. Cela fonctionne pour les SNARK et les KZG, mais pas pour les fourches Merkle.

En fait, "l'agrégation" n'a de valeur que lorsque la solution compte un grand nombre d'utilisateurs. ‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍

**Comment fonctionnent les preuves de Merkle ? **

Ce problème est très simple et peut être suivi directement par le schéma de la section précédente. Chaque "preuve" (en supposant qu'une L2 se révèle être une autre L2, ce qui est le scénario d'application le plus difficile) comprendra :

Un fork Merkle qui atteste détient la racine d'état du keystore L2, la dernière racine d'état d'Ethereum connue de L2. Les racines d'état contenant le magasin de clés L2 sont stockées dans des emplacements de stockage connus à des adresses connues (contrats L1 représentant L2), de sorte que les chemins peuvent être codés en dur.

Une branche Merkle attestant de la clé de vérification actuelle, selon la racine d'état contenant le magasin de clés L2. De plus, les clés d'authentification sont stockées dans des emplacements connus à des adresses connues, de sorte que les chemins peuvent être codés en dur.

Cependant, les preuves d'état dans Ethereum sont compliquées, mais il existe des bibliothèques qui peuvent être utilisées pour les vérifier, et si vous utilisez ces bibliothèques, le mécanisme n'est pas trop compliqué.

Cependant, le plus grand défi est le coût. **Merkle s'est avéré être très long, et l'arbre Patricia était 3,9 fois plus long que nécessaire - beaucoup plus élevé que le prix de base actuel de 21 000 frais de gaz par transaction.

Cependant, si la preuve est vérifiée sur L2, l'écart s'aggrave. Le calcul à l'intérieur de L2 est bon marché car le calcul est effectué hors chaîne et dans un écosystème avec moins de nœuds que L1.

Nous pouvons calculer ce que cela signifie en examinant la comparaison entre le coût des frais de gaz L1 et le coût des frais de gaz L2 :

À l'heure actuelle, s'il s'agit d'une opération d'envoi relativement simple, le coût sur le réseau L1 est d'environ 15 à 25 fois celui de L2, et le coût de l'échange de jetons est d'environ 20 à 50 fois celui de L2.

L'opération d'envoi simple a une grande quantité de données ; et l'opération d'échange nécessite une puissance de calcul plus élevée, de sorte que l'opération d'échange est une meilleure référence pour estimer le coût du calcul L1 et du calcul L2.

En réunissant ce qui précède, si nous supposons un rapport de coût de 30x entre le coût de calcul L1 et le coût de calcul L2, cela semble impliquer que le coût de mise en place des preuves de Merkle sur L2 pourrait être équivalent à une cinquantaine de transactions régulières.

Bien sûr, l'utilisation d'un arbre Merkle binaire réduirait le coût d'un facteur d'environ 4, mais même dans ce cas, le coût serait toujours prohibitif dans la plupart des cas, et si nous étions prêts à renoncer à la compatibilité avec l'arbre d'état hexa actuel d'Ethereum, cela pourrait Cherchera de meilleures options.

**Comment fonctionne la preuve ZK-SNARK ? **

L'utilisation des ZK-SNARK est également conceptuellement facile à comprendre : il vous suffit de remplacer les preuves de Merkle dans le diagramme ci-dessus par des ZK-SNARK prouvant l'existence de ces preuves de Merkle. Le montant de calcul d'un ZK-SNARK est d'environ 400 000 frais de gaz, environ 400 octets ; une transaction de base nécessite 21 000 frais de gaz et 100 octets.

Par conséquent, d'un point de vue calcul, le coût de ZK-SNARK est 19 fois le coût de transaction de base actuel ; d'un point de vue des données, le coût de ZK-SNARK est 4 fois le coût de transaction de base actuel et 16 fois le coût futur coût de transaction de base.

Ces chiffres représentent une énorme amélioration par rapport aux preuves de Merkle, mais sont encore assez chers. ** Il existe deux façons d'améliorer cette situation : ** (i) des épreuves KZG à usage spécial, ou (ii) l'agrégation, similaire à l'agrégation ERC-4337.

**Comment fonctionne l'épreuve spéciale KZG ? **

Tout d'abord, un récapitulatif du fonctionnement des promesses de KZG :

*[D_1 ...D_n] représente un ensemble de données à travers lequel la preuve polynomiale KZG est dérivée. *

*Plus précisément, le polynôme P, où P(w) = D_1, P(w²) = D_2 ... P(wⁿ) = D_n. w est ici la "racine uniforme", pour une évaluation Champ taille N, valeur wN = 1 (tout cela se fait dans des corps finis). *

• Pour "s'engager" à P, on crée un point de courbe elliptique com(P) = P₀ * G + P₁ * S₁ + ... + Pk * Sk. ici:*

G est le point générateur de la courbe

Pi est le ième coefficient du polynôme P

Si est le ième point dans le paramètre de confiance

*Et pour prouver que P(z) = a, on crée un polynôme quotient Q = (P - a) / (X - z), et on crée un engagement com(Q). Il n'est possible de créer un tel polynôme que si P(z) est effectivement égal à a. *

• Pour vérifier la preuve, on vérifie l'équation Q * (X - z) = P - a en effectuant une vérification de courbe elliptique sur la preuve com(Q) et l'engagement polynomial com(P) : on vérifie e(com( Q), com (X - z)) ? = e(com(P) - com(a), com(1))*

Certaines propriétés clés à connaître également incluent :

La preuve est juste la valeur com(Q), qui est de 48 octets

com（P₁） + com（P₂） = com（P₁ + P₂）

*Cela signifie également que vous pouvez "modifier" la valeur dans un contrat existant. *

• Supposons que nous sachions que D_i est actuellement a, que nous voulons le définir sur b, et que l'engagement existant sur D est com(P). promesse "P, mais P(wⁱ) = b, et aucune autre évaluation ne change", alors nous définissons com(new_P) = com(P) + (ba)*com(Li), où Li est "lag Langerian polynôme", égal à 1 en wⁱ et 0 en d'autres points wj. *

• Pour effectuer ces mises à jour efficacement, chaque client peut précalculer et stocker tous les engagements N envers le polynôme lagrangien (com(Li)). Dans un contrat en chaîne, il peut être trop important de stocker tous les N engagements, vous pouvez donc prendre des engagements KZG sur l'ensemble des valeurs com(L_i), donc chaque fois que quelqu'un a besoin de mettre à jour l'arborescence en chaîne, il peut soumettre simplement à Proper com(L_i) apporte la preuve de son exactitude. *

Donc, ayez une structure qui continue d'ajouter des valeurs à la fin de la liste croissante, mais avec une certaine limite de taille. Ensuite, utilisez cette structure comme structure de données pour (i) les engagements sur la liste des clés de chaque L2, stockés sur cette L2 et mis en miroir sur L1, et (ii) les engagements sur la liste des engagements sur les clés L2, stockées dans Ethereum sur L1 et mis en miroir sur chaque L2.

La mise à jour des engagements peut soit faire partie de la logique de base L2, soit être mise en œuvre via un pont de dépôt et de retrait sans modifier le protocole de base L2.

Une preuve complète nécessite ce qui suit :

1. Stockez la dernière com (liste de clés) du magasin de clés sur L2.
2. Preuve KZG avec com(keylist) comme valeur dans com(mirror list), qui est la liste de tous les engagements de la liste de clés.
3. Créez le certificat KZG de la clé de l'utilisateur dans com (liste de clés).

En fait, les deux preuves KZG ci-dessus peuvent être combinées en une seule avec une taille totale de seulement 100 octets.

Notez un détail : étant donné qu'une liste de clés est une liste, et non une carte clé/valeur comme l'est l'état, la liste de clés doit se voir attribuer des positions dans l'ordre. Le contrat de promesse de clé contiendra son propre registre interne, mappant chaque keystore à un ID, et pour chaque clé, il stockera le hachage (clé, l'adresse du keystore) au lieu de simplement la clé, pour indiquer explicitement aux autres L2 à propos de laquelle keystore auquel une entrée particulière fait référence.

L'avantage de cette technique est qu'elle fonctionne très bien en L2. Environ 4 fois plus court que ZK-SNARK, beaucoup plus court que la preuve Merkle. Le coût de calcul est d'environ 119 000 frais de gaz.

Sur L1, la puissance de calcul est plus importante que les données, donc KZG est légèrement plus cher que la preuve Merkle.

**Comment fonctionnent les arbres Verkle ? **

Les arbres Verkle impliquent essentiellement d'empiler des engagements KZG ensemble : pour stocker 2⁴⁸ valeurs, un engagement KZG peut être fait sur une liste de 2²⁴ valeurs, dont chacune est elle-même un engagement KZG sur 2²⁴ valeurs.

Les arbres Verkle sont pris en compte pour les arbres d'état Ethereum car les arbres Verkle peuvent être utilisés pour contenir des cartes clé-valeur.

Les preuves dans les arbres Verkle sont plus longues que les preuves KZG, elles peuvent faire plusieurs centaines d'octets.

En fait, les arbres Verkle doivent être considérés comme des arbres Merkle, mais sont plus réalisables sans SNARKing, mais il a été démontré que SNARKing a un coût de preuve inférieur.

Le grand avantage des arbres de Verkle est qu'ils peuvent coordonner les structures de données : ils peuvent donc être utilisés directement pour L1 ou L2, il n'y a pas de structure de superposition, et le même mécanisme est utilisé pour L1 et L2.

Une fois que les ordinateurs quantiques deviennent un problème, ou une fois que les branches de Merkle se sont avérées suffisamment efficaces, les arbres de Verkle ont plus d'utilisations.

polymérisation

Si N utilisateurs effectuent N transactions et doivent prouver N réclamations inter-chaînes, nous pouvons économiser beaucoup de frais de gaz en agrégeant ces preuves, ce qui peut signifier :

• Une preuve ZK-SNARK des branches N Merkle
• Un certificat multiple KZG
• Un multi-épreuve Verkle (ou un ZK-SNARK multi-épreuve)

Dans les trois cas, chaque preuve ne coûte que quelques centaines de milliers de frais de gaz.

Les développeurs doivent faire une telle preuve sur chaque L2 pour les utilisateurs de cette L2 ; ainsi, pour que cette preuve soit utile, l'ensemble du schéma doit avoir une utilisation suffisante pour qu'il y ait souvent au moins quelques transactions.

Si des ZK-SNARK sont utilisés, chaque utilisateur peut avoir besoin de dépenser des milliers de frais de gaz L2. Si KZG multi-preuve est utilisé, le vérificateur doit ajouter 48 frais de gaz au L2 de chaque magasin de clés utilisé dans le bloc.

Pourtant, ces coûts sont bien inférieurs à ceux sans agrégation, ce qui implique inévitablement plus de 10 000 frais de gaz L1 et des centaines de milliers de frais de gaz L2 par utilisateur.

Pour l'arbre Verkle, les utilisateurs peuvent utiliser directement Verkle multi-preuve, chaque utilisateur ajoute environ 100 ~ 200 octets, ou vous pouvez faire un ZK-SNARK multi-preuve Verkle, son coût est similaire au ZK-SNARK de la branche Merkle, mais la preuve Il semble évidemment pas cher.

Du point de vue de la mise en œuvre, il serait peut-être préférable de laisser les bundlers agréger les preuves inter-chaînes via la norme d'abstraction de compte ERC-4337. ERC-4337 dispose déjà d'un mécanisme permettant aux constructeurs d'agréger des parties d'opérations utilisateur de manière personnalisée. Il existe même une implémentation pour l'agrégation de signatures BLS, qui peut réduire les frais de gaz L2 de 1,5x à 3x.

Lire le statut directement

Une dernière possibilité, et qui ne s'applique qu'à L2 lisant L1 (plutôt que L1 lisant L2), consiste à modifier L2 afin qu'il effectue directement des appels statiques aux contrats de L1.

Cela peut être fait avec un opcode ou une précompilation qui autorise les appels au L1 où vous fournissez l'adresse cible, le gaz et les données d'appel et il renvoie la sortie, bien que puisque ces appels sont statiques, ils ne peuvent pas réellement changer l'état de L1. L2 doit savoir ce qui se passe avec L1 afin de traiter les dépôts, il n'y a donc rien de fondamental qui empêche cela d'être possible ; c'est surtout un défi de mise en œuvre technique.

Notez que si le magasin de clés est sur L1 et que L2 intègre la fonctionnalité d'appel statique de L1, aucune attestation n'est requise du tout.

Cependant, si L2 n'intègre pas les appels statiques L1, ou si le magasin de clés est sur L2, une preuve est requise.

**Comment L2 apprend-il la racine d'état Ethereum la plus récente ? **

Tous les schémas ci-dessus nécessitent que L2 accède à la racine d'état L1 la plus proche ou à l'ensemble de l'état L1 le plus proche.

En fait, si L2 a une fonction de dépôt, vous pouvez utiliser cette L2 telle quelle pour déplacer la racine de l'état L1 dans un contrat sur L2 : il suffit que le contrat sur L1 appelle l'opcode BLOCKHASH et le dépose en tant qu'actif Le message est passé à L2. L'en-tête de bloc complet peut être reçu du côté L2 et sa racine d'état extraite.

Cependant, chaque L2 a de préférence un moyen explicite d'accéder directement au dernier état L1 complet ou à la racine d'état L1 la plus proche.

Le principal défi dans l'optimisation de la façon dont L2 reçoit la dernière racine d'état L1 est d'atteindre la sécurité et une faible latence en même temps :

• Si L2 met du temps à implémenter la fonctionnalité de lecture directe L1, en ne lisant que la racine d'état L1 finale, le délai est généralement de 15 minutes, mais dans certains cas extrêmes, le délai peut être de plusieurs semaines.
• L2 peut certainement être conçu pour lire les racines d'état L1 mises à jour, mais comme L1 peut récupérer (ce qui se produit lors de fuites inactives même avec une finalité à socket unique), L2 doit également pouvoir récupérer. Du point de vue de l'ingénierie logicielle, c'est techniquement difficile.
• Si un pont est utilisé pour amener les racines d'état L1 dans L2, les mises à jour des actifs prennent très longtemps, dans le meilleur des cas, il y a des utilisateurs constants qui paient pour les mises à jour et maintiennent le système à jour pour tout le monde.
• Les oracles ne sont cependant pas une solution acceptable ici : la gestion des clés de portefeuille est une fonction de bas niveau très critique pour la sécurité, elle devrait donc tout au plus s'appuyer sur quelques infrastructures de bas niveau très simples et cryptographiquement sans confiance.

Aussi, dans le sens inverse (L1 lit L2) :

• Dans Optimistic Rollup, la racine d'état prend une semaine pour atteindre L1 en raison de retards de preuve de fraude. Dans les cumuls ZK, cela prend désormais des heures en raison d'une combinaison de temps de vérification et de contraintes économiques, bien que la technologie future réduise cela.
• La pré-confirmation (du séquenceur, certificateur, etc.) n'est pas une solution acceptable pour L1 lit L2. La gestion de portefeuille est une fonction de bas niveau très critique pour la sécurité, de sorte que le niveau de sécurité des communications L2 à L1 doit être absolument élevé. La seule racine d'état à laquelle L1 doit faire confiance est celle qui a été acceptée comme racine d'état finale par le contrat de maintien de la racine d'état de L2 sur L1.

Certains d'entre eux sont d'une lenteur inacceptable pour les opérations inter-chaînes sans confiance pour de nombreux cas d'utilisation DeFi. Cependant, pour le cas d'utilisation de la mise à jour des clés de portefeuille, des délais plus longs sont plus acceptables - car au lieu de retarder les transactions, cela retarde les changements de clé.

Les utilisateurs doivent simplement conserver l'ancienne clé plus longtemps. Si l'utilisateur change la clé parce qu'elle a été volée, alors il y a en effet une longue période de vulnérabilité, mais elle peut être atténuée, par ex. Via un portefeuille avec fonctionnalité de gel.

En fin de compte, la meilleure solution de minimisation de la latence consiste à ce que L2 implémente de manière optimale les lectures directes de la racine d'état L1, où chaque bloc L2 (ou journal de calcul de racine d'état) contient un pointeur vers le dernier bloc L1, donc si L1 récupère, et L2 peut aussi récupérer. Le contrat de magasin de clés doit être placé sur le réseau principal ou sur L2 de ZK-rollup afin qu'il puisse être rapidement engagé sur L1.

** De combien de connexion à Ethereum l'autre chaîne a-t-elle besoin pour conserver le magasin de clés stocké dans Ethereum ou le portefeuille L2 ? **

Étonnamment, pas tant que ça. En fait, il n'est même pas nécessaire qu'il s'agisse d'un Rollup.

S'il s'agit d'un L3 ou d'un validium, vous pouvez y stocker des portefeuilles, tant que les utilisateurs stockent le stockage des clés sur L1 ou ZK-rollup, ils doivent vraiment pouvoir accéder directement à la racine d'état d'Ethereum et sont prêts à stocker dans Ethereum Lors de la refactorisation, hard fork quand Ethereum hard fork.

Les schémas basés sur des ponts ZK ont des propriétés techniques attrayantes, mais ils ont une faiblesse clé en ce sens qu'ils ne sont pas robustes contre les attaques à 51% ou les hard forks.

la protection de la vie privée

Idéalement, les utilisateurs souhaitent également la confidentialité. Si un utilisateur possède plusieurs portefeuilles gérés par le même keystore, il souhaite s'assurer que :

• Empêchez le public de savoir que ces portefeuilles sont tous connectés les uns aux autres.
• Les tuteurs de récupération sociale ne sauront pas à quelle adresse ils sont sous tutelle.

Mais cela crée un problème :

• Nous ne pouvons pas utiliser les preuves Merkle directement car elles ne préservent pas la confidentialité.
• Si nous utilisons KZG ou SNARK, la preuve doit fournir une version aveugle de la clé de vérification sans révéler l'emplacement de la clé de vérification.
• Si nous utilisons l'agrégation, l'agrégateur ne devrait pas connaître l'emplacement en clair ; à la place, l'agrégateur devrait recevoir des preuves aveugles et avoir un moyen d'agréger ces preuves.
• Nous ne pouvons pas utiliser une "version allégée" (attestation inter-chaînes uniquement lors de la ressaisie des clés), car cela créerait une fuite de confidentialité : si de nombreux portefeuilles sont mis à jour en même temps en raison de la mise à jour, alors le timing de ces portefeuilles peuvent être des informations connexes. Par conséquent, nous devons utiliser la "version complète" (preuve inter-chaîne de chaque transaction).

Pour les SNARK, la solution est conceptuellement simple : les preuves cachent des informations par défaut, et les agrégateurs doivent produire des SNARK récursifs pour prouver les SNARK.

Le principal défi actuel avec cette approche est que l'agrégation nécessite que l'agrégateur crée un SNARK récursif, ce qui est plutôt lent.

Pour KZG, nous pouvons utiliser la non-indexation pour révéler le travail de la preuve KZG. Cependant, l'agrégation aveugle est un problème ouvert qui nécessite plus d'attention.

Cependant, bien que la lecture directe de L1 à partir de L2 ne protège pas la confidentialité, la mise en œuvre de cette capacité de lecture directe serait toujours très utile, non seulement pour minimiser la latence, mais pour de nombreux autres cas d'utilisation.