Eksplorator programów Solana: sprawdź smart kontrakt, zanim mu zaufasz

Eksplorator programów Solana to miejsce, w którym sprawdzasz smart kontrakt, zanim podpiszesz cokolwiek, co z nim współpracuje. Strona programu pokazuje, czy kod jest wykonywalny, który loader jest jego właścicielem, czy upgrade authority może go jeszcze podmienić, czy źródło ma verified build, a w przypadku programów Anchor także IDL, który dekoduje każdą instrukcję. W tym poradniku omawiamy każde pole na prawdziwym przykładzie programu pump.fun, a na końcu znajdziesz krótką listę kontrolną bezpieczeństwa, którą przejdziesz w dwie minuty w Solana Explorer, Solscanie albo Orb.

Czym jest konto programu na Solanie?

Konto programu to konto on-chain oznaczone jako wykonywalne (executable), które przechowuje skompilowany kod albo na niego wskazuje. Na Solanie słowo „program” oznacza to, co na innych blockchainach nazywa się smart kontraktem.

Programy na Solanie są bezstanowe. Nie trzymają w sobie sald ani danych użytkowników; te dane leżą w osobnych kontach, których właścicielem jest program. Kiedy wywołujesz program, twoja transakcja przekazuje mu potrzebne konta, a program je odczytuje i zapisuje. Dlatego strona programu w eksploratorze wygląda inaczej niż strona portfela: najciekawsze nie jest saldo, tylko to, kto może zmienić kod i co ten kod robi.

Większość dzisiejszych programów wdraża się za pomocą BPF Upgradeable Loader (BPFLoaderUpgradeab1e11111111111111111111111). W tym modelu samo konto programu jest małe. Dla programu pump.fun 6EF8rrecthR5Dkzon8Nwu78hRvfCKubJ14M5uBEwF6P surowe wywołanie getAccountInfo zwraca zaledwie 36 bajtów danych, executable: true, właściciela ustawionego na upgradeable loader i jedno sparsowane pole: programData. Właściwy kod znajduje się gdzie indziej. Jeśli konta na Solanie są dla ciebie czymś nowym, najjaśniejszym wprowadzeniem jest oficjalna dokumentacja kont.

Konto program data i upgrade authority w praktyce

Konto program data przechowuje właściwy bajtkod oraz dwie informacje dodatkowe: slot ostatniego wdrożenia i upgrade authority. To właśnie upgrade authority jest najważniejszym polem na stronie każdego smart kontraktu w eksploratorze.

Wracając do przykładu pump.fun: pole programData wskazuje na B5MvUwXdiW1NMM6QFFD3ssPKBujD4zMohncbM73Z2BQu. Gdy odpytaliśmy to konto 23 września 2026 roku, jako upgrade authority widniał adres 7gZufwwAo17y5kg8FMyJy2phgpvv9RSdzWtdXiWHjFr8. Mówiąc prosto: ktokolwiek kontroluje ten klucz, może wdrożyć nowy kod pump.fun. W aktywnie rozwijanym protokole to normalne, ale oznacza, że ufasz zespołowi, a nie tylko samemu kodowi.

Eksploratory prezentują to na różne sposoby. Solana Explorer pokazuje w przeglądzie programu adres program data, upgrade authority i slot ostatniego wdrożenia. Solscan i Orb pokazują te same fakty, dodając etykiety tam, gdzie je znają. Możesz to sprawdzić samodzielnie dowolnym klientem RPC albo wkleić adres programu do naszej wyszukiwarki, żeby zobaczyć surowe konto.

Na co zwracać uwagę:

• Pojedynczy portfel jako authority. Jeden przejęty klucz wystarczy, by podmienić program. Wyższe ryzyko.
• Multisig albo konto governance. Zmiana wymaga kilku podpisów lub głosowania. Niższe ryzyko i standard w dużych protokołach.
• Brak authority. Program jest niezmienny. Więcej w następnej sekcji.

Programy niezmienne: kiedy kodu nie da się już zmienić

Program niezmienny (immutable) to taki, którego upgrade authority zostało usunięte. Nikt, łącznie z pierwotnym deweloperem, nie zmieni już jego kodu.

Niezmienność to mocna gwarancja, ale działa w obie strony. Błędu w niezmiennym programie nie da się załatać; zespół musi wdrożyć nowy program i poprosić użytkowników o migrację. Dlatego wiele zespołów zamiast „spalić” uprawnienie trzyma je za multisigiem. Gdy eksplorator pokazuje „Upgradeable: No” albo puste pole authority, wiesz, że bajtkod, który czytasz dziś, będzie tym samym bajtkodem, z którym połączysz się jutro. Z tego powodu verified build programu niezmiennego ma szczególną wartość: raz potwierdzona zgodność ze źródłem pozostaje prawdziwa na zawsze.

Verified builds: solana-verify i API OtterSec

Verified build dowodzi, że bajtkod wdrożony on-chain został skompilowany z konkretnego publicznego repozytorium i konkretnego commita. To solanowy odpowiednik „zweryfikowanego kodu źródłowego” znanego z eksploratorów Ethereum.

Proces opisany w oficjalnym przewodniku po verified builds korzysta z open-source’owego CLI solana-verify od OtterSec:

1. solana-verify build kompiluje program deterministycznie w obrazie Dockera, więc każdy uzyska ten sam hash.
2. solana-verify verify-from-repo buduje program ponownie z repozytorium i porównuje wynik z hashem programu on-chain.
3. Deweloper wgrywa dane weryfikacyjne do PDA on-chain podpisanego kluczem upgrade authority, a potem uruchamia solana-verify remote submit-job, żeby API OtterSec pod adresem verify.osec.io publicznie to potwierdziło.

Solana Explorer odczytuje API OtterSec i pokazuje zakładkę verified build z linkiem do repozytorium i commita. Orb również oznacza zweryfikowane programy, a Solscan w dokumentacji opisuje programy „Anchor-verified”. Gdy 23 września 2026 roku sprawdziliśmy program pump.fun w endpoincie statusu OtterSec, odpowiedź brzmiała is_verified: false. Nie znaczy to, że program jest złośliwy; znaczy tylko, że z samego eksploratora nie potwierdzisz, że wdrożony kod odpowiada publicznemu źródłu.

Dokumentacja Solany stawia sprawę jasno: verified build nie powinien być uważany za bezpieczniejszy od niezweryfikowanego. Usuwa jedną niewiadomą, czyli lukę między źródłem a bajtkodem, a audyty i kontrola nad authority pozostają osobnymi pytaniami.

Zakładka IDL w programach Anchor

Zakładka IDL pokazuje interfejs programu: jego instrukcje, ich argumenty, konta, których oczekuje każda z nich, oraz własne typy danych. W przypadku programów Anchor eksploratory potrafią odczytać IDL opublikowany on-chain i użyć go do dekodowania transakcji.

Anchor to najpopularniejszy framework do pisania programów na Solanie i może publikować IDL programu na koncie on-chain wyprowadzonym z adresu programu. Solana Explorer go wykrywa, wyświetla zakładkę IDL i dekoduje konta oraz instrukcje Anchor na nazwane pola. Orb również pokazuje IDL zweryfikowanych programów. Bez IDL instrukcja wygląda jak blob w hex albo base58 i musisz zgadywać, co oznacza 0x66063d12....

W praktyce IDL zamienia transakcję z „nieznanej instrukcji” w coś w rodzaju buy { amount, max_sol_cost } z opisanymi kontami. To bezcenne, gdy sprawdzasz, co tak naprawdę zrobi okno podpisu w twoim portfelu. Pamiętaj jednak, że IDL wgrywa deweloper. Opisuje zamierzony interfejs, ale nie jest dowodem bezpieczeństwa, a nieuczciwy deweloper mógłby opublikować mylący IDL. Niektóre zespoły, w tym pump.fun, dokumentują też instrukcje i układ kont w publicznym repozytorium na GitHubie, np. w publicznej dokumentacji pump.fun.

Jak czytać logi programu w transakcji

Logi programu to komunikaty, które program zapisuje w trakcie działania, i najszybszy sposób, by zrozumieć, dlaczego transakcja się nie powiodła. Każdy eksplorator pokazuje je w widoku transakcji.

Logi mają stały schemat. Najpierw zobaczysz Program 6EF8... invoke [1], gdy program startuje, potem linie Program log: z komunikatami z kodu, linię z liczbą zużytych compute units, a na końcu success albo failed z błędem. Zagnieżdżone wywołania innych programów pojawiają się jako invoke [2], invoke [3] i pokazują drzewo wywołań. Błąd Anchor zwykle sam się przedstawia, np. jako niespełnione ograniczenie (constraint), co jest dużo bardziej pomocne niż surowy numer błędu.

Kiedy transakcja się wysypie, czytaj najpierw kilka ostatnich linii logu. Zazwyczaj wskazują na przekroczony limit slippage, niezainicjowane konto albo wyczerpany compute budget; maksimum to 1 400 000 compute units na transakcję. Nasz poradnik o sprawdzaniu transakcji Solana objaśnia resztę strony transakcji, a przewodnik po eksploratorze devnet pokazuje, jak bezpiecznie przetestować te same wywołania programu najpierw na klastrze testowym.

Jak zbadać program krok po kroku: przykład pump.fun

Oto cała procedura na jednym prawdziwym programie. Zajmuje kilka minut i działa w każdym eksploratorze kontraktów Solana.

Otwórz 6EF8rrecthR5Dkzon8Nwu78hRvfCKubJ14M5uBEwF6P w Solana Explorer, Solscanie albo Orb. Przegląd potwierdza, że program jest wykonywalny, a jego właścicielem jest BPF Upgradeable Loader. Przejdź do linku program data i zanotuj upgrade authority: w chwili pisania to 7gZu…jFr8, więc kod może się zmienić. Otwórz również ten adres; jeśli należy do programu multisig, do aktualizacji potrzeba kilku podpisów. Sprawdź zakładkę weryfikacji: przy naszym ostatnim sprawdzeniu program nie był zweryfikowany. Poszukaj zakładki IDL i skorzystaj z niej albo z publicznego repozytorium z dokumentacją, żeby zrozumieć nazwy instrukcji. Na koniec otwórz niedawną transakcję, która wywołała program, i przeczytaj logi, aby zobaczyć, jak wygląda typowy przebieg buy albo sell.

Porównaj to z programem, którego authority to znany multisig, a build jest zweryfikowany, i od razu zobaczysz, jak różny poziom zaufania każdy z nich od ciebie wymaga. Jeśli potrzebujesz danych na większą skalę, np. wszystkich sygnatur dla adresu programu, zajrzyj do naszego przeglądu opcji API eksploratorów Solana.

Kontrola bezpieczeństwa przed interakcją z programem

Zanim zatwierdzisz transakcję wywołującą nieznany program, sprawdź pięć rzeczy: dokładny adres, upgrade authority, status weryfikacji, IDL lub dokumentację oraz ostatnią aktywność.

• Dokładny adres. Program ID bierz z oficjalnej dokumentacji albo z GitHuba, a nie z wiadomości prywatnej czy przypadkowej strony, i porównuj go znak po znaku.
• Upgrade authority. Pojedynczy klucz, multisig czy brak? Ustal to, zanim wpłacisz większą kwotę.
• Verified build. Miły dodatek; potwierdza, że repozytorium, które czytasz, to kod, który faktycznie działa.
• IDL i instrukcje. Upewnij się, że instrukcja pokazana przez portfel zgadza się z tym, co chcesz zrobić. „Odbierz airdrop”, który wywołuje przelew na nieznane konto, to drainer.
• Kontakt ds. bezpieczeństwa. Solana Explorer wyświetla dane security.txt, jeśli program je zawiera, dzięki czemu wiesz, gdzie zgłaszać problemy.

Polscy użytkownicy memecoinów najczęściej trafiają na nieznane programy przez linki z Telegrama, X albo Discorda. Zasada jest prosta: jeśli nie możesz w dwie minuty potwierdzić adresu programu w oficjalnym źródle, nie podpisuj transakcji. Eksploratory mają interfejs po angielsku, ale pola, na które patrzysz, są zawsze te same, więc po jednym przećwiczeniu tej listy na pump.fun odnajdziesz się na każdej stronie programu.

Poszczególne eksploratory pokazują te pola z różną czytelnością. Nasz ranking najlepszych eksploratorów Solana ocenia je także pod kątem narzędzi deweloperskich, a recenzja Orb omawia jego czytelne widoki IDL i programów.