Alle bauen Agenten und Wallets. Fast niemand fragt, ob die Transaktionen tatsächlich ankommen.
Agenten bezahlen bereits für Dinge auf Ethereum. Nicht nur in einer Demo. x402 hat HTTP 402 in einen echten Payment-Flow verwandelt, und Agenten-Wallets werden inzwischen mit Schlüsseln und Ausgabelimits ausgeliefert. Teams bauen in der Annahme, dass eine Maschine ihre eigenen Verpflichtungen ohne eine anwesende Person begleichen kann.
Die Branche hat sich schnell bewegt, um Agenten Zahlungsfähigkeit zu geben, aber sie hat den darunterliegenden Teil übersprungen. Eine Payment-Rail setzt voraus, dass die Zahlung durchgeht, und Ethereum wurde nie auf dieser Annahme aufgebaut. Inklusion ist „Best Effort“: Man sendet eine Transaktion und hofft, dass sie im nächsten Block landet. Ein Mensch kann darum herumarbeiten, indem er eine stockende Transaktion beobachtet, die Gebühr anhebt und es erneut versucht. Man kann einen Agenten bauen, der dasselbe tut. Was man nicht bauen kann, ist Gewissheit: Ein Retry ist dieselbe Wette, erneut platziert, in einem Markt, der sich bereits bewegt hat.
All das ist bei einer einzelnen Transaktion nicht besonders wichtig. Es wird enorm wichtig bei zehntausend am Tag, wenn jede Aktion auf die vorherige wartet.
Ethereum settled Wert. Es terminiert ihn noch nicht.
Auf Ethereum wird Blockspace über eine Live-Auktion zugeteilt, die sich ungefähr alle zwölf Sekunden auflöst. Wenn man eine Transaktion einreicht, kauft man sich keinen garantierten Platz im nächsten Block. Man tritt in einen Wettbewerb ein, und dessen Ergebnis – sowohl ob man überhaupt inkludiert wird als auch was man letztlich zahlt – bleibt unbekannt, bis alles vorbei ist. Dieses Design ist elegant für ein permissionless Netzwerk. Es ist aber fremd für die Funktionsweise der institutionellen Finanzwelt.
Institutionen sind bereits auf Ethereum. Was sie nicht tun können, ist das Fahren von Strategien, die Garantien benötigen. Wenn ein Desk im Voraus weder wissen kann, ob eine Transaktion rechtzeitig ausgeführt wird, noch was sie kosten wird, kann es keine Größe dahinterstellen; diese Aktivität bleibt dann off-chain oder wandert dorthin, wo jemand diese Zusage macht.
Jahrelang lautete die Antwort auf Ethereums Grenzen: Durchsatz – mehr Transaktionen pro Sekunde, mehr Rollups, die die Nachfrage auffächern. Durchsatz misst, wie viel. Er sagt nichts darüber aus, wann. Das ist ein Problem der Zeit, nicht des Raums, und mehr Raum löst es nicht.
Die Lücke schließen
Mehrere Ansätze gehen jetzt in die Implementierung, jeder adressiert eine andere Schicht des Problems.
Preconfirmations ermöglichen es einem Proposer, sich zur Inklusion oder Ausführung einer Transaktion zu verpflichten, bevor der Block finalisiert ist. Das ist die direkteste Antwort auf das Timing-Problem: Der Agent muss nicht mehr senden und hoffen. Aber diese Zusage muss etwas bedeuten. Sie braucht breite Validator-Beteiligung, glaubwürdige ökonomische Unterlegung und durchsetzbare Konsequenzen, wenn ein Proposer nicht liefert. Systeme, die Preconfirmations mit gestaktem Collateral und Slashing-Bedingungen kombinieren, verwandeln ein Versprechen in eine einklagbare Verpflichtung.
Inclusion Lists greifen auf Protokollebene und begrenzen, was ein Builder weglassen darf. Das macht sie zu einem starken Werkzeug gegen Zensur. Aber sie lösen ein anderes Problem: Es ist nicht dasselbe, eine Transaktion schwerer ausschließbar zu machen, wie zuzusagen, wann sie ausgeführt wird. Eine Inclusion List legt einen Boden fest. Sie legt keinen Zeitplan fest.
Forward Markets verlängern diesen Zeitplan weiter in die Zukunft. Sie ermöglichen es Institutionen und Anwendungen, Blockspace zu reservieren, bevor sie ihn benötigen – so wie Energie, Bandbreite und Rechenkapazität im Voraus vor der Nachfrage kontrahiert werden. Das verwandelt zukünftige Kapazität in etwas, worum ein Käufer planen kann, statt in Echtzeit darum zu konkurrieren. Die Designfragen hier betreffen die Marktstruktur: transparenter Zugang, durch Validatoren verantwortete Lieferung und Mechanismen, die verhindern, dass eine kleine Zahl großer Käufer die Kapazität in der Hand konzentriert.
Jeder Ansatz kann Einschränkungen haben, die umdesignt werden müssen. Zusammen zeichnen sie die Konturen eines Marktes, auf den Agenten und Institutionen tatsächlich aufbauen können: Proposer-Zusagen, die etwas bedeuten, Protokoll-Garantien gegen Ausschluss und vorwärts gerichtete Kapazität, die mit institutioneller Nachfrage skaliert. Die einzelnen Ansätze haben noch Designfragen zu lösen. Die Richtung ist klar.
Ein Agent, der eine Position über zwei Venues abwickelt, muss wissen, dass das zweite Bein landet, bevor er sich zum ersten verpflichtet. Ohne das fährt er keine Strategie. Er platziert eine Wette und wartet ab.
Ethereum hat bereits glaubwürdiges Settlement aufgebaut. Die nächste Herausforderung ist, den Zugang zu diesem Settlement im Voraus programmierbar zu machen. Wenn Agenten Kapital in Maschinengeschwindigkeit koordinieren sollen, kann Blockspace nicht etwas bleiben, auf das sie nur bieten und hoffen, es zu erhalten. Es muss etwas werden, das sie terminieren können.