Constellation: Multi-Proposer-Vorschlag für Solanas Block-Konstruktion
Helius-Research hat mit Constellation einen Protokoll-Vorschlag für Multiple Concurrent Proposers (MCP) auf Solana veröffentlicht. Anza hat eine ergänzende Roadmap-Position publiziert. Übersicht der Mechanik und der offenen Probleme.
Worum es geht
Helius Research hat mit Constellation den ersten formalen Protokoll-Vorschlag für Multiple Concurrent Proposers (MCP) auf einer Production-Blockchain veröffentlicht. Anza hat parallel einen Roadmap-Post zur Adoption ähnlicher Mechaniken publiziert.
Was Constellation vorschlägt
Aus dem Helius-Research-Post:
- Statt eines einzelnen Block-Leaders, der allein über Transaktions-Reihenfolge entscheidet, arbeiten rund 16 Proposer parallel in einem 50-Millisekunden-Zyklus
- Proposer setzen Transaktionen zu Erasure-Code-Stücken (“pslices”) zusammen und verteilen sie an rund 256 Attester
- Attester unterschreiben kryptographisch, welche Transaktions-Sets sie gesehen haben
- Wenn genügend Attester ein pslice bezeugen, kann der Leader die Transaktionen nicht mehr selektiv ausschließen, ohne einen für das Netzwerk ungültigen Block zu produzieren
Die zentrale Eigenschaft: selektive Zensur-Resistenz. Entweder werden alle gebühren-konkurrenzfähigen Transaktionen eines Zyklus inkludiert, oder keine.
Offene Probleme (laut Helius selbst)
Helius nennt im Research-Post zwei nicht-gelöste Punkte:
- Content-visible Ordering bleibt ungelöst. Transaktionen sind für alle Proposer beim Empfang sichtbar — die Multi-Proposer-Architektur erweitert diese Angriffsfläche möglicherweise sogar
- Zeit-basierte Latenz-Spiele sind im aktuellen Design als “unpunishable” bezeichnet
Anzas paralleler Roadmap-Post
Anza hat am 25. März 2026 einen separaten Post veröffentlicht (Anza Blog: Solana Constellation — Fair Internet Capital Markets), der den Multi-Proposer-Vorschlag aus Anza-Perspektive adressiert. Anza-CEO Brennan Watt erwähnt MCP zusätzlich im Anza26-Roadmap-Post: “In 2026, we’ll ship an initial MCP version focused on enforcing transaction ordering within a batch in-protocol.”
Die genaue Beziehung zwischen Helius-Constellation-Spec und Anza-MCP-Implementation ist Gegenstand laufender Diskussion in der Solana-Foundation.
Wie Constellation mit Alpenglow zusammenpasst
Constellation und Alpenglow adressieren unterschiedliche Solana-Schichten:
- Alpenglow = Konsens-Layer (wie sich Validators auf finalisierte Blocks einigen)
- Constellation = Block-Construction-Layer (wer Blocks initial zusammenbaut)
Sie können technisch koexistieren. Alpenglow finalisiert Blocks unabhängig davon, ob sie von einem einzelnen Leader oder mehreren konkurrierenden Proposern stammen.
Status
- Constellation ist ein Research-Stage-Vorschlag
- Eine konkrete Mainnet-Implementations-Timeline ist weder von Helius noch von Anza öffentlich genannt
- Solana-Foundation und Validator-Communities diskutieren laufend Refinements
Was zu beobachten ist
- Wie sich die Helius-Spec und die Anza-Implementation-Roadmap aneinander angleichen
- Wie Validators die zusätzliche Rolle “Proposer/Attester” operativ einbauen werden
- Wie die ungelösten Probleme (Content-visible Ordering, Latency-Games) in nachfolgenden Spec-Versionen adressiert werden
- Wann ein formales SIMD aus Constellation hervorgeht
Quelle
- Helius Research — Constellation: A Proposal For MCP on Solana
- Anza Blog — Solana Constellation: Fair Internet Capital Markets, 25. März 2026
- Anza Blog — Anza26 Roadmap, 15. Januar 2026
- Solana Improvement Documents — github.com/solana-foundation/solana-improvement-documents