Solana Virtual Machine tiems, kurie pažįsta tik Bitcoin

Nuo Bitcoin raštinės iki Solana virtuvės

Bitcoin turi sąmoningai apribotą scenarijų kalbą, vadinamą Script. Ji nėra Tiuringo užbaigta, neleidžia ciklų ir leidžia tik elementarias operacijas: tikrinti parašus, kontroliuoti timelock arba nustatyti multisig schemas. Šis paprastumas padeda išlaikyti nuspėjamą veikimą ir sumažina vykdymo paviršių, nors Bitcoin saugumas priklauso nuo daugelio protokolo elementų.

Ethereum pasirinko kitą kelią: jis įvedė EVM (Ethereum Virtual Machine) — Tiuringo užbaigtą aplinką, kurioje galima vykdyti smart contract programas. Protokolo lygmeniu būklės perėjimai apdorojami pagal nuoseklų modelį, nors realizacijos gali paraleliai vykdyti kai kurias vidines užduotis.

Solana į mastelio problemą atsakė iš esmės kitokia architektūra: SVM (Solana Virtual Machine) ir Sealevel vykdymo aplinka.

Solana (ir SVM) paskyrų modelis

Ethereum tinkle smart contract „valdo“ savo būklę: duomenys saugomi pačioje sutartyje. SVM atveju architektūra yra atskirta:

• - Kodas saugomas programos paskyroje; jo atnaujinimo galimybė priklauso nuo įdiegimo mechanizmo ir nustatytos valdymo teisės
• - Duomenys (būklė) saugomi atskirose paskyrose, kurias kontroliuoja programa

Tai leidžia Sealevel iš anksto analizuoti operacijas: jei operacija A susijusi su paskyromis {X, Y}, o operacija B — su paskyromis {Z, W}, abi gali būti vykdomos paraleliai be konflikto.

Šis modelis leidžia paraleliai vykdyti operacijas, kurios nesikreipia į tas pačias paskyras. Jis gali padidinti pralaidumą, tačiau vien iš jo negalima daryti išvados apie kiekybinį pranašumą prieš EVM naudojant lygiavertę techninę įrangą. Jokių Bitcoin Hyper skirtų veikimo testų nebuvo paskelbta.

Ką tai reiškia kūrėjams

SVM skirtos programos rašomos Rust kalba (arba C/C++) ir kompiliuojamos į eBPF baitkodą. Plačiai naudojamas karkasas yra Anchor, kuris papildo makrokomandomis ir konvencijomis, palengvinančiomis kūrimą.

Bitcoin Hyper dokumentacijoje kaip tikslas pateikiamas iškart veikiantis suderinamumas, arba „drop-in compatibility“, su Solana ekosistema. Pagal projekto pateiktą informaciją, esama programa galėtų veikti su nedideliais pritaikymais, pavyzdžiui, pakeitus RPC endpoint ir kai kuriuos tinklo parametrus. Dokumentacijoje taip pat numatytas suderinamumas su priemonėmis, tokiomis kaip Solana CLI, Anchor ir IDE įskiepiai. Faktinį suderinamumo lygį dar reikia nepriklausomai patikrinti.

Jei toks suderinamumo lygis būtų pasiektas, jis galėtų sumažinti įėjimo barjerą Solana pažįstantiems kūrėjams. Tačiau vien bendra SVM pagrindu veikianti aplinka negarantuoja programų, API, sistemos programų, priemonių ar vykdymo aplinkos elgesio suderinamumo. Tai vis dar architektūrinis tikslas, o ne nepriklausomai patikrintas rezultatas.

Kas dar turi būti išsiaiškinta

Kartu reikia skaidriai nurodyti kelis aspektus:

1. Visapusiškas suderinamumas nebuvo nepriklausomai patikrintas: DevNet prieiga yra atrankinė, o vieši testai riboti
2. Mokesčių modelio skirtumai: pagal projekto dokumentaciją, Bitcoin Hyper mokesčiams naudoja $HYPER, o ne SOL, todėl kai kurios abstrakcijos skiriasi
3. Priklausomybė nuo Solana sistemos programų: kai kurios Solana programos remiasi sistemos programomis (pavyzdžiui, oficialiu Token Program), kurios gali būti neprieinamos tokia pačia forma

Tvirtinimą apie „drop-in“ suderinamumą dar reikia patikrinti. Jo vertinimui būtina vieša techninė dokumentacija, pakankama prieiga prie DevNet ir atkuriami testai, apimantys programas, priemones ir sistemos priklausomybes.

Franšizės analogija

SVM galima įsivaizduoti kaip franšizinio restorano virtuvę. Receptas atitinka kodą, o įstaiga — tinklą, kuriame jis vykdomas. Bitcoin Hyper ketina pasiūlyti su Solana suderinamą įrangą, tačiau dar neįrodyta, kad visi komponentai yra identiški ir kad rezultatas visais atvejais bus toks pat.

Skirtumas — pagrindinė sudedamoji dalis: užuot virtuvės „kuru“ naudojus SOL, čia būtų naudojamas $HYPER.