Le chemin d’entrée
Transaction signée
Validationsignature · format · état du compte · capacité à payer
Écartée, avec un motif renvoyépas en silence — l’émetteur sait pourquoi
Magasin de transactions
Diffusion aux pairs
Formation de lots, puis consensus
La validation est peu coûteuse et locale : les ressources coûteuses en aval ne servent qu’aux transactions qui pourraient s’exécuter.
rejetée
acceptée
Comment les transactions sont conservées
Les transactions acceptées ne sont pas conservées dans une file unique et plate. Le magasin maintient plusieurs vues sur le même ensemble, chacune répondant à une question différente.Un ensemble de transactions acceptéescinq vues dessus, pas cinq files
Séquence par comptePour cet émetteur, quelle transaction ensuite ?
Index de prioritéTous émetteurs confondus, que proposer au consensus en premier ?
Index d’expirationQui a dépassé son échéance ?
Index chronologiqueDe quoi ce pair n’a-t-il pas eu vent ?
Aire d’attenteBien formé mais pas encore éligible ?
C’est dans l’aire d’attente qu’un bug d’intégration devient visible : une transaction valide mais pas encore la prochaine de son émetteur est mise en attente, pas rejetée — elle devient éligible dès que le trou devant elle se comble.
L’aire d’attente mérite le plus d’attention, parce que c’est là qu’une catégorie de bug d’intégration devient visible. Une transaction peut être parfaitement valide sans être pour autant la prochaine de son émetteur — le plus souvent parce qu’une transaction antérieure du même compte n’est pas arrivée ou n’a pas été entérinée. Une telle transaction est mise en attente plutôt que rejetée : elle reste disponible et devient éligible dès que le trou devant elle est comblé. Un client qui soumet dans le désordre subit donc un délai plutôt qu’un échec, mais un client qui ne comble jamais le trou laisse du travail en attente jusqu’à son expiration.
L’index chronologique est ce qui rend la diffusion entre pairs incrémentale. Le mempool retient, pour chaque pair, jusqu’où il a été servi dans la chronologie, de sorte qu’une diffusion lui envoie ce qui lui manque plutôt que tout le pool. La chronologie est répartie en compartiments plutôt qu’en file unique, ce qui empêche un émetteur volumineux de monopoliser tous les créneaux de diffusion.
Diffusion et équité
Les nœuds n’apprennent pas chacun de leur côté l’existence des transactions. Un nœud qui accepte une transaction la diffuse à ses pairs, et les pairs ne sont pas traités de la même façon — les pairs en amont sont prioritaires, afin qu’une transaction se dirige vers les validateurs capables d’y donner suite plutôt que de se répandre uniformément sur le réseau. L’équité est suivie sur l’historique récent plutôt qu’imposée message par message. Le mempool tient un relevé glissant des émetteurs et des types de trafic ayant récemment consommé de la capacité, et s’en sert pour façonner ce qui sera servi ensuite. C’est le mécanisme qui empêche la tempête d’ordres et d’annulations d’un seul compte d’évincer le reste du réseau, sans exiger une limite de débit stricte par compte qui pénaliserait du market making légitime.Passage au consensus
Le consensus ne prend pas les transactions du mempool une par une. Les transactions sont rassemblées en lots, les lots sont diffusés aux validateurs en arrière-plan, et chacun est acquitté jusqu’à ce que son émetteur puisse prouver qu’une part suffisante du réseau le détient. Ce n’est qu’alors qu’une proposition de bloc peut le référencer. La conséquence est qu’une proposition de bloc porte des empreintes de lots plutôt que des corps de transactions, si bien que la taille des messages de consensus reste stable quand le débit augmente — et qu’un bloc entériné est toujours rejouable, parce que les données qui le sous-tendent ont été prouvées disponibles avant d’être référencées. Voir IntentionBFT pour la façon dont cette preuve est formée et utilisée.C’est aussi pourquoi l’admission dans le mempool n’équivaut pas à l’inclusion. Une transaction acceptée, stockée et diffusée est entrée dans la file ; elle n’a pas été séquencée. Rien du sort d’une transaction n’est arrêté tant que le consensus n’a pas entériné le bloc qui la contient.
Ce que cela signifie pour un client
- Un rejet à la soumission est informatif. Il est survenu avant le stockage de la transaction, et le motif décrit quelque chose que le client peut corriger.
- Le silence n’est pas un rejet. Une transaction peut être en attente derrière un trou que le client a lui-même créé. Suivez ce qui a été soumis et ce qui a été entériné, au lieu de supposer qu’un accusé de réception manquant signifie une perte.
- La séquence compte à l’intérieur d’un compte, pas entre comptes. Deux transactions d’un même émetteur ont une séquence définie. Deux transactions d’émetteurs différents sont séquencées par le consensus, pas par celui qui a soumis en premier.
- Les annulations ne sont pas privilégiées dans le mempool. La priorité d’annulation est une propriété de l’exécution du noyau, où les annulations passent avant les placements agressifs du même bloc — ce n’est pas une propriété de la mise en file.