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