Dieser Leitfaden richtet sich an Wallet-Dienstanbieter und Entwickler, die neue
Schlüsselverwaltungslösungen in die solana-keychain-Bibliothek integrieren
möchten. Durch das Hinzufügen Ihrer Signer-Implementierung ermöglichen Sie
Entwicklern, Ihren Dienst für die sichere Signierung von Solana-Transaktionen
über eine einheitliche Schnittstelle zu nutzen.
Verwenden Sie ein LLM? Schauen Sie sich die Skill zum Hinzufügen von Signern an.
Architekturübersicht
Die Bibliothek verwendet eine Trait-basierte Architektur, bei der alle Signer
das in src/traits.rs definierte SolanaSigner-Trait implementieren. Die
Bibliothek bietet außerdem ein einheitliches Signer-Enum, das alle
Implementierungen umschließt und eine Laufzeitauswahl der Signatur-Backends
ermöglicht, während eine konsistente API beibehalten wird.
Schnelle Integrationscheckliste
- Erstellen Sie Ihr Signer-Modul mit Implementierung
- Implementieren Sie das
SolanaSigner-Trait (3 asynchrone Methoden +pubkey()) - Fügen Sie ein Feature-Flag in
Cargo.tomlhinzu - Aktualisieren Sie das
Signer-Enum insrc/lib.rs(4 match-Zweige) - Aktualisieren Sie
src/error.rsreqwestFromimpl cfg gate (falls Ihr Signer reqwest verwendet) - Erzwingen Sie HTTPS und konfigurieren Sie Timeouts für HTTP-Clients
- Fügen Sie umfassende Tests hinzu
- Aktualisieren Sie die Dokumentation
- Reichen Sie einen PR ein
Schritt 1: Erstellen Sie Ihr Signer-Modul
Erstellen Sie ein neues Verzeichnis unter src/ für Ihre Implementierung:
src/├── your_service/│ ├── mod.rs # Main implementation with SolanaSigner trait│ └── types.rs # API request/response types (if needed)
Schritt 2: Definieren Sie Ihre Signer-Struktur
Definieren Sie in src/your_service/mod.rs Ihre Signer-Struktur:
//! YourService API signer integrationuse crate::{error::SignerError, traits::SolanaSigner};use solana_sdk::{pubkey::Pubkey, signature::Signature, transaction::Transaction};use std::str::FromStr;/// YourService-based signer using YourService's API#[derive(Clone)]pub struct YourServiceSigner {api_key: String,api_secret: String,wallet_id: String,api_base_url: String,client: reqwest::Client,public_key: Pubkey,}impl std::fmt::Debug for YourServiceSigner {fn fmt(&self, f: &mut std::fmt::Formatter<'_>) -> std::fmt::Result {f.debug_struct("YourServiceSigner").field("public_key", &self.public_key).finish_non_exhaustive()}}
Schritt 3: Implementieren Sie Konstruktor- und Hilfsmethoden
Remote-Signer müssen HTTPS erzwingen und HTTP-Timeouts konfigurieren.
Verwenden Sie die gemeinsame HttpClientConfig-Struktur für
Timeout-Einstellungen.
use crate::http_client_config::HttpClientConfig;impl YourServiceSigner {pub fn new(api_key: String,api_secret: String,wallet_id: String,public_key: String,http_config: Option<HttpClientConfig>,) -> Result<Self, SignerError> {let pubkey = Pubkey::from_str(&public_key).map_err(|e| SignerError::InvalidPublicKey(format!("Invalid public key: {e}")))?;let http = http_config.unwrap_or_default();let builder = reqwest::Client::builder().timeout(http.resolved_request_timeout()).connect_timeout(http.resolved_connect_timeout());// Enforce HTTPS in production; wiremock uses HTTP in tests#[cfg(not(test))]let builder = builder.https_only(true);let client = builder.build().map_err(|e| {SignerError::ConfigError(format!("Failed to build HTTP client: {e}"))})?;Ok(Self {api_key,api_secret,wallet_id,api_base_url: "https://api.yourservice.com/v1".to_string(),client,public_key: pubkey,})}/// Sign raw bytes using your service's APIasync fn sign(&self, message: &[u8]) -> Result<Signature, SignerError> {let encoded_message = base64::engine::general_purpose::STANDARD.encode(message);let url = format!("{}/sign", self.api_base_url);let response = self.client.post(&url).header("Authorization", format!("Bearer {}", self.api_key)).json(&serde_json::json!({"wallet_id": self.wallet_id,"message": encoded_message,})).send().await?;// Use generic error messages — never expose raw API response textif !response.status().is_success() {let status = response.status().as_u16();return Err(SignerError::RemoteApiError(format!("YourService API returned status {status}")));}// Parse response — always use map_err, never .expect() or .unwrap()let response_data: SignResponse = response.json().await.map_err(|e| SignerError::SerializationError(format!("Failed to parse response: {e}")))?;let sig_bytes = base64::engine::general_purpose::STANDARD.decode(&response_data.signature).map_err(|e| SignerError::SerializationError(format!("Failed to decode signature: {e}")))?;let sig_array: [u8; 64] = sig_bytes.try_into().map_err(|_| SignerError::SigningFailed("Invalid signature length".to_string()))?;Ok(Signature::from(sig_array))}}
Schritt 4: Implementieren Sie das SolanaSigner-Trait
Das Trait hat 3 asynchrone Methoden (sign_transaction, sign_message,
is_available) plus pubkey(). Beachten Sie, dass sign_transaction
SignTransactionResult zurückgibt – ein getaggtes Enum, das angibt, ob die
Transaktion vollständig oder teilweise signiert ist.
Verwenden Sie die gemeinsamen TransactionUtil-Hilfsfunktionen zum Signieren
und Serialisieren.
use crate::transaction_util::TransactionUtil;use crate::traits::SignTransactionResult;#[async_trait::async_trait]impl SolanaSigner for YourServiceSigner {fn pubkey(&self) -> Pubkey {self.public_key}async fn sign_transaction(&self,tx: &mut Transaction,) -> Result<SignTransactionResult, SignerError> {let tx_bytes = bincode::serialize(tx).map_err(|e| SignerError::SerializationError(format!("Failed to serialize: {e}")))?;let signature = self.sign(&tx_bytes).await?;// Add the signature at the correct positionTransactionUtil::add_signature_to_transaction(tx, &self.public_key, signature)?;// Serialize and classify as Complete or Partiallet serialized = TransactionUtil::serialize_transaction(tx)?;Ok(TransactionUtil::classify_signed_transaction(tx,(serialized, signature),))}async fn sign_message(&self, message: &[u8]) -> Result<Signature, SignerError> {self.sign(message).await}async fn is_available(&self) -> bool {let url = format!("{}/health", self.api_base_url);self.client.get(&url).send().await.map(|r| r.status().is_success()).unwrap_or(false)}}
Schritt 5: API-Typen hinzufügen (Optional)
Wenn Ihre API benutzerdefinierte Typen benötigt, erstellen Sie
src/your_service/types.rs:
use serde::{Deserialize, Serialize};#[derive(Serialize)]pub struct SignRequest {pub wallet_id: String,pub message: String,}#[derive(Deserialize)]pub struct SignResponse {pub signature: String,}
Schritt 6: Feature-Flag hinzufügen
Aktualisieren Sie Cargo.toml, um Ihren Signer als optionales Feature
hinzuzufügen:
[features]default = ["memory"]memory = []vault = ["dep:reqwest", "dep:vaultrs", "dep:base64"]privy = ["dep:reqwest", "dep:base64"]turnkey = ["dep:reqwest", "dep:base64", "dep:p256", "dep:hex", "dep:chrono"]your_service = ["dep:reqwest", "dep:base64"] # Add your featureall = ["memory", "vault", "privy", "turnkey", "your_service"] # Update all
Schritt 7: Signer-Enum aktualisieren
Fügen Sie Ihren Signer zu src/lib.rs hinzu. Sie benötigen 4 Match-Arme in der
SolanaSigner-Implementierung: pubkey, sign_transaction, sign_message und
is_available.
// Add feature-gated module#[cfg(feature = "your_service")]pub mod your_service;// Re-export your signer type#[cfg(feature = "your_service")]pub use your_service::YourServiceSigner;// Add to Signer enum#[derive(Debug)]pub enum Signer {#[cfg(feature = "memory")]Memory(MemorySigner),// ... existing variants#[cfg(feature = "your_service")]YourService(YourServiceSigner), // Add your variant}// Add constructor methodimpl Signer {#[cfg(feature = "your_service")]pub fn from_your_service(api_key: String,api_secret: String,wallet_id: String,public_key: String,) -> Result<Self, SignerError> {Ok(Self::YourService(YourServiceSigner::new(api_key,api_secret,wallet_id,public_key,None, // uses default HttpClientConfig)?))}}// Update trait implementation — 4 match arms#[async_trait::async_trait]impl SolanaSigner for Signer {fn pubkey(&self) -> sdk_adapter::Pubkey {match self {// ... existing variants#[cfg(feature = "your_service")]Signer::YourService(s) => s.pubkey(),}}async fn sign_transaction(&self,tx: &mut sdk_adapter::Transaction,) -> Result<SignTransactionResult, SignerError> {match self {// ... existing variants#[cfg(feature = "your_service")]Signer::YourService(s) => s.sign_transaction(tx).await,}}async fn sign_message(&self,message: &[u8],) -> Result<sdk_adapter::Signature, SignerError> {match self {// ... existing variants#[cfg(feature = "your_service")]Signer::YourService(s) => s.sign_message(message).await,}}async fn is_available(&self) -> bool {match self {// ... existing variants#[cfg(feature = "your_service")]Signer::YourService(s) => s.is_available().await,}}}
Wenn Ihr Signer reqwest verwendet, fügen Sie Ihr Feature dem
#[cfg(any(...))]-Gate bei der From<reqwest::Error>-Implementierung in
src/error.rs hinzu.
Schritt 8: Umfassende Tests hinzufügen
Fügen Sie Tests zu Ihrem Modul hinzu (am Ende von src/your_service/mod.rs):
#[cfg(test)]mod tests {use super::*;use solana_sdk::{signature::Keypair, signer::Signer};use wiremock::{matchers::{header, method, path},Mock, MockServer, ResponseTemplate,};#[tokio::test]async fn test_new() {let keypair = Keypair::new();let signer = YourServiceSigner::new("test-key".to_string(),"test-secret".to_string(),"test-wallet".to_string(),keypair.pubkey().to_string(),None,);assert!(signer.is_ok());}#[tokio::test]async fn test_sign_message() {let mock_server = MockServer::start().await;let keypair = Keypair::new();let message = b"test message";let signature = keypair.sign_message(message);Mock::given(method("POST")).and(path("/sign")).respond_with(ResponseTemplate::new(200).set_body_json(serde_json::json!({"signature": base64::engine::general_purpose::STANDARD.encode(signature.as_ref())}))).expect(1).mount(&mock_server).await;let mut signer = YourServiceSigner::new("test-key".to_string(),"test-secret".to_string(),"test-wallet".to_string(),keypair.pubkey().to_string(),None,).unwrap();signer.api_base_url = mock_server.uri();let result = signer.sign_message(message).await;assert!(result.is_ok());}#[tokio::test]async fn test_sign_unauthorized() {let mock_server = MockServer::start().await;let keypair = Keypair::new();Mock::given(method("POST")).and(path("/sign")).respond_with(ResponseTemplate::new(401)).expect(1).mount(&mock_server).await;let mut signer = YourServiceSigner::new("bad-key".to_string(),"bad-secret".to_string(),"test-wallet".to_string(),keypair.pubkey().to_string(),None,).unwrap();signer.api_base_url = mock_server.uri();let result = signer.sign_message(b"test").await;assert!(result.is_err());}}
Schritt 9: Dokumentation aktualisieren
Fügen Sie Ihren Signer zur Tabelle der unterstützten Backends in der README.md hinzu:
| Backend | Anwendungsfall | Feature-Flag |
|---|---|---|
| Memory | Lokale Schlüsselpaare, Entwicklung, Testing | memory |
| Vault | Enterprise-Schlüsselverwaltung mit HashiCorp Vault | vault |
| Privy | Eingebettete Wallets mit Privy-Infrastruktur | privy |
| Turnkey | Nicht-verwaltete Schlüsselverwaltung über Turnkey | turnkey |
| IhrService | Kurze Beschreibung Ihres Dienstes | your_service |
Fügen Sie ein Verwendungsbeispiel hinzu:
use solana_keychain::{Signer, SolanaSigner};#[tokio::main]async fn main() -> Result<(), Box<dyn std::error::Error>> {let signer = Signer::from_your_service("your-api-key".to_string(),"your-api-secret".to_string(),"your-wallet-id".to_string(),"your-public-key".to_string(),)?;let pubkey = signer.pubkey();println!("Public key: {}", pubkey);Ok(())}
Testen Ihrer Integration
Führen Sie Tests für Ihr Feature aus:
# Test only your signercargo test --features your_service# Test with all featurescargo test --all-features
TypeScript-Signer
Wenn Sie auch ein TypeScript-Signer-Paket hinzufügen, erstellen Sie es unter
typescript/packages/your-signer/. Wichtige Muster:
- Factory-Funktion
createYourSigner()gibtSolanaSigner<TAddress>zurück - Config-Interface exportieren (
YourSignerConfig) - HTTPS auf
apiBaseUrlConfig-Feldern erzwingen - Fehlertext der Remote-API mit
sanitizeRemoteErrorResponse()aus@solana/keychain-corebereinigen - Gegen fehlerhaftes JSON mit Optional Chaining und try/catch absichern
throwSignerError(SignerErrorCode.*, { cause, message })aus@solana/keychain-coreverwenden@throwsJSDoc zu Factory-Funktionen hinzufügen, die Fehlercodes auflisten
Umbrella-Paket aktualisieren
typescript/packages/keychain/ aktualisieren — 6 zu modifizierende Dateien:
src/types.ts—YourSignerConfigzurKeychainSignerConfigdiskriminierten Union hinzufügensrc/create-keychain-signer.ts— Factory importieren, Switch-Case hinzufügensrc/resolve-address.ts— Zum Fast-Path- oder Fetch-Path-Switch-Case hinzufügensrc/index.ts— Config-Typ, Namespace, Factory-Funktion und Klassen-Exporte hinzufügenpackage.json—@solana/keychain-your-signer: "workspace:*"Abhängigkeit hinzufügentsconfig.json—{ "path": "../your-signer" }Referenz hinzufügen
Die Switch-Anweisungen haben vollständige never Prüfungen — TypeScript wirft
einen Fehler, wenn Sie zur Union hinzufügen, aber einen Case verpassen.
Checkliste für die Einreichung
Vor dem Einreichen Ihres PRs:
- Code kompiliert ohne Warnungen (
just build) - Alle Tests bestehen (
just test) - Code ist formatiert/Linting besteht (
just fmt) - Keine hartcodierten Werte oder Secrets im Code
- Fehlermeldungen sind generisch (kein roher API-Antworttext)
- HTTPS auf Remote-HTTP-Clients erzwungen
- HTTP-Timeouts über
HttpClientConfigkonfiguriert - Folgt Rust-Namenskonventionen (snake_case)
- Zur README.md Tabelle unterstützter Backends hinzugefügt
Implementierungstipps
Fehlerbehandlung
Verwenden Sie immer die vorhandenen SignerError Varianten. Verwenden Sie
niemals .expect() oder .unwrap() bei nicht vertrauenswürdigen API-Antworten:
// Good — uses existing error types with generic messagesreturn Err(SignerError::RemoteApiError(format!("YourService API returned status {}", status)));// Good — converts from standard errorslet bytes = base64::decode(data).map_err(|e| SignerError::SerializationError(format!("Failed to decode: {e}")))?;
Best Practices für Sicherheit
- Niemals sensible Daten loggen (private Keys, API-Secrets)
DebugImplementierung verwenden, die sensible Felder verbirgt- Alle Eingaben validieren (öffentliche Keys, Signaturen)
- HTTPS für alle Remote-API-Aufrufe verwenden (erzwungen über
https_only(true)) - Request- und Connect-Timeouts über
HttpClientConfigkonfigurieren - Niemals rohen Remote-API-Fehlertext in Fehlermeldungen offenlegen
Option<Pubkey>(nichtPubkey::default()) für das Public-Key-Feld vorinit()verwenden
Testen mit Mocks
Verwenden Sie wiremock zum Mocken von HTTP-APIs. Prüfen Sie nur den Fehlertyp,
nicht den Fehlermeldungstext:
#[cfg(test)]mod tests {use wiremock::{MockServer, Mock, ResponseTemplate};#[tokio::test]async fn test_api_call() {let mock_server = MockServer::start().await;Mock::given(method("POST")).respond_with(ResponseTemplate::new(200)).mount(&mock_server).await;// Use mock_server.uri() as your api_base_url}}
Hilfe erhalten
- Überprüfen Sie vorhandene Signer-Implementierungen auf Muster:
src/memory/mod.rs— Einfach, synchronsrc/para/mod.rs— Erfordert Initialisierung (als Vorlage für neue Signer verwenden)src/turnkey/mod.rs— Komplexe Signaturverarbeitungsrc/vault/mod.rs— Externe Client-Bibliothek
- Wichtige Dateien:
src/traits.rs(Trait-Definition),src/transaction_util.rs(gemeinsame Hilfsfunktionen),src/http_client_config.rs(Timeout-Konfiguration) - Eröffnen Sie ein Issue für Design-Diskussionen, bevor Sie mit der Arbeit beginnen
Beispiel für eine PR-Struktur
feat(signer): add YourService signer integrationAdds support for YourService as a signing backend.- [X] Code compiles without warnings (`just build`)- [X] Code is formatted/linting passes (`just fmt`)- [X] Add comprehensive tests with wiremock - All tests pass (`just test`)- [X] Implemented SolanaSigner trait for YourServiceSigner- [X] Added feature flag 'your_service'- [X] HTTPS enforced, HTTP timeouts configured- [X] Added to README.md supported backends tableCloses #1337
Is this page helpful?