Solana Virtual Machine forklaret for alle, der kun kender Bitcoin
En guide til Solana Virtual Machine for læsere, der er fortrolige med Bitcoin: kontomodel, parallel eksekvering, udviklingsværktøjer og grænserne for den kompatibilitet, som Bitcoin Hyper har annonceret.
Uddannelsesmæssigt formål. Indholdet i denne artikel tjener udelukkende informations- og forklaringsformål. Det udgør ikke finansiel rådgivning. Fuld ansvarsfraskrivelse.
Fra Bitcoin-skrivebordet til Solana-køkkenet
Bitcoin har et scriptsprog — kaldet Script — der bevidst er begrænset. Det er ikke Turing-komplet, tillader ikke løkker og kun elementære operationer: at verificere signaturer, håndtere timelocks eller opsætte multisig-ordninger. Denne enkelhed bidrager til at gøre Bitcoins adfærd forudsigelig og til at mindske eksekveringsfladen, selv om Bitcoins sikkerhed afhænger af talrige elementer i protokollen.
Ethereum har valgt en anden vej: det introducerede EVM (Ethereum Virtual Machine), et Turing-komplet miljø, hvor smart contracts kan udføres. På protokolniveau behandles tilstandsovergange efter en sekventiel model, selv om implementeringer kan parallelisere visse interne opgaver.
Solana har svaret på skalerbarhedsudfordringen med en radikalt anderledes arkitektur: SVM (Solana Virtual Machine) og Sealevel-runtimen.
Solanas kontomodel (og SVM)
På Ethereum « ejer » en smart contract sin tilstand: dataene ligger i selve kontrakten. I SVM er designet afkoblet:
- - Koden ligger i en programkonto; dens opdaterbarhed afhænger af udrulningsmekanismen og den konfigurerede autoritet
- - Dataene (tilstanden) ligger i separate konti, der styres af programmet
Det gør Sealevel i stand til at analysere transaktioner på forhånd: hvis transaktion A vedrører kontiene {X, Y} og transaktion B kontiene {Z, W}, kan begge udføres parallelt og uden konflikt.
Denne model gør det muligt at udføre transaktioner, der ikke gør krav på de samme konti, parallelt. Det kan øge gennemløbet, men tillader ikke i sig selv at udlede en kvantitativ fordel i forhold til EVM ved tilsvarende hardware. Der er ikke offentliggjort nogen Bitcoin Hyper-specifik ydelsestest.
Hvad det betyder for udviklere
Programmer til SVM skrives i Rust (eller i C/C++) og kompileres til eBPF-bytekode. Et udbredt framework er Anchor, som tilføjer makroer og konventioner for at lette udviklingen.
Bitcoin Hypers dokumentation angiver som mål en umiddelbar kompatibilitet, eller « drop-in-kompatibilitet », med Solana-økosystemet. Ifølge projektet ville et eksisterende program kunne fungere med begrænsede tilpasninger, såsom ændring af RPC-endpointet og enkelte netværksparametre. Dokumentationen forudser desuden kompatibilitet med værktøjer som Solana-CLI'en, Anchor og IDE-plugins. Den reelle grad af kompatibilitet mangler endnu at blive verificeret uafhængigt.
Hvis denne grad af kompatibilitet blev opnået, kunne den sænke adgangsbarrieren for udviklere, der er fortrolige med Solana. Den fælles anvendelse af et SVM-baseret miljø garanterer dog ikke i sig selv kompatibiliteten af programmerne, API'erne, systemprogrammerne, værktøjerne eller runtimens adfærd. Der er stadig tale om et designmål og ikke om et uafhængigt verificeret resultat.
Hvad der endnu skal afklares
Alligevel skal flere punkter nævnes åbent:
- Den fulde kompatibilitet er ikke verificeret uafhængigt: Devnettet er selektivt, og de offentlige tests er begrænsede
- Forskelle i omkostningsmodellen: ifølge projektdokumentationen bruger Bitcoin Hyper $HYPER til gebyrerne i stedet for SOL, hvorved nogle abstraktioner adskiller sig
- Afhængigheder af Solanas systemprogrammer: nogle Solana-applikationer bygger på systemprogrammer (såsom det officielle Token Program), der muligvis ikke er tilgængelige i identisk form
Påstanden om en « drop-in »-kompatibilitet skal fortsat verificeres. En vurdering heraf kræver offentlig teknisk dokumentation, tilstrækkelig adgang til Devnettet og reproducerbare tests, der omfatter programmerne, værktøjerne og systemafhængighederne.
Franchise-analogien
Man kan forestille sig SVM som køkkenet i en franchiserestaurant. Opskriften står for koden, og lokalet står for det netværk, den udføres på. Bitcoin Hyper ønsker at tilbyde udstyr, der er kompatibelt med Solanas, men det er endnu ikke påvist, at alle komponenter er identiske, eller at resultatet er det samme i alle tilfælde.
Forskellen ligger i hovedingrediensen: i stedet for SOL som køkkenets « brændstof » ville $HYPER blive brugt her.