Dans mon article précédent sur les trois changements, j'ai décrit certaines des principales raisons pour lesquelles il est utile de commencer à penser explicitement à la prise en charge L1 + cross-L2, à la sécurité du portefeuille et à la confidentialité en tant que caractéristiques fondamentales nécessaires de la pile de l'écosystème. Les choses sont construites comme des plugins. qui peut être conçu individuellement par un seul portefeuille.
Cet article se concentrera plus directement sur les aspects techniques d'un sous-problème spécifique, tel que : comment lire plus facilement L1 à partir de L2, L2 à partir de L1 ou L2 à partir d'une autre L2. Il est essentiel de résoudre ce problème pour activer les architectures de séparation actifs/keystore, mais il existe également des cas d'utilisation précieux dans d'autres domaines, notamment l'optimisation de chaînes d'appels inter-L2 fiables, y compris des cas d'utilisation tels que le déplacement d'actifs entre L1 et L2.
Ce catalogue d'articles
Quel est l'objectif ?
À quoi ressemble la preuve inter-chaînes ?
Quel type de schéma de preuve peut-on utiliser ?
Preuve Merkle
ZK SNARK
Certificat KZG dédié
Preuve d'arbre Verkle
polymérisation
lecture directe de l'état
Comment L2 apprend-il la racine d'état Ethereum la plus récente ?
Portefeuilles sur des chaînes non L2
la protection de la vie privée
Résumer
1. Quel est l'objectif ?
Une fois que L2 sera devenu courant, les utilisateurs posséderont des actifs sur plusieurs L2, et éventuellement sur des L1 également. Une fois que les portefeuilles de contrats intelligents (multisig, récupération sociale ou autre) seront devenus courants, les clés nécessaires pour accéder à certains comptes changeront au fil du temps, et les anciennes clés n'auront plus besoin d'être valides. Une fois que ces deux choses se produiront, les utilisateurs auront besoin d'un moyen de changer les clés qui ont accès à de nombreux comptes situés dans de nombreux endroits différents sans effectuer un nombre extrêmement élevé de transactions.
En particulier, nous avons besoin d'un moyen de traiter les adresses contrefactuelles : les adresses qui n'ont en aucun cas été "enregistrées" sur la chaîne, mais qui doivent néanmoins recevoir et conserver des fonds en toute sécurité. Nous nous appuyons tous sur des adresses contrefactuelles : lorsque vous utilisez Ethereum pour la première fois, vous pouvez générer une adresse ETH que quelqu'un peut utiliser pour vous payer sans "enregistrer" l'adresse en chaîne (cela nécessite de payer un txfee, donc détenez déjà des ETH).
Pour EOA, toutes les adresses commencent par une adresse contrefactuelle. Avec les portefeuilles de contrats intelligents, les adresses contrefactuelles sont toujours possibles grâce en grande partie à CREATE2, qui vous permet d'avoir une adresse ETH qui ne peut être remplie que par un contrat intelligent avec un code qui correspond à un hachage spécifique.
Algorithme de calcul d'adresse EIP-1014 (CREATE2)
Cependant, les portefeuilles de contrats intelligents introduisent un nouveau défi : la possibilité de changer de clé d'accès. Cette adresse est un hachage de l'initcode et ne peut contenir que la clé de vérification initiale du portefeuille. La clé de vérification actuelle sera stockée dans le stockage du portefeuille, mais cet enregistrement de stockage ne se propagera pas comme par magie vers d'autres L2.
Si un utilisateur a de nombreuses adresses sur plusieurs L2, y compris des adresses inconnues du L2 sur lequel il se trouve (car elles sont contrefactuelles), alors il semble n'y avoir qu'un seul moyen de permettre aux utilisateurs de changer leurs clés : une architecture de séparation actif/keystore. Chaque utilisateur a (i) un "contrat de magasin de clés" (soit sur L1, soit sur un 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" qui lisent les chaînes pour les clés de vérification.
Il existe deux façons d'y parvenir :
Version allégée (vérifie uniquement les clés mises à jour) : chaque portefeuille stocke la clé de vérification localement et contient une fonction qui peut être appelée pour vérifier la preuve inter-chaîne de l'état actuel du magasin de clés et mettre à jour sa clé de clé de vérification stockée localement pour correspondre. Lorsque le portefeuille est utilisé pour la première fois sur un L2 particulier, cette fonction doit être appelée pour obtenir la clé d'authentification actuelle à partir du magasin de clés.
-Avantages : les épreuves inter-chaînes sont utilisées avec parcimonie, donc peu importe si les épreuves inter-chaînes sont chères. Tous les fonds ne peuvent être utilisés qu'avec la clé actuelle, ils restent donc en sécurité.
Inconvénient : pour changer la clé de vérification, vous devez effectuer un changement de clé en chaîne dans le magasin de clés et dans chaque portefeuille initialisé (mais pas un portefeuille contrefactuel). Cela peut coûter beaucoup de gaz.
Version lourde (vérifiez chaque tx) : chaque transaction nécessite une preuve inter-chaîne indiquant la clé actuelle dans le magasin de clés.
Avantages : moins de complexité du système, mises à jour bon marché du keystore.
Inconvénients : la transmission unique coûte cher, il faut donc plus d'ingénierie pour rendre les preuves inter-chaînes beaucoup moins chères. Également pas facilement compatible avec ERC-4337, qui ne prend actuellement pas en charge la lecture d'objets modifiables dans les contrats lors de la vérification.
2. À quoi ressemble la preuve inter-chaînes ?
Pour démontrer toute la complexité, nous allons explorer le cas le plus difficile : keystore sur une L2, wallet sur une autre L2. Seule la moitié de cette conception est nécessaire si le magasin de clés du portefeuille est sur L1.
Supposons que le magasin de clés est sur Linea et que le portefeuille est sur Kakarot. Une preuve complète de la clé du portefeuille comprend :
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 principaux problèmes de mise en œuvre délicats ici :
Quel type de preuves utilisons-nous ? (Est-ce une preuve de Merkel ? Quelque chose d'autre ?
Comment L2 apprend-il d'abord la racine d'état L1 (Ethereum) la plus proche (ou, comme nous le verrons, éventuellement l'état L1 complet) ? Ou, comment L1 apprend-il les racines d'état L2 ?
Dans les deux cas, quel est le délai entre ce qui se passe d'un côté et ce qui est démontrable de l'autre ?
3. Quels types de schémas de preuve pouvons-nous utiliser ?
Il existe cinq options principales :
-Preuve de Merkle
-Général ZK-SNARK
Preuve dédiée (par exemple en utilisant KZG)
-Verkle démontre qu'ils se situent entre KZG et ZK-SNARK en termes de charge de travail et de coût de l'infrastructure.
Aucune preuve requise, s'appuie sur la lecture directe de l'état
En termes de travail d'infrastructure requis et de coût d'utilisation, je les classerais approximativement comme suit :
"Agrégation" fait référence à l'agrégation de toutes les preuves fournies par les utilisateurs dans chaque bloc en une grande méta-preuve qui combine toutes les preuves. C'est possible avec SNARK et KZG, mais pas avec les fourches Merkle (vous pouvez combiner un peu les fourches Merkle, mais cela ne vous permet d'économiser que log(txs par bloc)/log(nombre total de keystores), en pratique c'est probablement 15-30% au milieu, donc ça ne vaut probablement pas le prix).
L'agrégation ne devient utile que lorsque le scénario compte un grand nombre d'utilisateurs, donc en pratique, une implémentation de la version 1 pourrait omettre l'agrégation et l'implémenter dans la version 2.
4. Comment fonctionneront les preuves de Merkle ?
Celui-ci est simple : suivez simplement le schéma de la section précédente. Plus précisément, chaque "preuve" (en supposant le cas de prouver la difficulté maximale d'une L2 à une autre L2) contiendra :
Une branche Merkle attestant de la racine d'état de L2 contenant le keystore, étant donné la dernière racine d'état d'Ethereum connue de L2. Le magasin de clés contient la racine d'état de L2 stockée dans un emplacement de stockage connu à une adresse connue (le contrat sur L1 représente L2), de sorte que le chemin à travers l'arborescence peut être codé en dur.
Une branche Merkle attestant de la clé de vérification actuelle, compte tenu de la racine d'état de L2 contenant le magasin de clés. Là encore, la clé d'authentification est stockée dans un emplacement de stockage connu à une adresse connue, de sorte que le chemin peut être codé en dur.
Malheureusement, les preuves d'état Ethereum sont complexes, mais des bibliothèques existent pour les valider, et si vous utilisez ces bibliothèques, ce mécanisme n'est pas trop compliqué à mettre en œuvre.
** Le plus gros problème est le coût. ** Les preuves de Merkle sont très longues, malheureusement l'arbre de Patricia est ~3,9 fois plus long que nécessaire (pour être exact : une preuve de Merkle idéale pour un arbre contenant N objets est longue de 32 * log2(N) octets, et parce que les arbres de Patricia d'Ethereum ont 16 feuilles par enfant, et la preuve de ces arbres est de 32 * 15 * log16(N) ~= 125 * log2(N) octets). Dans un État comptant environ 250 millions (~2²⁸) de comptes, cela fait de chaque preuve 125 * 28 = 3500 octets, soit environ 56 000 gaz, plus le coût supplémentaire du décodage et de la vérification du hachage.
Ensemble, les deux preuves coûteraient environ 100 000 à 150 000 gaz (si elles sont utilisées par transaction, hors vérification de signature) - bien plus que le prix de base actuel de 21 000 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 beaucoup moins de nœuds que L1. En revanche, les données doivent être publiées en L1. La comparaison n'est donc pas 21 000 gaz contre 15 000 gaz ; c'est 21 000 gaz L2 contre 100 000 gaz L1.
Nous pouvons calculer ce que cela signifie en regardant la comparaison entre le coût du gaz L1 et le coût du gaz L2 :
Actuellement, L1 est 15 à 25 fois plus cher que L2 pour un envoi simple et 20 à 50 fois plus cher pour les échanges de jetons. L'envoi simple est une quantité relativement importante de données, mais la quantité de calcul d'échange est beaucoup plus grande. Par conséquent, le swap est une meilleure référence pour le coût approximatif du calcul L1 par rapport au calcul L2. Compte tenu de tout cela, 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 d'une preuve Merkle sur L2 pourrait être équivalent à 50 transactions régulières.
Bien sûr, l'utilisation d'arbres Merkle binaires réduit le coût d'un facteur de ~ 4, mais même dans ce cas, dans la plupart des cas, le coût est trop élevé - si nous sommes prêts à sacrifier la non-compatibilité avec l'arbre d'état hexagonal actuel d'Ethereum, nous recherchons meilleures options.
5. Comment fonctionnera 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. Un ZK-SNARK nécessite ~400 000 GAS pour le calcul, ce qui prend environ 400 octets (par rapport à : une transaction de base nécessite 21 000 gaz et 100 octets, qui peuvent être réduits à ~25 mots après compression dans le futur Festival). Par conséquent, d'un point de vue informatique, le coût des ZK-SNARK est 19 fois le coût des transactions de base d'aujourd'hui, et du point de vue des données, le coût des ZK-SNARK est 4 fois celui des transactions de base d'aujourd'hui et 16 fois le coût des futures transactions de base fois.
Ces chiffres sont une grande amélioration par rapport à la preuve de Merkel, mais ils sont encore assez chers. Il existe deux façons d'améliorer cela : (i) des preuves KZG à usage spécial, ou (ii) l'agrégation, similaire à l'agrégation ERC-4337 mais en utilisant des mathématiques plus sophistiquées. On peut étudier les deux en même temps.
6. Comment fonctionneront les épreuves KZG spéciales ?
Attention, cette section est plus mathématique que les autres. C'est parce que nous allons au-delà des outils à usage général et que nous construisons des outils spéciaux moins chers, nous devons donc aller plus « sous le capot ». Si les mathématiques approfondies ne vous conviennent pas, passez directement à la section suivante.
Tout d'abord, un récapitulatif du fonctionnement des engagements KZG :
Nous pouvons représenter un ensemble de données [D_1...D_n] en utilisant la preuve KZG d'un polynôme dérivé des données : plus précisément, le polynôme P, où P(w) = D_1, P(w²) = D _2 ... P(wⁿ) = D_n. w ici est la "racine uniforme", la valeur de wN = 1 pour une taille de domaine d'évaluation N (tout cela se fait dans des corps finis).
Pour "s'engager" sur 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 la configuration de confiance
Pour prouver que P(z) = a, nous créons un polynôme quotient Q = (P - a) / (X - z), et créons 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 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 de Lagrange (com(Li)). Dans un contrat en chaîne, il peut être trop important de stocker tous les engagements N, vous pouvez donc prendre un engagement KZG pour l'ensemble de valeurs com(L_i) (ou hash(com(L_i)), donc chaque fois que quelqu'un a besoin Lors de la mise à jour de l'arborescence de la chaîne, ils peuvent simplement fournir la preuve de leur exactitude au com(L_i) approprié.
Nous avons donc une structure dans laquelle nous pouvons continuer à ajouter des valeurs à la fin de la liste croissante, mais avec une certaine limite de taille (en fait, des centaines de millions pourraient être faisables). Nous l'utilisons ensuite comme structure de données pour gérer (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 d'engagements de clés L2, stockés sur Ethereum L1 et miroir à chaque L2.
La mise à jour des engagements peut faire partie de la logique de base L2 ou être mise en œuvre via un pont de dépôt et de retrait sans modifier le protocole de base L2.
Par conséquent, une preuve complète nécessite :
Le magasin de clés contient la dernière com (liste de clés) sur L2 (48 octets)
-KZG prouve que com(liste de clés) est com(valeur dans mirror_list), engagement envers toutes les listes de soumission de listes de clés (48 octets)
-KZG prouve que votre clé est dans com (liste de clés) (48 octets, plus 4 octets pour l'index)
Il est en fait possible de combiner deux preuves KZG en une seule, nous obtenons donc une taille totale de seulement 100 octets.
Notez une subtilité : parce 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 d'engagement de clé contiendra son propre registre interne, mappant chaque keystore à un ID, et pour chaque clé, il stockera le hachage (adresse du keystore) au lieu de simplement la clé, afin de communiquer explicitement avec les autres L2 quel keystore une entrée particulière parle.
L'avantage de cette technique est qu'elle fonctionne très bien en L2. Les données sont de 100 octets, ce qui est ~ 4 fois plus court que les ZK-SNARK et plus court que les preuves Merkle. Le coût du calcul est principalement d'une vérification de paire, soit environ 119 000 gaz. Sur L1, les données sont moins importantes que le calcul, donc malheureusement les KZG sont un peu plus chers que les preuves de Merkle.
7. Comment fonctionnera l'arbre Verkle ?
Les arbres Verkle impliquent essentiellement d'empiler des engagements KZG (ou engagements IPA, qui peuvent être plus efficaces et utiliser un cryptage plus simple) : pour stocker 2⁴⁸ valeurs, vous faites un engagement KZG sur une liste de 2²⁴ valeurs, dont chacune est elle-même un engagement KZG à 2²⁴ Valeur. Les arbres Verkle sont fortement pris en compte pour les arbres d'état Ethereum, car les arbres Verkle peuvent être utilisés pour contenir des cartes clé-valeur, pas seulement des listes (en gros, vous pouvez créer un arbre de taille 2²⁵⁶ mais commencer vide, uniquement si vous ne remplissez que des parties spécifiques du arbre lorsque vous avez réellement besoin de les remplir).
À quoi ressemble un arbre Vicker. En fait, vous pouvez donner à chaque nœud une largeur de 256 == 2⁸ pour les arbres basés sur IPA, et 2²⁴ pour les arbres basés sur KZG.
Les preuves dans les arbres Verkle sont un peu plus longues que dans KZG ; elles peuvent faire plusieurs centaines d'octets. Ils sont également difficiles à vérifier, surtout si vous essayez d'agréger plusieurs preuves en une seule.
En fait, les arbres Verkle doivent être considérés comme des arbres Merkle, mais plus réalisables sans SNARKing (en raison du coût inférieur des données), et SNARKing est moins cher (en raison du coût de preuve inférieur).
Le plus grand avantage des arbres Verkle est qu'ils peuvent coordonner les structures de données : les preuves Verkle peuvent être utilisées directement pour les états L1 ou L2, n'ont pas de structure de superposition et utilisent exactement le même mécanisme pour L1 et L2. Une fois que les ordinateurs quantiques deviennent un problème, ou une fois que la ramification de Merkle s'avère suffisamment efficace, les arbres de Verkle peuvent être remplacés sur place par des arbres de hachage binaires avec des fonctions de hachage adaptées à SNARK.
8. Agrégats
Si N utilisateurs effectuant N transactions (ou plus réaliste, N ERC-4337 UserOperations) doivent prouver N revendications inter-chaînes, nous pouvons économiser beaucoup d'argent en agrégeant ces preuves : en combinant ces transactions dans un bloc ou le constructeur du bundle qui entre dans le bloc peut créer une preuve qui prouve toutes ces affirmations en même temps.
Cela pourrait signifier :
Preuves ZK-SNARK pour les branches N Merkle
Une multi-épreuve KZG
Un Verkle multi-épreuve (ou multi-épreuve ZK-SNARK)
Dans les trois cas, chaque épreuve ne nécessite que quelques centaines de milliers de gaz. Le constructeur doit en créer un sur chaque L2 pour les utilisateurs de cette L2 ; ainsi, pour faciliter la construction, l'ensemble du schéma doit être suffisamment utilisé pour qu'il y ait généralement au moins quelques transactions dans le même bloc sur plusieurs échanges majeurs de L2. .
Si des ZK-SNARK sont utilisés, le principal coût marginal est simplement la « logique commerciale » de passer des numéros entre les contrats, de sorte que chaque utilisateur peut avoir besoin de plusieurs milliers de gaz L2. Si KZG multi-preuve est utilisé, le prouveur doit ajouter 48 gaz pour chaque magasin de clés contenant L2 utilisé dans le bloc, de sorte que le coût marginal du schéma par utilisateur sera par L2 (et non par utilisateur), puis ajouté ~ 800 gaz L1 . Mais ces coûts sont beaucoup plus faibles que sans agrégation, ce qui implique inévitablement plus de 10 000 gaz L1 et des centaines de milliers de gaz L2 par utilisateur. Pour les arbres Verkle, vous pouvez utiliser directement les multi-preuves Verkle, en ajoutant environ 100 à 200 octets par utilisateur, ou vous pouvez créer des multi-preuves ZK-SNARK de Verkle, qui coûtent de la même manière que les ZK-SNARK de la branche Merkle, mais la preuve coûte beaucoup moins cher.
Du point de vue de la mise en œuvre, il est préférable pour les bundlers d'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'actions utilisateur de manière personnalisée. Il existe même une implémentation pour l'agrégation de signature BLS, qui peut réduire les coûts de gaz sur L2 d'un facteur de 1,5 à 3, selon les autres formes de compression incluses.
Diagramme de la publication sur la mise en œuvre du portefeuille BLS montrant le flux de travail pour les signatures agrégées BLS dans une première version d'ERC-4337. Le flux de travail pour l'agrégation des preuves inter-chaînes peut sembler très similaire.
9. Lecture directe de l'état
Une dernière possibilité, également disponible uniquement pour L2 lisant L1 (et non L1 lisant L2), consiste à modifier L2 afin qu'ils effectuent directement des appels statiques aux contrats sur L1.
Cela peut être fait avec des opcodes ou une précompilation, ce qui permet d'appeler le L1, où vous fournissez l'adresse cible, le gaz et les données d'appel, et il renvoie la sortie, mais comme ces appels sont statiques, ils ne peuvent réellement changer aucun état L1. L2 doit savoir que L1 a déjà traité le dépôt, donc rien n'empêche une telle chose d'être mise en œuvre ; il s'agit principalement d'un défi de mise en œuvre technique (voir : ceci d'un appel d'offres optimiste pour prendre en charge les appels statiques vers L1).
Notez que si le magasin de clés est sur L1 et que L2 intègre des appels statiques L1, aucune attestation n'est requise ! Cependant, si L2 n'intègre pas les appels statiques L1, ou si le magasin de clés est sur L2 (ce qui peut éventuellement devoir être fait une fois que L1 devient trop cher pour que les utilisateurs l'utilisent même un peu), alors une preuve sera requise.
10. 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. Heureusement, tous les L2 ont déjà des fonctionnalités pour accéder au dernier état L1. En effet, ils ont besoin de telles fonctionnalités pour gérer les messages de L1 à L2, en particulier les dépôts.
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 : demandez simplement au contrat sur L1 d'appeler l'opcode BLOCKHASH et de le transmettre à L2 en tant que message de dépôt. . 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 implémente la fonctionnalité "lire directement L1" de manière paresseuse, en ne lisant que la racine d'état L1 finale, le délai est généralement de 15 minutes, mais dans les cas extrêmes de fuites d'inactivité (que vous devez tolérer), le délai peut être des 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, mais au moins Optimistic en a la capacité.
Si vous utilisez un pont de dépôt pour amener les racines de l'état L1 dans L2, alors l'économie simple peut nécessiter beaucoup de temps entre les mises à jour de dépôt : si le coût total d'un dépôt est de 100 000 gaz, supposons 1 800 $ en ETH et des frais de 200 gwei, et les racines L1 entrent dans L2 une fois par jour, cela coûterait 236 $ par L par jour, ou 13 148 $ par L2 par an pour maintenir le système. Une heure de retard coûte la modique somme de 315 569 $ par L2 et par an. Au mieux, il y a un flux constant d'utilisateurs riches impatients qui paient pour mettre à jour et maintenir le système à jour pour tous les autres. Au pire, certains acteurs altruistes devront payer eux-mêmes.
"Oracles" (du moins la technologie que certains DeFi appellent "oracles") ne sont 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 dépendre au maximum de plusieurs A très simple, infrastructure de bas niveau qui ne nécessite aucune confiance cryptographique.
Aussi, dans la direction opposée (L1s se lit comme L2):
Dans Optimistic Aggregation, les racines d'état prennent 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 du portefeuille est une fonction de bas niveau très critique pour la sécurité, de sorte que le niveau de sécurité de la communication L2 - L1 doit être absolu : il n'est même pas possible de pousser une mauvaise racine d'état L1 en prenant en charge l'ensemble de validateurs L2. 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.
Pour de nombreux cas d'utilisation DeFi, certains d'entre eux sont d'une lenteur inacceptable pour les opérations inter-chaînes sans confiance ; pour ces cas, vous avez vraiment besoin de ponts plus rapides avec des modèles de sécurité plus imparfaits. Cependant, pour le cas d'utilisation de la mise à jour des clés de portefeuille, des délais plus longs sont plus acceptables : au lieu de retarder les transactions pendant des heures, vous retardez les changements de clés. Vous avez juste besoin de garder l'ancienne clé plus longtemps. Si vous changez votre clé parce qu'elle a été volée, vous avez une vulnérabilité pendant longtemps, mais elle peut être atténuée, par exemple. 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. Les contrats de magasin de clés doivent être placés sur le réseau principal ou sur L2 de ZK Rollup afin qu'ils puissent être rapidement validés sur L1.
Les blocs de la chaîne L2 peuvent dépendre non seulement des blocs L2 précédents, mais également des blocs L1. Si L1 récupère sur un tel lien, L2 récupère également. Il convient de noter que c'est également ainsi que les versions antérieures (pré-Dank) du sharding étaient censées fonctionner ; voir ici pour le code.
11. De quelle connexion à Ethereum une autre chaîne a-t-elle besoin pour détenir un magasin de clés enraciné dans Ethereum ou un portefeuille L2 ?
Étonnamment, pas tant que ça. Il n'a même pas besoin d'être un rollup en fait : s'il s'agit de L3 ou de validation, c'est bien d'y conserver un portefeuille, tant que vous détenez le keystore sur un rollup L1 ou ZK. Ce dont vous avez vraiment besoin, c'est que la chaîne ait un accès direct à la racine d'état d'Ethereum, et un engagement technique et social pour être prêt à se réorganiser si Ethereum se réorganise, et à hard fork si Ethereum hard fork.
Une question de recherche intéressante est de déterminer dans quelle mesure une chaîne peut avoir cette forme de connexion avec plusieurs autres chaînes (par exemple, Ethereum et Zcash). Faire cela naïvement est possible : si Ethereum ou Zcash se réorganise, votre chaîne peut accepter de se réorganiser (et hard fork si Ethereum ou Zcash hard forks), mais vos opérateurs de nœuds et votre communauté ont généralement deux fois des dépendances technologiques et politiques. Par conséquent, cette technique peut être utilisée pour se connecter à d'autres chaînes, mais à un coût accru. Les schémas basés sur des ponts ZK ont des propriétés techniques attrayantes, mais leur principale faiblesse est qu'ils ne sont pas robustes aux attaques à 51% ou aux hard forks. Il peut aussi y avoir des solutions plus intelligentes.
12. Protection de la vie privée
Idéalement, nous voulons aussi préserver la vie privée. Si vous avez plusieurs portefeuilles gérés par le même magasin de clés, nous voulons nous assurer que :
Il n'est pas clair que ces portefeuilles soient tous connectés les uns aux autres.
Les Gardiens de la Réinsertion Sociale ne savent pas quelle adresse ils protègent.
Cela crée quelques problèmes :
Nous ne pouvons pas utiliser les preuves Merkle directement car elles ne protègent pas la vie privée.
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 apprendre les positions dans le texte 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" (renouveler les clés en utilisant uniquement des preuves inter-chaînes), car cela crée une fuite de confidentialité : si de nombreux portefeuilles sont mis à jour en même temps en raison du processus de mise à jour, le temps laisse échapper des informations qui peuvent être pertinentes pour ces portefeuilles.
Par conséquent, nous devons utiliser la "version lourde" (preuve inter-chaîne de chaque transaction).
Avec les SNARK, la solution est conceptuellement simple : par défaut, les preuves sont masquées et les agrégateurs doivent générer des SNARK récursifs pour prouver les SNARK.
Le principal défi avec cette approche actuellement est que l'agrégation nécessite que l'agrégateur crée un SNARK récursif, qui est actuellement très lent.
Avec KZG, nous pouvons utiliser ce travail (voir aussi : une version plus formelle de ce travail dans l'article de Caulk) sur des preuves KZG révélatrices non indexées comme point de départ. Cependant, l'agrégation de preuves aveugles est un problème ouvert qui nécessite plus d'attention.
Malheureusement, lire L1 directement à partir de L2 ne préserve pas la confidentialité, bien que la mise en œuvre de la fonctionnalité de lecture directe soit toujours très utile, à la fois pour minimiser la latence et en raison de son utilité pour d'autres applications.
13. Résumé
Pour avoir un portefeuille de récupération sociale inter-chaînes, le flux de travail le plus réaliste est un portefeuille qui maintient un magasin de clés à un endroit, et un portefeuille qui maintient des portefeuilles dans de nombreux endroits, où le portefeuille lit le magasin de clés pour (i) mettre à jour sa clé d'authentification localement vue, ou (ii) dans le processus de validation de chaque transaction.
Un élément clé qui rend cela possible est les preuves inter-chaînes. Nous devons travailler sur l'optimisation de ces preuves. Les ZK-SNARK ou les solutions KZG personnalisées en attente de la preuve de Verkle semblent être les meilleures options.
À long terme, un protocole d'agrégation (où les bundlers génèrent des preuves agrégées dans le cadre de la création d'un bundle de toutes les actions utilisateur soumises par les utilisateurs) est nécessaire pour minimiser les coûts. Cela devrait probablement être intégré dans l'écosystème ERC-4337, bien que des modifications à ERC-4337 puissent être nécessaires.
L2 doit être optimisé pour minimiser la latence de lecture de l'état L1 (ou au moins de la racine d'état) à partir de L2. Il est idéal pour les L2 de lire directement l'état L1, ce qui permet d'économiser de l'espace de preuve.
Les portefeuilles peuvent non seulement être sur L2 ; vous pouvez également placer des portefeuilles sur des systèmes avec un niveau inférieur de connectivité à Ethereum (L3, ou même simplement accepter d'inclure la racine d'état Ethereum et une chaîne de fourches indépendante).
Cependant, le magasin de clés doit être sur L1 ou sur le cumul ZK haute sécurité L2. L'utilisation de L1 permet d'économiser beaucoup de complexité, mais même cela peut être trop coûteux à long terme, donc un magasin de clés doit être utilisé sur L2.
Préserver la vie privée demandera un travail supplémentaire et rendra certains choix plus difficiles. Cependant, nous devrions probablement nous tourner de toute façon vers des solutions de protection de la vie privée, en nous assurant au moins que tout ce que nous proposons est compatible avec la préservation de la vie privée.
Voir l'original
Le contenu est fourni à titre de référence uniquement, il ne s'agit pas d'une sollicitation ou d'une offre. Aucun conseil en investissement, fiscalité ou juridique n'est fourni. Consultez l'Avertissement pour plus de détails sur les risques.
Buterin : aperçu des lectures cross-L2 pour les portefeuilles et autres cas d'utilisation
Auteur : Vitalik Buterin Compilation : Blockchain vernaculaire
Dans mon article précédent sur les trois changements, j'ai décrit certaines des principales raisons pour lesquelles il est utile de commencer à penser explicitement à la prise en charge L1 + cross-L2, à la sécurité du portefeuille et à la confidentialité en tant que caractéristiques fondamentales nécessaires de la pile de l'écosystème. Les choses sont construites comme des plugins. qui peut être conçu individuellement par un seul portefeuille.
Cet article se concentrera plus directement sur les aspects techniques d'un sous-problème spécifique, tel que : comment lire plus facilement L1 à partir de L2, L2 à partir de L1 ou L2 à partir d'une autre L2. Il est essentiel de résoudre ce problème pour activer les architectures de séparation actifs/keystore, mais il existe également des cas d'utilisation précieux dans d'autres domaines, notamment l'optimisation de chaînes d'appels inter-L2 fiables, y compris des cas d'utilisation tels que le déplacement d'actifs entre L1 et L2. Ce catalogue d'articles Quel est l'objectif ? À quoi ressemble la preuve inter-chaînes ? Quel type de schéma de preuve peut-on utiliser ? Preuve Merkle ZK SNARK Certificat KZG dédié Preuve d'arbre Verkle polymérisation lecture directe de l'état Comment L2 apprend-il la racine d'état Ethereum la plus récente ? Portefeuilles sur des chaînes non L2 la protection de la vie privée Résumer
1. Quel est l'objectif ?
Une fois que L2 sera devenu courant, les utilisateurs posséderont des actifs sur plusieurs L2, et éventuellement sur des L1 également. Une fois que les portefeuilles de contrats intelligents (multisig, récupération sociale ou autre) seront devenus courants, les clés nécessaires pour accéder à certains comptes changeront au fil du temps, et les anciennes clés n'auront plus besoin d'être valides. Une fois que ces deux choses se produiront, les utilisateurs auront besoin d'un moyen de changer les clés qui ont accès à de nombreux comptes situés dans de nombreux endroits différents sans effectuer un nombre extrêmement élevé de transactions. En particulier, nous avons besoin d'un moyen de traiter les adresses contrefactuelles : les adresses qui n'ont en aucun cas été "enregistrées" sur la chaîne, mais qui doivent néanmoins recevoir et conserver des fonds en toute sécurité. Nous nous appuyons tous sur des adresses contrefactuelles : lorsque vous utilisez Ethereum pour la première fois, vous pouvez générer une adresse ETH que quelqu'un peut utiliser pour vous payer sans "enregistrer" l'adresse en chaîne (cela nécessite de payer un txfee, donc détenez déjà des ETH). Pour EOA, toutes les adresses commencent par une adresse contrefactuelle. Avec les portefeuilles de contrats intelligents, les adresses contrefactuelles sont toujours possibles grâce en grande partie à CREATE2, qui vous permet d'avoir une adresse ETH qui ne peut être remplie que par un contrat intelligent avec un code qui correspond à un hachage spécifique.
Algorithme de calcul d'adresse EIP-1014 (CREATE2)
Cependant, les portefeuilles de contrats intelligents introduisent un nouveau défi : la possibilité de changer de clé d'accès. Cette adresse est un hachage de l'initcode et ne peut contenir que la clé de vérification initiale du portefeuille. La clé de vérification actuelle sera stockée dans le stockage du portefeuille, mais cet enregistrement de stockage ne se propagera pas comme par magie vers d'autres L2. Si un utilisateur a de nombreuses adresses sur plusieurs L2, y compris des adresses inconnues du L2 sur lequel il se trouve (car elles sont contrefactuelles), alors il semble n'y avoir qu'un seul moyen de permettre aux utilisateurs de changer leurs clés : une architecture de séparation actif/keystore. Chaque utilisateur a (i) un "contrat de magasin de clés" (soit sur L1, soit sur un 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" qui lisent les chaînes pour les clés de vérification.
Il existe deux façons d'y parvenir :
Version allégée (vérifie uniquement les clés mises à jour) : chaque portefeuille stocke la clé de vérification localement et contient une fonction qui peut être appelée pour vérifier la preuve inter-chaîne de l'état actuel du magasin de clés et mettre à jour sa clé de clé de vérification stockée localement pour correspondre. Lorsque le portefeuille est utilisé pour la première fois sur un L2 particulier, cette fonction doit être appelée pour obtenir la clé d'authentification actuelle à partir du magasin de clés. -Avantages : les épreuves inter-chaînes sont utilisées avec parcimonie, donc peu importe si les épreuves inter-chaînes sont chères. Tous les fonds ne peuvent être utilisés qu'avec la clé actuelle, ils restent donc en sécurité.
2. À quoi ressemble la preuve inter-chaînes ?
Pour démontrer toute la complexité, nous allons explorer le cas le plus difficile : keystore sur une L2, wallet sur une autre L2. Seule la moitié de cette conception est nécessaire si le magasin de clés du portefeuille est sur L1.
Supposons que le magasin de clés est sur Linea et que le portefeuille est sur Kakarot. Une preuve complète de la clé du portefeuille comprend :
3. Quels types de schémas de preuve pouvons-nous utiliser ?
Il existe cinq options principales : -Preuve de Merkle -Général ZK-SNARK
"Agrégation" fait référence à l'agrégation de toutes les preuves fournies par les utilisateurs dans chaque bloc en une grande méta-preuve qui combine toutes les preuves. C'est possible avec SNARK et KZG, mais pas avec les fourches Merkle (vous pouvez combiner un peu les fourches Merkle, mais cela ne vous permet d'économiser que log(txs par bloc)/log(nombre total de keystores), en pratique c'est probablement 15-30% au milieu, donc ça ne vaut probablement pas le prix). L'agrégation ne devient utile que lorsque le scénario compte un grand nombre d'utilisateurs, donc en pratique, une implémentation de la version 1 pourrait omettre l'agrégation et l'implémenter dans la version 2.
4. Comment fonctionneront les preuves de Merkle ?
Celui-ci est simple : suivez simplement le schéma de la section précédente. Plus précisément, chaque "preuve" (en supposant le cas de prouver la difficulté maximale d'une L2 à une autre L2) contiendra : Une branche Merkle attestant de la racine d'état de L2 contenant le keystore, étant donné la dernière racine d'état d'Ethereum connue de L2. Le magasin de clés contient la racine d'état de L2 stockée dans un emplacement de stockage connu à une adresse connue (le contrat sur L1 représente L2), de sorte que le chemin à travers l'arborescence peut être codé en dur. Une branche Merkle attestant de la clé de vérification actuelle, compte tenu de la racine d'état de L2 contenant le magasin de clés. Là encore, la clé d'authentification est stockée dans un emplacement de stockage connu à une adresse connue, de sorte que le chemin peut être codé en dur. Malheureusement, les preuves d'état Ethereum sont complexes, mais des bibliothèques existent pour les valider, et si vous utilisez ces bibliothèques, ce mécanisme n'est pas trop compliqué à mettre en œuvre. ** Le plus gros problème est le coût. ** Les preuves de Merkle sont très longues, malheureusement l'arbre de Patricia est ~3,9 fois plus long que nécessaire (pour être exact : une preuve de Merkle idéale pour un arbre contenant N objets est longue de 32 * log2(N) octets, et parce que les arbres de Patricia d'Ethereum ont 16 feuilles par enfant, et la preuve de ces arbres est de 32 * 15 * log16(N) ~= 125 * log2(N) octets). Dans un État comptant environ 250 millions (~2²⁸) de comptes, cela fait de chaque preuve 125 * 28 = 3500 octets, soit environ 56 000 gaz, plus le coût supplémentaire du décodage et de la vérification du hachage. Ensemble, les deux preuves coûteraient environ 100 000 à 150 000 gaz (si elles sont utilisées par transaction, hors vérification de signature) - bien plus que le prix de base actuel de 21 000 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 beaucoup moins de nœuds que L1. En revanche, les données doivent être publiées en L1. La comparaison n'est donc pas 21 000 gaz contre 15 000 gaz ; c'est 21 000 gaz L2 contre 100 000 gaz L1. Nous pouvons calculer ce que cela signifie en regardant la comparaison entre le coût du gaz L1 et le coût du gaz L2 :
Actuellement, L1 est 15 à 25 fois plus cher que L2 pour un envoi simple et 20 à 50 fois plus cher pour les échanges de jetons. L'envoi simple est une quantité relativement importante de données, mais la quantité de calcul d'échange est beaucoup plus grande. Par conséquent, le swap est une meilleure référence pour le coût approximatif du calcul L1 par rapport au calcul L2. Compte tenu de tout cela, 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 d'une preuve Merkle sur L2 pourrait être équivalent à 50 transactions régulières. Bien sûr, l'utilisation d'arbres Merkle binaires réduit le coût d'un facteur de ~ 4, mais même dans ce cas, dans la plupart des cas, le coût est trop élevé - si nous sommes prêts à sacrifier la non-compatibilité avec l'arbre d'état hexagonal actuel d'Ethereum, nous recherchons meilleures options.
5. Comment fonctionnera 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. Un ZK-SNARK nécessite ~400 000 GAS pour le calcul, ce qui prend environ 400 octets (par rapport à : une transaction de base nécessite 21 000 gaz et 100 octets, qui peuvent être réduits à ~25 mots après compression dans le futur Festival). Par conséquent, d'un point de vue informatique, le coût des ZK-SNARK est 19 fois le coût des transactions de base d'aujourd'hui, et du point de vue des données, le coût des ZK-SNARK est 4 fois celui des transactions de base d'aujourd'hui et 16 fois le coût des futures transactions de base fois. Ces chiffres sont une grande amélioration par rapport à la preuve de Merkel, mais ils sont encore assez chers. Il existe deux façons d'améliorer cela : (i) des preuves KZG à usage spécial, ou (ii) l'agrégation, similaire à l'agrégation ERC-4337 mais en utilisant des mathématiques plus sophistiquées. On peut étudier les deux en même temps.
6. Comment fonctionneront les épreuves KZG spéciales ?
Attention, cette section est plus mathématique que les autres. C'est parce que nous allons au-delà des outils à usage général et que nous construisons des outils spéciaux moins chers, nous devons donc aller plus « sous le capot ». Si les mathématiques approfondies ne vous conviennent pas, passez directement à la section suivante. Tout d'abord, un récapitulatif du fonctionnement des engagements KZG : Nous pouvons représenter un ensemble de données [D_1...D_n] en utilisant la preuve KZG d'un polynôme dérivé des données : plus précisément, le polynôme P, où P(w) = D_1, P(w²) = D _2 ... P(wⁿ) = D_n. w ici est la "racine uniforme", la valeur de wN = 1 pour une taille de domaine d'évaluation N (tout cela se fait dans des corps finis). Pour "s'engager" sur 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 la configuration de confiance Pour prouver que P(z) = a, nous créons un polynôme quotient Q = (P - a) / (X - z), et créons 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 incluent :
Par conséquent, une preuve complète nécessite :
7. Comment fonctionnera l'arbre Verkle ?
Les arbres Verkle impliquent essentiellement d'empiler des engagements KZG (ou engagements IPA, qui peuvent être plus efficaces et utiliser un cryptage plus simple) : pour stocker 2⁴⁸ valeurs, vous faites un engagement KZG sur une liste de 2²⁴ valeurs, dont chacune est elle-même un engagement KZG à 2²⁴ Valeur. Les arbres Verkle sont fortement pris en compte pour les arbres d'état Ethereum, car les arbres Verkle peuvent être utilisés pour contenir des cartes clé-valeur, pas seulement des listes (en gros, vous pouvez créer un arbre de taille 2²⁵⁶ mais commencer vide, uniquement si vous ne remplissez que des parties spécifiques du arbre lorsque vous avez réellement besoin de les remplir).
À quoi ressemble un arbre Vicker. En fait, vous pouvez donner à chaque nœud une largeur de 256 == 2⁸ pour les arbres basés sur IPA, et 2²⁴ pour les arbres basés sur KZG. Les preuves dans les arbres Verkle sont un peu plus longues que dans KZG ; elles peuvent faire plusieurs centaines d'octets. Ils sont également difficiles à vérifier, surtout si vous essayez d'agréger plusieurs preuves en une seule. En fait, les arbres Verkle doivent être considérés comme des arbres Merkle, mais plus réalisables sans SNARKing (en raison du coût inférieur des données), et SNARKing est moins cher (en raison du coût de preuve inférieur). Le plus grand avantage des arbres Verkle est qu'ils peuvent coordonner les structures de données : les preuves Verkle peuvent être utilisées directement pour les états L1 ou L2, n'ont pas de structure de superposition et utilisent exactement le même mécanisme pour L1 et L2. Une fois que les ordinateurs quantiques deviennent un problème, ou une fois que la ramification de Merkle s'avère suffisamment efficace, les arbres de Verkle peuvent être remplacés sur place par des arbres de hachage binaires avec des fonctions de hachage adaptées à SNARK.
8. Agrégats
Si N utilisateurs effectuant N transactions (ou plus réaliste, N ERC-4337 UserOperations) doivent prouver N revendications inter-chaînes, nous pouvons économiser beaucoup d'argent en agrégeant ces preuves : en combinant ces transactions dans un bloc ou le constructeur du bundle qui entre dans le bloc peut créer une preuve qui prouve toutes ces affirmations en même temps. Cela pourrait signifier :
Diagramme de la publication sur la mise en œuvre du portefeuille BLS montrant le flux de travail pour les signatures agrégées BLS dans une première version d'ERC-4337. Le flux de travail pour l'agrégation des preuves inter-chaînes peut sembler très similaire.
9. Lecture directe de l'état
Une dernière possibilité, également disponible uniquement pour L2 lisant L1 (et non L1 lisant L2), consiste à modifier L2 afin qu'ils effectuent directement des appels statiques aux contrats sur L1. Cela peut être fait avec des opcodes ou une précompilation, ce qui permet d'appeler le L1, où vous fournissez l'adresse cible, le gaz et les données d'appel, et il renvoie la sortie, mais comme ces appels sont statiques, ils ne peuvent réellement changer aucun état L1. L2 doit savoir que L1 a déjà traité le dépôt, donc rien n'empêche une telle chose d'être mise en œuvre ; il s'agit principalement d'un défi de mise en œuvre technique (voir : ceci d'un appel d'offres optimiste pour prendre en charge les appels statiques vers L1). Notez que si le magasin de clés est sur L1 et que L2 intègre des appels statiques L1, aucune attestation n'est requise ! Cependant, si L2 n'intègre pas les appels statiques L1, ou si le magasin de clés est sur L2 (ce qui peut éventuellement devoir être fait une fois que L1 devient trop cher pour que les utilisateurs l'utilisent même un peu), alors une preuve sera requise.
10. 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. Heureusement, tous les L2 ont déjà des fonctionnalités pour accéder au dernier état L1. En effet, ils ont besoin de telles fonctionnalités pour gérer les messages de L1 à L2, en particulier les dépôts. 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 : demandez simplement au contrat sur L1 d'appeler l'opcode BLOCKHASH et de le transmettre à L2 en tant que message de dépôt. . 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 :
Les blocs de la chaîne L2 peuvent dépendre non seulement des blocs L2 précédents, mais également des blocs L1. Si L1 récupère sur un tel lien, L2 récupère également. Il convient de noter que c'est également ainsi que les versions antérieures (pré-Dank) du sharding étaient censées fonctionner ; voir ici pour le code.
11. De quelle connexion à Ethereum une autre chaîne a-t-elle besoin pour détenir un magasin de clés enraciné dans Ethereum ou un portefeuille L2 ?
Étonnamment, pas tant que ça. Il n'a même pas besoin d'être un rollup en fait : s'il s'agit de L3 ou de validation, c'est bien d'y conserver un portefeuille, tant que vous détenez le keystore sur un rollup L1 ou ZK. Ce dont vous avez vraiment besoin, c'est que la chaîne ait un accès direct à la racine d'état d'Ethereum, et un engagement technique et social pour être prêt à se réorganiser si Ethereum se réorganise, et à hard fork si Ethereum hard fork. Une question de recherche intéressante est de déterminer dans quelle mesure une chaîne peut avoir cette forme de connexion avec plusieurs autres chaînes (par exemple, Ethereum et Zcash). Faire cela naïvement est possible : si Ethereum ou Zcash se réorganise, votre chaîne peut accepter de se réorganiser (et hard fork si Ethereum ou Zcash hard forks), mais vos opérateurs de nœuds et votre communauté ont généralement deux fois des dépendances technologiques et politiques. Par conséquent, cette technique peut être utilisée pour se connecter à d'autres chaînes, mais à un coût accru. Les schémas basés sur des ponts ZK ont des propriétés techniques attrayantes, mais leur principale faiblesse est qu'ils ne sont pas robustes aux attaques à 51% ou aux hard forks. Il peut aussi y avoir des solutions plus intelligentes.
12. Protection de la vie privée
Idéalement, nous voulons aussi préserver la vie privée. Si vous avez plusieurs portefeuilles gérés par le même magasin de clés, nous voulons nous assurer que :
Le principal défi avec cette approche actuellement est que l'agrégation nécessite que l'agrégateur crée un SNARK récursif, qui est actuellement très lent. Avec KZG, nous pouvons utiliser ce travail (voir aussi : une version plus formelle de ce travail dans l'article de Caulk) sur des preuves KZG révélatrices non indexées comme point de départ. Cependant, l'agrégation de preuves aveugles est un problème ouvert qui nécessite plus d'attention. Malheureusement, lire L1 directement à partir de L2 ne préserve pas la confidentialité, bien que la mise en œuvre de la fonctionnalité de lecture directe soit toujours très utile, à la fois pour minimiser la latence et en raison de son utilité pour d'autres applications.
13. Résumé
Pour avoir un portefeuille de récupération sociale inter-chaînes, le flux de travail le plus réaliste est un portefeuille qui maintient un magasin de clés à un endroit, et un portefeuille qui maintient des portefeuilles dans de nombreux endroits, où le portefeuille lit le magasin de clés pour (i) mettre à jour sa clé d'authentification localement vue, ou (ii) dans le processus de validation de chaque transaction. Un élément clé qui rend cela possible est les preuves inter-chaînes. Nous devons travailler sur l'optimisation de ces preuves. Les ZK-SNARK ou les solutions KZG personnalisées en attente de la preuve de Verkle semblent être les meilleures options. À long terme, un protocole d'agrégation (où les bundlers génèrent des preuves agrégées dans le cadre de la création d'un bundle de toutes les actions utilisateur soumises par les utilisateurs) est nécessaire pour minimiser les coûts. Cela devrait probablement être intégré dans l'écosystème ERC-4337, bien que des modifications à ERC-4337 puissent être nécessaires. L2 doit être optimisé pour minimiser la latence de lecture de l'état L1 (ou au moins de la racine d'état) à partir de L2. Il est idéal pour les L2 de lire directement l'état L1, ce qui permet d'économiser de l'espace de preuve. Les portefeuilles peuvent non seulement être sur L2 ; vous pouvez également placer des portefeuilles sur des systèmes avec un niveau inférieur de connectivité à Ethereum (L3, ou même simplement accepter d'inclure la racine d'état Ethereum et une chaîne de fourches indépendante). Cependant, le magasin de clés doit être sur L1 ou sur le cumul ZK haute sécurité L2. L'utilisation de L1 permet d'économiser beaucoup de complexité, mais même cela peut être trop coûteux à long terme, donc un magasin de clés doit être utilisé sur L2. Préserver la vie privée demandera un travail supplémentaire et rendra certains choix plus difficiles. Cependant, nous devrions probablement nous tourner de toute façon vers des solutions de protection de la vie privée, en nous assurant au moins que tout ce que nous proposons est compatible avec la préservation de la vie privée.