Aller au contenu
Financial Context Wiki

Temps de bloc

Le temps de bloc peut désigner un slot programmé, un intervalle cible de preuve de travail ou l'écart observé entre blocs canoniques. Voici comment mesurer chaque horloge sans confondre inclusion, confirmations et finalité.

Mis à jour

À des fins éducatives uniquement ; ne constitue ni un conseil en investissement ni une recommandation d’investissement. Les investissements peuvent entraîner des pertes.

Réponse directe

Le temps de bloc n’est pas un chronomètre universel. En preuve de travail, il désigne souvent la cible à long terme d’un processus aléatoire d’arrivée des blocs. En preuve d’enjeu par slots, il peut désigner la durée programmée d’une occasion de proposition. L’écart observé entre blocs canoniques est une troisième mesure ; inclusion, profondeur de confirmation et finalité ont leurs propres horloges.

Sur le Mainnet Ethereum, il existe 12-second slots et 32 slots par époque. Un proposant peut manquer son slot : des blocs produits adjacents peuvent être espacés de 24 seconds, 36 seconds ou davantage alors que le slot reste de 12 seconds. Pour Bitcoin, 600 seconds est l’intervalle moyen cible du système de difficulté, pas une échéance pour le prochain bloc.

Précisez chaîne, réseau, fork, fenêtre et horloge. L’horodatage d’en-tête est une donnée du protocole, pas nécessairement l’heure de réception par chaque nœud. Un intervalle nominal plus court peut avancer la première possibilité d’inclusion, mais ne garantit seul ni débit supérieur, ni frais réduits, ni moins de reorgs, ni finalité plus rapide.

Attente prévue
1.2 min
Gamme illustrative
54s - 1.5 min

Les résultats sont des approximations pédagogiques. Ils excluent les règles du site, les taxes, la latence, le comportement d'Oracle et d'autres paramètres spécifiques au protocole, sauf indication contraire.

Fonctionnement

  1. Fixez chaîne, réseau, couche, fork actif, tête canonique, nœud ou RPC et fenêtre UTC. Conservez les hashes ; la hauteur seule n’est pas unique.
  2. Définissez la mesure : intervalle cible, durée du slot, différence entre horodatages canoniques, réception locale, latence d’inclusion, profondeur ou temps de finalité.
  3. Recueillez hash, hash parent, hauteur ou slot, horodatage du protocole et réception monotone locale. Conservez slots manqués, blocs obsolètes et réorganisés comme états explicites.
  4. Parcourez l’ascendance canonique, calculez les intervalles et publiez échantillon, fenêtre, moyenne, médiane, percentiles, minimum, maximum et taux de slots manqués. Une moyenne ne décrit pas une distribution asymétrique.
  5. Appliquez le modèle de consensus. Pour Ethereum, distinguez slots, époques, head, safe et finalized. Pour Bitcoin, distinguez 600-second target, arrivées aléatoires selon le hashrate, chainwork, fenêtre de 2,016-block et règles d’horodatage.
  6. Décomposez la latence en diffusion, attente dans le mempool ou séquenceur, proposition, propagation, inclusion canonique, confirmations, safe/finalized et traitement par pont, plateforme ou application.
  7. Comparez des nœuds indépendants et testez dérive d’horloge, lacunes RPC, proposants manqués, variations du hashrate, partitions, reorgs, retards de finalité, pannes du séquenceur et changements de paramètres avant de fixer un SLA.

Exemples

  • Ethereum produit des blocs aux slots 1,000 et 1,003. L’écart programmé vaut (1,003 - 1,000) * 12 = 36 seconds ; 1,001 et 1,002 ont été manqués. La hauteur avance d’un bloc produit, le numéro de slot de trois.
  • Sur 300 slots, la fenêtre vaut 300 * 12 = 3,600 seconds. Avec 294 canonical blocks, il y a 6 missed slots, un ratio de 294 / 300 = 98% et un taux de 294 / 3,600 = 0.0816666667 blocks/second, dont l’inverse est 12.2448979592 seconds/block. C’est une statistique, pas une promesse.
  • Une époque dure 32 * 12 = 384 seconds = 6.4 minutes ; deux durent 768 seconds = 12.8 minutes. Votes et participation déterminent la finalité : ce n’est pas un SLA fixe ; Ethereum indique actuellement environ 15 minutes en conditions normales.
  • Dans le modèle exponentiel Bitcoin de moyenne 600 seconds, la probabilité d’aucun bloc en 1,200 seconds vaut e^(-1,200/600) = e^-2 = 13.5335283237%, et celle d’au moins un 86.4664716763%. La fenêtre cible vaut 2,016 * 600 = 1,209,600 seconds = 14 days ; aucun chiffre ne programme un bloc donné.

Risques

  • Employer la mauvaise chaîne, le mauvais réseau, couche, fork ou paramètre historique.
  • Comparer slot programmé, cible PoW et intervalle observé.
  • Traiter cible ou moyenne comme attente maximale garantie.
  • Choisir une fenêtre courte, calme ou sélectionnée.
  • Traiter l’horodatage comme heure exacte de production ou réception.
  • Mélanger des horloges locales non synchronisées.
  • Omettre les slots manqués ou les confondre avec des blocs vides.
  • Inclure des blocs obsolètes ou réorganisés dans la série canonique.
  • Compter les hauteurs sans vérifier hashes, parents et ascendance.
  • Masquer les lacunes RPC, indexeur, websocket ou logs comme comportement du réseau.
  • Publier une moyenne sans médiane, percentiles, étendue et échantillon.
  • Confondre attente du mempool ou séquenceur et production.
  • Confondre première inclusion ou une confirmation et finalité économique.
  • Convertir les confirmations en minutes déterministes.
  • Traiter l’objectif Bitcoin 10-minute target comme un SLA.
  • Ignorer hashrate, retard de difficulté et limites d’horodatage.
  • Ignorer la pression de propagation, validation et forks temporaires.
  • Traiter le 12-second slot Ethereum comme bloc non vide garanti.
  • Traiter un bloc L2 comme publication, règlement ou finalité L1.
  • Déduire TPS, frais, sécurité ou décentralisation du seul temps de bloc.

Idées fausses courantes

  • Chaque slot Ethereum contient un bloc. C’est une occasion ; proposant ou propagation peuvent échouer.
  • Bitcoin produit exactement un bloc toutes les dix minutes. C’est une cible et une moyenne ; chaque attente varie.
  • L’horodatage est l’heure de réception de tous les nœuds. Horodatage et arrivée locale ont des acteurs et horloges distincts.
  • Diviser le temps par deux double le TPS sûr et divise frais ou finalité. Capacité, charge, demande, propagation et votes restent indépendants.
  • Un bloc L2 rapide a déjà la finalité Ethereum. Inclusion du séquenceur, publication L1, inclusion canonique et finalité sont des états distincts.

Sujets connexes

Sources

Navigation

Rechercher dans le wiki...