Een backend kiezen

Keychain biedt één SolanaSigner interface voor elke backend, waardoor de keuze operationeel is en niet architecturaal — u kunt deze later wijzigen via de configuratie. Begin daarom vanuit uw vereisten, niet vanuit een product. Twee vragen bepalen het meeste: waar bevindt de privésleutel zich, en wie mag een handtekening autoriseren?

Er is geen enkele beste backend. Elke backend is beter geschikt voor een bepaalde set beperkingen — de cloud waarop u al draait, of u sleutelinfrastructuur wilt beheren, en welke beheer- en goedkeuringscontroles u nodig heeft. De onderstaande flow koppelt die beperkingen aan een backend.

Deze handleiding behandelt backend-ondertekening (server-side). Wanneer uw eindgebruikers hun eigen transacties ondertekenen in een browser, gebruik dan een wallet via de Wallet Standard — zie Ondertekenen in Productie.

Beslissingsstroom

Choosing a Keychain backend

Lokale ontwikkeling en tests hebben dit allemaal niet nodig — gebruik de Memory-backend voor prototyping en schakel daarna via de configuratie over naar een van de bovenstaande productiebackends.

De vragen doorlopen

Ondertekent u voor uw eigen applicatie of voor uw eindgebruikers?

Als u wallets inricht die eindgebruikers bezitten en beheren (consumenten-apps, onboardingflows), gebruik dan een embedded / managed wallet-backend — Privy, Turnkey, CDP, Crossmint of Openfort. Deze beheren wallets per gebruiker en authenticatie namens u.

Als je tekent als je eigen applicatie — een fee payer, een treasury, backend-automatisering — ga dan hieronder verder.

Heb je goedkeuring van meerdere partijen, institutionele bewaring of regelgevende controles nodig?

Als handtekeningen een goedkeuringsbeleid, bestedingslimiet of complianceworkflow moeten doorlopen voordat ze worden gegenereerd — of als je een gereguleerde bewaarder nodig hebt die de sleutels beheert — gebruik dan een MPC / institutionele bewaring-backend: Fireblocks, Dfns, Para of Utila. Deze diensten splitsen of bewaren de sleutel en co-ondertekenen volgens jouw beleid.

Als je alleen een sleutel nodig hebt die op verzoek tekent, ga dan hieronder verder.

Wil je de sleutel zelf bewaren, of wil je dat een provider dat doet?

Als een cloudprovider de sleutel in hardware-ondersteunde infrastructuur moet bewaren en jouw IAM-beleid bepaalt wie kan tekenen, gebruik dan de KMS van die cloud:

  • Draaien op AWS → AWS KMS
  • Draaien op GCP → GCP KMS

Als je de sleutelinfrastructuur zelf wilt beheren — of je werkt multi-cloud of on-premises — gebruik dan HashiCorp Vault. Jij beheert en auditeert het; de sleutel blijft in de Transit-engine en tekent op verzoek.

Bewaarmodellen

De backends zijn ingedeeld in vijf bewaarmodellen. De bovenstaande flow leidt je naar een van hen.

  • Eigen beheer (in-process) — je applicatie bewaart de onbewerkte privésleutel. Handig voor ontwikkeling, maar ongeschikt voor productie. Backend: Memory.
  • Zelfgehoste sleutelbeheer — jij beheert de sleutelinfrastructuur; de sleutel blijft daarin en tekent op verzoek. Backend: HashiCorp Vault.
  • Cloud KMS / HSM — een cloudprovider bewaart de sleutel in hardware-ondersteunde infrastructuur; de sleutel verlaat de service nooit en jouw IAM-beleid bepaalt wie kan tekenen. Backends: AWS KMS, GCP KMS.
  • MPC & institutionele bewaring — de sleutel wordt gesplitst of bewaard door een provider, die mede-ondertekent volgens jouw beleid (goedkeuringen, limieten). Backends: Fireblocks, Dfns, Para, Utila.
  • Embedded & beheerde wallets — een provider beheert wallets namens jou, vaak om eindgebruikers te onboarden. Backends: Privy, Turnkey, CDP, Crossmint, Openfort.

Backend vergelijking

BackendBewaarmodelHet beste voorOpmerkingen
MemoryZelfbeheer (in-process)Lokale ontwikkeling, tests, CIRuwe sleutel in proces — niet gebruiken in productie
HashiCorp VaultZelfgehoste sleutelbeheerTeams die hun eigen sleutelinfrastructuur beherenTransit engine; u beheert en auditeert het zelf
AWS KMSCloud KMS / HSMBackends die op AWS draaienSleutel verlaat KMS nooit; IAM beheert ondertekening
GCP KMSCloud KMS / HSMBackends die op GCP draaienSleutel verlaat KMS nooit; IAM beheert ondertekening
FireblocksMPC / institutioneel beheerTreasuries, exchanges, gereguleerd beheerBeleidsmotor en goedkeuringsworkflows
DfnsMPC-walletinfrastructuurProgrammatische wallets met beleidscontrolesEd25519-ondertekening
ParaMPC-walletsApps die MPC-ondersteunde wallets willenAPI-sleutel + wallet-ID
UtilaMPC-beheer + co-ondertekenaarBestaande door Utila beheerde Solana-walletssignMessage niet ondersteund; u verstuurt de tx zelf
PrivyIngebedde walletsConsumenten-apps die gebruikers onboardenDoor app beheerde ingebedde wallets
TurnkeyNiet-custodiale sleutelbeheerProgrammatisch, door beleid beheerd ondertekenenNiet-custodiale sleutelbeheer
CDPBeheerde wallet (Coinbase)Apps op het Coinbase Developer PlatformsignMessage accepteert alleen UTF-8-payloads
CrossmintBeheerde walletsMarktplaatsen en beheerde-wallet-appssmart en mpc wallets; signMessage niet ondersteund
OpenfortIngebedde backend-walletsServer-side walletsIn TEE opgeslagen sleutels

Zakelijke scenario's

Een enkele applicatie heeft vaak meer dan één van deze tegelijk nodig. Omdat de interface identiek is, kun je per rol een andere backend gebruiken zonder de aanroeplocaties te wijzigen.

  • Treasurybeheer — scheid een operationele "hot" ondertekenaar van een "cold" treasury-ondertekenaar. Ondersteun de treasury met MPC-bewaring of een cloud-HSM en vereist goedkeuringsbeleid voorafgaand aan hoogwaardige handtekeningen.
  • Goedkeuringsworkflows — MPC- en bewaarbackends (bijv. Fireblocks) vereisen meervoudige goedkeuring voordat een handtekening wordt gegenereerd.
  • Compliance en audit — cloud-KMS (AWS/GCP) en Vault genereren auditlogboeken van ondertekeningen; institutionele bewaarders voegen beleidshandhaving en rapportage toe.
  • Gereguleerde omgevingen — bewaar sleutelmateriaal in een HSM, KMS of institutionele bewaarder zodat ruwe sleutels uw applicatie nooit bereiken.

Zie Best practices voor productie voor het veilig beheren van deze backends.

Is this page helpful?

© 2026 Solana Foundation. Alle rechten voorbehouden.