Solana Virtual Machine, selgitatuna Bitcoini kasutajatele
Miks teeb Bitcoin Hyper ettepaneku kasutada täitmiskeskkonnana Solana Virtual Machine'i? Juhend lugejale, kes tunneb Bitcoini, kuid puutub nutilepingutega kokku esimest korda.
Hariv eesmärk. Selle artikli sisu on esitatud üksnes teavitus- ja selgituseesmärgil. See ei kujuta endast finantsnõustamist. Täielik vastutusest loobumine.
Bitcoini kirjutuslaualt Solana kööki
Bitcoinil on skriptikeel — selle nimi on Script — ja see on teadlikult piiratud. See ei ole Turingi mõttes täielik, ei toeta tsükleid ja lubab üksnes elementaarseid toiminguid: allkirjade kontrollimist, ajalukkude kontrollimist, mitme allkirjaga lahenduste seadistamist. Just see lihtsus teebki selle turvaliseks ja etteaimatavaks.
Ethereum läks vastupidist teed: see tõi kasutusele EVM-i (Ethereum Virtual Machine), Turingi mõttes täieliku keskkonna, milles igaüks saab kirjutada suvalisi programme (nutilepinguid). Võimas, kuid ühe puudusega: täitmine on jadatöötlusega. Üks leping korraga, järjest.
Solana vastas skaleeritavuse väljakutsele radikaalselt teistsuguse arhitektuuriga: SVM (Solana Virtual Machine) ja Sealeveli käituskeskkond.
Solana (ja SVM-i) kontomudel
Ethereumis „omab“ nutileping oma olekut — andmed asuvad lepingu sees. SVM-is on see lahutatud:
- - Kood (programm) asub muutumatus kontos
- - Andmed (olek) asuvad eraldi kontodes, mida programm kontrollib
See võimaldab Sealevelil tehinguid ette analüüsida: kui tehing A puudutab kontosid {X, Y} ja tehing B kontosid {Z, W}, saab neid täita paralleelselt ilma konfliktita.
Praktiline tulemus on samaväärse riistvara juures EVM-ist märkimisväärselt suurem läbilaskevõime.
Mida see arendajate jaoks tähendab
SVM-i programmid kirjutatakse Rustis (või C/C++-s) ja kompileeritakse eBPF-baitkoodiks. Kõige laialdasemalt kasutatav raamistik on Anchor, mis lisab makrosid ja konventsioone arenduse sujuvamaks muutmiseks.
Bitcoin Hyperi deklareeritud eesmärk on kohene ühilduvus: projekti dokumentatsiooni kohaselt peaks olemasolev Solana programm Hyperis töötama minimaalsete muudatustega — vahetades RPC-lõpp-punkti ja mõned võrgu seadistused. Samad tööriistad (Solana CLI, Anchor, IDE pluginad) peaksid töötama muutmata kujul.
Kui see saavutatakse, oleks tegemist kaugeltki mitte tähtsusetu konkurentsieelisega: Solana ökosüsteemis on tuhandeid arendajaid ja suur hulk olemasolevaid programme. Nende toomine Bitcoin Hyperisse alandaks sisenemisbarjääri järsult. Praegu on see aga pigem kavandatud eesmärk kui sõltumatult kontrollitud tulemus.
Mis ei ole veel selge
Sellegipoolest tuleks mõned punktid ausalt välja öelda:
- Täielikku ühilduvust ei ole sõltumatult kontrollitud: DevNet on valikuline ja avalik testimine piiratud
- Erinevused tasumudelis: Bitcoin Hyper kasutab tasudeks $HYPERit, mitte SOLi — seetõttu erinevad mõned abstraktsioonid
- Sõltuvused Solana süsteemiprogrammidest: mõned Solana rakendused tuginevad süsteemiprogrammidele (näiteks ametlikule Token Programile), mis ei pruugi olla samal kujul saadaval
Väide „kohene ühilduvus“ väärib usalduse eeldust — kuid ka kriitilist kontrolli. Testi DevNetis, enne kui midagi eeldad. Tootmiskeskkonnas ei ole seda veel sõltumatult kontrollitud.
Frantsiisi analoogia
Mõtle SVM-ist kui frantsiisirestorani köögist. Retsept (Rusti kood) on kõikjal sama. Ruumid võivad erineda (Bitcoin Hyper Solana mainneti asemel), kuid seadmed (SVM-i käituskeskkond, Anchor) on identsed. Valmiv roog peaks olema seesama.
Erinevus peitub põhikoostisosas: SOLi asemel köögi „kütusena“ on siin $HYPER.