Constellation: Ein Vorschlag für MCP auf Solana

Praktische Erkenntnisse

• Constellation ist der erste formelle Vorschlag auf Protokollebene, um Multiple Concurrent Proposers (MCP) in großem Maßstab auf einer produktiven Blockchain zu implementieren.
• Constellation führt zwei neue Rollen ein (Proposer und Attester), die den Ermessensspielraum des Leaders bei der Blockerstellung begrenzen. Etwa 16 Proposer arbeiten gleichzeitig in einem 50-ms-Zyklus und fassen Transaktionen zu erasure-codierten pslices zusammen, die an 256 Attester verteilt werden. Der Attestierungsdatensatz bindet den Leader kryptografisch an die enthaltene Transaktionsmenge. Wurde ein pslice von einer ausreichenden Anzahl an Attestern bestätigt, kann der Leader die Transaktion nicht ausschließen, ohne einen ungültigen Block zu erzeugen, den das Netzwerk ablehnt.
• Constellation bietet selektive Zensurresistenz: In einem bestimmten Zyklus werden entweder alle hinsichtlich ihrer Gebühren konkurrenzfähigen Transaktionen aufgenommen oder keine davon.
• Angriffe durch inhaltssichtbare Sortierung und Timing-Manipulation bleiben ungelöst. Transaktionen unter Constellation sind zum Einreichungszeitpunkt für alle Proposer sichtbar, die sie empfangen. Aufgrund der Multi-Proposer-Architektur von MCP könnten sich diese Angriffsflächen sogar vergrößern statt verkleinern. Das aktuelle Design erkennt an, dass zeitbasierte Latenzmanipulationen nicht sanktionierbar sind.
• Constellation strukturiert bestehende Gebühren neu: Die Aufnahmegebühr entspricht der heutigen Basisgebühr, die Sortierungsgebühr der bestehenden Prioritätsgebühr. Die bedeutendere wirtschaftliche Veränderung besteht darin, dass Aktivitäten, die derzeit über Landing-Dienste außerhalb des Protokolls und Off-Chain-Gebührenvereinbarungen laufen, zum Protokoll zurückkehren sollen. Die stakegewichtete Rollenauswahl übernimmt bestehende Konzentrationsdynamiken. Die Nettoauswirkungen auf einzelne Validatoren lassen sich erst modellieren, wenn das endgültige SIMD von Constellation vorliegt.
• MCP erhöht die Reihenfolgelatenz, verringert aber die Aufnahmelatenz. Die Attester-Runde, das 50-ms-Zyklusfenster und die Batch-Zusammenstellung benötigen im Vergleich zum heutigen direkten TPU-Übermittlungspfad zusätzliche Zeit. Heute ist die Latenz bei Validatoren höher, die TPU-Transaktionen sofort bündeln, und niedriger bei solchen, die sie verzögern. Unter Constellation erhalten gültige Transaktionen nun eine begrenzte, vom Protokoll erzwungene Aufnahmegarantie.
• Constellation ist ausdrücklich nicht mit Modellen der Proposer-Builder Separation (PBS) kompatibel. Sobald der Attestierungsdatensatz den Ermessensspielraum des Leaders begrenzt, bleibt nichts mehr übrig, das ein spezialisierter Builder verkaufen könnte. Dieser Ansatz folgt einer grundlegend anderen Philosophie als Ethereums aktueller Umgang mit MEV.
• Empirische Benchmarks unter realistischen Netzwerkbedingungen gibt es noch nicht. Der wichtigste Datenpunkt, den Anza liefern kann, sind vergleichende Latenzprognosen für 200-ms-Slots unter dem aktuellen Protokoll und unter Constellation. Solange diese Daten fehlen, diskutiert die Community über Zielkonflikte, die sie nicht quantifizieren kann. 
• Constellation baut auf Alpenglow auf, dessen Mainnet-Start für das dritte Quartal 2026 geplant ist.

Einführung

Trotz eines erstaunlichen Mangels an Agaven reiste Brennan Watt, CEO von Anza, in die kalifornische Wüste, um Constellation vorzustellen – einen Vorschlag, Multiple Concurrent Proposers (MCP) auf Solana einzuführen. Es ist das strukturell ambitionierteste Upgrade und wohl der bisher folgenreichste MCP-Vorschlag auf Protokollebene, den eine produktive Blockchain vorgelegt hat. Er soll das vorübergehende Monopol des Leaders über die Transaktionsreihenfolge und den dadurch abschöpfbaren Wert beseitigen. Constellation demokratisiert den Blockspace auf Solana.

Dieser Artikel analysiert Constellation kritisch: was es löst, was es bewusst aufschiebt und was tatsächlich ungeklärt bleibt. Wir stellen ein dreistufiges Modell zur Bewertung der Zensurresistenz vor, vergleichen Constellation mit der aktuellen MCP-Landschaft und untersuchen, ob die damit verbundenen Zielkonflikte mit der Performance-Identität vereinbar sind, die Solana aufgebaut hat.

Kenntnisse über Alpenglow werden vorausgesetzt. 

Das Problem, das Constellation löst

Transaktionen sind das Lebenselixier von Solana. Sie werden gruppiert und in Form von Blöcken dauerhaft ins Netzwerk geschrieben. Doch die Entscheidung, welche Transaktionen in diese Blöcke gelangen und in welcher Reihenfolge, ist kein neutraler Prozess. 

Das Monopol des Leaders auf die Blockproduktion

Die Blockproduktion rotiert nach einem Leader-Zeitplan. Dabei ist jeweils ein Validator dafür verantwortlich, innerhalb eines bestimmten Zeitfensters Blöcke zu produzieren.

Während dieser Zeit werden Transaktionen direkt an die Transaction Processing Unit (TPU) des Leaders weitergeleitet, wo dieser sie üblicherweise vor allen anderen empfängt.

Der Leader befindet sich in einer ungewöhnlich mächtigen Position. Das heißt: Er kann eingehende Transaktionen beobachten, bevor sie öffentlich sichtbar sind.

Der Leader kann entscheiden, bestimmte Transaktionen nicht aufzunehmen, sie beliebig umzusortieren oder eigene hinzuzufügen.

Das ist ein strukturelles Merkmal der aktuellen Funktionsweise eines Konsenses mit einzelnem Leader und findet sich in unterschiedlicher Ausprägung heute bei praktisch jeder produktiven Proof-of-Stake-Blockchain.

Dass Solana keinen öffentlichen Mempool hat, verschärft diese Asymmetrie, statt sie zu verringern. Der öffentliche Mempool von Ethereum gibt Beteiligten einen gewissen Einblick in ausstehende Transaktionen. Dadurch entsteht eine Art Chancengleichheit zwischen versierten Akteuren, die darum konkurrieren, die Transaktionsreihenfolge auszunutzen.

Auf Solana lässt sich der Informationsvorsprung des Leaders aufgrund der Art der Transaktionsweiterleitung weniger gut anfechten. 

Maximal Extractable Value (MEV)

Unter normalen Bedingungen und bei ehrlichen Validatoren bleibt diese Macht weitgehend ungenutzt. Das Problem ist jedoch, dass Validatoren rational handelnde wirtschaftliche Akteure sind. Mit der Reife von Solana und dem weiteren Wachstum der Finanzaktivität steigt auch der mögliche Gewinn aus dem vorübergehenden Monopol des Leaders. Ein Validator, der diese Position nicht ausnutzt, verzichtet schlicht auf Einnahmen. Korrekt arbeitende Nodes geraten wirtschaftlich ins Hintertreffen. Das schafft einen Anreiz, die Qualität genau des Systems zu untergraben, an dem sie teilnehmen.

Dieser abschöpfbare Gewinn wird als Maximal Extractable Value (MEV) bezeichnet. Daian et al. formalisierten den Begriff erstmals in Flash Boys 2.0 als Miner Extractable Value, bevor er auf Proof-of-Stake-Netzwerke übertragen wurde. Er umfasst alles von Arbitrage und Frontrunning über Sandwich-Angriffe und selektive Zensur bis hin zu jeder anderen Strategie, die den Informations- und Positionsvorsprung des Leaders gegenüber den Nutzern ausnutzt, deren Transaktionen er verarbeitet.

Die Branche reagiert auf MEV vor allem mit dem Modell der Proposer-Builder Separation (PBS), das auf Ethereum über MEV-Boost implementiert ist. Unter PBS konkurrieren spezialisierte Builder darum, Blöcke zu erstellen, die den abschöpfbaren Wert maximieren. Proposer wählen lediglich den profitabelsten Block für die Produktion aus. Dieses pragmatische Modell formuliert das Problem neu: Es demokratisiert den Zugang zu MEV und verteilt die Erträge auf die Validatoren, statt sie bei den technisch versiertesten Akteuren zu konzentrieren. Denn das Modell geht davon aus, dass sich MEV zwangsläufig abschöpfen lässt.

Das Problem an dieser Sichtweise ist, dass PBS den Schaden für Nutzer nicht verringert – die Abschöpfung findet weiterhin statt, nur die Begünstigten haben sich geändert. PBS bekämpft einige der negativen Auswirkungen von MEV auf Netzwerk-Nodes, reduziert aber nicht den Schaden für die Nutzer des Netzwerks.

Auch Solanas Verhältnis zu MEV entwickelt sich weiter. Die Kombination aus kurzen Blockzeiten, direkter TPU-Übermittlung und einem wettbewerbsorientierten Validatorensatz hat eine eigene MEV-Landschaft hervorgebracht. Sie ist von Spam, Auktionen für Prioritätsgebühren und der Neuordnung von Transaktionen auf Validatorenebene geprägt. Jitos Block Engine ähnelt teilweise MEV-Boost: Sie bietet einen Off-Chain-Auktionsmechanismus, bei dem Searcher auf Transaktionsreihenfolgen bieten und die Erlöse zwischen Validatoren und Stakern aufgeteilt werden. Wie PBS verwaltet und verteilt Jito MEV also demokratischer, statt es vollständig zu beseitigen.

Constellation soll hier Abhilfe schaffen. Statt das Monopol des Leaders hinzunehmen und seine Folgen zu verwalten, soll es strukturell begrenzt werden. Die schädlichsten Formen von MEV sollen damit von vornherein unmöglich sein. Das Whitepaper von Constellation beschreibt dieses Ziel als „Infrastruktur der Internet-Kapitalmärkte, einen universellen Ort für wirtschaftliche Aktivitäten, an dem Nutzer darauf vertrauen können, dass die Marktstruktur fair ist“.

Traditionelle Finanzmärkte versuchen, ähnliche Schutzmechanismen durch Regulierung und gerichtliche Aufsicht durchzusetzen. Diese Schutzmechanismen greifen reaktiv und uneinheitlich und haben sich wiederholt als unzureichend erwiesen. Constellation will Fairness auf Protokollebene durchsetzen, sodass sie weder umgangen noch selektiv angewendet werden kann. Dazu soll Constellation Multiple Concurrent Proposers (MCP) auf Solana implementieren.

Multiple Concurrent Proposers

In einer traditionellen Blockchain mit einzelnem Leader ist ein Validator für die Produktion jedes Blocks verantwortlich. Dieser Validator, also der Leader, kontrolliert vorübergehend allein die Aufnahme und Reihenfolge von Transaktionen. Während dieser Validator Blöcke produzieren darf, bleiben alle anderen Netzwerkteilnehmer in diesem Zeitfenster passive Beobachter. Letztlich entscheidet der Leader, welche Transaktionen in welcher Reihenfolge aufgenommen werden.

Dieses Design ist aufgrund seiner Einfachheit attraktiv. Wenn ein einzelner Validator die Blockproduktion überwacht, entsteht kein Koordinierungsaufwand, es müssen keine widersprüchlichen Vorschläge geklärt werden und die Verantwortlichkeiten sind eindeutig. Allerdings entsteht damit auch ein einzelner Angriffspunkt. Das vorübergehende Monopol des Leaders ist die Hauptursache von MEV. Alle wichtigen bisherigen Gegenmaßnahmen akzeptieren diese Struktur und versuchen, ihre Folgen zu kontrollieren.

Multiple Concurrent Proposers (MCP) bezeichnet eine Klasse von Protokolldesigns, die dieses Monopol strukturell aufbrechen. Statt die exklusiven Blockproduktionsrechte jeweils einem einzelnen Leader zu übertragen, können bei MCP mehrere Nodes gleichzeitig Transaktionen vorschlagen. Kein einzelner Proposer kontrolliert die vollständige Transaktionsmenge. Stattdessen werden ihre Vorschläge gemäß den Protokollregeln zusammengeführt, üblicherweise durch eine eingeschränkte Assembler-Rolle.

Ein Nutzer, der eine Transaktion gleichzeitig an mehrere Proposer sendet, ist nicht mehr von einer einzelnen Node abhängig. Er hat nun mehrere unabhängige Wege zur Aufnahme. Ein Leader, der die Transaktion ausschließen will, muss berücksichtigen, dass andere Proposer sie bereits gesehen und Attester sie bereits bestätigt haben. Ein einzelner Leader stellt den endgültigen Block zusammen, sein Ermessensspielraum ist jedoch stark eingeschränkt.

Der wichtigste Zielkonflikt von MCP ist die komplexere Koordination. Wenn mehrere Nodes gleichzeitig Transaktionen vorschlagen dürfen, entstehen Fragen, die Designs mit einzelnem Leader vollständig vermeiden. Wie werden Konflikte gelöst, wenn zwei Proposer dieselbe Transaktion aufnehmen? Wie wird die Reihenfolge über mehrere Vorschläge hinweg bestimmt? Wie verhinderst du, dass ein versierter Proposer die Regeln für die Zusammenführung manipuliert? Das erhöht die Komplexität des Protokolls erheblich. Teams müssen Koordinationsprobleme rund um neue Node-Rollen, Zeitplanlogik, kryptografische Annahmen und Fehlermodi bewältigen. All das erfordert gründliche Tests.

Hier ist Präzision wichtig, da MCP in der Branche als unscharfer Sammelbegriff für verschiedene Designs mit deutlich unterschiedlichen Eigenschaften verwendet wird. In seiner einfachsten Form bietet MCP probabilistische Zensurresistenz: Eine an mehrere Proposer gesendete Transaktion lässt sich schwerer zensieren, da dafür mehrere Nodes zusammenarbeiten müssten. In einer stärkeren Form kann MCP strukturelle Zensurresistenz bieten: Es wird mathematisch unmöglich, dass der Leader einen Block produziert, der eine von einem ausreichenden Quorum bestätigte Transaktion zensiert. Genau das ist das Ziel von Constellation. Der Unterschied ist für Finanzanwendungen, die harte Garantien benötigen, enorm wichtig.

So funktioniert Constellation

Constellation ist ein Protokoll zur Implementierung von MCP auf Solana. Es ergänzt Alpenglow: Alpenglow verwaltet den Konsens, also Sicherheit, Lebendigkeit und Finalität. Constellation verwaltet dagegen die Marktstruktur – wer Transaktionen vorschlagen darf, wie diese Vorschläge bestätigt werden und was der Leader mit ihnen tun darf. Constellation erzeugt die Nutzlast, die Alpenglow finalisiert.

Architektur

Constellation führt zwei neue Rollen in Solanas Protokoll-Stack ein, die jeweils eine eigene Aufgabe haben. Gleichzeitig verändert es die Rollen von Leadern und Validatoren.

Proposer sind der Einstiegspunkt für Transaktionen. Zu jedem Zeitpunkt sind etwa 16 Proposer gleichzeitig aktiv. Sie werden zufällig nach Stake ausgewählt und rotieren alle 32 Zyklen (also etwa alle ~1,6 Sekunden). Nutzer senden ihre Transaktionen direkt an einen oder mehrere Proposer ihrer Wahl. Ein Proposer kann jede Transaktion annehmen oder ablehnen, wobei angenommene Transaktionen gültig sein müssen. In dieser Phase erzwingt keine Protokollregel die Aufnahme von Transaktionen. Die Garantie der Zensurresistenz greift erst später in der Pipeline. Jeder Proposer arbeitet in einem 50-Millisekunden-Zyklus. Innerhalb jedes Zyklus fasst ein Proposer seine angenommenen Transaktionen in einer Struktur namens pslice zusammen. Das Präfix „p“ wird nicht ausgesprochen und dient lediglich zur Unterscheidung von Alpenglows slices. Der pslice wird per Erasure Coding in 256 kleinere Teile aufgeteilt, die pshreds heißen. Jeder der 256 aktiven Attester erhält einen pshred. Das Erasure Coding verwendet einen Wiederherstellungsschwellenwert von 64. Somit reichen beliebige 64 der 256 pshreds aus, um den vollständigen pslice zu rekonstruieren. Jeder pshred enthält eine kryptografische Hash-Zusage für die vollständige Transaktionsliste. Dadurch kann der Leader weder andere Transaktionen einsetzen noch die Reihenfolge innerhalb eines pslice verändern, nachdem die Attester ihn bestätigt haben.

Attester empfangen pshreds von einem Proposer und leiten sie sofort an die nächsten ~2 Leader weiter, um mögliche Fehler oder Ausfälle abzufangen. Außerdem zeichnen sie den Commitment-Hash des empfangenen pslice auf. Am Ende jedes Zyklus signiert der Attester eine Attestierung – eine kryptografisch bindende Erklärung, die jeden in diesem Zyklus beobachteten pslice-Commitment-Hash auflistet. Diese Attestierung wird an den Leader gesendet und dient als Beweisdokument, das festlegt, welche Transaktionen der Leader aufnehmen darf. Der Datensatz ist stakegewichtet und signiert. Er kann daher weder gefälscht noch unbemerkt ignoriert werden. 

Der Leader in Constellation ist derselbe wie der Leader von Alpenglow – die Node, die den endgültigen Block produziert, der in den Konsens eingeht. Unter Constellation wird der Ermessensspielraum des Leaders jedoch durch den Attestierungsdatensatz stark eingeschränkt. Constellation erzwingt zwei verschiedene Schwellenwerte. Damit die aggregierte Attestierung gültig ist, müssen mindestens 60 % der Attester teilnehmen. Wird dieser Schwellenwert nicht erreicht, wird der Block vollständig übersprungen. Innerhalb dieser Menge muss der Leader jeden pslice aufnehmen, den mindestens 40 % der Attester bestätigt haben. Tut er das nicht, erzeugt er einen ungültigen Block, den das Netzwerk ablehnt. Dieses Design mit zwei Schwellenwerten trennt die Gültigkeit auf Blockebene von der Aufnahme pro Proposer. Der Leader kann also auch dann einen gültigen Block produzieren, wenn die Daten einiger Proposer nicht genügend Attester erreicht haben. Er kann jedoch keine Proposer selektiv ausschließen, deren Daten genügend Attester erreicht haben. Sobald der Leader alle bestätigten pslices zu einem Batch zusammengestellt hat, überträgt er diesen über Alpenglows Rotor an die Validatoren. 

Validatoren empfangen Batches über Rotor vom Leader und führen sie beim Eintreffen in einer Pipeline aus. Sobald der vollständige Block eingegangen ist, vergleichen die Validatoren ihn mit dem Attestierungsdatensatz. So bestätigen sie, dass jeder attestierte pslice eine entsprechende Einreichung im Block hat. Nur wenn alle Prüfungen erfolgreich sind, stimmt der Validator für die Finalisierung. Schlagen die Prüfungen fehl, stimmen die Validatoren über den Aufruf TrySkipWindow dafür, das gesamte Zeitfenster des Leaders zu überspringen. 

Zyklen und Blöcke

Ein Zyklus ist die grundlegende Zeiteinheit von Constellation. Er umfasst ein 50-Millisekunden-Fenster, das aus der UTC-Uhrzeit abgeleitet wird, indem der Unix-Zeitstempel in Nanosekunden durch 50.000.000 geteilt wird. Entscheidend ist, dass Zyklen nicht an den Slots von Alpenglow ausgerichtet sind. Ein Slot enthält mehrere Zyklen. Die in diesen Zyklen erzeugten Batches bilden die Nutzlast des Blocks des Leaders. Diese Unterscheidung ist wichtig: Der 50-ms-Zyklus ist der wirtschaftliche Takt, also das Fenster, in dem Zensurresistenz durchgesetzt wird. Der Slot bleibt dagegen Alpenglows Konsenseinheit.

Das Whitepaper definiert eine Toleranz für Zeitabweichungen zwischen Proposern und Attestern und passt das Attestierungsfenster entsprechend an. Warum das wichtig ist, zeigt folgendes Beispiel: Angenommen, die Uhr eines Proposers läuft 5 ms vor den Uhren der Attester. Die pshreds dieses Proposers könnten die Attester relativ zur Zyklusgrenze früher als erwartet erreichen. Dadurch erhalten Transaktionen in diesem pslice ein etwas größeres Zeitfenster, um Attestierungen zu sammeln. Umgekehrt könnten die pshreds eines Proposers mit nachgehender Uhr so spät eintreffen, dass sie vollständig aus dem Attestierungsfenster fallen, obwohl der Proposer sie „pünktlich“ übermittelt hat. In Rechenzentren, die Werkzeuge wie chrony oder GPS-Empfänger einsetzen, ist die Zeitsynchronisierung Routine. Die Abweichung liegt üblicherweise unter einer Millisekunde und damit deutlich innerhalb der Toleranzgrenzen von Constellation. Bedenklich ist, dass Constellation eine neue Variable einführt, die in Alpenglows rein logischem Zeitmodell nicht existierte. Das endgültige SIMD von Constellation sollte dafür Überwachungsgrenzen festlegen.

Wenn sich Constellation dem Ende einer Epoche nähert, können Proposer und Attester kurzzeitig unsicher sein, ob die nächste Epoche bereits begonnen hat. Während dieses Fensters arbeitet Constellation gleichzeitig in beiden Epochen. Dabei sind zwei Gruppen von Proposern und Attestern gleichzeitig aktiv. Alpenglows Konsens klärt auf natürliche Weise, welche Zyklen zu welcher Epoche gehören.

Lebenszyklus und Gebühren einer Transaktion

Eine Transaktion muss vor ihrer Ausführung vier Hürden passieren:

• Ein Proposer muss sie annehmen und in einen pslice aufnehmen.
• Dieser pslice muss genügend Attestierungen sammeln, um in den Batch des Leaders aufgenommen zu werden.
• Das Gebot der Transaktion muss hoch genug sein, damit sie innerhalb des Compute-Limits des Batches zur Ausführung ausgewählt wird.
• Der Block, der den Batch enthält, muss durch Alpenglows Konsens bestätigt werden.

Jede Transaktion enthält ein Gebot, also die Ausführungsgebühr pro Compute Unit. Dieses Gebot bestimmt ihre Reihenfolge innerhalb desselben Batches. Höhere Gebote werden zuerst ausgeführt.

Constellation teilt die Kosten einer Transaktion in zwei separate Gebühren auf:

• Eine Aufnahmegebühr.
• Eine Sortierungsgebühr.

Die Aufnahmegebühr ist ein kleiner, fester Betrag, der von der Größe und der Anzahl der Signaturen einer Transaktion abhängt. Sie wird an den Proposer gezahlt, der die Transaktion in seinen pslice aufgenommen hat. Die Gebühr fällt an, sobald die Transaktion den Attestierungsschwellenwert überschreitet – unabhängig davon, ob sie letztlich ausgeführt wird. Das entspricht der Basisgebühr im aktuellen System von Solana, jedoch mit einem wichtigen Vorbehalt: Sendet ein Nutzer dieselbe Transaktion zur Redundanz an drei Proposer, zahlt er die Aufnahmegebühr dreimal, also einmal pro Proposer. Schließlich hat jeder Proposer die Arbeit für die Aufnahme unabhängig ausgeführt. Sendet ein Nutzer dieselbe Transaktion zur Redundanz an n verschiedene Proposer, zahlt er die Aufnahmegebühr daher n-mal.

Die Sortierungsgebühr ist die größere, prioritätsbasierte Komponente. Sie ergibt sich aus den gesamten Compute Units der Transaktion, multipliziert mit ihrem Gebot. Sie wird nur einmal erhoben, da die Transaktion unabhängig von der Anzahl der Proposer, die sie aufnehmen, nur einmal ausgeführt werden kann. Eine Transaktion, die beispielsweise 200.000 Compute Units bei einem Gebot von 0,00001 SOL pro Compute Unit anfordert, zahlt eine Sortierungsgebühr von 2 SOL. Wurde dieselbe Transaktion zur Redundanz an vier Proposer gesendet, zahlt der Nutzer vier Aufnahmegebühren und eine einzige Sortierungsgebühr von 2 SOL. Die Sortierungsgebühr fließt proportional zum Stake der Nodes an das Ökosystem zurück. Das Whitepaper überlässt die Gestaltung dieses Mechanismus dem endgültigen SIMD.

Jedes gebührenzahlende Konto muss einen Mindestreservesaldo von etwa 0,001 SOL halten, um Gebührenmanipulationen zwischen gleichzeitig aktiven Proposern zu verhindern. Dadurch können Aufnahmegebühren immer bezahlt werden, selbst wenn mehrere Proposer gleichzeitig Transaktionen aufnehmen, die dasselbe Konto betreffen.

Constellation und Alpenglow

Alpenglow ist Solanas Konsensprotokoll. Es bestimmt, welche Blöcke gültig sind, in welcher Reihenfolge sie finalisiert werden und wie sich das Netzwerk von Fehlern erholt. Seine Komponenten Votor und Rotor ersetzen Tower BFT und die Gossip-basierte Weiterleitung von Stimmen. Dadurch verkürzt sich die Zeit bis zur Finalität erheblich. Alpenglow legt nicht fest, wer Transaktionen vorschlägt oder wie ihre Reihenfolge innerhalb eines Blocks bestimmt wird.

Constellation ist eine Marktstrukturschicht, die festlegt, was der Leader von Alpenglow mit den von ihm zusammengestellten Blöcken tun darf. Sie definiert, wer Transaktionen vorschlägt und wie ihre Reihenfolge innerhalb jedes Blocks bestimmt wird. Die von Constellation erzeugten Batches werden zur Nutzlast der Blöcke von Alpenglow. Alpenglows Votor notarisiert diese Blöcke anschließend gemäß seinen vordefinierten Abstimmungsregeln. Die beiden Protokolle sind so zusammengesetzt, dass Alpenglow Sicherheit und Lebendigkeit gewährleistet, während Constellation eine faire Reihenfolge sicherstellt.

Dank dieser Kombinierbarkeit übernimmt Constellation auch die Sicherheitsannahmen von Alpenglow, ohne sie abzuschwächen. Constellation verändert die Garantien von Alpenglow nicht. Stattdessen führt es neue Garantien und Annahmen für die neuen Rollen der Proposer und Attester sowie die Synchronisierung mit der UTC-Uhrzeit in seinem neuen zyklusbasierten Zeitmodell ein.

Constellation ist der erste formelle Vorschlag auf Protokollebene, MCP auf einer skalierbaren, produktiven Blockchain zu implementieren. Es ist eine bedeutende Ergänzung, die Solana Zensurresistenz verleiht – das nächste Kapitel einer Protokoll-Roadmap, die Alpenglow eröffnet.

Was Zensurresistenz tatsächlich erfordert

Die MEV-Literatur hat das Problem historisch aus mehreren unterschiedlichen Perspektiven betrachtet. Zusammen ergeben sie ein einheitlicheres Bild davon, was jeder Vorschlag zur Zensurresistenz tatsächlich lösen muss. Ausgehend von Eskandari et al.’s grundlegender Taxonomie von Frontrunning-Angriffen, Garimidi et al.’s formalem Zwei-Eigenschaften-Modell für MCP-Protokolle und Landers und Marshs Analyse MCP-spezifischer MEV-Kanäle schlagen wir vor, die Angriffsfläche in drei klar getrennte Ebenen zu unterteilen. Jede erfordert eine andere Lösungsklasse. Dieses Modell ist unsere eigene Synthese, die wir hier zur Bewertung des Designs von Constellation vorstellen.

Ebene 1: Harte Zensur

Harte Zensur bezeichnet die Fähigkeit eines Leaders oder Proposers, eine identifizierte Transaktion nicht aufzunehmen. Dies ist die offensichtlichste Form der Manipulation und Constellation löst sie strukturell. Unter Constellation ist es kryptografisch unmöglich, dass ein Leader einen gültigen Block erzeugt, der eine gebührenmäßig konkurrenzfähige Transaktion ausschließt, die von einem ausreichenden Quorum von Attestern bestätigt wurde. Dafür ist kein Slashing erforderlich, da die Architektur die Regel durchsetzt.

Ebene 2: Inhaltsbasierte Reihenfolge

Die zweite Ebene ist schwieriger zu lösen. Proposer können Transaktionen zwar nicht vollständig zensieren, aber weiterhin deren Inhalt vor der endgültigen Reihenfolge einsehen und versuchen, diese Sichtbarkeit auszunutzen, etwa durch einen Sandwich-Angriff auf einen großen Trade. Garimidi et al. formalisieren dies als Hiding-Eigenschaft: Ein Angreifer darf den Inhalt von Transaktionen nicht sehen können, bevor sie bestätigt sind. Constellation implementiert partielles Hiding. Eine Transaktion ist also nur für den Proposer sichtbar, der sie empfängt, nicht für alle Proposer. Der Leader sieht den Transaktionsinhalt erst nach Ablauf der Zyklusfrist. Das ist besser als vollständige Sichtbarkeit, erfüllt aber Garimidi et al.’s Hiding-Eigenschaft nicht vollständig. Diese verlangt, dass der Inhalt einer Transaktion vor der Bestätigung für alle Parteien unsichtbar bleibt. Der empfangende Proposer kann den Inhalt der erhaltenen Transaktionen weiterhin einsehen und ausnutzen.

Die größere Sorge bei Constellation ist, dass MCP mit öffentlicher Transaktionsübermittlung die inhaltsbasierte Ausnutzung verstärken könnte. Es entsteht ein System, in dem jeder Proposer die empfangenen Transaktionen sieht und diese Sichtbarkeit innerhalb seines eigenen pslice ausnutzen kann. Die Angriffsfläche unterscheidet sich vom Single-Leader-Modell, da mehrere Akteure jeweils eine Teilmenge sehen können. Wer nur an einen Proposer übermittelt, legt die Transaktion nur diesem offen. Wer sie zur Redundanz an mehrere Proposer übermittelt, vergrößert die Offenlegung proportional. Landers und Marsh formalisieren diese Dynamik: Gleichzeitige Blockproduktion schafft Timing-Spiele, Möglichkeiten zur Duplizierung im selben Tick und das strukturelle Fehlen eines einzelnen Builder-Engpasses, der derzeit begrenzt, wie viele Extraktionsversuche pro Opfertransaktion erfolgreich sein können. Wird die Proposer-Gruppe dezentralisiert, ohne die Inhaltssichtbarkeit zu lösen, vervielfacht sich die MEV-Angriffsfläche, statt zu schrumpfen.

Landers und Marshs Analyse MCP-spezifischer MEV-Kanäle geht von einer breiteren Inhaltssichtbarkeit aus, als Constellation sie bietet. Bei Constellations partiellem Hiding hängt die Verstärkung inhaltsbasierter Ausnutzung von der Übermittlungsstrategie der Nutzer ab und ist keine architektonische Zwangsläufigkeit. Wer an einen einzigen vertrauenswürdigen Proposer übermittelt, hat ungefähr dasselbe Offenlegungsprofil wie im heutigen Single-Leader-Modell. Dafür verzichtet eine Übermittlung an nur einen Proposer auf die Redundanz, von der Zensurresistenz abhängt. 

Ebene 3: Manipulation von Timing und Latenz

Die subtilste und am schwersten zu bestrafende Ebene betrifft die Manipulation von Timing und Latenz. Unter Constellation kann ein Proposer die Weiterleitung von pshreds an Attester gerade so lange verzögern, dass die Transaktion eines Konkurrenten aus dem Attestierungsfenster fällt. Er kann auch Abweichungen der UTC-Uhr ausnutzen, um zu beeinflussen, welche Transaktionen genügend Attestierungen erhalten. Das Constellation-Whitepaper erkennt diese Lücke direkt an: Eine verspätete Nachrichtenzustellung „kann nicht bestraft werden“, weil sie nicht von einer echten Netzwerkverzögerung zu unterscheiden ist. Auf dieser Ebene könnte Slashing relevant werden. Sie ist die wichtigste offene Frage, die Constellations künftiges SIMD lösen muss. 

Constellations Design beruht auf der grundlegenden Annahme, dass die Beziehung zwischen Proposer und Nutzer nicht anonym ist. Es handelt sich um wiederholte Interaktionen, bei denen Vertrauen messbar ist und Reputation zählt. Sind zu einem Zeitpunkt etwa 16 Proposer aktiv, kann ein Nutzer bei dauerhaft schlechter Behandlung durch einen Proposer zu einem der anderen 15 wechseln. Dadurch entsteht zwar kein Onchain-Artefakt, mit dem sich ein böswilliger Akteur direkt bestrafen lässt, aber Proposer tragen wirtschaftliche Konsequenzen, wenn sie ihre Position ausnutzen. Ob dieser Reputationsdruck im Vergleich zu einer Lösung wie Slashing ausreicht, um Timing-Manipulation abzuschrecken, bleibt offen. Die Antwort wird wahrscheinlich davon abhängen, wie transparent das Verhalten der Proposer für Nutzer im Laufe der Zeit wird. 

Auswirkungen auf Validatoren und Nutzer

Validatoren

Constellation verteilt MEV-Chancen unter Validatoren neu, statt sie vollständig zu beseitigen. Die derzeit offensichtlichste und direkt abschöpfbare Einnahmequelle für Leader, also harte Zensur, wird absichtlich unmöglich. Sie wird jedoch durch subtilere, schwerer zu bestrafende Timing-Kanäle ersetzt. Diese bevorzugen Validatoren mit Latenzvorteilen, präziser Uhrsynchronisierung und der nötigen technischen Reife, um Weiterleitungsfenster für pshreds konsequent auszunutzen. Im Ergebnis ändert sich, wie Validatoren Wert abschöpfen, statt die gesamte Extraktionsfläche zu verkleinern. Allerdings wird die Extraktion deutlich schwieriger.

Constellation führt weniger grundlegend neue Gebührenströme ein, als dass es bestehende neu strukturiert. Die Aufnahmegebühr entspricht ungefähr der heutigen Basisgebühr, die Ordnungsgebühr der bestehenden Prioritätsgebühr. Die Aufteilung dürfte den heutigen Einnahmen der Validatoren ähneln. Der Unterschied liegt vor allem im Betrieb. Gute Betreiber sollten als Proposer mehr Aufnahmegebühren verdienen. Innerhalb der bestehenden Ökonomie entsteht damit ein leistungsabhängiges Gefälle statt einer separaten Einnahmekategorie. Die Attester-Rolle wird im aktuellen Design nicht separat vergütet. Wie die heutige Teilnahme an Turbine soll sie ausgeführt werden, weil sie für das Netzwerk insgesamt vorteilhaft ist. Die wichtigere wirtschaftliche Veränderung betrifft Aktivitäten, die derzeit über Landing-Services außerhalb des Protokolls, marktbasierte Auktionen und Offchain-Gebührenvereinbarungen laufen. Sie sollen ins Protokoll zurückkehren und Validatoren direkter zugutekommen. Bis das SIMD die genauen Mechanismen festlegt, bleibt die wirtschaftliche Nettowirkung auf einzelne Validatoren jedoch offen. Das gilt besonders für kleinere Validatoren, bei denen die nach Stake gewichtete Auswahl die Proposer-Häufigkeit reduziert und der Infrastrukturaufwand die Kostenuntergrenze anhebt.

Proposer und Attester werden nach Stake-Gewicht ausgewählt. Daher prägen dieselben Konzentrationsdynamiken, die die Validator-Ökonomie bestimmen, auch die Teilnahme an diesen Rollen. Dominiert eine kleine Zahl von Validatoren mit hohem Stake die Proposer-Auswahl, bleibt die Garantie der Zensurresistenz formal bestehen. Die praktische Vielfalt der Proposer-Gruppe sinkt jedoch, auch wenn sie weiterhin eine Verbesserung gegenüber Solanas aktuellem Zustand darstellt, also n aus 1 gegenüber n aus 16. Die Annahme der Unabhängigkeit wird in der Praxis schwächer, selbst wenn sie theoretisch gilt. Das ist angesichts neuer Validator-as-a-Service (VaaS)-Angebote relevant, durch die ein einzelner Akteur mehrere Validatoren mit hohem Stake betreiben kann. Ob das SIMD Mechanismen gegen Konzentration oder Anreize für die Proposer-Auswahl einführt, ist eine Designfrage mit direkten Folgen für die Stärke der von Constellation versprochenen Garantien. 

Nutzer

Eine gebührenmäßig konkurrenzfähige Transaktion, die an genügend Proposer übermittelt wird, ist für Nutzer erstmals durch eine harte Protokollgarantie gegen selektiven Ausschluss geschützt. Finanzanwendungen lassen sich nun mit Garantien entwickeln, die es bisher schlicht nicht gab. Das verändert, was nur auf Solana möglich ist. 

Nutzer mit hoher Handelsfrequenz oder hoher Preissensibilität müssen Transaktionen nun zur Redundanz an mehrere Proposer übermitteln. Die Sorge ist, dass die Dezentralisierung der Proposer-Gruppe ohne eine Lösung für die Inhaltssichtbarkeit die Gefahr von Sandwich-Angriffen erhöhen kann. Jeder Proposer kann die an ihn übermittelten Transaktionen sehen und darauf reagieren. Nutzer, die zur Redundanz an mehrere Proposer senden, erhöhen daher proportional die Zahl der Parteien, die den Transaktionsinhalt sehen. Dadurch verschwindet zwangsläufig der Engpass eines einzelnen Leaders, und die Transaktionsabsicht wird an eine größere Gruppe potenzieller Angreifer übertragen. In der Praxis müssen erfahrenere Nutzer neue Übermittlungsstrategien entwickeln, die Redundanz und Offenlegung ausbalancieren. Statt breit angelegter Mehrfachübermittlungen könnten sie Proposer beispielsweise gezielt nach Reputation oder Stake auswählen.

Für Market Maker beseitigt Constellations Aufnahmegarantie insbesondere das gegnerische Risiko, dass die Infrastruktur die Ausführungsqualität bestimmt. Übrig bleibt reine Informationsasymmetrie. Das entspricht dem Risikoprofil, dem Market Maker heute an den besten traditionellen Handelsplätzen begegnen. Diese Annäherung macht das Argument für Aufnahme und Latenzreduzierung konkret statt nur ambitioniert. Wir behandeln sie ausführlicher im Abschnitt „Offene Fragen“.

Die wahrgenommene Erfahrung durchschnittlicher Nutzer dürfte sich insgesamt nur geringfügig ändern. Die Aufnahmegarantie verbessert die Zuverlässigkeit jedoch deutlich. Bis künftige Benchmarks vorliegen, bleibt die Nettowirkung auf die Sequenzlatenz eine offene empirische Frage.

Marktüberblick: Constellation im Vergleich

Sei Giga

Sei Giga ist im aktuellen MCP-Umfeld das nächste Gegenstück zu Constellation. Es ist eine produktionsreife Blockchain, die MCP als vorrangiges Architekturziel verfolgt und nicht als künftiges Forschungsziel. Ein Vergleich ist aufschlussreich, weil beide auf derselben Ebene unterschiedliche Kompromisse eingehen.

Gigas Konsensgrundlage heißt Autobahn. Es ist ein Multi-Proposer-BFT-Protokoll, in dem jeder Validator kontinuierlich eine eigene „Lane“ mit Vorschlägen parallel betreibt. Statt sich auf einen einzelnen Leader zu verlassen, verteilt jeder Node fortlaufend einen eigenen Stream von Datenvorschlägen über unabhängige Lanes. Die Konsensschicht bestätigt regelmäßig einen „Tip Cut“, also einen kompakten Snapshot, der die neuesten Vorschläge aller Lanes zusammenführt. Architektonisch unterscheidet sich das von Constellations Modell, in dem etwa 16 ausgewählte Proposer in einem festen 50-ms-Zyklus arbeiten. Das Lane-basierte Modell von Autobahn erlaubt jedem Validator, kontinuierlich eine Proposal-Lane zu betreiben, statt aus einer rotierenden, nach Stake gewichteten Teilmenge ausgewählt zu werden. Dadurch wird die Teilnahme an der Blockproduktion erheblich ausgeweitet.

Der folgenreichste Unterschied betrifft die inhaltsbasierte Reihenfolge. Autobahn ermöglicht asynchrone Ausführung, indem es Transaktionsreihenfolge und Ausführung voneinander trennt. Constellation verschiebt diese Designentscheidung. Wie im nächsten Abschnitt erläutert, verkleinert asynchrone Ausführung die Angriffsfläche der inhaltsbasierten Reihenfolge. Proposer können Ausführungsergebnisse zum Zeitpunkt der Sortierung nicht anhand eines bekannten endgültigen Zustands simulieren.

Giga bietet probabilistische Zensurresistenz, Constellation dagegen strukturelle Garantien. Giga beruht auf der Annahme, dass eine an mehrere Proposer übermittelte Transaktion schwerer zu zensieren ist. Jeder Proposer arbeitet mit unvollständigen Informationen, und der Nutzen der Zensur kann entfallen, wenn ein anderer Proposer die Transaktion im selben Tick aufnimmt. Bei Constellation erzeugt ein Leader dagegen einen ungültigen Block, wenn er eine ausreichend attestierte Transaktion ausschließt. Probabilistische Resistenz erhöht die Kosten der Zensur. Strukturelle Resistenz macht Zensur kryptografisch unmöglich. Für die Finanzanwendungen, die beide Protokolle ermöglichen wollen, ist dieser Unterschied entscheidend. 

Die unterschiedlichen Ambitionen der beiden Designs sollten offen benannt werden. Constellation ist eine Protokollspezifikation, die Korrektheitseigenschaften beweist, Fehlerbedingungen definiert und Quorum-Schwellen festlegt. Sie soll als formaler Vorschlag für ein skalierbares Produktionsnetzwerk mit Milliarden an gestaktem Wert eingereicht werden. Das Sei-Giga-Whitepaper liest sich anders. Es konzentriert sich auf Durchsatzversprechen und EVM-Kompatibilität. MEV und Zensurresistenz behandelt es als entstehende Vorteile der Multi-Proposer-Architektur, nicht als formal spezifizierte Garantien. Asynchrone Ausführung weist in die richtige Richtung. Giga bietet jedoch nicht dasselbe Niveau formaler Garantien für Reihenfolgebeschränkungen, Attester-Quoren oder Fehlerbedingungen wie Constellation. Das ist weniger Kritik an Gigas Sequenzierungsentscheidungen als ein Ausdruck unterschiedlicher Kontexte. Constellation wird für die produktive Blockchain mit dem weltweit höchsten Durchsatz vorgeschlagen. Das verlangt und liefert einen entsprechend höheren Spezifikationsstandard.

Das akademische Ideal

Der theoretische Maßstab für MCP-Design ist Multiple Concurrent Proposers: Why and How (2025) von Garimidi und Neu von a16z Crypto Research sowie Max Resnick von Anza. Das Paper schlägt ein MCP-Protokoll mit zwei Eigenschaften vor, die laut den Autoren jedes zensurresistente Design erfüllen muss: Resistenz gegen selektive Zensur und Hiding. Erstere garantiert, dass ein Angreifer Transaktionen nicht selektiv verzögern kann. Letztere garantiert, dass Transaktionsinhalte vor der Bestätigung unsichtbar bleiben. Es ist das einzige MCP-Design in der aktuellen Literatur, das beide Eigenschaften formal und gleichzeitig erreicht.

Der Mechanismus für Hiding ist HECC, der Hiding Erasure-Correcting Code. Seine Parameter stellen sicher, dass beliebige T shreds keine Informationen über den zugrunde liegenden Transaktionsbatch offenlegen, während K + T shreds eine vollständige Rekonstruktion erlauben. Entscheidend ist, dass Relays ihre gespeicherten shreds erst übertragen, nachdem der Konsens bestätigt hat, welche Batches aufgenommen werden. Dadurch kann der Transaktionsinhalt vor der Bestätigung nicht eingesehen werden. Die Angriffsfläche der inhaltsbasierten Reihenfolge wird als informationstheoretische Garantie vollständig geschlossen. 

Übertragen auf das zuvor entwickelte Modell ist dieses Protokolldesign das einzige, das Ebene 1 mit struktureller Zensurresistenz und Ebene 2 mit Hiding löst. Zudem begrenzt es Ebene 3 durch die von Hiding bereitgestellten Zensurresistenzgarantien. Weder Constellation noch Giga erreichen all das vollständig.

Besonders interessant ist, dass Resnick sowohl Co-Autor des theoretischen Ideals als auch Co-Autor von Constellation ist, obwohl das Protokoll bewusst davon abweicht. Dahinter steht die bewusste Einschätzung, dass sich das vollständige HECC-basierte Design noch nicht in einem Produktionsnetzwerk von Solanas Größe einsetzen lässt und strukturelle Zensurresistenz zuerst gelöst werden muss. Das Paper dient Constellation als Leitstern: eine formale Spezifikation des Ziels, auf das sich das Protokoll zubewegt, auch wenn es nicht alles auf einmal liefern kann. 

Ethereum Braid

Braid ist Ethereums wichtigster MCP-Vorschlag. Er wurde von Max Resnick vorgestellt und wird derzeit neben dem konkurrierenden FOCIL-Design mit Aufnahmelisten als Teil von Ethereums Scourge-Roadmap erwogen. Seine Aufnahme hier dient weniger dem technischen Vergleich als dem Kontext: Die gesamte Branche versucht, dieselben strukturellen Probleme von unterschiedlichen Ausgangspunkten aus zu lösen.

Braid implementiert MCP, indem mehrere Proposer gleichzeitig innerhalb desselben Slots Blöcke über parallele Chains erstellen. Die Ausführungsschicht aggregiert, dedupliziert und sortiert Transaktionen nach festgelegten Regeln. Zusätzliche Protokollrollen werden nicht eingeführt. Der wichtigste Unterschied ist, dass Braids Sicherheit stark von verschlüsselten Mempools abhängt. Hiding ist damit Voraussetzung und wird nicht auf später verschoben. Braid bleibt ein noch nicht eingesetzter Forschungsvorschlag. Die Ethereum-Community hat noch keinen Konsens darüber erreicht, ob sie ihn FOCIL vorziehen soll.

Braid bestätigt letztlich, dass das strukturelle Argument für MCP über einzelne Chains hinausgeht. Bemerkenswert ist außerdem, dass Resnick an drei der vier Einträge in diesem Abschnitt mitgearbeitet hat. Das ist vielleicht das klarste Zeichen dafür, dass Constellation das Ergebnis langfristiger, kontextübergreifender und akademisch fundierter Arbeit an einem Problem ist, für das es keine einfachen Lösungen gibt.

Eine Anmerkung zu PBS

Proposer-Builder Separation (PBS) ist hier eher als Gegenmodell denn als vergleichbares Design erwähnenswert. Jeder andere Eintrag in diesem Abschnitt versucht, das vorübergehende Monopol des Leaders strukturell einzuschränken. PBS akzeptiert es dagegen und optimiert darum herum, um MEV-Erlöse neu zu verteilen. Constellation ist ausdrücklich nicht mit PBS kompatibel. Sobald der Ermessensspielraum eines Leaders durch den Attestierungsdatensatz eingeschränkt wird, kann ein spezialisierter Builder nichts mehr verkaufen. Dass PBS trotz fehlender Schadensminderung für Nutzer zur vorherrschenden MEV-Gegenmaßnahme auf Ethereum geworden ist, entspricht genau dem Fehlermodus, den MCP vermeiden soll.

Der Präzedenzfall außerhalb des Protokolls

Schon bevor Constellation erscheint, bildet Solanas Ökosystem einige Aspekte von MCP außerhalb des Protokolls nach. Harmonic ist beispielsweise eine offene Aggregationsschicht für den Blockbau. Sie sammelt und bewertet kontinuierlich Blockvorschläge mehrerer unabhängiger Builder und legt sie Validatoren in Echtzeit zur wettbewerblichen Auswahl vor. Im formalen Sinn ist das kein MCP, da es weder protokollerzwungene Zensurresistenz noch ein Attestierungsquorum oder kryptografische Grenzen für den Ermessensspielraum des Leaders gibt. Validatoren mit Harmonic wählen jedoch bereits zwischen mehreren gleichzeitigen Blockvorschlägen. Genau diesen Kernmechanismus will MCP im Protokoll verankern. Gemeinsam mit BAM steht Harmonic für den Versuch des Ökosystems, Marktstrukturprobleme zu lösen, ohne auf die Durchsetzung durch das Protokoll zu warten. Diese Systeme außerhalb des Protokolls zeigen, dass die Nachfrage nach MCP-ähnlichen Eigenschaften real genug ist, dass Builder nicht auf Constellation warten.

Offene Fragen

Constellations Whitepaper ist eine Protokollspezifikation. Es beweist Korrektheitseigenschaften unter den genannten Annahmen und verschiebt alles andere zu Recht. Für einen v0.9-Vorschlag ist das angemessen. Was folgt, ist keine Liste von Constellations Fehlern, sondern eine Übersicht der Fragen, die das spätere SIMD und künftige Iterationen lösen müssen, um MCP effektiv auf Solana zu bringen. 

Diese Fragen sind nicht gleich schwierig. Einige betreffen die Spezifikation: Designentscheidungen, die Anza im normalen SIMD-Prozess lösen kann und sollte. Andere sind echte offene Probleme, die auch die breitere MCP-Forschung noch nicht gelöst hat. Wir müssen sie jedoch berücksichtigen, wenn wir als erste große Blockchain MCP implementieren wollen. Kein einzelnes SIMD kann diese Probleme lösen. Diese Unterscheidung ist wichtig. Wer beides vermischt, übertreibt entweder Constellations Lücken oder unterschätzt die verbleibende Arbeit.

Zu den unkomplizierten SIMD-Aufgaben gehören:

• Gebührenverteilung: Die Aufteilung der Prioritätsgebühren zwischen Proposern, Attestern und der breiteren Validator-Gruppe wird beschrieben, aber nicht vollständig ausgeführt. Laut Whitepaper fließen Prioritätsgebühren proportional zum Stake an das Ökosystem zurück. Der genaue Verteilungsmechanismus zwischen Proposern, Attestern und Validatoren ist jedoch nicht definiert.
• Vergütungsstruktur für Validatoren: Wie Proposer im Verhältnis zu bestehenden Validator-Vergütungen entlohnt werden und ob die Abschaffung der Gebühren für Vote-Transaktionen unter Alpenglow die Kalkulation kleinerer Validatoren verändert.
• Reihenfolge der Einführung: Constellation hängt von Alpenglow ab, das für Q3 2026 geplant ist. Das SIMD muss diese Abhängigkeit ausdrücklich festlegen und klären, was im Übergangsfenster von reinem Alpenglow zu Constellation+Alpenglow geschieht. Müssen zuvor bestimmte SIMDs im Mainnet eingeführt werden?
• Governance der Rollenparameter: Die Zahl der Proposer (p ≈ 16), die Zahl der Attester (q ≈ 256), die Zyklusdauer (△cycle = 50ms) und weitere Parameter aus Tabelle 1 des Constellation-Whitepapers sind lediglich Vorschläge. Das SIMD muss festlegen, wie diese Parameter bestimmt, verwaltet und im Laufe der Zeit möglicherweise geändert werden.

Die schwierigeren Fragen, etwa asynchrone Ausführung, Slashing und Datenschutz auf der Übermittlungsschicht, werden in den folgenden Unterabschnitten behandelt. An diesen Fragen arbeitet die MCP-Forschung aktiv. Wir müssen sie berücksichtigen, da Constellations Designentscheidungen den Weg zu bestimmten späteren Lösungen verkürzen oder verlängern können.

Asynchrone Ausführung

Bei synchroner Ausführung kennt ein Proposer den Inhalt einer Transaktion, wenn er sie im Klartext empfängt oder sie in einem naiven Übermittlungsmodell frühzeitig decodieren kann. Er kann dann ihr Ergebnis simulieren. Der Proposer kann die Transaktion gegen den aktuellen Zustand ausführen und genau berechnen, wie das Ergebnis aussehen wird. Dazu gehören Swap-Preise, Änderungen an Account-Guthaben und nachgelagerte Arbitragemöglichkeiten. Dadurch werden Sandwich-Angriffe mechanisch präzise. Angreifer können große Swaps sehen und berechnen, wie viel Frontrunning ihren Gewinn maximiert.

Asynchrone Ausführung beseitigt die zweite Hälfte dieses Vorteils, aber nur in Verbindung mit MCP. Legt der Konsens die Transaktionsreihenfolge vor der Ausführung fest, kann ein Proposer trotz sichtbarem Transaktionsinhalt die Ausführungsergebnisse nicht gegen einen bekannten endgültigen Zustand simulieren. Dieser Zustand existiert zum Zeitpunkt der Sortierung noch nicht. Der Informationsvorteil schrumpft effektiv von „Ich weiß, was diese Transaktion tut und in welcher Reihenfolge sie ausgeführt wird“ zu „Ich weiß, um welche Transaktion es sich handelt, aber nicht, was sie relativ zur endgültig sortierten Menge bewirkt“. Dieser Vorteil setzt voraus, dass der Proposer die endgültige Reihenfolge nicht kontrolliert. In einem Single-Leader-Modell bietet asynchrone Ausführung allein diesen Schutz nicht. Der Leader behält die vollständige Kontrolle über die Reihenfolge und kann eigene Transaktionen unabhängig vom Ausführungszeitpunkt vorteilhaft platzieren. Erst die Kombination aus eingeschränkter Reihenfolge und verzögerter Ausführung verkleinert die Angriffsfläche.

Asynchrone Ausführung schließt Ebene 2 nicht vollständig. Ein technisch versierter Proposer kann weiterhin kategorische Rückschlüsse ziehen. Er kann beispielsweise erkennen, dass eine Transaktion einen bestimmten Liquiditätspool berührt, und daraus die wahrscheinliche Richtung ableiten, ohne das genaue Ergebnis zu kennen. Dennoch erhöht das die Hürde für die mechanischsten und profitabelsten Formen der Ausnutzung deutlich. Es ist der klarste architektonische Weg, Ebene 2 zu verkleinern, ohne kryptografisches Hiding auf der Konsensschicht zu benötigen. Sei Giga hat genau diesen Ansatz gewählt und behandelt asynchrone Ausführung neben MCP als vorrangiges Architekturziel.

Daraus ergibt sich eine naheliegende Frage: Warum wurde asynchrone Ausführung nicht zuerst verfolgt? Sie verkleinert Ebene 2 und hätte theoretisch als begrenzte Änderung der Ausführungsschicht umgesetzt werden können, ohne die zusätzliche Protokollkomplexität von MCP einzuführen, also neue Node-Rollen, Anforderungen an die UTC-Uhrsynchronisierung, ein ungelöstes Slashing-Design und den doppelten Aufwand für Shredding. 

Das stärkste Argument für diese Reihenfolge lautet, dass asynchrone Ausführung und MCP unterschiedliche Probleme lösen. MCP schafft strukturelle Grenzen für die Reihenfolge, die asynchrone Ausführung allein nicht bieten kann. Ein Validator, der Ausführungsergebnisse nicht simulieren kann, aber weiterhin den Transaktionsinhalt sieht, kann die Reihenfolge innerhalb des vom Protokoll erlaubten Fensters beeinflussen. Für MCP an erster Stelle spricht, dass es Ebene 1 strukturell begrenzt. Ebene 1 ist die offensichtlichere und wirtschaftlich unmittelbarere Bedrohung. Asynchrone Ausführung nachträglich in Solanas bestehendes synchrones Ausführungsmodell einzubauen, ist wegen dessen Annahmen zur Komponierbarkeit und Program-Architektur schwieriger, als sie von Anfang an in eine neue Chain zu integrieren. Sei Giga konnte vom ersten Tag an für asynchrone Ausführung entworfen werden, Solana nicht. Diese praktische Asymmetrie könnte für die Entscheidung zugunsten von MCP ebenso wichtig sein wie das theoretische Prioritätsargument. Alpenglows Architektur macht MCP außerdem praktikabler, als es unter Tower BFT gewesen wäre. Das untersuchen wir im folgenden Unterabschnitt zur Protokollkomplexität.

Ob diese Reihenfolge richtig ist, bleibt eine berechtigte offene Frage. Constellation lässt Ebene 2 bestehen. Das ist angesichts der neuen Angriffsvektoren problematisch, die MCP auf Ebene 3 einführt. Dadurch können Angriffe auf Ebene 2 profitabler werden, weil sich beide Angriffsflächen ergänzen. Ein Proposer, der eine große DEX-Transaktion sieht, kann beispielsweise deren pshreds verzögern, um sie aus dem aktuellen Batchfenster zu drängen, und sie zugleich im selben Fenster mit einer eigenen Transaktion frontrunnen. Sichtbarkeit auf Ebene 2 und Timing-Spiele auf Ebene 3 sind eng verbundene Waffen innerhalb derselben Angriffsfläche. Mit Solanas Reife werden sie nur ausgefeilter.

Slashing

Kryptografische Durchsetzung funktioniert gut, wenn das Fehlverhalten eines Akteurs ein überprüfbares Artefakt erzeugt, etwa widersprüchliche Signaturen, fehlgeschlagene Gültigkeitsprüfungen oder nachweisbar fehlerhafte Commitments. Constellation löst die Zensurresistenz auf Ebene 1 so sauber, weil ein Leader durch den Ausschluss einer attestierten Transaktion einen ungültigen Block erzeugt. Diese Ungültigkeit lässt sich mathematisch nachweisen. Timing-Spiele und Latenzmanipulation erzeugen kein solches Artefakt. Das Problem ist, dass sich diese Art von Fehlverhalten bei einzelnen Handlungen nicht von ehrlicher Netzwerkverzögerung unterscheiden lässt. Das Fehlverhalten besteht in einer Abwesenheit, die kryptografisch nicht beweisbar ist. Der einzige verfügbare Hebel ist wirtschaftliche Abschreckung. Dafür braucht es Slashing. 

Die Herausforderung bei Slashing besteht darin, dass es traditionell ein beweisbares Vergehen voraussetzt. Constellations Mechanismen für Fault Witnesses decken den Fall ab, in dem ein Proposer zwei widersprüchliche pshreds signiert und dadurch identifiziert und ausgeschlossen werden kann. Strategische Latenzmanipulation erzeugt jedoch keinen Fault Witness. Keine Äquivokation, keine doppelte Signatur, kein Onchain-Fingerabdruck. Ein Proposer, der die Weiterleitung von pshreds konsequent und selektiv nur um wenige Millisekunden verzögert, hinterlässt nichts, das bestraft werden könnte. 

Wenn die pshreds eines Proposers über viele Zyklen hinweg konsequent in den letzten Millisekunden des Zyklusfensters bei den Attestern eintreffen und zufällig Transaktionen betreffen, die mit den eigenen Übermittlungen des Proposers konkurrieren, könnte ein gut spezifizierter Slashing-Mechanismus dieses Muster als Beleg für systematische Manipulation behandeln, ohne dass eine einzelne nachweislich böswillige Handlung vorliegt. Traditionelles Slashing kann dies nicht direkt lösen. In seiner üblichen Form verlangt Slashing einen eindeutigen, in sich geschlossenen Beweis. Für einen Proposer, der die Weiterleitung lediglich um einige Millisekunden verzögert hat, gibt es keinen solchen Beweis. Der Unterschied liegt im Muster.

Hier kann das traditionelle Finanzwesen dem dezentralen Finanzwesen Hinweise geben, wie Regulierungsbehörden mit latenzbasierter Manipulation umgehen. Die Durchsetzung gegen Spoofing nach dem Dodd-Frank Act beruht beispielsweise auf der Erkennung statistischer Muster, etwa dem Verhältnis von Stornierungen zu Ausführungen, der zeitlichen Verteilung von Stornierungen und Korrelationen mit Preiswirkungen. Sie versucht nicht, die Absicht hinter jeder einzelnen Order zu beweisen. Kein einzelner Fall ist nachweislich beabsichtigt. Das Muster ist es jedoch. Dieselbe Logik gilt hier, weil statistische Regelmäßigkeit objektiv ist, auch wenn einzelne Handlungen es nicht sind. Zudem besteht der wirtschaftliche Anreiz zur Manipulation in erlaubnisfreien Proposer-Gruppen ebenso wie bei Hochfrequenzhändlern im traditionellen Finanzwesen. Die Analogie scheitert bei der Durchsetzung. Dodd-Frank stützt sich auf eine Regulierungsbehörde mit Vorladungsbefugnis. In einem vertrauenslosen Kontext müssen Erkennungs- und Strafmechanismen dagegen im Protokoll selbst verankert sein.

Wir schlagen vor, Fisherman-Nodes als möglichen Mechanismus für diese Lücke anzupassen. Ursprünglich wurden sie in Vitaliks Forschung zur Datenverfügbarkeit vorgestellt. Fisherman-Nodes könnten als Beobachter fungieren, die Attestierungsdaten über viele Zyklen verfolgen und statistische Betrugsbeweise an ein verankertes Schlichtungsprotokoll übermitteln. Die einzelne verspätete Ankunft ist subjektiv. Das deterministisch über n Zyklen berechnete Muster ist jedoch objektiv. Derselbe Gedanke liegt Betrugsbeweisen in optimistischen Rollups zugrunde, hier jedoch auf Timing-Verhalten statt auf Zustandsübergänge angewendet. Ein verankertes Schlichtungsprotokoll für statistische Betrugsbeweise unterscheidet sich auch nicht grundsätzlich von den neuen Governance-Werkzeugen, die derzeit entwickelt werden. Sie sollen Stakern erlauben, die Stimmen ihrer Validatoren bei künftigen Governance-Vorschlägen zu überstimmen. Wenn Solana Infrastruktur für solche Staker-Overrides bereitstellt, könnten die technischen Grundlagen für ein Fisherman-basiertes Schlichtungssystem näher liegen als gedacht.

Die Untersuchung von Fisherman-Nodes ist glaubwürdiger als der Versuch, herkömmliches Slashing auf Handlungen ohne einzelnen Onchain-Fingerabdruck auszuweiten. Die aktuell entwickelte Governance-Infrastruktur des Protokolls könnte diesen Ansatz bereits unterstützen. Jede konkrete Spezifikation müsste dennoch drei Einschränkungen lösen. Erstens ist die statistische Analyse von Attestierungszeitpunkten über Tausende Zyklen nicht trivial und könnte die Hardwareanforderungen für Validatoren deutlich erhöhen. Das steigert die Betriebskosten und könnte die Betrugserkennung auf eine kleine Gruppe technisch versierter Akteure konzentrieren. Zweitens muss jede Schwellenwertspezifikation robust genug sein, um echte Netzwerkschwankungen von strategischer Manipulation zu unterscheiden, ohne durch zu geringe Vorsicht Fehlalarme auszulösen. Drittens schafft das Schlichtungsprotokoll selbst eine neue Angriffsfläche. Koordinierte Meldungen könnten das neue Fisherman-basierte System manipulieren. Das Design eines Schlichtungsprotokolls müsste dies berücksichtigen, etwa durch Anreizmechanismen, die den Betrieb von Fisherman-Nodes auch für kleinere Teilnehmer tragfähig machen, oder durch Aggregationsverfahren, die Rechenarbeit auf die Fisherman-Gruppe verteilen.

Unsere konkrete Forschungsfrage lautet: Lässt sich ein Modell für statistische Betrugsbeweise spezifizieren, das Schwellenwerte definiert, Netzwerkschwankungen berücksichtigt und die Skalierung von Strafen festlegt und zugleich robust genug ist, um systematische Latenzmanipulation abzuschrecken, vorsichtig genug, um ehrliche Schwankungen nicht zu bestrafen, und einfach genug, um Manipulationsversuchen technisch versierter Betreiber zu widerstehen? Dies ist eines der technisch anspruchsvollsten offenen Probleme in der MCP-Literatur. Die breitere Forschung hat es noch nicht gelöst.

Hiding

Slashing ist nicht die einzige Lösung für Spiele mit Timing- und Latenzmanipulation. Hiding löst sowohl Probleme der inhaltsbasierten Reihenfolge als auch der Timing- und Latenzmanipulation. Weder asynchrone Ausführung noch Slashing können beides allein lösen. Constellation implementiert partielles Hiding: Der Transaktionsinhalt ist nur für die empfangenden Proposer und nach Ablauf der Zyklusfrist für den Leader sichtbar. Die vollständige Hiding-Eigenschaft wird jedoch nicht erreicht. Die Angriffsfläche wächst mit der Zahl der Proposer, an die ein Nutzer übermittelt. Dieses partielle Hiding verkleinert die Angriffsfläche gegenüber vollständiger Sichtbarkeit, schließt sie aber nicht. Vollständiges Hiding, bei dem vor der Bestätigung keine Partei den Transaktionsinhalt sieht, bleibt für Constellation ein offenes Problem.

Das theoretische Ideal ist der von Garimidi et al. beschriebene Ansatz. Er verwendet Hiding Erasure-Correcting Code (HECC) als Grundbaustein. Anders als Constellations standardmäßiges Reed-Solomon liefert HECC eine informationstheoretische Garantie: Ein Angreifer, der weniger als den Schwellenwert an shreds sammelt, erfährt nichts über den Transaktionsinhalt. Constellation entschied sich dafür, die derzeit über Turbine auf Solana aktive Erasure-Codierung weiterzuverwenden.

Die relevanteste neue Entwicklung ist Jitos Block Assembly Marketplace (BAM). Er verwendet Trusted Execution Environments (TEEs), um einen verschlüsselten Mempool zu schaffen, in dem Transaktionen bis zur Ausführung privat bleiben. BAM zeigt, dass die konkrete Nachfrage nach Datenschutz für Inhalte auf Solana wächst. TEE-basiertes Hiding hat jedoch Einschränkungen. Es verlagert Vertrauensannahmen auf Hardwarehersteller, was für ein Protokoll mit dem Ziel eines vertrauenslosen Betriebs erheblich ist. Ein möglicher Weg mit Schwellenwertverschlüsselung als prinzipientreuer Alternative sollte gründlich untersucht werden.

BAM ist insofern wichtig, als es einen Versuch außerhalb des Protokolls darstellt, das von Constellation aufgeschobene Problem der Inhaltssichtbarkeit zu lösen. Jito ist betrieblich in der Lage, über BAM schon vor Constellations Einführung Transaktionsdatenschutz in großem Maßstab anzubieten. Das wirft die Frage auf, ob Hiding auf Protokollebene weiterhin dringend ist, wenn es bereits eine Lösung auf Anwendungsebene gibt. Die Antwort hängt vollständig von den Vertrauensannahmen ab und davon, ob Hardwarehersteller im Vergleich zu den theoretischen Protokollgarantien als „ausreichend“ vertrauenswürdig gelten. Dennoch darf dies nicht als dauerhafte Lösung betrachtet werden. Wahrscheinlich bietet BAM kurzfristig Datenschutz, während spätere Constellation-Versionen Schwellenwertverschlüsselung als langfristige Alternative untersuchen.

Für ein Protokoll, das die Infrastruktur der Internet-Kapitalmärkte werden will, ist partielles Hiding ein wichtiger Fortschritt, aber nicht das Endziel. Die verbleibende Lücke ist der Unterschied zwischen einer fairen Marktstruktur und einer, die lediglich weniger unfair ist als die heutige. 

Protokollkomplexität

Constellation ist das strukturell ambitionierteste Upgrade, das seit Solanas Start vorgeschlagen wurde. Es führt drei neue Node-Rollen, ein neues Timing-Modell auf Grundlage der UTC-Uhrsynchronisierung, neue Durchläufe zur Erasure-Codierung, neue Nachrichtentypen und neue Fehlermodi ein. All das baut auf Alpenglow auf, das im Mainnet noch nicht aktiv ist. Ob jetzt der richtige Zeitpunkt für diese Komplexität ist, ist eine ernsthafte Frage, die mehr als bloßen Optimismus verdient.

Solana hat sich in der Vergangenheit wegen der verschiedenen Ausfälle, die das Netzwerk 2021 und 2022 belasteten, einen berüchtigten Ruf erworben. Diese Ausfälle hatten eine Gemeinsamkeit: Sie entstanden durch die inhärente Schwierigkeit, Sonderfälle in einem neuartigen Hochdurchsatzprotokoll unter realer Last korrekt zu beurteilen. Die seitdem erreichten mehr als zwei Jahre Betriebszeit sind ein echter Meilenstein, geschmiedet in den schmerzhaften Feuern der Iteration. Diese Bilanz spricht für Solanas Reife. 

Heute muss jede Protokolländerung von Constellations Größenordnung gleichzeitig in Agave und Firedancer implementiert werden. Zwei unabhängige Entwicklungsteams müssen sich dafür über Protokollsemantik, Sonderfälle und Timing-Annahmen abstimmen, die für beide neu sind. Schon für Alpenglow allein ist das äußerst komplex. Constellation erhöht diese Komplexität weiter. Das ist kein Argument gegen die Umsetzung. Es ist ein Argument dafür, dass Constellations späteres SIMD einen klaren Plan für die Multi-Client-Implementierung enthalten muss.

Finanzinstitute beginnen, Onchain-Systeme zu nutzen. Die Folgen eines erheblichen Ausfalls wären heute sowohl für die Reputation als auch wirtschaftlich deutlich größer als 2021. Als Community müssen wir die von Constellation eingeführte Komplexität ehrlich benennen. Das spätere SIMD muss mit der Sorgfalt behandelt werden, die ein globales Finanzsystem verlangt. 

Natürlich stellt sich die Frage: Warum jetzt? Wollen wir das Risiko eines solchen Upgrades wirklich eingehen? Gibt es keine schrittweisen Upgrades, die diese Umstellung abfedern könnten? Die erwähnten Untersuchungen zu asynchroner Ausführung und Slashing legen beispielsweise nahe, dass eine schrittweise Alternative möglich ist. Constellations Roadmap könnte dem Ökosystem durch gestaffelte Einführungen verschiedener ergänzender Upgrades Vorteile bringen. Ob das als umsichtig oder als fortschrittsfeindlich gilt, ist ebenso eine Wertefrage wie eine technische Frage. Vernünftige Menschen können unterschiedlicher Meinung sein. Wir bauen ebenso ein Bedeutungssystem wie ein Finanzsystem.

In der Praxis geschieht das bereits. Anza hat bestätigt, dass 200ms-Slots und Leader-Fenster über zwei Slots vor Constellation eingeführt werden. Solana erhält damit erhebliche Leistungsverbesserungen, die einige der von der Community genannten Bedenken zur Sequenzlatenz lösen, die wir im nächsten Abschnitt behandeln. Dafür ist nicht die volle Komplexität von MCP nötig. Bringen 200ms-Slots Solanas Bestätigungspfad so nah an den erwarteten Overhead von Constellation, dass die Grenzkosten von MCP gering sind, wird die politische Argumentation deutlich einfacher. Gelten 200ms bei den etablierten Handelsteilnehmern jedoch als „gut genug“, sinkt die Dringlichkeit von Constellation. Vergleichende Latenzprognosen für 200ms-Slots gegenüber 200ms-Slots mit Constellation können der Community helfen, die zusätzlichen Kosten gegen die zusätzliche Garantie abzuwägen. Natürlich müssen wir auf Constellations späteres SIMD und die vorgeschlagene Implementierung warten.

Das stärkste Argument für die Umsetzung ist das von Alpenglow geschaffene Zeitfenster. Constellation übernimmt Alpenglows Sicherheitsmodell, verwendet Rotor als Schicht zur Datenverteilung und profitiert davon, dass die Komplexität von Tower BFT entfällt. Die Grenzkosten für MCP auf Alpenglow sind geringer als die Kosten eines Neustarts mit einem künftigen Konsensdesign. Warten ist nicht kostenlos. Konkurrenten untersuchen bereits, wie sie MCP Onchain bringen können. Zudem würde eine Verschiebung der Zensurresistenz in einen künftigen Upgrade-Zyklus zwangsläufig eigene Komplexität und politischen Gegenwind erzeugen.

Wenn nicht jetzt, wann dann?

Die Komplexität ist gerechtfertigt. Diese Rechtfertigung muss jedoch durch eine strenge Spezifikation, gestaffelte Einführungen und die empirische Validierung der Latenz- und Bandbreitenversprechen verdient werden, über die die Community derzeit nur auf theoretischer Grundlage debattiert. 

Passt Constellation zu IBRL?

Sequenzlatenz gegenüber Aufnahmelatenz

Die erste Reaktion der Solana-Community auf Constellation war gelinde gesagt polarisierend. Sie hat eine wichtige Debatte angestoßen, die eine präzise statt einer diplomatischen Antwort verdient. Die schärfste Formulierung kam aus Caveys Tweet: „MCP und IBRL sind grundsätzlich inkompatibel.“ Er argumentiert, MCP reduziere direkt und zweifelsfrei die Bandbreite und erhöhe die Latenz, um die Marktstruktur zu verbessern. Tolys Antwort war ebenso direkt: „Du liegst falsch. Ohne MCP lässt sich die Aufnahmelatenz nicht reduzieren.“

Beide haben technisch recht. Sie messen unterschiedliche Dinge.

MCP senkt die Aufnahmelatenz und erhöht die Sequenzlatenz. Diese Eigenschaften sind nicht identisch. Ihre Verwechslung verursacht den größten Teil der aktuellen Debatte.

Die Sequenzlatenz ist die Zeit von der Übermittlung einer Transaktion bis zu ihrer Ausführung. Unter MCP steigt sie zwangsläufig, weil die Attester-Runde, das 50ms-Zyklusfenster und die Batch-Zusammenstellung zusätzliche Zeit benötigen, die im aktuellen TPU-Übermittlungspfad zu einem kooperativen Leader nicht anfällt. Die Kritik, dass rationale Akteure durch das Senden an mehrere Proposer mehr Bandbreite verbrauchen, ist richtig. Auch das Coalesce-Fenster erhöht die Latenz. Das sind reale Kosten. Sie sollten gemessen und der Community als Kompromisse für die Beseitigung harter Zensur präsentiert werden.

Die Aufnahmelatenz ist das garantierte Zeitfenster, innerhalb dessen eine gültige, gebührenmäßig konkurrenzfähige Transaktion aufgenommen wird. Im heutigen Single-Leader-Modell ist diese Garantie praktisch unbegrenzt. Ein Leader kann eine bestimmte Transaktion nach Belieben verzögern oder ausschließen, ohne dass das Protokoll ihn daran hindert. Die von Nutzern bereits erlebte Latenz umfasst sämtliche Reibung durch Zurückhalten, Zeitplanung und Timing-Spiele sowie die selektive Reihenfolge der Leader. Der Einwand, dass reale Bestätigungszeiten die Latenz dieser Spiele einschließen und sich die Nutzererfahrung daher insgesamt verbessern könnte, weist unter dieser Betrachtung in die richtige Richtung. Das wird durch die derzeitigen Diskussionen der Community auf X gestützt. 

Die eigentliche Frage lautet, welche Latenz optimiert werden soll.

FIFO gegenüber FCFS gegenüber FBO

Bevor wir untersuchen, welche Latenz optimiert werden soll, lohnt sich ein Blick auf eine verwandte Debatte, die die Community gleichzeitig führt: Ist MCP mit FIFO kompatibel?

FIFO (First In, First Out) ist ein allgemeines Ordnungsprinzip, bei dem Transaktionen in der Reihenfolge ihres Eingangs verarbeitet werden. Umberto hat ausführlich dargelegt, dass die Antwort grundsätzlich differenziert ausfällt. MCP kann sogenanntes „probabilistisches FIFO“ ermöglichen, allerdings nur unter bestimmten Infrastrukturbedingungen. Im Wesentlichen erlebt ein Nutzer FIFO praktisch bei der Aufnahme, wenn er geografisch nah genug an ausreichend vielen Proposern ist, um Zensur zu vermeiden, und diese Proposer wiederum nah genug an den Attestierern sind, um schnell die Attestierungsschwelle von 40 % für eine garantierte Aufnahme zu erreichen. Seine Transaktion wird also aufgenommen, bevor ein Wettbewerber sie beobachten und darauf reagieren kann. Das Rennen endet bei der Aufnahme, nicht bei der Ausführung. Unter diesen Bedingungen nähert sich MCP FIFO als emergenter Eigenschaft an, nicht als Protokollregel.

Das Problem ist, dass die aktuelle Infrastruktur von Solana diese Bedingungen nicht erfüllt. Stake konzentriert sich auf wenige Regionen. Dadurch hängt die Quorumsbildung davon ab, dicht konzentrierte Stake-Cluster zu erreichen. Diese Konzentration öffnet ein Zeitfenster, in dem ein „geografisch bevorteilter“ Beobachter eine noch nicht abgeschlossene Transaktion frontrunnen kann. Ob die Bereitstellung von Constellation mit der geografischen Verteilung und Attestiererdichte einhergeht, die probabilistisches FIFO voraussetzt, ist genauso entscheidend wie das Protokolldesign selbst. Ein Protokoll, das Zensurresistenz garantiert, wegen einer dünn verteilten Infrastruktur aber latenzbasiertes Frontrunning ermöglicht, wird nicht die Marktgerechtigkeit liefern, die sein Whitepaper verspricht.

Eine damit zusammenhängende, aber eigenständige Frage lautet, ob Constellation FCFS hätte implementieren können, sich aber dagegen entschieden hat. Während FIFO eine emergente Eigenschaft der Infrastruktur ist, ist FCFS (First Come, First Served) eine konkrete Protokollregel, die sicherstellt, dass die zuerst eingegangene Transaktion deterministisch verarbeitet wird. Dabei ist zu beachten, dass Constellation durchaus deterministisch ordnet: Transaktionen werden innerhalb jedes Batches nach Priority Fee sortiert. Die Frage ist daher nicht, ob das Protokoll die Reihenfolge erzwingt, sondern ob die Eingangszeit diese Reihenfolge gegenüber Priority Fees bestimmen sollte.

Eine aktuelle Debatte hat einen grundlegenderen Einwand offengelegt als ursprünglich vorgebracht: FCFS könnte in einem vertrauenslosen Kontext überhaupt nicht durchsetzbar sein. Validatoren können die Eingangsreihenfolge von Transaktionen einfach falsch darstellen, ohne Onchain-Artefakte zu hinterlassen. Es handelt sich um dasselbe Problem fehlender Beweise, durch das Timing-Manipulation im herkömmlichen Sinne nicht mit Slashing bestraft werden kann. Möglicherweise sind kreativere Lösungen nötig, etwa der im Unterabschnitt zu Slashing entwickelte Ansatz zur Erkennung statistischer Muster. Eine Protokollregel, der ehrliche Validatoren folgen, während unehrliche sie unbemerkt ignorieren können, ist keine echte Garantie. Damit erscheint Constellations Verzicht auf FCFS nicht länger als erklärungsbedürftige Designpräferenz, sondern als Anerkennung, dass FCFS in einem permissionless Validator-Set unter den aktuellen Annahmen womöglich überhaupt noch nicht als harte Protokolleigenschaft auf Solana implementierbar ist. Wenn FCFS in einem permissionless Validator-Set unter den aktuellen Annahmen tatsächlich nicht durchsetzbar ist, muss das SIMD diese Einschränkung ausdrücklich benennen und die Sortierung nach Priority Fee als richtigen Designstandard begründen. Wenn die Community weiter über FCFS diskutiert, als wäre es eine praktikable Alternative, gegen deren Implementierung sich Constellation entschieden hat, statt es als möglicherweise nicht implementierbare Eigenschaft einzuordnen, wird das noch mehr Reibung in der Community erzeugen.

Die Sortierung nach Priority Fee innerhalb eines festen Zeitfensters ist kein neuartiger Kompromiss. Dieses Modell wird als Frequent Batch Auction (FBA) bezeichnet, ein Design der Marktmikrostruktur mit breiter akademischer Unterstützung. Budish, Cramton und Shim argumentieren beispielsweise in Das Wettrüsten im Hochfrequenzhandel: Frequent Batch Auctions als Antwort des Marktdesigns (2015), dass Batch-Auktionen in diskreten Zeitintervallen mit einheitlichen Clearingpreisen das von kontinuierlichen Märkten geschaffene Wettrüsten um Geschwindigkeit beenden. Dadurch wird latenzbasierter Wettbewerb durch preislichen Wettbewerb ersetzt. Constellation greift dieses Konzept auf und führt Fixed Batch Ordering (FBO) auf Grundlage von Priority Fees ein. Der 50-ms-Zyklus von Constellation setzt dieses Modell um: Innerhalb jedes Batches konkurrieren Transaktionen über Gebühren statt über ihre Eingangszeit, und alle Transaktionen im selben Batch werden bei der Sortierung gleich behandelt. Genau diese Anwendungsklasse wurde zuvor als auf Solana noch nicht in großem Maßstab vorhanden beschrieben. 

Bei den Debatten um FIFO, FCFS und FBO geht es weitgehend um dieselbe grundlegende Frage: Wer kontrolliert die Reihenfolge, sobald Zensurresistenz garantiert ist, und ist die von Constellation angestrebte Marktstruktur tatsächlich fair oder nur weniger unfair als der heutige Zustand? Constellation unterbindet die offensichtlichste Form der Manipulation. Was an ihre Stelle tritt, hängt von den Entscheidungen ab, die das Whitepaper dem SIMD überlässt.     

Worauf optimieren wir also?

Die Sequenzierungslatenz ist für bestehende Trading-Anwendungen am wichtigsten, also etwa für AMMs, Prop Desks und CLOBs. Diese Anwendungen basieren auf der Annahme, dass der schnellste und bei den Gebühren wettbewerbsfähigste Teilnehmer gewinnt. Ihre Infrastruktur wurde entsprechend aufgebaut. Trading sollte nur durch die Gesetze der Physik begrenzt sein und auf Solana ein unvergleichliches Nutzererlebnis bieten. Für einige dieser Nutzer ist Constellation bei der für sie wichtigsten Kennzahl ein Rückschritt. Es besteht die Sorge, dass Solana denselben fatalen Fehler machen könnte wie einst Ethereum: die Marktstruktur über die Performance zu stellen, wodurch die Ausführung die Chain verlassen könnte. Dieses berechtigte Risiko muss diskutiert werden.

Für die Finanzanwendungen, die Constellation ermöglichen soll, etwa Onchain-Auktionen, Orderbücher mit verlässlichen Aufnahmegarantien und zensurresistente DeFi-Protokolle, ist die Aufnahmelatenz die richtige Kennzahl. Eine Limit-Order, die gefrontrunnt oder gezielt verzögert werden kann, bietet schwächere Garantien als eine börsenähnliche Order – unabhängig davon, wie schnell die Bestätigung nominell erfolgt. Solana kann nun Trading-Anwendungen mit Batch-Auktionen und einheitlichen Clearingpreisen unterstützen, bei denen die Sequenzierung den Ausführungspreis nicht beeinflussen sollte. Diese Anwendungsklasse existiert heute auf Solana weitgehend nicht, gerade weil Aufnahmegarantien fehlen. Constellation legt womöglich zu viel Gewicht auf ein Design, das für Nutzer optimiert ist, die es auf Solana noch nicht in großem Maßstab gibt, und benachteiligt dafür bestehende Nutzer. Core-Contributors bringen dieses Argument bereits vor.   

Die Sorge um die Sequenzierungslatenz erhält zusätzlichen Kontext dadurch, dass Solana im Handel mit Perpetuals derzeit deutlich gegenüber Hyperliquid zurückfällt. Hyperliquid ist eine speziell entwickelte Perps-Börse mit zentralisiertem Sequencer, die keinen Anspruch auf Dezentralisierung erhebt, dafür aber die überzeugende Ausführung im Submillisekundenbereich bietet, die anspruchsvolle Trader und Anwendungen benötigen. Hyperliquid hat bewusst ein Produkt entwickelt, das professionelle Nutzer tatsächlich verwenden möchten, und dafür zentrale Grundsätze geopfert, die Krypto überhaupt erst zu „Krypto“ machen. Das implizite Risiko von Constellation besteht darin, dass zusätzlicher Kommunikationsaufwand und weitere Attestierungsrunden im Bestätigungspfad denselben Kompromiss darstellen wie bei Hyperliquid, allerdings in die falsche Richtung. Kritiker bewerten es negativ, einen potenziellen Performance-Vorteil aufzugeben, der Solana derzeit gegenüber zentralisierten Trading-Anwendungen wettbewerbsfähig macht, obwohl die Finanzanwendungen zur Rechtfertigung dieses Kompromisses noch fehlen. Das äußern sie sehr deutlich.

Diese Sorge sollte nicht vorschnell abgetan werden. Unsere frühere Frage, ob wir auf Sequenzierungs- oder Aufnahmelatenz optimieren sollten, lässt sich anders formulieren: Kann sich Solana diesen Kompromiss angesichts seiner aktuellen Konkurrenz leisten?

Dahinter liegt jedoch ein tieferes Problem. Der Vergleich mit Hyperliquid zeigt, dass sich die Bedeutung von IBRL im Laufe der Zeit möglicherweise verschoben hat. Die ursprüngliche Motivation von Toly und Raj für den Aufbau von Solana war Zensurresistenz: „Damit DeFi-Produkte Milliarden von Nutzern und Geräten erreichen können, müssen wir Zensurresistenz skalieren … Das ist das wichtigste Problem, das es zu lösen gilt, und unsere gesamte Motivation für den Aufbau von Solana.“ IBRL entstand erst deutlich später als technische Ausformulierung dieser Mission: so schnell zu werden, dass ein dezentrales Netzwerk zentralisierte Infrastruktur bei den entscheidenden Kennzahlen übertreffen kann. Seitdem hat IBRL eine eigene techno-optimistische Bedeutung angenommen und ist im kulturellen Zeitgeist von Solana allgegenwärtig geworden. Es ist zu gleichen Teilen technisches Diktat, kulturelles Erkennungszeichen und säkulares Gebet. Für viele ist es zum Ziel statt zum Mittel geworden. Die Minimierung der Sequenzierungslatenz gilt als Selbstzweck, losgelöst vom Ziel der Zensurresistenz, dem sie ursprünglich dienen sollte.

Wenn diese Verschiebung stattgefunden hat – und danach sieht es aus –, wird Constellation auf starken kulturellen Widerstand stoßen. Diese Dynamik ist nicht neu, wie die Ablehnung von SIMD-228 zeigt, einem umstrittenen Vorschlag zur Senkung der Inflation, der bei der Governance-Abstimmung scheiterte. Selbst Vorschläge mit breitem Nutzen können scheitern, wenn sie tief verankerten Überzeugungen der Community widersprechen. Bei Constellation ist die Lage differenzierter, da die Kosten bei Bandbreite und Latenz real sind, ihre Nettowirkung auf das Nutzererlebnis aber nicht quantifiziert wurde. Ohne Daten sind eindeutige Schlussfolgerungen in beide Richtungen verfrüht. Der Community fehlen empirische Daten dazu, wie der Bestätigungspfad unter realistischen Netzwerkbedingungen aussieht. Anza muss diese Daten für ein überzeugendes SIMD liefern. Alpenglow hatte dieses Problem nicht, weil es mit IBRL übereinstimmte: Die Zeit bis zur Finalität einer Transaktion wurde um den Faktor 100 verkürzt und der Konsens verschlankt. Constellations Nutzen ist intuitiv schwerer zu vermitteln, aber nicht weniger real, sofern zukünftige Benchmarks ihn bestätigen.

Offenbar wird die Community ein Upgrade für Zensurresistenz anhand einer Performance-Kennzahl beurteilen, für deren Optimierung es nie entwickelt wurde. Die produktivere Frage lautet, ob dieser Kompromiss seinen Preis wert ist. Es gibt messbare Kosten: etwas mehr Sequenzierungslatenz und Bandbreite im Austausch für eine harte, vom Protokoll erzwungene Garantie, dass kein Leader eine Transaktion gezielt ausschließen kann. Diese Garantie ist eine Voraussetzung für die Finanzanwendungen, die Solana derzeit gewinnen möchte.

Unserer Ansicht nach entspricht Constellation IBRL, wenn man IBRL so interpretiert, wie es ursprünglich gedacht war. Ob die Community zum selben Schluss kommt, hängt weniger von den technischen Vorzügen ab als davon, ob die empirischen Belege geliefert und die Designentscheidungen erklärt werden.  

Fazit

Constellation ist der erste formelle Vorschlag auf Protokollebene, MCP in großem Maßstab auf einer produktiven Blockchain einzuführen. Es löst harte Zensur strukturell: Gebührenkompetitive Transaktionen, die von einem ausreichenden Quorum attestiert wurden, können nicht aus einem gültigen Block ausgeschlossen werden. Diese kryptografische Garantie verändert, was sich auf Solana entwickeln lässt. 

Ebenso wichtig ist, was Constellation bewusst aufschiebt. Die inhaltsabhängige Sortierung wird durch das Übermittlungsmodell von Constellation teilweise entschärft, bei dem nur der empfangende Proposer den Inhalt einer Transaktion sieht. Die verbleibende Angriffsfläche wächst jedoch mit der Anzahl der Proposer, an die ein Nutzer seine Transaktion sendet. Timing- und Latenzmanipulation bleiben das größte ungelöste Problem und können im aktuellen Design nicht bestraft werden. Potenzielle Lösungswege – asynchrone Ausführung, Slashing und Verbergen – werden benannt, aber nicht spezifiziert. Jeder bringt eigene Komplexitäten mit sich. Das Whitepaper von Constellation benennt diese Grenzen offen. Das spätere SIMD sollte das ebenfalls tun.

Die schwierigste Frage, die Constellation aufwirft, ist, ob Solana sich die damit verbundenen Kompromisse leisten kann. Bei Sequenzierungslatenz und Bandbreite entstehen reale, messbare Kosten, die noch nicht quantifiziert wurden. Ebenso gibt es einen realen, bislang nicht gemessenen Nutzen durch Aufnahmegarantien, für die noch keine ausreichende Anwendungsbasis existiert, um sie im großen Maßstab zu rechtfertigen. Die Community soll in Infrastruktur für Finanzanwendungen investieren, die heute auf Solana weitgehend nicht existieren – möglicherweise zulasten bestehender Trading-Anwendungen. Ob das visionär oder verfrüht ist, hängt von Daten ab, über die die Community noch nicht verfügt.

Constellation wird letztlich mit zukünftigen empirischen Benchmarks unter realistischen Bedingungen stehen oder fallen. Die wichtigste Kennzahl, die Anza liefern kann, ist der Vergleich zwischen dem Bestätigungspfad bei 200-ms-Slots allein und bei 200-ms-Slots unter Constellation. Bis dahin diskutiert die Community über Kompromisse, die sie nicht quantifizieren kann.

Unserer Ansicht nach ist Constellation der richtige nächste Schritt auf der von Alpenglow eröffneten Protokoll-Roadmap. Es entspricht IBRL in der Interpretation, der Solana ursprünglich dienen sollte. Diese Einschätzung setzt jedoch voraus, dass das SIMD die Sorgfalt erreicht, die ein globales Finanzsystem verlangt – bei Spezifikation, stufenweiser Einführung, Tests und den empirischen Belegen, mit denen es die Community von seiner Einführung überzeugen will.

Weitere Ressourcen

• Budish, E., Cramton, P., und Shim, J. (2015). Das Wettrüsten im Hochfrequenzhandel: Frequent Batch Auctions als Antwort des Marktdesigns. https://doi.org/10.1093/qje/qjv027
• Daian, P., Goldfeder, S., Kell, T., et al. (2019). Flash Boys 2.0: Frontrunning, Neusortierung von Transaktionen und Konsensinstabilität an dezentralen Börsen. https://arxiv.org/abs/1904.05234
• Eskandari, S., Moosavi, S., und Clark, J. (2019). SoK: Transparente Unehrlichkeit: Front-Running-Angriffe auf Blockchain. https://arxiv.org/abs/1902.05164
• Garimidi, P., Neu, J., und Resnick, M. (2025). Multiple Concurrent Proposers: Warum und wie. https://arxiv.org/abs/2509.23984
• Kniep, Q., Resnick, M., Sliwinski, J., und Wattenhofer, R. (2026). Solana Constellation: Internet-Kapitalmärkte. https://drive.google.com/file/d/1MiGlZ_OORdnq6znkVQ5LrenBF3kyBIWf/view
• Landers, S. und Marsh, B. (2025). MEV in Blockchains mit Multiple Concurrent Proposers. https://arxiv.org/abs/2511.13080
• Yakovenko, T., und Gokal, R. Blockchain-Entwickler konzentrieren sich auf das falsche Problem. CoinDesk, 2020. https://www.coindesk.com/markets/2020/12/30/blockchain-developers-are-focused-on-the-wrong-problem