Block Assembly Marketplace (BAM)

Konkrete Erkenntnisse

• Heute bestimmen Solana-Leader während ihrer Slots allein die Transaktionsreihenfolge. Wie Blöcke erstellt werden, ist dabei nur begrenzt transparent. BAM führt eine überprüfbare, dezentrale Alternative ein, mit der sich die Sequenzierungslogik auditieren lässt.
• Das BAM-Netzwerk trennt Verantwortlichkeiten klar: BAM-Nodes übernehmen Beschaffung, Priorisierung und Filterung von Solana-Transaktionen, während BAM-Validatoren Ausführung, Konsens und Zustandsverwaltung übernehmen. Dieser Ansatz bringt Solana einer Architektur nach dem Prinzip der Proposer-Builder Separation (PBS) näher.
• Mit dem Plugin-Framework von BAM können Entwickler eigene Sortierlogik definieren und neue Scheduling-Primitive einführen. Das ermöglicht Application-Controlled Execution (ACE), bei der Apps ihre eigenen Regeln für das Transaktions-Scheduling durchsetzen können.
• Jito hat zugesagt, BAM letztlich als Open Source zu veröffentlichen und Transparenz zum Kern des Designs zu machen. Das ist eine erhebliche Verbesserung gegenüber der aktuellen Jito Block Engine, die Closed Source ist und von einer einzigen vertrauenswürdigen Partei betrieben wird.
• BAM-Nodes werden auf AMD-Prozessoren laufen, die Enhanced Secure Encrypted Virtualization with Secure Nested Paging (SEV-SNP) unterstützen. Dank Hardwarebeschleunigung verursacht SEV-SNP nur 2–5 % Overhead und ist damit schnell genug für die Echtzeitverarbeitung.
• Der erste implementierte Scheduler für BAM-Nodes führt in seinen Mempools regelmäßige Auktionen innerhalb eines Blocks durch. Dabei wird der Block in N Slots unterteilt und jeder Auktion werden gleich viele CUs zugewiesen.
• Application-Controlled Execution (ACE) könnte den Bedarf an Rollups oder Netzwerkerweiterungen zur Durchsetzung eigener Logik reduzieren und so mehr Aktivität im Solana-Mainnet halten. Zugleich erweitert es den Gestaltungsspielraum für neue Anwendungen, die programmierbaren Blockspace nutzen, erheblich.
• Jito plant, 100 % der Protokollgebühren aus der Block Engine und dem kommenden BAM-System an die Jito DAO Treasury weiterzuleiten. Derzeit erhebt Jito eine Gebühr von 6 % auf Tips, die zu gleichen Teilen zwischen Jito Labs und der DAO aufgeteilt wird. Im 2. Quartal 2025 verdiente die DAO über den Tip Router 22.391,31 SOL (~4 Millionen US-Dollar) aus diesen Gebühren.
• BAM orientiert sich an Flashbots’ BuilderNet und verfolgt einen ähnlichen Ansatz für die Blockerstellung in Trusted Execution Environments. Im Ethereum-Mainnet werden bereits etwa 40 % der Blöcke in TEEs erstellt.

Einführung

Jitos Block Assembly Marketplace (BAM) ist die bisher ambitionierteste Neugestaltung des Blockerstellungsprozesses auf Solana. BAM wurde über acht Monate entwickelt und entstand aus dem Wunsch nach mehr Datenschutz, Transparenz und deterministischer Ausführung innerhalb eines Slots auf Solana, um die nächste Generation fortschrittlicher Anwendungen zu ermöglichen. Das Ergebnis ist eine neu konzipierte Transaktionspipeline. Sie ersetzt das heutige undurchsichtige, von Validatoren gesteuerte Sortiermodell durch ein privates, programmierbares und nachweislich faires System zur Sequenzierung von Transaktionen.

BAM führt einen verschlüsselten Mempool ein, der innerhalb von Trusted Execution Environments (TEEs) läuft. Dort bleiben alle Transaktionen bis zur Ausführung vertraulich. Diese datenschutzfreundliche Architektur soll viele der ausbeuterischsten Formen von MEV deutlich reduzieren oder sogar vollständig beseitigen. Nutzer erhalten dadurch stärkere Ausführungsgarantien und bessere Preise. Validatoren können eine hochwertigere Ausführung anbieten, während Entwickler und Searcher direkt auf einer neuen programmierbaren Blockspace-Ebene aufbauen können.

BAM führt über ein Plugin-System Logik für Application-Controlled Execution (ACE) ein. Das ermöglicht Anwendungsfälle wie Maker-Priority-Matching für Perpetuals, Just-in-Time-Oracle-Updates, die Durchsetzung von Time-in-Force-Orders und andere Formen von individuellem Routing und individueller Ausführung. Durch die granulare Kontrolle über die Transaktionsreihenfolge können Entwickler auf Solana anspruchsvollere und zuverlässigere Finanzprimitive entwickeln, darunter Central Limit Order Books, Dark Pools und Aggregator-Ebenen.

Damit adressiert BAM direkt viele langjährige Kritikpunkte am Blockproduktionsmodell von Solana: undurchsichtiges Validatorverhalten, schwankende Ausführungsqualität und die Verbreitung von Graumärkten durch private Mempools und außerbörsliche Absprachen. Heute kontrollieren Solana-Leader während ihrer Slots einseitig die Transaktionsreihenfolge. Wie die finalen Blöcke zusammengesetzt werden, ist kaum einsehbar. BAM ersetzt dies durch eine überprüfbare, dezentrale Alternative, die sich dennoch nahtlos in die leistungsstarke Runtime von Solana integriert.

BAM baut auf bewährten Beispielen aus der Praxis auf und orientiert sich an Flashbots’ BuilderNet. Dabei kommt ein ähnlicher Ansatz zur Blockerstellung in Trusted Execution Environments zum Einsatz. Im Ethereum-Mainnet werden bereits etwa 40 % der Blöcke in TEEs erstellt, bei Unichain (Uniswaps eigener L2) sind es sogar 100 %. BAM überträgt dieses Modell auf Solana und bietet zusätzlich native Unterstützung für Programmierbarkeit auf Anwendungsebene, Ausführung mit niedriger Latenz und eine tiefe Integration mit den Jito-Validator-Clients. Jito-Agave und Jito-Firedancer sichern heute zusammen mehr als 89 % des gesamten Stakes.

Entscheidend ist, dass Jito zugesagt hat, BAM letztlich als Open Source zu veröffentlichen und Transparenz zum Kern des Designs zu machen. Das ist eine erhebliche Verbesserung gegenüber der aktuellen Jito Block Engine, die Closed Source ist und von einer einzigen vertrauenswürdigen Partei betrieben wird. BAM erzeugt Onchain-Attestierungen – kryptografisch signierte Nachweise, die exakt bestätigen, welcher Code ausgeführt und wie Transaktionen sortiert wurden. So kann jeder Beobachter die faire Ausführung überprüfen.

Allgemeiner Überblick über BAM

Im Kern ist BAM ein Netzwerk zur Sequenzierung von Transaktionen. BAM-Nodes übernehmen Beschaffung, Priorisierung und Filterung von Solana-Transaktionen, während sich BAM-Validatoren auf Ausführung, Konsens und Zustandsverwaltung konzentrieren. Diese Aufgabentrennung belässt die für die Verfügbarkeit des Netzwerks entscheidenden Kernverantwortlichkeiten beim Validator. Gleichzeitig ermöglicht sie mehr Flexibilität und Experimente mit der Sequenzierungslogik in BAM-Nodes.

Der BAM-Node selbst besteht aus einer Transaction Processing Unit (TPU) und einem Transaktions-Scheduler, die innerhalb einer TEE laufen. Außerdem betreibt er einen gRPC-Server für die Kommunikation mit verbundenen Validatoren. Der modifizierte Jito-Validator-Client enthält einen First-in-first-out-Executor (FIFO), der durch Account-basiertes Locking für Nebenläufigkeit und Parallelität optimiert ist.

Jeder BAM-Node kann mehrere Validatoren unterstützen, aber jeder Validator verbindet sich jeweils nur mit einem BAM-Node. Derzeit betreibt Jito sieben Block Engines. Mit BAM soll das Netzwerk deutlich skalieren. Angestrebt sind 50 bis über 100 BAM-Nodes, verteilt über alle wichtigen geografischen Regionen, um Dezentralisierung und Redundanz zu erhöhen. Die Kommunikation zwischen dem BAM-Node und dem Validator erfolgt über einen bidirektionalen gRPC-Stream. Die Ausführungsergebnisse werden vom Validator an den BAM-Node zurückgestreamt und ermöglichen Echtzeit-Feedback.

Alle Transaktionen in BAM-Nodes bleiben innerhalb von Trusted Execution Environments (TEEs) bis zum Zeitpunkt der Ausführung verschlüsselt. So bleibt der Transaktionsfluss bis zur Ausführung privat.

Um eine faire Ausführung zu garantieren, wird die Reihenfolge der Transaktionen mithilfe von Attestierungen überprüfbar aufgezeichnet. Dabei handelt es sich um kryptografische Nachweise, die von BAM-Nodes signiert und mit Zeitstempeln versehen werden. Sie bestätigen, dass bestimmte Ereignisse oder Bedingungen beobachtet wurden. Das Ergebnis ist ein unveränderlicher Audit-Trail, mit dem Beobachter nachweisen können, dass Transaktionen in der richtigen Reihenfolge ausgeführt wurden.

Der Audit-Trail enthält die an den Validator weitergeleiteten Transaktionen und deren Sequenzierung. Beispielsweise wurden die Transaktionen A, B und C in diesem Slot an den Helius-Validator gesendet. Das System bietet Tools zur Echtzeitüberwachung und Analysen, mit denen Nutzer ihre Transaktionen von der Übermittlung bis zur Ausführung verfolgen können. Nutzer und Anwendungen können überprüfen, ob der BAM-Validator die vorgegebene Reihenfolge eingehalten hat, und genau feststellen, welcher Code im BAM-Node ausgeführt wurde.

BAM-Nodes sind im Netzwerk transparent sichtbar, ähnlich wie bestehende Jito-Relayer. Wenn sich ein Validator mit BAM verbindet, kündigt er die BAM-Instanz über seine TPU- und TPU-Forward-Ports an. Diese dienen als Eingangspunkte für den Empfang von Transaktionen.

Nutzer können Transaktionen weiterhin über ihre üblichen RPC-Clients senden. Für zusätzliche Sicherheit können sie Transaktionen jedoch auch direkt an BAM-Instanzen senden. Dadurch können böswillige Validatoren die Transaktionspakete weder abfangen noch einsehen.

Wenn eine Transaktion bei BAM eingeht, durchläuft sie einen standardmäßigen Bereinigungsprozess. Dazu gehören Deduplizierung, Signaturprüfung sowie Prüfungen auf ein gültiges Format, einen gültigen Blockhash, Fee Payer, Nonce und gültige Address Lookup Tables.

Nach der Validierung gelangen Transaktionen in den Mempool von BAM und nehmen dort an regelmäßig stattfindenden Auktionen teil. Nach Abschluss einer Auktion werden die Transaktionen an Validatoren gesendet. Die vollständige Transaktionssequenz wird von der BAM-Software signiert und in einer Datenbank gespeichert. Anschließend streamen die Validatoren die Ausführungsergebnisse über eine API zurück, die sich an der vom modularen Scheduler von Anza vorgeschlagenen API orientiert.

Mit einer sicheren Scheduling-Umgebung und einem lokalen Gebührenmarkt arbeiten Validatoren nun unter einem deutlich strengeren Opt-in-Vertrag. Sie erhalten eine vordefinierte Transaktionssequenz, die exakt wie vorgegeben eingeplant werden muss. Dadurch entfallen Möglichkeiten, Transaktionen für böswillige Zwecke einzufügen oder neu anzuordnen.

Es werden mehrere Durchsetzungsmechanismen geprüft, um auf Fehlverhalten von Validatoren wie Sandwichen anhand von Belegen aus dem Audit-Trail zu reagieren. Die Details stehen noch nicht fest. Mögliche Maßnahmen sind:

• Ausschluss des betreffenden Validators aus dem BAM-Netzwerk.
• Verpflichtung der Validatoren, Sicherheiten in Form von Bonds zu hinterlegen, die bei Fehlverhalten gekürzt werden können. Dies könnte jedoch die Einstiegshürden für neue Validatoren erhöhen.
• Einsatz von Blacklists oder Greylists, um die Teilnahme von Regelverletzern teilweise einzuschränken oder zu begrenzen.

Gebühren

Jito Labs und die Jito Foundation erarbeiten gemeinsam einen Jito Improvement Proposal (JIP). Dieser soll 100 % der Protokollgebühren aus der Block Engine und dem kommenden BAM-System an die Jito DAO Treasury weiterleiten. Der Vorschlag soll in den kommenden Wochen offiziell eingereicht werden. Er stellt eine bedeutende Veränderung des Wirtschaftsmodells von Jito dar und muss von der DAO genehmigt werden. Bei Annahme stärkt er die zentrale Rolle der DAO und der JTO-Token-Inhaber im Jito-Ökosystem.

Derzeit erhebt das Jito-Protokoll eine Gebühr von 6 % auf Tips, die zu gleichen Teilen zwischen Jito Labs und der DAO aufgeteilt wird. Allein im 2. Quartal 2025 verdiente die DAO 22.391,31 SOL (~4 Millionen US-Dollar) aus diesen Gebühren über den Tip Router. Die andere wichtige Einnahmequelle der DAO sind jitoSOL-Gebühren, die sich im selben Zeitraum auf 13.223,73 SOL (~2,38 Millionen US-Dollar) beliefen.

Trusted Execution Environments (TEEs)

Eine Trusted Execution Environment (TEE) ist eine hardwaregestützte Architektur, die Vertraulichkeit und Integrität von Berechnungen und Speicher gewährleisten soll. TEEs werden auch als Enklaven bezeichnet und isolieren die Codeausführung vom Betriebssystem, Kernel und Hypervisor des Hostsystems, typischerweise durch Trennung auf Hardwareebene. Diese Isolation reduziert die Angriffsfläche erheblich. Dadurch ist es äußerst schwierig, wenn auch nicht unmöglich, Vorgänge in der Enklave zu beobachten oder zu manipulieren.

TEEs werden seit den 2000er-Jahren in Bereichen wie Digital Rights Management, Content-Schutz und sicheren Zahlungssystemen eingesetzt. Heute kommen sie in vielen Endgeräten und Cloud-Diensten zum Einsatz, um sensible Daten und Code sicher zu verarbeiten. Auf Smartphones und Laptops schützen Apples Secure Enclave und Androids TrustZone biometrische Daten, Zahlungsdaten und Verschlüsselungsschlüssel. Spielekonsolen wie PlayStation und Xbox verwenden AMD- oder Pluton-basierte Prozessoren, um Manipulation und Piraterie zu verhindern. In der Cloud nutzen Anbieter wie Azure und Google Cloud AMD SEV-SNP, Intel TDX oder AWS Nitro Enclaves, um Workloads zu isolieren und Confidential Computing zu ermöglichen. Krypto-Wallets wie Ledger und Trezor verwenden Secure Elements zum Schutz privater Schlüssel, während das neue Solana-Seeker-Smartphone für denselben Zweck auf TEEs setzt.

TEEs sind der hardwarebasierte Standardansatz zur Verarbeitung privater Daten und eine praktische Alternative zu rein kryptografischen Methoden wie Fully Homomorphic Encryption (FHE) und Secure Multiparty Computation (MPC). FHE und MPC bieten zwar starke theoretische Garantien, sind in der Praxis aufgrund ihrer hohen Komplexität und Performance-Kosten jedoch oft unpraktisch.

BAM stützt sich auf zwei Kerneigenschaften von TEEs:

Vertraulichkeit: Code und Daten innerhalb der TEE sind verschlüsselt und vom restlichen System isoliert. Weder das Betriebssystem noch der Hypervisor oder externe Software können auf die Vorgänge in der Enklave zugreifen oder sie einsehen.

Attestierbarkeit: TEEs unterstützen Attestierungen. Dieser Mechanismus erzeugt kryptografische Nachweise über die Herkunft und den aktuellen Zustand der Enklave. So können Dritte überprüfen, ob ein Ergebnis von einer echten TEE mit vertrauenswürdigem Code erzeugt wurde und nicht von einer kompromittierten oder emulierten Umgebung.

TEE-Implementierung in BAM

BAM wird auf AMD-Prozessoren laufen, die Enhanced Secure Encrypted Virtualization with Secure Nested Paging (SEV-SNP) unterstützen. Anders als kleinere, Enklaven-basierte Ansätze schützt SEV-SNP die gesamte BAM-Anwendung bei minimalen Performance-Kosten. Damit eignet es sich gut für Transaktionssysteme mit hohem Durchsatz und niedriger Latenz.

Dank Hardwarebeschleunigung verursacht SEV-SNP nur 2–5 % Overhead und ist damit schnell genug für die Echtzeitverarbeitung. Es unterstützt komplexe, zustandsbehaftete Netzwerkanwendungen und nicht nur isolierte Berechnungen. Die Technologie ist praxiserprobt. Sie wird von großen Cloud-Anbietern wie Google Cloud, Azure und AWS eingesetzt und stützt sich auf jahrelange Sicherheitsforschung und Betriebserfahrung.

Das in BAM verwendete SEV-SNP bietet mehrere wichtige Sicherheitsgarantien. Jede TEE-Instanz läuft in einer eigenen hardwareisolierten virtuellen Maschine. Der Speicher wird zur Laufzeit verschlüsselt, um eine starke Isolation auf VM-Ebene sicherzustellen. BAM nutzt hardwarebasierte Attestierung. Dadurch kann jede TEE kryptografisch nachweisen, dass sie echten, unveränderten Code ausführt. Diese Attestierungskette ist in den Hardware-Root-Schlüsseln von AMD verankert, die bei der Herstellung physisch in die CPU eingebettet werden. Zusätzlich werden TLS-Schlüssel mit dem internen Hardware-Zufallszahlengenerator des Prozessors erzeugt. So sind sie niemals in unverschlüsseltem Speicher verfügbar.

Wenn sich ein Client mit BAM verbindet, erhält er ein TLS-Zertifikat. Es enthält das standardmäßige Verbindungszertifikat, einen AMD-SEV-SNP-Attestierungsbericht und den kryptografischen Nachweis, dass der private TLS-Schlüssel innerhalb der attestierten TEE erzeugt wurde. Diese Zertifikatskette ist kryptografisch an AMDs hardwarebasierten Vertrauensanker gebunden. Ohne Zugriff auf die privaten Root-Schlüssel von AMD kann sie nicht gefälscht werden. Daher muss über den Chipherstellungsprozess von AMD hinaus keinem Vermittler vertraut werden.

Plugins

Heute können Anwendungen auf Solana die Transaktionsreihenfolge nur über Prioritätsgebühren oder gebündelte Transaktionen mit zugehörigen Tips beeinflussen. Da in Clients wie Agave und Firedancer mehrere Sequenzer zum Einsatz kommen, gibt es keine Garantie dafür, welche Sortierlogik angewendet wird. Anwendungen haben daher nur begrenzte Kontrolle über die Reihenfolge ihrer Transaktionen.

Plugins lösen dieses Problem. 

Mit dem Plugin-Framework von BAM können Entwickler maßgeschneiderte Sortierlogik implementieren und neue Scheduling-Primitive einführen. Sie ermöglichen Application-Controlled Execution (ACE), sodass Apps eigene Richtlinien für das Transaktions-Scheduling definieren können. ACE bietet viele potenzielle Anwendungen. Der bekannteste und meistdiskutierte Anwendungsfall ist jedoch die Priorisierung von Order-Book-Stornierungen. Dieser Mechanismus reduziert adverse Selektion und ermöglicht engere Spreads.

Stornierungen von Order-Book-Makern priorisieren

Heute sind Onchain-Order-Book-Market-Maker auf Solana benachteiligt. Market-Maker steuern ihr Risiko, indem sie veraltete Quotes kontinuierlich aktualisieren oder stornieren, wenn sich der faire Preis ändert. Bewegt sich der Marktpreis, müssen sie bestehende Orders stornieren, bevor informierte Taker die Gelegenheit ausnutzen können.  

Ohne granulare Kontrolle über die Transaktionsreihenfolge sind ihre Quotes anfällig für toxischen Flow, der veraltete Preise ausnutzt. Market-Maker können selbst dann verlieren, wenn sie schnell handeln, da die Jito-Auktion Gebote gegenüber Absichten priorisiert. Im Wesentlichen wird die Partei zuerst eingeordnet, die mehr zahlt.

Diese Dynamik zwingt Market-Maker dazu, ihre Spreads zur Risikosteuerung auszuweiten. Das reduziert die allgemeine Liquidität und führt zu schlechteren Preisen für Nutzer. Diese toxischen Trades, bei denen der Taker von veralteten Preisen profitiert und die Gegenpartei den Trade fast unmittelbar nach dem Abschluss bereut, verbessern die Nutzererfahrung kaum. Für Market-Maker und Liquiditätsanbieter erhöhen sie jedoch die Reibung erheblich.

Mit BAM-Plugins lassen sich Richtlinien nach dem Prinzip „Stornierung vor Ausführung“ auf Anwendungsebene durchsetzen. Programme erhalten granulare Kontrolle über die Transaktionsreihenfolge. Dadurch können Anwendungen Stornierungen von Makern vor Trades von Takern verarbeiten. Diese einfache Richtlinienänderung hat weitreichende Auswirkungen:

• Reduziert adverse Selektion: Maker werden bei Marktbewegungen nicht mehr routinemäßig zu nachteiligen Preisen ausgeführt.
• Filtert toxischen Flow: Das Gesamtvolumen kann durch weniger toxische Trades sinken, doch die Qualität des Flows und der Ausführung steigt.
• Ermöglicht engere Spreads: Durch das geringere Risiko können Maker aggressivere Quotes stellen.
• Verbessert die Liquidität: Professionelle Maker und Privatanleger stellen mit größerem Vertrauen Quotes bereit. Das führt zu höherer Liquidität.

Just-in-Time-Oracle-Updates

Ein weiteres Beispiel für ein anwendungsspezifisches Plugin ist Pyths geplante Implementierung von Just-in-Time-Oracle-Updates. Als führender Oracle-Anbieter auf Solana unterhält Pyth mehr als 1.700 einzelne Preis-Feeds. Sie alle in jedem Block zu aktualisieren, wäre unverhältnismäßig teuer und würde Blockspace ineffizient nutzen.

Mit BAM kann Pyth bestimmte Preis-Feeds genau dann aktualisieren, wenn sie benötigt werden. Dazu wird das Oracle-Update innerhalb desselben Blocks direkt vor der Transaktion eines Nutzers eingefügt. Dies reduziert die Risiken veralteter Oracle-Daten, etwa ineffiziente Liquidationen und Oracle-Manipulation. DeFi-Anwendungen können dadurch zuverlässiger und wettbewerbsfähiger arbeiten.

Weitere Plugins

Letztlich soll BAM eine permissionless Plattform werden, auf der Anwendungsentwickler Plugins erstellen, testen und bereitstellen können, um die Sequenzierung ihrer Transaktionen zu steuern. Viele weitere Plugins dürften folgen. BAM-Nodes sollen schließlich Hunderte anpassbare Erweiterungen unterstützen. Die meisten Anwendungen werden weiterhin den Standard-Scheduler verwenden. Anwendungen, die eigene Sequenzierungslogik benötigen, sind jedoch selbst für die Entwicklung und Wartung ihrer Plugins verantwortlich. 

Darüber hinaus können Anwendungen Plugin-Funktionen monetarisieren, indem sie Gebühren erheben. Ein Teil der Einnahmen könnte dabei an Governance-Token-Inhaber oder Validatoren ausgeschüttet werden.

Mögliche universelle Plugins

Plugins sind nicht auf eine einzelne Anwendung beschränkt. Jito hat bereits mehrere Beispiele für universelle, anwendungsübergreifende Plugins vorgeschlagen, die für BAM entwickelt werden könnten:

Blockspace-Futures: Nutzer und Anwendungen können sich das Recht auf die zukünftige Nutzung von Blockspace sichern oder damit handeln. Das bietet vorhersehbaren Zugriff und planbare Preise, selbst bei hoher Netzwerkauslastung.

Time in Force (TIF): bezeichnet die Dauer, für die eine Order aktiv bleibt, bevor sie automatisch storniert wird, wenn sie nicht vollständig ausgeführt wurde. Beispielsweise könnte eine Order-Book-Transaktion nur 20 Millisekunden lang gültig sein. Eine grobe Version davon ist heute auf Solana möglich, indem absichtlich ältere Blockhashes verwendet werden. So bleibt eine Transaktion nur für den oder die neuesten Blöcke gültig.

Vorab-Bestätigungen: Nutzer können benachrichtigt werden, wenn ihre Transaktion vor der Ausführung und Weitergabe an das Netzwerk an einen Validator weitergeleitet wird. So lassen sich Transaktionen früher mit einem gewissen Maß an Sicherheit bestätigen.

Gebührenfreie Transaktionen: Nutzer können Transaktionskosten statt mit SOL mit einem SPL-Token wie Stablecoins bezahlen. Dadurch entfallen Anforderungen an native Token und Gebühren lassen sich flexibel begleichen.

Aggregator mit niedriger Latenz und Request for Quotation (RFQ): Nutzer senden ihre Handelsabsichten direkt an BAM, wo ein lokal ausgeführter Aggregator die optimale Route ermittelt.

Transaktionen stornieren und ersetzen: Nutzer können Transaktionen mit speziellen Markierungen senden, die es ihnen ermöglichen, zuvor gesendete Transaktionen zu stornieren, zu verwerfen oder zu ersetzen.

Einführung

Während der Einführungsphase betreibt Jito Labs die ersten BAM-Nodes, um Stabilität, Performance und Sicherheit zu gewährleisten. Eine zugelassene Gruppe früher Validatorpartner, darunter Helius, SOL Strategies, Triton One und Figment, wird den BAM-Client ausführen. Kurz nach dem Start wird sie einen hohen einstelligen Prozentsatz des gesamten Netzwerk-Stakes absichern. 

Parallel dazu beginnt eine erste Gruppe von Solana-Anwendungen, darunter Drift, Pyth und DFlow, mit dem Entwurf und Test der ersten Plugin-Generation. Bis zum Ende der Einführungsphase soll BAM seine Kernfunktionen validiert und die Grundlage für eine breitere Beteiligung von Node-Betreibern und Validatoren geschaffen haben. 

Validatoren, Anwendungsentwickler oder Searcher, die an BAM teilnehmen möchten, können dieses Formular ausfüllen.

Ein Ecosystem Advisory Committee aus führenden Stakeholdern der Solana-Validator- und Entwickler-Community, einschließlich der Solana Foundation, wird Jito Labs beraten. Dieses Gremium soll die Erweiterung von BAM begleiten, die Dezentralisierung fördern und von der Community getriebene Innovation unterstützen.

Derzeit bleibt die BAM-Codebasis Closed Source. Sie soll jedoch in naher Zukunft geöffnet werden, damit Drittanbieter Plugins entwickeln können. Nach der Veröffentlichung als Open Source wird BAM Beiträge der Community in mehreren wichtigen Bereichen begrüßen:

• Plugin-Entwicklung: Entwickle eigene Plugins, um die Funktionen von BAM zu erweitern.
• Scheduling-Algorithmen: Entwirf neue Strategien zur Sortierung von Transaktionen für spezifische Anwendungsfälle und bringe sie ein.
• Integrationsbibliotheken: Entwickle SDKs in mehreren Programmiersprachen, um die Integration von BAM zu vereinfachen.
• Analysetools: Erstelle Dashboards und Überwachungssysteme, die die Attestierungsdaten von BAM nutzen.
• Forschungsbeiträge: Schlage neue Ansätze zur Reduzierung von MEV und zur Systemoptimierung vor und implementiere sie.

Auswirkungen

BAM markiert einen Wendepunkt für Solana. Es könnte eine Innovationswelle auslösen, indem es Bedenken rund um MEV-Ausbeutung und effizientes Packen von Blöcken ausräumt. TEE-gesicherte Sequenzierung und das Plugin-Framework von BAM könnten den Anreiz für Anwendungsteams verringern, Netzwerkerweiterungen, Rollups oder zugangsbeschränkte Solana-Umgebungen zu entwickeln, um eigene Logik oder spezifischen Blockspace durchzusetzen. So bliebe mehr Aktivität im Solana-Mainnet. Zusammen mit höheren Compute-Limits pro Block und der Nachfrage nach effizienteren Token-Programmen und Frameworks, die weniger CUs verbrauchen – etwa durch die steigende Beliebtheit von Pinocchio und p-token – entsteht außerdem mehr Bandbreite im Mainnet. Das verringert den Anreiz für Entwickler, eigene Lösungen zu bauen, zusätzlich.

Die Datenschutzfunktionen von BAM dürften auch die Verbreitung von Sandwich-Angriffen deutlich reduzieren. Transaktionen bleiben bis zur Ausführung verborgen, wodurch Bots Nutzer kaum noch frontrunnen können. Das dürfte DEXs effizienter machen und Nutzern wettbewerbsfähigere Preise bieten. BAM wird MEV jedoch wahrscheinlich nicht vollständig beseitigen. MEV ist von Natur aus ein Katz-und-Maus-Spiel, und Sandwicher werden sich anpassen – möglicherweise durch subtile Plugin-Exploits oder die Manipulation externer Oracles, also solcher ohne eigenes Plugin, da diese nicht Teil der verschlüsselten Pipeline sind. 

Die Reduzierung von MEV durch BAM könnte sich negativ auf den Umsatz von Jito auswirken. Das erinnert an die Abschaltung der Mempool im Jahr 2024, die kurzfristige Einnahmen verringerte, dem Netzwerk letztlich aber zugutekam. Die Verbesserungen durch BAM könnten dies ausgleichen, indem sie das gesamte Transaktionsvolumen und die Plugin-Gebühren steigern. Bessere Akzeptanzraten würden so langfristig den Umsatz erhöhen. Die genaue Implementierung von BAM, die schrittweise Einführung und die wirtschaftlichen Rahmenbedingungen bergen jedoch potenzielle Zentralisierungsrisiken und offene Fragen, die wir in den folgenden Abschnitten untersuchen. Diesen Risiken und offenen Fragen stehen wiederum verschiedene Vorteile gegenüber. Jeder davon hat eigene Auswirkungen auf die Umverteilung von MEV, PBS und die Entwicklung eines „neuen“ Clients.

Umverteilung von MEV

BAM verändert die MEV-Landschaft von Solana grundlegend: Statt unkontrollierter Abschöpfung entsteht ein strukturierteres Umverteilungsmodell. In herkömmlichen Konfigurationen entzieht MEV Nutzern häufig durch Frontrunning oder Spam einen Teil ihres Werts. Validatoren oder Bots schöpfen ihn mit schädlichen Methoden wie Sandwich-Angriffen ab. Die TEE-verschlüsselte Mempool von BAM verbirgt Transaktionen dagegen bis zur Ausführung und schränkt so die Sichtbarkeit für negatives MEV ein. Der Wert wird stattdessen durch Plugins und benutzerdefinierte Sequenzierung internalisiert. Dadurch können Apps, Entwickler und Searcher positive Formen von MEV erfassen, die die Effizienz des Ökosystems steigern, etwa durch engere DeFi-Spreads und weniger Oracle-Spam.

Diese Umverteilung führt MEV-Gewinne an die Beteiligten zurück, da Plugin-Gebühren zwischen Betreibern von BAM-Nodes, Validatoren, Stakern und der DAO von Jito aufgeteilt werden. Daraus könnten nachhaltige Einnahmequellen entstehen. Eine DEX könnte beispielsweise ein Plugin einsetzen, das das Order-Matching optimiert und potenziell von Validatoren abgeschöpftes MEV in von der App erzeugte Gebühren umwandelt. Diese ließen sich an Token-Inhaber umverteilen. Dieser „geschützte“ Ansatz für Handelsaktivitäten könnte MEV von einem Nullsummenspiel in einen Mechanismus verwandeln, der die Liquidität vertieft und institutionelles Kapital anzieht.

Die Umverteilung birgt jedoch Risiken. Entscheidend ist: BAM beseitigt MEV nicht – es verlagert MEV. Durch diese Verlagerung könnten frühe Plugin-Entwickler, Betreiber von BAM-Nodes und mit Jito verbundene Organisationen überproportional profitieren. Trotz kryptografischer Attestierungen könnten TEE-Schwachstellen, etwa Seitenkanalangriffe, privilegierten Searchern neue, subtile Möglichkeiten zur Wertabschöpfung eröffnen und so letztlich die Datenschutzgarantien untergraben. Das ermöglicht auch „geschützte“ Formen des Backrunnings: Searcher könnten Code bereitstellen, der Transaktionen an die eines Nutzers anhängt, etwa um Arbitrage aus einem preistreibenden Swap zu ziehen, ohne Strategien offenzulegen oder Frontrunning zu ermöglichen. Ohne programmatisches Slashing könnten anpassungsfähige Angreifer außerdem schädliche Strategien rund um Attestierungen verfolgen. Diese erfolgen erst nach der Ausführung und stützen sich derzeit auf die Durchsetzung durch die Community.

Die Umverteilung von MEV macht BAM letztlich zu einem möglichen Katalysator für das langfristige Ziel von Solana, also eine dezentrale NASDAQ. Der Erfolg hängt jedoch von fairen Gebührenmodellen und robuster TEE-Sicherheit ab. Bei einer schlechten Umsetzung könnte BAM das Netzwerk fragmentieren, das Vertrauen der Nutzer schwächen und wegen „geschützter“, aber undurchsichtiger Aktivitäten von Searchern Kritik auf sich ziehen.

Trennung von Proposer und Builder (PBS)

Die meisten Blockchains sind so konzipiert, dass dieselbe Instanz Blöcke sowohl vorschlägt als auch erstellt. Dadurch erhält sie monopolartige Kontrolle über die Reihenfolge und Aufnahme von Transaktionen in den ihr zugewiesenen Slots. Das ist für diese Instanzen vorteilhaft, da sie Transaktionsflüsse nach Belieben zensieren oder anderweitig manipulieren können. Sie könnten Blöcke beispielsweise mit ausgefeilten, aber schädlichen Strategien vorschlagen und erstellen, um Transaktionen in einer bestimmten Reihenfolge aufzunehmen und so MEV zu maximieren.

Die Trennung von Proposer und Builder (PBS) ist ein Entwurfsmuster, das dieses Problem löst, indem es die Blockerstellung vom Blockvorschlag trennt. Bei diesem Modell erstellen Block-Builder geordnete Transaktionslisten und geben Gebote für diese Blöcke ab. Block-Proposer, üblicherweise Validatoren, akzeptieren und bestätigen anschließend den Block mit dem höchsten Gebot. Dadurch wird MEV über Auktionen oder Tips umverteilt, ohne dass die Validatoren selbst komplexe Sequenzierungsstrategien ausführen müssen. 

PBS wird auf Ethereum seit The Merge im Jahr 2022 außerhalb des Protokolls über MEV-Boost implementiert. MEV-Boost ist ein „Sidecar“, das parallel zur Client-Software eines Validators für die Ausführungs- und Konsensschicht läuft. Validatoren mit MEV-Boost können sich mit mehreren Relays verbinden und vorgefertigte Blöcke von Block-Buildern annehmen. Sie sehen den Inhalt eines Blocks nicht, bevor er On-Chain aufgenommen wird, da sie von den Relays nur die Höhe der Blockbelohnung und die Block-Header erhalten. Dieses Design wird weiterhin aktiv erforscht. PBS wartet auf die vollständige Verankerung im Protokoll (ePBS), die Funktionen wie Aufnahmelisten enthalten könnte, um Zensur weiter einzudämmen.

Mit BAM bewegt sich Solana in Richtung einer PBS-ähnlichen Zukunft. Die Blockkonstruktion, also die Sequenzierung in TEE-gesicherten BAM-Nodes, wird von der Ausführung getrennt, für die weiterhin die Validatoren verantwortlich sind. Das könnte positive Formen von MEV über Plugins für Apps und Searcher demokratisieren. Es könnte aber auch die Stake-Zentralisierung von Solana verschärfen, wenn die wirtschaftlichen Anreize der Plugins etablierte Akteure bevorzugen. Das zeigt sich bei Ethereum, wo drei Builder – Titan Builder, BuilderNet und Beaverbuild – inzwischen über ~90 % aller Blöcke dominieren. Das schafft Vertrauensprobleme bei Relays und Hürden für kleinere Teilnehmer. 

MEV-Boost hat PBS zwar auf Ethereum eingeführt, ein treffenderer Vergleich ist hier jedoch BuilderNet. Dieses dezentrale Netzwerk zur Blockerstellung startete im November 2024 und wird von Flashbots, Beaverbuild und Nethermind betrieben. BuilderNet nutzt TEEs für die private Blockerstellung. Dadurch verteilt es den Prozess auf mehrere Node-Betreiber, neutralisiert exklusive Orderflow-Vereinbarungen und reduziert die Zentralisierung. Im Mittelpunkt steht die Wertschöpfung, also etwa die Weitergabe von MEV-Rückerstattungen an Orderflow-Anbieter wie Nutzer, Wallets und Apps, statt des Wettstreits um Orderflow, beispielsweise um private Vereinbarungen. BuilderNet verwendet weiterhin MEV-Boost-Relays, benötigt sie aber nicht zwingend. Direkte Interaktionen zwischen Buildern und Proposern können daher in TEEs stattfinden. 

Die schrittweise, zugangsbeschränkte Einführung von BAM muss faire Gebühren und quelloffene Plugins priorisieren, um diese Probleme von Ethereum zu vermeiden. Das ist besonders wegen der Hardwareabhängigkeiten wichtig, also TEEs im Gegensatz zu den Software-Relays von Ethereum, die Aspekte einer Anbieterbindung und Wartungskosten mit sich bringen. Solana möchte den Wettstreit um Orderflow überspringen und direkt zu einem BuilderNet-ähnlichen System gelangen, das sich auf Wertschöpfung konzentriert. 

Diese Verlagerung bei Blockkonstruktion und Blockvorschlag schwächt letztlich die Rolle der Validatoren. Sie gibt die Komplexität der Sequenzierung ab, könnte aber ihre Handlungsfreiheit und Einnahmen verringern, wenn Gebühren nicht breit verteilt werden. Im Abschnitt Die geschwächte Rolle der Validatoren gehen wir ausführlicher darauf ein.

Oben: Vergleich von PBS auf Ethereum mit BAM auf Solana

Ein „neuer“ Client entsteht

Der Jito-Agave-Client bildet die zentrale Agave-Codebasis weitgehend nach und unterscheidet sich vor allem durch zusätzliche MEV-Funktionen. Das Modell „Agave plus MEV“ von Jito ermöglichte eine nahtlose Integration des Clients in das bestehende Validator-Ökosystem von Solana. Es steigerte die Belohnungen und hielt Änderungen an der Kernarchitektur gering. Dadurch führt der Jito-Agave-Client zum Zeitpunkt der Erstellung mit einem Anteil von 79 % bei den Validatoren das Netzwerk an. Validatoren können sich somit auf die grundlegende Logik von Agave verlassen und gleichzeitig von den zusätzlichen Einnahmequellen von Jito profitieren.

BAM weicht vom bisherigen Ansatz von Jito ab, Agave eng nachzubilden. Ein dediziertes Netzwerk aus BAM-Nodes schafft eine neue Infrastrukturschicht. Damit entwickelt sich Jito von einem bloß „erweiterten Agave“ zu einem eigenständigeren Client mit einem eigenen programmierbaren Ökosystem, in das sich anwendungsspezifische Logik einbetten lässt.

Diese Abweichung zeigt sich in den kommenden Scheduler-Bindings von Agave, die Anza im Mai angekündigt hat. Benutzerdefinierte Scheduler-Implementierungen werden mit der zunehmenden Reife von MEV auf Solana immer verbreiteter. Sie können zwar die Einnahmen ihrer Betreiber steigern, ihre aktuellen Implementierungen haben aber mehrere Nachteile. Dazu zählen die Notwendigkeit, eine andere Binärversion des Validators auszuführen, die Abhängigkeit von proprietärem Code und mögliche Probleme mit der Verfügbarkeit. 

Die kommenden Scheduler-Bindings von Anza schaffen Modularität. Sie ermöglichen es Validatoren, externe Dienste zur Blockerstellung anzubinden, ohne die zentrale Validator-Binärdatei zu verändern, und unterstützen dadurch benutzerdefinierte Scheduler. Dieses Design fördert Transparenz, Sicherheit und einfacheres DevOps. BAM macht diese Bindings für Jito-Nutzer jedoch überflüssig, da der Scheduler des BAM-Nodes die Sequenzierung vorgelagert übernimmt. Damit umgeht BAM die geplanten Scheduler-Bindings von Agave. Das könnte Abläufe vereinfachen, wirft aber wegen der Abweichung von den Standardisierungsbemühungen von Anza Fragen zur künftigen Fragmentierung des Ökosystems auf, etwa durch kompliziertere Firedancer-Integrationen.

Jito positioniert BAM dagegen als Teil eines einheitlichen Validator-Clients. BAM-Validatoren werden eine aktualisierte Version des Agave-Clients ausführen, die den BAM-Scheduler integriert und von BAM-Nodes ausschließlich Transaktionen in FIFO-Reihenfolge annimmt. Dieses Design vermeidet eine Fragmentierung der Clients und stärkt zugleich die Widerstandsfähigkeit des Systems. Jito plant, seinen BAM-kompatiblen Client noch vor der Einführung des modularen Schedulers von Anza zu veröffentlichen. Dieser Schritt verdeutlicht die doppelte Wirkung von BAM: Es fördert Innovationen und entwickelt die MEV-Infrastruktur von Solana weiter, könnte Jitos Position als dominanter Validator-Client aber noch stärker festigen.

BAM könnte diese Bindings ebenfalls verwenden. Wenn BAM innerhalb des modularen Schedulers arbeitet, wird die Unterstützung von Firedancer trivial. Dann stellt sich eine neue Frage: Braucht Jito überhaupt einen Validator-Client? Das wird sich erst zeigen, wenn die Open-Source-Implementierung des Codes und die Einführung von BAM erfolgen.

Offene Fragen

Die geschwächte Rolle der Validatoren

Das Design von BAM verändert die Validator-Landschaft von Solana grundlegend, da es die Sequenzierung von Transaktionen an ein separates Netzwerk TEE-gesicherter BAM-Nodes auslagert. Validatoren sind dadurch hauptsächlich für Ausführung, Konsens und Zustandsverwaltung verantwortlich. Diese Trennung ist für Apps von Vorteil, da sie benutzerdefinierte Sequenzierung und Möglichkeiten zur Umsatzbeteiligung für Token-Inhaber schafft. Auch Nutzer profitieren durch weniger negatives MEV und günstigere Preise. Sie wirft jedoch Fragen zur schwindenden Handlungsfreiheit und zu den wirtschaftlichen Anreizen für Validatoren auf.

Wenn Validatoren als Leader Blöcke erzeugen, können sie derzeit frei über die Reihenfolge der Transaktionen entscheiden. So können sie benutzerdefinierte Scheduler ausführen und ihre Blöcke nach eigenen Vorstellungen optimieren. BAM nimmt den Validatoren diese Verantwortung ab. Sie erhalten nun vorab sequenzierte Transaktionen, die sie in strikter FIFO-Reihenfolge ausführen müssen. Damit verlieren sie ihre Autonomie bei der Blockkonstruktion. Im Extremfall, wenn alle Transaktionen über BAM laufen, werden Validatoren zu bloßen „Abnickern“. Dann stellt sich die Frage, ob dezentrale Validatoren überhaupt noch nötig sind. 

Es gibt jedoch gegenläufige Faktoren. Plugin-Gebühren schaffen neue Einnahmequellen, die mit Validatoren und Stakern geteilt werden. Der einheitliche Client und die automatischen Fallbacks von BAM bringen Eigeninteressen mit der Gesundheit des Netzwerks in Einklang und verbessern so die allgemeine Widerstandsfähigkeit. Die optionale, schrittweise Einführung bewahrt zudem die Wahlfreiheit. Eine langfristige Veröffentlichung als Open Source gibt Validatoren Mitspracherecht bei der Entwicklung von BAM, fördert von der Community getragene Verbesserungen und erhält Teile ihrer Handlungsfreiheit.  Validatoren können außerdem Verbesserungen am Scheduler von BAM vorschlagen und sich dadurch möglicherweise Einnahmen aus höheren Volumina erschließen. Die Vorstellung, Validatoren seien bloße Abnicker, ist wahrscheinlich ebenfalls übertrieben, da sie weiterhin eine zentrale Rolle bei Konsens und Fork-Auswahl spielen. Die eigentliche Frage lautet: Wie viel Handlungsfreiheit werden Validatoren wirklich verlieren? Könnte BAM ihnen sogar ermöglichen, sich stärker auf Verfügbarkeit und Zustandsintegrität zu konzentrieren?

Mehrere Fragen bleiben offen:

• Wie konkurrieren Validatoren jenseits von Hardware und Verfügbarkeit, wenn BAM-Nodes die Sequenzierung und MEV-Abschöpfung übernehmen? 
• Wird die reine Ausführungsrolle der Validatoren bei hoher Akzeptanz die Dezentralisierung von Solana insgesamt verringern? Falls ja, mit welchen Kennzahlen lässt sich dieser Rückgang messen?
• Welche Schutzmechanismen außer Attestierungen können verhindern, dass BAM Validatoren auf der Suche nach Einnahmen zu schädlicheren Methoden treibt, ohne ihre Anreize weiter zu verringern?
• Könnten TEE-Schwachstellen oder Plugin-Exploits dazu führen, dass Validatoren unfair bestraft werden? 
• Was kann Solana aus den Erfahrungen von Ethereum mit PBS lernen, um der schwindenden Handlungsfreiheit der Validatoren entgegenzuwirken?

Böswillige Node-Betreiber

Die Architektur von BAM führt neue Vertrauensannahmen hinsichtlich der Validatoren ein. Es wird angenommen, dass Validatoren bei der Interaktion mit BAM-Nodes nicht böswillig handeln, etwa indem sie vorab sequenzierte Transaktionen manipulieren oder Daten offenlegen. Zum Start wird BAM aufgrund der Einschränkungen von TEEs auf eine zugangsbeschränkte Gruppe von Betreibern setzen. Diese Gruppe erhält die Aufgabe, einen aktualisierten Jito-Solana-Client auszuführen und weitergeleitete Transaktionen korrekt zu verarbeiten. Die Validatoren müssen darauf vertrauen, dass BAM-Nodes den Eingang nicht manipulieren. Dadurch entsteht Vertrauen auf zwei Ebenen – BAM-Nodes vor dem TEE und Validatoren nach dem TEE –, was das Risiko in einer zugangsbeschränkten Konfiguration erhöht. Die entscheidende Frage lautet: Was hindert Betreiber von BAM-Nodes daran, Transaktionen einzusehen, bevor sie das TEE erreichen? Die Antwort ist QUIC-Verschlüsselung für verifizierte Nodes. Sie betten die Attestierung in das QUIC-Zertifikat ein. Ob BAM-Nodes ehrlich arbeiten, lässt sich außerdem prüfen, indem ihre Hashes mit dem Open-Source-Repository von BAM abgeglichen werden. So kann festgestellt werden, ob ein BAM-Node tatsächlich die angegebene Software ausführt. Sofern niemand das TEE kompromittiert hat, werden die QUIC-Zertifikate für die TPU innerhalb des TEE erzeugt. Damit wird der gesamte ein- und ausgehende Datenverkehr verschlüsselt.

Zensur und die selektive Manipulation von Transaktionspaketen an den Ein- und Ausgangspunkten des Netzwerks bleiben jedoch wichtige Bedenken. Böswillige Betreiber verfügen weiterhin über erhebliche Zensurmöglichkeiten, obwohl sie die verschlüsselten Transaktionsdetails nicht einsehen können. Sie könnten Protokolltypen anhand von TLS-Signaturen erkennen, nach Verbindungsendpunkten filtern, zeitliche Analysen zur Erkennung bestimmter Muster durchführen und alle verschlüsselten Daten blockieren, die bestimmte Merkmale aufweisen. Ein böswilliger Betreiber kennt möglicherweise nicht die genauen übertragenen Transaktionen, kann Pakete aber weiterhin anhand von Metadaten und bestimmten Verkehrsmustern verwerfen. DoubleZero könnte mit Funktionen zur Paketfilterung und Zeitstempelung für mehr Transparenz sorgen und dieses Risiko verringern. Die Abwehr von Zensurangriffen auf Netzwerkebene ist letztlich ein triftiger Grund für eine zugangsbeschränkte Einführung.

Auch rund um den physischen Zugriff entstehen neue Vertrauensannahmen, da er fast immer ein Sicherheitsrisiko darstellt – TEEs sind keine Ausnahme. TEEs bieten zwar starke Sicherheitsgarantien, können aber dennoch kompromittiert werden, wenn ein Angreifer physischen Zugriff auf den Server erhält. Exklusive Partnerschaften mit SOC-2-konformen Anbietern helfen, dieses Risiko zu reduzieren und eine robuste, mehrschichtige Sicherheit auf Rechenzentrumsebene zu gewährleisten.

Mehrere Fragen bleiben offen:

• Wie wird die Durchsetzung funktionieren, wenn ein böswilliger Betreiber Pakete zensiert oder Daten offenlegt?
• Wie verhindert die Auswahl der Betreiber in der zugangsbeschränkten Phase Absprachen, und mit welchen Kennzahlen lässt sich der Fortschritt bei der Dezentralisierung messen? 

Zusammensetzbarkeit und Interaktion zwischen Plugins

Eine der wichtigsten offenen Fragen für BAM ist, wie Plugins in der Praxis miteinander interagieren werden. Eine einzelne Transaktion könnte gleichzeitig von mehreren Plugins abhängen, etwa von einem Oracle-Plugin für Just-in-Time-Preisaktualisierungen, einem DEX-Plugin zur Ermittlung optimaler Swap-Routen und einem Token-Plugin zur Verarbeitung bestimmter Verhaltensweisen von SPL-Token. Es ist entscheidend, dass diese Komponenten vorhersehbar und sicher zusammenarbeiten.

Plugins müssen möglicherweise externe Daten abrufen, um effektiv zu funktionieren. Das schafft jedoch eine potenzielle Angriffsfläche, da böswillige Plugins externe Aufrufe missbrauchen könnten, um vertrauliche Transaktionsdaten offenzulegen. Damit das Vertrauen in das System erhalten bleibt, müssen klare Grenzen dafür gelten, auf welche Daten Plugins zugreifen und welche sie weitergeben dürfen.

Eine weitere Komplexitätsebene entsteht durch das Zusammenspiel zwischen der Plugin-Logik auf Anwendungsebene und den Gebührenmechanismen von Solana. Wie interagieren die Ausführungsreihenfolge von Plugins, Jito-Tips und Prioritätsgebühren, wenn mehrere Plugins um Einfluss auf die Blockkonstruktion konkurrieren? Diese wirtschaftlichen Dynamiken müssen klar definiert und transparent durchgesetzt werden, um unbeabsichtigte Manipulation oder Missbrauch zu vermeiden.

Um diese Risiken zu steuern, soll die Einführung von BAM-Plugins voraussichtlich in einer zugangsbeschränkten Umgebung beginnen. So lassen sich Plugin-Verhalten frühzeitig erproben und prüfen, bevor das System schrittweise zu einem offenen Modell übergeht.

Vertrauen in TEEs und Haftung

Die Abhängigkeit von TEEs führt neue Vertrauensannahmen ein. Statt ein vertrauensfreies System für verifizierbare Berechnungen zu schaffen, verwendet BAM eine spezielle Hardware-Enklave. Die Abhängigkeit von einem einzelnen Hardwareanbieter wie Intel oder AMD birgt Monokulturrisiken. Ein Firmware-Rückruf oder Exploit könnte BAM zum Stillstand bringen und je nach Akzeptanz im Netzwerk möglicherweise einen netzwerkweiten Ausfall auslösen. Lassen sich solche Schwachstellen nicht durch Aktualisierungen von Firmware, Mikrocode oder BIOS beheben, kostet der Austausch der Hardware Zeit und führt zu wiederkehrenden Investitionsausgaben für Betreiber von BAM-Nodes. Das würde die Folgen möglicher Ausfallzeiten weiter verschärfen. 

Diese Bedenken beruhen auf früheren Schwachstellen, die gezeigt haben, dass TEEs versagen und verschlüsselte Daten offenlegen können. Intels Software Guard Extensions (SGX) waren beispielsweise von mehreren Problemen betroffen, die sich auf Blockchains auswirkten. Im August 2022 war das Secret Network anfällig für die Schwachstellen xAPIC und MMIO. Zusammen konnten diese Schwachstellen dazu verwendet werden, den Konsens-Seed zu extrahieren – einen zentralen Entschlüsselungsschlüssel für private Transaktionen, die im Netzwerk ausgeführt wurden. 

Zahlreiche weitere Probleme führten letztlich dazu, dass Intel SGX bei Intel-Core-Prozessoren der 11. und 12. Generation einstellte. Auch AMDs Secure Encrypted Virtualization-Secure Nested Paging (SEV-SNP) weist mehrere offengelegte Schwachstellen auf. Besonders erwähnenswert ist die im Februar veröffentlichte Schwachstelle CVE-2024-56161, die es ermöglichte, mit Administratorzugriff bösartigen Mikrocode einzuschleusen. 

Updates zur Behebung von Schwachstellen sind nicht immer abwärtskompatibel und können physische Upgrades erfordern. Die Offenlegung von CVE02020-12967 und CVE-2021-26311 zeigte beispielsweise, dass in virtuellen Gastmaschinen auf Systemen mit AMD Secure Encrypted Virtualization-Encrypted State (SEV-ES), der vorherigen TEE-Implementierung des Unternehmens, beliebiger Code ausgeführt werden konnte. AMD veröffentlichte keine aktualisierte Firmware zur Behebung dieser Schwachstellen. Stattdessen stellte das Unternehmen eine Gegenmaßnahme über die SEV-SNP-Funktion bereit, die nur von AMD-EPYC-Prozessoren der 3. Generation, also „Milan“, unterstützt wurde. 

Die TEE-Infrastruktur von BAM basiert auf der neuesten Generation der SEV-SNP-Architektur. Sie umfasst die notwendigen Schutzmechanismen auf Hardwareebene, um diese bekannten Exploits zu verhindern. Erwähnenswert ist auch, dass das Netzwerk beim Entdecken einer Zero-Day-Schwachstelle weiterarbeiten könnte. Jito-Validatoren können automatisch auf ihre eigene TPU zurückfallen, wenn die Verbindung zu einem BAM-Node abbricht. Dieser Failover-Mechanismus sorgt dafür, dass Validatoren weiterlaufen, während Sicherheitspatches eingespielt werden.

Mehrere Fragen bleiben offen:

• Wie wirkt sich die Abhängigkeit von BAM von Hardwareanbietern angesichts früherer Exploits auf das langfristige Vertrauen aus? Können Alternativen wie Zero Trust Execution Environments (ZTEEs) diese Abhängigkeit verringern?
• Wer haftet für finanzielle Verluste, wenn private Transaktionsdaten aus einem kompromittierten TEE offengelegt werden?
• Wie ließe sich das Vertrauen nach einem Ausfall von TEEs wiederherstellen? Könnte eine Alternative angeboten werden?

Fazit

Validatoren können letztlich frei entscheiden, welche Software sie ausführen. Als gewinnorientierte Unternehmen in einem hart umkämpften Markt richten sie ihre Entscheidungen nach den potenziellen Erträgen für sich und ihre Delegierenden. Diese können ihren Stake dorthin verlagern, wo die Renditen am höchsten sind. Die breite Akzeptanz des Jito-Clients spiegelt diese Dynamik wider. Sein Erfolg beruht zu einem großen Teil darauf, dass er sowohl Betreibern als auch Delegierenden zusätzliche Einnahmen ermöglicht. Die Akzeptanz von BAM wird von ähnlichen Faktoren abhängen. Sollte der Betrieb von BAM dauerhaft profitabler sein als der Status quo, werden Validatoren es einsetzen. Andernfalls könnten sie trotz erheblicher Vorteile für andere Beteiligte vor einem Wechsel zurückschrecken.

Da BAM erst kürzlich angekündigt wurde, sind noch viele Fragen zu seinem Design und Betrieb offen. Wir freuen uns auf weitere Details, Dokumentation und Diskussionen in der Community über diese spannende Entwicklung in den kommenden Monaten.

Weitere Ressourcen

• Vorstellung von BAM: Die Zukunft der Blockerstellung auf Solana - Jito
• BAM-Whiteboard-Reihe - Jito Learn
• Jito BAM und die Zukunft von Solana - 0xResearch