Solana jest blockchainem należącym do grupy” high-performance chains”, czyli łańcuchów bloków wysokiej wydajności. Od lat zyskuje na popularności kosztem Ethereum, głównie w zastosowaniach opartych o wykorzystujące go oprogramowanie jak gry, zdecentralizowane finanse oraz jeszcze niedawno w obszarze NFT. Solana przoduje również jako główna platforma do tworzenia walut typu Memecoin i to w niezliczonej ilości. Waluty te generowane w celach spekulacyjnych w zautomatyzowanych platformach przy minimalnych kosztach są często wykorzystywane przez influencerów z różnych mediów społecznościowych do uzyskania dodatkowych zarobków. Ale to margines zastosowania Solana, bo jest to blockchain i waluta o bardzo dużych możliwościach i niskich kosztach transakcji.
Blockchain Solana jest lubiany za kilka ważnych cech:
Szybkość – bloki transakcji wystawiane są co 400ms, Solana osiąga ponad 65 000 transakcji na sekundę (TPS), czyli działa dużo szybciej niż Ethereum (15-30 TPS)
Niskie koszty – opłaty są bardzo niskie, co wynika między innymi z dużej wydajności, ale również z przemyślanego modelu ekonomicznego,
Szeroki ekosystem – jest to popularna platforma do programowania nowych rozwiązań, a co za tym idzie istnieją zasoby do tworzenia nowych rozwiązań,
Niski wpływ na środowisko – (https://solana.com/pl/news/solana-energy-usage-report-november-2021) dzięki konsensusowi typu Proof of Stake i jego autorskiemu udoskonaleniu „Proof of History”.
Należy dodać, że Solana pracuje w dużym stresie czasowym, co nieraz powodowało poważne awarie i przerwy w pracy. Wysoka wydajność oznacza też duże wymagania dla serwerów walidujących. Z tych i innych względów ich utrzymanie jest bardzo kosztowne, a mimo to nie brakuje chętnych. Wszystkim tym aspektom przyjrzymy się bardzo szczegółowo.
Aspekty techniczne modelu danych w Solana
Dane w blockchain Solana są przechowywane w dość uniwersalnej strukturze kont różnego typu, które mogą przechowywać programy “smart contracts” i dane o objętości do 10MB. Każde konto ma adres w postaci klucza publicznego. Tworzy to „Solana Account Model” czyli swoisty model danych, który wykorzystywany jest przy przeprowadzania transakcji.
Oprócz standardowej opłaty transakcyjnej stosowanej w wielu sieciach, w Solana występuje również renta za przechowywanie danych w blockchain, która może zostać zwrócona po ich usunięciu. Opłaty za transakcje składają się z części stałej w wysokości 5 tys. lamportów (1 lamport = 0.000000001 SOL) oraz dodatkowej opłaty zwiększającej priorytet. W celu utrzymania niskiej inflacji 50% opłat transakcyjnych jest spalana, czyli niszczona. Podobne rozwiązanie jest stosowane w blockchain Ethereum (“Ultrasound money”). Pozostałe 50% trafia do węzła walidatora, który wypuścił blok transakcji. Tak jak w innych blockchain, przed rozpoczęciem wykonania transakcji kalkulowana jest opłata i jeżeli saldo adresu konta przypisanego do transakcji jest wystarczające, transakcja dochodzi do skutku. W przypadku wystąpienia błędów w konstrukcji transakcji opłata za nią zostanie zawsze pobrana, na przykład w przypadku niewystarczających środków do dokonania zadeklarowanego transferu.
Solana jest wyposażona w mechanizm odśmiecania pamięci (ang. “garbage collection”). Kiedy konto z danymi ma balans 0 lamportów lub jest niewystarczająca ich ilość dla określonej ilości danych, zostanie usunięte z blockchain, a ślad po nim może pozostać jedynie w transakcjach. Jest to spora różnica w stosunku do innych blockchainów, gdzie dane pozostają praktycznie na zawsze, ale też transakcje związane z tworzeniem smartkontraktów z dużą ilością kodu z osadzonymi danymi (np. grafikami) są niezwykle kosztowne. Należy pamiętać, że dane z łańcucha bloków są replikowane pomiędzy węzłami walidującymi i każdy z nich musi przeznaczyć zasoby na pobranie i przechowanie tych samych danych. Ponieważ transakcji jest bardzo dużo, przechowywanie danych w blockchain powoduje szybkie zwiększanie się rozmiaru pliku z danymi, a dokładanie tam jakichkolwiek grafik czy dźwięku jest bardzo obciążające i mało efektywne. Autorzy treści będą zawsze dążyć do umieszczenia swoich dzieł on-chain, aby nabrały w ten sposób jeszcze bardziej unikatowego charakteru i były praktycznie wieczne. Prowadzi to jednak do zaśmiecenia łańcucha bloków, zwiększania kosztów zwykłych transakcji i zwiększania kosztów dla walidatorów, co ostatecznie może spowodować porzucenie przez nich blockchain. Dlatego kierunek obrany przez Solana wydaje się słuszny, ale odbywa się kosztem niezmienności i wieczności tego, co zostaje zapisane w blockchain.
Podobnie jak większość nowoczesnych rozwiązań blockchain, Solana umożliwia tworzenie smartkontraktów, które pozwalają wprowadzać nowe ogólnodostępne usługi i złożone funkcje przez użytkowników i deweloperów. W Solana rozszerzenia te noszą nazwę programów (ang. Programs) i są przechowywane w jednym z rodzajów kont wymienionych w Solana account Model. Programy mogą być aktualizowane lub skonfigurowane jako niezmienne, trzeba zwracać na to uwagę w zależności od zastosowania. Programy w Solana tworzy się w języku Rust, ogólnodostępnym języku programowania, ukierunkowanym na bezpieczne zarządzanie pamięcią i niezawodność. Dla ułatwienia dostępna jest biblioteka Anchor upraszczające tworzenie programów dla typowych zastosowań. Dzięki zastosowaniu ogólnie dostępnych rozwiązań do uruchamiania programów jak ELF i ePF, możliwe będzie tworzenie programów w innych językach niż Rust.
Ważnym aspektem umieszczania programów w blockchain Solana jest ich weryfikowalność. W danych konta z programem umieszczany jest bytecode, czyli kod wynikowy. Jeżeli działanie programu ma być przewidywalne i autorzy chcą zachować przejrzystość, powinni wskazać miejsce przechowywania kodu źródłowego, a niezależny podmiot w postacie skanera blockchain (https://solana.fm/?cluster=mainnet-alpha) może dostarczać informację o zweryfikowaniu zgodności kodu źródłowego z wynikowym. Umieszczanie w blockchain tylko kodu wynikowego, czyli już skompilowanego, przyśpiesza wykonanie programu, a całe oprogramowania Solana jest ukierunkowane na wysoką wydajność – nie dziwi więc wybór takiego rozwiązania.
Specyficznym wykorzystaniem “Solana Account Model” i tego, że wszystko w Solana jest kontem są tokeny – Solana pozwala na tworzenie zarówno tych wymienialnych i niewymienialnych. Ich tworzenie jest prostsze i tańsze niż w Ethereum, do stworzenia tokena potrzebny jest program, który będzie definiował jego działanie, konto mennicy (Mint Account) oraz konto utrzymujące informacje o właścicielstwie tokena (Token Account). Kod programu jest dostępny na GitHub (https://github.com/solana-labs/solana-program-library/) i zapewnia podstawową kompletną implementację wszystkich interfejsów wymaganych w sieci Solana, jak transfer środków czy wybijanie nowych monet. W przeciwieństwie do Ethereum, gdzie każdy token jest dowolnym programem spełniającym określone standardy (ERC-20), w Solana mam na sztywno określony program – jeden i słuszny. Dzięki temu jest bezpiecznie – nie ma możliwości wypuszczenia tokena z błędem lub oszukańczego honeypota. Zostanie natomiast ograniczona możliwość modyfikacji standardu i tworzenia bardziej zaawansowanych funkcji.
Konto do wybijania monet zapewnia określoną konfigurację tokena: ilość maksymalną tokenów, precyzję dziesiętną oraz “mint authority”, czyli adres upoważniony do wybijania monet. Jest też “Freeze authority” do wstrzymywania procesu wybijania tokenów w razie potrzeby. Można pominąć “mint authority” i wtedy ilość tokenów będzie stała do początku.
Konto tokena zawiera wartość tokenów przypisanych do właściciela (“Owner”). Może być ich wiele, jeden u jednego właściciela i muszą pochodzić z jednego takiego samego konta mennicy, aby mogły zostać uznane za część konkretnej waluty. Poprzez skuteczny trik z tworzeniem adresów kont tokenów, można połączyć typ tokena z właścicielem w jednym adresie. To znaczy można przewidzieć że Jan Kowalski, a ściślej jeden z adresów jego portfeli w sieci Solana, ma pod danym adresem token USDC, albo go nie ma. Dzięki temu nie trzeba przeglądać wszystkich kont tokenów skojarzonych z daną kryptowalutą aby odnaleźć saldo określonego portfela użytkownika. Utworzenie nowego tokena z poziomu linii komend w kliencie blockchaina Solana jest szybkie, proste i tanie. Dzięki rozszerzeniom w metadanych konta wybijania można utworzyć monetę z nadaną nazwą, symbolem i linkiem do obrazka.
Inflacja w Solana
Nagrody dla walidatorów, czyli osób utrzymujących konsensus PoS blockchain swoimi środkami, są głównym czynnikiem napędzającym inflację. Część nagród pokrywana jest z puli inflacyjnej zaprogramowanej w protokole Solana, część z opłat transakcyjnych. Projektanci Solana zdają sobie sprawę z potrzeby zachęt dla utrzymujących środki w stakingu oraz operatorów węzłów walidujących, bo to wspiera decentralizację, czyli zwiększa zaufanie do sieci. Z drugiej strony inflacja jest czynnikiem pozornie negatywnym, ale jednak przy rozszerzającym się zasięgu sieci w pewien sposób stabilizuje kurs podstawowego tokena, jakim jest Sol. W przypadku Bitcoina, ilość monet jak znajduje się w obiegu jest z góry znana i jeżeli waluta ma objąć szerszy zasięg zainteresowanych nią osób, to automatycznie jej wartość rośnie. Z punktu widzenia inwestowania długoterminowego, waluty z mniejszą lub brakiem inflacji są na pewno lepsze. Natomiast z punktu widzenia czysto użytkowego, do przeprowadzania transakcji handlowych najbezpieczniejsze są waluty o stabilnym kursie – i to w jak najdłuższym okresie. Stąd podejście projektantów Solana, aby zapewnić jak najbardziej stabilną i silną krypto-ekonomię w długim okresie jest jak najbardziej słuszne. Blockchain Solana jest jak najbardziej użytkowy i cechuje go decentralizacja, w przeciwieństwie do rozwiązań próbujących przyspieszyć przetwarzanie transakcji przez zmniejszenie liczby węzłów walidujących, a co za tym idzie mniejszą decentralizację – Polygon, BNB. Solana wybrała inna drogę, wymagania wobec przepustowości sieci i konfiguracji sprzętowych samych węzłów są wyśrubowane tak, aby wykorzystać maksymalnie obecnie dostępne technologie do jak najszybszego działania.
W przypadku, gdy inflacja okazuje się zbyt duża – następuje zwiększenie ruch w sieci mimo wzrostu opłat za transakcję, bo na przykład wchodzi jakiś nowy produkt oparty o blockchain, tak jak kiedyś kolekcje NFT w Ethereum, to istnieje mechanizm regulacyjny po stronie protokołu, który pozwala zmniejszać wysokość generowanych nagród dla walidatorów. Stosuje go zarówno Etehereum (podprojekt “Ultrasound money”) jak i Solana – to spalanie połowy opłat z transakcji.
Plan inflacyjny w Solana obejmuje przejście od początkowej 8% inflacji (“Initial Inflation Rate”) do stabilnego poziomu 1,5% (Long-term Inflation Rate ) w ciągu 10-15 lat. To przy wprowadzeniu dodatkowych 250 mln tokenów SOL w stosunku do 500mln pierwotnych (aktualna liczba tokenów znajduje się tutaj: https://explorer.solana.com/supply). Odsetki za Staking (“Staking Yield)’ mają obniżać się z 13%-9% do 2% docelowo, z szybkością zależną od tego ile tokenów będzie uczestniczyć w stakowaniu ( “% of Staked SOL”).
Staking jest, a właściwie powinien być, procesem zamrożenia środków przez operatora węzła sieci blockchain, tak aby odpowiadał on swoimi własnymi tokenami za ewentualne nadużycia poprzez “slashing” (odebranie środków) lub co najmniej udowodnił w ten sposób, że jest sam w niej zaangażowany finansowo. Tak wygląda pierwotna idea konsensusu Proof of Stake zabezpieczającego obecnie wiele różnych blockchainów. W praktyce bardzo szybko okazało się, że zbyt wysoko postawiony próg finansowy (32ETH w Ethereum) lub po prostu brak możliwości uruchomienia fizycznego serwera walidującego spowodowało, że posiadający takie zasoby umożliwiali innym chętnym korzystanie z wirtualnego stakingu, nazywając to delegowaniem (przykładowo: https://ethermine.org/). W protokołach wielu blockchain pojawiło się wbudowane wsparcie dla delegowanego stakingu – Solana, Cardano, Tezos i innych. Delegowanie stanowi istotną wartość tokenomiki sieci blockchain – operatorzy węzłów walidujących ponoszą koszty utrzymania serwera, a przyjmując dodatkowe obce środki do stakingu zatrzymują część wygenerowanych dla nich nagród. Im więcej serwer posiada zgromadzonych środków w puli stakingu, tym więcej zarabia na opłatach. Konkurencja między operatorami węzłów sprawia, że obniżają oni swoje marże zwiększając zyski delegujących. Wybór walidatora do delegowania środków powinien umożliwiać program portfela, ich listę można podejrzeć tu: https://solanabeach.io/validators. Niektórzy walidatorzy Solana chwalą się obecnie APY na poziomie 7,5%.
Wracając do technikaliów, warto zwrócić uwagę na specjalny typ kont dla stakingu – Stake Accounts. Jest to specjalny typ konta, który wspomaga delegację czynności administracyjnych do automatycznych botów, rozdzielających kwotę przeznaczoną do stakingu przez użytkownika-walidatora na różne fizyczne węzły sieci Solana. Takie konto posiada dwa poziomy dostępu – konto użytkownika administratora stakingu (stake authority) oraz administratora wypłat (withdraw authority). W ten sposób można przekazać konto bezpiecznie do zarządzania przez trzecią stroną, będzie ono mogło zmieniać, wycofywać i dzielić delegajce tokenów, ale wypłata pozostanie w rękach właściciela. W katalogu programów Solana jest “Stake Pools” – do auto-delegacji i uproszczonego zarządzania stakingiem tokenów (https://spl.solana.com/stake-pool).
Warto nadmienić, że Solana nie pozwala na nagłe operacje wprowadzania stakingu tokenów lub ich wycofania – ze reguły trwa to wiele dni, na raty (szczegóły: https://docs.anza.xyz/consensus/stake-delegation-and-rewards#stake-warmup-cooldown-withdrawal). To kolejne zabezpieczenie przed nagłymi zmianami i manipulacjami, z drugiej strony jest to czynnik, który należy mieć na uwadze inwestując w staking na Solana – środków nie da się wycofać w trybie nagłym.
Na stronie (https://solanacompass.com/tokenomics#inflation) można zobaczyć listy kont z największą liczbą SOL w stakingu i daty, kiedy zostaną one odblokowane.
Organizacja sieci i konsensus
Blockchain to głównie protokół komunikacji między węzłami – komputerami przetwarzającymi transakcje, zapisującymi je i potwierdzającymi. Oprogramowanie węzłów może pochodzić od wielu dostawców i komunikować się miedzy sobą uzgodnionym dla danego blockchain protokołem. Jest to jeden z najbardziej krytycznych elementów infrastruktury kryptowalut. Od utrzymywania komputerów węzłów w działaniu, aktualizacji ich do najnowszej wersji blockchain nie mógłby działać. Ktoś musi zapłacić za prąd, sprzęt lub wykupić hosting. To robią operatorzy węzłów, indywidualne osoby lub firmy, które liczą (lub nie) na zwrot kosztów poprzez marżę na nagrodach osób stakujących kwoty na ich serwerze. Osoby wprowadzające swoje tokeny do konsensusu również są pewnego rodzaju walidatorami, ponieważ uczestniczą w tym procesie, ale tylko w pośredni sposób. Czasami nazwa walidator bywa używana zamiennie dla stakujących i utrzymujących węzły, co bywa mylące.
Utrzymywanie wielu różnych programów obsługi węzłów, stworzonych również w innych technologiach może być nie lada wyzwaniem. Wprowadzanie zmian w protokole wymaga koordynacji prac wszystkich dostawców oprogramowania węzłów tak, aby zmiany wchodziły w tym samym czasie. W Ethereum istnieją niezależni dostawcy oprogramowania węzłów i ma to bardzo duży wpływ na wysoką ocenę decentralizacji, czyli również bezpieczeństwa sieci. Oznacza to, że blockchain nie jest już zależny od jednego dostawcy i operatorzy węzłów mają wybór. Oczywiście są też programy węzłów oparte całkowicie o proces tworzenia otwartego oprogramowania i rozwijane przez społeczność, jak w przypadku Bitcoin Core.
Do 2024 roku jedynym dostawcą oprogramowania węzłów Solana była Solana Labs, czyli firma skojarzona z twórcami sieci. W 2024 powstaje nowa firma Anza (https://docs.anza.xyz/faq) grupująca byłych głównych inżynierów Solana Labs i wypuszcza swoją wersję oprogramowania Agave, która staje się najbardziej popularnym oprogramowaniem węzłów.
Samodzielne prowadzenie węzła w sieci Solana nie jest łatwym zadaniem. Poczynając od wysokich wymagań sprzętowych, objemujących posiadanie najnowszych generacji procesorów, min. 256GB RAM, dyski SSD w standardzie NVMe (szczegóły na https://solanahcl.org/). Łącze internetowe powinno mieć przepustowość co najmniej 1 GBbit/s, symetrycznie. Preferowane 10 GBit/s (szczególnie w przypadku sieci mainnet-beta). Co ciekawe nie zaleca stosowania się procesorów Intel, gdyż nie dają sobie rady z utrzymywaniem wydajności węzłów Solana, tu liczą się tylko profesjonalne wersje AMD. Wymagany przez węzeł Agava system operacyjny to Linux w dystrybucji Ubuntu.
Węzły w sieci Solana są zorganizowane w klastry, które mogą być całkowicie niezależne lub współpracować. Podstawowe klastry to
Devnet – wersja blockchaina Solana do twrzorzenia nowych rozwiązań,
Testnet – wersja Solana do testów, bardziej stabilna,
Mainnet Beta – wersja właściwa = “produkcyjna”
Wysyłanie transakcji do klastra
Klienci wysyłają transakcje do portu jednostki przetwarzania transakcji (TPU) dowolnego walidatora. Jeśli ten węzeł w danej chwili pełni rolę zwykłego walidatora, to przekazuje transakcję do wyznaczonego lidera klastra. Jeśli pełni rolę lidera, węzeł łączy przychodzące transakcje, oznacza je znacznikiem czasu, tworząc wpis i wypycha je na płaszczyznę danych klastra. Po wejściu na płaszczyznę danych transakcje są sprawdzane przez węzły walidatora, skutecznie dołącza je do księgi. Lider zmienia się co jakiś czas. Zadaniem lidera jest oznakowanie znacznikiem czasowym transakcji, zestawienie wsadów z transakcji i rozesłanie ich po węzłach sieci blockchain. Robi to w sposób “wiralowy” – przekazuje kolejnym węzłom tylko część transakcji, każdemu inną. One robią to samo i mimo, że nikt nigdy nie wysyła całości, to w określonym czasie całą się siec wysyca się informacją o nowym wsadzie transakcji. W Solana nazywa się to techniką “Turbine Block Propagation”, z której twórcy są bardzo dumni, bo pozwala posiadać dużą liczbę węzłów jednocześnie, co poprawia wskaźnik decentralizacji, a co za tym idzie bezpieczeństwo sieci. O tym, że informacja nie pomiesza się i nie zgubi, decyduje użycia wskaźnika czasowego nadanego przez lidera, który szereguje wszystko w czasie.
W czasie pisania tego tekstu w sieci blockchain Solana jest 6093 węzłów (w tym 1327 w tym węzłów aktywnie walidujących) z 49 krajów, które obsługują środki z 591821 kont stakingowych przy wydajności 4,47 tys TPS i czasie wystawienie kolejnego bloku 426 ms. (https://solanacompass.com/statistics/decentralization).
Rozgałęzienia – forks
W celu uniknięcia malwersacji i oszustw ze strony nieuczciwego węzła walidującego pełniącego rolę lidera, w protokole Solana zastosowano rotację liderów, a każdy z nich ma tylko chwilę na swoją działalność, bo każdej epoce Solana jest zaplanowany terminarz liderów. Nieuczciwy lider może cenzurować transakcje albo blokować całkowicie działanie sieci. Niestety zmiany liderów oraz to, że w blockchain Solana nie czeka się z wypuszczeniem kolejnego bloku na zakończenie zatwierdzania poprzedniego, dochodzi do częstego powstawania rozgałęzień blockchaina – forków. Kolejny lider musi przejąć zarządzanie rozgałęzieniami i zapisać tę wersję, która uzyska najwięcej głosów walidatorów. Dla protokołu Solana został nawet wymyślony i opisany specjalny algorytm zarządzania rozgałęzieniami – |”Tower BFT” ( https://docs.anza.xyz/implemented-proposals/tower-bft )
Proof of Stake w Solana
Projekt walidacji księgi Solana opiera się na rotacyjnym, ważonym stawką stakingu liderze (PoS), który rozgłasza transakcje w strukturze danych PoH do węzłów walidacyjnych. Węzły te, po otrzymaniu transmisji lidera, mają możliwość zagłosowania na aktualny stan i wysokość PoH poprzez podpisanie transakcji do strumienia PoH.
Aby zostać walidatorem Solana, należy zdeponować/zablokować pewną ilość SOL w kontrakcie. Ten SOL nie będzie dostępny przez określony czas. Aby natomiast pójść krok dalej w zabezpieczaniu sieci i zostać operatorem węzła walidującego, musisz dysponować szybkim serwerem i wydajnym łączem internetowym. Możesz też tylko przekazać swoje SOL do właściciela takiego węzła, aby zapewnić mu odpowiednia masę do przeprowadzania walidacji i generowania nowych bloków.
Solana posiada swobodne podejście do czasu i kolejności generowanych bloków transakcji zapewniane przez struktury danych PoH ze znacznikami czasowymi, co wraz z projektem transmisji danych algorytmem turbinowym powinno zapewnić czasy potwierdzenia transakcji poniżej sekundy skalując się logarytmicznie względem liczby węzłów w klastrze. Oznacza to, że Solana nie musi ograniczać liczby węzłów walidujących za pomocą zaporowych „minimalnych depozytów” i nie oczekuje jak np. Ethereum, że węzły będą mogły stać się walidatorami z nominalnymi kwotami stakowanych SOL. Jednocześnie, Solana wymaga od węzłów w zamian wysokiej przepustowości i ciągłości działania, co stanowi zachętę dla operatorów węzłów walidujących do dostarczania wysokowydajnego i niezawodnego sprzętu. W połączeniu z potencjalnie minimalnym progiem prędkości sieci, do którego należy dołączyć jako klient walidacyjny, Solana wytworzyła zdrowy ekosystem do delegowania walidacji.
Delegacja Stakingu i Nagradzanie
Ponieważ w Solana wszystko jest kontem, to zarówno operatorzy węzłów są zdefiniowani jako konto typu “Vote”, a umieszczający środki do zabezpieczenia sieci posiadają konto typu Stake. Właściciele konta typu Stake mogą przypisać się do konta typu “Vote” bez jego zgody, wystarczy znać jego klucz publiczny. Konto typu “Vote” posiada wskazanie na węzeł Solana, konta uprawnione do głosowania i wypłat oraz procent opłaty pobieranej od wypłat. Konta typu Stake są niezależne i właściciel konta typu “Vote” nie może wpływać na środki w koncie “Stake”.
Generalnie w odróżnieniu od blockchain bez delegacji jak Ethereum, projekt zastosowany w Solana pozwala na rozdzielenie funkcji walidatora – jako obsługującego komputer z oprogramowaniem od inwestora, który dostarcza jedynie środki SOL do zabezpieczenia sieci. W przypadku blockchain bez delegacji wbudowanej w protokół, trzeba w większym stopniu ufać stronie trzeciej – operatorowi węzła. W sieci Solana delegacja jest wbudowana w protokół i operator węzła nie może odebrać przekazanych na Staking środków. Nie oznacza to jednak, że są one w 100% bezpieczne – delegujący powinien dobierać odpowiedzialnych operatorów, w przypadku wspierania węzłów szkodzących sieci lub niedziałających regularnie może grozić utrata nagród lub nawet slashing, czyli likwidacja środków. Choć slashing w wielu miejscach dokumentacji Solana jest opisany jako jeszcze niezaimplementowany, to jest to pewne ryzyko, że zostanie wprowadzony.
Powstaje tu ciekawy paradoks – z jednej strony brak wymogu wkupienia się własnymi środkami w siec węzłów – jak 32 ETH w Etherum zwiększa demokratyzm sieci, a wysoki poziom ekosystemu węzłów w Solana jest osiągany przez wysokie wymagania sprzętowe. Z drugiej strony, operatorzy węzłów nie ryzykują własnymi środkami w przypadku kar za nieprawidłowe działanie, jedynie utratą nagrody za walidacji wykonane w bieżącym Epoch. Możliwości ukarania takiego operatora są ograniczone, właściwie może to być bardziej dotkliwe dla inwestorów, jeżeli Solana wprowadzi slashing, którego zasady są niejasne (https://docs.anza.xyz/proposals/slashing).
Tak więc nagrody są zdobywane poprzez delegowanie udziału do węzła walidatora, który głosuje poprawnie. Głosowanie niepoprawne naraża udziały tego walidatora na slashing, trzeba więc brać odpowiedzialność za swoje wybory.
Sieć wypłaca nagrody z części przeznaczonej na inflację. Liczba lamportów dostępnych do wypłaty nagród za epokę jest stała i musi być równo podzielona pomiędzy wszystkie węzły objęte stawką zgodnie z ich względną wagą stawki. Wartość wagowa dla epoki zależy od łącznego uczestnictwa wszystkich walidatorów w sieci. Jeśli całkowite uczestnictwo w epoce spada, wartości nagród są wyższe dla tych, którzy uczestniczą.
Trzeba pamiętać że Staking i otrzymywanie nagród w sieci Solana wymaga cierpliwości. Nagrody za epokę nie są dostępne do końca tej epoki. Przy wpłacie i wypłacie środków następuje stake warmup, cooldown, withdrawal czyli rozgrzewka, wyciszenie, wycofanie się, każdy z tych etapów zajmuje jedną epokę.
Synchronizacja
To co odróżnia Solana od innych blockchain, to brak walidacji bloków transakcji. Bloki występują tu czysto organizacyjnie, a transakcje są walidowane jeszcze przed utworzeniem bloków. Bieżący lider na bieżęco rozrzuca transakcje po węzłach sieci nadając im precyzyjny stempel czasowy (timestamp), dzięki temu kolejność przetwarzania transakcji nie ma kompletnie znaczenia. To podejście Solana nazwała jako Proof of History (PoH), ale nie jest to nowy typ konsensusu tylko dodatek do tego znanego jako Proof of Stake. PoH pozwala zmniejszyć przerwy czasowe pomiędzy generacją bloków, bo protokół nie musi obsługiwać problemów związanych z kolejnością bloków, co jest ważne w tradycyjnym podejściu walidacji całych bloków – nie można dopuścić nowego bloku przed ukończeniem walidacji starego. W tym sensie Solana nie jest blockchainem, a na pewno nie jest tradycyjnym blockchainem.
Ekonomia prowadzenia własnego węzła walidującego
Sieć Solana stosuje szereg zachęt do prowadzenia węzłów walidujących, co ja akurat uważam za korzystne dla decentralizacji, ponieważ długoterminowo daje to większość stabilność niż wolontariat. Jednak prowadzenie węzła walidującego nie jest proste, bo trzeba zbilansować przychody z nagród z wydatkami na koszty głosowań, a te mogą dochodzić do 1 SOL dziennie.
Walidator głosujący może zarabiać SOL na 2 sposoby:
- Poprzez nagrody inflacyjne wypłacane na koniec epoki.
- Zebraniem 50% opłat transakcyjnych za bloki wyprodukowane przez walidatora, kiedy jest liderem w sieci węzłów.
W sieci znajdują się kalkulatory, pozwalające wyliczyć potencjalne zyski uruchomienia walidatora, np: https://cogentcrypto.io/ValidatorProfitCalculator. Głównym wytycznym sukcesu jest zdobycie odpowiedniego kapitału zdeponowanego na serwerze przez walidatorów delegujących. W innym przypadku koszt opłat stanie się olbrzymi. Ogólnie uruchomienie zyskownego węzła jest obecnie ryzykowne i wymaga sporych inwestycji (https://solanacompass.com/staking/how-much-do-solana-validators-make). Nie wszyscy operatorzy węzłów chcą uczestniczyć w ustalaniu konsensusu, czyli zatwierdzaniu transakcji – będą chcieć jedynie móc oglądać, to co dzieje się w blockchain lub integrować z blockchain własne oprogramowanie. W takiej sytuacji można uruchomić węzeł w trybie „RPC node”, w którym służy on do dostarczana możliwości interakcji z całą siecią węzłów, z czego korzystają aplikacje typu Solana Beach pokazujące aktualną listę transakcji (https://solanabeach.io/transactions). Każdy, kto chce wykonać operację w sieci blockchain Solana musi korzystać z takiego węzła.
W obecnej chwili jest nawet więcej węzłów RPC niż głosujących:
- Consensus validators: 1309
- RPC nodes: 4742
(dane z https://www.validators.app/ )
MEV w Solana
Maksymalizacja wartości z przetwarzania transakcji przez węzły nie jest tak istotna w strukturze przychodów operatorów węzłów jak np. w Ethereum, ale jest obecna w blockchainie Solana. Techniki MEV mają tu swoją specyfikę, ze względu na pewne własności występujące w Solana. Ze względu na niskie opłaty transakcyjne opłacalne może być spamowanie takimi samymi transakcjami serwerów RPC tak, aby transakcja została szybko uznana i wykonana. Ta metoda jest nieprzewidywalna. Użycie standardowego mechanizmu podwyższania opłaty transakcyjnej w zamian za wyższy priorytet również nie przynosi efektów w technikach zarabiania MEV, gdzie operacja arbitrażu pomiędzy transakcjami w róznych DEX musi zostać wykonana z dużą precyzją. Tu o wiele bardziej skuteczne są zmodyfikowane programy walidatorów – w Solana jest to głównie Jito-Solana, używa go jednak niewiele węzłów. Aby skutecznie egzekwować zyski z MEV musi zajść jednocześnie wiele czynników – liderem blockchain musi być węzeł z Jito w momencie, w którym zachodzi okazja do arbitrażu. Dlatego jednym z poważniejszych problemów w Solana są transakcje spamowe. Techniki MEV są bardzo dyskusyjne, powodują podwyższanie opłat transakcyjnych i wprowadzają potencjalnie możliwość cenzurowania transakcji przez oprogramowanie zewnętrzne, jeżeli tylko większość operatorów węzłów się na nie zgodzi, a zapewne zrobi to dla zwiększonego zysku. Na szczęście w Solana wpływy MEV są bardzo słabe. Podstawowe techniki MEV Solana są opisane w tym artykule. Obecnie podstawowym narzędziem pozwalającym pozyskiwać zyski z MEV jest zmodyfikowane oryginalne oprogramowanie walidatora Solana – Jito.
Oprogramowanie węzłów Solana
Istnienie blockchain zależy od oprogramowania, które uruchomione na komputerach węzłów realizują zadania i komunikują się z innymi węzłami według ustalonego protokołu. Im większy wybór mają operatorzy węzłów wśród dostawców takiego oprogramowania i czym większy jest jego zróżnicowanie, tym sieć blockchain jest mniej zależna do pojedynczego dostawcy, a tym samym lepiej zdecentralizowana. Jest to szczególnie istotne w przypadku sieci blockchain takich, które zostały ufundowane i stworzone przez spółki typu Venture Capital i inne prywatne firmy. Istnienie niezależnego oprogramowania węzłów daje dodatkowa weryfikacją do prac nadzorcy blockchain, a krytycznym przypadku ułatwia fork społecznościowy, czyli stworzenie własnej odnogi blockchain w ramach sprzeciwu do narzucanych zasad (przykład to Ethereum Classic).
W przypadku Solana w różnych źródłach mówi się o jednym do pięciu istniejących wersji oprogramowania klienckiego. Nie wszystkie wersje są jednak gotowe, a w zasadzie nie ma obecnie niezależnego dostawny oprogramowania Solana. Obecne możliwości wyglądają tak:
- Agave – oryginalny klient Solana Labs (napisany w języku programowania Rust), przejęty przez firmę Anza. https://www.anza.xyz/#validator, część jego dokumentacji nadal prowadzi Solana Labs.
- Jito-Solana client – odgałęzienie oryginalnego projektu Solana Labs z modyfikacjami w celu możliwości wprowadzenia mechanizmów MEV https://www.jito.wtf/
- Firedancer – całkiem nowy klient Solana napisany w języku C. Niestety nie jest jeszcze ukończony. https://jumpcrypto.com/firedancer/
- Frankendancer – hybrydowy walidator wykorzystujący części Firedancer i części Agave. Frankendancer wykorzystuje nowy kod sieciowy Firedancer i komponenty produkcji bloków, aby działać lepiej będąc liderem. Inne funkcje wykorzystują kod walidatora Agave. Istnieje wersja działająca. https://github.com/firedancer-io/firedancer
- Sig client – nowy klient zoptymalizowany na wydajność odczytów do wysoce wydajnych węzłów typu RPC dla zastosowań Dapp i DeFI pisany w języku Zig pod nadzorem firmy Syndica w formule Open Source. W trakcie budowy, https://www.syndica.io/sig .
Podsumowując aktualny stan oprogramowania klienckiego Solana, to wciąż jest bardzo mało zróżnicowane w stosunku do głównego konkurenta – Ethereum, gdzie jest co najmniej 9 różnych klientów i sześciokrotnie większe zaangażowanie deweloperów na GitHub . W przypadku Solany kompletne są trzy programy, z tym że wszystkie są klonem pierwotnego klienta.
Decentralizacja węzłów i protokołu
Od strony technicznej decentralizacja jest dość dobra, sieć węzłów alidujących jest sporo i dobrze rozproszona po całym Świecie (https://www.validators.app/). Największym wyzwaniem dla Solna wydaje się byc złożoność techniczna samego protokołu, co powoduje brak niezależnego dostawcy oprogramowania dla węzła, co jest normą na przykład w Ethereum. Grupa aktualizującea oprogramowanie węzłów Agave – Anza wydzieliła sie z Solana Labs, ale to wciąża za mało aby uznać sieć w pełni zdecentralizowaną. Na plus działa brak konieczności inwestowania własnych SOL w staking, ale próg kosztowy istnieje przez duże wymagania co do sprzętu, łącza i pokrycia kosztów głosowań na początku działalności – chyba, że zdobędzie się grant Fundacji Solana (https://solana.org/delegation-program).
Dodaj komentarz