SLV v0.9.911 Fügt Unterstützung für BAM Client-Operationen hinzu, um Solana zu einer transparenten Ausführungsebene zu fördern, die für institutionelle Verwendung geeignet ist

SLV v0.9.911 Fügt Unterstützung für BAM Client-Operationen hinzu, um Solana zu einer transparenten Ausführungsebene zu fördern, die für institutionelle Verwendung geeignet ist

SLV v0.9.911 Fügt Unterstützung für BAM Client-Operationen hinzu, um Solana zu einer transparenten Ausführungsebene zu fördern, die für institutionelle Verwendung geeignet ist
ELSOUL LABO B.V. (Hauptsitz: Amsterdam, Niederlande; CEO: Fumitake Kawasaki), zusammen mit Validators DAO, kündigt die Veröffentlichung von SLV v0.9.911, ein Open-Source-Betriebsrahmen für Solana-Validatoren. Diese Veröffentlichung unterstützt das Starten und Betreiben des von Block Assembly Marketplace (BAM) entwickelten Clients Jito Labs.
Mit dieser Version kann nun die Einführung und Vermittlung des BAM-Clients reproduzierbar gehandhabt werden. Anstatt sich auf unternehmensspezifische Verfahren oder individuelle betriebliche Expertise zu verlassen, SLV ermöglicht Validator-Betreibern, BAM-Client-Operationen mit einem einzigen Befehl zu starten.
Die Epics DAO validator hat bereits mit BAM-Client-Operationen migriert SLV und läuft derzeit in der Produktion.

Was BAM zu erreichen beabsichtigt: Verifizierbares Vertrauen auf Kette

BAM conceptual overview
Der Block Assembly Marketplace (BAM), entwickelt von Jito Labs, ist eine Initiative, die auf Solanas bereits leistungsfähige on-chain-Ausführung baut und versucht, es zu ermöglichen, nach der Tatsache, die Regeln, unter denen Transaktionen durchgeführt wurden, zu erklären und zu überprüfen.
Im Vergleich zu anderen Blockchains hat Solana einen deutlichen Vorteil bei Transaktionsdurchsatz und Latenz. Da jedoch das Netzwerk reift und seine Nutzerbasis erweitert, verschiebt sich die zentrale Frage, ob Transaktionen schnell verarbeitet werden können, ob der Ausführungsprozess selbst anhand der Logik und Regeln erläutert werden kann, mit denen es aufgetreten ist.
Insbesondere arbeiten Institutionen und Unternehmensnutzer nicht allein mit Eigenkapital zusammen. Sie verwalten Kunden- oder Verwahrvermögen und sind daher nicht nur für Ergebnisse, sondern für den Ausführungsprozess selbst verantwortlich. Sie müssen internen Risikoausschüssen, externen Prüfern und in einigen Fällen Regulierungsbehörden erklären, warum eine Transaktion unter bestimmten Bedingungen und in einer bestimmten Reihenfolge durchgeführt wurde.
Das ist keine theoretische Sorge. In traditionellen Finanzmärkten sind solche Anforderungen bereits Standardpraxis. Die beste Ausführungsberichterstattung und die Einreichung von Transaktionskostenanalysen sind typische Beispiele. Es reicht nicht aus, anzugeben, welcher Austausch oder Veranstaltungsort verwendet wurde; die Ausführungslogik selbst muss erklärt werden.
In den heutigen on-chain Ausführungsumgebungen ist es für Dritte schwierig, zu überprüfen, warum Transaktionen auf eine bestimmte Weise bestellt wurden oder welche Logik ihre Platzierung bestimmt. Unabhängig von Absicht reicht dieser Mangel an Erklärbarkeit allein aus, um die institutionelle Beteiligung zu entmutigen.
BAM adressiert dieses Problem, indem die Transaktionsbestellung durch kryptographische Mechanismen überprüft werden kann. Während es möglich wird, zu beweisen, dass Transaktionen nach definierter Logik bestellt wurden, können BAM-Knotenbetreiber selbst Transaktionsinhalte nicht inspizieren oder die Bestellung beliebig manipulieren.
Was BAM letztendlich zu etablieren versucht, ist kein Modell, das auf vertrauenswürdige spezifische Operatoren beruht, sondern ein Modell, in dem die Ausführungslogik selbst überprüfbar ist. Dies bewegt die on-chain-Ausführung über das bloße Fasten hinaus, hin zu einer Umgebung, die erklärt, auditierbar und für die formale Berichterstattung geeignet ist.

Die aktuelle Herausforderung: Flexibel aber Opaque Scheduling

Heute ermöglicht Solana einen hohen Freiheitsgrad in der Abwicklung von Transaktionsaufträgen. Mehrere Scheduler arbeiten parallel, jeweils mit verschiedenen Logik-, Timing- und Priorisierungsstrategien.
Während diese Vielfalt Experimente und Optimierungen ermöglicht, ist es auch schwierig, aus einer externen Perspektive, welche die Transaktionsordnung bestimmt, konsequent zu erklären. Je nach Client, Routing-Pfad oder operativer Einrichtung ist es nicht immer möglich, Bestellungsentscheidungen auszuschließen, die extern nicht eingehalten werden können.
Das Problem hier ist nicht bösartige Absicht. Selbst wenn alle Betreiber in gutem Glauben handeln, ist eine nicht zu erklärende oder zu verifizierende Ausführungsumgebung mit institutionellen und unternehmensspezifischen Anforderungen inhärent unvereinbar.
Auch wenn Probleme nicht sofort auftauchen, akkumuliert diese Opazität als Ausführungsrisiko und Prüfungsunsicherheit. Infolgedessen bleibt die on-chain-Nutzung weitgehend auf einzelne Nutzer und experimentelle Anwendungen beschränkt, während Großkapital und Unternehmensannahme kämpfen, um zu materialisieren.

Lektionen von Ethereums Präzedenzfall

Ähnliche Herausforderungen sind bereits im Ethereum-Ökosystem entstanden. Mit der Einführung der Vorschlager-Builder-Trennung stieg der Wettbewerb im Blockgebäude, was aber auch zu einer Konzentration von Bauherren und der Privatisierung des Auftragsflusses führte.
Da die Nutzer und Anwendungen eine bessere Ausführung suchten, stützten sie sich zunehmend auf private Beziehungen mit bestimmten Bauherren, wodurch die Transaktion schwieriger ist, außen zu beobachten. Während diese Struktur manchmal die kurzfristige Effizienz verbessert hat, führte sie letztendlich zu einer größeren Opazität und Zentralisierung.
In der heutigen Ethereum-Gemeinschaft werden Anstrengungen unternommen, um Transparenz durch Ansätze wie TEE-basiertes Blockgebäude wiederherzustellen. Dies spiegelt eine Nach-Hoc-Erkennung der Bedeutung der Erklärbarkeit an der Ausführungsschicht wider.
BAM ist mit diesen Präzedenzfällen konzipiert, die Verifizierbarkeit und Transparenz von vornherein enthalten, anstatt sie später nachzurüsten.

Durchführungsfortschritte SLV v0.9.911

Die Designprinzipien von BAM sind nur wichtig, wenn sie in der Praxis umgesetzt und betrieben werden können. Selbst ein gut gestaltetes System kann die Transparenz nicht verbessern, wenn es schwierig bleibt, nur für eine kleine Anzahl von Betreibern einzusetzen oder zugänglich zu sein.
SLV v0.9.911 integriert BAM-Client-Start und Betrieb in SLVs Standard-Workflow. Dies beseitigt die Abhängigkeit von individuellen Bediener-Know-how und Ad-hoc-Verfahren beim Wechsel auf BAM.
reproduzierbar einsetzbar zu sein, ist eine Voraussetzung für eine weit verbreitete Einführung einer überprüfbaren Ausführungsschicht. Diese Veröffentlichung stellt einen konkreten Schritt zur Einbettung von BAM in die operative Infrastruktur von Solana dar, nicht nur als Konzept.

Betriebsstatus der Epics DAO Gültig

Epics DAO validator running BAM client
Die Epics DAO validator hat bereits mit BAM-Client-Operationen migriert SLV und läuft weiter in der Produktion. Dies zeigt, dass BAM nicht auf konzeptionelle Gestaltung beschränkt ist, sondern aktiv in realen Validator-Betrieb arbeitet.
Darüber hinaus ermöglicht die Verwendung des BAM-Clients aus einer Sicht des Validierungsbetriebs die Trennung der Logik für die Transaktionsaufnahme und die Bestellung von den zentralen Ausführungs- und Abstimmungsprozessen des Validators.
Traditionell wurde die Last, die mit der Transaktionsaufnahme und der Bestellung verbunden ist, eng mit dem Ablaufweg des Validators gekoppelt. Mit einem BAM-basierten Setup kann die Verarbeitungslast im Zusammenhang mit Transaktionsempfang und Terminierung jedoch als besonderes Anliegen behandelt werden.
Dies ermöglicht es den Validatoren, sich direkter auf die Ausführung und Abstimmung zu konzentrieren und gleichzeitig ein operatives Design zu ermöglichen, bei dem Arbeitsbelastungen mit unterschiedlichen Eigenschaften getrennt behandelt werden. Dies behauptet nicht eine direkte Leistungsverbesserung, sondern betont, dass die Trennung von operativen Aufgaben und Lastdomänen die verfügbaren Designoptionen für Validator-Betrieb erweitert.

Seht ihr?

Die überprüfbare Transaktionsauftrags- und Ausführungstransparenz, die BAM bieten soll, sind ein Schlüsselelement für die Förderung von Solana in Richtung einer für den institutionellen und Unternehmensgebrauch geeigneten Ausführungsumgebung.
SLV dient als Grundlage für die Übersetzung dieser Richtung in die Praxis. Vorwärts, Validatoren, RPC-Infrastruktur, Vernetzung und dezentrale Anwendungen werden nicht als isolierte Optimierungsziele behandelt, sondern als interdependente Komponenten, die gemeinsam die Ausführungsqualität und das Vertrauen bestimmen. Durch diesen Ansatz wird die operative Infrastruktur von Solana weiter ausgebaut.