mirror of
https://github.com/XRPLF/xrpl-dev-portal.git
synced 2026-02-14 19:02:25 +00:00
Compare commits
5 Commits
add-readme
...
merge-veri
| Author | SHA1 | Date | |
|---|---|---|---|
|
|
65f9a8d53b | ||
|
|
f3e8db32dc | ||
|
|
5a763cb9c9 | ||
|
|
54637ac896 | ||
|
|
4568a71632 |
@@ -51,7 +51,7 @@ Para más información sobre Cheques en el XRP Ledger, ver:
|
||||
- [CheckCancel][]
|
||||
- **Tutoriales de cheques:**
|
||||
- [Enviar un cheque](/docs/tutorials/payments/send-a-check.md)
|
||||
- [Buscar cheques](/docs/tutorials/ /how-tos/use-specialized-payment-types/use-checks/look-up-checks.md)
|
||||
- [Buscar cheques](/docs/tutorials/payments/look-up-checks.md)
|
||||
- [Canjear un cheque por la cantidad exacta](/docs/tutorials/payments/cash-a-check-for-an-exact-amount.md)
|
||||
- [Canjear un cheque por una cantidad flexible](/docs/tutorials/payments/cash-a-check-for-a-flexible-amount.md)
|
||||
- [Cancelar un cheque](/docs/tutorials/payments/cancel-a-check.md)
|
||||
|
||||
@@ -6,4 +6,4 @@ Checkを換金するための前提条件は、正確な金額を換金する場
|
||||
- 発行済み通貨用のCheckの場合は、ご自身(受取人)にイシュアーに対するトラストラインがある必要があります。このトラストライン上のご自身の限度額は、受け取る金額を追加するための残高より十分高くなければなりません。
|
||||
- トラストラインと限度額について詳しくは、[トークン](../concepts/tokens/index.md)および[トラストラインと発行](../concepts/tokens/fungible-tokens/index.md)をご覧ください。
|
||||
- [トランザクションに安全に署名できる手段](../concepts/transactions/secure-signing.md)。
|
||||
- XRP Ledgerに接続できる[クライアントライブラリ](../references/client-libraries.md)か、それとも[HTTPライブラリ、WebSocketライブラリなど](../tutorials/http-websocket-apis/get-started.md)。
|
||||
- XRP Ledgerに接続できる[クライアントライブラリ](../references/client-libraries.md)か、それとも[HTTPライブラリ、WebSocketライブラリなど](../tutorials/get-started/get-started-http-websocket-apis.md)。
|
||||
|
||||
@@ -2,7 +2,7 @@
|
||||
|
||||
`rippled`ログメッセージの詳細は、[ログメッセージについて](../infrastructure/troubleshooting/understanding-log-messages.md)をご覧ください。
|
||||
|
||||
`rippled`が残りのネットワークと同期されたら、ストック`rippled`サーバが完全に機能するようになります。このサーバを、ローカル署名やXRP LedgerへのAPIアクセスに使用できます。`rippled`サーバがネットワークと同期されているかどうかを判別するには、[`rippled`サーバの状況](../references/http-websocket-apis/api-conventions/rippled-server-states.md)を使用します。[`rippled`のコマンドラインインターフェイス](../tutorials/http-websocket-apis/get-started.md#コマンドライン)を使用すれば、これを迅速にテストできます。
|
||||
`rippled`が残りのネットワークと同期されたら、ストック`rippled`サーバが完全に機能するようになります。このサーバを、ローカル署名やXRP LedgerへのAPIアクセスに使用できます。`rippled`サーバがネットワークと同期されているかどうかを判別するには、[`rippled`サーバの状況](../references/http-websocket-apis/api-conventions/rippled-server-states.md)を使用します。[`rippled`のコマンドラインインターフェイス](../tutorials/get-started/get-started-http-websocket-apis.md#コマンドライン)を使用すれば、これを迅速にテストできます。
|
||||
|
||||
```sh
|
||||
rippled server_info
|
||||
|
||||
@@ -73,8 +73,8 @@ labels:
|
||||
- [アカウント](index.md)
|
||||
- [暗号鍵](cryptographic-keys.md)
|
||||
- **チュートリアル:**
|
||||
- [レギュラーキーペアの割り当て](../../tutorials/how-tos/manage-account-settings/assign-a-regular-key-pair.md)
|
||||
- [レギュラーキーペアの変更または削除](../../tutorials/how-tos/manage-account-settings/change-or-remove-a-regular-key-pair.md)
|
||||
- [レギュラーキーペアの割り当て](../../tutorials/best-practices/key-management/assign-a-regular-key-pair.md)
|
||||
- [レギュラーキーペアの変更または削除](../../tutorials/best-practices/key-management/change-or-remove-a-regular-key-pair.md)
|
||||
- **リファレンス:**
|
||||
- [account_infoメソッド][]
|
||||
- [SetRegularKeyトランザクション][]
|
||||
|
||||
@@ -90,7 +90,7 @@ XRP Ledgerは、複数の[暗号署名アルゴリズム](#署名アルゴリズ
|
||||
|
||||
{% admonition type="warning" name="注意" %}悪意のある行為者があなたのマスター秘密鍵(またはシード)を知った場合、マスター鍵ペアが無効化されていない限り、彼らはあなたのアカウントを完全にコントロールすることができます。彼らはあなたのアカウントが保持している全ての資金を盗み、その他の回復不能な損害を与えることができます。秘密鍵は慎重に扱ってください!{% /admonition %}
|
||||
|
||||
マスターキーペアは変更できないため、漏えいが発生した場合には無効化せざるを得ません。[マスターキーペアをオフラインで保管](../../tutorials/how-tos/manage-account-settings/offline-account-setup.md)し、代わりにアカウントのトランザクションの署名用にレギュラーキーペアを設定することを強くお勧めします。マスターキーペアを有効にしておきながらオンラインで使用することで、インターネットを使用してマスターキーペアにアクセスすることはできませんが、緊急時にマスターキーペアを使うことが可能になります。
|
||||
マスターキーペアは変更できないため、漏えいが発生した場合には無効化せざるを得ません。[マスターキーペアをオフラインで保管](../../tutorials/best-practices/key-management/offline-account-setup.md)し、代わりにアカウントのトランザクションの署名用にレギュラーキーペアを設定することを強くお勧めします。マスターキーペアを有効にしておきながらオンラインで使用することで、インターネットを使用してマスターキーペアにアクセスすることはできませんが、緊急時にマスターキーペアを使うことが可能になります。
|
||||
|
||||
マスターキーペアをオフラインで保管する際には、不正使用者がアクセスできる場所に秘密情報(パスフレーズ、シード、秘密鍵)を保管しないようにします。たとえば、インターネットに一切接続されない物理的に隔離されたマシンに保管したり、紙に記入して安全な場所に保管します。一般的には、インターネットと相互にやり取りをするコンピュータプログラムがアクセスできる範囲内には保管しません。マスターキーペアは、緊急時(漏えいの恐れがある場合や実際に漏えいが発生した場合にレギュラーキーペアを変更するなど)に限り、最も信頼できるデバイスでのみ使用することが理想的です。
|
||||
|
||||
@@ -121,7 +121,7 @@ XRP Ledgerアカウントは、_レギュラーキーペア_ と呼ばれるセ
|
||||
|
||||
レギュラーキーペアは、マスターキーペアと同じ形式です。生成方法も同じです(例えば、[wallet_proposeメソッド][]を使用します)。唯一の違いは、レギュラーキーペアは、トランザクションに署名するアカウントと本質的に結びついていないことです。あるアカウントのマスターキーペアを別のアカウントの通常キーペアとして使用することは可能です(ただし、推奨されるものではありません)。
|
||||
|
||||
[SetRegularKeyトランザクション][]は、アカウントのレギュラーキーペアを割り当てたり変更したりします。レギュラーキーペアの割り当てまたは変更に関するチュートリアルは、[レギュラーキーペアの割り当て](../../tutorials/how-tos/manage-account-settings/assign-a-regular-key-pair.md)をご覧ください
|
||||
[SetRegularKeyトランザクション][]は、アカウントのレギュラーキーペアを割り当てたり変更したりします。レギュラーキーペアの割り当てまたは変更に関するチュートリアルは、[レギュラーキーペアの割り当て](../../tutorials/best-practices/key-management/assign-a-regular-key-pair.md)をご覧ください
|
||||
|
||||
|
||||
## 署名アルゴリズム
|
||||
@@ -250,8 +250,8 @@ XRP Ledgerアカウントキーでのsecp256k1鍵導出に、Ed25519鍵導出よ
|
||||
- **コンセプト:**
|
||||
- [発行アドレスと運用アドレス](account-types.md)
|
||||
- **チュートリアル:**
|
||||
- [レギュラーキーペアの割り当て](../../tutorials/how-tos/manage-account-settings/assign-a-regular-key-pair.md)
|
||||
- [レギュラーキーペアの変更または削除](../../tutorials/how-tos/manage-account-settings/change-or-remove-a-regular-key-pair.md)
|
||||
- [レギュラーキーペアの割り当て](../../tutorials/best-practices/key-management/assign-a-regular-key-pair.md)
|
||||
- [レギュラーキーペアの変更または削除](../../tutorials/best-practices/key-management/change-or-remove-a-regular-key-pair.md)
|
||||
- **リファレンス:**
|
||||
- [SetRegularKeyトランザクション][]
|
||||
- [AccountRootレジャーオブジェクト](../../references/protocol/ledger-data/ledger-entry-types/accountroot.md)
|
||||
|
||||
@@ -55,15 +55,15 @@ XRP Ledgerでアカウントを取得する一般的な方法は次のとおり
|
||||
- **コンセプト:**
|
||||
- [準備金](reserves.md)
|
||||
- [暗号鍵](cryptographic-keys.md)
|
||||
- [発行アドレスと運用アドレス](account-types.md)
|
||||
- [発行アドレスと運用アドレス](account-types.md)
|
||||
- **リファレンス:**
|
||||
- [account_infoメソッド][]
|
||||
- [wallet_proposeメソッド][]
|
||||
- [AccountSetトランザクション][]
|
||||
- [AccountSetトランザクション][]
|
||||
- [Paymentトランザクション][]
|
||||
- [AccountRootオブジェクト](../../references/protocol/ledger-data/ledger-entry-types/accountroot.md)
|
||||
- [AccountRootオブジェクト](../../references/protocol/ledger-data/ledger-entry-types/accountroot.md)
|
||||
- **チュートリアル:**
|
||||
- [アカウント設定の管理(カテゴリ)](../../tutorials/how-tos/manage-account-settings/index.md)
|
||||
- [WebSocketを使用した着信ペイメントの監視](../../tutorials/http-websocket-apis/monitor-incoming-payments-with-websocket.md)
|
||||
- [レギュラーキーペアの割り当て](../../tutorials/best-practices/key-management/assign-a-regular-key-pair.md)
|
||||
- [WebSocketを使用した着信ペイメントの監視](../../tutorials/advanced-developer-topics/client-library-development/monitor-incoming-payments-with-websocket.md)
|
||||
|
||||
{% raw-partial file="/@l10n/ja/docs/_snippets/common-links.md" /%}
|
||||
|
||||
@@ -58,7 +58,7 @@ CEOのウェイトを3、副社長3人のウェイトを各2、取締役3人の
|
||||
|
||||
マルチシグトランザクションを正常に送信するには、以下のすべての条件を満たす必要があります。
|
||||
|
||||
* トランザクションを送信するアドレス(`Account`に指定されるアドレス)は、[レジャーに`SignerList`](../../references/protocol/ledger-data/ledger-entry-types/signerlist.md)を所有する必要があります。この方法については、[マルチシグを設定する](../../tutorials/how-tos/manage-account-settings/set-up-multi-signing.md)をご覧ください。
|
||||
* トランザクションを送信するアドレス(`Account`に指定されるアドレス)は、[レジャーに`SignerList`](../../references/protocol/ledger-data/ledger-entry-types/signerlist.md)を所有する必要があります。この方法については、[マルチシグを設定する](../../tutorials/best-practices/key-management/set-up-multi-signing.md)をご覧ください。
|
||||
* トランザクションに`SigningPubKey`フィールドを空の文字列として含める必要があります。
|
||||
* トランザクションに、署名の配列が指定されている[`Signers`フィールド](../../references/protocol/transactions/common-fields.md#signersフィールド)を含める必要があります。
|
||||
* `Signers`配列に含まれている署名は、`SignerList`で定義されている署名と一致している必要があります。
|
||||
@@ -67,13 +67,13 @@ CEOのウェイトを3、副社長3人のウェイトを各2、取締役3人の
|
||||
* トランザクションのすべてのフィールドは、署名収集前に定義する必要があります。フィールドの[自動入力](../../references/protocol/transactions/common-fields.md#自動入力可能なフィールド)は実行できません。
|
||||
* `Signers`配列がバイナリ形式で指定される場合、この配列は署名者アドレスの数値に基づいて、低い値から順にソートされている必要があります。(JSONとして提出される場合は、[submit_multisignedメソッド][]がこの処理を自動的に実行します。)
|
||||
|
||||
詳細は、[マルチシグの設定](../../tutorials/how-tos/manage-account-settings/set-up-multi-signing.md)をご覧ください。
|
||||
詳細は、[マルチシグの設定](../../tutorials/best-practices/key-management/set-up-multi-signing.md)をご覧ください。
|
||||
|
||||
## 関連項目
|
||||
|
||||
- **チュートリアル:**
|
||||
- [マルチシグを設定する](../../tutorials/how-tos/manage-account-settings/set-up-multi-signing.md)
|
||||
- [マルチシグトランザクションを送信する](../../tutorials/how-tos/manage-account-settings/send-a-multi-signed-transaction.md)
|
||||
- [マルチシグを設定する](../../tutorials/best-practices/key-management/set-up-multi-signing.md)
|
||||
- [マルチシグトランザクションを送信する](../../tutorials/best-practices/key-management/send-a-multi-signed-transaction.md)
|
||||
- **コンセプト:**
|
||||
- [暗号鍵](cryptographic-keys.md)
|
||||
- [マルチシグトランザクションの特別なトランザクションコスト](../transactions/transaction-cost.md#特別なトランザクションコスト)
|
||||
|
||||
@@ -61,7 +61,7 @@ XRP Ledgerのチケットは、取引をすぐに送信せずに、その取引
|
||||
- **Concepts:**
|
||||
- [マルチシグ](multi-signing.md)
|
||||
- **Tutorials:**
|
||||
- [チケットを使用する](../../tutorials/how-tos/manage-account-settings/use-tickets.md)
|
||||
- [チケットを使用する](../../tutorials/best-practices/transaction-sending/use-tickets.md)
|
||||
- **References:**
|
||||
- [TicketCreateトランザクション][]
|
||||
- [トランザクションの共通フィールド](../../references/protocol/transactions/common-fields.md)
|
||||
|
||||
@@ -16,7 +16,7 @@ XRP LedgerのChecks機能を使用すると、指定の受取人による取消
|
||||
|
||||
XRP Ledger Checksには有効期限があり、この期限を過ぎると換金できなくなります。受取人が有効期限までにCheckを換金できなかった場合、Checkオブジェクトは誰かに取り消されるまでXRP Ledgerに残ります。有効期限切れになったCheckは誰でも取り消すことができます。有効期限前、あるいはChecksが換金されるまでは、送金元と受取人のみがCheckを取り消すことができます。Checkオブジェクトは、送金元がそのCheckを換金できた時点または誰かが取り消した時点でLedgerから削除されます。
|
||||
|
||||
Checksは[Escrow](escrow.md)と[Payment Channel](../../tutorials/how-tos/use-specialized-payment-types/use-payment-channels/index.md)に似ていますが、Checksとこれらの機能の間には重要な相違がいくつかあります。
|
||||
Checksは[Escrow](escrow.md)と[Payment Channel](../../tutorials/payments/use-payment-channels.md)に似ていますが、Checksとこれらの機能の間には重要な相違がいくつかあります。
|
||||
|
||||
* Checksではトークンを送金できます。Payment ChannelとEscrowで送金できるのはXRPのみです。
|
||||
|
||||
@@ -109,6 +109,6 @@ XRP LedgerのChecksの詳細は、以下をご覧ください。
|
||||
|
||||
* [Deposit Authorization](../accounts/depositauth.md)
|
||||
* [Escrow](escrow.md)
|
||||
* [Payment Channelチュートリアル](../../tutorials/how-tos/use-specialized-payment-types/use-payment-channels/index.md)
|
||||
* [Payment Channelチュートリアル](../../tutorials/payments/use-payment-channels.md)
|
||||
|
||||
{% raw-partial file="/@l10n/ja/docs/_snippets/common-links.md" /%}
|
||||
|
||||
@@ -9,7 +9,7 @@ labels:
|
||||
---
|
||||
# クロスカレンシー支払い
|
||||
|
||||
XRP Ledgerでは、1つ以上のトークンとXRP、またはその両方を交換して、クロスカレンシー支払いができます。[XRPによる直接支払い](../../tutorials/how-tos/send-xrp.md)と同様に、このような支払いでは[Paymentトランザクションタイプ][Payment]が使用されます。XRP Ledgerでのクロスカレンシー支払いは完全にアトミックです。つまり、支払いを全額実行するか、またはまったく実行しないかのいずれかになります。
|
||||
XRP Ledgerでは、1つ以上のトークンとXRP、またはその両方を交換して、クロスカレンシー支払いができます。[XRPによる直接支払い](../../tutorials/payments/send-xrp.md)と同様に、このような支払いでは[Paymentトランザクションタイプ][Payment]が使用されます。XRP Ledgerでのクロスカレンシー支払いは完全にアトミックです。つまり、支払いを全額実行するか、またはまったく実行しないかのいずれかになります。
|
||||
|
||||
デフォルトでは、クロスカレンシー支払いでは宛先に一定額が送金され、支払元が変動コストを負担します。クロスカレンシー支払いが、[Partial Payments](partial-payments.md)で行われ、一定の送金限度内の変動額が宛先に送金される場合もあります。
|
||||
|
||||
|
||||
@@ -80,8 +80,8 @@ XRP Ledgerでは、支払いを受け取ることができるアドレスは永
|
||||
## 関連項目
|
||||
|
||||
- **チュートリアル:**
|
||||
- [XRPの送金(対話型チュートリアル)](../../tutorials/how-tos/send-xrp.md)
|
||||
- [WebSocketを使用した着信ペイメントの監視](../../tutorials/http-websocket-apis/monitor-incoming-payments-with-websocket.md)
|
||||
- [XRPの送金(対話型チュートリアル)](../../tutorials/payments/send-xrp.md)
|
||||
- [WebSocketを使用した着信ペイメントの監視](../../tutorials/advanced-developer-topics/client-library-development/monitor-incoming-payments-with-websocket.md)
|
||||
- **リファレンス:**
|
||||
- [Paymentトランザクション][]
|
||||
- [トランザクションの結果](../../references/protocol/transactions/transaction-results/index.md)
|
||||
|
||||
@@ -82,13 +82,13 @@ reference_fee * (signer_count + 33 + (fulfillment_bytes / 16))
|
||||
|
||||
XRP LedgerのEscrowの詳細は、以下をご覧ください:
|
||||
|
||||
- [Escrowチュートリアル](../../tutorials/how-tos/use-specialized-payment-types/use-escrows/index.md)
|
||||
- [時間ベースのEscrowの送金](../../tutorials/payments/send-a-timed-escrow.md)
|
||||
- [トランザクションのリファレンス](../../references/protocol/transactions/index.md)
|
||||
- [EscrowCreateトランザクション][]
|
||||
- [EscrowFinishトランザクション][]
|
||||
- [EscrowCancelトランザクション][]
|
||||
- [レジャーリファレンス](../../references/protocol/ledger-data/index.md)
|
||||
- [Escrowオブジェクト](../../references/protocol/ledger-data/ledger-entry-types/escrow.md)
|
||||
- [Escrowエントリ][]
|
||||
|
||||
|
||||
Rippleによる550億XRPのロックアップについては、[Ripple's Insights Blog](https://ripple.com/insights/ripple-to-place-55-billion-xrp-in-escrow-to-ensure-certainty-into-total-xrp-supply/)をご覧ください。
|
||||
|
||||
@@ -36,7 +36,7 @@ Payment Channelでは本来、そこで売買可能なものにいては、一
|
||||
|
||||
## 関連項目
|
||||
|
||||
- [Payment Channelの使用](../../tutorials/how-tos/use-specialized-payment-types/use-payment-channels/index.md): Payment Channelを使用するプロセスを段階的に説明するチュートリアル。
|
||||
- [Payment Channelの使用](../../tutorials/payments/use-payment-channels.md): Payment Channelを使用するプロセスを段階的に説明するチュートリアル。
|
||||
|
||||
- [Escrow](escrow.md): 速度が遅い、条件付きの大量XRP決済のための類似機能。
|
||||
|
||||
|
||||
@@ -1,6 +1,4 @@
|
||||
---
|
||||
parent: concepts.html
|
||||
html: tokens.html
|
||||
seo:
|
||||
description: XRP Ledger上でデジタルな価値を表すトークンを作成することができます。
|
||||
labels:
|
||||
@@ -56,23 +54,4 @@ XRP Ledgerにおけるトークンは、[XRPと異なる性質](../../references
|
||||
|
||||
トークン発行の技術的な手順については、[代替可能トークンの発行](../../tutorials/tokens/fungible-tokens/issue-a-fungible-token.md) をご覧ください。
|
||||
|
||||
## 関連項目
|
||||
|
||||
- **コンセプト:**
|
||||
- [XRP?](../../introduction/what-is-xrp.md)
|
||||
- [クロスカレンシー支払い](../payment-types/cross-currency-payments.md)
|
||||
- [分散型取引所](decentralized-exchange/index.md)
|
||||
- **チュートリアル:**
|
||||
- [代替可能トークンの発行](../../tutorials/tokens/fungible-tokens/issue-a-fungible-token.md)
|
||||
- [XRP Ledgerゲートウェイの開設](../../use-cases/tokenization/stablecoin-issuer.md)
|
||||
- [トランザクションの結果の確認](../transactions/finality-of-results/look-up-transaction-results.md)
|
||||
- [専門化した支払いタイプの使用](../../tutorials/how-tos/use-specialized-payment-types/index.md)
|
||||
- **リファレンス:**
|
||||
- [Paymentトランザクション][]
|
||||
- [TrustSetトランザクション][]
|
||||
- [RippleStateオブジェクト](../../references/protocol/ledger-data/ledger-entry-types/ripplestate.md)
|
||||
- [account_linesメソッド][]
|
||||
- [account_currenciesメソッド][]
|
||||
- [gateway_balancesメソッド][]
|
||||
|
||||
{% raw-partial file="/@l10n/ja/docs/_snippets/common-links.md" /%}
|
||||
|
||||
@@ -16,7 +16,7 @@ labels:
|
||||
1. `AccountSet`を使用して、自分の運用するウォレットを発行者の認可Minterとして割り当てます。[代理Mint](authorizing-another-minter.md)をご覧ください。
|
||||
1. 運用アカウントで`NFTokenMint`を使ってトークンをミントします。運用中のウォレットには、発行者のためにMintされたすべてのトークンが保管されます。[Mintのバッチ処理](batch-minting.md)をご覧ください
|
||||
1. 発行者の認可Minterである自分の運用するウォレットを削除するために、`AccountSet`を使用します。
|
||||
1. 発行者アカウントを"ブラックホール化"する。[マスターキーペアの無効化](../../../tutorials/how-tos/manage-account-settings/disable-master-key-pair.md)をご覧ください。
|
||||
1. 発行者アカウントを"ブラックホール化"する。[マスターキーペアの無効化](../../../tutorials/best-practices/key-management/disable-master-key-pair.md)をご覧ください。
|
||||
|
||||
この時点で、発行者のアドレスを発行アカウントとする新たなトークンのミントは不可能となります。
|
||||
|
||||
|
||||
@@ -446,7 +446,7 @@ TrustSetトランザクションは、[`RippleState`オブジェクト](../../..
|
||||
- [結果のファイナリティー](index.md) - トランザクションの成功また失敗が最終的なものとなるタイミングを判断する方法。(簡単な説明: トランザクションが検証済みレジャーにある場合は、その結果とメタデータは最終的なものです。)
|
||||
- **チュートリアル:**
|
||||
- [信頼できるトランザクションの送信](../reliable-transaction-submission.md)
|
||||
- [WebSocketを使用した着信ペイメントの監視](../../../tutorials/http-websocket-apis/monitor-incoming-payments-with-websocket.md)
|
||||
- [WebSocketを使用した着信ペイメントの監視](../../../tutorials/advanced-developer-topics/client-library-development/monitor-incoming-payments-with-websocket.md)
|
||||
- **リファレンス:**
|
||||
- [レジャーオブジェクトタイプのリファレンス](../../../references/protocol/ledger-data/ledger-entry-types/index.md) - レジャーオブジェクトの使用可能なすべてのタイプのフィールド
|
||||
- [トランザクションのメタデータ](../../../references/protocol/transactions/metadata.md) - メタデータフォーマットとメタデータに表示されるフィールドの概要
|
||||
|
||||
@@ -65,7 +65,7 @@ XRP Ledgerにトランザクションを送信するには、いくつかの手
|
||||
5. `rippled`サーバはそれらのトランザクションを正規順序で前のレジャーに適用し、それらの結果を共有します。
|
||||
6. 十分に[信頼できるバリデータ](../networks-and-servers/rippled-server-modes.md#バリデータ)がまったく同じレジャーを作成した場合、そのレジャーは _検証済み_ であると宣言され、そのレジャーの[トランザクションの結果](../../references/protocol/transactions/transaction-results/index.md)は不変となります。
|
||||
|
||||
XRP決済の送信に関する対話型チュートリアルについては、[Send XRP](../../tutorials/how-tos/send-xrp.md)をご覧ください。
|
||||
XRP決済の送信に関する対話型チュートリアルについては、[Send XRP](../../tutorials/payments/send-xrp.md)をご覧ください。
|
||||
|
||||
|
||||
### 未署名のトランザクションの例
|
||||
@@ -205,7 +205,7 @@ XRP Ledgerは、トランザクションオブジェクトが送信元アドレ
|
||||
- [支払いタイプ](../payment-types/index.md)
|
||||
- **チュートリアル:**
|
||||
- [安全な署名の設定](secure-signing.md)
|
||||
- [XRPの送金](../../tutorials/how-tos/send-xrp.md)
|
||||
- [XRPの送金](../../tutorials/payments/send-xrp.md)
|
||||
- [トランザクションの結果の確認](finality-of-results/look-up-transaction-results.md)
|
||||
- [WebSocketを使用した着信ペイメントの監視](/docs/tutorials/advanced-developer-topics/client-library-development/monitor-incoming-payments-with-websocket.md)
|
||||
- [トランザクションの取り消しまたはスキップ](finality-of-results/canceling-a-transaction.md)
|
||||
|
||||
@@ -158,7 +158,7 @@ For each persisted transaction without validated result:
|
||||
|
||||
{% admonition type="success" name="ヒント" %}[`AccountTxnID`フィールド](../../references/protocol/transactions/common-fields.md#accounttxnid)を使用すると、このような状況で冗長的なトランザクションが成功しないように防ぐことができます。{% /admonition %}
|
||||
|
||||
- 不正使用者に秘密鍵を使われてトランザクションを送信された場合。その場合は、可能であれば[キーペアをローテーション](../../tutorials/how-tos/manage-account-settings/change-or-remove-a-regular-key-pair.md)して、送信された他のトランザクションを確認します。また、ネットワークを監査して、その秘密鍵が大規模な侵入やセキュリティ侵害に関係していたかどうかを判断する必要があります。キーペアのローテーションに成功して、不正使用者がアカウントやシステムにアクセスできなくなったら、通常のアクティビティーを再開します。
|
||||
- 不正使用者に秘密鍵を使われてトランザクションを送信された場合。その場合は、可能であれば[キーペアをローテーション](../../tutorials/best-practices/key-management/change-or-remove-a-regular-key-pair.md)して、送信された他のトランザクションを確認します。また、ネットワークを監査して、その秘密鍵が大規模な侵入やセキュリティ侵害に関係していたかどうかを判断する必要があります。キーペアのローテーションに成功して、不正使用者がアカウントやシステムにアクセスできなくなったら、通常のアクティビティーを再開します。
|
||||
|
||||
#### レジャーのギャップ
|
||||
|
||||
|
||||
@@ -139,7 +139,7 @@ labels:
|
||||
- [マルチシグ](../accounts/multi-signing.md)
|
||||
- **チュートリアル:**
|
||||
- [rippledのインストール](../../infrastructure/installation/index.md)
|
||||
- [レギュラーキーペアの割り当て](../../tutorials/how-tos/manage-account-settings/assign-a-regular-key-pair.md)
|
||||
- [レギュラーキーペアの割り当て](../../tutorials/best-practices/key-management/assign-a-regular-key-pair.md)
|
||||
- [信頼できるトランザクションの送信](reliable-transaction-submission.md)
|
||||
- [パブリック署名の有効化](../../infrastructure/configuration/enable-public-signing.md)
|
||||
- **リファレンス:**
|
||||
|
||||
@@ -42,12 +42,12 @@ _送信元タグ_ と _宛先タグ_ は、XRP Ledgerの[支払い](../payment-t
|
||||
|
||||
## タグの必須化
|
||||
|
||||
複数の顧客口座への支払いを受け取る可能性があるXRP Ledgerアドレスにとって、宛先タグなしで支払いを受け取ることは問題です。どの顧客に入金すべきかがすぐに分からないため、手作業が必要になったり、誰が受取人であったかを特定するために送金者とやり取りをしなければならなくなったりします。このようなケースを減らすために、[`RequireDest`設定を有効にする](../../tutorials/how-tos/manage-account-settings/require-destination-tags.md)ことができます。そうすることで、もしユーザが支払先にタグを設定し忘れた場合、XRP Ledgerはその支払いを拒否します。その後、ユーザはそのタグを使って再度支払いを行うことができます。
|
||||
複数の顧客口座への支払いを受け取る可能性があるXRP Ledgerアドレスにとって、宛先タグなしで支払いを受け取ることは問題です。どの顧客に入金すべきかがすぐに分からないため、手作業が必要になったり、誰が受取人であったかを特定するために送金者とやり取りをしなければならなくなったりします。このようなケースを減らすために、[`RequireDest`設定を有効にする](../../tutorials/compliance-features/require-destination-tags.md)ことができます。そうすることで、もしユーザが支払先にタグを設定し忘れた場合、XRP Ledgerはその支払いを拒否します。その後、ユーザはそのタグを使って再度支払いを行うことができます。
|
||||
|
||||
|
||||
## 関連項目
|
||||
|
||||
- [宛先タグの必須化](../../tutorials/how-tos/manage-account-settings/require-destination-tags.md)
|
||||
- [宛先タグの必須化](../../tutorials/compliance-features/require-destination-tags.md)
|
||||
- [様々なPaymentの種類](../payment-types/index.md)
|
||||
|
||||
{% raw-partial file="/@l10n/ja/docs/_snippets/common-links.md" /%}
|
||||
|
||||
@@ -54,7 +54,7 @@ XRP LedgerをスパムやDoS攻撃から守るため、各トランザクショ
|
||||
|
||||
## ローカル負荷コスト
|
||||
|
||||
各`rippled`サーバには、現在の負荷に基づいてコストしきい値が保持されています。送信するトランザクションの`Fee`値が`rippled`サーバの現在の負荷ベーストランザクションコストより低い場合、そのサーバはトランザクションの適用も中継もしません。(**注記:** [管理者接続](../../tutorials/http-websocket-apis/get-started.md)を介してトランザクションを送信する場合、トランザクションがスケーリングされていない最低トランザクションコストを満たすかぎり、サーバはそのトランザクションを適用し、中継します。)トランザクションの`Fee`値が大半のサーバの要件を満たさないかぎり、そのトランザクションが[コンセンサスプロセス](../consensus-protocol/index.md)を完了する可能性は極めて低くなります。
|
||||
各`rippled`サーバには、現在の負荷に基づいてコストしきい値が保持されています。送信するトランザクションの`Fee`値が`rippled`サーバの現在の負荷ベーストランザクションコストより低い場合、そのサーバはトランザクションの適用も中継もしません。(**注記:** [管理者接続](../../tutorials/get-started/get-started-http-websocket-apis.md)を介してトランザクションを送信する場合、トランザクションがスケーリングされていない最低トランザクションコストを満たすかぎり、サーバはそのトランザクションを適用し、中継します。)トランザクションの`Fee`値が大半のサーバの要件を満たさないかぎり、そのトランザクションが[コンセンサスプロセス](../consensus-protocol/index.md)を完了する可能性は極めて低くなります。
|
||||
|
||||
## オープンレジャーコスト
|
||||
|
||||
|
||||
@@ -117,7 +117,7 @@ labels:
|
||||
- **チュートリアル:**
|
||||
- [rippledの構成](../configuration/index.md)
|
||||
- [rippledのトラブルシューティング](../troubleshooting/index.md)
|
||||
- [rippled APIの使用開始](../../tutorials/http-websocket-apis/get-started.md)
|
||||
- [rippled APIの使用開始](../../tutorials/get-started/get-started-http-websocket-apis.md)
|
||||
- **リファレンス:**
|
||||
- [rippled APIリファレンス](../../references/http-websocket-apis/index.md)
|
||||
- [`rippled`コマンドラインの使用](../commandline-usage.md)
|
||||
|
||||
@@ -56,7 +56,6 @@ labels:
|
||||
- [`rippled`サーバ](../../concepts/networks-and-servers/index.md)
|
||||
- [コンセンサスについて](../../concepts/consensus-protocol/index.md)
|
||||
- **チュートリアル:**
|
||||
- [`rippled` v1.3.xへの移行手順](rippled-1-3-migration-instructions.md) <!-- Note: remove when versions older than v1.3 are basically extinct -->
|
||||
- [rippledのトラブルシューティング](../troubleshooting/index.md)
|
||||
- **リファレンス:**
|
||||
- [rippled APIリファレンス](../../references/http-websocket-apis/index.md)
|
||||
|
||||
@@ -11,34 +11,30 @@ labels:
|
||||
|
||||
このページでは、Ubuntu Linuxで最新リリースの`rippled`に手動で更新する手順を説明します。以下の手順は、[`rippled`がすでにネイティブパッケージを使用してインストール](install-rippled-on-ubuntu.md)されていることを前提としています。可能であれば手動更新ではなく[自動更新](update-rippled-automatically-on-linux.md)を設定することが推奨されます。
|
||||
|
||||
{% admonition type="warning" name="注意" %}Ubuntu Linuxで`rippled` 1.2.xから1.3.1以降にアップグレードするには、[1.3.1への移行手順](rippled-1-3-migration-instructions.md)に従う必要があります。以下の手順は、バージョン1.3.1以降で提供されているネイティブAPTパッケージがインストール済みであることを前提としています。{% /admonition %}
|
||||
|
||||
{% admonition type="success" name="ヒント" %}これらの手順をすべて一度に実行するには、`rippled`パッケージに含まれている`/opt/ripple/bin/update-rippled.sh`スクリプトを実行します。`rippled`バージョン1.3.1以降、このスクリプトはUbuntuおよびDebianと互換性があります。このスクリプトは`sudo`ユーザとして実行する必要があります。{% /admonition %}
|
||||
|
||||
手動で更新するには、以下の手順を実行します。
|
||||
|
||||
1. リポジトリを更新します。
|
||||
|
||||
```
|
||||
$ sudo apt -y update
|
||||
sudo apt -y update
|
||||
```
|
||||
|
||||
2. `rippled`パッケージをアップグレードします。
|
||||
|
||||
```
|
||||
$ sudo apt -y upgrade rippled
|
||||
sudo apt -y upgrade rippled
|
||||
```
|
||||
|
||||
3. `systemd`ユニットファイルを再度読み込みます。
|
||||
|
||||
```
|
||||
$ sudo systemctl daemon-reload
|
||||
sudo systemctl daemon-reload
|
||||
```
|
||||
|
||||
4. `rippled`サービスを再起動します。
|
||||
|
||||
```
|
||||
$ sudo service rippled restart
|
||||
sudo service rippled restart
|
||||
```
|
||||
|
||||
|
||||
@@ -48,7 +44,6 @@ labels:
|
||||
- [`rippled`サーバ](../../concepts/networks-and-servers/index.md)
|
||||
- [コンセンサスについて](../../concepts/consensus-protocol/index.md)
|
||||
- **チュートリアル:**
|
||||
- [`rippled` v1.3.xへの移行手順](rippled-1-3-migration-instructions.md) <!-- Note: remove when versions older than v1.3 are basically extinct -->
|
||||
- [rippledのトラブルシューティング](../troubleshooting/index.md)
|
||||
- **リファレンス:**
|
||||
- [rippled APIリファレンス](../../references/http-websocket-apis/index.md)
|
||||
|
||||
@@ -39,7 +39,6 @@ rippledサーバの管理には、以下のメソッドを使用します。
|
||||
* **[`connect`](peer-management-methods/connect.md)** - rippledサーバを特定のピアに強制的に接続します。
|
||||
* **[`ledger_accept`](server-control-methods/ledger_accept.md)** - スタンドアロンモードでレジャーを閉鎖し、次のレジャーに進みます。
|
||||
* **[`stop`](server-control-methods/stop.md)** - rippledサーバをシャットダウンします。
|
||||
* **[`validation_seed`](server-control-methods/validation_seed.md)** - 検証に使用するキーを一時的に設定します。
|
||||
|
||||
|
||||
## [ステータスおよびデバッグメソッド](status-and-debugging-methods/index.md)
|
||||
|
||||
@@ -227,7 +227,7 @@ rippled account_info rG1QQv2nh2gr7RCZ1P8YYcBUKCCN633jCn validated
|
||||
| `noFreeze` | 真偽値 | `true`の場合、このアカウントは個々のトラストラインをフリーズしたり、グローバルフリーズを行う機能を永久に放棄しています。詳細は[No Freeze](../../../../concepts/tokens/fungible-tokens/freezes.md#no-freeze)をご覧ください。 |
|
||||
| `passwordSpent` | 真偽値 | `false`の場合、このアカウントはトランザクションコスト0の特別な[キーリセットトランザクション](../../../../concepts/transactions/transaction-cost.md#key-resetトランザクション)を送信できます。プロトコルはこのフラグを自動的にオン/オフします。 |
|
||||
| `requireAuthorization` | 真偽値 | `true`の場合、このアカウントは[認可トラストライン](../../../../concepts/tokens/fungible-tokens/authorized-trust-lines.md)を使って、発行するトークンを保持できる人を制限しています。 |
|
||||
| `requireDestinationTag` | 真偽値 | `true`の場合、このアカウントは受け取るすべての支払いに[宛先タグ](../../../../tutorials/how-tos/manage-account-settings/require-destination-tags.md)をリクエストしています。 |
|
||||
| `requireDestinationTag` | 真偽値 | `true`の場合、このアカウントは受け取るすべての支払いに[宛先タグ](../../../../tutorials/compliance-features/require-destination-tags.md)をリクエストしています。 |
|
||||
|
||||
`queue_data`パラメーターが存在する場合、以下のフィールドが含まれます。
|
||||
|
||||
|
||||
@@ -42,7 +42,7 @@ Oracleのレジャーエントリには、単一資産の価格オラクルオ
|
||||
|
||||
| フィールド | JSONの型 | 内部の型 | 必須? | 説明 |
|
||||
|---------------------|-----------|---------------|-----------|-------------|
|
||||
| `Owner` | 文字列 | AccountID | はい | オラクルの更新および削除権限を持つXRPLアカウント。このアカウントで[マルチシグ](../../../../tutorials/how-tos/manage-account-settings/set-up-multi-signing.md)を設定することをお勧めします。 |
|
||||
| `Owner` | 文字列 | AccountID | はい | オラクルの更新および削除権限を持つXRPLアカウント。このアカウントで[マルチシグ](../../../../tutorials/best-practices/key-management/set-up-multi-signing.md)を設定することをお勧めします。 |
|
||||
| `Provider` | 文字列 | Blob | はい | オラクルプロバイダーを識別する任意の値、例えば、Chainlink、Band、またはDIAなど。このフィールドは、最大256文字のASCII 16進エンコード文字(0x20-0x7E)の文字列です。 |
|
||||
| `PriceDataSeries` | 配列 | Array | はい | トークンペアの価格情報を表す、最大10個の`PriceData`オブジェクトの配列。`PriceData`オブジェクトが5個を超える場合、2つの所有者準備金が必要です。 |
|
||||
| `LastUpdateTime` | 数値 | UInt32 | はい | Unix時間で表現された、データの最終更新時刻。 |
|
||||
|
||||
@@ -39,7 +39,7 @@ labels:
|
||||
|
||||
レギュラーキーペアとマスターキーペアの詳細は、[暗号鍵](../../../../concepts/accounts/cryptographic-keys.md)をご覧ください。
|
||||
|
||||
アカウントへのレギュラーキーペアの割り当てについてのチュートリアルは、[レギュラーキーペアの操作](../../../../tutorials/how-tos/manage-account-settings/assign-a-regular-key-pair.md)をご覧ください。
|
||||
アカウントへのレギュラーキーペアの割り当てについてのチュートリアルは、[レギュラーキーペアの操作](../../../../tutorials/best-practices/key-management/assign-a-regular-key-pair.md)をご覧ください。
|
||||
|
||||
セキュリティを強化するために[マルチシグ](../../../../concepts/accounts/multi-signing.md)を使用できますが、マルチシグを使用する場合には[トランザクションコスト][]および[準備金](../../../../concepts/accounts/reserves.md)に追加のXRPが必要となります。
|
||||
|
||||
|
||||
@@ -10,7 +10,7 @@ labels:
|
||||
---
|
||||
# WebSocketを使用した着信ペイメントの監視
|
||||
|
||||
このチュートリアルでは、[WebSocket `rippled` API](../../references/http-websocket-apis/index.md)を使用して、着信[ペイメント](../../concepts/payment-types/index.md)を監視する方法を説明します。すべてのXRP Ledgerトランザクションは公開されているため、誰もが任意のアドレスへの着信ペイメントを監視できます。
|
||||
このチュートリアルでは、[WebSocket `rippled` API](../../../references/http-websocket-apis/index.md)を使用して、着信[ペイメント](../../../concepts/payment-types/index.md)を監視する方法を説明します。すべてのXRP Ledgerトランザクションは公開されているため、誰もが任意のアドレスへの着信ペイメントを監視できます。
|
||||
|
||||
WebSocketは、クライアントとサーバが1つの接続を確立し、その接続を経由して両方向にメッセージを送信するモデルに従います。この接続は、明示的に閉じる(または接続に障害が発生する)まで続きます。これは、リクエストごとにクライアントが新しい接続を開いて閉じるHTTPベースのAPIモデル(JSON-RPCやRESTful APIなど)とは対照的です[¹](#footnote-1)<a id="from-footnote-1"></a>。
|
||||
|
||||
@@ -19,8 +19,8 @@ WebSocketは、クライアントとサーバが1つの接続を確立し、そ
|
||||
## 前提条件
|
||||
|
||||
- このページの例では、すべての主要な最新ブラウザーで使用できるJavaScriptおよびWebSocketプロトコルを使用しています。JavaScriptにある程度習熟し、WebSocketクライアントを使用する他のプログラミング言語の専門知識があれば、選択する言語に手順を適合させながら進めていくことができます。
|
||||
- 安定したインターネット接続と`rippled`サーバへアクセスが必要です。埋め込まれている例では、Rippleの公開サーバのプールに接続します。[独自の`rippled`サーバを運用](../../infrastructure/installation/index.md)する場合は、ローカルでそのサーバに接続することもできます。
|
||||
- 丸め方によるエラーを発生させることなくXRPの価値を適切に処理するには、64ビット符号なし整数で計算できる数値タイプを使用できる必要があります。このチュートリアルの例では、[big.js](https://github.com/MikeMcl/big.js/)を使用しています。[トークン](../../concepts/tokens/index.md)を使用する場合は、さらに高い精度が求められます。詳細は、[通貨の精度](../../references/protocol/data-types/currency-formats.md#xrpの精度)をご覧ください。
|
||||
- 安定したインターネット接続と`rippled`サーバへアクセスが必要です。埋め込まれている例では、Rippleの公開サーバのプールに接続します。[独自の`rippled`サーバを運用](../../../infrastructure/installation/index.md)する場合は、ローカルでそのサーバに接続することもできます。
|
||||
- 丸め方によるエラーを発生させることなくXRPの価値を適切に処理するには、64ビット符号なし整数で計算できる数値タイプを使用できる必要があります。このチュートリアルの例では、[big.js](https://github.com/MikeMcl/big.js/)を使用しています。[トークン](../../../concepts/tokens/index.md)を使用する場合は、さらに高い精度が求められます。詳細は、[通貨の精度](../../../references/protocol/data-types/currency-formats.md#xrpの精度)をご覧ください。
|
||||
|
||||
<!-- Helper for interactive tutorial breadcrumbs -->
|
||||
<script type="application/javascript" src="/vendor/big.min.js"></script>
|
||||
@@ -70,7 +70,7 @@ socket.addEventListener('close', (event) => {
|
||||
const socket = new WebSocket('ws://localhost:6006')
|
||||
```
|
||||
|
||||
{% admonition type="success" name="ヒント" %}デフォルトでは、ローカル`rippled`サーバに接続することで、インターネット上の公開サーバに接続する際に使用できる[パブリックメソッド](../../references/http-websocket-apis/public-api-methods/index.md)以外に、すべての[管理メソッド](../../references/http-websocket-apis/admin-api-methods/index.md)と、[server_info][server_infoメソッド]などの一部のレスポンスに含まれる管理者専用データを利用できます。{% /admonition %}
|
||||
{% admonition type="success" name="ヒント" %}デフォルトでは、ローカル`rippled`サーバに接続することで、インターネット上の公開サーバに接続する際に使用できる[パブリックメソッド](../../../references/http-websocket-apis/public-api-methods/index.md)以外に、すべての[管理メソッド](../../../references/http-websocket-apis/admin-api-methods/index.md)と、[server_info][server_infoメソッド]などの一部のレスポンスに含まれる管理者専用データを利用できます。{% /admonition %}
|
||||
|
||||
例:
|
||||
|
||||
@@ -122,11 +122,11 @@ WebSocket接続では、複数のメッセージをどちらの方向にも送
|
||||
|
||||
- このレスポンスに対するリクエストで指定された`id`に一致する`id`フィールド(レスポンスが順序どおりに到着しない可能性があるため、これは重要です)。
|
||||
|
||||
- APIがリクエストの処理に成功したかどうかを示す`status`フィールド。文字列値`success`は、[成功したレスポンス](../../references/http-websocket-apis/api-conventions/response-formatting.md)を示します。文字列値`error`は、[エラー](../../references/http-websocket-apis/api-conventions/error-formatting.md)を示します。
|
||||
- APIがリクエストの処理に成功したかどうかを示す`status`フィールド。文字列値`success`は、[成功したレスポンス](../../../references/http-websocket-apis/api-conventions/response-formatting.md)を示します。文字列値`error`は、[エラー](../../../references/http-websocket-apis/api-conventions/error-formatting.md)を示します。
|
||||
|
||||
{% admonition type="danger" name="警告" %}トランザクションを送信する際、WebSocketメッセージの先頭にある`success`の`status`は、必ずしもトランザクション自体が成功したことを意味しません。これは、サーバによってリクエストが理解されたということのみを示します。トランザクションの実際の結果を確認するには、[トランザクションの結果の確認](../../concepts/transactions/finality-of-results/look-up-transaction-results.md)をご覧ください。{% /admonition %}
|
||||
{% admonition type="danger" name="警告" %}トランザクションを送信する際、WebSocketメッセージの先頭にある`success`の`status`は、必ずしもトランザクション自体が成功したことを意味しません。これは、サーバによってリクエストが理解されたということのみを示します。トランザクションの実際の結果を確認するには、[トランザクションの結果の確認](../../../concepts/transactions/finality-of-results/look-up-transaction-results.md)をご覧ください。{% /admonition %}
|
||||
|
||||
- [サブスクリプション](../../references/http-websocket-apis/public-api-methods/subscription-methods/subscribe.md)からのフォローアップメッセージの場合、`type`は、新しいトランザクション、レジャーまたは検証の通知など、フォローアップメッセージのタイプを示します。または継続している[pathfindingリクエスト](../../references/http-websocket-apis/public-api-methods/path-and-order-book-methods/path_find.md)のフォローアップを示します。クライアントがこれらのメッセージを受信するのは、それらをサブスクライブしている場合のみです。
|
||||
- [サブスクリプション](../../../references/http-websocket-apis/public-api-methods/subscription-methods/subscribe.md)からのフォローアップメッセージの場合、`type`は、新しいトランザクション、レジャーまたは検証の通知など、フォローアップメッセージのタイプを示します。または継続している[pathfindingリクエスト](../../../references/http-websocket-apis/public-api-methods/path-and-order-book-methods/path_find.md)のフォローアップを示します。クライアントがこれらのメッセージを受信するのは、それらをサブスクライブしている場合のみです。
|
||||
|
||||
{% admonition type="success" name="ヒント" %}[JavaScript向けxrpl.js](https://js.xrpl.org/)は、デフォルトでこのステップに対応しています。すべての非同期APIリクエストはPromiseを使用してレスポンスを提供します。また[`.on(event, callback)`メソッド](https://js.xrpl.org/classes/Client.html#on)を使用して、ストリームをリッスンできます。{% /admonition %}
|
||||
|
||||
@@ -339,31 +339,31 @@ WS_HANDLERS["transaction"] = log_tx
|
||||
|
||||
## 4. 着信ペイメントの読み取り
|
||||
|
||||
アカウントをサブスクライブすると、 _アカウントへのすべてのトランザクションとアカウントからのすべてのトランザクション_ 、および _アカウントに間接的に影響を及ぼすトランザクション_ に関するメッセージが表示されます。この例として、[トークン](../../concepts/tokens/index.md)の取引があります。アカウントが着信ペイメントを受け取った日時を認識することを目的とする場合、トランザクションストリームを絞り込んで、実際に支払われた額に基づいて支払いを処理する必要があります。以下の情報を探します。
|
||||
アカウントをサブスクライブすると、 _アカウントへのすべてのトランザクションとアカウントからのすべてのトランザクション_ 、および _アカウントに間接的に影響を及ぼすトランザクション_ に関するメッセージが表示されます。この例として、[トークン](../../../concepts/tokens/index.md)の取引があります。アカウントが着信ペイメントを受け取った日時を認識することを目的とする場合、トランザクションストリームを絞り込んで、実際に支払われた額に基づいて支払いを処理する必要があります。以下の情報を探します。
|
||||
|
||||
- **`validated`フィールド**は、トランザクションの結果が[最終的である](../../concepts/transactions/finality-of-results/index.md)ことを示します。これは、`accounts`をサブスクライブする場合に常に当てはまりますが、`accounts_proposed`または`transactions_proposed`ストリーム _も_ サブスクライブしている場合は、サーバは未確認のトランザクションに関して同様のメッセージを同じ接続で送信します。予防策として、`validated`フィールドを常に確認することをお勧めします。
|
||||
- **`validated`フィールド**は、トランザクションの結果が[最終的である](../../../concepts/transactions/finality-of-results/index.md)ことを示します。これは、`accounts`をサブスクライブする場合に常に当てはまりますが、`accounts_proposed`または`transactions_proposed`ストリーム _も_ サブスクライブしている場合は、サーバは未確認のトランザクションに関して同様のメッセージを同じ接続で送信します。予防策として、`validated`フィールドを常に確認することをお勧めします。
|
||||
|
||||
- **`meta.TransactionResult`フィールド**は、[トランザクションの結果](../../references/protocol/transactions/transaction-results/index.md)です。結果が`tesSUCCESS`でない場合は、トランザクションは失敗したため、値を送信できません。
|
||||
- **`meta.TransactionResult`フィールド**は、[トランザクションの結果](../../../references/protocol/transactions/transaction-results/index.md)です。結果が`tesSUCCESS`でない場合は、トランザクションは失敗したため、値を送信できません。
|
||||
|
||||
- **`transaction.Account`** フィールドはトランザクションの送信元です。他の人が送信したトランザクションのみを探している場合は、このフィールドがあなたのアドレスと一致するトランザクションを無視できます(自身に対するクロスカレンシー支払いが _可能である_ 点に注意してください)。
|
||||
|
||||
- **`transaction.TransactionType`フィールド**はトランザクションのタイプです。アカウントに通貨を送金できる可能性があるトランザクションのタイプは以下のとおりです。
|
||||
|
||||
- **[Paymentトランザクション][]** はXRPまたは[トークン](../../concepts/tokens/index.md)を送金できます。受取人のアドレスを含んでいる`transaction.Destination`フィールドによってこれらを絞り込み、必ず`meta.delivered_amount`を使用して実際に支払われた額を確認します。XRPの額は、[文字列のフォーマットで記述されます](../../references/protocol/data-types/basic-data-types.md#通貨額の指定)。
|
||||
- **[Paymentトランザクション][]** はXRPまたは[トークン](../../../concepts/tokens/index.md)を送金できます。受取人のアドレスを含んでいる`transaction.Destination`フィールドによってこれらを絞り込み、必ず`meta.delivered_amount`を使用して実際に支払われた額を確認します。XRPの額は、[文字列のフォーマットで記述されます](../../../references/protocol/data-types/basic-data-types.md#通貨額の指定)。
|
||||
|
||||
{% admonition type="danger" name="警告" %}代わりに`transaction.Amount`フィールドを使用すると、[Partial Paymentの悪用](../../concepts/payment-types/partial-payments.md#partial-paymentの悪用)に対して脆弱になる可能性があります。不正使用者はこの悪用を行ってあなたをだまし、あなたが支払ったよりも多くの金額を交換または引き出すことができます。{% /admonition %}
|
||||
{% admonition type="danger" name="警告" %}代わりに`transaction.Amount`フィールドを使用すると、[Partial Paymentの悪用](../../../concepts/payment-types/partial-payments.md#partial-paymentの悪用)に対して脆弱になる可能性があります。不正使用者はこの悪用を行ってあなたをだまし、あなたが支払ったよりも多くの金額を交換または引き出すことができます。{% /admonition %}
|
||||
|
||||
- **[CheckCashトランザクション][]**では、アカウントは別のアカウントの[CheckCreateトランザクション][]によって承認された金額を受け取ることができます。**CheckCashトランザクション**のメタデータを確認すると、アカウントが受け取った通貨の額を確認できます。
|
||||
|
||||
- **[EscrowFinishトランザクション][]** は、以前の[EscrowCreateトランザクション][]によって作成された[Escrow](../../concepts/payment-types/escrow.md)を終了することでXRPを送金できます。**EscrowFinishトランザクション**のメタデータを確認すると、escrowからXRPを受け取ったアカウントと、その額を確認できます。
|
||||
- **[EscrowFinishトランザクション][]** は、以前の[EscrowCreateトランザクション][]によって作成された[Escrow](../../../concepts/payment-types/escrow.md)を終了することでXRPを送金できます。**EscrowFinishトランザクション**のメタデータを確認すると、escrowからXRPを受け取ったアカウントと、その額を確認できます。
|
||||
|
||||
- **[OfferCreateトランザクション][]** はアカウントがXRP Ledgerの[分散型取引所](../../concepts/tokens/decentralized-exchange/index.md)で以前発行したオファーを消費することで、XRPまたはトークンを送金できます。オファーを発行しないと、この方法で金額を受け取ることはできません。メタデータを確認して、アカウントが受け取った通貨(この情報がある場合)と、金額を確認します。
|
||||
- **[OfferCreateトランザクション][]** はアカウントがXRP Ledgerの[分散型取引所](../../../concepts/tokens/decentralized-exchange/index.md)で以前発行したオファーを消費することで、XRPまたはトークンを送金できます。オファーを発行しないと、この方法で金額を受け取ることはできません。メタデータを確認して、アカウントが受け取った通貨(この情報がある場合)と、金額を確認します。
|
||||
|
||||
- **[PaymentChannelClaimトランザクション][]** では、[Payment Channel](../../concepts/payment-types/payment-channels.md)からXRPを送金できます。メタデータを確認して、トランザクションからXRPを受け取ったアカウント(この情報がある場合)を確認します。
|
||||
- **[PaymentChannelClaimトランザクション][]** では、[Payment Channel](../../../concepts/payment-types/payment-channels.md)からXRPを送金できます。メタデータを確認して、トランザクションからXRPを受け取ったアカウント(この情報がある場合)を確認します。
|
||||
|
||||
- **[PaymentChannelFundトランザクション][]** は、閉鎖された(期限切れの)Payment Channelから送金元にXRPを返金することができます。
|
||||
|
||||
- **`meta`フィールド**には、1つまたは複数の通貨の種類とその正確な金額、その送金先などを示す[トランザクションメタデータ](../../references/protocol/transactions/metadata.md)が示されています。トランザクションメタデータを理解する方法の詳細は、[トランザクションの結果の確認](../../concepts/transactions/finality-of-results/look-up-transaction-results.md)をご覧ください。
|
||||
- **`meta`フィールド**には、1つまたは複数の通貨の種類とその正確な金額、その送金先などを示す[トランザクションメタデータ](../../../references/protocol/transactions/metadata.md)が示されています。トランザクションメタデータを理解する方法の詳細は、[トランザクションの結果の確認](../../../concepts/transactions/finality-of-results/look-up-transaction-results.md)をご覧ください。
|
||||
|
||||
以下のサンプルコードは、上に示したすべてのトランザクションのタイプのトランザクションメタデータを確認し、アカウントが受け取ったXRPの金額をレポートします。
|
||||
|
||||
@@ -474,9 +474,9 @@ $("#tx_read").click((event) => {
|
||||
|
||||
## 次のステップ
|
||||
|
||||
- [トランザクションの結果の確認](../../concepts/transactions/finality-of-results/look-up-transaction-results.md)で、トランザクションの実行内容を確認し、適切に対応するソフトウェアを構築します。
|
||||
- あなた自身のアドレスから[XRPの送金](../how-tos/send-xrp.md)を試します。
|
||||
- [Escrow](../../concepts/payment-types/escrow.md)、[Checks](../../concepts/payment-types/checks.md)または[Payment Channel](../../concepts/payment-types/payment-channels.md)のような高度なタイプのトランザクションの監視と着信通知へのレスポンスを試します。
|
||||
- [トランザクションの結果の確認](../../../concepts/transactions/finality-of-results/look-up-transaction-results.md)で、トランザクションの実行内容を確認し、適切に対応するソフトウェアを構築します。
|
||||
- あなた自身のアドレスから[XRPの送金](../../payments/send-xrp.md)を試します。
|
||||
- [Escrow](../../../concepts/payment-types/escrow.md)、[Checks](../../../concepts/payment-types/checks.md)または[Payment Channel](../../../concepts/payment-types/payment-channels.md)のような高度なタイプのトランザクションの監視と着信通知へのレスポンスを試します。
|
||||
<!--{# TODO: uncomment when it's ready. - To more robustly handle internet instability, [Follow a Transaction Chain](follow-a-transaction-chain.html) to detect if you missed a notification. #}-->
|
||||
|
||||
## その他のプログラミング言語
|
||||
@@ -500,14 +500,14 @@ $("#tx_read").click((event) => {
|
||||
## 関連項目
|
||||
|
||||
- **コンセプト:**
|
||||
- [トランザクション](../../concepts/transactions/index.md)
|
||||
- [結果のファイナリティー](../../concepts/transactions/finality-of-results/index.md) - トランザクションの成功また失敗が最終的なものとなるタイミングを判断する方法(簡単な説明: トランザクションが検証済みレジャーにある場合は、その結果とメタデータは最終的なものです)。
|
||||
- [トランザクション](../../../concepts/transactions/index.md)
|
||||
- [結果のファイナリティー](../../../concepts/transactions/finality-of-results/index.md) - トランザクションの成功また失敗が最終的なものとなるタイミングを判断する方法(簡単な説明: トランザクションが検証済みレジャーにある場合は、その結果とメタデータは最終的なものです)。
|
||||
- **チュートリアル:**
|
||||
- [信頼できるトランザクションの送信](../../concepts/transactions/reliable-transaction-submission.md)
|
||||
- [トランザクションの結果の確認](../../concepts/transactions/finality-of-results/look-up-transaction-results.md)
|
||||
- [信頼できるトランザクションの送信](../../../concepts/transactions/reliable-transaction-submission.md)
|
||||
- [トランザクションの結果の確認](../../../concepts/transactions/finality-of-results/look-up-transaction-results.md)
|
||||
- **リファレンス:**
|
||||
- [トランザクションのタイプ](../../references/protocol/transactions/types/index.md)
|
||||
- [トランザクションのメタデータ](../../references/protocol/transactions/metadata.md) - メタデータフォーマットとメタデータに表示されるフィールドの概要
|
||||
- [トランザクションの結果](../../references/protocol/transactions/transaction-results/index.md) - トランザクションのすべての結果コードを掲載した表一覧
|
||||
- [トランザクションのタイプ](../../../references/protocol/transactions/types/index.md)
|
||||
- [トランザクションのメタデータ](../../../references/protocol/transactions/metadata.md) - メタデータフォーマットとメタデータに表示されるフィールドの概要
|
||||
- [トランザクションの結果](../../../references/protocol/transactions/transaction-results/index.md) - トランザクションのすべての結果コードを掲載した表一覧
|
||||
|
||||
{% raw-partial file="/@l10n/ja/docs/_snippets/common-links.md" /%}
|
||||
@@ -18,7 +18,7 @@ labels:
|
||||
オフライン署名を使用するには、次の前提条件を満たしている必要があります。
|
||||
|
||||
- オフラインマシンとして使用する1台のコンピュータを用意していること。このマシンは[サポートされているオペレーティングシステム](../../../infrastructure/installation/system-requirements.md)でセットアップされている必要があります。オフラインセットアップの手順については、使用するオペレーティングシステムのサポートをご覧ください(例: [Red Hat Enterprise Linux DVD ISOインストール手順](https://access.redhat.com/solutions/7227))。使用するソフトウェアと物理メディアがマルウェアに感染していないことを確認します。
|
||||
- オンラインマシンとして使用する別のコンピュータを用意していること。このマシンは`rippled`を実行する必要はありませんが、XRP Ledgerネットワークに接続し、共有レジャーの状態についての正確な情報を受信できる必要があります。例えば、[公開サーバへのWebSocket接続](../../http-websocket-apis/get-started.md)を使用できます。
|
||||
- オンラインマシンとして使用する別のコンピュータを用意していること。このマシンは`rippled`を実行する必要はありませんが、XRP Ledgerネットワークに接続し、共有レジャーの状態についての正確な情報を受信できる必要があります。例えば、[公開サーバへのWebSocket接続](../../get-started/get-started-http-websocket-apis.md)を使用できます。
|
||||
- 署名済みのトランザクションバイナリデータをオフラインマシンからオンラインマシンに転送する安全な方法を用意していること。
|
||||
- その方法の1つは、オフラインマシンでQRコードジェネレーターを使用し、オンラインマシンでQRコードスキャナーを使用することです。(この場合、「オンラインマシン」はスマートフォンなどの携帯デバイスだとよいでしょう。)
|
||||
- 別の方法としては、物理メディアを使ってオフラインマシンからオンラインマシンにファイルをコピーします。この方法を使用する場合、オフラインマシンが悪意のあるソフトウェアに感染するおそれのある物理メディアは使用しないよう注意します。(例えば、オンラインマシンとオフラインマシンで同じUSBドライブを再利用しないようにします。)
|
||||
@@ -140,7 +140,7 @@ Loading: "/etc/opt/ripple/rippled.cfg"
|
||||
オフラインマシンで、アカウントの設定用のトランザクションを準備して署名します。詳細は、アカウントを使用する目的によって異なります。例えば次のようなことができます。
|
||||
|
||||
- 定期的なローテーションで使用できる[レギュラーキーペアを割り当てる](assign-a-regular-key-pair.md)。
|
||||
- ユーザが送金理由や送金相手をタグ付けせずに送金できないようにするために、[宛先タグを要求する](require-destination-tags.md)。
|
||||
- ユーザが送金理由や送金相手をタグ付けせずに送金できないようにするために、[宛先タグを要求する](../../compliance-features/require-destination-tags.md)。
|
||||
- アカウントセキュリティを強化するために、[マルチシグを設定する](set-up-multi-signing.md)。
|
||||
- 明示的に承認した送金、または事前に承認した相手からの送金のみを受け取れるようにするために、[DepositAuthを有効にする](../../../concepts/accounts/depositauth.md)。
|
||||
- ユーザがあなたの許可なくあなたへの[トラストライン](../../../concepts/tokens/fungible-tokens/index.md)を開けないようにするために、[RequireAuthを有効にする](../../../concepts/tokens/fungible-tokens/authorized-trust-lines.md#requireauthの有効化)。XRP Ledgerの分散型取引所やトークン機能を使用する予定がない場合は、これを対策として行うことをお勧めします。
|
||||
@@ -251,7 +251,7 @@ TicketCreateトランザクションをすぐに送信する予定がない場
|
||||
|
||||
チケットの主な使用例としては、複数の[マルチシグ](../../../concepts/accounts/multi-signing.md)を並行して集めることができます。チケットを使用することで、複数署名されたトランザクションが完全に署名されて準備が整った時点で、どれが先に準備されるかを気にすることなく送信することができます。
|
||||
|
||||
このシナリオでは、[step8,「チケット付きトランザクションの準備」](#8-チケット付きトランザクションの準備)が若干異なります。準備と署名を一度に行うのではなく、[任意のマルチシグトランザクションの送信](send-a-multi-signed-transaction.md)の手順に従うことになります。まずトランザクションを準備し、次に信頼できる署名者の間でトランザクションを循環させて署名を集め、最後に署名を組み合わせて最終的なマルチシグトランザクションを作成します。
|
||||
このシナリオでは、[step8,「チケット付きトランザクションの準備」](#8-チケット付きトランザクションの準備)が若干異なります。準備と署名を一度に行うのではなく、[任意のマルチシグトランザクションの送信](../key-management/send-a-multi-signed-transaction.md)の手順に従うことになります。まずトランザクションを準備し、次に信頼できる署名者の間でトランザクションを循環させて署名を集め、最後に署名を組み合わせて最終的なマルチシグトランザクションを作成します。
|
||||
|
||||
複数の異なるトランザクションを処理する場合、それぞれが異なるチケットを使用する限り、この作業を並行して行うことができます。
|
||||
|
||||
@@ -262,7 +262,7 @@ TicketCreateトランザクションをすぐに送信する予定がない場
|
||||
- [チケット](../../../concepts/accounts/tickets.md)
|
||||
- [マルチシグ](../../../concepts/accounts/multi-signing.md)
|
||||
- **Tutorials:**
|
||||
- [マルチシグの設定](set-up-multi-signing.md)
|
||||
- [マルチシグの設定](../key-management/set-up-multi-signing.md)
|
||||
- [信頼出来るトランザクションの送信](../../../concepts/transactions/reliable-transaction-submission.md)
|
||||
- **References:**
|
||||
- [account_objectsメソッド][]
|
||||
@@ -1,91 +0,0 @@
|
||||
---
|
||||
html: require-destination-tags.html
|
||||
parent: manage-account-settings.html
|
||||
seo:
|
||||
description: ユーザがあなたのアドレスに送金するときに宛先タグを必ず指定しなければならないようにします。
|
||||
labels:
|
||||
- アカウント
|
||||
---
|
||||
# 宛先タグの必須化
|
||||
|
||||
`RequireDest`設定は、送金先を識別する[宛先タグ](../../../concepts/transactions/source-and-destination-tags.md)を顧客が付け忘れている場合にあなたのアドレスに[送金](../../../concepts/payment-types/index.md)できないようにするためのものです。有効にすると、XRP Ledgerは宛先タグが付いていないあなたのアドレスへの送金を拒否します。
|
||||
|
||||
以下は、ローカルでホストされている`rippled`の[submitメソッド][]を使用して、`RequireDest`フラグを有効にする[AccountSetトランザクション][]を送信する例です。
|
||||
|
||||
リクエスト:
|
||||
|
||||
{% tabs %}
|
||||
|
||||
{% tab label="JSON-RPC" %}
|
||||
```json
|
||||
POST http://localhost:5005/
|
||||
Content-Type: application/json
|
||||
|
||||
{
|
||||
"method": "submit",
|
||||
"params": [
|
||||
{
|
||||
"secret": "sn3nxiW7v8KXzPzAqzyHXbSSKNuN9",
|
||||
"tx_json": {
|
||||
"Account": "rf1BiGeXwwQoi8Z2ueFYTEXSwuJYfV2Jpn",
|
||||
"Fee": "15000",
|
||||
"Flags": 0,
|
||||
"SetFlag": 1,
|
||||
"TransactionType": "AccountSet"
|
||||
}
|
||||
}
|
||||
]
|
||||
}
|
||||
```
|
||||
{% /tab %}
|
||||
|
||||
{% /tabs %}
|
||||
|
||||
レスポンス:
|
||||
|
||||
{% tabs %}
|
||||
|
||||
{% tab label="JSON-RPC" %}
|
||||
```json
|
||||
200 OK
|
||||
|
||||
{
|
||||
"result" : {
|
||||
"deprecated" : "Signing support in the 'submit' command has been deprecated and will be removed in a future version of the server. Please migrate to a standalone signing tool.",
|
||||
"engine_result" : "tesSUCCESS",
|
||||
"engine_result_code" : 0,
|
||||
"engine_result_message" : "The transaction was applied. Only final in a validated ledger.",
|
||||
"status" : "success",
|
||||
"tx_blob" : "12000322000000002400000179202100000001684000000000003A98732103AB40A0490F9B7ED8DF29D246BF2D6269820A0EE7742ACDD457BEA7C7D0931EDB7446304402201C430B4C29D0A0AB94286AE55FB9981B00F84C7985AF4BD44570782C5E0C5E290220363B68B81580231B32176F8C477B822ECB9EC673B84237BEF15BE6F59108B97D81144B4E9C06F24296074F7BC48F92A97916C6DC5EA9",
|
||||
"tx_json" : {
|
||||
"Account" : "rf1BiGeXwwQoi8Z2ueFYTEXSwuJYfV2Jpn",
|
||||
"Fee" : "15000",
|
||||
"Flags" : 0,
|
||||
"Sequence" : 377,
|
||||
"SetFlag" : 1,
|
||||
"SigningPubKey" : "03AB40A0490F9B7ED8DF29D246BF2D6269820A0EE7742ACDD457BEA7C7D0931EDB",
|
||||
"TransactionType" : "AccountSet",
|
||||
"TxnSignature" : "304402201C430B4C29D0A0AB94286AE55FB9981B00F84C7985AF4BD44570782C5E0C5E290220363B68B81580231B32176F8C477B822ECB9EC673B84237BEF15BE6F59108B97D",
|
||||
"hash" : "3F2B233907BE9EC51AE1C822EC0B6BB0965EFD2400B218BE988DDA9529F53CA4"
|
||||
}
|
||||
}
|
||||
}
|
||||
```
|
||||
{% /tab %}
|
||||
|
||||
{% /tabs %}
|
||||
|
||||
|
||||
## 関連項目
|
||||
|
||||
- **コンセプト:**
|
||||
- [アカウント](../../../concepts/accounts/index.md)
|
||||
- [送信元と宛先タグ](../../../concepts/transactions/source-and-destination-tags.md)
|
||||
- [トランザクションコスト](../../../concepts/transactions/transaction-cost.md)
|
||||
- [支払いタイプ](../../../concepts/payment-types/index.md)
|
||||
- **リファレンス:**
|
||||
- [account_infoメソッド][]
|
||||
- [AccountSetトランザクション][]
|
||||
- [AccountRootのフラグ](../../../references/protocol/ledger-data/ledger-entry-types/accountroot.md#accountrootのフラグ)
|
||||
|
||||
{% raw-partial file="/@l10n/ja/docs/_snippets/common-links.md" /%}
|
||||
@@ -327,7 +327,6 @@ XrplClient xrplClient = new XrplClient(rippledUrl);
|
||||
|
||||
- 本番システム向けに[信頼できるトランザクションの送信](../../concepts/transactions/reliable-transaction-submission.md)を構築する
|
||||
- [xrpl.jsリファレンス](https://js.xrpl.org/)を参照して、XRP Ledgerの全機能を確認する
|
||||
- [アカウント設定](../how-tos/manage-account-settings/index.md)をカスタマイズする
|
||||
- [トランザクションのメタデータ](../../references/protocol/transactions/metadata.md)にトランザクションの結果の詳細がどのように記述されているかを知る
|
||||
- escrowやPayment Channelなどの[複雑な支払いタイプ](../../concepts/payment-types/index.md)について調べる
|
||||
|
||||
@@ -9,9 +9,9 @@ labels:
|
||||
---
|
||||
# Payment Channelの使用
|
||||
|
||||
Payment Channelは、少額の単位に分割可能な「非同期」のXRPペイメントを送信し、後日決済する高度な機能です。このチュートリアルでは、全体的な[Payment Channel](../../../../concepts/payment-types/payment-channels.md)の使用方法を、ローカル`rippled`サーバの[JSON-RPC API](../../../../references/http-websocket-apis/index.md)を使用する例を使って説明します。
|
||||
Payment Channelは、少額の単位に分割可能な「非同期」のXRPペイメントを送信し、後日決済する高度な機能です。このチュートリアルでは、全体的な[Payment Channel](../../concepts/payment-types/payment-channels.md)の使用方法を、ローカル`rippled`サーバの[JSON-RPC API](../../references/http-websocket-apis/index.md)を使用する例を使って説明します。
|
||||
|
||||
このチュートリアルを進めるにあたって[資金供給されているXRP Ledgerアカウント](../../../../concepts/accounts/index.md)を所有するユーザが2名いれば理想的です。ただし、2つのXRP Ledgerアドレスを管理する1名のユーザとしてこのチュートリアルを進めることもできます。
|
||||
このチュートリアルを進めるにあたって[資金供給されているXRP Ledgerアカウント](../../concepts/accounts/index.md)を所有するユーザが2名いれば理想的です。ただし、2つのXRP Ledgerアドレスを管理する1名のユーザとしてこのチュートリアルを進めることもできます。
|
||||
|
||||
## サンプルの値
|
||||
|
||||
@@ -58,9 +58,9 @@ Payment Channelに使用できるXRPの額に制限はありません。この
|
||||
|
||||
{% admonition type="success" name="ヒント" %}「決済遅延」の設定だけが決済を遅延するわけでわありません。レジャーバージョンが閉鎖すると即時に決済が遅延されます(3~5秒)。「決済遅延」とは、Channel閉鎖の強制的な遅延です。これにより、受取人が決済を完了できるようになります。{% /admonition %}
|
||||
|
||||
以下の例は、JSON-RPC APIを使用してローカル`rippled`サーバへ[送信](../../../../references/http-websocket-apis/public-api-methods/transaction-methods/submit.md#署名と送信モード)することでPayment Channelを作成する方法を示しています。Payment Channelは、決済を1日遅らせて[サンプルの支払人](#サンプルの値)(rN7n7...)から[サンプルの受取人](#サンプルの値)(rf1Bi...)に100 XRPを割り当てます。公開鍵はサンプルの支払人のマスター公開鍵(16進数)です。
|
||||
以下の例は、JSON-RPC APIを使用してローカル`rippled`サーバへ[送信](../../references/http-websocket-apis/public-api-methods/transaction-methods/submit.md#署名と送信モード)することでPayment Channelを作成する方法を示しています。Payment Channelは、決済を1日遅らせて[サンプルの支払人](#サンプルの値)(rN7n7...)から[サンプルの受取人](#サンプルの値)(rf1Bi...)に100 XRPを割り当てます。公開鍵はサンプルの支払人のマスター公開鍵(16進数)です。
|
||||
|
||||
{% admonition type="info" name="注記" %}Payment Channelは1つのオブジェクトとして支払人の[所有者準備金](../../../../concepts/accounts/reserves.md#所有者準備金)に反映されます。所有者は少なくとも、Payment Channelに割り当てられたXRPを差引き後に、準備金を維持するのに十分なXRPを保有している必要があります。{% /admonition %}
|
||||
{% admonition type="info" name="注記" %}Payment Channelは1つのオブジェクトとして支払人の[所有者準備金](../../concepts/accounts/reserves.md#所有者準備金)に反映されます。所有者は少なくとも、Payment Channelに割り当てられたXRPを差引き後に、準備金を維持するのに十分なXRPを保有している必要があります。{% /admonition %}
|
||||
|
||||
リクエスト:
|
||||
|
||||
@@ -170,9 +170,9 @@ Content-Type: application/json
|
||||
支払人はJSON-RPCからのレスポンスで以下を確認する必要があります。
|
||||
|
||||
- トランザクションの`meta`フィールドで、`TransactionResult`が`tesSUCCESS`であることを確認します。
|
||||
- データが検証済みレジャーのデータであることを示す`"validated":true`がレスポンスに含まれていることを確認します。(結果`tesSUCCESS`は、検証済みレジャーバージョンに記録されている場合にのみ[最終的な](../../../../concepts/transactions/finality-of-results/index.md)結果です。)
|
||||
- データが検証済みレジャーのデータであることを示す`"validated":true`がレスポンスに含まれていることを確認します。(結果`tesSUCCESS`は、検証済みレジャーバージョンに記録されている場合にのみ[最終的な](../../concepts/transactions/finality-of-results/index.md)結果です。)
|
||||
- トランザクションの`meta`フィールドの`AffectedNodes`配列で、`LedgerEntryType`が`PayChannel`である`CreatedNode`オブジェクトを検索します。`CreatedNode`オブジェクトの`LedgerIndex`フィールドはChannel IDを示します。(上記の例では、これは「5DB0...」で始まる16進文字列です。)Channel IDは、後でクレームに署名する際に必要です。
|
||||
PayChannelレジャーオブジェクトタイプの詳細については、[PayChannelレジャーオブジェクト](../../../../references/protocol/ledger-data/ledger-entry-types/paychannel.md)をご覧ください。
|
||||
PayChannelレジャーオブジェクトタイプの詳細については、[PayChannelレジャーオブジェクト](../../references/protocol/ledger-data/ledger-entry-types/paychannel.md)をご覧ください。
|
||||
|
||||
|
||||
## 2. 受取人がPayment Channelの特性を確認します。
|
||||
@@ -455,7 +455,7 @@ Content-Type: application/json
|
||||
}
|
||||
```
|
||||
|
||||
受取人は検証済みレジャーでこのトランザクションが正常に処理されたことを確認します。詳細は、[確実なトランザクションの送信](../../../../concepts/transactions/reliable-transaction-submission.md)をご覧ください。
|
||||
受取人は検証済みレジャーでこのトランザクションが正常に処理されたことを確認します。詳細は、[確実なトランザクションの送信](../../concepts/transactions/reliable-transaction-submission.md)をご覧ください。
|
||||
|
||||
## 9. 支払人と受取人の取引完了後、支払人はChannelの閉鎖を要求します。
|
||||
|
||||
@@ -467,7 +467,7 @@ ChannelにXRPが _残っている_ 場合は、このChannelの閉鎖要求は
|
||||
|
||||
また、受取人はクレームの処理完了直後にPayment Channelを閉鎖できます _([フローチャート][]の9b)_。
|
||||
|
||||
Channelの閉鎖を要求する[トランザクションを送信する](../../../../references/http-websocket-apis/public-api-methods/transaction-methods/submit.md#署名と送信モード)例:
|
||||
Channelの閉鎖を要求する[トランザクションを送信する](../../references/http-websocket-apis/public-api-methods/transaction-methods/submit.md#署名と送信モード)例:
|
||||
|
||||
```
|
||||
{
|
||||
@@ -518,13 +518,13 @@ Channelの閉鎖を要求する[トランザクションを送信する](../../.
|
||||
|
||||
決済遅延が経過するか、またはChannelが予定されている有効期限に達したら、Channelは有効期限切れになります。それ以降に行われるこのChannelに影響するトランザクションはすべて、Channelを閉鎖するだけであり、未請求のXRPは支払人に返金されます。
|
||||
|
||||
Channelは期限切れ状態で永久にレジャーに残ることがあります。これは、レジャーはトランザクションの結果によってのみ変わるので、_誰かが_ 有効期限切れのChannelを閉鎖するトランザクションを送信する必要があるためです。Channelがレジャーに残っている限り、そのChannelは[所有者準備金](../../../../concepts/accounts/reserves.md#所有者準備金)の点から支払人が所有するオブジェクトと見なされます。
|
||||
Channelは期限切れ状態で永久にレジャーに残ることがあります。これは、レジャーはトランザクションの結果によってのみ変わるので、_誰かが_ 有効期限切れのChannelを閉鎖するトランザクションを送信する必要があるためです。Channelがレジャーに残っている限り、そのChannelは[所有者準備金](../../concepts/accounts/reserves.md#所有者準備金)の点から支払人が所有するオブジェクトと見なされます。
|
||||
|
||||
このため、支払人には`tfClose`フラグを指定した2番目の[PaymentChannelClaimトランザクション][]を送信することが推奨されます。ただしその他のアカウント(Payment Channelに関与するアカウントを含む)は有効期限切れのChannelを閉鎖できません。
|
||||
|
||||
このトランザクションを送信するコマンドは、Channelの有効期限切れをリクエストする前述の例と同じです。(ただしコマンドの実行結果である[自動入力](../../../../references/protocol/transactions/common-fields.md#自動入力可能なフィールド) `Sequence`番号、署名、識別用ハッシュは一意です。)
|
||||
このトランザクションを送信するコマンドは、Channelの有効期限切れをリクエストする前述の例と同じです。(ただしコマンドの実行結果である[自動入力](../../references/protocol/transactions/common-fields.md#自動入力可能なフィールド) `Sequence`番号、署名、識別用ハッシュは一意です。)
|
||||
|
||||
有効期限切れのChannelを閉鎖するトランザクションを[送信する](../../../../references/http-websocket-apis/public-api-methods/transaction-methods/submit.md#署名と送信モード)例:
|
||||
有効期限切れのChannelを閉鎖するトランザクションを[送信する](../../references/http-websocket-apis/public-api-methods/transaction-methods/submit.md#署名と送信モード)例:
|
||||
|
||||
```
|
||||
{
|
||||
@@ -42,14 +42,14 @@ Checkは、デポジット認可が有効な場合、シンプルで親しみや
|
||||
|
||||
この方法は最もシンプルですが、資金が保証されるわけではありません。Checkは後払いであり、Checkを現金化しようとする瞬間まで資金は動きません。Checkを現金化するときに、送金側のアカウントに必要な資金がない可能性があり、ビジネスによっては遅延やその他の問題を引き起こす可能性があります。
|
||||
|
||||
[Checkの利用](../../tutorials/how-tos/use-specialized-payment-types/use-checks/index.md)をご覧ください。
|
||||
[Checkの利用](../../tutorials/payments/send-a-check.md)をご覧ください。
|
||||
|
||||
|
||||
### Escrow
|
||||
|
||||
入金時の資金保証が必要な場合は、エスクローで入金してもらう方法もあります。通常のエスクローと同様に、送金者はレジャーに資金を確保し、一定の条件が満たされるまで資金を効果的にロックします。これにより、エスクローを閉じて資金を放出するときに、資金が利用できることが保証されます。
|
||||
|
||||
[エスクローの利用](../../tutorials/how-tos/use-specialized-payment-types/use-escrows/index.md)をご覧ください。
|
||||
[エスクローの利用](../../tutorials/payments/send-a-conditional-escrow.md)をご覧ください。
|
||||
|
||||
|
||||
<!-- Need a better understanding of Payment Channels use cases.
|
||||
|
||||
@@ -183,7 +183,7 @@ Clawbackは、ステーブルコインの配布を開始する前に選択でき
|
||||
|
||||
{% admonition type="warning" name="注意" %}ブラックホール済アカウントはトランザクションを送信する手段を持たないため、その後アカウントに関する設定を更新したり、メンテナンスを行ったりすることはできません!{% /admonition %}
|
||||
|
||||
[マスターキーペアの無効化](../../tutorials/how-tos/manage-account-settings/disable-master-key-pair.md)をご覧ください。
|
||||
[マスターキーペアの無効化](../../tutorials/best-practices/key-management/disable-master-key-pair.md)をご覧ください。
|
||||
|
||||
### 信頼できるトランザクションの送信
|
||||
|
||||
|
||||
@@ -1569,7 +1569,7 @@ XRPの「Payment Channel」を作成します。Payment Channelは、2名の当
|
||||
|
||||
新たに作成するトランザクションタイプは次の3つです。[PaymentChannelCreate][]、[PaymentChannelClaim][]、[PaymentChannelFund][]。新たに作成するレジャーオブジェクトタイプは[PayChannel](../docs/references/protocol/ledger-data/ledger-entry-types/paychannel.md)です。レジャー外のデータ構造`Claim`を定義し、ChannelClaimトランザクションに使用します。新たに作成する`rippled`APIメソッドは次のとおりです。[`channel_authorize`](../docs/references/http-websocket-apis/public-api-methods/payment-channel-methods/channel_authorize.md)(署名されたクレームを作成します)、[`channel_verify`](../docs/references/http-websocket-apis/public-api-methods/payment-channel-methods/channel_verify.md)(署名されたクレームを検証します)、[`account_channels`](../docs/references/http-websocket-apis/public-api-methods/account-methods/account_channels.md)(アカウントに関連するチャンネルをリストを作成します)。
|
||||
|
||||
詳細は、[Payment Channelsのチュートリアル](../docs/tutorials/how-tos/use-specialized-payment-types/use-payment-channels/index.md)をご覧ください。
|
||||
詳細は、[Payment Channelsのチュートリアル](../docs/tutorials/payments/use-payment-channels.md)をご覧ください。
|
||||
|
||||
|
||||
### PermissionDelegation
|
||||
|
||||
@@ -1,10 +1,10 @@
|
||||
import { Client, rippleTimeToISOTime, convertStringToHex } from "xrpl"
|
||||
|
||||
const client = new Client("wss://s.devnet.rippletest.net:51233")
|
||||
const client = new Client("wss://xrplcluster.com")
|
||||
await client.connect()
|
||||
|
||||
const SUBJECT_ADDRESS = "rsYhHbanGpnYe3M6bsaMeJT5jnLTfDEzoA"
|
||||
const ISSUER_ADDRESS = "rEzikzbnH6FQJ2cCr4Bqmf6c3jyWLzkonS"
|
||||
const SUBJECT_ADDRESS = "rf1BiGeXwwQoi8Z2ueFYTEXSwuJYfV2Jpn"
|
||||
const ISSUER_ADDRESS = "ra5nK24KXen9AHvsdFTKHSANinZseWnPcX"
|
||||
const CREDENTIAL_TYPE = convertStringToHex("my_credential").toUpperCase()
|
||||
|
||||
// Look up Credential ledger entry --------------------------------------------
|
||||
|
||||
@@ -1,8 +1,3 @@
|
||||
#!/usr/bin/env python
|
||||
|
||||
import argparse
|
||||
import logging
|
||||
import sys
|
||||
from binascii import hexlify
|
||||
from re import match
|
||||
|
||||
@@ -10,158 +5,61 @@ from xrpl.clients import JsonRpcClient
|
||||
from xrpl.models.requests import LedgerEntry, Ledger
|
||||
from xrpl.utils import ripple_time_to_datetime
|
||||
|
||||
# Set up logging --------------------------------------------------------------
|
||||
# Use WARNING by default in case verify_credential is called from elsewhere.
|
||||
logger = logging.getLogger("verify_credential")
|
||||
logger.setLevel(logging.WARNING)
|
||||
logger.addHandler(logging.StreamHandler(sys.stderr))
|
||||
client = JsonRpcClient("https://xrplcluster.com")
|
||||
SUBJECT_ADDRESS = "rf1BiGeXwwQoi8Z2ueFYTEXSwuJYfV2Jpn"
|
||||
ISSUER_ADDRESS = "ra5nK24KXen9AHvsdFTKHSANinZseWnPcX"
|
||||
CREDENTIAL_TYPE = hexlify("my_credential".encode("utf-8")).decode("ascii").upper()
|
||||
|
||||
# Define an error to throw when XRPL lookup fails unexpectedly ----------------
|
||||
class XRPLLookupError(Exception):
|
||||
def __init__(self, xrpl_response):
|
||||
self.body = xrpl_response.result
|
||||
|
||||
# Main function ---------------------------------------------------------------
|
||||
def verify_credential(client:JsonRpcClient,
|
||||
issuer:str,
|
||||
subject:str,
|
||||
credential_type:str="",
|
||||
credential_type_hex:str=""):
|
||||
"""
|
||||
Check whether an XRPL account holds a specified credential,
|
||||
as of the most recently validated ledger.
|
||||
|
||||
Paramters:
|
||||
client - JsonRpcClient for the XRPL network to use.
|
||||
issuer - Address of the credential issuer, in base58
|
||||
subject - Address of the credential holder/subject, in base58
|
||||
credential_type - Credential type to check for as a string,
|
||||
which will be encoded as UTF-8 (1-64 bytes long).
|
||||
credential_type_hex - Credential type (binary) as hexadecimal.
|
||||
verbose - If true, print details to stdout during lookup.
|
||||
You must provide either credential_type or credential_type_hex.
|
||||
|
||||
Returns True if the account holds the specified, valid credential.
|
||||
Returns False if the credential is missing, expired, or not accepted.
|
||||
"""
|
||||
# Handle function inputs --------------------------------------------------
|
||||
if not (credential_type or credential_type_hex):
|
||||
raise ValueError("Provide a non-empty credential_type or " +
|
||||
"credential_type_hex")
|
||||
if credential_type and credential_type_hex:
|
||||
raise ValueError("Provide either credential_type or " +
|
||||
"credential_type_hex, but not both")
|
||||
|
||||
# Encode credential_type as uppercase hex, if needed
|
||||
if credential_type:
|
||||
credential_type_hex = hexlify(credential_type.encode("utf-8")
|
||||
).decode("ascii")
|
||||
logger.info("Encoded credential_type as hex: "+credential_type_hex.upper())
|
||||
credential_type_hex = credential_type_hex.upper()
|
||||
|
||||
if len(credential_type_hex) % 2 or \
|
||||
not match(r"[0-9A-F]{2,128}", credential_type_hex):
|
||||
# Hexadecimal is always 2 chars per byte, so an odd length is invalid.
|
||||
raise ValueError("credential_type_hex must be 1-64 bytes as hexadecimal.")
|
||||
|
||||
# Perform XRPL lookup of Credential ledger entry --------------------------
|
||||
ledger_entry_request = LedgerEntry(
|
||||
credential={
|
||||
"subject": subject,
|
||||
"issuer": issuer,
|
||||
"credential_type": credential_type_hex
|
||||
},
|
||||
ledger_index="validated"
|
||||
)
|
||||
logger.info("Looking up credential...")
|
||||
logger.info(ledger_entry_request.to_dict())
|
||||
# Look up Credential ledger entry ----------------------------------------------
|
||||
ledger_entry_request = LedgerEntry(
|
||||
credential={
|
||||
"subject": SUBJECT_ADDRESS,
|
||||
"issuer": ISSUER_ADDRESS,
|
||||
"credential_type": CREDENTIAL_TYPE,
|
||||
},
|
||||
ledger_index="validated",
|
||||
)
|
||||
print("Looking up credential...")
|
||||
print(ledger_entry_request.to_dict())
|
||||
try:
|
||||
xrpl_response = client.request(ledger_entry_request)
|
||||
except Exception as err:
|
||||
print("Error: ledger_entry failed with error:", err)
|
||||
exit(1)
|
||||
|
||||
if xrpl_response.status != "success":
|
||||
if xrpl_response.result["error"] == "entryNotFound":
|
||||
logger.info("Credential was not found")
|
||||
return False
|
||||
# Other errors, for example invalidly-specified addresses.
|
||||
raise XRPLLookupError(xrpl_response)
|
||||
|
||||
credential = xrpl_response.result["node"]
|
||||
logger.info("Found credential:")
|
||||
logger.info(credential)
|
||||
|
||||
# Confirm that the credential has been accepted ---------------------------
|
||||
lsfAccepted = 0x00010000
|
||||
if not credential["Flags"] & lsfAccepted:
|
||||
logger.info("Credential is not accepted.")
|
||||
return False
|
||||
|
||||
# Confirm that the credential is not expired ------------------------------
|
||||
if credential.get("Expiration"):
|
||||
expiration_time = ripple_time_to_datetime(credential["Expiration"])
|
||||
logger.info("Credential has expiration: "+expiration_time.isoformat())
|
||||
logger.info("Looking up validated ledger to check for expiration.")
|
||||
|
||||
ledger_response = client.request(Ledger(ledger_index="validated"))
|
||||
if ledger_response.status != "success":
|
||||
raise XRPLLookupError(ledger_response)
|
||||
close_time = ripple_time_to_datetime(
|
||||
ledger_response.result["ledger"]["close_time"]
|
||||
)
|
||||
logger.info("Most recent validated ledger is: "+close_time.isoformat())
|
||||
|
||||
if close_time > expiration_time:
|
||||
logger.info("Credential is expired.")
|
||||
return False
|
||||
|
||||
# Credential has passed all checks. ---------------------------------------
|
||||
logger.info("Credential is valid.")
|
||||
return True
|
||||
|
||||
# Commandline usage -----------------------------------------------------------
|
||||
if __name__=="__main__":
|
||||
NETWORKS = {
|
||||
# JSON-RPC URLs of public servers
|
||||
"devnet": "https://s.devnet.rippletest.net:51234/",
|
||||
"testnet": "https://s.altnet.rippletest.net:51234/",
|
||||
"mainnet": "https://xrplcluster.com/"
|
||||
}
|
||||
|
||||
# Parse arguments ---------------------------------------------------------
|
||||
parser = argparse.ArgumentParser(description="Verify an XRPL credential")
|
||||
parser.add_argument("issuer", type=str, nargs="?",
|
||||
help="Credential issuer address as base58.",
|
||||
default="rEzikzbnH6FQJ2cCr4Bqmf6c3jyWLzkonS")
|
||||
parser.add_argument("subject", type=str, nargs="?",
|
||||
help="Credential subject (holder) address as base58.",
|
||||
default="rsYhHbanGpnYe3M6bsaMeJT5jnLTfDEzoA")
|
||||
parser.add_argument("credential_type", type=str, nargs="?",
|
||||
help="Credential type as string",
|
||||
default="my_credential")
|
||||
parser.add_argument("-b", "--binary", action="store_true",
|
||||
help="Use binary (hexadecimal) for credential_type")
|
||||
parser.add_argument("-n", "--network", choices=NETWORKS.keys(),
|
||||
help="Use the specified network for lookup",
|
||||
default="devnet")
|
||||
parser.add_argument("-q", "--quiet", action="store_true",
|
||||
help="Don't print log messages.")
|
||||
args = parser.parse_args()
|
||||
|
||||
# Call verify_credential with appropriate args ----------------------------
|
||||
client = JsonRpcClient(NETWORKS[args.network])
|
||||
if not args.quiet:
|
||||
# Use INFO level by default when called from the commandline.
|
||||
logger.setLevel(logging.INFO)
|
||||
|
||||
if args.binary:
|
||||
result = verify_credential(client,
|
||||
issuer=args.issuer,
|
||||
subject=args.subject,
|
||||
credential_type_hex=args.credential_type)
|
||||
else:
|
||||
result = verify_credential(client,
|
||||
issuer=args.issuer,
|
||||
subject=args.subject,
|
||||
credential_type=args.credential_type)
|
||||
|
||||
# Return a nonzero exit code if credential verification failed. -----------
|
||||
if not result:
|
||||
if xrpl_response.status != "success":
|
||||
if xrpl_response.result["error"] == "entryNotFound":
|
||||
print("Credential was not found")
|
||||
exit(1)
|
||||
# Other errors, for example invalidly-specified addresses.
|
||||
print("Unexpected error looking up credential:", xrpl_response.result)
|
||||
|
||||
credential = xrpl_response.result["node"]
|
||||
print("Found credential:")
|
||||
print(credential)
|
||||
|
||||
# Check if the credential has been accepted ------------------------------------
|
||||
lsfAccepted = 0x00010000
|
||||
if not credential["Flags"] & lsfAccepted:
|
||||
print("Credential is not accepted.")
|
||||
exit(2)
|
||||
|
||||
# Confirm that the credential is not expired -----------------------------------
|
||||
if credential.get("Expiration"):
|
||||
expiration_time = ripple_time_to_datetime(credential["Expiration"])
|
||||
print("Credential has expiration:", expiration_time.isoformat())
|
||||
print("Looking up validated ledger to check for expiration.")
|
||||
|
||||
ledger_response = client.request(Ledger(ledger_index="validated"))
|
||||
if ledger_response.status != "success":
|
||||
print("Error looking up most recent validated ledger:", ledger_response.result)
|
||||
exit(3)
|
||||
close_time = ripple_time_to_datetime(ledger_response.result["ledger"]["close_time"])
|
||||
print("Most recent validated ledger was at:", close_time.isoformat())
|
||||
|
||||
if close_time > expiration_time:
|
||||
print("Credential is expired.")
|
||||
exit(4)
|
||||
|
||||
# Credential has passed all checks. --------------------------------------------
|
||||
print("Credential is valid.")
|
||||
|
||||
@@ -40,7 +40,7 @@ The basis of any financial system is transferring value. The quickest and simple
|
||||
|
||||
- **Tutorials:**
|
||||
- [Send XRP (Interactive Tutorial)](../../tutorials/payments/send-xrp)
|
||||
- [Monitor Incoming Payments with WebSocket](../../tutorials/advanced-developer-topics/client-library-development//monitor-incoming-payments-with-websocket.md)
|
||||
- [Monitor Incoming Payments with WebSocket](../../tutorials/advanced-developer-topics/client-library-development/monitor-incoming-payments-with-websocket.md)
|
||||
- **References:**
|
||||
- [Payment transaction][]
|
||||
- [Transaction Results](../../references/protocol/transactions/transaction-results/index.md)
|
||||
|
||||
@@ -112,6 +112,6 @@ For more information about Escrow in the XRP Ledger, see the following:
|
||||
- [EscrowFinish transaction][]
|
||||
- [EscrowCancel transaction][]
|
||||
- [Ledger Reference](../../references/protocol/ledger-data/index.md)
|
||||
- [Escrow object](../../references/protocol/ledger-data/ledger-entry-types/escrow.md)
|
||||
- [Escrow entry][]
|
||||
|
||||
{% raw-partial file="/docs/_snippets/common-links.md" /%}
|
||||
|
||||
@@ -1,221 +0,0 @@
|
||||
---
|
||||
seo:
|
||||
description: Verify that an account holds a valid credential on the XRP Ledger.
|
||||
labels:
|
||||
- Credentials
|
||||
---
|
||||
# Verify Credentials in Python
|
||||
|
||||
This tutorial describes how to verify that an account holds a valid [credential](../../concepts/decentralized-storage/credentials.md) on the XRP Ledger, which has different use cases depending on the type of credential and the meaning behind it. A few possible reasons to verify a credential include:
|
||||
|
||||
- Confirming that a recipient has passed a background check before sending a payment.
|
||||
- Checking a person's professional certifications, after verifying their identity with a [DID](../../concepts/decentralized-storage/decentralized-identifiers.md).
|
||||
- Displaying a player's achievements in a blockchain-connected game.
|
||||
|
||||
This tutorial uses sample code in Python using the [xrpl-py library](../index.md).
|
||||
|
||||
## Prerequisites
|
||||
|
||||
- You must have Python installed and know how to run Python code from the command line. Python 3.8 or later is required for xrpl-py.
|
||||
- You should have a basic understanding of the XRP Ledger.
|
||||
- The credential you want to verify should exist in the ledger already, and you should know the addresses of both the issuer and the holder, as well as the official credential type you want to check.
|
||||
- For sample code showing how to create credentials, see [Build a Credential Issuing Service](../sample-apps/credential-issuing-service-in-python.md).
|
||||
|
||||
## Setup
|
||||
|
||||
First, download the complete sample code for this tutorial from GitHub:
|
||||
|
||||
- {% repo-link path="_code-samples/verify-credential/py/" %}Verify Credential sample code{% /repo-link %}
|
||||
|
||||
Then, in the appropriate directory, set up a virtual environment and install dependencies:
|
||||
|
||||
```sh
|
||||
python -m venv .venv
|
||||
source .venv/bin/activate
|
||||
pip install -r requirements.txt
|
||||
```
|
||||
|
||||
This installs the appropriate version of the `xrpl-py` library. There are no other dependencies for this tutorial outside of the Python standard library.
|
||||
|
||||
## Overview
|
||||
|
||||
The Verify Credential sample code consists of one file, `verify_credential.py`, and contains two main parts:
|
||||
|
||||
1. A function, `verify_credential(...)` which can be called with appropriate arguments to verify that a credential exists and is valid. This function can be imported into other code to be used as part of a larger application.
|
||||
2. A commandline utility that can be used to verify any credential.
|
||||
|
||||
## Usage
|
||||
|
||||
To test that you have the code installed and working properly, you can run the commandline utility with no arguments to check the existence of a default credential on Devnet, such as:
|
||||
|
||||
```sh
|
||||
python verify_credential.py
|
||||
```
|
||||
|
||||
If all goes well, you should see output such as the following:
|
||||
|
||||
```text
|
||||
Encoded credential_type as hex: 6D795F63726564656E7469616C
|
||||
Looking up credential...
|
||||
{'ledger_index': 'validated', 'method': 'ledger_entry', 'api_version': 2, 'credential': {'subject': 'rsYhHbanGpnYe3M6bsaMeJT5jnLTfDEzoA', 'issuer': 'rEzikzbnH6FQJ2cCr4Bqmf6c3jyWLzkonS', 'credential_type': '6D795F63726564656E7469616C'}, 'binary': False}
|
||||
Found credential:
|
||||
{'CredentialType': '6D795F63726564656E7469616C', 'Flags': 65536, 'Issuer': 'rEzikzbnH6FQJ2cCr4Bqmf6c3jyWLzkonS', 'IssuerNode': '0', 'LedgerEntryType': 'Credential', 'PreviousTxnID': '7D1257779E2D298C07C7E0C73CD446534B143FBD1F13DB268A878E40FD153B9A', 'PreviousTxnLgrSeq': 803275, 'Subject': 'rsYhHbanGpnYe3M6bsaMeJT5jnLTfDEzoA', 'SubjectNode': '0', 'index': '9603F0E204A8B1C61823625682EB0ECE98A4ECF22FF46CD4845FA9BFA3606B24'}
|
||||
Credential is valid.
|
||||
```
|
||||
|
||||
If the code reports that the credential was not found when called with no arguments, it's possible that the example credential has been deleted or the Devnet has been reset. If you have another credential you can verify, you can provide the details as commandline arguments. For example:
|
||||
|
||||
```sh
|
||||
python verify_credential.py rsYhHbanGpnYe3M6bsaMeJT5jnLTfDEzoA rsYhHbanGpnYe3M6bsaMeJT5jnLTfDEzoA my_credential
|
||||
```
|
||||
|
||||
A full usage statement is available with the `-h` flag.
|
||||
|
||||
### Interactive Shell
|
||||
|
||||
You can open an interactive python shell and import the `verify_credential` function, as in the following example:
|
||||
|
||||
```py
|
||||
>>> from verify_credential import verify_credential
|
||||
>>> from xrpl.clients import JsonRpcClient
|
||||
>>> client = JsonRpcClient("https://s.devnet.rippletest.net:51234/")
|
||||
>>> verify_credential(client, issuer="rEzikzbnH6FQJ2cCr4Bqmf6c3jyWLzkonS", subject="rsYhHbanGpnYe3M6bsaMeJT5jnLTfDEzoA", credential_type="my_credential")
|
||||
True
|
||||
```
|
||||
|
||||
You can import the `verify_credential(...)` function into other scripts and use it the same way.
|
||||
|
||||
### Other Examples
|
||||
|
||||
The following examples show other possible scenarios. The data for these examples may or may not still be present in Devnet. For example, anyone can delete an expired credential.
|
||||
|
||||
{% tabs %}
|
||||
{% tab label="Valid with Expiration" %}
|
||||
```text
|
||||
$ ./verify_credential.py rEzikzbnH6FQJ2cCr4Bqmf6c3jyWLzkonS rs9DtpwyCSGMCyxiYEvVG29ZXo99iFjZ9S long_lasting_credential
|
||||
|
||||
Encoded credential_type as hex: 6C6F6E675F6C617374696E675F63726564656E7469616C
|
||||
Looking up credential...
|
||||
{'ledger_index': 'validated', 'method': 'ledger_entry', 'api_version': 2, 'credential': {'subject': 'rs9DtpwyCSGMCyxiYEvVG29ZXo99iFjZ9S', 'issuer': 'rEzikzbnH6FQJ2cCr4Bqmf6c3jyWLzkonS', 'credential_type': '6C6F6E675F6C617374696E675F63726564656E7469616C'}, 'binary': False}
|
||||
Found credential:
|
||||
{'CredentialType': '6C6F6E675F6C617374696E675F63726564656E7469616C', 'Expiration': 1167724800, 'Flags': 65536, 'Issuer': 'rEzikzbnH6FQJ2cCr4Bqmf6c3jyWLzkonS', 'IssuerNode': '0', 'LedgerEntryType': 'Credential', 'PreviousTxnID': 'C65794B7C322F028DB0D2DD72C9FF69D53A676B1608B77ADEF22311AFB22BFF7', 'PreviousTxnLgrSeq': 996934, 'Subject': 'rs9DtpwyCSGMCyxiYEvVG29ZXo99iFjZ9S', 'SubjectNode': '0', 'index': 'FC4BB495DAE7C9F4615174188B3C5F2E337680017BA90E1F126DE08CAD15FD66'}
|
||||
Credential has expiration: 2037-01-01T08:00:00+00:00
|
||||
Looking up validated ledger to check for expiration.
|
||||
Most recent validated ledger is: 2025-03-11T20:01:51+00:00
|
||||
Credential is valid.
|
||||
```
|
||||
{% /tab %}
|
||||
|
||||
{% tab label="Expired" %}
|
||||
```text
|
||||
$ ./verify_credential.py rEzikzbnH6FQJ2cCr4Bqmf6c3jyWLzkonS rs9DtpwyCSGMCyxiYEvVG29ZXo99iFjZ9S expiring_credential
|
||||
|
||||
Encoded credential_type as hex: 6578706972696E675F63726564656E7469616C
|
||||
Looking up credential...
|
||||
{'ledger_index': 'validated', 'method': 'ledger_entry', 'api_version': 2, 'credential': {'subject': 'rs9DtpwyCSGMCyxiYEvVG29ZXo99iFjZ9S', 'issuer': 'rEzikzbnH6FQJ2cCr4Bqmf6c3jyWLzkonS', 'credential_type': '6578706972696E675F63726564656E7469616C'}, 'binary': False}
|
||||
Found credential:
|
||||
{'CredentialType': '6578706972696E675F63726564656E7469616C', 'Expiration': 795038400, 'Flags': 65536, 'Issuer': 'rEzikzbnH6FQJ2cCr4Bqmf6c3jyWLzkonS', 'IssuerNode': '0', 'LedgerEntryType': 'Credential', 'PreviousTxnID': 'E497F1EFE2E198EDED0D94ADDEE4CEFACDDC3B1674133A0123C765F8061B9600', 'PreviousTxnLgrSeq': 997087, 'Subject': 'rs9DtpwyCSGMCyxiYEvVG29ZXo99iFjZ9S', 'SubjectNode': '0', 'index': 'F3A9475871E7BA994E257732D0C7CB0B91CACBBB9F840BDFA6ABABD6F71454CD'}
|
||||
Credential has expiration: 2025-03-11T20:00:00+00:00
|
||||
Looking up validated ledger to check for expiration.
|
||||
Most recent validated ledger is: 2025-03-11T20:02:03+00:00
|
||||
Credential is expired.
|
||||
```
|
||||
{% /tab %}
|
||||
|
||||
{% tab label="Unaccepted" %}
|
||||
```text
|
||||
$ ./verify_credential.py rEzikzbnH6FQJ2cCr4Bqmf6c3jyWLzkonS rs9DtpwyCSGMCyxiYEvVG29ZXo99iFjZ9S unaccepted_credential
|
||||
|
||||
Encoded credential_type as hex: 756E61636365707465645F63726564656E7469616C
|
||||
Looking up credential...
|
||||
{'ledger_index': 'validated', 'method': 'ledger_entry', 'api_version': 2, 'credential': {'subject': 'rs9DtpwyCSGMCyxiYEvVG29ZXo99iFjZ9S', 'issuer': 'rEzikzbnH6FQJ2cCr4Bqmf6c3jyWLzkonS', 'credential_type': '756E61636365707465645F63726564656E7469616C'}, 'binary': False}
|
||||
Found credential:
|
||||
{'CredentialType': '756E61636365707465645F63726564656E7469616C', 'Flags': 0, 'Issuer': 'rEzikzbnH6FQJ2cCr4Bqmf6c3jyWLzkonS', 'IssuerNode': '0', 'LedgerEntryType': 'Credential', 'PreviousTxnID': '59DB4B17E5552AB1CA1E2A89F5C03E51C2ACD0D293955FA701AE4A1801E94C96', 'PreviousTxnLgrSeq': 997107, 'Subject': 'rs9DtpwyCSGMCyxiYEvVG29ZXo99iFjZ9S', 'SubjectNode': '0', 'index': '8E5AD9444D566BE5C6F87C94D696139CEEE43ACB9A96137A59C003B48DF565C6'}
|
||||
Credential is not accepted.
|
||||
```
|
||||
{% /tab %}
|
||||
{% tab label="Hexadecimal Credential Type" %}
|
||||
```text
|
||||
$ ./verify_credential.py rEzikzbnH6FQJ2cCr4Bqmf6c3jyWLzkonS rsYhHbanGpnYe3M6bsaMeJT5jnLTfDEzoA 6D795F63726564656E7469616C -b
|
||||
|
||||
Looking up credential...
|
||||
{'ledger_index': 'validated', 'method': 'ledger_entry', 'api_version': 2, 'credential': {'subject': 'rsYhHbanGpnYe3M6bsaMeJT5jnLTfDEzoA', 'issuer': 'rEzikzbnH6FQJ2cCr4Bqmf6c3jyWLzkonS', 'credential_type': '6D795F63726564656E7469616C'}, 'binary': False}
|
||||
Found credential:
|
||||
{'CredentialType': '6D795F63726564656E7469616C', 'Flags': 65536, 'Issuer': 'rEzikzbnH6FQJ2cCr4Bqmf6c3jyWLzkonS', 'IssuerNode': '0', 'LedgerEntryType': 'Credential', 'PreviousTxnID': '7D1257779E2D298C07C7E0C73CD446534B143FBD1F13DB268A878E40FD153B9A', 'PreviousTxnLgrSeq': 803275, 'Subject': 'rsYhHbanGpnYe3M6bsaMeJT5jnLTfDEzoA', 'SubjectNode': '0', 'index': '9603F0E204A8B1C61823625682EB0ECE98A4ECF22FF46CD4845FA9BFA3606B24'}
|
||||
Credential is valid.
|
||||
```
|
||||
{% /tab %}
|
||||
{% /tabs %}
|
||||
|
||||
|
||||
## Code Walkthrough
|
||||
|
||||
### 1. Initial setup
|
||||
|
||||
The `verify_credential.py` file implements the code for this tutorial.
|
||||
This file can be run as a commandline tool, so it starts with a [shebang](https://en.wikipedia.org/wiki/Shebang_(Unix)). Then it imports dependencies, with standard lib first and then specific parts of the `xrpl-py` library:
|
||||
|
||||
{% code-snippet file="/_code-samples/verify-credential/py/verify_credential.py" language="py" before="# Set up logging" /%}
|
||||
|
||||
The next section of the code sets the default log level for messages that might be written to the console through the utility:
|
||||
|
||||
{% code-snippet file="/_code-samples/verify-credential/py/verify_credential.py" language="py" from="# Set up logging" before="# Define an error to throw" /%}
|
||||
|
||||
Then it defines a type of exception to throw if something goes wrong when connecting to the XRP Ledger:
|
||||
|
||||
{% code-snippet file="/_code-samples/verify-credential/py/verify_credential.py" language="py" from="# Define an error to throw" before="# Main function" /%}
|
||||
|
||||
### 2. Main function
|
||||
|
||||
The `verify_credential(...)` function performs the main work for this tutorial. The function definition and docstring define the parameters:
|
||||
|
||||
{% code-snippet file="/_code-samples/verify-credential/py/verify_credential.py" language="py" from="# Main function" before="# Handle function inputs" /%}
|
||||
|
||||
The first thing the function does is verify that the user provided a credential type in either the `credential_type` or `credential_type_hex` parameter. The XRP Ledger APIs require the credential type to be hexadecimal, so it converts the user input if necessary:
|
||||
|
||||
{% code-snippet file="/_code-samples/verify-credential/py/verify_credential.py" language="py" from="# Handle function inputs" before="# Perform XRPL lookup" /%}
|
||||
|
||||
Next, it calls the [ledger_entry method](../../references/http-websocket-apis/public-api-methods/ledger-methods/ledger_entry.md#get-credential-entry) to look up the requested Credential ledger entry:
|
||||
|
||||
{% code-snippet file="/_code-samples/verify-credential/py/verify_credential.py" language="py" from="# Perform XRPL lookup" before="# Confirm that the credential has been accepted" /%}
|
||||
|
||||
If it succeeds in finding the credential, the function continues by checking that the credential has been accepted by its holder. Since anyone can issue a credential to anyone else, a credential is only considered valid if its subject has accepted it.
|
||||
|
||||
{% code-snippet file="/_code-samples/verify-credential/py/verify_credential.py" language="py" from="# Confirm that the credential has been accepted" before="# Confirm that the credential is not expired" /%}
|
||||
|
||||
Then, if the credential has an expiration time, the function checks that the credential is not expired. If the credential has no expiration, this step can be skipped. A credential is officially considered expired if its expiration time is before the [official close time](../../concepts/ledgers/ledger-close-times.md) of the most recently validated ledger. This is more universal than comparing the expiration to your own local clock. Thus, the code uses the [ledger method][] to look up the most recently validated ledger:
|
||||
|
||||
{% code-snippet file="/_code-samples/verify-credential/py/verify_credential.py" language="py" from="# Confirm that the credential is not expired" before="# Credential has passed all checks" /%}
|
||||
|
||||
If none of the checks up to this point have returned a `False` value, then the credential must be valid. This concludes the `verify_credential(...)` main function:
|
||||
|
||||
{% code-snippet file="/_code-samples/verify-credential/py/verify_credential.py" language="py" from="# Credential has passed all checks" before="# Commandline usage" /%}
|
||||
|
||||
### 3. Commandline interface
|
||||
|
||||
This file also implements a commandline utility which runs when the file is executed directly as a Python script. Some variables, such as the set of available networks, are only needed for this mode:
|
||||
|
||||
{% code-snippet file="/_code-samples/verify-credential/py/verify_credential.py" language="py" from="# Commandline usage" before="# Parse arguments" /%}
|
||||
|
||||
Then it uses the [argparse library](https://docs.python.org/3/library/argparse.html) to define and parse the arguments that the user can pass from the commandline:
|
||||
|
||||
{% code-snippet file="/_code-samples/verify-credential/py/verify_credential.py" language="py" from="# Parse arguments" before="# Call verify_credential" /%}
|
||||
|
||||
After parsing the commandline args, it sets the appropriate values and passes them to `verify_credential(...)` to perform the credential verification:
|
||||
|
||||
{% code-snippet file="/_code-samples/verify-credential/py/verify_credential.py" language="py" from="# Call verify_credential" before="# Return a nonzero exit code" /%}
|
||||
|
||||
Finally, it returns a nonzero exit code if this credential was not verified. This can be useful for shell scripts:
|
||||
|
||||
{% code-snippet file="/_code-samples/verify-credential/py/verify_credential.py" language="py" from="# Call verify_credential" before="# Return a nonzero exit code" /%}
|
||||
|
||||
Otherwise, the code exits as normal, which returns a successful exit code of `0` to the shell.
|
||||
|
||||
## Next Steps
|
||||
|
||||
Now that you know how to use `xrpl-py` to verify credentials, you can try building this or related steps together into a bigger project. For example:
|
||||
|
||||
- Incorporate credential verification into a [wallet application](../sample-apps/build-a-desktop-wallet-in-python.md).
|
||||
- Issue your own credentials with a [credential issuing service](../sample-apps/credential-issuing-service-in-python.md).
|
||||
|
||||
{% raw-partial file="/docs/_snippets/common-links.md" /%}
|
||||
@@ -26,7 +26,7 @@ To complete this tutorial, you should:
|
||||
- Have a basic understanding of the XRP Ledger.
|
||||
- Have an XRP Ledger client library, such as [xrpl.js](../get-started/get-started-javascript.md), installed.
|
||||
- Know the issuer, subject, and credential type of the credential you want to verify. For purposes of this tutorial, you can use sample values of data that exists in the public network.
|
||||
- For information on how to create your own credentials, see the [Build a Credential Issuing Service](../sample-apps/credential-issuing-service-in-javascript.md) tutorial.
|
||||
- For information on how to create your own credentials, see the [Build a Credential Issuing Service in JavaScript](../sample-apps/credential-issuing-service-in-javascript.md) (or [in Python](../sample-apps/credential-issuing-service-in-python.md)) tutorial.
|
||||
|
||||
## Source Code
|
||||
|
||||
@@ -45,7 +45,6 @@ npm i
|
||||
```
|
||||
{% /tab %}
|
||||
|
||||
<!-- re-add Python tab when merging the tutorials
|
||||
{% tab label="Python" %}
|
||||
From the code sample folder, set up a virtual environment and use `pip` to install dependencies:
|
||||
|
||||
@@ -55,17 +54,20 @@ source .venv/bin/activate
|
||||
pip install -r requirements.txt
|
||||
```
|
||||
{% /tab %}
|
||||
-->
|
||||
{% /tabs %}
|
||||
|
||||
### 2. Set up client and define constants
|
||||
|
||||
To get started, import the client library and instantiate an API client. You also need to specify the details of the credential you want to verify.
|
||||
To get started, import the client library and instantiate an API client. You also need to specify the details of the credential you want to verify. The sample code looks up a credential on Mainnet that is set to expire on January 1, 2038.
|
||||
|
||||
{% tabs %}
|
||||
{% tab label="JavaScript" %}
|
||||
{% code-snippet file="/_code-samples/verify-credential/js/verify_credential.js" language="js" before="// Look up Credential" /%}
|
||||
{% /tab %}
|
||||
|
||||
{% tab label="Python" %}
|
||||
{% code-snippet file="/_code-samples/verify-credential/py/verify_credential.py" language="py" before="# Look up Credential" /%}
|
||||
{% /tab %}
|
||||
{% /tabs %}
|
||||
|
||||
### 3. Look up the credential
|
||||
@@ -78,6 +80,10 @@ If the request fails with an `entryNotFound` error, then the specified credentia
|
||||
{% tab label="JavaScript" %}
|
||||
{% code-snippet file="/_code-samples/verify-credential/js/verify_credential.js" language="js" from="// Look up Credential" before="// Check if the credential has been accepted" /%}
|
||||
{% /tab %}
|
||||
|
||||
{% tab label="Python" %}
|
||||
{% code-snippet file="/_code-samples/verify-credential/py/verify_credential.py" language="py" from="# Look up Credential" before="# Check if the credential has been accepted" /%}
|
||||
{% /tab %}
|
||||
{% /tabs %}
|
||||
|
||||
### 4. Check if the credential has been accepted
|
||||
@@ -88,6 +94,10 @@ Since a credential isn't valid until the subject has accepted it, you need to ch
|
||||
{% tab label="JavaScript" %}
|
||||
{% code-snippet file="/_code-samples/verify-credential/js/verify_credential.js" language="js" from="// Check if the credential has been accepted" before="// Confirm that the credential is not expired" /%}
|
||||
{% /tab %}
|
||||
|
||||
{% tab label="Python" %}
|
||||
{% code-snippet file="/_code-samples/verify-credential/py/verify_credential.py" language="py" from="# Check if the credential has been accepted" before="# Confirm that the credential is not expired" /%}
|
||||
{% /tab %}
|
||||
{% /tabs %}
|
||||
|
||||
### 5. Check credential expiration
|
||||
@@ -100,6 +110,10 @@ If the credential does not have an expiration time, then it remains valid indefi
|
||||
{% tab label="JavaScript" %}
|
||||
{% code-snippet file="/_code-samples/verify-credential/js/verify_credential.js" language="js" from="// Confirm that the credential is not expired" before="// Credential has passed" /%}
|
||||
{% /tab %}
|
||||
|
||||
{% tab label="Python" %}
|
||||
{% code-snippet file="/_code-samples/verify-credential/py/verify_credential.py" language="py" from="# Confirm that the credential is not expired" before="# Credential has passed" /%}
|
||||
{% /tab %}
|
||||
{% /tabs %}
|
||||
|
||||
### 6. Declare credential valid
|
||||
@@ -114,6 +128,10 @@ If the credential has passed all checks to this point, it is valid. In summary,
|
||||
{% tab label="JavaScript" %}
|
||||
{% code-snippet file="/_code-samples/verify-credential/js/verify_credential.js" language="js" from="// Credential has passed" /%}
|
||||
{% /tab %}
|
||||
|
||||
{% tab label="Python" %}
|
||||
{% code-snippet file="/_code-samples/verify-credential/py/verify_credential.py" language="py" from="# Credential has passed" /%}
|
||||
{% /tab %}
|
||||
{% /tabs %}
|
||||
|
||||
|
||||
@@ -126,7 +144,11 @@ Now that you know how to use `xrpl.js` to verify credentials, you can try buildi
|
||||
|
||||
## See Also
|
||||
|
||||
- [Verify Credentials in Python](./verify-credentials-in-python.md)
|
||||
- **Concepts:**
|
||||
- [Credentials](../../concepts/decentralized-storage/credentials.md)
|
||||
- **Tutorials:**
|
||||
- [Build a Credential Issuing Service in JavaScript](../sample-apps/credential-issuing-service-in-javascript.md)
|
||||
- [Build a Credential Issuing Service in Python](../sample-apps/credential-issuing-service-in-python.md)
|
||||
- **References:**
|
||||
- API methods:
|
||||
- [ledger_entry method][]
|
||||
@@ -357,7 +357,7 @@ Using this service as a base, you can extend the service with more features, suc
|
||||
Alternatively, you can use credentials to for various purposes, such as:
|
||||
|
||||
- Define a [Permissioned Domain](/docs/concepts/tokens/decentralized-exchange/permissioned-domains) that uses your credentials to grant access to features on the XRP Ledger.
|
||||
- [Verify credentials](../compliance-features/verify-credentials-javascript.md) manually to grant access to services that exist off-ledger.
|
||||
- [Verify credentials](../compliance-features/verify-credentials.md) manually to grant access to services that exist off-ledger.
|
||||
|
||||
## See Also
|
||||
|
||||
|
||||
@@ -352,6 +352,6 @@ Using this service as a base, you can extend the service with more features, suc
|
||||
Alternatively, you can use credentials to for various purposes, such as:
|
||||
|
||||
- Define a [Permissioned Domain](/docs/concepts/tokens/decentralized-exchange/permissioned-domains) that uses your credentials to grant access to features on the XRP Ledger.
|
||||
- [Verify credentials](../compliance-features/verify-credentials-in-python.md) manually to grant access to services that exist off-ledger.
|
||||
- [Verify credentials](../compliance-features/verify-credentials.md) manually to grant access to services that exist off-ledger.
|
||||
|
||||
{% raw-partial file="/docs/_snippets/common-links.md" /%}
|
||||
|
||||
@@ -189,6 +189,7 @@
|
||||
labelTranslationKey: sidebar.docs.tutorials
|
||||
expanded: false
|
||||
items:
|
||||
- page: docs/tutorials/public-servers.md
|
||||
- group: Get Started
|
||||
groupTranslationKey: sidebar.docs.tutorials.getStarted
|
||||
expanded: false
|
||||
@@ -302,8 +303,7 @@
|
||||
expanded: false
|
||||
items:
|
||||
- page: docs/tutorials/compliance-features/require-destination-tags.md
|
||||
- page: docs/tutorials/compliance-features/verify-credentials-in-python.md
|
||||
- page: docs/tutorials/compliance-features/verify-credentials-javascript.md
|
||||
- page: docs/tutorials/compliance-features/verify-credentials.md
|
||||
- page: docs/tutorials/compliance-features/create-permissioned-domains-in-javascript.md
|
||||
- group: Programmability
|
||||
groupTranslationKey: sidebar.docs.tutorials.programmability
|
||||
|
||||
Reference in New Issue
Block a user