SLV v0.9.911 voegt ondersteuning toe voor BAM Client Operations, brengt Solana dichter bij een transparante uitvoeringslaag geschikt voor institutioneel gebruik

SLV v0.9.911 voegt ondersteuning toe voor BAM Client Operations, brengt Solana dichter bij een transparante uitvoeringslaag geschikt voor institutioneel gebruik

2025.12.30
ELSOUL LABO B.V. (Hoofdkantoor: Amsterdam, Nederland; CEO: Fumitake Kawasaki), samen met Validators DAO, kondigt de release aan van SLV v0.9.911, een open-source operationeel framework voor Solana validators. Deze release voegt ondersteuning toe voor het lanceren en beheren van de Block Assembly Marketplace (BAM)-client, ontwikkeld door Jito Labs.
Met deze release kan de introductie en omschakeling van de BAM-client nu op een reproduceerbare manier worden afgehandeld. In plaats van te vertrouwen op operator-specifieke procedures of individuele operationele expertise, stelt SLV validators in staat om BAM-clientoperaties met een enkel commando te starten.
De Epics DAO Validator is al gemigreerd naar BAM-clientoperaties met SLV en draait momenteel in productie.

Wat BAM beoogt te bereiken: verifieerbaar vertrouwen on-chain

BAM conceptual overview
De Block Assembly Marketplace (BAM), ontwikkeld door Jito Labs, is een initiatief dat voortbouwt op Solana's reeds hoogpresterende on-chain uitvoering en beoogt het mogelijk te maken om achteraf te verklaren en verifieren onder welke regels transacties zijn uitgevoerd.
Vergeleken met andere blockchains heeft Solana een duidelijk voordeel in transactiedoorvoer en latentie. Naarmate het netwerk echter volwassener wordt en het gebruikersbestand groeit, verschuift de kernvraag van of transacties snel kunnen worden verwerkt naar of het uitvoeringsproces zelf kan worden uitgelegd in termen van de logica en regels waaronder het plaatsvond.
Met name instellingen en zakelijke gebruikers opereren niet alleen met eigen kapitaal. Zij beheren klant- of custodiale activa en zijn daarom verantwoordelijk niet alleen voor resultaten, maar voor het uitvoeringsproces zelf. Zij moeten aan interne risicocomites, externe auditors en in sommige gevallen toezichthouders uitleggen waarom een transactie is uitgevoerd onder een specifieke set voorwaarden en in een bepaalde volgorde.
Dit is geen theoretische zorg. In traditionele financiele markten is dit al standaardpraktijk. Best execution-rapportage en het indienen van Transaction Cost Analysis zijn typische voorbeelden. Het volstaat niet om te vermelden welke beurs of marktplaats is gebruikt; de uitvoeringslogica zelf moet verklaarbaar zijn.
In de huidige on-chain uitvoeringsomgevingen is het moeilijk voor derden om te verifieren waarom transacties op een bepaalde manier zijn geordend of welke logica hun plaatsing heeft bepaald. Ongeacht de intentie is dit gebrek aan verklaarbaarheid alleen al voldoende om institutionele deelname te ontmoedigen.
BAM pakt dit probleem aan door transactieordening verifieerbaar te maken via cryptografische mechanismen. Hoewel het mogelijk wordt om te bewijzen dat transacties zijn geordend volgens gedefinieerde logica, kunnen BAM-nodeoperators zelf de transactie-inhoud niet inspecteren of de ordening willekeurig manipuleren.
Wat BAM uiteindelijk wil vaststellen is niet een model dat vertrouwt op het vertrouwen van specifieke operators, maar een model waarin de uitvoeringslogica zelf verifieerbaar is. Dit brengt on-chain uitvoering voorbij louter snel zijn, naar een omgeving die verklaarbaar, auditeerbaar en geschikt is voor formele rapportage.

De huidige uitdaging: flexibele maar ondoorzichtige planning

Momenteel staat Solana een hoge mate van vrijheid toe in hoe transactieordening wordt afgehandeld. Meerdere schedulers opereren parallel, elk met verschillende logica, timingkenmerken en prioriteringsstrategieen.
Hoewel deze diversiteit experimentatie en optimalisatie mogelijk maakt, maakt het het ook moeilijk om vanuit een extern perspectief consistent uit te leggen welke regels de transactieordening hebben bepaald. Afhankelijk van de client, het routeringspad of de operationele opstelling is het niet altijd mogelijk om ordenbeslissingen uit te sluiten die extern niet kunnen worden waargenomen.
Het probleem hier is niet kwade opzet. Zelfs wanneer alle operators te goeder trouw handelen, is een uitvoeringsomgeving die niet kan worden verklaard of geverifieerd inherent onverenigbaar met institutionele en zakelijke vereisten.
Zelfs als er niet onmiddellijk problemen opduiken, accumuleert deze ondoorzichtigheid als uitvoeringsrisico en auditonzekerheid. Als gevolg hiervan blijft on-chain gebruik grotendeels beperkt tot individuele gebruikers en experimentele applicaties, terwijl grootschalig kapitaal en bedrijfsadoptie moeilijk te realiseren zijn.

Lessen uit het precedent van Ethereum

Vergelijkbare uitdagingen zijn al opgedoken binnen het Ethereum-ecosysteem. Met de introductie van proposer-builder scheiding nam de concurrentie in blokbouw toe, maar dit leidde ook tot een concentratie van bouwers en de privatisering van orderflow.
Naarmate gebruikers en applicaties betere uitvoering zochten, vertrouwden ze steeds meer op prive-relaties met specifieke bouwers, waardoor transactieordening moeilijker extern waarneembaar werd. Hoewel deze structuur soms de kortetermijn-efficientie verbeterde, resulteerde het uiteindelijk in grotere ondoorzichtigheid en centralisatie.
Binnen de Ethereum-gemeenschap zijn vandaag inspanningen gaande om transparantie te herstellen via benaderingen zoals TEE-gebaseerde blokbouw. Dit weerspiegelt een achteraf erkenning van het belang van verklaarbaarheid op de uitvoeringslaag.
BAM is ontworpen met deze precedenten in gedachten en integreert verifieerbaarheid en transparantie vanaf het begin in plaats van ze later te proberen toe te voegen.

Implementatievoortgang in SLV v0.9.911

De ontwerpprincipes van BAM doen er alleen toe als ze in de praktijk kunnen worden geimplementeerd en beheerd. Zelfs een goed ontworpen systeem verbetert de transparantie niet als het moeilijk te implementeren blijft of slechts toegankelijk is voor een klein aantal operators.
SLV v0.9.911 integreert BAM-clientlancering en -operatie in SLV's standaardworkflow. Dit elimineert de afhankelijkheid van individuele operatorexpertise en ad-hocprocedures bij het overschakelen naar BAM.
Het reproduceerbaar kunnen implementeren is een voorwaarde voor brede adoptie van een verifieerbare uitvoeringslaag. Deze release vertegenwoordigt een concrete stap naar het inbedden van BAM in Solana's operationele infrastructuur als implementatie, niet slechts als concept.

Operationele status van de Epics DAO Validator

Epics DAO validator running BAM client
De Epics DAO Validator is al gemigreerd naar BAM-clientoperaties met SLV en blijft in productie draaien. Dit toont aan dat BAM niet beperkt is tot conceptueel ontwerp, maar actief functioneert binnen echte Validator-operaties.
Daarnaast maakt het gebruik van de BAM-client het vanuit een Validator-operatieperspectief mogelijk om de logica voor transactie-inname en -ordening te scheiden van de kern uitvoerings- en stemprocessen van de Validator.
Traditioneel was de belasting gerelateerd aan transactie-inname en -ordening nauw gekoppeld aan het uitvoeringspad van de Validator. Met een BAM-gebaseerde opstelling kan de verwerkingsbelasting gerelateerd aan transactieontvangst en -planning echter als een afzonderlijk aandachtspunt worden behandeld.
Dit stelt validators in staat zich meer direct te richten op uitvoering en stemming, terwijl een operationeel ontwerp mogelijk wordt gemaakt waarin werkbelastingen met verschillende kenmerken afzonderlijk worden afgehandeld. Dit stelt geen directe prestatieverbetering vast, maar benadrukt dat het scheiden van operationele verantwoordelijkheden en belastingsdomeinen de beschikbare ontwerpopties voor Validator-operaties uitbreidt.

Vooruitblik

De verifieerbare transactieordening en uitvoeringstransparantie die BAM beoogt te bieden, zijn een sleutelelement in het bevorderen van Solana naar een uitvoeringsomgeving die geschikt is voor institutioneel en zakelijk gebruik.
SLV dient als fundament om deze richting te vertalen naar praktische operaties. In de toekomst zullen validators, RPC-infrastructuur, netwerken en gedecentraliseerde applicaties niet als geisoleerde optimalisatiedoelen worden behandeld, maar als onderling afhankelijke componenten die gezamenlijk de uitvoeringskwaliteit en het vertrouwen bepalen. Via deze aanpak zal Solana's operationele infrastructuur zich blijven ontwikkelen.