Van het Bitcoin-bureau naar de Solana-keuken

Bitcoin beschikt over een scripttaal — Script genaamd — die bewust beperkt is. Ze is niet Turing-volledig, staat geen lussen toe en laat alleen elementaire bewerkingen toe: handtekeningen controleren, timelocks beheren of multisig-schema's opzetten. Deze eenvoud draagt eraan bij het gedrag van Bitcoin voorspelbaar te maken en het uitvoeringsoppervlak te verkleinen, ook al hangt de beveiliging van Bitcoin af van talrijke elementen van het protocol.

Ethereum heeft een andere weg gekozen: het introduceerde de EVM (Ethereum Virtual Machine), een Turing-volledige omgeving waarin smart contracts kunnen worden uitgevoerd. Op protocolniveau worden toestandsovergangen volgens een sequentieel model verwerkt, ook al kunnen implementaties bepaalde interne taken parallelliseren.

Solana heeft op de uitdaging van schaalbaarheid geantwoord met een radicaal andere architectuur: de SVM (Solana Virtual Machine) en de Sealevel-runtime.

Het rekeningmodel van Solana (en de SVM)

Op Ethereum « bezit » een smart contract zijn toestand: de data bevindt zich in het contract zelf. In de SVM is het ontwerp ontkoppeld:

- De code bevindt zich in een programmarekening; de bijwerkbaarheid ervan hangt af van het uitrolmechanisme en de geconfigureerde autoriteit
- De data (de toestand) bevindt zich in aparte rekeningen die door het programma worden gecontroleerd

Dat stelt Sealevel in staat transacties vooraf te analyseren: als transactie A betrekking heeft op de rekeningen {X, Y} en transactie B op de rekeningen {Z, W}, kunnen beide parallel en zonder conflict worden uitgevoerd.

Dit model maakt het mogelijk transacties die niet dezelfde rekeningen claimen parallel uit te voeren. Het kan de doorvoer verhogen, maar laat op zichzelf niet toe een kwantitatief voordeel ten opzichte van de EVM bij gelijkwaardige hardware af te leiden. Er is geen Bitcoin Hyper-specifieke prestatietest gepubliceerd.

Wat dat voor ontwikkelaars betekent

Programma's voor de SVM worden geschreven in Rust (of in C/C++) en gecompileerd naar eBPF-bytecode. Een veelgebruikt framework is Anchor, dat macro's en conventies toevoegt om de ontwikkeling te vergemakkelijken.

De documentatie van Bitcoin Hyper noemt als doel een onmiddellijke compatibiliteit, of « drop-in-compatibiliteit », met het Solana-ecosysteem. Volgens het project zou een bestaand programma met beperkte aanpassingen kunnen functioneren, zoals het wijzigen van het RPC-endpoint en enkele netwerkparameters. De documentatie voorziet bovendien in compatibiliteit met tools zoals de Solana-CLI, Anchor en IDE-plugins. De werkelijke mate van compatibiliteit moet nog onafhankelijk worden geverifieerd.

Zou deze mate van compatibiliteit worden bereikt, dan zou die de instapdrempel kunnen verlagen voor ontwikkelaars die vertrouwd zijn met Solana. Het gedeelde gebruik van een op de SVM gebaseerde omgeving garandeert op zichzelf echter niet de compatibiliteit van de programma's, de API's, de systeemprogramma's, de tools of het gedrag van de runtime. Het gaat nog om een ontwerpdoel en niet om een onafhankelijk geverifieerd resultaat.

Wat nog moet worden opgehelderd

Toch moeten verschillende punten transparant worden benoemd:

De volledige compatibiliteit is niet onafhankelijk geverifieerd: het Devnet is selectief en de openbare tests zijn beperkt
Verschillen in het kostenmodel: volgens de projectdocumentatie gebruikt Bitcoin Hyper $HYPER voor de kosten in plaats van SOL, waardoor sommige abstracties verschillen
Afhankelijkheden van de systeemprogramma's van Solana: sommige Solana-toepassingen steunen op systeemprogramma's (zoals het officiële Token Program) die mogelijk niet in identieke vorm beschikbaar zijn

De bewering van een « drop-in »-compatibiliteit moet nog worden geverifieerd. De beoordeling ervan vereist openbare technische documentatie, voldoende toegang tot het Devnet en reproduceerbare tests die betrekking hebben op de programma's, de tools en de systeemafhankelijkheden.

De franchise-analogie

Je kunt je de SVM voorstellen als de keuken van een franchiserestaurant. Het recept staat voor de code en het pand staat voor het netwerk waarop die wordt uitgevoerd. Bitcoin Hyper wil een uitrusting aanbieden die compatibel is met die van Solana, maar het is nog niet aangetoond dat alle componenten identiek zijn of dat het resultaat in alle gevallen hetzelfde is.

Het verschil zit in het hoofdingrediënt: in plaats van SOL als « brandstof » van de keuken zou hier $HYPER worden gebruikt.

De Solana Virtual Machine, uitgelegd voor iedereen die alleen Bitcoin kent