jakiro
Dencun est composé de deux noms Deneb et Cancun, représentant la fourche dure entre la couche consensus Ethereum et la couche d’exécution.Le Dencun Hard Fork a été achevé sur les réseaux de test Goerli, Sepolia et Holesky, et le MainNet aura lieu sur Epoch 269568 (vers le 13 mars 2024).
Conseils de lecture
Avant de lire cet article, la première connaissance que vous devez savoir comprend:
-
Fourchette
-
Ethereum est divisé en une couche consensus et une couche d’exécution.
La mise à niveau Dencun contient 9 EIP, à savoir:
-
EIP-1153: Opcodes de stockage transitoires (modifications de la couche d’exécution)
-
EIP-4788: racine de bloc de balise dans l’EVM (couche d’exécution et modifications de la couche consensus)
-
EIP-4844: transactions Shard Blob (modification de la couche d’exécution et de la couche consensus)
-
EIP-5656: MCOPY – Instruction de copie de mémoire (modifications de la couche d’exécution)
-
EIP-6780: s’autodéstruire uniquement dans la même transaction
-
EIP-7044: sorties volontaires signées perpétuellement valides
-
EIP-7045: augmenter la fente d’inclusion d’attestation maximale (changements de couche consensus)
-
EIP-7514: Ajouter la limite de désabonnement de l’époque max (modifications de la couche consensus)
-
EIP-7516: OPCODE BLOBBASEFEE (Modifications de la couche d’exécution)
Cet article introduira les changements et les impacts de ces EIP (à l’exclusion de l’EIP-4844).
Le grand ajout de Rollup: proto-danksharding (i)
-
https://medium.com/taipei-ethereum-meetup/rollup-and-the-boost-from-proto-danksharding-85d2fe0566b6
Le grand ajout de Rollup: proto-danksharding (ii)
-
https://medium.com/taipei-ethereum-meetup/rollup-proto-danksharding-implementation-detail-913a3c61fde8
Ensuite, nous présenterons l’ordre à peu près divisé en « EIP lié aux modifications de la couche d’exécution », « EIP lié aux modifications de la couche consensus » et « EIP liés à EIP-4844 ».
EIP-1153
-
Modifications de la couche d’exécution
-
EIP-1153: Opcodes de stockage transitoires
-
https://eips.ethereum.org/eips/eip-1153
-
EIP-1153: page de fan
-
https://www.eip1153.com/
-
EIP-1153: Opcodes de stockage transitoires
-
https://ethereum-magicicican.org/t/eip-1153-transent-storage-opcodes/553
L’EIP-1153 a ajouté deux nouveaux OPCodes: TStore et Tload, qui sont utilisés pour écrire et lire des données de stockage « temporaires ».Ils économiseront beaucoup de coûts de gaz pour de nombreux développeurs contractuels.
arrière-plan
Le stockage fait référence au contrat intelligent d’écriture de données dans l’espace de stockage du contrat via le SSTORE OPCODE.La caractéristique « temporaire » est que par rapport à « l’existence permanente », les données écrites par TSTORE sont valides jusqu’à la fin de la transaction.
Détails de l’opération
TSTORE est beaucoup moins cher que SSTORE, et sa période de validité peut passer des appels entre différents contrats (jusqu’à la fin de la transaction). La mémoire du contrat B.Ceci est très utile pour de nombreuses utilisations:
-
Verrouillage de réentrance.Actuellement, le verrouillage de réentrance ne peut être simulé que avec SSTORE.
-
Utilisé dans ERC-20 approuve dans une seule transaction.Si le contrat A interagit avec le contrat B et que le contrat A doit transférer l’ERC-20 du contrat B, le contrat B approuvera d’abord ERC-20 pour contracter A avant d’appeler Contrat A.Parce que l’approbation de l’ERC-20 est tout au long de SSTORE, le coût n’est pas faible et passer à l’utilisation de TSTORE réduira considérablement le coût.
-
Paramètres de déploiement lors du déploiement des contrats via CREATE2.Étant donné que le paramètre du constructeur affectera l’adresse du contrat du déploiement CREATE2, si vous ne souhaitez pas être affecté par le paramètre du constructeur, le constructeur du contrat sera conçu pour déployer les paramètres de lecture de stockage du contrat, tels que le pool d’UNISWAP V3.Avec Tstore, un tel modèle peut économiser beaucoup de coûts.
-
Lorsque les développeurs contractuels utilisent TSTORE pour réécrire leur propre verrouillage de réentrance, n’oubliez pas de nettoyer la serrure quand il est temps de le nettoyer. Sinon, s’il y a un besoin pendant le processus de transaction, si vous entrez le contrat, vous ne pourrez peut-être pas entrer car le verrouillage n’est pas déverrouillé (non effacé).
-
L’EIP-1153 a été lancée dans la version 0.8.24 de Solidity, et les développeurs peuvent l’essayer à l’avance.Voici les exemples Mutex mis en œuvre par les développeurs.UNISWAP V4, qui s’appuie sur TSTORE, sera également lancé une fois la mise à niveau Dencun terminée.
-
Cet EIP a un nouvel opcode, donc si les développeurs souhaitent déployer des contrats sur plusieurs chaînes, ils devraient prêter attention à savoir si toutes les chaînes prennent en charge le dernier opcode, sinon il ne sera pas disponible.
-
Modifications de la couche d’exécution
-
EIP-4788: racine de bloc de balise dans l’EVM
-
https://eips.ethereum.org/eips/eip-4788
-
EIP-4788: Racine de balise dans EVM
-
https://ethereum-magicicicic.org/t/eip-4788-beacon-root-in-evm/8281
-
Modifications de la couche d’exécution
-
EIP-5656: MCOPY – Instruction de copie de mémoire
-
https://eips.ethereum.org/eips/eip-5656
-
Modifications de la couche d’exécution
-
EIP-6780: s’autodéstruire uniquement dans la même transaction
-
https://eips.ethereum.org/eips/eip-6780
-
EIP-6780: désactiver l’auto-destruction, sauf lorsqu’il se produit dans la même transaction dans laquelle un contrat a été créé
-
https://ethereum-magicicicican.org/t/eip-6780-dectivate-selfdestruct-except-where-it-occurs-in-the-sa-transaction-in-which-a-contract-wa s-créé / 13539
-
Si le contrat n’est pas créé dans la même transaction, le code du contrat et le stockage restent inchangés, mais l’ETH est transféré à l’adresse spécifiée.
-
Si le contrat est créé sur la même transaction, le comportement est le même qu’auparavant (avant EIP-6780): le code et le stockage du contrat seront supprimés et l’ETH sera transféré à l’adresse spécifiée.
-
Si le développeur utilise CREATE2 + Self-destruct pour se déployer à plusieurs reprises sur la même adresse, cela ne se produira simultanément que dans la même transaction après Dencun à terminer.
-
Si le développeur utilise CREATE2 + Self-destruct pour réaliser l’effet des mises à niveau des contrats (donc Create2 + Self -struct ne sera pas terminé dans la même transaction), il ne pourra pas continuer après Dencun.
-
Modifications de la couche consensus
-
EIP-7044: sorties volontaires signées perpétuellement valides
-
https://eips.ethereum.org/eips/eip-7044
-
EIP-7044: sorties volontaires signées perpétuellement valides
-
https://ethereum-magicicicic.org/t/eip-7044-éprécéalement-valid-signed-voluntary-exits/14348
-
Modifications de la couche consensus
-
EIP-7045: augmenter la fente d’inclusion d’attestation maximale
-
https://eips.ethereum.org/eips/eip-7045
-
EIP-7045: augmenter la fente d’inclusion d’attestation maximale
-
https://ethereum-magicicicic.org/t/eip-7045-increase-max-attestation-inclusion-slot/14342
-
Modifications de la couche consensus
-
EIP-7514: Ajouter la limite de désabonnement de l’époque max
-
https://eips.ethereum.org/eips/eip-7514
-
EIP-7514: Ajouter la limite de désabonnement de l’époque max
-
https://ethereum-magicicicic.org/t/eip-7514-add-max-epoch-churn-limit/15709
-
EIP-4844: transactions Shard Blob
-
https://www.eip4844.com/
-
Le grand ajout de Rollup: proto-danksharding (i)
-
https://medium.com/taipei-ethereum-meetup/rollup-and-the-boost-from-proto-danksharding-85d2fe0566b6
-
Le grand ajout de Rollup: proto-danksharding (ii)
-
https://medium.com/taipei-ethereum-meetup/rollup-proto-danksharding-implementation-detail-913a3c61fde8
-
Le Dencun Hard Fork se compose de la fourche dure Deneb de la couche consensus et de la fourche dure Cancun de la couche d’exécution.
-
Le protagoniste de cette mise à niveau est EIP-4844.
-
Les modifications de la couche consensus incluent EIP-7044, EIP-7045 et EIP-7514.
-
L’EIP-7044 permet aux validateurs d’utiliser des services marqués non gérés pour éviter de futures fourches dures lors du retrait du POS.
-
EIP-7045 et EIP-7514 peuvent être considérés comme des mises à jour qui augmentent la stabilité du réseau POS.
-
Les modifications de la couche d’exécution incluent EIP-1153, EIP-4788, EIP-5656, EIP-6780 et EIP-7516.
-
EIP-1153 permet à de nombreux modèles de conception de contrat d’économiser beaucoup de gaz;
-
EIP-4788 permet à la couche d’exécution de lire les informations de la couche de consensus d’une manière qui ne nécessite pas de confiance de tiers, permettant plus de possibilités de jalonner les services connexes.
-
L’EIP-6780 élimine en outre l’autodestruction et supprime sa capacité à « supprimer les codes et les statuts contractuels ».
-
Les développeurs doivent prêter attention à l’hypothèse selon laquelle « le stockage temporaire sera effacé après les transactions » lors de l’utilisation de l’EIP-1153, et assurez-vous de prêter attention à si votre contrat sera affecté s’il est affecté.
-
Les utilisateurs ordinaires n’ont pas besoin de porter une attention particulière.
-
https://eips.ethereum.org/eips/eip-1153
-
https://www.eip1153.com/
-
https://ethereum-magicicican.org/t/eip-1153-transent-storage-opcodes/553
-
https://hackmd.io/@@-_wyfkbvsmip5m7mnb4b8a/sjfh66eca
-
https://eips.ethereum.org/eips/eip-4788
-
https://ethereum-magicicicic.org/t/eip-4788-beacon-root-in-evm/8281
-
https://eips.ethereum.org/eips/eip-5656
-
https://eips.ethereum.org/eips/eip-6780
-
https://ethereum-magicicicican.org/t/eip-6780-dectivate-selfdestruct-except-where-it-occurs-in-the-sa-transaction-in-which-a-contract-wa s-créé / 13539
-
https://www.youtube.com/watch?v=s7fm6zz_g0i
-
https://eips.ethereum.org/eips/eip-7044
-
https://ethereum-magicicicic.org/t/eip-7044-éprécéalement-valid-signed-voluntary-exits/14348
-
https://eips.ethereum.org/eips/eip-7514
-
https://ethereum-magicicicic.org/t/eip-7514-add-max-epoch-churn-limit/15709
-
https://www.eip4844.com/
-
https://medium.com/taipei-ethereum-meetup/rollup-and-the-boost-from-proto-danksharding-85d2fe0566b6
-
https://medium.com/taipei-ethereum-meetup/rollup-proto-danksharding-implementation-detail-913a3c61fde8
-
https://eips.ethereum.org/eips/eip-7516
-
https://ethereum-magicicicic.org/t/eip-7516-blobbasefee-opcode/15761
Choses à noter
EIP-4788
EIP-4788 a ajouté un contrat BeACON_ROOTS_ADDRESS pour permettre aux gens de lire les données des blocs de couche consensus, c’est-à-dire que la couche d’exécution pourra lire les données de la couche de consensus.Grâce à ce contrat, les protocoles d’allumage et de réapprovisionnement peuvent lire et utiliser des données de couche de consensus sans faire confiance à un tiers, tel que la lecture de l’état d’un certain vérificateur.
Détails de l’opération
Les utilisateurs ou les contrats peuvent interroger la racine du bloc de balise à un certain moment en appelant le contrat.La racine du bloc est comme la valeur de hachage de la teneur en bloc (Beacon Block Hash), qui est la racine de l’arbre Merkle du contenu du bloc via le codage SSZ.L’appelant code pour la valeur de la valeur de UINT256 et le traite comme le contenu de l’appel.
Si un développeur souhaite utiliser les informations de la couche consensus, son contrat interroge la racine du bloc du bloc de couche consensus qu’il souhaite lire le contrat Beacac_roots_Address, puis associer les informations du bloc de couche consensus (par exemple, l’équilibre d’un vérificateur ) et Merkle preuve pour vérifier si les informations appartiennent à la racine du bloc.(SSZ Parce que le contenu est transformé en arbre Merkle, toutes les informations du contenu peuvent générer la preuve Merkle correspondante pour vérifier que les informations existent dans le contenu.)
△ L’utilisateur fournit l’horodatage des blocs de calques de la preuve Merkle et du consensus
△ La preuve de Merkle est utilisée pour vérifier l’équilibre du vérificateur à un certain moment.
Cependant, la racine du bloc de couche consensus stockée dans le contrat Beacon_roots_Address est en fait la racine de bloc du bloc « principal » (c’est-à-dire le bloc précédent), plutôt que la racine de bloc du même bloc que la couche d’exécution.
△ L’horodatage du bloc 11001 (1234567) correspond à la racine du bloc du bloc 11000.De même, l’horodatage du bloc 11000 (1234555) correspond à la racine du bloc du bloc 10999.
Choses à noter
Le contrat Beacon_roots_Address stocke jusqu’à 8191 les racines de bloc de couche consensus et 8191 les racines de bloc précédente seront écrasées.Par exemple, s’il s’agit du bloc 18191 maintenant, la plage de racine de bloc actuelle qui peut être accessible sera la racine du bloc du bloc 10000 au bloc 18190.
EIP-5656
EIP-5656 a ajouté un OPCode McOPY, qui est spécifiquement utilisé pour copier les valeurs stockées en mémoire pendant l’exécution du contrat.Le contrat bénéficiera des économies de coûts de gaz de cet opcode.
Pour utiliser McOPY OPCODE, les développeurs de contrats doivent spécifier la version du compilateur comme 0.8.24 (ou supérieur) et la version EVM comme Cancun:
△ Pour utiliser mcopy, vous devez définir la version du compilateur et la version EVM
Remarque: Le compilateur de la version 0.8.24 est uniquement ouvert à l’utilisation de McOPY (McOPY (), lien) via l’assemblage.
Choses à noter
Cet EIP a un nouvel opcode, donc si les développeurs souhaitent déployer des contrats sur plusieurs chaînes, ils devraient prêter attention à savoir si toutes les chaînes prennent en charge le dernier opcode, sinon il ne sera pas disponible.
EIP-6780
L’EIP-6780 a modifié le comportement de l’opcode d’autodestruction pour se préparer à l’arbre Verkle et l’élimination de l’opcode d’autodestruction.Les développeurs qui utilisent l’opcode autodestruct ont besoin d’une attention particulière.
arrière-plan
Le comportement actuel de l’auto-destruction de l’Opcode est: (1) Supprimer le code et le stockage du contrat, et (2) transférer tout l’ETH dessus à l’adresse spécifiée.
Au début, nous avons conçu l’opcode d’autodestruction avec mécanisme de remboursement pour encourager les développeurs à supprimer les contrats inutilisés et l’espace de stockage pour aider à maintenir l’état Ethereum à une taille appropriée.Mais peu de gens le font vraiment, mais il y a des accidents comme la parité multisig qui ont fait geler des centaines de milliers d’ETH en raison de l’autodestruction, de sorte que la communauté Ethereum espère éliminer progressivement l’opcode autodestructrice.Il y a eu de nombreuses propositions pour modifier ou supprimer l’opcode d’autodestruction dans le passé, et EIP-6780 est l’un d’entre eux et a finalement été inclus dans la fourche dur Dencun.
Remarque: Dans la Fork Hard Shanghai au début de 2023, l’EIP-6049 a officiellement annoncé que l’auto-destruction serait éliminée.
Verkle Tree est une structure de stockage d’État en cours de recherche activement et développée par la communauté Ethereum et sera utilisée pour remplacer l’arbre actuel de Merkle Patricia.Verkle Tree rendra la taille de la preuve de l’état Ethereum plus petit, il est également essentiel dans la conception du client sans état.Avec le client apatride, le matériel des nœuds sera réduit, permettant à plus de personnes d’exécuter des nœuds avec du matériel plus léger et moins cher, améliorant la décentralisation du réseau.
Détails de l’opération
Après EIP-6780, l’opcode d’auto-destruction supprimera (1) le comportement et conservera uniquement la fonction de (2) « transférer tout l’ETH sur votre corps à l’adresse spécifiée ».Le code du contrat et le stockage resteront inchangés à moins que le contrat ne soit créé dans la même transaction, puis l’auto-destruction est effectuée.
Ainsi, lorsque l’autodestruction est déclenchée:
Pour Verkle Tree, le comportement de (1) doit être supprimé
Dans la conception de Verkle Tree, son statut de stockage est différent de celui de Merkle Patricia Tree.L’état de stockage de l’arbre Merkle Patricia peut être imaginé comme une structure de deux couches (arbres dans les arbres): la première couche est un arbre composé de toutes les adresses, et la deuxième couche est un arbre composé de tout stockage et synthèse pour chaque adresse; Et l’arbre Verkle peut être imaginé comme une structure en couches complètement plate.Par conséquent, dans l’arbre Merkle Patricia, nous pouvons facilement localiser le stockage d’une adresse et le supprimer, mais dans l’arbre Verkle, il est presque impossible de localiser le stockage d’une adresse, car toutes les adresses et chaque valeur de stockage de l’adresse sont Nuimment distribué dans le même arbre, il est impossible de savoir facilement quelle valeur appartient à quelle adresse stockage, nous ne pouvons donc pas supprimer le code contractuel et tout son stockage dans l’arborescence Verkle.
△ La conception actuelle de l’arborescence de l’état (arbre Merkle Patricia) est une structure à deux couches: la racine d’état correspond à un arbre composé de tous les ensembles d’adresses, et la racine de stockage correspond à tous les arbres de stockage et synthétiques sous une adresse.
Source: https://fisco-bcos-documentation.readthedocs.io/en/latest/docs/design/storage/mppt.html
△ L’arbre d’état de Verkle est un arbre complètement plat.
Sur la figure, le nœud rouge est l’adresse et le nœud vert est la valeur de stockage de l’adresse.
Source: https://youtu.be/s7fm6zz_g0i?t=572
△ Si nous supprimons le nœud rouge mais pas le stockage (nœuds verts), si le contrat est redémarré à la même adresse, il héritera directement de l’ancien stockage non supprimé, ce qui deviendra un risque potentiellement élevé.
Source: https://youtu.be/s7fm6zz_g0i?t=572
Ainsi, afin d’accueillir Verkle Tree, nous devons interdire à l’opcode d’auto-destruction de supprimer les codes et le stockage du contrat.
Choses à noter
EIP-7044
L’EIP-7044 permet à la signature utilisée par le vérificateur de quitter les points de vente en permanence, évitant que la signature ne soit pas valide en raison de la fourche dure du réseau.L’expérience utilisateur et la protection des vérificateurs confiés à des services de gage non gérés (tels que Lido) seront améliorés: il n’est pas nécessaire de demander à un tiers de re-signer à chaque fois que vous devez être dur.
arrière-plan
Le vérificateur d’Ethereum POS doit avoir deux clés privées: l’une est utilisée pour la participation quotidienne à la vérification (comme la production de blocs et la signature), appelée Validator Key; La clé de l’adresse est appelée clé de retrait.Lorsque le validateur est sur le point de quitter le POS, il signera avec la touche Validator et le contenu signé contient la version réseau actuelle (dur à forkage).
Dans les services d’engagement non hébergées actuels, le fournisseur de services détiendra la clé de validateur dans sa main, et l’utilisateur conservera la clé de retrait. Please des actifs et des frais de manutention pour atteindre l’objectif de la non-garde.Afin d’éviter les fournisseurs de services menaçant d’extorquer les utilisateurs en «ne sortant pas de points de vente», les fournisseurs de services signeront le certificat de sortie de sortie au début et remettent la preuve à l’utilisateur, afin que les utilisateurs puissent choisir de quitter à tout moment POS, pas affecté par les prestataires de services.
Détails de l’opération
Mais parce que le contenu de signature qui quitte POS contient la version réseau actuelle (Fork Hard Fork), comme le Shanghai actuel ou la version précédente de Capella.Le réseau comparera la « version dur de la fourche dans le certificat de sortie » et la « version actuelle du réseau ».En d’autres termes, alors que le réseau continue d’être mis à jour, après Fork Hard et pas à niveau vers une nouvelle version, la preuve de sortie qui est trop ancien sera invalide.
Par exemple, les versions forfaites durs de la couche de consensus de l’ancienne à la nouvelle sont Altair, Bellatrix et (actuelle) Capella.Le certificat de sortie signé à Altair deviendra invalide maintenant;Pour faire face à cette situation, l’utilisateur doit demander un autre certificat de sortie auprès du fournisseur de services chaque fois que l’utilisateur se propage. Pos de sortie « menace les utilisateurs de chantage.
Remarque: Cependant, puisque « sortie POS » n’est ouverte qu’après Capella, personne ne peut décrire le certificat de sortie à Altair ou Bellatrix à l’avance.
Par conséquent, EIP-7044 corrige la version de Fork Hard Fork dans le certificat de sortie à Capella, de sorte que tous les certificats de sortie signés dans la version actuelle seront valables en permanence.Peu importe le nombre de mises à jour effectuées à l’avenir, Capella sera signée dans le certificat de sortie et ne sera plus affectée par la version forte dure.
Choses à noter
Étant donné que la version Fork Hard Fork du certificat de sortie est déjà corrigée dans Capella, si un vérificateur ou un fournisseur de service signe le certificat de sortie de la version Deneb, il deviendra invalide après Deneb.
EIP-7045
L’EIP-7045 prolonge la période de validité du vote des validateurs, permettant plus de temps à gagner et augmente la stabilité du réseau.Aucun impact sur les utilisateurs généraux ou les vérificateurs.
arrière-plan
À l’origine, le vote du vérificateur (ATTESTATION) a un temps d’époque (32 emplacements) qui peut être gagné. Les problèmes d’attente ou ce n’est qu’après le vote de l’emplacement 10020 qu’il a été diffusé avec succès au réseau P2P, mais ses votes seraient toujours gagnés.Mais si son vote n’apparaît que jusqu’à 10033 emplacements, il n’y a aucun moyen d’inclure son vote et il est jugé qu’il n’y a pas de vote.
Détails de l’opération
L’EIP-7045 étend la période de validité de l’inclusion de vote jusqu’à la fin du dernier « avant la prochaine époque du vote ».Par exemple, supposons que le vérificateur Alice est chargé de voter à la fente 3205 sur l’époque 100, et avant EIP-7045, son vote est valide jusqu’à l’emplacement 3237 (3237 = 3205 + 32); Slot 3237 (3237 = 3205 + 32);
Remarque: L’époque 0 contient des emplacements 0 à 31;
EIP-7514
arrière-plan
Après que Shanghai ait amélioré et ouvert des validateurs pour quitter le POS en 2023, il a attiré plus d’utilisateurs pour rejoindre et devenir des validateurs, ce qui a entraîné la séquence d’attente du validateur (file d’attente d’entrée) et le nombre total de validateurs augmente également rapidement.
△ La file d’attente d’entrée a augmenté après avoir quitté les points de vente d’Open.Source: https://www.validatorqueue.com/
Si le validateur attend que la séquence reste entièrement chargée, 50% de l’ETH sera promis au POS dans environ huit mois à partir de septembre 2023 (lorsque le PEI a été proposé) à mai 2024; 2019.Il y a plusieurs inconvénients de tant de jalonnement d’ETH, comme trop de validateurs, ce qui conduit à trop de signatures de vote et d’agrégation de validateurs, augmentant le fardeau du réseau P2P des validateurs et l’expansion de la chaîne de consensus.De plus, certaines personnes pensent que la sécurité requise par Ethereum ne nécessite pas autant de participation d’ETH.
Et pourquoi autant d’ETH continue-t-il à affluer?Parce que même si l’ETH atteint une participation à 100%, le taux annualisé est toujours d’environ 1,6%. une option très attrayante.
Heureusement, le boom des engagements a progressivement reculé dans la seconde moitié de 2023, ralentissant la croissance du nombre de validateurs.
△ La croissance du nombre de validateurs a ralenti dans la seconde moitié de 2023, avec environ 25% d’ETH promis en février 2024.Source: https://www.validatorqueue.com/
Détails de l’opération
Le nombre d’origine d’origine varie avec le nombre actuel de validateurs. est environ 950 000).
L’EIP-7514 fixera la limite de la file d’attente d’entrée à 8, n’augmentant plus avec le nombre de validateurs actuels, ralentissant ainsi la croissance des validateurs et donnant à la communauté plus de temps pour trouver des solutions à long terme, telles que la prochaine fourche dure peut gagner EIP-7251.
EIP-4844 et EIP-7516
EIP-4844 a ajouté un nouveau type de transaction, une transaction spécifiquement utilisée pour stocker les données BLOB.En plaçant les données dans un blob, Rollup réduira davantage les frais de transaction.
L’EIP-4844 n’est pas un changement pour augmenter la capacité et mettre à niveau la capacité, mais ressemble plus à « mettre à niveau la limite de gaz du bloc » et « réduire les coûts », permettant au bloc de y mettre plus de transactions (ROLUP).Mais EIP-4844 ouvre également la voie au plan d’extension réel – Danksharding.
De plus, Blob Fair et General Fair sont des marchés de frais distincts et indépendants, chacun avec ses propres frais de base et les frais de priorité. transactions).
Résumé et concentration
Données de référence et lecture prolongée recommandée
EIP-1153
EIP-4788
EIP-5656
EIP-6780
EIP-7044
EIP-7514
EIP-4844 & AMP;
