Files
xrpl-dev-portal/@l10n/ja/docs/references/protocol/transactions/common-fields.md
Rome Reginelli fe279a1f63 Merge pull request #3164 from XRPLF/update_tx_ref_tables
Update internal data types in reference docs
2025-07-17 15:13:46 -07:00

22 KiB
Raw Blame History

html, parent, seo, labels
html parent seo labels
transaction-common-fields.html transaction-formats.html
description
どのトランザクションについても、共通する一連のフィールドがあります。
トランザクション送信

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

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

フィールド JSONの型 [内部の型][] 説明
Account 文字列 AccountID (必須) トランザクションを開始したアカウントの一意アドレス。
TransactionType 文字列 UInt16 (必須) トランザクションのタイプ。有効なタイプは、PaymentOfferCreateOfferCancelTrustSetAccountSetSetRegularKeySignerListSetEscrowCreateEscrowFinishEscrowCancelPaymentChannelCreatePaymentChannelFundPaymentChannelClaimDepositPreauthです。
Fee 文字列 Amount (必須。自動入力可能 整数で表したXRPの額drop単位。このトランザクションをネットワークに送信するためのコストとして消却されます。トランザクションのタイプによっては、最小要件が異なります。詳細は、[トランザクションコスト][]をご覧ください。
Sequence 符号なし整数 UInt32 (必須。自動入力可能 トランザクションを開始したアカウントに関連付けられた、トランザクションのシーケンス番号。トランザクションが有効とみなされるのは、そのSequence番号が、同一のアカウントの直前トランザクションよりも1大きい場合のみです。保留中のトランザクションをSequence番号を使用して無効にする方法については、トランザクションのキャンセルまたはスキップをご覧ください。
AccountTxnID 文字列 UInt256 (省略可) 別のトランザクションを識別するためのハッシュ値。このハッシュがある場合、このトランザクションが有効になるのは、送信側のアカウントの直前送信トランザクションがこのハッシュと一致しているときのみです。
Flags 符号なし整数 UInt32 (省略可) このトランザクションのビットフラグのセット。
LastLedgerSequence 数値 UInt32 (省略可。使用を強く推奨) このトランザクションを登録できるレジャーインデックスの最大値。このフィールドを指定することにより、トランザクションが検証または拒否されるのを待たなければならない期間の上限を設定することができます。詳細は、信頼できるトランザクションの送信をご覧ください。
NetworkID Number UInt32 (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 (署名時に自動追加) このトランザクションが、発信元であると主張しているアカウントから発信されたものであることを検証するための署名。

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

AccountTxnID

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

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

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

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

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

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

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

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

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

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

Flagsフィールド

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

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

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

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

グローバルフラグ

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

フラグの名前 16進値 10進値 説明
tfFullyCanonicalSig 0x80000000 2147483648 (使用を強く推奨) 完全に正規である署名を要求します。
tfInnerBatchTxn 0x40000000 1073741824 このフラグは [Batchトランザクション][] の内部トランザクションである場合にのみ使用されます。これは、トランザクションが署名されていないことを示します。このフラグを含む通常のトランザクションは拒否されます。

[signメソッド][](または「署名と送信」モードの[submitメソッド][])を使用すると、rippledは、Flagsフィールドがすでに存在している場合を除き、tfFullyCanonicalSigフラグを有効にした状態でFlagsフィールドを追加します。tfFullyCanonicalSigフラグは、Flagsが明示的に指定されている場合、自動的には有効になりません。また、[sign_forメソッド][]を使用してマルチシグトランザクションに署名を追加する場合も、自動的には有効になりません

{% admonition type="danger" name="警告" %}tfFullyCanonicalSigを有効にしない場合は、不正使用者がトランザクションの署名を改変して、期待されるものとは別のハッシュを使用してトランザクションを成功させることが理論上可能になります。最悪の場合、同一の支払を何回も送信するようシステムに仕掛けられるおそれがあります。この問題を回避するには、署名するすべてのトランザクションでtfFullyCanonicalSigフラグを有効にします。{% /admonition %}

フラグの範囲

トランザクションのFlagsフィールドでは、さまざまなレベルや状況に適用されるフラグを設定できます。個々の状況に関するフラグは、以下の範囲に限定されます。

範囲の名前 ビットマスク 説明
ユニバーサルフラグ 0xff000000 すべてのタイプのトランザクションに対して一様に適用されるフラグ。
タイプに基づくフラグ 0x00ff0000 フラグを使用するトランザクションのタイプに応じて意味が異なるフラグ。
予約済みのフラグ 0x0000ffff 現時点では定義されていないフラグ。トランザクションが有効になるのは、これらのフラグが無効になっている場合のみです。

{% admonition type="info" name="注記" %}[AccountSetトランザクション][]タイプには、タイプに基づくフラグと似た目的を果たすビット単位ではない独自のフラグがあります。レジャーオブジェクトにも、さまざまなビット単位のフラグが定義されるFlagsフィールドがあります。{% /admonition %}

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"
}

NetworkIDフィールド

{% badge href="https://github.com/XRPLF/rippled/releases/tag/1.11.0" %}新規: rippled 1.11.0{% /badge %}

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

ネットワーク ID NetworkIDフィールド
Mainnet 0 使用不可
Testnet 1 使用不可
Devnet 2 使用不可
Batch Testnet 21336 必須
Xahau Mainnet 21337 必須
Xahau Testnet 21338 必須
JS Hooks Testnet 31338 必須

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

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

Signersフィールド

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

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

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

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

{% raw-partial file="/docs/_snippets/common-links.md" /%}