La mise à niveau d'Ethereum Cancun approche, passant en revue le passé, le présent et l'avenir de la mise à niveau de Cancun

Auteur : Fat Bird Finance

vies antérieures

#### Pourquoi la mise à niveau de Cancun est-elle nécessaire ?

La vision d'Ethereum est de devenir plus évolutif et plus sécurisé sous le principe de la décentralisation. La mise à jour actuelle d'Ethereum s'est également engagée à résoudre ce trilemme, mais elle a été confrontée à de grands défis.

Problèmes avec Ethereum :

À l'heure actuelle, le TPS et les performances sont faibles, les frais d'essence élevés et la congestion grave.Dans le même temps, l'espace disque requis pour exécuter un client Ethereum augmente également rapidement.En bas, la charge de travail pour assurer la sécurité et la décentralisation d'EthereumL'impact de l'algorithme de consensus sur l'ensemble de l'environnement prend également de plus en plus d'importance.

Par conséquent, sous le principe de la décentralisation, comment transmettre plus de données et réduire le gaz pour améliorer l'évolutivité, et comment optimiser l'algorithme de consensus pour assurer la sécurité sont tous les efforts qu'Ethereum déploie actuellement.

Afin de résoudre le trilemme de la sécurité, de la décentralisation et de l'évolutivité, Ethereum a utilisé le mécanisme PoW-to-PoS pour réduire davantage le seuil de nœud, et prévoit également d'utiliser la chaîne de balises pour attribuer au hasard des vérificateurs afin d'optimiser la sécurité. d'évolutivité, Ethereum envisage d'utiliser le sharding pour réduire la charge de travail des nœuds, ce qui permet également à Ethereum de créer plusieurs blocs en même temps et d'améliorer son évolutivité.

À l'heure actuelle, l'espace de chaque bloc d'Ethereum est d'environ 200 ~ 300 Ko, la taille minimale de chaque transaction est d'environ 100 octets, environ 2000 transactions, divisées par le temps de bloc de 12 secondes, la limite supérieure du TPS d'Ethereum est limitée à environ 100. Ces données ne peuvent évidemment pas répondre aux besoins d'Ethereum.

Par conséquent, Ethereum Layer 2 se concentre sur la manière de mettre une grande quantité de données dans l'espace de blocs et d'assurer la sécurité grâce à des preuves de fraude et à des preuves de validité.C'est pourquoi la couche DA détermine la limite supérieure de sécurité, qui est également le contenu central du Mise à niveau de Cancún.

La route itérative de l'écologie Ethereum ne peut pas construire les performances du benchmark Solana (en termes de délai et de débit), et les performances de fragmentation de Near ne se verront pas à court terme, ni les performances d'exécution parallèle de Sui et Aptos. À court terme, Ethereum ne peut que Construire une structure multicouche avec Rollup comme noyau, de sorte que la mise à niveau de Cancun pour résoudre TPS, gasfee et l'expérience des développeurs est cruciale pour la feuille de route Ethereum.

Comment la feuille de route Ethereum est-elle planifiée ?

Mises à jour importantes récentes et leurs objectifs

Le 1er décembre 2020, la chaîne de balises a été officiellement lancée, ouvrant la voie aux mises à niveau des points de vente

Mise à niveau de Londres le 5 août 2021, EIP1559 a changé le modèle économique d'Ethereum ;

Le 15 septembre 2022, la mise à niveau de Paris (TheMerge) a achevé le passage de POW à POS;

Le 12 avril 2023, Shanghai a été mis à niveau pour résoudre le problème du retrait des promesses ;

Le modèle économique et les mises à niveau liées aux points de vente sont terminées, et les prochaines mises à niveau ont résolu les problèmes de performances, de TPS et d'expérience des développeurs d'Ethereum ;

La prochaine étape se concentre sur TheSurge dans la feuille de route Ethereum.

Objectif : atteindre plus de 100 000 TPS en Rollup.

Il existe principalement 2 solutions, on-chain et off-chain :

Solution hors chaîne : fait référence à la couche 2, y compris le cumul, etc.

Schéma en chaîne : fait référence à l'apport de modifications directement dans L1, qui est un schéma de partitionnement populaire. Une compréhension simple du partitionnement consiste à diviser tous les nœuds en différentes zones et à effectuer les tâches de chaque zone, ce qui augmentera efficacement la vitesse ;

Analyse du schéma de fragmentation :

Le dilemme du schéma de sharding : le sharding incluait auparavant le sharding d'état, le sharding de transaction, etc., mais la synchronisation entre les différents shards est un problème. À l'heure actuelle, il est techniquement difficile de réaliser une synchronisation de données de nœud de réseau à grande échelle. Non seulement ne peut-il pas résoudre la situation de MEV, mais aussi un grand nombre de correctifs peuvent être nécessaires pour pallier divers problèmes pouvant survenir, qui ne peuvent être réalisés à court terme.

Danksharding est une nouvelle conception de partitionnement proposée pour Ethereum. Son idée centrale est la génération de blocs centralisée + la vérification décentralisée + la résistance à la censure. Ceci est également lié à l'échantillonnage de la disponibilité des données (DAS) et aux producteurs de blocs mentionnés ci-dessous. - Séparation de l'emballeur (PBS) et censure Liées aux listes résistantes (Crlist). La plus grande importance de l'idée centrale de Danksharding est de transformer Ethereum L1 en une couche unifiée de règlement et de disponibilité des données (DataAvailability).

Le schéma de partitionnement est divisé en étapes 2. À l'heure actuelle, il est divisé en Proto-danksharding et Fully-Rollup.

Proto-danksharding：

Introduction : En introduisant des blobs pour aider L2 à réduire les frais et à augmenter le débit, cela ouvre également la voie à un partage complet en tant que pré-schéma pour le danksharding. Il est prévu qu'après le proto-danksharding, il faudra 2 à 5 ans pour la mise en œuvre du danksharding.

Contenu: La principale caractéristique du proto-danksharding est d'introduire un nouveau type de transaction blob. Blob a les caractéristiques d'une grande capacité et d'un faible coût. L'ajout de tels paquets de données à Ethereum peut permettre à toutes les données cumulées d'être stockées dans blob, réduisant considérablement le stockage de la pression de la chaîne principale, mais aussi réduire le coût de rollup.

Entièrement cumulatif

Introduction : Rollup étend entièrement la capacité, en se concentrant sur l'utilisation de la disponibilité des données.

contenu:

Conception P2P de DAS : certains travaux et recherches liés au problème de connexion au réseau de partage de données ;

Client d'échantillonnage de la disponibilité des données : développez un client léger capable de déterminer rapidement si les données sont disponibles en échantillonnant de manière aléatoire quelques kilo-octets ;

Auto-guérison efficace de l'AD : capable de reconstruire efficacement toutes les données dans les pires conditions du réseau (par exemple, une attaque de validateur malveillant ou un long temps d'arrêt de nœuds de bloc volumineux).

Réunion des développeurs Ethereum Core

Chaque mise à niveau d'Ethereum dépend de la réunion des développeurs principaux, à travers la discussion conjointe des principaux contributeurs, et selon une série de propositions des développeurs, la direction future du développement est déterminée

Définition : La réunion principale des développeurs est une conférence téléphonique hebdomadaire organisée par la communauté de développement Ethereum, où les principaux contributeurs de différentes organisations discutent des problèmes techniques et coordonnent les travaux futurs sur Ethereum. Ils déterminent l'orientation technique future du protocole Ethereum et sont également l'autorité qui prend réellement les décisions concernant la mise à niveau d'Ethereum.Ils sont chargés de décider si l'EIP est inclus dans la mise à niveau, s'il est nécessaire de modifier la feuille de route et d'autres éléments importants. importe.

Processus de base : le processus de mise à niveau centré sur l'EIP est à peu près le suivant. Tout d'abord, un EIP est initialement accepté lors de la conférence des développeurs de base (ACD en abrégé), puis l'équipe client le teste, que l'EIP soit inclus ou non dans la mise à niveau. Après le test final, révisez-le à nouveau, puis décidez de l'inclure dans la mise à niveau réelle en fonction de la discussion.

Il existe deux types de réunions, à savoir la réunion de la couche consensus et la réunion de la couche exécutive, qui se tiennent alternativement toutes les deux semaines :

Consensus Layer Conference (AllCore Developers Consensus - ACDC), axée sur la couche consensus d'Ethereum (Proof of Stake, Beacon Chain, etc.);

Conférence sur la couche exécutive (solution AllCore Developers - ACDE), qui porte sur la couche d'exécution d'Ethereum (EVM, Gas schedule, etc.).

Il existe trois types de mainteneurs principaux d'Ethereum, principalement des organisations officielles ou des forums de bénévoles qui discutent des propositions :

AllCoreDevs : responsables de la maintenance du code, responsables du client réseau ETH1, mise à niveau, maintenance du code Ethereum et de l'architecture centrale ;

Section « Gestion de projet » : soutenez les développeurs Ethereum, coordonnez les hard forks, surveillez l'EIP, etc., et aidez directement AllCoreDevs dans la communication et les opérations ;

EthereumMagicians : un "forum" pour discuter de l'EIP et d'autres sujets techniques.

Chronologie des réunions liées à l'escalade de Cancún

Selon le contenu de la discussion, cette mise à niveau de Cancun peut être grossièrement divisée en cinq étapes.

La première étape - introduction du thème de mise à niveau

Introduire de nouvelles tâches proto-danksharding, EOF et opcodes "selfdestruction", discuter brièvement du contenu de la mise à niveau de Shanghai

Une fois la fusion d'Ethereum achevée le 15 22 septembre, la réunion des développeurs a été suspendue pendant 4 semaines, permettant aux développeurs de vérifier l'EIP discuté dans la mise à jour suivante pendant un mois ;

Le 28 22 octobre, la première réunion des développeurs après la fusion a proposé pour la première fois l'implémentation du proto-danksharding, de l'EOF et de l'opcode "selfdestruction". À l'heure actuelle, la portée spécifique du proto-danksharding n'a pas été déterminée, et certains développeurs pensent initialement que la mise à niveau de Shanghai peut être divisée en plusieurs petites mises à niveau, telles que l'activation des retraits ETH promis en premier, puis la mise à niveau de l'EIP4844, mais certains développeurs pensent qu'il est plus significatif de mettre en œuvre une mise à niveau plus importante en une seule étape.

Phase 2 - Détermination du calendrier et préparation de la cérémonie KZG

Fin 2022, la conférence Ethereum se concentrera principalement sur EOF et EIP4844. Dans le même temps, nous continuerons à promouvoir la cérémonie de configuration pré-crédible requise par EIP4844 - la cérémonie KZG. Les développeurs détermineront formellement dans quelle mise à niveau 4844 sera paraîtra le 23 janvier

Le 22 novembre, EOF ou proto-danksharding a été mentionné lors de la conférence téléphonique n° 149 de tous les principaux développeurs d'Ethereum. À l'heure actuelle, les développeurs envisagent toujours de le placer dans la mise à niveau de Shanghai ;

Lors de la réunion Consensus Layer du 12/02/22, Trent Van Epps, responsable de l'écosystème Ethereum, a fait le point sur l'avancement de la cérémonie de configuration de confiance requise pour la mise en œuvre d'EIP4844, qui vise à générer un morceau de code sécurisé qui sera utilisé dans EIP4844. VanEpps espère que la cérémonie sera l'une des plus importantes jamais organisées dans l'espace cryptographique, recueillant des contributions de 8 000 à 10 000. La période de contribution publique de la cérémonie durera environ 2 mois et commencera en décembre ;

Lors de la réunion des développeurs principaux le même jour, il y a eu des discussions autour d'EOF et de la désactivation de l'opcode d'autodestruction. Un certain développeur de la Fondation Ethereum s'est opposé au report d'EOF à Cancun, arguant que si les changements de code ne sont pas inclus à Shanghai, il entrera La possibilité de Cancun est très faible. Concernant le code d'autodestruction, certains développeurs préconisaient d'avancer EIP4758 à l'époque, mais désactiver directement cet opcode cassera certaines applications. Les développeurs estiment qu'avant de créer un cas limite pour protéger ce type de contrat, Cet EIP doit être pesé à nouveau pendant un certain temps ;

Lors de la réunion des développeurs principaux du 9 22 décembre, la mise en œuvre de la cérémonie KZG a été promue concernant la mise à niveau de Cancun. À l'heure actuelle, la cérémonie de mise en place crédible requise par l'EIP4844 est prête ;

Lors de la réunion Consensus Layer du 16/12/22, sur le thème de l'EIP4844, les développeurs ont discuté de la fusion de deux demandes d'extraction (PR) différentes dans la spécification pour le proto-danksharding, l'une liée à la façon dont les nœuds gèrent les données extraites de One est que lorsque des informations sur les blobs manquent sur un certain bloc, un nouveau code d'erreur sera introduit pour alerter les nœuds ;

Lors de la réunion principale des développeurs du 5 janvier 23, les développeurs sont parvenus à un consensus sur la suppression des modifications de code liées à l'implémentation d'EOF de la mise à niveau de Shanghai. À ce moment-là, Beiko a suggéré de décider si EOF devait être inclus dans l'obstacle après deux semaines. Kun est en cours de mise à jour ;

Phase 3 - Discussion préliminaire sur la portée de la proposition

À la fin du 23 janvier, EOF a été déplacé à Cancun pour être mis à niveau après avoir été retiré de Shanghai. Au cours des deux mois suivants, les discussions ont principalement porté sur d'autres propositions, à l'exception d'EOF et d'EIP4844. Dans le même temps, il a été proposé à EOF de quitter Cancun. . Cette période de temps a été principalement consacrée à délimiter la portée des propositions pour la mise à niveau de Cancún.

Lors de la réunion des développeurs principaux du 20 au 23 janvier, EOF a été déplacé à Cancun pour une mise à niveau ;

Lors de la réunion principale des développeurs du 6 23 mars, les propositions préliminaires pour la mise à niveau de Cancun étaient : EIP4788 (racine d'état de la chaîne de balises publiques), EIP2537 (effectuer efficacement des opérations telles que la vérification de la signature BLS et la vérification des SNARK), EIP-5920 (introduction de nouveaux opcode PAY), et une implémentation combinée de EIP6189 (pour rendre SELFDESTRUCT compatible avec les arbres Verkle) et EIP-6190 (modifier la fonction SELFDESTRUCT pour ne provoquer qu'un nombre limité de changements d'état) ;

Lors de la réunion des développeurs principaux du 16 et 23 mars, outre EOF et EIP4844, les propositions suivantes ont été examinées pour inclusion à Cancun : format SSZ, suppression SELFDESTRUCT, EIP2537, EVMMAX, EIP1153, instructions SWAP et DUP illimitées, introduction de PAY Beacon racine d'état dans le code et EVM ;

Lors de la réunion des développeurs principaux du 30 mars 23, la proposition EIP-6780 sur la désactivation de SELFDESTRUCT a été présentée pour la première fois, qui est également la proposition de désactiver SELFDESTRUCT que Cancun a finalement décidé d'utiliser. Mais concernant la mise en œuvre d'EOF, un développeur de l'équipe client d'Erigon (EL) a déclaré qu'EOF "a trop changé" pour être combiné avec la proposition d'amélioration d'Ethereum EIP4844 dans la prochaine mise à niveau de Cancun, qui a été proposée pour être mise à niveau à Cancun. EOF dans le hard fork peu de temps après;

#### Quatrième étape : déterminez la direction claire de la mise à niveau de la proposition et supprimez les propositions non pertinentes.

En avril 23, il y avait une direction claire pour les propositions qui devraient être couvertes par la mise à niveau de Cancun. Le nœud clé était la réunion des développeurs le 13 avril. Cette réunion a proposé 9 EIP, et Tim lui-même avait également une compréhension plus approfondie de les propositions alternatives Discussion, lors de la réunion du 27 avril, EIP6780, EIP6475 et EIP1153 ont été déterminés à être inclus à Cancun, tandis qu'EOF et EVMMAX (sous-ensembles EIP liés à la mise en œuvre d'EOF) ont été supprimés de la mise à niveau de Cancun, la mise à niveau EOF peut principalement aider Le contrôle de version EVM et plusieurs ensembles de règles de contrat peuvent être exécutés en même temps, ce qui est propice à l'expansion ultérieure d'Ethereum.Cependant, compte tenu de la faisabilité de l'ensemble de la mise à niveau, la mise à niveau EOF peut être promue avec des mises à niveau quotidiennes dans la suite. en haut

Le 12 et 23 avril, la mise à niveau d'Ethereum Shanghai a été achevée ;

En plus de la réunion de développement principale du 13.04.23 où les développeurs ont discuté de l'EIP4844 (pour exposer des données sur la racine de l'état CL dans l'EL), il y a au moins neuf autres EIP envisagés pour la mise à niveau, ce sont EIP4844, la suppression de SELFDESTRUCT ( EIP-6780, EIP4758, EIP6046, EIP6190), EIP5920, EIP1153, EIP2537, EIP4788, EVMMAXEIP (EIP6601 et EIP6690), SSZchanges (EIP6475, EIP6493, EIP 6465, EIP6404 et EIP6466), EIP 5656 et EIP6193 ;

Lors de la réunion principale des développeurs les 27 et 23 avril, plusieurs progrès et compromis ont été mis en avant. Tout d'abord, EIP4844 continue d'être identifié pour être inclus dans la mise à niveau de Cancun, tandis que les EIP suivants ont été ajoutés : EIP6780 (modifie la fonctionnalité de l'opcode SELFDESTRUCT), EIP6475 (un nouveau type de sérialisation simple (SSZ) pour représenter les valeurs facultatives), EIP1153 ( ajoute un nouveau deuxièmement, les EIP qui sont envisagés mais non officiellement inclus dans la mise à niveau sont EIP6913 (introduisant l'instruction SETCODE), EIP6493 (définissant le schéma de signature pour les transactions codées SSZ), EIP4788 (divulguant la racine de la chaîne de balises dans le bloc EL en-tête), EIP2537 (ajoute la courbe BLS12-381 en tant que précompilation) et EIP5656 (introduit de nouvelles instructions EVM pour copier des régions de mémoire); enfin, EOF et EVMMAX (sous-ensemble d'EIP lié à l'implémentation d'EOF) ont été supprimés de la mise à niveau de Cancun. La mise à niveau EOF a été supprimée de la mise à niveau de Shanghai lors de la conférence des développeurs Ethereum début janvier 2023, et elle a été par défaut pour apparaître dans la mise à niveau de Cancun de fin janvier 2023 à début avril 2023, mais le développement le 29 avril 23 EOF est à nouveau supprimé lors de la réunion des auteurs.

La cinquième étape - détermination de la proposition finale et amélioration des détails

En mai 23, les détails de la proposition finale ont été principalement simplifiés et améliorés. Le changement de SSZ-> RLP signifiera que les deux SSZEIP à Cancun ne seront plus nécessaires, donc les EIP 6475 et 6493 seront déplacés hors de Cancun pour la mise à niveau. Toujours au caucus du 26, Tim Beiko a suggéré que les futures conversations sur l'élargissement de la portée de Cancun soient limitées aux cinq EIP suivants : EIP-5920, 5656, 7069, 4788 et 2530. Les développeurs ont maintenant déterminé l'étendue complète de la mise à niveau de Cancun.

La réunion Ethereum Core Consensus du 5 mai 23 a discuté de EIP4788, qui a été mentionné la dernière fois, et a ajouté des discussions sur EIP6987 et EIP6475, qui concernent respectivement les validateurs et les transactions SSZ ;

Lors de la 161e réunion de la couche exécutive d'Ethereum le 11 mai 23, TimBeiko a déclaré que la portée de la mise à niveau de Cancun peut encore être modifiée dans les prochaines semaines, mais s'il n'y a pas de suggestion claire du développeur, la portée de la mise à niveau de Cancun sera be Gardez le statut "par défaut", et la discussion sur EIP-4844 montre que les développeurs acceptent de supprimer SSZ de l'implémentation EL de EIP-4844, mais cela n'a pas affecté l'avancement continu de 6475. En plus de cela, les développeurs ont également brièvement discuté de deux EIP à considérer à Cancún, à savoir EIP6969 (une version modifiée de EIP1559) et EIP5656 (Efficient EVM instructions for copying memory regions);

Le développement de 4844 a été brièvement discuté lors de la réunion Developer Consensus du 18.05.23, comme permettre aux applications de contrat intelligent sur EL de vérifier les preuves de l'état CL;

La désactivation de SELFDESTRUCT, les modifications de la spécification EIP-4844, la gestion des opcodes et les éventuels ajouts à Cancun ont été discutés lors de la 162e réunion Ethereum Core le 25 mai 2023. Tim Beiko a suggéré que les conversations futures sur l'élargissement de la portée de Cancun soient limitées aux cinq EIP suivants : EIP-5920, 5656, 7069, 4788 et 2530. Le développeur déterminera la gamme complète de Dencun (Deneb+Cancun) dans les prochaines semaines ;

Lors de la 110e réunion Ethereum Consensus Layer le 1er juin 2023, un chercheur de la Fondation Ethereum a présenté les résultats d'une expérience de données sur la capacité des nœuds du réseau principal Ethereum à diffuser de grandes quantités de données. spécification augmentée d'un maximum de 4 blobs à 6 par bloc. Dans le même temps, les développeurs envisagent d'intégrer EIP4788 dans la mise à niveau de Cancun ;

Lors de la réunion principale des développeurs le 13 juin 2023, les développeurs ont officiellement confirmé la portée de la mise à niveau, y compris EIP4844, EIP1153, EIP5656, EIP6780 et EIP4788 ;

Lors de la réunion de consensus du 15 juin 2023, il a été discuté des EIP centrés sur le CL à inclure dans Deneb, parmi lesquels il a été proposé d'ajouter EIP-6988, EIP-7044, EIP-7045, et l'équipe du client CL s'est mise d'accord sur la prochaine Tester l'augmentation du nombre de blobs sur le réseau de test EIP-4844 Devnet6, et prendre une décision finale à ce sujet dans les deux semaines.Dans le même temps, Michael Neuder, chercheur à la Fondation Ethereum, a proposé d'annuler le 32 ETH limite de promesses pour aider à réduire la croissance de l'ensemble de validateurs actifs ;

Lors de la réunion du 22 juin 2023, Tim a proposé de déplacer l'adresse précompilée de 4844 vers 0xA, de les emballer et de déplacer BLS vers une autre adresse, bien que cette précompilation ait été introduite via EIP2537, elle ne sera pas prise en compte dans le plan de Cancun ;

Lors de la réunion de consensus du 29 juin 2023, les développeurs ont continué à discuter du nombre de blobs, ont augmenté la limite cible de blobs de 2 à 3 et augmenté la limite maximale de blobs de 4 à 6. Dans le même temps, le 4844 testnet Devnet #7 sera bientôt lancé.

cette vie

Le contenu principal est EIP4844, Proto-Danksharding

Les plages EIP finales pour la mise à niveau de Cancun sont : EIP4844, EIP1153, EIP5656, EIP6780 et EIP4788. Dans le même temps, lors de la 111e réunion Ethereum ACDC du 19 juin, les développeurs ont continué à discuter de l'EIP6988, de l'EIP7044 et de l'EIP7045 à inclure dans Deneb. Les développeurs ont déclaré qu'ils prévoyaient de fusionner les trois EIP susmentionnés dans la spécification Deneb dans les semaines à venir.

Analyse des EIP clés

EIP4844

Introduction:

Le nom de la proposition EIP4844 est Proto-Danksharding, qui est la solution de pré-sharding pour la version complète de Danksharding.L'ensemble des schémas de sharding tourne en fait autour de Rollup pour l'expansion en chaîne. Le but de la solution est d'étendre le cumul de couche 2 - en aidant L2 à réduire les frais et à augmenter le débit, tout en ouvrant la voie à un partage complet.

Lors de la conférence téléphonique du 23 février, les développeurs d'Ethereum ont mis à jour EIP4844 et l'ont nommé Deneb, qui est le nom d'une étoile de première classe dans Cygnus, c'est-à-dire que le nom d'EIP4844 sur la version GitHub correspondante sera mis à jour en Deneb dans le Lors de la réunion du 1er mars, il y a eu quelques changements dans la prochaine spécification de mise à niveau d'Ethereum, qui s'appelle Deneb du côté CL et Cancun du côté EL ;

Lors de la réunion des développeurs du 23 juin 23, les développeurs allaient mettre à jour l'adresse précompilée de EIP4844. Actuellement, les principaux développeurs ont ajouté 9 précompiles à l'EVM et créeront deux précompiles sous les adresses "0xA" et "0xB" en activant respectivement EIP4844 et 4788. Lors de la réunion de consensus du 29 juin, Devnet # 7, un réseau de test à court terme dédié à EIP4844, a été préparé.

EIP-4844 introduit un tout nouveau type de transaction - BlobTranscation.

Présentation des blobs :

Blob, similaire à un package de données de plug-in, ne dispose au départ que d'un espace de stockage de 128 Ko. Au début de la discussion de la proposition, la cible et la limite de Blob étaient de 2/4. Lors de la réunion des développeurs du 9 juin , 23, il a été ajusté à 3/6 . Autrement dit, à l'heure actuelle, chaque transaction dans Ethereum peut transporter jusqu'à trois transactions Blob, soit 384 Ko, et la capacité targetBlob de chaque bloc est de 6, soit 768 Ko, et peut transporter un maximum de 16 transactions Blob, soit 2 Mo ;

Cela peut avoir un certain impact sur la stabilité du réseau, mais l'équipe de développement d'Ethereum a quand même décidé de le tester d'abord pour éviter d'avoir à recourir à des hard forks ultérieurs pour étendre le bloc blob.

Blob utilise KZGcommit Hash comme hachage pour la vérification des données, similaire à Merkle ;

Une fois que le nœud a synchronisé la BlobTransaction sur la chaîne, la partie Blob expirera et sera supprimée après un certain temps, et la durée de stockage est de trois semaines.

Le rôle de Blob - améliorer le TPS d'Ethereum tout en réduisant les coûts

À l'heure actuelle, le volume total de données de l'ensemble d'Ethereum n'est que d'environ 1 To, et Blob peut apporter 2,5 à 5 To de volume de données supplémentaires à Ethereum chaque année, ce qui dépasse directement le registre lui-même de plusieurs fois ;

Pour les nœuds, le téléchargement de 1 Mo à 2 Mo de données blob par bloc n'entraînera pas de charge de bande passante, et l'espace de stockage n'augmentera que la quantité fixe de données blob d'environ 200 à 400 Go par mois, ce qui n'affectera pas la décentralisation de l'ensemble Nœud Ethereum, mais l'expansion autour de Rollup est grandement améliorée ;

Et le nœud lui-même n'a pas besoin de stocker toutes les données blob, car le blob est en fait un paquet de données temporaire, donc en fait, le nœud n'a besoin de télécharger qu'une quantité fixe de données pendant trois semaines.

Le rôle d'EIP-4844 - ouverture du premier chapitre du récit Danksharding

Forte expansion : à l'heure actuelle, EIP-4844 peut initialement étendre la capacité L2. La version complète de Danksharding peut augmenter la quantité de données Blob dans EIP-4844 de 1 Mo à 2 Mo à 16 Mo à 32 Mo, ce qui garantit la décentralisation et la sécurité. Forte expansion ;

Faibles frais : selon les analystes de bernstein, le Proto-dank-sharding peut réduire les frais du réseau de couche 2 à 10 à 100 fois le niveau actuel ;

Les données réelles :

Le réseau de test Opside a déployé 4844, et l'observation actuelle peut réduire le coût de déploiement de 50 % ;

La solution technique DA d'EigenLayer ne divulgue pas trop pour évaluer ses données ;

Strictement parlant, Celestia n'a pas grand-chose à voir avec Ethereum, et son coût en DA ne peut être évalué aujourd'hui, en fonction de ses solutions techniques spécifiques ;

La solution d'Ethstorage consiste à télécharger son certificat de stockage Layer2, et son coût DA peut être réduit à 5 % de l'original ;

Topia prévoit de réduire les coûts de 100 à 1000 fois, car le réseau principal Danksharding doit également prendre en compte la sécurité et la compatibilité avec la diffusion du réseau P2P de couche 1.

Solution DA : Danksharding (une solution de sharding pour l'expansion d'Ethereum) peut actuellement avoir des problèmes avec une charge de nœud excessive (supérieure à 16 Mo) et une disponibilité insuffisante des données (période de validité de 30 jours) si elle continue à se développer. Solution:

DataAvailability Sampling - réduit la charge des nœuds

Coupez les données du Blob en fragments de données et laissez les nœuds passer du téléchargement des données du Blob à la vérification aléatoire des fragments de données du Blob, de sorte que les fragments de données du Blob soient dispersés dans chaque nœud de l'Ethereum, mais que les données complètes du Blob soient stockées dans l'ensemble du registre Ethereum In Fang, le principe est que les nœuds doivent être suffisants et décentralisés ;

DAS utilise deux technologies : le codage d'effacement (ErasureCoding) et l'engagement polynomial KZG (KZGCommitment) ;

Séparation proposant-emballeur (PBS) - résout le problème de la division du travail entre les nœuds, permettant aux nœuds avec des configurations hautes performances d'être responsables du téléchargement de toutes les données pour l'encodage et la distribution, et permettant aux nœuds avec des configurations peu performantes d'être responsables des contrôles ponctuels et vérifications.

Les nœuds avec des configurations hautes performances peuvent devenir des générateurs. Les générateurs n'ont qu'à télécharger les données blob pour encoder et créer des blocs, puis diffuser vers d'autres nœuds pour des vérifications ponctuelles. Pour les générateurs, étant donné que le volume de données de synchronisation et les exigences en bande passante sont élevés, il sera relativement centralisé ;

Un nœud avec une configuration peu performante peut devenir proposant (Proposer). Le proposant n'a qu'à vérifier la validité des données et créer et diffuser l'en-tête de bloc (BlockHeader). Cependant, pour le proposant (Proposer), la quantité de données synchrones et les besoins en bande passante sont relativement élevés. Faible, il sera donc décentralisé.

Liste anti-censure (crList) - résout le problème selon lequel les conditionneurs peuvent délibérément ignorer certaines transactions et insérer des transactions qu'ils souhaitent obtenir MEV en raison de leur pouvoir de révision excessif.

Avant que le constructeur (Builder) ne bloque les transactions, le proposant (Proposer) publiera d'abord une liste résistante à la révision (crList), qui contient toutes les transactions dans le mempool ;

Le constructeur (Builder) peut uniquement choisir de regrouper et de trier les transactions dans crList, ce qui signifie que le constructeur ne peut pas insérer sa propre transaction privée pour obtenir MEV, ni rejeter délibérément une transaction (sauf si le Gaslimit est plein) ;

Après l'emballage, le Builder diffuse la version finale de la liste de transactions Hash au Proposer, et le Proposer sélectionne l'une des listes de transactions pour générer un en-tête de bloc (BlockHeader) et le diffuser ;

Lorsque le nœud synchronisera les données, il obtiendra l'en-tête du bloc du proposant (Proposer), puis obtiendra le corps du bloc du conditionneur (Builder), pour s'assurer que le corps du bloc est la version finale sélectionnée.

PBS à double emplacement - résout le problème que les conditionneurs centralisés deviennent de plus en plus centralisés en acquérant MEV

Utilisez le mode d'enchères pour déterminer le blocage :

Le constructeur (Builder) crée l'en-tête de bloc de la liste des transactions après avoir obtenu la crList et les enchères ;

Le proposant (Proposer) sélectionne l'en-tête de bloc et le constructeur (Builder) qui a finalement enchéri avec succès, et le proposant reçoit inconditionnellement les frais d'offre gagnante (indépendamment du fait qu'un bloc valide soit généré);

Le comité de vérification (Comités) confirme l'en-tête de bloc gagnant ;

Le Constructeur divulgue le corps du bloc gagnant ;

Le comité de vérification (Comités) confirme le corps du bloc gagnant et procède à un vote de vérification (si le bloc est adopté, le bloc est produit, et si le conditionneur ne donne délibérément pas le corps du bloc, on considère que le bloc ne exister).

importance:

Tout d'abord, le constructeur (Builder) a plus de pouvoir pour empaqueter les transactions, mais la crList mentionnée ci-dessus limite d'une part la possibilité d'insérer temporairement des transactions, et d'autre part, si le constructeur (Builder) veut en tirer profit en modifiant l'ordre des transactions, il est nécessaire de payer un coût d'enchère important au début pour s'assurer qu'il pourra obtenir la qualification de tête de bloc, alors le profit MEV qu'il obtient sera encore réduit, et globalement cela aura un impact sur les moyens et la valeur réelle de l'obtention MEV ;

Cependant, au début, seul un petit nombre de personnes peuvent devenir packers (compte tenu des problèmes de performances des nœuds), tandis que la plupart des gens ne deviennent que des proposants, ce qui peut conduire à une plus grande centralisation. petit Dans certaines circonstances, certains mineurs expérimentés dotés de capacités MEV seront plus susceptibles de soumissionner avec succès, ce qui affectera davantage l'effet réel de la solution MEV ;

Cela a des implications pour certaines solutions MEV qui utilisent des enchères MEV.

importance:

EIP4844 est en fait une version super simplifiée de Danksharding : il fournit la même interface d'application que Danksharding, y compris un nouvel opcode appelé DataHash ; et un nouvel objet de données appelé BinaryLarge Objects, qui est Blob ;

le proto-danksharding est une proposition "parenthèse" (c'est-à-dire le format de transaction et les règles de vérification) pour implémenter la spécification Danksharding complète : cependant, aucun sharding n'a encore été implémenté, et tous les vérificateurs et utilisateurs doivent encore vérifier directement la disponibilité des données complètes ;

Pourquoi choisissez-vous le proto-danksharding au lieu d'EIP4488 pour réduire directement les frais de couche 2 à long terme, car seul un petit ajustement est nécessaire lors de la mise à niveau vers un fragment complet à l'avenir :

La principale différence pratique entre EIP4488 et le proto-danksharding est que l'EIP-4488 essaie de minimiser les modifications qu'Ethereum doit apporter aujourd'hui, tandis que le proto-danksharding apporte davantage de modifications à Ethereum aujourd'hui afin de passer à Ethereum à l'avenir. requis pour le partage de la version complète ;

Bien que la mise en œuvre du partitionnement complet (échantillonnage de la disponibilité des données, etc.) soit une tâche très complexe, et qu'il reste encore beaucoup de travail à faire après la mise en œuvre du proto-danksharding, ces complexités seront contrôlées sur la couche consensus. Une fois le proto-danksharding déployé, l'équipe client de la couche exécutive, les développeurs de rollup et les utilisateurs n'ont pas besoin d'effectuer de travail supplémentaire lors de la transition vers le partitionnement complet.

Pour obtenir un partitionnement complet, il est nécessaire de terminer l'implémentation réelle de PBS, de la preuve déléguée et de l'échantillonnage de la disponibilité des données, mais ces modifications seront concentrées sur la couche CL, et les développeurs n'ont pas besoin de réajuster : actuellement, 4844 implémente un nouveau type de transaction. , qui est similaire à Le format de transaction, la logique de validation croisée consensuelle et la logique de couche d'exécution requises dans le partitionnement complet sont exactement les mêmes, et une tarification du gaz indépendante auto-ajustable pour les blobs est également dérivée. à l'avenir, les certificats PBS et de délégation doivent être complétés Et la mise en œuvre réelle de l'échantillonnage de la disponibilité des données, mais ces modifications ne concernent que la couche CL et ne nécessitent pas de modifications par la couche EL ou les développeurs de cumul, ce qui est pratique pour les développeurs.

Suivi par SELFDESTRUCTremoval, EIP-6780 a finalement été déterminé comme étant la solution la plus appropriée, mais lors de la réunion des développeurs du 26, Tim a proposé d'ajouter un autre opcode SETCODE à cette proposition pour permettre aux comptes programmatiques d'être toujours mis à jour.

Suppression SELFDESTRUCT EIP-6780：X

arrière-plan:

Le 21 mars, Vitalik a proposé que SELFDESTRUCT fait plus de mal que de bien à l'écologie Ethereum. La raison principale est qu'il est le seul à pouvoir modifier un nombre infini d'objets d'état en un seul bloc, ce qui entraîne des changements de code de contrat, et peut être modifié sans le consentement du compte.Le code d'opération du solde du compte présente un grand danger caché pour la sécurité d'Ethereum ;

Le seul moyen de supprimer un contrat en chaîne est SELFDESTRUCT. Si vous appelez la fonction d'autodestruction dans le contrat, vous pouvez autodétruire le contrat. L'Ethereum stocké dans le contrat sera envoyé à l'adresse désignée. Le code restant et les variables de stockage seront supprimés de la machine d'état. En fait, l'action de destruction de contrat semble bonne en théorie, mais elle est en réalité très dangereuse. Bien que la fonction d'autodestruction puisse aider les développeurs à supprimer le contrat intelligent et à transférer le solde du contrat à l'adresse spécifiée en cas d'urgence, cette fonctionnalité est également utilisée par les criminels, ce qui en fait un moyen d'attaque.

Lors de la réunion des développeurs principaux du 13 au 23 avril, quatre propositions sur SELFDESTRUCT ont été présentées pour participer à la discussion, à savoir 6780, 4758, 6046 et 6190, et le suivi EIP6780 a été déterminé comme la proposition finale.

Introduction : l'autodestruction est le bouton d'urgence du contrat intelligent, qui détruit le contrat et transfère l'ETH restant sur le compte désigné.

EIP6780 : Désactivez SELFDESTRUCT à moins qu'ils ne soient dans la même transaction dans le contrat.

MISE À JOUR : Le 26 mai, tim a proposé qu'en plus de supprimer SELFDESTRUCT, ajouter un autre opcode - SETCODE, pour permettre aux comptes programmatiques d'être toujours mis à jour. (C'est-à-dire que la fonction de mise à jour est ajoutée et que la propriété du contrat intelligent est mise à jour au moyen d'une mise à jour/mise à niveau.) Ici, les avantages d'EIP4758 sont absorbés, ce qui permet à dapp d'avoir de la place pour la mise à niveau.

Raison : la manipulation du code SELFDESTRUCT nécessitait à l'origine des modifications importantes de l'état du compte, telles que la suppression de tous les codes et le stockage. Cela crée des difficultés pour l'utilisation des arborescences Verkle à l'avenir : chaque compte sera stocké dans de nombreuses clés de compte différentes qui ne seront pas explicitement connectées au compte racine.

MODIFICATION : cet EIP implémente une modification qui supprime SELFDESTRUCT, sauf dans les deux cas suivants

Les applications qui ne sont utilisées que pour retirer des fonds de SELFDESTRUCT fonctionneront toujours ;

Le SELFDESTRUCT utilisé dans la même transaction dans le contrat n'a pas non plus besoin d'être modifié.

Signification : Améliorer la sécurité

Auparavant, il y avait un contrat sur le réseau principal qui utilisait SELFDESTRUCT pour restreindre qui peut initier des transactions via le contrat ;

Pour empêcher les utilisateurs de continuer à déposer des fonds et à échanger dans un coffre après SELFDESTRUCT, ce coffre peut amener quiconque à voler des jetons dans le coffre lors d'une utilisation répétée.

Les trois propositions ci-dessous sont des propositions liées à SELFDESTRUCT qui ont ensuite été supprimées. 6780 a été officiellement sélectionné lors de la réunion des développeurs principaux du 28 et 23 avril, et les trois propositions restantes ont été abandonnées car l'équipe de développement d'Ethereum a finalement voulu supprimer complètement l'opcode SELFDESTRUCT, et les trois propositions suivantes sont encore modifiées par remplacement.

EIP-4758 (OBSOLÈTE) : désactivez SELFDESTRUCT en remplaçant SELFDESTRUCT par SENDALL, qui restaure tous les fonds à l'appelant (envoie tout l'éther du compte à l'appelant), mais ne supprime aucun code ni stockage.

Raison : comme ci-dessus, la manipulation précédente des codes SELFDESTRUCT nécessitait des modifications importantes de l'état du compte, telles que la suppression de tous les codes et le stockage. Cela crée des difficultés pour l'utilisation des arborescences Verkle à l'avenir : chaque compte sera stocké dans de nombreuses clés de compte différentes qui ne seront pas explicitement connectées au compte racine.

Changement:

Opcode SELFDESTRUCT renommé en SENDALL, déplace désormais uniquement tous les ETH du compte vers l'appelant, le schéma ne casse plus le code et le stockage, ou ne modifie plus les nonces ;

Tous les remboursements associés SELFDESTRUCT ont été supprimés

importance:

La fonctionnalité d'origine est conservée par rapport à EIP-6780, car certaines applications ont encore/besoin d'utiliser le code SELFDESTRUCT.

EIP-6046 (obsolète) : remplacez SELFDESTRUCT par DEACTIVATE. Modifiez SELFDESTRUCT pour ne pas supprimer la clé de stockage et utilisez une valeur spéciale dans le compte nonce pour indiquer la désactivation

Raison : Comme ci-dessus, avec les arbres Verkle, les comptes seront organisés différemment : les propriétés du compte (y compris le stockage) auront des clés distinctes, mais il sera impossible de parcourir et de trouver toutes les clés utilisées. Cependant, la manipulation des codes SELFDESTRUCT nécessitait un grand nombre de modifications de l'état du compte, ce qui rendait très difficile la poursuite de l'utilisation de SELFDESTRUCT dans les arbres Verkle.

Changement:

Modifiez les règles introduites par EIP-2681 afin que les incréments réguliers de nonce soient limités par 2^64-2 au lieu de 2^64-1 ;

SELFDESTRUCT est remplacé par :

Ne supprimez aucune clé de stockage et laissez le compte en place ;

Transférez le solde du compte vers la cible et définissez le solde du compte sur 0.

Définissez le compte nonce sur 2^64-1.

Aucun remboursement depuis EIP-3529 ;

La règle pertinente SELFDESTRUCT de EIP-2929 reste inchangée.

importance:

Cette proposition a plus de flexibilité que d'autres comportements qui suppriment directement SELFDESTRUCT.

EIP-6190 (obsolète) : modification de SELFDESTRUCT, compatible avec Verkle, afin qu'il ne provoque qu'un nombre limité de changements d'état

Raison : Comme ci-dessus, avec les arbres Verkle, les comptes seront organisés différemment : les propriétés du compte (y compris le stockage) auront des clés distinctes, mais il sera impossible de parcourir et de trouver toutes les clés utilisées. La manipulation des codes SELFDESTRUCT nécessitait auparavant des modifications importantes de l'état du compte, ce qui rendait très difficile la poursuite de l'utilisation de SELFDESTRUCT dans les arbres Verkle.

Modification : au lieu de détruire le contrat à la fin de la transaction, ce qui suit se produit à la fin de la transaction qui l'a appelé :

Le code de contrat est défini sur 0x1 et le nombre aléatoire est défini sur 2^64-1.

Le 0ème emplacement du contrat est défini sur l'adresse qui sera publiée lorsque le contrat utilisera l'opcode CREATE (keccak256(contractAddress, nonce)). Le nombre aléatoire est toujours 2^64-1.

Si le contrat s'autodétruit après que l'appel a été transmis par un ou plusieurs contrats d'alias, définissez le 0e emplacement de stockage du contrat d'alias sur l'adresse calculée à l'étape 2 ;

Le solde du contrat sera entièrement transféré à l'adresse en haut de la pile ;

Le haut de la pile est éclaté.

importance:

Conçu pour permettre à SELFDESTRUCT de former ultérieurement des arbres Verkle avec un minimum de modifications ;

Le coût du gaz a augmenté avec l'EIP-2929 appliqué.

Ensuite, il y a EIP1153, qui économise du gaz et ouvre la voie à de futures conceptions de stockage

EIP1153X

Résumé : Opcodes de stockage transitoires, ajoutez des opcodes pour manipuler l'état qui se comportent de la même manière que les magasins mais sont supprimés après chaque transaction.

raison:

L'exécution d'une transaction dans Ethereum peut générer plusieurs trames d'exécution imbriquées, chaque trame étant créée par une instruction CALL (ou similaire). Les contrats peuvent être saisis à nouveau dans la même transaction, auquel cas plusieurs cadres appartiennent à un contrat.

Actuellement, ces frameworks peuvent communiquer de deux manières : entrée/sortie via des instructions CALL et via des mises à jour de magasin. La communication via E/S n'est pas sûre s'il existe un framework intermédiaire appartenant à un autre contrat non sécurisé.

En prenant le verrou de réentrance comme exemple, il ne peut pas s'appuyer sur des trames intermédiaires pour transmettre l'état du verrou : la communication SSTORE SLOAD via le stockage est coûteuse, et le stockage transitoire est une solution dédiée et économe en gaz au problème de communication inter-trames.

Changé : Deux nouveaux opcodes ont été ajoutés à l'EVM, TLOAD (0xb3) et TSTORE (0xb4).

Le stockage transitoire est privé pour le contrat qui le possède, et comme le stockage persistant, seul le framework de contrat propriétaire peut accéder à son stockage éphémère. Lors de l'accès au stockage, toutes les trames accèdent au même stockage éphémère de la même manière que le stockage persistant, mais différemment de la mémoire.

Cas d'utilisation potentiels :

verrou de réentrée ;

Adresses CREATE2 calculables sur la chaîne : les paramètres du constructeur sont lus à partir du contrat d'usine, plutôt que d'être transmis dans le cadre du hachage du code d'initialisation ;

Approbation EIP-20 pour une seule transaction, par exemple #temporaryApprove(addressspender, uint256 amount);

Contrat de frais de transfert : payez des frais au contrat de jeton pour débloquer les transferts lors des transactions ;

Mode "Till" : permet à l'utilisateur d'effectuer toutes les opérations dans le cadre du rappel, et vérifie si "till" est équilibré à la fin ;

Métadonnées d'appel de proxy : transmettez des métadonnées supplémentaires à l'implémentation de contrats sans utiliser de données d'appel, telles que les valeurs des paramètres de constructeur de proxy immuables.

importance:

Économisez du gaz et ayez des règles de facturation de gaz plus simples ;

Résoudre le problème de la communication inter-frame ;

ne change pas la sémantique des opérations existantes ;

Pas besoin de vider l'emplacement de stockage après utilisation ;

Les futures conceptions de stockage (telles que les arbres de Verkle) n'ont pas besoin de prendre en compte le problème des rétrofacturations pour le stockage instantané.

Ensuite, il y a 4788, ce qui peut réduire l'hypothèse de confiance du pool de gage

EIP4788：X

Brief : Racines du bloc balise dans l'EVM.

Mise à jour : lors de la réunion des développeurs du 15.06.23, les développeurs ont proposé d'apporter des modifications au code pour améliorer l'expérience du jalonneur, cet EIP divulguera la racine du bloc de chaîne de balises, qui contient les informations sur l'état de la chaîne interne EVM, pour la confiance des développeurs DApp. accès minimisé.

Modifié : soumettez les racines de hachage de chaque bloc de chaîne de balises dans l'en-tête de charge utile d'exécution correspondant, stockez ces racines dans un contrat en état d'exécution et ajoutez un nouvel opcode pour lire ce contrat.

Signification : Il s'agit d'une proposition de modification de code, qui propose de modifier la machine virtuelle Ethereum (EVM) afin qu'elle puisse divulguer les données de la racine d'état de la couche de contrat (CL) dans la couche d'exécution (EL), qui peut faire différents protocoles et applications dans le réseau Ethereum La communication entre les programmes est plus efficace et sécurisée. Autoriser des conceptions plus fiables pour les pools de jalonnement, les ponts et les protocoles de reprise.

Enfin, il y a le 5656, qui fournit un nouvel opcode de copie de mémoire efficace, mais est actuellement dans un état d'être temporairement inclus dans une mise à niveau en raison de sa bande passante de test

EIP5656X

Introduction : MCOPY - instruction de copie de mémoire.

MISE À JOUR: Le 09.06.23, l'équipe de développement a déclaré qu'elle était initialement divisée sur MCOPY car bien qu'elle résolve le problème de sécurité, elle était préoccupée par la bande passante de mise en œuvre + test nécessaire pour l'ajouter à la mise à niveau, mais a finalement accepté d'inclure l'EIP , Toutefois, si le développeur rencontre des problèmes de capacité lors des tests ou côté client, sa suppression sera envisagée. En tant que tel, MCOPY est en passe d'être temporairement inclus dans la mise à niveau de Cancun.

Modifié : Fournit une instruction EVM efficace pour copier les régions de mémoire.

Importance : la copie de la mémoire est une opération fondamentale, mais son implémentation sur l'EVM a un coût.

Avec la disponibilité de l'instruction MCOPY, les mots de code et les phrases peuvent être copiés avec plus de précision, ce qui augmentera les performances de copie de la mémoire d'environ 10,5 %, ce qui est très utile pour diverses opérations intensives en calcul ;

Il serait également utile pour les compilateurs de générer un bytecode plus efficace et plus petit ;

Cela peut permettre d'économiser une certaine quantité de gaz pour la précompilation d'identité, mais cela ne peut pas réellement favoriser la réalisation de cette partie.

Liste des candidats EIP

Le 15 juin 23, la réunion de consensus des développeurs a discuté des EIP centrés sur le CL à inclure dans Deneb, parmi lesquels il a été proposé d'ajouter EIP6988, EIP7044 et EIP7045.

EIP6988：X

Résumé : Empêche les validateurs barrés d'être élus comme proposants de bloc.

Signification : des pénalités accrues pour les nœuds enfreints profiteront à la TVP.

EIP7044：X

Résumé : S'assurer que les sorties de validateur signées sont valides en permanence.

Importance : cela peut améliorer l'expérience du jalonneur dans une certaine mesure.

EIP7045：X

Résumé : Étendez la plage d'inclusion de l'emplacement d'attestation d'une fenêtre glissante d'une époque à deux époques.

Signification : Améliorer la sécurité du réseau.

Supprimer l'analyse de l'EIP

Lors de la 160e réunion Ethereum ACDE les 29 et 23 avril, EVMMAX et EOF ont été confirmés comme étant supprimés de cette mise à niveau, et des modifications liées à EOF peuvent être introduites dans les mises à niveau quotidiennes ultérieures.

EVMMAXEIP :

Résumé : EVMMAX vise à apporter une plus grande flexibilité aux opérations arithmétiques et aux schémas de signature sur Ethereum. Actuellement, il existe deux propositions EVMMAX, une avec EOF et une sans EOF.

EIP6601 : Extensions arithmétiques modulaires EVM (EVMMAX)

Changement : C'est une itération de EIP5843, la différence avec EIP5843 est :

6601 introduit un nouveau type de section EOF qui stocke le module, le paramètre Montgomery précalculé, le nombre de valeurs qui seront utilisées (le module configurable à l'exécution est toujours pris en charge) ;

6601 utilise un espace mémoire séparé pour les valeurs EVMMAX, avec de nouveaux opcodes de chargement/stockage pour déplacer les valeurs entre la mémoire EVM<->EVMMAX ;

Le 6601 prend en charge les opérations sur des modules jusqu'à 4096 bits (limite provisoire mentionnée dans EIP).

Importance : EIP-5843 introduit une addition, une soustraction et une multiplication modulaires efficaces pour la machine virtuelle Ethereum, et EIP-6601 s'appuie sur cela en introduisant une section de configuration, un espace mémoire séparé et de nouveaux opcodes pour les opérations arithmétiques modulaires. Fournit une meilleure organisation et flexibilité. tout en prenant en charge des modules plus grands et en améliorant les performances EVM.

En tant que contrat EVM, permettant des opérations arithmétiques sur les courbes elliptiques sur diverses courbes, y compris BLS12-381 ;

MULMOD réduit de 90 à 95 % le coût du gaz d'exploitation sur des valeurs allant jusqu'à 256 bits par rapport aux opcodes ADDMOD existants ;

Permet à la précompilation modexp d'être implémentée en tant que contrats EVM ;

Réduisez considérablement le coût de la vérification ZKP dans les fonctions de hachage algébriques (telles que MiMC/Poséidon) et EVM.

EIP6690：

Modification : EIP-6990 est une proposition adaptée de EIP-6601 pour introduire des opérations arithmétiques modulaires optimisées dans l'EVM sans s'appuyer sur EOF. Alors que EIP-6601 nécessite EIP-4750 et EIP-3670 comme dépendances, EIP-6990 fournit une solution plus autonome. Il fournit une approche plus simplifiée en supprimant la dépendance à EOF.

Importance : Il conserve la fonctionnalité de base de EIP-6601 pour effectuer des opérations arithmétiques modulaires optimisées sur des modules impairs jusqu'à 4096 bits, cette simplification permet une mise en œuvre et une adoption plus efficaces tout en offrant les avantages associés à EIP-6601.

Modifications EOF：

Introduction : EOF est une mise à niveau d'EVM, qui introduit de nouvelles normes contractuelles et de nouveaux opcodes. Le bytecode EVM traditionnel (bytecode) est une séquence non structurée d'instructions bytecode. EOF introduit le concept de conteneur, qui implémente un bytecode structuré. Le conteneur se compose d'un en-tête et de plusieurs sections pour structurer le bytecode. Après la mise à niveau, l'EVM pourra effectuer un contrôle de version et exécuter plusieurs ensembles de règles de contrat en même temps.

EIP663：

Brève : instructions SWAP et DUP illimitées

Signification : En introduisant deux nouvelles instructions : SWAPN et DUPN, qui diffèrent de SWAP et DUP en augmentant la profondeur de pile de 16 éléments à 256 éléments

EIP3540：

Introduction:

Dans le passé, le bytecode EVM déployé sur la chaîne n'avait pas de structure prédéfinie, et le code n'était vérifié qu'avant d'être exécuté dans le client.Ceci n'est pas seulement un coût indirect, mais empêche également les développeurs d'introduire de nouvelles fonctions. Ou déprécier les anciennes fonctionnalités.

Cet EIP introduit un conteneur qui peut être étendu et contrôlé en version pour l'EVM, et déclare le format du contrat EOF. Sur cette base, le code peut être vérifié lorsque le contrat EOF est déployé, c'est-à-dire la validation au moment de la création, ce qui signifie que cela peut empêcher le déploiement de contrats déraisonnables conformes au format EOF.Ce changement implémente le contrôle de version EOF, ce qui aidera à désactiver les instructions EVM existantes ou à introduire des fonctions à grande échelle (telles que l'abstraction de compte) à l'avenir.

importance:

Le contrôle de version est propice à l'introduction ou à l'abandon de nouvelles fonctions à l'avenir (comme l'introduction de l'abstraction de compte) ;

La séparation du code de contrat et des données est bénéfique pour la vérification L2 (op), réduisant le coût du gaz des validateurs L2. Dans le même temps, la séparation du code de contrat et des données est également plus pratique pour les outils d'analyse de données sur la chaîne.

EIP3670：

Introduction : Basé sur EIP-3540, le but est de s'assurer que le code du contrat EOF est conforme au format et est valide. Pour les contrats qui ne sont pas conformes au format, son déploiement sera empêché et Legacybytecode ne sera pas affecté.

Signification : basé sur le conteneur introduit par 3540, EIP-3670 garantit que le code du contrat EOF est valide ou empêche son déploiement. Cela signifie que les opcodes non définis ne peuvent pas être déployés dans les contrats EOF, ce qui présente l'avantage supplémentaire de réduire le nombre de versions EOF à ajouter.

EIP4200：

Introduction:

Les premiers opcodes spécifiques à EOF sont introduits : RJUMP, RJUMPI et RJUMPV, qui encodent les destinations sous forme de valeurs immédiates signées. Les compilateurs peuvent utiliser ces nouveaux opcodes JUMP pour optimiser le coût en gaz du déploiement et de l'exécution de JUMP, car ils éliminent le temps d'exécution requis pour effectuer une analyse de saut pour les opcodes JUMP et JUMPI existants. Cet EIP est un complément à dynamicjump.

Par rapport à l'opération JUMP traditionnelle, la différence est que les opérations telles que RJUMP ne spécifient pas une position de décalage spécifique, mais spécifient une position de décalage relative (de sauts dynamiques -> sauts statiques), car les sauts statiques sont souvent suffisants.

Signification : optimiser le réseau et réduire les coûts.

EIP4750：

Poussez la fonction de 4200 un peu plus loin : en introduisant deux nouveaux opcodes de CALLF et RETF, une solution alternative est réalisée pour la situation qui ne peut pas être remplacée par RJUMP, RJUMPI et RJUMPV, de sorte que JUMPDEST n'est plus nécessaire dans le contrat EOF, c'est-à-dire que le saut dynamique est désactivé.

Signification : optimisez le code en divisant le code en plusieurs parties.

EIP5450：

Contexte : Le contexte est toujours que le contrat Ethereum n'est pas vérifié lorsqu'il est déployé, et seule une série de vérifications est effectuée lorsqu'il est en cours d'exécution, si la pile déborde (la limite supérieure est de 1024), si le gaz est suffisant et bientôt.

Contenu : Ajout d'un autre contrôle de validité pour les contrats EOF, cette fois autour de la pile. Cet EIP évite les situations où les déploiements de contrats EOF pourraient entraîner des sous-débordements/débordements de pile. De cette façon, les clients peuvent réduire le nombre de contrôles de validité qu'ils effectuent lors de l'exécution des contrats EOF.

Signification : une amélioration majeure consiste à réduire autant que possible ces vérifications qui se produisent pendant l'exécution, et davantage de vérifications se produisent lorsque le contrat est déployé.

Après la mise à jour de la réunion des développeurs du 26 mai, le changement de type de transaction de SSZ à RLP lié à EIP4844 signifiait que les deux SSZEIP à Cancun n'étaient plus nécessaires, donc les EIP6475 et 6493 ont été déplacés hors de Cancun pour mettre à niveau

EIP6475X

Introduction : Proposition complémentaire à EIP4844. Le proto-danksharding introduit un nouveau type de transaction qui utilise le codage SSZ au lieu du codage RLP utilisé par d'autres types de transaction.

MISE À JOUR : Lors de la 161e réunion des développeurs Ethereum Execution Layer Core, les discussions sur le format de sérialisation SSZ pour EIP4844 ont révélé qu'au départ, les développeurs avaient tendance à introduire les premières itérations du format SSZ dans EL via des transactions blob, et finalement les développeurs prévoient d'apporter tout le type de transaction a été mis à niveau de RLP vers SSZ, mais les développeurs ont envisagé de supprimer SSZ d'EIP-4844 compte tenu de son chemin peu clair et de ne pas pouvoir l'implémenter lors de la mise à niveau de Cancun. Après de nombreuses discussions, les développeurs ont convenu de supprimer SSZ de l'implémentation EL d'EIP-4844, mais ils n'ont pas encore supprimé EIP6475. Après la mise à jour du 26 mai, le changement SSZ->RLP signifiera que les deux SSZEIP à Cancun ne seront plus nécessaires : ainsi, les EIP 6475 et 6493 seront déplacés hors de Cancun pour les mises à niveau.

EIP6493X

Introduction : schéma de signature de transaction SSZ. Cet EIP définit un schéma de signature pour les transactions codées en sérialisation simple (SSZ) et explique comment les nœuds doivent gérer les types de transactions blob qui sont formatés au format SSZ sur CL mais codés différemment sur EL. Cet EIP fait partie d'une mise à jour du format de sérialisation Ethereum pour la cohérence entre les couches ;

Contexte : changements SSZ

Introduction : SimpleSerialiZe est la méthode de sérialisation utilisée sur la chaîne beacon.

SSZchanges comprend également trois autres propositions de soutien, cette fois seulement 6465 a été introduit.

EIP6465 : racine de retrait SSZ, qui définit le processus de migration des engagements Merkle-PatriciaTrie (MPT) existants vers les retraits de sérialisation simple (SSZ) ;

EIP6404/ EIP6466：

Les deux définissent un processus de migration des engagements Merkle-PatriciaTrie (MPT) existants vers la sérialisation simple (SSZ).

EIP-6404— Racine de transaction SSZ

EIP-6466— Base de réception SSZ

Tim Beiko a suggéré lors de la réunion principale des développeurs du 26 mai que les conversations futures sur l'élargissement de la portée de Cancun soient limitées aux cinq EIP suivants : EIP5920, 5656, 7069, 4788 et 2537, et que des propositions ultérieures soient générées dans cette portée. EIP5656 et EIP4788 ultérieurs ont été confirmés en tant que propositions de mise à niveau formelles, et 5920, 7069 et 2537 ont été supprimés. Parmi eux, EIP5920 était dû aux préoccupations des développeurs concernant les effets secondaires potentiels de la manière de transférer l'ETH, ainsi qu'un raisonnement inachevé, des tests, et travail de sécurité. Retiré de la mise à niveau.

EIP5920：X

Introduction : opcode de paiement. Introduit le nouvel opcode PAY pour les transferts Ethereum, qui envoie Ether à une adresse sans appeler aucune de ses fonctions.

Raison : Actuellement, l'envoi d'ether à une adresse nécessite que l'utilisateur appelle une fonction sur cette adresse, ce qui pose plusieurs problèmes :

Tout d'abord, cela ouvre un vecteur d'attaques par réentrance, puisque le récepteur peut rappeler l'expéditeur ;

Deuxièmement, il ouvre un vecteur DoS, de sorte que la fonction parent doit être consciente que le récepteur peut manquer de gaz ou de rappel ;

Enfin, l'opcode CALL est inutilement coûteux pour les transferts d'éther simples, car il nécessite d'étendre la mémoire et la pile, de charger les données complètes du récepteur, y compris le code et la mémoire, et doit finalement effectuer un appel, éventuellement en effectuant d'autres opérations involontaires.

Changement:

Un nouvel opcode a été introduit : (PAY)PAY_OPCODE, où :

Pop deux valeurs de la pile : addrthenval.

Transférer wei de l'adresse d'exécution val à l'adresse addr. Si addr est l'adresse zéro, valwei sera programmé à partir de l'adresse d'exécution.

Pièges potentiels : Les contrats existants seront utilisés indépendamment du solde réel de leur portefeuille, puisqu'il est déjà possible d'envoyer de l'ether à une adresse sans l'appeler.

Signification : économiser du gaz.

MISE À JOUR: Le 09.06.23, PAY a été supprimé de la mise à niveau en raison de préoccupations concernant les effets secondaires potentiels qui pourraient exister dans la manière dont l'ETH est transféré, et le travail de raisonnement, de test et de sécurité requis pour réussir la proposition.

EIP7069X

Introduction : Instruction CALL modifiée

Modification : introduction de trois nouvelles instructions d'appel, CALL2, DELEGATECALL2 et STATICCALL2, qui ont pour effet de simplifier la sémantique. Vise à supprimer l'observabilité du gaz de la nouvelle directive et à ouvrir la porte à une nouvelle classe de contrats qui ne sont pas affectés par la retarification.

arrière-plan:

Règle 63/64e : limitez la profondeur de l'appel et assurez-vous que l'appelant a encore de l'essence pour effectuer des changements d'état après le retour de l'appelé ;

Avant l'introduction des règles 63/64, le gaz disponible pour l'appelant devait être calculé avec une certaine précision. La solidité a une règle complexe qui essaie d'estimer le coût pour l'appelant de l'exécution de l'appel lui-même afin de définir une valeur de gaz raisonnable.

La règle 63/64e est actuellement introduite :

Suppression de l'inspection de la profondeur des appels ;

Assurez-vous de réserver au moins 5000 gaz avant d'exécuter le comportement appelé ;

Assurez-vous qu'au moins 2300 gaz sont disponibles pour le comportement appelé.

Règles de subvention : comme la fameuse subvention 2300, lorsqu'un contrat appelle un autre contrat, le contrat appelé obtiendra 2300gas pour effectuer des opérations très limitées (assez pour faire un peu de calcul et générer un journal, mais pas assez pour remplir un emplacement de stockage ), puisqu'il fixe une quantité fixe de gaz, tant que le prix du gaz peut être ajusté, les gens n'ont aucun moyen de déterminer quel type de calcul ce gaz peut prendre en charge.

Importance : Ouvrir la voie à l'introduction future d'EOF et faciliter la gestion de gros contrats.

Supprimer l'option de gaz : la nouvelle commande ne permet pas de spécifier la limite de gaz, mais s'appuie sur la "règle 63/64e" (se référant principalement à la retarification du gaz utilisée pour un grand nombre d'opérations IO dans EIP-150, ce qui augmente le consommation de gaz d'opérations spécifiques) à Limiter le gaz, cette amélioration importante est de simplifier les règles autour de la "subvention", peu importe si la valeur est envoyée ou non, l'appelant n'a pas besoin d'effectuer des calculs sur le gaz ;

Avec l'introduction de la nouvelle proposition, les utilisateurs peuvent toujours surmonter l'erreur Outof Gas en envoyant plus de gaz dans la transaction (sous réserve de la limite de gaz du bloc, bien sûr).

Certains contrats qui n'envoyaient qu'une quantité limitée de gaz à leurs appels ont été rompus par le nouveau mécanisme de tarification lors de l'augmentation précédente des coûts de stockage (par exemple, EIP-1884 a augmenté le gaz pour certains opcodes). Auparavant, certains contrats avaient un plafond d'essence qui limitait en permanence la quantité d'essence qu'ils pouvaient dépenser, même s'ils l'envoyaient dans leurs sous-appels, cela ne fonctionnerait pas, quelle que soit la quantité d'essence supplémentaire qu'ils envoyaient, car l'appel limiterait le montant envoyé.

Ouvrir la voie à l'introduction de l'EOF : une fois le format d'objet EVM (EOF) introduit, les anciennes instructions d'appel peuvent être rejetées dans le contrat EOF, garantissant ainsi qu'elles sont largement immunisées contre les changements de prix du gaz. Étant donné que ces opérations sont nécessaires pour supprimer l'observabilité du gaz, EOF les exigera à la place des instructions existantes ;

Plus de codes de retour d'état de commodité : Des fonctions de commodité ont été introduites qui renvoient des codes d'état plus détaillés : succès (0), retour (1), échec (2) et sont extensibles à l'avenir.

EIP2537：X

Brief : Une précompilation de la manipulation de courbe BLS12-381.

MODIFIÉ : Ajout d'opérations sur la courbe BLS12-381 en tant que précompilations à l'ensemble nécessaire pour effectuer efficacement des opérations telles que la vérification de la signature BLS et la vérification des SNARK.

Importance : Ethereum peut créer des preuves cryptographiques plus sécurisées et permettre une meilleure interopérabilité avec la chaîne de balises.

PR3175 a été mentionné, mais jamais présélectionné, pas d'autre discussion

PR3175：X

Résumé : Cette proposition empêcherait les validateurs pénalisés de proposer des blocs lorsqu'ils sont retirés de la file d'attente. Si plus de 50 % des validateurs sont pénalisés pour un comportement malveillant, ces validateurs pourront toujours proposer des blocages tout en étant retirés de force du réseau. Changer cette logique est un changement de couche CL relativement mineur qui offre une protection contre les "modes de défaillance élevés", selon les développeurs.

Selon la 108e réunion de consensus des développeurs Ethereum Core du 4 mai, PR3175 est en train d'être formaté en EIP et sera changé en EIP-6987, c'est-à-dire, pour des raisons de sécurité, pour empêcher la sélection de nœuds de vérification barrés est le proposant de bloc.

avenir

Sur la base des informations ci-dessus, nous sommes parvenus aux conclusions suivantes :

1. Les principaux objectifs de la mise à niveau de Cancún sont, par ordre de priorité, l'expansion, la sécurité, les économies de gaz et l'interopérabilité :

Il ne fait aucun doute que l'expansion est la première priorité (4844);

La sécurité et l'économie de gaz sont la deuxième priorité (6780, 1153, 5656 et 7045), tout en tenant compte d'une certaine expérience du développeur ;

Le troisième est l'interopérabilité, comme l'optimisation de la connexion, de la communication et de l'interopérabilité entre les dapps (4788, 7044 et 6988) ;

Données attendues : Testnet 4844 peut réduire le coût d'opsiderollup de 50 % ; les solutions techniques d'EigenLayer et de Celestia n'ont pas trop divulgué, et leurs données ne peuvent pas être évaluées ; Ethstorage estime que le coût de DA chutera à 5 % de l'original On s'attend à ce que Topia réduise le coût de 100 à 1000 fois.

2. Les 2 à 5 prochaines années, lorsque Cancun sera mis à niveau vers Danksharding, sont la période de développement en or pour les projets de couche DA

La limite supérieure de sécurité de la couche 2 dépend de la couche DA qu'elle adopte.Proto-Danksharding profitera aux protocoles de stockage, aux protocoles modulaires et aux réseaux d'extension de stockage L1 grâce à un stockage de données d'état moins cher.

Tout d'abord, Danksharding revient à l'essence de la machine à états Ethereum. V God a mentionné que le but du protocole de consensus Ethereum n'est pas de garantir le stockage permanent de toutes les données historiques. Au lieu de cela, l'intention est de fournir un tableau d'affichage en temps réel hautement sécurisé et de laisser de la place à d'autres protocoles décentralisés pour un stockage à plus long terme (le but du protocole de consensus Ethereum n'est pas de garantir le stockage de toutes les données historiques pour toujours. Au contraire, le but est de fournir un tableau d'affichage en temps réel hautement sécurisé et de laisser de la place à d'autres protocoles décentralisés pour effectuer un stockage à plus long terme. );

Deuxièmement, le Danksharding réduit le coût de la DA, mais les problèmes de temps d'atterrissage et de disponibilité des données doivent également être résolus.

Réduction des coûts DA : avant cette mise à jour, il était nécessaire d'appeler calldata pour libérer les données du cumul vers la chaîne principale Ethereum, et les frais de gaz pour appeler ce code étaient très chers, ce qui représentait la dépense la plus importante de la couche 2. EIP4844 introduit des blobs de données comme cumuls L'espace de données supplémentaire unique réduira considérablement les coûts de stockage, réduisant ainsi les coûts de DA.

Le temps d'atterrissage réel est long, et le TPS qui peut être amélioré et le gaz qui peut être réduit sont encore limités, c'est donc bon pour la poursuite du développement des projets de couche DA à l'avenir :

Dans l'article de polynya sur le partage de données iablesecurity sur le danksharding, il montre qu'il faudra 2 à 5 ans pour le mettre en œuvre ;

Même s'il atterrit, le TPS qu'il peut augmenter et le niveau de gaz qu'il peut réduire sont toujours limités :

EIP4844 prend actuellement en charge 6 blobs, et le futur problème d'expansion ne peut être résolu que par Danksharding ;

L'espace de bloc Ethereum actuel est d'environ 200 Ko. Après Danksharding, la taille prévue dans la spécification est de 32 mégaoctets, ce qui représente une amélioration d'environ 100 fois. À l'heure actuelle, le TPS d'Ethereum est d'environ 15, et dans un état idéalisé, il sera d'environ 1500 après avoir été augmenté de 100 fois, ce qui n'est pas une grande amélioration en ampleur.

Par conséquent, un long temps de mise en œuvre + des changements réels limités profiteront aux projets de couche DA.Certains projets DA tels que Celestia et Eigenda peuvent encore rivaliser avec Danksharding grâce à des coûts moins élevés et à des TPS plus rapides.De nouveaux projets DA tels que ETHstoragetopia peuvent également combler le vide du marché précédent.

Les problèmes techniques tels que les problèmes de stockage et de disponibilité des données doivent également être résolus :

Il y a deux coûts principaux de DA, l'un est le coût de la bande passante du réseau, l'autre est le coût du stockage, et 4844 lui-même ne résout pas le problème de stockage et le problème de bande passante de la chaîne de blocs

Le blob sera stocké sur la couche de consensus Ethereum pendant environ 3 semaines, puis supprimé.Si vous souhaitez stocker des enregistrements historiques complets et rendre toutes les données disponibles, les solutions actuelles incluent : dapp lui-même stocke les données liées à lui-même et au réseau du portail Ethereum (actuellement en cours de développement) en cours de développement) ou des protocoles tiers tels que les explorateurs de blocs, les données historiques dans BitTorrent ou le stockage spontané par des utilisateurs individuels.

Par conséquent, le Proto-Danksharding bénéficiera aux protocoles de stockage, aux protocoles modulaires et aux réseaux d'extension de stockage L1 :

La demande d'appel de données historiques conduira à une nouvelle voie de développement pour les protocoles de stockage décentralisés ou les protocoles d'index tiers ;

Les accords modulaires ultérieurs peuvent exécuter des transactions via Rollup à grande vitesse, la couche de règlement sécurisée est responsable du règlement et la couche de disponibilité des données à faible coût et à grande capacité est responsable de la garantie ;

C'est bon pour le réseau d'extension de stockage L1, tel qu'Ethstorage, qui peut fournir une solution de deuxième niveau pour le stockage programmable à un coût de stockage inférieur.

3. La mise à niveau de Cancun est bonne pour la diversité L2, L3, RAAS et la disponibilité des données et d'autres pistes

Analyse de la piste L2 :

Top Layer 2, cinq projets tels que ArbitrumOrbit, OPStack, Polygon2.0, FractalScaling (sous StarkWare) et HyperChain (sous zkSync) en bénéficieront. La réduction des frais de stockage apportée par blob améliorera considérablement une série de problèmes de coût et d'évolutivité qui limitaient le développement de la couche 2 auparavant, et améliorera considérablement le débit de données. Après avoir résolu le problème de coût, la couche principale 2 aura la possibilité de continuer à déployer des fonctions spécifiques , Écologie L3 simultanée multi-chaîne personnalisée de haut niveau ;

L'écart des coûts d'exploitation entre la couche 2 de deuxième niveau et la couche 2 principale sera réduit, ce qui donnera à certains petits projets plus d'opportunités de développement, comme Aztec, Metis, Boba, ZKspace, layer2.finance, etc. ;

Bien que les besoins réels des projets de blockchain modulaire restent à vérifier, divers langages de programmation sont encore possibles, tels que les langages de la série Cario, Move de Starkware, les langages de la série C, c++, C# et Go pris en charge par Wasm, qui peuvent introduire plus de nombreux langages web2 développeurs.

Analyse de la piste Raas :

L'avantage de Raas lui-même réside dans son haut degré de personnalisation, ses exigences personnalisées> son coût et son efficacité purs, de sorte que la réduction des coûts est un gros avantage du Rollup personnalisé.

Mais le problème avec la piste RAAS est qu'il peut s'agir d'OverHype, et il y a même des doutes sur la piste RAAS elle-même. Face à la concurrence des 5 top layer2 et à l'émergence de divers nouveaux DA, il faut se poser la question de savoir si les nouveaux projets peuvent former une piste.

Tout d'abord, l'avantage du déploiement de la chaîne applicative de la couche de tête2 réside dans l'intégrité du cadre réseau et la sécurité de l'écologie inter-chaînes, et l'avantage du RAAS réside dans sa personnalisation et sa liberté ;

Cependant, les barrières techniques RAAS des séries OP et ZK ne sont pas fortes à l'heure actuelle, et elles sont encore au stade de testnet à court terme, et il n'y a pas d'interaction réelle entre les produits. les avantages écologiques de la couche 3 à l'avenir, la demande réelle de RAAS est douteuse.

Série OP : bien que la mise à niveau +4844 de la pile OP ait apporté quelques petites améliorations en termes de coût et d'efficacité, l'attrait des améliorations n'est pas fort ;

Série ZK : à l'heure actuelle, de nombreux projets de premier plan suivent la voie ZKEVM et accordent plus d'attention à la compatibilité avec Ethereum, de sorte que la conception du circuit sacrifiera une certaine efficacité, et elle n'est pas aussi ciblée que la série OP. Cependant, la plupart des ZKRAAS actuellement sur le marché utilisent encore des projets phares (tels que ZkSync) pour bifurquer la chaîne, et les barrières ne sont toujours pas fortes.

Par conséquent, à court terme, OPRAAS a encore une certaine marge de développement avant l'arrivée de la couche 3. À long terme, ZKRAAS et la couche 3 pourraient être la tendance future.

ZKRAAS a un désavantage de coût plus important après 4844, et il consomme beaucoup plus de puissance de calcul que OP.Bien que le coût de téléchargement vers L1 soit inférieur à celui de OP, ce n'est qu'une goutte d'eau par rapport au coût du processus de preuve, tandis que OP L'avantage est qu'il peut rapidement construire une écologie en peu de temps, et il y a encore de la place pour le développement avant que la couche 3 n'atterrisse;

Pour les applications DeFi classiques et les marchés NFT, la transformation du rollup n'est pas une exigence rigide.Seules les applications de paiement ou les jeux qui nécessitent une efficacité élevée ont une demande plus forte de rollup. À l'avenir, les projets defi peuvent être sur l2, les projets sociaux peuvent être sur l3 ou hors chaîne, et enfin les données et les relations de base sont placées sur l2. les jeux de la chaîne sont essentiellement des fonds, et l'incapacité des jetons à circuler en externe ont apporté des goulots d'étranglement au développement, couplés à l'émergence de jeux sur l'ensemble de la chaîne, l'attrait écologique de l3 lui-même est bien supérieur à celui du rollup.

4. La mise à niveau de Cancun améliore l'expérience des développeurs et des utilisateurs

La deuxième proposition importante de la mise à jour de Cancun, SELFDESTRUCTremoval, améliorera encore la sécurité d'Ethereum. En même temps, pour le problème procédural de mise à jour du compte qui peut exister après la suppression, un nouveau code d'opération SETCODE est préparé pour améliorer cette situation ;

La troisième proposition EIP1153 mise à niveau par Cancun ajoute des codes d'opération de stockage transitoires, qui peuvent d'une part économiser du gaz, d'autre part résoudre le problème de la communication inter-trame, et enfin ouvrir la voie à une future conception de stockage, comme l'arbre Verkle n'aura pas besoin d'envisager le remboursement de la question du stockage transitoire ;

EIP5656, la quatrième proposition de la mise à niveau de Cancun, introduit l'instruction de copie de mémoire MCOPY, qui peut copier plus précisément des mots et des phrases de code, ce qui améliorera les performances de copie de mémoire d'environ 10 % ;

La cinquième proposition de la mise à niveau de Cancun est EIP4788, qui peut rendre la communication entre différents protocoles et applications du réseau Ethereum plus efficace et sécurisée, et également permettre des conceptions plus fiables pour les pools de jalonnement, les protocoles de pontage et de reprise ;

La dernière mise à jour de Cancun (15 juin 23) propose d'ajouter des mises à niveau EIP centrées sur le CL : EIP6988, EIP7044 et EIP7045, qui améliorent la sécurité et la convivialité d'Ethereum dans les détails, comme l'amélioration de l'expérience du donneur d'ordre et la sécurité du réseau, etc.

Parmi les propositions supprimées, la transition SSZ->RLP a entraîné la suppression de deux SSZEIP (EIP6475 et EIP6493) de la mise à niveau de Cancun ; les propositions liées à EOF ont de nouveau été supprimées de la mise à niveau de Cancun après avoir été supprimées de la mise à niveau de Shanghai, et sont actuellement considérées possible Il sera directement mis en œuvre dans les mises à jour quotidiennes ultérieures ; EVMMAX est également retiré de Cancun pour les mises à niveau avec EOF car il s'agit d'un sous-ensemble d'EIP lié à la mise en œuvre d'EOF ; compte tenu des effets secondaires potentiels qui peuvent exister dans le transfert d'ETH, et la nécessité de passer la proposition Le travail de raisonnement, de test et de sécurité, EIP5920 est retiré de la mise à niveau.

5. Relation avec zkml et abstraction de compte

Peu d'effet sur zkml

ZKML est la combinaison de Zero Knowledge Proof (ZeroKnowledge) et Machine Learning (Machine Learning); la combinaison de la blockchain et du modèle ML résout les problèmes de protection de la vie privée et de vérifiabilité de l'apprentissage automatique :

Protection de la vie privée : la confidentialité des données d'entrée, telles que l'utilisation d'une grande quantité d'informations personnelles comme données pour alimenter des machines pour la formation, la confidentialité des informations personnelles est une exigence majeure ; ou les paramètres du modèle, en tant que cœur de la compétitivité du projet, doivent également à chiffrer pour maintenir les barrières à la concurrence. Lorsque des problèmes de confiance tels que ceux-ci existent, les modèles ML seront empêchés d'obtenir des données et des applications à plus grande échelle.

Vérifiabilité : la technologie de preuve à connaissance zéro a un large éventail d'applications, et ZKP permet aux utilisateurs de connaître l'exactitude des informations sans vérification. Et parce que le modèle d'apprentissage automatique nécessite beaucoup de calculs, le modèle ML peut générer des preuves via ZK-SNARK, réduisant la taille de la preuve et atténuant la demande de puissance de calcul de ML.

Les exigences de stockage de ZKML ont peu à voir avec DA : une structure de stockage séparée comme l'espace et le temps est requise, et sa technologie de base est le nouveau protocole de sécurité "SQL Proof". Ou connectez les données en chaîne et hors chaîne dans un simple Formater SQL et charger les résultats directement dans des contrats intelligents ;

ZK-SNARKs est la forme principale de ZK dans ZKML, qui peut s'adapter aux besoins en puissance de calcul de ML sur la chaîne.Avec le développement de la cryptographie, les preuves SNARK particulièrement récursives bénéficieront de l'implémentation de ZKML sur la chaîne :

Les ZK-SNARK se caractérisent par une grande compacité. L'utilisation de ZK-SNARK permet au prouveur de générer une preuve courte, et le vérificateur n'a pas besoin d'interagir et n'a besoin d'effectuer qu'une petite quantité de calculs pour vérifier sa validité. Cela ne nécessite qu'un seul prouveur La nature de l'interaction avec les vérificateurs rend les ZK-SNARK efficaces et pratiques dans les applications pratiques, et est plus adapté aux exigences de puissance de calcul en chaîne de ML.

Il est actuellement impossible de s'entraîner sur la chaîne, et seuls les résultats des calculs hors chaîne peuvent être stockés sur la chaîne :

Le problème actuel de ML est davantage dû aux exigences de puissance de calcul non satisfaites et aux faibles performances causées par les limitations de l'algorithme (ne peut pas être calculé en parallèle).Le grand modèle ZK prouve qu'une puissance de calcul plus élevée est nécessaire, ce qui ne peut pas être pris en charge sur la chaîne. Les ZK-SNARK ne prennent en charge que les petites preuves d'échelle à connaissance zéro ML et une petite quantité de calcul, c'est-à-dire que la limitation de la puissance de calcul est un facteur clé affectant le développement des applications de blockchain ZKML, et la chaîne ne peut stocker que les résultats de off -chaîne de calculs.

** Bonne abstraction de compte **

Tout d'abord, la mise à niveau de Cancun peut réduire dans une certaine mesure le coût de la preuve ZKrollup :

Les frais de transaction zkSync actuels dépendent de 3 aspects :

Le coût des ressources fixes consommées par le vérificateur pour générer le certificat SNARK et le vérifier est relativement élevé ;

Les frais de gaz lorsque le vérificateur soumet la preuve SNARK au réseau principal Ethereum, cette partie des frais augmentera en conséquence en raison de la congestion du réseau principal ;

Les frais de service payés par l'utilisateur au vérificateur, y compris la confirmation de la transaction, la diffusion du message, etc.

Par conséquent, si 4844 est introduit, le problème de l'augmentation des frais de gaz causée par la congestion du réseau principal sera atténué et le coût des épreuves ZKP pourra être réduit dans une certaine mesure.La tendance de développement de la série ZK ne doit pas être sous-estimée.

Deuxièmement, l'abstraction de compte transforme les transactions tx traditionnelles en opérations utilisateur, puis regroupe les opérations utilisateur en blocs avec ECDSA, qui occupe plus de stockage sur la chaîne qu'auparavant, de sorte que les exigences de stockage sont plus élevées ;

Ensuite, l'abstraction de compte et ZKrollup peuvent se compléter :

À l'heure actuelle, le problème de l'abstraction de compte est que GasFee coûte cher. Parce qu'il y a trop d'étapes et de contrats intelligents, il y a beaucoup de données, ce qui rend GasFee cher. L'avantage de ZKRollup est qu'il peut réduire les données ;

L'abstraction de compte rend difficile la garantie de la sécurité : étant donné que AA implique plusieurs contrats, la sécurité est un problème. Cependant, après la formation progressive de L2 à l'avenir, la couche de consensus ne sera plus modifiée, les contrats intelligents auront plus d'utilisations et la sécurité d'abstraction de compte augmentera également. Il peut être garanti, et avec la vérification de confiance de ZKrollup, la sécurité sera encore améliorée.

Enfin, compte tenu de l'essor de la technologie de l'IA, elle peut contribuer à renforcer la sécurité des contrats en chaîne et à optimiser les transactions ou les étapes d'activité en chaîne :

IA et sécurité : la technologie de l'IA peut être utilisée pour améliorer la sécurité et la protection de la confidentialité des transactions en chaîne. Par exemple, la plateforme de sécurité Web3 SeQure utilise l'IA pour détecter et prévenir les attaques malveillantes, les fraudes et les fuites de données, et fournit des mécanismes de surveillance et d'alarme en temps réel pour assurer la sécurité et la stabilité des transactions sur la chaîne ;

Optimisation de l'IA et des activités en chaîne : les activités sur la blockchain incluent les transactions, l'exécution des contrats et le stockage des données. Grâce aux capacités d'analyse et de prédiction intelligentes de l'IA, les activités en chaîne peuvent être mieux optimisées et l'efficacité et les performances globales améliorées. L'IA peut aider à identifier les modèles de transaction, détecter les activités inhabituelles et fournir des recommandations en temps réel pour optimiser l'allocation des ressources pour les réseaux blockchain grâce à l'analyse des données et à la formation de modèles.

Par conséquent, la mise à niveau de Cancun bénéficiera progressivement au développement futur de l'abstraction de compte de l'expansion de l'espace de stockage, à la complémentarité avec ZKrollup, puis à la combinaison avec la technologie AI.

6. En regardant la feuille de route d'Ethereum, quelle est la prochaine étape ?

À l'heure actuelle, Layer2 n'a pas de performances similaires à Solana (en termes de latence et de débit), ni de performances de fragmentation comme Near, ni de performances d'exécution parallèle comme Sui et Aptos.La mise à niveau de Cancun a amélioré le leadership d'Ethereum en tant que chef;

Après la mise à niveau de Cancun, on estime que plusieurs temps de développement majeurs seront entièrement danksharding (2 ~ 5 ans), atterrissage MEV et PBS (1 ~ 3 ans), abstraction de compte (1 ~ 2 ans), ZK tout (3 ~ 6 ans) ), expérience EOF et développeur (combien de fois avez-vous vu l'extension ?).

Le fléau

Objectif : Concentrez-vous sur la résolution des problèmes MEV.

Solution : Minimiser le MEV au niveau de la couche application grâce à la "séparation proposant-constructeur (PBS)". À ce stade, les blobs peuvent être optimisés et des services de pré-confirmation ou de protection par préemption peuvent être introduits.

PBS est la séparation des créateurs de blocs et des trieurs. Le trieur est seul responsable du tri, quelle que soit la chaîne, et le créateur du bloc ne se soucie pas de la transaction, et sélectionne directement le paquet réalisé par le trieur et le met sur la chaîne. Ce processus rendra l'ensemble du processus plus équitable et atténuera le problème du MEV, qui est l'idée d'externaliser le MEV.

Le degré d'achèvement de PBS est encore très faible à l'heure actuelle, et le plus mature est la coopération avec des solutions MEV externes - mevboost de flashbots.

La version avancée de "Enshrined Proposer-Builder Separation (ePBS)" a un degré d'achèvement inférieur et un cycle plus long, et on estime qu'elle ne sera pas mise en œuvre à court terme. En outre, il existe des versions progressives de PEPC et Optimistic Relaying, qui améliore la flexibilité et l'adaptabilité du framework PBS

Le bord

Objectif : utiliser l'arborescence Verkel pour remplacer Merkle, introduire une solution de minimisation de la confiance, permettre aux nœuds légers d'obtenir la même sécurité que les nœuds complets et rendre la vérification des blocs aussi simple et portable que possible.

Dans le même temps, la ZKisation de L1 est clairement ajoutée à la feuille de route de Verge. ZK sera la tendance générale de l'expansion et de l'accélération futures ;

Solution : introduire des zk-SNARK pour remplacer l'ancien système de preuve, y compris les clients légers basés sur SNARK ; SNARK avec des changements d'état consensuels ; EnshrinedRollups.

Les arbres Verkle sont une alternative plus efficace aux arbres Merkle spécifiques à l'état qui n'ont pas besoin de fournir un chemin de chaque nœud frère (nœuds qui partagent le même parent) au nœud choisi, mais seulement le chemin lui-même comme preuve En partie, Verkle prouve sont 3 fois plus efficaces que les preuves de Merkle.

EnshrinedRollup fait référence à un cumul qui a une sorte d'intégration de consensus sur L1. L'avantage est qu'il hérite du consensus de L1 et n'a pas besoin de jetons de gouvernance pour effectuer des mises à niveau de cumul. En même temps, en effectuant des calculs en dehors de la chaîne et en publiant uniquement les résultats à la blockchain, cela peut augmenter le nombre de transactions, mais la difficulté technique de mise en œuvre est relativement importante. La combinaison de ces rollups à l'avenir pourra répondre à la plupart des besoins de l'écosystème blockchain dans les prochaines décennies.

La purge

ThePurge fait référence à l'objectif de simplifier le protocole en réduisant les besoins en stockage pour participer à la validation du réseau. Ceci est principalement réalisé par l'hibernation et la gestion de l'historique et de l'état. La dormance des données historiques (EIP-4444) permet aux clients d'élaguer les données historiques de plus d'un an et d'arrêter de fournir des services au niveau P2P.

état en sommeil. Lorsqu'il s'agit de gérer la croissance de l'état, il y a deux objectifs principaux : l'apatridie faible, qui fait référence à l'objectif de n'utiliser l'état que pour construire des blocs mais pas pour le vérifier ; L'état auquel on accède. L'hibernation d'état devrait réduire les nœuds d'état à stocker d'un total de 20 à 50 Go.

Dans la cinquième étape de Purge, EIP4444 est explicitement écrit dans la feuille de route. EIP-4444 exige que le client efface les données de plus d'un an. Dans le même temps, il existe certaines tâches d'optimisation EVM à cette étape, telles que la simplification du mécanisme de Précompilation GAS et EVM, etc. ;

TheSplurge

Dans la sixième étape finale de Splurge, EIP4337 a également été mentionné.En tant que proposition de mise en page à long terme pour l'écologie des portefeuilles, l'abstraction de compte améliorera encore la facilité d'utilisation des portefeuilles à l'avenir, y compris l'utilisation de pièces stables pour payer le gaz et les portefeuilles de récupération sociale. , etc.;