基本的なデータ型

さまざまなタイプのオブジェクトがそれぞれ異なる方法で一意に識別されます。

アカウントは"r9cZA1mLK5R5Am25ArfXFmqgNwjZgnfk59"のようなアドレスで一意に識別されます。アドレスは常に「r」で始まります。rippledメソッドの多くは、16進数表記に対応しています。

トランザクションは、トランザクションのバイナリフォーマットのハッシュで識別されます。また、トランザクションは送信アカウントとシーケンス番号でも識別できます。

閉鎖された各レジャーは、レジャーインデックスとハッシュ値を保有します。レジャーを指定する場合、いずれか1つを使用できます。

アドレス

XRP Ledgerのアカウントは、XRP Ledgerのbase58フォーマットのアドレスで識別されます。このアドレスはアカウントのマスター公開鍵から生成され、マスター公開鍵は秘密鍵から生成されます。アドレスはJSON文字列で記述され、以下の特徴があります。

長さは25から35文字
文字rから始まる
数字"0"、大文字"O"、大文字"I"、小文字"l"を除く英数字
大文字と小文字を区別
4バイトのチェックサムが含まれており、ランダムな文字から有効なアドレスが生成される確率はおよそ2³²分の1

注記

宛先タグをアドレスに「組み込む」Xアドレス形式もあります。これらのアドレスはX（メインネット用）またはT（テストネットワーク用）で始まります。取引所とウォレットは、顧客が知る必要のあるすべてのデータを1つの値で表すためにXアドレスを使用できます。詳細については、Xアドレスフォーマットサイトとコーデックをご覧ください

XRP Ledgerプロトコルは「クラシック」アドレスのみをネイティブにサポートしていますが、多くのクライアントライブラリはXアドレスもサポートしています。

ハッシュ

XRP Ledger内の多くのオブジェクト、特にトランザクションとレジャーは、256ビットのハッシュ値で一意に識別されます。通常、この値は「SHA-512ハーフ」として算出されます。SHA-512ハーフは、あるコンテンツからSHA-512ハッシュを計算し、出力の前半を取得したものです。（これは256ビット、つまり32バイトで、16進数表記では64文字です。）オブジェクトのハッシュは、極めて競合の発生しにくい方法でコンテンツから生成されるため、2つのオブジェクトが同じハッシュを持つ場合、それらのオブジェクトは同じものと見なされます。

XRP Ledgerのハッシュ値には、以下の特徴があります。

長さは64文字ちょうどです
16進数の文字セット: 0-9およびA-Fです。
通常は大文字で記述されます。

注記

SHA-512ハーフは、公式に定義されている SHA-512/256 ハッシュ関数とほぼ同等のセキュリティーを持ちます。しかし、XRP LedgerはSHA-512/256より前から利用されているため、既存のSHA-512関数上に実装することも容易にできます。（この記事の時点で、暗号ライブラリーでのSHA-512のサポートはSHA-512/256よりはるかに一般的です。）

ハッシュプレフィクス

[ソース]

多くの場合、XRP Ledgerではオブジェクトのバイナリデータに4バイトのプレフィクスを付けてからハッシュを計算するため、異なるタイプのオブジェクトが同じバイナリフォーマットである場合でも、異なるハッシュが設定されます。既存の4バイトコードは、ASCIIでエンコードされた英字3文字の後に0バイトが続く構成となっています。

ある種のハッシュは、APIのリクエストとレスポンスに使用されます。またある種のデータに署名するときの最初のステップで計算されるだけのものや、より高度なハッシュを計算するためのものもあります。XRP Ledgerで使用されるすべての4バイトのハッシュプレフィクスは以下の表の通りです。

オブジェクトタイプ	APIフィールド	ハッシュプレフィクス（16進数）	ハッシュプレフィクス（テキスト）
コンセンサスの提案	なし	`0x50525000`	`PRP\0`
レジャーバージョン	`ledger_hash`	`0x4C575200`	`LWR\0`
レジャー状態データ	`account_state` （レジャーヘッダー内）	`0x4D4C4E00`	`MLN\0`
レジャーデータ内部ノード	なし	`0x4D494E00`	`MIN\0`
レジャーデータ内部ノード（SHAMapv2）	なし	`0x494E5200`	`INR\0`
Payment Channelのクレーム	なし	`0x434C4D00`	`CLM\0`
署名済みのトランザクション	トランザクションの`hash`	`0x54584E00`	`TXN\0`
メタデータを持つトランザクション	なし	`0x534E4400`	`SND\0`
未署名のトランザクション（シングル署名）	なし	`0x53545800`	`STX\0`
未署名のトランザクション（マルチシグ）	なし	`0x534D5400`	`SMT\0`
検証の投票	なし	`0x56414C00`	`VAL\0`
バリデータサブキー認証（「バリデータマニフェスト」）	なし	`0x4D414E00`	`MAN\0`

レジャーオブジェクトIDも似た方法で計算されますが、ここで説明したプレフィクスの代わりに「スペースキー」という2バイトのプレフィクスを使用します。

アカウントシーケンス

シーケンス番号とは、32ビットの符号なし整数であり、指定された送金元からのトランザクションが正しい順序で1回だけ実行されるようにするために使用されます。

すべてのXRP Ledgerアカウントには、Sequenceフィールドに1つのシーケンス番号があり、アカウントがトランザクションを送信し、そのトランザクションが検証済みレジャーに記録されるたびに、1ずつ増加します。シーケンス番号は各トランザクションのSequenceフィールドにもあり、そのトランザクションが実行される際にアカウントの現在のシーケンス番号と一致している必要があります。各アカウントで、各シーケンス番号は番号順に一度だけ使用できます。

チケットは、通常の順序とは異なるトランザクションを送信できるように、これらのルールにいくつかの例外を設けています。チケットは、後で使用するために予約されたシーケンス番号を表します。トランザクションは、通常のシーケンス番号の代わりにチケットを使用することができます。

DeletableAccounts Amendment を適用する場合、アカウントのSequence番号の始まりが、アカウントが作成されたレジャーバージョンの[レジャーインデックス][]と一致します。DeletableAccountsを適用しない場合、どのアカウントのSequence番号も1で始まります。

トランザクションがレジャーに記録されると、トランザクションの実行が成功したかtecクラスのエラーコードで失敗したかを問わず、シーケンス番号が1つ消費されます。トランザクションのその他の失敗についてはレジャーに記録されないため、送金元のシーケンス番号は変更されません（その他の影響もありません）。

レジャー内では、[アドレス][]とシーケンス番号を一緒に使用して、その送金元とシーケンス番号を持つ検証済みトランザクションによって作成されたオブジェクトが識別されることがあります。この方法で識別されたオブジェクトの例として、Escrowとオファーが挙げられます。

複数の未確定のトランザクションが、同じ送金元と同じシーケンス番号を持つことが可能です。そのようなトランザクションは互いに排他的であり、検証済みレジャーに記録されるのはいずれか一方のみです。（それ以外は最終的に影響ありません。）

レジャーインデックス

レジャーインデックスは、32ビットの符号なし整数であり、レジャーを識別するために使用します。レジャーインデックスは、レジャーの シーケンス番号 と呼ばれることもあります。（アカウントシーケンスとは異なります。）一番最初のレジャーでは、レジャーインデックスは1でした。新しいレジャーのレジャーインデックスは、その直前のレジャーのレジャーインデックスに1を加算した値になります。

レジャーインデックスがレジャーの順番を示すのに対し、[ハッシュ][]値はレジャーの正確なコンテンツを示します。2つのレジャーが同じハッシュ値を持つ場合、それらは必ず同じものです。検証済みレジャーでは、ハッシュ値とレジャーインデックスは等しく有効で、1:1の関係です。しかし、進行中のレジャーに対しては、以下の理由によりその限りでありません。

ネットワーク全体でのトランザクションの伝搬遅延が原因で、2つの異なるrippledサーバで、同じレジャーインデックスを持つ現行レジャーに対するコンテンツが異なる場合があります。
決済済みレジャーバージョンが複数あり、コンセンサスによる検証が競合している場合があります。このようなレジャーバージョンでは、レジャーインデックスは同じですが、コンテンツは異なります（ハッシュも異なります）。これらの決済済みレジャーのうち、検証済みになるのは1つだけです。
現行のオープンレジャーのハッシュは計算されません。これは、現行レジャーのレジャーインデックスは同じままであっても、コンテンツは時間とともに変化し、ハッシュが変わる可能性があるためです。レジャーのハッシュは、レジャーが閉鎖されるときにのみ計算されます。

レジャーの指定

APIメソッドの多くは、レジャーのインスタンスを指定する必要があります。その場合、共有されたレジャーの特定バージョンで最新と見なされるデータで指定する必要があります。レジャーバージョンを受け入れるコマンドは、すべて同様に機能します。使用するレジャーを指定するには、以下の3つの方法があります。

ledger_indexパラメータにレジャーのレジャーインデックスを指定します。閉鎖された各レジャーには識別用のレジャーインデックスが付いていて、その前に検証されたレジャーより1つ大きい番号になります。（最初のレジャーのインデックスは1です。）
```
"ledger_index": 61546724
```

ledger_hashパラメータにレジャーのハッシュ値を指定します。

"ledger_hash": "8BB204CE37CFA7A021A16B5F6143400831C4D1779E6FE538D9AC561ABBF4A929"

ledger_indexパラメータに以下のいずれかのショートカットを指定します。
- validated: コンセンサスで検証された最新のレジャー
```
"ledger_index": "validated"
```
- closed: 変更できないように閉鎖され、検証を提案されている最新のレジャー
- current: サーバで現在処理中のレジャーバージョン

上記3つのフォーマットすべてを受け入れる、廃止予定のledgerパラメーターもあります。このパラメーターは使用しないでください。今後予告なしに廃止される可能性があります。

レジャーを指定しない場合、デフォルトでcurrent（処理中）レジャーが選択されます。レジャーを指定しなかった場合、サーバはリクエストにどのレジャーを使うかを決めます。デフォルトでは、サーバはcurrent(進行中)のレジャーを選択します。レポートモードでは、サーバは最新の検証済みレジャーを使います。レジャーを指定するフィールドは複数指定しないでください。

注記

レジャーを指定する際に上記のデフォルトの動作に頼らないでください。変更される場合があります。可能であれば、常にリクエストでレジャーバージョンを指定してください。

レポートモードでは、検証済みとなるまでレジャーデータは記録されません。レポートモードサーバにcurrentまたはclosedのレジャーをリクエストすると、サーバはそのリクエストを P2Pモードサーバに転送します。検証されていないレジャー番号またはハッシュをリクエストした場合、レポートモードのサーバはlgrNotFoundエラーを返します。

通貨額の指定

XRP LedgerにはXRPとトークンの2種類の通貨があります。これら2種類の通貨は、異なるフォーマット、異なる精度と丸め動作で指定されます。

Paymentトランザクションで送金するAmountのようないくつかのフィールドは、どちらのタイプにもすることができます。Feeフィールド（トランザクションコスト）のように、XRPのみを使用可能なフィールドもあります。

XRPは、XRPの “drop"数を含む整数の文字列として指定され、100万ドロップが1XRPに相当します。トークンは、10進数の金額、通貨コード、発行者のフィールドを持つオブジェクトとして指定されます。

XRP - Amountフィールドに13.1 XRPを指定するには:
```
"Amount": "13100000"
```

トークン - rf1B...が発行した13.1 FOOという値でAmountフィールドを指定するには：

"Amount": {
    "value": "13.1",
    "currency": "FOO",
    "issuer": "rf1BiGeXwwQoi8Z2ueFYTEXSwuJYfV2Jpn"
}

詳しくは通貨フォーマットをご覧ください。

時間の指定

rippledサーバとそのAPIでは、時間を符号なし整数で表します。この数値は、「Rippleエポック」である2000年1月1日（00:00 UTC）から経過した秒数を表しています。これはUNIXエポックと同様に機能しますが、RippleエポックはUNIXエポックより946684800秒遅れています。

Rippleエポック時間を32ビット変数でUNIXエポック時間に変換しないでください。整数のオーバーフローが発生する恐れがあります。