#eip
eip
14,122 vues
64 mentions
Populaire
Récents
·
--
Un projet d’EIP proposant une idée de conception particulièrement ingénieuse a émergé dans la communauté Ethereum : utiliser des « opcodes versionnés » pour revoir la tarification du gas, sans casser aucun contrat déjà déployé.
Le mécanisme repose sur trois piliers :
1｜Deux voies distinctes pour l’ancien et le nouveau. Les contrats nouvellement déployés doivent utiliser les opcodes V2 et appliquer la nouvelle grille tarifaire du gas définie par les EIP-8037/8038. Les contrats existants continuent d’utiliser l’ancienne grille, préservant ainsi le comportement historique sur la chaîne.
2｜Suppression de l’introspection du gas. Le jeu d’opcodes V2 n’inclut pas les opcodes de consultation comme GAS et GASLIMIT ; si le bytecode en contient un, le déploiement est immédiatement annulé. Cela revient à empêcher les contrats de s’appuyer sur le « gas restant » pour prendre des décisions logiques, levant ainsi les obstacles à de futures modifications tarifaires.
3｜Les appels sont également versionnés. Le nouvel opcode DELEGATECALL_V2 fonctionne comme DELEGATECALL, mais exige que code_version du contrat cible soit ≥ 2 ; dans le cas contraire, l’appel échoue immédiatement. Cela évite qu’un nouveau contrat appelle par erreur une logique d’une ancienne version.
En substance, cette approche transforme l’ajustement du coût du gas, qui nécessitait auparavant une mise à niveau généralisée et lourde de conséquences, en une opération courante déployée progressivement selon la version des contrats. La compatibilité ascendante est garantie par le protocole lui-même. Les utilisateurs ordinaires $ETH ne devraient presque pas remarquer de différence, tandis que les développeurs de contrats devront suivre le calendrier d’adaptation des futurs outils V2.
Texte original du projet : https://github.com/ethereum/EIPs/pull/12638
#以太坊 #EIP #FraisDeGas
Un projet d’EIP proposant une idée de conception particulièrement ingénieuse a émergé dans la communauté Ethereum : utiliser des « opcodes versionnés » pour revoir la tarification du gas, sans casser aucun contrat déjà déployé.
Le mécanisme repose sur trois piliers :
1｜Deux voies distinctes pour l’ancien et le nouveau. Les contrats nouvellement déployés doivent utiliser les opcodes V2 et appliquer la nouvelle grille tarifaire du gas définie par les EIP-8037/8038. Les contrats existants continuent d’utiliser l’ancienne grille, préservant ainsi le comportement historique sur la chaîne.
2｜Suppression de l’introspection du gas. Le jeu d’opcodes V2 n’inclut pas les opcodes de consultation comme GAS et GASLIMIT ; si le bytecode en contient un, le déploiement est immédiatement annulé. Cela revient à empêcher les contrats de s’appuyer sur le « gas restant » pour prendre des décisions logiques, levant ainsi les obstacles à de futures modifications tarifaires.
3｜Les appels sont également versionnés. Le nouvel opcode DELEGATECALL_V2 fonctionne comme DELEGATECALL, mais exige que code_version du contrat cible soit ≥ 2 ; dans le cas contraire, l’appel échoue immédiatement. Cela évite qu’un nouveau contrat appelle par erreur une logique d’une ancienne version.
En substance, cette approche transforme l’ajustement du coût du gas, qui nécessitait auparavant une mise à niveau généralisée et lourde de conséquences, en une opération courante déployée progressivement selon la version des contrats. La compatibilité ascendante est garantie par le protocole lui-même. Les utilisateurs ordinaires $ETH ne devraient presque pas remarquer de différence, tandis que les développeurs de contrats devront suivre le calendrier d’adaptation des futurs outils V2.
Texte original du projet : https://github.com/ethereum/EIPs/pull/12638
#以太坊 #EIP #FraisDeGas
Le mécanisme repose sur trois piliers :
1｜Deux voies distinctes pour l’ancien et le nouveau. Les contrats nouvellement déployés doivent utiliser les opcodes V2 et appliquer la nouvelle grille tarifaire du gas définie par les EIP-8037/8038. Les contrats existants continuent d’utiliser l’ancienne grille, préservant ainsi le comportement historique sur la chaîne.
2｜Suppression de l’introspection du gas. Le jeu d’opcodes V2 n’inclut pas les opcodes de consultation comme GAS et GASLIMIT ; si le bytecode en contient un, le déploiement est immédiatement annulé. Cela revient à empêcher les contrats de s’appuyer sur le « gas restant » pour prendre des décisions logiques, levant ainsi les obstacles à de futures modifications tarifaires.
3｜Les appels sont également versionnés. Le nouvel opcode DELEGATECALL_V2 fonctionne comme DELEGATECALL, mais exige que code_version du contrat cible soit ≥ 2 ; dans le cas contraire, l’appel échoue immédiatement. Cela évite qu’un nouveau contrat appelle par erreur une logique d’une ancienne version.
En substance, cette approche transforme l’ajustement du coût du gas, qui nécessitait auparavant une mise à niveau généralisée et lourde de conséquences, en une opération courante déployée progressivement selon la version des contrats. La compatibilité ascendante est garantie par le protocole lui-même. Les utilisateurs ordinaires $ETH ne devraient presque pas remarquer de différence, tandis que les développeurs de contrats devront suivre le calendrier d’adaptation des futurs outils V2.
Texte original du projet : https://github.com/ethereum/EIPs/pull/12638
#以太坊 #EIP #FraisDeGas
58
·
--
Ethereum veut ajouter des « numéros de version » à l’EVM.
Un nouveau projet d’EIP propose des « opcodes versionnés pour la révision des coûts du gas ». L’idée centrale tient en une phrase : les opcodes coexistent selon leur version ; les anciens contrats continuent de fonctionner avec l’ancien barème de gas, tandis que les nouveaux contrats déployés doivent utiliser les opcodes V2 et respecter les nouveaux barèmes définis par les EIP-8037/8038. Les deux ensembles de règles sont indépendants et rétrocompatibles.
Quelques détails à retenir pour les développeurs :
1. L’ensemble d’opcodes V2 supprime directement les opcodes d’introspection du gas, comme GAS et GASLIMIT. Si un nouveau contrat en contient, son déploiement échoue et est annulé. Le raisonnement est le suivant : si un contrat se fonde sur la quantité de gas restante pour prendre des décisions, toute future révision des coûts risque de le casser.
2. Un nouvel opcode, DELEGATECALL_V2, est ajouté. Son comportement est similaire à celui de DELEGATECALL, mais il exige que le contrat cible ait une code_version ≥ 2 ; dans le cas contraire, l’appel échoue immédiatement. Cela revient à instaurer un contrôle de version pour les appels entre contrats.
3. L’objectif de cette conception est de permettre à Ethereum de modifier à l’avenir les coûts du gas sans avancer à tâtons : l’isolation par version sépare la marge de manœuvre pour les mises à niveau de la sécurité des contrats déjà déployés, au lieu que chaque révision des coûts ait des répercussions sur tout l’écosystème.
En substance, l’EVM se forme aux principes des « systèmes logiciels évolutifs ». La proposition n’en est encore qu’au stade de projet et son intégration dans une mise à niveau du réseau principal est encore loin, mais cette orientation mérite d’être suivie sur le long terme.
#以太坊 #EIP #EVM
Ethereum veut ajouter des « numéros de version » à l’EVM.
Un nouveau projet d’EIP propose des « opcodes versionnés pour la révision des coûts du gas ». L’idée centrale tient en une phrase : les opcodes coexistent selon leur version ; les anciens contrats continuent de fonctionner avec l’ancien barème de gas, tandis que les nouveaux contrats déployés doivent utiliser les opcodes V2 et respecter les nouveaux barèmes définis par les EIP-8037/8038. Les deux ensembles de règles sont indépendants et rétrocompatibles.
Quelques détails à retenir pour les développeurs :
1. L’ensemble d’opcodes V2 supprime directement les opcodes d’introspection du gas, comme GAS et GASLIMIT. Si un nouveau contrat en contient, son déploiement échoue et est annulé. Le raisonnement est le suivant : si un contrat se fonde sur la quantité de gas restante pour prendre des décisions, toute future révision des coûts risque de le casser.
2. Un nouvel opcode, DELEGATECALL_V2, est ajouté. Son comportement est similaire à celui de DELEGATECALL, mais il exige que le contrat cible ait une code_version ≥ 2 ; dans le cas contraire, l’appel échoue immédiatement. Cela revient à instaurer un contrôle de version pour les appels entre contrats.
3. L’objectif de cette conception est de permettre à Ethereum de modifier à l’avenir les coûts du gas sans avancer à tâtons : l’isolation par version sépare la marge de manœuvre pour les mises à niveau de la sécurité des contrats déjà déployés, au lieu que chaque révision des coûts ait des répercussions sur tout l’écosystème.
En substance, l’EVM se forme aux principes des « systèmes logiciels évolutifs ». La proposition n’en est encore qu’au stade de projet et son intégration dans une mise à niveau du réseau principal est encore loin, mais cette orientation mérite d’être suivie sur le long terme.
#以太坊 #EIP #EVM
Un nouveau projet d’EIP propose des « opcodes versionnés pour la révision des coûts du gas ». L’idée centrale tient en une phrase : les opcodes coexistent selon leur version ; les anciens contrats continuent de fonctionner avec l’ancien barème de gas, tandis que les nouveaux contrats déployés doivent utiliser les opcodes V2 et respecter les nouveaux barèmes définis par les EIP-8037/8038. Les deux ensembles de règles sont indépendants et rétrocompatibles.
Quelques détails à retenir pour les développeurs :
1. L’ensemble d’opcodes V2 supprime directement les opcodes d’introspection du gas, comme GAS et GASLIMIT. Si un nouveau contrat en contient, son déploiement échoue et est annulé. Le raisonnement est le suivant : si un contrat se fonde sur la quantité de gas restante pour prendre des décisions, toute future révision des coûts risque de le casser.
2. Un nouvel opcode, DELEGATECALL_V2, est ajouté. Son comportement est similaire à celui de DELEGATECALL, mais il exige que le contrat cible ait une code_version ≥ 2 ; dans le cas contraire, l’appel échoue immédiatement. Cela revient à instaurer un contrôle de version pour les appels entre contrats.
3. L’objectif de cette conception est de permettre à Ethereum de modifier à l’avenir les coûts du gas sans avancer à tâtons : l’isolation par version sépare la marge de manœuvre pour les mises à niveau de la sécurité des contrats déjà déployés, au lieu que chaque révision des coûts ait des répercussions sur tout l’écosystème.
En substance, l’EVM se forme aux principes des « systèmes logiciels évolutifs ». La proposition n’en est encore qu’au stade de projet et son intégration dans une mise à niveau du réseau principal est encore loin, mais cette orientation mérite d’être suivie sur le long terme.
#以太坊 #EIP #EVM
66
·
--
Ethereum a discrètement publié un projet d’EIP susceptible d’influencer le cycle de vie des contrats pour la prochaine décennie : les « opcodes versionnés » ouvrent la voie à une nouvelle tarification du Gas.
La logique repose sur trois principes :
1. Les nouveaux contrats déployés doivent utiliser les opcodes V2 et appliquer les nouveaux barèmes de Gas d’EIP-8037/8038. Les contrats déjà déployés conservent l’ancien barème, sans changement de comportement.
2. Le jeu d’opcodes V2 supprime directement les instructions d’introspection du Gas, comme GAS et GASLIMIT. Si le bytecode contient ces opcodes, le déploiement est annulé.
3. Un nouvel opcode, DELEGATECALL_V2, est ajouté. Sa sémantique est similaire à celle de DELEGATECALL, mais il exige que la version du code du contrat cible soit ≥ 2 ; sinon, l’appel échoue immédiatement.
Pourquoi les développeurs devraient-ils s’y intéresser ? Jusqu’à présent, la principale inquiétude liée aux ajustements du coût du Gas sur Ethereum était que « modifier les tarifs revient à changer le comportement des contrats existants ». Les protocoles reposant sur des hypothèses de Gas codées en dur en ont fait les frais à plusieurs reprises. Avec la versionnalisation, les anciens contrats restent soumis aux anciennes règles et les nouvelles logiques aux nouvelles : pour la première fois, la mise à niveau et la compatibilité ont une frontière clairement définie.
Le coût est tout aussi évident : les capacités d’introspection du Gas sont délibérément supprimées. Les conceptions qui lisent en temps réel le Gas restant sur la chaîne devront être adaptées à l’avance. Le seuil de version imposé par DELEGATECALL_V2 obligera également les contrats proxy, les portefeuilles multisignatures et les portefeuilles intelligents à revoir toute leur chaîne d’appels.
Le projet est encore au stade PR. Il lui reste plusieurs étapes avant le mainnet : examen, tests et hard fork. Mais la direction est claire : Ethereum transforme l’« EVM évolutive », jusque-là un slogan, en un véritable mécanisme. Les détenteurs de $ETH n’ont rien à faire à court terme ; il est conseillé aux développeurs de lire le texte original dès maintenant et d’évaluer le coût de la migration.
#以太坊 #EIP #Gas
Ethereum a discrètement publié un projet d’EIP susceptible d’influencer le cycle de vie des contrats pour la prochaine décennie : les « opcodes versionnés » ouvrent la voie à une nouvelle tarification du Gas.
La logique repose sur trois principes :
1. Les nouveaux contrats déployés doivent utiliser les opcodes V2 et appliquer les nouveaux barèmes de Gas d’EIP-8037/8038. Les contrats déjà déployés conservent l’ancien barème, sans changement de comportement.
2. Le jeu d’opcodes V2 supprime directement les instructions d’introspection du Gas, comme GAS et GASLIMIT. Si le bytecode contient ces opcodes, le déploiement est annulé.
3. Un nouvel opcode, DELEGATECALL_V2, est ajouté. Sa sémantique est similaire à celle de DELEGATECALL, mais il exige que la version du code du contrat cible soit ≥ 2 ; sinon, l’appel échoue immédiatement.
Pourquoi les développeurs devraient-ils s’y intéresser ? Jusqu’à présent, la principale inquiétude liée aux ajustements du coût du Gas sur Ethereum était que « modifier les tarifs revient à changer le comportement des contrats existants ». Les protocoles reposant sur des hypothèses de Gas codées en dur en ont fait les frais à plusieurs reprises. Avec la versionnalisation, les anciens contrats restent soumis aux anciennes règles et les nouvelles logiques aux nouvelles : pour la première fois, la mise à niveau et la compatibilité ont une frontière clairement définie.
Le coût est tout aussi évident : les capacités d’introspection du Gas sont délibérément supprimées. Les conceptions qui lisent en temps réel le Gas restant sur la chaîne devront être adaptées à l’avance. Le seuil de version imposé par DELEGATECALL_V2 obligera également les contrats proxy, les portefeuilles multisignatures et les portefeuilles intelligents à revoir toute leur chaîne d’appels.
Le projet est encore au stade PR. Il lui reste plusieurs étapes avant le mainnet : examen, tests et hard fork. Mais la direction est claire : Ethereum transforme l’« EVM évolutive », jusque-là un slogan, en un véritable mécanisme. Les détenteurs de $ETH n’ont rien à faire à court terme ; il est conseillé aux développeurs de lire le texte original dès maintenant et d’évaluer le coût de la migration.
#以太坊 #EIP #Gas
La logique repose sur trois principes :
1. Les nouveaux contrats déployés doivent utiliser les opcodes V2 et appliquer les nouveaux barèmes de Gas d’EIP-8037/8038. Les contrats déjà déployés conservent l’ancien barème, sans changement de comportement.
2. Le jeu d’opcodes V2 supprime directement les instructions d’introspection du Gas, comme GAS et GASLIMIT. Si le bytecode contient ces opcodes, le déploiement est annulé.
3. Un nouvel opcode, DELEGATECALL_V2, est ajouté. Sa sémantique est similaire à celle de DELEGATECALL, mais il exige que la version du code du contrat cible soit ≥ 2 ; sinon, l’appel échoue immédiatement.
Pourquoi les développeurs devraient-ils s’y intéresser ? Jusqu’à présent, la principale inquiétude liée aux ajustements du coût du Gas sur Ethereum était que « modifier les tarifs revient à changer le comportement des contrats existants ». Les protocoles reposant sur des hypothèses de Gas codées en dur en ont fait les frais à plusieurs reprises. Avec la versionnalisation, les anciens contrats restent soumis aux anciennes règles et les nouvelles logiques aux nouvelles : pour la première fois, la mise à niveau et la compatibilité ont une frontière clairement définie.
Le coût est tout aussi évident : les capacités d’introspection du Gas sont délibérément supprimées. Les conceptions qui lisent en temps réel le Gas restant sur la chaîne devront être adaptées à l’avance. Le seuil de version imposé par DELEGATECALL_V2 obligera également les contrats proxy, les portefeuilles multisignatures et les portefeuilles intelligents à revoir toute leur chaîne d’appels.
Le projet est encore au stade PR. Il lui reste plusieurs étapes avant le mainnet : examen, tests et hard fork. Mais la direction est claire : Ethereum transforme l’« EVM évolutive », jusque-là un slogan, en un véritable mécanisme. Les détenteurs de $ETH n’ont rien à faire à court terme ; il est conseillé aux développeurs de lire le texte original dès maintenant et d’évaluer le coût de la migration.
#以太坊 #EIP #Gas
66
La communauté des développeurs principaux d’Ethereum passe à l’action : une proposition d’EIP intitulée « OpCodes versionnés pour la reprécification du gas » a été officiellement publiée sur le forum pour recueillir les commentaires. L’idée centrale consiste à ajouter un numéro de version aux opcodes afin que les futurs ajustements du coût du gas ne nécessitent pas une hard fork qui casserait les contrats déjà déployés.
Cette proposition comporte plusieurs points clés :
Premièrement, les versions ancienne et nouvelle coexistent tout en assurant la rétrocompatibilité. Les contrats nouvellement déployés doivent utiliser les opcodes V2 et respecter le nouveau barème de gas défini par les EIP-8037/8038 ; les contrats déjà en ligne continuent d’utiliser l’ancien barème et conservent leur comportement. L’impact d’une « hausse des prix » est ainsi limité aux nouveaux contrats.
Deuxièmement, l’ensemble d’opcodes V2 exclut délibérément les opcodes d’introspection du gas tels que GAS et GASLIMIT. Si le bytecode d’un nouveau contrat en contient, son déploiement est immédiatement annulé. La logique de la communauté des développeurs est la suivante : si un contrat dépend trop précisément de l’estimation du gas restant, toute reprécification future risque de déclencher une cascade de défaillances. Mieux vaut donc supprimer cette dépendance à la source.
Troisièmement, DELEGATECALL_V2 est ajouté. Sa sémantique est similaire à celle de DELEGATECALL classique, mais il impose que le code_version du contrat cible soit au moins égal à 2 ; sinon, l’appel échoue immédiatement. Cela évite qu’un contrat de nouvelle génération appelle par erreur une ancienne logique et s’appuie sur des hypothèses de gas obsolètes.
Dans l’ensemble, il s’agit d’une conception fondamentale qui prépare le terrain à l’évolutivité à long terme d’Ethereum : le prix du gas n’a jamais été un paramètre statique, et les opcodes versionnés offrent au protocole une voie d’ajustement progressive qui « ne touche que les nouveaux contrats sans affecter les anciens ». Pour les développeurs, il faudra suivre l’évolution des outils de migration et des règles d’audit ; pour les utilisateurs ordinaires, l’expérience sur la chaîne ne changera pas à court terme, mais cette évolution pourrait profondément influencer les pratiques de développement des contrats intelligents au cours des prochaines années.
#以太坊 #EIP
La communauté des développeurs principaux d’Ethereum passe à l’action : une proposition d’EIP intitulée « OpCodes versionnés pour la reprécification du gas » a été officiellement publiée sur le forum pour recueillir les commentaires. L’idée centrale consiste à ajouter un numéro de version aux opcodes afin que les futurs ajustements du coût du gas ne nécessitent pas une hard fork qui casserait les contrats déjà déployés.
Cette proposition comporte plusieurs points clés :
Premièrement, les versions ancienne et nouvelle coexistent tout en assurant la rétrocompatibilité. Les contrats nouvellement déployés doivent utiliser les opcodes V2 et respecter le nouveau barème de gas défini par les EIP-8037/8038 ; les contrats déjà en ligne continuent d’utiliser l’ancien barème et conservent leur comportement. L’impact d’une « hausse des prix » est ainsi limité aux nouveaux contrats.
Deuxièmement, l’ensemble d’opcodes V2 exclut délibérément les opcodes d’introspection du gas tels que GAS et GASLIMIT. Si le bytecode d’un nouveau contrat en contient, son déploiement est immédiatement annulé. La logique de la communauté des développeurs est la suivante : si un contrat dépend trop précisément de l’estimation du gas restant, toute reprécification future risque de déclencher une cascade de défaillances. Mieux vaut donc supprimer cette dépendance à la source.
Troisièmement, DELEGATECALL_V2 est ajouté. Sa sémantique est similaire à celle de DELEGATECALL classique, mais il impose que le code_version du contrat cible soit au moins égal à 2 ; sinon, l’appel échoue immédiatement. Cela évite qu’un contrat de nouvelle génération appelle par erreur une ancienne logique et s’appuie sur des hypothèses de gas obsolètes.
Dans l’ensemble, il s’agit d’une conception fondamentale qui prépare le terrain à l’évolutivité à long terme d’Ethereum : le prix du gas n’a jamais été un paramètre statique, et les opcodes versionnés offrent au protocole une voie d’ajustement progressive qui « ne touche que les nouveaux contrats sans affecter les anciens ». Pour les développeurs, il faudra suivre l’évolution des outils de migration et des règles d’audit ; pour les utilisateurs ordinaires, l’expérience sur la chaîne ne changera pas à court terme, mais cette évolution pourrait profondément influencer les pratiques de développement des contrats intelligents au cours des prochaines années.
#以太坊 #EIP
Cette proposition comporte plusieurs points clés :
Premièrement, les versions ancienne et nouvelle coexistent tout en assurant la rétrocompatibilité. Les contrats nouvellement déployés doivent utiliser les opcodes V2 et respecter le nouveau barème de gas défini par les EIP-8037/8038 ; les contrats déjà en ligne continuent d’utiliser l’ancien barème et conservent leur comportement. L’impact d’une « hausse des prix » est ainsi limité aux nouveaux contrats.
Deuxièmement, l’ensemble d’opcodes V2 exclut délibérément les opcodes d’introspection du gas tels que GAS et GASLIMIT. Si le bytecode d’un nouveau contrat en contient, son déploiement est immédiatement annulé. La logique de la communauté des développeurs est la suivante : si un contrat dépend trop précisément de l’estimation du gas restant, toute reprécification future risque de déclencher une cascade de défaillances. Mieux vaut donc supprimer cette dépendance à la source.
Troisièmement, DELEGATECALL_V2 est ajouté. Sa sémantique est similaire à celle de DELEGATECALL classique, mais il impose que le code_version du contrat cible soit au moins égal à 2 ; sinon, l’appel échoue immédiatement. Cela évite qu’un contrat de nouvelle génération appelle par erreur une ancienne logique et s’appuie sur des hypothèses de gas obsolètes.
Dans l’ensemble, il s’agit d’une conception fondamentale qui prépare le terrain à l’évolutivité à long terme d’Ethereum : le prix du gas n’a jamais été un paramètre statique, et les opcodes versionnés offrent au protocole une voie d’ajustement progressive qui « ne touche que les nouveaux contrats sans affecter les anciens ». Pour les développeurs, il faudra suivre l’évolution des outils de migration et des règles d’audit ; pour les utilisateurs ordinaires, l’expérience sur la chaîne ne changera pas à court terme, mais cette évolution pourrait profondément influencer les pratiques de développement des contrats intelligents au cours des prochaines années.
#以太坊 #EIP
56
Ethereum va doter l’EVM d’un « numéro de version ».
Un nouveau projet d’EIP propose des « opcodes versionnés pour la réévaluation du Gas ». L’idée centrale est la suivante : les contrats nouvellement déployés utilisent les opcodes V2 et une nouvelle grille de coûts en Gas (EIP-8037/8038), tandis que les anciens contrats déjà déployés conservent les anciennes règles. Les deux systèmes fonctionnent indépendamment, ce qui permet de préserver la compatibilité avec les versions antérieures lors de l’ajustement des coûts en Gas.
Quelques détails de conception méritent d’être relevés :
1. Le jeu d’opcodes V2 supprime directement les opcodes d’introspection du Gas, tels que GAS et GASLIMIT. Si un nouveau contrat contient ces instructions, son déploiement échoue immédiatement — ce sont précisément ces instructions qui rendaient les contrats existants particulièrement vulnérables aux ajustements historiques du prix du Gas.
2. DELEGATECALL_V2 est ajouté. Son comportement est similaire à celui de DELEGATECALL, mais il exige que le contrat cible ait un code_version ≥ 2 ; dans le cas contraire, l’appel échoue immédiatement. Cela évite toute ambiguïté sémantique lors des appels délégués entre différentes versions.
3. L’objectif global est unique : faire en sorte que les futurs ajustements des coûts en Gas ne prennent plus la forme d’une « rupture brutale lors d’un hard fork », mais s’effectuent progressivement, en fonction de la version du contrat, sans remettre en cause les hypothèses des contrats déjà déployés.
En d’autres termes, Ethereum tente de mettre en place pour l’EVM un mécanisme d’évolution comparable à la gestion des versions des logiciels. Si ce projet aboutit, la capacité de l’EVM à évoluer sur le long terme s’en trouvera nettement renforcée. Pour $ETH , il s’agirait également d’une amélioration concrète au niveau de l’infrastructure de base.
Texte original du projet : github.com/ethereum/EIPs/pull/12638
#以太坊 #EIP #EVM
Ethereum va doter l’EVM d’un « numéro de version ».
Un nouveau projet d’EIP propose des « opcodes versionnés pour la réévaluation du Gas ». L’idée centrale est la suivante : les contrats nouvellement déployés utilisent les opcodes V2 et une nouvelle grille de coûts en Gas (EIP-8037/8038), tandis que les anciens contrats déjà déployés conservent les anciennes règles. Les deux systèmes fonctionnent indépendamment, ce qui permet de préserver la compatibilité avec les versions antérieures lors de l’ajustement des coûts en Gas.
Quelques détails de conception méritent d’être relevés :
1. Le jeu d’opcodes V2 supprime directement les opcodes d’introspection du Gas, tels que GAS et GASLIMIT. Si un nouveau contrat contient ces instructions, son déploiement échoue immédiatement — ce sont précisément ces instructions qui rendaient les contrats existants particulièrement vulnérables aux ajustements historiques du prix du Gas.
2. DELEGATECALL_V2 est ajouté. Son comportement est similaire à celui de DELEGATECALL, mais il exige que le contrat cible ait un code_version ≥ 2 ; dans le cas contraire, l’appel échoue immédiatement. Cela évite toute ambiguïté sémantique lors des appels délégués entre différentes versions.
3. L’objectif global est unique : faire en sorte que les futurs ajustements des coûts en Gas ne prennent plus la forme d’une « rupture brutale lors d’un hard fork », mais s’effectuent progressivement, en fonction de la version du contrat, sans remettre en cause les hypothèses des contrats déjà déployés.
En d’autres termes, Ethereum tente de mettre en place pour l’EVM un mécanisme d’évolution comparable à la gestion des versions des logiciels. Si ce projet aboutit, la capacité de l’EVM à évoluer sur le long terme s’en trouvera nettement renforcée. Pour $ETH , il s’agirait également d’une amélioration concrète au niveau de l’infrastructure de base.
Texte original du projet : github.com/ethereum/EIPs/pull/12638
#以太坊 #EIP #EVM
Un nouveau projet d’EIP propose des « opcodes versionnés pour la réévaluation du Gas ». L’idée centrale est la suivante : les contrats nouvellement déployés utilisent les opcodes V2 et une nouvelle grille de coûts en Gas (EIP-8037/8038), tandis que les anciens contrats déjà déployés conservent les anciennes règles. Les deux systèmes fonctionnent indépendamment, ce qui permet de préserver la compatibilité avec les versions antérieures lors de l’ajustement des coûts en Gas.
Quelques détails de conception méritent d’être relevés :
1. Le jeu d’opcodes V2 supprime directement les opcodes d’introspection du Gas, tels que GAS et GASLIMIT. Si un nouveau contrat contient ces instructions, son déploiement échoue immédiatement — ce sont précisément ces instructions qui rendaient les contrats existants particulièrement vulnérables aux ajustements historiques du prix du Gas.
2. DELEGATECALL_V2 est ajouté. Son comportement est similaire à celui de DELEGATECALL, mais il exige que le contrat cible ait un code_version ≥ 2 ; dans le cas contraire, l’appel échoue immédiatement. Cela évite toute ambiguïté sémantique lors des appels délégués entre différentes versions.
3. L’objectif global est unique : faire en sorte que les futurs ajustements des coûts en Gas ne prennent plus la forme d’une « rupture brutale lors d’un hard fork », mais s’effectuent progressivement, en fonction de la version du contrat, sans remettre en cause les hypothèses des contrats déjà déployés.
En d’autres termes, Ethereum tente de mettre en place pour l’EVM un mécanisme d’évolution comparable à la gestion des versions des logiciels. Si ce projet aboutit, la capacité de l’EVM à évoluer sur le long terme s’en trouvera nettement renforcée. Pour $ETH , il s’agirait également d’une amélioration concrète au niveau de l’infrastructure de base.
Texte original du projet : github.com/ethereum/EIPs/pull/12638
#以太坊 #EIP #EVM
57
Le chercheur de la Fondation Ethereum frisitano a soumis une ébauche d’EIP visant à apporter à PeerDAS une mise à niveau « configuration sans confiance + résistance quantique ».
Changement principal : remplacer les engagements et preuves KZG des Blob par des engagements Merkle Keccak-256 et des chemins d’authentification. Une preuve LeanDA STARK recalculerait ensuite la racine Merkle, vérifierait les relations d’encodage Reed-Solomon et confirmerait la cohérence entre les engagements et les données. Cela éliminerait la dépendance à la configuration de confiance KZG, tout en renforçant la sécurité face à l’informatique quantique à venir.
L’ébauche introduit également des Blob de taille variable : leur longueur en octets doit être comprise entre 2048 et 524288, être une puissance de 2 et être divisible par 128 colonnes. Les transactions de la couche d’exécution transporteraient désormais (merkle_root, byte_length), au lieu d’utiliser un hash versionné ; la couche réseau et la facturation du Gas seraient également adaptées.
Si elle est finalement adoptée, cette proposition permettrait aux données soumises par les Rollups de mieux correspondre aux besoins réels et d’utiliser les ressources Blob plus finement. Toutefois, il ne s’agit encore que d’une ébauche : la conception des paramètres, la compatibilité et la sécurité doivent encore faire l’objet de discussions.$ETH #以太坊 #EIP #PeerDAS
Le chercheur de la Fondation Ethereum frisitano a soumis une ébauche d’EIP visant à apporter à PeerDAS une mise à niveau « configuration sans confiance + résistance quantique ».
Changement principal : remplacer les engagements et preuves KZG des Blob par des engagements Merkle Keccak-256 et des chemins d’authentification. Une preuve LeanDA STARK recalculerait ensuite la racine Merkle, vérifierait les relations d’encodage Reed-Solomon et confirmerait la cohérence entre les engagements et les données. Cela éliminerait la dépendance à la configuration de confiance KZG, tout en renforçant la sécurité face à l’informatique quantique à venir.
L’ébauche introduit également des Blob de taille variable : leur longueur en octets doit être comprise entre 2048 et 524288, être une puissance de 2 et être divisible par 128 colonnes. Les transactions de la couche d’exécution transporteraient désormais (merkle_root, byte_length), au lieu d’utiliser un hash versionné ; la couche réseau et la facturation du Gas seraient également adaptées.
Si elle est finalement adoptée, cette proposition permettrait aux données soumises par les Rollups de mieux correspondre aux besoins réels et d’utiliser les ressources Blob plus finement. Toutefois, il ne s’agit encore que d’une ébauche : la conception des paramètres, la compatibilité et la sécurité doivent encore faire l’objet de discussions.$ETH #以太坊 #EIP #PeerDAS
Changement principal : remplacer les engagements et preuves KZG des Blob par des engagements Merkle Keccak-256 et des chemins d’authentification. Une preuve LeanDA STARK recalculerait ensuite la racine Merkle, vérifierait les relations d’encodage Reed-Solomon et confirmerait la cohérence entre les engagements et les données. Cela éliminerait la dépendance à la configuration de confiance KZG, tout en renforçant la sécurité face à l’informatique quantique à venir.
L’ébauche introduit également des Blob de taille variable : leur longueur en octets doit être comprise entre 2048 et 524288, être une puissance de 2 et être divisible par 128 colonnes. Les transactions de la couche d’exécution transporteraient désormais (merkle_root, byte_length), au lieu d’utiliser un hash versionné ; la couche réseau et la facturation du Gas seraient également adaptées.
Si elle est finalement adoptée, cette proposition permettrait aux données soumises par les Rollups de mieux correspondre aux besoins réels et d’utiliser les ressources Blob plus finement. Toutefois, il ne s’agit encore que d’une ébauche : la conception des paramètres, la compatibilité et la sécurité doivent encore faire l’objet de discussions.$ETH #以太坊 #EIP #PeerDAS
15
·
--
EIP-7702 est une mise à jour de sécurité pour le réseau Ethereum, citée comme l’une des causes du récent piratage de Binance. Cette mise à jour vise à améliorer la sécurité des transactions sur le réseau Ethereum, mais sa mise en œuvre a suscité certaines inquiétudes parmi les développeurs.
Pour les traders, cette nouvelle est importante, car elle peut affecter la stabilité et la sécurité des transactions sur le réseau Ethereum, ce qui pourrait avoir un impact sur la valeur des cryptomonnaies qui utilisent ce réseau. Les développeurs d’Ethereum travaillent à mettre en œuvre cette mise à jour de manière à minimiser les interruptions de service.
Mais, selon vous, quelles mesures les plateformes d’échange devraient-elles prendre pour se protéger contre de futurs piratages ?
#EIP-7702 #BinanceHack #Ethereum #SécuritéCrypto
EIP-7702 est une mise à jour de sécurité pour le réseau Ethereum, citée comme l’une des causes du récent piratage de Binance. Cette mise à jour vise à améliorer la sécurité des transactions sur le réseau Ethereum, mais sa mise en œuvre a suscité certaines inquiétudes parmi les développeurs.
Pour les traders, cette nouvelle est importante, car elle peut affecter la stabilité et la sécurité des transactions sur le réseau Ethereum, ce qui pourrait avoir un impact sur la valeur des cryptomonnaies qui utilisent ce réseau. Les développeurs d’Ethereum travaillent à mettre en œuvre cette mise à jour de manière à minimiser les interruptions de service.
Mais, selon vous, quelles mesures les plateformes d’échange devraient-elles prendre pour se protéger contre de futurs piratages ?
#EIP-7702 #BinanceHack #Ethereum #SécuritéCrypto
Pour les traders, cette nouvelle est importante, car elle peut affecter la stabilité et la sécurité des transactions sur le réseau Ethereum, ce qui pourrait avoir un impact sur la valeur des cryptomonnaies qui utilisent ce réseau. Les développeurs d’Ethereum travaillent à mettre en œuvre cette mise à jour de manière à minimiser les interruptions de service.
Mais, selon vous, quelles mesures les plateformes d’échange devraient-elles prendre pour se protéger contre de futurs piratages ?
#EIP-7702 #BinanceHack #Ethereum #SécuritéCrypto
224
·
--
L’équipe Protocol DevOps de la Fondation Ethereum annonce officiellement le lancement du testnet précoce de la mise à niveau Glamsterdam, Platåberget, et prévoit d’effectuer le hard fork sur ce réseau le 20 août. Contrairement aux précédents devnets à court terme, Platåberget devrait fonctionner de manière stable pendant plusieurs mois, et s’accompagnera d’une configuration réseau en un clic ainsi que d’un robinet (faucet) pour des ETH de test, afin de permettre aux développeurs et à la communauté de continuer à participer aux validations.
La feuille de route de test est également globalement claire : au cours du mois, un devnet non définitif sera mis en ligne, destiné à tester des scénarios de consensus anormaux ; par la suite, des testnets à long terme tels que Sepolia, Hoodi, etc. termineront successivement le fork Glamsterdam, l’objectif final visant directement la mise à niveau du réseau principal Ethereum.
Les changements à surveiller particulièrement lors de cette mise à niveau comprennent :
l’inclusion de la séparation des proposer et builder (ePBS), qui inscrit la relation proposer-builder dans la couche de protocole ; des listes d’accès au niveau des blocs (Block-Level Access Lists), pour optimiser l’efficacité de l’accès aux données on-chain ; une nouvelle tarification des frais de gas, avec pour cible un seuil inférieur d’environ 200 millions de gas ; des limites maximales de taille pour les contrats et l’initcode, qui passent respectivement de 24 KiB et 48 KiB à 64 KiB et 128 KiB.
Il est particulièrement important de noter que : tout outil dépendant d’une limite maximale de gas codée en dur — tels que les portefeuilles (wallets), les indexeurs (indexers), les estimateurs de gas, etc. — sera impacté et nécessitera une mise à jour correspondante. Il est recommandé aux équipes de développement concernées d’évaluer l’adaptation le plus tôt possible.
#以太坊 #Glamsterdam #EIP
L’équipe Protocol DevOps de la Fondation Ethereum annonce officiellement le lancement du testnet précoce de la mise à niveau Glamsterdam, Platåberget, et prévoit d’effectuer le hard fork sur ce réseau le 20 août. Contrairement aux précédents devnets à court terme, Platåberget devrait fonctionner de manière stable pendant plusieurs mois, et s’accompagnera d’une configuration réseau en un clic ainsi que d’un robinet (faucet) pour des ETH de test, afin de permettre aux développeurs et à la communauté de continuer à participer aux validations.
La feuille de route de test est également globalement claire : au cours du mois, un devnet non définitif sera mis en ligne, destiné à tester des scénarios de consensus anormaux ; par la suite, des testnets à long terme tels que Sepolia, Hoodi, etc. termineront successivement le fork Glamsterdam, l’objectif final visant directement la mise à niveau du réseau principal Ethereum.
Les changements à surveiller particulièrement lors de cette mise à niveau comprennent :
l’inclusion de la séparation des proposer et builder (ePBS), qui inscrit la relation proposer-builder dans la couche de protocole ; des listes d’accès au niveau des blocs (Block-Level Access Lists), pour optimiser l’efficacité de l’accès aux données on-chain ; une nouvelle tarification des frais de gas, avec pour cible un seuil inférieur d’environ 200 millions de gas ; des limites maximales de taille pour les contrats et l’initcode, qui passent respectivement de 24 KiB et 48 KiB à 64 KiB et 128 KiB.
Il est particulièrement important de noter que : tout outil dépendant d’une limite maximale de gas codée en dur — tels que les portefeuilles (wallets), les indexeurs (indexers), les estimateurs de gas, etc. — sera impacté et nécessitera une mise à jour correspondante. Il est recommandé aux équipes de développement concernées d’évaluer l’adaptation le plus tôt possible.
#以太坊 #Glamsterdam #EIP
La feuille de route de test est également globalement claire : au cours du mois, un devnet non définitif sera mis en ligne, destiné à tester des scénarios de consensus anormaux ; par la suite, des testnets à long terme tels que Sepolia, Hoodi, etc. termineront successivement le fork Glamsterdam, l’objectif final visant directement la mise à niveau du réseau principal Ethereum.
Les changements à surveiller particulièrement lors de cette mise à niveau comprennent :
l’inclusion de la séparation des proposer et builder (ePBS), qui inscrit la relation proposer-builder dans la couche de protocole ; des listes d’accès au niveau des blocs (Block-Level Access Lists), pour optimiser l’efficacité de l’accès aux données on-chain ; une nouvelle tarification des frais de gas, avec pour cible un seuil inférieur d’environ 200 millions de gas ; des limites maximales de taille pour les contrats et l’initcode, qui passent respectivement de 24 KiB et 48 KiB à 64 KiB et 128 KiB.
Il est particulièrement important de noter que : tout outil dépendant d’une limite maximale de gas codée en dur — tels que les portefeuilles (wallets), les indexeurs (indexers), les estimateurs de gas, etc. — sera impacté et nécessitera une mise à jour correspondante. Il est recommandé aux équipes de développement concernées d’évaluer l’adaptation le plus tôt possible.
#以太坊 #Glamsterdam #EIP
25
·
--
La communauté Ethereum vient de lancer une toute nouvelle proposition de contrat de dépôt EIP dédiée à la sécurité contre le calcul quantique post-quantique. Cela marque une étape importante de plus pour Ethereum dans son architecture de sécurité à long terme.
Le cœur de cette proposition, identifiée par le numéro EIP-12235, comprend :
✅ L’introduction d’un nouveau contrat prenant en charge des clés publiques et des métadonnées de justificatifs de longueur variable, associé à un identifiant de scheme clair ; le dépôt BLS actuel conserve le scheme 0
✅ L’abandon de l’ancienne structure d’arbre de Merkle des contrats de dépôt, en utilisant l’exécution dérivée des journaux de l’EIP-7685 pour transmettre les informations de dépôt à la couche de consensus
✅ La mise en place d’une chronologie irréversible contrôlée par des appels du système de protocole : interdiction initiale des dépôts, activation d’abord des dépôts BLS, puis arrêt permanent final des dépôts BLS
✅ Pendant la phase de migration, les clients doivent fusionner les requêtes de dépôts des deux contrats, nouveaux et anciens
La sécurité post-quantique est depuis longtemps l’un des axes majeurs d’attention de l’industrie de la blockchain. L’évolution du calcul quantique constitue une menace potentielle à long terme pour les algorithmes cryptographiques existants. En préparant en amont une mise à niveau d’architecture, Ethereum se met en position pour répondre aux exigences futures en matière de sécurité ; cela mérite d’être suivi de près.
$ETH
#以太坊 #EIP #Sécurité post-quantique
La communauté Ethereum vient de lancer une toute nouvelle proposition de contrat de dépôt EIP dédiée à la sécurité contre le calcul quantique post-quantique. Cela marque une étape importante de plus pour Ethereum dans son architecture de sécurité à long terme.
Le cœur de cette proposition, identifiée par le numéro EIP-12235, comprend :
✅ L’introduction d’un nouveau contrat prenant en charge des clés publiques et des métadonnées de justificatifs de longueur variable, associé à un identifiant de scheme clair ; le dépôt BLS actuel conserve le scheme 0
✅ L’abandon de l’ancienne structure d’arbre de Merkle des contrats de dépôt, en utilisant l’exécution dérivée des journaux de l’EIP-7685 pour transmettre les informations de dépôt à la couche de consensus
✅ La mise en place d’une chronologie irréversible contrôlée par des appels du système de protocole : interdiction initiale des dépôts, activation d’abord des dépôts BLS, puis arrêt permanent final des dépôts BLS
✅ Pendant la phase de migration, les clients doivent fusionner les requêtes de dépôts des deux contrats, nouveaux et anciens
La sécurité post-quantique est depuis longtemps l’un des axes majeurs d’attention de l’industrie de la blockchain. L’évolution du calcul quantique constitue une menace potentielle à long terme pour les algorithmes cryptographiques existants. En préparant en amont une mise à niveau d’architecture, Ethereum se met en position pour répondre aux exigences futures en matière de sécurité ; cela mérite d’être suivi de près.
$ETH
#以太坊 #EIP #Sécurité post-quantique
Le cœur de cette proposition, identifiée par le numéro EIP-12235, comprend :
✅ L’introduction d’un nouveau contrat prenant en charge des clés publiques et des métadonnées de justificatifs de longueur variable, associé à un identifiant de scheme clair ; le dépôt BLS actuel conserve le scheme 0
✅ L’abandon de l’ancienne structure d’arbre de Merkle des contrats de dépôt, en utilisant l’exécution dérivée des journaux de l’EIP-7685 pour transmettre les informations de dépôt à la couche de consensus
✅ La mise en place d’une chronologie irréversible contrôlée par des appels du système de protocole : interdiction initiale des dépôts, activation d’abord des dépôts BLS, puis arrêt permanent final des dépôts BLS
✅ Pendant la phase de migration, les clients doivent fusionner les requêtes de dépôts des deux contrats, nouveaux et anciens
La sécurité post-quantique est depuis longtemps l’un des axes majeurs d’attention de l’industrie de la blockchain. L’évolution du calcul quantique constitue une menace potentielle à long terme pour les algorithmes cryptographiques existants. En préparant en amont une mise à niveau d’architecture, Ethereum se met en position pour répondre aux exigences futures en matière de sécurité ; cela mérite d’être suivi de près.
$ETH
#以太坊 #EIP #Sécurité post-quantique
60
La communauté Ethereum a récemment soumis une proposition EIP « Dépôts compatibles avec le calcul quantique post-quantique ». Anticiper ainsi les menaces pour la sécurité des actifs cryptographiques à l’avenir, qu’en pensez-vous ?
Les points clés de la proposition incluent :
1️⃣ L’introduction d’un nouveau contrat prenant en charge des clés publiques et des métadonnées de preuves de longueur variable, ainsi qu’un identifiant de scheme explicite (le scheme 0 est réservé aux dépôts BLS actuels)
2️⃣ Le nouveau contrat de dépôt ne dépend plus de la structure en arbre de Merkle du contrat de dépôt existant, mais transmet les informations de dépôt à la couche de consensus via l’exécution dérivée des journaux de l’EIP-7685, ce qui rend la structure plus claire
3️⃣ La mise en place d’un mode de basculement irréversible contrôlé par le système de protocole : le dépôt est initialement désactivé, puis les dépôts BLS sont activés à un timestamp spécifié ; ensuite, à un timestamp ultérieur, les dépôts BLS sont définitivement arrêtés, sans possibilité de réactivation, afin d’achever progressivement la migration de la mise à niveau
4️⃣ Pendant la période de migration, le client d’exécution doit fusionner simultanément les demandes de dépôt des deux contrats (nouveau et ancien) pour assurer une transition fluide
Dans un contexte où la technologie de l’informatique quantique progresse sans cesse, mettre à niveau en amont les normes de sécurité de l’infrastructure cryptographique est essentiel pour protéger durablement la sécurité des actifs des utilisateurs. Une mise à niveau préventive comme celle de l’écosystème $ETH , vous semble-t-elle nécessaire ?
#以太坊 #EIP #sécurité post-quantique
La communauté Ethereum a récemment soumis une proposition EIP « Dépôts compatibles avec le calcul quantique post-quantique ». Anticiper ainsi les menaces pour la sécurité des actifs cryptographiques à l’avenir, qu’en pensez-vous ?
Les points clés de la proposition incluent :
1️⃣ L’introduction d’un nouveau contrat prenant en charge des clés publiques et des métadonnées de preuves de longueur variable, ainsi qu’un identifiant de scheme explicite (le scheme 0 est réservé aux dépôts BLS actuels)
2️⃣ Le nouveau contrat de dépôt ne dépend plus de la structure en arbre de Merkle du contrat de dépôt existant, mais transmet les informations de dépôt à la couche de consensus via l’exécution dérivée des journaux de l’EIP-7685, ce qui rend la structure plus claire
3️⃣ La mise en place d’un mode de basculement irréversible contrôlé par le système de protocole : le dépôt est initialement désactivé, puis les dépôts BLS sont activés à un timestamp spécifié ; ensuite, à un timestamp ultérieur, les dépôts BLS sont définitivement arrêtés, sans possibilité de réactivation, afin d’achever progressivement la migration de la mise à niveau
4️⃣ Pendant la période de migration, le client d’exécution doit fusionner simultanément les demandes de dépôt des deux contrats (nouveau et ancien) pour assurer une transition fluide
Dans un contexte où la technologie de l’informatique quantique progresse sans cesse, mettre à niveau en amont les normes de sécurité de l’infrastructure cryptographique est essentiel pour protéger durablement la sécurité des actifs des utilisateurs. Une mise à niveau préventive comme celle de l’écosystème $ETH , vous semble-t-elle nécessaire ?
#以太坊 #EIP #sécurité post-quantique
Les points clés de la proposition incluent :
1️⃣ L’introduction d’un nouveau contrat prenant en charge des clés publiques et des métadonnées de preuves de longueur variable, ainsi qu’un identifiant de scheme explicite (le scheme 0 est réservé aux dépôts BLS actuels)
2️⃣ Le nouveau contrat de dépôt ne dépend plus de la structure en arbre de Merkle du contrat de dépôt existant, mais transmet les informations de dépôt à la couche de consensus via l’exécution dérivée des journaux de l’EIP-7685, ce qui rend la structure plus claire
3️⃣ La mise en place d’un mode de basculement irréversible contrôlé par le système de protocole : le dépôt est initialement désactivé, puis les dépôts BLS sont activés à un timestamp spécifié ; ensuite, à un timestamp ultérieur, les dépôts BLS sont définitivement arrêtés, sans possibilité de réactivation, afin d’achever progressivement la migration de la mise à niveau
4️⃣ Pendant la période de migration, le client d’exécution doit fusionner simultanément les demandes de dépôt des deux contrats (nouveau et ancien) pour assurer une transition fluide
Dans un contexte où la technologie de l’informatique quantique progresse sans cesse, mettre à niveau en amont les normes de sécurité de l’infrastructure cryptographique est essentiel pour protéger durablement la sécurité des actifs des utilisateurs. Une mise à niveau préventive comme celle de l’écosystème $ETH , vous semble-t-elle nécessaire ?
#以太坊 #EIP #sécurité post-quantique
83
·
--
📰 L’équipe du protocole de la Fondation Ethereum a déjà listé les priorités de mise à niveau de Hegotá au travers des EIP. L’objectif est également très clair : d’ici décembre 2029, assurer la préparation à la sécurité quantique sur les trois couches de base d’Ethereum — exécution, consensus et données.
🔥 Cette fois, deux propositions clés ont été classées en catégorie S, « indispensables à mettre en ligne ». Pour la couche de consensus, FOCIL, soit l’EIP-7805, prévoit de renforcer la résistance du réseau à la censure en imposant l’inclusion des transactions provenant d’un pool de mémoire public.
💡 Pour la couche d’exécution, Frame Transactions, c’est-à-dire l’EIP-8141, fait aussi partie des projets indispensables. Il découpera les transactions en plusieurs « trames » programmables : validation, paiement du Gas et exécution. À l’avenir, l’abstraction native des comptes, les signatures personnalisées et le paiement du Gas pour le compte d’un tiers disposeront d’une base technique plus précise.
Honnêtement, la sécurité quantique semble loin du quotidien des utilisateurs, mais ce n’est pas un simple correctif temporaire : c’est une feuille de route de long terme planifiée à l’avance par l’équipe protocolaire. Celle-ci estime qu’à partir de la fourchette Glamsterdam du quatrième trimestre 2026, les mises à niveau suivantes nécessiteront en moyenne environ 7,2 mois à chaque fourchette, afin de terminer avant le « Q-day » attendu autour de 2030.
🤔 En combien de temps Ethereum compte faire cela ? Selon vous, ce type de mise à niveau anticipée est-il une approche prudente, ou risque-t-il de rendre l’itération du protocole trop lente ?
#以太坊 #Hegotá #量子安全 #EIP
📰 L’équipe du protocole de la Fondation Ethereum a déjà listé les priorités de mise à niveau de Hegotá au travers des EIP. L’objectif est également très clair : d’ici décembre 2029, assurer la préparation à la sécurité quantique sur les trois couches de base d’Ethereum — exécution, consensus et données.
🔥 Cette fois, deux propositions clés ont été classées en catégorie S, « indispensables à mettre en ligne ». Pour la couche de consensus, FOCIL, soit l’EIP-7805, prévoit de renforcer la résistance du réseau à la censure en imposant l’inclusion des transactions provenant d’un pool de mémoire public.
💡 Pour la couche d’exécution, Frame Transactions, c’est-à-dire l’EIP-8141, fait aussi partie des projets indispensables. Il découpera les transactions en plusieurs « trames » programmables : validation, paiement du Gas et exécution. À l’avenir, l’abstraction native des comptes, les signatures personnalisées et le paiement du Gas pour le compte d’un tiers disposeront d’une base technique plus précise.
Honnêtement, la sécurité quantique semble loin du quotidien des utilisateurs, mais ce n’est pas un simple correctif temporaire : c’est une feuille de route de long terme planifiée à l’avance par l’équipe protocolaire. Celle-ci estime qu’à partir de la fourchette Glamsterdam du quatrième trimestre 2026, les mises à niveau suivantes nécessiteront en moyenne environ 7,2 mois à chaque fourchette, afin de terminer avant le « Q-day » attendu autour de 2030.
🤔 En combien de temps Ethereum compte faire cela ? Selon vous, ce type de mise à niveau anticipée est-il une approche prudente, ou risque-t-il de rendre l’itération du protocole trop lente ?
#以太坊 #Hegotá #量子安全 #EIP
🔥 Cette fois, deux propositions clés ont été classées en catégorie S, « indispensables à mettre en ligne ». Pour la couche de consensus, FOCIL, soit l’EIP-7805, prévoit de renforcer la résistance du réseau à la censure en imposant l’inclusion des transactions provenant d’un pool de mémoire public.
💡 Pour la couche d’exécution, Frame Transactions, c’est-à-dire l’EIP-8141, fait aussi partie des projets indispensables. Il découpera les transactions en plusieurs « trames » programmables : validation, paiement du Gas et exécution. À l’avenir, l’abstraction native des comptes, les signatures personnalisées et le paiement du Gas pour le compte d’un tiers disposeront d’une base technique plus précise.
Honnêtement, la sécurité quantique semble loin du quotidien des utilisateurs, mais ce n’est pas un simple correctif temporaire : c’est une feuille de route de long terme planifiée à l’avance par l’équipe protocolaire. Celle-ci estime qu’à partir de la fourchette Glamsterdam du quatrième trimestre 2026, les mises à niveau suivantes nécessiteront en moyenne environ 7,2 mois à chaque fourchette, afin de terminer avant le « Q-day » attendu autour de 2030.
🤔 En combien de temps Ethereum compte faire cela ? Selon vous, ce type de mise à niveau anticipée est-il une approche prudente, ou risque-t-il de rendre l’itération du protocole trop lente ?
#以太坊 #Hegotá #量子安全 #EIP
24
·
--
La proposition EIP-8361 est officiellement publiée. L’idée centrale consiste à « installer un régulateur » pour l’inflation d’Ethereum :
· Pour chaque epoch, une partie de la récompense de bloc des validateurs est prélevée et détruite
· Lorsque le taux de mise en jeu total du réseau atteint 50 %, le taux de destruction est immédiatement porté à 100 %
· La proportion exacte d’arrêt des récompenses est déterminée par les jeux du marché, mais strictement inférieure à 50 %
En bref : plus il y a de mises en jeu, plus la destruction des récompenses est intense. C’est une expérience de conception visant à freiner à rebours l’inflation de l’ETH via des mécanismes on-chain. Les 50 % constituent un seuil psychologique clé, et aussi la « ligne d’alerte » du point de vue de l’auteur de la proposition contre une « mise en jeu excessive ».
Si elle est mise en œuvre, cela signifie que le modèle économique d’Ethereum se rapprochera davantage d’une approche « déflationniste d’abord » : les détenteurs de long terme y gagneraient, mais les rendements des validateurs seraient fortement compressés. Êtes-vous favorable à cette direction ?
#Ethereum#EIP#Inflation
La proposition EIP-8361 est officiellement publiée. L’idée centrale consiste à « installer un régulateur » pour l’inflation d’Ethereum :
· Pour chaque epoch, une partie de la récompense de bloc des validateurs est prélevée et détruite
· Lorsque le taux de mise en jeu total du réseau atteint 50 %, le taux de destruction est immédiatement porté à 100 %
· La proportion exacte d’arrêt des récompenses est déterminée par les jeux du marché, mais strictement inférieure à 50 %
En bref : plus il y a de mises en jeu, plus la destruction des récompenses est intense. C’est une expérience de conception visant à freiner à rebours l’inflation de l’ETH via des mécanismes on-chain. Les 50 % constituent un seuil psychologique clé, et aussi la « ligne d’alerte » du point de vue de l’auteur de la proposition contre une « mise en jeu excessive ».
Si elle est mise en œuvre, cela signifie que le modèle économique d’Ethereum se rapprochera davantage d’une approche « déflationniste d’abord » : les détenteurs de long terme y gagneraient, mais les rendements des validateurs seraient fortement compressés. Êtes-vous favorable à cette direction ?
#Ethereum#EIP#Inflation
· Pour chaque epoch, une partie de la récompense de bloc des validateurs est prélevée et détruite
· Lorsque le taux de mise en jeu total du réseau atteint 50 %, le taux de destruction est immédiatement porté à 100 %
· La proportion exacte d’arrêt des récompenses est déterminée par les jeux du marché, mais strictement inférieure à 50 %
En bref : plus il y a de mises en jeu, plus la destruction des récompenses est intense. C’est une expérience de conception visant à freiner à rebours l’inflation de l’ETH via des mécanismes on-chain. Les 50 % constituent un seuil psychologique clé, et aussi la « ligne d’alerte » du point de vue de l’auteur de la proposition contre une « mise en jeu excessive ».
Si elle est mise en œuvre, cela signifie que le modèle économique d’Ethereum se rapprochera davantage d’une approche « déflationniste d’abord » : les détenteurs de long terme y gagneraient, mais les rendements des validateurs seraient fortement compressés. Êtes-vous favorable à cette direction ?
#Ethereum#EIP#Inflation
125
La communauté Ethereum vient de lancer une toute nouvelle proposition d’EIP de contrats de dépôt pour l’ère du calcul quantique post‑quantique. Anticiper les mises à niveau de sécurité cryptographique, il faut donner plein de points pour ce sens de la vision👏
Synthèse des points clés de la proposition :
▫️ Introduction d’un nouveau contrat prenant en charge des clés et des métadonnées de preuves de longueur variable, ajout d’un identifiant de scheme explicite (le scheme 0 est réservé au dépôt BLS actuel)
▫️ Fin de la dépendance à l’ancienne structure d’arbre de Merkle du contrat de dépôt : via l’exécution dérivée des journaux de l’EIP‑7685, les informations de dépôt sont transmises à la couche de consensus, l’architecture est ainsi plus simple et plus efficace
▫️ Mise en place d’un mécanisme de transition irréversible : les dépôts initialement sont désactivés, puis les dépôts BLS sont activés par fenêtre temporelle ; à l’expiration, les dépôts BLS sont définitivement désactivés. Le processus de bascule est clair et contrôlable
▫️ Pendant la phase de migration, le client doit exécuter une gestion combinée des requêtes de dépôts des nouveaux et anciens contrats, afin d’assurer une transition fluide
À l’heure où la menace du calcul quantique se rapproche progressivement, la communauté Ethereum lance en avance une mise à niveau de sécurité au niveau fondamental : poser des bases solides pour la sécurité à long terme de l’écosystème. Voilà le type d’attitude long terme que les meilleurs devraient avoir.
Qu’en pensez-vous de cette anticipation d’Ethereum pour l’ère post‑quantique ? N’hésitez pas à en discuter dans les commentaires👇
#以太坊 #EIP #calcul_post_quantique
La communauté Ethereum vient de lancer une toute nouvelle proposition d’EIP de contrats de dépôt pour l’ère du calcul quantique post‑quantique. Anticiper les mises à niveau de sécurité cryptographique, il faut donner plein de points pour ce sens de la vision👏
Synthèse des points clés de la proposition :
▫️ Introduction d’un nouveau contrat prenant en charge des clés et des métadonnées de preuves de longueur variable, ajout d’un identifiant de scheme explicite (le scheme 0 est réservé au dépôt BLS actuel)
▫️ Fin de la dépendance à l’ancienne structure d’arbre de Merkle du contrat de dépôt : via l’exécution dérivée des journaux de l’EIP‑7685, les informations de dépôt sont transmises à la couche de consensus, l’architecture est ainsi plus simple et plus efficace
▫️ Mise en place d’un mécanisme de transition irréversible : les dépôts initialement sont désactivés, puis les dépôts BLS sont activés par fenêtre temporelle ; à l’expiration, les dépôts BLS sont définitivement désactivés. Le processus de bascule est clair et contrôlable
▫️ Pendant la phase de migration, le client doit exécuter une gestion combinée des requêtes de dépôts des nouveaux et anciens contrats, afin d’assurer une transition fluide
À l’heure où la menace du calcul quantique se rapproche progressivement, la communauté Ethereum lance en avance une mise à niveau de sécurité au niveau fondamental : poser des bases solides pour la sécurité à long terme de l’écosystème. Voilà le type d’attitude long terme que les meilleurs devraient avoir.
Qu’en pensez-vous de cette anticipation d’Ethereum pour l’ère post‑quantique ? N’hésitez pas à en discuter dans les commentaires👇
#以太坊 #EIP #calcul_post_quantique
Synthèse des points clés de la proposition :
▫️ Introduction d’un nouveau contrat prenant en charge des clés et des métadonnées de preuves de longueur variable, ajout d’un identifiant de scheme explicite (le scheme 0 est réservé au dépôt BLS actuel)
▫️ Fin de la dépendance à l’ancienne structure d’arbre de Merkle du contrat de dépôt : via l’exécution dérivée des journaux de l’EIP‑7685, les informations de dépôt sont transmises à la couche de consensus, l’architecture est ainsi plus simple et plus efficace
▫️ Mise en place d’un mécanisme de transition irréversible : les dépôts initialement sont désactivés, puis les dépôts BLS sont activés par fenêtre temporelle ; à l’expiration, les dépôts BLS sont définitivement désactivés. Le processus de bascule est clair et contrôlable
▫️ Pendant la phase de migration, le client doit exécuter une gestion combinée des requêtes de dépôts des nouveaux et anciens contrats, afin d’assurer une transition fluide
À l’heure où la menace du calcul quantique se rapproche progressivement, la communauté Ethereum lance en avance une mise à niveau de sécurité au niveau fondamental : poser des bases solides pour la sécurité à long terme de l’écosystème. Voilà le type d’attitude long terme que les meilleurs devraient avoir.
Qu’en pensez-vous de cette anticipation d’Ethereum pour l’ère post‑quantique ? N’hésitez pas à en discuter dans les commentaires👇
#以太坊 #EIP #calcul_post_quantique
69
·
--
Explication détaillée de la dernière allocution de Vitalik sur l’EIP-8288 : un « remède ultime » pour l’expansion d’Ethereum, et des transactions futures à la fois plus rapides et moins chères !
Problème central : Ethereum fait face depuis longtemps à une impasse où il est difficile de concilier sécurité quantique, protection de la confidentialité et évolutivité. Une transaction classique consomme environ 21 000 gas, et la vérification d’une signature ECDSA environ 4 000 gas ; en revanche, les signatures à sécurité quantique coûtent jusqu’à 100 000–300 000 gas, et les preuves de confidentialité ZK nécessitent au minimum 350 000 gas (parfois plus d’un million). Si l’on combine les deux (preuves STARK pour la sécurité quantique + la confidentialité), une seule transaction peut brûler environ 8 millions de gas — ce qui ferait chuter le TPS d’Ethereum de 25 à 0,25, le rendant quasiment inutilisable.
La solution proposée par Vitalik : le cœur de l’EIP-8288 consiste à déplacer les calculs cryptographiques coûteux vers le hors-chaîne.
Avant d’enregistrer la transaction on-chain, les nœuds agrègent dans le mempool les signatures/preuves de plusieurs utilisateurs en une preuve STARK, conçue avec une « structure de micro-trame » ; sur la chaîne, on ne conserve que des informations de dépendance de 65 à 96 octets. Les énormes données cryptographiques elles-mêmes ne sont pas stockées sur la chaîne. L’idée consiste à séparer la transaction en deux parties : « logique métier » et « tâche de vérification », la partie vérification étant traitée en parallèle hors-chaîne (via des sharding spécialisés).
Points forts : il s’agirait peut-être du premier cas où Ethereum introduit réellement l’ensemble d’instructions RISC-V ; cette approche s’appuie sur l’EIP-8141 à venir (abstraction native des comptes) ; après compression, la taille des données des blocs peut être contrôlée dans une fourchette de 100–300 Ko ; l’expérience développeur ne serait pas beaucoup modifiée, sans nécessiter de lourdes adaptations de la part des développeurs d’Ethereum.
Conclusion : si la proposition aboutit, le coût des transactions à sécurité quantique baissera fortement, les applications axées confidentialité n’auront plus à être découragées par des frais de gas trop élevés, et la vitesse de confirmation des ZK-Rollups L2 pourra aussi nettement s’améliorer. À l’heure actuelle, la communauté a déjà ouvert plusieurs canaux de participation : modèles de simulation réseau, réseau de test, concours d’algorithmes, dépôts de code prototypes, etc. Nous sommes à un stade de co-construction précoce.
#以太坊扩容 #EIP #比特币现货ETF四日流入23.1亿美元
Explication détaillée de la dernière allocution de Vitalik sur l’EIP-8288 : un « remède ultime » pour l’expansion d’Ethereum, et des transactions futures à la fois plus rapides et moins chères !
Problème central : Ethereum fait face depuis longtemps à une impasse où il est difficile de concilier sécurité quantique, protection de la confidentialité et évolutivité. Une transaction classique consomme environ 21 000 gas, et la vérification d’une signature ECDSA environ 4 000 gas ; en revanche, les signatures à sécurité quantique coûtent jusqu’à 100 000–300 000 gas, et les preuves de confidentialité ZK nécessitent au minimum 350 000 gas (parfois plus d’un million). Si l’on combine les deux (preuves STARK pour la sécurité quantique + la confidentialité), une seule transaction peut brûler environ 8 millions de gas — ce qui ferait chuter le TPS d’Ethereum de 25 à 0,25, le rendant quasiment inutilisable.
La solution proposée par Vitalik : le cœur de l’EIP-8288 consiste à déplacer les calculs cryptographiques coûteux vers le hors-chaîne.
Avant d’enregistrer la transaction on-chain, les nœuds agrègent dans le mempool les signatures/preuves de plusieurs utilisateurs en une preuve STARK, conçue avec une « structure de micro-trame » ; sur la chaîne, on ne conserve que des informations de dépendance de 65 à 96 octets. Les énormes données cryptographiques elles-mêmes ne sont pas stockées sur la chaîne. L’idée consiste à séparer la transaction en deux parties : « logique métier » et « tâche de vérification », la partie vérification étant traitée en parallèle hors-chaîne (via des sharding spécialisés).
Points forts : il s’agirait peut-être du premier cas où Ethereum introduit réellement l’ensemble d’instructions RISC-V ; cette approche s’appuie sur l’EIP-8141 à venir (abstraction native des comptes) ; après compression, la taille des données des blocs peut être contrôlée dans une fourchette de 100–300 Ko ; l’expérience développeur ne serait pas beaucoup modifiée, sans nécessiter de lourdes adaptations de la part des développeurs d’Ethereum.
Conclusion : si la proposition aboutit, le coût des transactions à sécurité quantique baissera fortement, les applications axées confidentialité n’auront plus à être découragées par des frais de gas trop élevés, et la vitesse de confirmation des ZK-Rollups L2 pourra aussi nettement s’améliorer. À l’heure actuelle, la communauté a déjà ouvert plusieurs canaux de participation : modèles de simulation réseau, réseau de test, concours d’algorithmes, dépôts de code prototypes, etc. Nous sommes à un stade de co-construction précoce.
#以太坊扩容 #EIP #比特币现货ETF四日流入23.1亿美元
Problème central : Ethereum fait face depuis longtemps à une impasse où il est difficile de concilier sécurité quantique, protection de la confidentialité et évolutivité. Une transaction classique consomme environ 21 000 gas, et la vérification d’une signature ECDSA environ 4 000 gas ; en revanche, les signatures à sécurité quantique coûtent jusqu’à 100 000–300 000 gas, et les preuves de confidentialité ZK nécessitent au minimum 350 000 gas (parfois plus d’un million). Si l’on combine les deux (preuves STARK pour la sécurité quantique + la confidentialité), une seule transaction peut brûler environ 8 millions de gas — ce qui ferait chuter le TPS d’Ethereum de 25 à 0,25, le rendant quasiment inutilisable.
La solution proposée par Vitalik : le cœur de l’EIP-8288 consiste à déplacer les calculs cryptographiques coûteux vers le hors-chaîne.
Avant d’enregistrer la transaction on-chain, les nœuds agrègent dans le mempool les signatures/preuves de plusieurs utilisateurs en une preuve STARK, conçue avec une « structure de micro-trame » ; sur la chaîne, on ne conserve que des informations de dépendance de 65 à 96 octets. Les énormes données cryptographiques elles-mêmes ne sont pas stockées sur la chaîne. L’idée consiste à séparer la transaction en deux parties : « logique métier » et « tâche de vérification », la partie vérification étant traitée en parallèle hors-chaîne (via des sharding spécialisés).
Points forts : il s’agirait peut-être du premier cas où Ethereum introduit réellement l’ensemble d’instructions RISC-V ; cette approche s’appuie sur l’EIP-8141 à venir (abstraction native des comptes) ; après compression, la taille des données des blocs peut être contrôlée dans une fourchette de 100–300 Ko ; l’expérience développeur ne serait pas beaucoup modifiée, sans nécessiter de lourdes adaptations de la part des développeurs d’Ethereum.
Conclusion : si la proposition aboutit, le coût des transactions à sécurité quantique baissera fortement, les applications axées confidentialité n’auront plus à être découragées par des frais de gas trop élevés, et la vitesse de confirmation des ZK-Rollups L2 pourra aussi nettement s’améliorer. À l’heure actuelle, la communauté a déjà ouvert plusieurs canaux de participation : modèles de simulation réseau, réseau de test, concours d’algorithmes, dépôts de code prototypes, etc. Nous sommes à un stade de co-construction précoce.
#以太坊扩容 #EIP #比特币现货ETF四日流入23.1亿美元
120
·
--
【Compilation d’informations】 Des chercheurs sur Ethereum proposent l’EIP-8361 : limiter le taux de mise en jeu grâce à un « burn d’émission dégressif »
Récemment, un groupe de chercheurs sur Ethereum (dont Justin Drake, etc.) a rendu public un projet d’EIP-8361 (Tapered Issuance Burn).
En bref, le mécanisme :
1. La récompense des validateurs est calculée selon le ratio global de mise en jeu du réseau, puis une partie est déduite et détruite définitivement
2. Plus on met en jeu, plus le taux de combustion est élevé
3. Lorsque la mise en jeu active atteint 60,25 millions d’ETH (environ la moitié de l’offre), la combustion peut atteindre 100 %, de sorte que l’émission nette au niveau de la couche de consensus tend vers zéro
4. Pour atténuer l’impact sur les participants déjà mis en jeu, une période de transition d’environ 18 mois est prévue (la période de transition ajuste également les facteurs de récompense)
La motivation du projet penche plutôt du côté de la couche protocolaire : éviter les risques de centralisation et de capture liés à l’empilement illimité de mises en jeu, et préserver autant que possible le rôle neutre de l’ETH non mis en jeu en tant que monnaie. À ce stade, il s’agit toujours d’un « Draft » ; la communauté discute sur Eth Magicians / GitHub et il n’est pas certain que cela puisse être intégré aux prochaines mises à jour du réseau.
Sources :
The Block https://www.theblock.co/post/410643/ethereum-researchers-propose-burning-validator-rewards-cap-staking-50
CoinDesk https://www.coindesk.com/tech/2026/08/05/new-ethereum-proposal-would-cut-issuance-to-zero-if-staked-eth-reaches-usd112-billion
Projet https://github.com/pintail-xyz/EIPs/blob/edde78eb1feeb285906d5a8deb582c4feaecd6ba/EIPS/eip-draft_tapered_issuance_burn.md
#Ethereum #EIP
Compilation d’informations, pas un conseil en investissement
【Compilation d’informations】 Des chercheurs sur Ethereum proposent l’EIP-8361 : limiter le taux de mise en jeu grâce à un « burn d’émission dégressif »
Récemment, un groupe de chercheurs sur Ethereum (dont Justin Drake, etc.) a rendu public un projet d’EIP-8361 (Tapered Issuance Burn).
En bref, le mécanisme :
1. La récompense des validateurs est calculée selon le ratio global de mise en jeu du réseau, puis une partie est déduite et détruite définitivement
2. Plus on met en jeu, plus le taux de combustion est élevé
3. Lorsque la mise en jeu active atteint 60,25 millions d’ETH (environ la moitié de l’offre), la combustion peut atteindre 100 %, de sorte que l’émission nette au niveau de la couche de consensus tend vers zéro
4. Pour atténuer l’impact sur les participants déjà mis en jeu, une période de transition d’environ 18 mois est prévue (la période de transition ajuste également les facteurs de récompense)
La motivation du projet penche plutôt du côté de la couche protocolaire : éviter les risques de centralisation et de capture liés à l’empilement illimité de mises en jeu, et préserver autant que possible le rôle neutre de l’ETH non mis en jeu en tant que monnaie. À ce stade, il s’agit toujours d’un « Draft » ; la communauté discute sur Eth Magicians / GitHub et il n’est pas certain que cela puisse être intégré aux prochaines mises à jour du réseau.
Sources :
The Block https://www.theblock.co/post/410643/ethereum-researchers-propose-burning-validator-rewards-cap-staking-50
CoinDesk https://www.coindesk.com/tech/2026/08/05/new-ethereum-proposal-would-cut-issuance-to-zero-if-staked-eth-reaches-usd112-billion
Projet https://github.com/pintail-xyz/EIPs/blob/edde78eb1feeb285906d5a8deb582c4feaecd6ba/EIPS/eip-draft_tapered_issuance_burn.md
#Ethereum #EIP
Compilation d’informations, pas un conseil en investissement
Récemment, un groupe de chercheurs sur Ethereum (dont Justin Drake, etc.) a rendu public un projet d’EIP-8361 (Tapered Issuance Burn).
En bref, le mécanisme :
1. La récompense des validateurs est calculée selon le ratio global de mise en jeu du réseau, puis une partie est déduite et détruite définitivement
2. Plus on met en jeu, plus le taux de combustion est élevé
3. Lorsque la mise en jeu active atteint 60,25 millions d’ETH (environ la moitié de l’offre), la combustion peut atteindre 100 %, de sorte que l’émission nette au niveau de la couche de consensus tend vers zéro
4. Pour atténuer l’impact sur les participants déjà mis en jeu, une période de transition d’environ 18 mois est prévue (la période de transition ajuste également les facteurs de récompense)
La motivation du projet penche plutôt du côté de la couche protocolaire : éviter les risques de centralisation et de capture liés à l’empilement illimité de mises en jeu, et préserver autant que possible le rôle neutre de l’ETH non mis en jeu en tant que monnaie. À ce stade, il s’agit toujours d’un « Draft » ; la communauté discute sur Eth Magicians / GitHub et il n’est pas certain que cela puisse être intégré aux prochaines mises à jour du réseau.
Sources :
The Block https://www.theblock.co/post/410643/ethereum-researchers-propose-burning-validator-rewards-cap-staking-50
CoinDesk https://www.coindesk.com/tech/2026/08/05/new-ethereum-proposal-would-cut-issuance-to-zero-if-staked-eth-reaches-usd112-billion
Projet https://github.com/pintail-xyz/EIPs/blob/edde78eb1feeb285906d5a8deb582c4feaecd6ba/EIPS/eip-draft_tapered_issuance_burn.md
#Ethereum #EIP
Compilation d’informations, pas un conseil en investissement
115
·
--
La communauté Ethereum a récemment soumis une proposition d’EIP-12235. Elle prévoit d’introduire un tout nouveau contrat de dépôt conçu pour assurer une sécurité post-quantique, en vue de préparer l’écosystème Ethereum à long terme. Cette étape est très solide.
Les points clés de la proposition incluent :
1️⃣ Un nouveau contrat prenant en charge des clés publiques et des métadonnées de justificatifs de longueur variable, avec l’ajout d’un identifiant explicite de scheme. Le scheme 0 est réservé au mécanisme actuel de dépôts BLS
2️⃣ La suppression de la dépendance à la structure de l’arbre de Merkle du contrat de dépôt historique : à la place, l’exécution transmet les informations de dépôt à la couche de consensus via l’exécution dérivée des journaux selon l’EIP-7685
3️⃣ La mise en place d’un mode de transition irréversible contrôlé par le système de protocole : au départ, la fonctionnalité de dépôt est désactivée. Elle est ensuite activée en premier pour les dépôts BLS à un horodatage donné, puis les dépôts BLS sont définitivement arrêtés à un horodatage ultérieur, sans possibilité de réactivation
4️⃣ Pendant la migration, le client d’exécution doit fusionner à la fois les requêtes de dépôt du nouveau et de l’ancien contrat
Dans le contexte plus large des avancées de l’informatique quantique, la mise à niveau en amont de l’infrastructure de sécurité cryptographique est tout à fait nécessaire : après tout, la sécurité est la ligne de vie d’une blockchain.
$ETH
#以太坊 #后量子安全 #EIP
La communauté Ethereum a récemment soumis une proposition d’EIP-12235. Elle prévoit d’introduire un tout nouveau contrat de dépôt conçu pour assurer une sécurité post-quantique, en vue de préparer l’écosystème Ethereum à long terme. Cette étape est très solide.
Les points clés de la proposition incluent :
1️⃣ Un nouveau contrat prenant en charge des clés publiques et des métadonnées de justificatifs de longueur variable, avec l’ajout d’un identifiant explicite de scheme. Le scheme 0 est réservé au mécanisme actuel de dépôts BLS
2️⃣ La suppression de la dépendance à la structure de l’arbre de Merkle du contrat de dépôt historique : à la place, l’exécution transmet les informations de dépôt à la couche de consensus via l’exécution dérivée des journaux selon l’EIP-7685
3️⃣ La mise en place d’un mode de transition irréversible contrôlé par le système de protocole : au départ, la fonctionnalité de dépôt est désactivée. Elle est ensuite activée en premier pour les dépôts BLS à un horodatage donné, puis les dépôts BLS sont définitivement arrêtés à un horodatage ultérieur, sans possibilité de réactivation
4️⃣ Pendant la migration, le client d’exécution doit fusionner à la fois les requêtes de dépôt du nouveau et de l’ancien contrat
Dans le contexte plus large des avancées de l’informatique quantique, la mise à niveau en amont de l’infrastructure de sécurité cryptographique est tout à fait nécessaire : après tout, la sécurité est la ligne de vie d’une blockchain.
$ETH
#以太坊 #后量子安全 #EIP
Les points clés de la proposition incluent :
1️⃣ Un nouveau contrat prenant en charge des clés publiques et des métadonnées de justificatifs de longueur variable, avec l’ajout d’un identifiant explicite de scheme. Le scheme 0 est réservé au mécanisme actuel de dépôts BLS
2️⃣ La suppression de la dépendance à la structure de l’arbre de Merkle du contrat de dépôt historique : à la place, l’exécution transmet les informations de dépôt à la couche de consensus via l’exécution dérivée des journaux selon l’EIP-7685
3️⃣ La mise en place d’un mode de transition irréversible contrôlé par le système de protocole : au départ, la fonctionnalité de dépôt est désactivée. Elle est ensuite activée en premier pour les dépôts BLS à un horodatage donné, puis les dépôts BLS sont définitivement arrêtés à un horodatage ultérieur, sans possibilité de réactivation
4️⃣ Pendant la migration, le client d’exécution doit fusionner à la fois les requêtes de dépôt du nouveau et de l’ancien contrat
Dans le contexte plus large des avancées de l’informatique quantique, la mise à niveau en amont de l’infrastructure de sécurité cryptographique est tout à fait nécessaire : après tout, la sécurité est la ligne de vie d’une blockchain.
$ETH
#以太坊 #后量子安全 #EIP
56
·
--
📰 Exploit de Binance lié à une délégation EIP-7702, les pertes préliminaires s’accumulent
Fireblocks indique qu’une délégation EIP-7702 signée a permis des retraits depuis les portefeuilles chauds de Binance ; la mise à jour préliminaire de Binance évoque un ordinateur portable DevOps compromis. (Lire la suite)
Source : Blockchain News
Heure : 2026-10-30 19:59:28
Crédit : tony kim
#lazarus_group #binance #crypto-security #news #eip-7702
$ARB $BTC $USDT
Partagez votre avis dans les commentaires ci-dessous
📰 Exploit de Binance lié à une délégation EIP-7702, les pertes préliminaires s’accumulent
Fireblocks indique qu’une délégation EIP-7702 signée a permis des retraits depuis les portefeuilles chauds de Binance ; la mise à jour préliminaire de Binance évoque un ordinateur portable DevOps compromis. (Lire la suite)
Source : Blockchain News
Heure : 2026-10-30 19:59:28
Crédit : tony kim
#lazarus_group #binance #crypto-security #news #eip-7702
$ARB $BTC $USDT
Partagez votre avis dans les commentaires ci-dessous
Fireblocks indique qu’une délégation EIP-7702 signée a permis des retraits depuis les portefeuilles chauds de Binance ; la mise à jour préliminaire de Binance évoque un ordinateur portable DevOps compromis. (Lire la suite)
Source : Blockchain News
Heure : 2026-10-30 19:59:28
Crédit : tony kim
#lazarus_group #binance #crypto-security #news #eip-7702
$ARB $BTC $USDT
Partagez votre avis dans les commentaires ci-dessous
76
·
--
Voir la traduction
以太坊想把最终结算从约 16 分钟压到约 4 分钟。以太坊快速最终性研究协调人 Ben Edgington 联合 Francesco D'Amato、Roberto Saltini、Yann Vonlanthen、Mikhail Kalinin 提交 EIP 草案（编号 12566，已进正式流程），目标把最终确认缩约 4 倍。
为什么要快？跨链汇款服务得先垫资等确认：每小时稳定垫出 100 万美元，16 分钟延迟下约 26.7 万美元被占用，4 分钟就能降到约 6.7 万美元。
技术根因是验证者一票两用——既选区块又确认旧区块，确认只能跟着验证者轮换节奏走。草案把两票拆开，确认可独立提速，后续还能持续收紧；拆分投票后也更容易最终换上抗量子签名。起草人自己说 many aspects remain TBD，眼下的小目标只是拿个提案编号进以太坊正式升级管道——设计未完成，也没有激活日期，别当成板上钉钉。
对照看更有意思：Circle（CRCL）对快速跨链转 USDC 已经按速度收费——Ethereum 快速路由按 0.01%（每 1 万美元收 1 美元），另有限制快速转账总额；竞争端 Solana Alpenglow 目标最终性约 150 毫秒（昨日刚上线）。以太坊即便 4 分钟仍慢，但优势是主网安全性与规模。
来源：CoinDesk 与 EIP 草案（github.com/ethereum/EIPs/pull/12566）。
#ETH #以太坊 #EIP #跨链 #Circle
以太坊想把最终结算从约 16 分钟压到约 4 分钟。以太坊快速最终性研究协调人 Ben Edgington 联合 Francesco D'Amato、Roberto Saltini、Yann Vonlanthen、Mikhail Kalinin 提交 EIP 草案（编号 12566，已进正式流程），目标把最终确认缩约 4 倍。
为什么要快？跨链汇款服务得先垫资等确认：每小时稳定垫出 100 万美元，16 分钟延迟下约 26.7 万美元被占用，4 分钟就能降到约 6.7 万美元。
技术根因是验证者一票两用——既选区块又确认旧区块，确认只能跟着验证者轮换节奏走。草案把两票拆开，确认可独立提速，后续还能持续收紧；拆分投票后也更容易最终换上抗量子签名。起草人自己说 many aspects remain TBD，眼下的小目标只是拿个提案编号进以太坊正式升级管道——设计未完成，也没有激活日期，别当成板上钉钉。
对照看更有意思：Circle（CRCL）对快速跨链转 USDC 已经按速度收费——Ethereum 快速路由按 0.01%（每 1 万美元收 1 美元），另有限制快速转账总额；竞争端 Solana Alpenglow 目标最终性约 150 毫秒（昨日刚上线）。以太坊即便 4 分钟仍慢，但优势是主网安全性与规模。
来源：CoinDesk 与 EIP 草案（github.com/ethereum/EIPs/pull/12566）。
#ETH #以太坊 #EIP #跨链 #Circle
为什么要快？跨链汇款服务得先垫资等确认：每小时稳定垫出 100 万美元，16 分钟延迟下约 26.7 万美元被占用，4 分钟就能降到约 6.7 万美元。
技术根因是验证者一票两用——既选区块又确认旧区块，确认只能跟着验证者轮换节奏走。草案把两票拆开，确认可独立提速，后续还能持续收紧；拆分投票后也更容易最终换上抗量子签名。起草人自己说 many aspects remain TBD，眼下的小目标只是拿个提案编号进以太坊正式升级管道——设计未完成，也没有激活日期，别当成板上钉钉。
对照看更有意思：Circle（CRCL）对快速跨链转 USDC 已经按速度收费——Ethereum 快速路由按 0.01%（每 1 万美元收 1 美元），另有限制快速转账总额；竞争端 Solana Alpenglow 目标最终性约 150 毫秒（昨日刚上线）。以太坊即便 4 分钟仍慢，但优势是主网安全性与规模。
来源：CoinDesk 与 EIP 草案（github.com/ethereum/EIPs/pull/12566）。
#ETH #以太坊 #EIP #跨链 #Circle
10
Article
Vitalik dit qu’Ethereum deviendra une chaîne hybride avec FOCIL, EIP-8288 et confidentialité$Le fondateur d’Ethereum, Vitalik Buterin, vient de révéler la mise à jour la plus importante pour Ethereum après le fork Hegota.Il a déclaré qu’Ethereum n’est plus seulement une blockchain. Il deviendra une architecture hybride combinant blockchain + une cryptographie moderne comme les SNARKs, les STARKs, le FHE et l’Obfuscation. Qu’est-ce que le FOCIL ?🚀
FOCIL arrive dans la mise à niveau H-STARK. À l’heure actuelle, un seul constructeur peut censurer votre transaction. Avec FOCIL, 16 constructeurs co-créeront des blocs. Donc si vous envoyez une transaction, ELLE DOIT être incluse dans le prochain créneau. Aucune entité unique ne peut la retarder. C’est énorme pour la décentralisation. Qu’est-ce que l’EIP-8288 ?
Vitalik dit qu’Ethereum deviendra une chaîne hybride avec FOCIL, EIP-8288 et confidentialité
$Le fondateur d’Ethereum, Vitalik Buterin, vient de révéler la mise à jour la plus importante pour Ethereum après le fork Hegota.Il a déclaré qu’Ethereum n’est plus seulement une blockchain. Il deviendra une architecture hybride combinant blockchain + une cryptographie moderne comme les SNARKs, les STARKs, le FHE et l’Obfuscation. Qu’est-ce que le FOCIL ?🚀
FOCIL arrive dans la mise à niveau H-STARK. À l’heure actuelle, un seul constructeur peut censurer votre transaction. Avec FOCIL, 16 constructeurs co-créeront des blocs. Donc si vous envoyez une transaction, ELLE DOIT être incluse dans le prochain créneau. Aucune entité unique ne peut la retarder. C’est énorme pour la décentralisation. Qu’est-ce que l’EIP-8288 ?
FOCIL arrive dans la mise à niveau H-STARK. À l’heure actuelle, un seul constructeur peut censurer votre transaction. Avec FOCIL, 16 constructeurs co-créeront des blocs. Donc si vous envoyez une transaction, ELLE DOIT être incluse dans le prochain créneau. Aucune entité unique ne peut la retarder. C’est énorme pour la décentralisation. Qu’est-ce que l’EIP-8288 ?
1
70
·
--
Haussier
$BTC $ASTER
Avez-vous déjà été "blessé" par la montée soudaine des frais de Gas d'Ethereum ? Avez-vous déjà vu une transaction avec des frais plus élevés que le montant transféré pendant une congestion du réseau, sans pouvoir rien y faire ? 🤯 Ne vous inquiétez pas, Vitalik a récemment proposé un plan audacieux qui pourrait changer complètement la donne - établir un marché à terme pour le Gas d'Ethereum ! Ce n'est pas pour que les traders spéculent, mais pour que vous et moi puissions verrouiller à l'avance les prix du carburant et dire adieu à l'ère des fluctuations angoissantes ! 🚀
En termes simples, cette idée permet aux utilisateurs et aux développeurs de verrouiller à l'avance les prix futurs du Gas, comme s'ils achetaient une assurance. Fini le temps de "jouer à la loterie" à chaque fois que le réseau est occupé ! 📉
Pourquoi est-ce important ?
Actuellement, la volatilité extrême des frais de Gas est l'un des plus grands points douloureux d'Ethereum. C'est difficile à prédire, impossible à budgétiser, et c'est un véritable cauchemar lors de l'exécution d'applications à grande échelle. Un marché à terme vise à transformer le Gas d'une variable chaotique en un coût stable et prévisible.
Si cela réussit, quels en seront les bénéfices ?
✅ Les développeurs pourront établir des budgets en toute confiance, sans craindre la perte de contrôle des coûts.
✅ Les DApps fonctionneront de manière plus stable et fiable, et l'expérience utilisateur sera en forte hausse.
✅ $ETH ressemblera davantage à une véritable infrastructure, et ne sera pas seulement un réseau expérimental.
💡 L'essentiel est que : ce n'est pas pour spéculer sur les cryptomonnaies, mais pour rendre Ethereum utilisable et abordable au moment où il en a le plus besoin de stabilité - c'est-à-dire lorsque les transactions explosent et que le réseau est le plus congestionné. Actuellement, ce n'est qu'une proposition préliminaire, mais elle envoie un signal fort : Ethereum reste concentré sur la résolution de ces problèmes fondamentaux difficiles et peu attrayants qui influencent réellement l'adoption à long terme !
Pensez-vous que cette idée de "Gas à terme" peut réussir ? Deviendra-t-elle la pièce maîtresse de la large adoption d'Ethereum ? 🤔 Venez discuter de votre avis dans les commentaires ! ⬇️
#区块链 #Web3 #EIP #加密货币
$BTC $ASTER
Avez-vous déjà été "blessé" par la montée soudaine des frais de Gas d'Ethereum ? Avez-vous déjà vu une transaction avec des frais plus élevés que le montant transféré pendant une congestion du réseau, sans pouvoir rien y faire ? 🤯 Ne vous inquiétez pas, Vitalik a récemment proposé un plan audacieux qui pourrait changer complètement la donne - établir un marché à terme pour le Gas d'Ethereum ! Ce n'est pas pour que les traders spéculent, mais pour que vous et moi puissions verrouiller à l'avance les prix du carburant et dire adieu à l'ère des fluctuations angoissantes ! 🚀
En termes simples, cette idée permet aux utilisateurs et aux développeurs de verrouiller à l'avance les prix futurs du Gas, comme s'ils achetaient une assurance. Fini le temps de "jouer à la loterie" à chaque fois que le réseau est occupé ! 📉
Pourquoi est-ce important ?
Actuellement, la volatilité extrême des frais de Gas est l'un des plus grands points douloureux d'Ethereum. C'est difficile à prédire, impossible à budgétiser, et c'est un véritable cauchemar lors de l'exécution d'applications à grande échelle. Un marché à terme vise à transformer le Gas d'une variable chaotique en un coût stable et prévisible.
Si cela réussit, quels en seront les bénéfices ?
✅ Les développeurs pourront établir des budgets en toute confiance, sans craindre la perte de contrôle des coûts.
✅ Les DApps fonctionneront de manière plus stable et fiable, et l'expérience utilisateur sera en forte hausse.
✅ $ETH ressemblera davantage à une véritable infrastructure, et ne sera pas seulement un réseau expérimental.
💡 L'essentiel est que : ce n'est pas pour spéculer sur les cryptomonnaies, mais pour rendre Ethereum utilisable et abordable au moment où il en a le plus besoin de stabilité - c'est-à-dire lorsque les transactions explosent et que le réseau est le plus congestionné. Actuellement, ce n'est qu'une proposition préliminaire, mais elle envoie un signal fort : Ethereum reste concentré sur la résolution de ces problèmes fondamentaux difficiles et peu attrayants qui influencent réellement l'adoption à long terme !
Pensez-vous que cette idée de "Gas à terme" peut réussir ? Deviendra-t-elle la pièce maîtresse de la large adoption d'Ethereum ? 🤔 Venez discuter de votre avis dans les commentaires ! ⬇️
#区块链 #Web3 #EIP #加密货币
Avez-vous déjà été "blessé" par la montée soudaine des frais de Gas d'Ethereum ? Avez-vous déjà vu une transaction avec des frais plus élevés que le montant transféré pendant une congestion du réseau, sans pouvoir rien y faire ? 🤯 Ne vous inquiétez pas, Vitalik a récemment proposé un plan audacieux qui pourrait changer complètement la donne - établir un marché à terme pour le Gas d'Ethereum ! Ce n'est pas pour que les traders spéculent, mais pour que vous et moi puissions verrouiller à l'avance les prix du carburant et dire adieu à l'ère des fluctuations angoissantes ! 🚀
En termes simples, cette idée permet aux utilisateurs et aux développeurs de verrouiller à l'avance les prix futurs du Gas, comme s'ils achetaient une assurance. Fini le temps de "jouer à la loterie" à chaque fois que le réseau est occupé ! 📉
Pourquoi est-ce important ?
Actuellement, la volatilité extrême des frais de Gas est l'un des plus grands points douloureux d'Ethereum. C'est difficile à prédire, impossible à budgétiser, et c'est un véritable cauchemar lors de l'exécution d'applications à grande échelle. Un marché à terme vise à transformer le Gas d'une variable chaotique en un coût stable et prévisible.
Si cela réussit, quels en seront les bénéfices ?
✅ Les développeurs pourront établir des budgets en toute confiance, sans craindre la perte de contrôle des coûts.
✅ Les DApps fonctionneront de manière plus stable et fiable, et l'expérience utilisateur sera en forte hausse.
✅ $ETH ressemblera davantage à une véritable infrastructure, et ne sera pas seulement un réseau expérimental.
💡 L'essentiel est que : ce n'est pas pour spéculer sur les cryptomonnaies, mais pour rendre Ethereum utilisable et abordable au moment où il en a le plus besoin de stabilité - c'est-à-dire lorsque les transactions explosent et que le réseau est le plus congestionné. Actuellement, ce n'est qu'une proposition préliminaire, mais elle envoie un signal fort : Ethereum reste concentré sur la résolution de ces problèmes fondamentaux difficiles et peu attrayants qui influencent réellement l'adoption à long terme !
Pensez-vous que cette idée de "Gas à terme" peut réussir ? Deviendra-t-elle la pièce maîtresse de la large adoption d'Ethereum ? 🤔 Venez discuter de votre avis dans les commentaires ! ⬇️
#区块链 #Web3 #EIP #加密货币
5
375
Connectez-vous pour découvrir plus de contenu
Rejoignez la communauté mondiale des adeptes de cryptomonnaies sur Binance Square
⚡️ Suviez les dernières informations importantes sur les cryptomonnaies.
💬 Jugé digne de confiance par la plus grande plateforme d’échange de cryptomonnaies au monde.
👍 Découvrez les connaissances que partagent les créateurs vérifiés.
Adresse e-mail/Nº de téléphone
Sujets d’actualité
1
#CryptoSelloffTriggersMultipleWhaleLiquidations
67,893 vues
862 mentions
2
#USSpotXRPETFsSeeLargestWeeklyOutflowIn8Months
88,557 vues
1,024 mentions
3
#WillFOMCMinutesReinforceRateHikeExpectations?
15,748 vues
356 mentions
4
#BitcoinActiveSupplyInProfitDropsBelow45%
158,746 vues
1,367 mentions
5
#TONStrategyReports$23.97MQ3NetLoss
15,825 vues
109 mentions
6
#KavaSaysAbnormalActivityLimitedToKavaLend
103,403 vues
754 mentions
7
#WORPTLetsTouristsConvertCryptoToThaiBaht
28,367 vues
272 mentions
8
#WhoWillSucceedJensenHuangatNvidia?
285,618 vues
2,021 mentions
9
#WhatWillDriveCryptoandStocks’NextRebound?
770,571 vues
3,824 mentions
10
#TradFiForBeginners
802,463 vues
4,815 mentions