Solana Virtual Machine w ujęciu dla użytkowników Bitcoina
Przewodnik po Solana Virtual Machine dla czytelników znających Bitcoina: model kont, wykonywanie równoległe, narzędzia deweloperskie i granice zgodności deklarowanej przez Bitcoin Hyper.
Cel edukacyjny. Treść tego artykułu ma charakter wyłącznie informacyjny i wyjaśniający. Nie stanowi porady finansowej. Pełne zastrzeżenia prawne.
Od warsztatu Bitcoina do kuchni Solany
Bitcoin dysponuje językiem skryptowym — Script — który został celowo ograniczony. Nie jest Turing-zupełny, nie pozwala na pętle i dopuszcza wyłącznie podstawowe operacje: weryfikację podpisów, obsługę blokad czasowych (timelock) oraz tworzenie układów wielopodpisowych (multisig). Ta prostota sprawia, że zachowanie Bitcoina jest przewidywalne, a także zmniejsza powierzchnię wykonania — choć jego bezpieczeństwo zależy od wielu elementów protokołu.
Ethereum poszedł inną drogą: wprowadził EVM (Ethereum Virtual Machine) — Turing-zupełne środowisko, w którym można wykonywać smart kontrakty. Na poziomie protokołu przejścia stanu odbywają się według modelu sekwencyjnego, choć konkretne implementacje mogą częściowo zrównoleglać zadania wewnętrzne.
Solana odpowiedziała na wyzwanie skalowalności radykalnie odmienną architekturą: SVM (Solana Virtual Machine) oraz środowiskiem wykonawczym Sealevel.
Model kont Solany (i SVM)
W Ethereum stan „należy” do smart kontraktu — dane znajdują się bezpośrednio w nim samym. W SVM architektura jest rozprzężona:
- - Kod rezyduje na koncie programu; możliwość jego aktualizacji zależy od mechanizmu wdrożenia oraz wyznaczonego podmiotu uprawnionego (authority)
- - Dane (stan) znajdują się na osobnych kontach kontrolowanych przez program
Dzięki temu Sealevel może analizować transakcje z wyprzedzeniem: jeśli transakcja A dotyczy kont {X, Y}, a transakcja B — kont {Z, W}, obie mogą zostać wykonane równolegle i bez konfliktu.
Taki model umożliwia równoległe wykonywanie transakcji, które nie dotyczą tych samych kont. Może to zwiększać przepustowość, lecz samo w sobie nie uzasadnia żadnych wniosków o ilościowej przewadze nad EVM na porównywalnym sprzęcie. Dla Bitcoin Hyper nie opublikowano dotąd żadnego konkretnego testu wydajności.
Co to oznacza dla deweloperów
Programy SVM pisze się w Rust (lub C/C++), a następnie kompiluje do bajtkodu eBPF. Popularnym frameworkiem jest Anchor, który dodaje makra i konwencje ułatwiające programowanie.
Dokumentacja Bitcoin Hyper stawia sobie za cel bezpośrednią zgodność z ekosystemem Solany, określaną jako „drop-in compatibility”. Według projektu istniejący program mógłby działać po ograniczonych zmianach — na przykład po zmianie punktu końcowego RPC i kilku parametrów sieciowych. Dokumentacja zakłada również zgodność z narzędziami takimi jak Solana CLI, Anchor czy wtyczki IDE. Rzeczywisty stopień zgodności pozostaje do niezależnego zweryfikowania.
Gdyby taki stopień zgodności rzeczywiście udało się osiągnąć, mógłby on obniżyć próg wejścia dla deweloperów znających Solanę. Samo współdzielenie środowiska opartego na SVM nie gwarantuje jednak zgodności programów, API, programów systemowych, narzędzi ani zachowania środowiska wykonawczego. Pozostaje to raczej celem projektowym niż niezależnie zweryfikowanym rezultatem.
Co pozostaje do wyjaśnienia
Mimo to warto otwarcie wskazać kilka kwestii:
- Pełna zgodność nie została niezależnie zweryfikowana: Devnet ma charakter selektywny, a testy publiczne są ograniczone
- Różnice w modelu opłat: według dokumentacji projektu Bitcoin Hyper do pobierania opłat wykorzystuje $HYPER zamiast SOL, co oznacza, że część abstrakcji jest odmienna
- Zależności od programów systemowych Solany: część aplikacji Solany opiera się na programach systemowych (takich jak oficjalny Token Program), które mogą nie być dostępne w identycznej formie
Twierdzenie o zgodności typu „drop-in” pozostaje do zweryfikowania. Jego ocena wymaga publicznej dokumentacji technicznej, wystarczającego dostępu do Devnetu oraz powtarzalnych testów obejmujących programy, narzędzia i zależności systemowe.
Analogia z franczyzą
SVM można sobie wyobrazić jako kuchnię restauracji działającej we franczyzie. Przepis odpowiada kodowi, a lokal — sieci, w której ten kod działa. Bitcoin Hyper dąży do zaoferowania narzędzi zgodnych z Solaną; nie wykazano jednak dotąd, że wszystkie elementy są identyczne ani że wynik jest taki sam w każdym przypadku.
Różnica tkwi w głównym składniku: zamiast SOL, „paliwem” tej kuchni miałby być $HYPER.