Keychain stellt über alle Backends hinweg eine gemeinsame SolanaSigner-Basisschnittstelle
bereit. Bei den meisten Backends ist die Wahl daher betrieblicher, 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 Backends ändert daher, wie Sie den Signer aufrufen. Deshalb gilt:
Gehen Sie von Ihren Anforderungen aus, nicht von einem Produkt. Zwei Fragen entscheiden
den Großteil: Wo liegt der private Schlüssel, und wer darf eine Signatur damit autorisieren?
Jedes Backend außer Ledger ist in allen vier Sprachen verfügbar (Rust, TypeScript,
Python und Go). Ledger gibt es nur für Rust, hinter dem optionalen Feature ledger.
Ein einzelnes bestes Backend gibt es nicht. Jedes passt besser zu bestimmten Rahmenbedingungen: der Cloud, die Sie bereits nutzen, der Frage, ob Sie Schlüsselinfrastruktur selbst betreiben möchten, und den Verwahrungs- und Freigabekontrollen, die Sie erfüllen müssen. Das folgende Ablaufdiagramm ordnet diese Rahmenbedingungen einem Backend zu.
Dieser Leitfaden behandelt das Signieren über das Backend (serverseitig). Wenn Ihre Endnutzer ihre eigenen Transaktionen in einem Browser signieren, verwenden Sie stattdessen eine Wallet über den Wallet Standard. Siehe Signieren in der Produktion.
Entscheidungsablauf
Lokale Entwicklung und Tests benötigen nichts davon: Verwenden Sie das Memory-Backend für Prototypen 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 verwaltet werden (Consumer-Apps, Onboarding-Abläufe), verwenden Sie ein Embedded-/Managed-Wallet-Backend: 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-Freigaben, institutionelle Verwahrung oder regulatorische Kontrollen?
Wenn Signaturen vor ihrer Erstellung eine Freigaberichtlinie, 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 MPC-/Institutional-Custody-Backend: 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 den KMS der jeweiligen 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 einsetzen, verwenden Sie HashiCorp Vault. Sie betreiben und prüfen es selbst; der Schlüssel verbleibt in der Transit-Engine und signiert auf Anfrage.
Verwahrungsmodelle
Die Backends lassen sich in sechs Verwahrungsmodelle einteilen. Der obige Ablauf führt Sie zu einem davon.
- Selbstverwahrung (im Prozess): Ihre Anwendung hält den rohen privaten Schlüssel. Praktisch für die Entwicklung, aber ungeeignet für die Produktion. Backend: Memory.
- Selbstverwahrung (Hardware-Wallet): Der Schlüssel verlässt das Ledger-Gerät nie, und eine Person bestätigt jede Signatur auf dessen Display. Geeignet für interaktives Signieren durch Operatoren, nicht für unbeaufsichtigte Dienste. Nur Rust, optional und nicht vom Audit abgedeckt. Backend: Ledger.
- Selbstgehostetes Schlüsselmanagement: Sie betreiben die Schlüsselinfrastruktur; der Schlüssel verbleibt 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 und institutionelle Verwahrung: Der Schlüssel wird aufgeteilt oder bei einem Anbieter verwahrt, der gemäß Ihrer Richtlinie (Freigaben, Limits) mitsigniert. Backends: Fireblocks, Dfns, Para, Utila, Fordefi.
- Embedded und Managed Wallets: Ein Anbieter verwaltet Wallets in Ihrem Auftrag, oft für das Onboarding von Endnutzern. 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 | Selbstverwahrung (Hardware-Wallet) | Interaktives Signieren durch Operatoren aus Rust-Tools | Nur Rust, optionales Feature ledger, ungeprüft; 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 | Blackbox: 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 |
Funktionsumfang
Über die Verwahrung hinaus hat jedes Backend genau eine Transaktionsform, und sie 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 Blackbox-Modus.
- Umschreiben und signieren: Der Anbieter schreibt die Transaktion um und signiert sie dann, ohne sie zu senden. Machen Sie mit der zurückgegebenen Transaktion weiter. Fordefi im nativen manuellen Modus.
- Signieren und senden: Der Anbieter signiert und sendet serverseitig, sodass ein Fehler nicht bedeutet, dass nichts übermittelt wurde. Crossmint und Fordefi im nativen Auto-Modus.
Die Signer-Capabilities-Tabelle in der README der jeweiligen Sprache listet die Form jedes Backends auf; das Sicherheitsmodell erklärt, 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 einsetzen, ohne die Aufrufstellen zu ändern, solange die Backends dieselbe Funktionsform 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?