Base fixe au 5 novembre ses blocs de 200 ms avec Denim : fin des Flashblocks, timelocks en blocs dix fois plus rapides

Base, le réseau de couche 2 d’Ethereum exploité par Coinbase, fera passer son mainnet à des blocs de 200 millisecondes le 5 novembre avec la mise à jour Denim, selon The Defiant, qui a cité le 29 octobre le compte « builders » de Base sur X. Le temps de bloc serait ainsi divisé par dix, de deux secondes à 200 ms : cinq blocs complets par seconde, soit 432 000 par jour au lieu de 43 200. La documentation de Base, elle, indique toujours seulement « novembre 2026 » pour le mainnet, sans horodatage d’activation.

Pour les développeurs, c’est un changement cassant. Les Flashblocks, ce flux de préconfirmations de 200 ms que Base exploite depuis juillet 2025, s’arrêtent à l’activation de Denim, et avec eux tous les abonnements et toutes les requêtes « pending » sur lesquels reposent les applications. Les contrats intelligents qui mesurent le temps en nombre de blocs verront ces blocs arriver dix fois plus vite. Base n’a pas encore publié l’heure exacte d’activation ni les versions de ses logiciels de nœud pour le mainnet.

La mise à jour Denim est active sur le testnet Base Sepolia depuis le 21 octobre à 18 h 00 UTC.

Mise à jour Base Denim : ce qui est confirmé pour le 5 novembre, et ce qui ne l’est pas

La date du 5 novembre repose sur une seule chaîne de sources. L’article de The Defiant, titré « Base Sets November 5 for Denim’s 200ms Mainnet Blocks », a été repris par KuCoin News le 29 octobre. Cette reprise rapporte que le compte « builders » de Base a écrit que Denim « est en ligne sur Base Sepolia, le mainnet arrive le 5 novembre ». Coindaro n’a pas pu ouvrir le message sur X lui-même, et aucun des deux articles n’en donne l’adresse. Phemex a publié la même date le même soir, en citant un message du compte X de The Defiant.

La documentation de Base, consultée le 30 octobre, est plus prudente. La page de présentation de Denim place le mainnet au stade « Planning », pour novembre 2026. La spécification des blocs de 200 ms parle de ce mois comme d’« une cible de planification, pas d’un horodatage d’activation », et l’index des mises à jour de Base précise qu’une telle cible peut évoluer. Le blog de Base ne comportait aucun article sur Denim le 30 octobre ; son dernier billet, du 29 octobre, portait sur Shopify. Personne en dehors de l’équipe ne peut donc dire à quelle heure UTC la bascule aura lieu.

Crypto Briefing, qui écrivait le 27 octobre, avant que la date ne circule, parlait de novembre comme d’« une cible plutôt qu’un lancement verrouillé ».

Cinq blocs par seconde : ce qui change dans la chaîne elle-même

Aujourd’hui, Base produit un bloc canonique toutes les deux secondes. Après Denim, d’après la spécification des blocs de 200 ms, le séquenceur construit et exécute un bloc complet dans chaque créneau de 200 ms. Chacun de ces blocs est un bloc à part entière, avec son numéro, son hash, sa racine d’état et ses reçus, et blockchain that runs exactly as written when it is called, holding and moving funds according to its code, without an intermediary able to change the outcome.">smart contract holding reserves of two or more tokens, supplied by users, that a decentralized exchange uses to execute trades automatically at a price set by a formula.">pool diverge, compared with simply holding the same tokens in a wallet. It becomes permanent when the provider withdraws.">il suit le cycle habituel unsafe, safe puis finalized.

C’est l’horloge murale du séquenceur, et non l’horodatage du bloc, qui déclenche le début d’une construction. Aucun créneau ne peut être sauté : chaque bloc doit arriver exactement 200 ms après son parent.

Ce n’est pas ce que faisaient les Flashblocks. Ils découpaient chaque fenêtre de deux secondes en dix mises à jour incrémentales que les portefeuilles et les applications pouvaient lire en avance, mais seul le bloc de deux secondes était canonique. Denim transforme ce rythme de 200 ms en vrais blocs, ce qui explique que la couche de préconfirmation ne soit plus nécessaire.

Les horodatages restent en secondes entières

Le champ timestamp de l’en-tête Ethereum et le block.timestamp de l’EVM restent exprimés en secondes entières : cinq blocs consécutifs peuvent donc partager la même valeur. Pour porter la précision manquante, Denim ajoute une transaction de dépôt BaseTime en position tx[1] de chaque bloc, avec une partie en millisecondes égale à 0, 200, 400, 600 ou 800.

Un contrat prédéployé BaseTime, à l’adresse 0x4200000000000000000000000000000000000030, expose deux fonctions, timestampMillisPart() et timestampMs(). Les réponses RPC gagnent deux champs facultatifs : timestampMs (sur les blocs, les en-têtes et les événements newHeads) et blockTimestampMs (sur les transactions, les reçus et les logs). Les deux sont omis, et non estimés, lorsque les données BaseTime manquent, comme dans les blocs antérieurs à Denim ou dans l’historique élagué.

Sources : documentation de Base (consultée le 30 octobre 2026), Crypto Briefing (27 octobre 2026) pour le nombre de blocs par jour ; la ligne des 30 blocs est un calcul de Coindaro.

Les timelocks en nombre de blocs vont tourner dix fois plus vite

C’est la partie de Denim que les utilisateurs ordinaires des applications Base pourraient ressentir, même sans lire le moindre journal de modifications. Tout contrat qui mesure le temps en comptant des blocs verra ce temps fondre au dixième. À deux secondes par bloc, 30 blocs duraient 60 secondes ; à 200 ms, ils en durent 6.

La spécification de Base dresse la liste des logiques exposées. Les timelocks, les périodes de refroidissement et les délais de sortie écrits en blocs s’écoulent en un dixième du temps prévu. Les calendriers de vesting et d’émission comptés en blocs se terminent dix fois plus tôt. Les limites de débit par bloc se réinitialisent cinq fois par seconde, ce qui multiplie par dix la limite effective par seconde. Les échéances écrites sous la forme block.number plus N expirent plus vite.

La gouvernance figure sur la liste. Un délai de vote ou une période de vote fixés en blocs, y compris avec l’ERC20Votes d’OpenZeppelin et son horloge en numéro de bloc, raccourcit d’un facteur dix, même si les points de contrôle de votes déjà enregistrés restent corrects. Les oracles TWAP de type Uniswap V3 conservent des valeurs correctes, mais un nombre fixe d’observations stockées ne couvre plus qu’environ la moitié de l’historique, de sorte que les longues fenêtres de calcul échouent plus tôt avec l’erreur OLD. Le guide de migration ajoute les flux de ponts et de preuves qui lisent un nombre donné de hashes de blocs historiques ou de racines de la beacon chain : ils couvriront moins de temps écoulé.

La logique qui s’appuie sur block.timestamp n’est pas touchée.

Le conseil de Base : faire passer les durées exprimées en blocs à block.timestamp lorsqu’un contrat peut être mis à jour ou redéployé, diviser par dix à l’activation les nombres de blocs réglables par la gouvernance, et prévoir une migration pour les contrats immuables, qu’on ne peut pas réajuster. Pour un utilisateur, la vérification pratique est la suivante : si vous détenez une position dans un protocole de Base avec un verrouillage, un calendrier de vesting ou un délai de retrait, regardez si le protocole fixe ces durées en secondes ou en blocs, et s’il a publié un plan pour Denim.

Flashblocks et lectures « pending » : l’arrêt à l’activation

Les Flashblocks étaient la réponse de Base au bloc de deux secondes. Conçus avec Flashbots, testés sur Sepolia à partir de février 2025, présentés sur le blog de Base le 15 mai 2025 comme un moyen de rendre la chaîne « 10x plus rapide », puis déclarés actifs sur le mainnet à la mi-juillet 2025, selon The Block le 17 juillet. Des applications et des indexeurs de Base se sont construits dessus, d’où la nécessité d’un guide de migration pour Denim.

Denim y met fin. Le guide de migration de Base est sans détour : les abonnements Flashblocks et l’état « pending » sont indisponibles après l’activation. Le guide demande aux équipes de recenser chaque abonnement Flashblocks et chaque appel RPC qui utilise le tag « pending », puis de les remplacer.

• L’abonnement newFlashblocks devient newHeads.
• L’abonnement pendingLogs devient logs.
• L’abonnement newFlashblockTransactions devient newHeads, suivi de la récupération des transactions de chaque bloc.
• Les appels tels que eth_getBlockByNumber, eth_getBalance, eth_getTransactionCount, eth_call, eth_estimateGas, eth_simulateV1 et eth_getBlockTransactionCountByNumber effectués avec « pending » passent au dernier bloc ou à l’état canonique le plus récent.
• Les plages eth_getLogs qui se terminent à « pending » doivent se terminer à un bloc canonique.

Les remplaçants renvoient des données canoniques issues des blocs de 200 ms, et non des données préconfirmées ; le guide précise que le tag « pending » n’a pas d’équivalent direct. Comme chaque mise à jour de 200 ms est désormais un bloc, une application qui passe à newHeads devrait voir arriver du nouvel état à peu près aussi souvent qu’avec les Flashblocks. Une application qui continue d’appeler les anciens abonnements ou le tag « pending » perdra ces données à l’activation.

La charge pose aussi question. Crypto Briefing a cité des recherches non nommées qui prévoient environ dix fois plus d’appels RPC pour les indexeurs. Coindaro n’a pas pu retrouver ces travaux ; ce chiffre est donc à prendre comme un ordre de grandeur. Le simple calcul suffit à voir qu’un indexeur traitera dix fois plus de blocs par jour.

Exploitants de nœuds : les versions de client pour le mainnet se font attendre

Pour ceux qui font tourner des nœuds Base, Denim modifie l’API du moteur. Après l’activation, les attributs de charge utile envoyés avec forkchoiceUpdated doivent comporter un timestampMillisPart, et la transaction tx[1] de chaque bloc doit être le dépôt BaseTime. Les attributs mal formés sont rejetés avec l’erreur -32602, et un newPayload dont le dépôt est absent ou invalide est signalé comme invalide. Avant l’activation, les blocs ne doivent pas contenir ce dépôt.

La spécification indique que les versions de base-reth-node et de base-consensus requises pour le mainnet « ne sont pas encore publiées ». C’était toujours le cas le 30 octobre, six jours avant la date annoncée. L’ancien dépôt GitHub base/node de Base a été archivé le 8 septembre 2026 et ne mentionne pas Denim ; les exploitants doivent donc surveiller les dépôts des clients plus récents. Les développeurs qui testent en local doivent aussi savoir qu’Anvil ne produit pas de métadonnées BaseTime au départ.

Frais et limite de gaz : rien dans la documentation

Base n’a documenté aucun changement de frais avec Denim, et sa spécification ne dit rien de la limite de gaz par bloc. Coindaro n’a trouvé aucune source affirmant que les transactions deviendront moins chères ou plus chères.

Denim touche aussi le standard de jetons B20 de Base, son format pour les actions tokenisées présenté le 27 août 2026, avec des règles plus strictes : les transferts, créations et saisies vers l’adresse du jeton lui-même sont annulés, la TRANSFER_EXECUTOR_POLICY s’applique à tous les chemins de transfert, et toute politique du PolicyRegistry peut être inversée avec un drapeau NOT. Le regroupement natif de transactions et le parrainage de gaz ne font pas partie de Denim ; ils relèvent d’une mise à jour ultérieure baptisée Everest, que l’index des mises à jour de Base mentionne sans date.

Denim glisse de mois en mois : fin août, puis octobre, maintenant novembre

Crypto Briefing écrivait le 2 septembre 2026 que la mise à jour visait la fin août. Un guide de migration de Dwellir daté du 11 septembre plaçait Sepolia et le mainnet en octobre. Sepolia a bien été activé le 21 octobre, et la reprise de The Defiant par KuCoin note que le 5 novembre est postérieur à la cible d’octobre que Base avait publiée.

L’écart entre le testnet et le mainnet est lui aussi plus large que d’habitude. Les deux dernières mises à jour de Base ont atteint le mainnet sept jours après Sepolia. Denim, si le 5 novembre tient, en prendra 15.

Source : aperçu des mises à jour de Base, consulté le 30 octobre 2026.

Base livre désormais ses propres hardforks depuis sa sortie de la Superchain

Le tableau montre aussi un changement de propriétaire. La documentation de Base classe Isthmus et Jovian parmi les hardforks de l’OP Stack en amont, adoptés par Base, et présente Azul comme sa « première mise à niveau indépendante du réseau ». Base a dévoilé sa propre pile unifiée sur son blog le 18 février 2026 ; L2BEAT date sa sortie de la gouvernance de la Superchain au 4 mars 2026. La chaîne fonctionne toujours sur l’OP Stack.

Ce départ a compté pour Optimism, puisque Base était la plus grande chaîne bâtie sur l’OP Stack. Notre page sur Optimism et la Superchain explique le fonctionnement de la Superchain après le départ de Base.

Denim est le plus gros changement que Base ait livré sur cette voie indépendante : un temps de bloc divisé par dix, sur son propre calendrier, sans attendre une version commune de l’OP Stack.

BNB Chain veut aussi des blocs de 200 ms, sur une chaîne encore en test privé

Base n’est pas le seul réseau à courir après les 200 ms. BNB Chain construit une nouvelle couche 1 avec des blocs de 200 ms et sans nouveau jeton, toujours sur un devnet privé ; nous avons détaillé cette feuille de route le 27 octobre. Des sources secondaires situent son testnet public fin 2026 et son mainnet en 2027.

La différence tient au stade d’avancement. La chaîne à 200 ms de BNB Chain est un projet. Base compte basculer un réseau en production que L2BEAT donnait pour 14,48 milliards de dollars sécurisés le 30 octobre, d’ici une semaine, si la date est tenue.

Les pannes de juin, et la sécurité de Base selon L2BEAT

Base aborde cette mise à jour quatre mois après deux arrêts. D’après le postmortem de Base publié le 27 juin 2026, la production de blocs s’est arrêtée environ 116 minutes le 25 juin, à partir de 11 h 47 EDT, puis environ 20 minutes le 26 juin, à partir de 11 h 28 EDT. Base a remonté la cause à un bogue de construction de blocs du séquenceur, qui laissait persister un état de journal périmé après l’échec de validation d’une transaction, ainsi qu’à une situation de concurrence qui empêchait les séquenceurs de se resynchroniser après un redémarrage. Base a indiqué que les fonds des utilisateurs n’avaient pas été touchés. Elle a livré deux correctifs et promis des tests de fuzzing et de charge renforcés.

Rien de ce qui a été publié ne relie Denim à ce bogue. Le point est plus modeste : la brique qui a lâché en juin est celle à qui Denim demande de construire dix fois plus de blocs.

La page de L2BEAT consacrée à Base, consultée le 30 octobre 2026 (elle ne donne pas de date d’instantané pour ses chiffres de valeur ; sa dernière entrée datée remonte au 9 octobre), classe la chaîne au Stage 1. Elle n’atteint pas le Stage 2 parce que des mises à jour sans rapport avec des bogues démontrables laissent aux utilisateurs moins de 30 jours pour sortir, et que le Security Council n’est pas limité aux bogues démontrables. Les mises à jour exigent à la fois le Base Coordinator Multisig et le Base Security Council, sans délai. Si le séquenceur tombe en panne, les utilisateurs peuvent forcer leurs propres transactions via Ethereum au bout de 12 heures au plus ; les preuves de fraude reposent sur une période de contestation de cinq jours.

Base n’a pas de jeton natif : aucun cours ne réagit donc à l’annonce. La chaîne appartient à Coinbase (voir notre avis sur Coinbase).

Des blocs de 200 ms ne signifient pas une finalité en 200 ms

Une couche 2 est un réseau qui exécute les transactions en dehors d’Ethereum et republie ses données sur Ethereum pour le règlement. Le temps de bloc de Base mesure la fréquence à laquelle son séquenceur produit un bloc. Le règlement sur Ethereum est une étape distincte.

Analyse de Coindaro à partir de la documentation : Denim conserve tel quel le cycle unsafe, safe, finalized ; un bloc de 200 ms est donc une première confirmation plus rapide, pas un règlement plus rapide sur Ethereum. Les retraits vers Ethereum passent toujours par la fenêtre de preuve de fraude. Les utilisateurs ne ressentiront la vitesse que là où les portefeuilles et les applications lisent les nouveaux blocs canoniques. Notre guide des réseaux de couche 1 et de couche 2 détaille la différence.

Les dates à surveiller avant et après le 5 novembre

D’ici le 5 novembre, il faut guetter deux signaux : un horodatage d’activation dans la documentation de Base à la place de « novembre 2026 », et les versions mainnet de base-reth-node et de base-consensus dont les exploitants de nœuds ont besoin avant la bascule.

Après l’activation, l’épreuve se déplace vers les applications : les portefeuilles et les indexeurs ont-ils quitté les Flashblocks à temps, et un protocole aux délais comptés en blocs devra-t-il expliquer pourquoi un verrouillage s’est terminé trop tôt ?