Titre original : "Mise à jour 014 de la réunion des développeurs Ethereum Core"
Source originale : mise à jour AllCoreDevs
Auteur original : Tim Beiko
Compilation originale : Ethereum.cn
Bienvenue dans une nouvelle édition de la mise à jour AllCoreDevs (Ethereum Core Developer Conference) – la dernière de 2022.
aperçu
Le contenu de l'upgrade Shanghai/Capella a été finalisé : retraits, EOF et quelques modifications mineures... à condition de ne pas retarder les retraits.
L'espace Blob arrive : EIP-4844 sera au centre de la prochaine mise à niveau d'Ethereum, et sa cérémonie d'invocation commencera bientôt.
Sur le plan technique, des efforts sont en cours pour coordonner les processus de mise à niveau de la couche d'exécution et de la couche de consensus. Nous assistons également à des discussions actives sur une meilleure intégration de la contribution de la communauté dans le processus.
La Protocol Guild a publié un rapport pilote à mi-parcours et un plan approximatif visant à augmenter la taille des responsables de premier niveau et à mieux les soutenir en 2023.
Mise à niveau de Shanghai/Capella
Lors d'un récent AllCoreDevs, l'équipe client est parvenue à un consensus sur la portée finale de la mise à niveau de Shanghai/Capella. Bien que le nom de la mise à niveau puisse faire l’objet d’un débat, l’équipe est claire sur sa portée. La principale caractéristique de la mise à niveau est l'introduction des retraits Beacon Chain pour les joueurs. L'équipe client ne veut pas faire de compromis sur le déploiement de cette fonctionnalité le plus rapidement possible. Les autres fonctionnalités de la mise à niveau doivent donc être prêtes en même temps, sinon elles risquent d'être abandonnées.
La spécification de la couche exécutive de Shanghai répertorie tous les EIP inclus :
EIP-3540 : Format d'objet EVM (EOF) v1
EIP-3651 : Réduisez le coût du gaz pour accéder aux adresses COINBASE
EIP-3670 : EOF – Vérification du code
EIP-3855 : ajout de l'opcode PUSH 0
EIP-3860 : Limiter la taille du code d'initialisation et introduire le comptage de gaz
EIP-4200 : EOF - saut relatif statique
EIP-4750 : EOF – Fonctions d'importation
EIP-4895 : Retraits poussés de la chaîne de balises en tant que fonctionnement du système
EIP-5450 : EOF – Vérification de la pile
Bien que la liste soit longue, elle peut être divisée en trois parties différentes : améliorations mineures, formats d'objet EVM et retraits. Ensuite, nous les présenterons un par un :
Améliorations mineures
EIP-3651 : Warm COINBASE (réduit le coût du gaz pour accéder aux adresses COINBASE)
Cet EIP corrige un oubli dans EIP-2929 où le coût du gaz pour accéder à certains champs de données était modifié selon que les données étaient déjà dans la mémoire client (WARM) ou devaient être récupérées à partir du disque (COLD).
EIP-2929 définit deux éléments de données dans la mémoire client sur WARM au début de chaque transaction : l'adresse d'envoi et l'adresse de réception. EIP-3651 ajoute une troisième adresse à cette liste, l'adresse COINBASE (c'est-à-dire feeRecipient), puisque c'est également l'adresse que le client a en mémoire lors du traitement des transactions de bloc.
EIP-3855 : instruction PUSH 0 (nouvel opcode `PUSH 0)
Comme son nom l'indique, EIP-3855 introduit un opcode qui pousse une valeur de 0 sur la pile. Pousser des 0 est souvent utilisé pour remplir des valeurs dans l'EVM, cet opcode fournira un moyen plus efficace et moins cher de le faire.
EIP-3860 : Limiter et mesurer le code d'initialisation (limiter la taille du code d'initialisation et introduire le comptage de gaz)
Cet EIP ajoute un plafond à la taille du code d'initialisation et introduit un comptage de gaz en fonction de sa longueur. Sa limite supérieure de taille ajoute un invariant à l'EVM, le rendant plus facile à comprendre et à proposer des modifications.
Introduit une surcharge de 2 gaz par 32 octets pour le code d'initialisation, qui est utilisée pour payer l'analyse la plus rapide que le client doit effectuer avant l'exécution, qui n'est pas répertoriée dans le compteur de gaz.
format d'objet
La plupart des EIP inclus dans la mise à niveau de Shanghai font en fait partie d'une seule fonctionnalité : le format d'objet EVM (EOF). Le travail a été divisé en 5 EIP différents pour aider les développeurs clients à comprendre chaque modification individuelle, mais pour fournir une vue d'ensemble de plus haut niveau, les développeurs ont publié une spécification unifiée. Les EIP de ces cinq EOF sont :
EIP-3540 : format d'objet EVM version 1
EIP-3670 : EOF – Vérification du code
EIP-4200 : EOF - saut relatif statique
EIP-4750 : EOF – Fonctions d'importation
EIP-5450 : EOF – Vérification de la pile
Il convient de noter que la première étape d'EOF a été la mise à niveau de Londres EIP-3541, qui réservait le préfixe 0xEF 00 pour le contrat EOF. La portée EOF de la mise à niveau de Shanghai a également changé au cours des derniers mois.
En février, l'équipe client a accepté d'envisager une mise à niveau à Shanghai pour inclure les deux plus petits EIP EOF : EIP 3540 et 3670. Ils serviront tous de blocs de construction, mais ne fourniront pas toutes les fonctionnalités sans l'introduction des EIP 4200, 4750 et 5450. Bien qu'il soit possible d'étendre EOF, une incompatibilité descendante peut nécessiter une nouvelle version. Étant donné que les contrats pré-EOF ou EOF avec une version spécifique doivent toujours être exécutables, chaque nouvelle version d'EOF signifie que les développeurs clients doivent maintenir un nouvel ensemble de règles d'exécution EVM en parallèle avec les anciennes règles.
Avant EOF, les clients ne conservaient qu'un seul ensemble de règles EVM à la fois. La base de code prend également en charge les règles EVM précédentes, qui sont modifiées à chaque mise à niveau du réseau, mais une fois qu'elles atteignent la tête de la blockchain, seules les dernières règles doivent être appliquées. Après le déploiement d'EOF, le client conservera deux ensembles parallèles de règles EVM, afin de pouvoir exécuter du code dans des contrats EOF et non-EOF. En d’autres termes, l’augmentation des versions d’EOF augmente le nombre d’ensembles de règles EVM parallèles plutôt que consécutifs qui doivent être maintenus.
Dans ce sens, depuis quelques mois, les équipes clients ont commencé à privilégier une approche « big EOF ». De cette façon, même s'ils doivent implémenter des ensembles de modifications plus importants, la version EOF durera plus longtemps et réduira le nombre d'« EVM parallèles » qui doivent être maintenus. Par conséquent, les développeurs ont considéré un « gros EOF » et l'ont finalement inclus dans la mise à niveau de Shanghai.
Cela dit, les fonctionnalités plus volumineuses sont évidemment plus difficiles à mettre en œuvre et à tester, et l’équipe ne souhaite pas voir EOF retarder considérablement le retrait des chaînes de balises. Par conséquent, si la mise en œuvre d'EOF n'est pas terminée d'ici janvier et qu'ils ne peuvent pas interopérer rapidement les uns avec les autres, l'équipe client accepte de déplacer EOF hors de Shanghai pour la mise à niveau.
En gardant ces contextes à l’esprit, présentons maintenant brièvement chaque EIP EOF :
EIP-3540 : Format d'objet EVM (EOF) v1 (Format d'objet EVM version 1)
Cet EIP introduit le « conteneur » dans le contrat EOF. Il ajoute des balises pour distinguer les parties code et données du contrat et empêche le déploiement de contrats EOF non conformes au format. Cela garantit que tout contrat EOF sur la chaîne suivra un format valide, ce qui simplifie l'interaction avec ces contrats, ainsi que leur analyse statique.
EIP-3670 : EOF - Validation du code (EOF - Validation du code)
S'appuyant 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. Si un nouvel opcode est ajouté, les règles de validation peuvent simplement être modifiées pour l'activer et garantir qu'aucun contrat EOF déployé ne le référence dans sa section de code.
EIP-4200 : EOF - Sauts relatifs statiques (EOF - Sauts relatifs statiques)
EIP-4200 introduit les premiers opcodes spécifiques à EOF : RJUMP, RJUMPI et RJUMPV, qui codent les destinations sous forme de valeurs immédiates signées. Ces nouveaux opcodes JUMP peuvent être utilisés par les compilateurs pour optimiser la surcharge de gaz, car ils éliminent le besoin d'analyse jumpdest à l'exécution, qui est requise par les opcodes JUMP et JUMPI existants.
EIP-4750 : EOF - Fonctions (fonctions introduites par EOF)
EIP-4750 va plus loin que 4200 : il interdit l'utilisation des opcodes JUMP & JUMPI et ajoute des alternatives pour les fonctions qui ne peuvent pas être copiées. Il est implémenté en introduisant des sections de fonctions spécifiques dans le bytecode EOF. Ces fonctions peuvent respectivement sauter des nouveaux opcodes JUMPF, CALLF et RETF, et les utiliser pour appeler et revenir.
EIP-5450 : EOF - Validation de la pile (EOF-Validation de la pile)
Enfin, EIP-5450 ajoute un autre contrôle de validation pour les contrats EOF, cette fois autour de la pile. Cet EIP empêche les contrats EOF de déployer du code susceptible de provoquer un débordement de pile et un débordement dans certains cas. Avec cet EIP, les clients peuvent réduire le nombre de contrôles de validation lors de l'exécution des contrats EOF car ils disposent de meilleures garanties concernant les exceptions liées à la pile.
En tant qu'expert non-EVM et très concentré sur l'EIP lui-même, je ne peux pas en dire grand-chose ! Si les lecteurs souhaitent en savoir plus sur EOF, je recommande les tweets pertinents publiés par lightclients de l'équipe Geth et Leo de l'équipe Solidity.
Retrait de la chaîne de balise
Enfin et surtout, la partie principale de « Shapella » (Note du traducteur : nom collectif de Shanghai/Capella) est le retrait de la chaîne de balise. Cette partie du changement est décrite dans la spécification de la couche consensus et dans l'EIP-4895. Il existe désormais une méta-spécification légèrement obsolète reliant ces modifications entre elles.
À un niveau élevé, les mécanismes de retrait sont les suivants :
Lorsqu'il propose un bloc, le validateur analyse linéairement l'index du validateur pour trouver les 16 premiers validateurs avec des informations d'identification 0x01, qui doivent remplir l'une des conditions suivantes :
Avoir un solde supérieur à 32 ETH (c'est-à-dire avoir accumulé des récompenses de validation)
Sont retirables (c'est-à-dire qu'ils ont complètement quitté l'ensemble des validateurs)
Le solde est supérieur à 32 ETH (c'est-à-dire que la récompense du validateur a été obtenue)
Il est retirable (retirable, c'est-à-dire qu'il a complètement quitté l'ensemble du validateur)
À partir de ceux-ci, le validateur créera une liste de retraits à inclure dans son ExecutionPayload. Chaque élément de cette liste contient les éléments suivants :
Le validateur créera une liste de retrait de ces validateurs et la conditionnera dans leur ExecutionPayload. Chaque élément de la liste contient les éléments suivants :
WithdrawalIndex : Index de toutes les transactions de retrait qui ont été effectuées - cela permet de distinguer les retraits du même montant à partir de la même adresse, du même validateur
ValidatorIndex : l'index du validateur où le solde a été augmenté
ExecutionAddress : l'adresse ETH de la couche d'exécution, à laquelle les retraits doivent être envoyés.
Montant : Le montant envoyé à ExecutionAddress, ce montant est mesuré en gwei (et non en wei)
Les clients de la couche d'exécution effectueront ces retraits après l'exécution des transactions lors de la construction ou du traitement des blocs. En d’autres termes, les retraits sont traités de la même manière que les récompenses de preuve de travail enregistrées, et ils n’entrent pas en concurrence avec les transactions des utilisateurs pour l’espace de bloc.
Il y a quelques autres détails à noter :
Lors du traitement des retraits, il n'y a aucune différence de priorité/ordre entre les « fonds complets » et les « fonds partiels ». Les retraits complets se produisent lorsqu'un validateur quitte l'équipe de sortie, tandis que les retraits partiels se produisent périodiquement, c'est-à-dire lorsqu'une analyse linéaire de l'ensemble des validateurs est effectuée et que le numéro d'index d'un certain validateur est analysé.
Pour que les retraits soient traités, les validateurs doivent utiliser des informations d'identification 0x01, qui sont représentées par des adresses ETH. Seules les informations d’identification de la paire de clés BLS 0x00 sont autorisées lorsque la chaîne de balises est mise en ligne. Afin d'initier un retrait, un validateur avec des informations d'identification 0x00 devra signer un message BLSToExecutionChange. Ceux-ci seront activés dans la mise à niveau Capella. Une variété d'outils seront utilisés pour signer ce message, et les validateurs peuvent s'attendre à une assistance et à des didacticiels pour ces outils.
L'analyse des validateurs se fait par bloc. S'il n'y a pas 16 retraits à traiter après avoir analysé un sous-ensemble de l'ensemble du validateur, le validateur arrêtera l'analyse et le validateur suivant démarrera à partir du dernier index du validateur analysé.
Comme d'habitude, il y aura plusieurs testnets et testnets de développeurs (peut-être même de nouveaux testnets !) pour que les validateurs puissent exécuter l'ensemble du processus et résoudre tous les problèmes avant la mise en ligne du réseau principal.
Shanghai/Capella n’est pas la seule mise à niveau à progresser ! L'équipe de développeurs attend toujours avec impatience la prochaine mise à niveau.
Surclassement à Cancún
Étant donné que le contenu de la mise à niveau de Shanghai est déjà complet, de nombreux EIP (CFI) envisagés pour la mise à niveau n'ont pas pu participer à la mise à niveau de Shanghai. L'équipe client commence à discuter des EIP qui devraient être pris en compte pour la prochaine mise à niveau : la mise à niveau de Cancun (nom de la couche de consensus à déterminer)
En termes de couche consensus, EIP-4844 est devenu le premier EIP inscrit dans la spécification après la mise à niveau de Capella. Il n'existe pas (encore) de spécification pour la couche exécutive pouvant implémenter cette disposition, mais l'équipe de la couche exécutive a accepté de suivre un chemin similaire et de centrer EIP-4844 sur la prochaine mise à niveau.
Suite à la convention des mises à niveau utilisant les noms des villes où Devcon a eu lieu, cancun.md a été créé, avec EIP-4844 officiellement inclus dans la mise à niveau.
Cette décision a été prise à la dernière minute de la dernière réunion AllCoreDevs de 2022, nous n'avons donc pas eu le temps de travailler sur d'autres propositions. Les EIP qui sont entrés dans la mise à niveau CFI à Shanghai mais n'ont finalement pas été inclus ont été déplacés vers la liste CFI pour la mise à niveau de Cancun. Un message a également été ouvert sur le forum Ethereum Magicians pour discuter des EIP candidats à Cancun. Les discussions sur l'ampleur des améliorations à Cancun devraient commencer sérieusement au début de l'année prochaine.
Cérémonie KZG
Une autre chose à espérer liée à la mise à niveau de Cancun est la cérémonie KZG, qui est une exigence de l'EIP-4844.
Ce rituel générera le caractère aléatoire nécessaire pour vérifier la validité des données blob. Pour que cela soit considéré comme sûr, un seul participant doit être honnête. En d’autres termes, si tous les participants sauf un sont de connivence, l’ensemble du processus est cryptographiquement sécurisé.
La cérémonie débute en janvier et sera ouverte à tous pendant plusieurs mois. Avec un objectif de 10 000 participants, elle devrait être la plus grande cérémonie du genre à ce jour ! Si vous voulez être sûr de ne rien manquer, suivez Trent Van Epps sur Twitter !
Processus de mise à niveau post-fusion
Comme mentionné dans la mise à jour précédente, après la fusion, la coordination du processus de mise à niveau d’Ethereum au niveau de la couche d’exécution et de la couche de consensus est une tâche importante. D'un point de vue de haut niveau, la couche d'exécution utilise Yellow Paper et EIP pour décrire les modifications, tandis que la couche consensus utilise des spécifications Python exécutables.
L’avantage du processus au niveau exécutif est que l’EIP est bien connu de la communauté et est formaté de manière à démontrer clairement le raisonnement derrière la proposition. Les livres jaunes avec beaucoup de contenu mathématique associés aux EIP, et la nécessité de replacer les spécifications dans le contexte de chaque EIP, rendent les spécifications de la couche d'exécution difficiles à comprendre et à étendre.
Le problème avec la couche consensus est à l'opposé : elle a une spécification claire et compréhensible dans un seul référentiel, mais les changements ne sont pas tangibles et les propositions sont enfouies dans d'autres PR publics du référentiel.
Avec l’introduction de la spécification de la couche d’exécution Ethereum, nous espérons réduire cet écart du côté de la couche d’exécution. Et, après quelques discussions de processus, nous pourrons peut-être introduire l'EIP dans le processus de la couche de consensus !
Cela dit, alors que la portée de la mise à niveau de Shanghai était discutée et finalisée, il est devenu clair qu'une autre partie du processus pourrait manquer : permettre à la communauté d'exprimer ses préférences relatives en matière de changements et d'engager des discussions sur la portée entière de la mise à niveau (plutôt que de EIP individuels) Discutez-en sur place et intégrez-le aux décisions des réunions AllCoreDevs et de la couche de consensus.
On ne sait pas encore à quoi cela ressemblera – j’aimerais avoir des suggestions ! – mais à mesure que le nombre de parties prenantes activement impliquées dans les changements de protocole augmentait, tout comme le nombre de zones affectées par les changements de couche 1, il était clair que nous avions besoin de quelque chose.
Heureusement, nous n’avons pas besoin de repartir de zéro. Ethereum Magicians existe depuis des années et ses rencontres hors ligne, ses réunions de groupe dédiées ou ses réunions communautaires peuvent être de bons points de départ pour son expansion.
Attendez-vous à davantage de progrès sur ce front début 2023 !
Mise à jour de la guilde des accords
Alors que le projet pilote de Protocol Guild (PG) est à mi-chemin, ils ont publié un rapport pour examiner comment les choses se déroulent et réfléchir aux prochaines étapes du projet.
Pour rappel, PG est un mécanisme de financement sans autorisation pour les développeurs de clients Ethereum Layer 1, les chercheurs de protocoles et les contributeurs de soutien (comme vous).
Ce mécanisme est centré sur l’individu et non sur l’organisation. En bref, chaque membre a droit à une part des jetons de la guilde, pondérée en fonction de la durée de sa contribution à Ethereum. L'ajout et la suppression de membres se font à la manière d'Ethereum, sur la base d'un ensemble de normes et d'un consensus approximatif au sein de PG. Cette liste sera ensuite mise en chaîne à l'aide du contrat fractionné 0xSplit. Le donateur peut ensuite envoyer des fonds directement à l'adresse du destinataire ou via un contrat d'acquisition qui libère les fonds à l'adresse du destinataire.
Le rapport intermédiaire pilote est résumé dans ce tweet. Voici quelques faits saillants
Le projet pilote a permis de récolter 9,7 millions de dollars auprès d'organisations telles que Lido, Uniswap, ENS, NounsDAO et MolochDAO, ainsi que de donateurs réguliers de particuliers (merci Tetranode !) - merci à tous ceux qui ont rendu cela possible !
PG comptait 90 membres au lancement et en compte désormais 128, avec 5 millions de dollars répartis entre eux
En moyenne, chaque membre a reçu 39 000 $, le plus bas étant de 13 000 $ et le plus élevé atteignant 79 000 $.
L'architecture de PG évolue et prendra en charge L2 et supprimera le besoin de multi-sig pour mettre à jour les pondérations.
Ces premiers résultats montrent que PG fonctionne comme prévu : un mécanisme permettant de distribuer un panier de jetons à un groupe croissant et auto-incubateur de contributeurs de protocole. Ce projet ne serait pas ce qu'il est aujourd'hui sans le généreux soutien de donateurs pilotes.
En regardant vers l’avenir, le moment est venu d’étendre la portée de PG et de réaliser tout son potentiel : offrir aux mainteneurs d’Ethereum une rémunération compétitive et ajustée au risque. La chose la plus simple à faire ici est que le projet fasse un don à PG dès le début, comme l'a dit Danny Ryan dans le tweet lançant PG.
La plupart des dons du projet pilote provenaient de grands projets bénéficiant de financements importants. Si la Protocol Guild parvient à convaincre ces projets de faire un don à PG dès le premier jour, alors que leurs jetons sont encore vraiment « sans valeur », alors les responsables d’Ethereum pourront bénéficier de toute la trajectoire ascendante de ces projets réussis.
Lorsqu’un nombre suffisant de projets sont impliqués, les incitations peuvent retenir les meilleurs talents dans les contrats de maintenance au lieu de les éloigner.
Pour prendre en charge ce type de don, ainsi que de nombreux autres types de dons, PG aura besoin d’une refonte technologique. La prochaine version prendra en charge L1 et L2 et réduira davantage son empreinte de gouvernance en chaîne.
Si vous êtes un projet qui souhaite faire un don à la Protocol Guild, veuillez me contacter – mes DM sont ouverts !
Suivi
Voilà qui conclut 2022... Quelle année extraordinaire ! Il y a trois mois, nous n’avions même pas fusionné ! Maintenant qu’Ethereum a une preuve de participation qui s’exécute tranquillement en arrière-plan, l’attention s’est déplacée vers les transactions futures.
Alors que tout le monde revient en janvier, vous pouvez vous attendre à :
Shanghai/Capella a mis à niveau le testnet et le shadow fork des développeurs
La cérémonie KZG est en ligne
Discussions autour de Cancun et comment le processus de mise à niveau du réseau devrait évoluer pour mieux prendre en compte les préférences de la communauté
Le projet pilote de guilde protocolaire se terminera et nous annoncerons la structure post-pilote.