トランザクションの結果の確認
XRP Ledgerを効果的に使用するには、トランザクションの結果を次のように把握することが重要です。トランザクションは成功したか?トランザクションは何を遂行したか?失敗した場合は、なぜか?
XRP Ledgerは共有システムとなっていて、すべてのデータが公開された形で正確に記録され、データはそれぞれ新しいレジャーバージョンで安全に更新されます。誰もが任意のトランザクションの結果を確認し、トランザクションメタデータによってその実行内容を確認できます。
このドキュメントでは、トランザクションの結果がもたらされた理由を把握する方法について、詳細に説明します。エンドユーザ向けには、トランザクションの処理内容を表示するとわかりやすいです。例えば、XRPチャートを使用して、記録されたトランザクションについての説明を英語で参照できます。
前提条件
これらの手順で説明されているトランザクションの結果を理解するには、以下が必要となります。
- 理解する対象となるトランザクションがわかっている。トランザクションの識別用ハッシュがわかっていれば、それによりトランザクションを検索できます。また、最近のレジャーで実行されたトランザクションまたは特定のアカウントに最後に影響を及ぼしたトランザクションを確認することもできます。
- 信頼できる情報と、トランザクションの送信日時に関する必要な履歴を提供する
rippled
サーバにアクセスできる。- 最近送信したトランザクションの結果を確認する場合、トランザクションの送信時に使用したサーバがネットワークと同期されていれば、そのサーバにアクセスできるだけで十分です。
- 古いトランザクションの結果については、全履歴を記録するサーバを使用できます。
rippled
APIを直接使用してデータを確認する方法を説明します。1. トランザクションステータスの取得
トランザクションが成功したか失敗したかを確認するには、2つの問いが必要です。
- トランザクションが検証済みレジャーに記録されたか。
- 記録されていた場合、結果としてレジャーの状態はどのように変化したか。
検証済みレジャーにトランザクションが記録されていたかどうかを確認するには、通常、トランザクションが記録されている可能性のあるすべてのレジャーにアクセスする必要があります。最も簡単で確実な方法は、全履歴を記録するサーバでトランザクションを検索する方法です。txメソッド、account_txメソッドまたはその他のrippled
からのレスポンスを使用します。コンセンサスにより検証されたレジャーバージョンがこのレスポンスに使用されていることを示す"validated": true
を検索します。
- 結果に
"validated": true
がない場合は、その結果は一時的である可能性があり、トランザクションの結果が最終的なものであるかどうかを知るには、レジャーが検証されるまで待機する必要があります。 - 結果に目的のトランザクションが含まれていない場合、または
txnNotFound
エラーが返される場合は、サーバにある利用可能な履歴に保存されているどのレジャーにもそのトランザクションはありません。ただし、このことだけでトランザクションが失敗したかどうかを判断できないことがあります。サーバに保存されていない検証済みレジャーバージョンにトランザクションが記録されている、または今後検証されるレジャーにトランザクションが記録されている場合があるためです。以下を把握することで、トランザクションが記録されるレジャーの範囲を制限することができます。- トランザクションが記録されている可能性のある最古のレジャー。つまり、トランザクションを初めて送信した 後に 最初に検証されるレジャー。
- トランザクションが記録されている可能性のある最新のレジャー。つまり、トランザクションの
LastLedgerSequence
フィールドで定義されるレジャー
以下の例では、成功したトランザクションがtxメソッドによって返され、検証済みレジャーバージョンに記録されています。わかりやすくするために、JSONレスポンスのフィールドの順序を並べ替え、一部を省略しています。
{ "TransactionType": "AccountSet", "Account": "rf1BiGeXwwQoi8Z2ueFYTEXSwuJYfV2Jpn", "Sequence": 376, "hash": "017DED8F5E20F0335C6F56E3D5EE7EF5F7E83FB81D2904072E665EEA69402567", ... (省略) ... "meta": { "AffectedNodes": [ ... (省略) ... ], "TransactionResult": "tesSUCCESS" }, "ledger_index": 46447423, "validated": true }
この例では、rf1BiGeXwwQoi8Z2ueFYTEXSwuJYfV2Jpnというアドレスを持つアカウントが、シーケンス番号 376を使用して、AccountSetトランザクションを送信したことを示しています。トランザクションの識別用ハッシュは017DED8F5E20F0335C6F56E3D5EE7EF5F7E83FB81D2904072E665EEA69402567
で、その結果はtesSUCCESS
です。トランザクションは、検証済みのレジャーバージョン46447423に記録されたため、結果は最終的なものです。
ケース: 検証済みレジャーに記録されていない
トランザクションが検証済みレジャーに記録されていない場合は、共有XRP Ledgerの状態には いかなる 影響も及ぼしません。 今後レジャーに記録されるトランザクションの失敗が最終的となる場合、その失敗が将来影響を及ぼすことはありません。
トランザクションの失敗が最終的でない場合は、 将来の 検証済みレジャーに記録される可能性があります。トランザクションを現在のオープンレジャーに適用して得た暫定的な結果から、トランザクションが最終レジャーに及ぼすと思われる影響を事前に確認できます。ただし、実際の結果はさまざまな要因によって変わる場合があります。
ケース: 検証済みレジャーに記録されている
トランザクションが検証済みレジャーに記録 されている 場合、トランザクションメタデータにはトランザクションの処理結果として、レジャーの状態に対して行われたすべての変更を網羅したレポートが含まれます。メタデータのTransactionResult
フィールドには、以下のような、結果を要約したトランザクション結果コードが含まれます。
- コード
tesSUCCESS
は、トランザクションが、おおよそ成功したことを示します。 tec
-クラスコードは、トランザクションが失敗したことを示します。このことがレジャーの状態に及ぼす影響は、XRPトランザクションコストを消却し、場合によっては有効期限切れのオファーの削除およびPayment Channelの閉鎖などのブックキーピングを行うことだけです。- どのレジャーにもその他のコードは表示されません。
結果コードは、トランザクションの結果の要約にすぎません。トランザクションの実行内容を詳しく理解するには、トランザクションの指示とトランザクションの実行前のレジャーの状態に照らして残りのメタデータを確認する必要があります。
2. メタデータの解釈
トランザクションメタデータは、以下に示すフィールドをはじめとして、トランザクションがレジャーに適用された方法を 正確に 示します。
フィールド | 値 | 説明 |
---|---|---|
AffectedNodes | 配列 | このトランザクションで作成、削除、または修正されたレジャーオブジェクトのリストと、個々のオブジェクトに対する具体的な変更内容。 |
DeliveredAmount | 通貨額 | 廃止予定。delivered_amount で置き換えられます。Partial Paymentsでない場合は省略されます。 |
TransactionIndex | 符号なし整数 | トランザクションが記録されているレジャーでのトランザクションの位置。この配列は0から始まります。(例えば、値が2 の場合、そのレジャーの3番目のトランザクションであったことを意味します)。 |
TransactionResult | 文字列 | トランザクションが成功したか、どのような理由で失敗したかを示す結果コード。 |
delivered_amount | 通貨額 | Destination アカウントが実際に受取った通貨額。このフィールドは、トランザクションがPartial Paymentsであるかどうかにかかわらず、送金された金額を特定するために使用します。 |
ほとんどのメタデータは、AffectedNodes
配列に含まれています。この配列で探す対象は、トランザクションのタイプによって異なります。ほぼすべてのトランザクションが、送金元のAccountRootオブジェクトを変更してXRPトランザクションコストを消却し、アカウントのシーケンス番号を増やします。
情報: このルールの例外として疑似トランザクションがあります。このトランザクションは実在するアカウントから送信されないため、AccountRootオブジェクトを変更しません。その他の例外として、AccountRootオブジェクトのBalance
フィールドを変更せずに、AccountRootオブジェクトを変更するトランザクションがあります。Free Key Resetトランザクションの場合、送金元のXRP残高は変わりません。トランザクションによって消却される金額と同額のXRPをアカウントが受け取る場合(ただし、このようなことはほとんどありません)、そのアカウントの正味残高は変わりません。(XRPを受領したアカウントに関係なくトランザクションコストはメタデータの別の場所に反映されます。)
以下は、上記のステップ1からのレスポンス全文例です。レジャーに対して行われた変更を把握できるか確認してください。
{ "Account": "rf1BiGeXwwQoi8Z2ueFYTEXSwuJYfV2Jpn", "Fee": "12", "Flags": 2147483648, "LastLedgerSequence": 46447424, "Sequence": 376, "SigningPubKey": "03AB40A0490F9B7ED8DF29D246BF2D6269820A0EE7742ACDD457BEA7C7D0931EDB", "TransactionType": "AccountSet", "TxnSignature": "30450221009B2910D34527F4EA1A02C375D5C38CF768386ACDE0D17CDB04C564EC819D6A2C022064F419272003AA151BB32424F42FC3DBE060C8835031A4B79B69B0275247D5F4", "date": 608257201, "hash": "017DED8F5E20F0335C6F56E3D5EE7EF5F7E83FB81D2904072E665EEA69402567", "inLedger": 46447423, "ledger_index": 46447423, "meta": { "AffectedNodes": [ { "ModifiedNode": { "LedgerEntryType": "AccountRoot", "LedgerIndex": "13F1A95D7AAB7108D5CE7EEAF504B2894B8C674E6D68499076441C4837282BF8", "FinalFields": { "Account": "rf1BiGeXwwQoi8Z2ueFYTEXSwuJYfV2Jpn", "AccountTxnID": "017DED8F5E20F0335C6F56E3D5EE7EF5F7E83FB81D2904072E665EEA69402567", "Balance": "396015164", "Domain": "6D64756F31332E636F6D", "EmailHash": "98B4375E1D753E5B91627516F6D70977", "Flags": 8519680, "MessageKey": "0000000000000000000000070000000300", "OwnerCount": 9, "Sequence": 377, "TransferRate": 4294967295 }, "PreviousFields": { "AccountTxnID": "E710CADE7FE9C26C51E8630138322D80926BE91E46D69BF2F36E6E4598D6D0CF", "Balance": "396015176", "Sequence": 376 }, "PreviousTxnID": "E710CADE7FE9C26C51E8630138322D80926BE91E46D69BF2F36E6E4598D6D0CF", "PreviousTxnLgrSeq": 46447387 } } ], "TransactionIndex": 13, "TransactionResult": "tesSUCCESS" }, "validated": true }
このno-opトランザクションによって行われた 唯一 の変更はAccountRootオブジェクトの更新で、送金元のアカウントは以下のように表されています。
Sequence
値は376から377に増えます。このアカウントのXRPの
Balance
は、396015176
から396015164
(XRPのdrop数)に変わります。残高から差し引かれた12dropはトランザクションコストで、このトランザクションのFee
フィールドに指定されています。このトランザクションが、このアドレスから送信された最新のトランザクションとなったことを反映して
AccountTxnID
が変わります。このアカウントに影響を及ぼした以前のトランザクションは、レジャーバージョン46447387で実行されたトランザクション
E710CADE7FE9C26C51E8630138322D80926BE91E46D69BF2F36E6E4598D6D0CF
で、PreviousTxnID
およびPreviousTxnLgrSeq
フィールドに指定されています。(このことは、アカウントのトランザクション履歴をさかのぼる際に役立つ場合があります。)注記メタデータには明示的に示されませんが、トランザクションがレジャーオブジェクトを変更すると、必ずそのオブジェクトのPreviousTxnID
およびPreviousTxnLgrSeq
フィールドが現在のトランザクションの情報で更新されます。同じ送金元の複数のトランザクションが1つのレジャーバージョンに含まれている場合、最初のトランザクション以降の各トランザクションは、これらすべてのトランザクションを記録するレジャーバージョンのレジャーインデックスを値とするPreviousTxnLgrSeq
を提供します。
rf1BiGeXwwQoi8Z2ueFYTEXSwuJYfV2JpnのアカウントのModifiedNode
エントリがAffectedNodes
配列の唯一のオブジェクトであるため、このトランザクションの結果として、このレジャーに対してその他の変更は行われませんでした。
Balance
フィールドの正味金額は1回で変更されます。例えば、1XRP(1,000,000drop)を送信し、トランザクションコストで10drop消却した場合、メタデータにはBalance
が1,000,010(XRPのdrop数)減少したと示されます。汎用的なブックキーピング
ほぼすべてのトランザクションにより、以下のような変更が行われます。
- シーケンスとトランザクションコストの変更: 送金元のシーケンス番号を増やし、トランザクションコストの支払いに使用するXRPを消却するために、前述のとおりどのトランザクション(疑似トランザクションを除く)も、送金元の
AccountRoot
オブジェクトに変更を加えます。 - アカウントのスレッド化: オブジェクトを作成する一部のトランザクションでは、目的の受取人または宛先のアカウントのAccountRootオブジェクトも変更し、そのアカウントに関連する何らかの要素が変更されたことを示します。このアカウントを「タグ付け」する手法で、オブジェクトの
PreviousTxnID
およびPreviousTxnLgrSeq
フィールドのみを変更します。これにより、これらのフィールドに指定されたトランザクションの「スレッド」を追跡することで、アカウントが保持するアカウントのトランザクション履歴を効率よく検索することができます。 - ディレクトリーの更新: レジャーオブジェクトを作成または削除するトランザクションは、多くの場合DirectoryNodeオブジェクトを変更して、どのオブジェクトが存在しているかを追跡します。また、トランザクションによって、アカウントの所有者準備金に反映されるオブジェクトが追加されると、所有者のAccountRootオブジェクトの
OwnerCount
が増加します。オブジェクトを削除すると、OwnerCount
が減少します。
アカウントのOwnerCount
を増やす例:
{ "ModifiedNode": { "FinalFields": { "Account": "r9cZA1mLK5R5Am25ArfXFmqgNwjZgnfk59", "Balance": "9999999990", "Flags": 0, "OwnerCount": 1, "Sequence": 2 }, "LedgerEntryType": "AccountRoot", "LedgerIndex": "4F83A2CF7E70F77F79A307E6A472BFC2585B806A70833CCD1C26105BAE0D6E05", "PreviousFields": { "Balance": "10000000000", "OwnerCount": 0, "Sequence": 1 }, "PreviousTxnID": "B24159F8552C355D35E43623F0E5AD965ADBF034D482421529E2703904E1EC09", "PreviousTxnLgrSeq": 16154 } }
多くのトランザクションのタイプで、DirectoryNodeオブジェクトが作成または変更されます。これらのオブジェクトは、ブックキーピングに使用します。アカウントが所有するすべてのオブジェクト、またはすべてのオファーを追跡して、同じ為替レートで通貨を交換します。トランザクションがレジャーに新しいオブジェクトを作成した場合、トランザクションは既存のDirectoryNodeオブジェクトにエントリを追加するか、別のDirectoryNodeオブジェクトを追加してディレクトリーの別のページを表さなければならないことがあります。トランザクションがレジャーからオブジェクトを削除した場合、トランザクションは不要となった1つ以上のDirectoryNodeオブジェクトを削除しなければならないことがあります。
新しいオファーディクトリーを表すCreatedNodeの例:
{ "CreatedNode": { "LedgerEntryType": "DirectoryNode", "LedgerIndex": "F60ADF645E78B69857D2E4AEC8B7742FEABC8431BD8611D099B428C3E816DF93", "NewFields": { "ExchangeRate": "4E11C37937E08000", "RootIndex": "F60ADF645E78B69857D2E4AEC8B7742FEABC8431BD8611D099B428C3E816DF93", "TakerPaysCurrency": "0000000000000000000000004254430000000000", "TakerPaysIssuer": "5E7B112523F68D2F5E879DB4EAC51C6698A69304" } } },
トランザクションメタデータを処理する際に探すその他の項目は、トランザクションのタイプによって異なります。
支払い
PaymentトランザクションはXRP間の直接トランザクション、クロスカレンシー支払い、または(XRP以外の)トークンでの直接トランザクションを表します。トークンからXRPへのトランザクション、またはXRPからトークンへのトランザクションなど、XRP間の直接トランザクション以外はすべてpartial paymentが可能です。
XRPの額は、AccountRoot
オブジェクトのBalance
フィールドで追跡されます。(XRPはEscrowオブジェクトおよびPayChannelオブジェクトにも存在する可能性がありますが、Paymentトランザクションがそれらに影響を及ぼすことはありません。)
支払いでいくら支払われたかを確認するには、必ずdelivered_amountフィールドを使用する必要があります。
支払いにLedgerEntryTypeがAccountRoot
のCreatedNode
が含まれている場合は、その支払いによってレジャーの新しいアカウントへの資金供給が行われたことを意味します。
トークンでの支払い
トークンを利用する支払いは、多少複雑です。
トークン残高の変更は、トラストラインを表すRippleStateオブジェクトにすべて反映されます。一方の当事者のトラストラインで残高が増加すると、相手側当事者の残高は同じ額だけ減少すると考えられます。このことは、メタデータには、RippleStateオブジェクトの共有Balance
に対する1回の変更としてのみ記録されます。この変更が「増加」または「減少」のどちらで記録されるかは、どちらのアカウントのアドレスが数値として大きいかによって決まります。
1回の支払いは、複数のトラストラインとオーダーブックで構成される長いパスをたどる場合があります。間接的に当事者間を接続する複数のトラストラインの残高を変更するプロセスをRipplingと呼びます。トランザクションのAmount
フィールドに指定されたissuer
に応じて、支払先アカウントに結び付けられている複数のトラストライン(RippleState
アカウント)で支払額を分割することもできます。
AffectedNodes
メンバーを並べ替えて資金がレジャーまでたどったパスを再構成すると、支払いの実行の詳細を把握しやすくなります。クロスカレンシー支払いでは、オファーの一部または全額を消費して、通貨コードとイシュアーが異なる通貨間で変更が行われます。トランザクションでOffer
タイプのDeletedNode
オブジェクトが示される場合は、全額が消費されたオファーを示しているか、または処理の時点で期限切れになるか、または資金化されないことがわかったオファーを示している可能性があります。トランザクションでOffer
タイプのModifiedNode
が示される場合は、オファーの一部が消費されたことを示します。
トラストラインのQualityIn
およびQualityOut
設定は、トラストラインの一方の側におけるトークンの金額に影響を与える可能性があるため、残高の数値の変化は、送金元におけるその通貨の額と異なります。delivered_amount
は、受取人による評価額でいくら送金されたのかを示します。
送金額と受取額がトークンの精度の範囲外である場合は、一方のトランザクションで0に丸められる金額が、他方から引き出される可能性があります。そのため、両当事者が、お互いの残高に1016倍の差があるときに取引をすると、丸めることによって少額のトークンが「作成」または「消却」される可能性があります。(XRPは丸められないので、XRPではこの状況は発生しません。)
パスの長さに応じて、クロスカレンシー支払いのメタデータは 長く なります。例えば、トランザクション8C55AFC2A2AA42B5CE624AEECDB3ACFDD1E5379D4E5BF74A8460C5E97EF8706Bでは、rHaaans...が発行した2.788 GCBを送金しXRPを支払いますが、2人のイシュアーのUSDを経由し、2つのアカウントにXRPを支払います。r9ZoLsJからのEURをETHと交換する資金供給されていないオファーを削除し、変更された合計17の異なるレジャーオブジェクトのブックキーピングを行います。
オファー
OfferCreateトランザクションでは、成立した額や、トランザクションがtfImmediateOrCancel
などのフラグを使用したかどうかによって、レジャーにオブジェクトが作成される場合と作成されない場合があります。トランザクションがレジャーのオーダーブックに新しいオファーを追加したどうかを確認するには、LedgerEntryTypeがOffer
のCreatedNode
エントリを探します。例:
{ "CreatedNode": { "LedgerEntryType": "Offer", "LedgerIndex": "F39B13FA15AD2A345A9613934AB3B5D94828D6457CCBB51E3135B6C44AE4BC83", "NewFields": { "Account": "rETSmijMPXT9fnDbLADZnecxgkoJJ6iKUA", "BookDirectory": "CA462483C85A90DB76D8903681442394D8A5E2D0FFAC259C5B0C59269BFDDB2E", "Expiration": 608427156, "Sequence": 1082535, "TakerGets": { "currency": "EUR", "issuer": "rhub8VRN55s94qWKDv6jmDy1pUykJzF3wq", "value": "2157.825" }, "TakerPays": "7500000000" } } }
タイプOffer
のModifiedNode
は、成立し、かつ一部が消費されたオファーを示します。1つのトランザクションで多数のオファーを消費できます。2種類のトークンを交換するオファーが、オートブリッジングによってXRPを交換するオファーを消費することもあります。両替取引のすべてまたは一部をオートブリッジングできます。
LedgerEntryTypeがOffer
のDeletedNode
は、すべて消費された成立オファー、処理の時点で期限切れになるか、または資金化されないことがわかったオファー、または新しいオファーを発行する過程でキャンセルされたオファーを示すことができます。キャンセルされたオファーは識別できます。これは、キャンセルされたオファーを発行したAccount
は、そのオファーを削除するトランザクションの送信元であるためです。
削除されたオファーの例:
{ "DeletedNode": { "FinalFields": { "Account": "rETSmijMPXT9fnDbLADZnecxgkoJJ6iKUA", "BookDirectory": "CA462483C85A90DB76D8903681442394D8A5E2D0FFAC259C5B0C595EDE3E1EE9", "BookNode": "0000000000000000", "Expiration": 608427144, "Flags": 0, "OwnerNode": "0000000000000000", "PreviousTxnID": "0CA50181C1C2A4D45E9745F69B33FA0D34E60D4636562B9D9CDA1D4E2EFD1823", "PreviousTxnLgrSeq": 46493676, "Sequence": 1082533, "TakerGets": { "currency": "EUR", "issuer": "rhub8VRN55s94qWKDv6jmDy1pUykJzF3wq", "value": "2157.675" }, "TakerPays": "7500000000" }, "LedgerEntryType": "Offer", "LedgerIndex": "9DC99BF87F22FB957C86EE6D48407201C87FBE623B2F1BC4B950F83752B55E27" } }
オファーでは、両方のタイプのDirectoryNodeオブジェクトを作成、削除、変更して、オファーの発行者と、どのオファーがどのような為替レートで利用可能になっているのかを追跡できます。一般的に、ユーザがこのブックキーピングに細かな注意を払う必要はありません。
削除するオファーがなかった場合でも、OfferCancelトランザクションには、コードtesSUCCESS
が含まれる可能性があります。トランザクションが実際にオファーを削除したことを確認するには、LedgerEntryTypeがOffer
のDeletedNode
を探します。削除されていなかった場合は、そのオファーは以前のトランザクションによってすでに削除された可能性があります。またはOfferCancelトランザクションで、OfferSequence
フィールドに誤ったシーケンス番号が使用された可能性があります。
OfferCreateトランザクションが、タイプがRippleState
のCreatedNode
を示す場合は、取引で受け取ったトークンを保持するために、オファーがトラストラインを作成したことを示しています。
Escrow
成功したEscrowCreateトランザクションは、レジャーにEscrowオブジェクトを作成します。LedgerEntryTypeがEscrow
のCreatedNode
エントリを探します。NewFields
には、escrowに預託されたXRPと同じAmount
と、指定したその他のプロパティが示されます。
成功したEscrowCreateトランザクションは、送金元から同じ額のXRPを引き出します。最終的なフィールドのAccount
がトランザクションの指示にあるAccount
のアドレスと一致する、LedgerEntryTypeがAccountRoot
のModifiedNode
を探します。XRPのBalance
は、(トランザクションコストの支払いのためにXRPが消却されたのに加えて)XRPがescrowに預託されたため減少します。
成功したEscrowFinishトランザクションは、受取人のAccountRoot
を変更して(Balance
フィールドの)XRP残高を増やし、Escrow
オブジェクトを削除し、escrow作成者の所有者数を減らします。escrow作成者、受取人および終了者をすべて異なるアカウントにしても、同じアカウントにしてもかまわないため、結果としてLedgerEntryTypeがAccountRoot
のModifiedNode
オブジェクトが 1~3個 になる可能性があります。XRPがescrowの最初の作成者に返されることを除けば、成功したEscrowCancelトランザクションは極めて類似しています。
EscrowFinishは、escrowの条件を満たす場合にのみ成功し、EscrowCancelはEscrowオブジェクトの期限が前のレジャーの閉鎖時刻よりも前である場合にのみ成功します。
Escrowトランザクションでは、関係する送金元の所有者準備金やアカウントのディレクトリーを調整するために通常のブックキーピングも行われます。
次に示すコードの抜粋では、r9UUEX...の残高が10億XRP増加し、その所有者の数が1人減少しています。これは、そのアカウントからの自分自身へのescrowが正常に終了したためです。第三者がescrowを完了したためSequence
番号は変更されません。
{ "ModifiedNode": { "FinalFields": { "Account": "r9UUEXn3cx2seufBkDa8F86usfjWM6HiYp", "Balance": "1650000199898000", "Flags": 1048576, "OwnerCount": 11, "Sequence": 23 }, "LedgerEntryType": "AccountRoot", "LedgerIndex": "13FDBC39E87D9B02F50940F9FDDDBFF825050B05BE7BE09C98FB05E49DD53FCA", "PreviousFields": { "Balance": "650000199898000", "OwnerCount": 12 }, "PreviousTxnID": "D853342BC27D8F548CE4D7CB688A8FECE3229177790453BA80BC79DE9AAC3316", "PreviousTxnLgrSeq": 41005507 } }, { "DeletedNode": { "FinalFields": { "Account": "r9UUEXn3cx2seufBkDa8F86usfjWM6HiYp", "Amount": "1000000000000000", "Destination": "r9UUEXn3cx2seufBkDa8F86usfjWM6HiYp", "FinishAfter": 589075200, "Flags": 0, "OwnerNode": "0000000000000000", "PreviousTxnID": "D5FB1C7D18F931A4FBFA468606220560C17ADF6DE230DA549F4BD11A81F19DFC", "PreviousTxnLgrSeq": 35059548 }, "LedgerEntryType": "Escrow", "LedgerIndex": "62F0ABB58C874A443F01CDCCA18B12E6DA69C254D3FB17A8B71CD8C6C68DB74D" } },
Payment Channel
Payment Channelの作成時に、LedgerEntryTypeがPayChannel
のCreatedNode
を探します。また、送金元の残高の減少を示す、LedgerEntryTypeがAccountRoot
のModifiedNode
も探す必要があります。アドレスが送金元に一致することを確認するためにFinalFields
のAccount
フィールドを探し、XRP残高の変化を確認するためにBalance
フィールドの差異を確認します。
fixPayChanRecipientOwnerDir Amendmentが有効な場合は、メタデータは宛先のアカウントの所有者ディレクトリーを変更して、新しく作成されるPayment Channelをリストで示す必要もあります。これにより、アカウントがオープンPayment Channelの受取人である場合に、そのアカウントが削除されることを防ぎます。(fixPayChanRecipientOwnerDir Amendmentが有効になる前にPayment Channelが作成された場合は、アカウントを削除できます。)
Payment Channelの閉鎖を要求する方法は、Payment Channelの不変のCancelAfter
時刻(作成時にのみ設定されます)以外にもいくつかあります。トランザクションでChannelの閉鎖をスケジュールする場合は、そのChannel用にLedgerEntryTypeがPayChannel
のModifiedNode
エントリがあり、FinalFields
のExpiration
フィールドには閉鎖時刻が新たに追加されています。以下の例は、送金元がクレームを清算せずにChannelを閉鎖するよう要求した場合にPayChannel
に対して行われる変更を示します。
{ "ModifiedNode": { "FinalFields": { "Account": "rNn78XpaTXpgLPGNcLwAmrcS8FifRWMWB6", "Amount": "1000000", "Balance": "0", "Destination": "rwWfYsWiKRhYSkLtm3Aad48MMqotjPkU1F", "Expiration": 608432060, "Flags": 0, "OwnerNode": "0000000000000002", "PublicKey": "EDEACA57575C6824FC844B1DB4BF4AF2B01F3602F6A9AD9CFB8A3E47E2FD23683B", "SettleDelay": 3600, "SourceTag": 1613739140 }, "LedgerEntryType": "PayChannel", "LedgerIndex": "DC99821FAF6345A4A6C41D5BEE402A7EA9198550F08D59512A69BFC069DC9778", "PreviousFields": {}, "PreviousTxnID": "A9D6469F3CB233795B330CC8A73D08C44B4723EFEE11426FEE8E7CECC611E18E", "PreviousTxnLgrSeq": 41889092 } }
TrustSetトランザクション
TrustSetトランザクションは、RippleState
オブジェクトとして表されるトラストラインを作成、変更、または削除します。1つのRippleState
オブジェクトに、関与する両当事者の設定が含まれます。これには両当事者の制限やRipplingの設定などがあります。トラストラインの作成と変更によって送金元の所有者準備金と所有者ディレクトリーの調整も行われます。
以下の例は、rf1BiG... がrsA2Lp... によって発行されたUSDを最大110 USDまで保持するという新しいトラストラインを示します。
{ "CreatedNode": { "LedgerEntryType": "RippleState", "LedgerIndex": "9CA88CDEDFF9252B3DE183CE35B038F57282BC9503CDFA1923EF9A95DF0D6F7B", "NewFields": { "Balance": { "currency": "USD", "issuer": "rrrrrrrrrrrrrrrrrrrrBZbvji", "value": "0" }, "Flags": 131072, "HighLimit": { "currency": "USD", "issuer": "rf1BiGeXwwQoi8Z2ueFYTEXSwuJYfV2Jpn", "value": "110" }, "LowLimit": { "currency": "USD", "issuer": "rsA2LpzuawewSBQXkiju3YQTMzW13pAAdW", "value": "0" } } } }
その他のトランザクション
その他のほとんどのトランザクションは、特定のタイプのレジャーエントリを作成し、送金元の所有者準備金と所有者ディレクトリーの調整を行います。
- AccountSetトランザクションは、送金元の既存のAccountRoot objectを変更し、指定されたとおりに設定とフラグを変更します。
- DepositPreauthトランザクションは、特定の送金元のDepositPreauthオブジェクトを追加または削除します。
- SetRegularKeyトランザクションは、送金元のAccountRootオブジェクトを変更し、指定されたとおりに
RegularKey
フィールドを変更します。 - SignerListSetトランザクションは、SignerListオブジェクトを追加、削除、または置換します。
疑似トランザクション
疑似トランザクションにもメタデータがありますが、これらのトランザクションは通常のトランザクションのすべてのルールに従うとは限りません。これらのトランザクションは、実在のアカウントには関連付けられていないため(このAccount
の値は、base58エンコード形式の数字の0です)、レジャーのAccountRootオブジェクトを変更してSequence
シーケンス番号を増やしたり、XRPを消却したりしません。疑似トランザクションは、特別なレジャーオブジェクトに対して特定の変更のみを行います。
- EnableAmendment疑似トランザクションは、Amendmentレジャーオブジェクトを変更して、有効なAmendment、過半数の支持を得ている保留中のAmendment、および保留中の期間を追跡します。
- SetFee疑似トランザクションは、FeeSettingsレジャーオブジェクトを変更して、トランザクションコストおよび必要準備金のベースレベルを変更します。
関連項目
- コンセプト:
- 結果のファイナリティー - トランザクションの成功また失敗が最終的なものとなるタイミングを判断する方法。(簡単な説明: トランザクションが検証済みレジャーにある場合は、その結果とメタデータは最終的なものです。)
- チュートリアル:
- リファレンス:
- レジャーオブジェクトタイプのリファレンス - レジャーオブジェクトの使用可能なすべてのタイプのフィールド
- トランザクションのメタデータ - メタデータフォーマットとメタデータに表示されるフィールドの概要
- トランザクションの結果 - トランザクションのすべての結果コードを掲載した表一覧