Från Bitcoin-skrivbordet till Solana-köket

Bitcoin har ett skriptspråk — kallat Script — som medvetet är begränsat. Det är inte Turing-komplett, tillåter inte loopar och endast elementära operationer: att verifiera signaturer, hantera timelocks eller upprätta multisig-lösningar. Denna enkelhet bidrar till att göra Bitcoins beteende förutsägbart och till att minska exekveringsytan, även om Bitcoins säkerhet beror på talrika element i protokollet.

Ethereum har valt en annan väg: det introducerade EVM (Ethereum Virtual Machine), en Turing-komplett miljö där smarta kontrakt kan utföras. På protokollnivå behandlas tillståndsövergångar enligt en sekventiell modell, även om implementeringar kan parallellisera vissa interna uppgifter.

Solana har svarat på skalbarhetsutmaningen med en radikalt annorlunda arkitektur: SVM (Solana Virtual Machine) och Sealevel-runtimen.

Solanas kontomodell (och SVM)

På Ethereum « äger » ett smart kontrakt sitt tillstånd: datan ligger i själva kontraktet. I SVM är designen frikopplad:

- Koden ligger i ett programkonto; dess uppdaterbarhet beror på utrullningsmekanismen och den konfigurerade auktoriteten
- Datan (tillståndet) ligger i separata konton som styrs av programmet

Det gör Sealevel i stånd att analysera transaktioner i förväg: om transaktion A berör kontona {X, Y} och transaktion B kontona {Z, W} kan båda utföras parallellt och utan konflikt.

Denna modell gör det möjligt att utföra transaktioner som inte gör anspråk på samma konton parallellt. Det kan öka genomströmningen, men tillåter inte i sig att härleda en kvantitativ fördel jämfört med EVM vid motsvarande hårdvara. Ingen Bitcoin Hyper-specifik prestandatest har publicerats.

Vad det betyder för utvecklare

Program för SVM skrivs i Rust (eller i C/C++) och kompileras till eBPF-bytekod. Ett utbrett framework är Anchor, som lägger till makron och konventioner för att underlätta utvecklingen.

Bitcoin Hypers dokumentation anger som mål en omedelbar kompatibilitet, eller « drop-in-kompatibilitet », med Solana-ekosystemet. Enligt projektet skulle ett befintligt program kunna fungera med begränsade anpassningar, såsom ändring av RPC-endpointen och enstaka nätverksparametrar. Dokumentationen förutser dessutom kompatibilitet med verktyg som Solana-CLI:n, Anchor och IDE-plugins. Den reella graden av kompatibilitet återstår ännu att verifiera oberoende.

Om denna grad av kompatibilitet uppnåddes skulle den kunna sänka tröskeln för utvecklare som är förtrogna med Solana. Den gemensamma användningen av en SVM-baserad miljö garanterar dock inte i sig kompatibiliteten hos programmen, API:erna, systemprogrammen, verktygen eller runtimens beteende. Det rör sig fortfarande om ett designmål och inte om ett oberoende verifierat resultat.

Vad som ännu återstår att klargöra

Ändå bör flera punkter nämnas öppet:

Den fullständiga kompatibiliteten är inte oberoende verifierad: Devnetet är selektivt, och de offentliga testerna är begränsade
Skillnader i kostnadsmodellen: enligt projektdokumentationen använder Bitcoin Hyper $HYPER till avgifterna i stället för SOL, varvid vissa abstraktioner skiljer sig åt
Beroenden av Solanas systemprogram: vissa Solana-applikationer bygger på systemprogram (såsom det officiella Token Program) som möjligen inte är tillgängliga i identisk form

Påståendet om en « drop-in »-kompatibilitet återstår att verifiera. En bedömning av detta kräver offentlig teknisk dokumentation, tillräcklig åtkomst till Devnetet och reproducerbara tester som omfattar programmen, verktygen och systemberoendena.

Franchiseanalogin

Man kan föreställa sig SVM som köket i en franchiserestaurang. Receptet motsvarar koden, och lokalen motsvarar det nätverk som den utförs på. Bitcoin Hyper vill erbjuda utrustning som är kompatibel med Solanas, men det har ännu inte påvisats att alla komponenter är identiska eller att resultatet är detsamma i samtliga fall.

Skillnaden ligger i huvudingrediensen: i stället för SOL som kökets « bränsle » skulle $HYPER användas här.

Solana Virtual Machine förklarad för alla som bara känner till Bitcoin