[JA] fix italic

This commit is contained in:
tequ
2024-04-07 15:48:55 +09:00
parent afc65c08bf
commit 5cab71c726
9 changed files with 12 additions and 12 deletions

View File

@@ -52,7 +52,7 @@ XRP Ledgerのチケットは、取引をすぐに送信せずに、その取引
- 各チケットは一度しか使用できません。同じチケットシーケンスを使用する複数の異なるトランザクション候補があることは可能ですが、コンセンサスで検証できるのはそのうちの1つだけです。
- 各アカウントでは、一度に250枚以上のチケットをレジャーに登録することはできません。また、一度に250枚以上のチケットを作成することもできません。
- チケットを使って別のチケットを作ることは_できます_。その場合、使用したチケットは、一度に所持できるチケットの合計数にはカウントされません。
- チケットを使って別のチケットを作ることは _できます_。その場合、使用したチケットは、一度に所持できるチケットの合計数にはカウントされません。
- 各チケットは[所有者準備金](reserves.md#所有者準備金)にカウントされるため、まだ使用していないチケット1枚につき2XRPを確保する必要があります。このXRPは、チケットを使用した後、再び使用することができます。
- 個々の元帳の中では、チケットを使用した取引は、同じ送信者からの他の取引の後に実行されます。1つのアカウントが同じ元帳のバージョンでTicketを使用する複数のトランザクションを持つ場合、それらのTicketは最も低いTicket Sequenceから最も高いTicket Sequenceの順に実行されます。 (詳細については、コンセンサスの[正規順序](../consensus-protocol/consensus-structure.md#xrp-ledgerプロトコル-コンセンサスと検証)に関するドキュメントをご覧ください)。
- 個々の元帳の中では、チケットを使用した取引は、同じ送信者からの他の取引の後に実行されます。1つのアカウントが同じ元帳のバージョンでチケットを使用する複数のトランザクションを持つ場合、それらのチケットは最も低いチケット シーケンス番号から最も高いチケット シーケンス番号の順に実行されます。 (詳細については、コンセンサスの[正規順序](../consensus-protocol/consensus-structure.md#xrp-ledgerプロトコル-コンセンサスと検証)に関するドキュメントをご覧ください)。

View File

@@ -60,7 +60,7 @@ D = A × ( e ^ (t ÷ τ) )
### e倍加時間の計算
レジャー金額と表示金額の変換や、有利子/不利子通貨の通貨コードの計算には、「e倍加時間」としての金利が必要です。e倍加時間とは、ある数量が_e_オイラー数の倍数だけ増加するのにかかる時間のことである。慣例として、e倍加時間は数式では**τ**という文字で表記される。
レジャー金額と表示金額の変換や、有利子/不利子通貨の通貨コードの計算には、「e倍加時間」としての金利が必要です。e倍加時間とは、ある数量が _e_オイラー数の倍数だけ増加するのにかかる時間のことである。慣例として、e倍加時間は数式では**τ**という文字で表記される。
ある年率パーセントの利息に対するe倍加時間の時間を計算すること。

View File

@@ -45,7 +45,7 @@ ECDSA署名はRおよびSと呼ばれる2つの整数で構成されています
このように、 _完全に_ 正規である署名を使用する場合には、2つの有効な値のうちどちらを使用するかを選択し、もう一方が無効であることを宣言する必要があります。XRP Ledgerの作成者は、2つの有効な値`S``N-S`)のいずれか _小さい方_ を任意に選択すると決めました。トランザクションが選択された(小さな)値`S`を使用し、正規トランザクションとなるためのすべての標準ルールに準拠している場合、このトランザクションは _完全に正規_ であるとみなされます。
[RequireFullyCanonicalSig Amendment][]2020年に有効では、すべてのトランザクションは_完全正規(fully canonical)な_署名のみを使用しなければなりません。
[RequireFullyCanonicalSig Amendment][]2020年に有効では、すべてのトランザクションは _完全正規(fully canonical)な_ 署名のみを使用しなければなりません。
2014年から2020年の間、XRP Ledgerは常に完全な正規署名を生成するわけではないレガシーソフトウェアと互換性がありましたが、トランザクションの脆弱性から互換性のあるソフトウェアを保護するために、トランザクションに[**tfullyCanonicalSig`**](../../../references/protocol/transactions/common-fields.md#global-flags)と呼ばれるフラグを使用していました。このフラグは互換署名ソフトウェアがデフォルトで有効にしており、トランザクションが有効であるために _完全正規な_ 署名を使用することを要求していました。[RequireFullyCanonicalSig Amendment][]が有効になったので、このフラグは必要なくなりましたが、いずれにせよ有効にしても害はありません。

View File

@@ -10,13 +10,13 @@ labels:
---
# 送信元タグと宛先タグ
_送信元タグ__宛先タグ_は、XRP Ledgerの[支払い](../payment-types/index.md)機能で、多目的アドレスからの支払いや多目的アドレスへの支払いの特定の目的を示すことができます。送信元タグと宛先タグは、台帳上の直接的な機能を持ちません。送信元タグと宛先タグは、台帳外のシステムがどのように支払いを処理すべきかについての情報を提供するだけです。トランザクションでは、送信元タグも宛先タグも 32ビット符号なし整数の形式です。
_送信元タグ__宛先タグ_ は、XRP Ledgerの[支払い](../payment-types/index.md)機能で、多目的アドレスからの支払いや多目的アドレスへの支払いの特定の目的を示すことができます。送信元タグと宛先タグは、台帳上の直接的な機能を持ちません。送信元タグと宛先タグは、台帳外のシステムがどのように支払いを処理すべきかについての情報を提供するだけです。トランザクションでは、送信元タグも宛先タグも 32ビット符号なし整数の形式です。
宛先タグは、支払いの受取人または宛先を示します。例えば、[取引所](../../use-cases/defi/list-xrp-as-an-exchange.md) や [ステーブルコインの発行者](../../use-cases/tokenization/stablecoin-issuer.md)アドレスへの支払いは、宛先タグを使用して、そのビジネス自体のシステム内で支払額を与信するユーザを表すことができます。店舗・業者への支払いは、その支払いがどの商品を購入するのかを表すことができます。
送信元タグは、支払いの送信者または送信元を示します。最も一般的なのは、受取人に対する返金時の送信先として送信元タグを使用することです。返金する場合は、受領した支払いの送信元タグを返金支払いの宛先タグとして使用する必要があります。
顧客に、別のインターフェースを使用してXRP Ledgerアドレスからトランザクションを送受信する機能を提供することを、_ホストされたアカウント_の提供と呼びます。ホストされたアカウントでは通常、顧客ごとに送信元タグと宛先タグを使用します。
顧客に、別のインターフェースを使用してXRP Ledgerアドレスからトランザクションを送受信する機能を提供することを、_ホストされたアカウント_ の提供と呼びます。ホストされたアカウントでは通常、顧客ごとに送信元タグと宛先タグを使用します。
**ヒント:** [Xアドレス](https://xrpaddress.info/)は、従来のアドレスとタグを組み合わせて、両方をエンコードして1つのアドレスにしたものです。顧客に入金アドレスを示す場合、顧客にアドレスとタグの2つの情報を管理させるよりも、Xアドレスを使用する方が顧客にとって簡単かもしれません。(Xアドレスのタグは、送信時には送信元タグとして、受信時には宛先タグとして機能します)。

View File

@@ -14,7 +14,7 @@ seo:
`rippled` サーバではトランザクション履歴のコピーがSQLiteデータベースに保管されます。バージョン0.40.0より古い`rippled`では、このデータベースの容量は約2TBに設定されました。ほとんどの場合はこの容量で十分です。ただし、レジャー32570本番環境XRP Ledgerの履歴で利用可能な最も古いレジャーバージョン以降の全トランザクション履歴は、このSQLiteデータベースの容量を超える可能性があります。`rippled`サーババージョン0.40.0以降では、これよりも大きな容量でSQLiteデータベースファイルが作成されているため、この問題が発生する可能性は低くなります。
SQLiteデータベースの容量は、データベースの_ページサイズ_パラメーターによって決まります。この容量は、データベース作成後は容易に変更できません。SQLiteの内部についての詳細は、[SQLite公式ドキュメント](https://www.sqlite.org/fileformat.html)をご覧ください。)データベースが保管されているディスクとファイルシステムに空き容量がある場合でも、データベースが容量いっぱいになることがあります。以下の「[解決策](#解決策)」で説明するように、この問題を回避するためにページサイズを再構成するには、時間のかかる移行プロセスが必要です。
SQLiteデータベースの容量は、データベースの _ページサイズ_ パラメーターによって決まります。この容量は、データベース作成後は容易に変更できません。SQLiteの内部についての詳細は、[SQLite公式ドキュメント](https://www.sqlite.org/fileformat.html)をご覧ください。)データベースが保管されているディスクとファイルシステムに空き容量がある場合でも、データベースが容量いっぱいになることがあります。以下の「[解決策](#解決策)」で説明するように、この問題を回避するためにページサイズを再構成するには、時間のかかる移行プロセスが必要です。
**ヒント:** ほとんどの場合、`rippled`サーバの稼働に全履歴が必要となることはありません。サーバにトランザクションの全履歴が記録されていれば、長期分析やアーカイブ、または災害に対する事前対策に役立ちます。リソースを大量に消費せずにトランザクション履歴を保管する方法については、[履歴シャーディング](../configuration/data-retention/history-sharding.md)をご覧ください。

View File

@@ -238,7 +238,7 @@ labels:
{% /tabs %}
`binary`パラメータを_true_に設定すると、16進数文字列を使用したコンパクトなレスポンスを受け取ります。人間が読めるものではありませんが、より簡潔です。
`binary`パラメータを _true_ に設定すると、16進数文字列を使用したコンパクトなレスポンスを受け取ります。人間が読めるものではありませんが、より簡潔です。
{% tabs %}

View File

@@ -464,7 +464,7 @@ path_findコマンドには3種類のモードサブコマンドがあり
* [汎用エラータイプ][]のすべて。
* `invalidParams` - 1つ以上のフィールドの指定が正しくないか、1つ以上の必須フィールドが指定されていません。
* `noEvents` - 非同期コールバックをサポートしていないプロトコルJSON-RPCなどを使用しています。JSON-RPCと互換性が_ある_Pathfindingメソッドについては、[ripple_path_findメソッド][]をご覧ください。)
* `noEvents` - 非同期コールバックをサポートしていないプロトコルJSON-RPCなどを使用しています。JSON-RPCと互換性が _ある_ Pathfindingメソッドについては、[ripple_path_findメソッド][]をご覧ください。)
### 非同期フォローアップ
@@ -539,7 +539,7 @@ Pathfindingリクエストが正常にクローズされた場合、レスポン
* [汎用エラータイプ][]のすべて。
* `invalidParams` - フィールドの指定が正しくないか、必須フィールドが指定されていません。
* `noEvents` - 非同期コールバックをサポートしていないプロトコルJSON-RPCなどでこのメソッドを使用しようとしました。JSON-RPCと互換性が_ある_Pathfindingメソッドについては、[ripple_path_findメソッド][]をご覧ください。)
* `noEvents` - 非同期コールバックをサポートしていないプロトコルJSON-RPCなどでこのメソッドを使用しようとしました。JSON-RPCと互換性が _ある_ Pathfindingメソッドについては、[ripple_path_findメソッド][]をご覧ください。)
* `noPathRequest` - Pathfindingリクエストをクローズしようとしましたが、実行中のリクエストがありませんでした。
## path_find status
@@ -584,7 +584,7 @@ Pathfindingリクエストが実行中の場合、レスポンスは[`path_find
* [汎用エラータイプ][]のすべて。
* `invalidParams` - 1つ以上のフィールドの指定が正しくないか、1つ以上の必須フィールドが指定されていません。
* `noEvents` - 非同期コールバックをサポートしていないプロトコルJSON-RPCなどを使用しています。JSON-RPCと互換性が_ある_Pathfindingメソッドについては、[ripple_path_findメソッド][]をご覧ください。)
* `noEvents` - 非同期コールバックをサポートしていないプロトコルJSON-RPCなどを使用しています。JSON-RPCと互換性が _ある_ Pathfindingメソッドについては、[ripple_path_findメソッド][]をご覧ください。)
* `noPathRequest` - Pathfindingリクエストのステータスを確認しようとしましたが、処理中のリクエストがありませんでした。
{% raw-partial file="/docs/_snippets/common-links.md" /%}

View File

@@ -58,7 +58,7 @@ const xrpl = require("xrpl");
[分散型取引所](../concepts/tokens/decentralized-exchange/index.md)の状態を調べる時のように、完了見込みの多数のトランザクション結果が保留中であるため、現時点のオープンレジャーを使用したい場合があります。また、完了したトランザクション結果を取り込んだ検証済みのレジャーを使用したい場合もあります。
xrpl.js 2.0が`Client.request()`を使用してAPIリクエストをする際、明確に[使用するレジャー番号を指定する](protocol/data-types/basic-data-types.md#specifying-ledgers)必要があります。例えば、最新の_検証済みレジャー_を使用してトラストラインを調べるためには:
xrpl.js 2.0が`Client.request()`を使用してAPIリクエストをする際、明確に[使用するレジャー番号を指定する](protocol/data-types/basic-data-types.md#specifying-ledgers)必要があります。例えば、最新の _検証済みレジャー_ を使用してトラストラインを調べるためには:
**ripple-lib 1.x:**

View File

@@ -72,7 +72,7 @@ XRP Ledgerの分散型取引所(DEX)には、「アルゴリズムトレード
### トレードの発注
XRP Ledgerの分散型取引所で_代替可能_トークンとXRPを売買するには、通常[OfferCreateトランザクション](../../references/protocol/transactions/types/offercreate.md)を送信します。この方法でトレードを行うためのコードと技術的ステップの詳細なウォークスルーについては、[分散型取引所でのトレード](../../tutorials/how-tos/use-tokens/trade-in-the-decentralized-exchange.md)をご覧ください。[Paymentトランザクション](../../references/protocol/transactions/types/payment.md)を使用して通貨を両替することも可能です。[クロスカレンしー支払い](../../concepts/payment-types/cross-currency-payments.md)を他のユーザに送ったり、長い[パス](../../concepts/tokens/fungible-tokens/paths.md)を使って裁定取引の機会を1つの操作にまとめることで、自分自身に送り返すこともできます。
XRP Ledgerの分散型取引所で _代替可能_ トークンとXRPを売買するには、通常[OfferCreateトランザクション](../../references/protocol/transactions/types/offercreate.md)を送信します。この方法でトレードを行うためのコードと技術的ステップの詳細なウォークスルーについては、[分散型取引所でのトレード](../../tutorials/how-tos/use-tokens/trade-in-the-decentralized-exchange.md)をご覧ください。[Paymentトランザクション](../../references/protocol/transactions/types/payment.md)を使用して通貨を両替することも可能です。[クロスカレンしー支払い](../../concepts/payment-types/cross-currency-payments.md)を他のユーザに送ったり、長い[パス](../../concepts/tokens/fungible-tokens/paths.md)を使って裁定取引の機会を1つの操作にまとめることで、自分自身に送り返すこともできます。
NFTをトレードするためのコードと技術的な手順については、[JavaScriptを使用したNFTokenの送信](../../tutorials/javascript/nfts/transfer-nfts.md)をご覧ください。