mirror of
https://github.com/XRPLF/xrpl-dev-portal.git
synced 2025-11-23 05:05:50 +00:00
Merge commit '6e7a8b8ad389845d792b6798bf7b8ddebb7b540c' into ja-multisig
This commit is contained in:
tequ
@@ -1,88 +0,0 @@
|
||||
---
|
||||
html: federated-sidechains.html
|
||||
parent: consensus-network.html
|
||||
blurb: サイドチェーンとXRP Ledgerの間で、XRPやその他のトークン（IOU）の形で価値を効率的に移動させることができる、フェデレーションサイドチェーンについてご紹介します。
|
||||
labels:
|
||||
- ブロックチェーン
|
||||
---
|
||||
# フェデレーションサイドチェーン
|
||||
|
||||
_フェデレーションサイドチェーンは開発者プレビューとして提供されており、`rippled` 1.8.0を使った開発やテストに使用することができます。_
|
||||
|
||||
サイドチェーンとは、独自のコンセンサスアルゴリズムと取引の種類やルールを持つ独立した台帳のことです。独自のブロックチェーンとして機能します。フェデレーションは、XRPや他のトークンの形で、サイドチェーンとXRP Ledger _メインチェーン_（通常はMainnetですが、テスト用に[Testnet or Devnet](parallel-networks.html)にすることもできます）の間で、価値を効率的に移動させることができます。フェデレーションサイドチェーンは、公開メインネットのスピード、効率、スループットを損なうことなく動作します。
|
||||
|
||||
フェデレーションサイドチェーンにより、開発者はXRP Ledger技術の基盤を使って新機能や革新的なアプリケーションを立ち上げることができます。サイドチェーンは、特定のユースケースやプロジェクトのニーズに合わせてXRP Ledgerのプロトコルをカスタマイズし、独自のブロックチェーンとして運用することができます。いくつかの例をご紹介します。
|
||||
|
||||
* Ethereum Virtual Machine (EVM)、Web Assembly、またはMove VMと互換性のあるエンジンを搭載した、スマートコントラクトレイヤーの構築。例えば、[smart sidechain with Hooks](https://hooks-testnet.xrpl-labs.com/)を有効にする等。
|
||||
* 台帳の種類や取引ルールをカスタマイズした独自のアルゴリズムでのステーブルコインの構築。
|
||||
* Mainnetの[分散型取引所](decentralized-exchange.html)で取引することが可能な資産を持つ、許可制またはほぼ無許可、中央集権型または大部分が分散型の台帳の構築。
|
||||
|
||||
## フェデレーションサイドチェーンのしくみ
|
||||
|
||||
サイドチェーンは、独自のコンセンサス・アルゴリズムや取引の種類・ルールを持つ独立した台帳です。各サイドチェーンは独自のサーバーセット(バリデータを含む)によって運営されており、サイドチェーン上の取引についてはMainnet上のバリデータに依存しません。
|
||||
|
||||
各サイドチェーンには、サイドチェーン上とメインチェーン上の2つのドアアカウントがあり、サイドチェーン上のフェデレータが管理しています。フェデレータは、この両方のドアアカウントとの間のトランザクションを監視します。
|
||||
|
||||
サイドチェーンには、両ネットワークのドア・アカウントを共同で管理する _フェデレータ_ がおり、[マルチサイン](multi-signing.html)を用いて、フェデレータの80%が取引を承認しなければなりません。多くの場合、フェデレータはサイドチェーンの信頼できる検証者でもあるべきです。
|
||||
|
||||
ドアアカウントがサイドチェーンまたはメインチェーンのいずれかでトランザクションを受け取ると、フェデレータは他のチェーンでミラートランザクションを作成します。(例えば、メインチェーンの _ドアアカウントにXRPを送信_ した場合、フェデレータはサイドチェーンのドアアカウントからXRPを _目的の受信者に送信_ するために、サイドチェーンでトランザクションを作成します) フェデレータはそのトランザクションに署名し、お互いにブロードキャストします。同時に、フェデレータは他のフェデレータからの署名付きトランザクションをリッスンし、それを収集します。
|
||||
|
||||
フェデレータの80％がトランザクションに署名したら、それを適宜サイドチェーンまたはメインチェーンに提出します。こうすることで、メインチェーンのドアアカウントが持つ資産をサイドチェーンの他の人に割り当てたり、サイドチェーンのドアアカウントが受け取る資産をメインチェーンの他の人に送ったりすることができます。
|
||||
|
||||
サイドチェーン内の取引は、サイドチェーン上のサーバーからは見えません。
|
||||
|
||||
|
||||
## 用語解説
|
||||
|
||||
_サイドチェーン_: XRP Ledgerのサイドチェーンとは、XRP Ledgerの技術をベースにした別のブロックチェーンのことです。_フェデレーター_ サイドチェーンは、メインチェーンからサイドチェーンへの資産移転の手段を提供します。サイドチェーンは、XRP Ledgerのプロトコルの完全なコピーを使用することもできますし、[コンセンサス・アルゴリズム](consensus.html)、[トランザクション・タイプ](transaction-types.html)、その他のルールを含む変更を加えることもできます。
|
||||
|
||||
_フェデレーター_: サイドチェーン上のサーバーで、メインチェーンとサイドチェーンの両方のトランザクションのトリガーをリッスンします。各フェデレーターは、トランザクションの署名に使用される署名鍵を持っています。トランザクションを送信するには、フェデレータの定足数による署名が必要です。フェデレータは、有効なレスポンス・トランザクションの作成と署名、他のフェデレータからの署名の収集、メイン・チェーンとサイド・チェーンへのトランザクションの送信に責任を負います。
|
||||
|
||||
_メインチェーン_: 資産が生まれるブロックチェーンで、サイドチェーンで使用されている間、資産が保持される場所。ほとんどのサイドチェーンでは、メインチェーンはXRP Ledger Mainnet、Testnet、またはDevnetとなっています。
|
||||
|
||||
_サイドチェーン_: 一部の資産がメインチェーンに裏付けられているカスタムブロックチェーンです。代理資産はサイドチェーンで発行され、同等の資産はメインチェーンのドアアカウントで保有されます。サイドチェーンはメインチェーンとは別の履歴、ルール、バリデーターを持ちます。サイドチェーン上の代理資産は、メインチェーンに送り返され、フェデレータの管理下からロックを解除することができます。
|
||||
|
||||
_ドアアカウント_: フェデレータが管理するアカウントです。ドアアカウントは、メインチェーン上とサイドチェーン上の2つがあります。クロスチェーンの取引は、ユーザーがドアアカウントにアセットを送ることで始まります。メインチェーンからサイドチェーンへの取引では、メインチェーンのドアアカウントの残高が増加し、サイドチェーンのドアアカウントの残高が減少します。ドアと呼ばれるのは、あるチェーンから別のチェーンへと資産を移動させるための仕組みだからです。
|
||||
|
||||
_トリガー トランザクション_: フェデレータが新たな応答トランザクションに署名して提出するプロセスを開始するきっかけとなるトランザクションのこと。例えば、メインチェーンのドアアカウントにXRPを送ることは、サイドチェーン上でフェデレータに新しいトランザクションを提出させるトリガーとなるトランザクションです。
|
||||
|
||||
_レスポンス トランザクション_: トリガーとなるトランザクションに反応してフェデレータが提出するトランザクション。ほとんどの場合、レスポンス・トランザクションはトリガー・トランザクションと反対側のチェーンで発生する。ただし、失敗したトランザクションを処理するためのいくつかの例外があります。
|
||||
|
||||
|
||||
## フェデレーションサイドチェーンのセットアップ方法
|
||||
|
||||
フェデレーションサイドチェーンは現在開発者プレビューとして提供されているため、サイドチェーンの可能性を実験的に探ることができます。メインチェーンネットワーク内の[サーバー](xrpl-servers.html)のバージョンが1.8.0以上であれば、サイドチェーンをXRP Ledger Testnet、Devnet、Mainnetに接続することができます。
|
||||
|
||||
**注意:** サイドチェーンをXRP Ledger Mainnetに接続することで、少量の開発やテストを行うことができますが、フェデレーションサイドチェーンがリリースされるまでは、本番環境での使用はお勧めできません。
|
||||
|
||||
サイドチェーンの設定には、次のような大まかなステップがあります。
|
||||
|
||||
1. rippled`のソースコードをクローンして、`sidechain`ブランチをチェックアウトします。https://github.com/ripple/rippled/tree/sidechain。
|
||||
2. サイドチェーンのソースコードをカスタマイズします。例えば、カスタムの[トランザクションタイプ](transaction-types.html)を書きたいと思うかもしれません。 これは重要で簡単ではない作業であることに注意してください。
|
||||
3. 各サイドチェーン・フェデレーターにはそれぞれ設定ファイルがあり、以下の情報を含むように更新する必要があります。
|
||||
- `[sidechain]` 節 - 署名鍵、メインチェーンアカウント、リッスンするメインチェーンアドレス（IPとポート）などの詳細を追加します。
|
||||
`[sidechain_assets]` 節 - クロスチェーン取引に使用できる資産（XRPまたは[発行されたトークン](issued-currencies.html)）、資産の交換レート、デフォルトになる可能性のある取引を阻止するためのオプションの返金ペナルティを定義します。
|
||||
- [sidechain_federators] 節 - 署名に使用されるフェデレータ公開鍵のリスト。このリストは、サイドチェーン上のすべてのフェデレータに共通です。
|
||||
4. クロスチェーン取引を可能にするため、ドアアカウントを設定する。これには（両方のチェーンで）以下の手順が必要です。
|
||||
- ドアアカウントの作成と資金調達
|
||||
- ドアアカウントの[署名者リストの設定](set-up-multi-signing.html)
|
||||
- エラー処理のためにの3つの[チケット](tickets.html)の作成
|
||||
- そして最後に、フェデレータがドアアカウントを共同で管理するようにするためのドアアカウントの[マスターキーペアの無効化](disable-master-key-pair.html)
|
||||
|
||||
なお、この最後のステップは、これまでのステップが正常に完了した後に実行することが重要です。
|
||||
|
||||
|
||||
_サイドチェーン ローンチキット_ は、フェデレーションサイドチェーンの設定を簡素化するコマンドラインツールで、ローカルマシン上でサイドチェーンを素早く立ち上げるのに使用できます。また、ローンチキットは、サイドチェーンとの対話を可能にするインタラクティブなサイドチェーンシェルをインストールします。
|
||||
|
||||
[サイドチェーン ローンチキット >](https://github.com/xpring-eng/sidechain-launch-kit/blob/main/README.md)
|
||||
|
||||
|
||||
## 関連項目
|
||||
|
||||
- **概念:**
|
||||
- [フェデーレーションサイドチェーン ビデオ](https://www.youtube.com/embed/NhH4LM8NxgY)
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
@@ -1,88 +0,0 @@
|
||||
---
|
||||
html: federated-sidechains.html
|
||||
parent: consensus-network.html
|
||||
blurb: Learn about federated sidechains, which enable value in the form of XRP and other tokens (IOUs) to move efficiently between a sidechain and the XRP Ledger.
|
||||
labels:
|
||||
- Blockchain
|
||||
---
|
||||
# Federated Sidechains
|
||||
|
||||
_Federated Sidechains are available as an Engineering Preview and can be used to develop and test using `rippled` 1.8.0._
|
||||
|
||||
A sidechain is an independent ledger with its own consensus algorithm and transaction types and rules. It acts as its own blockchain. Federation enables value in the form of XRP and other tokens to move efficiently between a sidechain and an XRP Ledger _mainchain_ (usually Mainnet, but could be [Testnet or Devnet](parallel-networks.html) for testing). Federated sidechains run without compromising the speed, efficiency, and throughput of the public Mainnet.
|
||||
|
||||
Federated sidechains enable developers to launch new features and innovative applications using the foundation of XRP Ledger technology. Sidechains can customize the XRP Ledger protocol to the needs of a specific use case or project and run it as its own blockchain. Here are a few examples:
|
||||
|
||||
* Build a smart contract layer, powered by an engine compatible with the Ethereum Virtual Machine (EVM), web assembly, or a Move VM. For example, a [smart sidechain with Hooks](https://hooks-testnet.xrpl-labs.com/) enabled.
|
||||
* Build your own algorithmic stable coin with customised ledger types and transaction rules.
|
||||
* Build permissioned or nearly permissionless, centralized or largely decentralized ledgers whose assets can be traded on the Mainnet [decentralized exchange](decentralized-exchange.html).
|
||||
|
||||
## How Federated Sidechains Work
|
||||
|
||||
|
||||
A sidechain is an independent ledger with its own consensus algorithm and transaction types and rules. Each sidechain is run by its own set of servers (including validators) and does not rely on the validators on the Mainnet for transactions on the sidechain.
|
||||
|
||||
Each sidechain has two door accounts, one on the sidechain and one on the mainchain, that are controlled by the federators on the sidechain. The federators listen for transactions to and from both of these door accounts.
|
||||
|
||||
The sidechain has _federators_ who jointly control the door accounts on both networks using [multi-signing](multi-signing.html) so that 80% of federators must approve a transaction. In many cases, the federators should also be the trusted validators of the sidechain.
|
||||
|
||||
When a door account receives a transaction on either the sidechain or the mainchain, the federators create a mirror transaction on the other chain. (For example, if you send XRP _to_ the mainchain door account, the federators create a transaction on the sidechain to send XRP _from_ the sidechain door account to the intended recipient.) The federators sign the transaction and broadcast it to each other. Simultaneously, federators also listen for signed transactions from other federators and collect them.
|
||||
|
||||
When 80% of the federators have signed the transaction, they submit it to the sidechain or mainchain as appropriate. This way, assets that the mainchain door account holds can be allocated to others on the sidechain, and assets that sidechain door account receives can be sent to others on the mainchain.
|
||||
|
||||
Transactions within the sidechain are not visible to the servers on the mainchain.
|
||||
|
||||
|
||||
## Terminology
|
||||
|
||||
Below is an alphabetical list of terms and their definitions.
|
||||
|
||||
_Door account_: An account controlled by the federators. There are two door accounts: one on the mainchain and one on the sidechain. Cross chain transactions are started by users sending assets to a door account. Mainchain to sidechain transactions cause the balance to increase on the mainchain door account and the balance to decrease on the sidechain door account. It is called a "door" because it is the mechanism to move assets from one chain to another—much like going between rooms in a house requires stepping through a door.
|
||||
|
||||
_Federator_: A server on the sidechain that listens for triggering transactions on both the mainchain and the sidechain. Each federator has a signing key associated with it that is used to sign transactions. A transaction must be signed by a quorum of federators before it can be submitted. Federators are responsible for creating and signing valid response transactions, collecting signatures from other federators, and submitting transactions to the mainchain and sidechain.
|
||||
|
||||
_Mainchain_: The blockchain where assets originate and where assets are held while being used on the sidechain. For most sidechains, the mainchain is the XRP Ledger Mainnet, Testnet, or Devnet.
|
||||
|
||||
_Response transaction_: A transaction submitted by the federators in reaction to a triggering transaction. In most cases, the response transaction occurs on the opposite chain as the triggering transaction. However, there are some exceptions for handling failed transactions.
|
||||
|
||||
_Sidechain_: An XRP Ledger sidechain is another blockchain based on XRP Ledger technology. A _federated_ sidechain provides a way to transfer assets from a mainchain to the sidechain and back. A sidechain can use an exact copy of the XRP Ledger's protocol or it can make changes, including to the [consensus algorithm](consensus.html), [transaction types](transaction-types.html), and other rules. Sidechains have separate history, rules, and validators than the mainchain. Proxy assets are issued in the sidechain, with the equivalent assets held by a door account on the mainchain. Proxy assets on the sidechain can be sent back to the mainchain and unlocked from the control of the federators.
|
||||
|
||||
_Triggering transaction_: A transaction that causes the federators to start the process of signing and submitting a new response transaction. For example, sending XRP to the mainchain's door account is a triggering transaction that causes the federators to submit a new transaction on the sidechain.
|
||||
|
||||
## How to Set Up a Federated Sidechain
|
||||
|
||||
Federated Sidechains are currently available as an Engineering Preview so you can experiment and explore the potential of sidechains. You can connect sidechains to the XRP Ledger Testnet, Devnet, or Mainnet as long as [the servers](xrpl-servers.html) in the mainchain network are running version 1.8.0 or higher.
|
||||
|
||||
**Caution:** You can connect sidechains to the XRP Ledger Mainnet to develop and test with small amounts; it is not recommended for production use cases until federated sidechains are available in a release.
|
||||
|
||||
Setting up a sidechain involves the following high-level steps:
|
||||
|
||||
1. Clone the `rippled` source code and check out the `sidechain` branch: https://github.com/ripple/rippled/tree/sidechain.
|
||||
2. Customize the source code for your sidechain. For example, you may want to write custom [transaction types](transaction-types.html). Note that this is an important and non-trivial task.
|
||||
3. Each sidechain federator has its own configuration file that must be updated to include the following information:
|
||||
- `[sidechain]` stanza - add details such as signing key, mainchain account, and the mainchain address (IP and port) to listen to.
|
||||
- `[sidechain_assets]` stanza - define assets that can be used for cross-chain transactions (XRP or [issued tokens](issued-currencies.html)), exchange rate for the assets, and optional refund penalty to discourage transactions that may default.
|
||||
- [sidechain_federators] stanza - list of federators public keys to be used for signing. This list is common for all federators on the sidechain.
|
||||
4. Set up door accounts to enable cross chain transactions. This involves the following steps (on _both_ chains):
|
||||
- Create and fund the door accounts.
|
||||
- [Set up the SignerList](set-up-multi-signing.html) for the door account.
|
||||
- Create three [tickets](tickets.html) for error handling.
|
||||
- And finally, [disable the master key pair](disable-master-key-pair.html) to the door account to ensure that the federators jointly control the door account.
|
||||
|
||||
Note that it is important to perform this final step only after successful completion of the previous steps.
|
||||
|
||||
|
||||
The _Sidechain Launch Kit_ is a commandline tool that simplifies setting up federated sidechains and can be used to quickly spin up a sidechain on your local machine. The launch kit also installs an interactive Sidechain Shell that enables you to interact with the sidechain.
|
||||
|
||||
[Sidechain Launch Kit >](https://github.com/xpring-eng/sidechain-launch-kit)
|
||||
|
||||
|
||||
## See Also
|
||||
|
||||
- **Concepts:**
|
||||
- [Federated Sidechains Video](https://www.youtube.com/embed/NhH4LM8NxgY)
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
@@ -1,44 +0,0 @@
|
||||
---
|
||||
html: intro-to-evm-sidechain.html
|
||||
parent: xrpl-interoperability.html
|
||||
blurb: Introduction to the EVM compatible XRP Ledger Sidechain
|
||||
labels:
|
||||
- Interoperability
|
||||
status: not_enabled
|
||||
---
|
||||
# Introduction to EVM Compatible XRP Ledger Sidechain
|
||||
|
||||
{% include '_snippets/evmsc-disclaimer.md' %}
|
||||
|
||||
The Ethereum Virtual Machine (EVM) compatible XRP Ledger sidechain is a secure and fast public blockchain that brings all kinds of web3 applications to the XRP Ledger community.
|
||||
|
||||
- Explorer: [https://evm-sidechain.xrpl.org](https://evm-sidechain.xrpl.org/)
|
||||
- Public RPC: [https://rpc-evm-sidechain.xrpl.org](https://rpc-evm-sidechain.xrpl.org/)
|
||||
|
||||
|
||||
The EVM Sidechain is a powerful latest generation blockchain with the following features:
|
||||
|
||||
- Supports up to 1000 transactions per second, thus handling large loads and throughput.
|
||||
- Has a low transaction confirmation time, on average, as a block is produced every 5 seconds.
|
||||
- Once a block is added to the chain and confirmed, it is considered final (1 block finalization time).
|
||||
- Provides full Ethereum Virtual Machine (EVM) compatibility, enabling you to connect your wallet and interact or deploy smart contracts written in Solidity. <!-- STYLE_OVERRIDE: wallet -->
|
||||
|
||||
## Consensus
|
||||
|
||||
The EVM Sidechain runs on a proof-of-stake (PoS) consensus algorithm. Staking is when you pledge your coins to be used for verifying transactions. The proof-of-stake model allows you to stake cryptocurrency (also referred to as "coins") and create your own validator nodes. Your coins are locked up while you stake them, but you can unstake them if you want to trade your coins.
|
||||
|
||||
In a proof-of-stake blockchain, mining power depends on the amount of coins a validator is staking. Participants who stake more coins are more likely to be chosen to add new blocks.
|
||||
|
||||
If you are interested in staking cryptocurrency and running your own validator, see [Join EVM Sidechain Devnet](join-evm-sidechain-devnet.html) for more information.
|
||||
|
||||
The underlying technology for the XRP Ledger EVM Sidechain consensus is [Tendermint](https://tendermint.com/), a Byzantine-Fault Tolerant engine for building blockchains.
|
||||
|
||||
The blockchain uses the `cosmos-sdk` library on top of Tendermint to create and customize the blockchain using its built-in modules. The EVM sidechain uses the [Ethermint](https://github.com/evmos/ethermint) `cosmos-sdk` module, which provides EVM compatibility
|
||||
|
||||
## Interoperability Using the EVM Sidechain
|
||||
|
||||
The EVM sidechain is directly connected to XRP Ledger through the XRP Ledger bridge [https://bridge.devnet.xrpl](https://bridge.devnet.xrpl.org/). Through this bridge, you can connect to the EVM Sidechain and use its features.
|
||||
|
||||
## See Also
|
||||
|
||||
[Get Started with EVM Sidechain](get-started-evm-sidechain.html)
|
||||
@@ -1,13 +0,0 @@
|
||||
---
|
||||
html: xrpl-interoperability.html
|
||||
parent: concepts.html
|
||||
blurb: Learn about capabilities that bring programmability and ability to interact with other chains to the XRP Ledger.
|
||||
template: pagetype-category.html.jinja
|
||||
labels:
|
||||
- Interoperability
|
||||
status: not_enabled
|
||||
---
|
||||
# Interoperability
|
||||
|
||||
The XRP Ledger is known for its transaction throughput, speed, and low fees. With the addition of programmability and interoperability, developers can access features such as smart contracts and can build apps with cross-chain interoperability.
|
||||
|
||||
@@ -8,7 +8,7 @@ labels:
|
||||
---
|
||||
# 暗号鍵
|
||||
|
||||
XRP Ledgerでは、[トランザクション](transaction-basics.html)による一連の具体的なアクションの実行が承認されていることを、デジタル署名によって証明します。署名されたトランザクションのみがネットワークに送信され、検証済みレジャーに含まれます。 <!-- STYLE_OVERRIDE: is authorized to -->
|
||||
XRP Ledgerでは、[トランザクション](transaction-basics.html)による一連の具体的なアクションの実行が承認されていることを、デジタル署名によって証明します。署名されたトランザクションのみがネットワークに送信され、検証済みレジャーに含まれます。
|
||||
|
||||
すべてのデジタル署名は、トランザクションの送信側アカウントに関連付けられている暗号鍵ペアに基づいています。キーペアはXRP Ledgerでサポートされている[暗号化署名アルゴリズム](#署名アルゴリズム)を使用して生成できます。キーペアの生成に使用されたアルゴリズムの種類にかかわらず、キーペアは[マスターキーペア](#マスターキーペア)、[レギュラーキーペア](#レギュラーキーペア)、または[署名者リスト](multi-signing.html)のメンバーとして使用できます。
|
||||
|
||||
@@ -16,96 +16,106 @@ XRP Ledgerでは、[トランザクション](transaction-basics.html)による
|
||||
|
||||
## キーの生成
|
||||
|
||||
[`wallet_propose`](wallet_propose.html)メソッドを使用してキーペアを生成します。以下は、`wallet_propose`の応答例です。
|
||||
多くの[クライアントライブラリ](client-libraries.html)やアプリケーションは、XRP Ledgerでの使用に合わせてキーペアを生成できます。もちろん、信頼できるデバイスやソフトウェアで生成されたキーペアのみを使用する必要があります。悪意のあるアプリケーションは、あなたの秘密情報を悪意のあるユーザーに公開する可能性があり、そのユーザーはあなたのアカウントから後でトランザクションを送信することができます。
|
||||
|
||||
```
|
||||
{
|
||||
"result": {
|
||||
"account_id": "rDGnaDqJczDAjrKHKdhGRJh2G7zJfZhj5q",
|
||||
"key_type": "secp256k1",
|
||||
"master_key": "COON WARN AWE LUCK TILE WIRE ELI SNUG TO COVE SHAM NAT",
|
||||
"master_seed": "sstV9YX8k7yTRzxkRFAHmX7EVqMfX",
|
||||
"master_seed_hex": "559EDD35041D3C11F9BBCED912F4DE6A",
|
||||
"public_key": "aBQXEw1vZD3guCX3rHL8qy8ooDomdFuxZcWrbRZKZjdDkUoUjGVS",
|
||||
"public_key_hex": "0351BDFB30E7924993C625687AE6127034C4A5EBA78A01E9C58B0C46E04E3A4948"
|
||||
},
|
||||
"status": "success",
|
||||
"type": "response"
|
||||
}
|
||||
```
|
||||
## キーの構成要素
|
||||
|
||||
この応答には、キーペア（さまざまなフォーマットのシードと公開鍵）と`account_id`が含まれています。
|
||||
暗号鍵ペアは、鍵の導出プロセスを通じて数学的に関連づけられる**秘密鍵**と**公開鍵**のことです。秘密鍵は、強力なランダム性によって決定されなければなりません。[暗号化署名アルゴリズム](#署名アルゴリズム)は、鍵の導出プロセスを定義し、暗号鍵となり得る数値の制限を設定します。
|
||||
|
||||
**シード**
|
||||
XRP Ledgerを扱う場合、パスフレーズ、シード、アカウントID、アドレスなど、いくつかの関連する値を使用することもあります。
|
||||
|
||||
_シード_ 値は、アカウントの実際の秘密鍵（および公開鍵）を[導出する](#鍵導出)ために使用されるコンパクトな値です。`master_key`、`master_seed`、および`master_seed_hex`はすべて、同じシード値を表しますが、フォーマットが異なります。これらのいずれのフォーマットも、[`rippled` API](http-websocket-apis.html)や[その他のXRPLソフトウェア](software-ecosystem.html)で[トランザクションに署名](transaction-basics.html#トランザクションへの署名とトランザクションの送信)するときに使用することができます。キーの先頭に`master_`が付いていますが、このシードが表すキーが必ずしもアカウントのマスターキーであるとは限りません。キーペアは、レギュラーキーだけでなく、マルチシグのリストのメンバーとしても使用できます。
|
||||
{{ include_svg("img/cryptographic-keys.svg", "Diagram: パスフレーズ → シード → 秘密鍵 → 公開鍵 → アカウントID ←→ アドレス") }}
|
||||
_図: 暗号鍵の値の関係を簡略化した図_
|
||||
|
||||
シード値はアカウントのその他のあらゆる情報の基盤であるため、慎重に保護する必要があります。アドレスのシード値を知っている人なら誰でも、事実上そのアドレスを完全に制御できます。
|
||||
パスフレーズ、シード、秘密鍵は**秘密**であり、あるアカウントのこれらの値のいずれかを知っていれば、有効な署名を行うことができ、そのアカウントを完全に制御することができます。もしあなたがアカウントを所有しているのであれば、アカウントの秘密情報には**細心の注意を払ってください**。もしあなたがそれらを持っていないなら、あなたは自分のアカウントを利用することはできません。もし他の誰かがそれらにアクセスすることができれば、彼らはあなたのアカウントをコントロールすることができます。
|
||||
|
||||
**秘密鍵**
|
||||
公開鍵、アカウントID、アドレスは公開情報です。一時的に公開鍵を秘密にするような状況もありますが、最終的にはトランザクションの一部として公開し、XRP Ledgerが署名を検証してトランザクションを処理できるようにすることが必要です。
|
||||
|
||||
`wallet_propose`応答には、秘密鍵（ _プライベートキー_ とも呼ばれます）の値が明示的に示されていません。トランザクションに署名できるソフトウェアであれば、シード値から[秘密鍵を導出](#鍵導出)可能であると考えられます。
|
||||
鍵の導出の仕組みの技術的な詳細については、[鍵の導出](#鍵導出)を参照してください。
|
||||
|
||||
**公開鍵**
|
||||
|
||||
`public_key`と`public_key_hex`はいずれも、同一値の公開鍵を表します。公開鍵は、鍵導出の一環として秘密鍵から導出されます。公開鍵を使用すると、トランザクション署名の真正性を検証できますが、それ以上の署名を作成することはできません。
|
||||
### パスフレーズ
|
||||
|
||||
**account_id**
|
||||
オプションとして、パスフレーズやその他の情報を、シードや秘密鍵の決定方法として使用することができます。これは、完全にランダムにシードや秘密鍵を選択するよりも安全性が低いですが、これを行いたいレアケースもあります。(例えば、2018年に「XRPuzzler」が最初に[パズルを解いた人](https://bitcoinexchangeguide.com/cryptographic-puzzle-creator-xrpuzzler-offers-137-xrp-reward-to-anyone-who-can-solve-it/)にXRPをプレゼントしました。彼はパズルの解答を、賞品のXRPを保有するアカウントへのパスフレーズとして使用しました)
|
||||
|
||||
`account_id`は[公開鍵から生成され](accounts.html#アドレスのエンコード)、アカウントがXRP Ledgerに作成される*可能性*を示します。`account_id`が存在していても、`account_id`が最初の XRPでの支払いを受領するまでは、実際のアカウントはXRP Ledgerに存在しません。さらに`account_id`は、資金を供給するトランザクションを受領して、アカウントが作成されるまでは、トランザクションを送信することができません。
|
||||
パスフレーズは秘密情報であるため、厳重に保管する必要があります。アドレスのパスフレーズを知った人は、そのアドレスを実質的に完全にコントロールすることができます。
|
||||
|
||||
ただし、（資金供給されたアカウントのない）`account_id`は、既存の別のアカウントのトランザクションを承認する際に[レギュラーキー](#レギュラーキーペア)または[署名者リストのメンバー](multi-signing.html)として使用できます。
|
||||
### シード
|
||||
|
||||
資金供給されたアカウントを作成してレジャーに保管するには、`account_id`が、[必要準備金](reserves.html)を満たすのに十分なXRPを供給する[`Payment`トランザクションを受領する](payment.html#アカウントの作成)必要があります。
|
||||
_シード_ 値は、アカウントの実際の秘密鍵と公開鍵を[導出](#鍵導出)するために使用される、コンパクトな値です。[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`応答についての詳細は、[`wallet_propose`](wallet_propose.html)を参照してください。
|
||||
シード値は秘密情報であるため、非常に厳重に保管する必要があります。あるアドレスのシード値を知っている人は、そのアドレスを実質的に完全にコントロールすることができます。
|
||||
|
||||
生成されたキーペアは、[マスターキーペア](#マスターキーペア)、[レギュラーキーペア](#レギュラーキーペア)、または[署名者リストメンバー](multi-signing.html)のいずれかとして使用できます。
|
||||
### 秘密鍵
|
||||
|
||||
**キータイプ**
|
||||
_秘密鍵_ は、デジタル署名を作成するために使用される値です。ほとんどのXRP Ledgerソフトウェアは、秘密鍵を明示的に表示せず、必要に応じてシード値から[秘密鍵の導出](#鍵導出)を行っています。シードの代わりに秘密鍵を保存し、それを使ってトランザクションに直接署名することは技術的には可能ですが、この使い方はレアケースです。
|
||||
|
||||
`key_type`フィールドは、このキーペアの生成に使用された[暗号化署名アルゴリズム](#署名アルゴリズム)を示します。[wallet_proposeメソッド][]を使用したキーペアの生成を要求するときに、`key_type`を指定できます。
|
||||
シードと同様、秘密鍵は秘密情報であるため、厳重に保管する必要があります。あるアドレスの秘密鍵を知っている人は、そのアドレスを事実上完全にコントロールすることができます。
|
||||
|
||||
### 公開鍵
|
||||
|
||||
公開鍵は、電子署名の正当性を検証するために使用される値です。公開鍵は、鍵の導出の一部として秘密鍵から導出されます。[wallet_proposeメソッド][]のレスポンスでは、`public_key` と `public_key_hex` は両方とも同じ公開鍵の値を表します。
|
||||
|
||||
XRP Ledgerのトランザクションには、ネットワークがトランザクションの署名を検証できるように、公開鍵が含まれている必要があります。公開鍵は有効な署名を作成するために使用することはできないので、公開しても問題はありません。
|
||||
|
||||
|
||||
### アカウントIDとアドレス
|
||||
|
||||
**アカウントID**は、[アカウント](accounts.html)またはキーペアの中核となる識別子です。これは公開鍵から派生します。XRP Ledgerのプロトコルでは、アカウントIDは20バイトのバイナリデータです。ほとんどのXRP Ledger APIは、アカウントIDをアドレスとして表現し、次の2つのフォーマットのうちの1つで表現します。
|
||||
|
||||
- 「クラシックアドレス」は、[base58][]にチェックサム付きでアカウントIDを書きます。[wallet_proposeメソッド][]のレスポンスでは、これが `account_id` の値となります。
|
||||
- 「X-Address」は、アカウントIDと[宛先タグ](source-and-destination-tags.html)を組み合わせ、チェックサムとともに[base58][]にその値を書き込みます。
|
||||
|
||||
どちらの形式でもチェックサムがあるため、わずかな変更でアドレスが無効になり、他の有効なアカウントと入れ替わる可能性はありません。これにより、タイプミスや送信エラーが発生しても、間違った場所に送金されることはありません。
|
||||
|
||||
すべてのアカウントID（またはアドレス）が台帳のアカウントを参照しているわけではないことを知っておくことが重要です。キーとアドレスの導出は、純粋に数学的な操作です。アカウントがXRPレジャーに情報を持つには、[XRPの支払いを受け](accounts.html#creating-accounts)、[準備金](reserves.html)を満たす必要があります。アカウントは、資金が供給されるまでトランザクションを送信することはできません。
|
||||
|
||||
アカウントIDやアドレスが資金提供されたアカウントを指していない場合でも、そのアカウントIDやアドレスを使用して、[レギュラーキーペア](#レギュラーキーペア)や[署名者リストのメンバー](multi-signing.html)を表すことはできます。
|
||||
|
||||
### キーの種類
|
||||
|
||||
XRP Ledgerは、複数の[暗号署名アルゴリズム](#署名アルゴリズム)をサポートしています。任意のキーペアは、特定の暗号化署名アルゴリズムに対してのみ有効です。いくつかの秘密鍵は、技術的には複数のアルゴリズムに対して有効な鍵として適格かもしれませんが、それらの秘密鍵は各アルゴリズムに対して異なる公開鍵を持つことになり、いずれにしても秘密鍵を再利用すべきではありません。
|
||||
|
||||
[wallet_proposeメソッド][]の`key_type`フィールドは、使用する暗号化署名アルゴリズムを指します。
|
||||
|
||||
## マスターキーペア
|
||||
|
||||
マスターキーペアは秘密鍵と公開鍵で構成されます。マスターキーペアの秘密鍵は、レギュラーキーペアで署名できるすべてのトランザクションに署名できるほか、以下の操作の実行に使用できる唯一の鍵でもあります。
|
||||
マスターキーペアは、秘密鍵と公開鍵で構成されています。アカウントのアドレスは、そのアカウントのマスターキーペアから得られるので、両者は[本質的な関係](accounts.html#アドレスのエンコード)となります。マスターキーペアの変更・削除はできませんが、無効にすることはできます。
|
||||
|
||||
* [マスター公開鍵を無効にする](accountset.html)。
|
||||
[wallet_proposeメソッド][]は、マスターキーペアを生成する方法の1つです。このメソッドからの応答には、アカウントのシード、アドレス、マスター公開鍵が一緒に表示されます。マスターキーペアを設定する他の方法については、[安全な署名の設定](set-up-secure-signing.html) を参照してください。
|
||||
|
||||
* [凍結](freezes.html#no-freeze)機能を永久に放棄する。
|
||||
**注意:** 悪意のある行為者があなたのマスター秘密鍵（またはシード）を知った場合、マスター鍵ペアが無効化されていない限り、彼らはあなたのアカウントを完全にコントロールすることができます。彼らはあなたのアカウントが保持している全ての資金を盗み、その他の回復不能な損害を与えることができます。秘密鍵は慎重に扱ってください！
|
||||
|
||||
* トランザクションコストが0の[Key Resetトランザクション](transaction-cost.html#key-resetトランザクション)を送信する。
|
||||
マスターキーペアは変更できないため、漏えいが発生した場合には無効化せざるを得ません。[マスターキーペアをオフラインで保管](offline-account-setup.html)し、代わりにアカウントのトランザクションの署名用にレギュラーキーペアを設定することを強くお勧めします。マスターキーペアを有効にしておきながらオンラインで使用することで、インターネットを使用してマスターキーペアにアクセスすることはできませんが、緊急時にマスターキーペアを使うことが可能になります。
|
||||
|
||||
アカウントのマスターキーペアは、マスターキーペアによるトランザクションへの署名が承認されているアカウントの`account_id`と同じ[`wallet_propose`](wallet_propose.html)応答にて生成されます。マスターキーペアは同じ応答内で生成されるため、アドレスに[固有に関連付け](accounts.html#アドレスのエンコード)られています。このアドレスは、公開鍵から導出されます。
|
||||
マスターキーペアをオフラインで保管する際には、不正使用者がアクセスできる場所に秘密情報(パスフレーズ、シード、秘密鍵)を保管しないようにします。たとえば、インターネットに一切接続されない物理的に隔離されたマシンに保管したり、紙に記入して安全な場所に保管します。一般的には、インターネットと相互にやり取りをするコンピュータプログラムがアクセスできる範囲内には保管しません。マスターキーペアは、緊急時（漏えいの恐れがある場合や実際に漏えいが発生した場合にレギュラーキーペアを変更するなど）に限り、最も信頼できるデバイスでのみ使用することが理想的です。
|
||||
|
||||
これは、同様に`wallet_propose`メソッドを使用して生成されても、レギュラーキーペアとしてアカウントに明示的に割り当てられる必要があるレギュラーキーペアとは対照的です。レギュラーキーペアは明示的に割り当てられるため、トランザクションの署名が承認されているアカウントのアドレスには固有に関連付けられません。詳細は、[レギュラーキーペア](#レギュラーキーペア)を参照してください。
|
||||
### 特殊な権限
|
||||
|
||||
**注意:** マスターキーペアは変更できませんが、無効にできます。つまり、マスターシードまたは秘密鍵が漏えいした場合は、変更するのではなく、[無効にする](accountset.html)必要があります。
|
||||
**マスターキーペア**のみが、ある特定の処理を行うトランザクションを承認することができます。
|
||||
|
||||
マスターキーペアは変更できないため、漏えいが発生した場合には無効化せざるを得ません。[マスターキーペアをオフラインで保管](offline-account-setup.html)し、代わりにアカウントのトランザクションの署名用にレギュラーキーペアを設定することを強くお勧めします。
|
||||
- アカウントの最初のトランザクションを送信する。アカウントはその他の方法で[トランザクションを承認](transaction-basics.html#authorizing-transactions)して初期化することができないからです。
|
||||
|
||||
マスターキーペアをオフラインで保管する際には、不正使用者がアクセスできる場所にマスター秘密鍵を保管しないようにします。たとえば、インターネットに一切接続されない物理的に隔離されたマシンに保管したり、紙に記入して安全な場所に保管します。一般的には、インターネットと相互にやり取りをするコンピュータプログラムがアクセスできる範囲内には保管しません。マスターキーペアは、緊急時（漏えいの恐れがある場合や実際に漏えいが発生した場合にレギュラーキーペアを変更するなど）に限り、最も信頼できるデバイスでのみ使用することが理想的です。
|
||||
- マスターキーペアを無効化する。
|
||||
|
||||
- [凍結](freezes.html#no-freeze)の機能を永久に放棄する。
|
||||
|
||||
- トランザクションコスト0XRPの特別な[キーリセットトランザクション](transaction-cost.html#key-resetトランザクション)を送信する。
|
||||
|
||||
レギュラーキーや[マルチシグ](multi-signing.html)は、マスターキーペアと同じようにその他の処理を行うことができます。特に、マスターキーペアを無効にした後、レギュラーキーペアやマルチシグを使用して再び有効にすることができます。また、削除の条件を満たしていれば、[アカウントの削除](accounts.html#アカウントの削除)を行うことも可能です。
|
||||
|
||||
## レギュラーキーペア
|
||||
|
||||
XRP Ledgerでは、アカウントのマスターキーペアをオフラインで保管し、その後のトランザクションには _レギュラーキーペア_ と呼ばれるセカンダリキーペアで署名することができます。レギュラーキーペアのシードまたは秘密鍵が漏えいした場合は、キーペアを削除または交換できます。その際に、アカウントのキーペア以外の設定を変更する必要はありません。これにより、アカウントの設定や他のアカウントとの関係を再設定する手間が省けます。レギュラーキーペアを積極的にローテーションすることも可能です。（アカウントのアドレスに固有に関連付けられているアカウントのマスターキーペアでは、このような操作は実行できません。）
|
||||
XRP Ledgerアカウントは、_レギュラーキーペア_ と呼ばれるセカンダリキーペアを許可することができます。そうすると、[マスターキーペア](#マスターキーペア)とレギュラーキーのどちらかを使ってトランザクションを承認することができるようになります。レギュラーキーペアは、アカウントの他の部分を変更することなく、いつでも削除または変更することができます。
|
||||
|
||||
レギュラーキーペアとして使用するキーペアは、[`wallet_propose`](wallet_propose.html)メソッドを使用して生成します。ただし、サポートするアカウントの`account_id`と同時に生成され、それに固有に関連付けられている[マスターキーペア](#マスターキーペア)とは異なり、レギュラーキーペアと、このキーペアがトランザクションの署名に使用されるアカウントとの関係を明示的に作成する必要があります。レギュラーキーペアをアカウントに割り当てるには、[`SetRegularKey`](setregularkey.html)メソッドを使用します。
|
||||
レギュラーキーペアは、マスターキーペアと同じ種類のトランザクションのほとんどを承認することができますが、[特定の例外](#特殊な権限)があります。例えば、レギュラーキーペアは、レギュラーキーペアを変更するトランザクションを _承認_ することができます。
|
||||
|
||||
レギュラーキーペアの割り当てに関するチュートリアルについては、[レギュラーキーペアの割り当て](assign-a-regular-key-pair.html)を参照してください。
|
||||
マスター秘密鍵はオフラインの場所に保存し、ほとんどの時間、レギュラーキーペアを使用することがセキュリティ上推奨されます。万一の備えとして、レギュラーキーペアを定期的に変更するのもよいでしょう。悪意のあるユーザーにレギュラーの秘密鍵を知られてしまった場合、マスターキーペアをオフラインで保存し、それを使ってレギュラーキーペアを変更または削除することができます。こうすることで、アカウントの制御を取り戻すことができます。悪意のあるユーザーにお金を盗まれるのを阻止するほどのスピードがなかったとしても、少なくとも、新しいアカウントに移行して、すべての設定や人間関係を一から作り直す必要はありません。
|
||||
|
||||
レギュラーキーペアを割り当てたアカウントには、次の2つのキーペアが関連付けられることになります。
|
||||
レギュラーキーペアは、マスターキーペアと同じ形式です。生成方法も同じです（例えば、[wallet_proposeメソッド][]を使用します）。唯一の違いは、レギュラーキーペアは、トランザクションに署名するアカウントと本質的に結びついていないことです。あるアカウントのマスターキーペアを別のアカウントの通常キーペアとして使用することは可能です（ただし、推奨されるものではありません）。
|
||||
|
||||
* アカウントの`account_id`に固有に関連付けられるマスターキーペア。オフラインで保管します。
|
||||
* アカウントに明示的に割り当てられ、アカウントのトランザクションの署名に使用されるレギュラーキーペア。
|
||||
|
||||
レギュラーキーペアをアカウントに割り当てて、[マスターキーペア](#マスターキーペア)で署名されるトランザクションを除く、すべてのトランザクションの署名にそのレギュラーキーペアを使用できます。
|
||||
|
||||
レギュラーキーペアはいつでも削除または変更できます。つまり、レギュラーキーペアの秘密鍵が漏えいした（ただしマスターキーペアの秘密鍵の漏えいは発生していない）場合、レギュラーキーペアを削除または変更するだけでアカウントの制御を取り戻すことができます。
|
||||
|
||||
レギュラーキーペアの変更または削除のチュートリアルについては、[レギュラーキーペアの割り当て](assign-a-regular-key-pair.html)を参照してください。
|
||||
[SetRegularKeyトランザクション][]は、アカウントのレギュラーキーペアを割り当てたり変更したりします。レギュラーキーペアの割り当てまたは変更に関するチュートリアルは、[レギュラーキーペアの割り当て
|
||||
](assign-a-regular-key-pair.html)を参照してください。
|
||||
|
||||
|
||||
## 署名アルゴリズム
|
||||
@@ -123,11 +133,9 @@ XRP Ledgerでは次の暗号化署名アルゴリズムがサポートされて
|
||||
|
||||
XRP Ledgerでは、サポートされているさまざまなタイプのキーペアは、マスターキーペア、レギュラーキーペア、署名者リストメンバーとして互換的に使用できます。[アドレス生成](accounts.html#アドレスのエンコード)プロセスは、secp256k1キーペアとEd25519キーペアでは同一です。
|
||||
|
||||
**注記:** 現時点では、Ed25519キーで[Payment Channelクレーム](use-payment-channels.html)に署名することはできません。これはバグです。
|
||||
|
||||
### 将来のアルゴリズム
|
||||
|
||||
今後、暗号技術の発展に対応するため、XRP Ledgerには新しい暗号化署名アルゴリズムが必要になるでしょう。例えば、[Shorのアルゴリズム](https://en.wikipedia.org/wiki/Shor's_algorithm)（または類似のアルゴリズム）を使用する量子コンピューターの実用化が間近となり、楕円曲線暗号が解読される可能性が生じた場合、XRP Ledger開発者は容易に解読できない暗号化署名アルゴリズムを追加できます。2019年半ばの時点で、確実な第一選択肢となる「耐量子」署名アルゴリズムはなく、量子コンピューターはまだ脅威となるほど実用的ではないため、現時点では特定のアルゴリズムを追加する予定はありません。<!-- STYLE_OVERRIDE: will -->
|
||||
今後、暗号技術の発展に対応するため、XRP Ledgerには新しい暗号化署名アルゴリズムが必要になるでしょう。例えば、[Shorのアルゴリズム](https://en.wikipedia.org/wiki/Shor's_algorithm)（または類似のアルゴリズム）を使用する量子コンピューターの実用化が間近となり、楕円曲線暗号が解読される可能性が生じた場合、XRP Ledger開発者は容易に解読できない暗号化署名アルゴリズムを追加できます。2019年半ばの時点で、確実な第一選択肢となる「耐量子」署名アルゴリズムはなく、量子コンピューターはまだ脅威となるほど実用的ではないため、現時点では特定のアルゴリズムを追加する予定はありません。
|
||||
|
||||
|
||||
## 鍵導出
|
||||
@@ -139,14 +147,14 @@ XRP Ledgerでは、サポートされているさまざまなタイプのキー
|
||||
ここで説明する鍵導出プロセスは、さまざまなプログラミング言語で複数の場所に実装されています。
|
||||
|
||||
- C++: `rippled`コードベース:
|
||||
- [シード定義](https://github.com/ripple/rippled/blob/develop/src/ripple/protocol/Seed.h)
|
||||
- [汎用キー & Ed25519鍵導出](https://github.com/ripple/rippled/blob/develop/src/ripple/protocol/impl/SecretKey.cpp)
|
||||
- [secp256k1鍵導出](https://github.com/ripple/rippled/blob/develop/src/ripple/protocol/impl/SecretKey.cpp)
|
||||
- [シード定義](https://github.com/XRPLF/rippled/blob/develop/src/ripple/protocol/Seed.h)
|
||||
- [汎用キー & Ed25519鍵導出](https://github.com/XRPLF/rippled/blob/develop/src/ripple/protocol/impl/SecretKey.cpp)
|
||||
- [secp256k1鍵導出](https://github.com/XRPLF/rippled/blob/develop/src/ripple/protocol/impl/SecretKey.cpp)
|
||||
- Python 3: [このリポジトリのコードサンプルセクション]({{target.github_forkurl}}/blob/{{target.github_branch}}/content/_code-samples/key-derivation/py/key_derivation.py)。
|
||||
- JavaScript: [`ripple-keypairs`](https://github.com/ripple/ripple-keypairs/)パッケージ。
|
||||
- JavaScript: [`ripple-keypairs`](https://github.com/XRPLF/xrpl.js/tree/main/packages/ripple-keypairs)パッケージ。
|
||||
|
||||
### Ed25519鍵導出
|
||||
[[ソース]](https://github.com/ripple/rippled/blob/fc7ecd672a3b9748bfea52ce65996e324553c05f/src/ripple/protocol/impl/SecretKey.cpp#L203 "Source")
|
||||
[[ソース]](https://github.com/XRPLF/rippled/blob/fc7ecd672a3b9748bfea52ce65996e324553c05f/src/ripple/protocol/impl/SecretKey.cpp#L203 "Source")
|
||||
|
||||
[](img/key-derivation-ed25519.ja.png)
|
||||
|
||||
@@ -168,7 +176,7 @@ XRP Ledgerでは、サポートされているさまざまなタイプのキー
|
||||
|
||||
### secp256k1鍵導出
|
||||
|
||||
[[ソース]](https://github.com/ripple/rippled/blob/develop/src/ripple/protocol/impl/SecretKey.cpp "Source")
|
||||
[[ソース]](https://github.com/XRPLF/rippled/blob/develop/src/ripple/protocol/impl/SecretKey.cpp "Source")
|
||||
|
||||
[](img/key-derivation-secp256k1.ja.png)
|
||||
|
||||
@@ -188,7 +196,7 @@ XRP Ledgerアカウントキーでのsecp256k1鍵導出に、Ed25519鍵導出よ
|
||||
|
||||
2. 連結された（シード+ルートシーケンス）値の[SHA-512ハーフ][]を計算します。
|
||||
|
||||
3. 結果が有効なsecp256k1秘密鍵でない場合は、ルートシーケンスを1増やして最初からやり直します。[[ソース]](https://github.com/ripple/rippled/blob/fc7ecd672a3b9748bfea52ce65996e324553c05f/src/ripple/crypto/impl/GenerateDeterministicKey.cpp#L103 "Source")
|
||||
3. 結果が有効なsecp256k1秘密鍵でない場合は、ルートシーケンスを1増やして最初からやり直します。[[ソース]](https://github.com/XRPLF/rippled/blob/fc7ecd672a3b9748bfea52ce65996e324553c05f/src/ripple/crypto/impl/GenerateDeterministicKey.cpp#L103 "Source")
|
||||
|
||||
有効なsecp256k1鍵は0であってはならず、 _secp256k1グループ_ の数値順よりも低くなければなりません。secp256k1グループの順序は、定数`0xFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFEBAAEDCE6AF48A03BBFD25E8CD0364141`です。
|
||||
|
||||
@@ -233,15 +241,15 @@ XRP Ledgerアカウントキーでのsecp256k1鍵導出に、Ed25519鍵導出よ
|
||||
## 関連項目
|
||||
|
||||
- **コンセプト:**
|
||||
- [発行アドレスと運用アドレス](issuing-and-operational-addresses.html)
|
||||
- [発行アドレスと運用アドレス](issuing-and-operational-addresses.html)
|
||||
- **チュートリアル:**
|
||||
- [レギュラーキーペアの割り当て](assign-a-regular-key-pair.html)
|
||||
- [レギュラーキーペアの変更または削除](change-or-remove-a-regular-key-pair.html)
|
||||
- [レギュラーキーペアの割り当て](assign-a-regular-key-pair.html)
|
||||
- [レギュラーキーペアの変更または削除](change-or-remove-a-regular-key-pair.html)
|
||||
- **リファレンス:**
|
||||
- [SetRegularKeyトランザクション][]
|
||||
- [AccountRootレジャーオブジェクト](accountroot.html)
|
||||
- [wallet_proposeメソッド][]
|
||||
- [account_infoメソッド][]
|
||||
- [SetRegularKeyトランザクション][]
|
||||
- [AccountRootレジャーオブジェクト](accountroot.html)
|
||||
- [wallet_proposeメソッド][]
|
||||
- [account_infoメソッド][]
|
||||
|
||||
<!--{# common link defs #}-->
|
||||
{% include '_snippets/rippled-api-links.md' %}
|
||||
|
||||
@@ -151,14 +151,14 @@ The process of deriving a key pair depends on the signing algorithm. In all case
|
||||
The key derivation processes described here are implemented in multiple places and programming languages:
|
||||
|
||||
- In C++ in the `rippled` code base:
|
||||
- [Seed definition](https://github.com/ripple/rippled/blob/develop/src/ripple/protocol/Seed.h)
|
||||
- [General & Ed25519 key derivation](https://github.com/ripple/rippled/blob/develop/src/ripple/protocol/impl/SecretKey.cpp)
|
||||
- [secp256k1 key derivation](https://github.com/ripple/rippled/blob/develop/src/ripple/protocol/impl/SecretKey.cpp)
|
||||
- [Seed definition](https://github.com/XRPLF/rippled/blob/develop/src/ripple/protocol/Seed.h)
|
||||
- [General & Ed25519 key derivation](https://github.com/XRPLF/rippled/blob/develop/src/ripple/protocol/impl/SecretKey.cpp)
|
||||
- [secp256k1 key derivation](https://github.com/XRPLF/rippled/blob/develop/src/ripple/protocol/impl/SecretKey.cpp)
|
||||
- In Python 3 in [this repository's code samples section]({{target.github_forkurl}}/blob/{{target.github_branch}}/content/_code-samples/key-derivation/py/key_derivation.py).
|
||||
- In JavaScript in the [`ripple-keypairs`](https://github.com/ripple/ripple-keypairs/) package.
|
||||
- In JavaScript in the [`ripple-keypairs`](https://github.com/XRPLF/xrpl.js/tree/main/packages/ripple-keypairs) package.
|
||||
|
||||
### Ed25519 Key Derivation
|
||||
[[Source]](https://github.com/ripple/rippled/blob/fc7ecd672a3b9748bfea52ce65996e324553c05f/src/ripple/protocol/impl/SecretKey.cpp#L203 "Source")
|
||||
[[Source]](https://github.com/XRPLF/rippled/blob/fc7ecd672a3b9748bfea52ce65996e324553c05f/src/ripple/protocol/impl/SecretKey.cpp#L203 "Source")
|
||||
|
||||
{{ include_svg("img/key-derivation-ed25519.svg", "Passphrase → Seed → Secret Key → Prefix + Public Key") }}
|
||||
|
||||
@@ -179,7 +179,7 @@ The key derivation processes described here are implemented in multiple places a
|
||||
Validator ephemeral keys cannot be Ed25519.
|
||||
|
||||
### secp256k1 Key Derivation
|
||||
[[Source]](https://github.com/ripple/rippled/blob/develop/src/ripple/protocol/impl/SecretKey.cpp "Source")
|
||||
[[Source]](https://github.com/XRPLF/rippled/blob/develop/src/ripple/protocol/impl/SecretKey.cpp "Source")
|
||||
|
||||
{{ include_svg("img/key-derivation-secp256k1.svg", "Passphrase → Seed → Root Key Pair → Intermediate Key Pair → Master Key Pair") }}
|
||||
|
||||
@@ -198,7 +198,7 @@ The steps to derive the XRP Ledger's secp256k1 account key pair from a seed valu
|
||||
|
||||
2. Calculate the [SHA-512Half][] of the concatenated (seed+root sequence) value.
|
||||
|
||||
3. If the result is not a valid secp256k1 secret key, increment the root sequence by 1 and start over. [[Source]](https://github.com/ripple/rippled/blob/fc7ecd672a3b9748bfea52ce65996e324553c05f/src/ripple/crypto/impl/GenerateDeterministicKey.cpp#L103 "Source")
|
||||
3. If the result is not a valid secp256k1 secret key, increment the root sequence by 1 and start over. [[Source]](https://github.com/XRPLF/rippled/blob/fc7ecd672a3b9748bfea52ce65996e324553c05f/src/ripple/crypto/impl/GenerateDeterministicKey.cpp#L103 "Source")
|
||||
|
||||
A valid secp256k1 key must not be zero, and it must be numerically less than the _secp256k1 group order_. The secp256k1 group order is the constant value `0xFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFEBAAEDCE6AF48A03BBFD25E8CD0364141`.
|
||||
|
||||
|
||||
@@ -21,7 +21,7 @@ Checksは[Escrow](escrow.html)と[Payment Channel](use-payment-channels.html)に
|
||||
|
||||
* Checksは資金を凍結しません。Payment ChannelとEscrowでは、送金元が発行したクレームでXRPが清算されるか（Payment Channel）、または有効期限切れまたはCrypto-conditionsによってXRPがリリースされる（Escrow）までは、そのXRPを使用できません。
|
||||
|
||||
* EscrowではXRPを自分自身に送金できます。ChecksとPayment Channelを使用してXRP（Checksの場合は発行済み通貨）を自身に送金することはできません。
|
||||
* EscrowではXRPを自分自身に送金できます。ChecksではXRPを自身に送金することはできません。
|
||||
|
||||
|
||||
**注記:** [Checks Amendment][] により、[OfferCreate][]トランザクションの有効期限が変更されます。詳細は[オファーの有効期限](offers.html#オファーの有効期限)を参照してください。
|
||||
@@ -33,8 +33,6 @@ Checksは[Escrow](escrow.html)と[Payment Channel](use-payment-channels.html)に
|
||||
|
||||
XRP Ledger Checksは、XRP Ledgerに固有の問題も解決できます。たとえば、ユーザーが不審な支払いを拒否したり、支払いの一部のみを受領することを可能にします。これは、コンプライアンス上の理由から支払いの受け入れに慎重に対応する必要がある機関にとっては有用です。
|
||||
|
||||
Checksはその他のさまざまな用途に利用できる可能性があります。RippleはコミュニティにてChecksの新しく創造的な用途が探られていくことを推奨しています。
|
||||
|
||||
|
||||
### ユースケース: 支払いの承認
|
||||
|
||||
@@ -85,7 +83,7 @@ Checksはすべて同じ方法で開始されるため、**ステップ1と2**
|
||||
|
||||
## Checksの利用可能性
|
||||
|
||||
Checksを使用するには`rippled` v0.90.0以降が必要です。2018年10月11日の時点では、Checks Amendmentは本番環境のXRP Ledgerで有効になっていません。すべての既知のAmendmentの最新状況については、[既知のAmendment](known-amendments.html)を参照してください。Amendmentを有効化し、Amendmentに投票する方法については、[Amendmentプロセス](amendments.html#amendmentプロセス)を参照してください。
|
||||
[Checks amendment][]は2020年6月18日にメインネットで有効化されました。Amendmentがどのように有効化され、投票されるかについては、[Amendmentsプロセス](amendments.html#amendmentプロセス)を参照してください。
|
||||
|
||||
Test NetまたはプライベートXRP LedgerネットワークでのAmendmentの状況を確認するには、[featureメソッド][]を使用してください。
|
||||
|
||||
|
||||
@@ -1,40 +1,45 @@
|
||||
---
|
||||
html: authorized-trust-lines.html
|
||||
parent: tokens.html
|
||||
blurb: 通貨発行者が自己の発行済み通貨を保有できる人を制限できる、Authorized Trust Lineについて説明します。
|
||||
blurb: 認可トラストラインとは、トークンを保有できる人を制限するための設定です。
|
||||
labels:
|
||||
- トークン
|
||||
- セキュリティ
|
||||
---
|
||||
# Authorized Trust Lines
|
||||
# 認可トラストライン
|
||||
|
||||
XRP LedgerのAuthorized Trust Lines機能により、通貨イシュアーは自身の（XRP以外の）発行済み通貨を保有できるユーザーを制限できます。これにより、不明なXRP Ledgerアドレスは発行済み通貨を保有できなくなります。Authorized Trust Lines機能は発行済み通貨にのみ適用され、XRPには影響しません。
|
||||
XRP Ledgerの認可トラストライン機能により、発行者は、発行者が許可したアカウントのみが保有できるトークンを作成することができます。。認可トラストライン機能はトークンにのみ適用され、XRPには影響しません。
|
||||
|
||||
Authorized Trust Lines機能を使用するには、発行アドレスでRequireAuthフラグを有効にします。その後、発行アドレスは他のアドレスからのトラストラインを承認する[TrustSetトランザクション][]を送信できます。RequireAuthが有効であるときに発行アドレスから発行された資金を他のアドレスが保有できるのは、発行アドレスへのトラストラインが承認されている場合だけです。
|
||||
認可トラストライン機能を使用するには、発行アドレスで**RequireAuth**フラグを有効にします。その後、他のアカウントは、あなたがそのアカウントのトラストラインをあなたの発行アカウントに承認した場合にのみ、あなたが発行したトークンを保持することができます。
|
||||
|
||||
トラストラインを承認するトランザクションには発行アドレスによる署名が必要ですが、これにより発行アドレスが危険にさらされる可能性が高くなります。RequireAuthが有効であるXRP Ledgerへの資金の送金プロセスは次のようになります。
|
||||
発行アドレスから[TrustSetトランザクション][]を送信し、自分のアカウントと認可するアカウントとの間のトラストラインを設定することで、トラストラインを認可することができます。トラストラインを認可した後、その認可を取り消すことはできません。(ただし、必要に応じてトラストラインを[凍結](freezes.html)することは可能です)。
|
||||
|
||||
1. 発行ゲートウェイがその発行アドレスを顧客に公開します。
|
||||
2. 顧客のXRP Ledgerアドレスからゲートウェイの発行アドレスへのトラストラインを作成するために顧客は[TrustSetトランザクション][]を送信します。これは、ゲートウェイが発行した特定通貨を特定の限度額まで保有することを顧客が望んでいることを意味します。
|
||||
3. ゲートウェイの発行アドレスは、顧客のトラストラインを承認するTrustSetトランザクションを送信します。
|
||||
トラストラインを認可するためのトランザクションは、発行アドレスの署名が必要であり、残念ながらそのアドレスのリスクエクスポージャーが増加することを意味します。
|
||||
|
||||
**ヒント:** 発行ゲートウェイは、顧客がトラストラインの作成を完了する前に、そのトラストラインを事前に承認できます（ステップ3）。これにより限度額がゼロのトラストラインが作成されます。顧客のTrustSetトランザクション（ステップ2）により、事前承認されたトラストラインに限度額が設定されます。_（[TrustSetAuth Amendment][]が必要です。）_
|
||||
**注意:** Require Authを有効にできるのは、アカウントにトラストラインがなく、XRP LedgerにOffersがない場合だけなので、トークンの発行前に使用するかどうかを決定する必要があります。
|
||||
|
||||
## RequireAuth設定
|
||||
## ステーブルコインの発行
|
||||
|
||||
`RequireAuth`設定をすることで、発行アドレスが当該通貨に関してその取引相手とのトラストラインを具体的に承認している場合を除き、すべての取引相手はアドレスから発行された残高を保有できなくなります。
|
||||
XRP Ledger上のステーブルコインと認可トラストラインの使用により、新規顧客の獲得プロセスは以下のようなものになります。
|
||||
|
||||
用心として、発行ゲートウェイが[運用アドレスとスタンバイアドレス](issuing-and-operational-addresses.html)に対して`RequireAuth`を常に有効にし、これらのアドレスへのトラストラインを一切承認しないことが推奨されます。これにより、運用アドレスとスタンバイアドレスがXRP Ledgerで誤って通貨を発行することを防止できます。これは純粋な予防措置であり、発行アドレスにより作成された発行済み通貨の残高を、これらのアドレスが意図したとおりに送金することを阻止するものではありません。
|
||||
1. 顧客は、ステーブルコイン発行会社のシステムに登録し、身元を証明する情報（「Know Your Customer」（KYC）情報とも呼ばれる）を送信します。
|
||||
2. 顧客とステーブルコイン発行者は、お互いのXRP Ledgerアドレスを提示し合います。
|
||||
3. 顧客は[TrustSetトランザクション][]を送信し、発行者のアドレスにトラストラインを作成し、正のリミットを設定します。
|
||||
4. 発行者はTrustSetトランザクションを送信し、顧客のトラストラインを認可します。
|
||||
|
||||
Authorized Trust Lines機能を使用するには、イシュアーがその発行アドレスの`RequireAuth`も有効にする必要もあります。その後、発行アドレスは顧客からの[各トラストラインを承認する`TrustSet`トランザクションを送信する](#トラストラインの承認)必要があります。
|
||||
**ヒント:** 2つのTrustSetトランザクション（ステップ3および4）は、どちらの順序で発生しても構いません。発行者がトラストラインを先に認可した場合、これにより限度額が0に設定されたトラストラインが作成され、顧客のTrustSetトランザクションは、事前に認可されたトラストラインの限度額を設定することになります。([TrustSetAuth amendment][]によって追加されました。)_
|
||||
## 注意事項
|
||||
|
||||
**注意:** アカウントが`RequireAuth`を有効にできるのは、アカウントがトラストラインを所有しておらず、またXRP Ledgerにオファーがない場合に限られます。したがってXRP Ledgerで取引を開始する前に、この設定を使用するかどうかを決定しておく必要があります。
|
||||
認可トラストラインを使用するつもりがない場合でも、[運用アカウントと予備アカウント](issuing-and-operational-addresses.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. #}-->
|
||||
|
||||
### RequireAuthの有効化
|
||||
|
||||
ローカルでホストされている`rippled`の[submitメソッド][]を使用して、RequireAuthフラグを有効にする[AccountSetトランザクション][]を送信する例を以下に示します。（このメソッドは、アドレスが発行アドレス、運用アドレス、スタンバイアドレスのいずれであっても同様に機能します。）
|
||||
以下は、ローカルでホストされている`rippled`の[submitメソッド][]を使って、`asfRequireAuth`フラグを使ってRequire Authを有効にする[AccountSetトランザクション][]を送信する例です。（このメソッドは、アドレスが発行アドレス、運用アドレス、スタンバイアドレスのいずれであっても同様に機能します。）
|
||||
|
||||
要求:
|
||||
リクエスト:
|
||||
|
||||
```json
|
||||
POST http://localhost:5005/
|
||||
@@ -42,7 +47,7 @@ POST http://localhost:5005/
|
||||
"method": "submit",
|
||||
"params": [
|
||||
{
|
||||
"secret": "sn3nxiW7v8KXzPzAqzyHXbSSKNuN9",
|
||||
"secret": "s████████████████████████████",
|
||||
"tx_json": {
|
||||
"Account": "rUpy3eEg8rqjqfUoLeBnZkscbKbFsKXC3v",
|
||||
"Fee": "15000",
|
||||
@@ -62,17 +67,17 @@ POST http://localhost:5005/
|
||||
|
||||
アカウントのRequireAuth設定の有効化の状態を確認するには、[account_infoメソッド][]を使用してアカウントを調べます。`Flags`フィールド（`result.account_data`オブジェクト）の値を、[AccountRootレジャーオブジェクトのビット単位フラグ](accountroot.html)と比較します。
|
||||
|
||||
`Flags`値と`lsfRequireAuth`フラグ値（0x00040000）のビット単位のANDの結果がゼロ以外の場合、アカウントではRequireAuthが有効になっています。結果がゼロの場合、アカウントではRequireAuthが無効になっています。
|
||||
`Flags`値と`lsfRequireAuth`フラグ値（`0x00040000`）のビット単位のANDの結果がゼロ以外の場合、アカウントではRequireAuthが有効になっています。結果がゼロの場合、アカウントではRequireAuthが無効になっています。
|
||||
|
||||
## トラストラインの承認
|
||||
## トラストラインの認可
|
||||
|
||||
Authorized Trust Lines機能を使用している場合、他のアカウントからのトラストラインを最初に承認しなければ、これらの他のアカウントはあなたが発行する残高を保有できません。複数の通貨を発行する場合には、各通貨のトラストラインを個別に承認する必要があります。
|
||||
認可トラストライン機能を使用している場合、他のアカウントからのトラストラインを認可しなければ、これらの他のアカウントはあなたが発行する残高を保有できません。複数のトークンを発行する場合には、各通貨のトラストラインを個別に認可する必要があります。
|
||||
|
||||
トラストラインを承認するには、`LimitAmount`の`issuer`として信頼するユーザーを指定して、発行アドレスから[TrustSetトランザクション][]を送信します。`value`（信頼する額）を**0**のままにし、トランザクションの[tfSetfAuth](trustset.html#trustsetのフラグ)フラグを有効にします。
|
||||
トラストラインを認可するには、`LimitAmount`の`issuer`として信頼するユーザーを指定して、発行アドレスから[TrustSetトランザクション][]を送信します。`value`（信頼する額）を**0**のままにし、トランザクションの[tfSetfAuth](trustset.html#trustsetのフラグ)フラグを有効にします。
|
||||
|
||||
ローカルでホストされている`rippled`の[submitメソッド][]を使用して、顧客アドレス（rf1BiGeXwwQoi8Z2ueFYTEXSwuJYfV2Jpn）が発行アドレス（rsA2LpzuawewSBQXkiju3YQTMzW13pAAdW）からのUSDのイシュアンスを保有することを承認するTrustSetトランザクションを送信する例を以下に示します。
|
||||
以下は、ローカルでホストされている`rippled`の[submitメソッド][]を使用して、顧客アドレス`rf1BiGeXwwQoi8Z2ueFYTEXSwuJYfV2Jpn`がアドレス`rsA2LpzuawewSBQXkiju3YQTMzW13pAAdW`で発行したUSDを持つことを認可するTrustSetトランザクションを送信する例です。
|
||||
|
||||
要求:
|
||||
リクエスト:
|
||||
|
||||
```json
|
||||
POST http://localhost:8088/
|
||||
@@ -80,7 +85,7 @@ POST http://localhost:8088/
|
||||
"method": "submit",
|
||||
"params": [
|
||||
{
|
||||
"secret": "sn3nxiW7v8KXzPzAqzyHXbSSKNuN9",
|
||||
"secret": "s████████████████████████████",
|
||||
"tx_json": {
|
||||
"Account": "rsA2LpzuawewSBQXkiju3YQTMzW13pAAdW",
|
||||
"Fee": "15000",
|
||||
@@ -100,11 +105,26 @@ POST http://localhost:8088/
|
||||
{% include '_snippets/secret-key-warning.md' %}
|
||||
<!--{#_ #}-->
|
||||
|
||||
## トラストラインの承認状況の確認
|
||||
## トラストラインの認可状況の確認
|
||||
|
||||
トラストラインの承認状況を確認するには、[account_linesメソッド][]を使用してトラストラインを調べます。要求の`account`フィールドに顧客のアドレスを指定し、`peer`フィールドにイシュアーのアドレスを指定します。
|
||||
トラストラインの認可状況を確認するには、[account_linesメソッド][]を使用してトラストラインを調べます。レスポンスの`account`フィールドに顧客のアドレスを指定し、`peer`フィールドに発行者のアドレスを指定します。
|
||||
|
||||
応答の`result.lines`配列で、必要とする通貨のトラストラインを表している`currency`フィールドを持つオブジェクトを見つけます。そのオブジェクトの`peer_authorized`フィールドに値`true`が設定されている場合は、イシュアー（要求の`peer`フィールドとして使用したアドレス）によりそのトラストラインが承認されています。
|
||||
応答の`result.lines`配列で、必要とする通貨のトラストラインを表している`currency`フィールドを持つオブジェクトを見つけます。そのオブジェクトの`peer_authorized`フィールドに値`true`が設定されている場合は、発行者（レスポンスの`peer`フィールドとして使用したアドレス）によりそのトラストラインが承認されています。
|
||||
|
||||
## 関連項目
|
||||
|
||||
- **コンセプト:**
|
||||
- [Deposit Authorization](depositauth.html)
|
||||
- [トークンの凍結](freezes.html)
|
||||
- **チュートリアル:**
|
||||
- [ステーブルコインを発行する](become-an-xrp-ledger-gateway.html)
|
||||
- **リファレンス:**
|
||||
- [account_linesメソッド][]
|
||||
- [account_infoメソッド][]
|
||||
- [AccountSetトランザクション][]
|
||||
- [TrustSetトランザクション][]
|
||||
- [AccountRootフラグ](accountroot.html#accountrootのフラグ)
|
||||
- [RippleState (トラストライン) フラグ](ripplestate.html#ripplestateのフラグ)
|
||||
|
||||
<!--{# common link defs #}-->
|
||||
{% include '_snippets/rippled-api-links.md' %}
|
||||
|
||||
@@ -121,7 +121,7 @@ In the response's `result.lines` array, find the object whose `currency` field i
|
||||
- [Deposit Authorization](depositauth.html)
|
||||
- [Freezing Issued Currencies](freezes.html)
|
||||
- **Tutorials:**
|
||||
- [Become an XRP Ledger Gateway](become-an-xrp-ledger-gateway.html)
|
||||
- [Become a Stablecoin Issuer](become-an-xrp-ledger-gateway.html)
|
||||
- **References:**
|
||||
- [account_lines method][]
|
||||
- [account_info method][]
|
||||
|
||||
Reference in New Issue
Block a user