Le guide pour les débutants
Gate Post
En direct
Discussion
Événements à venir
Actualités
Blog Gate
Accueil
Recommander
Populaire
Aperçu
Publication

Le passé, le présent et l'avenir des mises à niveau de Cancun

金色财经_vip

Vie antérieure

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

  • La vision d'Ethereum est de devenir plus évolutif et plus sûr 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 de gaz sont élevés et la congestion est grave. Dans le même temps, l'espace disque requis pour exécuter un client Ethereum augmente également rapidement. Au fond, le travail d'assurer le sécurité et décentralisation d'Ethereum L'impact de l'algorithme de consensus de volume sur l'ensemble de l'environnement devient également de plus en plus important.
  • 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'espace actuel de chaque bloc d'Ethereum est d'environ 200 ~ 300 Ko, la taille minimale de chaque transaction est d'environ 100 octets, soit 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 façon de mettre une grande quantité de données dans le bloc Dans l'espace, la sécurité est garantie par 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 principal de la mise à niveau de Cancun.
  • 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 construire qu'une structure multicouche avec Rollup comme noyau, donc Cancun se met à niveau pour résoudre le TPS, le gaz Les frais et l'expérience des développeurs sont essentiels à la feuille de route Ethereum.

**Comment est prévue la feuille de route Ethereum ? **

Les dernières améliorations importantes et leurs objectifs

  • 2020année12mois1* La chaîne Beacon est officiellement lancée, ouvrant la voie à la mise à niveau POS*
  • 2021**8mois5** Mise à niveau de Londres, EIP1559 change le modèle économique d'Ethereum ;
  • 2022année9mois15* Surclassement Paris (Le Fusionner), terminé POW commutation POS ;*
  • 2023année4mois12* Mise à niveau à Shanghai, résolution du problème de retrait de promesse ;*
  • Le modèle économique et les mises à niveau liées au POS sont terminées, et les prochaines mises à niveau ont résolu les problèmes de performances d'Ethereum, de TPS et d'expérience des développeurs ;
  • La prochaine étape consiste à se concentrer sur la feuille de route Ethereum Le Surtension .
  • Cible: Atteignez plus de 100 000 TPS en Rollup.
  • Il existe 2 schémas, en chaîne et hors chaîne :
  • 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 partitionnement :
  • Le dilemme du schéma de sharding : le sharding incluait auparavant le sharding d'état, le sharding de transaction, etc., mais la synchronisation entre différents shards est un problème. À l'heure actuelle, il est difficile de réaliser une synchronisation de données de nœud de réseau à grande échelle. , non seulement ne peut pas résoudre la situation MEV, mais peut également nécessiter un grand nombre de correctifs pour compenser divers problèmes qui peuvent survenir, qui ne peuvent pas être réalisés à court terme.
  • Danksharding est une nouvelle conception de sharding proposée pour Ethereum, Son idée de base est Production de blocs centralisée + Vérification décentralisée + Résistance à la censure, Ceci est également lié à la disponibilité des données mentionnée ci-dessous Échantillonnage (DAS), Block Producer-Packer Separation (PBS) et liste de résistance à la censure (Crlist). La plus grande importance de l'idée centrale de Danksharding réside dans la transformation d'Ethereum L1 en un règlement unifié (règlement) et la disponibilité des données (Disponibilité des données) Disponibilité）层。

Le schéma de partitionnement est divisé en 2 étapes, actuellement il est divisé en Proto- sharding etentièrement cumulatif*****. ***

  • Donc- Danksharding**：**
  • introduire: Aidez à réduire les frais L2 et à augmenter le débit en introduisant des blobs , en même temps qu'une solution de pré-sharding pour ouvrir la voie au full sharding. On s'attend à ce qu'après le proto-danksharding, la mise en œuvre du danksharing prenne 2 à 5 ans.
  • 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 de stocker toutes les données cumulées dans blob, ce qui grandement allège la charge sur la chaîne principale.La pression de stockage peut également réduire le coût du rollup.
  • Complètement cumulatif * Introduction : le cumul est entièrement développé et se concentre sur l'utilisation de la disponibilité des données.
  • contenu:
  • Conception P2P de DAS : certains travaux et recherches impliquant des problèmes 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 qui peut déterminer rapidement si les données sont disponibles en échantillonnant au hasard quelques kilo-octets ;
  • Auto-guérison efficace de l'AD : capable de reconstruire efficacement toutes les données dans les pires conditions de réseau (par exemple, attaque de validateur malveillant ou temps d'arrêt à long terme des nœuds à gros blocs).

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, l'orientation 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 réunion des développeurs principaux (ACD en abrégé), puis l'équipe client le teste, que l'EIP soit inclus ou non dans le mise à niveau ou non, et 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.
  • Les conférences sont divisées en catégories 2, qui sont la réunion de la couche de consensus et la réunion de la couche exécutive, qui se tiennent alternativement toutes les deux semaines :
  • ** Réunion de la couche de consensus (Tous Core Developers Consensus - ACDC), se concentrant sur la couche de consensus Ethereum (preuve d'enjeu, chaîne de balises, etc.) ;**
  • Réunion du niveau exécutif ( Tous Solution Core Developers - ACDE**), qui se concentre sur la couche d'exécution d'Ethereum (EVM, **Gas schedule, etc.).
  • Il existe 3 types de mainteneurs du cœur d'Ethereum, principalement des organisations officielles ou des forums de bénévoles discutant de propositions :
  • AllCoreDevs : mainteneurs de code, responsables du client réseau ETH1, mise à niveau, maintenance du code Ethereum et de l'architecture de base ;
  • 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 ;
  • Éthereum Magiciens : Un "forum" qui veut des discussions autour 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 5 étapes. ***

Phase 1 - Présentation des thèmes de mise à niveau

Introduire de nouvelles tâchesproto-danksharding***,EOF et "selfdestruction" * Opcode, discussion superficielle 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". A ce jour, la portée spécifique du proto-danksharding n'a pas été déterminée, et certains développeurs sont préliminaires À mon avis, 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'EIP 4844, mais un autre groupe de développeurs pense qu'il est plus logique d'implémenter 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 tourne principalement autour de ***EOF et *EIP 4844 Discussion, tout en continuant à promouvoir ****EIP 4844 ***** La cérémonie de réglage pré-crédible requise pour la cérémonie ***—KZG, les développeurs seront le *******23 **** Année **** 1 **** mois officiellement confirmé quelle mise à jour **** 4844 **** apparaîtra dans ***

  • 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 de la couche de consensus du 22 décembre, Trent, le chef de l'écosystème Ethereum Van Epps a mis à jour l'EIP 4844 Progrès dans la mise en œuvre de la cérémonie de configuration de confiance requise pour générer un Code de sécurité utilisé dans 4844. Van Epps espère que la cérémonie sera l'une des plus importantes jamais organisées dans l'espace cryptographique, recueillant 8 000 à 10 000 contributions, et que la période de contribution publique pour 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 développeur de la Fondation Ethereum s'est opposé au report d'EOF à Cancun, arguant que si les changements de code n'étaient pas inclus à Shanghai, il La possibilité d'entrer à Cancun est très faible, concernant le code d'autodestruction, il y a des développeurs qui préconisent de faire avancer l'EIP à l'époque 4758, mais désactiver directement cet opcode cassera certaines applications, et le développeur estime que cet EIP devrait être à nouveau pesé pendant un certain temps avant de créer un cas limite pour protéger ce type de contrat ;
  • Lors de la réunion des développeurs principaux du 9 décembre 22, la mise en œuvre de la cérémonie KZG a été promue concernant la mise à niveau de Cancun et l'EIP actuel 4844 La cérémonie de configuration sécurisée requise est prête ;
  • Lors de la réunion de la couche de consensus les 16 et 22 décembre à propos de l'EIP 4844, les développeurs ont discuté de la fusion de deux demandes d'extraction (PR) différentes dans la spécification de proto-danksharding, l'une liée à la façon dont les nœuds gèrent la disponibilité des données au-delà d'un certain point après l'élagage des données, et l'autre lorsqu'un bloc De nouveaux codes d'erreur seront introduits pour alerter les nœuds lorsque il manque des informations sur les blobs sur
  • Lors de la réunion de développement principale du 5 janvier 23, les développeurs sont parvenus à un consensus pour supprimer les modifications de code liées à la mise en œuvre d'EOF de la mise à niveau de Shanghai, Beiko a alors suggéré de décider après deux semaines si EOF devrait être inclus dans Cancun est en cours de mise à niveau ;

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

À la fin du 231**EOF a déménagé à Cancun pour une promotion après avoir été déplacé de la promotion de Shanghai, depuis lors, **** 2 **** mois tournent principalement autour de l'exception de **** EOF ****** et **** EIP D'autres propositions autres que 4844***** ont été discutées, et en même temps, ***EOF a été proposé 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 les 20 et 23 janvier, EOF a été déplacé à Cancun pour une mise à niveau ;
  • Lors de la réunion des développeurs principaux du 6 23 mars, la proposition préliminaire pour la mise à niveau de Cancun était : EIP 4788 (racine d'état de la chaîne de balise publique), EIP 2537 (Effectuer efficacement des opérations telles que la vérification de la signature BLS et la vérification des SNARK), EIP-5920 (introduit le nouvel opcode PAY) et EIP Une implémentation combinée de 6189 (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 les 16 et 23 mars, sauf pour EOF et EIP 4844, les propositions suivantes ont été prises en compte pour inclusion dans Cancún : format SSZ, suppression SELFDESTRUCT, EIP 2537、EVMMAX、EIP
  1. Instructions SWAP et DUP illimitées, introduisant des codes PAY et des racines d'état de balise dans l'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ésactivation de SELFDESTRUCT que Cancun a finalement décidé d'utiliser. Mais concernant la mise en place d'EOF, d'Erigon (EL) Un développeur de l'équipe client a déclaré EOF "Trop de changements" pour concurrencer la proposition d'amélioration d'Ethereum EIP dans la prochaine mise à niveau de Cancún 4844, il y avait une proposition d'implémenter EOF dans le hard fork peu de temps après la mise à jour de Cancun ;

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

En 234mois, il y a une orientation claire pour les propositions qui devraient être couvertes par la mise à niveau de Cancun, et les nœuds clés sont en 4 ********************************************* ****************************************************** ********** EIP, et tim ont également eu une discussion plus approfondie sur les propositions alternatives, en 4mois Lors de la réunion du 27EIP 6780**、EIP 6475 etEIP 1153 est déterminé à être inclus à Cancun, et en même temps EOF et EVMMAX (avec * *** EOF ***** lié à la mise en œuvre ***** EIP ****** sous-ensemble) a été supprimé de la mise à niveau de Cancun, la mise à niveau ********* EOF ****** aide principalement EVM effectue le contrôle de version et peut exécuter plusieurs ensembles de règles de contrat en même temps, ce qui aidera l'expansion ultérieure d'Ethereum, mais compte tenu de la faisabilité de l'ensemble de la mise à niveau, ** * EOFLa mise à niveau peut être reportée avec la mise à niveau quotidienne**

  • 23****4mois12****, la mise à niveau d'Ethereum Shanghai est terminée ;
  • Lors de la réunion de développement principale du 13.04.23, les développeurs ont discuté de l'EIP 4844 (pour exposer les données sur la racine de l'état CL dans l'EL), au moins neuf autres EIP sont envisagés pour la mise à niveau, à savoir EIP 4844**, AUTODESTRUCTION SUPPRIMER (EIP-6780, EIP 4758、EIP 6046、EIP 6190）、EIP 5920、EIP 1153、EIP 2537、EIP 4788、EVMMAX EIP（EIP 6601 et EIP 6690), SS changements ** (EIP 6475、EIP 6493、EIP 6465、EIP 6404 et EIP 6466 ）、EIP 5656 et**EIP 6193** ;
  • Lors de la réunion des développeurs principaux 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, avec l'ajout des EIP suivants : EIP 6780 (modifie la fonctionnalité de l'opcode SELFDESTRUCT), EIP 6475 (un nouveau type de sérialisation simple (SSZ) pour représenter les valeurs facultatives), EIP 1153 (ajouter un nouvel opcode pour opérer le statut); deuxièmement, l'EIP qui est considéré mais pas officiellement inclus dans la mise à niveau est EIP 6913 (introduction de l'instruction SETCODE), EIP 6493 (Définir un schéma de signature pour les transactions codées SSZ), EIP 4788 (exposer la racine du bloc de la chaîne de balises dans l'en-tête du bloc EL), EIP 2537 (ajoute la courbe BLS12-381 comme précompilation) et EIP 5656 (introduit de nouvelles instructions EVM pour copier des régions de mémoire) ; enfin, EOF ** et ** EVMMAX** (** EOF ** dépend de l'implémentation ** * EIP* sous-ensemble) a été supprimé de la mise à niveau de Cancun. **** EOF ** ** La mise à niveau a été déplacée hors de Shanghai lors de la conférence des développeurs Ethereum au début de **** 2023 ******** 1 , et a ensuite été mise à niveau de * *** De la fin de 1 au début de 4 en 23, il apparaîtra dans la mise à jour de Cancun par défaut, mais en ** 23 **EOF **a été supprimé à nouveau lors de la réunion des développeurs le 29, 4. **

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

235mois rationalise et améliore principalement les détails de la proposition finale,SSZ-> Les changements RLP signifieront que les deuxSSZ à Cancún ne seront plus nécessaires EIP**, doncEIP 6475 et 6493 seront déplacés hors de Cancun pour des mises à niveau. Au même moment, lors de la réunion principale du 26, Tim Beiko recommande 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 * ****. Les développeurs ont maintenant déterminé l'étendue complète de la mise à niveau de Cancun. ***

*Réunion Ethereum Core Consensus le 5/5/23, discutant du dernier EIP mentionné 4788, tout en ajoutant l'EIP 6987 et EIP Discussion en 6475, ces deux propositions concernent respectivement les vérificateurs et les transactions SSZ ;

  • Lors de la 161e réunion de la couche exécutive d'Ethereum les 11 et 23 mai, Tim Beiko a déclaré que la portée de la mise à niveau de Cancun peut encore être modifiée dans les prochaines semaines, mais sans avis explicite des développeurs, la portée de la mise à niveau de Cancun restera dans l'état "par défaut", et la discussion sur EIP-4844 montre que le développement L'auteur a accepté de supprimer SSZ de l'implémentation EL de EIP-4844, ** mais cela n'a pas encore affecté la progression continue de ** ** 6475 ** **. ** En plus de cela, les développeurs ont également brièvement discuté de deux EIP à examiner à Cancun, à savoir EIP 6969（EIP
  1. et EIP 5656 (instructions EVM efficaces pour copier des régions de mémoire);
  • Les développements de 4844 ont été brièvement discutés lors de la réunion Developer Consensus du 18 mai 23, comme l'autorisation des applications de contrat intelligent sur EL pour 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 finaux à Cancun ont été discutés lors de la 162e réunion Ethereum Core le 25 mai 2023. Tim Beiko recommande 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**. Les devs confirmeront dans les prochaines semaines ** Dencun** (****Deneb
  • toute la gamme de Cancun****);**
  • 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. À partir de ce résultat, le chercheur a suggéré que le EIP La spécification 4844 est passée d'un maximum de 4 blobs à 6 par bloc. Dans le même temps, les développeurs envisagent l'EIP 4788 inclus dans la mise à niveau de Cancun ;
  • Lors de la réunion principale des développeurs du 13 juin 2023, ** les développeurs ont officiellement confirmé la portée de la mise à niveau, y compris **** EIP 4844****、EIP 1153、EIP 5656、EIP 6780、EIP 4788；**
  • 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 a accepté à ce qui suit Un réseau de test EIP-4844 Devnet6 testera le nombre accru de blobs et prendra une décision finale à ce sujet dans les deux semaines, tandis que le chercheur de la Fondation Ethereum Michael Neuder a proposé de supprimer le plafond de jalonnement de 32 ETH 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 le BLS vers une autre adresse, bien que précompilé via EIP 2537, mais il ne sera pas envisagé à Cancun ;
  • Lors de la réunion de consensus du 29 juin 2023, les développeurs ont continué à discuter du nombre de blobs, limitant le blob cible Augmentation de 2 à 3, augmentation de la limite maximale de blob de 4 à 6 et 4844 réseaux de test Devnet #7 arrive bientôt.

cette vie

  • Le contenu de base est EIP 4844，即Proto-Danksharding
  • La plage EIP finale pour cette mise à niveau de Cancún est : EIP 4844**、EIP 1153、EIP 5656、EIP 6780、EIP 4788. Pendant ce temps, lors de la 111e réunion Ethereum ACDC le 19 juin, les développeurs ont continué à discuter EIP 6988、** EIP 7044**、**EIP 7045 pour inclusion 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 de KeyEIP

EIP 4844

  • Introduction:
  • Le nom de la proposition EIP4844 est Proto-Danksharding, qui est le pré-protocole de la version complète de l'extension de partitionnement Danksharding. L'ensemble des schémas de partitionnement est en fait basé sur Rollup pour l'expansion en chaîne. **Le but du programme est d'étendre la ** 2 couche **Rollup——****En aidant L2 à réduire les frais et à augmenter le débit , tout en ouvrant la voie au sharding complet (sharding). **
  • Lors de la conférence téléphonique du 23 février, les développeurs d'Ethereum EIP La mise à niveau 4844 s'appelle Deneb, qui est le nom d'une étoile de première magnitude dans la constellation Cygnus, qui est l'EIP sur la version GitHub pertinente à l'avenir Le nom de 4844 sera mis à jour en Deneb ; lors de la réunion du 1er juin 23, il y aura 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 des 23 et 23 juin, les développeurs se sont préparés à mettre à jour l'EIP L'adresse précompilée de 4844. Actuellement, les principaux développeurs ont ajouté 9 précompilations à l'EVM et activeront l'EIP en 4844 et 4788 créent deux précompilations sous les adresses "0xA" et "0xB" respectivement. Lors de la réunion de consensus du 29 juin, le PEI est prêt à être lancé Le réseau de test à court terme dédié de 4844 Devnet #7.
  • EIP-4844** introduit un tout nouveau type de transaction - Blob Transaction。** *Profil blob :
  • Blob, similaire à un paquet de données de plug-in, seulement 128 au début L'espace de stockage de KB, au début de la discussion de la proposition, la cible et la limite de Blob étaient de 2/4, et il a été ajusté à 3/6 lors de la réunion des développeurs du 9 juin 23. C'est-à-dire qu'actuellement, chaque transaction dans Ethereum peut transporter jusqu'à trois transactions Blob, soit 384 KB, la cible de chaque bloc La capacité de blob est de 6, soit 768 KB, qui peut contenir jusqu'à 16 blobs, 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 tester d'abord pour éviter le besoin de hard forks ultérieurs pour étendre le bloc blob.
  • Blob **dans ** KZG commit Hash En tant que ** Hash, utilisé pour la vérification des données, la fonction est similaire à ** Merkle ;
  • Le nœud synchronise le Blob sur la chaîne Après la transaction, la partie blob expirera et sera supprimée après un certain temps, et la durée de stockage est de trois semaines.
  • Fonction 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, dépassant directement de loin le registre lui-même de plusieurs fois ;
  • Pour les nœuds, le téléchargement de 1 Mo à 2 Mo supplémentaires 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 le décentralisation de l'ensemble du nœud Ethereum, mais l'expansion autour de Rollup est grandement améliorée ;
  • En fait, 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** - pour ouvrir le premier chapitre du récit Danksharding**
  • **Extension haute capacité : **À l'heure actuelle, EIP-4844 peut initialement étendre la capacité L2. La version complète de Danksharding peut étendre le volume de données Blob dans EIP-4844 de 1 Mo à 2 Mo à 16 Mo à 32 Mo, garantissant la décentralisation et la sécurité. obtenir une expansion plus élevée ;
  • ** Frais peu élevés : ** Les analystes de Bernstein montrent que 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, ce qui peut réduire le coût de déploiement de 50 % selon les observations actuelles ;
  • La solution technique DA d'EigenLayer ne divulgue pas trop pour évaluer ses données ;
  • Stricto sensu, Celestia n'a que peu à 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 le coût 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.
  • **DA****Solution : Danksharding (une solution de sharding pour l'expansion d'Ethereum) à l'heure actuelle, si l'expansion se poursuit, la charge des nœuds peut être trop importante (****16 mb **** ci-dessus) et disponibilité insuffisante des données (validité 30 jours). Solution: **
  • Échantillonnage de la disponibilité des données (Data Échantillonnage de la disponibilité) - réduit la charge sur les nœuds
  • Coupez les données du Blob en fragments de données et laissez le nœud 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 les données complètes du Blob sont stocké dans l'intégralité du registre Ethereum, le principe est que les nœuds doivent être suffisants et décentralisés ;
  • DAS utilise deux technologies : code d'effacement (Erasure Codage) et KZG Polynomial Commitment (KZG Engagement);
  • Séparation Proposer-Packager (PBS)——Résolu le problème de la division du travail des nœuds, laisser les nœuds avec une configuration haute performance être responsables du téléchargement de toutes les données pour la distribution d'encodage, et laisser les nœuds avec une configuration basse performance être responsables de vérification par sondage.
  • Un nœud avec une configuration haute performance peut devenir un builder. Le builder n'a qu'à télécharger les données blob pour l'encodage et créer un bloc (Block), puis les diffuser à d'autres nodes pour des vérifications ponctuelles. Pour le builder , car la synchronisation le volume de données et les besoins en bande passante sont élevés, il sera donc relativement centralisé ;
  • Un nœud avec une configuration peu performante peut devenir un proposant (Proposer), et le proposant n'a qu'à vérifier la validité des données et créer et diffuser l'en-tête de bloc (Block Header), mais pour le proposant (Proposer), le volume de données de synchronisation et les besoins en bande passante sont faibles, 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 trier et insérer au hasard les 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 aux révisions (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 Gas la limite est pleine);
  • Après 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 l'en-tête de bloc (Block En-tête) et diffusion ;
  • Lorsque le nœud synchronise les données, il obtiendra l'en-tête du bloc du proposant (Proposer), puis obtiendra le corps du bloc auprès 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 emballeurs 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'enchère 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 sera produit, si l'emballeur ne donne délibérément pas le corps du bloc, il sera considéré que le bloc n'existe pas).
  • Signification:
  • Tout d'abord, le constructeur (Builder) a plus de pouvoir pour packager 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, ensuite Il doit payer beaucoup de frais d'appel d'offres au début pour s'assurer qu'il peut obtenir la qualification de tête de bloc, ensuite le profit MEV qu'il obtient sera encore réduit, et globalement cela aura un impact sur les moyens et la valeur réelle d'obtention du 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. Dans le même temps, le nombre de packers est très faible Dans le cas de , 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 ;
  • A un certain impact sur certaines solutions MEV utilisant les enchères MEV.
  • Signification:
  • EIP 4844 En fait une version super simplifiée Danksharding** : **Il fournit la même interface d'application que Danksharding, y compris un nouvel opcode appelé Data Hash ; et un nouvel objet de données appelé Binary Grands objets, c'est-à-dire Blob ;
  • proto-danksharding ** est utilisé pour implémenter la spécification complète ** Danksharding ** "bracket"** (** est le format de transaction et les règles de vérification****) * * Proposition : Cependant, aucun partage 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 la perspective à long terme choisit proto-danksharding non EIP 4488 ** réduit directement les frais de ** layer2 , car seul un petit ajustement est nécessaire lors de la mise à niveau vers une partition complète à l'avenir :
  • EIP La principale différence pratique entre 4488 et le proto-danksharding est que l'EIP-4488 essaie de minimiser les changements qu'Ethereum doit apporter aujourd'hui, tandis que le proto-danksharding apporte plus de changements à Ethereum aujourd'hui afin de passer à Ethereum à l'avenir. requis pour le partage de la version complète ;
  • Bien qu'il s'agisse d'une tâche très complexe pour réaliser un partitionnement complet (avec échantillonnage de la disponibilité des données, etc.), 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 d'exécution, les développeurs de rollup et les utilisateurs n'ont pas besoin d'effectuer de travail supplémentaire pour passer au sharding complet.
  • Pour obtenir un partage complet, il est nécessaire de terminer la mise en œuvre réelle de ** PBS, la preuve de délégation et l'échantillonnage de la disponibilité des données, mais ces modifications seront concentrées dans le ** CL * * couche, les développeurs n'ont pas besoin de réajuster ** : 4844 implémente actuellement un nouveau type de transaction, qui est exactement le même que le format de transaction, la logique de validation croisée consensuelle et la logique de couche d'exécution requise dans le fragment complet, et aussi dérivé pour les blobs , tarification du gaz indépendante auto-ajustable, afin d'obtenir un partage complet à l'avenir, il est nécessaire d'achever la mise en œuvre réelle du PBS, de la preuve de délégation et de l'échantillonnage de la disponibilité des données, mais ces modifications ne concernent que la couche CL, et ne nécessite pas la modification de la couche EL ou des développeurs de cumul, ce qui est pratique pour le développement.

*** suivi de ****** SELFDESTRUCT retrait , EIP-6780 a finalement été déterminé comme étant la solution la plus appropriée, mais le développeur sur 26 Dans le réunion tim a proposé d'ajouter un autre opcode à cette propositionSETCODE** pour permettre aux comptes programmatiques d'être toujours mis à jour***

AUTO-DESTRUCTION suppression 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 étant qu'il est le seul capable de modifier un nombre infini d'objets d'état en un seul bloc, ce qui entraîne des changements dans les codes de contrat, et peut être utilisé sans le consentement du compte. peut modifier le code d'opération du solde du compte, ce qui présente de grands dangers cachés pour la sécurité d'Ethereum ;**
  • La seule façon 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 selfdestruction** 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 l'EIP qui en découle 6780 a été fixé comme 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é.
  • EIP 6780 : 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é dans le contrat intelligent est mise à jour au moyen d'une mise à jour/mise à niveau), voici l'absorption d'EIP Les avantages du 4758, qui peut donner à dapp la possibilité de se mettre à 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 pose une difficulté pour l'utilisation future des arbres Verkle : chaque compte sera stocké dans de nombreuses clés de compte différentes qui ne seront pas explicitement liées au compte racine.
  • CHANGÉ : Cet EIP implémente des modifications pour supprimer SELFDESTRUCT, sauf dans les deux cas suivants
  • Les applications qui ne sont utilisées que pour SELFDESTRUCT pour retirer des fonds fonctionneront toujours ;
  • SELFDESTRUCT utilisé dans la même transaction dans le contrat n'a pas besoin d'être modifié. * Importance : Sécurité accrue
  • Auparavant, il y avait un contrat sur le réseau principal qui utilisait SELFDESTRUCT pour restreindre qui peut initier des transactions via le contrat ;
  • Empêchez les utilisateurs de continuer à déposer des fonds et à échanger dans un coffre après SELFDESTRUCT, alors ce coffre peut amener n'importe qui à voler des jetons dans le coffre lors d'une utilisation répétée.

Les trois propositions ci-dessous sont les propositions concernant AUTODESTRUCTION qui ont ensuite été supprimées, en 23année*****4 *** 6780 a été officiellement sélectionné lors de la réunion des développeurs principaux le **28, et les trois autres propositions ont été abandonnées. est que l'équipe de développement d'Ethereum veut finalement supprimer complètement l'opcode SELFDESTRUCT, et les trois propositions suivantes sont pour la plupart modifiées par remplacement. ***

  • EIP-4758 (PÉRIMÉ) : 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 du code SELFDESTRUCT nécessitait des modifications importantes de l'état du compte, telles que la suppression de tous les codes et le stockage. Cela pose une difficulté pour l'utilisation future des arbres Verkle : chaque compte sera stocké dans de nombreuses clés de compte différentes qui ne seront pas explicitement liées au compte racine.
  • Changement:
  • Opcode SELFDESTRUCT renommé en SENDALL, déplace désormais uniquement tous les ETH du compte vers l'appelant, ce schéma ne détruit plus le code et le stockage, ni ne modifie les nombres aléatoires ;
  • Tous les remboursements liés à SELFDESTRUCT ont été supprimés
  • Signification:
  • Préservation de la fonctionnalité d'origine par rapport à EIP-6780, car certaines applications ont encore/besoin d'utiliser le code SELFDESTRUCT.
  • EIP-6046 (PÉRIMÉ) : Remplacez SELFDESTRUCT par DESACTIVATE. 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 un arbre 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.
  • Changement:
  • Modifier les règles introduites par EIP-2681 afin que l'augmentation régulière du nonce soit limitée 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 **, ** 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.
  • Signification:
  • Cette proposition a plus de flexibilité que les autres suppressions directes de SELFDESTRUCT.
  • EIP-6190 (PÉRIMÉ) : SELFDESTRUCT modifié, compatible avec Verkle, de sorte qu'il ne provoque qu'un nombre limité de changements d'état
  • Raison : comme ci-dessus, avec un arbre 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.
  • MODIFIÉ : Au lieu de détruire le contrat à la fin d'une 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 de stockage du contrat est défini sur le contrat à l'aide de l'opcode CREATE ( keccak256(contractAddress, nonce)) sera émis lorsque l'adresse. 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 intégralement viré à l'adresse en haut de la pile ;
  • Le haut de la pile est sauté.
  • Signification:
  • 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é.

Suivi deEIP 1153***, tout en économisantde gaz, ouvrant la voie à la conception future du stockage***

EIP 1153X

  • En bref : opcodes de stockage transitoires, ajoutez des opcodes pour manipuler l'état qui se comporte 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 trames 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é.
  • avec réentrance verrou par exemple, il ne peut pas s'appuyer sur des trames intermédiaires pour communiquer l'état du verrou : la communication SSTORE via le stockage SLOAD 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, TLOAD ( 0xb3 ) et TSTORE ( 0xb4 ), ont été ajoutés à l'EVM.
  • Le stockage transitoire est privé pour le contrat qui le possède, tout comme le stockage persistant, seul le cadre du contrat propriétaire peut accéder à son stockage temporaire. 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 :
  • réentrance verrouillage;
  • Adresses CREATE2 calculables sur la chaîne : les paramètres du constructeur sont lus à partir du contrat d'usine, plutôt que transmis dans le cadre du hachage du code d'initialisation ; * Approbation EIP-20 pour une seule transaction, par exemple #temporaryApprove(address dépensier, montant uint256) ;
  • 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 actions dans le cadre du rappel, et vérifie si "till" est équilibré à la fin ;
  • Métadonnées d'appel 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.
  • Signification:
  • Économisez gaz**, avec des règles de facturation plus simples** gaz ;**
  • ** Résoudre le problème de la communication inter-trame ; **
  • ** Ne modifiez pas la sémantique des opérations existantes ; **
  • Pas besoin de vider le réservoir de stockage après utilisation ;
  • ** Les futures conceptions de stockage (telles que les arbres ** ** Verkle ** **) n'ont pas besoin de prendre en compte les remboursements pour le stockage instantané. **

Suivi de 4788, cela peut réduire l'hypothèse de confiance sur le pool de gage**

EIP 4788**：**X

  • Introduction : racine du bloc balise dans EVM. *Mise à jour : lors de la réunion des développeurs du 15 juin 23, les développeurs ont proposé d'apporter des modifications au code pour améliorer l'expérience de mise en jeu. Cet EIP divulguera la racine du bloc de chaîne de balises, qui contient des informations sur l'état de la chaîne interne EVM, pour le développement de DApp. la confiance de l'auteur minimise l'accès.
  • MODIFIÉ : validez 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 exposer l'état de la couche de contrat ( CL ) Les données racine au niveau de la couche d'exécution (EL) peuvent rendre la communication entre différents protocoles et applications du réseau Ethereum plus efficace et sécurisée. **Autoriser des conceptions plus fiables pour les pools d'implantation, les protocoles de pontage et de reprise.

Le dernier est5656***, qui fournit un nouvel opcode de copie de mémoire efficace, mais est actuellement en état d'être temporairement inclus dans la mise à niveau en raison de sa bande passante de test** *

EIP 5656X

* Introduction : MCOPY

  • Instruction de copie de mémoire. Mise à jour : 09.06.23, l'équipe de développement a déclaré qu'elle était initialement divisée sur MCOPY car, même si cela résolvait le problème de sécurité, elle était toujours préoccupée par son ajout à la bande passante d'implémentation et de test requise pour la mise à niveau, mais a finalement accepté d'inclure le EIP , mais sa suppression sera envisagée si le développeur rencontre des problèmes de capacité lors des tests ou côté client. Par conséquent, 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.
  • Signification : la copie de la mémoire est une opération de base, 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 plus précisément, ce qui augmentera les performances de copie en mémoire d'environ 10,5 %, ce qui est très utile pour diverses opérations gourmandes en calculs ;
  • Il sera également utile pour les compilateurs de générer un bytecode plus efficace et plus petit ;
  • Il peut économiser une certaine quantité de coûts de gaz précompilé d'identité, mais il ne peut pas réellement promouvoir la mise en œuvre de cette partie.

Liste restreinte****EIP

Le 236mois15**, la réunion de consensus des développeurs a discuté en *** Quel EIP** centré sur CL sont inclus dans Deneb, où **** ** EIP 6988*****、*EIP 7044、******EIP 7045 *** *** est proposé d'adhérer. ***

EIP 6988**：**X

  • Brief : Empêcher les validateurs slashés d'être élus comme proposants de blocs. * Importance : des pénalités accrues pour les nœuds enfreints profiteront à la TVP.

EIP 7044**：**X

  • Résumé : S'assurer que les sorties de validateur signées sont valides en permanence.
  • Importance : cela peut améliorer l'expérience des jalonneurs dans une certaine mesure.

EIP 7045**：**X

  • Introduction : attestation de volonté La plage d'inclusion de créneaux s'étend d'une fenêtre glissante d'une époque à deux époques.
  • Signification : Améliorer la sécurité du réseau.

Supprimer l'analyse de EIP

Le **** jour du 29***************************** ********************************************** A ** 160****ACDE réunion d'Ethereum, EVMMAX et EOF **** est confirmé comme étant supprimé de cette mise à jour, des modifications liées à EOF peuvent être introduites dans les mises à jour quotidiennes suivantes

EVMMAX EIP**：**

  • Brief: 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.
  • EIP 6601 : Extensions arithmétiques modulaires EVM (EVMMAX)
  • Changement : est EIP 5843 itérations, avec EIP La différence de 5843 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, EIP-6601 d'autres mises à niveau sur cette base, en introduisant une section de configuration, un espace mémoire séparé et de nouveaux opcodes, pour que les opérations arithmétiques modulaires offrent une meilleure organisation et flexibilité tout en prenant en charge un module plus important 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 le coût du gaz des opérations sur des valeurs allant jusqu'à 256 bits de 90 à 95 % par rapport aux opcodes ADDMOD existants ;
  • Permet à la précompilation modexp d'être implémentée en tant que contrat EVM ;
  • Réduit considérablement le coût de la vérification ZKP dans les fonctions de hachage algébriques (par exemple MiMC/Poséidon) et EVM.
  • EIP 6690：
  • 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 indépendante. Il fournit une approche plus simplifiée en supprimant la dépendance à EOF.
  • Importance : il conserve la fonctionnalité de base de l'EIP-6601, qui peut effectuer des opérations arithmétiques modulaires optimisées sur des modules impairs jusqu'à 4 096 bits. Cette simplification permet une mise en œuvre et une adoption plus efficaces, tout en offrant les avantages associés à l'avantage de l'EIP-6601.

EOF changements**:**

  • Introduction : EOF est une mise à niveau vers EVM, qui introduit de nouvelles normes contractuelles et de nouveaux opcodes. Le bytecode EVM traditionnel (bytecode) est une séquence d'instructions non structurées (non structurées séquence 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 contractuelles en même temps.
  • EIP 663：
  • Brève : instructions SWAP et DUP sans restriction
  • 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
  • EIP 3540：
  • 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 fonctionnalités ou anciennes fonctionnalités obsolètes.
  • Cet EIP introduit un conteneur qui peut être étendu et contrôlé en version pour EVM, et déclare le format du contrat EOF. Sur cette base, le code peut être vérifié lors du déploiement du contrat EOF, c'est-à-dire la création Validation temporelle, ce qui signifie que les contrats non conformes au format EOF peuvent être empêchés d'être déployés.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) dans l'avenir.
  • Signification:
  • 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 le travail d'analyse de données en chaîne outils.
  • EIP 3670：
  • Introduction : Basé sur EIP-3540, le but est de s'assurer que le code du contrat EOF est conforme au format et est valide, et le déploiement de contrats non conformes au format sera empêché sans affecter Legacy bytecode。
  • 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.
  • EIP 4200：
  • Introduction:
  • Introduit les premiers opcodes spécifiques à EOF : RJUMP, RJUMPI et RJUMPV, qui encodent destinations sous forme de valeurs immédiates signées. Les compilateurs peuvent utiliser ces nouveaux opcodes JUMP pour optimiser le coût du gaz lors du déploiement et de l'exécution de JUMP, car ils éliminent le besoin d'opcodes JUMP et JUMPI existants pour faire jumpdest Le temps d'exécution requis pour l'analyse. Cet EIP est pour dynamique L'ajout de saut.
  • Par rapport aux opérations JUMP traditionnelles, 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 (à partir de dynamique sauts -> sauts statiques), car plusieurs fois statique les sauts suffisent.
  • Importance : optimiser le réseau et réduire les coûts.
  • EIP 4750：
  • Poussez la fonction de 4200 un peu plus loin : en introduisant CALLF Les deux nouveaux opcodes of et RETF implémentent des alternatives pour les situations qui ne peuvent pas être remplacées par RJUMP, RJUMPI et RJUMPV. De cette façon, JUMPDEST n'est plus nécessaire dans le contrat EOF, donc la dynamique est interdite. saut.
  • Signification : optimisez le code en divisant le code en plusieurs parties.
  • EIP 5450：
  • 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 ainsi de suite.
  • Contenu : Ajout d'un autre contrôle de validité pour les contrats EOF, cette fois autour de la pile. Cet EIP empêche les situations où le déploiement du contrat EOF peut provoquer un débordement ou un débordement de pile (pile débordements/débordements). 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. * Importance : une grande amélioration 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é.

5mois26****************************** ****************************************************** ****************************************** 4844 Le changement de type de transaction connexe de SSZ à RLP signifie qu'il n'est pas nécessaire d'avoir les deux a de Cancun SSZ EIP**, doncEIP 6475 et 6493** sont déplacés hors de Cancun pour mise à niveau***

EIP 6475X

  • Présentation : EIP Proposition complémentaire au 4844. 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 Executive Layer Core, il y a eu une discussion sur l'EIP La discussion sur le format de sérialisation SSZ pour 4844 a montré qu'au départ, les développeurs étaient favorables à l'introduction d'une première itération du format SSZ à EL via des transactions blob, et finalement les développeurs prévoyaient de mettre à niveau tous les types de transactions de RLP à SSZ, mais étant donné son chemin peu clair et certainement non implémenté sur la mise à niveau de Cancun, les développeurs ont envisagé de supprimer SSZ de l'EIP-4844. Après de longues discussions, les développeurs ont convenu de supprimer SSZ de l'implémentation EL de EIP-4844, ** mais il n'y a pas de suppression de **** EIP **** 6475 ****. **SSZ-> Les changements RLP ** signifieront que les deux ** SSZ à Cancún ne seront plus nécessaires EIP : ** Donc EIP 6475 et 6493 seront déplacés hors de Cancun pour des mises à niveau. **

EIP 6493X

  • 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 : SSZ changements
  • Présentation : Simple SerialiZe, est la méthode de sérialisation utilisée sur la chaîne de balises.
  • SS Les changements incluent également trois autres propositions de soutien, cette fois seulement 6465 a été introduit.
  • EIP 6465 : Racine de retrait SSZ, définit Merkle-Patricia existante Migration des engagements de Trie (MPT) vers les retraits de sérialisation simple (SSZ) ;
  • EIP 6404 / EIP 6466：
  • Les deux définissent une Merkle-Patricia existante Les promesses Trie (MPT) sont en cours de migration vers la sérialisation simple (SSZ).
  • EIP-6404 — Racine de transaction SSZ
  • EIP-6466 — Base de réception SSZ

Tim Beiko** a suggéré des développements futurs autour de l'expansion de Cancun lors d'une réunion de développeurs principaux le 5mois26*** Les conversations sont limité aux cinq EIP suivants :EIP 5920,5656,7069,4788 et 2537, des propositions de suivi seront générées dans ce cadre. SuiviEIP 5656*** etEIP 4788 a été confirmé comme proposition de mise à niveau officielle,5920,7069 et2537 *****supprimé là oùEIP 5920***** est dû à l'inquiétude du développeur concernant les effets secondaires potentiels de la manière de transférer ETH*, ainsi que le travail de raisonnement, de test et de sécurité inachevé, donc à partir de la mise à niveau retirer. ***

EIP 5920**：**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 présente plusieurs problèmes :
  • Premièrement, cela ouvre un vecteur pour les attaques de réentrance, puisque le récepteur peut rappeler l'expéditeur ;
  • Deuxièmement, il ouvre un vecteur DoS, donc 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, en faisant éventuellement d'autres opérations involontaires.
  • Changement:
  • Un nouvel opcode est introduit : ( PAY) PAY_OPCODE où :
  • Extrayez deux valeurs de la pile : addrtpuis val.
  • 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'éther à une adresse sans l'appeler.
  • Signification : économiser gaz**. ** *Mise à jour : 09.06.23 PAY a été supprimé de la mise à niveau en raison de préoccupations concernant les effets secondaires potentiels de 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.

EIP 7069X

  • Introduction : Instruction CALL modifiée
  • CHANGÉ : 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 dispose d'essence restante pour effectuer des changements d'état après le retour de l'appelé ;
  • Avant l'introduction des règles 63/64, un calcul légèrement plus précis du gaz disponible de l'appelant était requis. 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.
  • **Introduction actuelle **63/64e Règles :
  • Inspection de profondeur d'appel supprimée ;
  • Assurez-vous de réserver au moins 5000 gaz avant d'exécuter le comportement appelé ;
  • Assurez-vous qu'il y a au moins 2300 gaz disponibles pour le comportement appelé.
  • Règles de subvention : comme la subvention bien connue de 2300, lorsqu'un contrat appelle un autre contrat, le contrat appelé recevra 2300 le gaz est utilisé pour effectuer des opérations très limitées (assez pour faire un petit calcul et générer un journal, mais pas assez pour remplir un emplacement de stockage), et comme il définit une quantité fixe de gaz, il n'y a aucun moyen pour les gens de les déterminer comme tant que le prix du gaz peut être ajusté Quel type de calculs le gaz peut-il supporter ?
  • Importance : ** ouvre la voie à l'introduction de ** ** EOF ** ** à l'avenir, et il est plus pratique pour l'exploitation de grands contrats. **
  • Suppression de l'option gaz : les nouvelles directives ne permettent pas de spécifier le gaz limiter, mais s'appuyer sur la "règle 63/64" (se référant principalement à la retarification du gaz pour un grand nombre d'opérations IO dans EIP-150, ce qui augmente la consommation de gaz d'opérations spécifiques) pour limiter le gaz. Cette amélioration importante simplifie le processus autour de la règle "Allocation", peu importe si la valeur est envoyée ou non, l'appelant n'a pas besoin d'effectuer des calculs liés au gaz ;
  • Après avoir introduit la nouvelle proposition, les utilisateurs peuvent toujours surmonter Out en envoyant plus de gaz dans la transaction (bien sûr, sous réserve de la limite de gaz du bloc) d'erreur de gaz.
  • Auparavant, lors de l'augmentation des coûts de stockage (par exemple, EIP-1884 augmentait le gaz pour certains opcodes), certains contrats qui n'envoyaient qu'une quantité limitée de gaz à leurs appels étaient rompus par le nouveau mécanisme de tarification. 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é des gaz, EOF les exigera à la place des instructions existantes ;
  • Codes de retour d'état plus pratiques : des fonctions pratiques ont été introduites qui renvoient des codes d'état plus détaillés : succès (0), restauration (1), échec (2) et peuvent être étendues à l'avenir.

EIP 2537**：**X

  • Introduction : Précompilation de la manipulation de courbe BLS12-381.
  • Changé : ajout d'opérations sur la courbe BLS12-381 telles que précompilées à l'ensemble requis pour effectuer efficacement la vérification de la signature BLS et effectuer les opérations de vérification SNARK, etc.
  • Importance : ** Ethereum peut créer des preuves cryptographiques plus sécurisées et permettre une meilleure interopérabilité avec la chaîne de balises ****. **

RP 3175 *** Mentionné mais pas présélectionné, pas de discussion supplémentaire ***

PR 3175**：**X

  • Brève : 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, PR 3175 est en train d'être formaté en tant qu'EIP et sera changé en EIP-6987, qui est pour des raisons de sécurité pour empêcher les validateurs barrés d'être élus comme proposants de blocs.

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 de la capacité, la sécurité, l'économie 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 de 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 l'opside 50 % du coût du rollup ; 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 la DA chutera à 5 % de l'original ; Topia prévoit de réduire le coût par 100 ~ 1000 fois.

2.** Surclassement à Cancún Dans les 2~5 années à venir de Danksharding**, c'est la période dorée de développement des projets de couches DA****

  • Couche La limite supérieure de sécurité de 2 dépend de la couche DA qu'elle adopte. Le proto-Danksharding bénéficiera au protocole de stockage, au protocole modulaire et au réseau d'extension de stockage L1 grâce à un stockage de données d'état moins cher.
  • **Premièrement, **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 stockage de toutes les données historiques pour toujours. Le but est plutôt de fournir un tableau d'affichage en temps réel hautement sécurisé et laisser de la place pour d'autres protocoles décentralisés pour effectuer un stockage à plus long terme. ）；
  • **Deuxièmement, **Danksharding **réduit le coût de **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 publier les données du rollup vers la chaîne principale Ethereum, et les frais de gaz pour appeler ce code étaient très chers, ce qui est la couche Le plus gros paiement de 2, l'EIP 4844 introduit le blob de données en tant qu'espace de données supplémentaire unique pour les cumuls, ce qui 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 les ** TPS ** améliorés et réduits ** gaz ** sont encore limités, donc c'est bon pour ** DA * * projets de couches en développement continu ultérieur : **
  • responsable du danksharding en polynie Dans l'article sur le partage des données de sécurité, il est indiqué qu'il faudra 2 à 5 ans pour le mettre en œuvre ;
  • ** Même s'il atterrit, il peut augmenter ** TPS ** et réduire ** gaz ** les magnitudes sont encore limitées :**
  • EIP 4844 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, soit environ 100 fois plus. À l'heure actuelle, le TPS d'Ethereum est d'environ 15. 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, beaucoup de temps pour atterrir + Des changements réels limités bénéficieront DA Projets de couches, certains tels que Celestia, ** Eigenda ** ** ** ** DA ** ** le projet peut encore passer moins cher et plus rapidement ** ** TPS ** ** pour concurrencer ** ** Danksharding ** ** à l'avenir , ** Stockage ETH Topia*** et d'autres nouveaux projets DA peuvent également combler le vide du marché avant l'atterrissage. ** * 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, le réseau de portail Ethereum (actuellement 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 du protocole de stockage, du protocole modulaire et du réseau d'extension de stockage L1 :
  • La demande d'appel de données historiques conduira à un nouveau canal 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 un 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 ;
  • Bon réseau d'extension de stockage L1, tel que Eth stockage, qui peut fournir une solution de second niveau pour le stockage programmable à un coût de stockage inférieur.

3.** Avantages du surclassement à Cancún **** L2 **** diversité, **** L3 **, **** RAAS **** et Disponibilité des données et autres pistes

  • Analyse de la piste L2 :
  • Head Layer2, comme Arbitrum Orbite、OP Pile、Polygon2.0、Fractale 5 projets dont Scaling (sous StarkWare) et HyperChain (sous zkSync) en bénéficieront. La réduction des frais de stockage apportée par blob rendra la série précédente de couche restreinte 2 Le coût du développement et les problèmes d'évolutivité ont été considérablement améliorés et le débit de données a été considérablement amélioré. Après avoir résolu le problème de coût, la couche principale 2 Il sera possible de continuer à déployer une écologie L3 simultanée multi-chaînes hautement personnalisée pour des fonctions spécifiques ;
  • L'écart des coûts d'exploitation entre Layer2 de deuxième niveau et Layer2 principal sera réduit, donnant à 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 Cario de Starkware, les langages de la série Move, les langages de la série C, c++, C# et Go supportés par Wasm, qui peuvent présenter Plus de développeurs web2.
  • 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 de ** 5 ** têtes ** layer2 **, l'émergence de divers nouveaux ** DA **, de nouveaux projets peuvent-ils constituer un Nous devons mettre un point d'interrogation sur la piste. **
  • Tout d'abord, la couche d'en-tête 2 L'avantage du déploiement de la chaîne applicative réside dans l'intégrité du framework réseau et la sécurité de l'écologie entre les 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. Compte tenu des progrès réels du RAAS, des formulaires techniques et les avantages écologiques de la couche 3 à l'avenir, la demande réelle de RAAS est douteuse.
  • Département OP : Bien que OP mise à niveau du substrat rocheux de la pile + Le lancement du 4844 a entraîné une légère augmentation des coûts et de l'efficacité, mais l'augmentation n'est pas très attrayante ;
  • 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. Mais le ZK actuellement sur le marché La plupart des RAAS utilisent encore des projets phares (tels que ZkSync) pour bifurquer la chaîne, et les barrières ne sont toujours pas solides.
  • SO, court terme OP RAAS** **Il y a encore de la place pour le développement avant que ** layer3 ** débarque. À long terme, ** ZK RAAS ** et ** layer3 ** pourraient être la tendance future. **
  • ZK RAAS 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 d'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 défi 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

  • Cancun met à jour la deuxième proposition importante SELFDESTRUCT la suppression améliorera encore la sécurité d'Ethereum. Dans le même temps, pour les éventuels problèmes de mise à jour de compte programmatique après la suppression, nous prévoyons d'introduire un nouveau code d'opération SETCODE pour améliorer cette situation ;
  • Troisième proposition EIP pour la mise à niveau de Cancun 1153 ajoute un code d'opération de stockage transitoire, qui peut 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, telle que l'arbre Verkle, qui n'aura pas besoin de prendre en compte le problème de remboursement des transitoires stockage;
  • Quatrième proposition EIP pour la mise à niveau de Cancun 5656 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 mise à niveau de Cancun est EIP 4788 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 promesses, les protocoles de pontage et de reprise ;
  • Cancún met à niveau les dernières mises à niveau EIP centrées sur le CL proposées (15 et 23 juin) : EIP 6988、EIP 7044、EIP 7045, qui améliore la sécurité et la convivialité d'Ethereum dans les détails, comme l'amélioration de l'expérience des donateurs et l'amélioration de la sécurité du réseau.
  • Parmi les propositions supprimées, SSZ-> La transformation du RLP rend les deux SSZ EIP（EIP 6475 et EIP
  1. a été supprimée de la mise à niveau de Cancun ; les propositions liées à EOF ont été supprimées de la mise à niveau de Cancun après avoir été supprimées de la mise à niveau de Shanghai, et on considère actuellement qu'elles peuvent être directement implémentées dans la mise à niveau quotidienne ultérieure ; EVMMAX est dû à certains EIP lié au sous-ensemble de mise en œuvre de l'EOF, il a donc également été déplacé hors de Cancún pour être mis à niveau avec l'EOF ; compte tenu des effets secondaires potentiels qui peuvent exister dans la manière de transférer l'ETH, ainsi que du raisonnement, des tests et des travaux de sécurité nécessaires pour réussir la proposition , PEI 5920 supprimé de la mise à niveau.

**5. **Relation avec zkml et abstraction de compte

Peu d'effet sur zkml

  • ZKML est une preuve de connaissance zéro (zéro connaissances) et l'apprentissage automatique (Machine Learning ); la combinaison de **blockchain et ML modèle 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 la machine pour la formation, la confidentialité des informations personnelles est une exigence majeure ; ou les paramètres du modèle sont au cœur de la compétitivité du projet, et le cryptage est également nécessaire pour maintenir les barrières à la concurrence . Lorsque des problèmes de confiance tels que ceux-ci existent, les modèles ML sont 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 ** n'ont pas grand-chose à voir avec ** DA ** : **Besoin de quelque chose comme Espace La technologie de base de cette structure de stockage séparée est le nouveau protocole de sécurité "SQL proof". En termes simples, il s'agit d'un entrepôt de données à côté de la blockchain, permettant aux développeurs de se connecter en chaîne et hors chaîne dans un format SQL simple. charger les résultats directement dans le contrat intelligent ;
  • ZK-SNARKs **est la forme principale de ** ZK ** dans ** ZKML **, et peut s'adapter au calcul en chaîne de ** **ML ** ** Avec le développement de la cryptographie, en particulier le récursif **SNARK la preuve sera bénéfique ZKML Atterrissage 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 que d'effectuer une petite quantité de calculs pour vérifier sa validité. Ce type de preuve n'a besoin que d'une seule fois La nature de l'interaction entre le vérificateur et le vérificateur rend les ZK-SNARK efficaces et pratiques dans les applications pratiques, et est plus adapté aux exigences de puissance de calcul de ML sur la chaîne.
  • ** 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). Les ZK-SNARK ne prennent en charge que la preuve de connaissance zéro ML avec une petite échelle 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 d'off- calculs en chaîne.

** Bonne abstraction de compte **

  • ** Tout d'abord, la mise à niveau de Cancun peut réduire dans une certaine mesure ** ** ZK cumul** Preuve de frais :
  • 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 des preuves SNARK et les 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 le 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 peut être réduit dans une certaine mesure.Bien que ce ne soit pas beaucoup par rapport au coût de génération des preuves, étant donné que ZK en est encore à ses débuts, la tendance de développement future de la série ZK ne doit pas être sous-estimée.
  • Deuxièmement, l'abstraction de compte transforme les transactions ** tx ** traditionnelles en ** useroperation, puis ** useroperations use *ECDSA * * * Emballé en blocs, le stockage sur la chaîne occupe plus qu'avant, donc les besoins de stockage sont plus élevés ; **
  • **Ensuite, abstraction de compte et ** ZK rollup peuvent se compléter :
  • Le problème actuel d'abstraction de compte est le gaz Les frais sont chers, car il y a trop d'étapes et des contrats intelligents sont impliqués, donc il y a beaucoup de données, ce qui conduit à Gas Les frais sont chers, et ZK L'avantage de Rollup est qu'il peut réduire les données ;
  • L'abstraction de compte rend la sécurité difficile à garantir : étant donné que AA implique plusieurs contrats, la sécurité est un problème, mais après la formation progressive de L2 à l'avenir, la couche de consensus ne sera pas modifiée, les contrats intelligents auront plus d'utilisations et la sécurité de l'abstraction de compte peut également être garantie, avec l'aide de ZK La vérification fiable du cumul améliorera encore la sécurité.
  • **Enfin, compte tenu de l'essor de la technologie ** **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 ;
  • IA et optimisation des activités sur la 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 ira de l'expansion de l'espace de stockage à l'intégration avec le ** ZK La complémentarité du rollup ** et la combinaison avec la technologie ** AI ** bénéficieront progressivement au développement futur de l'abstraction de compte. **

**6.**En revenant sur la feuille de route d'Ethereum, quelle est la prochaine étape

  • **Actuellement, **Layer2 ** n'a pas de performances (en termes de latence et de débit) similaires à ** Solana **, ni à ** Near ** Tel performances de partitionnement et aucune performance d'exécution parallèle comme ** Sui ** et ** Aptos **, la mise à niveau de Cancun a amélioré la position de leader d'Ethereum en tant que leader ; **
  • Après la mise à niveau de Cancun, plusieurs temps de développement majeurs sont estimés Fully-Danksharding** (2~5 ans), *MEV * et ** PBS atterrissage (1~3 ans), abstraction de compte (1~2 ans), ***ZK * * *Tout (3~6 ans), EOF et expérience de développeur (combien de fois avez-vous vu l'extension ?). **

Le Fléau

  • Objectif : se concentrer sur la résolution des problèmes MEV. * Solution : Minimiser le MEV au niveau de la couche d'application grâce à la "séparation proposant-constructeur (PBS)". À ce stade, les blobs peuvent être optimisés et des services de pré-confirmation ou des protections de préemption peuvent être introduits.
  • PBS est la séparation des producteurs 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 les problèmes de MEV, ce qui est l'idée de l'externalisation du MEV.
  • Le degré d'achèvement du PBS est encore très faible, et les plus matures sont Collaboration avec des solutions MEV externes - mevboost par flashbots.
  • Version avancée de "Enshrined La séparation proposant-constructeur (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 Le relais, qui améliore la flexibilité et l'adaptabilité du cadre PBS

Le Bord

  • Objectif : utiliser l'arbre 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 légère 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 pour les changements d'état consensuels ; Enchâssé Cumuls。
  • 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 juste le chemin lui-même comme preuve Partie de Verkle les preuves sont 3 fois plus efficaces que les preuves de Merkle.
  • Enchâssé Le cumul 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.

Le purge

  • Le La purge 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 servir au niveau P2P.
  • Etat dormant. 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 un bloc, mais pas de le vérifier ; L'état auquel on accède. L'hibernation d'état devrait réduire l'état qu'un nœud doit stocker d'un total de 20 à 50 Go。
  • Dans la cinquième étape Purge, EIP 4444 est explicitement écrit dans la feuille de route, EIP-4444 oblige le client à effacer les données de plus d'un an, et à ce stade, il reste encore du travail d'optimisation EVM, comme la simplification du mécanisme de précompilation GAS et EVM, etc. ;

Le Faire des folies

  • Dans la sixième étape finale Splurge, EIP 4337 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 l'essence, les portefeuilles de récupération sociale, etc. ;

Matériel de référence:

  • Mise à jour de la réunion de développement du noyau Ethereum :
  • Éthereum Tous les développeurs de base appellent # 148 Rédaction
  • Éthereum Rédaction de l'appel n° 149 pour tous les développeurs principaux
  • Éthereum Appel de la couche de consensus # 99 Rédaction
  • Éthereum Tous les développeurs principaux appellent # 150 Rédaction
  • Éthereum Tous les développeurs principaux appellent # 151 Rédaction
  • Éthereum Appel de la couche de consensus #100 Rédaction
  • Éthereum Appel à tous les développeurs de base n° 152 Rédaction
  • Éthereum Appel à tous les développeurs de base n° 153 Rédaction
  • Éthereum Discussion sur le forum des magiciens originaux :
  • Éthereum Appel à tous les développeurs de base n° 156 Rédaction
  • Éthereum Appel à tous les développeurs de base n° 157 Rédaction
  • Éthereum Appel à tous les développeurs de base n° 158 Rédaction
  • Éthereum Appel à tous les développeurs de base n° 159 Rédaction
  • Éthereum Appel à tous les développeurs de base n° 160 Rédaction
  • Éthereum Appel à consensus de tous les développeurs principaux #108 Rédaction
  • Éthereum Appel à tous les développeurs de base n° 161 Rédaction
  • Éthereum Appel à consensus de tous les développeurs principaux #109 Rédaction
  • Éthereum Appel à tous les développeurs de base n° 162 Rédaction
  • Éthereum Appel à consensus de tous les développeurs principaux #110 Rédaction *Tim a tweeté à propos de la dernière mise à jour d'Ethereum Cancun (09.06.23) :
  • Ethereum All Core Developers Consensus Call #111 Rédaction
  • Éthereum Appel à consensus de tous les développeurs principaux #112 Rédaction
  • Contenu lié à la mise à niveau d'Ethereum :
  • Introduction au code d'autodestruction :
  • Explorez la proposition EVMMAX et BLS12-381
  • Outre EIP-4844, qu'est-ce que la mise à niveau de Cancun comprendra d'autre ? Un aperçu du dernier appel de consensus d'Ethereum
  • Quel nouveau contenu a été ajouté dans la mise à jour d'Ethereum Shanghai ?
  • tweets :
  • D'ACCORD Ventures : après la mise à niveau d'Ethereum Shanghai, Cancun améliore les opportunités d'investissement potentielles - Nouvelles prospectives
  • En plus de l'EIP-4844 très médiatisé, quelles propositions la mise à niveau de Cancun comprendra-t-elle ?
  • V God : Fonction EVM à considérer pour suppression
  • Proto-Danksharding FAQ
  • Recommandé par V God 丨 Compréhension approfondie de la feuille de route de partage d'Ethereum, la lecture de ce rapport suffit
  • Un article pour comprendre Danksharding, le nouveau plan de mise à jour d'Ethereum
  • Déchiffrez des faits intéressants et des secrets cachés dans la dernière feuille de route d'Ethereum
  • Vitalik : Pourquoi SELFDESTRUCT fait plus de mal que de bien à l'écologie d'Ethereum
  • Vision Ethereum :
  • Blocages Chercheur Brrr : comment le proto-danksharding accélère la L1 d'Ethereum Évolutivité du cumul
  • La 111e réunion Ethereum ACDC : discuter de la portée finale de la mise à niveau de Deneb et de trois propositions, y compris EIP-7044
  • COL Le regard de Stacy Muur sur l'évolution des solutions de mise à l'échelle d'Ethereum : OP Pile、Arbitraire Orbite、Polygone 2.0
  • Comparaison horizontale de trois types de Rollups : Rollups classiques (Optimistic/ZK Rollups）、Enchâssé Cumuls、Souverain Cumuls
  • [AMA] Nous sommes EF Research (Pt. 8 : 07 juillet, 2022)：
  • 3 morceaux populaires à repenser en 2023
  • Monténégro EDCON Réflexions sur la fin de 2023 : un regard sur les tendances en matière d'infrastructure et d'applications
  • Fantaisie infinie de la possibilité de combiner IA et Web3
  • AI+Web3 : Exploration de l'intégration de l'intelligence artificielle et de la blockchain
  • Comparer zk-rollup et op-rollup : analyser pourquoi le zkSync actuel de la méthode de vérification Les frais de gaz sont élevés
  • "Ajouter des volumes aux volumes" : les solutions d'abstraction de compte à l'ère du Rollup
  • Interprétation approfondie de ZKML : principes techniques, scénarios d'application, avantages et défis
  • ZKML : une technologie de déploiement de modèle qui intègre l'IA et la blockchain pour assurer la protection de la vie privée
  • fiable données de sécurité partitionnement
  • Dialogue avec Qi, fondateur d'EthStorage Zhou | Disponibilité des données et stockage décentralisé
  • Lisez la dernière version de la feuille de route de développement d'Ethereum dans un article
  • À propos de l'espace et Une brève introduction au temps
  • Proposition originale :
  • EIP 4844：
  • EIP 6780：
  • EIP 1153：
  • EIP 5920：
  • EIP 5656：
  • EIP 7069：
  • EIP 4788：
  • EIP 2537：
  • EVMMAX EIP：
  • EIP 6601：
  • EIP 6990： * EOF changements:
  • EIP 663：
  • EIP 3540：
  • EIP 3670：
  • EIP 4200：
  • EIP 4750：
  • EIP 5450：
  • EIP 6475：
  • EIP 6493：
  • RP 3175：
Voir l'original
Le contenu est fourni à titre de référence uniquement, il ne s'agit pas d'une sollicitation ou d'une offre. Aucun conseil en investissement, fiscalité ou juridique n'est fourni. Consultez l'Avertissement pour plus de détails sur les risques.
  • Récompense
  • Commentaire
  • Partager
Commentaire
0/400
Aucun commentaire
  • Épingler
plan du site
Trader les cryptos partout et à tout moment
qrCode
Scan pour télécharger Gate.io app
Communauté
Français (Afrique)
  • 简体中文
  • English
  • Tiếng Việt
  • 繁體中文
  • Español
  • Русский
  • Français (Afrique)
  • Português (Portugal)
  • ไทย
  • Indonesia
  • 日本語
  • بالعربية
  • Українська
  • Português (Brasil)
    • À propos de nousCarrièresPartenairesConsulter les clauses contractuellesAvertissement Consulter les clauses contractuelles et notre Politique de confidentialitéCookie PolicyKit médiaPreuve de réserve à 100 %LicenseSécuritéPrivilèges utilisateur GTGate ChainCalendrierApplication de la loiSommetsGate Ventures
    AcheterVendreSpot TradingTrading FuturesTokens à effet de levierStartupNFTGate PayGate LifeGift CardGate OTCGate CharityGate CardBoutique Gate
    Avantages VIPCommentaires des utilisateursAnnoncesFraisAideEnvoyer une demandeListingVérifiez la sécurité d'un smart contractDéveloppeursRecherche de vérificationApplication pour les marchands P2PApplication Blue V P2PProgramme d'affiliation
    Gate LearnCours cryptoGlossaire des cryptomonnaiesCours des cryptomonnaiesBig DataHalving du Bitcoin
    Gate.io © 2013-2025.