Das ist erstaunlich. Ich habe ein paar verschiedene Block-Builder durchgeklickt - Agave, Firedancer, BAM und Harmonic. Alle vier zeigen unterschiedliche Scheduling-Logiken. Wir haben auch Paladin und Rakurai, jeder mit seinen eigenen Versionen. Aus der Perspektive der Markt-Mikrostruktur hat man in TradFi ein unbeschränktes System: Aufträge kommen kontinuierlich an und werden FIFO von einer einzigen Matching-Engine ausgeführt. Diese Kontinuität ermöglicht es den Market Makern, Angebote zu stornieren, ohne ständig das Risiko einzugehen, ausgespielt zu werden. Keine Prioritätsgebühren erforderlich, und die Maker können Spreads von unter 1 bp bei Einzelgeschäften im Wert von Millionen Dollar anbieten. Auf den ersten Blick scheint Solana durch ~380 ms Slot-Zeiten eingeschränkt zu sein. Das stimmt, aber nur bis zu einem gewissen Grad. Dank Turbine shreddern Validatoren Transaktionen alle ~15–20 ms und propagieren diese Shreds im Netzwerk. Sobald ein Shred produziert wird, ist die Reihenfolge innerhalb dieses Batches festgelegt. Bei der aktuellen Blockauslastung, die weit unter den CU-Grenzen liegt, verhält sich Solana viel mehr wie ein gebündeltes FIFO-System, als es die Slot-Länge vermuten lässt. Allerdings ist das Shredding nur ein Teil des Bildes. Die andere große Einschränkung ist das Design des Schedulers. Verschiedene Block-Builder implementieren bedeutend unterschiedliche Scheduling-Logiken: wie Stimmen und Nicht-Stimmen miteinander verwoben sind, wann Nicht-Stimmen-Transaktionen innerhalb des Slots enthalten sind und wie wirtschaftlich verwandte Transaktionen gruppiert werden. Für prop AMMs führt dies zu Unsicherheiten. Selbst wenn Blöcke halb leer sind und keine Transaktionen aufgrund niedriger Prioritätsgebühren fallen gelassen werden, variiert die Reihenfolge von Slot zu Slot je nach Builder. Prop AMMs benötigen, dass Angebotsaktualisierungen und Taker-Transaktionen innerhalb eines Shreds vorhersehbar geordnet sind. Mit heterogenen Schedulern ist diese Reihenfolge über Slots hinweg nicht deterministisch, was es schwierig macht, über Ausführungszusagen nachzudenken. Man könnte sich vorstellen, dies mit Maker-Priorität oder Geschwindigkeitsbremsen für Taker-Flow zu mildern. Aber wenn das Ziel ICM auf Solana ist, benötigt dieses Problem eine systemischere Lösung. Zu erkennen, dass es ein Problem gibt, ist der erste Schritt zur Lösung, daher ist der IRBL-Explorer eine sehr wertvolle Ressource.