𝗕𝗲𝗻 𝗕𝗔𝗠 𝗼𝗳 𝗻𝗶𝗰𝗵𝘁 𝗯𝗲𝗻 𝗕𝗔𝗠 💥🤔 Auf den Rat von @0xMert hat das Team einen Blog geschrieben, der jedes Gegenargument gegen BAM widerlegt. Siehe den Link unten. Lass uns eintauchen 🧵 ⬇️

"𝗕𝗔𝗠 𝗶𝘀 𝗮 𝗰𝗲𝗻𝘁𝗿𝗮𝗹𝗶𝘇𝗲𝗱 𝘀𝗲𝗾𝘂𝗲𝗻𝗰𝗲𝗿 𝘄𝗶𝘁𝗵 𝗮 𝗯𝗹𝗼𝗰𝗸-𝗯𝘂𝗶𝗹𝗱𝗶𝗻𝗴 𝗺𝗼𝗻𝗼𝗽𝗼𝗹𝘆." 𝘚𝘵𝘦𝘦𝘭𝘮𝘢𝘯: Diese Kritik argumentiert, dass BAM einen einzelnen Sequencer einführt, der die gesamte Transaktionsplanung für Solana übernimmt. Auch wenn die Infrastruktur verteilt ist, stammen die Planungsregeln aus einem System, das von Jito kontrolliert wird. Die Stakeholder befürchten, dass dies die natürliche Vielfalt der Planer von Solana untergräbt und zu einem zentralisierten Sequencer führen könnte, der einen einzelnen Ausfallpunkt darstellt und zu viel Einfluss in einem Planer und einer Partei konzentriert. BAM ist so konzipiert, dass keine einzelne Entität die Transaktionsreihenfolge kontrollieren kann. Das System wird seinen Betrieb und die Governance der Planungslogik dezentralisieren durch: • 𝗼𝗽𝗲𝗻 𝗽𝗮𝗿𝘁𝗶𝗰𝗶𝗽𝗮𝘁𝗶𝗼𝗻: Jeder berechtigte Betreiber kann teilnehmen und seinen eigenen BAM-Knoten betreiben. • 𝗴𝗹𝗼𝗯𝗮𝗹 𝗰𝗼𝘃𝗲𝗿𝗮𝗴𝗲: BAM-Knoten werden über ein geografisch vielfältiges Netzwerk von Betreibern verteilt. • 𝗼𝗽𝗲𝗻-𝘀𝗼𝘂𝗿𝗰𝗲, 𝘃𝗲𝗿𝗶𝗳𝗶𝗮𝗯𝗹𝗲 𝘀𝗰𝗵𝗲𝗱𝘂𝗹𝗶𝗻𝗴: Alle BAM-Codes werden Open Source sein und über kryptografische Bestätigungen überprüfbar sein. Obwohl es stimmt, dass BAM-Knoten derzeit ausschließlich von Jito betrieben werden, wird ab Q1 '26 der Code als Open Source veröffentlicht und unabhängige Betreiber werden integriert.

„𝗔𝘀 𝗮 𝘃𝗮𝗹𝗶𝗱𝗮𝘁𝗼𝗿, 𝗕𝗔𝗠 𝘁𝗶𝗲𝘀 𝗺𝗲 𝘂𝗽 𝘁𝗼 𝗼𝗻𝗹𝘆 𝗼𝗻𝗲 𝘀𝗰𝗵𝗲𝗱𝘂𝗹𝗲𝗿“ 𝘚𝘵𝘦𝘦𝘭𝘮𝘢𝘯: Diese Kritik besagt, dass ein Validator, der sich für BAM entscheidet, effektiv die Kontrolle über die Transaktionsreihenfolge an einen einzigen Scheduler abgibt. Anstatt verschiedene Scheduler zu betreiben oder zu übernehmen, mit eigenen Strategien zu experimentieren oder zwischen konkurrierenden Designs zu wechseln, sind sie an ein System gebunden. Um Internet-Kapitalmärkte zu ermöglichen, benötigt Solana deterministische und transparente Reihenfolgeregeln. Fragmentierung schadet den Nutzern. BAM macht dies mit standardisiertem, überprüfbarem Blockbau möglich, der von leistungsstarken Anwendungen gefordert wird. Die Fakten sind: • BAM ist strikt freiwillig. • Validatoren können auf Agave, Jito-Solana oder Firedancer-Clients zurückgreifen. • Sie können sich jederzeit von BAM trennen. BAM-Plugins bieten eine Plattform für Optimierung und Entwicklerinnovation, die allen von Solana zugutekommt.

"𝗕𝗔𝗠 𝗺𝗼𝗻𝗼𝗽𝗼𝗹𝗶𝘇𝗲𝘀 𝗦𝗼𝗹𝗮𝗻𝗮 𝗼𝗿𝗱𝗲𝗿𝗳𝗹𝗼𝘄." 𝘚𝘵𝘦𝘦𝘭𝘮𝘢𝘯: Interessengruppen argumentieren, dass die Aggregation öffentlicher Transaktionen in einer einzigen Pipeline einen zentralen Engpass schafft, durch den der gesamte Orderflow fließt, und Vorteile für diejenigen bietet, die ihn kontrollieren. Selbst wenn es anfangs neutral ist, kontrolliert BAM den Orderflow, was seine Wettbewerbsposition stärken und verhindern kann, dass andere Lösungen an Bedeutung gewinnen. BAM sammelt Transaktionen mit dem Standard-Solana-TPU-Mechanismus. Es gibt keinen Unterschied zwischen "BAM-Transaktionen" und öffentlichen. Validatoren erhalten denselben öffentlichen Flow, der einfach durch eine überprüfbare Schicht geplant wird. Validatoren können sofort ohne Wechselkosten zu ihrem nativen TPU zurückkehren und den Orderflow öffentlich halten, anstatt ihn in private Kanäle zu fragmentieren.

“𝗕𝗔𝗠 𝗶𝗻𝘁𝗿𝗼𝗱𝘂𝗰𝗲𝘀 𝗲𝘅𝘁𝗿𝗮 𝗹𝗮𝘁𝗲𝗻𝗰𝘆 𝘃𝘀. 𝘃𝗮𝗹𝗶𝗱𝗮𝘁𝗼𝗿’𝘀 𝗻𝗮𝘁𝗶𝘃𝗲 𝗧𝗣𝗨.” 𝘚𝘵𝘦𝘦𝘭𝘮𝘢𝘯: Interessengruppen argumentieren, dass einer der Leistungsvorteile von Solana darin besteht, dass Transaktionen direkt zum TPU des Leaders mit minimalen Hops fließen. Jede Zwischenrouting-Schicht, selbst eine schnelle, birgt das Risiko, Latenz, Jitter und neue Ausfallpunkte unter Last hinzuzufügen, und könnte die IBRL-Mission im Vergleich zur nativen TPU-Planung schwächen. BAM gewährleistet minimale Latenz durch einen globalen Fußabdruck von über 100 Knoten und strategische Co-Location, wodurch die Hin- und Rücklaufzeiten unter 5 ms bleiben. Unser TEE-Stack ist hochgradig optimiert durch Thread-Pinning und CPU-Isolation, wodurch wir eine Leistungsparität mit Agave erreichen. Mit der bevorstehenden Migration zu DoubleZero erwarten wir, die Leistungsbenchmarks von Bare Metal zu übertreffen.

„𝗕𝗔𝗠 𝗽𝗿𝗼𝗱𝘂𝗰𝗲𝘀 𝗹𝗲𝘀𝘀 𝗿𝗲𝘄𝗮𝗿𝗱𝘀 𝘃𝘀. 𝗼𝘁𝗵𝗲𝗿 𝗰𝗹𝗶𝗲𝗻𝘁𝘀“ 𝘚𝘵𝘦𝘦𝘭𝘮𝘢𝘯: Validatoren haben Bedenken geäußert, dass die Zeitplanungslogik von BAM die Trinkgelder und die Gesamtbelohnungen im Vergleich zu anderen Blockbauern oder Zeitplanungsmöglichkeiten reduzieren könnte. Darüber hinaus sind die Plugin-Gebührenmärkte noch nicht aktiv, was den potenziellen Gewinn theoretisch macht, während der Nachteil sofort zu erscheinen scheint. Wir priorisieren die Maximierung des langfristigen Gewinns. Die Belohnungen von BAM sind bereits mit Jito-Agave vergleichbar. Frühere Unterschiede wurden durch vorübergehende, extraktive Zeitplaner an anderer Stelle verursacht, die abgeschafft werden. Zukünftige Erträge werden durch Plugins und ACE vorangetrieben, die nachhaltige Gebührenströme aus neuem wirtschaftlichem Aktivität freisetzen, anstatt kurzfristige Spiele.

„Als Validator muss ich meinen Stakern die höchsten Erträge bieten.“ 𝘚𝘵𝘦𝘦𝘭𝘮𝘢𝘯: Staker wählen Validatoren oft ausschließlich basierend auf den Belohnungen aus. Selbst eine kleine Verringerung der Tipps oder Schwankungen bei den Einnahmen über einen Epoch kann dazu führen, dass delegierte Stakes woanders hinfließen. Validatoren befürchten, dass die frühe Einführung von BAM sie in einen Wettbewerbsnachteil bringen könnte, wenn ihre Kollegen die Einführung verzögern. Wir verstehen, dass Validatoren die Erträge für sich selbst und ihre Staker maximieren müssen, aber sie müssen auch die sekundären Auswirkungen ihrer Handlungen berücksichtigen. Kurzfristiges Yield-Hacking (Sandwiching, Slot-Lagging) mindert die allgemeine Ausführungsqualität und treibt die Liquidität weg. Der einzige nachhaltige Weg zu höheren Erträgen ist eine tiefere Onchain-Aktivität, die nur durch bessere Anwendungen, tiefere Liquidität und engere Spreads ermöglicht werden kann.

"𝗔𝗽𝗽𝗹𝗶𝗰𝗮𝘁𝗶𝗼𝗻-𝗖𝗼𝗻𝘁𝗿𝗼𝗹𝗹𝗲𝗱 𝗘𝘅𝗲𝗰𝘂𝘁𝗶𝗼𝗻 (𝗔𝗖𝗘) 𝗶𝘀 𝗻𝗼𝘁 𝗶𝗺𝗽𝗼𝗿𝘁𝗮𝗻𝘁." 𝘚𝘵𝘦𝘦𝘭𝘮𝘢𝘯: Interessengruppen argumentieren, dass Solana-Anwendungen bereits gut unter den Mechanismen der Prioritätsgebühren und Tipps funktionieren. Die Einführung von ACE könnte die Komplexität erhöhen und ungleiche Ausführungszusagen zwischen anspruchsvollen Apps und kleineren Entwicklern schaffen. Sie befürchten, dass die Erlaubnis für Anwendungen, die Logik der Reihenfolge zu definieren, dazu führen könnte, dass BAM bestimmten Akteuren Vorteile verschafft. Anspruchsvolle Apps benötigen Garantien wie Stornierungspriorität oder Liquidationspriorität, um sicher zu funktionieren. Hyperliquid erzielt 10-15x das Volumen von Solana Perps, insbesondere wegen seines genehmigten Validator-Sets, das strenge Reihenfolgen durchsetzt. Ohne ACE werden diese Apps zu benutzerdefinierten L1s oder L2s migrieren, um diese Garantien zu erhalten.

„𝗙𝗜𝗙𝗢-Bestellungen sind die fairste Transaktionsbestelllogik“ 𝘚𝘵𝘦𝘦𝘭𝘮𝘢𝘯: Interessengruppen argumentieren, dass die einfache FIFO (First-In, First-Out) Bestellweise die fairste und neutralste Methode ist, um Transaktionen auf Solana zu planen. Sie spiegelt die Zeitpriorität traditioneller Märkte wider, ist für die Benutzer leicht verständlich („wenn meine tx zuerst ankommt, wird sie zuerst ausgeführt“) und vermeidet die „Pay-to-Win“-Dynamik der meisten Blockchains. Obwohl FIFO am fairsten erscheint, indem es Transaktionen in der Reihenfolge verarbeitet, in der sie empfangen werden, ermutigt es die Benutzer, das Netzwerk mit Spam zu überfluten, um eine günstige Position zu sichern, was zu Staus und geldverbrennenden Latenzrennen führt. Dies bricht zusammen, wenn die Netzwerknachfrage hoch ist, was unvorhersehbare Verzögerungen für alle Benutzer verursacht, während die Warteschlangen länger werden. Der One-Size-Fits-All-Ansatz von FIFO erfüllt nicht die Bedürfnisse von Apps, die eine spezifische Transaktionsreihenfolge benötigen, um optimal zu funktionieren.

"𝗔𝗿𝗲𝗻'𝘁 𝗕𝗔𝗠'𝘀 𝗧𝗿𝘂𝘀𝘁𝗲𝗱 𝗘𝘅𝗲𝗰𝘂𝘁𝗶𝗼𝗻 𝗘𝗻𝘃𝗶𝗿𝗼𝗻𝗺𝗲𝗻𝘁𝘀 (𝗧𝗘𝗘𝘀) 𝘃𝘂𝗹𝗻𝗲𝗿𝗮𝗯𝗹𝗲 𝘁𝗼 𝗮𝘁𝘁𝗮𝗰𝗸𝘀?" 𝘚𝘵𝘦𝘦𝘭𝘮𝘢𝘯: TEEs haben eine Geschichte von Seitenkanalanfälligkeiten, Firmwarefehlern und Risiken in der Lieferkette. Interessengruppen argumentieren, dass die Abhängigkeit von TEEs für die Blockplanung korrelierte Fehlermodi einführen könnte: Wenn ein Hardware-Exploit SEV-SNP betrifft, könnte BAM als Netzwerk kompromittiert werden. Sie argumentieren auch, dass TEEs das Vertrauen auf Hardwareanbieter und Rechenzentrumsanbieter verlagern. BAM läuft auf AMD SEV-SNP mit kryptografischen Attestierungen in sicheren, konformen Rechenzentren (ISO 27001/SOC 2). Selbst im schlimmsten Fall eines Hardwarekompromisses bleiben die Validator-Schlüssel sicher und die Historie der Kette kann nicht umgeschrieben werden, nur die Bestellprivatsphäre auf diesem spezifischen Knoten ist betroffen. Validatoren überprüfen den "gemessenen TCB" und können schlechte Firmware über die Attestierung ablehnen.

@0xmert Die Zukunft des Blockbaus bewegt sich von fragmentierter Planung zu einem transparenten, überprüfbaren Marktplatz. BAM ist die Lösung. Milliarden müssen BAM! 💥