
Un candidate block désigne un « bloc préliminaire » qui n’a pas encore été officiellement validé par la blockchain. Il est assemblé par des mineurs ou des validateurs sélectionnant un ensemble de transactions depuis le pool de transactions (mempool). Les candidate blocks occupent une phase transitoire, entre « transactions soumises » et « blocs confirmés ».
On peut comparer un candidate block à un colis en attente dans un centre de tri logistique : il contient déjà les transactions des utilisateurs, mais n’a pas encore été expédié. Ce colis n’est considéré comme confirmé qu’après acceptation par le réseau et enregistrement on-chain. Ce processus dépend de facteurs tels que les frais de transaction, la capacité du bloc, la propagation sur le réseau et le mécanisme de production des blocs.
Les candidate blocks servent de « propositions » en attente d’acceptation par le mécanisme de consensus, en vue d’être inscrits dans le prochain bloc à une nouvelle hauteur. Une fois acceptés, ils deviennent des blocs officiels, confirmant ainsi les transactions qu’ils contiennent.
Le « consensus » correspond au processus de vote et de vérification standardisé entre les nœuds du réseau. En Proof of Work (PoW), il s’agit de résoudre des calculs complexes ; en Proof of Stake (PoS), les validateurs sont sélectionnés selon les actifs mis en jeu. Les candidate blocks sont diffusés, vérifiés, et le réseau décide finalement lequel deviendra le prochain bloc valide. Ce choix influence à la fois la rapidité et la sécurité de la confirmation des transactions.
Étape 1 : Sélection des transactions depuis le mempool.
Le pool de transactions (mempool) regroupe les transactions en attente. Les nœuds vérifient signatures et règles de base : seules les transactions valides peuvent être incluses dans un candidate block.
Étape 2 : Définition des paramètres du bloc.
Cela implique la définition de l’en-tête du bloc, du timestamp, de la taille/du poids ou des limites de gas, ainsi que des récompenses du mineur ou du valideur (comme la transaction coinbase de Bitcoin ou les priority fees d’Ethereum). L’ensemble doit respecter les limites fixées par le protocole.
Étape 3 : Déclenchement de la production du bloc.
En Proof of Work, les mineurs essaient successivement différents nonces pour atteindre la cible de difficulté du réseau. En Proof of Stake, les validateurs désignés regroupent et signent les candidate blocks dans des slots attribués (comme sur Ethereum après le merge).
Étape 4 : Diffusion et vérification.
Lorsqu’un nœud reçoit un candidate block, il revalide la validité des transactions et les changements d’état. Il décide ensuite de l’adopter ou non en fonction de la hauteur de la chaîne et des règles de fork.
Étape 5 : Devenir un bloc officiel ou être remplacé.
Si un autre candidat est accepté en premier ou forme une chaîne plus longue, ce candidate block peut être écarté ; sinon, il est enregistré comme prochain bloc officiel.
L’objectif est de maximiser la valeur économique dans la limite de capacité du bloc tout en minimisant les conflits. Généralement, les transactions avec des frais élevés, sans dépendances ni conflits, et exécutables immédiatement sont priorisées et triées selon leur rentabilité et viabilité.
Sur Bitcoin, les mineurs privilégient les transactions à « fee rate » élevé (frais par virtual byte), dans la limite du poids maximal du bloc (environ 4 millions d’unités de poids en 2025). Sur Ethereum, EIP-1559 a introduit les frais de base et de priorité : les builders sélectionnent les transactions non conflictuelles offrant des priority fees plus élevées, dans la limite du gas block (généralement plusieurs dizaines de millions d’unités de gas).
D’autres critères entrent en jeu, comme l’ordre des nonces de compte (Ethereum exige des nonces strictement croissants), les transactions de remplacement (utilisateurs augmentant les frais pour accélérer la confirmation), ou les conflits de lecture/écriture entre transactions. Un candidate block bien construit réduit les conflits d’état et les échecs d’exécution, améliorant ainsi ses chances d’être accepté par le réseau.
Bien que les candidate blocks aient des fonctions similaires sur les deux réseaux, leur création et leur validation diffèrent. Bitcoin utilise le Proof of Work, où les mineurs gagnent en trouvant un hash valide pour leur candidate block. Après le Merge d’Ethereum, le Proof of Stake désigne des validateurs qui proposent des candidate blocks dans des slots temporels fixes, validés par le vote d’autres validateurs.
Sur Bitcoin, l’intervalle entre les blocs est en moyenne de 10 minutes (objectif protocolaire, observé jusqu’en 2025), ce qui implique des contraintes fortes sur le fee rate et le poids pour la sélection des transactions. Sur Ethereum, chaque slot dure environ 12 secondes (paramètre protocolaire, observé jusqu’en 2025), avec la Proposer-Builder Separation (PBS) : des builders spécialisés créent les candidate blocks, les proposers les sélectionnent et les signent, permettant une gestion plus fine de l’ordre des transactions et des gains potentiels comme le MEV.
Plusieurs candidate blocks peuvent exister simultanément sur le réseau. Les nœuds sélectionnent la chaîne la plus « efficace » — souvent la plus longue ou la mieux validée —, ce qui conduit à l’abandon de certains candidats ou à une réorganisation de la chaîne (reorg).
Les causes fréquentes sont les délais de propagation entraînant la création simultanée de blocs par différents mineurs, les propositions concurrentes de validateurs dans les systèmes PoS, ou des attaques liées à une concentration de puissance de calcul ou de stake. Ethereum a introduit la notion de « finality », rendant les blocs très peu susceptibles d’être annulés après un certain temps ; Bitcoin utilise le « nombre de confirmations », le risque diminuant à mesure que de nouveaux blocs sont ajoutés.
Pour les utilisateurs, les candidate blocks déterminent la rapidité de confirmation de leurs transactions. Les transactions à faible frais ou conflictuelles peuvent rester dans le mempool pendant une période prolongée, sans être incluses dans plusieurs candidate blocks successifs.
Par exemple, lors d’un retrait on-chain via Gate, la transaction entre d’abord dans le mempool, puis attend son inclusion dans un candidate block avant diffusion. Le « nombre de confirmations » affiché sur les pages de retrait indique si le bloc de la transaction a dépassé le stade de candidate block pour être largement accepté ; le risque diminue à mesure que le nombre de confirmations augmente.
Un candidate block n’est qu’une proposition. Dès qu’il est accepté par le réseau, il devient un bloc officiel et commence à accumuler les confirmations. Ce n’est qu’après avoir atteint un nombre suffisant de confirmations ou la finality qu’il devient irréversible, avec un risque minimal pour les fonds.
Conseil : payez des frais appropriés lors d’un envoi ou d’un retrait pour éviter une attente prolongée dans le mempool ; pour Bitcoin, attendez plusieurs confirmations avant de considérer les fonds comme sécurisés ; pour Ethereum, surveillez la finality (généralement en quelques minutes selon la congestion réseau). Si votre transaction est bloquée, vous pouvez l’accélérer en augmentant les frais ou en l’annulant et la renvoyant.
Les candidate blocks représentent une étape intermédiaire essentielle dans la production des blocs : sélection des transactions depuis le mempool, construction et diffusion selon les règles du protocole, puis officialisation par consensus. Leur sort dépend des frais, de la capacité, du mécanisme de production et de la propagation réseau — ils peuvent être remplacés en cas de concurrence. Comprendre les candidate blocks permet d’interpréter correctement le statut « en attente de confirmation », d’ajuster frais et délais, et d’optimiser la gestion des arrivées de fonds et du risque sur des plateformes comme Gate.
Si un candidate block n’est pas accepté par le réseau, il est écarté par les mineurs ou validateurs. Les transactions qu’il contient peuvent retourner dans le mempool pour une inclusion ultérieure. Cette situation est normale et n’expose pas les fonds des utilisateurs : les transactions non confirmées ne sont simplement pas encore on-chain. En période de congestion, les candidate blocks de priorité inférieure sont plus susceptibles d’être remplacés.
Si votre transaction est au stade candidate block, cela signifie qu’elle a été prise en charge et empaquetée par un mineur ou un valideur, mais n’a pas encore été définitivement confirmée on-chain. Ce délai varie généralement de quelques secondes à quelques minutes selon les conditions réseau : il s’agit d’un état d’attente standard. Vous pouvez consulter le statut du hash de transaction sur Gate ou tout autre explorateur de blocs pour obtenir des mises à jour en temps réel.
L’estimation du Gas affichée pour les candidate blocks est généralement une projection. Les mineurs ou validateurs ajustent dynamiquement selon la congestion réelle du réseau. Le montant final de Gas consommé est souvent inférieur à l’estimation initiale affichée dans les candidate blocks. Pour bénéficier de meilleurs prix du Gas, il est conseillé de transacter hors des périodes de pointe.
Le mempool fait office de « salle d’attente » pour toutes les transactions non confirmées ; les candidate blocks sont des sélections opérées dans ce pool par les mineurs ou validateurs. Les transactions entrent d’abord dans le mempool ; si elles sont retenues, elles sont intégrées dans un candidate block ; seule la confirmation de ce bloc les rend officiellement on-chain.
La vitesse de confirmation dépend principalement de l’intervalle de bloc et du mécanisme de consensus de chaque blockchain. Sur Bitcoin, l’intervalle moyen de 10 minutes est plus lent ; sur Ethereum, les slots d’environ 12 secondes sont nettement plus rapides ; les solutions Layer 2 comme Arbitrum permettent une confirmation en millisecondes. Le délai entre la génération et la confirmation finale d’un candidate block dépend entièrement de l’architecture de chaque chaîne.


