Solana (SOL): Jak działają transakcje i walidatorzy

Stan znajduje się na kontach

Każdy trwały stan Solany jest przechowywany na koncie identyfikowanym przez 32-bajtowy adres. Konto rejestruje lamporty, dane, program właściciela i pola związane z wykonaniem. Właściciel to program uprawniony do zmiany danych tego konta; niekoniecznie jest to osoba kontrolująca klucz portfela.

Programy Solana to wykonywalne konta zawierające kod sBPF. Program jest zazwyczaj traktowany jako bezstanowy, ponieważ zmienny stan aplikacji znajduje się w oddzielnych kontach dostarczanych do każdej instrukcji. Pozwala to środowisku wykonawczemu zobaczyć, które konta transakcja będzie czytać lub zapisywać przed wykonaniem i zaplanować pracę, która nie konkuruje o ten sam zapisywalny stan.

Portfele, konta tokenów i PDA

Adres portfela może być właścicielem SOL i autoryzować transakcje, ale saldo tokena SPL zwykle znajduje się na koncie tokena powiązanym z mennicą i właścicielem. Adres pochodny programu (Program Derived Address) jest deterministycznie wyprowadzany z programu ID i ziaren; program może go autoryzować poprzez reguły środowiska wykonawczego, nawet jeśli dla tego adresu nie istnieje klucz prywatny.

Przed wysłaniem tokena potwierdź mennicę, docelowe konto tokena i wywoływany program. Znany ticker lub etykieta portfela nie jest dowodem, że mennica jest kanoniczna. Zamykanie, tworzenie lub realokacja kont może również przenosić lamporty, więc podsumowanie transakcji należy przejrzeć poza główną kwotą tokena.

Wiadomość, podpisy i instrukcje

Wiadomość zawiera adresy kont, ostatni blockhash i skompilowane instrukcje. Każda instrukcja wymienia program i identyfikuje konta, z których może korzystać. Wymagani sygnatariusze autoryzują wiadomość, a transakcje w wersji mogą używać tabel przeglądowych adresów, aby odwoływać się do większej liczby kont bez umieszczania każdego adresu bezpośrednio w pakiecie.

Świeżość i potwierdzenie

Ostatni blockhash zapobiega temu, aby zwykła transakcja pozostała ważna w nieskończoność. Jeśli wygaśnie przed przetworzeniem, transakcja musi zostać odbudowana i podpisana ponownie; ponowne wysłanie starego podpisu nie tworzy nowej transakcji. Istnieją przepływy pracy z trwałym nonce (durable nonce) dla specjalistycznego podpisywania offline lub opóźnionego i wymagają one osobnego obsłużenia.

Klienci RPC udostępniają poziomy potwierdzenia: processed, confirmed i finalized. Szybki interfejs może pokazywać wyniki processed, zanim zostanie osiągnięty silniejszy konsensus klastra. Depozyty, mosty i zależne działania aplikacji powinny czekać na poziom wymagany przez tę usługę i powinny weryfikować podpis przez aktualny RPC lub eksplorator.

Składniki bazowe i priorytetowe

Każda transakcja płaci opłatę bazową w SOL za wymagane podpisy. Protokół wyraża SOL w lamportach, a kwota bazowa zależy zatem od liczby podpisów, a nie od wartości płatności lub wymiany tokena. Nieudana transakcja może zużyć opłatę bazową, ponieważ podjęto próbę weryfikacji podpisu i wykonania.

Opcjonalna opłata priorytetowa opiera się na żądanym limicie jednostek obliczeniowych i wybranej cenie jednostki obliczeniowej. Limit to budżet, a nie prognoza rzeczywistego użycia, więc ustawienie go znacznie wyżej niż to konieczne może spowodować nadpłatę składnika priorytetowego. Szacunki portfela powinny wykorzystywać ostatnie warunki i symulację transakcji zamiast kopiowania stałej opłaty z innej aplikacji.

Kontrole operacyjne

Zachowaj wystarczającą ilość SOL na opłatę, nawet jeśli przesyłanym zasobem jest token SPL. Przejrzyj wszelkie instrukcje budżetu obliczeniowego, ponieważ mogą one zmienić żądany limit i cenę priorytetu. Rozróżniaj także opłaty transakcyjne od finansowania konta, sald związanych z czynszem, wpływu ceny wymiany i opłat aplikacji; to oddzielne koszty, nawet jeśli jeden portfel podsumowuje je razem.