Autre solution : Ethereum devrait-il accepter d’intégrer davantage de choses dans le protocole ?

Auteur : Vitalik Buterin

Compilé par : Nian Yin Si Tang, Planet Daily

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 créant 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 explorera certains des raisonnements philosophiques qui sous-tendent la philosophie originale de l'encapsulation minimale, ainsi que certaines réflexions récentes sur ces idées. L'objectif sera de commencer à établir un cadre permettant de mieux identifier les objectifs potentiels pour lesquels l'encapsulation de certaines fonctionnalités pourrait être envisagée.

Philosophie primitive du minimalisme protocolaire

Aux débuts de ce qui était alors connu sous le nom d'« Ethereum 2.0 », il existait une forte volonté de créer un protocole clair, simple et esthétique, capable d'en faire le moins possible par lui-même et de laisser la quasi-totalité du travail à l'utilisateur. Idéalement, le protocole aurait été une simple machine virtuelle, et la validation d'un bloc se serait limitée à un simple appel à cette machine.

Il s'agit d'une reconstruction fidèle d'un diagramme sur 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 traite un bloc) ne nécessitera qu'un seul appel à la VM, et toute la logique se fera via des contrats : certains au niveau système, mais principalement des contrats fournis par l'utilisateur. Une fonctionnalité intéressante de ce modèle est que même un hard fork complet peut être décrit comme une transaction unique vers le contrat du processeur de blocs, laquelle sera approuvée par la gouvernance on-chain ou off-chain, puis exécutée avec des autorisations améliorées.

Ces discussions de 2015 s'appliquaient particulièrement à deux domaines que nous examinions : l'abstraction des comptes et la mise à l'échelle. Dans le cas de la mise à l'échelle, l'idée était de créer une forme de mise à l'échelle la plus abstraite possible, qui s'apparenterait à une extension naturelle du schéma ci-dessus. Un contrat pourrait appeler des données que la plupart des nœuds Ethereum ne stockent pas, et le protocole détecterait ce phénomène et résoudrait l'appel via une fonction de calcul étendue très générale. Du point de vue de la machine virtuelle, l'appel serait dirigé vers un sous-système distinct et, quelque temps plus tard, renverrait la bonne réponse comme par magie.

Nous avons brièvement exploré cette piste de réflexion, mais l'avons rapidement abandonnée, trop préoccupés par la démonstration de la faisabilité de toute mise à l'échelle de la blockchain. Nous verrons plus loin que la combinaison de l'échantillonnage de la disponibilité des données et du ZK-EVM laisse entrevoir un avenir possible pour la mise à l'échelle d'Ethereum, qui semble assez proche de cette vision ! En revanche, avec l'abstraction des comptes, nous savions dès le départ qu'une certaine implémentation était possible. Les recherches ont donc immédiatement commencé à tenter de concrétiser un concept aussi proche que possible du principe de base « une transaction n'est qu'un appel ».

Il y a énormément de code standard entre le traitement d'une transaction et l'appel EVM sous-jacent depuis l'adresse de l'expéditeur, et encore plus de code standard après cela. Comment pouvons-nous réduire ce code au minimum ?

L'une des principales lignes de code est validate_transaction(state, tx), qui vérifie l'exactitude du nonce et de la signature de la transaction. Dès le départ, l'objectif de l'abstraction du compte était de permettre aux utilisateurs de remplacer la validation non incrémentielle de base et la validation ECDSA par leur propre logique de validation, afin de faciliter l'utilisation de fonctionnalités telles que la récupération sociale et les portefeuilles multi-signatures. Par conséquent, trouver un moyen de restructurer apply_transaction en un simple appel EVM n'était pas une simple tâche de « nettoyage du code pour le simple plaisir du code » ; il s'agissait plutôt d'intégrer la logique dans le code du compte utilisateur, lui offrant ainsi la flexibilité nécessaire.

Cependant, insister pour que l'application de la transaction contienne le moins de logique fixe possible a finalement posé de nombreux problèmes. Prenons l'exemple de 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 exact ailleurs, sauf en introduisant des classes entièrement nouvelles d'étrangetés, comme la possibilité que la même transaction avec le même hachage puisse 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 seule transaction intégrée à la chaîne peut invalider des milliers d'autres transactions dans le pool de mémoire, ce qui facilite l'inondation à moindre coût du pool.

Depuis lors, l'abstraction des comptes a évolué par phases. L'EIP-86 est ensuite devenu l'EIP-208, puis l'implémentation actuelle, l'EIP-2938.

Cependant, la norme EIP-2938 est loin d'être minimaliste. Elle comprend :

  • Nouveaux types de transactions

  • Trois nouvelles variables globales à portée commerciale

  • Deux nouveaux opcodes, dont l'opcode PAYgas très maladroit, qui gère les vérifications du prix et de la limite du gaz, agit comme un point d'arrêt d'exécution EVM et stocke temporairement l'ETH pour les paiements de frais uniques.

  • Un ensemble complexe de stratégies d'extraction et de relais, 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 concentraient sur l'optimisation des clients Ethereum et la mise en œuvre des fusions), EIP-2938 a finalement été réarchitecturé en tant qu'ERC-4337 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 ? En fait, pas vraiment. La feuille de route à moyen terme actuelle de l'ERC-4337 prévoit en réalité la transformation à terme de la majeure partie de l'ERC-4337 en une série de fonctionnalités du protocole, ce qui explique pourquoi cette voie est envisagée.

Emballage ERC-4337

Plusieurs raisons clés ont été évoquées pour justifier la réintégration éventuelle de l'ERC-4337 dans le protocole :

Efficacité du gaz : Toute opération effectuée dans l'EVM entraîne une surcharge de la machine virtuelle, notamment des inefficacités liées à l'utilisation de fonctionnalités de gaz coûteuses comme les emplacements de stockage. Actuellement, ces inefficacités supplémentaires peuvent représenter au moins 20 000 gaz, et souvent plus. Intégrer ces composants au protocole est 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 suffisamment grave, tous les portefeuilles compatibles ERC-4337 pourraient voir leurs fonds épuisés. Remplacer le contrat par une fonction interne au protocole crée une obligation implicite de corriger le bug de code via un hard fork, éliminant ainsi le risque de vider les fonds des utilisateurs.

Prise en charge des opcodes EVM tels que txt.origin. La norme ERC-4337 oblige nativement txt.origin à renvoyer l'adresse d'un « bundler » qui regroupe un ensemble d'opérations utilisateur dans une transaction. L'abstraction de compte native permet de résoudre ce problème en faisant pointer txt.origin vers le compte ayant réellement envoyé la transaction, ce qui lui permet de fonctionner de la même manière qu'EOA.

Résistance à la censure : L’un des défis de la séparation entre proposant et constructeur est qu’elle facilite la censure des transactions individuelles. Dans un monde où le protocole Ethereum peut identifier les transactions individuelles, les listes d’inclusion peuvent grandement atténuer ce problème. Ces listes permettent aux proposants de spécifier une liste de transactions à inclure dans les deux emplacements suivants dans la quasi-totalité des cas. Cependant, l’ERC-4337 hors protocole encapsule les « actions utilisateur » au sein d’une seule transaction, rendant ces actions opaques pour le protocole Ethereum ; par conséquent, les listes d’inclusion fournies par le protocole Ethereum ne peuvent pas offrir de résistance à la censure pour les actions utilisateur ERC-4337. Encapsuler l’ERC-4337 et faire des actions utilisateur un type de transaction « approprié » permettrait de résoudre 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 les coûts d'accès au stockage (in-protocole et hors protocole) correspondent ; il n'y a aucune raison pour que le transfert d'ETH coûte 9 000 gaz alors que d'autres types d'opérations d'édition de stockage sont moins coûteux. D'ailleurs, deux EIP liés à la conversion prochaine de l'arbre de Verkle tentent de le faire. Mais même si nous y parvenons, il existe une raison évidente pour laquelle les fonctionnalités du protocole encapsulé seront inévitablement beaucoup moins chères que le code EVM, quelle que soit l'efficacité de ce dernier : le code encapsulé n'a pas besoin de payer de gaz pour le préchargement.

Un portefeuille ERC-4337 pleinement fonctionnel est volumineux ; cette implémentation, compilée et déployée sur la chaîne, occupe environ 12 800 octets. Bien sûr, vous pourriez déployer ce code une fois et utiliser DELEGATECALL pour permettre à chaque portefeuille de l'appeler, mais ce code devrait toujours être accessible dans chaque bloc qui l'utilise. Selon l'EIP du coût en gaz de l'arbre de Verkle, 12 800 octets seraient organisés en 413 blocs, dont l'accès nécessiterait le double du coût de branche témoin (pour un total de 3 800 gaz) et le double du coût de bloc témoin (pour un total de 82 600 gaz). Et cela sans parler du point d'entrée ERC-4337 lui-même, qui, dans la version 0.6.0, représente 23 689 octets sur la chaîne (environ 158 700 gaz à charger, selon l'EIP de l'arbre de Verkle).

Cela pose un problème : le coût d'accès à ce code 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 efficace : la première transaction d'un bundle entraîne un coût unique de stockage/lecture de code, ce qui la rend bien plus coûteuse que les autres transactions. L'encapsulation intra-protocole permettrait à ces bibliothèques partagées publiques d'intégrer le protocole et d'être librement accessibles à tous.

Que pouvons-nous apprendre de cet exemple et quand utiliser l’encapsulation de manière plus générale ?

Dans cet exemple, nous avons vu différentes justifications pour encapsuler des aspects de l’abstraction de compte dans le protocole.

Les approches basées sur le marché qui « repoussent la complexité à l'extrême » sont plus susceptibles d'échouer lorsque les coûts fixes sont élevés. En effet, la feuille de route à long terme pour l'abstraction des comptes suggère que les coûts fixes par bloc sont nombreux. 244 100 gas pour charger un code de portefeuille standardisé est une chose ; mais l'agrégation pourrait ajouter des centaines de milliers de gas pour la vérification ZK-SNARK, ainsi que des coûts on-chain pour la vérification des preuves. Il est impossible de facturer ces coûts aux utilisateurs sans introduire d'importantes inefficacités sur le marché, et transformer certaines de ces fonctionnalités en fonctionnalités de protocole librement accessibles pourrait être une solution prometteuse.

Réponse communautaire aux bugs de code. Si un morceau de code est utilisé par tous les utilisateurs, voire par un très large éventail, il est souvent plus judicieux que la communauté blockchain prenne en charge le hard fork afin de corriger les bugs qui surviennent. La norme ERC-4337 introduit une grande quantité de code partagé mondialement, et à long terme, corriger les bugs de ce code via un hard fork est sans aucun doute plus raisonnable que de faire perdre aux utilisateurs de grandes quantités d'ETH.

Parfois, des formes plus robustes de ce système peuvent être obtenues en exploitant directement les fonctionnalités du protocole. Un exemple clé est la résistance à la censure au sein du protocole, comme les listes d'inclusion : ces listes peuvent offrir une meilleure résistance à la censure que les approches hors protocole. De plus, pour que les opérations utilisateur en bénéficient pleinement, chaque opération utilisateur doit être lisible par le protocole. Un autre exemple moins connu est la conception de preuve d'enjeu Ethereum de 2017, qui implémentait l'abstraction de compte pour les clés de jalonnement. Cette conception a été abandonnée au profit de Wrapper BLS, car ce dernier prend en charge un mécanisme d'agrégation qui doit être implémenté au niveau du protocole et du réseau, ce qui peut optimiser le traitement d'un grand nombre de signatures.

Il est important de rappeler que même l'abstraction des comptes au sein du protocole wrapper représente une désencapsulation significative par rapport au statu quo. Aujourd'hui, les transactions Ethereum de premier niveau ne peuvent être initiées qu'à partir de comptes externes (EOA), vérifiés à l'aide d'une signature unique à courbe elliptique secp256k1. L'abstraction des comptes élimine ce problème et laisse les conditions de vérification à l'utilisateur. Ainsi, dans cet article sur l'abstraction des comptes, nous voyons également le principal argument contre l'encapsulation : la flexibilité pour répondre aux besoins d'utilisateurs divers.

Approfondissons cette histoire en examinant quelques exemples de fonctionnalités récemment envisagées pour le packaging. Nous nous concentrerons plus particulièrement sur : ZK-EVM, la séparation proposant-constructeur, les mempools privés, le staking de liquidité et les nouvelles précompilations.

Paquet ZK-EVM

Intéressons-nous à une autre cible potentielle pour l'encapsulation du protocole Ethereum : ZK-EVM. Nous disposons actuellement d'un grand nombre de ZK-rollups, qui doivent tous écrire un code relativement 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 ZK EVM concerne la gestion des bugs potentiels dans le code ZK. Actuellement, tous ces systèmes en fonctionnement disposent d'un mécanisme de « conseil de sécurité » capable de prendre le contrôle du système de preuve en cas de bug. L'année dernière, j'ai tenté de créer un cadre standardisé pour encourager les projets à clarifier leur niveau de confiance dans le système de preuve et dans le conseil de sécurité, et à réduire progressivement son influence.

À moyen terme, les cumuls pourraient s’appuyer sur plusieurs systèmes de preuve, le Conseil de sécurité n’ayant de pouvoir que dans le cas extrême d’un désaccord entre deux systèmes de preuve différents.

Cependant, certains aspects de ce travail semblent redondants. Nous disposons déjà de la couche de base Ethereum, dotée d'une EVM, et d'un mécanisme opérationnel de gestion des bugs dans l'implémentation : en cas de bug, les clients sont mis à jour pour le corriger, et la chaîne continue de fonctionner. Du point de vue du client buggé, les blocs qui semblaient finalisés ne le seront plus, mais au moins, les utilisateurs ne perdront pas de fonds. De même, si les rollups souhaitent simplement maintenir la parité EVM, ils devraient mettre en œuvre leur propre gouvernance pour modifier en permanence leurs règles ZK-EVM internes afin de correspondre aux mises à niveau de la couche de base Ethereum. Cela semble anormal, car au final, ils reposent sur la couche de base Ethereum elle-même, qui sait quand mettre à niveau et selon quelles nouvelles règles.

Étant donné que ces ZK-EVM L2 utilisent essentiellement exactement le même EVM qu'Ethereum, pouvons-nous d'une manière ou d'une autre intégrer la « vérification de l'exécution de l'EVM dans ZK » dans la fonctionnalité du protocole et gérer les anomalies telles que les bugs et les mises à niveau en appliquant le consensus social d'Ethereum, comme nous le faisons déjà pour l'exécution de l'EVM de la couche de base elle-même ?

Il s’agit d’un sujet important et stimulant.

Un point de discorde potentiel concernant la disponibilité des données dans les ZK-EVM natives concerne l'état. Les ZK-EVM seraient bien plus efficaces en termes de données si elles n'avaient pas besoin de contenir de données « témoins ». Autrement dit, si une donnée 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. Cela va au-delà du simple fait de ne pas recharger le stockage et le code ; il s'avère que si un rollup compresse correctement les données, la compression avec état peut entraîner des économies de données jusqu'à trois fois supérieures à la compression sans état.

Cela signifie que pour les précompilations ZK-EVM, nous avons deux options :

1. Les précompilations nécessitent que toutes les données soient disponibles dans le même bloc. Cela signifie que le prouveur peut être sans état, mais cela signifie également qu'un cumul ZK utilisant cette précompilation est beaucoup plus coûteux qu'un cumul utilisant du code personnalisé.

2. La précompilation permet de pointer vers des données utilisées ou générées par des exécutions précédentes. Cela rend le rollup ZK 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 existe de bonnes raisons d'encapsuler la vérification ZK-EVM d'une manière ou d'une autre : les rollups créent déjà leurs propres versions personnalisées, et Ethereum est prêt à faire peser le poids de ses multiples implémentations et de son consensus social hors chaîne sur L1. Exécuter l'EVM semble inapproprié, mais L2, effectuant exactement la même tâche, doit implémenter des gadgets complexes impliquant un conseil de sécurité. Mais le diable est dans les détails : il existe différentes versions de ZK-EVM, avec des coûts et des avantages variables. La distinction entre avec et sans état n'est qu'une infime partie ; les tentatives de prise en charge de « presque-EVM », du code personnalisé éprouvé par d'autres systèmes, pourraient exposer un espace de conception encore plus vaste. Par conséquent, l'encapsulation de ZK-EVM est à la fois prometteuse et complexe.

Séparation du proposant et du constructeur de packages (ePBS)

L'essor du MEV a fait de la production de blocs une activité économique à grande échelle, permettant à des acteurs sophistiqués de produire des blocs générant davantage de revenus que l'algorithme par défaut, qui se contente d'observer le mempool de transactions et de les inclure. Jusqu'à présent, la communauté Ethereum a tenté d'exploiter le MEV pour booster Boost. BOOST est une plateforme applicative décentralisée conçue pour améliorer l'expérience des outils existants en augmentant leurs fonctionnalités et en les rendant plus robustes. BOOST est le jeton utilitaire natif utilisé pour débloquer des fonctionnalités avancées et évolutives, le vote futur dans les activités de gouvernance et le traitement des paiements pour les futures fonctionnalités des produits. Les prochains produits BOOST incluent BoostSWAP, BoostFARM et BoostNFT. Ces produits innovants amélioreront l'infrastructure DeFi existante et contribueront au développement de la communauté Internet décentralisée. BOOST Coin a été lancé le 9 août 2021, avec 1 milliard de jetons en circulation. Boost est actuellement négociable sur Uniswap et sera bientôt disponible sur BoostSwap. Voir plus Ce problème est résolu par des schémas de séparation hors protocole proposant-constructeur tels que [1], qui permettent aux validateurs réguliers (« proposants ») d'externaliser la construction de blocs à des participants spécialisés (« constructeurs »).

Cependant, MEV-Boost pose des hypothèses de confiance sur une nouvelle classe de participants, les relais. Ces deux dernières années, de nombreuses propositions ont été faites pour créer des « PBS encapsulés ». Quels en sont les avantages ? Dans ce cas précis, la réponse est simple : les PBS créés directement à l'aide des fonctions du protocole sont plus puissants (au sens où leurs hypothèses de confiance sont plus faibles) que ceux créés sans elles. Ce cas est similaire à l'encapsulation des oracles de prix dans le protocole, même si, dans ce cas, de fortes objections se font jour.

Encapsuler le pool de mémoire privé

Lorsqu'un utilisateur effectue une transaction, celle-ci est immédiatement publique et visible par tous, avant même d'être intégrée à 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 « mempools privés » (ou « mempools cryptés »), qui cryptent 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 de cryptage particulier : pour empêcher les utilisateurs d’inonder le système et de le décrypter en premier, le cryptage doit se décrypter automatiquement une fois que la transaction a été acceptée de manière irréversible.

Il existe différentes techniques pour mettre en œuvre ce type de chiffrement, avec des compromis différents. Jon Charbonneau l'a bien décrit :

Crypto vers des opérateurs centralisés comme Flashbots. Flashbots est une société de recherche et développement spécialisée dans la valeur extractible par les mineurs (MEV). Elle vise à atténuer les externalités négatives et les risques existentiels que la MEV pose aux blockchains de contrats intelligents. Voir plus Protéger.

Cryptage à verrouillage temporel : cette forme de cryptage peut être décryptée par n'importe qui après une certaine séquence d'étapes de calcul et ne peut pas être parallélisée ;

Chiffrement à seuil, faisant confiance à un comité majoritaire honnête pour déchiffrer les données. Pour des suggestions spécifiques, voir le concept de chaîne de balises fermée.

Matériel de confiance, tel que SGX.

Malheureusement, chaque méthode de chiffrement présente des faiblesses différentes. Bien qu'un sous-ensemble d'utilisateurs fasse confiance à chaque solution, aucune n'est suffisamment fiable pour être adoptée par la couche 1. Par conséquent, l'encapsulation d'une fonctionnalité anti-frontrunning dans la couche 1 semble difficile, du moins jusqu'à ce que le chiffrement différé soit perfectionné ou qu'une autre avancée technologique soit réalisée, même s'il s'agit d'une fonctionnalité suffisamment précieuse pour que de nombreuses solutions applicatives aient déjà émergé.

Jalonnement de liquidité encapsulé

Une demande fréquente des utilisateurs de la DeFi Ethereum est de pouvoir utiliser leurs ETH à la fois pour le staking et comme garantie dans d'autres applications. Une autre demande fréquente est simplement la commodité : les utilisateurs souhaitent pouvoir jalonner sans la complexité liée à l'exécution d'un nœud et à sa disponibilité permanente (et à la protection des clés de staking en ligne).

Jusqu'à présent, l'interface de staking la plus simple répondant à ces deux besoins se résumait à un jeton ERC20 : convertissez vos ETH en « ETH staking », conservez-les, puis reconvertissez-les. En réalité, Lido Lido Lido est une solution de staking de pool de liquidité. Lido permet aux utilisateurs de staker sur des chaînes publiques PoS avec des rendements composés tout en participant à des activités on-chain (telles que les prêts, le trading) sans dépôt minimum ni maintenance d'infrastructure. ETH2.0, Terra et Solana sont actuellement pris en charge, avec un potentiel d'extension à d'autres chaînes publiques POS à l'avenir. Voir plus et Rocket Rocket (ROCKET) est une cryptomonnaie lancée en 2021 qui fonctionne sur la plateforme BNB Smart Chain (BEP20). Voir plus Pool Pool soutient les organisations qui permettent aux particuliers de monétiser et de partager des données. Voir plus Les fournisseurs de staking de liquidité tels que ont déjà commencé à le faire. Cependant, certains mécanismes naturels de centralisation sont à l’œuvre avec le jalonnement de liquidité : les gens se tournent naturellement vers la plus grande version d’ETH jalonné car elle est la plus familière et la plus liquide.

Chaque version de staking d'ETH doit disposer d'un mécanisme permettant de déterminer qui peut devenir l'opérateur du nœud sous-jacent. Ce mécanisme ne peut être illimité, car des attaquants pourraient alors se joindre à eux et utiliser les fonds des utilisateurs pour étendre leur attaque. Actuellement, les deux principales sont Lido et Rocket Pool. Rocket Pool est un service d'infrastructure Ethereum PoS. Toute personne ou organisation souhaitant gagner des intérêts Ethereum par le biais d'un staking régulier peut participer au staking en exécutant un nœud sur le réseau grâce au réseau décentralisé et fiable de RocketPool. Voir plus : le premier a des opérateurs de nœuds sur liste blanche DAO, et le second permet à quiconque de gérer un nœud en déposant 8 ETH. Les deux méthodes présentent des risques différents : la méthode Rocket Pool permet aux attaquants de lancer une attaque à 51 % sur le réseau et de forcer les utilisateurs à payer la majeure partie des coûts ; quant à la méthode DAO, si un jeton staking devient dominant, un seul dispositif de gouvernance potentiellement attaquable contrôlera une grande partie de tous les validateurs Ethereum. Il est important de noter que des protocoles comme Lido ont mis en œuvre des mesures préventives, mais une seule couche de défense pourrait ne pas suffire.

À court terme, une option consiste à encourager les acteurs de l'écosystème à recourir à une gamme diversifiée de fournisseurs de liquidités afin de réduire le risque systémique potentiel d'un fournisseur dominant unique. Cependant, à long terme, cet équilibre est précaire, et il est dangereux de s'appuyer excessivement sur la pression morale pour résoudre le problème. Une question se pose naturellement : serait-il judicieux d'intégrer certaines fonctionnalités au protocole afin de rendre le staking de liquidités moins centralisé ?

La question clé ici est : quel type de fonctionnalité au sein du protocole ? Le problème avec la simple création d'un jeton « ETH staking » fongible au sein du protocole est qu'il doit soit intégrer une gouvernance à l'échelle d'Ethereum pour choisir qui gère les nœuds, soit être ouvert, ce qui en fait un outil pour les attaquants.

L'article de Dankrad Feist sur la maximisation du jalonnement de liquidité est une idée intéressante. Prenons d'abord le principe : si Ethereum était attaqué à 51 %, seuls 5 % des ETH attaqués seraient réduits. Il s'agit d'un compromis raisonnable ; avec plus de 26 millions d'ETH actuellement jalonnés, le coût d'une attaque d'un tiers de ce montant (environ 8 millions d'ETH) serait excessif, surtout si l'on considère le nombre d'attaques « hors modèle » qui pourraient être réalisées à moindre coût. En fait, un compromis similaire a déjà été exploré dans la proposition du « supercomité » visant à mettre en œuvre la finalité à un seul emplacement.

Si nous acceptons que seulement 5 % de l'ETH d'attaque soit réduit, alors plus de 90 % de l'ETH jalonné ne sera pas affecté par le slash, ils peuvent donc être utilisés comme jetons de jalonnement de liquidité fongibles au sein du protocole, puis utilisés par d'autres applications.

Cette approche est intéressante. Mais la question reste posée : qu'est-ce qui est encapsulé exactement ? Rocket Pool fonctionne de manière très similaire : chaque opérateur de nœud fournit des fonds, et les stakers de liquidité fournissent le reste. Il suffit d'ajuster certaines constantes pour plafonner la pénalité maximale de slashing à 2 ETH, et le rETH existant de Rocket Pool deviendra sans risque.

Nous pouvons également réaliser d'autres opérations astucieuses grâce à de simples ajustements du protocole. Par exemple, supposons que nous souhaitions un système à deux niveaux de jalonnement : les opérateurs de nœuds (avec des exigences de garantie élevées) et les déposants (sans exigences de garantie minimale et pouvant rejoindre et quitter le système à tout moment). Nous souhaitons néanmoins empêcher la centralisation des opérateurs de nœuds en conférant à un comité de déposants choisi au hasard des pouvoirs, tels que la possibilité de suggérer une liste de transactions à inclure (pour des raisons de résistance à la censure), de contrôler la sélection des forks pendant les périodes d'inactivité et de fuites, ou d'être tenus de signer des blocs. Cela peut être réalisé de manière largement hors protocole en modifiant le protocole pour exiger de chaque validateur qu'il fournisse (i) une clé de jalonnement standard et (ii) une adresse ETH pouvant être appelée pour générer une clé de jalonnement secondaire entre chaque emplacement. Le protocole accorderait des pouvoirs à ces deux clés, mais le mécanisme de sélection de la seconde clé dans chaque emplacement pourrait être laissé au protocole du pool de jalonnement. Il serait peut-être préférable d'encapsuler directement certaines fonctionnalités, mais il convient de noter que ce type d'espace de conception « inclure certaines choses, laisser d'autres à l'utilisateur » existe.

Encapsuler davantage de précompilés

Les précompilations (ou « contrats précompilés ») sont des contrats Ethereum qui implémentent des opérations cryptographiques complexes, dont la logique est nativement implémentée dans le code client, plutôt que dans le code du contrat intelligent EVM. Les précompilations étaient un compromis adopté au début du développement d'Ethereum : la surcharge de la machine virtuelle étant trop importante pour du code très complexe et hautement spécialisé, nous pouvions implémenter en code natif certaines opérations clés utiles aux applications importantes afin de les accélérer. Aujourd'hui, cela se résume principalement à quelques fonctions de hachage spécialisées et à des opérations sur courbes elliptiques.

Un effort est actuellement en cours pour ajouter une précompilation pour secp256r1, une courbe elliptique légèrement différente de secp256k1 utilisée pour les comptes Ethereum de base. Grâce à sa bonne prise en charge par des modules matériels fiables, son utilisation généralisée peut améliorer la sécurité des portefeuilles. Ces dernières années, la communauté a également œuvré pour l'ajout de précompilations pour BLS-12-377, BW6-761, les appariements généralisés et d'autres fonctionnalités.

Un contre-argument à ces appels à davantage de précompilations est que de nombreuses précompilations précédemment ajoutées (telles que RIPEMD et BLAKE) ont finalement été bien moins utilisées que prévu, et c'est une leçon à retenir. Plutôt que d'ajouter des précompilations supplémentaires pour des opérations spécifiques, nous devrions peut-être privilégier une approche plus modérée basée sur l'EVM. Le jeton MAX MAX est un jeton utilitaire émis par Maxcoin Asset Exchange (MAX). MAX Exchange se concentre sur le soutien de sa communauté de trading et fournit la plateforme de trading la plus sécurisée. Les jetons MAX seront récompensés par le minage de transactions et pourront également être utilisés pour des récompenses de jalonnement sur la plateforme. Découvrez d'autres idées comme la proposition SIMD, dormante mais toujours réactivable, qui permettrait aux implémentations EVM d'exécuter un large éventail de classes de code à moindre coût. Il serait même possible de supprimer les précompilations existantes, rarement utilisées, et de les remplacer par des implémentations de code EVM (inévitablement moins efficaces) des mêmes fonctions. Cela dit, certaines opérations cryptographiques spécifiques peuvent encore avoir une valeur suffisamment élevée pour justifier leur ajout en tant que précompilations.

Qu’avons-nous appris de tout cela ?

La volonté d'encapsuler le moins possible est compréhensible et bénéfique ; elle découle de la tradition philosophique d'Unix, qui consiste à créer des logiciels minimalistes, facilement adaptables aux différents besoins des utilisateurs, évitant ainsi le fléau de la surabondance logicielle. Cependant, les blockchains ne sont pas des systèmes d'exploitation pour ordinateurs personnels, mais des systèmes sociaux. Il est donc logique d'encapsuler certaines fonctionnalités au sein du protocole.

Dans de nombreux cas, ces exemples sont similaires à ceux observés avec l'abstraction de compte. Mais nous avons également tiré de nouvelles leçons :

  • L'encapsulation des fonctionnalités peut aider à éviter les risques de centralisation dans d'autres zones de la pile :

Souvent, maintenir un protocole de base minimal et simple transfère la complexité vers une partie de l'écosystème hors protocole. Du point de vue de la philosophie Unix, c'est acceptable. Cependant, il existe parfois un risque que l'écosystème hors protocole devienne centralisé, souvent (mais pas exclusivement) en raison de coûts fixes élevés. L'encapsulation peut parfois réduire la centralisation de facto.

  • Encapsuler trop d’éléments peut accroître excessivement la confiance et la charge de gouvernance du protocole :

C'est le thème d'un article précédent intitulé « Ne surchargez pas le consensus Ethereum » : si l'encapsulation d'une fonctionnalité spécifique affaiblit le modèle de confiance et rend Ethereum dans son ensemble plus « subjectif », cela compromet sa neutralité de confiance. Dans ce cas, il est préférable d'implémenter la fonctionnalité spécifique sous forme de mécanisme au-dessus d'Ethereum plutôt que de tenter de l'introduire dans Ethereum lui-même. Les pools de mémoire cryptographiques en sont le meilleur exemple, et leur encapsulation peut s'avérer difficile, du moins jusqu'à ce que la cryptographie différée s'améliore.

  • Encapsuler trop de choses peut compliquer le protocole :

La complexité des protocoles constitue un risque systémique, et l'ajout de trop de fonctionnalités à un protocole l'accroît. Les précompilations en sont un parfait exemple.

  • L’encapsulation des fonctionnalités peut être contre-productive à long terme 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 peut ne pas être utilisée très souvent dans la pratique.

De plus, les exemples de jalonnement de liquidité, de ZK-EVM et de précompilations illustrent la possibilité d'une voie intermédiaire : l'enchâssement minimal viable. Au lieu d'encapsuler la fonctionnalité dans son intégralité, le protocole peut inclure des parties spécifiques répondant à des défis clés, facilitant ainsi son implémentation sans être trop paranoïaque ou trop restreint. Exemples :

  • Plutôt que 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, encapsulez EVM-MAX et/ou SIMD pour rendre une classe d'opérations plus large plus facile à implémenter efficacement ;

  • Au lieu d'encapsuler l'intégralité du concept d'un rollup, il peut simplement encapsuler la vérification EVM.

Nous pouvons développer le diagramme précédent comme suit :

Il est parfois judicieux de désencapsuler quelque chose, et la suppression des précompilations rarement utilisées 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 souhaitons assurer la rétrocompatibilité pour les utilisateurs existants, le mécanisme pourrait être étonnamment similaire à celui de la désencapsulation des précompilations : l'une de ces propositions est l'EIP-5003, qui permettrait aux EOA de convertir leurs comptes en contrats avec des fonctionnalités identiques (ou supérieures).

L’équilibre entre les fonctionnalités qui doivent être intégrées au protocole et celles qui doivent être laissées à d’autres couches de l’écosystème est complexe et continuera, espérons-le, à s’améliorer au fil du temps, à mesure que notre compréhension des besoins des utilisateurs et de l’ensemble des idées et technologies disponibles s’améliore.