Keychain udostępnia jeden bazowy interfejs SolanaSigner dla każdego backendu, więc w
większości przypadków wybór ma charakter operacyjny, a nie architektoniczny: możesz go zmienić
później w konfiguracji. Wyjątkiem jest kształt transakcji. Crossmint
oraz tryb natywny auto w Fordefi podpisują i rozgłaszają transakcje po stronie serwera, a tryb natywny
manual w Fordefi przepisuje transakcję przed jej podpisaniem, więc przejście na jeden
z nich lub z niego zmienia sposób wywoływania signera. Dlatego zacznij od swoich
wymagań, a nie od produktu. Większość decyzji wynika z dwóch pytań: gdzie
znajduje się klucz prywatny i kto może autoryzować jego użycie do podpisu?
Każdy backend poza Ledgerem jest dostępny we wszystkich czterech językach (Rust, TypeScript,
Python i Go). Ledger jest dostępny tylko w Rust, za opcjonalną funkcją ledger.
Nie istnieje jeden najlepszy backend. Każdy z nich lepiej pasuje do określonego zestawu ograniczeń: chmury, na której już działasz, tego, czy chcesz samodzielnie obsługiwać infrastrukturę kluczy, oraz wymaganych kontroli przechowywania i zatwierdzania. Poniższy schemat przypisuje te ograniczenia do odpowiedniego backendu.
Ten przewodnik dotyczy podpisywania po stronie backendu (serwera). Jeśli Twoi użytkownicy końcowi podpisują własne transakcje w przeglądarce, użyj zamiast tego portfela za pośrednictwem Wallet Standard. Zobacz Podpisywanie w środowisku produkcyjnym.
Schemat decyzyjny
Lokalne środowisko programistyczne i testy nie wymagają niczego z tego: użyj backendu Memory do prototypowania, a następnie przełącz się na jeden z powyższych backendów produkcyjnych w konfiguracji.
Analiza pytań
Czy podpisujesz dla własnej aplikacji, czy dla użytkowników końcowych?
Jeśli udostępniasz portfele, których właścicielami i operatorami są użytkownicy końcowi (aplikacje konsumenckie, procesy onboardingu), użyj backendu portfeli osadzonych / zarządzanych: Privy, Turnkey, CDP, Crossmint lub Openfort. Zarządzają one portfelami poszczególnych użytkowników i uwierzytelnianiem w Twoim imieniu.
Jeśli podpisujesz jako własna aplikacja (płatnik opłat, skarbiec, automatyzacja backendu), czytaj dalej.
Czy potrzebujesz zatwierdzania wielostronnego, instytucjonalnego przechowywania kluczy lub kontroli regulacyjnych?
Jeśli podpisy muszą przejść politykę zatwierdzeń, limit wydatków lub proces zgodności, zanim zostaną wygenerowane, albo potrzebujesz regulowanego depozytariusza przechowującego klucze, użyj backendu MPC / przechowywania instytucjonalnego: Fireblocks, Dfns, Para, Utila lub Fordefi. Dzielą one klucz lub go przechowują i współpodpisują zgodnie z Twoją polityką.
Jeśli potrzebujesz tylko klucza, który podpisuje na żądanie, czytaj dalej.
Chcesz samodzielnie przechowywać klucz, czy powierzyć to dostawcy?
Jeśli dostawca chmury ma przechowywać klucz w infrastrukturze opartej na sprzęcie, a Twoja polityka IAM kontroluje, kto może podpisywać, użyj KMS tej chmury:
- Działasz na AWS → AWS KMS
- Działasz na GCP → GCP KMS
Jeśli chcesz samodzielnie obsługiwać infrastrukturę kluczy albo korzystasz z wielu chmur lub z infrastruktury on-prem, użyj HashiCorp Vault. Sam go uruchamiasz i audytujesz; klucz pozostaje wewnątrz silnika Transit i podpisuje na żądanie.
Modele przechowywania kluczy
Backendy dzielą się na sześć modeli przechowywania kluczy. Powyższy schemat prowadzi do jednego z nich.
- Samodzielne przechowywanie (w procesie): Twoja aplikacja przechowuje surowy klucz prywatny. Wygodne w trakcie developmentu, ale nieodpowiednie dla produkcji. Backend: Memory.
- Samodzielne przechowywanie (portfel sprzętowy): klucz nigdy nie opuszcza urządzenia Ledger, a człowiek potwierdza każdy podpis na jego ekranie. Odpowiednie do interaktywnego podpisywania przez operatora, a nie do usług działających bez nadzoru. Tylko Rust, opcjonalne i nieobjęte audytem. Backend: Ledger.
- Samodzielnie hostowane zarządzanie kluczami: sam obsługujesz infrastrukturę kluczy; klucz pozostaje wewnątrz niej i podpisuje na żądanie. Backend: HashiCorp Vault.
- Cloud KMS / HSM: dostawca chmury przechowuje klucz w infrastrukturze opartej na sprzęcie; klucz nigdy nie opuszcza usługi, a Twoja polityka IAM kontroluje, kto może podpisywać. Backendy: AWS KMS, GCP KMS.
- MPC i przechowywanie instytucjonalne: klucz jest dzielony lub przechowywany u dostawcy, który współpodpisuje zgodnie z Twoją polityką (zatwierdzenia, limity). Backendy: Fireblocks, Dfns, Para, Utila, Fordefi.
- Portfele osadzone i zarządzane: dostawca zarządza portfelami w Twoim imieniu, często w celu onboardingu użytkowników końcowych. Backendy: Privy, Turnkey, CDP, Crossmint, Openfort.
Porównanie backendów
| Backend | Model przechowywania kluczy | Najlepszy dla | Uwagi |
|---|---|---|---|
| Memory | Samodzielna opieka (w procesie) | Lokalne środowisko deweloperskie, testy, CI | Surowy klucz w procesie; nie używaj w produkcji |
| Ledger | Samodzielne przechowywanie (portfel sprzętowy) | Interaktywne podpisywanie przez operatora z narzędzi Rust | Tylko Rust, opcjonalna funkcja ledger, bez audytu; każdy podpis potwierdzany na urządzeniu |
| HashiCorp Vault | Samodzielnie hostowane zarządzanie kluczami | Zespoły posiadające własną infrastrukturę kluczy | Silnik Transit; samodzielna obsługa i audyt |
| AWS KMS | Chmurowy KMS / HSM | Backendy działające na AWS | Klucz nigdy nie opuszcza KMS; IAM kontroluje podpisywanie |
| GCP KMS | Chmurowy KMS / HSM | Backendy działające na GCP | Klucz nigdy nie opuszcza KMS; IAM kontroluje podpisywanie |
| Fireblocks | MPC / instytucjonalna opieka | Skarbce, giełdy, regulowana opieka nad aktywami | Silnik reguł i przepływy zatwierdzania |
| Dfns | Infrastruktura portfeli MPC | Programowe portfele z kontrolą reguł | Podpisywanie Ed25519 |
| Para | Portfele MPC | Aplikacje wymagające portfeli opartych na MPC | Klucz API + ID portfela |
| Utila | Opieka MPC + współpodpisujący | Istniejące portfele Solana zarządzane przez Utila | signMessage nieobsługiwane; transakcja rozgłaszana samodzielnie |
| Fordefi | MPC / instytucjonalna opieka | Instytucjonalna opieka nad kluczami z kontrolą polityk | Czarna skrzynka: Ty wysyłasz. Natywny auto: Fordefi przepisuje i wysyła. Natywny manual: Fordefi przepisuje, a Ty wysyłasz wynik |
| Privy | Wbudowane portfele | Aplikacje konsumenckie wprowadzające użytkowników do portfeli | Wbudowane portfele zarządzane przez aplikację |
| Turnkey | Niedepozytatywne zarządzanie kluczami | Programowe, zabezpieczone regułami podpisywanie | Niedepozytatywne zarządzanie kluczami |
| CDP | Zarządzany portfel (Coinbase) | Aplikacje na platformie Coinbase Developer Platform | signMessage akceptuje wyłącznie payloady UTF-8 |
| Crossmint | Zarządzane portfele | Platformy handlowe i aplikacje z zarządzanymi portfelami | Tylko wysyłanie: rozgłasza po stronie serwera, może przepisywać na potrzeby sponsorowania gazu; signMessage nieobsługiwane |
| Openfort | Wbudowane portfele backendowe | Portfele po stronie serwera | Klucze przechowywane w TEE |
Kształt możliwości
Poza przechowywaniem kluczy każdy backend ma jeden kształt transakcji, który decyduje o tym, jak wywołujesz signera:
- Podpisanie: dostawca podpisuje bajty, które zbudowałeś, a Ty je rozgłaszasz. Większość backendów, w tym Ledger i tryb czarnej skrzynki Fordefi.
- Przepisanie i podpisanie: dostawca przepisuje transakcję, a następnie ją podpisuje bez rozgłaszania. Kontynuuj od zwróconej transakcji. Tryb natywny manual w Fordefi.
- Podpisanie i rozgłoszenie: dostawca podpisuje i rozgłasza po stronie serwera, więc błąd nie oznacza, że nic nie trafiło do sieci. Crossmint i tryb natywny auto w Fordefi.
Tabela możliwości signerów w README każdego języka wymienia kształt każdego backendu; model bezpieczeństwa wyjaśnia, co gwarantuje każdy z tych kształtów.
Scenariusze dla przedsiębiorstw
Pojedyncza aplikacja często potrzebuje kilku z nich jednocześnie. Ponieważ interfejs jest wspólny, możesz uruchomić inny backend dla każdej roli bez zmiany miejsc wywołań, o ile backendy mają ten sam kształt możliwości.
- Operacje skarbcowe — oddziel operacyjny podpisujący "hot" od "cold" podpisującego skarbcowego. Zabezpiecz skarbiec za pomocą przechowywania MPC lub sprzętowego modułu HSM w chmurze i wymagaj polityk zatwierdzania przed podpisami wysokiej wartości.
- Przepływy zatwierdzania — backendy MPC i custody (np. Fireblocks) wymuszają wielostronne zatwierdzenie przed wygenerowaniem podpisu.
- Zgodność i audyt — chmurowe KMS (AWS/GCP) i Vault emitują dzienniki audytu podpisywania; instytucjonalni depozytariusze dodają egzekwowanie polityk i raportowanie.
- Środowiska regulowane — przechowuj materiał kluczowy w HSM, KMS lub instytucjonalnym depozycie, aby surowe klucze nigdy nie dotykały twojej aplikacji.
Zobacz Najlepsze praktyki produkcyjne dotyczące bezpiecznego obsługiwania tych backendów.
Is this page helpful?