Ce qui se casse généralement en premier sous charge n'est pas le débit, c'est le timing. Lorsque un réseau devient occupé, les blocs ne se remplissent pas simplement, ils deviennent plus difficiles à prédire. Les transactions arrivent, les frais augmentent, les validateurs réorganisent, et le chemin de l'envoi d'une transaction à son exécution devient incertain. J'ai vu des stratégies qui semblent précises en test échouer en production simplement parce que l'ordre d'exécution a changé d'une fraction de seconde. Une liquidation échoue parce qu'elle atterrit une position plus tard que prévu. Un arbitrage en plusieurs étapes complète la première partie mais la seconde partie voit un état légèrement différent parce qu'une autre transaction s'est glissée entre-temps. Ce ne sont pas des échecs dramatiques. Ce sont de petits changements d'ordre qui modifient discrètement les résultats.
À l'intérieur de Fogo, la différence se manifeste dans la façon dont cet ordre est géré. Le système fait un choix délibéré autour de la planification déterministe. Les transactions ne sont pas constamment remaniées en fonction de petites différences de frais une fois qu'elles entrent dans une fenêtre de planification. Elles sont placées dans des tranches de temps définies et ordonnées de manière prévisible au sein de ces tranches. En cas de trafic élevé, ce choix devient visible. Au lieu de voir le constructeur de blocs ajuster continuellement les positions en réponse à la pression des frais, vous voyez une structure plus fixe. Si une transaction entre dans une limite de planification donnée à temps, sa position relative est stable. Si elle arrive trop tard, elle ne concurrence pas à l'intérieur de cette même limite en enchérissant plus haut. Elle passe à la suivante.
J'ai tracé une stratégie de multi-transactions à travers des blocs consécutifs lors d'un test de congestion. Sur de nombreux systèmes, même lorsque vous concevez des transactions pour s'exécuter séquentiellement, il y a toujours un risque qu'une transaction non liée se glisse entre elles car l'ordre reste fluide jusqu'à la dernière minute. Sur Fogo, cette fluidité est réduite. Une fois que les transactions sont à l'intérieur de la même tranche de planification, il y a beaucoup moins de remaniement en milieu de fenêtre. La séquence s'exécute soit comme modélisée dans cette limite, soit se déplace proprement vers la suivante. L'imprévisibilité qui apparaît généralement sous stress est remplacée par une file d'attente plus claire.
Ceci produit un type de limitation différent. Sur la plupart des chaînes à haute variance, si vous voyez que vous êtes sur le point de perdre une position, vous pouvez tenter d'augmenter votre frais et d'avancer dans le même bloc. Le résultat est incertain, mais l'option existe. Sur Fogo, cette option est contrainte. Le planificateur priorise l'ordre prévisible plutôt que la re-prix de dernière seconde. Une fois qu'une limite de planification est effectivement définie, augmenter vos frais ne garantit pas que vous avancerez dans cette tranche. Si vous manquez la fenêtre, vous attendez. Le système réduit la variance de timing, mais il réduit également la capacité à réagir à l'intérieur de cette fenêtre de timing.
La couche de propagation soutient cette structure. Les validateurs se coordonnent autour d'intervalles de timing définis, et la propagation des transactions est réglée pour converger dans une latence limitée avant la finalisation. Le design ne vise pas à maximiser la flexibilité dans la composition des blocs au dernier moment possible. Il vise à garantir que ce que voient les validateurs s'aligne rapidement et de manière cohérente. Lorsque le trafic augmente, le système protège ces garanties de timing au lieu de s'étirer pour absorber un réordonnancement opportuniste. Le résultat est qu'en cas de stress, vous voyez un ordonnancement ordonné plutôt qu'une re-prix chaotique.
J'ai testé un arbitrage sensible à la latence qui dépendait de petits écarts de timing entre deux marchés liés. Sur des systèmes plus élastiques, il y a des moments où une mise à jour d'état est visible tandis qu'une autre accuse légèrement du retard. Cet écart peut créer une opportunité. Sur Fogo, ces écarts sont plus étroits car les transitions d'état se propagent et se finalisent dans des enveloppes de timing plus serrées. Les validateurs observent les changements dans un alignement plus étroit. La logique d'arbitrage s'est exécutée correctement, mais l'avantage a diminué car le système a réduit l'ambiguïté dont la stratégie dépendait. Rien ne s'est mal passé. L'environnement offrait simplement moins d'asymétrie temporelle à exploiter.
La coordination des validateurs sous ce modèle comporte de réelles exigences. Pour maintenir une planification déterministe et une latence limitée, les validateurs ont besoin d'une performance et d'une connectivité fiables. Lors d'un test de stress avec un léger retard de propagation entre des nœuds géographiquement éloignés, le système a préféré retarder légèrement la finalisation plutôt que de laisser passer et réconcilier des vues de transaction divergentes plus tard. La cohérence a été préservée, mais au prix d'attentes d'infrastructure plus strictes. Le design tolère moins de variance dans la performance des validateurs car les garanties de timing en dépendent.
Une condition limite a rendu le compromis clair. Un groupe de transactions ciblant le même contrat est arrivé près du bord d'une fenêtre de planification. Certaines sont entrées dans la tranche actuelle. D'autres, seulement légèrement plus tard, sont passées à la suivante. Sur un système basé sur les frais, ces transactions en retard auraient pu essayer de surenchérir et de forcer un réordonnancement partiel au sein du même bloc. Sur Fogo, la séparation est restée propre. Le planificateur n'a pas rouvert la limite pour accueillir des enchères plus élevées. Pour une application reposant sur un séquençage stable, cette prévisibilité était bénéfique. Pour un trader tentant de s'insérer devant des concurrents à la dernière seconde, l'opportunité n'existait pas.
Le déterminisme d'exécution s'étend à travers la finalisation. Parce que l'ordre est étroitement lié aux limites de planification, la finalité se comporte comme une continuation de cette structure plutôt que comme une seconde étape de filtrage probabiliste. Lors des pics de charge, je n'ai pas observé de micro-réorganisations opportunistes utilisées pour capturer des frais plus élevés en modifiant l'ordre des transactions. La mécanique du système réduit les incitations et l'espace pour ce comportement. Le timing reste contrôlé, et l'ordre reste aligné entre les validateurs.
Les implications dépendent de ce que vous construisez ou exécutez. Si votre application nécessite une exécution multi-étapes étroitement coordonnée, où un entrelacement inattendu pourrait briser des hypothèses, la rigidité de Fogo simplifie l'environnement. Vous pouvez estimer le timing d'inclusion avec une incertitude plus étroite. Vous êtes moins exposé à un remaniement soudain déclenché par la pression des frais. Si, cependant, votre stratégie dépend d'exploiter l'ambiguïté de l'ordre, de la re-prix dynamique, ou de brèves discordances de timing entre les participants, l'environnement offre moins de flexibilité. Les mêmes mécanismes qui réduisent la variance réduisent également la manœuvre stratégique.
Il y a une friction honnête dans ce design. La planification déterministe avec une latence limitée nécessite une performance de validateurs disciplinée et augmente les coûts d'infrastructure. Les outils construits autour de l'escalade élastique des frais doivent s'adapter à un système où les enchères tardives ont un impact limité à l'intérieur d'une limite de planification. Certaines stratégies perdent leur avantage non pas parce qu'elles sont défectueuses, mais parce que l'environnement ne produit plus les incohérences de timing sur lesquelles elles comptaient.
Ce qui s'effondre généralement sous charge est la prévisibilité du timing d'exécution. Sur Fogo, cette prévisibilité se maintient largement. Le compromis est que la capacité à remodeler le timing à la dernière seconde devient structurellement contrainte.