Jak działają transakcje na Solanie?

Ponieważ opłata jest pobierana przy każdym wykonaniu transakcji, warto zrozumieć, jak transakcje działają. Transakcja składa się z trzech części:

jednej lub więcej instrukcji
tablicy kont do odczytu lub zapisu
jednego lub więcej podpisów
ostatniego blokhasza lub nonce

Instrukcja to najmniejsza jednostka logiki wykonawczej na Solanie. Instrukcje są wywołaniami aktualizującymi globalny stan Solany. Instrukcje wywołują programy, które z kolei wywołują środowisko uruchomieniowe Solany w celu aktualizacji stanu (na przykład wywołanie token program w celu przeniesienia tokenów z Twojego konta na inne konto). Instrukcję można traktować jak wywołanie funkcji w inteligentnym kontrakcie Ethereum.

Istotną różnicą między Ethereum a Solaną jest liczba wywołań funkcji w ramach jednej transakcji, wynikająca z liczby instrukcji. Możliwość umieszczenia wielu instrukcji w jednej transakcji jest korzystna dla deweloperów, ponieważ nie muszą tworzyć niestandardowych inteligentnych kontraktów, aby łączyć funkcje w ramach jednej transakcji. Każda instrukcja może być oddzielnym wywołaniem funkcji, wykonywanym w określonej kolejności w transakcji. Transakcje są atomowe, co oznacza, że jeśli którakolwiek z instrukcji się nie powiedzie, cała transakcja zostanie odrzucona i zapłacisz jedynie opłatę transakcyjną. Przypomina to nieudaną transakcję z powodu niepoprawnego ustawienia slippage na Ethereum.

Kolejną kluczową różnicą wartą odnotowania jest stosowanie ostatniego blokhasza zamiast inkrementalnego nonce w transakcjach. Gdy portfel chce wykonać transakcję, z klastra pobierany jest ostatni blokhasz w celu utworzenia prawidłowej transakcji. Ten ostatni blokhasz sprawia, że transakcja jest ważna jedynie przez 150 bloków od momentu jego pobrania. Zapobiega to wykonywaniu podpisów transakcji z dużym opóźnieniem w znacznie późniejszym terminie.

Cross-Program Invocation (CPI)

Cross-Program Invocation (CPI) zachodzi wtedy, gdy jeden program Solany wywołuje instrukcję innego programu w trakcie wykonywania oryginalnej transakcji. CPI to główny mechanizm kompozycji programów Solany, jednak model kont zmienia sposób projektowania grafu wywołań: transakcja musi zawierać każde konto, które zostanie odczytane lub zapisane przez cały łańcuch CPI, zanim rozpocznie się jej wykonanie.

Wywoływany program dziedziczy jedynie uprawnienia podpisującego i uprawnień do zapisu, które otrzymał wywołujący, oraz korzysta z tego samego budżetu obliczeniowego transakcji. Użyj invoke, gdy wszyscy wymagani podpisujący podpisali oryginalną transakcję. Użyj invoke_signed, gdy wywołujący program musi podpisać się za jedno ze swoich PDA przy użyciu seed podpisującego.

Poziomy potwierdzenia

Odczyty RPC, subskrypcje i logika potwierdzania transakcji mogą korzystać z poziomu commitment. Jest to odpowiednik Solany dla decydowania, ile potwierdzeń bloków Ethereum czekać, z tą różnicą, że poziomy są tu jawnie zdefiniowane:

processed: najnowszy przetworzony widok węzła. Używaj go wyłącznie do optymistycznego UI lub przepływów tolerujących wycofanie zmian.
confirmed: blok, za którym zagłosowała superwiększa część stawki. Używaj go jako domyślnego dla większości potwierdzeń produkcyjnych i statusu transakcji widocznego dla użytkownika.
finalized: najsilniejszy stan potwierdzenia. Używaj go przed nieodwracalnymi działaniami poza łańcuchem, takimi jak wypłaty fiat, wysyłka towarów czy ostateczne zapisy rozliczeniowe.

Jeśli metoda RPC akceptuje commitment i zostanie on pominięty, domyślnie stosowany jest zazwyczaj finalized. Klienci produkcyjni powinni mimo to jawnie ustawiać commitment, aby opóźnienie interfejsu, zachowanie indeksera i polityka rozliczeń były świadome i przemyślane.