最終更新:
編集

トランザクションの共通フィールド

どのトランザクションについても、共通する一連のフィールドに加え、トランザクションのタイプに応じた追加のフィールドがあります。フィールドの名前では、大文字と小文字が区別されます。すべてのトランザクションに共通するフィールドは、以下のとおりです。

フィールドJSONの型内部の型説明
Account文字列AccountID(必須) トランザクションを開始したアカウントの一意アドレス。
TransactionType文字列UInt16(必須) トランザクションのタイプ。有効なタイプは、PaymentOfferCreateOfferCancelTrustSetAccountSetSetRegularKeySignerListSetEscrowCreateEscrowFinishEscrowCancelPaymentChannelCreatePaymentChannelFundPaymentChannelClaimDepositPreauthです。
Fee文字列Amount(必須。自動入力可能 整数で表したXRPの額(drop単位)。このトランザクションをネットワークに送信するためのコストとして消却されます。トランザクションのタイプによっては、最小要件が異なります。詳細は、トランザクションコストをご覧ください。
Sequence符号なし整数UInt32(必須。自動入力可能 トランザクションを開始したアカウントに関連付けられた、トランザクションのシーケンス番号。トランザクションが有効とみなされるのは、そのSequence番号が、同一のアカウントの直前トランザクションよりも1大きい場合のみです。保留中のトランザクションをSequence番号を使用して無効にする方法については、トランザクションのキャンセルまたはスキップをご覧ください。
AccountTxnID文字列Hash256(省略可) 別のトランザクションを識別するためのハッシュ値。このハッシュがある場合、このトランザクションが有効になるのは、送信側のアカウントの直前送信トランザクションがこのハッシュと一致しているときのみです。
Flags符号なし整数UInt32(省略可) このトランザクションのビットフラグのセット。
LastLedgerSequence数値UInt32(省略可。使用を強く推奨) このトランザクションを登録できるレジャーインデックスの最大値。このフィールドを指定することにより、トランザクションが検証または拒否されるのを待たなければならない期間の上限を設定することができます。詳細は、信頼できるトランザクションの送信をご覧ください。
NetworkIDNumberUInt32(Network-specific) The network ID of the chain this transaction is intended for. MUST BE OMITTED for Mainnet and some test networks. REQUIRED on chains whose network ID is 1025 or higher.
Memosオブジェクトの配列配列(省略可) このトランザクションの識別に使用される任意の追加情報。
Signers配列配列(省略可) このトランザクションを承認するためのマルチシグを表すオブジェクトの配列。
SourceTag符号なし整数UInt32(省略可) この支払いの理由、またはこのトランザクションの実行元である送信者を識別するために使用される任意の整数。一般的に、返金については、最初の支払いのSourceTagを返金のDestinationTagとして指定する必要があります。
SigningPubKey文字列Blob(署名時に自動追加) このトランザクションへの署名に使用される秘密鍵に対応する公開鍵の16進表現。空文字列の場合は、代わりにSignersフィールドにマルチシグが保持されていることを示します。
TxnSignature文字列Blob(署名時に自動追加) このトランザクションが、発信元であると主張しているアカウントから発信されたものであることを検証するための署名。

削除: rippled 0.28.0: トランザクションのPreviousTxnIDフィールドは、AccountTxnIDフィールドに置き換えられました。この文字列/Hash256フィールドは、過去に発生したトランザクションの一部に記述されています。このフィールドは、一部のレジャーオブジェクトにあるPreviousTxnIDという同じ名前のフィールドとは無関係です。

AccountTxnID

AccountTxnIDフィールドにより、直前のトランザクション(シーケンス番号で識別)も有効で、かつ期待するトランザクションに一致しない限り、現在のトランザクションが有効にならないよう、トランザクションどうしをチェーンにすることができます。

このフィールドが有用になるのは、例えば、トランザクション送信用のプライマリーシステムと受動的なバックアップシステムを運用している場合です。受動的なバックアップシステムがプライマーリから切断されたものの、プライマリが完全に稼働停止となったわけではなく、両システムが同時に稼働を開始した場合は、トランザクションが2回送信される、あるいはまったく送信されないなど、深刻な問題が発生するおそれがあります。AccountTxnIDを使用してトランザクションどうしをチェーンにすると、両方のシステムがアクティブになったときも、有効なトランザクションを送信できるのはいずれか一方のみとなります。

AccountTxnIDを使用するには、アカウントの1つ前のトランザクションのIDがレジャーで追跡されるよう、最初にasfAccountTxnIDフラグを設定する必要があります。

自動入力可能なフィールド

一部のフィールドについては、トランザクションの署名前に、rippledサーバによって、または署名に使用されるripple-libなどのライブラリーによって値を自動入力できます。値を自動入力するには、最新の状態を取得するためのXRP Ledgerへのアクティブな接続が必要です。したがって、オフラインでは実行できません。ripple-librippledのどちらも、以下の値を自動的に提供できます。

  • Fee - ネットワークに基づいてトランザクションコストを自動的に入力します。

    注記:rippledsignメソッドを使用するときは、fee_mult_maxパラメーターとfee_div_maxパラメーターを使用して、自動入力値の上限を設定できます。

  • Sequence - トランザクションを送信する側のアカウントの次のシーケンス番号を自動的に使用します。

本番システムについては、これらのフィールドの値がサーバによって入力される状態に しない ことをお勧めします。例えば、ネットワークの負荷が一時的に急上昇したためにトランザクションコストが高騰した場合、トランザクションによっては、一時的な高額のコストを支払うよりも、必要に応じて待機し、コストが低下してから送信したほうが好ましいことがあります。

PaymentトランザクションタイプのPathsフィールドについても、値を自動入力できます。

Flagsフィールド

Flagsフィールドには、トランザクションの行動を調整する各種のオプションを設定できます。オプションは、ビット単位のOR操作と組み合わせることで複数のフラグを同時に設定できるバイナリー値として表現します。

トランザクションで所定のフラグが有効になっているかどうかを確認するには、ビット単位のAND演算子をフラグの値とFlagsフィールドで使用します。結果が0の場合は無効になっていることを示し、結果がフラグ値と等しい場合は有効になっていることを示します(その他の結果の場合は、実行した操作に誤りがあることを示します)。

ほとんどのフラグは、特定のタイプのトランザクションに対してのみ効果があります。複数のタイプのトランザクションに対して、同一のビット単位値をフラグに再利用できるため、フラグの設定と読み取りではTransactionTypeフィールドに留意することが重要です。

フラグとして定義しないビットは、0にする必要があります(fix1543 Amendmentでは、一部のタイプのトランザクションについて、このルールが適用されます。デフォルトでは、ほとんどのタイプのトランザクションでこのルールが強制されます)。

グローバルフラグ

すべてのトランザクションにグローバルに適用される唯一のフラグは、以下のとおりです。

フラグの名前16進値10進値説明
tfFullyCanonicalSig0x800000002147483648(使用を強く推奨) 完全に正規である署名を要求します。

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文字列BlobURLで使用できる文字を表現する16進値。通例、メモのエンコード方法に関する情報を保持しています(MIMEタイプなど)。
MemoType文字列BlobURLで使用できる文字を表現する16進値。通例、このメモのフォーマットを定義する一意の関係(RFC 5988に準拠)。

MemoTypeフィールドとMemoFormatフィールドには、以下の文字のみを使用できます。 ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz0123456789-._~:/?#[]@!$&'()*+,;=%

Memosフィールドのサイズの上限は1KBです(バイナリーフォーマットでシリアル化されている場合)。

以下に、Memosフィールドが定義されているトランザクションの例を示します。

{
    "TransactionType": "Payment",
    "Account": "rMmTCjGFRWPz8S2zAUUoNVSQHxtRQD4eCx",
    "Destination": "r3kmLJN5D28dHuH8vZNUZpMC43pEHpaocV",
    "Memos": [
        {
            "Memo": {
                "MemoType": "687474703a2f2f6578616d706c652e636f6d2f6d656d6f2f67656e65726963",
                "MemoData": "72656e74"
            }
        }
    ],
    "Amount": "1"
}

NetworkIDフィールド

新規: rippled 1.11.0

NetworkIDフィールドは「クロスチェーン」トランザクションのリプレイ攻撃に対する保護であり、同じトランザクションがコピーされ、意図していないネットワークで実行されることを防ぎます。既存のチェーンとの互換性のため、ネットワークIDが1024以下のネットワークではNetworkIDフィールドを省略する必要がありますが、ネットワークIDが1025以上のネットワークではNetworkIDフィールドを含める必要があります。以下の表は、さまざまな既知のネットワークのステータスと値を示しています。

ネットワークIDNetworkIDフィールド
Mainnet0使用不可
Testnet1使用不可
Devnet2使用不可
Batch Testnet21336必須
Xahau Mainnet21337必須
Xahau Testnet21338必須
JS Hooks Testnet31338必須

トランザクションのリプレイ攻撃は理論的には可能ですが、2つ目のネットワークに特定の条件が必要です。次のすべてが真でなければなりません。

  • トランザクションの送信者が2つ目のネットワーク上の資金提供アカウントである。
  • 2つ目のネットワーク上の送信者のSequenceがトランザクションのSequenceと一致するか、トランザクションが第二のネットワークで利用可能なTicketを使用している。
  • トランザクションがLastLedgerSequenceフィールドを持っていないか、2つ目レジャーの現在のレジャーインデックスよりも高い値を指定している。
    • メインネットは一般的に、テストネットワークやサイドチェーンよりもレジャーインデックスが高いため、トランザクションがLastLedgerSequenceを本来の意図通りに使用している場合、メインネットのトランザクションをサイドチェーンやテストネットワークでリプレイする方が現実的です。
  • ネットワークが両方とも1024以下のIDを持っているか、両方のネットワークが同じIDを使用しているか、2つ目のネットワークがNetworkIDフィールドを必要としないかのいずれか。

Signersフィールド

Signersフィールドには、最大8つのキーペアから取得された署名を保持し、トランザクションを承認するためのマルチシグが含まれています。Signersリストはオブジェクトの配列であり、各オブジェクトが1つのSignerフィールドを保持しています。Signerフィールドには、以下の入れ子フィールドがあります。

フィールド内部の型説明
Account文字列AccountIDSignerListに記述され、この署名に関連付けられているアドレス。
TxnSignature文字列BlobSigningPubKeyを使用して検証できる、このトランザクションの署名。
SigningPubKey文字列Blobこの署名の作成に使用される公開鍵。

SigningPubKeyは、Accountアドレスに関連付けられているキーでなければなりません。参照されているAccountが、レジャーにあり資金供給済みアカウントである場合、SigningPubKeyには、そのアカウントの現在のレギュラーキー(設定されている場合)を指定できます。また、lsfDisableMasterフラグが有効になっている場合を除き、そのアカウントのマスターキーを指定することもできます。参照されているAccountアドレスが、レジャーの資金供給済みのアカウントではない場合、SigningPubKeyは、そのアドレスに関連付けられているマスターキーでなければなりません。

署名の検証は大量の演算能力を消費するタスクであるため、マルチシグトランザクションをネットワークに中継するには、追加のXRPがコストとしてかかります。マルチシグに含まれている署名ごとに、トランザクションに必要なトランザクションコストが増加します。例えば、トランザクションをネットワークに中継するための現在の最小トランザクションコストが10000dropである場合、Signers配列に3つのエントリが含まれているマルチシグトランザクションを中継するには、Feeの値を少なくとも40000dropにする必要があります。