トランザクションの共通フィールド
どのトランザクションについても、共通する一連のフィールドに加え、トランザクションのタイプに応じた追加のフィールドがあります。フィールドの名前では、大文字と小文字が区別されます。すべてのトランザクションに共通するフィールドは、以下のとおりです。
フィールド | JSONの型 | 内部の型 | 説明 |
---|---|---|---|
Account | 文字列 | AccountID | (必須) トランザクションを開始したアカウントの一意アドレス。 |
TransactionType | 文字列 | UInt16 | (必須) トランザクションのタイプ。有効なタイプは、Payment 、OfferCreate 、OfferCancel 、TrustSet 、AccountSet 、SetRegularKey 、SignerListSet 、EscrowCreate 、EscrowFinish 、EscrowCancel 、PaymentChannelCreate 、PaymentChannelFund 、PaymentChannelClaim 、DepositPreauth です。 |
Fee | 文字列 | Amount | (必須。自動入力可能) 整数で表したXRPの額(drop単位)。このトランザクションをネットワークに送信するためのコストとして消却されます。トランザクションのタイプによっては、最小要件が異なります。詳細は、トランザクションコストを参照してください。 |
Sequence | 符号なし整数 | UInt32 | (必須。自動入力可能) トランザクションを開始したアカウントに関連付けられた、トランザクションのシーケンス番号。トランザクションが有効とみなされるのは、そのSequence 番号が、同一のアカウントの直前トランザクションよりも1大きい場合のみです。保留中のトランザクションをSequence 番号を使用して無効にする方法については、トランザクションのキャンセルまたはスキップを参照してください。 |
AccountTxnID | 文字列 | Hash256 | (省略可) 別のトランザクションを識別するためのハッシュ値。このハッシュがある場合、このトランザクションが有効になるのは、送信側のアカウントの直前送信トランザクションがこのハッシュと一致しているときのみです。 |
Flags | 符号なし整数 | UInt32 | (省略可) このトランザクションのビットフラグのセット。 |
LastLedgerSequence | 数値 | UInt32 | (省略可。使用を強く推奨) このトランザクションを登録できるレジャーインデックスの最大値。このフィールドを指定することにより、トランザクションが検証または拒否されるのを待たなければならない期間の上限を設定することができます。詳細は、信頼できるトランザクションの送信を参照してください。 |
Memos | オブジェクトの配列 | 配列 | (省略可) このトランザクションの識別に使用される任意の追加情報。 |
Signers | 配列 | 配列 | (省略可) このトランザクションを承認するためのマルチ署名を表すオブジェクトの配列。 |
SourceTag | 符号なし整数 | UInt32 | (省略可) この支払いの理由、またはこのトランザクションの実行元である送信者を識別するために使用される任意の整数。一般的に、返金については、最初の支払いのSourceTag を返金のDestinationTag として指定する必要があります。 |
SigningPubKey | 文字列 | Blob | (署名時に自動追加) このトランザクションへの署名に使用される秘密鍵に対応する公開鍵の16進表現。空文字列の場合は、代わりにSigners フィールドにマルチ署名が保持されていることを示します。 |
TxnSignature | 文字列 | Blob | (署名時に自動追加) このトランザクションが、発信元であると主張しているアカウントから発信されたものであることを検証するための署名。 |
: トランザクションのPreviousTxnID
フィールドは、AccountTxnIDフィールドに置き換えられました。この文字列/Hash256フィールドは、過去に発生したトランザクションの一部に記述されています。このフィールドは、一部のレジャーオブジェクトにあるPreviousTxnID
という同じ名前のフィールドとは無関係です。
AccountTxnID
AccountTxnID
フィールドにより、直前のトランザクション(シーケンス番号で識別)も有効で、かつ期待するトランザクションに一致しない限り、現在のトランザクションが有効にならないよう、トランザクションどうしをチェーンにすることができます。
このフィールドが有用になるのは、例えば、トランザクション送信用のプライマリーシステムと受動的なバックアップシステムを運用している場合です。受動的なバックアップシステムがプライマーリから切断されたものの、プライマリが完全に稼働停止となったわけではなく、両システムが同時に稼働を開始した場合は、トランザクションが2回送信される、あるいはまったく送信されないなど、深刻な問題が発生するおそれがあります。AccountTxnID
を使用してトランザクションどうしをチェーンにすると、両方のシステムがアクティブになったときも、有効なトランザクションを送信できるのはいずれか一方のみとなります。
AccountTxnIDを使用するには、アカウントの1つ前のトランザクションのIDがレジャーで追跡されるよう、最初にasfAccountTxnIDフラグを設定する必要があります。
自動入力可能なフィールド
一部のフィールドについては、トランザクションの署名前に、rippled
サーバーによって、または署名に使用されるripple-lib などのライブラリーによって値を自動入力できます。値を自動入力するには、最新の状態を取得するためのXRP Ledgerへのアクティブな接続が必要です。したがって、オフラインでは実行できません。ripple-lib とrippled
のどちらも、以下の値を自動的に提供できます。
-
Fee
- ネットワークに基づいてトランザクションコストを自動的に入力します。注記:
rippled
のsignメソッドを使用するときは、fee_mult_max
パラメーターとfee_mult_div
パラメーターを使用して、自動入力値の上限を設定できます。 -
Sequence
- トランザクションを送信する側のアカウントの次のシーケンス番号を自動的に使用します。
本番システムについては、これらのフィールドの値がサーバーによって入力される状態に しない ことをお勧めします。例えば、ネットワークの負荷が一時的に急上昇したためにトランザクションコストが高騰した場合、トランザクションによっては、一時的な高額のコストを支払うよりも、必要に応じて待機し、コストが低下してから送信したほうが好ましいことがあります。
PaymentトランザクションタイプのPaths
フィールドについても、値を自動入力できます。
Flagsフィールド
Flags
フィールドには、トランザクションの行動を調整する各種のオプションを設定できます。オプションは、ビット単位のOR操作と組み合わせることで複数のフラグを同時に設定できるバイナリー値として表現します。
トランザクションで所定のフラグが有効になっているかどうかを確認するには、ビット単位のAND演算子をフラグの値とFlags
フィールドで使用します。結果が0の場合は無効になっていることを示し、結果がフラグ値と等しい場合は有効になっていることを示します(その他の結果の場合は、実行した操作に誤りがあることを示します)。
ほとんどのフラグは、特定のタイプのトランザクションに対してのみ効果があります。複数のタイプのトランザクションに対して、同一のビット単位値をフラグに再利用できるため、フラグの設定と読み取りではTransactionType
フィールドに留意することが重要です。
フラグとして定義しないビットは、0にする必要があります(fix1543 Amendmentでは、一部のタイプのトランザクションについて、このルールが適用されます。デフォルトでは、ほとんどのタイプのトランザクションでこのルールが強制されます)。
グローバルフラグ
すべてのトランザクションにグローバルに適用される唯一のフラグは、以下のとおりです。
フラグの名前 | 16進値 | 10進値 | 説明 |
---|---|---|---|
tfFullyCanonicalSig | 0x80000000 | 2147483648 | (使用を強く推奨) 完全に正規である署名を要求します。 |
signメソッド(または「署名と送信」モードのsubmitメソッド)を使用すると、rippled
は、Flags
フィールドがすでに存在している場合を除き、tfFullyCanonicalSig
フラグを有効にした状態でFlags
フィールドを追加します。tfFullyCanonicalSig
フラグは、Flags
が明示的に指定されている場合、自動的には有効になりません。また、sign_forメソッドを使用してマルチ署名済みトランザクションに署名を追加する場合も、自動的には有効になりません。
警告: tfFullyCanonicalSig
を有効にしない場合は、不正使用者がトランザクションの署名を改変して、期待されるものとは別のハッシュを使用してトランザクションを成功させることが理論上可能になります。最悪の場合、同一の支払を何回も送信するようシステムに仕掛けられるおそれがあります。この問題を回避するには、署名するすべてのトランザクションでtfFullyCanonicalSig
フラグを有効にします。
フラグの範囲
トランザクションのFlags
フィールドでは、さまざまなレベルや状況に適用されるフラグを設定できます。個々の状況に関するフラグは、以下の範囲に限定されます。
範囲の名前 | ビットマスク | 説明 |
---|---|---|
ユニバーサルフラグ | 0xff000000 |
すべてのタイプのトランザクションに対して一様に適用されるフラグ。 |
タイプに基づくフラグ | 0x00ff0000 |
フラグを使用するトランザクションのタイプに応じて意味が異なるフラグ。 |
予約済みのフラグ | 0x0000ffff |
現時点では定義されていないフラグ。トランザクションが有効になるのは、これらのフラグが無効になっている場合のみです。 |
注記: AccountSetトランザクションタイプには、タイプに基づくフラグと似た目的を果たすビット単位ではない独自のフラグがあります。レジャーオブジェクトにも、さまざまなビット単位のフラグが定義されるFlags
フィールドがあります。
Memosフィールド
Memos
フィールドは、トランザクションに関する任意のメッセージデータを保持します。このフィールドは、オブジェクトの配列として表現します。各オブジェクトには唯一のフィールドMemo
があり、このフィールドは、以下のフィールドを1つ以上持つ別のオブジェクトを保持しています。
フィールド | 型 | 内部の型 | 説明 |
---|---|---|---|
MemoData | 文字列 | Blob | 通例、メモの内容を保持する任意の16進値。 |
MemoFormat | 文字列 | Blob | URLで使用できる文字を表現する16進値。通例、メモのエンコード方法に関する情報を保持しています(MIMEタイプ など)。 |
MemoType | 文字列 | Blob | URLで使用できる文字を表現する16進値。通例、このメモのフォーマットを定義する一意の関係(RFC 5988 に準拠)。 |
MemoTypeフィールドとMemoFormatフィールドには、以下の文字のみを使用できます。 ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz0123456789-._~:/?#[]@!$&'()*+,;=%
Memos
フィールドのサイズの上限は1KBです(バイナリーフォーマットでシリアル化されている場合)。
以下に、Memosフィールドが定義されているトランザクションの例を示します。
{
"TransactionType": "Payment",
"Account": "rMmTCjGFRWPz8S2zAUUoNVSQHxtRQD4eCx",
"Destination": "r3kmLJN5D28dHuH8vZNUZpMC43pEHpaocV",
"Memos": [
{
"Memo": {
"MemoType": "687474703a2f2f6578616d706c652e636f6d2f6d656d6f2f67656e65726963",
"MemoData": "72656e74"
}
}
],
"Amount": "1"
}
Signersフィールド
Signers
フィールドには、最大8つのキーペアから取得された署名を保持し、トランザクションを承認するためのマルチ署名が含まれています。Signers
リストはオブジェクトの配列であり、各オブジェクトが1つのSigner
フィールドを保持しています。Signer
フィールドには、以下の入れ子フィールドがあります。
フィールド | 型 | 内部の型 | 説明 |
---|---|---|---|
Account | 文字列 | AccountID | SignerListに記述され、この署名に関連付けられているアドレス。 |
TxnSignature | 文字列 | Blob | SigningPubKey を使用して検証できる、このトランザクションの署名。 |
SigningPubKey | 文字列 | Blob | この署名の作成に使用される公開鍵。 |
SigningPubKey
は、Account
アドレスに関連付けられているキーでなければなりません。参照されているAccount
が、レジャーにあり資金供給済みアカウントである場合、SigningPubKeyには、そのアカウントの現在のレギュラーキー(設定されている場合)を指定できます。また、lsfDisableMasterフラグが有効になっている場合を除き、そのアカウントのマスターキーを指定することもできます。参照されているAccount
アドレスが、レジャーの資金供給済みのアカウントではない場合、SigningPubKey
は、そのアドレスに関連付けられているマスターキーでなければなりません。
署名の検証は大量の演算能力を消費するタスクであるため、マルチ署名済みトランザクションをネットワークに中継するには、追加のXRPがコストとしてかかります。マルチ署名に含まれている署名ごとに、トランザクションに必要なトランザクションコストが増加します。例えば、トランザクションをネットワークに中継するための現在の最小トランザクションコストが10000
dropである場合、Signers
配列に3つのエントリーが含まれているマルチ署名済みトランザクションを中継するには、Fee
の値を少なくとも40000
dropにする必要があります。