Tokeny SPL i konta tokenów w SSP

Jeśli używałeś tokenów ERC-20 na Ethereum, model tokenów Solany wyda ci się znajomy przez jakieś trzydzieści sekund, a potem przestanie mieć sens. Na Ethereum kontrakt tokena prowadzi rejestr tego, kto co posiada, a twój adres pojawia się w nim jako wiersz. Na Solanie twój adres w ogóle nie występuje w zapisach tokena. Zamiast tego powstaje osobne konto, które trzyma twoje saldo właśnie tego tokena — należące do ciebie, ale odrębne od twojego głównego adresu.

Ta jedna decyzja projektowa tłumaczy prawie każde zaskoczenie, jakie ludzie napotykają przy tokenach SPL: dlaczego wysłanie tokena komuś nowemu kosztuje więcej niż wysłanie komuś, kto już go ma; dlaczego portfel może pokazywać zerowe saldo tokena dla adresu, który nigdy go nie dotknął; i dlaczego miejsca dziesiętne mają tu większe znaczenie niż gdziekolwiek indziej. Ten artykuł przechodzi przez ten model tak, jak implementuje go SSP.

Dlaczego Solana potrzebuje osobnego konta na każdy token

Podstawowa zasada Solany brzmi: wszystko jest kontem, a każde konto ma właściciela, rozmiar i depozyt czynszowy proporcjonalny do tego rozmiaru. Nie ma tu czegoś takiego jak kontrakt, który po cichu rozrasta wewnętrzne odwzorowanie w miarę napływu użytkowników — pamięć musi gdzieś mieszkać, w jakimś koncie, i ktoś musi za nią zapłacić.

Dlatego program SPL Token dzieli zadanie. Konto mintu trzyma fakty o samym tokenie: całkowitą podaż, miejsca dziesiętne i to, kto może emitować więcej. Każdy posiadacz dostaje własne konto tokena — niewielkie konto o stałym rozmiarze, które zapisuje jedno saldo dla jednego mintu i wskazuje właściciela. Twoje saldo SOL mieszka pod twoim adresem; twoje saldo USDC mieszka na koncie tokena, które kontroluje twój adres.

Zaletą tego projektu jest przewidywalność — każde saldo tokena ma ten sam kształt i kosztuje tyle samo w przechowaniu. Ceną jest to, że posiadanie nowego tokena wymaga powołania nowego konta do istnienia. Dokumentacja tokenów Solany jest źródłem pierwotnym, jeśli chcesz specyfikacji zamiast streszczenia.

Powiązane konto tokena i kto za nie płaci

Gdyby każdy posiadacz potrzebował konta tokena, a konta mógł zakładać każdy, skończyłbyś z kilkoma kontami tokena na osobę i mint, bez sposobu, by wiedzieć, na które wysłać. Powiązane konto tokena — ATA — to konwencja, która to rozwiązuje: dla danego właściciela i danego mintu istnieje jeden kanoniczny adres, wyprowadzony deterministycznie z obu. Portfele potrafią go wyliczyć, więc nikt nie musi go publikować.

Haczykiem jest czynsz. Konto tokena zajmuje mniej więcej 165 bajtów, co daje około 0,002 SOL zamrożonych jako depozyt czynszowy, dopóki konto istnieje. Depozyt jest do odzyskania po zamknięciu konta, ale trzeba go wpłacić z góry — i to komuś, kto ma SOL, czego odbiorca swojego pierwszego w życiu przelewu tokena z definicji może nie mieć.

SSP załatwia to tak samo jak każdą inną opłatę na Solanie. Kiedy wysyłasz token SPL komuś, czyje ATA nie istnieje, transakcja zawiera idempotentną instrukcję jego utworzenia, a paymaster SSP płaci czynsz. Twój skarbiec zwraca paymasterowi koszt w ramach tej samej transakcji — i dlatego ten pierwszy przelew do nowego odbiorcy kosztuje około 0,0025 SOL więcej niż kolejny do tej samej osoby. „Idempotentna" to tu kluczowe słowo: jeśli konto jednak już istnieje, instrukcja kończy się powodzeniem i nie robi nic, zamiast wywrócić cały przelew.

Zwróć uwagę, że ta instrukcja tworzenia stoi poza propozycją multisig. Utworzenie czyjegoś konta tokena nie rusza twoich środków i nie wymaga autoryzacji ze strony skarbca, więc nie należy do części podpisywanej przez twoje dwa urządzenia. Zwrot kosztu, który już rusza twoje środki, jest wewnątrz propozycji.

Co SSP obsługuje domyślnie

SSP przychodzi z natywnym SOL, oficjalnym mintem USDC od Circle oraz FLUX-em na Solanie. Każdy inny token SPL, który pojawi się w twoim skarbcu, zostaje rozpoznany i wyświetlony obok nich.

Warto wprost nazwać jedno świadome ograniczenie: przelewy Solany w SSP budowane są na klasycznym programie SPL Token. Tokeny wyemitowane w ramach Token-2022 — nowszego programu z transfer hookami, przelewami poufnymi i innymi rozszerzeniami — nie są dziś częścią ścieżki wysyłki. To decyzja o zakresie, a nie przeoczenie: rozszerzenia Token-2022 mogą zmieniać to, co robi przelew, a ich wsparcie oznacza audyt każdego rozszerzenia względem opisanych niżej gwarancji dekodowania na urządzeniu.

Jak naprawdę zbudowany jest przelew tokena

Kiedy wysyłasz token SPL z SSP, podpisywana transakcja zawiera po kolei:

1. Utworzenie ATA odbiorcy, jeśli trzeba — idempotentnie, opłacone przez paymastera, poza propozycją.
2. TransferChecked — przenosi saldo z konta tokena twojego skarbca na konto odbiorcy, autoryzowane przez skarbiec.
3. Zwrot dla paymastera — zwykły przelew SOL ze skarbca, wewnątrz propozycji.

Wszystko to ląduje jako jedna atomowa transakcja. Nie ma osobnego kroku zatwierdzania, nie ma oczekującej propozycji leżącej on-chain, nie ma stanu, w którym konto odbiorcy zostało utworzone, ale przelew się nie odbył. Albo wykonuje się całość, albo nic.

Kontem źródłowym jest własne ATA twojego skarbca — wyprowadzone tak samo deterministycznie, z adresem programu skarbca jako właścicielem. Ponieważ skarbiec jest adresem wyprowadzonym z programu, a nie parą kluczy, wyprowadzanie wprost dopuszcza właściciela leżącego poza krzywą ed25519. Jeśli chcesz sedno tego, dlaczego adres skarbca tak działa, omawia to samoinicjujący się multisig Solany.

Miejsca dziesiętne są częścią podpisu

To fragment, przy którym warto zwolnić, bo tu token może cię okłamać.

Mint deklaruje, ilu miejsc dziesiętnych używa jego token. USDC używa sześciu, wiele tokenów dziewięciu, reguły nie ma. Jeśli portfel pokazuje „100 USDC", ale buduje przelew na liczbę jednostek surowych zakładającą złe miejsca dziesiętne, możesz wysłać tysiąc razy za dużo i nie zobaczyć na ekranie nic niepokojącego.

SSP używa TransferChecked zamiast zwykłej instrukcji przelewu. Różnica polega na tym, że TransferChecked wpisuje adres mintu i bajt miejsc dziesiętnych wprost w dane podpisywanej instrukcji. Wynikają z tego trzy odrębne kontrole:

• Twoje rozszerzenie dekoduje bajty i porównuje je z tym, co wyświetla.
• SSP Key dekoduje te same bajty niezależnie na telefonie i porównuje je z metadanymi tokena dostarczonymi przez rozszerzenie.
• Program SPL Token on-chain porównuje miejsca dziesiętne z instrukcji z rzeczywistymi miejscami dziesiętnymi mintu i odrzuca transakcję, jeśli się różnią.

Trzecia kontrola jest tą, której nie da się zagadać. Mint deklarujący inne miejsca dziesiętne niż faktyczne nie produkuje błędnego przelewu — produkuje nieudaną transakcję.

Odbieranie tokenów

Odbieranie jest prostsze, z jednym niuansem. Podaj nadawcy swój adres portfela — ten, który SSP pokazuje na ekranie odbioru — a nie adres konta tokena. Cokolwiek wysyła, właściwe ATA jest wyprowadzane z twojego adresu i mintu, a portfel nadawcy utworzy je w razie potrzeby.

Jeśli twój skarbiec nigdy nie posiadał tego tokena, konto nie będzie istniało, dopóki nie dotrze pierwszy przelew, a jego czynsz płaci ten, kto do ciebie wysyła. To normalne i nie wymaga od ciebie niczego. Oznacza natomiast, że eksplorator bloków nie pokaże żadnego konta tokena dla tokena, który ci obiecano, ale jeszcze nie dotarł — to konto jeszcze nie istnieje, a nie zgubiony przelew.

Częste pułapki

Wysyłanie na adres konta tokena zamiast na adres portfela. Niektóre eksploratory eksponują ATA na pierwszym planie. Wysłanie tokena na konto tokena zamiast do jego właściciela to dobrze znany sposób na utratę środków na Solanie. SSP oczekuje adresu portfela właściciela i resztę wyprowadza samo.

Zakładanie, że nieznany token jest bezpieczny, bo pojawił się w portfelu. Każdy może utworzyć mint i ci go wysłać, a minty mogą nosić nazwy naśladujące prawdziwe tokeny. Pojawienie się tokena w skarbcu nie jest rekomendacją. Zweryfikuj adres mintu w oficjalnym źródle, zanim potraktujesz saldo jako realną wartość.

Oczekiwanie zatwierdzeń w stylu Ethereum. Tokeny SPL mają mechanizm delegata, ale wzorzec stałego przyzwolenia, który czyni z zatwierdzeń ERC-20 powracające ryzyko, nie jest tym, jak buduje się większość aplikacji na Solanie. Jeśli przychodzisz z Ethereum, zatwierdzenia tokenów: uprawnienia, które wciąż przyznajesz tłumaczy nawyk, którego się oduczasz, a Ethereum w SSP daje porównanie.

Zapomnienie o dopłacie przy pierwszym wysłaniu. Dodatkowe ~0,0025 SOL przy pierwszym przelewie do nowego odbiorcy to czynsz, a nie opłata pobierana przez SSP. Zostaje na koncie tokena odbiorcy i jest przez niego do odzyskania, jeśli kiedyś je zamknie.

Po mechanikę krok po kroku rzeczywistego przelewu sięgnij do wysyłania Solany z SSP. O tym, jak SSP trzyma sam skarbiec w multisigu 2 z 2 bez twórcy, zacznij od Solana w SSP.