原文标题：Ethereum devrait-il accepter d'inscrire plus de choses dans le protocole ?
Auteur original : Vitalik Buterin
Traducteur d'Odaily Planet Daily | Nian Yin Si Tang
*Un merci spécial à Justin Drake, Tina Zhen et Yoav Weiss pour leurs commentaires et critiques. *
Depuis le début du projet Ethereum, il y a eu une philosophie forte consistant à essayer de rendre le noyau Ethereum aussi simple que possible et à y parvenir autant que possible en construisant des protocoles par-dessus. Dans l’espace blockchain, le débat « s’appuyer sur L1 » ou « se concentrer sur L2 » est souvent considéré comme étant principalement une question de mise à l’échelle, mais en fait, il existe des problèmes similaires pour répondre aux besoins de plusieurs utilisateurs d’Ethereum : échanges d’actifs numériques, confidentialité. , noms d'utilisateur, cryptage avancé, sécurité des comptes, résistance à la censure, protection de premier plan, etc. Cependant, il y a eu récemment des tentatives prudentes pour intégrer davantage de ces fonctionnalités dans le protocole de base d’Ethereum.
Cet article approfondira certains des raisonnements philosophiques derrière la philosophie originale de l'encapsulation minimale, ainsi que quelques façons récentes de réfléchir à ces idées. L’objectif sera de commencer à construire un cadre pour mieux identifier les objectifs possibles pour lesquels l’encapsulation de certaines fonctionnalités pourrait être envisagée.
Une première philosophie sur le minimalisme des protocoles
Au début de l'histoire de ce qui était alors connu sous le nom de « Ethereum 2.0 », il y avait un fort désir de créer un protocole propre, simple et beau qui essayait le moins possible de s'appuyer sur lui-même et laissait presque tout ce travail aux utilisateurs. Idéalement, le protocole n'est qu'une machine virtuelle, et la validation d'un bloc n'est qu'un appel de machine virtuelle.
Il s'agit d'une reconstruction approximative du diagramme du tableau blanc que Gavin Wood et moi avons dessiné début 2015 lorsque je parlais de ce à quoi ressemblerait Ethereum 2.0.
La "fonction de transition d'état" (la fonction qui gère le bloc) ne sera qu'un seul appel de VM, et toutes les autres logiques se feront via des contrats : certains contrats au niveau du système, mais principalement des contrats fournis par l'utilisateur. Une caractéristique très intéressante de ce modèle est que même un hard fork entier peut être décrit comme une transaction unique dans le contrat de processeur de bloc, qui sera approuvée par une gouvernance hors chaîne ou en chaîne, puis mise à niveau avec l'autorisation d'exécution.
Ces discussions en 2015 s'appliquent spécifiquement à deux domaines que nous considérons : l'abstraction et la mise à l'échelle des comptes. Dans le cas de la mise à l'échelle, l'idée est d'essayer de créer une forme de mise à l'échelle abstraite maximale qui ressemble à une extension naturelle du diagramme ci-dessus. Les contrats peuvent appeler des données qui ne sont pas stockées par la plupart des nœuds Ethereum, et le protocole le détectera et résoudra l'appel via une fonctionnalité informatique étendue très générale. Du point de vue de la machine virtuelle, l'appel sera dirigé vers un sous-système distinct, puis renverra comme par magie la bonne réponse quelque temps plus tard.
Nous avons brièvement exploré cette idée, mais nous l’avons rapidement abandonnée car nous étions trop concentrés sur la preuve que tout type de mise à l’échelle de la blockchain était possible. Bien que, comme nous le verrons plus tard, la combinaison de l’échantillonnage de la disponibilité des données et de ZK-EVM signifie qu’un avenir possible pour la mise à l’échelle d’Ethereum semble en fait très proche de cette vision ! Avec l'abstraction des comptes, en revanche, nous savions dès le départ qu'une certaine forme de mise en œuvre était possible, c'est pourquoi les recherches ont immédiatement commencé à essayer de faire quelque chose d'aussi proche que possible du pur point de départ "une transaction n'est qu'un appel".
*Il existe de nombreux codes passe-partout entre le traitement de la transaction et l'appel EVM sous-jacent réel à partir de l'adresse de l'expéditeur, avec davantage de code passe-partout à suivre. Comment réduire ce code le plus près possible de zéro ? *
L'un des codes principaux ici est validate_transaction(state, tx), qui est chargé de vérifier si le nom occasionnel et la signature de la transaction sont corrects. Depuis le début, le véritable objectif de l'abstraction des comptes a été de permettre aux utilisateurs de remplacer la vérification non incrémentielle de base et la vérification ECDSA par leur propre logique de vérification, afin que les utilisateurs puissent utiliser plus facilement des fonctionnalités telles que la récupération sociale et les portefeuilles multi-signatures. Ainsi, trouver un moyen de restructurer apply_transaction en un simple appel EVM n'est pas seulement une tâche « rendre le code propre dans le seul but de rendre le code propre » ; il s'agit plutôt de déplacer la logique vers le code de compte de l'utilisateur, en donnant aux utilisateurs la flexibilité dont ils ont besoin. besoin.
Cependant, insister pour que apply_transaction contienne le moins de logique fixe possible a fini par créer de nombreux défis. Nous pouvons examiner l'une des premières propositions d'abstraction de compte, EIP-86.
Si EIP-86 était inclus tel quel, cela réduirait la complexité de l'EVM au prix d'une augmentation massive de la complexité d'autres parties de la pile Ethereum, nécessitant essentiellement l'écriture du même code ailleurs, en plus d'introduire un tout un code. Nouvelle classe d'étrangeté.Par exemple, la même transaction avec la même valeur de hachage peut apparaître plusieurs fois dans la chaîne, sans parler du problème d'invalidation multiple.
*Plusieurs problèmes d'invalidation dans l'abstraction du compte. Une transaction incluse dans la chaîne pourrait invalider des milliers d'autres transactions dans le pool de mémoire, ce qui faciliterait le remplissage du pool de mémoire à moindre coût. *
Depuis lors, l’abstraction des comptes a évolué par étapes. L'EIP-86 est ensuite devenu l'EIP-208, et finalement l'EIP-2938 pratique a émergé.
Cependant, l'EIP-2938 est tout sauf minimaliste. Son contenu comprend :
Nouveau type de transaction
Trois nouvelles variables globales de portée de transaction
Deux nouveaux opcodes, dont le très maladroit opcode PAYgas pour gérer le prix du gaz et les contrôles de limite de gaz, comme points d'arrêt d'exécution EVM, et pour stocker temporairement l'ETH pour un paiement unique
Un ensemble complexe de stratégies d'extraction et de retransmission, y compris une liste d'opcodes interdits pendant la phase de vérification de la transaction
Dans le but de réaliser l'abstraction des comptes sans impliquer les principaux développeurs d'Ethereum (qui se concentraient sur l'optimisation des clients Ethereum et la mise en œuvre de fusions), l'EIP-2938 a finalement été restructuré sous le nom d'ERC-4337, qui était complètement hors protocole.
ERC-4337. Il repose entièrement sur les appels EVM !
Puisqu’il s’agit d’un ERC, il ne nécessite pas de hard fork et existe techniquement « en dehors du protocole Ethereum ». Alors... problème résolu ? Il s’avère que ce n’est pas le cas. La feuille de route actuelle à mi-parcours pour l'ERC-4337 implique en fait la transition éventuelle de grandes parties de l'ERC-4337 vers une série de fonctionnalités de protocole, ce qui constitue un exemple utile d'orientation quant aux raisons pour lesquelles cette voie devrait être envisagée.
Paquet ERC-4337
Plusieurs raisons clés sont évoquées pour la réincorporation éventuelle de l'ERC-4337 dans le protocole :
Efficacité du gaz : toute opération effectuée à l'intérieur de l'EVM entraîne un certain niveau de surcharge de la machine virtuelle, y compris des inefficacités lors de l'utilisation de fonctionnalités coûteuses en gaz telles que les emplacements de stockage. Actuellement, ces inefficacités supplémentaires totalisent au moins 20 000 gaz, voire plus. L'intégration de ces composants dans le protocole constitue le moyen le plus simple d'éliminer ces problèmes.
Risque de bug de code : Si le "contrat de point d'entrée" ERC-4337 présente un bug assez terrible, tous les portefeuilles compatibles ERC-4337 pourraient voir tous leurs fonds se tarir. Le remplacement des contrats par des fonctionnalités intégrées au protocole crée une obligation implicite de corriger les bogues de code via des hard forks, éliminant ainsi le risque que les utilisateurs manquent de fonds.
Prend en charge les opcodes EVM, tels que txt.origin. ERC-4337 lui-même amène txt.origin à renvoyer l'adresse d'un « bundler » qui regroupe un ensemble d'actions utilisateur dans une transaction. L'abstraction de compte natif résout ce problème en faisant pointer txt.origin vers le compte réel qui envoie la transaction, ce qui lui permet de se comporter de la même manière qu'EOA.
Résistance à la censure : l'un des défis liés à la séparation entre promoteur et constructeur est qu'il devient plus facile d'examiner les transactions individuelles. Dans un monde où le protocole Ethereum peut identifier des transactions individuelles, ce problème peut être grandement atténué par des listes d'inclusion, qui permettent aux proposants de spécifier une liste de transactions qui doivent être incluses dans les deux créneaux suivants dans presque tous les cas. Cependant, ERC-4337 en dehors du protocole encapsule les « opérations utilisateur » dans une seule transaction, rendant les opérations utilisateur opaques au protocole Ethereum ; par conséquent, la liste d'inclusion fournie par le protocole Ethereum ne sera pas en mesure de fournir une résistance à la censure à l'utilisateur ERC-4337. opérations. Encapsuler ERC-4337 et faire de l'action de l'utilisateur un type de transaction « approprié » résoudrait ce problème.
Il convient de mentionner que dans sa forme actuelle, l'ERC-4337 est nettement plus cher que les transactions Ethereum « de base » : une transaction coûte 21 000 gaz, tandis que l'ERC-4337 coûte environ 42 000 gaz.
En théorie, il devrait être possible d'ajuster le système de coût du gaz EVM jusqu'à ce que le coût dans le protocole et le coût d'accès au stockage en dehors du protocole correspondent ; il n'y a aucune raison de devoir dépenser 9 000 gaz pour transférer l'ETH lorsque d'autres types de stockage modifient les opérations sont moins chères. En fait, deux EIP liés à la prochaine transformation de l’arborescence de Verkle tentent de faire exactement cela. Mais même si nous faisons cela, il y a une raison évidente pour laquelle, quelle que soit l'efficacité de l'EVM, les fonctions de protocole encapsulées seront inévitablement beaucoup moins chères que le code EVM : le code encapsulé n'a pas besoin de payer du gaz pour le préchargement.
Un portefeuille ERC-4337 entièrement fonctionnel est volumineux et l'implémentation compilée et mise en chaîne occupe environ 12 800 octets. Bien sûr, vous pouvez déployer ce code une fois et utiliser DELEGATECALL pour permettre à chaque portefeuille individuel de l'appeler, mais vous devrez toujours accéder au code dans chaque bloc où il est utilisé. Dans le cadre de l'EIP du coût du gaz de l'arbre Verkle, 12 800 octets formeront des morceaux 413. Pour accéder à ces morceaux, il faudra payer 2 fois le coût de la branche témoin (un total de 3 800 gaz) et 413 fois le coût du morceau témoin (un total de 82 600). gaz). Cela ne commence même pas à mentionner le point d'entrée ERC-4337 lui-même, qui dans la version 0.6.0 compte 23 689 octets sur la chaîne (environ 158 700 gaz à charger selon les règles Verkle Tree EIP).
Cela pose un problème : le coût du gaz nécessaire à l'accès réel à ces codes doit être amorti d'une manière ou d'une autre sur les transactions. L'approche actuelle utilisée par ERC-4337 n'est pas très bonne : la première transaction du bundle consomme un coût unique de stockage/lecture de code, ce qui la rend beaucoup plus chère que les autres transactions. L'encapsulation intra-protocole permettra à ces bibliothèques publiques partagées de faire partie du protocole et d'être librement accessibles à tous.
Que pouvons-nous apprendre de cet exemple et quand faut-il pratiquer l'encapsulation de manière plus générale ?
Dans cet exemple, nous voyons différentes justifications pour encapsuler les abstractions de comptes dans des protocoles.
**Les approches basées sur le marché qui « poussent la complexité à l'extrême » sont plus susceptibles d'échouer lorsque les coûts fixes sont élevés. **En fait, la feuille de route d'abstraction de compte à long terme semble comporter de nombreux coûts fixes par bloc. 244 100 gas pour charger un code de portefeuille standardisé est une chose ; mais l'agrégation peut ajouter des centaines de milliers de gas pour la vérification ZK-SNARK, ainsi que le coût en chaîne de la vérification des preuves. Il n’existe aucun moyen de facturer ces coûts aux utilisateurs sans introduire d’énormes inefficacités sur le marché, et transformer certaines de ces fonctionnalités en fonctionnalités de protocole auxquelles tout le monde peut accéder gratuitement résoudrait très bien ce problème.
**Réponse à l'échelle de la communauté aux bogues de code. **Si un morceau de code est utilisé par tous les utilisateurs ou par un très large éventail d'utilisateurs, il est souvent plus logique que la communauté blockchain assume la responsabilité d'un hard fork pour corriger les bogues qui surviennent. ERC-4337 introduit une grande quantité de code partagé à l'échelle mondiale. À long terme, il est sans aucun doute plus raisonnable de corriger les erreurs dans le code via des hard forks plutôt que de faire perdre une grande quantité d'ETH aux utilisateurs.
**Parfois, une forme plus solide de protocole peut être mise en œuvre en exploitant directement ses fonctionnalités. ** L'exemple clé ici concerne les fonctionnalités résistantes à la censure au sein du protocole, telles que les listes d'inclusion : les listes d'inclusion dans le protocole peuvent garantir une meilleure résistance à la censure que les méthodes extérieures au protocole. Afin que les opérations au niveau de l'utilisateur puissent réellement bénéficier des fonctionnalités du protocole. inclure des listes, les opérations individuelles au niveau de l'utilisateur doivent être "lisibles" pour le protocole. Un autre exemple moins connu est que la conception de preuve de participation Ethereum de l'ère 2017 prévoyait une abstraction des comptes des clés de participation, qui a été abandonnée au profit du BLS encapsulé parce que BLS prenait en charge un mécanisme « d'agrégation » qui devait être implémenté au niveau du protocole et niveaux du réseau, cela peut rendre le traitement d’un grand nombre de signatures plus efficace.
Mais il est important de se rappeler que même l’abstraction de compte au sein du protocole d’encapsulation reste une énorme « désencapsulation » par rapport au statu quo. Aujourd'hui, les transactions Ethereum de premier niveau ne peuvent être initiées qu'à partir de comptes externes (EOA), qui sont vérifiés à l'aide d'une seule signature de courbe elliptique secp 256k 1. L'abstraction du compte élimine cela et laisse les conditions de validation à définir par l'utilisateur. Par conséquent, dans cette histoire sur l'abstraction de compte, nous voyons également la principale raison contre l'encapsulation : La flexibilité pour répondre aux besoins des différents utilisateurs.
Développons davantage l'histoire en examinant quelques autres exemples de fonctionnalités qui ont récemment été envisagées pour l'encapsulation. Nous examinerons en particulier : ZK-EVM, séparation proposant-constructeur, pools de mémoire privés, jalonnement de liquidité et nouvelle précompilation.
Package ZK-EVM
Tournons notre attention vers une autre cible d’encapsulation potentielle pour le protocole Ethereum : ZK-EVM. Actuellement, nous disposons d’un grand nombre de ZK-rollups qui doivent tous écrire un code assez similaire pour vérifier l’exécution de blocs Ethereum similaires dans les ZK-SNARK. Il existe un écosystème assez diversifié d'implémentations indépendantes : PSE ZK-EVM, Kakarot, Polygon ZK-EVM, Linea, Zeth et bien d'autres.
Une controverse récente dans le domaine du rollup EVM ZK concerne la manière de gérer les bogues pouvant apparaître dans le code ZK. Actuellement, tous ces systèmes en fonctionnement disposent d'une forme de mécanisme de « conseil de sécurité » qui contrôle le système d'attestation en cas de bug. L’année dernière, j’ai essayé de créer un cadre standardisé qui encouragerait les projets à préciser dans quelle mesure ils font confiance au système d’attestation et dans quelle mesure ils font confiance au Conseil de sécurité, et à réduire progressivement leur autorité sur cette organisation au fil du temps.
*À moyen terme, le rollup pourrait s'appuyer sur plusieurs systèmes de certification, et le Conseil de sécurité n'aura de pouvoir que dans les cas extrêmes où deux systèmes de certification différents divergent. *
Cependant, on a le sentiment qu’une partie de ce travail semble redondante. Nous avons déjà une couche de base Ethereum, elle a un EVM, et nous avons déjà un mécanisme fonctionnel pour gérer les bugs dans l'implémentation : s'il y a un bug, le client sera mis à jour pour le corriger, et la chaîne continuera à fonctionner . Du point de vue du client buggy, il semble que les blocages finalisés ne seront plus confirmés, mais au moins nous ne verrons pas les utilisateurs perdre de fonds. De même, si les rollups veulent simplement conserver le rôle équivalent d'EVM, ils doivent alors mettre en œuvre leur propre gouvernance pour modifier constamment leurs règles internes ZK-EVM afin de correspondre aux mises à niveau de la couche de base Ethereum, ce qui semble faux car en fin de compte, ils sont construits sur le dessus. de la couche de base Ethereum elle-même, il sait quand mettre à niveau et selon quelles nouvelles règles.
Étant donné que ces ZK-EVM L2 utilisent fondamentalement exactement le même EVM qu'Ethereum, pouvons-nous d'une manière ou d'une autre incorporer "vérifier l'exécution de l'EVM dans ZK" dans la fonctionnalité du protocole et gérer les exceptions en appliquant le consensus social d'Ethereum, comme les bugs et les mises à niveau, comme nous le faisons déjà pour le l'exécution EVM de la couche de base elle-même ?
Il s’agit d’un sujet important et stimulant.
Un sujet de débat possible concernant la disponibilité des données dans ZK-EVM natif est l'état. Les ZK-EVM seraient beaucoup plus efficaces en matière de données s'ils n'avaient pas besoin de transporter des données « témoins ». Autrement dit, si une donnée particulière a déjà été lue ou écrite dans un bloc précédent, nous pouvons simplement supposer que le prouveur y a accès et n'a pas besoin de la rendre à nouveau disponible. Il ne s'agit pas seulement de ne pas recharger le stockage et le code ; il s'avère que si un cumul compresse correctement les données, la compression avec état peut économiser jusqu'à 3 fois les données par rapport à la compression sans état.
Cela signifie que pour la précompilation ZK-EVM, nous avons deux options :
**1.**La précompilation nécessite que toutes les données soient disponibles dans le même bloc. Cela signifie que le prouveur peut être apatride, mais cela signifie également que l'utilisation de ce cumul ZK précompilé est beaucoup plus coûteuse que l'utilisation d'un cumul de code personnalisé.
**2.**La précompilation permet aux pointeurs de pointer vers les données utilisées ou générées par les exécutions précédentes. Cela rend le ZK-rollup proche de l'optimum, mais il est plus complexe et introduit un nouvel état qui doit être stocké par le prouveur.
Que pouvons-nous en tirer ? Il y a une bonne raison d'encapsuler la vérification ZK-EVM d'une manière ou d'une autre : le rollup construit déjà sa propre version personnalisée, et Ethereum est prêt à implémenter EVM sur L1 avec le poids de ses multiples implémentations et de son consensus social hors chaîne. , cela semble faux, mais L2, pour faire exactement le même travail, devrait mettre en œuvre un gadget complexe impliquant le Conseil de sécurité. Mais d'un autre côté, il y a un gros problème dans les détails : il existe différentes versions de ZK-EVM, et elles ont des coûts et des avantages différents. La distinction entre avec et sans état ne fait qu'effleurer la surface ; les tentatives de prise en charge du code personnalisé "presque-EVM" qui a été prouvé par d'autres systèmes peuvent exposer un espace de conception plus grand. Par conséquent, l'emballage de ZK-EVM apporte à la fois de l'espoir et des défis.
Proposant d'encapsulation et séparation du constructeur (ePBS)
L’essor du MEV fait de la production de blocs une activité économique à grande échelle, avec des acteurs sophistiqués capables de produire des blocs générant plus de revenus que l’algorithme par défaut, qui observe simplement un pool de transactions et les contient. Jusqu'à présent, la communauté Ethereum a tenté de résoudre ce problème en utilisant des schémas de séparation proposant-constructeur hors protocole tels que MEV-Boost, qui permet aux validateurs réguliers (« proposants ») de pousser des blocs vers le bâtiment. Le bâtiment est sous-traité à des acteurs spécialisés (« constructeurs »). ").
Cependant, MEV-Boost fait des hypothèses de confiance envers une nouvelle classe d’acteurs appelés relais. Au cours des deux dernières années, de nombreuses propositions ont été formulées pour créer un "PBS packagé". Quels sont les avantages de faire cela ? Dans ce cas, la réponse est très simple : un PBS construit en utilisant directement les fonctionnalités du protocole est plus puissant (dans le sens d’avoir des hypothèses de confiance plus faibles) qu’un PBS construit sans les utiliser. Ceci est similaire au cas de l’encapsulation d’oracles de prix dans un protocole – même si dans ce cas, il y a de fortes objections.
Encapsuler le pool de mémoire privée
Lorsqu'un utilisateur envoie une transaction, celle-ci est immédiatement publique et visible par tous, avant même qu'elle ne soit incluse dans la chaîne. Cela rend les utilisateurs de nombreuses applications vulnérables aux attaques économiques, telles que le front-running.
Récemment, un certain nombre de projets ont été consacrés à la création de « pools de mémoire privés » (ou « pools de mémoire cryptographiques »), qui chiffrent les transactions des utilisateurs jusqu'à ce qu'elles soient acceptées de manière irréversible dans un bloc.
Le problème, cependant, est qu'un tel système nécessite un type particulier de cryptage : pour empêcher les utilisateurs d'inonder le système et de le déchiffrer en premier, le cryptage doit être automatiquement déchiffré une fois que la transaction a été acceptée de manière irréversible.
Il existe différentes techniques avec différents compromis pour mettre en œuvre cette forme de cryptage. Jon Charbonneau l'a bien décrit un jour :
Chiffrement pour les opérateurs centralisés tels que Flashbots Protect**. **
Chiffrement à verrouillage temporel, cette forme de cryptage peut être déchiffrée par n'importe qui après certaines étapes de calcul séquentielles et ne peut pas être parallélisée ;
Threshold Encryption, faites confiance à un comité majoritaire honnête pour décrypter les données. Voir le concept de chaînes de balises fermées pour des suggestions spécifiques.
Matériel de confiance, tel que SGX.
Malheureusement, chaque méthode de cryptage présente des faiblesses différentes. Même si pour chaque solution il existe un segment d’utilisateurs prêts à lui faire confiance, aucune solution n’est suffisamment fiable pour être réellement acceptée par la couche 1. **Ainsi, au moins jusqu'à ce que le cryptage différé soit perfectionné ou une autre avancée technologique, encapsuler la fonctionnalité de trading anti-ahead dans la couche 1 semble être une proposition difficile, même s'il s'agit d'une fonctionnalité suffisamment précieuse pour que de nombreuses applications résolvent le problème. un plan a émergé.
Encapsuler le jalonnement de liquidité
Un besoin commun parmi les utilisateurs d’Ethereum DeFi est la possibilité d’utiliser simultanément leur ETH pour le jalonnement et comme garantie dans d’autres applications. Une autre demande courante concerne simplement la commodité : les utilisateurs veulent pouvoir miser (et protéger les clés de jalonnement en ligne) sans la complexité de gérer un nœud et de le maintenir toujours en ligne.
L'interface de loin la plus simple qui répond à ces deux besoins n'est qu'un jeton ERC 20 : convertissez votre ETH en "ETH de jalonnement", conservez-le, puis reconvertissez-le. En fait, les fournisseurs de jalonnement de liquidité comme Lido et Rocket Pool le font déjà. Cependant, il existe certains mécanismes naturels de centralisation en jeu avec le staking de liquidité : les gens se tourneront naturellement vers le staking de la version la plus grande d’ETH car c’est la plus familière et la plus liquide.
Chaque version d'ETH mis en jeu doit disposer d'un mécanisme permettant de déterminer qui peut devenir l'opérateur de nœud sous-jacent. Cela ne peut pas être illimité, car les attaquants se joindront alors à nous et utiliseront les fonds des utilisateurs pour étendre leurs attaques. Actuellement, les deux premiers sont Lido et Rocket Pool, le premier ayant des opérateurs de nœuds DAO sur liste blanche et le second permettant à quiconque d'exécuter un nœud avec un dépôt de 8 ETH. Ces deux méthodes présentent des risques différents : la méthode Rocket Pool permet à un attaquant de mener une attaque à 51 % sur le réseau et oblige les utilisateurs à payer la plupart des coûts ; quant à la méthode DAO, si un certain token misé devient dominant, il entraînera à un seul, un gadget de gouvernance potentiellement compromis contrôle une grande partie de tous les validateurs Ethereum. Il faut reconnaître que des protocoles comme le Lido ont mis en place des garanties, mais une seule couche de défense pourrait ne pas suffire.
À court terme, une option consiste à encourager les acteurs de l’écosystème à recourir à un ensemble diversifié de fournisseurs de jalonnement de liquidités afin de réduire la possibilité qu’un acteur dominant pose un risque systémique. À long terme, cependant, l’équilibre est instable et il est dangereux de s’appuyer trop sur la pression morale pour résoudre les problèmes. Une question naturelle se pose : **Est-il judicieux d'encapsuler certaines fonctionnalités dans le protocole pour rendre le jalonnement de liquidité moins centralisé ? **
La question clé ici est : quel type de fonctionnalité dans le protocole ? Un problème lié à la simple création d'un jeton fongible de « staking ETH » au sein du protocole est qu'il devrait soit avoir une gouvernance encapsulée à l'échelle d'Ethereum pour choisir qui peut exécuter les nœuds, soit être à durée indéterminée, mais cela le transformerait en l'attaquant. Outils.
Une idée intéressante est l’article de Dankrad Feist sur la maximisation du jalonnement de liquidité. Tout d'abord, mordons la balle : si Ethereum est soumis à une attaque à 51 %, seulement 5 % de l'ETH attaqué peut être réduit. Il s'agit d'un compromis raisonnable ; avec plus de 26 millions d'ETH actuellement mis en jeu, le coût d'une attaque sur un tiers de ce montant (~ 8 millions d'ETH) est excessif, surtout si l'on considère le nombre d'attaques « hors modèle » qui peuvent être effectuées simultanément. moindre coût. En fait, des compromis similaires ont été explorés dans la proposition du Super Comité visant à mettre en œuvre la finalité du créneau unique.
Si nous acceptons que seulement 5 % de l’ETH d’attaque soit réduit, alors plus de 90 % de l’ETH mis en jeu ne sera pas affecté par la réduction, ils peuvent donc être utilisés comme jetons de jalonnement liquide fongibles dans le protocole, puis utilisés par d’autres applications.
Ce chemin est intéressant. Mais cela laisse encore une question : qu’est-ce qui est exactement encapsulé ? **Rocket Pool fonctionne de manière très similaire : chaque opérateur de nœud fournit une partie des fonds et les acteurs de la liquidité fournissent le reste. Nous pouvons simplement ajuster certaines constantes pour limiter la pénalité maximale à 2 ETH, et le rETH existant de Rocket Pool deviendra sans risque.
Avec de simples ajustements de protocole, nous pouvons également faire d’autres choses intelligentes. Par exemple, disons que nous voulons un système avec deux « niveaux » de jalonnement : les opérateurs de nœuds (exigences de garantie élevées) et les déposants (pas d'exigences de garantie minimale, peuvent rejoindre et quitter à tout moment), mais nous voulons quand même doter un échantillon aléatoire. le comité des déposants a le pouvoir d'empêcher la centralisation des opérateurs de nœuds, par exemple en recommandant une liste de transactions qui doivent être incluses (pour des raisons de résistance à la censure), en contrôlant la sélection des forks lors de fuites d'inactivité ou en exigeant des signatures sur les blocs. Cela pourrait être accompli d'une manière qui sort essentiellement du protocole en modifiant le protocole pour exiger que chaque validateur fournisse (i) une clé de jalonnement régulière, et (ii) une adresse ETH qui peut être utilisée dans chaque emplacement est appelée pour afficher le clé de gage secondaire. Le protocole autoriserait les deux clés, mais le mécanisme de sélection de la deuxième clé dans chaque emplacement pourrait être laissé au protocole du pool de jalonnement. Il est peut-être préférable d'encapsuler certaines fonctionnalités directement, mais il convient de noter que cet espace de conception "inclure certaines choses et laisser d'autres choses à l'utilisateur" existe.
Encapsuler plus de précompilation
Les contrats précompilés (ou « contrats précompilés ») sont des contrats Ethereum qui implémentent des opérations cryptographiques complexes, avec une logique implémentée nativement dans le code client plutôt que dans le code du contrat intelligent EVM. Le précodage est un compromis adopté dès le début du développement d'Ethereum : la surcharge d'une machine virtuelle étant trop importante pour certains codes très complexes et hautement spécialisés, nous pouvons implémenter certaines applications importantes en code natif et valoriser les opérations critiques pour les rendre plus rapides. Aujourd'hui, cela inclut essentiellement certaines fonctions de hachage spécifiques et des opérations sur les courbes elliptiques.
Il existe actuellement une pression pour ajouter une précompilation pour secp 256 r 1, une courbe elliptique légèrement différente de celle de secp 256 k 1 utilisée pour les comptes Ethereum de base, qui est largement utilisée car elle est bien prise en charge par des modules matériels de confiance. Utilisez-la pour augmenter la sécurité du portefeuille. Ces dernières années, la communauté a également poussé à ajouter la précompilation pour BLS-12-377, BW 6-761, l'appariement généralisé et d'autres fonctionnalités.
Le contre-argument à ces appels à davantage de précompilateurs est que bon nombre des précompilateurs ajoutés précédemment (tels que RIPEMD et BLAKE) ont fini par être beaucoup moins utilisés que prévu, et nous devrions en tirer des leçons. Plutôt que d'ajouter davantage de précompilation pour des opérations spécifiques, nous devrions peut-être nous concentrer sur une approche plus douce basée sur des idées comme EVM-MAX et la proposition SIMD Hibernate-But-Always-Resumable, qui permettrait aux implémentations EVM de fonctionner à moindre coût. un large éventail de classes de code. Peut-être que même la précompilation existante, peu utilisée, pourrait être supprimée et remplacée par une implémentation de code EVM (inévitablement moins efficace) des mêmes fonctions. Cela dit, il est toujours possible que certaines opérations cryptographiques spécifiques soient suffisamment précieuses pour être accélérées. Il est donc logique de les ajouter précompilées.
Qu'avons-nous appris de tout cela ?
Le désir d’encapsuler le moins possible est compréhensible et bon ; il découle de la tradition philosophique Unix de création de logiciels minimalistes qui peuvent facilement s’adapter aux différents besoins des utilisateurs et éviter la malédiction de la surcharge logicielle. Cependant, la blockchain n’est pas un système d’exploitation informatique personnel, mais un système social. Cela signifie qu’il est logique d’encapsuler certaines fonctionnalités dans le protocole.
Dans de nombreux cas, ces autres exemples sont similaires à ce que nous avons vu dans l’abstraction du compte. Mais nous avons également appris de nouvelles leçons :
Les fonctions encapsulées peuvent aider à éviter les risques de centralisation dans d'autres zones de la pile :
Souvent, garder le protocole de base minimal et simple repousse la complexité vers un écosystème en dehors du protocole. Du point de vue de la philosophie Unix, c'est très bien. Cependant, il existe parfois un risque que l’écosystème hors protocole se centralise, généralement (mais pas seulement) en raison de coûts fixes élevés. L'encapsulation peut parfois réduire la centralisation de facto.
Encapsuler trop de contenu peut exagérer le fardeau de confiance et de gouvernance du protocole :
C’est le sujet de l’article précédent sur « Ne pas surcharger le consensus Ethereum » : si encapsuler une fonctionnalité spécifique affaiblit le modèle de confiance et rend Ethereum dans son ensemble plus « subjectif », cela affaiblit la neutralité crédible d’Ethereum. Dans ces cas, il est préférable d’avoir la fonctionnalité spécifique comme mécanisme au-dessus d’Ethereum plutôt que d’essayer de l’introduire dans Ethereum lui-même. Les pools de mémoire chiffrés en sont le meilleur exemple, qui peuvent être un peu difficiles à encapsuler, du moins jusqu'à ce que le chiffrement de la latence s'améliore.
Encapsuler trop de contenu peut rendre le protocole trop complexe :
La complexité des protocoles est un risque systémique qui augmente en ajoutant trop de fonctionnalités à un protocole. La précompilation en est le meilleur exemple.
À long terme, l'encapsulation des fonctionnalités peut s'avérer contre-productive car les besoins des utilisateurs sont imprévisibles :
Une fonctionnalité que beaucoup de gens considèrent comme importante et qui sera utilisée par de nombreux utilisateurs n’est probablement pas très souvent utilisée dans la pratique.
De plus, le jalonnement de liquidité, le ZK-EVM et des exemples précompilés montrent la possibilité d'une voie médiane : une consécration minimale viable. Le protocole n'a pas besoin d'encapsuler l'intégralité de la fonctionnalité, mais peut contenir des parties spécifiques qui répondent aux principaux défis, ce qui rend la fonctionnalité facile à mettre en œuvre sans être trop paranoïaque ou trop étroite. Les exemples comprennent:
Au lieu d'encapsuler un système complet de jalonnement de liquidité, il est préférable de modifier les règles de pénalité de jalonnement pour rendre le jalonnement de liquidité sans confiance plus réalisable ;
Plutôt que d'encapsuler davantage de précompilateurs, il est préférable d'encapsuler EVM-MAX et/ou SIMD pour faciliter la mise en œuvre efficace d'une classe plus large d'opérations ;
Peut simplement encapsuler la vérification EVM au lieu d'encapsuler l'ensemble du concept de cumul.
On peut étendre le schéma précédent comme suit :
Parfois, il est judicieux d’encapsuler quelque chose, et la suppression des précompilateurs rarement utilisés en est un exemple. L'abstraction de compte dans son ensemble, comme mentionné précédemment, est également une forme importante de désencapsulation. Si nous voulons prendre en charge la compatibilité ascendante pour les utilisateurs existants, le mécanisme pourrait en fait être étonnamment similaire à celui qui a déballé la précompilation : l'une des propositions est EIP-5003, qui permettrait aux EOA de convertir leurs comptes pour avoir le même ( ou mieux) contrat fonctionnel.
Quelles fonctionnalités doivent être intégrées au protocole et lesquelles doivent être laissées à d’autres couches de l’écosystème est un compromis complexe. Ce compromis devrait continuer à s'améliorer au fil du temps, à mesure que notre compréhension des besoins des utilisateurs et de la suite d'idées et de technologies disponibles continue de s'améliorer.
Voir l'original
Cette page peut inclure du contenu de tiers fourni à des fins d'information uniquement. Gate ne garantit ni l'exactitude ni la validité de ces contenus, n’endosse pas les opinions exprimées, et ne fournit aucun conseil financier ou professionnel à travers ces informations. Voir la section Avertissement pour plus de détails.
Le dernier long article de Buterin : Le protocole Ethereum devrait-il encapsuler plus de fonctions ?
原文标题：Ethereum devrait-il accepter d'inscrire plus de choses dans le protocole ?
Auteur original : Vitalik Buterin
Traducteur d'Odaily Planet Daily | Nian Yin Si Tang
*Un merci spécial à Justin Drake, Tina Zhen et Yoav Weiss pour leurs commentaires et critiques. *
Depuis le début du projet Ethereum, il y a eu une philosophie forte consistant à essayer de rendre le noyau Ethereum aussi simple que possible et à y parvenir autant que possible en construisant des protocoles par-dessus. Dans l’espace blockchain, le débat « s’appuyer sur L1 » ou « se concentrer sur L2 » est souvent considéré comme étant principalement une question de mise à l’échelle, mais en fait, il existe des problèmes similaires pour répondre aux besoins de plusieurs utilisateurs d’Ethereum : échanges d’actifs numériques, confidentialité. , noms d'utilisateur, cryptage avancé, sécurité des comptes, résistance à la censure, protection de premier plan, etc. Cependant, il y a eu récemment des tentatives prudentes pour intégrer davantage de ces fonctionnalités dans le protocole de base d’Ethereum.
Cet article approfondira certains des raisonnements philosophiques derrière la philosophie originale de l'encapsulation minimale, ainsi que quelques façons récentes de réfléchir à ces idées. L’objectif sera de commencer à construire un cadre pour mieux identifier les objectifs possibles pour lesquels l’encapsulation de certaines fonctionnalités pourrait être envisagée.
Une première philosophie sur le minimalisme des protocoles
Au début de l'histoire de ce qui était alors connu sous le nom de « Ethereum 2.0 », il y avait un fort désir de créer un protocole propre, simple et beau qui essayait le moins possible de s'appuyer sur lui-même et laissait presque tout ce travail aux utilisateurs. Idéalement, le protocole n'est qu'une machine virtuelle, et la validation d'un bloc n'est qu'un appel de machine virtuelle.
Il s'agit d'une reconstruction approximative du diagramme du tableau blanc que Gavin Wood et moi avons dessiné début 2015 lorsque je parlais de ce à quoi ressemblerait Ethereum 2.0.
La "fonction de transition d'état" (la fonction qui gère le bloc) ne sera qu'un seul appel de VM, et toutes les autres logiques se feront via des contrats : certains contrats au niveau du système, mais principalement des contrats fournis par l'utilisateur. Une caractéristique très intéressante de ce modèle est que même un hard fork entier peut être décrit comme une transaction unique dans le contrat de processeur de bloc, qui sera approuvée par une gouvernance hors chaîne ou en chaîne, puis mise à niveau avec l'autorisation d'exécution.
Ces discussions en 2015 s'appliquent spécifiquement à deux domaines que nous considérons : l'abstraction et la mise à l'échelle des comptes. Dans le cas de la mise à l'échelle, l'idée est d'essayer de créer une forme de mise à l'échelle abstraite maximale qui ressemble à une extension naturelle du diagramme ci-dessus. Les contrats peuvent appeler des données qui ne sont pas stockées par la plupart des nœuds Ethereum, et le protocole le détectera et résoudra l'appel via une fonctionnalité informatique étendue très générale. Du point de vue de la machine virtuelle, l'appel sera dirigé vers un sous-système distinct, puis renverra comme par magie la bonne réponse quelque temps plus tard.
Nous avons brièvement exploré cette idée, mais nous l’avons rapidement abandonnée car nous étions trop concentrés sur la preuve que tout type de mise à l’échelle de la blockchain était possible. Bien que, comme nous le verrons plus tard, la combinaison de l’échantillonnage de la disponibilité des données et de ZK-EVM signifie qu’un avenir possible pour la mise à l’échelle d’Ethereum semble en fait très proche de cette vision ! Avec l'abstraction des comptes, en revanche, nous savions dès le départ qu'une certaine forme de mise en œuvre était possible, c'est pourquoi les recherches ont immédiatement commencé à essayer de faire quelque chose d'aussi proche que possible du pur point de départ "une transaction n'est qu'un appel".
*Il existe de nombreux codes passe-partout entre le traitement de la transaction et l'appel EVM sous-jacent réel à partir de l'adresse de l'expéditeur, avec davantage de code passe-partout à suivre. Comment réduire ce code le plus près possible de zéro ? *
L'un des codes principaux ici est validate_transaction(state, tx), qui est chargé de vérifier si le nom occasionnel et la signature de la transaction sont corrects. Depuis le début, le véritable objectif de l'abstraction des comptes a été de permettre aux utilisateurs de remplacer la vérification non incrémentielle de base et la vérification ECDSA par leur propre logique de vérification, afin que les utilisateurs puissent utiliser plus facilement des fonctionnalités telles que la récupération sociale et les portefeuilles multi-signatures. Ainsi, trouver un moyen de restructurer apply_transaction en un simple appel EVM n'est pas seulement une tâche « rendre le code propre dans le seul but de rendre le code propre » ; il s'agit plutôt de déplacer la logique vers le code de compte de l'utilisateur, en donnant aux utilisateurs la flexibilité dont ils ont besoin. besoin.
Cependant, insister pour que apply_transaction contienne le moins de logique fixe possible a fini par créer de nombreux défis. Nous pouvons examiner l'une des premières propositions d'abstraction de compte, EIP-86.
Si EIP-86 était inclus tel quel, cela réduirait la complexité de l'EVM au prix d'une augmentation massive de la complexité d'autres parties de la pile Ethereum, nécessitant essentiellement l'écriture du même code ailleurs, en plus d'introduire un tout un code. Nouvelle classe d'étrangeté.Par exemple, la même transaction avec la même valeur de hachage peut apparaître plusieurs fois dans la chaîne, sans parler du problème d'invalidation multiple.
*Plusieurs problèmes d'invalidation dans l'abstraction du compte. Une transaction incluse dans la chaîne pourrait invalider des milliers d'autres transactions dans le pool de mémoire, ce qui faciliterait le remplissage du pool de mémoire à moindre coût. *
Depuis lors, l’abstraction des comptes a évolué par étapes. L'EIP-86 est ensuite devenu l'EIP-208, et finalement l'EIP-2938 pratique a émergé.
Cependant, l'EIP-2938 est tout sauf minimaliste. Son contenu comprend :
Dans le but de réaliser l'abstraction des comptes sans impliquer les principaux développeurs d'Ethereum (qui se concentraient sur l'optimisation des clients Ethereum et la mise en œuvre de fusions), l'EIP-2938 a finalement été restructuré sous le nom d'ERC-4337, qui était complètement hors protocole.
ERC-4337. Il repose entièrement sur les appels EVM !
Puisqu’il s’agit d’un ERC, il ne nécessite pas de hard fork et existe techniquement « en dehors du protocole Ethereum ». Alors... problème résolu ? Il s’avère que ce n’est pas le cas. La feuille de route actuelle à mi-parcours pour l'ERC-4337 implique en fait la transition éventuelle de grandes parties de l'ERC-4337 vers une série de fonctionnalités de protocole, ce qui constitue un exemple utile d'orientation quant aux raisons pour lesquelles cette voie devrait être envisagée.
Paquet ERC-4337
Plusieurs raisons clés sont évoquées pour la réincorporation éventuelle de l'ERC-4337 dans le protocole :
Il convient de mentionner que dans sa forme actuelle, l'ERC-4337 est nettement plus cher que les transactions Ethereum « de base » : une transaction coûte 21 000 gaz, tandis que l'ERC-4337 coûte environ 42 000 gaz.
En théorie, il devrait être possible d'ajuster le système de coût du gaz EVM jusqu'à ce que le coût dans le protocole et le coût d'accès au stockage en dehors du protocole correspondent ; il n'y a aucune raison de devoir dépenser 9 000 gaz pour transférer l'ETH lorsque d'autres types de stockage modifient les opérations sont moins chères. En fait, deux EIP liés à la prochaine transformation de l’arborescence de Verkle tentent de faire exactement cela. Mais même si nous faisons cela, il y a une raison évidente pour laquelle, quelle que soit l'efficacité de l'EVM, les fonctions de protocole encapsulées seront inévitablement beaucoup moins chères que le code EVM : le code encapsulé n'a pas besoin de payer du gaz pour le préchargement.
Un portefeuille ERC-4337 entièrement fonctionnel est volumineux et l'implémentation compilée et mise en chaîne occupe environ 12 800 octets. Bien sûr, vous pouvez déployer ce code une fois et utiliser DELEGATECALL pour permettre à chaque portefeuille individuel de l'appeler, mais vous devrez toujours accéder au code dans chaque bloc où il est utilisé. Dans le cadre de l'EIP du coût du gaz de l'arbre Verkle, 12 800 octets formeront des morceaux 413. Pour accéder à ces morceaux, il faudra payer 2 fois le coût de la branche témoin (un total de 3 800 gaz) et 413 fois le coût du morceau témoin (un total de 82 600). gaz). Cela ne commence même pas à mentionner le point d'entrée ERC-4337 lui-même, qui dans la version 0.6.0 compte 23 689 octets sur la chaîne (environ 158 700 gaz à charger selon les règles Verkle Tree EIP).
Cela pose un problème : le coût du gaz nécessaire à l'accès réel à ces codes doit être amorti d'une manière ou d'une autre sur les transactions. L'approche actuelle utilisée par ERC-4337 n'est pas très bonne : la première transaction du bundle consomme un coût unique de stockage/lecture de code, ce qui la rend beaucoup plus chère que les autres transactions. L'encapsulation intra-protocole permettra à ces bibliothèques publiques partagées de faire partie du protocole et d'être librement accessibles à tous.
Que pouvons-nous apprendre de cet exemple et quand faut-il pratiquer l'encapsulation de manière plus générale ?
Dans cet exemple, nous voyons différentes justifications pour encapsuler les abstractions de comptes dans des protocoles.
Mais il est important de se rappeler que même l’abstraction de compte au sein du protocole d’encapsulation reste une énorme « désencapsulation » par rapport au statu quo. Aujourd'hui, les transactions Ethereum de premier niveau ne peuvent être initiées qu'à partir de comptes externes (EOA), qui sont vérifiés à l'aide d'une seule signature de courbe elliptique secp 256k 1. L'abstraction du compte élimine cela et laisse les conditions de validation à définir par l'utilisateur. Par conséquent, dans cette histoire sur l'abstraction de compte, nous voyons également la principale raison contre l'encapsulation : La flexibilité pour répondre aux besoins des différents utilisateurs.
Développons davantage l'histoire en examinant quelques autres exemples de fonctionnalités qui ont récemment été envisagées pour l'encapsulation. Nous examinerons en particulier : ZK-EVM, séparation proposant-constructeur, pools de mémoire privés, jalonnement de liquidité et nouvelle précompilation.
Package ZK-EVM
Tournons notre attention vers une autre cible d’encapsulation potentielle pour le protocole Ethereum : ZK-EVM. Actuellement, nous disposons d’un grand nombre de ZK-rollups qui doivent tous écrire un code assez similaire pour vérifier l’exécution de blocs Ethereum similaires dans les ZK-SNARK. Il existe un écosystème assez diversifié d'implémentations indépendantes : PSE ZK-EVM, Kakarot, Polygon ZK-EVM, Linea, Zeth et bien d'autres.
Une controverse récente dans le domaine du rollup EVM ZK concerne la manière de gérer les bogues pouvant apparaître dans le code ZK. Actuellement, tous ces systèmes en fonctionnement disposent d'une forme de mécanisme de « conseil de sécurité » qui contrôle le système d'attestation en cas de bug. L’année dernière, j’ai essayé de créer un cadre standardisé qui encouragerait les projets à préciser dans quelle mesure ils font confiance au système d’attestation et dans quelle mesure ils font confiance au Conseil de sécurité, et à réduire progressivement leur autorité sur cette organisation au fil du temps.
*À moyen terme, le rollup pourrait s'appuyer sur plusieurs systèmes de certification, et le Conseil de sécurité n'aura de pouvoir que dans les cas extrêmes où deux systèmes de certification différents divergent. *
Cependant, on a le sentiment qu’une partie de ce travail semble redondante. Nous avons déjà une couche de base Ethereum, elle a un EVM, et nous avons déjà un mécanisme fonctionnel pour gérer les bugs dans l'implémentation : s'il y a un bug, le client sera mis à jour pour le corriger, et la chaîne continuera à fonctionner . Du point de vue du client buggy, il semble que les blocages finalisés ne seront plus confirmés, mais au moins nous ne verrons pas les utilisateurs perdre de fonds. De même, si les rollups veulent simplement conserver le rôle équivalent d'EVM, ils doivent alors mettre en œuvre leur propre gouvernance pour modifier constamment leurs règles internes ZK-EVM afin de correspondre aux mises à niveau de la couche de base Ethereum, ce qui semble faux car en fin de compte, ils sont construits sur le dessus. de la couche de base Ethereum elle-même, il sait quand mettre à niveau et selon quelles nouvelles règles.
Étant donné que ces ZK-EVM L2 utilisent fondamentalement exactement le même EVM qu'Ethereum, pouvons-nous d'une manière ou d'une autre incorporer "vérifier l'exécution de l'EVM dans ZK" dans la fonctionnalité du protocole et gérer les exceptions en appliquant le consensus social d'Ethereum, comme les bugs et les mises à niveau, comme nous le faisons déjà pour le l'exécution EVM de la couche de base elle-même ?
Il s’agit d’un sujet important et stimulant.
Un sujet de débat possible concernant la disponibilité des données dans ZK-EVM natif est l'état. Les ZK-EVM seraient beaucoup plus efficaces en matière de données s'ils n'avaient pas besoin de transporter des données « témoins ». Autrement dit, si une donnée particulière a déjà été lue ou écrite dans un bloc précédent, nous pouvons simplement supposer que le prouveur y a accès et n'a pas besoin de la rendre à nouveau disponible. Il ne s'agit pas seulement de ne pas recharger le stockage et le code ; il s'avère que si un cumul compresse correctement les données, la compression avec état peut économiser jusqu'à 3 fois les données par rapport à la compression sans état.
Cela signifie que pour la précompilation ZK-EVM, nous avons deux options :
**1.**La précompilation nécessite que toutes les données soient disponibles dans le même bloc. Cela signifie que le prouveur peut être apatride, mais cela signifie également que l'utilisation de ce cumul ZK précompilé est beaucoup plus coûteuse que l'utilisation d'un cumul de code personnalisé.
**2.**La précompilation permet aux pointeurs de pointer vers les données utilisées ou générées par les exécutions précédentes. Cela rend le ZK-rollup proche de l'optimum, mais il est plus complexe et introduit un nouvel état qui doit être stocké par le prouveur.
Que pouvons-nous en tirer ? Il y a une bonne raison d'encapsuler la vérification ZK-EVM d'une manière ou d'une autre : le rollup construit déjà sa propre version personnalisée, et Ethereum est prêt à implémenter EVM sur L1 avec le poids de ses multiples implémentations et de son consensus social hors chaîne. , cela semble faux, mais L2, pour faire exactement le même travail, devrait mettre en œuvre un gadget complexe impliquant le Conseil de sécurité. Mais d'un autre côté, il y a un gros problème dans les détails : il existe différentes versions de ZK-EVM, et elles ont des coûts et des avantages différents. La distinction entre avec et sans état ne fait qu'effleurer la surface ; les tentatives de prise en charge du code personnalisé "presque-EVM" qui a été prouvé par d'autres systèmes peuvent exposer un espace de conception plus grand. Par conséquent, l'emballage de ZK-EVM apporte à la fois de l'espoir et des défis.
Proposant d'encapsulation et séparation du constructeur (ePBS)
L’essor du MEV fait de la production de blocs une activité économique à grande échelle, avec des acteurs sophistiqués capables de produire des blocs générant plus de revenus que l’algorithme par défaut, qui observe simplement un pool de transactions et les contient. Jusqu'à présent, la communauté Ethereum a tenté de résoudre ce problème en utilisant des schémas de séparation proposant-constructeur hors protocole tels que MEV-Boost, qui permet aux validateurs réguliers (« proposants ») de pousser des blocs vers le bâtiment. Le bâtiment est sous-traité à des acteurs spécialisés (« constructeurs »). ").
Cependant, MEV-Boost fait des hypothèses de confiance envers une nouvelle classe d’acteurs appelés relais. Au cours des deux dernières années, de nombreuses propositions ont été formulées pour créer un "PBS packagé". Quels sont les avantages de faire cela ? Dans ce cas, la réponse est très simple : un PBS construit en utilisant directement les fonctionnalités du protocole est plus puissant (dans le sens d’avoir des hypothèses de confiance plus faibles) qu’un PBS construit sans les utiliser. Ceci est similaire au cas de l’encapsulation d’oracles de prix dans un protocole – même si dans ce cas, il y a de fortes objections.
Encapsuler le pool de mémoire privée
Lorsqu'un utilisateur envoie une transaction, celle-ci est immédiatement publique et visible par tous, avant même qu'elle ne soit incluse dans la chaîne. Cela rend les utilisateurs de nombreuses applications vulnérables aux attaques économiques, telles que le front-running.
Récemment, un certain nombre de projets ont été consacrés à la création de « pools de mémoire privés » (ou « pools de mémoire cryptographiques »), qui chiffrent les transactions des utilisateurs jusqu'à ce qu'elles soient acceptées de manière irréversible dans un bloc.
Le problème, cependant, est qu'un tel système nécessite un type particulier de cryptage : pour empêcher les utilisateurs d'inonder le système et de le déchiffrer en premier, le cryptage doit être automatiquement déchiffré une fois que la transaction a été acceptée de manière irréversible.
Il existe différentes techniques avec différents compromis pour mettre en œuvre cette forme de cryptage. Jon Charbonneau l'a bien décrit un jour :
Malheureusement, chaque méthode de cryptage présente des faiblesses différentes. Même si pour chaque solution il existe un segment d’utilisateurs prêts à lui faire confiance, aucune solution n’est suffisamment fiable pour être réellement acceptée par la couche 1. **Ainsi, au moins jusqu'à ce que le cryptage différé soit perfectionné ou une autre avancée technologique, encapsuler la fonctionnalité de trading anti-ahead dans la couche 1 semble être une proposition difficile, même s'il s'agit d'une fonctionnalité suffisamment précieuse pour que de nombreuses applications résolvent le problème. un plan a émergé.
Encapsuler le jalonnement de liquidité
Un besoin commun parmi les utilisateurs d’Ethereum DeFi est la possibilité d’utiliser simultanément leur ETH pour le jalonnement et comme garantie dans d’autres applications. Une autre demande courante concerne simplement la commodité : les utilisateurs veulent pouvoir miser (et protéger les clés de jalonnement en ligne) sans la complexité de gérer un nœud et de le maintenir toujours en ligne.
L'interface de loin la plus simple qui répond à ces deux besoins n'est qu'un jeton ERC 20 : convertissez votre ETH en "ETH de jalonnement", conservez-le, puis reconvertissez-le. En fait, les fournisseurs de jalonnement de liquidité comme Lido et Rocket Pool le font déjà. Cependant, il existe certains mécanismes naturels de centralisation en jeu avec le staking de liquidité : les gens se tourneront naturellement vers le staking de la version la plus grande d’ETH car c’est la plus familière et la plus liquide.
Chaque version d'ETH mis en jeu doit disposer d'un mécanisme permettant de déterminer qui peut devenir l'opérateur de nœud sous-jacent. Cela ne peut pas être illimité, car les attaquants se joindront alors à nous et utiliseront les fonds des utilisateurs pour étendre leurs attaques. Actuellement, les deux premiers sont Lido et Rocket Pool, le premier ayant des opérateurs de nœuds DAO sur liste blanche et le second permettant à quiconque d'exécuter un nœud avec un dépôt de 8 ETH. Ces deux méthodes présentent des risques différents : la méthode Rocket Pool permet à un attaquant de mener une attaque à 51 % sur le réseau et oblige les utilisateurs à payer la plupart des coûts ; quant à la méthode DAO, si un certain token misé devient dominant, il entraînera à un seul, un gadget de gouvernance potentiellement compromis contrôle une grande partie de tous les validateurs Ethereum. Il faut reconnaître que des protocoles comme le Lido ont mis en place des garanties, mais une seule couche de défense pourrait ne pas suffire.
À court terme, une option consiste à encourager les acteurs de l’écosystème à recourir à un ensemble diversifié de fournisseurs de jalonnement de liquidités afin de réduire la possibilité qu’un acteur dominant pose un risque systémique. À long terme, cependant, l’équilibre est instable et il est dangereux de s’appuyer trop sur la pression morale pour résoudre les problèmes. Une question naturelle se pose : **Est-il judicieux d'encapsuler certaines fonctionnalités dans le protocole pour rendre le jalonnement de liquidité moins centralisé ? **
La question clé ici est : quel type de fonctionnalité dans le protocole ? Un problème lié à la simple création d'un jeton fongible de « staking ETH » au sein du protocole est qu'il devrait soit avoir une gouvernance encapsulée à l'échelle d'Ethereum pour choisir qui peut exécuter les nœuds, soit être à durée indéterminée, mais cela le transformerait en l'attaquant. Outils.
Une idée intéressante est l’article de Dankrad Feist sur la maximisation du jalonnement de liquidité. Tout d'abord, mordons la balle : si Ethereum est soumis à une attaque à 51 %, seulement 5 % de l'ETH attaqué peut être réduit. Il s'agit d'un compromis raisonnable ; avec plus de 26 millions d'ETH actuellement mis en jeu, le coût d'une attaque sur un tiers de ce montant (~ 8 millions d'ETH) est excessif, surtout si l'on considère le nombre d'attaques « hors modèle » qui peuvent être effectuées simultanément. moindre coût. En fait, des compromis similaires ont été explorés dans la proposition du Super Comité visant à mettre en œuvre la finalité du créneau unique.
Si nous acceptons que seulement 5 % de l’ETH d’attaque soit réduit, alors plus de 90 % de l’ETH mis en jeu ne sera pas affecté par la réduction, ils peuvent donc être utilisés comme jetons de jalonnement liquide fongibles dans le protocole, puis utilisés par d’autres applications.
Ce chemin est intéressant. Mais cela laisse encore une question : qu’est-ce qui est exactement encapsulé ? **Rocket Pool fonctionne de manière très similaire : chaque opérateur de nœud fournit une partie des fonds et les acteurs de la liquidité fournissent le reste. Nous pouvons simplement ajuster certaines constantes pour limiter la pénalité maximale à 2 ETH, et le rETH existant de Rocket Pool deviendra sans risque.
Avec de simples ajustements de protocole, nous pouvons également faire d’autres choses intelligentes. Par exemple, disons que nous voulons un système avec deux « niveaux » de jalonnement : les opérateurs de nœuds (exigences de garantie élevées) et les déposants (pas d'exigences de garantie minimale, peuvent rejoindre et quitter à tout moment), mais nous voulons quand même doter un échantillon aléatoire. le comité des déposants a le pouvoir d'empêcher la centralisation des opérateurs de nœuds, par exemple en recommandant une liste de transactions qui doivent être incluses (pour des raisons de résistance à la censure), en contrôlant la sélection des forks lors de fuites d'inactivité ou en exigeant des signatures sur les blocs. Cela pourrait être accompli d'une manière qui sort essentiellement du protocole en modifiant le protocole pour exiger que chaque validateur fournisse (i) une clé de jalonnement régulière, et (ii) une adresse ETH qui peut être utilisée dans chaque emplacement est appelée pour afficher le clé de gage secondaire. Le protocole autoriserait les deux clés, mais le mécanisme de sélection de la deuxième clé dans chaque emplacement pourrait être laissé au protocole du pool de jalonnement. Il est peut-être préférable d'encapsuler certaines fonctionnalités directement, mais il convient de noter que cet espace de conception "inclure certaines choses et laisser d'autres choses à l'utilisateur" existe.
Encapsuler plus de précompilation
Les contrats précompilés (ou « contrats précompilés ») sont des contrats Ethereum qui implémentent des opérations cryptographiques complexes, avec une logique implémentée nativement dans le code client plutôt que dans le code du contrat intelligent EVM. Le précodage est un compromis adopté dès le début du développement d'Ethereum : la surcharge d'une machine virtuelle étant trop importante pour certains codes très complexes et hautement spécialisés, nous pouvons implémenter certaines applications importantes en code natif et valoriser les opérations critiques pour les rendre plus rapides. Aujourd'hui, cela inclut essentiellement certaines fonctions de hachage spécifiques et des opérations sur les courbes elliptiques.
Il existe actuellement une pression pour ajouter une précompilation pour secp 256 r 1, une courbe elliptique légèrement différente de celle de secp 256 k 1 utilisée pour les comptes Ethereum de base, qui est largement utilisée car elle est bien prise en charge par des modules matériels de confiance. Utilisez-la pour augmenter la sécurité du portefeuille. Ces dernières années, la communauté a également poussé à ajouter la précompilation pour BLS-12-377, BW 6-761, l'appariement généralisé et d'autres fonctionnalités.
Le contre-argument à ces appels à davantage de précompilateurs est que bon nombre des précompilateurs ajoutés précédemment (tels que RIPEMD et BLAKE) ont fini par être beaucoup moins utilisés que prévu, et nous devrions en tirer des leçons. Plutôt que d'ajouter davantage de précompilation pour des opérations spécifiques, nous devrions peut-être nous concentrer sur une approche plus douce basée sur des idées comme EVM-MAX et la proposition SIMD Hibernate-But-Always-Resumable, qui permettrait aux implémentations EVM de fonctionner à moindre coût. un large éventail de classes de code. Peut-être que même la précompilation existante, peu utilisée, pourrait être supprimée et remplacée par une implémentation de code EVM (inévitablement moins efficace) des mêmes fonctions. Cela dit, il est toujours possible que certaines opérations cryptographiques spécifiques soient suffisamment précieuses pour être accélérées. Il est donc logique de les ajouter précompilées.
Qu'avons-nous appris de tout cela ?
Le désir d’encapsuler le moins possible est compréhensible et bon ; il découle de la tradition philosophique Unix de création de logiciels minimalistes qui peuvent facilement s’adapter aux différents besoins des utilisateurs et éviter la malédiction de la surcharge logicielle. Cependant, la blockchain n’est pas un système d’exploitation informatique personnel, mais un système social. Cela signifie qu’il est logique d’encapsuler certaines fonctionnalités dans le protocole.
Dans de nombreux cas, ces autres exemples sont similaires à ce que nous avons vu dans l’abstraction du compte. Mais nous avons également appris de nouvelles leçons :
Souvent, garder le protocole de base minimal et simple repousse la complexité vers un écosystème en dehors du protocole. Du point de vue de la philosophie Unix, c'est très bien. Cependant, il existe parfois un risque que l’écosystème hors protocole se centralise, généralement (mais pas seulement) en raison de coûts fixes élevés. L'encapsulation peut parfois réduire la centralisation de facto.
C’est le sujet de l’article précédent sur « Ne pas surcharger le consensus Ethereum » : si encapsuler une fonctionnalité spécifique affaiblit le modèle de confiance et rend Ethereum dans son ensemble plus « subjectif », cela affaiblit la neutralité crédible d’Ethereum. Dans ces cas, il est préférable d’avoir la fonctionnalité spécifique comme mécanisme au-dessus d’Ethereum plutôt que d’essayer de l’introduire dans Ethereum lui-même. Les pools de mémoire chiffrés en sont le meilleur exemple, qui peuvent être un peu difficiles à encapsuler, du moins jusqu'à ce que le chiffrement de la latence s'améliore.
La complexité des protocoles est un risque systémique qui augmente en ajoutant trop de fonctionnalités à un protocole. La précompilation en est le meilleur exemple.
Une fonctionnalité que beaucoup de gens considèrent comme importante et qui sera utilisée par de nombreux utilisateurs n’est probablement pas très souvent utilisée dans la pratique.
De plus, le jalonnement de liquidité, le ZK-EVM et des exemples précompilés montrent la possibilité d'une voie médiane : une consécration minimale viable. Le protocole n'a pas besoin d'encapsuler l'intégralité de la fonctionnalité, mais peut contenir des parties spécifiques qui répondent aux principaux défis, ce qui rend la fonctionnalité facile à mettre en œuvre sans être trop paranoïaque ou trop étroite. Les exemples comprennent:
On peut étendre le schéma précédent comme suit :
Parfois, il est judicieux d’encapsuler quelque chose, et la suppression des précompilateurs rarement utilisés en est un exemple. L'abstraction de compte dans son ensemble, comme mentionné précédemment, est également une forme importante de désencapsulation. Si nous voulons prendre en charge la compatibilité ascendante pour les utilisateurs existants, le mécanisme pourrait en fait être étonnamment similaire à celui qui a déballé la précompilation : l'une des propositions est EIP-5003, qui permettrait aux EOA de convertir leurs comptes pour avoir le même ( ou mieux) contrat fonctionnel.
Quelles fonctionnalités doivent être intégrées au protocole et lesquelles doivent être laissées à d’autres couches de l’écosystème est un compromis complexe. Ce compromis devrait continuer à s'améliorer au fil du temps, à mesure que notre compréhension des besoins des utilisateurs et de la suite d'idées et de technologies disponibles continue de s'améliorer.