Keychain stellt eine einheitliche SolanaSigner-Basisschnittstelle für alle
Backends bereit, daher ist die Wahl bei den meisten Backends operativer, nicht
architektonischer Natur: Sie können sie später per Konfiguration ändern. Die
Ausnahme ist die Transaktionsform. Crossmint und der native Auto-Modus von
Fordefi signieren und senden serverseitig, und der native manuelle Modus von
Fordefi schreibt die Transaktion vor dem Signieren um. Ein Wechsel zu oder von
einem dieser Modi ändert daher, wie Sie den Signer aufrufen. Deshalb gilt:
Starten Sie von Ihren Anforderungen, nicht von einem Produkt. Zwei Fragen
entscheiden das meiste: Wo liegt der private Schlüssel, und wer darf eine
Signatur damit autorisieren?
Jedes Backend außer Ledger wird in allen vier Sprachen (Rust, TypeScript,
Python und Go) bereitgestellt. Ledger ist nur für Rust verfügbar, hinter dem
optionalen Feature ledger.
Es gibt kein einzelnes bestes Backend. Jedes passt besser zu einer bestimmten Kombination von Rahmenbedingungen: die Cloud, auf der Sie bereits arbeiten, ob Sie Schlüsselinfrastruktur selbst betreiben möchten und welche Verwahrungs- und Genehmigungskontrollen Sie erfüllen müssen. Das folgende Ablaufdiagramm ordnet diese Rahmenbedingungen einem Backend zu.
Dieser Leitfaden behandelt das Signieren im Backend (serverseitig). Wenn Ihre Endnutzer ihre eigenen Transaktionen in einem Browser signieren, verwenden Sie stattdessen eine Wallet über den Wallet Standard. Siehe Signing in Production.
Entscheidungsablauf
Lokale Entwicklung und Tests benötigen nichts davon: Verwenden Sie das Memory-Backend für Prototyping und wechseln Sie dann per Konfiguration zu einem der oben genannten Produktions-Backends.
Die Fragen durchgehen
Signieren Sie für Ihre eigene Anwendung oder für Ihre Endnutzer?
Wenn Sie Wallets bereitstellen, die Endnutzern gehören und von ihnen genutzt werden (Consumer-Apps, Onboarding-Abläufe), verwenden Sie ein Backend für eingebettete / verwaltete Wallets: Privy, Turnkey, CDP, Crossmint oder Openfort. Diese verwalten Wallets pro Nutzer und die Authentifizierung in Ihrem Auftrag.
Wenn Sie als Ihre eigene Anwendung signieren (Fee Payer, Treasury, Backend-Automatisierung), lesen Sie unten weiter.
Benötigen Sie Multi-Party-Genehmigung, institutionelle Verwahrung oder regulatorische Kontrollen?
Wenn Signaturen vor ihrer Erstellung eine Genehmigungsrichtlinie, ein Ausgabenlimit oder einen Compliance-Workflow durchlaufen müssen oder Sie einen regulierten Verwahrer benötigen, der die Schlüssel hält, verwenden Sie ein Backend für MPC / institutionelle Verwahrung: Fireblocks, Dfns, Para, Utila oder Fordefi. Diese teilen den Schlüssel auf oder verwahren ihn und signieren gemäß Ihrer Richtlinie mit.
Wenn Sie nur einen Schlüssel benötigen, der auf Anfrage signiert, lesen Sie unten weiter.
Möchten Sie den Schlüssel selbst halten oder von einem Anbieter halten lassen?
Wenn ein Cloud-Anbieter den Schlüssel in hardwaregestützter Infrastruktur halten soll und Ihre IAM-Richtlinie steuert, wer signieren darf, verwenden Sie das KMS dieser Cloud:
- Betrieb auf AWS → AWS KMS
- Betrieb auf GCP → GCP KMS
Wenn Sie die Schlüsselinfrastruktur selbst betreiben möchten oder Multi-Cloud bzw. On-Premises nutzen, verwenden Sie HashiCorp Vault. Sie betreiben und auditieren es selbst; der Schlüssel bleibt in der Transit-Engine und signiert auf Anfrage.
Verwahrungsmodelle
Die Backends lassen sich in sechs Verwahrungsmodelle gruppieren. Der obige Ablauf führt Sie zu einem davon.
- Eigenverwaltung (In-Process): Ihre Anwendung hält den rohen privaten Schlüssel. Praktisch für die Entwicklung, aber für die Produktion ungeeignet. Backend: Memory.
- Eigenverwaltung (Hardware-Wallet): Der Schlüssel verlässt nie das Ledger-Gerät, und eine Person bestätigt jede Signatur auf dessen Bildschirm. Geeignet für interaktives Signieren durch Operatoren, nicht für unbeaufsichtigte Dienste. Nur Rust, optional und nicht vom Audit abgedeckt. Backend: Ledger.
- Self-Hosted Key Management: Sie betreiben die Schlüsselinfrastruktur; der Schlüssel bleibt darin und signiert auf Anfrage. Backend: HashiCorp Vault.
- Cloud KMS / HSM: Ein Cloud-Anbieter speichert den Schlüssel in hardwaregestützter Infrastruktur; der Schlüssel verlässt den Dienst nie, und Ihre IAM-Richtlinie steuert, wer signieren darf. Backends: AWS KMS, GCP KMS.
- MPC & institutionelle Verwahrung: Der Schlüssel wird aufgeteilt oder bei einem Anbieter verwahrt, der gemäß Ihrer Richtlinie (Genehmigungen, Limits) mitsigniert. Backends: Fireblocks, Dfns, Para, Utila, Fordefi.
- Eingebettete & verwaltete Wallets: Ein Anbieter verwaltet Wallets in Ihrem Auftrag, oft um Endnutzer einzuführen. Backends: Privy, Turnkey, CDP, Crossmint, Openfort.
Backend-Vergleich
| Backend | Verwahrungsmodell | Am besten geeignet für | Hinweise |
|---|---|---|---|
| Memory | Eigenverwaltung (In-Process) | Lokale Entwicklung, Tests, CI | Roher Schlüssel im Prozess; nicht in der Produktion verwenden |
| Ledger | Eigenverwaltung (Hardware-Wallet) | Interaktives Signieren durch Operatoren aus Rust-Tools | Nur Rust, optionales Feature ledger, nicht auditiert; jede Signatur wird auf dem Gerät bestätigt |
| HashiCorp Vault | Self-Hosted Key Management | Teams mit eigener Schlüsselinfrastruktur | Transit Engine; Sie betreiben und prüfen es selbst |
| AWS KMS | Cloud KMS / HSM | Backends auf AWS | Schlüssel verlässt KMS nie; IAM steuert das Signieren |
| GCP KMS | Cloud KMS / HSM | Backends auf GCP | Schlüssel verlässt KMS nie; IAM steuert das Signieren |
| Fireblocks | MPC / institutionelle Verwahrung | Treasuries, Börsen, regulierte Verwahrung | Policy Engine und Genehmigungsworkflows |
| Dfns | MPC-Wallet-Infrastruktur | Programmgesteuerte Wallets mit Richtlinienkontrollen | Ed25519-Signierung |
| Para | MPC-Wallets | Apps, die MPC-gestützte Wallets wünschen | API-Schlüssel + Wallet-ID |
| Utila | MPC-Verwahrung + Co-Signer | Bestehende Utila-verwaltete Solana-Wallets | signMessage nicht unterstützt; Sie übertragen die Tx selbst |
| Fordefi | MPC / institutionelle Verwahrung | Institutionelle Verwahrung mit Richtlinienkontrollen | Black Box: Sie senden. Native Auto: Fordefi schreibt um und sendet. Native Manual: Fordefi schreibt um, Sie senden das Ergebnis |
| Privy | Eingebettete Wallets | Consumer-Apps zur Wallet-Einführung für Nutzer | App-verwaltete eingebettete Wallets |
| Turnkey | Nicht-verwahrendes Key Management | Programmgesteuertes, richtliniengesteuertes Signieren | Nicht-verwahrendes Key Management |
| CDP | Verwaltete Wallet (Coinbase) | Apps auf der Coinbase Developer Platform | signMessage akzeptiert nur UTF-8-Payloads |
| Crossmint | Verwaltete Wallets | Marktplätze und Apps mit verwalteten Wallets | Nur Senden: sendet serverseitig, kann für Gas-Sponsoring umschreiben; signMessage wird nicht unterstützt |
| Openfort | Eingebettete Backend-Wallets | Serverseitige Wallets | TEE-gespeicherte Schlüssel |
Capability-Form
Über die Verwahrung hinaus hat jedes Backend genau eine Transaktionsform, die bestimmt, wie Sie den Signer aufrufen:
- Signieren: Der Anbieter signiert die von Ihnen erstellten Bytes, und Sie senden sie selbst. Die meisten Backends, einschließlich Ledger und Fordefi im Black-Box-Modus.
- Umschreiben und signieren: Der Anbieter schreibt die Transaktion um und signiert sie anschließend, ohne sie zu senden. Fahren Sie mit der zurückgegebenen Transaktion fort. Fordefi im nativen manuellen Modus.
- Signieren und senden: Der Anbieter signiert und sendet serverseitig, sodass ein Fehler nicht bedeutet, dass nichts angekommen ist. Crossmint und Fordefi im nativen Auto-Modus.
Die Signer-Capabilities-Tabelle in der README jeder Sprache listet die Form jedes Backends auf; das Sicherheitsmodell erläutert, was jede Form garantiert.
Enterprise-Szenarien
Eine einzelne Anwendung benötigt oft mehrere davon gleichzeitig. Da die Schnittstelle gemeinsam genutzt wird, können Sie pro Rolle ein anderes Backend betreiben, ohne die Aufrufstellen zu ändern, solange die Backends dieselbe Capability-Form haben.
- Treasury-Operationen — trennen Sie einen operativen "Hot"-Signer von einem "Cold"-Treasury-Signer. Sichern Sie den Treasury mit MPC-Verwahrung oder einem Cloud-HSM ab und verlangen Sie Genehmigungsrichtlinien vor hochwertigen Signaturen.
- Genehmigungsworkflows — MPC- und Verwahrungsbackends (z. B. Fireblocks) erzwingen eine mehrseitige Genehmigung, bevor eine Signatur erstellt wird.
- Compliance und Audit — Cloud-KMS (AWS/GCP) und Vault erstellen Signatur-Audit-Logs; institutionelle Verwahrer ergänzen Richtliniendurchsetzung und Berichterstattung.
- Regulierte Umgebungen — bewahren Sie Schlüsselmaterial in einem HSM, KMS oder bei einem institutionellen Verwahrer auf, sodass rohe Schlüssel Ihre Anwendung niemals berühren.
Siehe Best Practices für den Produktionsbetrieb für den sicheren Betrieb dieser Backends.
Is this page helpful?