昵称7天才能修改一次

【协议笔记】以太坊下一次大升级，可能改掉钱包默认的「21000 gas」

据 CoinDesk（约 1 天前）整理：在规划中的 Glamsterdam 升级里，长期默认「普通 ETH 转账一律 21000 gas」的假设会被拆开——

• 转给已存在地址：仍大致按 21000 那套结构
• 转给从未上过链的新地址：还要额外承担创建账户/写入状态的成本（状态 gas）

以太坊基金会 8/17 关于 Platåberget 测试网的说明也提到：账户创建、部署代码、写新存储槽等会重定价；任何把 gas limit 写死的工具都可能受影响。

对钱包和 dApp 来说，重点不是喊涨跌，而是工程适配：
1）费用估算不能再一律写死 21000
2）空投/首次转账的成本模型要重算
3）用户侧要能解释「为什么这笔更贵」

相关方向可对照 EIP-8037 / EIP-2780 等 gas 重定价讨论。升级仍在开发与测试推进中，细节以最终客户端实现为准。

来源：
https://www.coindesk.com/tech/2026/08/18/ethereum-s-next-upgrade-breaks-the-21-000-gas-rule-wallets-rely-on
https://blog.ethereum.org/2026/08/17/plataberget-testnet

#Ethereum #Glamsterdam #L1

信息整理，非投资建议

以太坊下一次大升级 Hegotá（目标约 2027）正在收提案清单～

据 CoinDesk 等报道，开发者目前桌上大约有 66 项 EIP，接下来几轮 core dev 会把能实现、能测、有机会按期上的挑出来。目前相对明确推进的是偏抗审查方向的 FOCIL（EIP-7805）。

另一个技术看点是 Frame Transactions（EIP-8141）以及配套的 Keyed Nonces、Recent Roots：讨论重点是给隐私类应用更多“协议层工具”，少一点对外部 relayer 的依赖。需要说清楚——普通 ETH 转账本身不会变成全链隐私，隐藏效果仍主要靠应用层设计。

公开文档可对：eips.ethereum.org（EIP-7805 / 8141 等）。最终上什么，以客户端实现和测试网进展为准。

来源：https://www.coindesk.com/tech/2026/08/17/ethereum-s-next-big-upgrade-has-66-proposals-including-a-major-privacy-fix

信息整理，非投资建议
#Ethereum #ETH

今天一条偏硬核的基础设施动态：World Chain（基于 OP Stack 的以太坊 L2）按计划在主网启用流式 EIP-7928 区块级访问列表（Block-Level Access Lists, BALs）。

技术钩子可以这样理解：
1) 以前很多客户端要按序执行整块交易，才能摸清状态依赖
2) EIP-7928 让区块明确记录本块读/写过哪些账户和存储槽，方便并行磁盘读取、并行校验，也为后续更高吞吐铺路
3) World Chain 还把它塞进 flashblock，大约每 200ms 流式推送访问列表，验证可以边出块边并行检查；公开报道提到目标是在不抬高验证者硬件门槛的前提下推高吞吐（具体数字以官方与实测为准）

以太坊主网侧，EIP-7928 仍走标准讨论/后续升级路径（外界常把它和 Glamsterdam 路线图联系在一起）；L2 用 runtime flag 先行，相当于给生态提前做一轮工程演练。

项目侧快速核验：公开仓库 worldcoin/world-chain 是 Rust monorepo，MIT 开源，近几日仍有连续 commit/PR（含 proofs、flashblock 相关修复），不是只有宣发页的空壳。

来源（可点开对照）：
- EIP-7928：https://github.com/ethereum/EIPs/blob/master/EIPS/eip-7928.md
- 报道整理：https://news.bitcoin.com/blockchain/world-chain-deploys-eip-7928-ahead-of-ethereum-mainnet/
- 代码：https://github.com/worldcoin/world-chain

信息整理，非投资建议

【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.

Source :
https://solana.com/news/solana-changelog-august-13-2026
https://github.com/anza-xyz/agave

Synthèse des informations, pas un conseil en investissement

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.

Source :
https://www.coindesk.com/tech/2026/08/12/smart-contract-blockchain-solana-nearly-froze-wednesday-marinade-finance-says

Synthèse d’informations, ne constitue pas un conseil en investissement

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.

Source : CoinDesk
https://www.coindesk.com/tech/2026/08/12/miden-bets-on-privacy-stablecoins-with-introduction-of-usdcx

Synthèse de l’information, ne constitue pas un conseil en investissement

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).

Source :
https://www.coindesk.com/business/2026/08/10/moneygram-expands-on-solana-with-global-crypto-to-cash-service
https://solana.com/news/moneygram-ramps

Informations compilées, pas un conseil en investissement

【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é.

Source :
https://www.theblock.co/news/ecosystems/2026-08-10-vitalik-buterin-privacy-quantum-resistance-front-and-center-ethereum-latest-roadmap-411298
https://strawmap.org/

Synthèse d’informations, pas un conseil en investissement

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.

Source :
https://www.sui.io/blog/making-sui-quantum-ready
https://www.theblock.co/post/410968/sui-post-quantum-signature-scheme

Synthèse d’informations, pas un conseil en investissement

【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.

Source :
https://www.sui.io/blog/making-sui-quantum-ready
https://www.theblock.co/post/410968/sui-post-quantum-signature-scheme

Synthèse d’informations, pas un conseil en investissement

【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.

Source :
https://www.coindesk.com/tech/2026/08/04/a-new-solana-proposal-would-take-daily-sol-burns-from-usd47-000-to-usd650-000
https://github.com/solana-foundation/solana-improvement-documents/pull/553

Synthèse des informations, ne constitue pas un conseil en investissement

Petite leçon de “hard wallet” : faille de l’entropie des graines sur Coldcard. Le problème ne vient pas du fait que le “matériel est emporté physiquement”, mais du fait que le chemin du générateur aléatoire du firmware a été pris au mauvais endroit.

D’après les explications officielles de Coinkite, lorsque la connexion à libsecp256k1 / libNgU a été faite en 2021, la génération de la graine du portefeuille a utilisé un pseudo‑aléatoire logiciel de MicroPython par erreur : le vrai TRNG du matériel n’a pas été injecté correctement dans le chemin principal. Le résultat : une entropie effective plus faible (estimation officielle grossière : ordre de grandeur ~40 bits pour Mk2/Mk3 ; ~72 bits avant correction pour Mk4/Mk5/Q ; dans tous les cas, en dessous des 128 bits attendus).

Les attaquants peuvent énumérer hors ligne l’espace de clés faibles, sans même toucher l’appareil.

Le suivi de Galaxy Research et d’autres indique que l’ampleur de la collecte des adresses concernées se chiffre à environ 1 000+ BTC / ~70 millions de dollars, puis à une deuxième vague qui s’accumule pour atteindre environ 1 300+ BTC / près de 90 millions de dollars (les statistiques continuent d’être mises à jour). L’éditeur a publié des correctifs de firmware (par ex. Mk3 4.2.0, Mk4/Mk5 5.6.0, Q 1.5.0Q, etc.) et insiste : la mise à jour ne corrige pas les anciennes graines. Il faut générer de nouvelles graines sur le nouveau firmware, puis migrer. Et à l’époque, le risque était nettement plus faible si l’on utilisait au moins 50 tirages de dés indépendants pour l’entropie.

Le dépôt open source Coldcard/firmware indique des soumissions de signatures denses entre le 31/7 et le 1/8.

Trois observations côté technique :
1) Les wallets matériels open source doivent toujours valider de bout en bout “l’analyse des symboles / le chemin réel d’appel du RNG” ; on ne peut pas se contenter de vérifier que le code TRNG est bien présent dans le binaire
2) L’audit assisté par IA est une épée à double tranchant : les deux camps (attaque et défense) peuvent accélérer leurs recherches
3) L’autohébergement doit traiter la source d’entropie, les sauvegardes, le passphrase et la procédure de migration “à froid” comme des citoyens de première classe

Sources :
https://blog.coinkite.com/coldcard-mk3-seed-generation-warning/
https://blog.coinkite.com/entropy-technical-backgrounder/
https://www.theblock.co/post/410332/bitcoin-losses-linked-coldcard-vulnerability-70-million-galaxy-research
https://www.coindesk.com/tech/2026/08/02/bitcoin-cold-wallet-attack-spreads-to-4-500-addresses-as-losses-near-usd89-million
https://github.com/Coldcard/firmware

Synthèse des informations, pas un conseil en investissement.

【Observation du protocole】Le XRP Ledger prépare à réintroduire des fonctionnalités retirées deux fois pour des problèmes de sécurité ; une fois réparées, elles seront à nouveau soumises au vote des validateurs

Selon CoinDesk, la version xrpld 3.3.0 devrait sortir la semaine prochaine et inclure 5 propositions d’amendements. Parmi elles, Batch (jusqu’à 8 transactions atomiques entre comptes) et Permission Delegation (une organisation peut déléguer des droits de signature fins, sans devoir céder le contrôle complet) avaient tous deux été suspendus en urgence à cause de failles graves : pour la première, un défaut de validation des signatures pourrait permettre à un attaquant d’émettre des transactions sans clé ; pour la seconde, il existait un risque de transfert de frais et d’assèchement du solde. À l’époque, ces fonctions n’étaient pas encore en production sur le réseau principal, donc aucun fonds n’a été perdu, mais le processus mérite d’être noté : d’abord retirer, puis corriger, puis voter.

Dans le même lot, trois nouvelles capacités orientées plutôt institution et actifs :
• Confidential MPT : preuve à divulgation nulle de connaissance + chiffrement à courbe elliptique, permettant de cacher au public les soldes et montants de transferts de jetons multi-usages tout en conservant un chemin d’audit et de conformité
• Sponsored Fees and Reserves : une banque ou une plateforme peut payer les frais XRP et les réserves pour les utilisateurs, réduisant la barrière « devoir d’abord détenir un token de carburant pour pouvoir l’utiliser »
• Dynamic MPT : au moment de l’émission, il sera possible de définir quelles propriétés de jetons pourront être modifiées par la suite, afin de réduire les migrations de jetons entiers

Côté gouvernance, les amendements doivent encore être soutenus par des validateurs dignes de confiance à hauteur d’au moins 80 % pendant deux semaines consécutives pour être activés : ce n’est pas une seule entreprise qui décide, mais le réseau. Le dépôt principal XRPLF/rippled (C++ open source) reste récemment très actif ; le 1er août, un hotfix de la 3.2.1 est également sorti, et les tests liés à Confidential MPT continuent d’avancer.

En une phrase : ce n’est pas « empiler des fonctionnalités », mais reprendre à zéro des hypothèses de sécurité déjà échouées, puis repasser par le seuil de validation. La mise en œuvre de la tokenisation « institutionnalisée » et des actifs privés dépendra des votes et du déploiement réel.

Source : CoinDesk https://www.coindesk.com/tech/2026/08/01/xrp-ledger-upgrade-brings-back-features-once-pulled-over-critical-bugs
Code et publication : https://github.com/XRPLF/rippled

Synthèse de l’information, pas un conseil en investissement

【Observation de protocole】Prochaine version du XRP Ledger xrpld 3.3.0 : cinq amendments de retour pour un vote des validateurs

D’après des informations publiques partagées par CoinDesk et le volet produits de RippleX, la prochaine version logicielle est prévue pour la semaine prochaine : elle soumettra cinq révisions de protocole à l’examen des validateurs. Points techniques à retenir :

1）Confidential MPT : ZK + chiffrement par courbes elliptiques, afin que les soldes/ montants de transferts de tokens à usage multiple puissent être anonymisés, tout en permettant à l’entité autorisée d’effectuer un audit
2）Batch (version révisée) : exécution atomique, au maximum 8 transactions entre plusieurs comptes, avec tout réussi ou tout échoué
3）Permission Delegation (version révisée) : délégation de droits sur un périmètre étroit, sans besoin de céder le pouvoir de signature complet
4）Sponsored Fees and Reserves : des institutions/plateformes peuvent payer les frais et les réserves à la place
5）Dynamic MPT : lors de l’émission, il est possible de définir des propriétés modifiables ultérieurement, afin de réduire la migration de l’intégralité du solde

Contexte intéressant : Batch et Permission Delegation avaient été retirés en urgence plus tôt à cause de failles graves (problèmes dans la logique de vérification de la signature pouvant entraîner des transactions non autorisées ; lors de la divulgation de la vulnérabilité, l’amendment n’était pas encore activé sur le réseau principal, et il n’y a eu aucune perte de fonds). Cette fois, il s’agit de la version corrigée. L’activation nécessite toujours le soutien continu pendant deux semaines d’environ 80 % des validateurs de confiance : c’est déterminé par le vote du réseau, et non par une mise en ligne à un seul clic.

Côté code : le client principal rippled (XRPLF/rippled) a encore soumis intensément ces derniers jours, incluant des tests liés à Confidential MPT ; le dépôt fait l’objet d’une maintenance publique continue.

Source :
https://www.coindesk.com/tech/2026/08/01/xrp-ledger-upgrade-brings-back-features-once-pulled-over-critical-bugs
https://xrpl.org/resources/known-amendments
https://xrpl.org/blog/2026/vulnerabilitydisclosurereport-bug-feb2026
https://github.com/XRPLF/rippled

Synthèse des informations, pas un conseil en investissement

Notes techniques ｜ Zcash finalise la mise à niveau Ironwood (NU6.3)

Le réseau de confidentialité Zcash a activé la mise à niveau du réseau Ironwood au bloc 3,428,143. L’enjeu n’est pas un simple récit de hausse ou de baisse, mais une correction d’ingénierie visant l’intégrité de la chaîne d’approvisionnement et des circuits de preuve à divulgation nulle de connaissance.

Contexte, en bref :
Des chercheurs ont identifié un risque potentiel de création de faux jetons indétectables dans les circuits zk de la pool masquée Orchard (le problème existe depuis la mise en ligne en 2022). Les développeurs ont d’abord corrigé en urgence via une mise à jour logicielle/matérielle en fourche souple/dure, puis ont poursuivi avec une nouvelle pool Ironwood.

Que fait cette mise à niveau :
1）Mise en ligne d’une nouvelle pool masquée Ironwood, réutilisant les circuits Orchard/Halo 2 déjà corrigés, et finalisation par une vérification formelle (preuves vérifiables via Lean, dépôt public visible)
2）Ancienne pool Orchard limitée à l’extraction uniquement, avec une comptabilité à “porte tournante/turnstile” aux frontières : quantités entrées/sorties vérifiables publiquement, afin d’éviter des retraits excessifs
3）Introduction de designs comme la note de récupération quantique ZIP 2005, pour préserver une voie de repli lors de l’évolution à long terme de la cryptographie
4）Côté nœuds, coopération avec le retrait de zcashd : le chemin principal se tourne vers Zebra et d’autres nouvelles piles

Les traces de collaboration sont très marquées : Shielded Labs, ZODL, Project Tachyon, Valar, Zcash Foundation, etc. Côté code, le dépôt formel Zebra et ironwood continue d’avoir des soumissions récentes : ce n’est pas une annonce vide.

La migration côté utilisateurs est volontaire : les fonds doivent être transférés activement d’Orchard vers Ironwood, et l’avancement dépend du portefeuille et des actions de l’utilisateur.

Pourquoi ça vaut le coup pour les lecteurs de la place :
C’est un cas complet de “découverte d’un problème → vérification formelle entre équipes → mise à niveau du protocole + bornes de comptabilité”. Plus qu’un slogan, cela montre concrètement comment un protocole de confidentialité peut reconstruire une confiance vérifiable dans l’émission.

Source :
The Block https://www.theblock.co/post/409934/zcash-ironwood-upgrade-launching-new-shielded-pool-after-orchard-vulnerability
CoinDesk https://www.coindesk.com/tech/2026/07/28/zcash-seals-usd1-7-billion-shielded-pool-as-ironwood-upgrade-activates
Project Tachyon https://tachyon.z.cash/blog/ironwood-verification-complete/
GitHub https://github.com/zcash/ironwood

Synthèse de l’information, pas un conseil en investissement

【Notes techniques】Zcash Ironwood (NU6.3) réseau principal activé

Le 28 juillet, Zcash a finalisé la mise à niveau Ironwood à la hauteur de bloc 3 428 143. L’accent est mis sur la sécurité des pools de confidentialité et l’intégrité de l’approvisionnement, pas sur le récit de marché :

1. Le pool Orchard obsolète a été mis sous scellés (auparavant, le circuit contenait une vulnérabilité potentiellement falsifiable, latente depuis environ quatre ans ; aucune trace manifeste d’exploitation n’a été observée dans les analyses publiques)
2. Nouveau pool de masquage lancé depuis zéro : les fonds doivent être migrés manuellement par les utilisateurs
3. Sortie du pool avec comptabilisation via turnstile (portillon) : le montant total extractible ne peut pas dépasser le montant déposé vérifiable, afin de bloquer d’éventuelles fausses pièces
4. Le nouveau pool intègre un schéma de comptabilisation plus orienté anti-quantique et fait progresser la preuve avec une validation formelle du circuit

Côté nœuds : zcashd est entré en fin de vie (EOL) et le client principal se tourne vers Zebra de la Zcash Foundation (6.0+ prend en charge NU6.3 ; avant et après l’activation, il y a encore des soumissions et des publications actives). librustzcash est également en synchronisation avec des versions liées au déploiement des portefeuilles/la migration.

D’après CoinDesk, le premier jour d’activation, environ 176 000 ZEC (de l’ordre de 810 millions de dollars) ont migré vers le nouveau pool, soit environ 5 % du solde de l’ancien pool. La migration reste volontaire et progressive.

Source :
https://www.coindesk.com/tech/2026/07/28/zcash-seals-usd1-7-billion-shielded-pool-as-ironwood-upgrade-activates
https://www.coindesk.com/tech/2026/07/29/about-usd80-million-zec-crosses-into-zcash-s-new-ironwood-pool-in-the-first-day
https://zfnd.org/zebra-6-0-0-release/

Synthèse d’informations, ne constitue pas un conseil en investissement