Réponse rapide : Non. La mise à niveau Denim de Base, annoncée en ligne le 5 novembre 2026, a fait passer la chaîne à un bloc canonique complet produit toutes les 200 millisecondes. Il s'agit d'un intervalle de production de blocs, et non d'une garantie qu'une transaction est définitive sur Ethereum en 200 millisecondes, ni qu'un retrait peut être dépensé immédiatement sur une autre chaîne. Pour un transfert, distinguez d'abord l'inclusion initiale sur Base des états ultérieurs « safe » et « finalized », ainsi que du processus d'achèvement propre à tout pont interchaîne.
Qu'a changé Denim ?
L'annonce de Denim sur Base indique que la mise à niveau a remplacé une cadence de blocs de deux secondes par cinq blocs canoniques complets par seconde. Elle a également remplacé l'approche Flashblocks précédente, qui exposait un aperçu d'état en attente entre des blocs plus lents. Dans la nouvelle conception, le réseau produit lui-même un bloc complet toutes les 200 millisecondes. Cela concerne les applications qui ont besoin d'actualisations d'état plus fréquentes ou d'informations temporelles à la milliseconde près.
Le chiffre mis en avant décrit la cadence. Si une transaction atteint le séquenceur au bon moment et est acceptée, la prochaine occasion de bloc arrive rapidement. Pourtant, l'expérience utilisateur comprend plus d'étapes que la création de bloc : soumission depuis le portefeuille, transport réseau, ordonnancement par le séquenceur, synchronisation des nœuds, indexation par l'application, et la politique de tout processeur de paiement. Aucune de ces étapes n'est garantie de se terminer en un seul intervalle. Une connexion lente au portefeuille ou une application encombrée peut toujours créer un délai, même quand les blocs sont fréquents.
L'annonce aborde aussi l'accès des contrats au temps avec une précision à la milliseconde et des modifications pour les vérifications de transfert B20. Ces éléments concernent les développeurs, mais un utilisateur ordinaire ne devrait pas en déduire que son pont ou sa plateforme a modifié sa politique de confirmation des dépôts. Ces services définissent leurs propres seuils, parfois selon l'actif et la destination plutôt que selon l'intervalle de bloc nominal de la couche 2 (Layer 2).
Quelle est la différence entre inclusion et finalité ?
L'inclusion signifie qu'une transaction apparaît dans un bloc Base. C'est une étape observable : un explorateur de blocs ou un nœud signale la transaction, son statut et une référence de bloc. L'inclusion peut suffire pour qu'une interface à faible risque affiche un solde actualisé ou un reçu de paiement en attente. Ce n'est pas la même chose que la garantie de règlement la plus forte disponible dans le système.
Base est un réseau Ethereum Layer 2. Son protocole distingue les blocs L2 nouvellement séquentiés des blocs dont les données d'entrée ont été dérivées d'Ethereum, et des blocs associés à des données Ethereum finalisées. La spécification de dérivation de Base utilise les termes unsafe, safe et finalized pour ces états. Ces noms décrivent différents niveaux de prise en charge par les données et la finalité de la L1 ; ce ne sont pas trois étiquettes pour le même événement de 200 millisecondes.
Un bloc L2 unsafe peut être visible avant que les données correspondantes n'aient obtenu les garanties ultérieures décrites dans le processus de dérivation. Un bloc safe a été dérivé de données L1 canoniques selon les règles du protocole. Un bloc L2 finalized est dérivé de données L1 finalisées. Les détails comptent pour un opérateur qui décide quand un dépôt peut être crédité de façon irréversible, mais un consommateur peut retenir la règle simple : « je vois la transaction » et « le service récepteur la considère comme définitive » sont deux affirmations distinctes.
La finalité peut aussi signifier des choses différentes selon la documentation produit. Un portefeuille peut indiquer « confirmée » après un reçu de transaction local, tandis qu'un pont attend une preuve ou un processus de contestation. Une page de contenu devrait nommer l'événement exact visé plutôt que d'utiliser « règlement instantané » comme description fourre-tout.
Découvrir le trading sur Phemex
Pourquoi Ethereum compte encore après l'apparition d'un bloc Base ?
Base s'appuie sur Ethereum pour une partie de sa sécurité et de son chemin de disponibilité des données. Les blocs L2 sont produits plus fréquemment que les blocs Ethereum, mais les données qui les rendent reproductibles et le processus qui détermine leur statut final impliquent la L1. La spécification de dérivation décrit comment Base utilise les données L1 et les signaux de finalité pour mettre à jour les têtes safe et finalized de la L2. Des blocs L2 plus rapides créent davantage d'actualisations d'état ; ils ne suppriment pas la relation avec la L1.
Cette distinction est pertinente lorsqu'un opérateur doit décider combien de risque de réorganisation ou de renversement accepter. Un jeu peut accorder un petit objet en jeu après la première inclusion parce que le coût de l'attente est élevé et son exposition limitée. Une plateforme traitant un gros dépôt peut attendre une garantie supplémentaire. Aucune de ces politiques ne modifie le protocole sous-jacent ; elles représentent différents choix de risque par le service récepteur.
Elle est aussi pertinente pour les affirmations sur la sécurité. Des blocs plus fréquents ne constituent pas, en soi, la preuve que la chaîne est devenue plus décentralisée ou que les preuves de fraude se complètent plus vite. Ces propriétés dépendent de mécanismes protocolaires et opérationnels distincts. Un article sur Denim devrait s'en tenir à ce que documente la version publiée : un changement de cadence de blocs et des fonctionnalités précisées pour les développeurs.
Un bloc de 200 ms accélère-t-il un retrait vers Ethereum ?
Pas nécessairement. Un retrait d'un rollup vers Ethereum suit un processus de pont distinct de l'inclusion dans un bloc L2. La transaction peut apparaître sur Base rapidement, tandis que la preuve ou la finalisation de son effet sur Ethereum prend beaucoup plus longtemps. La documentation du protocole Base distingue explicitement les entrées L2 finalisées de l'achèvement d'un processus de sortie ou de retrait d'un optimistic rollup. Les deux peuvent être qualifiés de « finalisés » dans un langage informel, ce qui rend le vocabulaire précis important.
Un utilisateur devrait consulter les instructions du pont concerné : quel réseau reçoit l'actif, si la route est native ou fournie par un service de liquidité, quels frais s'appliquent, et ce que signifie l'estimation d'achèvement affichée. Un pont de liquidité rapide peut payer le destinataire avant la fin d'une route native, mais alors l'utilisateur dépend de la capacité et des conditions du fournisseur de liquidité. C'est un risque différent de l'attente du processus natif.
Le chiffre de 200 millisecondes de Denim ne peut pas être recopié dans une estimation de retrait. Le temps jusqu'à la première inclusion L2, jusqu'à un statut L2 safe ou finalized, et jusqu'à la disponibilité des fonds sur Ethereum devrait être indiqué séparément si un tutoriel donne des attentes temporelles. Quand un service n'a pas publié d'estimation actuelle, l'article ne doit pas en inventer une.
Comment une application devrait-elle décider quand créditer un transfert ?
Commencez par la valeur et la réversibilité de ce que l'application délivre. Une application capable de revenir sur un état d'affichage de faible valeur peut utiliser un signal précoce. Une qui libère des fonds ou un élément numérique irréversible devrait envisager un seuil plus fort. La décision devrait être documentée comme une politique plutôt qu'inférée de l'intervalle de bloc de la chaîne.
Identifiez ensuite la source d'état. L'application lit-elle le dernier bloc auprès d'un fournisseur RPC, de son propre nœud complet, d'un indexer ou d'un événement de pont ? Ceux-ci peuvent diverger temporairement pendant la synchronisation. La nouvelle cadence de 200 millisecondes peut obliger un indexer à traiter davantage d'événements de blocs par seconde ; s'il prend du retard, l'interface utilisateur peut s'actualiser plus lentement que la chaîne. Les développeurs devraient mesurer le chemin réel après la mise à niveau au lieu de supposer que la cadence de la version égale leur latence de bout en bout.
Enfin, définissez la gestion des exceptions. Que se passe-t-il quand une transaction est remplacée, qu'un nœud devient indisponible ou qu'un message interchaîne est retardé ? Une machine à états claire — soumise, incluse, safe, finalized, livrée — aide les équipes de support à expliquer un transfert en attente. Elle empêche aussi une interface d'afficher « terminé » au moment où elle voit un bloc alors que l'action métier dépend encore d'une condition ultérieure.
Que doivent vérifier les utilisateurs dans un explorateur de blocs ?
Vérifiez d'abord le réseau. Un hash de transaction sur Base devrait être consulté dans un explorateur Base ou un nœud compatible, et non sur une page de jeton au nom similaire sur une autre chaîne. Contrôlez l'expéditeur, le destinataire, le contrat de jeton le cas échéant, le statut, le numéro de bloc et le montant. Pour une interaction avec un contrat, lisez les événements et les registres de transfert de jetons plutôt que de vous fier uniquement au message de succès de la transaction ; un appel réussi peut contenir plusieurs transferts.
Si une application réceptrice n'a pas crédité les fonds, comparez sa politique de dépôt affichée avec l'état réel de la transaction. L'application peut attendre son propre seuil de confirmation, exiger un contrat de jeton pris en charge, ou rejeter des dépôts via une route qu'elle n'accepte pas. Le fait que Base ait produit de nombreux blocs après la transaction ne prouve pas que l'application a effectué toutes les vérifications requises. Contactez le support avec le hash et le réseau, jamais une phrase de récupération.
Ne confondez pas le dernier bloc visible avec une promesse contre toute perturbation future. Un explorateur est un outil d'observation utile ; il ne remplace pas les conditions du service récepteur ni le modèle de sécurité du protocole. Un article daté peut expliquer comment inspecter le statut, mais il ne devrait pas garantir un nombre fixe de millisecondes pour tous les transferts.
FAQ
Denim a-t-il rendu les transactions Base définitives en 200 ms ?
Non. Denim a fait arriver des blocs L2 canoniques toutes les 200 millisecondes. L'inclusion dans l'un de ces blocs est une étape antérieure au statut safe ou finalized dérivé de la L1, et l'achèvement par un pont est un processus séparé.
Flashblocks sont-elles encore la source des actualisations de 200 ms ?
La version de Denim indique que les blocs natifs de 200 millisecondes remplacent le précédent modèle d'aperçu Flashblocks. Les développeurs devraient utiliser la documentation post-mise à niveau et vérifier si d'anciennes hypothèses d'API subsistent dans leur application.
Pourquoi un portefeuille peut-il afficher un succès alors qu'un dépôt est en attente ?
Le portefeuille signale peut-être une inclusion réussie sur Base, tandis que le service récepteur attend un autre état de sécurité ou traite le dépôt via ses propres systèmes. Vérifiez le hash de transaction, le réseau, le jeton pris en charge et la politique de dépôt du service.
Une production de blocs plus rapide réduit-elle tous les frais ?
Non. Les frais dépendent de la tarification du réseau, de la complexité de la transaction et des frais de service. La cadence de blocs annoncée par Denim n'est pas une grille tarifaire. Comparez les coûts réels pour la transaction et l'application utilisées.
