ARCHIVE/xrpl-dev-portal
1
0
Fork 0
mirror of https://github.com/XRPLF/xrpl-dev-portal.git synced 2025-11-03 19:35:50 +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

203
CONTRIBUTING.ja.md
View File

@@ -1,204 +1,3 @@
# コントリビューション
XRP Ledger開発者ポータルへのコントリビューションをご検討いただきありがとうございます。
ぜひ、皆様の力をお貸しくださいますようお願いいたします。ご協力いただくことで、XRP Ledger（XRPL）への理解を深めることができます。
また、XRPLと併せて、[インターレジャープロトコル（ILP）](https://interledger.org/)を学習することもおすすめいたします。ILPも[RippleX開発者エコシステム](https://ripplex.io)の一部です。
皆様からのプルリクエストをお待ちしております。プルリクエストのレビュー工程をできるだけ円滑に進めるためにも、本ドキュメントをお読みいただき、記載されているガイドラインに従ってください。
ご提供いただいたコードは、XRP Ledgerプロジェクトの著作物となり、MIT[ライセンス](LICENSE)に基づいて提供いたします。
## このサイトについて
XRPL開発者ポータルは、XRP Ledgerに関するドキュメントを幅広く提供します。これには、開発者がビルドを始めるためのサンプルコードなどの情報も含まれます。
## リポジトリーのレイアウト
- [assets/](assets/) - サイトのテンプレートに使用する静的ファイル。
- [content/](content/) - ドキュメントのビルドに使用するソースファイル。主にMarkdownです。
- [content/\_code-samples/](content/_code-samples/) - ドキュメントに使用するか、ドキュメントで参照するコードサンプル。可能であれば、完全に機能するか実行可能なスクリプトです。
- [content/\_img-sources/](content/_img-sources/) - ドキュメントで使用する画像のソースファイル。`.uxf`ファイルはすべて、[Umlet](https://www.umlet.com/)で作成された図です。
- [content/\_snippets/](content/_snippets/) - 再利用可能なMarkdownテキストのまとまり。Dactylプリプロセッサーを使用して他のコンテンツファイルに組み込みます。
- [img/](img/) - ドキュメントのコンテンツに使用する画像。
- [tool/](tool/) - テンプレート、スタイルチェッカーのルール、その他スクリプト。
- [`dactyl-config.yml`](dactyl-config.yml) - メインの設定ファイル。すべてのドキュメントのメタデータが含まれます。規約についての詳細は、[設定の書式](#設定の書式)を参照してください。
## プルリクエストを成功させるための要件
プルリクエストがレビューまたはマージの対象になるためには、各プルリクエストが以下を満たしている必要があります。
- 継続的インティグレーションテストに合格している。
- レビューの準備ができるまでは[ドラフトのマークが付けられている](https://github.blog/2019-02-14-introducing-draft-pull-requests/)。
- このリポジトリーの[行動規範](CODE_OF_CONDUCT.md)に従っている。
## Dactylのセットアップ
このポータルは、[Dactyl](https://github.com/ripple/dactyl)を使用して構築されています。
Dactylには[Python 3](https://python.org/)が必要です。以下のようにして[pip](https://pip.pypa.io/en/stable/)でインストールしてください。
`sudo pip3 install dactyl`
## サイトのビルド
このリポジトリーでは、[**Dactyl**](https://github.com/ripple/dactyl)を使用して、すべてのドキュメントのHTML表示のバージョンをビルドできます。[Dactylのセットアップ](#dactylのセットアップ)が完了したら、プロジェクトのルートディレクトリーから以下のコマンドを使用してドキュメントをビルドできます。
```
dactyl_build
```
生成されたコンテンツが`out/`ディレクトリーに出力されます。これらのコンテンツは、ウェブブラウザーでファイルとして開くことも、ウェブサーバーで静的コンテンツとして提供することもできます。
同様に、ルートディレクトリーからリンクチェックやスタイルチェックを実行することもできます。
リンクチェックは、出力フォルダーを空にし、ドキュメントをビルドしてから実行する必要があります。
```
dactyl_link_checker
```
スタイルチェックは試験的なものです。
```
dactyl_style_checker
```
### 日本語サイトのビルド
ターゲットと出力先を指定してビルドしてください。
```
dactyl_build -t ja -o out/ja
```
日本語サイトの場合、生成されたコンテンツをウェブブラウザーでファイルとして開くことができません。ローカルHTTPサーバーやエディターの拡張機能(VSCodeであればLive Serverなど)を利用してください。
##### ローカルでHTTPサーバを利用する方法
1. `out`直下で次のコマンドを実施しサーバーを起動する
```
python -m http.server
```
2. ウェブブラウザーから`localhost`にアクセスする。
サーバー起動時にアサインされたポート番号を利用してください。
## 設定の書式
このリポジトリー内のテンプレートは`dactyl-config.yml`ファイルのメタデータを使用して、生成されたサイトをナビゲートする際のページ階層を生成します。ナビゲーションを正しく生成するには、ページの定義に適切なフィールドを含める必要があります。以下の例に、すべてのフィールドを指定したページを示します。
```
- md: concept-authorized-trust-lines.md
funnel: Docs
doc_type: Concepts
category: Payment System
subcategory: Accounts
targets:
- local
```
ナビゲーションには、フィールド`funnel`、`doc_type`、`category`、および`subcategory`をこの順序（広範から詳細へ）で使用します。各階層では、新しい値が最初に記載されるページが、その階層の親かランディングとなります。（例えば、「Accounts」サブカテゴリーの親には`subcategory: Accounts`フィールドがあり、子より前に記載されている必要があります。）ランディングページの場合は、下位階層フィールドを省きます。（例えば、「Concepts」doc_typeのランディングページには、`doc_type`フィールドは必要ですが、`category`フィールドは不要です。）
**警告:** いずれかのフィールドに入力ミスがあると、ページがナビゲーションに表示されないか、誤った場所に表示されるおそれがあります。
規約として、親ページには、親である階層と同じ名前が必要です。（例えば、`Payment System`カテゴリーのランディングページの名前は`Payment System`である必要があります。）`md`をソースとするファイルの名前は、そのファイルの最初の行のヘッダーによって自動的に決まります。
Markdownソースコンテンツのないページの場合は、`md`行を省き、代わりに以下のフィールドを記載します。
| フィールド | 内容 |
|:----------|:----------|
| `name` | 人間が読めるページ名（プレーンテキストのみ） |
| `html` | ページの出力ファイル名`.html`で終わり、ターゲット内で一意である必要があります。 |
## 翻訳
XRP Ledger開発者ポータルは主に英語で記載されているため、通常は英語版が最新かつ正確なバージョンです。しかし、XRP Ledgerのソフトウェアとコミュニティーの利用者を拡大するため、このリポジトリーには翻訳版のドキュメントも含まれています。他の言語を理解するコミュニティーのメンバーの皆様には、どうか開発者ポータルのコンテンツを母国語に翻訳していただけますようお願いいたします。
`dactyl-config.yml`には、使用可能な各言語の「ターゲット」項目が含まれます。（2019年11月18日現在、使用可能な言語は英語と日本語です。）この項目には、テンプレートファイルで使用する文字列の辞書が含まれています。例:
```yaml
- name: en
lang: en
display_name: XRP Ledger Dev Portal
# These github_ fields are used by the template's "Edit on GitHub" link.
# Override them with --vars to change which fork/branch to edit.
github_forkurl: https://github.com/XRPLF/xrpl-dev-portal
github_branch: master
strings:
blog: "Blog"
search: "Search site with Google..."
bc_home: "Home"
# ...
```
サポート対象の各言語のプロパティーをいくつか定義する最上位の`languages`リストもあります。各言語のショートコードは、[IETF BCP47](https://tools.ietf.org/html/bcp47)に沿ったものである必要があります。例えば、英語は「en」、スペイン語は「es」、日本語は「ja」、簡体字中国語は「zh-CN」、繁体字中国語（台湾で使用）は「zh-TW」になります。`display_name`フィールドでは、言語名をその言語で記載して定義します。`prefix`フィールドでは、その言語版のサイトへのハイパーリンクに使用されるプレフィックスを定義します。`languages`のサンプルの定義を以下に示します。
```yaml
languages:
- code: en
display_name:English
prefix: "/"
- code: ja
display_name:日本語
prefix: "/ja/"
```
同じ`dactyl-config.yml`ファイルに、XRP Ledger開発者ポータルの各コンテンツページの項目が記載されています。ページが翻訳されている場合は、翻訳ごとに別個の項目があり、その翻訳「ターゲット」にリンクされています。ページがまだ翻訳されていない場合は、すべての対象に英語版が使用されます。各ページで、HTMLファイル名（`html`フィールド）とナビゲーションフィールド（`funnel`、`doc_type`、`supercategory`、`category`、および`subcategory`。それぞれ、指定される場合）は、どの言語版のページでも同じである必要があります。翻訳版のページで内容の異なるフィールドは、以下のとおりです（いずれの場合においても、そのフィールドが項目で使用される場合に限ります）。
- **`name`** - ページのタイトル。通常は、Markdownソースファイルを使用しないランディングページや、[開発者用ツール](https://xrpl.org/dev-tools.html)などの独自のテンプレートを使用する特殊なページでのみ指定されます。通常、Markdownのファイルではこのフィールドが省かれます。Dactylはファイルの最初の行のヘッダーからタイトルを引き出すためです。
- **`md`** - ページのソースコンテンツとして使用するMarkdownファイル。規約として、翻訳したMarkdownソースファイルには英語版と同じファイル名を使用する必要があります。ただし、ファイルの拡張子は英語版のように`.md`のみでなく、`.{language code}.md`とする必要があります。例えば、日本語の翻訳ファイルは`.ja.md`で終わります。
- **`blurb`** - ページの要約。このテキストは主にcategoryランディングページで使用されます。
以下の例に、`server_info`メソッドページの英語の項目と日本語の項目を示します。
```yaml
- md: references/http-websocket-apis/public-api-methods/server-info-methods/server_info.md
html: server_info.html
funnel: Docs
doc_type: References
supercategory: rippled API
category: Public rippled Methods
subcategory: Server Info Methods
blurb: Retrieve status of the server in human-readable format.
targets:
- en
- md: references/http-websocket-apis/public-api-methods/server-info-methods/server_info.ja.md
html: server_info.html
funnel: Docs
doc_type: References
supercategory: rippled API
category: Public rippled Methods
subcategory: Server Info Methods
blurb: rippledサーバーについての各種情報を、人間が読めるフォーマットでサーバーに要求します。
targets:
- ja
```
翻訳されていないページの項目の例は以下のとおりです。
```yaml
- md: concepts/payment-system-basics/transaction-basics/source-and-destination-tags.md
html: source-and-destination-tags.html
funnel: Docs
doc_type: Concepts
category: Payment System Basics
subcategory: Transaction Basics
blurb: Use source and destination tags to indicate specific purposes for payments from and to multi-purpose addresses.
targets:
- en
- ja
```
### 最初にすべきこと
XRP Ledger開発者ポータルを任意の母国語に翻訳いただける場合は、XRP Ledgerの主要なプロパティーと機能について説明する[XRP Ledgerの概要ファイル](https://github.com/XRPLF/xrpl-dev-portal/blob/master/content/concepts/introduction/xrp-ledger-overview.md)から始めてください。
ファイル名は`xrp-ledger-overview.{language code}.md`で保存してください。`{language code}`は[IETF BCP47](https://tools.ietf.org/html/bcp47)の言語コードです。（例えば、スペイン語は「es」、日本語は「ja」、簡体字中国語は「zh-CN」、台湾で使用される繁体字中国語は「zh-TW」などです。）その後、このリポジトリーにファイルを追加する[プルリクエスト](https://help.github.com/en/github/collaborating-with-issues-and-pull-requests/about-pull-requests)を開きます。リポジトリーのメンテナーが、サイトに言語を追加するために必要なその他のセットアップについてお手伝いします。
Markdownコンテンツのファイルについては、以下の規則に従ってください。
- 改行には改行文字（`\n`）のみを使用します（Unix形式）。復帰改行文字（`\r`）は使用しないでください（Windows形式）。
- UTF-8エンコーディングを使用します。バイトオーダーマークは使用しないでください。
コントリビューションの情報には[「ドキュメントへの貢献」](https://xrpl.org/ja/contribute-documentation.html)をご覧ください。

259
CONTRIBUTING.md
View File

@@ -1,260 +1,3 @@
# Contributing
Thanks for considering a contribution to the XRP Ledger Developer Portal!
We're thrilled you're interested and your help is greatly appreciated. Contributing is a great way to learn about the XRP Ledger (XRPL).
We are happy to review your pull requests. To make the process as smooth as possible, please read this document and follow the stated guidelines.
Contributions become copyright the XRP Ledger Project and are provided under the MIT [LICENSE](LICENSE).
## About This Site
The XRPL Dev Portal provides comprehensive documentation of the the XRP Ledger, including sample code and other information for developers to start building.
## Repository Layout
- [assets/](assets/) - Static files used by the site's templates.
- [content/](content/) - Source files used to build the documentation. Mostly in Markdown.
- [content/\_code-samples/](content/_code-samples/) - Code samples used or referenced by the documentation. Where possible, these are fully functional / executable scripts.
- [content/\_img-sources/](content/_img-sources/) - Source files for images used in the documentation. Any `.uxf` files are diagrams made with [Umlet](https://www.umlet.com/).
- [content/\_snippets/](content/_snippets/) - Reusable chunks of Markdown text that are included in other content files, using the Dactyl preprocessor.
- [img/](img/) - Images used by the documentation contents.
- [template/](template/) - Template files for building the HTML outputs.
- [tool/](tool/) - Filters, style-checker rules, and other scripts.
- [styles/](styles/) - Source files (SCSS) to generate the CSS files in the assets folder.
- [`dactyl-config.yml`](dactyl-config.yml) - Main config file, which contains the metadata for the site. For information on our conventions, see [Config Formatting](#config-formatting).
## Requirements for a Successful Pull Request
Before being considered for review or merging, each pull request must:
- Pass continuous integration tests.
- Be [marked as drafts](https://github.blog/2019-02-14-introducing-draft-pull-requests/) until they are ready for review.
- Adhere to the [code of conduct](CODE_OF_CONDUCT.md) for this repository.
## Dactyl Setup
The portal is built using [Dactyl](https://github.com/ripple/dactyl).
Dactyl requires [Python 3](https://python.org/). Install it with [pip](https://pip.pypa.io/en/stable/):
`sudo pip3 install dactyl
`
## Building the Site
This repo uses [**Dactyl**](https://github.com/ripple/dactyl) to build HTML display versions of all the documentation. After you've done the [Dactyl Setup](#dactyl-setup), you can build the site from the project root directory:
```
dactyl_build
```
This outputs the generated contents to the `out/` directory. These contents can be opened in a web browser as files or served as static content by a web server.
You can also run link checking or style checking from the root directory.
Link checking should be run after emptying the output folder and then building:
```
dactyl_link_checker
```
Style checking is experimental:
```
dactyl_style_checker
```
## Config Formatting
The templates in this repository use metadata from the `dactyl-config.yml` file as well as the pages' [frontmatter](https://dactyl.link/frontmatter.html) to generate navigation elements in the site, including header, footer, sidebars, and breadcrumbs.
If you add a new page, you must add it to the appropriate page in the pages array of the `dactyl-config.yml` file. An example entry looks like this:
```yaml
- md: concepts/the-rippled-server/the-rippled-server.md
targets:
- en
- ja # Include in all targets unless you have a translation
```
The Markdown file itself should start with a frontmatter stanza such as the following:
```yaml
---
html: the-rippled-server.html
parent: concepts.html
template: pagetype-category.html.jinja
blurb: rippled is the core peer-to-peer server that manages the XRP Ledger. This section covers concepts that help you learn the "what" and "why" behind fundamental aspects of the rippled server.
---
```
At a minimum, most pages should have `html`, `parent` and `blurb` fields (plus the `md` and `targets` fields in the config file). You can put any key-value pairs here or in the config file entry for the page, but the following ones are relevant:
| Field | Type | Contents |
|:---------------------|:-----------------|:-----------------------------------|
| `html` | String | Output filename for the page. Should end in `.html` and MUST be unique within the target. For translated pages, leave the filename the same as the English version page. |
| `parent` | String | The exact, unique `html` value of this page's "parent" page. Indicates where this page should appear in the navigation. |
| `blurb` | String | Human-readable summary of the page. (Plain text only.) Should be about 1 sentence long. This appears in various places, including landing pages and metadata used in unfurling links on social media. |
| `name` | String | Human-readable page name. (Plain text only.) For files with Markdown content, you should omit this so that Dactyl can automatically detect it from a header on the first line of the contents instead. This is usually only provided on landing pages or other special pages with no Markdown source file. |
| `template` | String | The filename of a template file to use (in the `template/` directory) for this page. Most pages should use the default template. The `pagetype-category.html.jinja` template shows a list of child pages at the end. Pages with special or particularly unique layouts may need individual templates (conventionally, starting with `page-`). |
| `status` | String | Use the value `not_enabled` on pages relating to an amendment that is not yet enabled on the XRP Ledger mainnet. This displays a "flask" badge with a tooltip next to the page in the navigation. |
| `nav_omit` | Boolean | Use `true` to cause this page not to appear in any navigation elements. |
| `top_nav_omit` | Boolean | Use `true` to cause this page not to appear in the page top dropdown navigation. |
| `top_nav_level` | Number | Adjust the indentation level for the page in the top nav dropdowns. Level `2` is indented to appear like a child of the page above it in the dropdown. |
| `sidebar` | String | Use `disabled` to hide the left and right sidebars (if the page uses a template derived from the base template) |
| `fb_card` | String | Filename of an image (in `assets/img/`) to use when unfurling links to this page on Facebook. |
| `twitter_card` | String | Filename of an image (in `assets/img/`) to use when unfurling links to this page on Twitter. |
| `redirect_url` | String | Use with `template: pagetype-redirect.html.jinja` only. Automatically redirect the user to the provided URL when they navigate to this page. |
| `cta_text` | String | Text to appear in "call to action" buttons that link to this page (on special landings). |
| `curated_anchors` | Array of Objects | A set of anchors in this page to show, similar to child pages, in landings. Each object in the array should have a human-readable `name` field (such as `"Available Modes"`) and an `anchor` field with the HTML ID to link to (such as `"#available-modes"`). |
| `skip_spell_checker` | Boolean | Use `true` to make the Dactyl's style checker skip spell-checking this page. |
| `filters` | Array of Strings | A list of additional filters to use on this page. [Filters](https://github.com/ripple/dactyl/blob/master/README.md#filters) are Python scripts that provide additional pre- or post-processing of page contents. |
| `canonical_url` | String | Provides the canonical URL for a page that takes query parameters. Search engines and other tools may use this when linking to the page. |
| `embed_xrpl_js` | Boolean | Use `true` to have the latest version of [xrpl.js](https://js.xrpl.org) loaded on the page. |
### Conventions
Use the following conventions when creating a page:
- The HTML filename and MD filename should match exactly except for the file extension.
- The filenames should closely match the title of the page, including words like "and" and "the", but should be in all lowercase with hyphens instead of spaces and punctuation. For example, `cash-a-check-for-an-exact-amount.md`. If you change the title of a page, change the filename too. (If it has already been published at another URL, leave a redirect from the old URL.)
- Always start a page with a h1 header.
- Don't link to the top h1 anchor of a page, link to the page itself without an anchor. This helps prevent broken links in translation. It's OK to link to later headers.
- Don't use any formatting (like _italics_ or `code font`) in the title of the page.
- Don't hard-wrap text in Markdown files.
- For code samples, try to keep lines no longer than 80 columns wide.
- When in doubt, follow [Ciro Santilli's Markdown Style Guide (Writability Profile)](https://cirosantilli.com/markdown-style-guide/).
- Landing pages should be in subfolders and should have the same filename as the folder. For example, the landing page of the "Accounts" page group should be `accounts/accounts.md` with the HTML filename `accounts.html`. **Don't** use `index.md`.
- Don't use tab characters for indentation in Markdown or code samples. Use **4 spaces per indent**, except in **JavaScript** code samples, which should use 2 spaces per indent.
### Terminology
Use the following words and phrases as described:
| Term | Terms to Avoid | Notes |
|-------------------|----------------|-------|
| API, APIs | API's, RPC | Application Programming Interface, a set of functions and definitions for software to connect to other software. |
| core server, core XRP Ledger server | `rippled` | The `rippled` name is probably going to be retired in the near future, so it's better to refer to it by the more generic name. When necessary, refer to `rippled` in all lowercase and code font. (It's pronounced "ripple dee", and the "d" stands for "daemon" per UNIX tradition.)
| financial institution | bank, FI, PSP (payment services provider) | This term encompasses a wider range of businesses than just _bank_ or other terms and does not rely on an understanding of industry jargon. |
| ledger entry | ledger object, node | A single object inside the state data of the XRP Ledger. The term _ledger object_ could refer to one of these or to the whole ledger. The term _node_ was sometimes used for this case because the ledger's state data can be envisioned as a graph, but this is confusing because _node_ has other uses. |
| liquidity provider | market maker | A business or individual who offers to exchange between two currencies or assets, often deriving income from the price differential between trades. The term _market maker_ has a specific legal definition in some jurisdictions and may not apply in all the same circumstances. |
| malicious actor | hacker | A person, organization, or even an automated tool which might attempt to acquire secrets, break encryption, deny service, or otherwise attack a secure resource. |
| a NFToken | NFT, an NFToken | A NFToken object in the XRP Ledger tracks or represents a non-fungible token. Pronounced "nif-token" and written _a NFToken_ rather than _an NFToken_ |
| PostgreSQL | Postgres | A specific brand of relational database software. Always use the full name, not an informal short version. |
| order book | orderbook, offer book | A collection of trade orders waiting to be matched and executed, typically sorted by exchange rate. Use two words. |
| server | node | A server is software and/or hardware, especially the ones that connect to the XRP Ledger peer-to-peer network. The term _node_ is sometimes used for this purpose but is also overloaded with other meanings including entries in a graph and Node.js, a JavaScript interpreter. |
| stablecoin issuer | gateway | An issuer is the organization that issues a token in the XRP Ledger. A stablecoin is a token where the issuer promises that it is fully backed by some outside asset (such as fiat currency), with the stablecoin issuer providing deposit and withdraw operations to convert between the two (possibly for a fee). Previously the term _gateway_ was used (especially by Ripple, the company) to describe this use case, but the rest of the industry adopted _stablecoin issuer_ instead. |
| transaction cost | transaction fee | The amount of XRP burnt to send a transaction in the XRP Ledger. Even though this is specified in the `Fee` field of transactions, the term _fee_ implies that the money is paid to someone, so _cost_ is preferable. |_
| trust line | trustline | Use two words. A trust line is a relationship between two accounts in the XRP Ledger that tracks a balance of tokens between those accounts. |
| tokens | IOUs, issuances, issues, issued currencies | A token in the XRP ledger may not represent money owed outside of the ledger as the name _IOU_ implies. Specify _fungible tokens_ if necessary to distinguish from non-fungible tokens. |
| wallet | wallet | Depending on the context, _wallet_ could refer to hardware, software, a cryptographic key pair, or an online service. Be sure to provide enough context that the meaning is clear, or use an alternative such as _key pair_ or _client application_. |
| WebSocket | web socket, Websockets | A two way protocol for communication on the web. Always singular and in CamelCase. |
| XRP | XRPs, ripples | The native digital asset, or cryptocurrency, of the XRP Ledger. XRP is not a token. |
| the XRP Ledger | XRP Ledger (no the), Ripple, Ripple Network, RCL | The XRP Ledger was called _the Ripple network_ and the _Ripple Consensus Ledger_ or _RCL_ at various times in the past. These names were confusing and have been retired because of their similarity to the name of the company, Ripple (formerly Ripple Labs) which develops the reference implementation of the core server. |
| XRPL | XRPL | Short for _XRP Ledger_. As much as possible, spell out _XRP Ledger_ instead; _XRPL_ is cryptic and looks like it could be a typo for _XRP_. |
## Translations
The XRP Ledger Dev Portal is mostly written in English, so the English version is generally the most up-to-date and accurate version. However, to broaden the reach of the XRP Ledger software and community, this repository also contains translated versions of the documentation. We strongly encourage members of the community who understand other languages to contribute translations of the dev portal contents in their native languages.
The `dactyl-config.yml` contains a "target" entry for each available language. (As of 2019-11-18, the available languages are English and Japanese.) This entry includes a dictionary of strings used in the template files. For example:
```yaml
- name: en
lang: en
display_name: XRP Ledger Dev Portal
# These github_ fields are used by the template's "Edit on GitHub" link.
# Override them with --vars to change which fork/branch to edit.
github_forkurl: https://github.com/XRPLF/xrpl-dev-portal
github_branch: master
strings:
blog: "Blog"
search: "Search site with Google..."
bc_home: "Home"
# ...
```
There is also a top-level `languages` listing that defines some properties for each supported language. The short code for each language should be short code according to [IETF BCP47](https://tools.ietf.org/html/bcp47). For example, "en" for English, "es" for Spanish, "ja" for Japanese, "zh-CN" for Simplified Chinese, "zh-TW" for Traditional Chinese (as used in Taiwan), and so on. The `display_name` field defines the language's name as written natively in that language. The `prefix` field defines a prefix to be used in hyperlinks to that language's version of the site. Example `languages` definition:
```yaml
languages:
- code: en
display_name: English
prefix: "/"
- code: ja
display_name: 日本語
prefix: "/ja/"
```
The same `dactyl-config.yml` file contains an entry for each content page in the XRP Ledger Dev Portal. If a page has been translated, there is a separate entry for each translation, linked to the "target" for that translation. If a page has not yet been translated, the English version is used across all targets.
By convention, a page's the HTML filename (`html` field) should be the same across all language versions of a page. Translated Markdown source files should use the same filename as the English-language version except that the file extension should be `.{language code}.md` instead of only `.md` for English. For example, Japanese translated files end in `.ja.md`
- **`blurb`** - a short summary of the page. This text is mostly used on category landing pages.
Example of English and Japanese entries for the `server_info` method page:
```yaml
- md: references/http-websocket-apis/public-api-methods/server-info-methods/server_info.md
targets:
- en
- md: references/http-websocket-apis/public-api-methods/server-info-methods/server_info.ja.md
targets:
- ja
```
Example entry for a page that isn't translated:
```yaml
- md: concepts/payment-system-basics/transaction-basics/source-and-destination-tags.md
targets:
- en
- ja
```
### Where to Start
If you want to translate the XRP Ledger Dev Portal into your native language of choice, start with the [XRP Ledger Overview file](https://github.com/XRPLF/xrpl-dev-portal/blob/master/content/concepts/introduction/xrp-ledger-overview.md), which describes the core properties and functions of the XRP Ledger.
Save the file as `xrp-ledger-overview.{language code}.md`, where `{language code}` is the [IETF BCP47](https://tools.ietf.org/html/bcp47) language code. (For example, "es" for Spanish, "ja" for Japanese, "zh-CN" for Simplified Chinese, "zh-TW" for Traditional Chinese as used in Taiwan, and so on.) Then open a [pull request](https://help.github.com/en/github/collaborating-with-issues-and-pull-requests/about-pull-requests) adding your file to this repository. One of the repository's maintainers can help with the other necessary setup to add the language to the site.
For the Markdown content files, please use the following conventions:
- Line-feed newline characters (`\n`) only (Unix style). Do not use carriage return (`\r`) characters (Windows style).
- Use UTF-8 encoding. Avoid the use of Byte-order marks.
## Theme-Aware Diagrams
The site contains code to automatically recolor SVG diagrams for light and dark mode. This is more than just inverting images. The recoloring keeps gradients going the same direction (so that things don't look bottom-lit) and replaces colors with equivalents that fit with the theme rather than their inverse. For example, "Ripple blue" gets recolored to XRPL green, not its inverse orange. Example:
![Comparison of invert and theme-aware recoloring](./theme-aware-recolor.png)
Theme-aware recoloring uses a single source file in SVG format for diagrams, and produces diagrams that are recolored to match the current theme (light/dark) using CSS. If the user changes their theme, the diagrams immediately change to match it.
To include a theme-aware diagram in a document, use the `include_svg` filter with syntax such as the following:
```jinja
{{ include_svg("img/anatomy-of-a-ledger-complete.svg", "Figure 1: XRP Ledger Elements") }}
```
Leave empty lines before and after this syntax. The SVG file in question should be in the [`img/`](./img/) folder at the top level of the repo, or a subfolder of it. The second argument is _title text_, which appears when the user hovers their mouse over the diagram, and can also be used by other software (such as screen readers) to caption the diagram.
The resulting SVG file is inlined directly into the Markdown file. One limitation is that you can't use it inside other Markdown structures such as bulleted lists or tables.
> **Note:** The filter source code is [`tool/filter_include_svg.py`](./tool/filter_include_svg.py). This is also the reason that `lxml` is one of the dependencies for building the site.
### Making Diagrams
You have to take care when creating diagrams so that the recoloring applies correctly; otherwise, some elements might be invisible (white-on-white or black-on-black, for example) when recolored for the other theme. The theme-aware diagrams code supports diagrams created using either [Umlet](https://www.umlet.com/) or [Google Draw](https://docs.google.com/drawings/) and exported as SVG. Additionally, you should follow these guidelines when making diagrams:
0. Create diagrams for light mode by default. Use a transparent background color.
0. Only use colors that the theme-aware diagrams code has mappings for. The code for this, including the full list of colors, is in [`styles/_diagrams.scss`](./styles/_diagrams.scss). If needed, you can add new colors by extending the SCSS code. (Don't forget to re-export the CSS when you're done. See the [styles README](./styles/README.md).)
0. Use actual vector shapes instead of embedded icons/images whenever possible. If you need to put text on top of an image, add a solid background to the text element and use one of the colors the theme has mappings for.
0. Don't layer transparent elements containing text on top of elements with different background colors. Apply a background color directly to the element that contains the text.
For information about how to contribute to this repository, see [Contribute Documentation (XRPL.org)](https://xrpl.org/contribute-documentation.html).

2
assets/css/devportal2022-v23.css
View File

File diff suppressed because one or more lines are too long

82
assets/js/js-editor.js
View File

@@ -1,82 +0,0 @@
// Interactive JavaScript editor code
let js_interactives = {};
$(document).ready(()=> {
$(".js_interactive").each((i, el) => {
const wrapper = $(el);
const interactive_id = wrapper.attr("id");
const code_blocks = wrapper.find("pre code");
const code_ex0 = code_blocks.eq(0); // First code block is the default
const og_text = code_ex0.text().trim();
const cm = CodeMirror(wrapper.find(".editor").get(0), {
mode: 'javascript',
json: false,
smartIndent: false,
gutters: ["CodeMirror-lint-markers"],
lint: CodeMirror.lint.javascript
});
cm.setValue(og_text);
code_ex0.parent().hide();
wrapper.find(".reset-button").click((evt) => {
cm.setValue(og_text);
wrapper.find(".response").empty();
});
wrapper.find(".run-button").click((evt) => {
// Wipe the results area and make a new response CodeMirror
const resp = wrapper.find(".response");
resp.empty().append("<p><strong>Output</strong></p>");
// TODO: make "Response" translatable
const cm_resp = CodeMirror(resp.get(0), {
mode: 'javascript',
json: false,
readOnly: true,
gutters: ["CodeMirror-lint-markers"]
});
const oldconsole = console;
console = {
log: (...args) => {
oldconsole.log(...args);
cm_resp.setValue(args.map(x => JSON.stringify(x, null, 2)).join(" "));
},
warn: (...args) => {
oldconsole.warn(...args);
cm_resp.setValue(args.map(x => JSON.stringify(x, null, 2)).join(" "));
},
error: (...args) => {
oldconsole.error(...args);
cm_resp.setValue(args.map((x) => {
if (x instanceof Error) return x.toString();
return JSON.stringify(x, null, 2);
}).join(" "));
}
}
try {
Function(cm.getValue())();
} catch(error) {
console.error(error);
}
});
js_interactives[interactive_id] = {}
code_blocks.slice(1).each((i, el) => {
// Turn each additional code block into a function that fills in the
// editor with the provided text example.
// Example: js_interactives.some_unique_id.ex_1()
const code_ex = $(el);
const ex_text = code_ex.text().trim();
js_interactives[interactive_id]["ex_"+(i+1)] = function() {
//
cm.setValue(ex_text);
$("html").animate({scrollTop: wrapper.offset().top}, 500);
}
code_ex.parent().hide();
});
})
});

42
content/_code-samples/escrow/js/cancel-escrow-v2.js Normal file
View File

@@ -0,0 +1,42 @@
// Code in progress.
const xrpl = require("xrpl")
async function main() {
// Create a client and connect to the network.
const client = new xrpl.Client("wss://xrplcluster.com/")
await client.connect()
// Query the most recently validated ledger for info.
const ledger = await client.request({
"command": "ledger",
"ledger_index": "validated",
})
const ledgerCloseTime = ledger["result"]["ledger"]["close_time"]
// Check the `CancelAfter` time of the escrow.
// For this example, we have the identifying hash of the `EscrowCreate` transaction.
const escrowInfo = await client.request({
"command": "tx",
"transaction": "3DC728E4DB4120AD26DD41997C42FF5AD46C0073D8692AFB8F59660D058D87A3",
})
const escrowAccountSender = escrowInfo["result"]["Account"]
const escrowCancelAfter = escrowInfo["result"]["CancelAfter"]
const escrowSequence = escrowInfo["result"]["Sequence"]
// Submit an `EscrowCancel` transaction if the cancel after time is smaller than the ledger close time.
// Any valid account can submit an escrow cancel transaction.
if (escrowCancelAfter < ledgerCloseTime) {
client.submitAndWait({
"Account": escrowAccountSender,
"TransactionType": "EscrowCancel",
"Owner": escrowAccountSender,
"OfferSequence": escrowSequence
})
}
client.disconnect()
}
main()

2
content/_code-samples/secure-signing/README.md
View File

@@ -2,4 +2,4 @@
Sign transactions from the security of your own machine.
For more information and more options, see [Set Up Secure Signing](https://xrpl.org/set-up-secure-signing.html).
For more information and more options, see [Set Up Secure Signing](https://xrpl.org/secure-signing.html).

2
content/_snippets/checkcash-prereqs.ja.md
View File

@@ -5,5 +5,5 @@ Checkを換金するための前提条件は、正確な金額を換金する場
- Checkに記載されている受取人の**アドレス**と**秘密鍵**。このアドレスは、Checkオブジェクトの`Destination`アドレスと一致している必要があります。
- 発行済み通貨用のCheckの場合は、ご自身（受取人）にイシュアーに対するトラストラインがある必要があります。このトラストライン上のご自身の限度額は、受け取る金額を追加するための残高より十分高くなければなりません。
- トラストラインと限度額について詳しくは、[発行済み通貨](issued-currencies.html)および[トラストラインと発行](trust-lines-and-issuing.html)を参照してください。
- [トランザクションに安全に署名できる手段](set-up-secure-signing.html)。
- [トランザクションに安全に署名できる手段](secure-signing.html)。
- XRP Ledgerに接続できる[クライアントライブラリ](client-libraries.html)か、それとも[HTTPライブラリ、WebSocketライブラリなど](get-started-using-http-websocket-apis.html)。

2
content/_snippets/checkcash-prereqs.md
View File

@@ -4,5 +4,5 @@ The prerequisites for cashing a check are the same whether you are cashing it fo
- For example, the ID of one Check in these examples is `838766BA2B995C00744175F69A1B11E32C3DBC40E64801A4056FCBD657F57334`, although you must use a different ID to go through these steps yourself.
- The **address** and **secret key** of the Check's stated recipient. The address must match the `Destination` address in the Check object.
- If the Check is for a [token](tokens.html), you (the recipient) must have a [trust line](trust-lines-and-issuing.html) to the issuer. Your limit on that trust line must be high enough to hold your previous balance plus the amount you would receive.
- A [secure way to sign transactions](set-up-secure-signing.html).
- A [secure way to sign transactions](secure-signing.html).
- A [client library](client-libraries.html) that can connect to the XRP Ledger, or [any HTTP or WebSocket client](get-started-using-http-websocket-apis.html).

2
content/_snippets/data_types/account_sequence.ja.md
View File

@@ -1,6 +1,6 @@
シーケンス番号とは、32ビットの符号なし整数であり、指定された送金元からのトランザクションが正しい順序で1回だけ実行されるようにするために使用されます。
すべての[XRP Ledgerアカウント](accounts.html)には、`Sequence`フィールドに1つのシーケンス番号があり、アカウントがトランザクションを送信し、そのトランザクションが[検証済みレジャー](ledgers.html)に記録されるたびに、1ずつ増加します。シーケンス番号は各[トランザクション](transaction-basics.html)の`Sequence`フィールドにもあり、そのトランザクションが実行される際にアカウントの現在のシーケンス番号と一致している必要があります。各アカウントで、各シーケンス番号は番号順に一度だけ使用できます。
すべての[XRP Ledgerアカウント](accounts.html)には、`Sequence`フィールドに1つのシーケンス番号があり、アカウントがトランザクションを送信し、そのトランザクションが[検証済みレジャー](ledgers.html)に記録されるたびに、1ずつ増加します。シーケンス番号は各[トランザクション](transactions.html)の`Sequence`フィールドにもあり、そのトランザクションが実行される際にアカウントの現在のシーケンス番号と一致している必要があります。各アカウントで、各シーケンス番号は番号順に一度だけ使用できます。
[DeletableAccounts Amendment](known-amendments.html#deletableaccounts) を適用する場合、アカウントの`Sequence`番号の始まりが、アカウントが作成されたレジャーバージョンの[レジャーインデックス][]と一致します。DeletableAccountsを適用しない場合、どのアカウントの`Sequence`番号も1で始まります。

2
content/_snippets/data_types/account_sequence.md
View File

@@ -1,6 +1,6 @@
A sequence number is a 32-bit unsigned integer that is used to make sure transactions from a given sender execute only once each, and in the correct order.
Every [account in the XRP Ledger](accounts.html) has a sequence number in its `Sequence` field, which increases by 1 whenever that account sends a transaction and that transaction gets included in a [validated ledger](ledgers.html). Each [transaction](transaction-basics.html) also has a sequence number in its `Sequence` field, which must match the account's current sequence number when the transaction executes. For each account, each sequence number can only be used once, in numerical order.
Every [account in the XRP Ledger](accounts.html) has a sequence number in its `Sequence` field, which increases by 1 whenever that account sends a transaction and that transaction gets included in a [validated ledger](ledgers.html). Each [transaction](transactions.html) also has a sequence number in its `Sequence` field, which must match the account's current sequence number when the transaction executes. For each account, each sequence number can only be used once, in numerical order.
[Tickets](tickets.html) make some exceptions from these rules so that it is possible to send transactions out of the normal order. Tickets represent sequence numbers reserved for later use; a transaction can use a Ticket instead of a normal sequence number.

2
content/_snippets/data_types/address.ja.md
View File

@@ -3,7 +3,7 @@ XRP Ledgerのアカウントは、XRP Ledgerの[base58][]フォーマットの
* 長さは25から35文字です
* 文字`r`で始まります
**注記:** XRPコミュニティは、取引所およびウォレットで[宛先タグ](https://xrpl.org/source-and-destination-tags.html)の代わりに使用できる新しいフォーマット、**X**アドレスを[提案](https://github.com/XRPLF/XRPL-Standards/issues/6)（これをサポートする[コーデック](https://github.com/xrp-community/xrpl-tagged-address-codec)も開発）しました。これらの「パック化」したアドレスは、`r`ではなく`X`で開始します。詳細は、[𝗫-address format](https://xrpaddress.info/)のサイトを参照してください。
**注記:** XRPコミュニティは、取引所およびウォレットで[宛先タグ](source-and-destination-tags.html)の代わりに使用できる新しいフォーマット、**X**アドレスを[提案](https://github.com/XRPLF/XRPL-Standards/issues/6)（これをサポートする[コーデック](https://github.com/xrp-community/xrpl-tagged-address-codec)も開発）しました。これらの「パック化」したアドレスは、`r`ではなく`X`で開始します。詳細は、[𝗫-address format](https://xrpaddress.info/)のサイトを参照してください。
* 英数字を使用します（数字「`0`」、大文字「`O`」、大文字「`I`」、小文字「`l`」を除く）
* 大/小文字を区別します

2
content/_snippets/data_types/address.md
View File

@@ -6,7 +6,7 @@ Accounts in the XRP Ledger are identified by an address in the XRP Ledger's [bas
* Case-sensitive
* Includes a 4-byte checksum so that the probability of generating a valid address from random characters is approximately 1 in 2<sup>32</sup>
> **Note:** The XRP community has [proposed](https://github.com/XRPLF/XRPL-Standards/issues/6) an **X**-address format that "packs" a [destination tag](source-and-destination-tags.html) into the address. These addresses start with an `X` (for the mainnet) or a `T` (for the [testnet](parallel-networks.html)). Exchanges and wallets can use X-addresses to represent all the data a customer needs to know in one value. For more information, see the [X-address format site](https://xrpaddress.info/) and [codec](https://github.com/xrp-community/xrpl-tagged-address-codec).
> **Note:** There is also an **X**-address format that "packs" a [destination tag](source-and-destination-tags.html) into the address. These addresses start with an `X` (for Mainnet) or a `T` (for [test networks](parallel-networks.html)). Exchanges and wallets can use X-addresses to represent all the data a customer needs to know in one value. For more information, see the [X-address format site](https://xrpaddress.info/) and [codec](https://github.com/xrp-community/xrpl-tagged-address-codec).
>
> The XRP Ledger protocol only supports "classic" addresses natively, but many [client libraries](client-libraries.html) support X-addresses too.

4
content/_snippets/rippled-api-links.md
View File

@@ -15,8 +15,8 @@
[XRPのdrop数]: basic-data-types.html#通貨額の指定
[Hash]: basic-data-types.html#hashes
[ハッシュ]: basic-data-types.html#ハッシュ
[identifying hash]: transaction-basics.html#identifying-transactions
[識別用ハッシュ]: transaction-basics.html#トランザクションの識別
[identifying hash]: transactions.html#identifying-transactions
[識別用ハッシュ]: transactions.html#トランザクションの識別
[Internal Type]: serialization.html
[内部の型]: serialization.html
[Ledger Index]: basic-data-types.html#ledger-index

2
content/_snippets/string-number-formatting.md
View File

@@ -1,4 +1,4 @@
XRP Ledger APIs generally use strings, rather than native JSON numbers, to represent numeric amounts of currency for both [XRP](xrp.html) and [tokens](tokens.html). This protects against a loss of precision when using JSON parsers, which may automatically try to represent all JSON numbers in a floating-point format. Within the String value, the numbers are serialized in the same way as native JSON numbers:
XRP Ledger APIs generally use strings, rather than native JSON numbers, to represent numeric amounts of currency for both [XRP](what-is-xrp.html) and [tokens](tokens.html). This protects against a loss of precision when using JSON parsers, which may automatically try to represent all JSON numbers in a floating-point format. Within the String value, the numbers are serialized in the same way as native JSON numbers:
* Base-10.
* Non-zero-prefaced.

2
content/_snippets/tutorial-sign-step.md
View File

@@ -1,3 +1,3 @@
The most secure way to sign a transaction is to [sign locally with a client library](set-up-secure-signing.html#local-signing-example). Alternatively, if you run your own `rippled` node you can sign the transaction using the [sign method](sign.html), but this must be done through a trusted and encrypted connection, or through a local (same-machine) connection.
The most secure way to sign a transaction is to [sign locally with a client library](secure-signing.html#local-signing-example). Alternatively, if you run your own `rippled` node you can sign the transaction using the [sign method](sign.html), but this must be done through a trusted and encrypted connection, or through a local (same-machine) connection.
In all cases, note the signed transaction's identifying hash for later.

4
content/_snippets/tx-metadata-field-table.md
View File

@@ -1,7 +1,7 @@
| Field | Value | Description |
|:----------------------------------------|:--------------------|:-------------|
| `AffectedNodes` | Array | List of [ledger objects](ledger-object-types.html) that were created, deleted, or modified by this transaction, and specific changes to each. |
| `AffectedNodes` | Array | List of [ledger entries](ledger-object-types.html) that were created, deleted, or modified by this transaction, and specific changes to each. |
| `DeliveredAmount` | [Currency Amount][] | _(May be omitted)_ For a [partial payment](partial-payments.html), this field records the amount of currency actually delivered to the destination. To avoid errors when reading transactions, instead use the `delivered_amount` field, which is provided for all Payment transactions, partial or not. |
| `TransactionIndex` | Unsigned Integer | The transaction's position within the ledger that included it. This is zero-indexed. (For example, the value `2` means it was the 3rd transaction in that ledger.) |
| `TransactionResult` | String | A [result code](transaction-results.html) indicating whether the transaction succeeded or how it failed. |
| [`delivered_amount`](transaction-metadata.html#delivered_amount) | [Currency Amount][] | _(Omitted for non-Payment transactions)_ The [Currency Amount][] actually received by the `Destination` account. Use this field to determine how much was delivered, regardless of whether the transaction is a [partial payment](partial-payments.html). See [this description](transaction-metadata.html#delivered_amount) for details. [New in: rippled 0.27.0][] |
| [`delivered_amount`](transaction-metadata.html#delivered_amount) | [Currency Amount][] | _(Omitted for non-Payment transactions)_ The [Currency Amount][] actually received by the `Destination` account. Use this field to determine how much was delivered, regardless of whether the transaction is a [partial payment](partial-payments.html). See [this description](transaction-metadata.html#delivered_amount) for details. |

6
content/concepts/tokens/issuing-and-operational-addresses.ja.md → content/concepts/accounts/account-types.ja.md
View File

@@ -1,6 +1,6 @@
---
html: issuing-and-operational-addresses.html
parent: tokens.html
html: account-types.html
parent: accounts.html
blurb: XRP Ledgerで自動的にトランザクションを送信するビジネスは、リスクを最小限に抑えるために目的ごとに別のアドレスを設定することをおすすめします。
labels:
- トークン
@@ -63,7 +63,7 @@ XRP LedgerのXRP以外の残高はすべて、2つのXRP Ledgerアドレス間
- [アカウント](accounts.html)
- [暗号鍵](cryptographic-keys.html)
- **チュートリアル:**
- [XRP Ledgerゲートウェイの開設](become-an-xrp-ledger-gateway.html)
- [XRP Ledgerゲートウェイの開設](stablecoin-issuer.html)
- [レギュラーキーペアの割り当て](assign-a-regular-key-pair.html)
- [レギュラーキーペアの変更または削除](change-or-remove-a-regular-key-pair.html)
- **リファレンス:**

7
content/concepts/tokens/issuing-and-operational-addresses.md → content/concepts/accounts/account-types.md
View File

@@ -1,12 +1,12 @@
---
html: issuing-and-operational-addresses.html
parent: tokens.html
html: account-types.html
parent: accounts.html
blurb: Businesses sending transactions on the XRP Ledger automatically should set up separate addresses for different purposes to minimize risk.
labels:
- Tokens
- Security
---
# Issuing and Operational Addresses
# Account Types
{% include '_snippets/issuing-and-operational-addresses-intro.md' %}
<!--{#_ #}-->
@@ -73,7 +73,6 @@ If a standby address is compromised, the consequences are like an operational ad
- [Accounts](accounts.html)
- [Cryptographic Keys](cryptographic-keys.html)
- **Tutorials:**
- [Become an XRP Ledger Gateway](become-an-xrp-ledger-gateway.html)
- [Assign a Regular Key Pair](assign-a-regular-key-pair.html)
- [Change or Remove a Regular Key Pair](change-or-remove-a-regular-key-pair.html)
- **References:**

8
content/concepts/payment-system-basics/accounts/accounts.ja.md → content/concepts/accounts/accounts.ja.md
View File

@@ -1,6 +1,6 @@
---
html: accounts.html
parent: payment-system-basics.html
parent: concepts.html
blurb: XRP Ledgerのアカウントについて説明します。アカウントはトランザクションを送信でき、XRPを保有できます。
labels:
- アカウント
@@ -12,12 +12,12 @@ XRP Ledgerの「アカウント」は、XRPの所有者と[トランザクショ
- 識別用の**アドレス**。例えば、`rf1BiGeXwwQoi8Z2ueFYTEXSwuJYfV2Jpn`
**注記:** XRPコミュニティは、取引所およびウォレットで[宛先タグ](https://xrpl.org/source-and-destination-tags.html)の代わりに使用できる新しいフォーマット、**X**アドレスを[提案](https://github.com/XRPLF/XRPL-Standards/issues/6)（これをサポートする[コーデック](https://github.com/xrp-community/xrpl-tagged-address-codec)も開発）しました。これらの「パック化」したアドレスは、`r`ではなく`X`で開始します。詳細は、[XRPL 𝗫-address format](https://xrpaddress.info/)のサイトを参照してください。
**注記:** XRPコミュニティは、取引所およびウォレットで[宛先タグ](source-and-destination-tags.html)の代わりに使用できる新しいフォーマット、**X**アドレスを[提案](https://github.com/XRPLF/XRPL-Standards/issues/6)（これをサポートする[コーデック](https://github.com/xrp-community/xrpl-tagged-address-codec)も開発）しました。これらの「パック化」したアドレスは、`r`ではなく`X`で開始します。詳細は、[XRPL 𝗫-address format](https://xrpaddress.info/)のサイトを参照してください。
- **XRPの残高**。このXRPの一部は、[準備金](reserves.html)用に確保されています。
- **シーケンス番号**。このアカウントから送信されるトランザクションがすべて、正しい順序で、それぞれ1回のみ適用されるようにします。トランザクションを実行するには、トランザクションのシーケンス番号と送金元のシーケンス番号が一致する必要があります。その後も、トランザクションが適用されている限り、アカウントのシーケンス番号は1ずつ増加します。（関連項目: [基本的なデータタイプ: アカウントシーケンス](basic-data-types.html#アカウントシーケンス)）
- このアカウントと残高に影響を及ぼした**取引の履歴**。
- [トランザクションの承認](transaction-basics.html#トランザクションの承認)方法。以下に例を示します。
- [トランザクションの承認](transactions.html#トランザクションの承認)方法。以下に例を示します。
- アカウント固有のマスターキーのペア。（[無効](accountset.html)にできますが、変更はできません。）
- [ローテーションで使用](setregularkey.html)できる「レギュラー」キーペア。
- [マルチシグ](multi-signing.html)の署名者のリスト。（アカウントのコアデータとは別に保存されます。）
@@ -169,7 +169,7 @@ XRP Ledgerのアドレスは、[base58][]_形式のディクショナリ_`rpshna
- **コンセプト:**
- [準備金](reserves.html)
- [暗号鍵](cryptographic-keys.html)
- [発行アドレスと運用アドレス](issuing-and-operational-addresses.html)
- [発行アドレスと運用アドレス](account-types.html)
- **リファレンス:**
- [account_infoメソッド][]
- [wallet_proposeメソッド][]

71
content/concepts/accounts/accounts.md Normal file
View File

@@ -0,0 +1,71 @@
---
html: accounts.html
parent: concepts.html
blurb: Learn about accounts in the XRP Ledger. Accounts can send transactions and hold XRP.
labels:
- Accounts
- Payments
---
# Accounts
An "Account" in the XRP Ledger represents a holder of XRP and a sender of [transactions](transaction-formats.html).
An account consists of an address, an XRP balance, a sequence number, and a history of its transactions. To be able to send transactions, the owner also needs one or more cryptographic key pairs associated with the account.
## Account Structure
The core elements of an account are:
- An identifying **address**, such as `rf1BiGeXwwQoi8Z2ueFYTEXSwuJYfV2Jpn`.
- An **XRP balance**. Some of this XRP is set aside for the [Reserve](reserves.html).
- A **sequence number**, which helps make sure any transactions this account sends are applied in the correct order and only once. To execute a transaction, the transaction's sequence number and its sender's sequence number must match. Then, as part of applying the transaction, the account's sequence number increases by 1. (See also: [Basic Data Types: Account Sequence](basic-data-types.html#account-sequence).)
- A **history of transactions** that affected this account and its balances.
- One or more ways to [authorize transactions](transactions.html#authorizing-transactions), possibly including:
- A master key pair intrinsic to the account. (This can be disabled but not changed.)
- A "regular" key pair that can be rotated.
- A signer list for [multi-signing](multi-signing.html). (Stored separately from the account's core data.)
An account's core data is stored in an [AccountRoot](accountroot.html) ledger entry. An account can also be the owner (or partial owner) of several other types of ledger entry.
**Tip:** An "Account" in the XRP Ledger is somewhere between the financial usage (like "bank account") and the computing usage (like "UNIX account"). Non-XRP currencies and assets aren't stored in an XRP Ledger Account itself; each such asset is stored in an accounting relationship called a "Trust Line" that connects two parties.
## Creating Accounts
There is not a dedicated "create account" transaction. The [Payment transaction][] automatically creates a new account if the payment sends enough XRP to a mathematically-valid address that does not already have an account. This is called _funding_ an account, and creates an [AccountRoot entry](accountroot.html) in the ledger. No other transaction can create an account.
**Caution:** Funding an account **does not** give you any special privileges over that account. Whoever has the secret key corresponding to the account's address has full control over the account and all XRP it contains. For some addresses, it's possible that no one has the secret key, in which case the account is a [black hole](addresses.html#special-addresses) and the XRP is lost forever.
The typical way to get an account in the XRP Ledger is as follows:
1. Generate a key pair from a strong source of randomness and calculate the address of that key pair.
2. Have someone who already has an account in the XRP Ledger send XRP to the address you generated.
- For example, you can buy XRP in a private exchange, then withdraw XRP from the exchange to the address you specified.
**Caution:** The first time you receive XRP at your own XRP Ledger address, you must pay the [account reserve](reserves.html) (currently 10 XRP), which locks up that amount of XRP indefinitely. In contrast, private exchanges usually hold all their customers' XRP in a few shared XRP Ledger accounts, so customers don't have to pay the reserve for individual accounts at the exchange. Before withdrawing, consider whether having your own account directly on the XRP Ledger is worth the price.
## See Also
- **Concepts:**
- [Reserves](reserves.html)
- [Cryptographic Keys](cryptographic-keys.html)
- [Issuing and Operational Addresses](account-types.html)
- **References:**
- [account_info method][]
- [wallet_propose method][]
- [AccountSet transaction][]
- [Payment transaction][]
- [AccountRoot object](accountroot.html)
- **Tutorials:**
- [Manage Account Settings (Category)](manage-account-settings.html)
- [Monitor Incoming Payments with WebSocket](monitor-incoming-payments-with-websocket.html)
<!--{# common link defs #}-->
{% include '_snippets/rippled-api-links.md' %}
{% include '_snippets/tx-type-links.md' %}
{% include '_snippets/rippled_versions.md' %}

89
content/concepts/accounts/addresses.md Normal file
View File

@@ -0,0 +1,89 @@
---
html: addresses.html
parent: accounts.html
blurb: Addresses uniquely identify XRP Ledger accounts, using base58 format.
labels:
- Accounts
---
# Addresses
{% include '_snippets/data_types/address.md' %}
Any valid address can [become an account in the XRP Ledger](accounts.html#creating-accounts) by being funded. You can also use an address that has not been funded to represent a [regular key](cryptographic-keys.html) or a member of a [signer list](multi-signing.html). Only a funded account can be the sender of a transaction.
Creating a valid address is a strictly mathematical task starting with a key pair. You can generate a key pair and calculate its address entirely offline without communicating to the XRP Ledger or any other party. The conversion from a public key to an address involves a one-way hash function, so it is possible to confirm that a public key matches an address but it is impossible to derive the public key from the address alone. (This is part of the reason why signed transactions include the public key _and_ the address of the sender.)
## Special Addresses
Some addresses have special meaning, or historical uses, in the XRP Ledger. In many cases, these are "black hole" addresses, meaning the address is not derived from a known secret key. Since it is effectively impossible to guess a secret key from only an address, any XRP possessed by black hole addresses is lost forever.
| Address | Name | Meaning | Black Hole? |
|-------------------------------|------|---------|-------------|
| `rrrrrrrrrrrrrrrrrrrrrhoLvTp` | ACCOUNT\_ZERO | An address that is the XRP Ledger's [base58][] encoding of the value `0`. In peer-to-peer communications, `rippled` uses this address as the issuer for XRP. | Yes |
| `rrrrrrrrrrrrrrrrrrrrBZbvji` | ACCOUNT\_ONE | An address that is the XRP Ledger's [base58][] encoding of the value `1`. In the ledger, [RippleState entries](ripplestate.html) use this address as a placeholder for the issuer of a trust line balance. | Yes |
| `rHb9CJAWyB4rj91VRWn96DkukG4bwdtyTh` | The genesis account | When `rippled` starts a new genesis ledger from scratch (for example, in stand-alone mode), this account holds all the XRP. This address is generated from the seed value `masterpassphrase` which is [hard-coded](https://github.com/ripple/rippled/blob/94ed5b3a53077d815ad0dd65d490c8d37a147361/src/ripple/app/ledger/Ledger.cpp#L184). | No |
| `rrrrrrrrrrrrrrrrrNAMEtxvNvQ` | Ripple Name reservation black-hole | In the past, Ripple asked users to send XRP to this account to reserve Ripple Names.| Yes |
| `rrrrrrrrrrrrrrrrrrrn5RM1rHd` | NaN Address | Previous versions of [ripple-lib](https://github.com/XRPLF/xrpl.js) generated this address when encoding the value [NaN](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/NaN) using the XRP Ledger's [base58][] string encoding format. | Yes |
## Address Encoding
**Tip:** These technical details are only relevant for people building low-level library software for XRP Ledger compatibility!
[[Source]](https://github.com/ripple/rippled/blob/35fa20a110e3d43ffc1e9e664fc9017b6f2747ae/src/ripple/protocol/impl/AccountID.cpp#L109-L140 "Source")
XRP Ledger addresses are encoded using [base58][] with the _dictionary_ `rpshnaf39wBUDNEGHJKLM4PQRST7VWXYZ2bcdeCg65jkm8oFqi1tuvAxyz`. Since the XRP Ledger encodes several types of keys with base58, it prefixes the encoded data with a one-byte "type prefix" (also called a "version prefix") to distinguish them. The type prefix causes addresses to usually start with different letters in base58 format.
The following diagram shows the relationship between keys and addresses:
{{ include_svg("img/address-encoding.svg", "Master Public Key + Type Prefix → Account ID + Checksum → Address") }}
The formula for calculating an XRP Ledger address from a public key is as follows. For the complete example code, see [`encode_address.js`](https://github.com/XRPLF/xrpl-dev-portal/blob/master/content/_code-samples/address_encoding/js/encode_address.js). For the process of deriving a public key from a passphrase or seed value, see [Key Derivation](cryptographic-keys.html#key-derivation).
1. Import required algorithms: SHA-256, RIPEMD160, and base58. Set the dictionary for base58.
'use strict';
const assert = require('assert');
const crypto = require('crypto');
const R_B58_DICT = 'rpshnaf39wBUDNEGHJKLM4PQRST7VWXYZ2bcdeCg65jkm8oFqi1tuvAxyz';
const base58 = require('base-x')(R_B58_DICT);
assert(crypto.getHashes().includes('sha256'));
assert(crypto.getHashes().includes('ripemd160'));
2. Start with a 33-byte ECDSA secp256k1 public key, or a 32-byte Ed25519 public key. For Ed25519 keys, prefix the key with the byte `0xED`.
const pubkey_hex =
'ED9434799226374926EDA3B54B1B461B4ABF7237962EAE18528FEA67595397FA32';
const pubkey = Buffer.from(pubkey_hex, 'hex');
assert(pubkey.length == 33);
3. Calculate the [RIPEMD160](https://en.wikipedia.org/wiki/RIPEMD) hash of the SHA-256 hash of the public key. This value is the "Account ID".
const pubkey_inner_hash = crypto.createHash('sha256').update(pubkey);
const pubkey_outer_hash = crypto.createHash('ripemd160');
pubkey_outer_hash.update(pubkey_inner_hash.digest());
const account_id = pubkey_outer_hash.digest();
4. Calculate the SHA-256 hash of the SHA-256 hash of the Account ID; take the first 4 bytes. This value is the "checksum".
const address_type_prefix = Buffer.from([0x00]);
const payload = Buffer.concat([address_type_prefix, account_id]);
const chksum_hash1 = crypto.createHash('sha256').update(payload).digest();
const chksum_hash2 = crypto.createHash('sha256').update(chksum_hash1).digest();
const checksum = chksum_hash2.slice(0,4);
5. Concatenate the payload and the checksum. Calculate the base58 value of the concatenated buffer. The result is the address.
const dataToEncode = Buffer.concat([payload, checksum]);
const address = base58.encode(dataToEncode);
console.log(address);
// rDTXLQ7ZKZVKz33zJbHjgVShjsBnqMBhmN
<!--{# common link defs #}-->
{% include '_snippets/rippled-api-links.md' %}
{% include '_snippets/tx-type-links.md' %}
{% include '_snippets/rippled_versions.md' %}

10
content/concepts/payment-system-basics/accounts/cryptographic-keys.ja.md → content/concepts/accounts/cryptographic-keys.ja.md
View File

@@ -8,7 +8,7 @@ labels:
---
# 暗号鍵
XRP Ledgerでは、[トランザクション](transaction-basics.html)による一連の具体的なアクションの実行が承認されていることを、デジタル署名によって証明します。署名されたトランザクションのみがネットワークに送信され、検証済みレジャーに含まれます。
XRP Ledgerでは、[トランザクション](transactions.html)による一連の具体的なアクションの実行が承認されていることを、デジタル署名によって証明します。署名されたトランザクションのみがネットワークに送信され、検証済みレジャーに含まれます。
すべてのデジタル署名は、トランザクションの送信側アカウントに関連付けられている暗号鍵ペアに基づいています。キーペアはXRP Ledgerでサポートされている[暗号化署名アルゴリズム](#署名アルゴリズム)を使用して生成できます。キーペアの生成に使用されたアルゴリズムの種類にかかわらず、キーペアは[マスターキーペア](#マスターキーペア)、[レギュラーキーペア](#レギュラーキーペア)、または[署名者リスト](multi-signing.html)のメンバーとして使用できます。
@@ -42,7 +42,7 @@ _図: 暗号鍵の値の関係を簡略化した図_
### シード
_シード_ 値は、アカウントの実際の秘密鍵と公開鍵を[導出](#鍵導出)するために使用される、コンパクトな値です。[wallet_proposeメソッド][]のレスポンスでは、`master_key`, `master_seed`, `master_seed_hex` はすべて同一のシード値を様々な形式で表現します。これらの形式はいずれも、[`rippled` API](http-websocket-apis.html) やいくつかの [他のXRP Ledgerソフトウェア](software-ecosystem.html) で [トランザクションの署名] (transaction-basics.html#signing-and-submitting-transactions) に使用することができます。`master_`という接頭辞がついていますが、このシードが表す鍵は必ずしもアカウントのマスターキーではありません。この鍵ペアはレギュラーキーとして、あるいはマルチシグリストのメンバーとして使用することもできます。
_シード_ 値は、アカウントの実際の秘密鍵と公開鍵を[導出](#鍵導出)するために使用される、コンパクトな値です。[wallet_proposeメソッド][]のレスポンスでは、`master_key`, `master_seed`, `master_seed_hex` はすべて同一のシード値を様々な形式で表現します。これらの形式はいずれも、[`rippled` API](http-websocket-apis.html) やいくつかの [他のXRP Ledgerソフトウェア](software-ecosystem.html) で [トランザクションの署名] (transactions.html#signing-and-submitting-transactions) に使用することができます。`master_`という接頭辞がついていますが、このシードが表す鍵は必ずしもアカウントのマスターキーではありません。この鍵ペアはレギュラーキーとして、あるいはマルチシグリストのメンバーとして使用することもできます。
シード値は秘密情報であるため、非常に厳重に保管する必要があります。あるアドレスのシード値を知っている人は、そのアドレスを実質的に完全にコントロールすることができます。
@@ -82,7 +82,7 @@ XRP Ledgerは、複数の[暗号署名アルゴリズム](#署名アルゴリズ
マスターキーペアは、秘密鍵と公開鍵で構成されています。アカウントのアドレスは、そのアカウントのマスターキーペアから得られるので、両者は[本質的な関係](accounts.html#アドレスのエンコード)となります。マスターキーペアの変更・削除はできませんが、無効にすることはできます。
[wallet_proposeメソッド][]は、マスターキーペアを生成する方法の1つです。このメソッドからの応答には、アカウントのシード、アドレス、マスター公開鍵が一緒に表示されます。マスターキーペアを設定する他の方法については、[安全な署名の設定](set-up-secure-signing.html) を参照してください。
[wallet_proposeメソッド][]は、マスターキーペアを生成する方法の1つです。このメソッドからの応答には、アカウントのシード、アドレス、マスター公開鍵が一緒に表示されます。マスターキーペアを設定する他の方法については、[安全な署名の設定](secure-signing.html) を参照してください。
**注意:** 悪意のある行為者があなたのマスター秘密鍵（またはシード）を知った場合、マスター鍵ペアが無効化されていない限り、彼らはあなたのアカウントを完全にコントロールすることができます。彼らはあなたのアカウントが保持している全ての資金を盗み、その他の回復不能な損害を与えることができます。秘密鍵は慎重に扱ってください！
@@ -94,7 +94,7 @@ XRP Ledgerは、複数の[暗号署名アルゴリズム](#署名アルゴリズ
**マスターキーペア**のみが、ある特定の処理を行うトランザクションを承認することができます。
- アカウントの最初のトランザクションを送信する。アカウントはその他の方法で[トランザクションを承認](transaction-basics.html#authorizing-transactions)して初期化することができないからです。
- アカウントの最初のトランザクションを送信する。アカウントはその他の方法で[トランザクションを承認](transactions.html#トランザクションの承認)して初期化することができないからです。
- マスターキーペアを無効化する。
@@ -241,7 +241,7 @@ XRP Ledgerアカウントキーでのsecp256k1鍵導出に、Ed25519鍵導出よ
## 関連項目
- **コンセプト:**
- [発行アドレスと運用アドレス](issuing-and-operational-addresses.html)
- [発行アドレスと運用アドレス](account-types.html)
- **チュートリアル:**
- [レギュラーキーペアの割り当て](assign-a-regular-key-pair.html)
- [レギュラーキーペアの変更または削除](change-or-remove-a-regular-key-pair.html)

18
content/concepts/payment-system-basics/accounts/cryptographic-keys.md → content/concepts/accounts/cryptographic-keys.md
View File

@@ -8,7 +8,7 @@ labels:
---
# Cryptographic Keys
In the XRP Ledger, a digital signature _authorizes_ a [transaction](transaction-basics.html) to do a specific set of actions. Only signed transactions can be submitted to the network and included in a validated ledger.
In the XRP Ledger, a digital signature _authorizes_ a [transaction](transactions.html) to do a specific set of actions. Only signed transactions can be submitted to the network and included in a validated ledger.
To make a digital signature, you use a cryptographic key pair associated with the transaction's sending account. A key pair may be generated using any of the XRP Ledger's supported [cryptographic signing algorithms](#signing-algorithms). A key pair can be used as a [master key pair](#master-key-pair), [regular key pair](#regular-key-pair) or a member of a [signer list](multi-signing.html), regardless of what algorithm was used to generate it.
@@ -42,7 +42,7 @@ The passphrase is secret information, so you must protect it very carefully. Any
### Seed
A _seed_ value is a compact value that is used to [derive](#key-derivation) the actual private and public keys for an account. In a [wallet_propose method][] response, the `master_key`, `master_seed`, and `master_seed_hex` all represent the same seed value, in various formats. Any of these formats can be used to [sign transactions](transaction-basics.html#signing-and-submitting-transactions) in the [`rippled` APIs](http-websocket-apis.html) and some [other XRP Ledger software](software-ecosystem.html). Despite being prefixed with `master_`, the keys this seed represents are not necessarily the master keys for an account; you can use a key pair as a regular key or a member of a multi-signing list as well.
A _seed_ value is a compact value that is used to [derive](#key-derivation) the actual private and public keys for an account. In a [wallet_propose method][] response, the `master_key`, `master_seed`, and `master_seed_hex` all represent the same seed value, in various formats. Any of these formats can be used to sign transactions. Despite being prefixed with `master_`, the keys this seed represents are not necessarily the master keys for an account; you can use a key pair as a regular key or a member of a multi-signing list as well.
The seed value is secret information, so you must protect it very carefully. Anyone who knows an address's seed value has effectively full control over that address.
@@ -81,9 +81,9 @@ The `key_type` field in the [wallet_propose method][] refers to the cryptographi
## Master Key Pair
The master key pair consists of a private key and a public key. The address of an account is derived from the account's master key pair, so they are [intrinsically related](accounts.html#address-encoding). You cannot change or remove the master key pair, but you can disable it.
The master key pair consists of a private key and a public key. The address of an account is derived from the account's master key pair, so they are intrinsically related. You cannot change or remove the master key pair, but you can disable it.
The [wallet_propose method][] is one way of generating a master key pair. The response from this method shows the account's seed, address, and master public key together. For some other ways of setting up master key pairs, see [Set Up Secure Signing](set-up-secure-signing.html).
The [wallet_propose method][] is one way of generating a master key pair. The response from this method shows the account's seed, address, and master public key together. For some other ways of setting up master key pairs, see [Secure Signing](secure-signing.html).
**Warning:** If a malicious actor learns your master private key (or seed), they have full control over your account, unless your master key pair is disabled. They can take all the money your account holds and do other irreparable harm. Treat your secret values with care!
@@ -97,7 +97,7 @@ Keeping your master key pair offline means not putting the secret information (p
**Only** the master key pair can authorize transactions to do certain things:
- Send an account's very first transaction, because accounts cannot be initialized with another way of [authorizing transactions](transaction-basics.html#authorizing-transactions).
- Send an account's very first transaction, because accounts cannot be initialized with another way of [authorizing transactions](transactions.html#authorizing-transactions).
- Disable the master key pair.
@@ -105,7 +105,7 @@ Keeping your master key pair offline means not putting the secret information (p
- Send a special [key reset transaction](transaction-cost.html#key-reset-transaction) with a transaction cost of 0 XRP.
A regular key or [multi-signature](multi-signing.html) can do anything else the same as the master key pair. Notably, after you have disabled the master key pair, you can re-enable it using a regular key pair or multi-signature. You can also [delete an account](accounts.html#deletion-of-accounts) if it meets the requirements for deletion.
A regular key or [multi-signature](multi-signing.html) can do anything else the same as the master key pair. Notably, after you have disabled the master key pair, you can re-enable it using a regular key pair or multi-signature. You can also [delete an account](deleting-accounts.html) if it meets the requirements for deletion.
## Regular Key Pair
@@ -134,7 +134,7 @@ The XRP Ledger supports the following cryptographic signing algorithms:
When you generate a key pair with the [wallet_propose method][], you can specify the `key_type` to choose which cryptographic signing algorithm to use to derive the keys. If you generated a key type other than the default, you must also specify the `key_type` when signing transactions.
The supported types of key pairs can be used interchangeably throughout the XRP Ledger as master key pairs, regular key pairs, and members of signer lists. The process of [deriving an address](accounts.html#address-encoding) is the same for secp256k1 and Ed25519 key pairs.
The supported types of key pairs can be used interchangeably throughout the XRP Ledger as master key pairs, regular key pairs, and members of signer lists. The process of [deriving an address](addresses.html#address-encoding) is the same for secp256k1 and Ed25519 key pairs.
### Future Algorithms
@@ -237,13 +237,13 @@ The steps to derive the XRP Ledger's secp256k1 account key pair from a seed valu
6. When serializing an account's public key to its [base58][] format, use the account public key prefix, `0x23`.
See [Address Encoding](accounts.html#address-encoding) for information and sample code to convert from an account's public key to its address.
See [Address Encoding](addresses.html#address-encoding) for information and sample code to convert from an account's public key to its address.
## See Also
- **Concepts:**
- [Issuing and Operational Addresses](issuing-and-operational-addresses.html)
- [Issuing and Operational Addresses](account-types.html)
- **Tutorials:**
- [Assign a Regular Key Pair](assign-a-regular-key-pair.html)
- [Change or Remove a Regular Key Pair](change-or-remove-a-regular-key-pair.html)

40
content/concepts/accounts/deleting-accounts.md Normal file
View File

@@ -0,0 +1,40 @@
---
html: deleting-accounts.html
parent: accounts.html
blurb: About deleting an XRP Ledger account.
labels:
- Accounts
---
## Deleting Accounts
The owner of an account can send an [AccountDelete transaction][] to deletes the account and related entries from the ledger, sending most of the account's remaining XRP balance to another account. To discourage wasteful creation and deletion of accounts, deleting an account requires burning a higher than usual amount of XRP as the [transaction cost](transaction-cost.html).
Some types of associated ledger entries block an account from being deleted. For example, the issuer of a fungible token can't be deleted while anyone holds a nonzero balance of that token.
After an account has been deleted, it can be re-created in the ledger through the normal method of [creating accounts](accounts.html#creating-accounts). An account that has been deleted and re-created is no different than an account that has been created for the first time.
## Requirements
To be deleted, an account must meet the following requirements:
- The account's `Sequence` number plus 256 must be less than the current [Ledger Index][].
- The account must not be linked to any of the following types of [ledger objects](ledger-object-types.html) (as a sender or receiver):
- `Escrow`
- `PayChannel`
- `RippleState`
- `Check`
- The account must own fewer than 1000 objects in the ledger.
- The transaction must pay a special [transaction cost][] equal to at least the [owner reserve](reserves.html) for one item (currently 2 XRP).
## Cost of Deleting
**Warning:** The [AccountDelete transaction][]'s transaction cost always applies when the transaction is included in a validated ledger, even if the transaction failed because the account does not meet the requirements to be deleted. To greatly reduce the chances of paying the high transaction cost if the account cannot be deleted, use the `fail_hard` option when submitting an AccountDelete transaction.
Unlike Bitcoin and many other cryptocurrencies, each new version of the XRP Ledger's public ledger chain contains the full state of the ledger, which increases in size with each new account. For that reason, you should not create new XRP Ledger accounts unless necessary. You can recover some of an account's 10 XRP [reserve](reserves.html) by deleting the account, but you must still destroy at least 2 XRP to do so.
Institutions who send and receive value on behalf of many users can use [**Source Tags** and **Destination Tags**](source-and-destination-tags.html) to distinguish payments from and to their customers while only using one (or a handful) of accounts in the XRP Ledger.
<!--{# common link defs #}-->
{% include '_snippets/rippled-api-links.md' %}
{% include '_snippets/tx-type-links.md' %}
{% include '_snippets/rippled_versions.md' %}

2
content/concepts/payment-system-basics/accounts/depositauth.ja.md → content/concepts/accounts/depositauth.ja.md
View File

@@ -105,7 +105,7 @@ DepositPreauthトランザクションの処理が完了すると、承認済み
- [`rippled` API](http-websocket-apis.html)の[deposit_authorizedメソッド][]。
- [Authorized Trust Lines](authorized-trust-lines.html)機能（`RequireAuth`フラグ）により、アカウントが発行したXRP以外の通貨を保有できる取引相手が制限されます。
- `DisallowXRP`フラグは、アカウントがXRPを受領してはならないことを示します。これはDeposit Authorizationよりもソフトな保護機能であり、XRP Ledgerにより強制されません。（クライアントアプリケーションはこのフラグに従うか、または少なくともこのフラグについて警告します。）
- 送信トランザクションが[Destinationタグ](become-an-xrp-ledger-gateway.html#source-and-destination-tags)を指定している場合には、`RequireDest`フラグは、アカウントが通貨額のみを受領できることを示します。これにより、ユーザーが支払の目的を指定し忘れることがなくなりますが、恣意的な送金先タグを作成できる不明な送金元から受取人が保護されるわけではありません。
- 送信トランザクションが[Destinationタグ](source-and-destination-tags.html)を指定している場合には、`RequireDest`フラグは、アカウントが通貨額のみを受領できることを示します。これにより、ユーザーが支払の目的を指定し忘れることがなくなりますが、恣意的な送金先タグを作成できる不明な送金元から受取人が保護されるわけではありません。
- [Partial Payment](partial-payments.html)により、アカウントは不要な支払を返金できます。この際、[送金手数料](transfer-fees.html)と為替レートは送金額には追加されず、送金された金額から差し引かれます。
<!--{# TODO: Add link to "check for authorization" tutorial DOC-1684 #}-->

2
content/concepts/payment-system-basics/accounts/depositauth.md → content/concepts/accounts/depositauth.md
View File

@@ -108,7 +108,7 @@ You can use the [deposit_authorized method][] to see if an account is authorized
- The [deposit_authorized method][] of the [`rippled` API](http-websocket-apis.html).
- The [Authorized Trust Lines](authorized-trust-lines.html) feature (`RequireAuth` flag) limits which counterparties can hold non-XRP currencies issued by an account.
- The `DisallowXRP` flag indicates that an account should not receive XRP. This is a softer protection than Deposit Authorization, and is not enforced by the XRP Ledger. (Client applications should honor this flag or at least warn about it.)
- The `RequireDest` flag indicates that an account can only receive currency amounts if the sending transaction specifies a [Destination Tag](become-an-xrp-ledger-gateway.html#source-and-destination-tags). This protects users from forgetting to indicate the purpose of a payment, but does not protect recipients from unknown senders, who can make up arbitrary destination tags.
- The `RequireDest` flag indicates that an account can only receive currency amounts if the sending transaction specifies a [Destination Tag](source-and-destination-tags.html). This protects users from forgetting to indicate the purpose of a payment, but does not protect recipients from unknown senders, who can make up arbitrary destination tags.
- [Partial Payments](partial-payments.html) provide a way for accounts to return unwanted payments while subtracting [transfer fees](transfer-fees.html) and exchange rates from the amount delivered instead of adding them to the amount sent.
<!--{# TODO: Add link to "check for authorization" tutorial DOC-1684 #}-->

0
content/concepts/payment-system-basics/accounts/reserves.ja.md → content/concepts/accounts/reserves.ja.md
View File

4
content/concepts/payment-system-basics/accounts/reserves.md → content/concepts/accounts/reserves.md
View File

@@ -11,7 +11,7 @@ top_nav_grouping: Popular Pages
The XRP Ledger applies _reserve requirements_, in XRP, to protect the shared global ledger from growing excessively large as the result of spam or malicious usage. The goal is to constrain the growth of the ledger to match improvements in technology so that a current commodity-level machine can always fit the current ledger in RAM.
To have an account, an address must hold a minimum amount of XRP in the shared global ledger. To fund a new address, you must receive enough XRP at that address to meet the reserve requirement. You cannot send the reserved XRP to others, but you can recover some of the XRP by [deleting the account](accounts.html#deletion-of-accounts).
To have an account, an address must hold a minimum amount of XRP in the shared global ledger. To fund a new address, you must receive enough XRP at that address to meet the reserve requirement. You cannot send the reserved XRP to others, but you can recover some of the XRP by [deleting the account](deleting-accounts.html).
The reserve requirement changes from time to time due to the [Fee Voting](fee-voting.html) process, where validators can agree to new reserve settings.
@@ -60,7 +60,7 @@ To calculate an address's total reserve requirement, multiply `OwnerCount` by `r
During transaction processing, the [transaction cost](transaction-cost.html) destroys some of the sending address's XRP balance. This can cause an address's XRP to go below the reserve requirement. You can even destroy _all_ of your XRP this way.
When your account holds less XRP than its current reserve requirement, you cannot send XRP to others, or create new objects that would increase your account's reserve requirement. Even so, the account continues to exist in the ledger and you can still send transactions that don't do these things, as long as you have enough XRP to pay the transaction cost. You can go back above the reserve requirement by receiving enough XRP, or if the [reserve requirement decreases](#changing-the-reserve-requirements) below the amount you have.
When your account holds less XRP than its current reserve requirement, you cannot send XRP to others, or create new objects that would increase your account's reserve requirement. Even so, the account continues to exist in the ledger and you can still send transactions that don't do these things, as long as you have enough XRP to pay the transaction cost. You can go back above the reserve requirement by receiving enough XRP, or if the reserve requirement decreases below the amount you have.
**Tip:** If your address is below the reserve requirement, you can send an [OfferCreate transactions][] to acquire more XRP and get back above the reserve requirement. However, since you cannot create an [Offer entry in the ledger](offer.html) while you are below the reserve, this transaction can only consume Offers that are already in the order books.

2
content/concepts/consensus-network/consensus-principles-and-rules.ja.md → content/concepts/consensus-protocol/consensus-principles-and-rules.ja.md
View File

@@ -1,6 +1,6 @@
---
html: consensus-principles-and-rules.html
parent: consensus-network.html
parent: consensus.html
blurb: XRP Ledgerは世界規模の決済システムで、ユーザーはメールを送るときのようにスムーズに国境を越えて送金することができます。
labels:
- ブロックチェーン

4
content/concepts/consensus-network/consensus-principles-and-rules.md → content/concepts/consensus-protocol/consensus-principles-and-rules.md
View File

@@ -1,6 +1,6 @@
---
html: consensus-principles-and-rules.html
parent: consensus-network.html
parent: consensus.html
blurb: The rules and principles of the consensus algorithm that allow users to transfer funds (including fiat currencies, digital currencies and other forms of value) across national boundaries as seamlessly as sending an email.
labels:
- Blockchain
@@ -113,7 +113,7 @@ The XRP Ledger's consensus algorithm provides a robust alternative to proof of w
## See Also
- **Concepts:**
- [Introduction to Consensus](intro-to-consensus.html)
- [Consensus](consensus.html)
- [Consensus Research](consensus-research.html)
- [XRPL Consensus Mechanism Video](https://www.youtube.com/watch?v=k6VqEkqRTmk&list=PLJQ55Tj1hIVZtJ_JdTvSum2qMTsedWkNi&index=2)
- **Tutorials:**

6
content/concepts/consensus-network/consensus-protections.ja.md → content/concepts/consensus-protocol/consensus-protections.ja.md
View File

@@ -1,6 +1,6 @@
---
html: consensus-protections.html
parent: consensus-network.html
parent: consensus.html
blurb: Learn how the XRP Ledger Consensus Protocol is protected against various problems and attacks that may occur in a decentralized financial system. #TODO: translate
labels:
- ブロックチェーン
@@ -9,7 +9,7 @@ labels:
XRP Ledgerコンセンサスプロトコルは、 _ビザンチンフォールトトレラント性_ のあるコンセンサスメカニズムです。つまり、あらゆる不適切な状況（参加者が信頼できないオープンネットワークを利用して通信している場合や、不正使用者が常にシステムを乗っ取ろうとしているかまたは中断しようとしている場合など）が発生しても動作するように設計されています。さらに、XRP Ledgerコンセンサスプロトコルの参加者が事前に判明していない場合や、時間の経過とともに変わる場合があります。
[ネットワークに求められる特性](intro-to-consensus.html#コンセンサスプロトコルの特性)を維持しつつ、トランザクションをタイミングよく承認する作業は複雑であり、また完璧なシステムを構築することは不可能です。XRP Ledgerコンセンサスプロトコルは、ほとんどの状況で機能し、機能できない状況では可能な限り安全に失敗するように設計されています。
[ネットワークに求められる特性](consensus.html#コンセンサスプロトコルの特性)を維持しつつ、トランザクションをタイミングよく承認する作業は複雑であり、また完璧なシステムを構築することは不可能です。XRP Ledgerコンセンサスプロトコルは、ほとんどの状況で機能し、機能できない状況では可能な限り安全に失敗するように設計されています。
このページでは、XRP Ledgerコンセンサスプロトコルのいくつかの課題のタイプとその対処について説明します。
@@ -68,7 +68,7 @@ XRP Ledgerのすべての参加者が何を検証済みとみなすかについ
## 関連項目
- コンセンサスの**入門レベルの概要**については、[コンセンサスについて](intro-to-consensus.html)を参照してください。
- コンセンサスの**入門レベルの概要**については、[コンセンサスについて](consensus.html)を参照してください。
- コンセンサスプロトコルの**詳細な説明**については、[コンセンサス](consensus.html)を参照してください。
- コンセンサスプロトコルの**設計に関する決定と背景**については、[コンセンサスの原理とルール](consensus-principles-and-rules.html)を参照してください。
- コンセンサスプロトコルの特性と制約に関する**学術研究**については、[コンセンサスの研究](consensus-research.html)を参照してください。

5
content/concepts/consensus-network/consensus-protections.md → content/concepts/consensus-protocol/consensus-protections.md
View File

@@ -1,6 +1,6 @@
---
html: consensus-protections.html
parent: consensus-network.html
parent: consensus.html
blurb: Learn how the XRP Ledger Consensus Protocol is protected against various problems and attacks that may occur in a decentralized financial system.
labels:
- Blockchain
@@ -9,7 +9,7 @@ labels:
The XRP Ledger Consensus Protocol is a _byzantine fault tolerant_ consensus mechanism, which means it's designed to work even if all kinds of things can go wrong: participants depend on an unreliable open network to communicate, and malicious actors may be attempting to control or interrupt the system at any given time. On top of that, the set of participants in the XRP Ledger Consensus Protocol isn't known in advance and can change over time.
Confirming transactions quickly while maintaining [the desired properties of the network](intro-to-consensus.html#consensus-protocol-properties) is a complex challenge, and it's impossible to build a perfect system. The XRP Ledger Consensus Protocol is designed to work as well as it can in most situations, and to fail as gracefully as possible in the situations where it can't.
Confirming transactions quickly while maintaining the desired properties of the network is a complex challenge, and it's impossible to build a perfect system. The XRP Ledger Consensus Protocol is designed to work as well as it can in most situations, and to fail as gracefully as possible in the situations where it can't.
This page describes some of the types of challenges that the XRP Ledger Consensus Protocol faces and how it handles them.
@@ -68,7 +68,6 @@ Research is ongoing to design an improved consensus protocol that allows more he
## See Also
- For an **intro-level overview** of consensus, see [Intro to Consensus](intro-to-consensus.html).
- For a **detailed description** of the consensus protocol, see [Consensus](consensus.html).
- For an explanation of the **design decisions and background** behind the consensus protocol, see [Consensus Principles and Rules](consensus-principles-and-rules.html).
- For **academic research** exploring the properties and limitations of the protocol, see [Consensus Research](consensus-research.html).

2
content/concepts/consensus-network/consensus-research.ja.md → content/concepts/consensus-protocol/consensus-research.ja.md
View File

@@ -1,6 +1,6 @@
---
html: consensus-research.html
parent: consensus-network.html
parent: consensus.html
blurb: コンセンサスアルゴリズムに関する学術論文と関連研究。
labels:
- ブロックチェーン

2
content/concepts/consensus-network/consensus-research.md → content/concepts/consensus-protocol/consensus-research.md
View File

@@ -1,6 +1,6 @@
---
html: consensus-research.html
parent: consensus-network.html
parent: consensus.html
blurb: Scholarly articles on consensus algorithms and related research.
labels:
- Blockchain

6
content/concepts/consensus-network/consensus.ja.md → content/concepts/consensus-protocol/consensus-structure.ja.md
View File

@@ -1,6 +1,6 @@
---
html: consensus.html
parent: consensus-network.html
html: consensus-structure.html
parent: consensus.html
blurb: XRP Ledgerにおけるコンセンサスの役割について理解を深めましょう。
labels:
- ブロックチェーン
@@ -170,7 +170,7 @@ XRP Ledgerに送信されたトランザクションはすぐには処理され
## 関連項目
- **コンセプト:**
- [コンセンサスについて](intro-to-consensus.html)
- [コンセンサスについて](consensus.html)
- [コンセンサスの研究](consensus-research.html)
- [Rippleコンセンサスの動画](https://www.youtube.com/watch?v=pj1QVb1vlC0)
- **チュートリアル:**

7
content/concepts/consensus-network/consensus.md → content/concepts/consensus-protocol/consensus-structure.md
View File

@@ -1,11 +1,11 @@
---
html: consensus.html
parent: consensus-network.html
html: consensus-structure.html
parent: consensus.html
blurb: Understand the role of consensus in the XRP Ledger.
labels:
- Blockchain
---
# Consensus
# Consensus Structure
_Written by Dave Cohen, David Schwartz, and Arthur Britto._
@@ -173,7 +173,6 @@ Best practices for applications submitting transactions include:
## See Also
- **Concepts:**
- [Introduction to Consensus](intro-to-consensus.html)
- [Consensus Research](consensus-research.html)
- [The Consensus Mechanism (YouTube)](https://www.youtube.com/watch?v=k6VqEkqRTmk&list=PLJQ55Tj1hIVZtJ_JdTvSum2qMTsedWkNi&index=2)
- **Tutorials:**

15
content/concepts/introduction/intro-to-consensus.ja.md → content/concepts/consensus-protocol/consensus.ja.md
View File

@@ -1,12 +1,12 @@
---
html: intro-to-consensus.html
parent: introduction.html
html: consensus.html
parent: concepts.html
blurb: XRP Ledgerのコンセンサスメカニズムについて基本的な理解を深めましょう。
labels:
- ブロックチェーン
top_nav_grouping: 人気ページ
---
# コンセンサスについて
# コンセンサスプロトコル
_コンセンサス_ は、分散型決済システムの最も重要な特性です。従来の中央集権型決済システムでは、権限のある1人の管理者が決済の方法とタイミングについて最終的な決定権を持ちます。分散型システムでは、その名が示すとおり、そのような管理者は存在しません。その代わりに、XRP Ledgerのような分散型システムでは、参加者は定められた一連のルールに従うことになっているため、同じ一連のイベントとその結果についていつでも合意することができます。この一連のルールは、 _コンセンサスプロトコル_ と呼ばれます。
@@ -58,15 +58,6 @@ XRP Ledgerのコンセンサスメカニズムは、小さな信頼が大きな
XRP Ledger コンセンサスプロトコルで、さまざまな課題や攻撃、失敗の事例にどのように対応するかについての詳細な説明については、[攻撃と失敗モードに対するコンセンサスの保護](consensus-protections.html)を参照してください。
## 関連項目
- XRP Ledger コンセンサスプロトコルの仕組みの詳細に関する記事は、[コンセンサスネットワークの概念](consensus-network.html)を参照してください。
- 独自のバリデータを実行する手順については、[バリデータとしての`rippled`の実行](run-rippled-as-a-validator.html)を参照してください。
- XRP Ledgerの分散化に関するRippleの目標および計画については、[分散化戦略についてのアップデート (Ripple Dev Blog)](https://ripple.com/dev-blog/decentralization-strategy-update/)を参照してください。
<!--{# TODO: Replace the Decent Strategy Update w/ a newer article when we have one #}-->
----
## 脚注

20
content/concepts/introduction/intro-to-consensus.md → content/concepts/consensus-protocol/consensus.md
View File

@@ -1,14 +1,16 @@
---
html: intro-to-consensus.html
parent: introduction.html
blurb: Develop a basic understanding of the XRP Ledger's consensus mechanism.
html: consensus.html
parent: concepts.html
blurb: Consensus is how new blocks of transactions get confirmed by the XRP Ledger blockchain.
labels:
- Blockchain
top_nav_grouping: Popular Pages
---
# Introduction to Consensus
# Consensus Protocol
_Consensus_ is the most important property of any decentralized payment system. In traditional centralized payment systems, one authoritative administrator gets the final say in how and when payments occur. Decentralized systems, by definition, don't have an administrator to do that. Instead, decentralized systems like the XRP Ledger define a set of rules all participants follow, so every participant can agree on the exact same series of events and their outcome at any point in time. We call this set of rules a _consensus protocol_.
This topic explains how the decentralized XRP Ledger confirms new transactions and ledger versions, forming a blockchain.
Consensus is the most important property of any decentralized payment system. In traditional centralized payment systems, one authoritative administrator gets the final say in how and when payments occur. Decentralized systems, by definition, don't have an administrator to do that. Instead, decentralized systems like the XRP Ledger define a set of rules all participants follow, so every participant can agree on the exact same series of events and their outcome at any point in time. We call this set of rules a _consensus protocol_.
## Consensus Protocol Properties
@@ -58,14 +60,6 @@ It's OK if a small proportion of validators don't work properly all the time. As
For a longer exploration of how the XRP Ledger Consensus Protocol responds to various challenges, attacks, and failure cases, see [Consensus Protections Against Attacks and Failure Modes](consensus-protections.html).
## See Also
- [Consensus Network Concepts](consensus-network.html) for several articles describing the mechanics of the XRP Ledger Consensus Protocol in greater depth.
- [Run `rippled` as a Validator](run-rippled-as-a-validator.html) for instructions on running your own validator.
- [Decentralization Strategy Update (Ripple Dev Blog)](https://xrpl.org/blog/2017/decent-strategy-update.html) for a description of Ripple's goals and plans for decentralizing the XRP Ledger.
<!--{# TODO: Replace the Decent Strategy Update w/ a newer article when we have one #}-->
----
## Footnotes

2
content/concepts/consensus-network/fee-voting.ja.md → content/concepts/consensus-protocol/fee-voting.ja.md
View File

@@ -1,6 +1,6 @@
---
html: fee-voting.html
parent: consensus-network.html
parent: consensus.html
blurb: トランザクションコストと必要準備金の変更投票について。
labels:
- 手数料

2
content/concepts/consensus-network/fee-voting.md → content/concepts/consensus-protocol/fee-voting.md
View File

@@ -1,6 +1,6 @@
---
html: fee-voting.html
parent: consensus-network.html
parent: consensus.html
blurb: How validators vote on fees (transaction cost and reserve requirements).
labels:
- Fees

3
content/concepts/consensus-network/invariant-checking.ja.md → content/concepts/consensus-protocol/invariant-checking.ja.md
View File

@@ -1,6 +1,6 @@
---
html: invariant-checking.html
parent: consensus-network.html
parent: consensus.html
blurb: 不変性チェックとは何か、なぜ存在するのか、どのように機能するのか、どのような不変性チェックが有効なのかを理解することができます。
labels:
- ブロックチェーン
@@ -146,7 +146,6 @@ XRP Ledgerは、各トランザクションについて、以下のすべての
- **その他:**
- [Authorized Trust Lines](authorized-trust-lines.html)
- [XRPの特性](xrp.html#xrpの特性)
- [トランザクションの残高変化の計算](https://xrpl.org/blog/2015/calculating-balance-changes-for-a-transaction.html#calculating-balance-changes-for-a-transaction)

3
content/concepts/consensus-network/invariant-checking.md → content/concepts/consensus-protocol/invariant-checking.md
View File

@@ -1,6 +1,6 @@
---
html: invariant-checking.html
parent: consensus-network.html
parent: consensus.html
blurb: Understand what invariant checking is, why it exists, how it works, and what invariant checks are active.
labels:
- Blockchain
@@ -166,7 +166,6 @@ The XRP Ledger checks all the following invariants on each transaction:
- **Other:**
- [Authorized Trust Lines](authorized-trust-lines.html)
- [XRP Properties](xrp.html#xrp-properties)
- [Calculating Balance Changes for a Transaction](https://xrpl.org/blog/2015/calculating-balance-changes-for-a-transaction.html#calculating-balance-changes-for-a-transaction)

6
content/concepts/consensus-network/negative-unl.ja.md → content/concepts/consensus-protocol/negative-unl.ja.md
View File

@@ -1,6 +1,6 @@
---
html: negative-unl.html
parent: consensus-network.html
parent: consensus.html
blurb: ネガティブUNLが部分的な停止時に台帳の耐障害性を向上させることを理解する。
labels:
- ブロックチェーン
@@ -72,7 +72,7 @@ V<sub>a</sub>は、サーバー側のコンセンサス見解と一致した過
1. 前のフラグレジャーで予定されていたネガティブUNLの変更は、次のレジャーバージョンから有効となる。このフラグレジャーの検証のための合意プロセスそのものは、予定されていた変更を利用しない。
**注記:** これは、[トランザクション](transaction-basics.html)や[疑似トランザクション](pseudo-transaction-types.html)を行わずにレジャーの状態データを変更する唯一の機会です。
**注記:** これは、[トランザクション](transactions.html)や[疑似トランザクション](pseudo-transaction-types.html)を行わずにレジャーの状態データを変更する唯一の機会です。
2. ネガティブUNLが満杯でない場合、各サーバーは信頼度50%未満のバリデータの中から、**最大1つ**のバリデータをネガティブUNLに追加することを提案する。
3. ネガティブUNLが空でない場合、各サーバーはネガティブUNLから**最大1つ**のバリデータを削除することを提案する。サーバーがバリデータをネガティブUNLから削除することを提案できる理由は2つある。
@@ -110,7 +110,7 @@ V<sub>a</sub>は、サーバー側のコンセンサス見解と一致した過
### 検証のフィルタリング
[コンセンサスプロセスの検証ステップ](consensus.html#検証)では、親レジャーのネガティブUNLのバリデータを無効化します。各サーバーは無効化されたバリデータを取り除いた設定済みUNLからなる"有効UNL"を計算し、定足数を再計算します。(定足数は常に有効UNLの80%以上、かつ設定UNLの60%以上です)。無効化されたバリデータが検証票を送信した場合、サーバーは無効化されたバリデータの信頼性を計算するためにその票を追跡するが、あるバージョンのレジャーが合意に達したかどうかを判断するためにその票を使うことはありません。
[コンセンサスプロセスの検証ステップ](consensus-structure.html#検証)では、親レジャーのネガティブUNLのバリデータを無効化します。各サーバーは無効化されたバリデータを取り除いた設定済みUNLからなる"有効UNL"を計算し、定足数を再計算します。(定足数は常に有効UNLの80%以上、かつ設定UNLの60%以上です)。無効化されたバリデータが検証票を送信した場合、サーバーは無効化されたバリデータの信頼性を計算するためにその票を追跡するが、あるバージョンのレジャーが合意に達したかどうかを判断するためにその票を使うことはありません。
**注記:** ネガティブUNLは、定足数を直接計算するのではなく、定足数の計算元となる信頼できるバリデータの合計を調整するものです。定足数はパーセンテージですが、投票数は整数であるため、信頼できるバリデータの合計を減らしても、定足数に達するために必要な投票数が変わるとは限りません。たとえば、総バリデータが15人である場合、80%はちょうど12人のバリデータである。これを14人に減らすと、80%は11.2人となり、定足数に達するには依然として12人の有効投票者が必要である。

6
content/concepts/consensus-network/negative-unl.md → content/concepts/consensus-protocol/negative-unl.md
View File

@@ -1,6 +1,6 @@
---
html: negative-unl.html
parent: consensus-network.html
parent: consensus.html
blurb: Understand how Negative UNL improves the ledger's resilience during partial outages.
labels:
- Blockchain
@@ -73,7 +73,7 @@ Each flag ledger, all of the following changes apply:
1. Changes to the Negative UNL that were scheduled in the previous flag ledger go into effect for the following ledger version. The consensus process for validating this flag ledger itself does not use the scheduled change.
**Note:** 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).
**Note:** 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).
2. If the Negative UNL is not full, each server proposes adding **up to 1** validator to the Negative UNL from among its trusted validators with less than 50% reliability.
3. If the Negative UNL is not empty, each server proposes removing **up to 1** validator from the Negative UNL. A server can propose removing a validator from the Negative UNL for two reasons:
@@ -111,7 +111,7 @@ This mechanism has several useful properties:
### Filtering Validations
During [the validation step of the consensus process](consensus.html#validation), validators in the parent ledger's Negative UNL are disabled. Each server calculates an "effective UNL" consisting of its configured UNL with the disabled validators removed, and recalculates its quorum. (The quorum is always at least 80% of the effective UNL and at least 60% of the configured UNL.) If a disabled validator sends validation votes, servers track those votes for purposes of calculating the disabled validator's reliability measurement, but they do not use those votes towards determining whether a ledger version has achieved a consensus.
During [the validation step of the consensus process](consensus-structure.html#validation), validators in the parent ledger's Negative UNL are disabled. Each server calculates an "effective UNL" consisting of its configured UNL with the disabled validators removed, and recalculates its quorum. (The quorum is always at least 80% of the effective UNL and at least 60% of the configured UNL.) If a disabled validator sends validation votes, servers track those votes for purposes of calculating the disabled validator's reliability measurement, but they do not use those votes towards determining whether a ledger version has achieved a consensus.
**Note:** The Negative UNL adjusts the _total_ trusted validators that the quorum is calculated from, not the quorum directly. The quorum is a percentage but the number of votes is a whole number, so reducing the total trusted validators does not always change the number of votes required to reach a quorum. For example, if there are 15 total validators, 80% is 12 validators exactly. If you reduce the total to 14 validators, 80% is 11.2 validators, which means that it still requires 12 validators to reach a quorum.

29
content/concepts/decentralized-exchange/autobridging.md
View File

@@ -1,29 +0,0 @@
---
html: autobridging.html
parent: decentralized-exchange.html
blurb: Autobriding automatically connects order books using XRP as an intermediary when it reduces costs.
labels:
- XRP
- Decentralized Exchange
---
# Auto-Bridging
Any [Offer](offers.html) in the XRP Ledger's [decentralized exchange](decentralized-exchange.html) that would exchange two non-XRP currencies could potentially use [XRP](xrp.html) as an intermediary currency in a synthetic order book. This is because of _auto-bridging_, which serves to improve liquidity across all currency pairs by using XRP when doing so is cheaper than trading those currencies directly. This works because of XRP's nature as a native cryptocurrency to the XRP Ledger. Offer execution can use a combination of direct and auto-bridged offers to achieve the best total exchange rate.
Example: _Anita places an offer to sell GBP and buy BRL. She might find that this uncommon currency market has few offers. There is one offer with a good rate, but it has insufficient quantity to satisfy Anita's trade. However, both GBP and BRL have active, competitive markets to XRP. The XRP Ledger's auto-bridging system finds a way to complete Anita's offer by purchasing XRP with GBP from one trader, then selling the XRP to another trader to buy BRL. Anita automatically gets the best rate possible by combining the small offer in the direct GBP:BRL market with the better composite rates created by pairing GBP:XRP and XRP:BRL offers._ <!-- SPELLING_IGNORE: gbp -->
Auto-bridging happens automatically on any [OfferCreate transaction][]. [Payment transactions](payment.html) _do not_ use auto-bridging by default, but path-finding can find [paths](paths.html) that have the same effect.
## See Also
- [Dev Blog: Introducing Autobridging](https://xrpl.org/blog/2014/introducing-offer-autobridging.html) <!-- SPELLING_IGNORE: autobridging -->
- [Offer Preference](offers.html#offer-preference)
- [Payment Paths](paths.html)
<!--{# common link defs #}-->
{% include '_snippets/rippled-api-links.md' %}
{% include '_snippets/tx-type-links.md' %}
{% include '_snippets/rippled_versions.md' %}

48
content/concepts/introduction/crypto-wallets.md Normal file
View File

@@ -0,0 +1,48 @@
---
html: crypto-wallets.html
parent: intro-to-xrpl.html
blurb: Wallets provide a convenient way of managing your XRP on the XRP Ledger.
labels:
- Blockchain
---
# Crypto Wallets
Crypto wallets provide a way to manage your account and funds on the XRP Ledger. There are many wallets to choose from. Choosing the right wallet ultimately comes down to your needs and comfort working with XRP.
## Custodial vs Non-custodial Wallets
A major factor when choosing a wallet is if you want a custodial or non-custodial wallet.
A custodial wallet means a third party holds your funds, typically on an account they manage on the XRP Ledger. A custodial wallet can be thought of like a bank, where you're trusting another entity to keep your money secure. Many centralized exchanges offer custodial wallets, so when you create an account with them and use their app, you don't technically have an account on the ledger.
For day-to-day payments, this may be preferable, since these types of wallets are user-friendly: if you forget your password, you can typically have it reset. Also, if you don't have an individual XRP Ledger account, the ledger's reserve requirement doesn't apply to you. The custodian acts a buffer to any issues you run into on the XRP Ledger, and may offer support or assistance if you're not sure how to do something.
![Custodial vs. Non-custodial Wallets](img/introduction15-custodial-non-custodial.png)
A non-custodial wallet, such as [XUMM](https://xumm.app/), is one where you have the secret keys to your account. This means you're ultimately responsible for managing the security of your account.
**Caution:** If you lose your keys, you are locked out of your XRP Ledger account and there are no recovery options.
Non-custodial wallets allow more freedom. Since you're interacting directly with the XRP Ledger yourself, you can handle any type of transaction you want without anyone restricting your options. If the ledger allows it, you can do it. Non-custodial wallets also don't require you to trust an institution with your money, which can insulate you from market factors outside your control.
Users of both custodial and non-custodial wallets have to protect themselves from malicious users who might try to steal their funds. With a custodial wallet, you have to manage your login and password to the app or site; with a non-custodial wallet, you have to manage your secret keys to your on-ledger account. In both cases, the wallet provider's own security practices are also important to protect you from vulnerabilities like supply-chain attacks, where an attacker loads malicious code into the wallet through software updates or dependencies. However, custodial wallets can be a bigger target for attackers since they have immediate access to multiple customers' funds.
## Hardware vs Software Wallets
Another deciding factor when choosing a wallet is picking between a hardware or software wallet.
Hardware wallets are physical devices that store your private/secret keys. The main benefit of using hardware wallets is that you can secure your information by disconnecting it from the internet when it's not in use; hardware wallets totally isolate your keys from easier-to-hack computers or smartphones.
![Hardware vs. Software Wallets](img/introduction16-hardware-software.png)
Software wallets on the other hand, are entirely digital. While this makes them easier to use, it also makes them the less secure method of the two, but they usually come with additional features to enhance your experience. Ultimately, the decision between the two will come down to your comfort level and how important ease-of-use is to you.
## Creating Your Own Wallet
The XRP Ledger is an opensource project with publicly available client libraries and API methods. While you can technically interact with the ledger using HTTP/WebSocket tools, it isn't practical for day-to-day use. You can create your own wallet to interact with the ledger, but you'll need to understand exactly how accounts, transactions, and the ledger work together before committing to this option.
Next: [Transactions and Requests](txn-and-requests.html)

4
content/concepts/introduction/software-ecosystem.ja.md
View File

@@ -11,7 +11,7 @@ XRP Ledgerは、「価値のインターネット」を推進および実現可
[![4層からなるエコシステムの図: 最下層にはXRP Ledgerのピアツーピアネットワーク、その上にプログラミングライブラリー、次にミドルウェア、そして最上層にアプリとサービスがあります。](img/ecosystem.ja.png)](img/ecosystem.ja.png)
- [XRP Ledgerの基盤](#rippled-コアサーバー)は、トランザクションを共有し、[コンセンサスプロセス](consensus.html)に関与し、[トランザクション](transaction-basics.html)を処理する常時接続のサーバーのピアツーピアネットワークです。XRP Ledgerエコシステム内の他のすべてのものが、最終的にこのピアツーピアネットワーク上に直接、または間接的に構築されます。
- [XRP Ledgerの基盤](#rippled-コアサーバー)は、トランザクションを共有し、[コンセンサスプロセス](consensus.html)に関与し、[トランザクション](transactions.html)を処理する常時接続のサーバーのピアツーピアネットワークです。XRP Ledgerエコシステム内の他のすべてのものが、最終的にこのピアツーピアネットワーク上に直接、または間接的に構築されます。
- [_プログラミングライブラリー_](#プログラミングライブラリー)は、さらに上位のソフトウェアに存在し、プログラムコードに直接インポートされます。また、XRP Ledgerにアクセスするためのルーチンの実装があらかじめ作成され、組み込まれています。
@@ -47,7 +47,7 @@ XRP Ledger上のミドルウェアサービスの例として、[Data API](data-
### アプリとサービス
最上層は、最もエキサイティングなことが起こる場所です。アプリとサービスは、XRP Ledgerに接続するための手段をユーザーとデバイスに提供します。この層では、[取引所がXRPを上場](list-xrp-as-an-exchange.html)したり、分散型取引所で使用するために[ゲートウェイが他の通貨を発行](become-an-xrp-ledger-gateway.html)したり、あるいはXRPを購入、売却、または単に<s>HODLing</s>保持するためにウォレットがユーザーインターフェイスを提供したりします。さらに高階層にサービスを追加するなど、他にも多くの可能性があります。
最上層は、最もエキサイティングなことが起こる場所です。アプリとサービスは、XRP Ledgerに接続するための手段をユーザーとデバイスに提供します。この層では、[取引所がXRPを上場](list-xrp-as-an-exchange.html)したり、分散型取引所で使用するために[ゲートウェイが他の通貨を発行](stablecoin-issuer.html)したり、あるいはXRPを購入、売却、または単に<s>HODLing</s>保持するためにウォレットがユーザーインターフェイスを提供したりします。さらに高階層にサービスを追加するなど、他にも多くの可能性があります。
XRPだけでなく、通貨価値を表す他のさまざまな方法と互換性のあるアプリケーションを構築するには、XRPでの決済に[Interledger Protocol][]を使用するのが最適です。

52
content/concepts/introduction/software-ecosystem.md
View File

@@ -7,60 +7,60 @@ labels:
---
# Software Ecosystem
The XRP Ledger is home to a deep, layered ecosystem of software projects powering and enabling an Internet of Value. It's impossible to list every project, tool, and business that interacts with the XRP Ledger, so this page only lists a few categories and highlights some central projects that are documented here on [xrpl.org](https://xrpl.org). <!-- SPELLING_IGNORE: xrpl -->
The XRP Ledger is home to a deep, layered ecosystem of software projects powering and enabling an Internet of Value. It's impossible to list every project, tool, and business that interacts with the XRP Ledger, so this page only lists a few categories and highlights some central projects that are documented on this website.
![The XRPL Ecosystem](img/ecosystem-apps-and-services.svg)
## Stack Levels
{{ include_svg("img/ecosystem.svg", "Ecosystem diagram with the four layers: XRP Ledger peer-to-peer network on the bottom, Programming Libraries above that, Middleware next, and Apps and Services at the top") }}
- [_Core Servers_](#core-servers) form the basis of the XRP Ledger, a peer-to-peer network relaying and processing transactions at all times.
- The [basis of the XRP Ledger](#rippled-the-core-server) is a peer-to-peer network of always-on servers sharing transactions, engaging in the [consensus process](consensus.html) and processing [transactions](transaction-basics.html). Everything else in the XRP Ledger ecosystem is ultimately built on top of this peer-to-peer network, directly or indirectly.
- [_Programming Libraries_](#programming-libraries) exist in higher level software, where they are imported directly into program code, and contain methods to access the XRP Ledger.
- [_Client Libraries_](#client-libraries) exist in higher level software, where they are imported directly into program code, and contain methods to access the XRP Ledger.
- [_Middleware_](#middleware) provides indirect access to XRP Ledger data. Applications in this layer often have their own data storage and processing.
- [_Apps and Services_](#apps-and-services) provide user-level interaction with the XRP Ledger, or provide a basis for even higher-level apps and services.
### rippled: The Core Server
### Core Servers
The peer-to-peer network at the heart of the XRP Ledger requires a highly-reliable, efficient server to enforce the rules of consensus and transaction processing. XRPL Foundation manages and publishes a reference implementation of this server software, called [**`rippled`**](xrpl-servers.html) (pronounced "ripple-dee"). The server is available under [a permissive open-source license](https://github.com/ripple/rippled/blob/develop/LICENSE.md), so anyone can inspect and modify their own instance of the server, and re-publish with few restrictions.
The peer-to-peer network at the heart of the XRP Ledger requires a highly-reliable, efficient server to enforce the rules of consensus and transaction processing. The XRP Ledger Foundation publishes a reference implementation of this server software, called [**`rippled`**](xrpl-servers.html) (pronounced "ripple-dee"). The server is available under [a permissive open-source license](https://github.com/XRPLF/rippled/blob/develop/LICENSE.md), so anyone can inspect and modify their own instance of the server, and re-publish with few restrictions.
Every instance of `rippled` syncs to the same network (unless it's configured to follow a [parallel network such as a test net](parallel-networks.html)) and has access to all communications across the network. Every `rippled` server on the network keeps a complete copy of the latest state data for the entire XRP Ledger, along with a slice of recent transactions and a record of the changes those transactions made, and every server processes every transaction independently while verifying that its outcome matches the rest of the network. Servers can be configured to keep more [ledger history](ledger-history.html) and to participate in the consensus process as a [validator](rippled-server-modes.html#validators).
![Core Servers](img/ecosystem-peer-to-peer.svg)
This server exposes [`rippled` APIs](http-websocket-apis.html) for users to look up data, administer the server, and submit transactions.
Every core server syncs to the same network (unless it's configured to follow a [test network](parallel-networks.html)) and has access to all communications across the network. Every server on the network keeps a complete copy of the latest state data for the entire XRP Ledger, along with recent transactions and a record of the changes those transactions made, and every server processes every transaction independently while verifying that its outcome matches the rest of the network. Servers can be configured to keep more [ledger history](ledger-history.html) and to participate in the consensus process as a [validator](rippled-server-modes.html#validators).
### Programming Libraries
Core servers expose [HTTP / WebSocket APIs](http-websocket-apis.html) for users to look up data, administer the server, and submit transactions. Some servers also serve HTTP / WebSocket APIs but don't connect directly to the peer-to-peer network and don't process transactions or participate in consensus. These servers, such as `rippled` servers running in Reporting Mode and Clio servers, rely on a core server in P2P mode to process transactions.
[Programming libraries](client-libraries.html) are not strictly required to access XRP Ledger data, since you can use HTTP or WebSocket to connect to the [`rippled` APIs](http-websocket-apis.html) directly. Libraries simplify some of the common work of accessing the `rippled` APIs, and convert the data into forms that are easier to understand and program with in the programming language of the library.
[xrpl.js for JavaScript](get-started-using-javascript.html) (formerly called "ripple-lib") is the longest-standing, most well-supported library for accessing the XRP Ledger. Many [middleware services](#middleware) use programming libraries like this internally.
### Client Libraries
Libraries simplify some of the common work of accessing the XRP Ledger, usually through the HTTP / WebSocket APIs. They convert the data into forms that are more familiar and convenient for various programming languages, and include implementations of common operations.
![Client Libraries](img/ecosystem-client-libraries.svg)
One core feature of most client libraries is signing transactions locally, so users never have to send their private key across any network.
Many middleware services use client libraries internally.
See [Client Libraries](client-libraries.html) for some information about currently available client libraries.
### Middleware
Middleware services are programs that consume the XRP Ledger APIs on one side and provide their own APIs on the other side. They provide a layer of abstraction to make it easier to build higher-level applications by providing some common functionality as a service.
Unlike [programming libraries](#programming-libraries), which are instantiated fresh and shut down with the program that imports them, middleware services typically stay running indefinitely, and may have their own databases (relational SQL databases or otherwise) and configuration files.
![Middleware](img/ecosystem-middleware.svg)
The [Data API](data-api.html) is an example of a middleware service on top of the XRP Ledger. The Data API collects and transforms XRP Ledger data, so that you can query by time, filter by data type, or perform data analysis.
[XRP-API](xrp-api.html) is another middleware service. XRP-API manages secret keys and provides a more convenient RESTful interface to the XRP Ledger for apps in any programming language.
Unlike client libraries, which are instantiated fresh and shut down with the program that imports them, middleware services typically stay running indefinitely, and may have their own databases (relational SQL databases or otherwise) and configuration files. Some are available as cloud services with various pricing or usage limitations.
### Apps and Services
Atop the stack is where the truly exciting things happen. Apps and services provide a way for users and devices to connect to the XRP Ledger. At this level, [exchanges list XRP](list-xrp-as-an-exchange.html), [gateways issue other currencies](become-an-xrp-ledger-gateway.html) for use in the decentralized exchange, and wallets provide user interfaces for buying, selling, or <s>HODLing</s> holding XRP. Many other possibilities exist, including additional services layered even higher. <!-- SPELLING_IGNORE: hodling -->
Atop the stack is where the truly exciting things happen. Apps and services provide a way for users and devices to connect to the XRP Ledger. Services like private exchanges, token issuers, marketplaces, interfaces to the decentralized exchange, and wallets provide user interfaces for buying, selling, and trading various assets including XRP and tokens of all kinds. Many other possibilities exist, including additional services layered even higher.
A great way to build applications that are compatible with not only XRP but lots of other ways of denominating value is to use the [Interledger Protocol][] with settlement in XRP.
![Apps and Services](img/ecosystem-apps-and-services.svg)
There are many other examples of projects using XRP and adjacent technologies to interact with users. For some examples, see [Businesses](businesses.html), [Exchanges](exchanges.html), and [Wallets](wallets.html).
## See Also
- [RippleX](https://ripplex.io/)
- [Technical FAQ](technical-faq.html)
- [XRPChat Links & Resources](https://www.xrpchat.com/links/) - Includes updated lists of gateways and exchanges, wallets and storage, apps, and more.
See [Use Cases](use-cases.html) for some examples that can be built at or above this layer.
<!--{# common link defs #}-->
{% include '_snippets/rippled-api-links.md' %}

115
content/concepts/introduction/txn-and-requests.md Normal file
View File

@@ -0,0 +1,115 @@
---
html: txn-and-requests.html
parent: intro-to-xrpl.html
blurb: All interactions with the ledger are either transactions or requests.
labels:
- Blockchain
---
# Transactions and Requests
Most interactions with the XRP Ledger involve either sending a transaction that makes changes to the ledger or sending a request for information from the ledger. You can also subscribe to monitor continual notifications of interest.
## How Do Transactions Work?
Use transactions to make changes on the ledger such as transferring XRP and other tokens between accounts; minting and burning NFTs; and creating, accepting, and cancelling offers. You execute a transaction by sending a command to the XRP Ledger and watching for confirmation that the transaction is complete. The command syntax format is the same for every transaction.
- You must always provide the _TransactionType_ and the public address of the _Account_ making the transaction.
- Two required fields are the _Fee_ for the transaction and the next _Sequence_ number for transactions from the account. These fields can be filled in automatically.
- Transactions can also have required fields specific to the transaction type. For example, a _Payment_ transaction requires an _Amount_ value (in _drops_, or millionths of an XRP) and a _Destination_ public address to which the funds are credited.
Here is a sample transaction in JSON format. This transaction transfers 1 XRP from account _rf1BiGeXwwQoi8Z2ueFYTEXSwuJYfV2Jpn_ to destination account _ra5nK24KXen9AHvsdFTKHSANinZseWnPcX_.
```json
{
"TransactionType": "Payment",
"Account": "rf1BiGeXwwQoi8Z2ueFYTEXSwuJYfV2Jpn",
"Amount": "1000000",
"Destination": "ra5nK24KXen9AHvsdFTKHSANinZseWnPcX"
}
```
Optional fields are available for all transactions, with additional fields available for specific transactions. You can include as many optional fields as you need, but do not have to include every field in every transaction.
You send the transaction to the ledger as a command from JavaScript, Python, the command line, or any compatible service. The rippled servers propose transactions to the XRPL.
![Proposed Transacations](img/introduction17-gather-txns.png)
When 80% of the validators approve a current set of proposed transactions, they are recorded as part of the permanent ledger. The rippled server returns the results of the transaction you sent.
For more information on Transactions, see [Transactions](transactions.html).
## How Do Requests Work?
Requests are used to get information from the ledger, but they do not make changes to the ledger. The information is freely available to anyone to view, so there is no need to sign in with your account information.
The fields you send vary with the type of information you request. They typically have several optional fields, but only a few required fields.
When you submit your request, it might be processed by a rippled server or by a Clio server, a server that is dedicated to responding to requests.
![Clio Server](img/introduction19-clio.png)
Clio servers take some of the load off the other rippled servers on the XRPL to improve processing speed and reliability.
This is a sample request in JSON format. This request gets the current account information for the account number you provide.
```json
{
"command": "account_info",
"account": "rG1QQv2nh2gr7RCZ1P8YYcBUKCCN633jCn"
}
```
The request returns a wealth of information. Here is an example response for an account information request in JSON format.
```json
{
"result": {
"account_data": {
"Account": "rG1QQv2nh2gr7RCZ1P8YYcBUKCCN633jCn",
"Balance": "999999999960",
"Flags": 8388608,
"LedgerEntryType": "AccountRoot",
"OwnerCount": 0,
"PreviousTxnID": "4294BEBE5B569A18C0A2702387C9B1E7146DC3A5850C1E87204951C6FDAA4C42",
"PreviousTxnLgrSeq": 3,
"Sequence": 6,
"index": "92FA6A9FC8EA6018D5D16532D7795C91BFB0831355BDFDA177E86C8BF997985F"
},
"ledger_current_index": 4,
"queue_data": {
"auth_change_queued": true,
"highest_sequence": 10,
"lowest_sequence": 6,
"max_spend_drops_total": "500",
"transactions": [
{
"auth_change": false,
"fee": "100",
"fee_level": "2560",
"max_spend_drops": "100",
"seq": 6
},
... (trimmed for length) ...
{
"LastLedgerSequence": 10,
"auth_change": true,
"fee": "100",
"fee_level": "2560",
"max_spend_drops": "100",
"seq": 10
}
],
"txn_count": 5
},
"status": "success",
"validated": false
}
}
```
For information on the fields in an Account record, see [Accounts](accounts.html).
Next: [Software Ecosystem](software-ecosystem.html)

69
content/concepts/introduction/what-is-the-xrp-ledger.md Normal file
View File

@@ -0,0 +1,69 @@
---
html: what-is-the-xrp-ledger.html
parent: introduction.html
blurb: Learn about the XRP Ledger (XRPL) blockchain.
labels:
- Blockchain
---
# What is the XRP Ledger?
The XRP Ledger is a decentralized blockchain that uses its own digital currency to process and record financial transactions.
## What Is a Blockchain?
A blockchain is a continuously growing list of records. The blockchain starts with a block of data.
![A block of data](img/introduction2-data-block.png)
A group of trusted validator nodes reach consensus that the data is valid.
![Validator nodes](img/introduction3-validators.png)
The block is uniquely identified with a very elaborate, complicated, computer-generated, cryptographic Hash number that is 64 hexadecimal characters long.
![Crypto hash](img/introduction4-hash.png)
The block is also identified by a timestamp with its creation time.
![Timestamp](img/introduction5-time-stamp.png)
Each validator node gets its own copy of the data block. There is no single central authority. All copies are equally valid.
![Validators with valid copies](img/introduction6-valid-copies.png)
Each block contains a hash pointer as a link to the previous block. It also has a timestamp, new data, and its own unique hash number.
![Hash pointer](img/introduction7-two-blocks.png)
Using this structure, each block has a clear position in the chain, linking back to the previous data block. This creates an immutable chain of blocks. You can always verify all current information on the chain by tracing back through the previous blocks.
![Three data blocks](img/introduction8-3-blocks.png)
By design, blockchains are resistant to modification of the data. Every ledger node gets an exact copy of the blockchain.
![Two validators with identical copies of the blockchain](img/introduction9-2-sets-of-3.png)
This creates an open, distributed ledger that records transactions between parties efficiently and in a verifiable and permanent way.
Once recorded, the data in any given block cannot be altered retroactively, unless a majority of the validators agree to the change. If so, all subsequent blocks are changed in the same way (a very rare and extreme occurrence).
### How Does the Federated Consensus Process Work?
Most of the rippled servers in the XRPL monitor or propose transactions. An important subset of servers are run as validators. These trusted servers accumulate lists of new transactions into a new possible ledger instance (a new block in the block chain).
![Gathering Transactions](img/introduction17-gather-txns.png)
They share their lists with all of the other validators. The validators incorporate proposed changes from one another and distribute a new version of the ledger proposal.
![80% Consensus](img/introduction18-80-percent-consensus.png)
When 80% of the validators agree on a set of transactions, they create a new ledger instance at the end of the chain and start the process again. This consensus process takes 4-6 seconds. You can monitor as ledger instances are created in real time by visiting [https://livenet.xrpl.org/](https://livenet.xrpl.org/).
### What Networks Are Available?
The XRPL is open to anyone who wants to set up their own instance of the rippled server and connect. The node can monitor the network, perform transactions, or become a validator. The active XRPL network is typically referred to as _Mainnet_.
For developers or new users who want to try out the features of XRPL without investing their own funds, there are two developer environments, _Testnet_ and _Devnet_. Users can create an account funded with 1,000 (fake) XRP and connect to either environment to interact with the XRPL.
Next: [What is XRP?](what-is-xrp.html)

73
content/concepts/introduction/what-is-xrp.md Normal file
View File

@@ -0,0 +1,73 @@
---
html: what-is-xrp.html
parent: introduction.html
blurb: Learn about XRP, the cryptocurrency traded on the XRP Ledger.
labels:
- Blockchain
---
# What is XRP?
XRP is the cryptocurrency supported by the XRP Ledger.
## What Is Cryptocurrency?
A cryptocurrency is a digital or virtual currency that is secured by cryptography and tracked using a blockchain. The security and integrity of cryptocurrency makes it nearly impossible to counterfeit or double-spend.
![XRP on the blockchain](img/introduction10-xrp-on-chain.png)
Cryptocurrencies, digital currencies, and digital assets all fall into the same general category. Cryptocurrencies are:
- digitally native (meaning they are built for the internet)
- programmable
- fast to transfer at a low cost
- open and transparent
- not restricted by borders or governments (so no need for nostro accounts that hold funds in another country)
- not subject to counterfeit
- do not require a bank account or infrastructure to settle payments.
![Advantages of cryptocurrencies](img/introduction11-all-the-things.png)
Cryptocurrencies are _fungible tokens_. _Fungible_ means that you can replace one token with other tokens of equal value. Postage is an example of a fungible token: if it costs 50 cents to mail a letter, you can use 2 25-cent stamps or 5 10-cent stamps for the postage, because postage stamps are fungible (consistent in relative value and interchangeable).
Cryptocurrencies are also decentralized. There’s no central authority governing the currency. Once a transaction is on the blockchain you cannot change it. It is difficult to censor cryptocurrency: so long as the system is sufficiently decentralized, no one can roll back transactions, freeze balances, or block someone from using a decentralized digital asset. Rules do not change without significant coordination among all participants.
Cryptocurrencies are compelling for investors and developers because no single entity can “pull the plug” on them and have them disappear.
## But Why Is It Valuable?
![Advantages of cryptocurrencies](img/introduction12-diamond.png)
It might seem strange that cryptocurrency is based solely on computer data, and not on any sort of tangible commodity such as precious metal. Traditionally, currencies have been based on cattle, sea shells, rare metals, stones, or other physical objects. But these items have value only because there was agreement between people in a culture.
While it might seem safer to have something “real” in your hand, many people wouldn’t know fool’s gold from the actual thing, or cubic zirconia from a genuine diamond. Paper money can be counterfeit. You can forget you have a $10 bill in your pocket and ruin it in the wash. It is costly to safely store and transport valuable items for payment.
The value of cryptocurrency comes from the faith that holders place in the currency. Given the distributed nature of the records and the cryptographic safeguards to secure the funds, cryptocurrency could be considered a much more robust, secure, and convenient form of currency than traditional fiat currencies.
## XRP is Cryptocurrency
The XRP Ledger was built over 2011 – early 2012 by Jed McCaleb, Arthur Britto and David Schwartz. At the time of its creation, there were 100 billion XRP. In September 2012, Jed and Arthur, along with Chris Larsen formed Ripple (the company, called OpenCoin Inc. at the time) and decided to gift 80 billion XRP to Ripple in exchange for Ripple developing on the XRP Ledger.
![One Hundred Billion with a "B"](img/introduction14-hundred-billion.png)
Since then, the company has regularly sold XRP, used it to strengthen XRP markets and improve network liquidity, and incentivized development of the greater ecosystem. In 2017, the company placed [55 billion XRP in escrow](https://ripple.com/insights/ripple-escrows-55-billion-xrp-for-supply-predictability/?__hstc=78174987.8aa695b6d0420a940041f1842edfd8a6.1692378128025.1692644550213.1692652561840.8&__hssc=78174987.3.1692652561840&__hsfp=3379522993) to ensure that the amount entering the general supply [grows predictably](https://ripple.com/insights/ripple-to-place-55-billion-xrp-in-escrow-to-ensure-certainty-into-total-xrp-supply/?__hstc=78174987.8aa695b6d0420a940041f1842edfd8a6.1692378128025.1692644550213.1692652561840.8&__hssc=78174987.3.1692652561840&__hsfp=3379522993) for the foreseeable future. Ripple's [XRP Market Performance site](https://ripple.com/xrp/?__hstc=78174987.8aa695b6d0420a940041f1842edfd8a6.1692378128025.1692644550213.1692652561840.8&__hssc=78174987.3.1692652561840&__hsfp=3379522993) reports how much XRP the company has available and locked in escrow at present.
![Man with one XRP](img/introduction13-x-prefix.png)
### Naming
Originally, the XRP Ledger was called "Ripple" for the way the technology allowed payments [to ripple through multiple hops and currencies](rippling.html). For the native asset built into the ledger, the creators chose the ticker symbol "XRP" from the term "ripple credits" or "ripples" and the X prefix for non-national currencies in the [ISO 4217](https://www.iso.org/iso-4217-currency-codes.html) standard. The company registered itself as "Ripple Labs". The name "XRP" came to be used to refer to the asset in all contexts, to avoid confusion with the similar names for the technology and company, and eventually the company shortened its own name to "Ripple". In May 2018, [the community selected a new "X" symbol](https://twitter.com/xrpsymbol/status/1006925937571713025) to represent XRP to differentiate it from the triskelion logo that had previously been used for both the company and the digital asset.
| XRP "X" Logo | Ripple triskelion |
|:---------------------------------------|:------------------------------------|
| !["X" logo](assets/img/xrp-x-logo.png) | ![Triskelion](img/ripple-triskelion.png) |
### Trademark
"XRP" is a registered trademark of the XRPL Foundation in the U.S.A. and other countries like China and Estonia.
The trademark application was registered with the United States Patent and Trademark Office (USPTO) in 2013 with OpenCoin Inc and Ripple Labs Inc as assignees. In 2022, the trademark assignment was updated and is now assigned to the MITTETULUNDUSÜHING XRP LEDGER TRUST (“XRPLF”).
Next: [Crypto Wallets](crypto-wallets.html)

108
content/concepts/introduction/xrp-ledger-overview.ja.md
View File

@@ -1,108 +0,0 @@
---
html: xrp-ledger-overview.html
parent: introduction.html
blurb: XRP Ledgerの基本機能を簡単に紹介します。
labels:
- ブロックチェーン
- XRP
---
# XRP Ledgerの概要
**XRP Ledger**は、ピアツーピア・サーバーのネットワーク機能を備えた分散型の暗号台帳です。XRP Ledgerは**XRP**の土台となるものであり、世界中で使用されている様々な通貨の橋渡しをするために設計されたデジタル資産です。RippleはXRP Ledgerの開発を主導し、_「価値のインターネット」_（情報が移動するようにお金が移動する世界）の実現に向けて鍵となる役割を果たすと期待されるXRPを推進しています。
## 決済のためのデジタル資産
XRPはXRP Ledger固有のデジタル資産です。暗号鍵を持ち、インターネットに接続できる人は誰でも、XRPを受け取り、保持し、任意の人に送ることができます。XRPは他の通貨での取引をも容易にできる魅力的なブリッジ通貨として開発されました。XRPには次のような多くの特性があり、これにより他の多くのユースケースでも魅力的な資産となっています。
- **[耐検閲性のある取引処理][]:** どの特定の個人もXRP取引の成功・不成功を勝手に決定することはできませんし、一度完了した取引を組み戻すこともできません。ネットワークに参加するユーザーは、ネットワークを健全に保っている限り、XRPを数秒で送受信できます。
- **[高速で効率的なConsensusアルゴリズム][]:** XRP LedgerのConsensusアルゴリズムは、最大1500件/秒のスループットで取引を処理し、4秒から5秒で完了します。これらの特性により、XRPは、他の上位デジタル資産の少なくとも10倍の優位性をもっています。
- **[限定されたXRP供給量][]:** XRP Ledgerが開始された時、1000億XRPが発行され、今後さらにXRPが発行されることはありません。（各XRPは、小数第6位まで再分割でき、総計10万兆（10の17乗）_drop_（XRPの最小単位）となります。）取引に必要なコストを支払うために少額のXRPが毎回消却され、使用可能なXRPの供給量は時間とともにゆっくりと減少していきます。
- **[責任あるソフトウェアガバナンス][]:** Rippleでは、世界に通用する技術をもった常勤の開発チームが、XRP Ledgerの基礎となるソフトウェアを保守し、継続的に改良しています。Rippleは、技術の担い手として、さらに技術に対する支援者として、世界中の政府および金融機関と建設的な関係を築いています。
- **[安全で適応性のある暗号技術][]:** XRP Ledgerは、ECDSA（Bitcoinが使用しているものと同じアルゴリズム）などの業界標準のデジタル署名システムを利用しています。またEd25519などの最新の効率的なアルゴリズムもサポートしています。XRP Ledgerのソフトウェアは拡張性に富み、最先端の暗号技術の進歩に合わせてアルゴリズムを追加したり消却にしたりすることが可能です。
- **[スマートコントラクト用の最新機能][]:** Escrow、ChecksおよびPayment Channelなどの機能は、[Interledgerプロトコル](https://interledger.org/)を含む最新の金融アプリケーションをサポートしています。この拡張機能のツールボックスには、ネットワークの修正プロセスや、取引の不変性を担保するチェックを分けて行うなどの安全機能が備わっています。
- **[台帳上の分散型取引所][]:** XRP Ledgerには、それ自体でXRPを便利に使うための機能すべてに加え、ユーザー任意の通貨建ての債務を追跡し取引するための多機能な会計システムや、プロトコルに組み込まれた両替機能などがあります。XRP Ledgerは、通貨間の長い支払いパスや、複数通貨の一元的決済を確実に処理し、XRPを活用することで分散型ネットワークに存在する信頼のギャップを解消しています。
## 耐検閲性のある取引処理
[耐検閲性のある取引処理]: #耐検閲性のある取引処理
XRPは、Bitcoinや他の暗号資産と同様に新しい通貨の一種です。
- これらの**分散型デジタル資産**はそれぞれのコンピューターシステム上に存在し、これを管理する中央管理者はいません。システムが十分に分散されている限り、取引を組み戻したり、残高を凍結したり、他のユーザーが分散型デジタル資産を使用することを阻止したりすることはできません。これらの資産はもともとデジタルであるため、離れた場所からもオンラインで使用できます。
これは物理的な通貨と中央集権型デジタル通貨の良い部分を併せ持っていることを意味します。2009年にBitcoinが発明されるまでは、すべての通貨は次の2つのカテゴリに分類できました。
- **物理的な硬貨および紙幣**。これは、中央の管理者を経由せずに、個人が決済するために使用できます。ただし、物理的なものであるためオンラインでは使用できず、長距離のビジネスで使うには時間がかかり不便です。
- **中央集権型デジタル通貨**。これには、取引を承認する管理者が必要です。管理者には、取引の検閲や組み戻しの権限、また一部の個人がデジタル通貨を使用することを許可しない権限もあります。デジタル通貨の運営者は、誰かが利用規約に違反したことが判明した場合、その個人の通貨を凍結したり没収したりすることもできます。ただし、これらの通貨の残高はデジタルであるためオンラインで使用でき、離れた場所の取引にも便利です。
**注記:** XRP Ledgerのユーザーは、XRP Ledgerで発行されたXRP以外の通貨であれば凍結 _できます_ 。詳細は、[凍結についての資料](freezes.html)を参照してください。
信頼できるバリデータノードから構成されるXRP Ledgerのシステムでは、人手をほとんどかけることなく、他の分散型システムよりも優れた権限の分散が可能です。不特定多数の参加者間でのConsensusを完全に自動化しているシステムは、議決権の集中のリスクに晒されます。例えば、Bitcoinの採掘は、電気代が安い場所に偏って集中しています。Rippleは、様々な地域の異なる組織によって運営される別個のバリデータリストを管理しています。そのためXRP Ledgerは検閲などの外部の圧力に対してプルーフ・オブ・ワークによる採掘よりも高い耐性を持つことができます。推奨されるバリデータを分散させるためのRippleの対応策の詳細は、[分散化戦略についてのアップデート](https://xrpl.org/blog/2017/decent-strategy-update.html)を参照してください。
XRP Ledgerの検閲機能の詳細は、[取引検閲の検知](transaction-censorship-detection.html)を参照してください。
## 高速で効率的なConsensusアルゴリズム
[高速で効率的なConsensusアルゴリズム]: #高速で効率的なconsensusアルゴリズム
XRP Ledgerが多くの暗号資産と最も異なっている点は、BitcoinやEthereumなど他のほとんどのシステムが行う「採掘」の時間と労力を必要とせず、独自のConsensusアルゴリズムを使用していることです。「プルーフ・オブ・ワーク」または「プルーフ・オブ・ステーク」の代わりに、XRP LedgerのConsensusアルゴリズムでは、すべての参加者が重複する「信頼されるバリデータ」のリストを持ち、どの取引がどの順序で発生したかについて効率的に合意するシステムとなっています。2018年の初めの時点で、Bitcoinネットワークが取引ごとに使用する電力量は、米国の一世帯の住宅で1日に使用される量よりも多く、さらに取引の承認には何時間もかかっています。1つのXRP取引で使用される電力量はごく少量であり、承認には4秒から5秒しかかかりません。
さらに、XRP Ledgerのそれぞれの新しい「台帳バージョン」（「ブロック」と同義）には、すべての残高が完全かつ最新の状態で保持されているため、サーバーは、何時間もかけてすべての取引履歴をダウンロードして再処理する必要がなく、数分でネットワークと同期することができます。
XRP LedgerのConsensusアルゴリズムの動作方法の詳細は、[XRP Ledger Consensusプロセス](consensus.html)を参照してください。XRP LedgerがこのConsensusアルゴリズムを使用する理由の背景は、[Consensusの原理とルール](consensus-principles-and-rules.html)を参照してください。
## 限定されたXRP供給量
[限定されたXRP供給量]: #限定されたxrp供給量
戦争および政変と並んで、超インフレは通貨が消滅する主な原因の1つです。バリデータが分散しているため、XRPは政治的要因に対してはある程度の耐性があります。一方、超インフレに対しては、XRP Ledgerのルールにより簡潔なソリューションで対応しています。つまりXRPのトータル供給量の限定です。発行量を増やすメカニズムがそもそもないため、XRPが超インフレに悩まされる可能性は非常に低くなります。
市場に出回るXRPの供給量は、次のいくつかの要因によって変化 _します_。
- XRP Ledgerで取引を送信すると、毎回少額のXRPが消却されます。送信者は消却する額を選択できますが、予想される取引の処理作業とネットワークの混雑度に応じて一定の最低額が設定されています。ネットワークが混み合っている場合、より多くのXRPを消却するよう選択している取引は、取引キューの前に割り込むことができます。これはスパム防止策で、XRP Ledgerネットワークに対する[DDoS](https://en.wikipedia.org/wiki/Denial-of-service_attack)攻撃にかかるコストは極めて高額になります。詳細は、[取引コスト](transaction-cost.html)を参照してください。
- XRP Ledgerの各アカウントは、少額のXRPを準備しておく必要があります。これもスパム防止策で、台帳データが必要以上に増えてしまうことを防ぎます。XRP Ledgerのバリデータは、実世界でのXRPの価値の変動に対応する目的で、準備金として必要なXRPの金額を変更するために投票決議を行うことができます。（この投票が前回発生したのは2021年の9月であり、このときは[必要な準備金が20 XRPから10 XRPに減少しました](https://xrpl.org/blog/2021/reserves-lowered.html)。）必要な準備金が減少すると、以前は準備金によって使用できなくなっていた部分のXRPが再び使用可能になります。
- Ripple（会社）は、大量のXRPをEscrowに保有しています。毎月の初めに、Rippleで使用するために10億XRPがEscrowから引き出されます。（RippleはXRPを使用してXRP Ledgerエコシステムの成長を促し、また一部のXRPを機関投資家に売却しています。Rippleはまた、取引所での取引総量のうちのわずかな比率に限定して、プログラムに従って取引所でXRPを売却しています。Rippleは[XRP市場レポート](https://ripple.com/insights/q1-2018-xrp-markets-report/)で四半期ごとに売上高を公開しています。）毎月の終わりに、Rippleが売却や譲渡をせずに残っているXRPがあればEscrowに戻し、54か月保管します。RippleのEscrowポリシーの詳細は、[RippleはXRPの総供給量の確実性を確保するために550億XRPをエスクローに預託することを発表しました](https://ripple.com/insights/ripple-to-place-55-billion-xrp-in-escrow-to-ensure-certainty-into-total-xrp-supply/)を参照してください。Escrow機能の技術的詳細は、[Escrow](escrow.html)を参照してください。
<a id="責任あるソフトウェア管理"><!-- Legacy anchor --></a>
## 責任あるソフトウェアガバナンス
[責任あるソフトウェアガバナンス]: #責任あるソフトウェアガバナンス
ソフトウェアの水準は、そのソフトウェアを作成して管理する開発者によって決まります。Rippleは、XRP Ledgerソフトウェア、特にコアサーバーである`rippled`の保守および改良に専念する優秀な常勤エンジニアチームを雇用しています。[`rippled`のソースコード](https://github.com/ripple/rippled/)は、XRP Ledgerエコシステムの他の多くの部分と同様に、一般利用が可能なオープンソースライセンスを有するソフトウェアとして公開されています。Rippleのエンジニアは、次のようなソフトウェアエンジニアリングのベストプラクティスに従っています。
- 慎重で徹底的なコードレビュープロセス
- 包括的なコードカバレッジと単体テスト
- 潜在的な脆弱性およびメモリーリークの自動チェックの定期的な実行
- 専門家組織による外部レビューヘの定期的な委託
巨額のXRPを長期にわたって保持する義務がある組織として、Rippleは、XRPが法に準拠して持続的かつ建設的な方法で広く使用されるために努力する強い自発的なインセンティブを持っています。「価値のインターネット」というRippleの理想と同じ目標を持つ企業に対して、Rippleは技術的なサポートを提供します。Rippleはまた、世界中の立法当局や規制当局と協力し、デジタル資産および関連ビジネスを管理する合理的な法律の実施に向けて誘導しています。
## 安全で適応性のある暗号技術
[安全で適応性のある暗号技術]: #安全で適応性のある暗号技術
暗号技術は分散システムにおいて最も重要な部分の1つであり、小さな技術的問題が一瞬にして世界中の悪意あるハッカーによる盗難につながる危険性を秘めています。XRP Ledgerは、取引の署名および検証のための業界標準の技術と、何年もの間、数千億USドルにも相当する価値を保護することに成功してきたアルゴリズムを使用しています。また、XRP Ledgerにはマルチシグ機能が備わっているため、バックアップとして多要素認証や複数のユーザー間で分割キーを使用できます。さらに暗号技術の飛躍的な進歩によって古いアルゴリズムが時代遅れになり、新しいアルゴリズムが導入される場合でも、ユーザーはそのままキーを使い続けることができます。
詳細は、[暗号鍵](cryptographic-keys.html)および[マルチシグ](multi-signing.html)を参照してください。
## スマートコントラクト用の最新機能
[スマートコントラクト用の最新機能]: #スマートコントラクト用の最新機能
[XRP決済](direct-xrp-payments.html)による単純な価値の移動に加え、XRP Ledgerには「価値のインターネット」に特化した拡張機能があります。この拡張機能により、XRP上にビルドされたアプリケーションは、以前は実用的でなかったり実現不可能だったりしたサービスや機能を提供できるようになります。ネットワーク自体のなかで「スマートコントラクト」としてのアプリケーションを実行するのではなく、XRP Ledgerでは、コントラクトを処理するためのツールを提供しつつ、実行環境またはコンテナが適切であれば、すべての場所でアプリケーションを実行することができます。この「シンプルにする」というアプローチは、柔軟でスケーラブル、かつ強力です。
XRP Ledgerの拡張機能として次のものがあります。
- [Payment Channel](use-payment-channels.html)により、非同期の残高を署名の作成、検証とほぼ同時に変更することができます。
- [Escrow](escrow.html)により、宣言した時間が経過するまで、または暗号条件が満たされるまで、XRPはロックされます。
- [DepositAuth](depositauth.html)により、ユーザーは自分に対して送金できる相手か、送金できない相手かを決めることができます。
- [分散型取引所](#台帳上の分散型取引所)により、ユーザーは台帳上で債務およびXRPを取引することができます。
- [Invariant Checking](https://xrpl.org/blog/2017/invariant-checking.html)により、独立したレイヤーで取引実行時のバグから取引を保護することができます。
- [Amendment](amendments.html)により、現行機能にスムーズにアップグレードすることができ、移行に際してエコシステムに被害を及ぼしたり、不確定要素を発生させることなく、継続して技術を発展させることができます。
## 台帳上の分散型取引所
[台帳上の分散型取引所]: #台帳上の分散型取引所
XRP Ledgerを他の暗号資産ネットワークとは異なるものにしている最も大きな特徴は、XRP Ledger上に完全な取引機能が含まれている点です。このシステム内で、事業者（通常は「ゲートウェイ」と言います）は希望の通貨を顧客に自由に発行でき、その顧客はその特定ゲートウェイによってXRPに発行された通貨や他のゲートウェイによって発行された通貨を自由に取引できます。このようにXRP Ledgerでは、取引注文によって流動性を確保しつつ、複数通貨間の一元的な取引を実行することができます。
分散型取引所がどのように機能するかの詳細は、[分散型取引所](decentralized-exchange.html)を参照してください。ゲートウェイビジネスモデルの詳細は、[Become an XRP Ledger Gateway](become-an-xrp-ledger-gateway.html)を参照してください。

107
content/concepts/introduction/xrp-ledger-overview.md
View File

@@ -1,107 +0,0 @@
---
html: xrp-ledger-overview.html
parent: introduction.html
blurb: Get a quick and concise introduction to key features of the XRP Ledger.
labels:
- Blockchain
- XRP
---
# XRP Ledger Overview
The **XRP Ledger** is an online system for payments, powered by a community without a central leader. Anyone can connect their computer to the peer-to-peer network that manages the ledger. The XRP Ledger is the home of **XRP**, a digital asset designed to bridge the world's many currencies. The XRP Ledger is one part of the developing _Internet of Value_: a world in which money moves the way information does today.
## The Digital Asset for Payments
XRP is a digital asset native to the XRP Ledger. Anyone with a cryptographic key and an internet connection can receive, hold, and send XRP to anyone else. XRP's creators have developed it to be a desirable bridge currency that can enable trades in any other currency. XRP has many properties which make it an appealing asset for many other use cases, too:
- **[Censorship-Resistant Transaction Processing][]:** No single party decides which XRP transactions succeed or fail, and no one can "roll back" a transaction after it completes. As long as those who choose to participate in the network keep it healthy, they can send and receive XRP in seconds.
- **[Fast, Efficient Consensus Algorithm][]:** The XRP Ledger's consensus algorithm settles transactions in 4 to 5 seconds, and can process up to 1500 transactions per second. These properties put XRP far ahead of other top digital assets.
- **[Finite XRP Supply][]:** When the XRP Ledger began, 100 billion XRP were created, and no more XRP will ever be created. (Each XRP is divisible down to 6 decimal places, for a grand total of 100 quadrillion (10^17) _drops_ of XRP.) The available supply of XRP decreases slowly over time as small amounts are destroyed to pay transaction costs. <!-- STYLE_OVERRIDE: will -->
- **[Responsible Software Governance][]:** A team of full-time, world-class developers at Ripple maintain and continually improve the XRP Ledger's underlying software. Ripple acts as a steward for the technology and an advocate for its interests, and builds constructive relationships with governments and financial institutions worldwide.
- **[Secure, Adaptable Cryptography][]:** The XRP Ledger relies on industry standard digital signature systems like ECDSA (the same scheme used by Bitcoin) but also supports modern, efficient algorithms like Ed25519. The extensible nature of the XRP Ledger's software makes it possible to add and disable algorithms as the state of the art in cryptography advances.
- **[Modern Features for Smart Contracts][]:** Features like Escrow, Checks, and Payment Channels support cutting-edge financial applications including the [Interledger Protocol](https://interledger.org/). This toolbox of advanced features comes with safety features like a process for amending the network and separate checks against invariant constraints.
- **[On-Ledger Decentralized Exchange][]:** In addition to all the features that make XRP useful on its own, the XRP Ledger also has a fully-functional accounting system for tracking and trading obligations denominated in any way users want, and an exchange built into the protocol. The XRP Ledger can settle long, cross-currency payment paths and exchanges of multiple currencies in atomic transactions, bridging gaps of trust with XRP.
## Censorship-Resistant Transaction Processing
[Censorship-Resistant Transaction Processing]: #censorship-resistant-transaction-processing
XRP is part of a new class of money which includes Bitcoin and other cryptocurrencies:
- These **Decentralized digital assets** exist in computer systems without a central administrator. As long as the system is sufficiently decentralized, no one can roll back transactions, freeze balances, or block someone from using a decentralized digital asset. These assets are natively digital, so they can be used online across any distance.
This combines qualities of physical and centralized digital money. Prior to the invention of Bitcoin in 2009, all currencies could be divided into those two categories:
- **Physical coins and paper money**, which individuals can use to do business without going through a central party. As physical objects, they cannot be used online, and doing business long-distance is slow and inconvenient.
- **Centralized digital currencies**, which need an administrator to confirm transactions. The administrator also has the power to censor or roll back transactions, or disallow some individuals from using the digital currency. If the operator of a digital currency decides someone has violated its terms of service, it can freeze or even confiscate that person's money. However, as digital balances, these currencies can be used online and are convenient across long distances.
**Note:** Users of the XRP Ledger _can_ freeze non-XRP currencies issued in the XRP Ledger. For more information, see the [Freeze documentation](freezes.html).
The XRP Ledger's system of trusted validators uses a small amount of human interaction to achieve better distribution of authority than other decentralized systems. Fully-automated systems for reaching consensus from an unknown set of participants are vulnerable to concentrations of voting power. For example, Bitcoin mining is disproportionately concentrated in places with cheap electricity. As Ripple curates a list of distinct validators run by different entities in different jurisdictions, the XRP Ledger can become more resistant to censorship and outside pressures than proof-of-work mining. For more information on Ripple's plan to decentralize the recommended set of validators, see the [Decentralization Strategy Update](https://xrpl.org/blog/2017/decent-strategy-update.html).
For more information about the XRP Ledger's ability to detect censorship, see [Transaction Censorship Detection](transaction-censorship-detection.html).
## Fast, Efficient Consensus Algorithm
[Fast, Efficient Consensus Algorithm]: #fast-efficient-consensus-algorithm
The XRP Ledger's biggest difference from most cryptocurrencies is that it uses a unique consensus algorithm that does not require the time and energy of "mining", the way Bitcoin, Ethereum, and almost all other such systems do. Instead of "proof of work" or even "proof of stake", The XRP Ledger's consensus algorithm uses a system where every participant has an overlapping set of "trusted validators" and those trusted validators efficiently agree on which transactions happen in what order. As of early 2018, the amount of electricity the Bitcoin network uses per transaction is more than a family home in the USA uses in an entire day, and confirming the transaction takes hours. A single XRP transaction uses a negligible amount of electricity, and takes 4 or 5 seconds to confirm.
Furthermore, each new "ledger version" in the XRP Ledger (the equivalent of a "block") contains the full current state of all balances, so a server can synchronize with the network in minutes instead of spending hours downloading and re-processing the full transaction history.
For more information on how the XRP Ledger's consensus algorithm works, see [The XRP Ledger Consensus Process](consensus.html). For background on why the XRP Ledger uses this consensus algorithm, see [Consensus Principles and Rules](consensus-principles-and-rules.html).
## Finite XRP Supply
[Finite XRP Supply]: #finite-xrp-supply
Alongside war and political turmoil, hyperinflation is one of the leading causes of death for currencies. While the decentralized system of validators provides XRP with some resistance to political factors, the rules of the XRP Ledger provide a simpler solution to hyperinflation: the total supply of XRP is finite. Without a mechanism to create more, it becomes much less likely that XRP could suffer hyperinflation.
The supply of XRP available to the general public _does_ change due to a few factors:
- Sending transactions in the XRP Ledger destroys a small amount of XRP. Senders choose how much to destroy, with the minimum based on the expected work of processing the transaction and how busy the network is. If the network is busy, potential transactions that promise to destroy more XRP can cut in front of the transaction queue. This is an anti-spam measure to make it prohibitively expensive to [DDoS](https://en.wikipedia.org/wiki/Denial-of-service_attack) the XRP Ledger network. For more information, see [Transaction Cost](transaction-cost.html).
- Each account in the XRP Ledger must hold a small amount of XRP in reserve. This is an anti-spam measure to disincentivize making the ledger data occupy too much space. XRP Ledger validators can vote to change the amount of XRP required as a reserve, to compensate for changes in XRP's real-world value. (The last time this happened was in September 2021, when [the reserve requirement decreased from 20 XRP to 10 XRP](https://xrpl.org/blog/2021/reserves-lowered.html).) If the reserve requirement decreases, XRP that was previously locked up by the reserve becomes available again.
- Ripple (the company) holds a large reserve of XRP in escrow. At the start of each month, 1 billion XRP is released from escrow for Ripple to use. (Ripple uses XRP to incentivize growth in the XRP Ledger ecosystem and sells XRP to institutional investors. Ripple also sells XRP programmatically on exchanges, limited to a small percentage of overall exchange volume. Ripple publishes sales figures quarterly in the [XRP Markets Report](https://ripple.com/insights/q1-2018-xrp-markets-report/).) At the end of each month, any remaining XRP the company does not sell or give away is stored into escrow for a 54-month period. For more information on Ripple's escrow policy, see [Ripple Escrows 55 Billion XRP for Supply Predictability](https://ripple.com/insights/ripple-to-place-55-billion-xrp-in-escrow-to-ensure-certainty-into-total-xrp-supply/). For more information on the technical capabilities of the Escrow feature, see [Escrow](escrow.html).
## Responsible Software Governance
[Responsible Software Governance]: #responsible-software-governance
Any piece of software can only be as good as the developers who code and manage it. Ripple employs a team of world-class engineers dedicated full-time to maintaining and improving the XRP Ledger software, especially the core server, `rippled`. The [source code for `rippled`](https://github.com/ripple/rippled/) is available to the public with a permissive open-source license, as are many other parts of the XRP Ledger ecosystem. Ripple engineers follow best practices for software engineering, including:
- A famously strict and thorough code review process
- Comprehensive code coverage and unit tests
- Regularly running automated checks for potential vulnerabilities and memory leaks
- Regularly commissioning external reviews by professional organizations
As an entity that is obligated to hold large amounts of XRP for the long term, Ripple has a strong incentive to ensure that XRP is widely used in ways that are legal, sustainable, and constructive. Ripple provides technical support to businesses whose goals align with Ripple's ideal of an Internet of Value. Ripple also cooperates with legislators and regulators worldwide to guide the implementation of sensible laws governing digital assets and associated businesses.
## Secure, Adaptable Cryptography
[Secure, Adaptable Cryptography]: #secure-adaptable-cryptography
Cryptography is one of the hardest parts of any distributed system, and a mistake can lead to money stolen by malicious actors anywhere in the world. The XRP Ledger uses industry-standard schemes for signing and verifying transactions, algorithms that have successfully protected hundreds of billions of US dollars' worth of value for many years. The XRP Ledger also layers multi-signing functionality so you can use multi-factor authorization or split keys across multiple people as a backup, and provides new algorithms with a path to migrate the keys you use if a breakthrough in cryptography makes the old algorithms obsolete.
For more information, see [Cryptographic Keys](cryptographic-keys.html) and [Multi-Signing](multi-signing.html).
## Modern Features for Smart Contracts
[Modern Features for Smart Contracts]: #modern-features-for-smart-contracts
Besides direct value transfer with [XRP payments](direct-xrp-payments.html), the XRP Ledger has advanced features specialized for the Internet of Value. This allows applications built on XRP to provide services and functionality that would have been impractical or impossible in the past. Rather than running applications as "smart contracts" in the network itself, the XRP Ledger provides tools for settling contracts, while letting the applications themselves run anywhere, in whatever environment or container is appropriate. This "keep it simple" approach is flexible, scalable, and powerful. <!-- STYLE_OVERRIDE: simple -->
A sample of advanced features in the XRP Ledger:
- [Payment Channels](use-payment-channels.html) allow asynchronous balance changes as fast as you can create and validate signatures.
- [Escrow](escrow.html) locks up XRP until a declared time passes or cryptographic condition is met.
- [DepositAuth](depositauth.html) lets users decide who can send them money and who can't.
- A [Decentralized Exchange](#on-ledger-decentralized-exchange) lets users trade obligations and XRP on-ledger.
- [Invariant Checking](https://xrpl.org/blog/2017/invariant-checking.html) provides an independent layer of protections against bugs in transaction execution.
- [Amendments](amendments.html) provide smooth upgrades to the existing feature set, so the technology can continue to evolve without fracturing the ecosystem or causing uncertainty around times of transition.
## On-Ledger Decentralized Exchange
[On-Ledger Decentralized Exchange]: #on-ledger-decentralized-exchange
One of the biggest features that sets the XRP Ledger apart from other cryptocurrency networks is that it also contains a full currency exchange that runs on the XRP Ledger. Within this system, businesses (typically called "gateways") can freely issue any currency they want to customers, and those customers can freely trade tokens for XRP or other tokens. The XRP Ledger can execute atomic cross-currency transactions this way, using orders in the exchange to provide liquidity.
For more information on how the decentralized exchange works, see [Decentralized Exchange](decentralized-exchange.html). For more information on the gateway business model, see the [Become an XRP Ledger Gateway](become-an-xrp-ledger-gateway.html).

22
content/concepts/introduction/xrp.ja.md
View File

@@ -1,22 +0,0 @@
---
html: xrp.html
parent: introduction.html
blurb: 送金のためのデジタルアセットである、XRPの使い方と特性について学びましょう。
labels:
- XRP
---
# XRP
**XRP**は、XRP Ledgerのネイティブ暗号資産です。XRP Ledgerのすべての[アカウント](accounts.html)間で相互にXRPを送金できます。アカウントは、最小限度額のXRPを[準備金](reserves.html)として保有する必要があります。XRP Ledgerアドレス間にてXRPの直接送金が可能で、ゲートウェイや流動性プロバイダーを必要としません。このため、XRPは便利なブリッジ通貨となりました。
XRP Ledgerの高度機能の一部（[Escrow](escrow.html)や[Payment Channel](use-payment-channels.html)など）は、XRPでのみ使えます。オーダーブックの[オートブリッジング](autobridging.html)は、XRPを使用して、2つの発行済み通貨のオーダーブックをXRPオーダーブックにマージして、合成された一つのオーダーブックを作成することで、分散型取引所の流動性を高めます。（たとえば、オートブリッジングによりUSD:XRPオーダーとXRP:EURオーダーがマッチングされ、USD:EURオーダーブックとなります。）
XRPはまた、ネットワークのスパムの防御対策としても機能します。すべてのXRP Ledgerアドレスには、XRP Ledger維持管理コストを支払うために少額のXRPが必要です。[トランザクションコスト](transaction-cost.html)と[準備金](reserves.html)は、XRP建ての中立的な手数料であり、どの当事者にも支払われません。レジャーのデータフォーマットで、XRPは[AccountRootオブジェクト](accountroot.html)に保管されます。
XRPのユースケース、メリット、最新情報についての詳細は、[XRPポータル](https://ripple.com/xrp/)を参照してください。
## XRPの特性
一番最初のレジャーにて1000億XRPが発行され、これ以上新しいXRPは作成できません。XRPは、[トランザクションコスト](transaction-cost.html)によって消却されるか、またはキーの所有者がいないアドレスに送金すると失われることがあります。このため、XRPは本質的にはやや[デフレ通貨](https://en.wikipedia.org/wiki/Deflation)です。XRPがなくなることを心配する必要はありません。現時点の消却のペースでは、すべてのXRPが消却されるまでに約7万年かかります。またXRPの総供給量の変化に伴い、XRPの[価格と手数料が調整される可能性があります](fee-voting.html)。
技術的には、XRPは0.000001 XRPの単位まで正確に計算され、「Drop」と呼ばれます。[`rippled`API](http-websocket-apis.html)では、XRPの量は常にXRPのdrop単位で指定する必要があります。たとえば1 XRPは`1000000` dropと表されます。詳細については、[通貨フォーマットのリファレンス](currency-formats.html)を参照してください。

46
content/concepts/introduction/xrp.md
View File

@@ -1,46 +0,0 @@
---
html: xrp.html
parent: introduction.html
blurb: Learn about the uses and properties of XRP, the digital asset for payments.
labels:
- XRP
---
# XRP
**XRP** is the native cryptocurrency of the XRP Ledger. All [accounts](accounts.html) in the XRP Ledger can send XRP among one another and must hold a minimum amount of XRP as a [reserve](reserves.html). XRP can be sent directly from any XRP Ledger address to any other. This helps make XRP a convenient bridge currency.
Some advanced features of the XRP Ledger, such as [Escrow](escrow.html) and [Payment Channels](use-payment-channels.html), only work with XRP. Order book [auto-bridging](autobridging.html) uses XRP to deepen liquidity for tokens in the decentralized exchange by using XRP as an intermediary when doing so is cheaper. (For example, auto-bridging matches USD:XRP and XRP:EUR orders to augment USD:EUR order books.)
XRP also serves as a protective measure against spamming the network. All XRP Ledger addresses need a small amount of XRP to offset the costs of maintaining the XRP Ledger. The [transaction cost](transaction-cost.html) and [reserve](reserves.html) are neutral fees denominated in XRP and not paid to any party. In the ledger's data format, XRP is stored in [AccountRoot objects](accountroot.html).
Some of the desirable properties of XRP come from the nature of the XRP Ledger and its [consensus process](consensus.html). The XRP Ledger does not require mining and the consensus process does not require multiple confirmations for immutability, which makes the XRP Ledger faster and more efficient at processing transactions than Bitcoin and other top cryptocurrencies.
## XRP Properties
The very first ledger contained 100 billion XRP, and no new XRP can be created. XRP can be destroyed by [transaction costs](transaction-cost.html) or lost by sending it to addresses for which no one holds a key, so XRP is slightly [deflationary](https://en.wikipedia.org/wiki/Deflation) by nature. No need to worry about running out, though: at the current rate of destruction, it would take at least 70,000 years to destroy all XRP, and XRP [prices and fees can be adjusted](fee-voting.html) as the total supply of XRP changes.
In technical contexts, XRP is measured precisely to the nearest 0.000001 XRP, called a "drop" of XRP. The [`rippled` APIs](http-websocket-apis.html) require all XRP amounts to be specified in drops of XRP. For example, 1 XRP is represented as `1000000` drops. For more detailed information, see the [currency format reference](currency-formats.html).
## History
### XRP Sales
The XRP Ledger was built over 2011 – early 2012 by Jed McCaleb, Arthur Britto and David Schwartz. In September 2012, Jed and Arthur, along with Chris Larsen formed Ripple (the company, called OpenCoin Inc. at the time) and decided to gift 80 billion XRP to Ripple in exchange for Ripple developing on the XRP Ledger. Since then, the company has regularly sold XRP, used it to strengthen XRP markets and improve network liquidity, and incentivized development of the greater ecosystem. In 2017, the company [placed 55 billion XRP in escrow](https://ripple.com/insights/ripple-escrows-55-billion-xrp-for-supply-predictability/) to ensure that the amount entering the general supply [grows predictably](https://ripple.com/insights/ripple-to-place-55-billion-xrp-in-escrow-to-ensure-certainty-into-total-xrp-supply/) for the foreseeable future. Ripple's [XRP Market Performance site](https://ripple.com/xrp/market-performance/) reports how much XRP the company has available and locked in escrow at present. <!-- SPELLING_IGNORE: mccaleb, britto, opencoin -->
### Naming
Originally, the XRP Ledger was called "Ripple" for the way the technology allowed payments [to ripple through multiple hops and currencies](rippling.html). For the native asset built into the ledger, the creators chose the ticker symbol "XRP" from the term "ripple credits" or "ripples" and the X prefix for non-national currencies in the [ISO 4217 standard](https://www.iso.org/iso-4217-currency-codes.html). The company registered itself as "Ripple Labs". The name "XRP" came to be used to refer to the asset in all contexts, to avoid confusion with the similar names for the technology and company, and eventually the company shortened its own name to "Ripple". In May 2018, [the community selected a new "X" symbol](https://twitter.com/xrpsymbol/status/1006925937571713025) to represent XRP to differentiate it from the triskelion logo that had previously been used for both the company and the digital asset.
| XRP "X" Logo | Ripple triskelion |
|:---------------------------------------|:------------------------------------|
| !["X" logo](assets/img/xrp-x-logo.png) | ![Triskelion](img/ripple-triskelion.png) |
The smallest, indivisible unit of XRP was named a "drop" at the suggestion of Ripple forum member ThePiachu. An early alternative term was a "jed", after Jed McCaleb. <!-- SPELLING_IGNORE: thepiachu, mccaleb -->
## See Also
- [Send XRP (Interactive Tutorial)](send-xrp.html)
- [List XRP In Your Exchange](list-xrp-as-an-exchange.html)
- [Currency Formatting in rippled APIs](currency-formats.html#)

40
content/concepts/ledgers/ledger-close-times.md Normal file
View File

@@ -0,0 +1,40 @@
---
html: ledger-close-times.html
parent: ledgers.html
blurb: How the XRP Ledger calculates a unique close time value for each ledger version.
labels:
- Blockchain
---
# Ledger Close Times
The time that a ledger version closed is recorded at the `close_time` field of the [ledger header](ledger-header.html). To make it easier for the network to reach a consensus on an exact close time, this value is rounded to a number of seconds based on the close time resolution, currently 10 seconds. If rounding would cause a ledger's close time to be the same as (or earlier than) its parent ledger's, the child ledger has its close time set to the parent's close time plus 1. This guarantees that the close times of validated ledgers are strictly increasing. <!-- STYLE_OVERRIDE: a number of -->
Since new ledger versions usually close about every 3 to 5 seconds, these rules result in a loose pattern where ledgers' close times end in :00, :01, :02, :10, :11, :20, :21, and so on. Times ending in 2 are less common and times ending in 3 are very rare, but both occur randomly when more ledgers randomly happen to close within a 10-second window.
Generally speaking, the ledger cannot make any time-based measurements that are more precise than the close time resolution. For example, to check if an object has passed an expiration date, the rule is to compare it to the close time of the parent ledger. (The close time of a ledger is not yet known when executing transactions to go into that ledger.) This means that, for example, an [Escrow](escrow.html) could successfully finish at a real-world time that is up to about 10 seconds later than the time-based expiration specified in the Escrow object.
### Example
The following examples show the rounding behavior of ledger close times, from the perspective of an example validator, following a ledger with the close time **12:00:00**:
**Current consensus round**
1. A validator notes that it was **12:00:03** when the ledger closed and entered consensus. The validator includes this close time in its proposals.
2. The validator observes that most other validators (on its UNL) proposed a close time of 12:00:02, and one other proposed a close time of 12:00:03. It changes its proposed close time to match the consensus of **12:00:02**.
3. The validator rounds this value to the nearest close time interval, resulting in **12:00:00**.
4. Since 12:00:00 is not greater than the previous ledger's close time, the validator adjusts the close time to be exactly 1 second after the previous ledger's close time. The result is an adjusted close time of **12:00:01**.
5. The validator builds the ledger with these details, calculates the resulting hash, and confirms in the validation step that others did the same.
Non-validating servers do all the same steps, except they don't propose their recorded close times to the rest of the network.
**Next consensus round**
1. The next ledger enters consensus at **12:00:04** according to most validators.
2. This rounds down again, to a close time of **12:00:00**.
3. Since this is not greater than the previous ledger's close time of 12:00:01, the adjusted close time is **12:00:02**.
**Next consensus round after that**
1. The ledger after that enters consensus at **12:00:05** according to most validators.
2. This rounds up, based on the close time resolution, to **12:00:10**.
3. Since this value is larger than the previous ledger's close time, it does not need to be adjusted. **12:00:10** becomes the official close time.

69
content/concepts/ledgers/ledger-structure.md Normal file
View File

@@ -0,0 +1,69 @@
---
html: ledger-structure.html
parent: ledgers.html
blurb: A closer look at the elements of an individual ledger block.
---
# Ledger Structure
The XRP Ledger is a blockchain, which means it consists of a history of data blocks in sequence. A block in the XRP Ledger blockchain is called a _ledger version_ or a _ledger_ for short.
The consensus protocol takes a previous ledger version as a starting point, forms an agreement among validators on a set of transactions to apply next, then confirms that everyone got the same results from applying those transactions. When this happens successfully, the result is a new _validated_ ledger version. From there, the process repeats to build the next ledger version.
Each ledger version contains _state data_, a _transaction set_, and a _header_ containing metadata.
{{ include_svg("img/ledger.svg", "Diagram: A ledger consists of a header, transaction set, and state data.") }}
## State Data
{{ include_svg("img/ledger-state-data.svg", "Diagram: A ledger's state data, in the form of various objects which are sometimes linked like a graph.") }}
The _state data_ represents a snapshot of all accounts, balances, settings, and other information as of this ledger version. When a server connects to the network, one of the first things it does is download a full set of the current state data so that it can process new transactions and answer queries about the current state. Since every server in the network has a full copy of the state data, all data is public and every copy is equally valid.
The state data consists of individual objects called _ledger entries_, stored in a tree format. Each ledger entry has a unique 256-bit ID that you can use to look it up in the state tree.
## Transaction Set
{{ include_svg("img/ledger-transaction-set.svg", "Diagram: A ledger's transaction set, a group of transactions placed in canonical order.") }}
Every change made to the ledger is the result of a transaction. Each ledger version contains a _transaction set_ which is a group of transactions that have been newly applied in a specific order. If you take the previous ledger version's state data, and apply this ledger's transaction set on top of it, you get this ledger's state data as a result.
Every transaction in a ledger's transaction set has both of the following parts:
- _Transaction instructions_ showing what its sender told the ledger to do.
- _Transaction metadata_ showing exactly how the transaction was processed and how it affected the ledger's state data.
## Ledger Header
The _ledger header_ is a block of data that summarizes a ledger version. Like the cover of a report, it uniquely identifies the ledger version, lists its contents, and shows the time it was created, along with some other notes. The ledger header contains the following information:
<!-- Note: the alt text for the diagrams is intentionally empty because any caption would be redundant with the text. -->
- {{include_svg("img/ledger-index-icon.svg", "", classes="floating-diagram")}} The _ledger index_, which identifies the ledger version's position in the chain. It builds on the ledger with an index that is one lower, back to the starting point known as the _genesis ledger_. This forms a public history of all transactions and results.
- {{include_svg("img/ledger-hash-icon.svg", "", classes="floating-diagram")}} The _ledger hash_, which uniquely identifies the ledger's contents. The hash is calculated so that if any detail of the ledger version changes, the hash is completely different, which makes it also like a checksum that shows that none of the data in the ledger has been lost, modified, or corrupted.
- {{include_svg("img/ledger-parent-icon.svg", "", classes="floating-diagram")}} The _parent ledger hash_. A ledger version is largely defined by the difference from the _parent ledger_ that came before it, so the header also contains the unique hash of its parent ledger.
- {{include_svg("img/ledger-timestamp-icon.svg", "", classes="floating-diagram")}} The _close time_, the official timestamp when this ledger's contents were finalized. This number is rounded off by a number of seconds, usually 10.
- {{include_svg("img/ledger-state-data-hash-icon.svg", "", classes="floating-diagram")}} A _state data hash_ which acts as a checksum on this ledger's state data.
- {{include_svg("img/ledger-tx-set-hash-icon.svg", "", classes="floating-diagram")}} A _transaction set hash_ which acts as a checksum on this ledger's transaction set data.
- {{include_svg("img/ledger-notes-icon.svg", "", classes="floating-diagram")}} A few other notes like the total amount of XRP in existence and the amount the close time was rounded by.
A ledger's transaction set and state data are unlimited in size, but the ledger header is always a fixed size. For the exact data and binary format of a ledger header, see [Ledger Header](ledger-header.html).
## Validation Status
{{ include_svg("img/ledger-validated-mark.svg", "Diagram: A ledger's validation status, which is added on top of the ledger and not part of the ledger itself.") }}
When a consensus of validators in a server's Unique Node List agree on the contents of a ledger version, that ledger version is marked as validated and immutable. The ledger's contents can only change by subsequent transactions making a new ledger version, continuing the chain.
When a ledger version is first created, it is not yet validated. Due to differences in when candidate transactions arrive at different servers, the network may build and propose multiple different ledger versions to be the next step in the chain. The [consensus protocol](consensus.html) decides which one of them becomes validated. (Any candidate transactions that weren't in the validated ledger version can typically be included in the next ledger version's transaction set instead.)
## Ledger Index or Ledger Hash?
There are two different ways of identifying a ledger version: its _ledger index_ and its _ledger hash_. These two fields both identify a ledger, but they serve different purposes. The ledger index tells you the ledger's position in the chain, and the ledger hash reflects the ledger's contents.
Ledgers from different chains can have the same ledger index but different hashes. Also, when dealing with unvalidated ledger versions, there can be multiple candidate ledgers with the same index but different contents and therefore different hashes.
Two ledgers with the same ledger hash are always completely identical.

6
content/concepts/payment-system-basics/ledgers.ja.md → content/concepts/ledgers/ledgers.ja.md
View File

@@ -1,6 +1,6 @@
---
html: ledgers.html
parent: payment-system-basics.html
parent: concepts.html
blurb: XRP Ledgerは、rippledによって内部データベースに保持されている一連の個別レジャー（レジャーバージョン）で構成されています。これらのレジャーの構造と内容について説明します。
labels:
- ブロックチェーン
@@ -46,7 +46,7 @@ The `rippled` server makes a distinction between ledger versions that are _open_
Unintuitively, the XRP Ledger never "closes" an open ledger to convert it into a closed ledger. Instead, the server throws away the open ledger, creates a new closed ledger by applying transactions on top of a previous closed ledger, then creates a new open ledger using the latest closed ledger as a base. This is a consequence of [how consensus solves the double-spend problem](consensus-principles-and-rules.html#問題の単純化).
For an open ledger, servers apply transactions in the order those transactions appear, but different servers may see transactions in different orders. Since there is no central timekeeper to decide which transaction was actually first, servers may disagree on the exact order of transactions that were sent around the same time. Thus, the process for calculating a closed ledger version that is eligible for [validation](consensus.html#検証) is different than the process of building an open ledger from proposed transactions in the order they arrive. To create a "closed" ledger, each XRP Ledger server starts with a set of transactions and a previous, or "parent", ledger version. The server puts the transactions in a canonical order, then applies them to the previous ledger in that order. The canonical order is designed to be deterministic and efficient, but hard to game, to increase the difficulty of front-running Offers in the [decentralized exchange](decentralized-exchange.html).
For an open ledger, servers apply transactions in the order those transactions appear, but different servers may see transactions in different orders. Since there is no central timekeeper to decide which transaction was actually first, servers may disagree on the exact order of transactions that were sent around the same time. Thus, the process for calculating a closed ledger version that is eligible for [validation](consensus-structure.html#検証) is different than the process of building an open ledger from proposed transactions in the order they arrive. To create a "closed" ledger, each XRP Ledger server starts with a set of transactions and a previous, or "parent", ledger version. The server puts the transactions in a canonical order, then applies them to the previous ledger in that order. The canonical order is designed to be deterministic and efficient, but hard to game, to increase the difficulty of front-running Offers in the [decentralized exchange](decentralized-exchange.html).
Thus, an open ledger is only ever used as a temporary workspace, which is a major reason why transactions' [tentative results may vary from their final results](finality-of-results.html).
@@ -68,7 +68,7 @@ The following examples demonstrate the rounding behavior of ledger close times,
2. The validator observes that most other validators (on its UNL) proposed a close time of 12:00:02, and one other proposed a close time of 12:00:03. It changes its proposed close time to match the consensus of **12:00:02**.
3. The validator rounds this value to the nearest close time interval, resulting in **12:00:00**.
4. Since 12:00:00 is not greater than the previous ledger's close time, the validator adjusts the close time to be exactly 1 second after the previous ledger's close time. The result is an adjusted close time of **12:00:01**.
5. The validator builds the ledger with these details, calculates the resulting hash, and confirms in the [validation step](consensus.html#検証) that others did the same.
5. The validator builds the ledger with these details, calculates the resulting hash, and confirms in the [validation step](consensus-structure.html#検証) that others did the same.
Non-validating servers do all the same steps, except they don't propose their recorded close times to the rest of the network.

38
content/concepts/ledgers/ledgers.md Normal file
View File

@@ -0,0 +1,38 @@
---
html: ledgers.html
parent: concepts.html
blurb: Ledgers are the data structure that holds data in the shared XRP Ledger network. A chain of ledgers records the history of transactions and state changes.
labels:
- Blockchain
- Data Retention
---
# Ledgers
The XRP Ledger is a shared, global ledger that is open to all. Individual participants can trust the integrity of the ledger without having to trust any single institution to manage it. The XRP Ledger protocol accomplishes this by managing a ledger database that can only be updated according to very specific rules. Each server in the peer-to-peer network keeps a full copy of the ledger database, and the network distributes candidate transactions, which are applied in blocks according to the [consensus process](consensus.html).
{{ include_svg("img/ledger-changes.svg", "Diagram: Each ledger is the result of applying transactions to the previous ledger version.") }}
The shared global ledger consists of a series of blocks, called ledger versions or simply _ledgers_. Every ledger version has a [Ledger Index][] which identifies the correct order of ledgers. Each permanent, closed ledger also has a unique, identifying hash value.
At any given time, each XRP Ledger server has an in-progress _open_ ledger, a number of pending _closed_ ledgers, and a history of _validated_ ledgers that are immutable.
A single ledger version consists of several parts:
{{ include_svg("img/anatomy-of-a-ledger-simplified.svg", "Diagram: A ledger has transactions, a state tree, and a header with the close time and validation info") }}
* A **header** - The [Ledger Index][], hashes of its other contents, and other metadata.
* A **transaction tree** - The [transactions](transaction-formats.html) that were applied to the previous ledger to make this one.
* A **state tree** - All the data in the ledger, as [ledger entries](ledger-object-types.html): balances, settings, and so on.
## See Also
- For more information about ledger headers, ledger object IDs, and ledger object types, see [Ledger Data Formats](ledger-data-formats.html)
- For information on how servers track the history of changes to ledger state, see [Ledger History](ledger-history.html)
<!--{# common link defs #}-->
{% include '_snippets/rippled-api-links.md' %}
{% include '_snippets/tx-type-links.md' %}
{% include '_snippets/rippled_versions.md' %}

23
content/concepts/ledgers/open-closed-validated-ledgers.md Normal file
View File

@@ -0,0 +1,23 @@
---
html: open-closed-validated-ledgers.html
parent: ledgers.html
blurb: Ledger objects have one of three states — open, closed, or validated.
labels:
- Blockchain
---
## Open, Closed, and Validated Ledgers
The `rippled` server makes a distinction between ledger versions that are _open_, _closed_, and _validated_. A server has one open ledger, any number of closed but unvalidated ledgers, and an immutable history of validated ledgers. The following table summarizes the difference:
| Ledger Type: | Open | Closed | Validated |
|:---------------------------------|:----------------------------|:-------------------------------------------|:--|
| **Purpose:** | Temporary workspace | Proposed next state | Confirmed previous state |
| **Number used:** | 1 | Any number, but usually 0 or 1 | One per ledger index, growing over time |
| **Can contents change?** | Yes | No, but the whole ledger could be replaced | Never |
| **Transactions are applied in:** | The order they are received | Canonical order | Canonical order |
Unintuitively, the XRP Ledger never "closes" an open ledger to convert it into a closed ledger. Instead, the server throws away the open ledger, creates a new closed ledger by applying transactions on top of a previous closed ledger, then creates a new open ledger using the latest closed ledger as a base. This is a consequence of [how consensus solves the double-spend problem](consensus-principles-and-rules.html#simplifying-the-problem).
For an open ledger, servers apply transactions in the order those transactions appear, but different servers may see transactions in different orders. Since there is no central timekeeper to decide which transaction was actually first, servers may disagree on the exact order of transactions that were sent around the same time. Thus, the process for calculating a closed ledger version that is eligible for [validation](consensus-structure.html#validation) is different than the process of building an open ledger from proposed transactions in the order they arrive. To create a "closed" ledger, each XRP Ledger server starts with a set of transactions and a previous, or "parent", ledger version. The server puts the transactions in a canonical order, then applies them to the previous ledger in that order. The canonical order is designed to be deterministic and efficient, but hard to game, to increase the difficulty of front-running Offers in the [decentralized exchange](decentralized-exchange.html).
Thus, an open ledger is only ever used as a temporary workspace, which is a major reason why transactions' [tentative results may vary from their final results](finality-of-results.html).

2
content/concepts/consensus-network/amendments/amendments.ja.md → content/concepts/networks-and-servers/amendments.ja.md
View File

@@ -1,6 +1,6 @@
---
html: amendments.html
parent: consensus-network.html
parent: networks-and-servers.html
blurb: Amendmentはトランザクション処理の新しい機能やその他の変更を指します。バリデータはコンセンサスを通して連携し、XRP Ledgerにこれらのアップグレードを順序正しく適用します。
labels:
- ブロックチェーン

4
content/concepts/consensus-network/amendments/amendments.md → content/concepts/networks-and-servers/amendments.md
View File

@@ -1,6 +1,6 @@
---
html: amendments.html
parent: consensus-network.html
parent: networks-and-servers.html
blurb: Amendments represent new features or other changes to transaction processing. Validators coordinate through consensus to apply these upgrades to the XRP Ledger in an orderly fashion.
labels:
- Blockchain
@@ -73,7 +73,7 @@ The [XRP Ledger Standard 11d](https://github.com/XRPLF/XRPL-Standards/discussion
## See Also
- **Concepts:**
- [Introduction to Consensus](intro-to-consensus.html)
- [Consensus](consensus.html)
- **Tutorials:**
- [Run rippled as a Validator](run-rippled-as-a-validator.html)
- [Configure Amendment Voting](configure-amendment-voting.html)

2
content/concepts/xrpl-servers/clustering.ja.md → content/concepts/networks-and-servers/clustering.ja.md
View File

@@ -1,6 +1,6 @@
---
html: clustering.html
parent: xrpl-servers.html
parent: networks-and-servers.html
blurb: 暗号処理の負荷を分散させるためにクラスターでrippledサーバーを運用できます。
labels:
- コアサーバー

2
content/concepts/xrpl-servers/clustering.md → content/concepts/networks-and-servers/clustering.md
View File

@@ -1,6 +1,6 @@
---
html: clustering.html
parent: xrpl-servers.html
parent: networks-and-servers.html
blurb: Run rippled servers in a cluster to share the load of cryptography between them.
labels:
- Core Server

2
content/concepts/xrpl-servers/ledger-history/history-sharding.ja.md → content/concepts/networks-and-servers/ledger-history/history-sharding.ja.md
View File

@@ -1,6 +1,6 @@
---
html: history-sharding.html
parent: ledger-history.html
parent: data-retention.html
blurb: 履歴シャーディングは、履歴レジャーデータを保持する任務をrippledサーバー間で分担するようにします。
labels:
- データ保持

4
content/concepts/xrpl-servers/ledger-history/history-sharding.md → content/concepts/networks-and-servers/ledger-history/history-sharding.md
View File

@@ -1,6 +1,6 @@
---
html: history-sharding.html
parent: ledger-history.html
parent: data-retention.html
blurb: History sharding divides the work of keeping historical ledger data among rippled servers.
labels:
- Data Retention
@@ -37,7 +37,7 @@ History shards are recorded in a deterministic format, so that any two servers a
- **Concepts:**
- [Ledgers](ledgers.html)
- [Introduction to Consensus](intro-to-consensus.html)
- [Consensus](consensus.html)
- **Tutorials:**
- [Capacity Planning](capacity-planning.html)
- [Configure `rippled`](configure-rippled.html)

6
content/concepts/xrpl-servers/ledger-history/ledger-history.ja.md → content/concepts/networks-and-servers/ledger-history/ledger-history.ja.md
View File

@@ -1,6 +1,6 @@
---
html: ledger-history.html
parent: xrpl-servers.html
parent: networks-and-servers.html
blurb: rippledサーバーはトランザクションの変動金額と状態の履歴をローカルに保管します。
labels:
- データ保持
@@ -9,7 +9,7 @@ labels:
---
# レジャー履歴
[コンセンサスプロセス](intro-to-consensus.html)により、[検証済みレジャーバージョン](ledgers.html)のチェーンが作成されます。各バージョンは、以前のバージョンに[トランザクション](transaction-basics.html)のセットを適用して生成されます。各[`rippled`サーバー](xrpl-servers.html)には、レジャーバージョンとトランザクション履歴がローカルに保管されます。サーバーに保管されるトランザクション履歴の量は、サーバーがオンラインであった期間と、サーバーが取得し、保持する履歴量の設定に応じて異なります。
[コンセンサスプロセス](consensus.html)により、[検証済みレジャーバージョン](ledgers.html)のチェーンが作成されます。各バージョンは、以前のバージョンに[トランザクション](transactions.html)のセットを適用して生成されます。各[`rippled`サーバー](xrpl-servers.html)には、レジャーバージョンとトランザクション履歴がローカルに保管されます。サーバーに保管されるトランザクション履歴の量は、サーバーがオンラインであった期間と、サーバーが取得し、保持する履歴量の設定に応じて異なります。
ピアツーピアのXRP Ledgerネットワーク内のサーバーは、コンセンサスプロセスの一環としてトランザクションやその他のデータを相互に共有します。各サーバーは個別に新しいレジャーバージョンを作成し、その結果を信頼できるバリデータと比較して、整合性を維持します。（信頼できるバリデータのコンセンサスがサーバーの結果と一致しない場合は、サーバーがピアから必要なデータを取得して整合性を維持します。）サーバーはピアから古いデータをダウンロードして、利用可能な履歴のギャップを埋めることができます。レジャーはデータの暗号[ハッシュ](basic-data-types.html#ハッシュ)を使用した構造となっているため、すべてのサーバーがデータの整合性の検証を行えます。
@@ -65,7 +65,7 @@ XRP Ledgerのすべての履歴を1台の高価なマシンに保管する代わ
- **コンセプト:**
- [レジャー](ledgers.html)
- [コンセンサスの紹介](intro-to-consensus.html)
- [コンセンサス](consensus.html)
- **チュートリアル:**
- [`rippled`の設定](configure-rippled.html)
- [オンライン削除の設定](configure-online-deletion.html)

6
content/concepts/xrpl-servers/ledger-history/ledger-history.md → content/concepts/networks-and-servers/ledger-history/ledger-history.md
View File

@@ -1,6 +1,6 @@
---
html: ledger-history.html
parent: xrpl-servers.html
parent: networks-and-servers.html
blurb: rippled servers store a variable amount of transaction and state history locally.
labels:
- Data Retention
@@ -9,7 +9,7 @@ labels:
---
# Ledger History
The [consensus process](intro-to-consensus.html) creates a chain of [validated ledger versions](ledgers.html), each derived from the previous one by applying a set of [transactions](transaction-basics.html). Every [`rippled` server](xrpl-servers.html) stores ledger versions and transaction history locally. The amount of transaction history a server stores depends on how long that server has been online and how much history it is configured to fetch and keep.
The [consensus process](consensus.html) creates a chain of [validated ledger versions](ledgers.html), each derived from the previous one by applying a set of [transactions](transactions.html). Every [`rippled` server](xrpl-servers.html) stores ledger versions and transaction history locally. The amount of transaction history a server stores depends on how long that server has been online and how much history it is configured to fetch and keep.
Servers in the peer-to-peer XRP Ledger network share transactions and other data with each other as part of the consensus process. Each server independently builds each new ledger version and compares results with its trusted validators to ensure consistency. (If a consensus of trusted validators disagrees with a server's results, that server fetches the necessary data from its peers to achieve consistency.) Servers can download older data from their peers to fill gaps in their available history. The structure of the ledger uses cryptographic [hashes](basic-data-types.html#hashes) of the data so that any server can verify the integrity and consistency of the data.
@@ -70,7 +70,7 @@ For more information, see [Configure History Sharding](configure-history-shardin
- **Concepts:**
- [Ledgers](ledgers.html)
- [Introduction to Consensus](intro-to-consensus.html)
- [Consensus](consensus.html)
- **Tutorials:**
- [Configure `rippled`](configure-rippled.html)
- [Configure Online Deletion](configure-online-deletion.html)

2
content/concepts/xrpl-servers/ledger-history/online-deletion.ja.md → content/concepts/networks-and-servers/ledger-history/online-deletion.ja.md
View File

@@ -1,6 +1,6 @@
---
html: online-deletion.html
parent: ledger-history.html
parent: data-retention.html
blurb: オンライン削除は古いトランザクションと状態の履歴を消去します。
labels:
- データ保持

6
content/concepts/xrpl-servers/ledger-history/online-deletion.md → content/concepts/networks-and-servers/ledger-history/online-deletion.md
View File

@@ -1,13 +1,13 @@
---
html: online-deletion.html
parent: ledger-history.html
parent: data-retention.html
blurb: Online deletion purges outdated transaction and state history.
labels:
- Data Retention
- Core Server
---
# Online Deletion
[[Source]<br/>](https://github.com/ripple/rippled/blob/master/src/ripple/app/misc/SHAMapStoreImp.cpp "Source")
[[Source]](https://github.com/ripple/rippled/blob/master/src/ripple/app/misc/SHAMapStoreImp.cpp "Source")
The online deletion feature lets the `rippled` server delete the server's local copy of old ledger versions to keep disk usage from rapidly growing over time. The default config file sets online deletion to run automatically, but online deletion can also be configured to run only when prompted. [New in: rippled 0.27.0][]
@@ -119,7 +119,7 @@ When it comes time for online deletion, the server first walks through the oldes
- **Concepts:**
- [Ledgers](ledgers.html)
- [Introduction to Consensus](intro-to-consensus.html)
- [Consensus](consensus.html)
- **Tutorials:**
- [Capacity Planning](capacity-planning.html)
- [Configure `rippled`](configure-rippled.html)

3
content/concepts/xrpl-servers/xrpl-servers.ja.md → content/concepts/networks-and-servers/networks-and-servers.ja.md
View File

@@ -1,6 +1,7 @@
---
html: xrpl-servers.html
html: networks-and-servers.html
parent: concepts.html
name: Networks and Servers
blurb: rippledは、XRP Ledgerを管理するコアとなるピアツーピアサーバーです。
template: pagetype-category.html.jinja
---

4
content/concepts/xrpl-servers/xrpl-servers.md → content/concepts/networks-and-servers/networks-and-servers.md
View File

@@ -1,10 +1,10 @@
---
html: xrpl-servers.html
html: networks-and-servers.html
parent: concepts.html
blurb: rippled is the core peer-to-peer server that manages the XRP Ledger.
template: pagetype-category.html.jinja
---
# XRP Ledger Servers
# Networks and Servers
There are two main types of server software that power the XRP Ledger:

6
content/concepts/consensus-network/parallel-networks.ja.md → content/concepts/networks-and-servers/parallel-networks.ja.md
View File

@@ -1,6 +1,6 @@
---
html: parallel-networks.html
parent: consensus-network.html
parent: networks-and-servers.html
blurb: テストネットワークおよび代替レジャーチェーンと本番環境のXRP Ledgerとの関係について説明します。
labels:
- ブロックチェーン
@@ -13,7 +13,7 @@ XRP Ledgerにはピアツーピアの本番環境のネットワークが1つ存
| ネットワーク | アップグレード頻度 | 説明 |
|:--------|:----------------|:-------------------------------------------------|
| Mainnet | 安定版リリース | [XRP Ledger](xrp-ledger-overview.html)。ピアツーピアサーバーのネットワーク機能を備えた分散型の暗号台帳であり、[XRP](xrp.html)の土台となるものです。 |
| Mainnet | 安定版リリース | [XRP Ledger](xrp-ledger-overview.html)。ピアツーピアサーバーのネットワーク機能を備えた分散型の暗号台帳であり、[XRP](what-is-xrp.html)の土台となるものです。 |
| Testnet | 安定版リリース | XRP Ledger上に構築したソフトウェアのテスト環境として動作する「代替環境」のネットワーク。本番環境のXRP Ledgerユーザーに影響を及ぼすことも、本物の通貨をリスクにさらすこともありません。Testnetの[Amendmentのステータス](known-amendments.html)は、Mainnetを厳密に反映するようになっていますが、分散型システムが持つ予測不可能な性質により、タイミングにわずかな違いが生じることがあります。 |
| Devnet | ベータ版リリース | 次期リリースのプレビュー。XRP Ledgerのコアソフトウェアへの不安定な変更がテストされます。このAltNetを使用すると、開発者はまだMainnetで有効になっていないXRPLの計画段階の新機能やAmendmentを操作したり学習したりすることができます。 |
@@ -34,7 +34,7 @@ Rippleでは、TestnetとDevnetでメインサーバーを運用しています
- **ツール:**
- [XRP Testnet Faucet](xrp-test-net-faucet.html)
- **コンセプト:**
- [コンセンサスについて](intro-to-consensus.html)
- [コンセンサスについて](consensus.html)
- [Amendment](amendments.html)
- **チュートリアル:**
- [XRP Testnetへの`rippled`の接続](connect-your-rippled-to-the-xrp-test-net.html)

6
content/concepts/consensus-network/parallel-networks.md → content/concepts/networks-and-servers/parallel-networks.md
View File

@@ -1,6 +1,6 @@
---
html: parallel-networks.html
parent: consensus-network.html
parent: networks-and-servers.html
blurb: Understand how test networks and alternate ledger chains relate to the production XRP Ledger.
labels:
- Blockchain
@@ -13,7 +13,7 @@ To help members of the XRP Ledger community interact with XRP Ledger technology
| Network | Upgrade Cadence | Description |
|:--------|:----------------|:-------------------------------------------------|
| Mainnet | Stable releases | _The_ [XRP Ledger](xrp-ledger-overview.html), a decentralized cryptographic ledger powered by a network of peer-to-peer servers and the home of [XRP](xrp.html). |
| Mainnet | Stable releases | _The_ [XRP Ledger](xrp-ledger-overview.html), a decentralized cryptographic ledger powered by a network of peer-to-peer servers and the home of [XRP](what-is-xrp.html). |
| Testnet | Stable releases | An "alternate universe" network that acts as a testing ground for software built on the XRP Ledger, without impacting production XRP Ledger users and without risking real money. The [amendment status](known-amendments.html) of the Testnet is intended to closely mirror the Mainnet, although slight variations in timing may occur due to the unpredictable nature of decentralized systems. |
| Devnet | Beta releases | A preview of coming attractions, where unstable changes to the core XRP Ledger software may be tested out. Developers can use this altnet to interact with and learn about planned new XRP Ledger features and amendments that are not yet enabled on the Mainnet. |
| [Hooks V3 Testnet](https://hooks-testnet-v3.xrpl-labs.com/) | [Hooks server](https://github.com/XRPL-Labs/xrpld-hooks) | A preview of on-chain smart contract functionality using [hooks](https://xrpl-hooks.readme.io/). |
@@ -36,7 +36,7 @@ Ripple runs the main servers in the Testnet and Devnet; you can also [connect yo
- **Tools:**
- [XRP Testnet Faucet](xrp-test-net-faucet.html)
- **Concepts:**
- [Introduction to Consensus](intro-to-consensus.html)
- [Consensus](consensus.html)
- [Amendments](amendments.html)
- **Tutorials:**
- [Connect Your `rippled` to the XRP Testnet](connect-your-rippled-to-the-xrp-test-net.html)

2
content/concepts/xrpl-servers/peer-protocol.ja.md → content/concepts/networks-and-servers/peer-protocol.ja.md
View File

@@ -1,6 +1,6 @@
---
html: peer-protocol.html
parent: xrpl-servers.html
parent: networks-and-servers.html
blurb: ピアプロトコルは、rippledサーバーが互いに通信する言語を指定します。
labels:
- コアサーバー

2
content/concepts/xrpl-servers/peer-protocol.md → content/concepts/networks-and-servers/peer-protocol.md
View File

@@ -1,6 +1,6 @@
---
html: peer-protocol.html
parent: xrpl-servers.html
parent: networks-and-servers.html
blurb: The peer protocol specifies the language rippled servers speak to each other.
labels:
- Core Server

4
content/concepts/xrpl-servers/rippled-server-modes.ja.md → content/concepts/networks-and-servers/rippled-server-modes.ja.md
View File

@@ -1,6 +1,6 @@
---
html: rippled-server-modes.html
parent: xrpl-servers.html
parent: networks-and-servers.html
blurb: ストックサーバー、バリデータサーバー、スタンドアロンモードで運用されるrippledサーバーなど、rippledサーバーのモードについて説明します。
labels:
- コアサーバー
@@ -35,7 +35,7 @@ P2Pモードのサーバーは、デフォルトで[Mainnet](parallel-networks.h
### APIサーバー
全てのP2Pモードサーバーは、トランザクションの送信、残高や設定の確認、サーバーの管理などの目的で、[API](http-websocket-apis.html)を提供しています。もしあなたがXRP Ledgerにデータを照会したり、ビジネス用途でトランザクションを送信するのであれば、[独自サーバーを運営する](xrpl-servers.html#独自サーバーを運用する理由)ことが有効でしょう。
全てのP2Pモードサーバーは、トランザクションの送信、残高や設定の確認、サーバーの管理などの目的で、[API](http-websocket-apis.html)を提供しています。もしあなたがXRP Ledgerにデータを照会したり、ビジネス用途でトランザクションを送信するのであれば、[独自サーバーを運営する](networks-and-servers.html#独自サーバーを運用する理由)ことが有効でしょう。
#### 全履歴サーバー

4
content/concepts/xrpl-servers/rippled-server-modes.md → content/concepts/networks-and-servers/rippled-server-modes.md
View File

@@ -1,6 +1,6 @@
---
html: rippled-server-modes.html
parent: xrpl-servers.html
parent: networks-and-servers.html
blurb: Learn about rippled server modes, including stock servers, validator servers, and rippled servers run in stand-alone mode.
labels:
- Core Server
@@ -36,7 +36,7 @@ P2P Mode servers connect to [Mainnet](parallel-networks.html) by default.
### API Servers
All P2P Mode servers provide [APIs](http-websocket-apis.html) for purposes like submitting transactions, checking balances and settings, and administering the server. If you query the XRP Ledger for data or submit transactions for business use, it can be useful to [run your own server](xrpl-servers.html#reasons-to-run-your-own-server).
All P2P Mode servers provide [APIs](http-websocket-apis.html) for purposes like submitting transactions, checking balances and settings, and administering the server. If you query the XRP Ledger for data or submit transactions for business use, it can be useful to [run your own server](networks-and-servers.html#reasons-to-run-your-own-server).
#### Full History Servers

2
content/concepts/xrpl-servers/the-clio-server.ja.md → content/concepts/networks-and-servers/the-clio-server.ja.md
View File

@@ -1,6 +1,6 @@
---
html: the-clio-server.html
parent: xrpl-servers.html
parent: networks-and-servers.html
blurb: Clioは、API呼び出しに最適化されたXRP Ledgerサーバーです。
---
# Clioサーバー

2
content/concepts/xrpl-servers/the-clio-server.md → content/concepts/networks-and-servers/the-clio-server.md
View File

@@ -1,6 +1,6 @@
---
html: the-clio-server.html
parent: xrpl-servers.html
parent: networks-and-servers.html
blurb: Clio is an XRP Ledger server optimized for API calls.
---
# The Clio Server

4
content/concepts/xrpl-servers/transaction-censorship-detection.ja.md → content/concepts/networks-and-servers/transaction-censorship-detection.ja.md
View File

@@ -1,6 +1,6 @@
---
html: transaction-censorship-detection.html
parent: xrpl-servers.html
parent: networks-and-servers.html
blurb: XRP Ledgerでは取引検閲の自動検知機能がすべてのrippledサーバーで有効になっています。
labels:
- ブロックチェーン
@@ -11,7 +11,7 @@ labels:
XRP Ledgerは、高い検閲耐性を実現できるように設計されています。この設計をサポートするために、XRP Ledgerでは、取引検閲の自動検知機能がすべての`rippled`サーバーで有効になっており、検閲によるネットワークへの影響の有無を、すべての参加者が確認できます。
`rippled`サーバーがネットワークと同期している間、検知機能は、`rippled`サーバーの観点から、[コンセンサス](intro-to-consensus.html)の最終ラウンドで受け入れられ、最後に検証されたレジャーに取り込まれるトランザクションをすべて追跡します。検知機能では、数回のコンセンサスラウンド後、検証済みのレジャーに取り込まれていないトランザクションの重大度が高くなるというログメッセージを発行します。
`rippled`サーバーがネットワークと同期している間、検知機能は、`rippled`サーバーの観点から、[コンセンサス](consensus.html)の最終ラウンドで受け入れられ、最後に検証されたレジャーに取り込まれるトランザクションをすべて追跡します。検知機能では、数回のコンセンサスラウンド後、検証済みのレジャーに取り込まれていないトランザクションの重大度が高くなるというログメッセージを発行します。

4
content/concepts/xrpl-servers/transaction-censorship-detection.md → content/concepts/networks-and-servers/transaction-censorship-detection.md
View File

@@ -1,6 +1,6 @@
---
html: transaction-censorship-detection.html
parent: xrpl-servers.html
parent: networks-and-servers.html
blurb: XRP Ledger provides an automated transaction censorship detector that is available on all rippled servers.
labels:
- Blockchain
@@ -11,7 +11,7 @@ labels:
The XRP Ledger is designed to be censorship resistant. In support of this design, the XRP Ledger provides an automated transaction censorship detector that is available on all `rippled` servers, enabling all participants to see if censorship is affecting the network.
While a `rippled` server is in sync with the network, the detector tracks all transactions that should have been accepted in the last round of [consensus](intro-to-consensus.html) and included in the last validated ledger. The detector issues log messages of increasing severity when it sees transactions that have not been included in a validated ledger after several rounds of consensus.
While a `rippled` server is in sync with the network, the detector tracks all transactions that should have been accepted in the last round of [consensus](consensus.html) and included in the last validated ledger. The detector issues log messages of increasing severity when it sees transactions that have not been included in a validated ledger after several rounds of consensus.

186
content/concepts/payment-system-basics/accounts/accounts.md
View File

@@ -1,186 +0,0 @@
---
html: accounts.html
parent: payment-system-basics.html
blurb: Learn about accounts in the XRP Ledger. Accounts can send transactions and hold XRP.
labels:
- Accounts
- Payments
---
# Accounts
An "Account" in the XRP Ledger represents a holder of XRP and a sender of [transactions](transaction-formats.html). The core elements of an account are:
- An identifying **address**, such as `rf1BiGeXwwQoi8Z2ueFYTEXSwuJYfV2Jpn`. (This is a "classic address", as opposed to the [X-Address format](#addresses).)
- An **XRP balance**. Some of this XRP is set aside for the [Reserve](reserves.html).
- A **sequence number**, which helps make sure any transactions this account sends are applied in the correct order and only once each. To execute a transaction, the transaction's sequence number and its sender's sequence number must match. Then, as part of applying the transaction, the account's sequence number increases by 1. (See also: [Basic Data Types: Account Sequence](basic-data-types.html#account-sequence).)
- A **history of transactions** that affected this account and its balances.
- One or more ways to [authorize transactions](transaction-basics.html#authorizing-transactions), possibly including:
- A master key pair intrinsic to the account. (This can be [disabled](accountset.html) but not changed.)
- A "regular" key pair that [can be rotated](setregularkey.html).
- A signer list for [multi-signing](multi-signing.html). (Stored separately from the account's core data.)
In the ledger's data tree, an account's core data is stored in the [AccountRoot](accountroot.html) ledger object type. An account can also be the owner (or partial owner) of several other types of data.
**Tip:** An "Account" in the XRP Ledger is somewhere between the financial usage (like "bank account") and the computing usage (like "UNIX account"). Non-XRP currencies and assets aren't stored in an XRP Ledger Account itself; each such asset is stored in an accounting relationship called a "Trust Line" that connects two parties.
### Creating Accounts
There is not a dedicated "create account" transaction. The [Payment transaction][] automatically creates a new account if the payment sends XRP equal to or greater than the [account reserve](reserves.html) to a mathematically-valid address that does not already have an account. This is called _funding_ an account, and creates an [AccountRoot object](accountroot.html) in the ledger. No other transaction can create an account.
**Caution:** Funding an account **does not** give you any special privileges over that account. Whoever has the secret key corresponding to the account's address has full control over the account and all XRP it contains. For some addresses, it's possible that no one has the secret key, in which case the account is a [black hole](#special-addresses) and the XRP is lost forever.
The typical way to get an account in the XRP Ledger is as follows:
1. Generate a key pair from a strong source of randomness and calculate the address of that key pair. (For example, you can use the [wallet_propose method][] to do this.)
2. Have someone who already has an account in the XRP Ledger send XRP to the address you generated.
- For example, you can buy XRP in a private exchange, then withdraw XRP from the exchange to the address you specified.
**Caution:** The first time you receive XRP at your own XRP Ledger address, you must pay the [account reserve](reserves.html) (currently 10 XRP), which locks up that amount of XRP indefinitely. In contrast, private exchanges usually hold all their customers' XRP in a few shared XRP Ledger accounts, so customers don't have to pay the reserve for individual accounts at the exchange. Before withdrawing, consider whether having your own account directly on the XRP Ledger is worth the price.
## Addresses
{% include '_snippets/data_types/address.md' %}
Any valid address can [become an account in the XRP Ledger](#creating-accounts) by being funded. You can also use an address that has not been funded to represent a [regular key](setregularkey.html) or a member of a [signer list](multi-signing.html). Only a funded account can be the sender of a transaction.
Creating a valid address is a strictly mathematical task starting with a key pair. You can generate a key pair and calculate its address entirely offline without communicating to the XRP Ledger or any other party. The conversion from a public key to an address involves a one-way hash function, so it is possible to confirm that a public key matches an address but it is impossible to derive the public key from the address alone. (This is part of the reason why signed transactions include the public key _and_ the address of the sender.)
For more technical details of how to calculate an XRP Ledger address, see [Address Encoding](#address-encoding).
### Special Addresses
Some addresses have special meaning, or historical uses, in the XRP Ledger. In many cases, these are "black hole" addresses, meaning the address is not derived from a known secret key. Since it is effectively impossible to guess a secret key from only an address, any XRP possessed by black hole addresses is lost forever.
| Address | Name | Meaning | Black Hole? |
|-------------------------------|------|---------|-------------|
| `rrrrrrrrrrrrrrrrrrrrrhoLvTp` | ACCOUNT\_ZERO | An address that is the XRP Ledger's [base58][] encoding of the value `0`. In peer-to-peer communications, `rippled` uses this address as the issuer for XRP. | Yes |
| `rrrrrrrrrrrrrrrrrrrrBZbvji` | ACCOUNT\_ONE | An address that is the XRP Ledger's [base58][] encoding of the value `1`. In the ledger, [RippleState entries](ripplestate.html) use this address as a placeholder for the issuer of a trust line balance. | Yes |
| `rHb9CJAWyB4rj91VRWn96DkukG4bwdtyTh` | The genesis account | When `rippled` starts a new genesis ledger from scratch (for example, in stand-alone mode), this account holds all the XRP. This address is generated from the seed value `masterpassphrase` which is [hard-coded](https://github.com/ripple/rippled/blob/94ed5b3a53077d815ad0dd65d490c8d37a147361/src/ripple/app/ledger/Ledger.cpp#L184). | No |
| `rrrrrrrrrrrrrrrrrNAMEtxvNvQ` | Ripple Name reservation black-hole | In the past, Ripple asked users to send XRP to this account to reserve Ripple Names.| Yes |
| `rrrrrrrrrrrrrrrrrrrn5RM1rHd` | NaN Address | Previous versions of [ripple-lib](https://github.com/XRPLF/xrpl.js) generated this address when encoding the value [NaN](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/NaN) using the XRP Ledger's [base58][] string encoding format. | Yes |
## Deletion of Accounts
The [DeletableAccounts amendment](known-amendments.html#deletableaccounts) (enabled 2020-05-08) made it possible to delete accounts.
To be deleted, an account must meet the following requirements:
- The account's `Sequence` number plus 256 must be less than the current [Ledger Index][].
- The account must not be linked to any of the following types of [ledger objects](ledger-object-types.html) (as a sender or receiver):
- `Escrow`
- `PayChannel`
- `RippleState`
- `Check`
- The account must own fewer than 1000 objects in the ledger.
- The [AccountDelete transaction][] must pay a special [transaction cost][] equal to at least the [owner reserve](reserves.html) for one item (currently 2 XRP).
After an account has been deleted, it can be re-created in the ledger through the normal method of [creating accounts](#creating-accounts). An account that has been deleted and re-created is no different than an account that has been created for the first time.
**Warning:** The [AccountDelete transaction][]'s transaction cost always applies when the transaction is included in a validated ledger, even if the transaction failed because the account does not meet the requirements to be deleted. To greatly reduce the chances of paying the high transaction cost if the account cannot be deleted, [submit the transaction](submit.html) with `fail_hard` enabled.
Unlike Bitcoin and many other cryptocurrencies, each new version of the XRP Ledger's public ledger chain contains the full state of the ledger, which increases in size with each new account. For that reason, you should not create new XRP Ledger accounts unless necessary. You can recover some of an account's 10 XRP [reserve](reserves.html) by deleting the account, but you must still destroy at least 2 XRP to do so.
Institutions who send and receive value on behalf of many users can use [**Source Tags** and **Destination Tags**](source-and-destination-tags.html) to distinguish payments from and to their customers while only using one (or a handful) of accounts in the XRP Ledger.
## Transaction History
In the XRP Ledger, transaction history is tracked by a "thread" of transactions linked by a transaction's identifying hash and the ledger index. The `AccountRoot` ledger object has the identifying hash and ledger of the transaction that most recently modified it; the metadata of that transaction includes the previous state of the `AccountRoot` node, so it is possible to iterate through the history of a single account this way. This transaction history includes any transactions that modify the `AccountRoot` node directly, including:
- Transactions sent by the account, because they modify the account's `Sequence` number. These transactions also modify the account's XRP balance because of the [transaction cost](transaction-cost.html).
- Transactions that modified the account's XRP balance, including incoming [Payment transactions][] and other types of transactions such as [PaymentChannelClaim][] and [EscrowFinish][].
The _conceptual_ transaction history of an account also includes transactions that modified the account's owned objects and non-XRP balances. These objects are separate ledger objects, each with their own thread of transactions that affected them. If you have an account's full ledger history, you can follow it forward to find the ledger objects created or modified by it. A "complete" transaction history includes the history of objects owned by a transaction, such as:
- `RippleState` objects (Trust Lines) connected to the account.
- `DirectoryNode` objects, especially the owner directory tracking the account's owned objects.
- `Offer` objects, representing the account's outstanding currency-exchange orders in the decentralized exchange
- `PayChannel` objects, representing asynchronous payment channels to and from the account
- `Escrow` objects, representing held payments to or from the account that are locked by time or a crypto-condition.
- `SignerList` objects, representing lists of addresses that can authorize transactions for the account by [multi-signing](multi-signing.html).
For more information on each of these objects, see the [Ledger Format Reference](ledger-data-formats.html).
## Address Encoding
**Tip:** These technical details are only relevant for people building low-level library software for XRP Ledger compatibility!
[[Source]](https://github.com/ripple/rippled/blob/35fa20a110e3d43ffc1e9e664fc9017b6f2747ae/src/ripple/protocol/impl/AccountID.cpp#L109-L140 "Source")
XRP Ledger addresses are encoded using [base58][] with the _dictionary_ `rpshnaf39wBUDNEGHJKLM4PQRST7VWXYZ2bcdeCg65jkm8oFqi1tuvAxyz`. Since the XRP Ledger encodes several types of keys with base58, it prefixes the encoded data with a one-byte "type prefix" (also called a "version prefix") to distinguish them. The type prefix causes addresses to usually start with different letters in base58 format.
The following diagram shows the relationship between keys and addresses:
{{ include_svg("img/address-encoding.svg", "Master Public Key + Type Prefix → Account ID + Checksum → Address") }}
The formula for calculating an XRP Ledger address from a public key is as follows. For the complete example code, see [`encode_address.js`](https://github.com/XRPLF/xrpl-dev-portal/blob/master/content/_code-samples/address_encoding/js/encode_address.js). For the process of deriving a public key from a passphrase or seed value, see [Key Derivation](cryptographic-keys.html#key-derivation).
1. Import required algorithms: SHA-256, RIPEMD160, and base58. Set the dictionary for base58.
'use strict';
const assert = require('assert');
const crypto = require('crypto');
const R_B58_DICT = 'rpshnaf39wBUDNEGHJKLM4PQRST7VWXYZ2bcdeCg65jkm8oFqi1tuvAxyz';
const base58 = require('base-x')(R_B58_DICT);
assert(crypto.getHashes().includes('sha256'));
assert(crypto.getHashes().includes('ripemd160'));
2. Start with a 33-byte ECDSA secp256k1 public key, or a 32-byte Ed25519 public key. For Ed25519 keys, prefix the key with the byte `0xED`.
const pubkey_hex =
'ED9434799226374926EDA3B54B1B461B4ABF7237962EAE18528FEA67595397FA32';
const pubkey = Buffer.from(pubkey_hex, 'hex');
assert(pubkey.length == 33);
3. Calculate the [RIPEMD160](https://en.wikipedia.org/wiki/RIPEMD) hash of the SHA-256 hash of the public key. This value is the "Account ID".
const pubkey_inner_hash = crypto.createHash('sha256').update(pubkey);
const pubkey_outer_hash = crypto.createHash('ripemd160');
pubkey_outer_hash.update(pubkey_inner_hash.digest());
const account_id = pubkey_outer_hash.digest();
4. Calculate the SHA-256 hash of the SHA-256 hash of the Account ID; take the first 4 bytes. This value is the "checksum".
const address_type_prefix = Buffer.from([0x00]);
const payload = Buffer.concat([address_type_prefix, account_id]);
const chksum_hash1 = crypto.createHash('sha256').update(payload).digest();
const chksum_hash2 = crypto.createHash('sha256').update(chksum_hash1).digest();
const checksum = chksum_hash2.slice(0,4);
5. Concatenate the payload and the checksum. Calculate the base58 value of the concatenated buffer. The result is the address.
const dataToEncode = Buffer.concat([payload, checksum]);
const address = base58.encode(dataToEncode);
console.log(address);
// rDTXLQ7ZKZVKz33zJbHjgVShjsBnqMBhmN
## See Also
- **Concepts:**
- [Reserves](reserves.html)
- [Cryptographic Keys](cryptographic-keys.html)
- [Issuing and Operational Addresses](issuing-and-operational-addresses.html)
- **References:**
- [account_info method][]
- [wallet_propose method][]
- [AccountSet transaction][]
- [Payment transaction][]
- [AccountRoot object](accountroot.html)
- **Tutorials:**
- [Manage Account Settings (Category)](manage-account-settings.html)
- [Monitor Incoming Payments with WebSocket](monitor-incoming-payments-with-websocket.html)
<!--{# common link defs #}-->
{% include '_snippets/rippled-api-links.md' %}
{% include '_snippets/tx-type-links.md' %}
{% include '_snippets/rippled_versions.md' %}

94
content/concepts/payment-system-basics/ledgers.md
View File

@@ -1,94 +0,0 @@
---
html: ledgers.html
parent: payment-system-basics.html
blurb: The XRP Ledger is composed of a series of individual ledgers, or ledger versions, which rippled keeps in its internal database. Learn about the structure and contents of these ledgers.
labels:
- Blockchain
- Data Retention
---
# Ledgers
The XRP Ledger is a shared, global ledger that is open to all. Individual participants can trust the integrity of the ledger without having to trust any single institution to manage it. The `rippled` server software accomplishes this by managing a ledger database that can only be updated according to very specific rules. Each instance of `rippled` keeps a full copy of the ledger, and the peer-to-peer network of `rippled` servers distributes candidate transactions among themselves. The consensus process determines which transactions get applied to each new version of the ledger. See also: [The Consensus Process](consensus.html).
{{ include_svg("img/ledger-changes.svg", "Diagram: Each ledger is the result of applying transactions to the previous ledger version.") }}
The shared global ledger is actually a series of individual ledgers, or ledger versions, which `rippled` keeps in its internal database. Every ledger version has a [Ledger Index][] which identifies the order in which ledgers occur. Each closed ledger version also has an identifying hash value, which uniquely identifies the contents of that ledger. At any given time, a `rippled` instance has an in-progress "current" open ledger, plus some number of closed ledgers that have not yet been approved by consensus, and any number of historical ledgers that have been validated by consensus. Only the validated ledgers are certain to be correct and immutable.
A single ledger version consists of several parts:
{{ include_svg("img/anatomy-of-a-ledger-simplified.svg", "Diagram: A ledger has transactions, a state tree, and a header with the close time and validation info") }}
* A **header** - The [Ledger Index][], hashes of its other contents, and other metadata.
* A **transaction tree** - The [transactions](transaction-formats.html) that were applied to the previous ledger to make this one. Transactions are the _only_ way to change the ledger.
* A **state tree** - All the [ledger objects](ledger-object-types.html) that contain the settings, balances, and objects in the ledger as of this version.
## Tree Format
As its name might suggest, a ledger's state tree is a tree data structure. Each object in the state tree is identified by a 256-bit object ID. In JSON, a ledger object's ID is the `index` field, which contains a 64-character hexadecimal string like `"193C591BF62482468422313F9D3274B5927CA80B4DD3707E42015DD609E39C94"`. Every object in the state tree has an ID that you can use to look up that object; every transaction has an identifying hash that you can use to look up the transaction in the transaction tree. Do not confuse the `index` (ID) of a ledger object with the [`ledger_index` (sequence number) of a ledger][Ledger Index].
**Tip:** Sometimes, an object in the ledger's state tree is called a "ledger node". For example, transaction metadata returns a list of `AffectedNodes`. Do not confuse this with a "node" (server) in the peer-to-peer network.
In the case of transactions, the identifying hash is based on the signed transaction instructions, but the contents of the transaction object when you look it up also contain the results and metadata of the transaction, which are not taken into account when generating the hash.
## Open, Closed, and Validated Ledgers
The `rippled` server makes a distinction between ledger versions that are _open_, _closed_, and _validated_. A server has one open ledger, any number of closed but unvalidated ledgers, and an immutable history of validated ledgers. The following table summarizes the difference:
| Ledger Type: | Open | Closed | Validated |
|:---------------------------------|:----------------------------|:-------------------------------------------|:--|
| **Purpose:** | Temporary workspace | Proposed next state | Confirmed previous state |
| **Number used:** | 1 | Any number, but usually 0 or 1 | One per ledger index, growing over time |
| **Can contents change?** | Yes | No, but the whole ledger could be replaced | Never |
| **Transactions are applied in:** | The order they are received | Canonical order | Canonical order |
Unintuitively, the XRP Ledger never "closes" an open ledger to convert it into a closed ledger. Instead, the server throws away the open ledger, creates a new closed ledger by applying transactions on top of a previous closed ledger, then creates a new open ledger using the latest closed ledger as a base. This is a consequence of [how consensus solves the double-spend problem](consensus-principles-and-rules.html#simplifying-the-problem).
For an open ledger, servers apply transactions in the order those transactions appear, but different servers may see transactions in different orders. Since there is no central timekeeper to decide which transaction was actually first, servers may disagree on the exact order of transactions that were sent around the same time. Thus, the process for calculating a closed ledger version that is eligible for [validation](consensus.html#validation) is different than the process of building an open ledger from proposed transactions in the order they arrive. To create a "closed" ledger, each XRP Ledger server starts with a set of transactions and a previous, or "parent", ledger version. The server puts the transactions in a canonical order, then applies them to the previous ledger in that order. The canonical order is designed to be deterministic and efficient, but hard to game, to increase the difficulty of front-running Offers in the [decentralized exchange](decentralized-exchange.html).
Thus, an open ledger is only ever used as a temporary workspace, which is a major reason why transactions' [tentative results may vary from their final results](finality-of-results.html).
## Ledger Close Times
The time that a ledger version closed is recorded at the `close_time` field of the [ledger header](ledger-header.html). To make it easier for the network to reach a consensus on an exact close time, this value is rounded to a number of seconds based on the close time resolution, currently 10 seconds. If rounding would cause a ledger's close time to be the same as (or earlier than) its parent ledger's, the child ledger has its close time set to the parent's close time plus 1. This guarantees that the close times of validated ledgers are strictly increasing. <!-- STYLE_OVERRIDE: a number of -->
Since new ledger versions usually close about every 3 to 5 seconds, these rules result in a loose pattern where ledgers' close times end in :00, :01, :02, :10, :11, :20, :21, and so on. Times ending in 2 are less common and times ending in 3 are very rare, but both occur randomly when more ledgers randomly happen to close within a 10-second window.
Generally speaking, the ledger cannot make any time-based measurements that are more precise than the close time resolution. For example, to check if an object has passed an expiration date, the rule is to compare it to the close time of the parent ledger. (The close time of a ledger is not yet known when executing transactions to go into that ledger.) This means that, for example, an [Escrow](escrow.html) could successfully finish at a real-world time that is up to about 10 seconds later than the time-based expiration specified in the Escrow object.
### Example
The following examples show the rounding behavior of ledger close times, from the perspective of an example validator, following a ledger with the close time **12:00:00**:
**Current consensus round**
1. A validator notes that it was **12:00:03** when the ledger closed and entered consensus. The validator includes this close time in its proposals.
2. The validator observes that most other validators (on its UNL) proposed a close time of 12:00:02, and one other proposed a close time of 12:00:03. It changes its proposed close time to match the consensus of **12:00:02**.
3. The validator rounds this value to the nearest close time interval, resulting in **12:00:00**.
4. Since 12:00:00 is not greater than the previous ledger's close time, the validator adjusts the close time to be exactly 1 second after the previous ledger's close time. The result is an adjusted close time of **12:00:01**.
5. The validator builds the ledger with these details, calculates the resulting hash, and confirms in the [validation step](consensus.html#validation) that others did the same.
Non-validating servers do all the same steps, except they don't propose their recorded close times to the rest of the network.
**Next consensus round**
1. The next ledger enters consensus at **12:00:04** according to most validators.
2. This rounds down again, to a close time of **12:00:00**.
3. Since this is not greater than the previous ledger's close time of 12:00:01, the adjusted close time is **12:00:02**.
**Next consensus round after that**
1. The ledger after that enters consensus at **12:00:05** according to most validators.
2. This rounds up, based on the close time resolution, to **12:00:10**.
3. Since this value is larger than the previous ledger's close time, it does not need to be adjusted. **12:00:10** becomes the official close time.
## See Also
- For more information about ledger headers, ledger object IDs, and ledger object types, see [Ledger Data Formats](ledger-data-formats.html)
- For information on how servers track the history of changes to ledger state, see [Ledger History](ledger-history.html)
<!--{# common link defs #}-->
{% include '_snippets/rippled-api-links.md' %}
{% include '_snippets/tx-type-links.md' %}
{% include '_snippets/rippled_versions.md' %}

74
content/concepts/payment-system-basics/transaction-basics/understanding-signatures-draft.md
View File

@@ -1,74 +0,0 @@
# Understanding Signatures
***TODO: DRAFT***
***TODO: Question: Added this concept section based on fantastic source material from Rome -- thought we should publish it. Useful? May be good to associate it with a flow diagram - like the one for address encoding: https://ripple.com/build/accounts/#address-encoding. Address both single and multi-sign flows.***
In the XRP Ledger, a digital signature proves that a transaction is authorized to do a specific set of actions. A digital signature is created based on a [key pair](cryptographic-keys.html) associated with the transaction's sending account.
Here's an overview of some of the more common signature-related fields used in the XRP Ledger.
***TODO: address from Ryan: Where would you see these fields? Either address in text -- or ensure that this is answered via the flow diagram discussed below.***
***TODO: JHA fix the IA here. Also need to more clearly express the single-signer flow vs multi-signer flow. Provide a flow diagram. Also need to move some conceptual content out of "Authorizing Transactions" and "Signing and Submitting Transactions" and put it in this doc.***
## `SigningPubKey` (top-level)
The public key of the sender in hex format. Empty in the case of a multi-signed transaction.
To verify whether a single-signed transaction is valid, a `rippled` server checks that all of the following are true:
1. This key hashes to an address that's authorized by the transaction's sender.
The default is that only the address of an account is authorized to send all transactions for that account. That address is [derived from](accounts.html#address-encoding) the public key from the master key pair that was generated during address creation. Regular keys add a different address (derived from a different key pair) that's authorized to send most transactions. And of course, you can also disable the [master key](cryptographic-keys.html) or add a [multi-signing list](reference-transaction-format.html#multi-signing). ***TODO: address from Ryan: "And of course" - Nit: this seems a little informal. Maybe just drop it and go into the next sentence? JHA take a closer look at what this sentence is trying to say.***
2. This key matches the signature on the transaction.
3. The signature matches the transaction instructions.
The validation process for multi-signed transactions is slightly different. For more information, see [`Signers[*].SigningPubKey`](#signerssigningpubkey).
## `TxnSignature` (top-level)
The signature of the transaction instructions, in hex format.
Used with the `SigningPubKey` to verify that the sender did in fact approve the corresponding transaction instructions.
***TODO: Ensure that this doc reflects this: In transactions, we have two TxnSignature fields—one at the top level for single-signed transactions, and one in each member of the Signers array for multi-signed transactions. (Any given transaction has either the top level TxnSignature or the members in the Signers array but not both.)***
## `Signers` (in a multi-signed transaction)
An array of signature data for a [multi-signed transaction](reference-transaction-format.html#multi-signing).
Used to verify that a quorum of signers approved a transaction.
### `Signers[*].AccountID`
The address of one signer, in base58.
***TODO: JHA: Slightly nitpicky note (relevant to all the fields, but it especially attracted my notice here): the base58 is how it's generally represented in JSON. In the canonical binary format, I believe this is the AccountID as a 160-bit number, so it's not base58-encoded and doesn't have the checksum in the binary format. Similarly, hexadecimal is just a way of representing a 160-bit number in formats like JSON. In the native binary format, the various fields are just numbers/data in various low-level computer formats. That's only relevant for people who are trying to implement offline signing, though. Everyone else will probably see the JSON representation, where they'll want to know what the conventional way to represent the fields is.***
Identifies which signer from the (predefined) [multi-signing list](reference-transaction-format.html#multi-signing) this portion of the multi-signature represents.
### `Signers[*].TxnSignature`
One signature, as hexadecimal.
Verifying a [multi-signed transaction](reference-transaction-format.html#multi-signing) involves making sure each such signature is valid for its `SigningPubKey` and the transaction instructions.
### `Signers[*].SigningPubKey`
The public key of one signer. Verifying a [multi-signed transaction](reference-transaction-format.html#multi-signing) involves making sure each such key is authorized to sign for the `AccountID` of the signer.
Multi-signature `AccountIDs` are a little special. If one is an address that doesn't exist in the ledger, then the `SigningPubKey` must hash to the `AccountID` value using the standard rules for [deriving an AccountID](accounts.html#address-encoding) from a public key. If the address does exist in the ledger, then either:
1. The `SigningPubKey` must hash to the `AccountID` and the address must not have the master key disabled.
or
2. The `SigningPubKey` must hash to a regular key that the address has set in the ledger.
For more information about signing transactions, see [Signing and Submitting Transactions](reference-transaction-format.html#signing-and-submitting-transactions).

2
content/concepts/payment-types/checks.ja.md
View File

@@ -36,7 +36,7 @@ XRP Ledger Checksは、XRP Ledgerに固有の問題も解決できます。た
### ユースケース: 支払いの承認
**課題:** [BSA、KYC、AML、CFT](become-an-xrp-ledger-gateway.html#compliance-guidelines)などの規制に準拠するにあたり、金融機関は受領する資金の送金元に関する文書を提出する必要があります。違法な資金移動を防止するため、これらの規制は金融機関に対して、処理済のすべての支払いについて、その送金元と送金先を開示するよう義務付けています。XRP Ledgerの性質上、誰でもXRPを（および該当する場合には発行済み通貨を）XRP Ledger上の金融機関のアカウントに送金することができます。金融機関のコンプライアンス部門では、このような不審な支払いへの対応にかかるコスト（罰金の可能性を含む）の増大と処理の遅れが生じます。
**課題:** [BSA、KYC、AML、CFT](stablecoin-issuer.html#compliance-guidelines)などの規制に準拠するにあたり、金融機関は受領する資金の送金元に関する文書を提出する必要があります。違法な資金移動を防止するため、これらの規制は金融機関に対して、処理済のすべての支払いについて、その送金元と送金先を開示するよう義務付けています。XRP Ledgerの性質上、誰でもXRPを（および該当する場合には発行済み通貨を）XRP Ledger上の金融機関のアカウントに送金することができます。金融機関のコンプライアンス部門では、このような不審な支払いへの対応にかかるコスト（罰金の可能性を含む）の増大と処理の遅れが生じます。
**解決策:** 金融機関は各自のXRP Ledgerのアカウントで、[`AccountSet`トランザクションの`asfDepositAuth`フラグを設定](accountset.html)することにより、[Deposit Authorization](depositauth.html)を有効にできます。これにより、アカウントはPaymentトランザクションを受領できなくなります。Deposit Authorizationが有効なアカウントは、Escrow、Payment Channel、またはChecksでのみ資金を受領できます。Deposit Authorizationが有効な場合、Checksが最もシンプルで使いやすく、柔軟な資金移動手段となります。

82
content/concepts/payment-types/checks.md
View File

@@ -9,85 +9,35 @@ labels:
---
# Checks
_(Added by the [Checks amendment][].)_
The Checks feature enables users to create deferred payments similar to personal paper checks. Unlike an escrow or payment channel, funds aren't set aside when a check is created, so money only moves when the check is cashed. If the sender doesn't have the funds at the time a check is cashed, the transaction fails; recipients can retry failed transactions until the check expires.
The Checks feature in the XRP Ledger allows users to create deferred payments that can be canceled or cashed by the intended recipients. Like personal paper checks, XRP Ledger Checks start with the sender of the funds creating a Check that specifies an amount and a recipient. The recipient cashes the check to pull the funds from the sender's account into the recipient's account. No money moves until the recipient cashes the Check. Because funds are not put on hold when the Check is created, cashing a Check can fail if the sender doesn't have enough funds when the recipient tries to cash it. If there's a failure cashing the check, the check's recipient can retry until the Check expires.
XRP Ledger Checks can have expiration times after which they may no longer be cashed. If the recipient doesn't successfully cash the Check before it expires, the Check can no longer be cashed, but the object remains in the XRP Ledger until someone cancels it. Anyone may cancel the Check after it expires. Only the sender and recipient can cancel the Check before it expires. The Check object is removed from the Ledger when the sender successfully cashes the check or someone cancels it.
XRP Ledger Checks may have expiration times after which they may no longer be cashed. If the recipient doesn't successfully cash the Check before it expires, the Check can no longer be cashed, but the object remains in the XRP Ledger until someone cancels it. Anyone may cancel the Check after it expires. Only the sender and recipient can cancel the Check before it expires. The Check object is removed from the Ledger when the sender successfully cashes the check or someone cancels it.
## Use Cases
Checks have some similarities to [Escrow](escrow.html) and [Payment Channels](use-payment-channels.html), but there are some important differences between those features and Checks:
- Checks allow people to exchange funds using a process that is familiar to and accepted by the banking industry.
* You can send [tokens](tokens.html) with Checks. With Payment Channels and Escrow, you can only send XRP.
- If your intended recipient uses [Deposit Authorization](depositauth.html) to block direct payments from strangers, a check is a good alternative.
* Checks do not lock up or set aside any funds. The XRP involved in Payment Channels and Escrow cannot be spent until it is redeemed with a claim provided by the sender (Payment Channels), or released by an expiration or crypto-condition (Escrow).
* You can send XRP to yourself through Escrow. You cannot send Checks to yourself.
- Flexible check cashes. The recipient can redeem the Check for between a minimum and maximum amount.
**Note:** The [Checks amendment][] changes the expiration behavior of the [OfferCreate][] transaction. For more information, see [Offer Expiration](offers.html#offer-expiration).
## Check Lifecycle
1. The sender sends a [CheckCreate transaction][], which defines:
- The recipient.
- An expiration date.
- The maximum amount that can be debited from their account.
## Why Checks?
2. When the transaction is processed, the XRP Ledger creates a `Check` object. The check can be canceled by the sender or receiver with a [CheckCancel transaction][].
Traditional paper checks allow people to transfer funds without immediately exchanging physical currency. XRP Ledger Checks allow people to exchange funds asynchronously using a process that is familiar to and accepted by the banking industry.
3. The recipient submits a [CheckCash transaction][] that transfers the funds and destroys the `Check` object. Recipients have two options for cashing checks:
- Exact Amount: They specify an exact amount to cash that doesn't exceed the check maximum.
- Flexible Amount: They specify a minimum amount to cash and the XRP Ledger delivers as much as possible up to the check maximum. If the sender doesn't have the funds to at least meet the specified minimum, the transaction fails.
XRP Ledger Checks also solve a problem that is unique to the XRP Ledger: they allow users to reject unwanted payments or accept only part of a payment. This is useful for institutions that need to be careful about accepting payments for compliance reasons.
4. If the check expires before the receiver cashes the check, the `Check` object remains until anyone cancels it.
### Use Case: Payment Authorization
**Problem:** To comply with regulations like [BSA, KYC, AML, and CFT](become-an-xrp-ledger-gateway.html#compliance-guidelines), financial institutions must provide documentation about the source of funds they receive. Such regulations seek to prevent the illicit transfer of funds by requiring institutions to know the source and destination of all payments processed by the institution. Because of the nature of the XRP Ledger, anyone could potentially send XRP (and, under the right circumstances, tokens) to an institution's account on the XRP Ledger. Dealing with such unwanted payments adds significant cost and time delays to these institutions' compliance departments, including potential fines or penalties. <!-- SPELLING_IGNORE: cft -->
**Solution:** Institutions can enable [Deposit Authorization](depositauth.html) on their XRP Ledger accounts by [setting the `asfDepositAuth` flag in an `AccountSet` transaction](accountset.html). This makes the account unable to receive Payment transactions. Accounts with Deposit Authorization enabled can only receive funds through Escrow, Payment Channels, or Checks. Checks are the most straightforward, familiar, and flexible way to transfer funds if Deposit Authorization is enabled.
## Usage
Checks typically have the lifecycle described below.
<!--{# Diagram source: https://docs.google.com/drawings/d/1Ez8OZVB2TLH-b_kSFOAgfYqXlEQt4KaUBW6F3TJAv_Q/edit #}-->
[![Check flow diagram (successful cashing)](img/checks-happy-path.png)](img/checks-happy-path.png)
**Step 1:** To create a Check, the sender submits a [CheckCreate][] transaction and specifies the recipient (`Destination`), expiration time (`Expiration`), and maximum amount that may be debited from the sender's account (`SendMax`).
**Step 2:** After the CheckCreate transaction is processed, a [Check object](check.html) is created on the XRP Ledger. This object contains the properties of the Check as defined by the transaction that created it. The object can only be modified by the sender (by canceling it with a [CheckCancel][] transaction) or recipient (by canceling it or cashing it) before the expiration time passes. After the expiration time, anyone may cancel the Check.
**Step 3:** To cash the check, the recipient submits a [CheckCash][] transaction. The recipient has two options for cashing the check:
* `Amount` — The recipient can use this option to specify an exact amount to cash. This may be useful for cases where the sender has padded the check to cover possible [transfer fees](transfer-fees.html) and the recipient wants to accept the exact amount on an invoice or other contract.
* `DeliverMin` — The recipient can use this option to specify the minimum amount they are willing to receive from the Check. If the recipient uses this option, the XRP Ledger attempts to deliver as much as possible and always delivers at least this amount. The transaction fails if the amount that can be credited to the recipient is not at least the requested amount.
If the sender has enough funds to cover the Check and the expiration time has not passed, the funds are debited from the sender's account and credited to the recipient's account, and the Check object is destroyed.
#### Expiration Case
In the case of expirations, Checks have the lifecycle described below.
<!--{# Diagram source: https://docs.google.com/drawings/d/11auqa0kVUPonqlc_RaQUfHcSkUI47xneSKpwlLxzSK0/edit #}-->
[![Check flow diagram (expiration)](img/checks-expiration.png)](img/checks-expiration.png)
All Checks start the same way, so **Steps 1 and 2** are the same.
**Step 3a:** If the Check expires before the recipient can cash it, the Check can no longer be cashed but the object remains in the ledger.
**Step 4a:** After a Check expires, anyone may cancel it by submitting a [CheckCancel][] transaction. That transaction removes the Check from the ledger.
<!-- SPELLING_IGNORE: 3a, 4a -->
## Availability of Checks
The [Checks amendment][] became enabled on the XRP Ledger Mainnet on 2020-06-18. For more information about how amendments are enabled and voted on, see [Amendment Process](amendments.html#amendment-process).
To check the status of an amendment on a test network or private network, use the [feature method][].
## See Also

2
content/concepts/payment-types/cross-currency-payments.ja.md
View File

@@ -16,7 +16,7 @@ XRP Ledgerでは、1つ以上の発行済み通貨、XRP、またはその両方
## 前提条件
- 定義上、複数通貨間支払いには2種類以上の通貨が関係します。つまり、関係する通貨のうち、少なくとも1種類以上がXRP以外の発行済み通貨である必要があります。
- 通常は、[XRP Ledgerゲートウェイ](become-an-xrp-ledger-gateway.html)が発行した通貨を1種類以上使用することになります。このような通貨はXRP Ledger外部の資金を担保とし、ゲートウェイを通じて引き出すことができます。
- 通常は、[XRP Ledgerゲートウェイ](stablecoin-issuer.html)が発行した通貨を1種類以上使用することになります。このような通貨はXRP Ledger外部の資金を担保とし、ゲートウェイを通じて引き出すことができます。
- 取引を行う当事者が、XRP Ledger内でのみ発行され、外部の担保がないデジタルトークンを送受信し、何らかの価値を持つ資産として取り扱うことを望む限り、このデジタルトークンを使用することもできます。
- 送金元と受取人の間に1つ以上の[パス](paths.html)が確立しており、すべてのパスの総流動性が、支払いを促進するのに十分である必要があります。複数通貨間の支払いの場合、これは一般に通貨取引[オファー](offers.html)を消費することを意味します。

4
content/concepts/payment-types/cross-currency-payments.md
View File

@@ -8,9 +8,9 @@ labels:
---
# Cross-Currency Payments
In the XRP Ledger, you can send cross-currency payments that exchange tokens, XRP, or both. Like [direct XRP payments](use-simple-xrp-payments.html), these payments use the [Payment transaction type][Payment]. Cross-currency payments within the XRP Ledger are fully atomic, meaning that either the payment fully executes or no part of it executes.
The XRP Ledger enables you to make cross-currency payments of XRP and tokens. Cross-currency payments within the XRP Ledger are fully atomic, meaning the payment fully executes or no part of the payment executes at all.
By default, cross-currency payments deliver a fixed amount to their destination at a variable cost to their source. Cross-currency payments can also be [partial payments](partial-payments.html), which deliver a variable amount to the destination within a fixed sending limit.
By default, cross-currency payments deliver a fixed amount to their destination at a variable cost to their source. Cross-currency payments can also be [partial payments](partial-payments.html) that deliver a variable amount within a set sending limit.
## Prerequisites

2
content/concepts/payment-types/direct-xrp-payments.ja.md
View File

@@ -78,8 +78,6 @@ XRP Ledgerでは、支払いを受け取ることができるアドレスは永
## 関連項目
- **コンセプト:**
- [決済システムの基本](payment-system-basics.html)
- **チュートリアル:**
- [XRPの送金（対話型チュートリアル）](send-xrp.html)
- [WebSocketを使用した着信ペイメントの監視](monitor-incoming-payments-with-websocket.html)

79
content/concepts/payment-types/direct-xrp-payments.md
View File

@@ -8,81 +8,34 @@ labels:
---
# Direct XRP Payments
The basis of any financial system is _transferring value_: or, in one word, payments. The simplest type of payment in the XRP Ledger is a direct XRP-to-XRP payment, which transfers XRP directly from one account in the XRP Ledger to another.
## About Direct XRP-to-XRP Payments
Generally, any address in the XRP Ledger can send XRP directly to any other address. The address on the receiving side is often called the _destination address_, and the address on the sending side is called the _source address_. To send XRP directly, the sender uses a [Payment transaction][], which can be as concise as the following:
```json
{
"TransactionType": "Payment",
"Account": "rf1BiGeXwwQoi8Z2ueFYTEXSwuJYfV2Jpn",
"Destination": "ra5nK24KXen9AHvsdFTKHSANinZseWnPcX",
"Amount": "13000000"
}
```
These transaction instructions mean: Send a payment from `rf1Bi...` to `ra5nK...` delivering exactly 13 XRP. If the transaction is successfully processed, it does exactly that. Since it usually takes about 4 seconds for each new ledger version to become [validated](consensus.html), a successful transaction can be created, submitted, executed, and have a final outcome in 8 seconds or less, even if gets queued for the ledger version after the current in-progress one.
**Caution:** The [Payment transaction type][Payment] can also be used for some more specialized kinds of payments, including [cross-currency payments](cross-currency-payments.html) and [partial payments](partial-payments.html). In the case of partial payments, it is possible that the `Amount` shows a large amount of XRP even if the transaction only delivered a very small amount. See [partial payments exploit](partial-payments.html#partial-payments-exploit) for how to avoid crediting a customer for the wrong amount.
Direct XRP-to-XRP payments cannot be partial payments, but partial payments can deliver XRP after converting from a different source currency.
The basis of any financial system is transferring value. The quickest and simplest method on the XRP Ledger is a direct XRP payment from one account to another. Unlike other payment methods that require multiple transactions to complete, a direct XRP payment executes in one transaction with no intermediaries, and typically completes in 8 seconds or less. You can only make direct payments when XRP is the currency sent and received.
## Funding Accounts
Any mathematically-valid address can receive a payment, even if the XRP Ledger has no record of that address existing beforehand, as long as the payment delivers enough XRP to meet the minimum [account reserve](reserves.html). If the payment would not deliver enough XRP, it fails.
## Direct XRP Payment Lifecycle
For more information, see [Accounts](accounts.html#creating-accounts).
1. The sender creates a [Payment transaction][], which defines the parameters of the payment. The transaction is a direct XRP payment if XRP is the currency sent and received.
2. Transaction processing checks the parameters and circumstances of the transaction; if any check fails, the payment fails.
## Address Reuse
- All fields are formatted correctly.
- The sending address is a funded account in the XRP Ledger.
- All provided signatures are valid for the sending address.
- The destination address is different than the sending address.
- The sender has a high enough XRP balance to send the payment.
In the XRP Ledger, addresses where you can receive payments are permanent, and have a non-trivial [reserve requirement](reserves.html) of XRP that they cannot spend. This means that, contrary to some other blockchain systems, it is not a good idea to use a different, disposable address for every transaction. The best practice for the XRP Ledger is to reuse the same address for multiple transactions. If you use the address regularly (especially if it's managed by an internet-connected service), you should set a [regular key](cryptographic-keys.html) and proactively change keys on a regular basis to reduce the risk of a key compromise.
2. Transaction processing checks the receiving address; if any check fails, the payment fails.
As a sender, it is best not to assume that your intended recipient is using the same address from the last time you sent them a payment. Inevitably, sometimes security compromises happen and a person or business has to change addresses. Before sending money, you should ask the recipient for their current receiving address, so you don't accidentally send money to a malicious user who has taken control of a compromised old address.
## How Direct XRP Payments Are Processed
From a relatively high level, the XRP Ledger's transaction processing engine applies a direct XRP payment as follows:
1. It validates the parameters of the [Payment transaction][]. If the transaction is structured to send and deliver XRP, the transaction processing engine recognizes it as a direct XRP-to-XRP payment. Validation checks include:
- Checking that all fields are formatted correctly. For example, for direct XRP payments, the `Amount` field must be [drops of XRP][].
- Checking that the sending address is a funded [account](accounts.html) in the XRP Ledger.
- Checking that all provided signatures are valid for the sending address.
- Confirming that the destination address is different than the sender address. (It is not sufficient to send to the same address with a different [destination tag](source-and-destination-tags.html).)
- Confirming that the sender has a high enough XRP balance to send the payment.
If any check fails, the payment fails.
2. It checks whether the receiving address is a funded account.
- If the receiving address is funded, the engine checks any additional requirements for receiving payments, such as [Deposit Authorization](depositauth.html) or [`RequireDest`](source-and-destination-tags.html#requiring-tags). If the payment does not satisfy any of these additional requirements, the payment fails.
- If the receiving address is not funded, it checks whether the payment would deliver enough XRP to meet the minimum [account reserve](reserves.html). If not, the payment fails.
3. It debits the sending account by an amount of XRP specified by the `Amount` field plus the XRP to be destroyed for the [transaction cost](transaction-cost.html) and credits the receiving account for the same amount.
If necessary, it creates a new account ([AccountRoot object](accountroot.html)) for the receiving address. The new account's starting balance is equal to the `Amount` of the payment.
The engine adds a `delivered_amount` field to the [transaction's metadata](transaction-metadata.html) to indicate how much was delivered. You should always use `delivered_amount`, **not** the `Amount` field, to avoid being tricked about how much XRP you received. (Cross-currency "Partial Payments" can deliver less XRP than stated in the `Amount` field.) For more information, see [Partial Payments](partial-payments.html).
## Comparison to Other Payment Types
- **Direct XRP Payments** are the only way to both send and receive XRP in a single transaction. They are a good balance of speed, simplicity, and low cost.
- [Cross-currency payments](cross-currency-payments.html) also use the [Payment][] transaction type, but can send any combination of XRP and non-XRP [tokens](tokens.html) except XRP-to-XRP. They can also be [partial payments](partial-payments.html). Cross-currency payments are good for payments not denominated in XRP or for taking arbitrage opportunities in the [decentralized exchange](decentralized-exchange.html).
- [Checks](checks.html) let the sender set up an obligation without transferring any money immediately. The recipient can cash it any time before it expires, but the amount is not guaranteed. Checks can send either XRP or [tokens](tokens.html). Checks are good for giving the recipient the autonomy to claim the payment.
- [Escrow](escrow.html) sets aside XRP which can be claimed by its intended recipient when certain conditions are met. The XRP amount is fully guaranteed and cannot be otherwise used by the sender unless the Escrow expires. Escrow is good for smart contracts in large amounts.
- [Payment Channels](payment-channels.html) set aside XRP. The recipient can claim XRP from the channel in bulk using signed authorizations. Individual authorizations can be verified without sending a full XRP Ledger transaction. Payment channels are good for extremely high-volume micropayments or "streaming" payments.
- If the receiving address is funded, the engine makes additional checks based on their settings, such as [Deposit Authorization](depositauth.html).
- If the receiving address isn't funded, it checks if the payment will deliver enough XRP to meet the minimum [account reserve](reserves.html) requirement. If the reserve is met, a new account is created for the address and its starting balance is the amount received.
4. The ledger debits and credits the corresponding accounts.
**Note:** The sender is also debited the XRP [transaction cost](transaction-cost.html).
## See Also
- **Concepts:**
- [Payment System Basics](payment-system-basics.html)
- **Tutorials:**
- [Send XRP (Interactive Tutorial)](send-xrp.html)
- [Monitor Incoming Payments with WebSocket](monitor-incoming-payments-with-websocket.html)

110
content/concepts/payment-types/escrow.md
View File

@@ -1,60 +1,39 @@
---
html: escrow.html
parent: payment-types.html
blurb: Escrows set aside XRP and deliver it later when certain conditions are met. Escrows can depend on time limits, cryptographic conditions, or both.
blurb: Escrow holds funds until specified conditions are met.
labels:
- Escrow
- Smart Contracts
---
# Escrow
Escrow is a feature of the XRP Ledger that allows you to send conditional XRP payments. These conditional payments, called _escrows_, set aside XRP and deliver it later when certain conditions are met. Conditions to successfully finish an escrow include time-based unlocks and [crypto-conditions][]. Escrows can also be set to expire if not finished in time.
Traditionally, an escrow is a contract between two parties to facilitate financial transactions. An impartial third party receives and holds funds, and only releases them to the intended recipient when conditions specified by the contract are met. This method ensures both parties meet their obligations.
The XRP set aside in an escrow is locked up. No one can use or destroy the XRP until the escrow has been successfully finished or canceled. Before the expiration time, only the intended receiver can get the XRP. After the expiration time, the XRP can only be returned to the sender.
The XRP Ledger takes escrow a step further, replacing the third party with an automated system built into the ledger. An escrow locks up XRP, which can't be used or destroyed until conditions are met.
## Usage
## Types of Escrow
<!--{# Diagram sources: https://docs.google.com/presentation/d/1C-_TLkkoQEH7KJ6Gjwa1gO6EX17SLiJ8lxvFcAl6Rxo/ #}-->
The XRP Ledger supports three types of escrow:
[![Escrow Flow Diagram (Successful finish)](img/escrow-success-flow.png)](img/escrow-success-flow.png)
- **Time-based Escrow:** Funds only become available after a certain amount of time passes.
- **Conditional Escrow:** This escrow is created with a corresponding condition and fulfillment. The condition serves as a lock on the funds and won't release until the correct fulfillment key is provided.
- **Combination Escrow:** This escrow combines the features of time-based and conditional escrow. The escrow is completely inaccessible until the specified time passes, after which the funds can be release by providing the correct fulfillment.
**Step 1:** To send an escrow, the sender uses an [EscrowCreate transaction][] to lock up some XRP. This transaction defines a finish time, an expiration time, or both. The transaction may also define a crypto-condition that must be fulfilled to finish the escrow. This transaction must define an intended recipient for the XRP; the recipient _may_ be the same as the sender.
## Escrow Lifecycle
**Step 2:** After this transaction has been processed, the XRP Ledger has an [Escrow object](escrow-object.html) that holds the escrowed XRP. This object contains the properties of the escrow as defined by the transaction that created it. If this escrow has a finish time, no one can access the XRP before then.
1. The sender creates an escrow using the `EscrowCreate` transaction. This transaction defines:
**Step 3:** The recipient, or any other XRP Ledger address, sends an [EscrowFinish transaction][] to deliver the XRP. If the correct conditions are met, this destroys the Escrow object in the ledger and credits the XRP to the intended recipient. If the escrow has a crypto-condition, this transaction must include a fulfillment for that condition. If the escrow has an expiration time that has already passed, the EscrowFinish transaction instead fails with the code [`tecNO_PERMISSION`](tec-codes.html).
- An amount of XRP to lock up.
- The conditions to release the XRP.
- The recipient of the XRP.
### Expiration Case
2. When the transaction is processed, the XRP Ledger creates an `Escrow` object that holds the escrowed XRP.
[![Escrow Flow Diagram (Expired escrow)](img/escrow-cancel-flow.png)](img/escrow-cancel-flow.png)
3. The recipient sends an `EscrowFinish` transaction to deliver the XRP. If the conditions have been met, this destroys the `Escrow` object and delivers the XRP to the recipient.
All escrows start the same way, so **Steps 1 and 2** are the same as in the successful case.
**Note:** If the escrow has an expiration time and isn't successfully finished before then, the escrow becomes expired. An expired escrow remains in the ledger until an `EscrowCancel` transaction cancels it, destroying the `Escrow` object and returning the XRP to the sender.
**Step 3a:** If the escrow has an expiration time, and it has not been successfully finished before then, the escrow is considered expired. It continues to exist in the XRP Ledger, but can no longer successfully finish. (Expired objects remain in the ledger until a transaction modifies them. Time-based triggers cannot change the ledger contents.)
**Step 4a:** The sender, or any other XRP Ledger address, sends an [EscrowCancel transaction][] to cancel the expired escrow. This destroys the [Escrow object](escrow-object.html) in the ledger and returns the XRP to the sender.
<!-- SPELLING_IGNORE: 3a, 4a -->
## Limitations
Escrow is designed as a feature to enable the XRP Ledger to be used in the [Interledger Protocol][] and with other smart contracts. The current version has a modest scope to avoid complexity.
- Escrow only works with XRP, not tokens.
- Escrow requires sending at least two transactions: one to create the escrow, and one to finish or cancel it. Thus, it may not be financially sensible to escrow payments for very small amounts, because the participants must destroy the [transaction cost](transaction-cost.html) of the two transactions.
- When using Crypto-Conditions, the [cost of the transaction to finish the escrow](#escrowfinish-transaction-cost) is higher than usual.
- All escrows must be created with a "finish-after" time or a [crypto-condition][], or both. If the escrow does not have a finish-after time, it must have an expiration time.
**Note:** The [fix1571 amendment][] changed the requirements for creating an escrow. Escrows created before that amendment could provide an expiration time with no condition or finish-after time. Anyone can finish such escrows immediately (sending the funds to the intended recipient).
- None of the time values can be in the past when the escrow-creating transaction executes.
- Timed releases and expirations are limited to the resolution of XRP Ledger closes. This means that, in practice, times may be rounded to approximately 5 second intervals, depending on exactly when the ledgers close.
- The only supported [crypto-condition][] type is PREIMAGE-SHA-256.
Escrow provides strong guarantees that are best suited for high-value, low-quantity payments. [Payment Channels](use-payment-channels.html) are better suited for fast, low-value payments. Of course, unconditional [Payments](payment.html) are also preferable for many use cases.
## State Diagram
## Escrow States
The following diagram shows the states an Escrow can progress through:
@@ -69,25 +48,24 @@ The diagram shows three different cases for three possible combinations of the e
- **Conditional Escrow (right):** If the escrow specifies a crypto-condition (`Condition` field) and not a finish-after time, the escrow becomes **Conditionally Ready** immediately when it is created. During this time, anyone can finish the escrow, but only if they supply the correct fulfillment to the crypto-condition. If no one finishes the escrow before its expiration time (`CancelAfter` field), the escrow becomes **Expired**. (An escrow without a finish-after time _must_ have an expiration time.) In the expired state, the escrow can no longer be finished, and anyone can cancel it.
## Limitations
## Availability of Escrow
- Escrow only works with XRP, not tokens.
- The costs can make it infeasible for small amounts.
- Escrow requires two transactions: one to create the escrow, and one to finish or cancel it. Crypto-Conditions incur a higher [transaction cost](transaction-cost.html) than usual.
- While the escrow is incomplete, the sender is responsible for the [reserve requirement](reserves.html) of the `Escrow` object.
- You can't create an escrow with past time values.
- Timed releases and expirations resolve according to [ledger close times](ledger-close-times.html). In practice, actual release and expiration times can vary by about five seconds as ledgers close.
- The only supported crypto-condition type is PREIMAGE-SHA-256.
Conditional payments have been enabled by the ["Escrow" Amendment](known-amendments.html#escrow) to the XRP Ledger Consensus Protocol since 2017-03-31. A previous version of the same functionality was available on the [XRP Ledger Test Net](xrp-test-net-faucet.html) by the name "Suspended Payments" (SusPay) in 2016.
When testing in [stand-alone mode][], you can force the Escrow feature to be enabled locally regardless of the amendment status. Add the following stanza to your `rippled.cfg`:
[features]
Escrow
You can check the status of the Escrow amendment using the [feature method][].
## EscrowFinish Transaction Cost
When using [crypto-conditions][], the EscrowFinish transaction must pay a [higher transaction cost](transaction-cost.html#special-transaction-costs) because of the higher processing load involved in verifying the crypto-condition fulfillment.
When using crypto-conditions, the EscrowFinish transaction must pay a [higher transaction cost](transaction-cost.html#special-transaction-costs) because of the higher processing load involved in verifying the crypto-condition fulfillment.
If the escrow is purely time-locked with no crypto-condition, the EscrowFinish costs only the standard [transaction cost](transaction-cost.html) for a reference transaction.
The additional transaction cost required is proportional to the size of the fulfillment. If the transaction is [multi-signed](multi-signing.html), the cost of multi-signing is added to the cost of the fulfillment.
The additional transaction cost required is proportional to the size of the fulfillment. Currently, an EscrowFinish with a fulfillment requires a minimum transaction cost of **330 [drops of XRP](basic-data-types.html#specifying-currency-amounts) plus 10 drops per 16 bytes in the size of the fulfillment**. If the transaction is [multi-signed](multi-signing.html), the cost of multi-signing is added to the cost of the fulfillment.
Currently, an EscrowFinish with a fulfillment requires a minimum transaction cost of **330 [drops of XRP](basic-data-types.html#specifying-currency-amounts) plus 10 drops per 16 bytes in the size of the fulfillment**.
**Note:** The above formula is based on the assumption that the reference cost of a transaction is 10 drops of XRP.
@@ -98,43 +76,12 @@ reference_fee * (signer_count + 33 + (fulfillment_bytes / 16))
```
## Why Escrow?
The age-old practice of [Escrow](https://en.wikipedia.org/wiki/Escrow) enables many kinds of financial transactions that would be considered risky otherwise, especially online. By letting a trusted third party hold the money while a transaction or evaluation period is underway, both sides can be assured that the other must hold up their end of the bargain.
The Escrow feature takes this idea further by replacing the third party with an automated system built into the XRP Ledger, so that the lock up and release of funds is impartial and can be automated.
Fully automated escrow, backed by the integrity of the XRP Ledger itself, solves important problems for Ripple, and we think there are many other use cases that escrow enables. Ripple encourages the industry to find new and unique ways to put escrow to use.
### Use Case: Time-based Lock-Up
**Background:** Ripple holds a large amount of the total XRP, which it sells methodically as a way to fund and incentivize the healthy development of the XRP Ledger and related technologies. At the same time, owning such a large chunk of XRP causes problems for the company, such as:
- Individuals and businesses who use the XRP Ledger worry that their investments in XRP could be diluted or devalued if Ripple were to flood the market by selling at a higher rate than usual.
- Although flooding the market would be a long-term loss for Ripple, the possibility that the company could do so exerts downward pressure over the price of XRP, and thus decreases the value of the company's assets.
- Ripple must carefully manage ownership of its accounts to protect against digital theft and other forms of malicious behavior, even by insiders.
**Solution:** By placing 55 billion XRP into time-based escrows, Ripple ensures that the supply of XRP in circulation is predictable and increases at a slow but steady rate. Others who hold XRP know that Ripple cannot flood the market, even if the company's priorities or strategy changes.
Placing the money into escrow does not directly protect Ripple's holdings from malicious actors, but it sharply reduces the amount of XRP that can be quickly stolen or redirected if a malicious actor gains temporary control over Ripple's XRP accounts. This reduces the risk of catastrophic losses of XRP and increases the time for Ripple to detect, prevent, and track down unintended uses of Ripple's XRP assets.
### Use Case: Interledger Payments
**Background:** In the quickly-developing world of financial technology, one of the core challenges is coordinating activities that cross multiple digital money systems, or ledgers. Many proposed solutions to this problem (including early views of the XRP Ledger!) can be reduced to creating "one ledger to rule them all." Ripple believes no single system can meet the needs of everyone in the world: in fact, some desirable features are mutually exclusive. Instead, Ripple believes that an interconnected network of ledgers—an _interledger_—is the true future of financial technology. The [Interledger Protocol][] defines standards for making as many systems as possible connect securely and smoothly.
The most fundamental principle of inter-ledger payments is _conditional transfers_. Multi-hop payments have a risk problem: the more hops in the middle, the more places the payment can fail. Interledger solves this with the financial equivalent of a "[two-phase commit](https://en.wikipedia.org/wiki/Two-phase_commit_protocol)", where the two steps are (1) prepare conditional transfers, then (2) fulfill the conditions to execute the transfers. The Interledger project defined a [crypto-conditions][] specification to standardize automated ways to define and verify conditions, and settled on SHA-256 hashes as a "common denominator" of such conditions.
**Solution:** The Escrow feature makes the XRP Ledger ideal for bridging multi-hop payments using the Interledger Protocol, because it natively supports transfers that deliver XRP based on PREIMAGE-SHA-256 crypto-conditions, and it executes those transfers within seconds of being presented with the matching fulfillment.
## See Also
For more information about Escrow in the XRP Ledger, see the following:
- [Escrow Tutorials](use-escrows.html)
- [Send a Time-Held Escrow](send-a-time-held-escrow.html)
- [Send a conditionally-held escrow](send-a-conditionally-held-escrow.html)
- [Look up escrows by sender or receiver](look-up-escrows.html)
- [Transaction Reference](transaction-formats.html)
- [EscrowCreate transaction][]
- [EscrowFinish transaction][]
@@ -142,7 +89,6 @@ For more information about Escrow in the XRP Ledger, see the following:
- [Ledger Reference](ledger-data-formats.html)
- [Escrow object](escrow-object.html)
For more information on Interledger and how conditional transfers enable secure payments across multiple ledgers, see [Interledger Architecture](https://interledger.org/rfcs/0001-interledger-architecture/).
For more information on Ripple's 55-billion XRP lock-up, see [Ripple's Insights Blog](https://ripple.com/insights/ripple-to-place-55-billion-xrp-in-escrow-to-ensure-certainty-into-total-xrp-supply/).

2
content/concepts/payment-types/partial-payments.ja.md
View File

@@ -8,7 +8,7 @@ labels:
---
# Partial Payment
デフォルトのケースでは、XRP Ledgerの[Paymentトランザクション][]の`Amount`フィールドに、為替レートと[送金手数料](transfer-fees.html)を差し引いた実際の送金額が指定されます。「Partial Payment」フラグ（[**tfPartialPayment**](payment.html#paymentのフラグ)）を使うと、送金額を増額する代わりに受取金額を減額して、支払を正常に実行できます。Partial Paymentは、追加コストなしで[支払を返金](become-an-xrp-ledger-gateway.html#bouncing-payments)したい場合に便利です。
デフォルトのケースでは、XRP Ledgerの[Paymentトランザクション][]の`Amount`フィールドに、為替レートと[送金手数料](transfer-fees.html)を差し引いた実際の送金額が指定されます。「Partial Payment」フラグ（[**tfPartialPayment**](payment.html#paymentのフラグ)）を使うと、送金額を増額する代わりに受取金額を減額して、支払を正常に実行できます。Partial Paymentは、追加コストなしで[支払を返金](stablecoin-issuer.html#bouncing-payments)したい場合に便利です。
[トランザクションコスト](transaction-cost.html)に使用されるXRPの額は、トランザクションタイプに関わらず常に送金元のアカウントから差し引かれます。

8
content/concepts/payment-types/partial-payments.md
View File

@@ -10,7 +10,7 @@ labels:
The sender of any [Payment transaction][] can enable the ["Partial Payment" flag](payment.html#payment-flags) and send a payment which delivers less than the `Amount` field indicates. When processing any Payment, use the `delivered_amount` metadata field, not the `Amount` field. The `delivered_amount` is the amount a payment actually delivered.
If a Payment does not enable the Partial Payment flag, the `Amount` field of a [Payment transaction][] in the XRP Ledger specifies the amount to deliver after charging for exchange rates and [transfer fees](transfer-fees.html). The Partial Payment flag ([`tfPartialPayment`](payment.html#payment-flags)) allows a payment to succeed by reducing the amount received instead of increasing the amount sent. Partial payments are useful for [returning payments](become-an-xrp-ledger-gateway.html#bouncing-payments) without incurring additional costs to oneself.
If a Payment does not enable the Partial Payment flag, the `Amount` field of a [Payment transaction][] in the XRP Ledger specifies the amount to deliver after charging for exchange rates and [transfer fees](transfer-fees.html). The Partial Payment flag ([`tfPartialPayment`](payment.html#payment-flags)) allows a payment to succeed by reducing the amount received instead of increasing the amount sent. Partial payments are useful for [returning payments](stablecoin-issuer.html#bouncing-payments) without incurring additional costs to oneself.
The amount of XRP used for the [transaction cost](transaction-cost.html) is always deducted from the sender’s account, regardless of the type of transaction. This transaction cost, or fee, is not included in the `Amount`.
@@ -120,7 +120,7 @@ Using [the `delivered_amount` field](#the-delivered_amount-field) when processin
- **Tools:**
- [Transaction Sender](tx-sender.html)
- **Concepts:**
- [Transaction Basics](transaction-basics.html)
- [Transactions](transactions.html)
- **Tutorials:**
- [Look Up Transaction Results](look-up-transaction-results.html)
- [Monitor Incoming Payments with WebSocket](monitor-incoming-payments-with-websocket.html)
@@ -133,6 +133,6 @@ Using [the `delivered_amount` field](#the-delivered_amount-field) when processin
- [tx method][]
<!--{# common link defs #}-->
{% include '_snippets/rippled-api-links.md' %}
{% include '_snippets/tx-type-links.md' %}
{% include '_snippets/rippled-api-links.md' %}
{% include '_snippets/tx-type-links.md' %}
{% include '_snippets/rippled_versions.md' %}

4
content/concepts/tokens/authorized-trust-lines.ja.md
View File

@@ -30,7 +30,7 @@ XRP Ledger上のステーブルコインと認可トラストラインの使用
**ヒント:** 2つのTrustSetトランザクション（ステップ3および4）は、どちらの順序で発生しても構いません。発行者がトラストラインを先に認可した場合、これにより限度額が0に設定されたトラストラインが作成され、顧客のTrustSetトランザクションは、事前に認可されたトラストラインの限度額を設定することになります。([TrustSetAuth amendment][]によって追加されました。)_
## 注意事項
認可トラストラインを使用するつもりがない場合でも、[運用アカウントと予備アカウント](issuing-and-operational-addresses.html)のRequire Auth設定を有効にし、これらのアカウントにトラストラインを認可させないようにすることができます。これは、これらのアカウントが誤ってトークンを発行することを防止します（たとえば、ユーザーが誤って間違ったアドレスをトラストしてしまった場合など）。これはあくまで予防措置であり、運用アカウントと予備アカウントが意図したとおりに _発行者の_ トークンを転送することを止めるものではありません。
認可トラストラインを使用するつもりがない場合でも、[運用アカウントと予備アカウント](account-types.html)のRequire Auth設定を有効にし、これらのアカウントにトラストラインを認可させないようにすることができます。これは、これらのアカウントが誤ってトークンを発行することを防止します（たとえば、ユーザーが誤って間違ったアドレスをトラストしてしまった場合など）。これはあくまで予防措置であり、運用アカウントと予備アカウントが意図したとおりに _発行者の_ トークンを転送することを止めるものではありません。
## 技術情報
<!--{# TODO: split these off into one or more tutorials on using authorized trust lines, preferably with both JavaScript and Python code samples. #}-->
@@ -116,8 +116,6 @@ POST http://localhost:8088/
- **コンセプト:**
- [Deposit Authorization](depositauth.html)
- [トークンの凍結](freezes.html)
- **チュートリアル:**
- [ステーブルコインを発行する](become-an-xrp-ledger-gateway.html)
- **リファレンス:**
- [account_linesメソッド][]
- [account_infoメソッド][]

6
content/concepts/tokens/authorized-trust-lines.md
View File

@@ -27,11 +27,11 @@ With a stablecoin on the XRP Ledger and use Authorized Trust Lines, the process
3. The customer sends a [TrustSet transaction][] to create a trust line to the issuer's address, with a positive limit.
4. The issuer sends a TrustSet transaction to authorize the customer's trust line.
**Tip:** The two TrustSet transactions (steps 3 and 4) can occur in either order. If the issuer authorizes the trust line first, this creates a trust line with the limit set to 0, and the customer's TrustSet transaction sets the limit on the pre-authorized trust line. _(Added by the [TrustSetAuth amendment][].)_
**Tip:** The two TrustSet transactions (steps 3 and 4) can occur in either order. If the issuer authorizes the trust line first, this creates a trust line with the limit set to 0, and the customer's TrustSet transaction sets the limit on the pre-authorized trust line.
## As a Precaution
Even if you don't intend to use Authorized Trust Lines, you can enable the Require Auth setting on [operational and standby accounts](issuing-and-operational-addresses.html), and then never have those accounts approve any trust lines. This prevents those accounts from issuing tokens by accident (for example, if a user accidentally trusts the wrong address). This is only a precaution, and does not stop the operational and standby accounts from transferring the _issuer's_ tokens, as intended.
Even if you don't intend to use Authorized Trust Lines, you can enable the Require Auth setting on [operational and standby accounts](account-types.html), and then never have those accounts approve any trust lines. This prevents those accounts from issuing tokens by accident (for example, if a user accidentally trusts the wrong address). This is only a precaution, and does not stop the operational and standby accounts from transferring the _issuer's_ tokens, as intended.
## Technical Details
@@ -120,8 +120,6 @@ In the response's `result.lines` array, find the object whose `currency` field i
- **Concepts:**
- [Deposit Authorization](depositauth.html)
- [Freezing Issued Currencies](freezes.html)
- **Tutorials:**
- [Become a Stablecoin Issuer](become-an-xrp-ledger-gateway.html)
- **References:**
- [account_lines method][]
- [account_info method][]

2
content/concepts/decentralized-exchange/autobridging.ja.md → content/concepts/tokens/autobridging.ja.md
View File

@@ -8,7 +8,7 @@ labels:
---
# オートブリッジング
XRP Ledgerの[分散型取引所](decentralized-exchange.html)で、XRP以外の2種類の通貨を交換する[オファー](offers.html)があった場合、合成されたオーダーブックで[XRP](xrp.html)が中間通貨として使用されることがあります。これは _オートブリッジング_ によるものです。この機能は、通貨を直接交換するよりも安く済む場合にXRPを使用し、あらゆる通貨ペアの流動性を向上させる役割を担います。XRP Ledgerのネイティブ暗号資産であるというXRPの特性によりこのように機能します。オファーを実行する際は、直接オファーとオートブリッジングオファーを組み合わせることで全体として最良の為替レートを実現できます。
XRP Ledgerの[分散型取引所](decentralized-exchange.html)で、XRP以外の2種類の通貨を交換する[オファー](offers.html)があった場合、合成されたオーダーブックで[XRP](what-is-xrp.html)が中間通貨として使用されることがあります。これは _オートブリッジング_ によるものです。この機能は、通貨を直接交換するよりも安く済む場合にXRPを使用し、あらゆる通貨ペアの流動性を向上させる役割を担います。XRP Ledgerのネイティブ暗号資産であるというXRPの特性によりこのように機能します。オファーを実行する際は、直接オファーとオートブリッジングオファーを組み合わせることで全体として最良の為替レートを実現できます。
例: _AnitaはGBPを売却してBRLを購入するオファーを発行しました。このような一般的ではない通貨マーケットでは、オファーがあまりない場合があります。良いレートのオファーが1件ありますが、Anitaの取引を満たすのに十分な量ではありません。ただしGBPとXRPおよびBRLとXRPの間には、それぞれアクティブで競争力のあるマーケットが存在します。XRP Ledgerのオートブリッジングシステムは、あるトレーダーからXRPをGBPで購入し、そのXRPを別のトレーダーに支払ってBRLを購入することで、Anitaのオファーを履行できる方法を見つけます。AnitaはGBPとBRLを直接交換するマーケットでの少額オファーを、GBP対XRPのオファーとXRP対BRLのオファーをペアリングしてより良い複合レートと組み合わせて、最適なレートを自動的に得ることができます。_

29
content/concepts/tokens/autobridging.md Normal file
View File

@@ -0,0 +1,29 @@
---
html: autobridging.html
parent: decentralized-exchange.html
blurb: Autobriding automatically connects order books using XRP as an intermediary when it reduces costs.
labels:
- XRP
- Decentralized Exchange
---
# Auto-Bridging
Any [Offer](offers.html) in the XRP Ledger's [decentralized exchange](decentralized-exchange.html) that would exchange two tokens could potentially use XRP as an intermediary currency in a synthetic order book. This is because of _auto-bridging_, which serves to improve liquidity across all asset pairs by using XRP when doing so is cheaper than trading directly. This works because of XRP's nature as a native cryptocurrency to the XRP Ledger. Offer execution can use a combination of direct and auto-bridged offers to achieve the best total exchange rate.
Example: _Anita places an offer to sell GBP and buy BRL. She might find that this uncommon market has few offers. There is one offer with a good rate, but it has insufficient quantity to satisfy Anita's trade. However, both GBP and BRL have active, competitive markets to XRP. The XRP Ledger's auto-bridging system finds a way to complete Anita's offer by purchasing XRP with GBP from one trader, then selling the XRP to another trader to buy BRL. Anita automatically gets the best rate possible by combining the small offer in the direct GBP:BRL market with the better composite rates created by pairing GBP:XRP and XRP:BRL offers._ <!-- SPELLING_IGNORE: gbp -->
Auto-bridging happens automatically on any [OfferCreate transaction][]. [Payment transactions](payment.html) _do not_ use auto-bridging by default, but path-finding can find [paths](paths.html) that have the same effect.
## See Also
- [Dev Blog: Introducing Autobridging](https://xrpl.org/blog/2014/introducing-offer-autobridging.html) <!-- SPELLING_IGNORE: autobridging -->
- [Offer Preference](offers.html#offer-preference)
- [Payment Paths](paths.html)
<!--{# common link defs #}-->
{% include '_snippets/rippled-api-links.md' %}
{% include '_snippets/tx-type-links.md' %}
{% include '_snippets/rippled_versions.md' %}

4
content/concepts/decentralized-exchange/decentralized-exchange.ja.md → content/concepts/tokens/decentralized-exchange.ja.md
View File

@@ -1,6 +1,6 @@
---
html: decentralized-exchange.html
parent: concepts.html
parent: tokens.html
template: pagetype-category.html.jinja
blurb: XRP Ledgerには多機能な取引所が含まれており、この取引所を利用してユーザーはトークンをXRPに、あるいはXRPをトークンにに交換できます。
---
@@ -14,7 +14,7 @@ XRP Ledgerには、世界でおそらく最も古い _分散型取引所_ (「DE
XRP Ledgerの分散型取引所は、無制限の通貨ペアで構成されており、ユーザーが取引を行う際にオンデマンドで追跡されます。通貨ペアは、XRPとトークン、または2つの異なるトークンから構成されます。トークンは常に、発行者と通貨コードの組み合わせによって識別されます。同じ通貨コードで異なる発行者のトークン同士、または同じ発行者で異なる通貨コードのトークン同士の取引も可能です。
XRP Ledgerのすべての変更がそうであるように、取引を行うには[トランザクション](transaction-basics.html)を送信する必要があります。XRP Ledgerにおける取引は、[オファー](offers.html)と呼ばれています。オファーは事実上、ある通貨(XRPまたはトークン)を特定の金額で他の通貨と売買するための[_指値注文_](https://ja.wikipedia.org/wiki/%E3%83%AA%E3%83%9F%E3%83%83%E3%83%88%E3%82%AA%E3%83%BC%E3%83%80%E3%83%BC)です。ネットワークがオファーを実行する際、同じ通貨ペアでマッチングするオファーがあれば、最も良い取引レートから順に約定されます。
XRP Ledgerのすべての変更がそうであるように、取引を行うには[トランザクション](transactions.html)を送信する必要があります。XRP Ledgerにおける取引は、[オファー](offers.html)と呼ばれています。オファーは事実上、ある通貨(XRPまたはトークン)を特定の金額で他の通貨と売買するための[_指値注文_](https://ja.wikipedia.org/wiki/%E3%83%AA%E3%83%9F%E3%83%83%E3%83%88%E3%82%AA%E3%83%BC%E3%83%80%E3%83%BC)です。ネットワークがオファーを実行する際、同じ通貨ペアでマッチングするオファーがあれば、最も良い取引レートから順に約定されます。
オファーは、全額または一部が約定されることがあります。すぐに全額が約定されなかった場合は、残りの金額は台帳上のOfferオブジェクトとなります。その後、他のオファーや[クロスカレンシー支払い](cross-currency-payments.html)がオファーにマッチし、約定する可能性があります。このため、Offerは最初に注文したときは指定した取引レートよりも高いレートで約定し、後で注文したときは指定した取引レートと全く同じレートで約定することがあります。（端数処理のためのわずかな差は除きます）

4
content/concepts/decentralized-exchange/decentralized-exchange.md → content/concepts/tokens/decentralized-exchange.md
View File

@@ -1,6 +1,6 @@
---
html: decentralized-exchange.html
parent: concepts.html
parent: tokens.html
template: pagetype-category.html.jinja
blurb: The XRP Ledger contains a fully-functional exchange where users can trade tokens for XRP or each other.
targets:
@@ -16,7 +16,7 @@ The XRP Ledger has possibly the world's oldest _decentralized exchange_ (sometim
The XRP Ledger's decentralized exchange consists of an unlimited number of currency pairs, tracked on-demand when users make trades. A currency pair can consist of XRP and a token or two different tokens; tokens are always identified by the combination of an issuer and a currency code. It is possible to trade between two tokens with the same currency code and different issuers, or the same issuer and different currency codes. <!-- STYLE_OVERRIDE: limited number -->
As with all changes to the XRP Ledger, you need to send a [transaction](transaction-basics.html) to make a trade. A trade in the XRP Ledger is called an [Offer](offers.html). An Offer is effectively a [_limit order_](https://en.wikipedia.org/wiki/Order_(exchange)#Limit_order) to buy or sell a specific amount of one currency (XRP or a token) for a specific amount of another. When the network executes an Offer, if there are any matching Offers for the same currency pair, they are consumed starting with the best exchange rate first.
As with all changes to the XRP Ledger, you need to send a [transaction](transactions.html) to make a trade. A trade in the XRP Ledger is called an [Offer](offers.html). An Offer is effectively a [_limit order_](https://en.wikipedia.org/wiki/Order_(exchange)#Limit_order) to buy or sell a specific amount of one currency (XRP or a token) for a specific amount of another. When the network executes an Offer, if there are any matching Offers for the same currency pair, they are consumed starting with the best exchange rate first.
An Offer can be fully or partially filled; if it's not fully filled right away, it becomes a passive Offer object in the ledger for the remaining amount. Later on, other Offers or [Cross-currency payments](cross-currency-payments.html) can match and consume the Offer. Because of this, Offers can execute at better than their requested exchange rate when initially placed, or at exactly their stated exchange rate later on (aside from minor differences to account for rounding).

Some files were not shown because too many files have changed in this diff Show More