C'est incroyable. J'ai exploré quelques constructeurs de blocs différents - Agave, Firedancer, BAM et Harmonic. Les quatre montrent une logique de planification différente. Nous avons également Paladin et Rakurai, chacun avec ses propres versions. D'un point de vue microstructure de marché, dans le TradFi, vous avez un système non contraint : les ordres arrivent en continu et sont exécutés FIFO par un seul moteur de correspondance. Cette continuité est ce qui permet aux teneurs de marché d'annuler des devises sans risquer constamment d'être éliminés. Pas de frais de priorité nécessaires, et les teneurs peuvent proposer des écarts de moins de 1 bp sur des transactions uniques d'une valeur de millions de dollars. À première vue, Solana semble contraint par des temps de slot d'environ 380 ms. C'est vrai, mais dans une certaine mesure. Grâce à Turbine, les validateurs déchiquettent les transactions toutes les ~15–20 ms et propagent ces déchiquetages à travers le réseau. Une fois qu'un déchiquetage est produit, l'ordre au sein de ce lot est fixe. Avec une utilisation actuelle des blocs bien en dessous des limites de CU, Solana se comporte beaucoup plus comme un système FIFO par lots que la longueur du slot ne le suggérerait. Cependant, le déchiquetage n'est qu'une partie de l'image. L'autre contrainte majeure est la conception du planificateur. Différents constructeurs de blocs mettent en œuvre une logique de planification significativement différente : comment les votes et les non-votes sont entrelacés, quand les txs non-votes sont inclus dans le slot, et comment les txs économiquement liés sont regroupés. Pour les AMMs prop, cela introduit de l'incertitude. Même lorsque les blocs sont à moitié vides et qu'aucune tx n'est abandonnée en raison de frais de priorité faibles, l'ordre varie toujours d'un slot à l'autre en fonction du constructeur. Les AMMs prop ont besoin que les mises à jour de devises et les txs de preneurs soient ordonnés de manière prévisible au sein d'un déchiquetage. Avec des planificateurs hétérogènes, cet ordre est non déterministe à travers les slots, rendant difficile le raisonnement sur les garanties d'exécution. On pourrait imaginer atténuer cela avec une priorité pour les teneurs ou des ralentisseurs pour le flux des preneurs. Mais si l'objectif est l'ICM sur Solana, ce problème nécessite une solution plus systémique. Réaliser qu'il y a un problème est la première étape vers sa résolution, donc l'explorateur IRBL est une ressource très précieuse.