Solana Virtual Machine (SVM) to środowisko wykonawcze, które przetwarza programy  Solana i stosuje ich zmiany stanu w całej sieci. Programy kompilują się do formatu Solana Bytecode Format, czyli sBPF, i działają w środowisku uruchomieniowym objętym piaskownicą. Transakcje wskazują programy, które wywołują, oraz konta, które każda instrukcja może odczytywać lub zapisywać, dostarczając środowisku wykonawczemu informacji potrzebnych do wczytania stanu i zaplanowania zgodnych zadań.

SVM oddziela wykonywalny kod programu od modyfikowalnych danych kont i używa jednostek obliczeniowych do pomiaru zużycia zasobów. Model ten wspiera równoległe środowisko uruchomieniowe Sealevel w Solana, ponieważ transakcje, które nie żądają konfliktowych kont z prawem zapisu, mogą być przetwarzane współbieżnie. SVM to warstwa wykonawcza, a nie mechanizm konsensusu Solana, klient walidatora ani zegar Proof of History.

Czym jest Solana Virtual Machine?

Solana Virtual Machine (SVM) to środowisko wykonawcze, które uruchamia programy  kontraktów inteligentnych i przetwarza instrukcje transakcji w Solana. W przeciwieństwie do systemów, w których kontrakt inteligentny przechowuje własny stan, Solana oddziela kod programu od kont danych. Transakcje określają, które programy i konta będą używane, co pozwala sieci przetwarzać niezależne transakcje równolegle.

Termin SVM może również odnosić się do środowisk wykonawczych kompatybilnych z Solana, używanych przez inne sieci blockchain. Sieci te mogą obsługiwać podobne programy i narzędzia dla deweloperów, jednocześnie stosując inne mechanizmy konsensusu, sekwencjonowania,  dostępności danych lub rozliczania. Zgodność z SVM opisuje zatem środowisko wykonawcze, a nie model bezpieczeństwa bazowej sieci.

Jak działa Solana Virtual Machine?

Solana Virtual Machine przetwarza każdą transakcję, korzystając z programów i kont wymienionych w tej transakcji.

1. Wczytaj wymagane konta: SVM identyfikuje płatnika opłaty, sygnatariuszy, konta z prawem zapisu oraz programy potrzebne transakcji.

2. Wykonaj instrukcje: Instrukcje są wykonywane w kolejności przez odpowiednie programy Solana, które w razie potrzeby mogą również wywoływać inne programy.

3. Zastosuj uprawnienia i limity: Środowisko wykonawcze sprawdza własność kont, uprawnienia sygnatariuszy, dostęp z prawem zapisu oraz limity jednostek obliczeniowych podczas wykonania.

4. Zweryfikuj wynik: Po wykonaniu SVM potwierdza, że salda i dane kont są zgodne z regułami protokołu Solana.

5. Zatwierdź transakcję: Jeśli każda instrukcja zakończy się sukcesem, zmiany stanu są zapisywane razem. Jeśli jedna zawiedzie, transakcja nie aktualizuje częściowo stanu aplikacji.

Ponieważ transakcje deklarują, do których kont uzyskują dostęp, Solana może równolegle wykonywać transakcje korzystające z różnych kont, co pomaga sieci obsługiwać większą przepustowość.

Jakie są główne korzyści i zastosowania SVM?

SVM jest projektowany dla aplikacji, które wymagają przewidywalnego wykonania programu i mogą skorzystać z jawnego dostępu do kont. Jego wydajność zależy zarówno od projektu środowiska wykonawczego, jak i od tego, czy transakcje konkurują o ten sam stan z prawem zapisu.

1. Zadeklarowany dostęp do kont umożliwia równoległe planowanie. Transakcje wymieniają potrzebne konta przed wykonaniem, co pozwala planiście uruchamiać niekolidujące transakcje na różnych rdzeniach procesora, chroniąc współdzielony stan z prawem zapisu.

2. Programy i stan pozostają oddzielone. Jeden bezstanowy program może działać na wielu kontach danych, co wspiera wielokrotnie używalną logikę aplikacji i pozwala deweloperom organizować stan pod kątem współbieżności, zamiast powielać kod.

3. Transakcje atomowe mogą łączyć kilka instrukcji. Transakcja może kolejno wywoływać wiele programów i albo zatwierdzić wszystkie udane zmiany stanu razem, albo odrzucić całą transakcję, gdy jedna instrukcja zawiedzie.

4. Jednostki obliczeniowe czynią zużycie zasobów jawnym. Środowisko wykonawcze mierzy pracę programu i pozwala transakcjom żądać odpowiedniego budżetu, co pomaga walidatorom ograniczać wykonanie, a użytkownikom wyrażać priorytet poprzez mechanizmy opłat w sieci.

Jakie są przykłady programów i sieci SVM?

Technologia SVM występuje w aplikacjach Solana oraz w sieciach, które wykorzystują wykonanie kompatybilne z Solana. Przykłady różnią się pod względem rozliczania i infrastruktury, więc sama zgodność z SVM nie czyni ich tą samą siecią.

• Programy natywne Solana. System Program tworzy konta, natomiast programy vote, stake, compute-budget i address-lookup-table zapewniają podstawowe funkcje bezpośrednio obsługiwane przez środowisko wykonawcze Solana.

• Programy aplikacyjne Solana. DEX-y, rynki pożyczkowe, platformy NFT i gry wdrażają programy sBPF, które działają na kontach użytkowników, rynków, skarbców, mint i pozycji dostarczanych z każdą instrukcją.

• Wykonanie Eclipse. Eclipse używa środowiska wykonawczego opartego na SVM, rozliczając się przez infrastrukturę związaną z  Ethereum, co ilustruje, jak środowisko wykonawcze może działać w innym modularnym stosie  blockchain.

• Lokalne narzędzia testowe SVM. Narzędzia takie jak LiteSVM odtwarzają odpowiednie zachowanie środowiska wykonawczego na potrzeby tworzenia i testów, bez konieczności wysyłania przez każdy przypadek testowy transakcji do działającego klastra walidatorów.

Jakie są ograniczenia i ryzyka SVM?

Model wydajności SVM tworzy określone ograniczenia projektowe. Deweloperzy muszą dokładnie deklarować konta, ograniczać niepotrzebne konflikty i mieścić się w limitach środowiska wykonawczego, podczas gdy użytkownicy nadal ponoszą zwykłe ryzyko związane z kontraktami inteligentnymi i transakcjami.

1. Współdzielone konta z prawem zapisu mogą ograniczać równoległość. Transakcje wymagające tego samego konta z prawem zapisu nie mogą bezpiecznie działać razem, więc popularne globalne konto stanu może stać się wąskim gardłem aplikacji mimo równoległego środowiska wykonawczego.

2. Programy wymagają wiedzy o tworzeniu na Solana. Deweloperzy muszą rozumieć kompilację sBPF, własność kont, adresy pochodne programów, wywołania między programami, budżety obliczeniowe i wymagania dotyczące kont związane z rent.

3. Limity obliczeniowe i limit kont mogą odrzucać złożone wywołania. Transakcja może się nie powieść, gdy przekroczy budżet obliczeniowy, odwoła się do zbyt wielu zasobów, nieprawidłowo zwiększy dane konta lub osiągnie ograniczenia głębokości wywołań i środowiska wykonawczego.

4. Zgodność z SVM nie równa się bezpieczeństwu Solana. Oddzielny łańcuch SVM może używać innych walidatorów, mostów, sekwencerów, dostępności danych lub mechanizmów kontroli aktualizacji, tworząc założenia zaufania niezwiązane z bajtkodem wykonawczym.

Czym SVM różni się od EVM?

SVM różni się od EVM głównie modelem kont, bajtkodem i podejściem do współbieżności. Transakcje Solana deklarują dostęp do kont przed wykonaniem, a programy działają na oddzielnych kontach stanu, co pozwala środowisku Sealevel planować niekolidującą pracę równolegle. Kontrakty Ethereum zwykle przechowują kod i pamięć trwałą pod tym samym adresem, a tradycyjne  wykonanie EVM przebiega zgodnie z uporządkowaną sekwencją transakcji. Oba środowiska wymagają deterministycznych wyników na węzłach walidujących, ale ich narzędzia dla deweloperów, pomiar opłat, układy stanu i standardy zgodności są różne.

Powiązane pojęcia

1. Czym jest kontrakt inteligentny?

2. Czym jest Gas?

3. Czym jest walidator?

4. Czym jest blockchain?

Dalsza lektura

1. Najlepsze projekty Solana Virtual Machine (SVM) w 2025 roku?

2. Czym jest Eclipse (ES), pierwsza warstwa 2 na Ethereum wykorzystująca SVM?

3. Czym jest Solscan i jak korzystać z eksploratora blockchaina Solana?

4. Solana vs. Ethereum: analiza porównawcza