ARCHIVE/xrpl-dev-portal
1
0
Fork 0
mirror of https://github.com/XRPLF/xrpl-dev-portal.git synced 2025-11-21 04:05:49 +00:00
Code Issues Packages Projects Releases Wiki Activity

Information Architecture v3 (#1934)

Browse Source 
* Update look up escrows to remove redundant info about lookups via sender/destination. Modify cancel expired escrow for brevity.

* Cancel escrow: fix notes

* Add draft of updated cancel-escrow.js.

* Update intro to escrows.

* Add Escrow Tutorial

* Minor corrections

* Fix headings, add HTML

* Update escrow docs

This commit re-creates f205a92db2 with
some adjustments:

- Omit the accidentally-created dir full of junk
- Fix some typos and one mistake in the Escrow limitations section
- Add a table to the EscrowCreate ref to clarify valid combos of fields.

* Concept info from send-a-time-held-escrow added to escrow.md

* IA: Move "Consensus Network" files

This re-creates some work from the original commit 56fffe0b9f

* Rewrite escrows article (re-created)

This commit re-creates relevant work from the following commits:

9a4a588f2b Update escrow.md context info
e1b017dc83 Remove references to using escrow for interledger payments.

* IA: Move "XRPL servers" files

This re-creates some work from original commit 7611979abf

* IA: move "production readiness" files.

Re-creates work from the following commit:

692438693a  Move tutorials to concepts

* New intro articles

Original commit: 56fffe0b9f

* IA: Reorg account concepts

Re-creates some work from original commit 56fffe0b9f

* IA: reorg transaction concepts

Original commits:
9d4eff9940  WIP - reorg accounts
7611979abf  WIP dir. reorg

* IA: reorg consensus concepts

Original commit: 56fffe0b9f

* IA: Reorg ledger docs

Original commit: 56fffe0b9f

- Rephrased some details of the section

* IA: rename issuing/operational addresses page

Original commit: 56fffe0b9f

* Moving use cases

* Fleshing out Use Cases

Note, the dactyl-config.yml file has not been fully updated.

* Clean up checks conceptual info.

* Remove redundant checks use case section

Original commit: 3c29e9c05e

* IA: move Dex under tokens

Original commit: d08b3ba7d7

* Touch up stablecoin issuer use case (#1856)

* Consolidate stablecoin use case

* Stablecoin issuer: cleanup progress through sending

* Stablecoin issuer: reorg second half

(Note: the dactyl-config.yml is not fully reconciled yet)

* Move rippled and clio tutorials into infrastructure

* Remove link to checks amendement.

* Add note to account_objects.md about commandline interface type field.

* Merge expiration case with lifecycle section.

* Interoperability Use Cases

* Add graphics to intro

* Move escrow use cases to dedicated page.

* Update use case page intros and corresponding concept info.

* Clarify meaning of direct XRP payments.

* Intro link updates

* Payment use cases

* Remove some unnecessary links in transactions section

Original commit: e6fcf4a4dc

* Link cleanup in Tokens section

Original commit: 9588dd5e70

* Touch up 'Configure Peering' section

Original commit: fc8f0990b8

* Clean up links in accounts section

Original commit: 3da5fde7a8

* Add NFT mkt use case

* p2p payments: edits to Wallets

* Clean up payments use cases

* Refine history description

* IA: use case cleanup

* IA: reconcile servers, ledgers sections

* IA: reconcile payment types, tx, tokens

* IA: reconcile accounts section

* IA: reconcile infra

* IA: Fix most broken links

* Full Docs Index: omit from sidebar

* IA: fix up most broken links

* fix Absolute path link to internal content

* Quick updates to Software Ecosystem

* Remove some absolute links to internal resources

* Fix remaining broken links in JA target

* Contributing: tweak formatting

* Tutorials: fix some minor issues

* remove interop use cases

* remove intro image and personal references to dennis

* alphabetize-transaction-nav

* Remove unused files

* Add QS escrow tutorials

* IA: move ledgers, consensus protocol files around

* IA: update nav for new page hierarchy

* reordering of topics under new networks and servers top-nav

* Move "Naming" to "What is XRP?"

* Update dactyl-config.yml

Remove xrp.md from the TOC.

* Update list-xrp-as-an-exchange.md

Update link to what-is-xrp

* Update list-xrp-as-an-exchange.ja.md

Change link to what-is-xrp

* Update currency-formats.md

Change link to what-is-xrp

* Update currency-formats.ja.md

Change link to what-is-xrp

* Update cancel-an-expired-escrow.md

Change link to what-is-xrp

* Update paymentchannelfund.md

Change link to what-is-xml

* Update look-up-escrows.md

Change link to what-is-xrp

* Update tokens.md

change link to what-is-xrp

* Update use-payment-channels.md

* Update send-a-time-held-escrow.md

Update link to what-is-xml

* fix broken links

* Update parallel-networks.md

Change link to what-is-xml

* Update parallel-networks.ja.md

* Update invariant-checking.md

Remove link to xrp.html

* Update invariant-checking.ja.md

Remove link to xrp.html

* Update transaction-cost.md

Change link to what-is-xrp

* Update transaction-cost.ja.md

Change link to what-is-xrp

* Update send-a-conditionally-held-escrow.md

Change link to what-is-xrp

* Update stablecoin-issuer.md

Change link to what-is-xrp

* Update tokens.ja.md

Change link to what-is-xml

* Update autobridging.ja.md

Change link to what-is-xrp

* Update currency-formats.md

update text

* reorganize infrastructure nav section

* Update currency-formats.md

Try removing link altogether.

* Update currency-formats.ja.md

Remove link to what-is-xrp.html

* move commandline usage topic to infrastructure

* initial intro rewrite

* minor update to language

* IA.v3: rm Production Readiness

* Delete xrp.md

* Update xrp link in snippet

* Add redirect for old xrp.html URL

* Small edits to 'What is XRP?' article

* Add missing imgs

* XRP - copy edit per @DennisDawson

* restructure tutorials nav and pages

* fix broken links

* more broken link fixes

* Algo trading: 1st draft

* Algo trading: notes on taxes

* Algo trading: edits per review

* algo trading: fix broken link

* Ledger structure: rewrite for accuracy and clarity

* Update links to removed 'tree format' header

* Ledger Structure: Update diagrams

* Re-gen CSS for ledger structure changes

* Ledger structure: edits per review

* IA.v3: fix broken NFT links introduced by rebase

* Desktop Wallet (py): update little stuff

* Update some capacity/storage details

* contribute doc nav update

* fix image link in create diagram page

* IAv3: Fix 'Ledgers' blurb

* Update full history requirements with details from community members

* add reviewer suggestions

* Edits per @trippled review

* Apply suggestions from peer review

Co-authored-by: oeggert <117319296+oeggert@users.noreply.github.com>

* FH: reword file size limit note per review

* Update software ecosystem

* updates per review

* Minor tweaks to graphics

* fixTypos

* Update content/concepts/introduction/software-ecosystem.md

Co-authored-by: Amarantha Kulkarni <amarantha-k@users.noreply.github.com>

* Update content/concepts/introduction/software-ecosystem.md

Co-authored-by: Amarantha Kulkarni <amarantha-k@users.noreply.github.com>

* [JA] update AccountDelete cost

* custom transactors doc

* add doc to dactyl config

* [JA] fix NonFungibleTokensV1_1 amendment status

* [JA] update NFTokenOffer page

* Remove old, unused XRP article (#2039)

* add reviewer suggestions

* Add tooling to check for file/nav consistency

- From the repo top, run tool/check_file_consistency.py to look for
  Markdown files that exist in the "content/" directory but aren't used
  in the documentation.
- New "enforce_filenames" filter prints a warning to console when
  building, if a file's path and filename don't match expectations
  based on its place in the nav and top heading.

* File consistency checker: correctly handle filenames starting in _

* Remove unused old 'get started' and associated code

* Create Resources section & reorg some files

- Rename some files/folders based on their place in the nav
- Move a bunch of non-documentation stuff, and docs on contributing code
  and/or docs to the new "Resources" section.
- Known issue: nav spills into a second row on page widths between
  993px-1110px. To be fixed in a later CSS update, maybe along with
  making the Resources dropdown multi-column.

* Fix #2078 code tab bug

CSS not built yet, to reduce merge conflicts. Won't have any effect
until that happens.

* fix Transaction JSON

* [JA] translate contributing contents

* fix contributing-to-documentation parent

* fix contribute-code blurb

* Top nav: add cols for Resources, fix broken links

* CSS: fix top nav overflows

* Fix broken link from redirect not in JA target

* Top nav: add Infra to article types

* Update contrib info & rename intro file

* [ja] Update link to suggested first page to translate

* [ja] fix contribute docs organization

* Run private network with docker tutorial (#2065)

* [NO-ISSUE] Run private network with docker tutorial

Adds a tutorial page in the Infrastructure section on how to run a private XRPL network with Docker.

Please let me know if you think this is a useful page to include for developers, whether the steps are clear or not, and if you have suggestions on what can be added to it.

* Add minor link fixes and Japanese target

* Apply suggestions from code review

Co-authored-by: Amarantha Kulkarni <amarantha-k@users.noreply.github.com>

* Add link to ripple-docker-testnet setup scripts in See Also section

* Update repo URL

---------

Co-authored-by: Amarantha Kulkarni <amarantha-k@users.noreply.github.com>

* add intro gfx (#2036)

* add intro gfx

* Move graphic up

* Update some graphics with their revised versions

* Add updated version of the custodial vs non-custodial graphic

---------

Co-authored-by: Amarantha Kulkarni <amarantha-k@users.noreply.github.com>
Co-authored-by: Amarantha Kulkarni <akulkarni@ripple.com>

* Update to reflect current UNL publishers

* [ja] update contributing

Co-authored-by: tequ <git@tequ.dev>

* Incorporate feedback on "What is XRP" page. (#2099)

* Add trademark info for XRP

* Revert section to previous state

* Fix broken link (#2101)

---------

Co-authored-by: Oliver Eggert <oeggert@ripple.com>
Co-authored-by: ddawson <dennis.s.dawson@gmail.com>
Co-authored-by: Maria Shodunke <mshodunke@ripple.com>
Co-authored-by: tequ <git@tequ.dev>
Co-authored-by: oeggert <117319296+oeggert@users.noreply.github.com>
Co-authored-by: Amarantha Kulkarni <amarantha-k@users.noreply.github.com>
Co-authored-by: develoQ <develoQ.jp@gmail.com>
Co-authored-by: Maria Shodunke <maria-robobug@users.noreply.github.com>
Co-authored-by: Amarantha Kulkarni <akulkarni@ripple.com>
This commit is contained in:
Rome Reginelli
2023-09-01 12:40:18 -07:00
committed by GitHub
parent 31a068e6ae
commit b51bcb4ea3
445 changed files with 9020 additions and 4411 deletions
Download Patch File Download Diff File Expand all files Collapse all files

2
content/references/protocol-reference/ledger-data/ledger-header.md
View File

@@ -32,7 +32,7 @@ Every [ledger version](ledgers.html) has a unique header that describes the cont
## Close Flags
The ledger has only one flag defined for `closeFlags`: **`sLCF_NoConsensusTime`** (value `1`). If this flag is enabled, it means that validators had different [close times for the ledger](ledgers.html#ledger-close-times), but built otherwise the same ledger, so they declared consensus while "agreeing to disagree" on the close time. In this case, official `close_time` value of the ledger is 1 second after that of the parent ledger.
The ledger has only one flag defined for `closeFlags`: **`sLCF_NoConsensusTime`** (value `1`). If this flag is enabled, it means that validators had different [close times for the ledger](ledger-close-times.html), but built otherwise the same ledger, so they declared consensus while "agreeing to disagree" on the close time. In this case, official `close_time` value of the ledger is 1 second after that of the parent ledger.
The `closeFlags` field is not included in any JSON representations of a ledger, but is included in the binary representation of a ledger, and is one of the fields that determine the ledger's hash.

6
content/references/protocol-reference/ledger-data/ledger-object-types/directorynode.md
View File

@@ -9,11 +9,11 @@ labels:
# DirectoryNode
[[Source]](https://github.com/ripple/rippled/blob/5d2d88209f1732a0f8d592012094e345cbe3e675/src/ripple/protocol/impl/LedgerFormats.cpp#L44 "Source")
The `DirectoryNode` object type provides a list of links to other objects in the ledger's state tree. A single conceptual _Directory_　takes the form of a doubly linked list, with one or more DirectoryNode objects each containing up to 32 [IDs](ledgers.html#tree-format) of other objects. The first object is called the root of the directory, and all objects other than the root object can be added or deleted as necessary.
The `DirectoryNode` ledger entry type provides a list of links to other entries in the ledger's state data. A single conceptual _Directory_　takes the form of a doubly linked list, with one or more DirectoryNode entries each containing up to 32 [IDs of other entries](ledger-object-ids.html). The first DirectoryNode entry is called the root of the directory, and all entries other than the root can be added or deleted as necessary.
There are two kinds of Directories:
* **Owner directories** list other objects owned by an account, such as [`RippleState` (trust line)](ripplestate.html) or [`Offer`](offer.html) objects.
* **Owner directories** list other entries owned by an account, such as [`RippleState` (trust line)](ripplestate.html) or [`Offer`](offer.html) entries.
* **Offer directories** list the offers available in the [decentralized exchange](decentralized-exchange.html). A single Offer directory contains all the offers that have the same exchange rate for the same token (currency code and issuer).
## Example {{currentpage.name}} JSON
@@ -61,7 +61,7 @@ There are two kinds of Directories:
| Name | JSON Type | [Internal Type][] | Required? | Description |
|:--------------------|:----------|:------------------|:----------|:------------|
| `ExchangeRate` | String | UInt64 | No | (Offer Directories only) **DEPRECATED**. Do not use. |
| `ExchangeRate` | String | UInt64 | No | (Offer Directories only) **DEPRECATED**. Do not use. |
| `Flags` | Number | UInt32 | Yes | A bit-map of boolean flags enabled for this object. Currently, the protocol defines no flags for `DirectoryNode` objects. The value is always `0`. |
| `Indexes` | Array | Vector256 | Yes | The contents of this Directory: an array of IDs of other objects. |
| `IndexNext` | Number | UInt64 | No | If this Directory consists of multiple pages, this ID links to the next object in the chain, wrapping around at the end. |

2
content/references/protocol-reference/ledger-data/ledger-object-types/ledgerhashes.md
View File

@@ -10,7 +10,7 @@ labels:
(Not to be confused with the ["ledger hash" string data type][Hash], which uniquely identifies a ledger version. This section describes the `LedgerHashes` ledger object type.)
The `LedgerHashes` object type contains a history of prior ledgers that led up to this ledger version, in the form of their hashes. Objects of this ledger type are modified automatically when closing a ledger. (This is one of the only times a ledger's state data is modified without a [transaction](transaction-basics.html) or [pseudo-transaction](pseudo-transaction-types.html).) The `LedgerHashes` objects exist to make it possible to look up a previous ledger's hash with only the current ledger version and at most one lookup of a previous ledger version.
The `LedgerHashes` object type contains a history of prior ledgers that led up to this ledger version, in the form of their hashes. Objects of this ledger type are modified automatically when closing a ledger. (This is one of the only times a ledger's state data is modified without a [transaction](transactions.html) or [pseudo-transaction](pseudo-transaction-types.html).) The `LedgerHashes` objects exist to make it possible to look up a previous ledger's hash with only the current ledger version and at most one lookup of a previous ledger version.
There are two kinds of `LedgerHashes` object. Both types have the same fields. Each ledger version contains:

73
content/references/protocol-reference/ledger-data/ledger-object-types/nftokenoffer.ja.md
View File

@@ -7,34 +7,40 @@ labels:
---
# NFTokenOffer
`lsfTransferable` フラグが設定されているトークンは、オファーを使って 参加者間で転送することができます。`NFTokenOffer` オブジェクトは `NFToken` オブジェクトの購入、売却、または譲渡のオファーを表します。`NFToken` の所有者は `NFTokenCreateOffer` を使用して売買を行うことができます。
`lsfTransferable`フラグが設定されているトークンは、オファーを使って参加者間で転送することができます。`NFTokenOffer`オブジェクトは`NFToken`オブジェクトの購入、売却、または譲渡のオファーを表します。`NFToken`の所有者は`NFTokenCreateOffer`を使用して売買を行うことができます。
_([NonFungibleTokensV1_1 amendment][]が必要です)_
_([NonFungibleTokensV1_1 amendment][]により追加されました)_
## {{currentpage.name}} JSONの例
### `NFTokenOfferID`のフォーマット
`NFTokenOffer` オブジェクトのユニーク ID (`NFTokenOfferID`) は、以下の値を順番に結合したものである。
* `NFTokenOffer` のスペースキー、`0x0074`
* オファーを出すアカウントの `AccountID`
* `NFTokenCreateOffer` トランザクションが生成する `Sequence` (または `Ticket`)
```json
{
"Amount": "1000000",
"Flags": 1,
"LedgerEntryType": "NFTokenOffer",
"NFTokenID": "00081B5825A08C22787716FA031B432EBBC1B101BB54875F0002D2A400000000",
"NFTokenOfferNode": "0",
"Owner": "rhRxL3MNvuKEjWjL7TBbZSDacb8PmzAd7m",
"OwnerNode": "17",
"PreviousTxnID": "BFA9BE27383FA315651E26FDE1FA30815C5A5D0544EE10EC33D3E92532993769",
"PreviousTxnLgrSeq": 75443565,
"index": "AEBABA4FAC212BF28E0F9A9C3788A47B085557EC5D1429E7A8266FB859C863B3"
}
```
### `NFTokenOffer`のフィールド
| 名前 | JSONの型 | [内部の型][] | 必須？ | 説明 |
|:--------------------|:------------|:------------------|:------|:-----------|
| `Amount` | [通貨額][] | AMOUNT | はい | NFTokenに対して見込まれる、または提示される金額です。トークンに `lsfOnlyXRP` フラグが設定されている場合、金額は XRP で指定する必要があります。XRP 以外の資産を指定する売却オファーは、0 以外の金額を指定する必要があります。XRP を指定する売却オファーは、`無料`にすることができます（つまり、このフィールドは `"0"` とすることができます）。 |
| `Amount` | [通貨額][] | AMOUNT | はい | NFTokenに対して見込まれる、または提示される金額です。トークンに`lsfOnlyXRP`フラグが設定されている場合、金額はXRPで指定する必要があります。XRP以外の資産を指定する売却オファーは、0以外の金額を指定する必要があります。XRPを指定する売却オファーは、`無料`にすることができます（つまり、このフィールドは`"0"`とすることができます）。 |
| `Destination` | 文字列 | AccountID | いいえ | このオファーの対象となるAccountID。存在する場合、そのアカウントのみがオファーを受け入れることができます。 |
| `Expiration` | 数値 | UInt32 | いいえ | オファーが有効でなくなる時刻。値は、リップルエポックからの秒数です。 |
| `Flags` | 数値 | UInt32 | はい | このオブジェクトに関連付けられたフラグのセットで、様々なオプションや設定を指定するために使用されます。フラグは、以下の表に示すとおりです。 |
| `LedgerEntryType` | 文字列 | UInt16 | はい | レジャーオブジェクトの種類を示します（0x0074）。 |
| `NFTokenID` | 文字列 | Hash256 | はい | このオファーが参照する NFToken オブジェクトの NFTokenID。 |
| `NFTokenID` | 文字列 | Hash256 | はい | このオファーが参照するNFTokenオブジェクトのNFTokenID。 |
| `NFTokenOfferNode` | 文字列 | UInt64 | いいえ | トークン購入または売却のオファーディレクトリの中で、このトークンが記録されている内部的な台帳です。このフィールドを使用することで、オファーを効率的に削除することができます。 |
| `Owner` | 文字列 | AccountID | はい | オファーの作成者であり、所有者であるアカウント。NFToken の現在の所有者のみが NFToken の売却オファーを作成できますが、NFToken の購入オファーはどのアカウントでも作成できます。 |
| `Owner` | 文字列 | AccountID | はい | オファーの作成者であり、所有者であるアカウント。NFTokenの現在の所有者のみがNFTokenの売却オファーを作成できますが、NFTokenの購入オファーはどのアカウントでも作成できます。 |
| `OwnerNode` | 文字列 | UInt64 | いいえ | このトークンが記録されているオーナーディレクトリ内のページを示す、内部的な台帳です。このフィールドを使用することで、オファーを効率的に削除することができます。 |
| `PreviousTxnID` | 文字列 | Hash256 | はい | このオブジェクトを最も最近更新したトランザクションの識別ハッシュ。 |
| `PreviousTxnLgrSeq` | 数値 | UInt32 | はい | このオブジェクトを最も最近更新したトランザクションを含むレジャーのインデックス。 |
@@ -43,39 +49,38 @@ _([NonFungibleTokensV1_1 amendment][]が必要です)_
#### NFTokenOffer フラグ
|フラグ名 |16進数値 |10進数値|説明 |
|------------------|--------------|------|---------|
| `lsfSellNFToken `| `0x00000001` | 1 | 有効な場合、オファーは売却オファーとなります。そうでない場合、オファーは購入オファーとなります。 |
|フラグ名|フラグ値|説明|
|---|---|---|
| `lsfSellNFToken `| `0x00000001` | 有効な場合、オファーは売却オファーとなります。そうでない場合、オファーは購入オファーとなります。 |
## `NFTokenOffer`トランザクション
## `NFTokenOffer` トランザクション
[代替可能トークンに対するOffer](offers.html)とは異なり、`NFTokenOffer`はオーダーブックに保存されず、自動的にマッチングされたり約定されたりすることはありません。買い手は売り手により提示されてた`NFTokenOffer`の受け入れを明示的に選択する必要があります。同様に、売り手は自分が所有する`NFToken`オブジェクトを買いたいと申し出た買い手の`NFTokenOffer`を受け入れることを明示的に選択しなければなりません。
XRPL上のトークン・オファーは、オーダーブックに品質順に保存され、オンレジャーのメカニズムによって自動的にマッチングされます。`NFTokenOffer`はオーダーブックに保存されず、自動的にマッチングされたり実行されたりすることはありません。
`NFToken`の取引のためのトランザクションは3つあります。
購入者は `NFToken` の購入を申し出る `NFTokenOffer` を受け入れるかどうかを明示的に選択しなければなりません。同様に、販売者は自分が所有する `NFToken` オブジェクトの購入を申し出る特定の `NFTokenOffer` を受け入れることを明示的に選択する必要があります。
- [NFTokenCreateOffer][]
- [NFTokenCancelOffer][]
- [NFTokenAcceptOffer][]
定義されたトランザクションは3つあります。
### `NFTokenOffer`オブジェクトの検索
各`NFToken`は、2つの[ディレクトリ](directorynode.html)があります。1つはトークンを購入するためのオファー、もう1つはトークンを売却するためのオファーが含まれています。マーケットプレイスやその他のクライアントアプリケーションは、ユーザに対し`NFToken`オブジェクトの取引オファーを提示したり、自動的にマッチングすることができます。
### `NFTokenOffer`の準備金
1. `NFTokenCreateOffer`
各`NFTokenOffer`オブジェクトは、オファーを出すアカウントに1つ分の準備金の増額を要求します。執筆時点では、準備金の増分は2XRPです。この準備金は、オファーをキャンセルすることで取り戻すことができます。
2. `NFTokenCancelOffer`
### `NFTokenOfferID`のフォーマット
`NFTokenOffer`オブジェクトのユニークID(`NFTokenOfferID`)は、以下の値を順番に結合したものです。
3. `NFTokenAcceptOffer`
### `NFTokenOffer` オブジェクトの検索
各トークンには、2つのディレクトリがあります。1 つはトークンを購入するためのオファー、もう 1 つはトークンを売却するためのオファーが含まれています。これにより、特定のトークンの `NFTokenOffer` を簡単に見つけることができます。オフレッジャー システムが、オファーの取得、提示、通知、作成、照会、承認、キャンセルに使用されることが予想されます。たとえば、マーケットプレイスは、ウェブやアプリベースの直感的なインターフェースをユーザに提供することができます。
### `NFTokenOffer` の準備金
各NFTokenOfferオブジェクトは、オファーを出すアカウントに準備金の増額を1つ要求します。この記事の執筆時点では、準備金の増分は2 XRPです。この準備金は、オファーをキャンセルすることで 取り戻すことができます。
* `NFTokenOffer`のスペースキー、`0x0074`
* オファーを出すアカウントの`AccountID`
* `NFTokenCreateOffer`トランザクションが生成する`NFTokenCreateOffer`の`Sequence`(または`Ticket`)
<!--{# common link defs #}-->

2
content/references/protocol-reference/ledger-data/ledger-object-types/nftokenpage.ja.md
View File

@@ -9,7 +9,7 @@ labels:
`NFTokenPage` オブジェクトは、同じアカウントが所有する `NFToken` オブジェクトのコレクションを表します。一つのアカウントは複数の `NFTokenPage` 型のレジャーオブジェクトを持つことができ、それらは双方向リストを形成します。
_([NonFungibleTokensV1_1 amendment][]が必要です)_
_([NonFungibleTokensV1_1 amendment][]により追加されました)_
## {{currentpage.name}} JSONの例

4
content/references/protocol-reference/ledger-data/ledger-object-types/ripplestate.md
View File

@@ -12,7 +12,7 @@ The `RippleState` object type connects two accounts in a single currency. Concep
## High vs. Low Account
There can only be one `RippleState` object per currency for any given pair of accounts. Since no account is privileged in the XRP Ledger, a `RippleState` object sorts account addresses numerically, to ensure a canonical form. Whichever address is numerically lower when [decoded](accounts.html#address-encoding) is deemed the "low account" and the other is the "high account". The net balance of the trust line is stored from the low account's perspective.
There can only be one `RippleState` object per currency for any given pair of accounts. Since no account is privileged in the XRP Ledger, a `RippleState` object sorts account addresses numerically, to ensure a canonical form. Whichever address is numerically lower when [decoded](addresses.html#address-encoding) is deemed the "low account" and the other is the "high account". The net balance of the trust line is stored from the low account's perspective.
The ["issuer"](trust-lines-and-issuing.html) for the balance in a trust line depends on whether the balance is positive or negative. If a `RippleState` object shows a positive balance, the high account is the issuer. If the balance is negative, the low account is the issuer. Often, the issuer has its limit set to 0 and the other account has a positive limit, but this is not reliable because limits can change without affecting an existing balance.
@@ -52,7 +52,7 @@ A `RippleState` object has the following fields:
| Name | JSON Type | Internal Type | Required? | Description |
|:--------------------|:----------|:--------------|:----------|:------------|
| `Balance` | Object | Amount | Yes | The balance of the trust line, from the perspective of the low account. A negative balance indicates that the high account holds tokens issued by the low account. The issuer in this is always set to the neutral value [ACCOUNT_ONE](accounts.html#special-addresses). |
| `Balance` | Object | Amount | Yes | The balance of the trust line, from the perspective of the low account. A negative balance indicates that the high account holds tokens issued by the low account. The issuer in this is always set to the neutral value [ACCOUNT_ONE](addresses.html#special-addresses). |
| `Flags` | Number | UInt32 | Yes | A bit-map of boolean options enabled for this object. |
| `HighLimit` | Object | Amount | Yes | The limit that the high account has set on the trust line. The `issuer` is the address of the high account that set this limit. |
| `HighNode` | String | UInt64 | Yes | (Omitted in some historical ledgers) A hint indicating which page of the high account's owner directory links to this object, in case the directory consists of multiple pages. |

2
content/references/protocol-reference/ledger-data/ledger-object-types/ticket.ja.md
View File

@@ -37,7 +37,7 @@ _([TicketBatch amendment][]が必要です)_
| `Account` | 文字列 | AccountID | このチケットを所有する[アカウント](accounts.html)です。 |
| `Flags` | Number | UInt32 | ブール値フラグのビットマップ。Ticketにはフラグが定義されていないため、この値は常に0です。 |
| `OwnerNode` | 文字列 | UInt64 | 送金元の所有者ディレクトリが複数ページで構成されている場合に、このオブジェクトにリンクしているページを示すヒントです。注記: このオブジェクトには、オブジェクトを含む所有者ディレクトリへの直接リンクは含まれていません。これは、その値を`Account`から取得できるためです。 |
| `PreviousTxnID` | 文字列 | Hash256 | 最後にこのオブジェクトを変更した[トランザクション](transaction-basics.html)の識別用ハッシュ。 |
| `PreviousTxnID` | 文字列 | Hash256 | 最後にこのオブジェクトを変更した[トランザクション](transactions.html)の識別用ハッシュ。 |
| `PreviousTxnLgrSeq` | 数値 | UInt32 | 最後にこのオブジェクトを変更したトランザクションを含む[レジャーインデックス][Ledger Index]。 |
| `TicketSequence` | 数値 | UInt32 | 本チケットが設定する[シーケンス番号][]。 |

2
content/references/protocol-reference/ledger-data/ledger-object-types/ticket.md
View File

@@ -37,7 +37,7 @@ A `Ticket` object has the following fields:
| `Flags` | Number | UInt32 | Yes | A bit-map of boolean flags enabled for this object. Currently, the protocol defines no flags for `Ticket` objects. The value is always `0`. |
| `LedgerEntryType` | String | UInt16 | Yes | The value `0x0054`, mapped to the string `Ticket`, indicates that this object is a {{currentpage.name}} object. |
| `OwnerNode` | String | UInt64 | Yes | A hint indicating which page of the owner directory links to this object, in case the directory consists of multiple pages. **Note:** The object does not contain a direct link to the owner directory containing it, since that value can be derived from the `Account`. |
| `PreviousTxnID` | String | Hash256 | Yes | The identifying hash of the [transaction](transaction-basics.html) that most recently modified this object. |
| `PreviousTxnID` | String | Hash256 | Yes | The identifying hash of the [transaction](transactions.html) that most recently modified this object. |
| `PreviousTxnLgrSeq` | Number | UInt32 | Yes | The [index of the ledger][Ledger Index] that contains the transaction that most recently modified this object. |
| `TicketSequence` | Number | UInt32 | Yes | The [Sequence Number][] this Ticket sets aside. |