トランザクションは、必要なすべての署名者からの有効な
署名が含まれている場合にのみ実行されます。ローカル開発では通常、Keypairとして鍵を保持し、直接署名します。本番環境では、重要な問いは異なります：秘密鍵はどこに保存され、誰がその鍵で署名を承認できるのか？
秘密鍵をクライアントサイドのコードに埋め込んだり、フロントエンドにバンドルしたり、ソース管理にコミットしたりしないでください。鍵を取得した人は誰でも、そのアカウントの資金を完全に制御できるようになります。
署名アプローチ
| アプローチ | 鍵の保存場所 | 署名者 | 最適な用途 |
|---|---|---|---|
| ローカルkeypair | マシン上のファイルまたは環境変数 | コードが直接署名 | ローカル開発、テスト、CI |
| ブラウザウォレット | エンドユーザーのウォレット（例：Phantom、Solflare） | エンドユーザーがトランザクションごとに署名 | ユーザーが自身のトランザクションに署名するフロントエンドdApp |
| クラウドKMS / HSM | ハードウェアバックエンドの鍵サービス（AWS KMS、GCP KMS、Vault） | バックエンドがサービスに署名を要求 | バックエンドサービス、資金管理、規制された環境 |
| マネージド / MPCウォレット | プロバイダーのインフラ全体で分割または管理 | プロバイダーがポリシーに従って共同署名 | 組み込みウォレット、承認ワークフロー、機関向けカストディ |
ローカルkeypairは、生のキーマテリアルをアプリケーション内に直接保持する唯一のアプローチです。本番環境向けのアプローチはすべて、専用のインフラストラクチャにキーを保管し、そのインフラストラクチャが代わりに署名を行います。
バックエンド署名
サーバーが署名を行う必要がある場合（手数料の支払い、プログラムトランザクションの送信、またはトレジャリーの運用など）、生のkeypairではなく専用のキー管理バックエンドを使用してください。Solana
FoundationはKeychainを提供しています。これは、上記の表に含まれるすべてのバックエンド（Memory、HashiCorp
Vault、AWS KMS、GCP
KMS、Fireblocks、Privy、Turnkey、CDP、Crossmint、Dfns、Para、Openfort、Utila）にわたって統一されたSolanaSignerインターフェースを提供する、RustおよびTypeScript対応の統合署名ライブラリです。
インターフェースはすべてのバックエンドで共通のため、開発時はインメモリキーを使用し、アプリケーションコードを書き直すことなく設定変更だけで本番バックエンドに切り替えることができます。Keychainは@solana/kitおよびRust SDKと互換性があります。
キー管理、RPCセキュリティ、監視を含む本番環境向けの完全なチェックリストについては、本番環境への対応をご覧ください。
Is this page helpful?