Optimism vise une réduction de 20 % de l’intervalle de préconfirmation sur OP Mainnet, qui passerait de 250 millisecondes à 200 millisecondes, dans le cadre d’un déploiement progressif prévu pour le 31 août. Les sous-blocs, autrefois appelés Flashblocks, sont des mises à jour incrémentales du séquenceur envoyées pendant la construction d’un bloc normal, ce qui permet aux applications d’obtenir un retour avant que le bloc ne soit scellé. Le payload conserve le type ExecutionPayloadFlashblockDeltaV1, mais state_root, block_hash et withdrawals_root prennent des valeurs entièrement nulles, tandis que withdrawals devient une liste vide. Les logiciels peuvent toujours décoder le flux, même si quatre champs ne contiennent plus de données exploitables.
Pourquoi c’est important
Le risque se situe à la jonction avec le fournisseur. Les sous-blocs sont des préconfirmations, et non des blocs finalisés ou des engagements d’état, si bien que les consommateurs directs du flux doivent exécuter les transactions diffusées pour déduire l’état préconfirmé, plutôt que de lire les racines mises à zéro ou le hachage du bloc.
Les applications qui utilisent un fournisseur RPC compatible avec les sous-blocs peuvent continuer à employer les méthodes standard d’Ethereum, souvent avec le tag pending. Un fournisseur ou un nœud correctement configuré maintient sa propre vue de l’état, ce qui permet à eth_getBalance de renvoyer des données préconfirmées dérivées sans dépendre d’une racine d’état exploitable.
Impact sur le marché
La cadence accélérée constitue un véritable gain de scalabilité pour les applications sensibles à la latence, mais elle rend les contrôles d’intégration plus importants. Les équipes qui consomment directement le flux WebSocket doivent repérer les lectures des quatre champs concernés, considérer les valeurs de remplissage comme indisponibles et les exclure de l’état, des soldes et des données d’entrée des preuves.
Les fournisseurs qui transmettent le payload brut doivent en informer leurs clients. Alchemy documente des mises à jour de 200 ms via les points de terminaison RPC d’Optimism, tandis que QuickNode applique la migration à Optimism Mainnet et aux composants RPC de Sepolia. La date cible du 31 août peut évoluer et le déploiement est progressif. Les opérateurs doivent donc valider la prise en charge de ces données avant que la cadence accélérée n’atteigne leur environnement.
Questions fréquemment posées
-
Que sont les sous-blocs d’Optimism et sont-ils des blocs finalisés ?
Ce sont des mises à jour incrémentales du séquenceur envoyées pendant la construction d’un bloc normal. Elles fournissent un retour de préconfirmation, mais ne sont ni des blocs finalisés ni des engagements d’état.
-
Quelles valeurs deviennent inutilisables dans les payloads accélérés d’Optimism ?
state_root, block_hash et withdrawals_root prennent des valeurs entièrement nulles, tandis que withdrawals devient une liste vide. Le type de payload reste ExecutionPayloadFlashblockDeltaV1.
-
Pourquoi un décodeur peut-il manquer le risque lié à la migration vers 200 ms ?
Le payload conserve le type ExecutionPayloadFlashblockDeltaV1, de sorte que les logiciels peuvent l’analyser sans erreur, même si quatre champs ne contiennent plus de données exploitables.
-
Comment les consommateurs directs du flux doivent-ils calculer l’état préconfirmé ?
Ils doivent exécuter les transactions transportées par le flux et considérer les racines mises à zéro ainsi que le hachage du bloc comme absents. Les valeurs de remplissage ne doivent pas être intégrées à l’état en aval, aux soldes ni aux données d’entrée des preuves.
-
Comment les utilisateurs RPC peuvent-ils lire les soldes préconfirmés après ce changement ?
Un fournisseur ou un nœud RPC correctement configuré et compatible avec les sous-blocs maintient sa propre vue de l’état, ce qui permet à eth_getBalance, avec le tag pending, de renvoyer des données préconfirmées dérivées. Les fournisseurs qui transmettent les champs bruts doivent en informer leurs clients.
WuBlockchain
CoinDesk
Crypto Rank News
TheBlock