XRP Ledger Apex is back in Amsterdam

Register Now
Last updated
Edit

レギュラーキーペアの変更または削除

XRP Ledgerでは、アカウントはその後のトランザクションには レギュラーキーペア と呼ばれるセカンダリキーペアで署名することができます。アカウントのレギュラーキーペアが漏えいした場合、またはセキュリティ対策としてレギュラーキーペアを定期的に変更する必要がある場合は、SetRegularKeyトランザクションを使用してアカウントレギュラーキーペアを削除または変更します。

マスターキーペアとレギュラーキーペアの詳細は、暗号鍵をご覧ください。

レギュラーキーペアの変更

既存のレギュラーキーペアを変更する手順は、初めてレギュラーキーを割り当てる手順とほぼ同じです。キーペアを生成し、レギュラーキーペアとしてアカウントに割り当てます。これにより既存のレギュラーキーペアが上書きされます。ただし大きく異なる点は、既存のレギュラーキーペアを変更するときには既存のレギュラー秘密鍵を使用して秘密鍵自体を置き換えることができますが、レギュラーキーペアをアカウントに初めて割り当てるときにはアカウントのマスター秘密鍵を使用する必要があることです。

マスターキーペアとレギュラーキーペアの詳細は、暗号鍵をご覧ください。

レギュラーキーペアの削除

漏えいしたレギュラーキーペアを単にアカウントから削除する場合は、キーペアを最初に生成する必要はありません。RegularKeyフィールドを省略したSetRegularKeyトランザクションを使用します。アカウントの別の署名手段(マスターキーペアまたは署名者リスト)が現在有効になっていない場合は、トランザクションが失敗することに注意してください。

アカウントのレギュラーキーペアを削除する場合、SetRegularKeyトランザクションでは、アカウントのマスター秘密鍵(シークレット)または既存のレギュラーキーペアによる署名が必要です。マスター秘密鍵またはレギュラー秘密鍵の送信は危険であるため、トランザクションの署名とネットワークへのトランザクションの送信を切り離した2段階方式でこのトランザクションを実行します。

トランザクションの署名

トランザクションに署名する最も安全な方法は、クライアントライブラリを使用してローカルで署名することです。signメソッドを使用してトランザクションに署名することもできますが、その場合は信頼できる暗号化された接続を使用するか、ローカル接続を使用して、自分が管理しているサーバに対してのみに行うようにしてください。

いずれの場合も、後のために、署名したトランザクションの識別用ハッシュを書き留めておいてください。

リクエストフィールドに以下の値を指定します。

リクエストフィールド
Accountアカウントのアドレス。
secretアカウントのmaster_keymaster_seed、またはmaster_seed_hex(マスター秘密鍵またはレギュラー秘密鍵)

リクエストのフォーマット

リクエストのフォーマットの例:

  1. WebSocket
  2. JSON-RPC
  3. コマンドライン
{
 "command":"sign",
 "tx_json":{
     "TransactionType":"SetRegularKey",
     "Account":"r9xQZdFGwbwTB3g9ncKByWZ3du6Skm7gQ8"
     },
  "secret":"snoPBrXtMeMyMHUVTgbuqAfg1SUTb"
}

レスポンスのフォーマット

処理が成功したレスポンスの例:

  1. WebSocket
  2. JSON-RPC
  3. コマンドライン
{
 "result":{
   "tx_blob":"1200052280000000240000000268400000000000000A73210330E7FC9D56BB25D6893BA3F317AE5BCF33B3291BD63DB32654A313222F7FD02074473045022100CAB9A6F84026D57B05760D5E2395FB7BE86BF39F10DC6E2E69DC91238EE0970B022058EC36A8EF9EE65F5D0D8CAC4E88C8C19FEF39E40F53D4CCECBB59701D6D1E838114623B8DA4A0BFB3B61AB423391A182DC693DC159E",
   "tx_json":{
     "Account":"r9xQZdFGwbwTB3g9ncKByWZ3du6Skm7gQ8",
     "Fee":"10",
     "Flags":2147483648,
     "Sequence":2,
     "SigningPubKey":"0330E7FC9D56BB25D6893BA3F317AE5BCF33B3291BD63DB32654A313222F7FD020",
     "TransactionType":"SetRegularKey",
     "TxnSignature":"3045022100CAB9A6F84026D57B05760D5E2395FB7BE86BF39F10DC6E2E69DC91238EE0970B022058EC36A8EF9EE65F5D0D8CAC4E88C8C19FEF39E40F53D4CCECBB59701D6D1E83",
     "hash":"59BCAB8E5B9D4597D6A7BFF22F6C555D0F41420599A2E126035B6AF19261AD97"
   }
 },
 "status":"success",
 "type":"response"
}

signコマンドのレスポンスには上記のようなtx_blob値が含まれています。オフライン署名レスポンスにはsignedTransaction値が含まれています。いずれもトランザクションの署名済みバイナリ表現(ブロブ)です。

次にsubmitコマンドを使用して、トランザクションブロブ(tx_blobまたはsignedTransaction)をネットワークに送信します。

トランザクションの送信

オフライン署名レスポンスのsignedTransaction値、またはsignコマンドレスポンスのtx_blob値をとり、submitメソッドを使用してtx_blobとして送信します。

リクエストのフォーマット

リクエストのフォーマットの例:

  1. WebSocket
  2. JSON-RPC
  3. コマンドライン
{
   "command":"submit",
   "tx_blob":"1200052280000000240000000268400000000000000A73210330E7FC9D56BB25D6893BA3F317AE5BCF33B3291BD63DB32654A313222F7FD02074473045022100CAB9A6F84026D57B05760D5E2395FB7BE86BF39F10DC6E2E69DC91238EE0970B022058EC36A8EF9EE65F5D0D8CAC4E88C8C19FEF39E40F53D4CCECBB59701D6D1E838114623B8DA4A0BFB3B61AB423391A182DC693DC159E"
}

レスポンスのフォーマット

処理が成功したレスポンスの例:

  1. WebSocket
  2. JSON-RPC
  3. コマンドライン
{
 "result":{
   "engine_result":"tesSUCCESS",
   "engine_result_code":0,
   "engine_result_message":"The transaction was applied.Only final in a validated ledger.",
   "tx_blob":"1200052280000000240000000268400000000000000A73210330E7FC9D56BB25D6893BA3F317AE5BCF33B3291BD63DB32654A313222F7FD02074473045022100CAB9A6F84026D57B05760D5E2395FB7BE86BF39F10DC6E2E69DC91238EE0970B022058EC36A8EF9EE65F5D0D8CAC4E88C8C19FEF39E40F53D4CCECBB59701D6D1E838114623B8DA4A0BFB3B61AB423391A182DC693DC159E",
   "tx_json":{
     "Account":"r9xQZdFGwbwTB3g9ncKByWZ3du6Skm7gQ8",
     "Fee":"10",
     "Flags":2147483648,
     "Sequence":2,
     "SigningPubKey":"0330E7FC9D56BB25D6893BA3F317AE5BCF33B3291BD63DB32654A313222F7FD020",
     "TransactionType":"SetRegularKey",
     "TxnSignature":"3045022100CAB9A6F84026D57B05760D5E2395FB7BE86BF39F10DC6E2E69DC91238EE0970B022058EC36A8EF9EE65F5D0D8CAC4E88C8C19FEF39E40F53D4CCECBB59701D6D1E83",
     "hash":"59BCAB8E5B9D4597D6A7BFF22F6C555D0F41420599A2E126035B6AF19261AD97"
   }
 },
 "status":"success",
 "type":"response"
}

レギュラーキーペアの削除が成功したかどうかを確認するには、削除したレギュラー秘密鍵を使用してトランザクションを送信できないことを確認します。

前述のSetRegularKeyトランザクションにより削除されたレギュラー秘密鍵を使用してAccountSetトランザクションに署名した際のエラーレスポンスの例を以下に示します。

レスポンスのフォーマット

処理が成功したレスポンスの例:

  1. WebSocket
  2. JSON-RPC
  3. コマンドライン
{
 "error":"badSecret",
 "error_code":41,
 "error_message":"Secret does not match account.",
 "request":{
   "command":"submit",
   "secret":"snoPBrXtMeMyMHUVTgbuqAfg1SUTb",
   "tx_json":{
     "Account":"r9xQZdFGwbwTB3g9ncKByWZ3du6Skm7gQ8",
     "TransactionType":"AccountSet"
   }
 },
 "status":"error",
 "type":"response"
}

場合によっては、SetRegularKeyトランザクションを使用して、トランザクションコストを支払わずにKey Resetトランザクションを送信できます。FeeEscalation Amendmentを有効にすると、Key Resetトランザクションの名目トランザクションコストがゼロであっても、rippledは他のトランザクションよりもKey Resetトランザクションを優先します。