Premières philosophies du minimalisme protocolaire
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 esthétiquement agréable qui essayait de construire par lui-même avec le moins possible et laissait presque tout ce type de travail aux utilisateurs. Idéalement, le protocole n’est qu’une machine virtuelle et la validation d’un morceau n’est qu’un appel de machine virtuelle.
La « fonction de transition d’état » (la fonction qui traite le morceau) ne sera qu’un seul appel de machine virtuelle, et toute la autre logique se produira via le contrat : certains contrats au niveau du système, mais surtout des contrats fournis par l’utilisateur. Une très bonne caractéristique de ce modèle est que même un hard fork entier peut être décrit comme une transaction unique pour un contrat de processeur de bloc qui sera approuvé par la gouvernance hors chaîne ou sur la chaîne, puis exécuté avec des privilèges élevés.
Ces discussions en 2015 s’appliquent en particulier à deux domaines que nous avons considérés : l’abstraction des comptes et la mise à l’échelle. Dans le cas de la mise à l’échelle, l’idée est d’essayer de créer une forme d’abstraction maximale de mise à l’échelle qui ressemble à une extension naturelle du graphique 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 détectera cela et résoudra l’appel avec une sorte de fonction informatique étendue très générale. Du point de vue de la machine virtuelle, l’appel va dans un sous-système distinct et renvoie comme par magie la bonne réponse après un certain temps.
Nous avons exploré brièvement cette ligne de pensée, mais avons rapidement abandonné parce que nous étions trop concentrés sur la vérification que tout type de mise à l’échelle de la blockchain est possible. Bien que nous le verrons plus tard, la combinaison de l’échantillonnage de 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! D’autre part, pour l’abstraction des comptes, nous savions dès le début qu’une sorte de mise en œuvre était possible, de sorte que la recherche a immédiatement commencé à essayer d’amener quelque chose aussi proche que possible du point de départ pur de « le trading n’est qu’un appel » dans la réalité.
Entre le traitement de la transaction et l’appel EVM sous-jacent réel à partir de l’adresse de l’expéditeur, il y a beaucoup de code passe-partout, et plus de code passe-partout après cela. Comment réduire ce code le plus près possible de zéro ?
L’un des principaux codes ici est validate_transaction(state, tx), qui est chargé de vérifier que la transaction a le nonce et la signature corrects. Dès le début, l’objectif pratique de l’abstraction de compte était de permettre aux utilisateurs de remplacer la vérification de base non incrémentielle et 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 l_transaction comme un simple appel EVM n’est pas seulement une tâche de « code propre pour rendre le code propre » ; Au lieu de cela, il s’agit de déplacer la logique dans le code de compte de l’utilisateur, donnant à l’utilisateur la flexibilité dont il a besoin.
Cependant, insister pour que les _transaction appliquent contiennent le moins de logique fixe possible finit par créer beaucoup de défis. Nous pouvons jeter un coup d’œil à l’une des premières propositions d’abstraction de compte, EIP-86 .
Si EIP-86 est inclus tel quel, cela réduira la complexité de l’EVM au prix d’une augmentation massive de la complexité d’autres parties de la pile Ethereum, nécessitant que du code essentiellement identique soit écrit ailleurs, sauf pour introduire de toutes nouvelles catégories étranges, telles que la même transaction avec le même numéro 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 de compte. Une transaction incluse dans la chaîne peut invalider des milliers d’autres transactions dans le mempool, ce qui rend le mempool facile à inonder à bon marché.
Depuis lors, l’abstraction du compte a évolué par étapes. L’EIP-86 est devenu plus tard l’EIP-208 et finalement l’EIP-2938.
Cependant, EIP-2938 est tout sauf minimaliste. Son contenu comprend :
· Nouveaux types de transactions
· Variables globales pour trois nouveaux champs de trading
· Deux nouveaux opcodes, y compris l’opcode PAYgas très maladroit pour gérer les contrôles des prix de l’essence et des limites de gaz, effectuer des points d’arrêt en EVM et stocker temporairement l’ETH moyennant des frais uniques
· Un ensemble complexe de stratégies d’exploration et de rediffusion, y compris une liste d’opcodes interdits pendant la phase de vérification des transactions
Afin de mettre en œuvre l’abstraction de compte sans impliquer les développeurs principaux d’Ethereum (qui se concentrent sur l’optimisation des clients Ethereum et la mise en œuvre de la fusion), EIP-2938 a finalement été restructuré en ERC-4337 entièrement hors protocole.
Parce qu’il s’agit d’un ERC, il ne nécessite pas de hard fork et existe techniquement « en dehors du protocole Ethereum ». Ainsi...... Le problème est-il résolu? Il s’avère que ce n’est pas le cas. La feuille de route à moyen terme actuelle de l’ERC-4337 implique en fait de transformer une grande partie de l’ERC-4337 en un ensemble de fonctionnalités de protocole, ce qui est un exemple utile de la raison pour laquelle cette voie devrait être envisagée.
Colis ERC-4337
Plusieurs raisons principales ont été discutées pour finalement ramener 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. Mettre ces composants dans un protocole est le moyen le plus simple d’éliminer ces problèmes.
Risque de bogue de code: Si le « contrat de point d’entrée » ERC-4337 a un bogue suffisamment effrayant, tous les portefeuilles compatibles ERC-4337 peuvent voir tous leurs fonds se tarir. Le remplacement des contrats par une fonctionnalité intégrée au protocole crée une obligation implicite de corriger les erreurs de code via des hard forks, éliminant ainsi le risque d’épuisement des fonds des utilisateurs.
Prise en charge des opcodes EVM tels que txt.origin. ERC-4337 lui-même provoque txt.origin pour renvoyer l’adresse d’un « bundler » qui empaquete un ensemble d’actions utilisateur dans une transaction. L’abstraction de compte native résout ce problème en faisant pointer txt.origin vers le compte réel qui envoie la transaction, ce qui la fait fonctionner de la même manière que EOA.
Résistant à la censure : L’un des défis de la séparation entre le proposant et le constructeur est qu’il devient plus facile d’examiner les transactions individuelles. Ce problème peut être grandement atténué dans un monde où le protocole Ethereum peut reconnaître une seule transaction, permettant au proposant de spécifier une liste de transactions qui doivent être incluses dans les deux emplacements suivants dans presque tous les cas. Cependant, ERC-4337 en dehors du protocole encapsule les « opérations utilisateur » dans une seule transaction, ce qui rend les opérations utilisateur opaques pour le 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 aux opérations des utilisateurs ERC-4337. L’encapsulation de ERC-4337 et la transformation de l’action de l’utilisateur en un type de transaction « approprié » résoudront ce problème.
Il convient de mentionner que dans sa forme actuelle, ERC-4337 est beaucoup plus cher qu’une transaction Ethereum « de base »: le coût de transaction est de 21 000 gaz, tandis que ERC-4337 coûte environ 42 000 gaz.
Théoriquement, il devrait être possible d’ajuster le coût du gaz EVM jusqu’à ce que le coût de l’accord et le coût de l’accès hors protocole au stockage correspondent; Lorsque d’autres types d’opérations d’édition de stockage sont moins chers, il n’y a aucune raison de transférer l’ETH à 9000 gaz. En fait, deux EIP liés à la prochaine conversion de l’arbre Verkle essaient de faire exactement cela. Mais même si nous le faisons, il y a une raison évidente pour laquelle la fonctionnalité de protocole encapsulé sera inévitablement beaucoup moins chère que le code EVM, quelle que soit l’efficacité de l’EVM : le code encapsulé n’a pas besoin de payer du gaz pour le préchargement.
Le portefeuille ERC-4337 entièrement fonctionnel est volumineux, et l’implémentation qui le compile et le met en chaîne prend 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 devez toujours accéder au code dans chaque bloc qui l’utilise. Dans le cadre de l’EIP sur le coût du gaz de Verkle, 12 800 octets constitueraient 413 morceaux, et l_cost’accès à ces morceaux nécessiterait de payer 2x la branche témoin (3 800 gaz au total) et 413x le morceau témoin _cost (82 600 gaz au total). Et cela ne commence même pas à mentionner le point d’entrée ERC-4337 lui-même, qui dans la version 0.6.0 a 23 689 octets sur la chaîne (environ 158 700 gaz à charger selon les règles EIP de l’arbre Verkle).
Cela conduit au problème: le coût du gaz pour accéder réellement à ces codes doit être amorti d’une manière ou d’une autre sur l’ensemble de la transaction. 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 coûteuse que les autres transactions. L’encapsulation dans le 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 l’emballage sera-t-il plus courant? **
Dans cet exemple, nous voyons différentes justifications pour encapsuler l’aspect abstraction de compte dans le protocole.
Les approches basées sur le marché qui « poussent la complexité à la limite » sont plus susceptibles d’échouer lorsque les coûts fixes sont élevés. En fait, la feuille de route d’abstraction des comptes à long terme semble indiquer que chaque bloc a beaucoup de coûts fixes. 244, 100 gaz pour charger des codes de portefeuille standardisés est une chose; Mais l’agrégation pourrait ajouter des centaines de milliers de gaz à la validation ZK-SNARK, ainsi que le coût en chaîne de la validation de la preuve de chaîne. Il n’y a aucun moyen de facturer ces coûts aux utilisateurs sans introduire beaucoup d’inefficacités du marché, et traduire certaines de ces fonctionnalités en fonctionnalités de protocole auxquelles tout le monde peut accéder gratuitement résout bien ce problème.
Réponses à l’échelle de la communauté aux bogues de code. Si certains extraits de code sont utilisés par tous les utilisateurs ou un très large éventail d’utilisateurs, il est généralement plus logique que la communauté blockchain prenne la responsabilité d’un hard fork pour corriger les bogues qui surviennent. ERC-4337 introduit une grande quantité de code partagé à l’échelle mondiale, et la correction de bogues dans le code via un hard fork est sans aucun doute plus raisonnable à long terme que de faire perdre beaucoup d’ETH aux utilisateurs.
Parfois, une forme plus forte peut être obtenue en tirant directement parti de la fonctionnalité du protocole. L’exemple clé ici est la fonctionnalité anti-censure dans le protocole, telle que la liste d’inclusion: la liste d’inclusion dans le protocole peut garantir la résistance à la censure mieux que la méthode en dehors du protocole, et pour que les opérations au niveau de l’utilisateur bénéficient vraiment de la liste d’inclusion dans le protocole, une seule opération au niveau de l’utilisateur doit être « lisible » pour le protocole. Un autre exemple moins connu est la conception de preuve d’enjeu Ethereum de l’ère 2017 qui a abstrait le compte clé d’enjeu, qui a été abandonné en faveur de l’encapsulation de BLS, car BLS prend en charge un mécanisme « d’agrégation » qui doit être mis en œuvre au niveau du protocole et du réseau, ce qui peut rendre le traitement d’un grand nombre de signatures plus efficace.
Mais il est important de se rappeler que même l’encapsulation de l’abstraction de compte dans le protocole est toujours une énorme « désencapsulation » par rapport à la situation actuelle. Aujourd’hui, les transactions Ethereum de premier plan ne peuvent être initiées qu’à partir de comptes externes (EOA) vérifiés avec une seule signature de courbe elliptique secp 256k1. L’abstraction de compte élimine cela et laisse les critères de validation à l’utilisateur pour définir. Ainsi, dans cette histoire sur l’abstraction de compte, nous voyons également le plus grand argument contre l’encapsulation: la flexibilité pour répondre aux besoins des différents utilisateurs.
Étoffons cette histoire en examinant plusieurs autres exemples de fonctionnalités qui ont récemment été considérées comme encapsulées. Nous accorderons une attention particulière à: ZK-EVM, la séparation proposant-constructeur, les mempools privés, le jalonnement de liquidité et la nouvelle précompilation.
Forfait ZK-EVM
Tournons notre attention vers une autre cible d’encapsulation potentielle du protocole Ethereum: ZK-EVM. Actuellement, nous avons un grand nombre de ZK-rollups, qui doivent tous écrire du code assez similaire pour vérifier l’exécution de blocs Ethereum similaires dans 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 l’espace EVM ZK-rollup concerne la façon de gérer les bogues possibles dans le code ZK. Actuellement, tous ces systèmes en cours d’exécution ont une forme de mécanisme « Conseil de sécurité » qui contrôle le système d’attestation en cas de bogues. L’année dernière, j’ai essayé de créer un cadre normalisé pour encourager les projets à clarifier leur niveau de confiance dans le système de certification, ainsi que dans le Conseil de sécurité, et à réduire progressivement leur autorité sur l’organisation au fil du temps.
À moyen terme, les synthèses peuvent s’appuyer sur des systèmes d’attestation multiples, et le Conseil de sécurité n’aura ce pouvoir que dans les cas extrêmes où deux systèmes d’attestation différents divergent.
Cependant, on a le sentiment qu’une partie du travail semble redondante. Nous avons déjà la couche de base Ethereum, elle a un EVM, et nous avons déjà un mécanisme de travail pour gérer les bogues dans l’implémentation: s’il y a un bogue, le client mettra à jour pour le corriger, puis la chaîne continuera à fonctionner. Du point de vue du client buggé, il semble que les blocs qui ont été finalisés ne seront plus confirmés, mais au moins nous ne verrons pas les utilisateurs perdre de l’argent. De même, si les rollups veulent simplement conserver leur rôle équivalent à EVM, ils doivent mettre en œuvre leur propre gouvernance pour modifier constamment leurs règles internes ZK-EVM pour correspondre aux mises à niveau de la couche de base Ethereum, ce qui semble faux car en fin de compte, ils sont construits sur la couche de base Ethereum elle-même, qui sait quand mettre à niveau et selon quelles nouvelles règles.
Étant donné que ces L2 ZK-EVM utilisent essentiellement exactement les mêmes EVM qu’Ethereum, pouvons-nous en quelque sorte intégrer « la vérification de l’exécution de l’EVM dans ZK » dans la fonction de protocole et gérer les exceptions telles que les bogues et les mises à niveau en appliquant le consensus social d’Ethereum, comme nous le faisons déjà avec l’implémentation EVM de la couche de base elle-même?
Il s’agit d’un sujet important et stimulant.
Un sujet de débat possible sur la disponibilité des données dans ZK-EVM natif est l’étativité. Si les ZK-EVM n’avaient pas besoin de transporter des données « témoins », leur efficacité des données serait beaucoup plus élevée. 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 praticien y a accès et n’a pas à la rendre disponible à nouveau. Il ne s’agit pas seulement de ne pas recharger le stockage et le code; Il s’avère que la compression avec état peut enregistrer jusqu’à 3x les données par rapport à la compression sans état si un cumul compresse correctement les données.
Cela signifie que pour la précompilation ZK-EVM, nous avons deux options :
La précompilation exige que toutes les données soient disponibles dans le même morceau. Cela signifie que prover peut être sans état, mais cela signifie également que l’utilisation de ce ZK-rollup précompilé est beaucoup plus coûteuse que l’utilisation de rollup avec du code personnalisé.
La précompilation permet au pointeur de pointer vers des données précédemment exécutées, utilisées ou générées. Cela rend ZK-rollup presque optimal, mais il est plus complexe et introduit un nouvel état qui doit être stocké par le prouveur.
Que pouvons-nous en apprendre? Il y a une bonne raison d’encapsuler en quelque sorte la vérification ZK-EVM: rollup construit déjà sa propre version personnalisée, et Ethereum est prêt à pondérer ses multiples implémentations et son consensus social hors chaîne sur L1 pour exécuter EVM, ce qui semble faux, mais L2 faisant exactement le même travail doit implémenter des gadgets complexes 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 du ZK-EVM, qui diffèrent par le coût et le bénéfice. La distinction entre apatrides et apatrides ne fait qu’effleurer la surface; Essayer de prendre en charge les codes personnalisés « presque-EVM », qui ont été prouvés par d’autres systèmes, peut exposer plus d’espace de conception. L’encapsulation du ZK-EVM présente donc à la fois des promesses et des défis.
Séparation de l’emballage et du constructeur (ePBS)
L’essor de la MEV a fait de la production de blocs une activité économique à grande échelle, avec des participants complexes capables de produire des blocs qui génèrent plus de revenus que l’algorithme par défaut, qui observe simplement le mempool de transactions et les contient. Jusqu’à présent, la communauté Ethereum a essayé de résoudre ce problème en utilisant un schéma de séparation proposant-constructeur hors protocole tel que MEV-Boost, qui permet aux validateurs réguliers (« proposants ») d’externaliser la construction de blocs à des participants spécialisés (« constructeurs »).
Cependant, MEV-Boost fait des hypothèses de confiance dans une nouvelle classe de participants appelés relais. Au cours des deux dernières années, il y a eu de nombreuses propositions visant à créer un « PBS encapsulé ». Quels en sont les avantages? Dans ce cas, la réponse est simple: PBS construit directement avec des fonctionnalités de protocole est plus puissant (dans le sens d’avoir des hypothèses de confiance plus faibles) que PBS construit sans eux. Ceci est similaire au cas des oracles de prix dans le protocole d’encapsulation – bien que dans ce cas, il existe également une forte opposition.
Encapsulation du pool de mémoire privée
Lorsqu’un utilisateur envoie une transaction, elle est immédiatement publique et visible par tout le monde, 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 les transactions préventives.
Récemment, il y a eu un certain nombre de projets dédiés à la création de « mempools privés » (ou « mempools cryptés ») qui cryptent les transactions des utilisateurs jusqu’à ce qu’elles soient irréversiblement acceptées dans un bloc.
Le problème, cependant, est que de tels schémas nécessitent un type spécial de cryptage: afin d’empêcher les utilisateurs d’inonder le système et de le décrypter en premier, le cryptage doit être automatiquement décrypté après que la transaction a effectivement été acceptée de manière irréversible.
Pour obtenir cette forme de cryptage, il existe différentes techniques de compromis. Jon Charbonneau l’a bien dit un jour :
Chiffrez les opérateurs centralisés, tels que Flashbots Protect.
le cryptage timelock, qui peut être déchiffré par n’importe qui après une certaine étape de calcul séquentiel et ne peut pas être parallélisé;
Cryptage de seuil, faisant confiance à un comité majoritaire honnête pour décrypter les données. Pour des recommandations spécifiques, voir Concept de chaîne de balises fermées.
Matériel de confiance, tel que SGX.
Malheureusement, chaque cryptage a des faiblesses différentes. Bien que pour chaque solution, il existe un sous-ensemble d’utilisateurs prêts à lui faire confiance, aucune des solutions n’est suffisamment fiable pour être acceptée par la couche 1. Ainsi, au moins jusqu’à ce que le chiffrement de latence soit perfectionné ou une autre percée technologique, encapsuler la fonctionnalité de trading anti-advance à la couche 1 semble être une proposition difficile, même si c’est une fonctionnalité suffisamment précieuse pour que de nombreuses solutions applicatives aient émergé.
Jalonnement de liquidité encapsulé
Un besoin commun pour les utilisateurs d’Ethereum DeFi est la possibilité d’utiliser leur ETH simultanément pour le jalonnement et comme garantie dans d’autres applications. Un autre besoin courant est simplement pour la commodité : les utilisateurs veulent être en mesure de jalonner (et de protéger les clés de jalonnement en ligne) sans la complexité d’exécuter un nœud et de le garder toujours en ligne.
Jusqu’à présent, l'« interface » de jalonnement la plus simple qui répond à ces deux besoins n’est qu’un jeton ERC 20 : convertissez votre ETH en « ETH de mise », conservez-le et reconvertissez-le. En fait, les fournisseurs de capitalisation de liquidité comme Lido et Rocket Pool ont déjà commencé à le faire. Cependant, le jalonnement de liquidité a des mécanismes de centralisation naturels à l’œuvre: les gens vont naturellement dans la plus grande version du jalonnement ETH parce que c’est la plus familière et la plus liquide.
Chaque version de l’ETH de jalonnement nécessite un mécanisme pour déterminer qui peut être l’opérateur de nœud sous-jacent. Il ne peut pas être illimité, car les attaquants se joindront à eux et amplifieront l’attaque avec les fonds de l’utilisateur. Actuellement, les deux premiers sont Lido, qui a un opérateur de nœud de liste blanche DAO, et Rocket Pool, qui permet à quiconque d’exécuter un nœud avec 8 ETH déposés. Les deux méthodes comportent des risques différents : l’approche Rocket Pool permet aux attaquants de mener 51% d’attaques sur le réseau et oblige les utilisateurs à payer la majeure partie du coût ; En ce qui concerne l’approche DAO, si un certain jeton de jalonnement domine, il en résulte un seul gadget de gouvernance potentiellement attaquable contrôlant une partie importante de tous les validateurs Ethereum. Certes, des protocoles comme Lido ont déjà mis en place des précautions, mais une couche de défense peut ne pas suffire.
À court terme, une option consiste à encourager les participants de l’écosystème à utiliser un large éventail de fournisseurs de jalonnement de liquidité afin de réduire la probabilité d’un risque systémique d’une seule entreprise. À long terme, cependant, il s’agit d’un équilibre précaire, et il est dangereux de trop compter sur la pression morale pour résoudre les problèmes. Une question naturelle se pose : est-il judicieux d’encapsuler une sorte de fonctionnalité dans le protocole pour rendre le jalonnement de liquidité moins centralisé ?
La question clé ici est : quel type de fonctionnalité dans le protocole ? Le problème avec la simple création d’un jeton fongible « staking ETH » dans le protocole est qu’il doit soit avoir une gouvernance encapsulée à l’échelle d’Ethereum pour choisir qui exécute les nœuds, soit il est ouvert, mais cela le transforme en un outil pour les attaquants.
Une idée intéressante est l’article de Dankrad Feist sur la maximisation du jalonnement de liquidité. Tout d’abord, mordons la balle et si Ethereum est attaqué par 51%, seulement 5% de l’ETH d’attaque peut être confisqué. Il s’agit d’un compromis raisonnable; Avec plus de 26 millions d’ETH actuellement en jeu, un tiers de ce montant (environ 8 millions d’ETH) du coût de l’attaque est excessif, en particulier si l’on considère le nombre d’attaques « hors modèle » pouvant être effectuées à moindre coût. En fait, des compromis similaires ont été explorés dans la proposition de la Super Commission visant à mettre en œuvre le caractère définitif de la créneau unique.
Si nous acceptons que seulement 5% de l’ETH d’attaque est confisquée, alors plus de 90% des ETH jalonnés ne seront pas affectés par la confiscation, de sorte qu’ils peuvent être utilisés comme jetons de jalonnement de liquidité fongibles dans le protocole, puis utilisés par d’autres applications.
Le chemin est intéressant. Mais il reste la question: qu’est-ce qui est encapsulé exactement? Le Rocket Pool fonctionne de manière très similaire: chaque opérateur de nœud fournit des fonds et les investisseurs en liquidité fournissent le reste. Nous pouvons simplement ajuster certaines constantes pour limiter la pénalité maximale à 2 ETH et le rETH existant du 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 « couches » de jalonnement: les opérateurs de nœuds (exigences élevées en matière de garantie) et les déposants (pas d’exigences minimales de garantie et peuvent rejoindre et quitter à tout moment), mais nous voulons toujours empêcher la centralisation des opérateurs de nœuds en habilitant un comité de déposants échantillonné au hasard, par exemple en suggérant une liste de transactions qui doivent être incluses (pour des raisons résistantes à la censure), en contrôlant la sélection des fourches lors de fuites inactives ou en exigeant la signature de blocs. Cela peut être réalisé d’une manière qui se détache essentiellement du protocole en ajustant le protocole pour exiger que chaque validateur fournisse (i) une clé de jalonnement régulière, et (ii) une adresse ETH qui peut être appelée sur chaque emplacement pour produire une clé de jalonnement secondaire. Le protocole donnera de l’énergie aux deux clés, mais le mécanisme de choix de la deuxième clé dans chaque emplacement peut être laissé au protocole de pool de jalonnement. Il est peut-être toujours préférable d’encapsuler directement certaines fonctionnalités, mais il convient de noter que cet espace de conception « inclut certaines choses et laisse tout le reste à l’utilisateur » existe.
Encapsuler plus de précompilations
Les contrats précompilés (ou « contrats précompilés ») sont des contrats Ethereum qui implémentent des opérations cryptographiques complexes, dont la logique est implémentée nativement dans le code client, plutôt que dans le code de contrat intelligent EVM. Le précodage était un compromis adopté au début du développement d’Ethereum : puisque la surcharge d’une machine virtuelle était trop importante pour un code très complexe et hautement spécialisé, nous pouvions implémenter certaines opérations clés dans le code local qui étaient précieuses pour les applications importantes pour le rendre plus rapide. Aujourd’hui, cela inclut essentiellement des fonctions de hachage spécifiques et des opérations de courbe elliptique.
Il y a actuellement une poussée pour ajouter une précompilation pour secp 256 R1, une courbe elliptique légèrement différente de secp 256 K1 pour les comptes Ethereum de base, car elle est bien prise en charge par des modules matériels de confiance, de sorte que son utilisation généralisée peut améliorer la sécurité du portefeuille. Ces dernières années, la communauté a également poussé à l’ajout de précompilations pour BLS-12-377, BW 6-761, l’appariement généralisé et d’autres fonctionnalités.
Le contre-argument à ces demandes de fichiers plus précompilés est que beaucoup de précompilations ajoutées précédemment (par exemple RIPEMD et BLAKE) finissent par utiliser beaucoup moins que prévu, et nous devrions en tirer des leçons. Au lieu d’ajouter plus de précompilation pour des opérations spécifiques, peut-être devrions-nous nous concentrer sur une approche plus douce basée sur des idées telles que EVM-MAX et des propositions SIMD dormantes mais toujours récupérables, qui permettront aux implémentations EVM d’exécuter un large éventail de classes de code à moindre coût. Peut-être même que la précompilation existante rarement utilisée pourrait être supprimée et remplacée par une implémentation (inévitablement moins efficace) du code EVM de la même fonction. Cela dit, il est toujours possible qu’il existe des opérations cryptographiques spécifiques suffisamment précieuses pour être accélérées, il est donc logique de les ajouter comme 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érive de la tradition philosophique Unix de créer des logiciels minimalistes qui peuvent être facilement adaptés aux différents besoins des utilisateurs et éviter la malédiction du gonflement des logiciels. 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 voyons dans l’abstraction du compte. Mais nous avons également appris de nouvelles leçons :
L’encapsulation peut aider à éviter le risque de centralisation ailleurs dans la pile :
Souvent, garder le protocole de base minimal et simple pousse la complexité au-delà de certains des protocoles de l’écosystème. D’un point de vue philosophique Unix, c’est bien. Cependant, il existe parfois un risque que les écosystèmes hors protocole se centralisent, 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 trop alourdir la charge de confiance et de gouvernance sur le protocole :
C’est le sujet d’un article précédent sur « Ne surchargez pas le consensus Ethereum » : si l’encapsulation d’une fonction particulière affaiblit le modèle de confiance et rend Ethereum dans son ensemble plus « subjectif », elle affaiblit la neutralité de confiance d’Ethereum. Dans ces cas, il est préférable de présenter une caractéristique spécifique comme un mécanisme au-dessus d’Ethereum que d’essayer de l’introduire dans Ethereum lui-même. Ici, les pools de mémoire chiffrée sont le meilleur exemple, et il peut être un peu difficile à encapsuler, du moins jusqu’à ce que le chiffrement de latence s’améliore.
Encapsuler trop peut compliquer excessivement le protocole :
La complexité du protocole est un risque systémique qui peut être augmenté en ajoutant trop de fonctionnalités au protocole. La précompilation en est le meilleur exemple.
À long terme, la fonctionnalité d’encapsulation peut se retourner contre vous, car les besoins des utilisateurs sont imprévisibles :
Une fonctionnalité que beaucoup de gens considèrent importante et qui sera utilisée par de nombreux utilisateurs n’est probablement pas utilisée régulièrement dans la pratique.
En outre, le jalonnement de liquidité, le ZK-EVM et les cas précompilés montrent la possibilité d’une voie médiane : une consécration viable minimale. Les protocoles n’ont pas besoin d’encapsuler toute la fonction, mais peuvent contenir des parties spécifiques qui répondent à des défis clés, ce qui rend la fonction facile à mettre en œuvre sans être trop paranoïaque ou trop étroite. En voici quelques exemples :
Au lieu d’encapsuler un système complet de nantissement de liquidité, il est préférable de modifier les règles de pénalité de jalonnement pour rendre plus réalisable le nantissement de liquidité sans confiance;
Au lieu d’encapsuler plus de précompilateurs, encapsulez EVM-MAX et/ou SIMD pour faciliter l’implémentation efficace pour un plus large éventail de catégories d’exploitation ;
La vérification EVM peut simplement être encapsulée au lieu d’encapsuler tout le concept de rollup.
Nous pouvons développer le graphique précédent comme suit:
Parfois, il est logique d’envelopper quelque chose, et la suppression de la précompilation rarement utilisée 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 rétrocompatibilité pour les utilisateurs existants, le mécanisme peut en fait être étonnamment similaire à celui qui désencapsule les précompilés: l’une des propositions est l’EIP-5003, qui permettrait à EOA de convertir ses comptes en contrats avec la même fonctionnalité (ou une meilleure).
Les caractéristiques qui devraient être introduites dans le protocole et celles qui devraient être laissées à d’autres couches de l’écosystème constituent un compromis complexe. On s’attend à ce que ce compromis continue de s’améliorer au fil du temps, à mesure que notre compréhension des besoins des utilisateurs et des idées et suites technologiques 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.
Vitalik Buterin: Ethereum devrait-il encapsuler plus de fonctionnalités?
Premières philosophies du minimalisme protocolaire
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 esthétiquement agréable qui essayait de construire par lui-même avec le moins possible et laissait presque tout ce type de travail aux utilisateurs. Idéalement, le protocole n’est qu’une machine virtuelle et la validation d’un morceau n’est qu’un appel de machine virtuelle.
La « fonction de transition d’état » (la fonction qui traite le morceau) ne sera qu’un seul appel de machine virtuelle, et toute la autre logique se produira via le contrat : certains contrats au niveau du système, mais surtout des contrats fournis par l’utilisateur. Une très bonne caractéristique de ce modèle est que même un hard fork entier peut être décrit comme une transaction unique pour un contrat de processeur de bloc qui sera approuvé par la gouvernance hors chaîne ou sur la chaîne, puis exécuté avec des privilèges élevés.
Ces discussions en 2015 s’appliquent en particulier à deux domaines que nous avons considérés : l’abstraction des comptes et la mise à l’échelle. Dans le cas de la mise à l’échelle, l’idée est d’essayer de créer une forme d’abstraction maximale de mise à l’échelle qui ressemble à une extension naturelle du graphique 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 détectera cela et résoudra l’appel avec une sorte de fonction informatique étendue très générale. Du point de vue de la machine virtuelle, l’appel va dans un sous-système distinct et renvoie comme par magie la bonne réponse après un certain temps.
Nous avons exploré brièvement cette ligne de pensée, mais avons rapidement abandonné parce que nous étions trop concentrés sur la vérification que tout type de mise à l’échelle de la blockchain est possible. Bien que nous le verrons plus tard, la combinaison de l’échantillonnage de 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! D’autre part, pour l’abstraction des comptes, nous savions dès le début qu’une sorte de mise en œuvre était possible, de sorte que la recherche a immédiatement commencé à essayer d’amener quelque chose aussi proche que possible du point de départ pur de « le trading n’est qu’un appel » dans la réalité.
Entre le traitement de la transaction et l’appel EVM sous-jacent réel à partir de l’adresse de l’expéditeur, il y a beaucoup de code passe-partout, et plus de code passe-partout après cela. Comment réduire ce code le plus près possible de zéro ?
L’un des principaux codes ici est validate_transaction(state, tx), qui est chargé de vérifier que la transaction a le nonce et la signature corrects. Dès le début, l’objectif pratique de l’abstraction de compte était de permettre aux utilisateurs de remplacer la vérification de base non incrémentielle et 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 l_transaction comme un simple appel EVM n’est pas seulement une tâche de « code propre pour rendre le code propre » ; Au lieu de cela, il s’agit de déplacer la logique dans le code de compte de l’utilisateur, donnant à l’utilisateur la flexibilité dont il a besoin.
Cependant, insister pour que les _transaction appliquent contiennent le moins de logique fixe possible finit par créer beaucoup de défis. Nous pouvons jeter un coup d’œil à l’une des premières propositions d’abstraction de compte, EIP-86 .
Si EIP-86 est inclus tel quel, cela réduira la complexité de l’EVM au prix d’une augmentation massive de la complexité d’autres parties de la pile Ethereum, nécessitant que du code essentiellement identique soit écrit ailleurs, sauf pour introduire de toutes nouvelles catégories étranges, telles que la même transaction avec le même numéro 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 de compte. Une transaction incluse dans la chaîne peut invalider des milliers d’autres transactions dans le mempool, ce qui rend le mempool facile à inonder à bon marché.
Depuis lors, l’abstraction du compte a évolué par étapes. L’EIP-86 est devenu plus tard l’EIP-208 et finalement l’EIP-2938.
Cependant, EIP-2938 est tout sauf minimaliste. Son contenu comprend :
· Nouveaux types de transactions
· Variables globales pour trois nouveaux champs de trading
· Deux nouveaux opcodes, y compris l’opcode PAYgas très maladroit pour gérer les contrôles des prix de l’essence et des limites de gaz, effectuer des points d’arrêt en EVM et stocker temporairement l’ETH moyennant des frais uniques
· Un ensemble complexe de stratégies d’exploration et de rediffusion, y compris une liste d’opcodes interdits pendant la phase de vérification des transactions
Afin de mettre en œuvre l’abstraction de compte sans impliquer les développeurs principaux d’Ethereum (qui se concentrent sur l’optimisation des clients Ethereum et la mise en œuvre de la fusion), EIP-2938 a finalement été restructuré en ERC-4337 entièrement hors protocole.
Parce qu’il s’agit d’un ERC, il ne nécessite pas de hard fork et existe techniquement « en dehors du protocole Ethereum ». Ainsi...... Le problème est-il résolu? Il s’avère que ce n’est pas le cas. La feuille de route à moyen terme actuelle de l’ERC-4337 implique en fait de transformer une grande partie de l’ERC-4337 en un ensemble de fonctionnalités de protocole, ce qui est un exemple utile de la raison pour laquelle cette voie devrait être envisagée.
Colis ERC-4337
Plusieurs raisons principales ont été discutées pour finalement ramener 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. Mettre ces composants dans un protocole est le moyen le plus simple d’éliminer ces problèmes.
Risque de bogue de code: Si le « contrat de point d’entrée » ERC-4337 a un bogue suffisamment effrayant, tous les portefeuilles compatibles ERC-4337 peuvent voir tous leurs fonds se tarir. Le remplacement des contrats par une fonctionnalité intégrée au protocole crée une obligation implicite de corriger les erreurs de code via des hard forks, éliminant ainsi le risque d’épuisement des fonds des utilisateurs.
Prise en charge des opcodes EVM tels que txt.origin. ERC-4337 lui-même provoque txt.origin pour renvoyer l’adresse d’un « bundler » qui empaquete un ensemble d’actions utilisateur dans une transaction. L’abstraction de compte native résout ce problème en faisant pointer txt.origin vers le compte réel qui envoie la transaction, ce qui la fait fonctionner de la même manière que EOA.
Résistant à la censure : L’un des défis de la séparation entre le proposant et le constructeur est qu’il devient plus facile d’examiner les transactions individuelles. Ce problème peut être grandement atténué dans un monde où le protocole Ethereum peut reconnaître une seule transaction, permettant au proposant de spécifier une liste de transactions qui doivent être incluses dans les deux emplacements suivants dans presque tous les cas. Cependant, ERC-4337 en dehors du protocole encapsule les « opérations utilisateur » dans une seule transaction, ce qui rend les opérations utilisateur opaques pour le 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 aux opérations des utilisateurs ERC-4337. L’encapsulation de ERC-4337 et la transformation de l’action de l’utilisateur en un type de transaction « approprié » résoudront ce problème.
Il convient de mentionner que dans sa forme actuelle, ERC-4337 est beaucoup plus cher qu’une transaction Ethereum « de base »: le coût de transaction est de 21 000 gaz, tandis que ERC-4337 coûte environ 42 000 gaz.
Théoriquement, il devrait être possible d’ajuster le coût du gaz EVM jusqu’à ce que le coût de l’accord et le coût de l’accès hors protocole au stockage correspondent; Lorsque d’autres types d’opérations d’édition de stockage sont moins chers, il n’y a aucune raison de transférer l’ETH à 9000 gaz. En fait, deux EIP liés à la prochaine conversion de l’arbre Verkle essaient de faire exactement cela. Mais même si nous le faisons, il y a une raison évidente pour laquelle la fonctionnalité de protocole encapsulé sera inévitablement beaucoup moins chère que le code EVM, quelle que soit l’efficacité de l’EVM : le code encapsulé n’a pas besoin de payer du gaz pour le préchargement.
Le portefeuille ERC-4337 entièrement fonctionnel est volumineux, et l’implémentation qui le compile et le met en chaîne prend 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 devez toujours accéder au code dans chaque bloc qui l’utilise. Dans le cadre de l’EIP sur le coût du gaz de Verkle, 12 800 octets constitueraient 413 morceaux, et l_cost’accès à ces morceaux nécessiterait de payer 2x la branche témoin (3 800 gaz au total) et 413x le morceau témoin _cost (82 600 gaz au total). Et cela ne commence même pas à mentionner le point d’entrée ERC-4337 lui-même, qui dans la version 0.6.0 a 23 689 octets sur la chaîne (environ 158 700 gaz à charger selon les règles EIP de l’arbre Verkle).
Cela conduit au problème: le coût du gaz pour accéder réellement à ces codes doit être amorti d’une manière ou d’une autre sur l’ensemble de la transaction. 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 coûteuse que les autres transactions. L’encapsulation dans le 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 l’emballage sera-t-il plus courant? **
Dans cet exemple, nous voyons différentes justifications pour encapsuler l’aspect abstraction de compte dans le protocole.
Les approches basées sur le marché qui « poussent la complexité à la limite » sont plus susceptibles d’échouer lorsque les coûts fixes sont élevés. En fait, la feuille de route d’abstraction des comptes à long terme semble indiquer que chaque bloc a beaucoup de coûts fixes. 244, 100 gaz pour charger des codes de portefeuille standardisés est une chose; Mais l’agrégation pourrait ajouter des centaines de milliers de gaz à la validation ZK-SNARK, ainsi que le coût en chaîne de la validation de la preuve de chaîne. Il n’y a aucun moyen de facturer ces coûts aux utilisateurs sans introduire beaucoup d’inefficacités du marché, et traduire certaines de ces fonctionnalités en fonctionnalités de protocole auxquelles tout le monde peut accéder gratuitement résout bien ce problème.
Réponses à l’échelle de la communauté aux bogues de code. Si certains extraits de code sont utilisés par tous les utilisateurs ou un très large éventail d’utilisateurs, il est généralement plus logique que la communauté blockchain prenne la responsabilité d’un hard fork pour corriger les bogues qui surviennent. ERC-4337 introduit une grande quantité de code partagé à l’échelle mondiale, et la correction de bogues dans le code via un hard fork est sans aucun doute plus raisonnable à long terme que de faire perdre beaucoup d’ETH aux utilisateurs.
Parfois, une forme plus forte peut être obtenue en tirant directement parti de la fonctionnalité du protocole. L’exemple clé ici est la fonctionnalité anti-censure dans le protocole, telle que la liste d’inclusion: la liste d’inclusion dans le protocole peut garantir la résistance à la censure mieux que la méthode en dehors du protocole, et pour que les opérations au niveau de l’utilisateur bénéficient vraiment de la liste d’inclusion dans le protocole, une seule opération au niveau de l’utilisateur doit être « lisible » pour le protocole. Un autre exemple moins connu est la conception de preuve d’enjeu Ethereum de l’ère 2017 qui a abstrait le compte clé d’enjeu, qui a été abandonné en faveur de l’encapsulation de BLS, car BLS prend en charge un mécanisme « d’agrégation » qui doit être mis en œuvre au niveau du protocole et du réseau, ce qui peut rendre le traitement d’un grand nombre de signatures plus efficace.
Mais il est important de se rappeler que même l’encapsulation de l’abstraction de compte dans le protocole est toujours une énorme « désencapsulation » par rapport à la situation actuelle. Aujourd’hui, les transactions Ethereum de premier plan ne peuvent être initiées qu’à partir de comptes externes (EOA) vérifiés avec une seule signature de courbe elliptique secp 256k1. L’abstraction de compte élimine cela et laisse les critères de validation à l’utilisateur pour définir. Ainsi, dans cette histoire sur l’abstraction de compte, nous voyons également le plus grand argument contre l’encapsulation: la flexibilité pour répondre aux besoins des différents utilisateurs.
Étoffons cette histoire en examinant plusieurs autres exemples de fonctionnalités qui ont récemment été considérées comme encapsulées. Nous accorderons une attention particulière à: ZK-EVM, la séparation proposant-constructeur, les mempools privés, le jalonnement de liquidité et la nouvelle précompilation.
Forfait ZK-EVM
Tournons notre attention vers une autre cible d’encapsulation potentielle du protocole Ethereum: ZK-EVM. Actuellement, nous avons un grand nombre de ZK-rollups, qui doivent tous écrire du code assez similaire pour vérifier l’exécution de blocs Ethereum similaires dans 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 l’espace EVM ZK-rollup concerne la façon de gérer les bogues possibles dans le code ZK. Actuellement, tous ces systèmes en cours d’exécution ont une forme de mécanisme « Conseil de sécurité » qui contrôle le système d’attestation en cas de bogues. L’année dernière, j’ai essayé de créer un cadre normalisé pour encourager les projets à clarifier leur niveau de confiance dans le système de certification, ainsi que dans le Conseil de sécurité, et à réduire progressivement leur autorité sur l’organisation au fil du temps.
À moyen terme, les synthèses peuvent s’appuyer sur des systèmes d’attestation multiples, et le Conseil de sécurité n’aura ce pouvoir que dans les cas extrêmes où deux systèmes d’attestation différents divergent.
Cependant, on a le sentiment qu’une partie du travail semble redondante. Nous avons déjà la couche de base Ethereum, elle a un EVM, et nous avons déjà un mécanisme de travail pour gérer les bogues dans l’implémentation: s’il y a un bogue, le client mettra à jour pour le corriger, puis la chaîne continuera à fonctionner. Du point de vue du client buggé, il semble que les blocs qui ont été finalisés ne seront plus confirmés, mais au moins nous ne verrons pas les utilisateurs perdre de l’argent. De même, si les rollups veulent simplement conserver leur rôle équivalent à EVM, ils doivent mettre en œuvre leur propre gouvernance pour modifier constamment leurs règles internes ZK-EVM pour correspondre aux mises à niveau de la couche de base Ethereum, ce qui semble faux car en fin de compte, ils sont construits sur la couche de base Ethereum elle-même, qui sait quand mettre à niveau et selon quelles nouvelles règles.
Étant donné que ces L2 ZK-EVM utilisent essentiellement exactement les mêmes EVM qu’Ethereum, pouvons-nous en quelque sorte intégrer « la vérification de l’exécution de l’EVM dans ZK » dans la fonction de protocole et gérer les exceptions telles que les bogues et les mises à niveau en appliquant le consensus social d’Ethereum, comme nous le faisons déjà avec l’implémentation EVM de la couche de base elle-même?
Il s’agit d’un sujet important et stimulant.
Un sujet de débat possible sur la disponibilité des données dans ZK-EVM natif est l’étativité. Si les ZK-EVM n’avaient pas besoin de transporter des données « témoins », leur efficacité des données serait beaucoup plus élevée. 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 praticien y a accès et n’a pas à la rendre disponible à nouveau. Il ne s’agit pas seulement de ne pas recharger le stockage et le code; Il s’avère que la compression avec état peut enregistrer jusqu’à 3x les données par rapport à la compression sans état si un cumul compresse correctement les données.
Cela signifie que pour la précompilation ZK-EVM, nous avons deux options :
La précompilation exige que toutes les données soient disponibles dans le même morceau. Cela signifie que prover peut être sans état, mais cela signifie également que l’utilisation de ce ZK-rollup précompilé est beaucoup plus coûteuse que l’utilisation de rollup avec du code personnalisé.
La précompilation permet au pointeur de pointer vers des données précédemment exécutées, utilisées ou générées. Cela rend ZK-rollup presque optimal, mais il est plus complexe et introduit un nouvel état qui doit être stocké par le prouveur.
Que pouvons-nous en apprendre? Il y a une bonne raison d’encapsuler en quelque sorte la vérification ZK-EVM: rollup construit déjà sa propre version personnalisée, et Ethereum est prêt à pondérer ses multiples implémentations et son consensus social hors chaîne sur L1 pour exécuter EVM, ce qui semble faux, mais L2 faisant exactement le même travail doit implémenter des gadgets complexes 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 du ZK-EVM, qui diffèrent par le coût et le bénéfice. La distinction entre apatrides et apatrides ne fait qu’effleurer la surface; Essayer de prendre en charge les codes personnalisés « presque-EVM », qui ont été prouvés par d’autres systèmes, peut exposer plus d’espace de conception. L’encapsulation du ZK-EVM présente donc à la fois des promesses et des défis.
Séparation de l’emballage et du constructeur (ePBS)
L’essor de la MEV a fait de la production de blocs une activité économique à grande échelle, avec des participants complexes capables de produire des blocs qui génèrent plus de revenus que l’algorithme par défaut, qui observe simplement le mempool de transactions et les contient. Jusqu’à présent, la communauté Ethereum a essayé de résoudre ce problème en utilisant un schéma de séparation proposant-constructeur hors protocole tel que MEV-Boost, qui permet aux validateurs réguliers (« proposants ») d’externaliser la construction de blocs à des participants spécialisés (« constructeurs »).
Cependant, MEV-Boost fait des hypothèses de confiance dans une nouvelle classe de participants appelés relais. Au cours des deux dernières années, il y a eu de nombreuses propositions visant à créer un « PBS encapsulé ». Quels en sont les avantages? Dans ce cas, la réponse est simple: PBS construit directement avec des fonctionnalités de protocole est plus puissant (dans le sens d’avoir des hypothèses de confiance plus faibles) que PBS construit sans eux. Ceci est similaire au cas des oracles de prix dans le protocole d’encapsulation – bien que dans ce cas, il existe également une forte opposition.
Encapsulation du pool de mémoire privée
Lorsqu’un utilisateur envoie une transaction, elle est immédiatement publique et visible par tout le monde, 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 les transactions préventives.
Récemment, il y a eu un certain nombre de projets dédiés à la création de « mempools privés » (ou « mempools cryptés ») qui cryptent les transactions des utilisateurs jusqu’à ce qu’elles soient irréversiblement acceptées dans un bloc.
Le problème, cependant, est que de tels schémas nécessitent un type spécial de cryptage: afin d’empêcher les utilisateurs d’inonder le système et de le décrypter en premier, le cryptage doit être automatiquement décrypté après que la transaction a effectivement été acceptée de manière irréversible.
Pour obtenir cette forme de cryptage, il existe différentes techniques de compromis. Jon Charbonneau l’a bien dit un jour :
Chiffrez les opérateurs centralisés, tels que Flashbots Protect.
le cryptage timelock, qui peut être déchiffré par n’importe qui après une certaine étape de calcul séquentiel et ne peut pas être parallélisé;
Cryptage de seuil, faisant confiance à un comité majoritaire honnête pour décrypter les données. Pour des recommandations spécifiques, voir Concept de chaîne de balises fermées.
Matériel de confiance, tel que SGX.
Malheureusement, chaque cryptage a des faiblesses différentes. Bien que pour chaque solution, il existe un sous-ensemble d’utilisateurs prêts à lui faire confiance, aucune des solutions n’est suffisamment fiable pour être acceptée par la couche 1. Ainsi, au moins jusqu’à ce que le chiffrement de latence soit perfectionné ou une autre percée technologique, encapsuler la fonctionnalité de trading anti-advance à la couche 1 semble être une proposition difficile, même si c’est une fonctionnalité suffisamment précieuse pour que de nombreuses solutions applicatives aient émergé.
Jalonnement de liquidité encapsulé
Un besoin commun pour les utilisateurs d’Ethereum DeFi est la possibilité d’utiliser leur ETH simultanément pour le jalonnement et comme garantie dans d’autres applications. Un autre besoin courant est simplement pour la commodité : les utilisateurs veulent être en mesure de jalonner (et de protéger les clés de jalonnement en ligne) sans la complexité d’exécuter un nœud et de le garder toujours en ligne.
Jusqu’à présent, l'« interface » de jalonnement la plus simple qui répond à ces deux besoins n’est qu’un jeton ERC 20 : convertissez votre ETH en « ETH de mise », conservez-le et reconvertissez-le. En fait, les fournisseurs de capitalisation de liquidité comme Lido et Rocket Pool ont déjà commencé à le faire. Cependant, le jalonnement de liquidité a des mécanismes de centralisation naturels à l’œuvre: les gens vont naturellement dans la plus grande version du jalonnement ETH parce que c’est la plus familière et la plus liquide.
Chaque version de l’ETH de jalonnement nécessite un mécanisme pour déterminer qui peut être l’opérateur de nœud sous-jacent. Il ne peut pas être illimité, car les attaquants se joindront à eux et amplifieront l’attaque avec les fonds de l’utilisateur. Actuellement, les deux premiers sont Lido, qui a un opérateur de nœud de liste blanche DAO, et Rocket Pool, qui permet à quiconque d’exécuter un nœud avec 8 ETH déposés. Les deux méthodes comportent des risques différents : l’approche Rocket Pool permet aux attaquants de mener 51% d’attaques sur le réseau et oblige les utilisateurs à payer la majeure partie du coût ; En ce qui concerne l’approche DAO, si un certain jeton de jalonnement domine, il en résulte un seul gadget de gouvernance potentiellement attaquable contrôlant une partie importante de tous les validateurs Ethereum. Certes, des protocoles comme Lido ont déjà mis en place des précautions, mais une couche de défense peut ne pas suffire.
À court terme, une option consiste à encourager les participants de l’écosystème à utiliser un large éventail de fournisseurs de jalonnement de liquidité afin de réduire la probabilité d’un risque systémique d’une seule entreprise. À long terme, cependant, il s’agit d’un équilibre précaire, et il est dangereux de trop compter sur la pression morale pour résoudre les problèmes. Une question naturelle se pose : est-il judicieux d’encapsuler une sorte de fonctionnalité dans le protocole pour rendre le jalonnement de liquidité moins centralisé ?
La question clé ici est : quel type de fonctionnalité dans le protocole ? Le problème avec la simple création d’un jeton fongible « staking ETH » dans le protocole est qu’il doit soit avoir une gouvernance encapsulée à l’échelle d’Ethereum pour choisir qui exécute les nœuds, soit il est ouvert, mais cela le transforme en un outil pour les attaquants.
Une idée intéressante est l’article de Dankrad Feist sur la maximisation du jalonnement de liquidité. Tout d’abord, mordons la balle et si Ethereum est attaqué par 51%, seulement 5% de l’ETH d’attaque peut être confisqué. Il s’agit d’un compromis raisonnable; Avec plus de 26 millions d’ETH actuellement en jeu, un tiers de ce montant (environ 8 millions d’ETH) du coût de l’attaque est excessif, en particulier si l’on considère le nombre d’attaques « hors modèle » pouvant être effectuées à moindre coût. En fait, des compromis similaires ont été explorés dans la proposition de la Super Commission visant à mettre en œuvre le caractère définitif de la créneau unique.
Si nous acceptons que seulement 5% de l’ETH d’attaque est confisquée, alors plus de 90% des ETH jalonnés ne seront pas affectés par la confiscation, de sorte qu’ils peuvent être utilisés comme jetons de jalonnement de liquidité fongibles dans le protocole, puis utilisés par d’autres applications.
Le chemin est intéressant. Mais il reste la question: qu’est-ce qui est encapsulé exactement? Le Rocket Pool fonctionne de manière très similaire: chaque opérateur de nœud fournit des fonds et les investisseurs en liquidité fournissent le reste. Nous pouvons simplement ajuster certaines constantes pour limiter la pénalité maximale à 2 ETH et le rETH existant du 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 « couches » de jalonnement: les opérateurs de nœuds (exigences élevées en matière de garantie) et les déposants (pas d’exigences minimales de garantie et peuvent rejoindre et quitter à tout moment), mais nous voulons toujours empêcher la centralisation des opérateurs de nœuds en habilitant un comité de déposants échantillonné au hasard, par exemple en suggérant une liste de transactions qui doivent être incluses (pour des raisons résistantes à la censure), en contrôlant la sélection des fourches lors de fuites inactives ou en exigeant la signature de blocs. Cela peut être réalisé d’une manière qui se détache essentiellement du protocole en ajustant le protocole pour exiger que chaque validateur fournisse (i) une clé de jalonnement régulière, et (ii) une adresse ETH qui peut être appelée sur chaque emplacement pour produire une clé de jalonnement secondaire. Le protocole donnera de l’énergie aux deux clés, mais le mécanisme de choix de la deuxième clé dans chaque emplacement peut être laissé au protocole de pool de jalonnement. Il est peut-être toujours préférable d’encapsuler directement certaines fonctionnalités, mais il convient de noter que cet espace de conception « inclut certaines choses et laisse tout le reste à l’utilisateur » existe.
Encapsuler plus de précompilations
Les contrats précompilés (ou « contrats précompilés ») sont des contrats Ethereum qui implémentent des opérations cryptographiques complexes, dont la logique est implémentée nativement dans le code client, plutôt que dans le code de contrat intelligent EVM. Le précodage était un compromis adopté au début du développement d’Ethereum : puisque la surcharge d’une machine virtuelle était trop importante pour un code très complexe et hautement spécialisé, nous pouvions implémenter certaines opérations clés dans le code local qui étaient précieuses pour les applications importantes pour le rendre plus rapide. Aujourd’hui, cela inclut essentiellement des fonctions de hachage spécifiques et des opérations de courbe elliptique.
Il y a actuellement une poussée pour ajouter une précompilation pour secp 256 R1, une courbe elliptique légèrement différente de secp 256 K1 pour les comptes Ethereum de base, car elle est bien prise en charge par des modules matériels de confiance, de sorte que son utilisation généralisée peut améliorer la sécurité du portefeuille. Ces dernières années, la communauté a également poussé à l’ajout de précompilations pour BLS-12-377, BW 6-761, l’appariement généralisé et d’autres fonctionnalités.
Le contre-argument à ces demandes de fichiers plus précompilés est que beaucoup de précompilations ajoutées précédemment (par exemple RIPEMD et BLAKE) finissent par utiliser beaucoup moins que prévu, et nous devrions en tirer des leçons. Au lieu d’ajouter plus de précompilation pour des opérations spécifiques, peut-être devrions-nous nous concentrer sur une approche plus douce basée sur des idées telles que EVM-MAX et des propositions SIMD dormantes mais toujours récupérables, qui permettront aux implémentations EVM d’exécuter un large éventail de classes de code à moindre coût. Peut-être même que la précompilation existante rarement utilisée pourrait être supprimée et remplacée par une implémentation (inévitablement moins efficace) du code EVM de la même fonction. Cela dit, il est toujours possible qu’il existe des opérations cryptographiques spécifiques suffisamment précieuses pour être accélérées, il est donc logique de les ajouter comme 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érive de la tradition philosophique Unix de créer des logiciels minimalistes qui peuvent être facilement adaptés aux différents besoins des utilisateurs et éviter la malédiction du gonflement des logiciels. 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 voyons dans l’abstraction du compte. Mais nous avons également appris de nouvelles leçons :
L’encapsulation peut aider à éviter le risque de centralisation ailleurs dans la pile :
Souvent, garder le protocole de base minimal et simple pousse la complexité au-delà de certains des protocoles de l’écosystème. D’un point de vue philosophique Unix, c’est bien. Cependant, il existe parfois un risque que les écosystèmes hors protocole se centralisent, 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 trop alourdir la charge de confiance et de gouvernance sur le protocole :
C’est le sujet d’un article précédent sur « Ne surchargez pas le consensus Ethereum » : si l’encapsulation d’une fonction particulière affaiblit le modèle de confiance et rend Ethereum dans son ensemble plus « subjectif », elle affaiblit la neutralité de confiance d’Ethereum. Dans ces cas, il est préférable de présenter une caractéristique spécifique comme un mécanisme au-dessus d’Ethereum que d’essayer de l’introduire dans Ethereum lui-même. Ici, les pools de mémoire chiffrée sont le meilleur exemple, et il peut être un peu difficile à encapsuler, du moins jusqu’à ce que le chiffrement de latence s’améliore.
Encapsuler trop peut compliquer excessivement le protocole :
La complexité du protocole est un risque systémique qui peut être augmenté en ajoutant trop de fonctionnalités au protocole. La précompilation en est le meilleur exemple.
À long terme, la fonctionnalité d’encapsulation peut se retourner contre vous, car les besoins des utilisateurs sont imprévisibles :
Une fonctionnalité que beaucoup de gens considèrent importante et qui sera utilisée par de nombreux utilisateurs n’est probablement pas utilisée régulièrement dans la pratique.
En outre, le jalonnement de liquidité, le ZK-EVM et les cas précompilés montrent la possibilité d’une voie médiane : une consécration viable minimale. Les protocoles n’ont pas besoin d’encapsuler toute la fonction, mais peuvent contenir des parties spécifiques qui répondent à des défis clés, ce qui rend la fonction facile à mettre en œuvre sans être trop paranoïaque ou trop étroite. En voici quelques exemples :
Au lieu d’encapsuler un système complet de nantissement de liquidité, il est préférable de modifier les règles de pénalité de jalonnement pour rendre plus réalisable le nantissement de liquidité sans confiance;
Au lieu d’encapsuler plus de précompilateurs, encapsulez EVM-MAX et/ou SIMD pour faciliter l’implémentation efficace pour un plus large éventail de catégories d’exploitation ;
La vérification EVM peut simplement être encapsulée au lieu d’encapsuler tout le concept de rollup.
Nous pouvons développer le graphique précédent comme suit:
Parfois, il est logique d’envelopper quelque chose, et la suppression de la précompilation rarement utilisée 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 rétrocompatibilité pour les utilisateurs existants, le mécanisme peut en fait être étonnamment similaire à celui qui désencapsule les précompilés: l’une des propositions est l’EIP-5003, qui permettrait à EOA de convertir ses comptes en contrats avec la même fonctionnalité (ou une meilleure).
Les caractéristiques qui devraient être introduites dans le protocole et celles qui devraient être laissées à d’autres couches de l’écosystème constituent un compromis complexe. On s’attend à ce que ce compromis continue de s’améliorer au fil du temps, à mesure que notre compréhension des besoins des utilisateurs et des idées et suites technologiques disponibles continue de s’améliorer.