Od Bitcoinove delovne mize do Solanine kuhinje

Bitcoin ima skriptni jezik — imenovan Script — ki je namerno omejen. Ni Turingovsko poln, ne dopušča zank in omogoča le osnovne operacije: preverjanje podpisov, obravnavo časovnih zapor (timelock) ali sestavljanje večpodpisnih (multisig) rešitev. Ta preprostost pomaga narediti vedenje Bitcoina predvidljivo in zmanjšati izvajalno površino, čeprav je varnost Bitcoina odvisna od številnih sestavnih delov protokola.

Ethereum je izbral drugo pot: predstavil je EVM (Ethereum Virtual Machine), Turingovsko polno okolje, v katerem je mogoče izvajati pametne pogodbe. Na ravni protokola se prehodi stanja obravnavajo po zaporednem modelu, čeprav lahko izvedbe nekatere notranje naloge izvajajo vzporedno.

Solana je na izziv skalabilnosti odgovorila z radikalno drugačno arhitekturo: SVM (Solana Virtual Machine) in izvajalno okolje Sealevel.

Solanin model računov (in SVM)

V Ethereumu pametna pogodba « ima v lasti » svoje stanje: podatki se nahajajo v sami pogodbi. V SVM je zasnova ločena:

- Koda se nahaja na programskem računu; njena posodobljivost je odvisna od mehanizma uvedbe in določene avtoritete
- Podatki (stanje) se nahajajo na ločenih računih, ki jih upravlja program

To Sealevelu omogoča, da transakcije analizira vnaprej: če transakcija A zadeva računa {X, Y}, transakcija B pa računa {Z, W}, ju je mogoče izvesti vzporedno in brez konflikta.

Ta model omogoča vzporedno izvajanje tistih transakcij, ki ne posegajo v iste račune. Lahko poveča prepustnost, vendar sam po sebi ne dopušča sklepanja o količinski prednosti pred EVM na primerljivi strojni opremi. Za Bitcoin Hyper ni bil objavljen noben poseben test zmogljivosti.

Kaj to pomeni za razvijalce

Programi za SVM se pišejo v Rustu (ali C/C++) in se prevedejo v bajtno kodo eBPF. Široko uporabljano ogrodje je Anchor, ki dodaja makre in konvencije za lažji razvoj.

Dokumentacija Bitcoin Hyperja si za cilj postavlja neposredno združljivost oziroma « drop-in združljivost » z ekosistemom Solane. Po navedbah projekta bi obstoječi program lahko deloval z omejenimi spremembami, na primer s spremembo končne točke RPC (RPC endpoint) in posameznih omrežnih parametrov. Dokumentacija poleg tega predvideva združljivost z orodji, kot so Solana CLI, Anchor in vtičniki za IDE. Dejansko stopnjo združljivosti je treba še neodvisno preveriti.

Če bi to stopnjo združljivosti dosegli, bi lahko znižala vstopni prag za razvijalce, ki poznajo Solano. Skupna uporaba okolja, ki temelji na SVM, pa sama po sebi ne jamči združljivosti programov, API-jev, sistemskih programov, orodij ali vedenja izvajalnega okolja (runtime). Gre še vedno za cilj zasnove in ne za neodvisno preverjen rezultat.

Kaj je treba še razjasniti

Kljub temu velja odkrito omeniti več okoliščin:

Popolna združljivost ni bila neodvisno preverjena: Devnet je selektiven, javni testi pa so omejeni
Razlike v stroškovnem modelu: po projektni dokumentaciji Bitcoin Hyper za plačila uporablja $HYPER namesto SOL, zaradi česar se nekatere abstrakcije razlikujejo
Odvisnosti od Solaninih sistemskih programov: nekatere aplikacije na Solani temeljijo na sistemskih programih (kot je uradni Token Program), ki morda niso na voljo v enaki obliki

Trditev o « drop-in » združljivosti je treba še preveriti. Njena ocena zahteva javno tehnično dokumentacijo, zadosten dostop do Devneta in ponovljive teste, ki zajemajo programe, orodja in sistemske odvisnosti.

Analogija s franšizo

SVM si lahko predstavljamo kot kuhinjo franšizne restavracije. Recept ustreza kodi, poslovni prostor pa omrežju, v katerem se ta izvaja. Bitcoin Hyper želi ponuditi orodja, združljiva s Solano, vendar še ni dokazano, da so vse komponente identične ali da je rezultat enak v vseh primerih.

Razlika je v glavni surovini: namesto SOL bi se kot « gorivo » kuhinje tukaj uporabljal $HYPER.

Solana Virtual Machine, pojasnjen vsem, ki poznajo le Bitcoin