La Fondation Ethereum a récemment ouvert le testnet public Platåberget, afin de s’entraîner en amont à la prochaine grande mise à niveau Glamsterdam (Gloas + Amsterdam).
Cette fois, ce n’est pas seulement « encore un testnet » : les règles de base vont changer dans pas mal d’endroits, notamment : • Proposer-Builder Separation (ePBS) intégré au protocole • Access List au niveau des blocs (BAL) • Repricing du gas, avec l’introduction d’une dimension de facturation basée sur les « octets d’état »
Pour les utilisateurs ordinaires, le point le plus directement visible est le suivant : auparavant, l’expérience selon laquelle « un transfert ETH standard = 21000 gas » est l’hypothèse par défaut. Elle devra désormais être réécrite. Si vous envoyez vers une nouvelle adresse jamais utilisée auparavant, comme il faut créer un compte, vous paierez en plus des frais liés à l’état. Les portefeuilles, indexeurs et outils d’estimation du gas qui auraient encore des hypothèses anciennes codées en dur peuvent donc se tromper.
La Fondation rappelle également : les outils qui dépendent de valeurs de gas maximales codées en dur doivent être mis à jour. Les développeurs peuvent d’abord tester sur Platåberget, puis suivre le calendrier des prochains testnets longue durée et du mainnet.
Le prochain grand upgrade d’Ethereum, « Glamsterdam », apporte un changement très concret : le passage à ETH n’est plus systématiquement un gas fixe de 21000.
D’après les explications de la Fondation Ethereum : transférer vers une adresse déjà existante revient encore à environ 21000 ; transférer vers une nouvelle adresse jamais vue sur la blockchain entraîne en plus des frais de gas liés à l’état (le réseau doit créer et conserver à vie l’état de ce compte). Si un portefeuille, un navigateur ou un estimateur de gas continue de considérer 21000 comme un plafond « mort », une fois la mise en ligne sur le réseau principal, le calcul des frais peut échouer ou la transaction être refusée.
L’EF a ouvert le testnet public Plataberget afin d’aider portefeuilles et dApps à anticiper les pièges. La mise à niveau inclut aussi ePBS, Block-level Access Lists, et une hausse de la limite de volume des contrats, entre autres. En ce moment, l’ensemble est encore en phase de test/durcissement ; cette semaine, les utilisateurs ordinaires n’ont pas besoin d’agir, l’effort principal concerne les développeurs et l’infrastructure.
Le prochain grand upgrade d’Ethereum, Glamsterdam, apporte un détail assez pointu : la règle empirique de longue date selon laquelle un virement « ETH standard » (transfert simple) coûte fixe 21 000 gas va changer.
D’après un article de CoinDesk et des explications de la Fondation Ethereum : transférer des fonds vers un compte déjà existant coûtera toujours environ 21 000 gas ; en revanche, envoyer à une nouvelle adresse qui n’a jamais interagi avec la blockchain inclura en plus un lot de « state gas » (l’article mentionne environ 183 600 unités) — car le réseau doit créer et conserver durablement l’état de ce nouveau compte. Les deux opérations ne demandent pas le même travail, mais auparavant elles étaient facturées au même prix.
Pour les utilisateurs ordinaires, pas de panique : le changement sera d’abord validé sur des réseaux de test (comme Platåberget). Le vrai point à surveiller, ce sont les portefeuilles, les navigateurs et les outils d’estimation des frais : si vous continuez à considérer 21 000 comme une borne codée en dur, vous pourriez vous retrouver avec des transactions refusées (ou des devis insuffisants).
Au niveau du protocole, le modèle de tarification devient plus fin pour la « croissance de l’état », ce qui colle davantage aux contraintes réelles côté clients et ingénierie des portefeuilles que le seul débat sur le TPS.
【Notes sur le protocole】La prochaine grosse mise à niveau d’Ethereum pourrait modifier le « 21000 gas » par défaut des portefeuilles
D’après CoinDesk (environ il y a 1 jour), dans la mise à niveau Glamsterdam en projet : l’hypothèse selon laquelle, par défaut, tout transfert « simple » d’ETH coûte systématiquement 21000 gas serait décomposée —
• Pour les transferts vers une adresse déjà existante : cela resterait globalement basé sur la structure à ~21000 • Pour les transferts vers une adresse jamais utilisée auparavant : il faut en plus supporter le coût de création du compte et d’écriture dans l’état (gas d’état)
La Fondation Ethereum, dans ses explications du 17/8 concernant le testnet Platåberget, mentionne également que la création de compte, le déploiement de code, l’écriture de nouvelles “cases” de stockage, etc. fera l’objet d’une nouvelle tarification ; tout outil qui “fixe” un gas limit en dur pourrait donc être impacté.
Pour les portefeuilles et les dApp, l’enjeu n’est pas tant de crier à la hausse ou à la baisse, que d’adapter l’ingénierie : 1)Les estimations de frais ne peuvent plus être systématiquement fixées à 21000 2)Les modèles de coût des airdrops / des premiers transferts doivent être recalculés 3)Côté utilisateur, il faut pouvoir expliquer « pourquoi cette transaction est plus chère »
Les discussions relatives à d’autres pistes peuvent être mises en parallèle avec les débats de re-tarification du gas comme EIP-8037 / EIP-2780. La mise à niveau continue d’avancer en développement et en tests ; les détails dépendront de l’implémentation finale du client.
La prochaine grande mise à niveau d’Ethereum, Hegotá (objectif : environ 2027), est en train de rassembler la liste des propositions~
D’après CoinDesk et d’autres sources, il y a actuellement environ 66 EIP sur la table. Lors des prochaines étapes, les core dev vont sélectionner celles qui peuvent être réalisées, qui peuvent être testées et qui ont une chance d’être mises en œuvre à temps. Les avancées les plus claires concernent pour l’instant des aspects orientés vers la résistance à la censure, avec FOCIL (EIP-7805).
Un autre point technique à surveiller : les Frame Transactions (EIP-8141), ainsi que les Keyed Nonces et Recent Roots. Les discussions portent sur l’ajout d’outils davantage « au niveau du protocole » pour les applications de confidentialité, avec moins de dépendance aux relayer externes. Il faut préciser : un simple transfert d’ETH ne deviendra pas une confidentialité « sur toute la chaîne » ; l’effet de dissimulation repose toujours principalement sur la conception applicative.
Les documents publics sont disponibles sur : eips.ethereum.org (EIP-7805 / 8141, etc.). Ce qui sera finalement retenu dépendra de l’implémentation côté clients et de l’avancement des réseaux de test.
Voici une mise à jour d’infrastructure plutôt « hard core » : World Chain (Ethereum L2 basé sur OP Stack) active, comme prévu, sur le réseau principal des listes d’accès au niveau des blocs (Block-Level Access Lists, BALs) via le streaming EIP-7928.
Voici comment comprendre le point technique : 1) Auparavant, de nombreux clients devaient exécuter les transactions d’un bloc dans l’ordre pour déterminer les dépendances d’état. 2) EIP-7928 permet au bloc d’enregistrer clairement quels comptes et quels slots de stockage ont été lus/écrits dans ce bloc, ce qui facilite les lectures disque en parallèle, les vérifications en parallèle, et ouvre la voie à un futur accroissement du débit. 3) World Chain intègre aussi cela à flashblock : environ toutes les ~200 ms, la liste d’accès est poussée en streaming, et la validation peut ainsi se faire en parallèle au fur et à mesure que les blocs sortent. Des articles publics mentionnent que l’objectif est d’augmenter le débit sans relever le seuil matériel des validateurs (les chiffres exacts dépendront des sources officielles et des mesures).
Côté réseau principal Ethereum, EIP-7928 suit toujours la voie standard de discussion / de mise à niveau ultérieure (souvent, le public l’associe à la feuille de route « Glamsterdam »). Pour le L2, l’activation se fait d’abord via un runtime flag : c’est comme une répétition d’ingénierie effectuée en amont pour l’écosystème.
Vérification rapide côté projet : le dépôt public worldcoin/world-chain est un monorepo Rust, open source sous licence MIT, avec encore récemment des commits/PR continus (y compris des correctifs liés aux proofs et à flashblock). Ce n’est donc pas juste une coquille de page de promotion.
【Dossier d’actualités】 Le laboratoire de la Banque d’Angleterre sur la livre numérique — Phase 2 : les stablecoins et la CBDC peuvent-ils régler ensemble les paiements ?
D’après CoinDesk, le Digital Pound Lab de la Banque d’Angleterre (BoE) est entré dans sa deuxième phase, avec pour objectif de tester si les stablecoins publics et les monnaies numériques de banque centrale (livre sterling numérique) peuvent coopérer dans le cadre d’un même flux de paiement pour le financement du commerce transfrontalier.
Les participants incluent NOBO Finance, Dun & Bradstreet et Polygon Labs. L’un des scénarios envisagés : l’exportateur pourrait d’abord obtenir une avance de financement sur facture via un stablecoin, tandis que l’importateur britannique finaliserait le règlement en livre sterling numérique. Côté Polygon, la société fournit l’infrastructure de règlement liée à Open Money Stack pour des stablecoins (conversion fiduciaire, portefeuilles, contrats intelligents, etc.), et tente de combiner les données de transactions de portefeuille avec des informations de crédit des entreprises afin de créer un profil de crédit réutilisable pour les PME.
Il faut clarifier les limites : le laboratoire ne concerne pas de vrais clients ni de vrais fonds, et ne signifie pas non plus que le Royaume-Uni a décidé d’émettre une livre numérique. Il s’agit surtout d’évaluer comment différentes formes de monnaies numériques peuvent être interopérables, et si cela peut réduire les frictions de vérification et de règlement dans le financement du commerce des PME.
Source : CoinDesk https://www.coindesk.com/business/2026/08/12/bank-of-england-to-test-stablecoin-digital-currency-use-in-cross-border-finance BOE Digital Pound Lab https://www.bankofengland.co.uk/the-digital-pound/lab
Synthèse d’informations, ne constitue pas un conseil en investissement
【Notes techniques】À quoi s’occupent les équipes d’ingénierie côté Solana
En regardant le Changelog officiel du 13/08, c’est plutôt hard-core, sans parler de prix :
1)Compression continue du temps de slot sur le réseau de test : il y a déjà des “feature gates” de 350→300 ms puis 300→250 ms, et le client se prépare à un rythme de production de blocs plus court. 2)Itérations en parallèle entre plusieurs clients : Agave dispose récemment d’une version stable v4.2.x et avance vers la v4.3 ; Firedancer / Frankendancer ont aussi des versions correspondantes. 3)Préparation du chemin pour Alpenglow : par exemple, paralléliser la vérification des votes BLS afin de réduire le risque que le “pic” de votes sature la vérification des nœuds.
Comment interpréter ces deux axes : • Raccourcir le slot ≈ augmenter la fréquence de production (activation par étapes, tout en restant attentif à la stabilité du réseau) • Alpenglow est une refonte majeure du consensus : dans les documentations publiques, l’objectif le plus souvent cité consiste à faire passer la confirmation finale d’un ordre de grandeur de plusieurs dizaines de secondes à environ 150 ms — la fenêtre du réseau principal peut encore varier en fonction des ajustements des tests
Côté code : vérification rapide. Agave (anza-xyz/agave) a encore, ces derniers jours, des commits et des releases très fréquents : c’est une progression d’ingénierie continue, pas un récit vide.
Solana a failli déclencher un seuil de gel : un cours fondamental sur l’infrastructure, pas une publication de “cotes”.
D’après CoinDesk et la plateforme de staking Marinade : un incident de routage survenu chez un grand fournisseur de centres de données a temporairement fait tomber la connexion d’environ 29 % du SOL staké. La conception de Solana est la suivante : si environ plus d’un tiers du poids de staking passe hors ligne, le réseau ne peut plus achever la finalité (confirmation finale des transactions). Marinade affirme qu’à ce moment-là, il ne manquait qu’environ 20 millions d’unités de staking pour atteindre ce seuil.
Quelques points techniques à retenir : 1) La source de la panne viserait un mauvais routage au sein du data center de Teraswitch à Miami, avec un impact sur une partie des nœuds en Europe et en Asie ; en Amérique du Nord, l’essentiel restait en ligne. 2) Le rapport indique qu’un seul opérateur réseau (AS2032) aurait détenu temporairement plus d’un quart du poids de staking ; le degré de concentration en lui-même constitue un facteur de risque. 3) La réparation du routage a pris environ 10 minutes ; la Solana Foundation souligne que la production continue de blocs et l’enregistrement des transactions se poursuivaient : environ 597/699 validateurs ayant du staking ont maintenu leurs votes — plus proche d’un test de résistance que d’un arrêt complet.
Observation : la décentralisation d’une chaîne hautes performances ne se limite pas au nombre de validateurs ; il faut aussi vérifier si les data centers, les ASN et les bascules de secours sont réellement répartis. S’approcher du seuil des 1/3 revient à faire passer tout le réseau pour un cours magistral.
Chaîne à preuve zéro ZK Miden annonce un stablecoin de confidentialité USDCx : 1:1 adossé aux réserves de xReserve, appuyées par Circle USDC. Les transactions ne sont par défaut pas rendues publiques en ce qui concerne les soldes, les contreparties et les flux, mais une divulgation sélective peut être faite à des fins d’audit ou de réglementation.
Les points techniques clés sont la preuve côté client — la transaction s’exécute sur l’appareil de l’utilisateur et génère une preuve, qui est ensuite vérifiée en chaîne, dans le but de combiner la confidentialité recherchée par les institutions avec une vérification vérifiable sur la blockchain. L’annonce officielle indique que l’objectif est un déploiement synchronisé avec le mainnet (vers la fin de ce mois), couvrant des cas d’usage tels que les paiements, les transactions, la paie et la gestion des fonds des entreprises.
Miden a été scindé de Polygon et constitue désormais une entité indépendante ; du côté du code open source, les dépôts Rust comme miden-vm / protocol / node continuent de recevoir des contributions régulières ces derniers temps. La date exacte du mainnet et d’USDCx dépend des annonces officielles.
Revue d’informations : MoneyGram Ramps est désormais en ligne sur Solana.
En bref, les portefeuilles, les exchanges et les applications peuvent relier le réseau mondial de cash de MoneyGram à la chaîne via une même API : les dépôts en espèces couvrent 25+ pays, et les retraits couvrent 170+ pays et régions. Les utilisateurs n’ont pas besoin d’intégrer chaque banque via chaque application, et les développeurs sont aussi soulagés d’une couche d’infrastructure.
Pour le récit des paiements sur Solana, c’est assez concret : les stablecoins ne sont pas seulement des paires de trading, mais aussi des points d’entrée et de sortie capables de s’intégrer aux services hors ligne, y compris les guichets des réseaux de cash. MoneyGram était déjà présent sur Solana en tant que validateur ; cette fois, il intègre directement son produit Ramps à l’écosystème (Rift fait partie des premiers partenaires).
【Rassemblement d’actualités】La feuille de route d’Ethereum change : la confidentialité et la résistance aux attaques quantiques passent au premier plan
Vitalik a récemment comparé le schéma de feuille de route classique de 2023 avec le Strawmap (références de mises à jour de protocole, aperçu jusqu’en gros à 2029) que la Fondation Ethereum met à jour en continu.
Il dit que ce qui frappe le plus n’est pas « ce qui est encore là », mais une série d’orientations qui n’existaient même pas sur le schéma de 2023 et qui sont désormais au cœur du sujet :
1) Forte confidentialité : des pools de confidentialité, des wormholes, etc., afin d’exposer le moins possible l’historique complet des transactions ; des conceptions liées à la résistance à la censure (comme FOCIL) figurent aussi dans la feuille de route 2) Résistance aux attaques quantiques : intégrer la sécurité cryptographique à long terme dans le north star (par exemple des directions basées sur le hash) 3) Lean Ethereum : des spécifications plus épurées ; à long terme, il est aussi question d’évolutions de la forme des environnements d’exécution 4) Une fois la technologie zk plus mature, d’autres voies comme le native rollup pourront également être davantage discutées
Les cinq grandes directions que Strawmap liste lui-même : un L1 plus rapide, un débit plus élevé (gigagas L1 / teragas L2), un L1 post-quantique, et le fait de considérer la confidentialité comme une citoyenne de plein droit.
Ce n’est pas un contenu destiné à donner des signaux d’achat/vente : c’est plutôt une coordination publique au niveau des protocoles. L’objectif est, en étendant les performances, de tenir aussi la confidentialité, la résistance à la censure et la sécurité à long terme. Strawmap insiste également sur le fait qu’il s’agit d’un strawman / d’un document vivant, et non d’un calendrier figé.
Notes techniques|Tentative de fourche Bitcoin BIP-110 : après deux blocs, quasi à l’arrêt
Le BIP-110 (Reduced Data Temporary Softfork) vise à resserrer, « temporairement pendant un an », au niveau du consensus, les données non financières pouvant être intégrées dans les transactions : limitation des scriptPubKey / données de témoin trop volumineuses, rétablissement de limites plus strictes pour les OP_RETURN, etc. Les partisans estiment que des données de type inscriptions accaparent l’espace destiné aux paiements et augmentent les coûts pour les nœuds ; les opposants, eux, pensent que si des frais sont payés, l’espace de bloc doit pouvoir être utilisé librement.
Pendant la fenêtre d’activation, les signaux des mineurs ne représentent qu’environ 2,53 %, bien en dessous du seuil de 55 %. À partir du bloc 961 632, les nœuds exécutant des clients BIP-110 commencent à refuser les blocs qui n’ont pas été signalés, ce qui déclenche une chaîne de fourche minoritaire.
Le mécanisme le plus intéressant, sur le plan technique, est la difficulté : la chaîne de fourche hérite de la difficulté actuelle d’extraction du réseau principal, mais avec une part de puissance de calcul extrêmement faible. En conséquence, l’intervalle entre les blocs est étiré jusqu’à plusieurs heures ; la difficulté ne sera recalculée qu’après 2016 blocs. Résultat : côté fourche, on n’arrive à extraire qu’environ 2 blocs avant un quasi-arrêt, avec un écart de progression par rapport à la chaîne principale de l’ordre d’environ une journée.
Autre avertissement pratique : au début de la fourche, les deux chaînes peuvent encore accepter des transactions au même format, ce qui implique un risque de « replay »—une transaction de vente signée sur la monnaie issue de la fourche pourrait aussi être rejouée sur le réseau principal. Lorsqu’on observe un événement de fourche, les détails techniques comptent davantage que les slogans.
Sources : CoinDesk https://www.coindesk.com/tech/2026/08/09/controversial-bitcoin-fork-bip-110-mines-two-blocks-then-stops Spécification du BIP-110 https://github.com/bitcoin/bips/blob/master/bip-0110.mediawiki
Synthèse de l’information, pas un conseil en investissement
Sui annonce récemment officiellement la progression de ses capacités de signatures résistantes aux attaques quantiques, en suivant une feuille de route déjà standardisée par le NIST :
1) Comptes du quotidien : prise en charge native prévue de ML-DSA-65 (FIPS 204) 2) Coffres de grande valeur : utilisation, dans des contrats Move, de SLH-DSA-SHA2-128s basé sur le hachage
Officiellement, l’implémentation centrale serait déjà achevée et a fait l’objet de benchmarks. La feuille de route, en gros : objectif de coffre quantiquement sécurisé cette année sur le réseau principal ; comptes natifs ML-DSA-65 sur le réseau de test d’ici fin d’année ; objectif d’authentification des comptes sur le réseau principal pour le 1er trimestre 2027. Le design est optionnel : activable, dérivable depuis les phrases mnémoniques existantes, et ne force pas tout le monde à changer de clés immédiatement.
Le point technique : faire passer la sécurité post-quantique de la simple discussion vers une capacité évolutive au niveau des protocoles / des portefeuilles, plutôt que d’en faire un récit axé sur les prix. Pour les détails, se référer au blog officiel.
【Note technique】XRPL 3.3.0 : « Montants dissimulables, registre toujours vérifiable » pour les institutions RWA
Le client du registre XRP, rippled, a publié cette semaine la version 3.3.0 (GitHub XRPLF/rippled, ~6/8). Parmi les amendements, le plus à surveiller est Confidential Transfers (transferts confidentiels) :
• Conçu pour le Multi-Purpose Token (MPT, format couramment utilisé pour les actifs tokenisés d’entreprise) • Les adresses de comptes et le type de jeton restent publics • Le solde et les montants transférés peuvent être chiffrés ; le registre utilise des preuves cryptographiques pour établir l’équilibre « entrées/sorties », sans exposer les chiffres précis à tout le réseau • La première version nécessite un opt-in volontaire de la part des détenteurs, et couvre surtout les paiements MPT directs entre comptes (ne comprend pas pour l’instant les parcours via DEX intégré, custody, etc.)
La même version regroupe aussi des capacités orientées opérations en entreprise : Batch (jusqu’à 8 opérations regroupées, soit toutes exécutées soit aucune), Sponsor (paiement des frais / réserves pour le compte d’autrui ; un nouvel utilisateur n’a pas besoin d’avoir d’abord amassé du XRP), Permission Delegation (autoriser uniquement certains types de transactions) et Dynamic MPT, etc. Côté officiel/maintenance, il est également mentionné une réduction de l’occupation mémoire d’environ 10 % à 15 % et un suivi de blocs plus rapide.
Point important : ces amendements ne sont pas encore activés. Sur l’XRPL, ils ne le seront que si les validateurs dignes de confiance atteignent pendant deux semaines consécutives ≥80 % de soutien. CoinDesk cite RWA.xyz : sur l’XRPL, la taille des RWA déjà distribuées est d’environ 1,38 milliard de dollars (incluant RLUSD, etc.), dont les actifs tokenisés hors RLUSD représentent environ 530 millions+ ; une fois la fonctionnalité déployée, le point clé sera de savoir si des émetteurs comme Aviva, Ondo, etc. ouvriront réellement le mode crypto.
En bref : un correctif au niveau du protocole pour la « confidentialité conforme + l’expérience opérationnelle des institutions », pas un récit sur le prix.
Source : • CoinDesk : https://www.coindesk.com/tech/2026/08/07/new-xrp-ledger-amendments-target-usd530-million-in-tokenized-wall-street-assets • Version GitHub 3.3.0 : https://github.com/XRPLF/rippled/releases/tag/3.3.0 • Notes de publication : https://xrpl.org/blog/2026/xrpld-3.3.0
Synthèse des informations, pas un conseil en investissement
【Notes techniques】Sui annonce officiellement l’avancée des signatures résistantes aux attaques quantiques
Le blog officiel de Sui (6/8) indique qu’il va intégrer deux ensembles de signatures quantiques normalisées par le NIST : • Comptes du quotidien : ML-DSA-65 (FIPS 204) utilisé comme signature native du protocole • Coffres de grande valeur : dans des contrats Move, utilisation de SLH-DSA-SHA2-128s (FIPS 205)
Points plus concrets : les clés peuvent encore être dérivées à partir des mnémoniques existantes ; en s’appuyant sur les address aliases déjà déployés, les comptes peuvent mettre à jour les clés d’autorisation sans avoir besoin de déplacer d’abord les actifs. La feuille de route est, à grands traits, : objectif “coffres résistants au quantique” sur le réseau principal cette année ; objectif “comptes natifs ML-DSA” sur le testnet d’ici la fin de l’année, puis réseau principal au 1er trimestre 2027 (le calendrier reste ajusté en fonction des audits et des retours des testnets).
The Block, entre autres, a également fait le point. L’essence, c’est une cryptographie “plug-and-play” : on ajoute un schéma de signature sans modifier le consensus ni l’état existant.
【Notes techniques】Validation parallèle : commencer par exécuter L2
Dernière mise à jour plutôt « côté couche protocole » : World Chain (OP Stack L2 de l’écosystème World) annonce qu’elle activera, sur le réseau principal, des listes d’accès complètes aux blocs (Block Access Lists / BALs). Les BALs seront intégrées en continu dans Flashblocks : une tranche de la liste d’accès est incluse à chaque incrément de sous-bloc, environ toutes les 200 ms. Officiellement, Sepolia a été ouverte le 27/07, et l’objectif pour le réseau principal est le 17/08. L’activation se fait via un commutateur (runtime), sans attendre une fourche dure.
Pourquoi ça vaut le coup de regarder ? • La validation traditionnelle doit rejouer les blocs en série, dans l’ordre des transactions : les dépendances d’état bloquent la parallélisation • EIP-7928 fait que chaque bloc emporte un enregistrement de ce qui a été « lu/écrit » (comptes et slots de stockage) + les valeurs après coup • Les nœuds de validation peuvent ainsi vérifier en parallèle, préchauffer l’état et répartir le coût de validation pendant la production des blocs, plutôt que de tout calculer une seule fois à la fin du bloc • Description des tests officiels : même avec un débit plus élevé (des rapports/articles de blog évoquent un benchmark visant ~1 Ggas/s), la latence de validation reste relativement stable. L’idée clé est : « augmenter le débit sans augmenter proportionnellement le matériel de validation »
Et ensuite : les BALs font aussi partie des directions mises en avant dans les discussions autour de la mise à jour Glamsterdam d’Ethereum ; sur L2, on teste d’abord sur la voie de production, puis on renvoie les retours à L1 : c’est un rythme typique de collaboration au sein d’un écosystème.
Côté code : le monorepo Rust worldcoin/world-chain a encore ces derniers jours des commits et PR liés à Flashblocks / proofs ; ce n’est pas de la simple communication à vide.
Sources (à vérifier) : • The Block : https://www.theblock.co/post/410651/world-chain-first-production-l2-block-access-lists-via-flashblocks • Blog d’ingénierie World : https://world.org/blog/engineering/world-chain-full-block-access-lists • EIP-7928 : https://eips.ethereum.org/EIPS/eip-7928 • GitHub : https://github.com/worldcoin/world-chain
Synthèse d’informations, pas un conseil en investissement
【Notes de protocole】Solana veut réévaluer les transactions qui « consomment vraiment des ressources »
Aujourd’hui, CoinDesk rapporte que les validateurs apportent un signal de gouvernance pour deux propositions liées : SIMD-0553 et SIMD-0550.
Le crochet technique n’est pas compliqué, mais il est crucial : 1)Situation actuelle : la redevance de base est facturée en grande partie selon le nombre de signatures ; une fois les signatures vérifiées, la proportion de compute consommée dans les frais de base est presque identique. 2)SIMD-0553 : scinder les frais en « frais d’inclusion dans un bloc + frais de ressources ». Les frais de ressources sont facturés selon les « cost units » demandées par la transaction, puis entièrement détruits ; les transactions légères (comme un vote ou une mise à jour d’oracle) peuvent coûter moins cher, tandis que les transactions lourdes de calcul coûteront davantage. 3)En estimant à grands traits l’activité récente on-chain, la quantité quotidienne détruite passerait d’environ 650 SOL à un ordre de grandeur de 7 500–9 000 SOL. Même ainsi, c’est clairement inférieur à l’ordre de grandeur de l’émission quotidienne, donc à elle seule, la mesure ne rendra pas le réseau déflationniste. 4)SIMD-0550 : doubler environ le rythme de la déflation, en avançant le moment où l’inflation terminale d’environ 1,5% survient, de 2032 vers autour de 2029.
À l’heure actuelle, les documents des deux propositions ont été fusionnés dans le processus SIMD sur GitHub ; pour savoir si elles seront effectives sur le réseau principal, il faudra voir si les signaux de mise (staking) franchissent le seuil, ainsi que le vote officiel ultérieur (fenêtre de signal jusqu’à environ le 18/08).
En une phrase : il s’agit d’utiliser la conception de mécanismes pour inscrire dans la facture la « consommation de ressources d’ordonnancement et d’exécution », plutôt que de facturer uniquement selon le nombre de signatures.