From feea33a9169a389651513491dc4f2b8af0ce7fe3 Mon Sep 17 00:00:00 2001 From: AKCodez Date: Mon, 28 Aug 2023 15:10:36 +0000 Subject: [PATCH] deploy: 6895569355c18e9a6439e0ee248b7e4871e2ccdf --- .../ja/amendments-object.html | 2 +- .../messaging-updates/ja/amendments.html | 215 ++------ pr-preview/messaging-updates/ja/feature.html | 8 +- .../ja/known-amendments.html | 494 ++++++++++++------ .../ja/xrp-ledger-overview.html | 2 +- pr-preview/messaging-updates/style_report.txt | 50 +- .../xrp-ledger-overview.html | 2 +- 7 files changed, 426 insertions(+), 347 deletions(-) diff --git a/pr-preview/messaging-updates/ja/amendments-object.html b/pr-preview/messaging-updates/ja/amendments-object.html index a79eadf73a9..b3db75db22e 100644 --- a/pr-preview/messaging-updates/ja/amendments-object.html +++ b/pr-preview/messaging-updates/ja/amendments-object.html @@ -333,7 +333,7 @@

AmendmentsのフィールドAmendments 配列 STI_VECTOR256 -（省略可） 現在有効なすべてのAmendmentの256ビットAmendment IDからなる配列。省略されている場合は、有効なAmendmentがありません。 +（省略可） 現在有効なすべてのAmendmentの256ビットAmendment IDからなる配列。省略されている場合は、有効なAmendmentがありません。 Majorities diff --git a/pr-preview/messaging-updates/ja/amendments.html b/pr-preview/messaging-updates/ja/amendments.html index 37720a56f71..cccfbc0fc55 100644 --- a/pr-preview/messaging-updates/ja/amendments.html +++ b/pr-preview/messaging-updates/ja/amendments.html @@ -271,13 +271,11 @@

目次

@@ -297,173 +295,68 @@

目次

Amendment

-

導入: rippled 0.31.0

-

Amendmentシステムは、混乱を生じさせることなく、分散型のXRP Ledgerネットワークに新しい機能を導入する方法を提供します。Amendmentシステムは、ネットワークのコンセンサスの主要プロセスを利用して、継続的なサポートを含めて変更を承認し適用される仕組みになっています。Amendmentを適用するには通常、80%のサポートが2週間にわたって必要になります。

-

Amendmentが有効になると、そのAmendmentが含まれているバージョン以降のすべてのレジャーバージョンに永続的に適用されます。Amendmentを無効にすることはできません。ただし、Amendmentを無効にするための新しいAmendmentを導入する場合は除きます。

-

既知のAmendment、それらのステータス、およびIDのリストについては、以下を参照してください: 既知のAmendment

-

背景

-

トランザクション処理に変更があると、サーバーで同じトランザクションのセットを使用して別のレジャーが作成される場合があります。一部の バリデータ （コンセンサスに参加しているrippledサーバー）が古いバージョンのソフトウェアを使用している状態で、他のバリデータが新しいバージョンのソフトウェアにアップグレードすると、ごく小さな問題から、場合によっては完全機能停止などの問題が生じる可能性があります。希なケースでは、少数のサーバーにおいて、実際のコンセンサスレジャーを取得するために、より多くの時間と帯域幅が使用される場合があります。既知のトランザクションの処理ルールを使ってレジャーを構築できないためです。最悪の場合、異なるルールを使用するサーバー間で当該レジャーについてコンセンサスに達することができないため、コンセンサスプロセスにより新しいレジャーバージョンを検証できない可能性があります。

-

Amendmentはこの問題を解決し、十分なバリデータがそれらの機能をサポートしている場合にのみ新しい機能を有効にします。

-

XRP Ledgerを使用しているユーザーや企業は、業務に影響を及ぼす可能性があるトランザクション処理の変更について事前に通知するためにAmendmentを使用することもできます。ただし、トランザクション処理やコンセンサスプロセスに影響のないAPIを変更する場合、Amendmentは不要です。

-

Amendmentについて

-

Amendmentは、正常に動作する機能や変更であり、コンセンサスプロセスの一環としてピアツーピアサーバーのネットワークで有効になるのを待っています。Amendmentを使用するrippledサーバーには、Amendmentなし（古い動作）とAmendmentあり（新しい動作）の2種類のモードのコードがあります。

-

各Amendmentには、識別用の一意の16進値および短縮名が付けられています。短縮名は人間が使用するためのものであり、Amendmentプロセスでは使用されません。説明用に異なった名前を使った場合でも、2つのサーバーで同じAmendment IDを使用できます。Amendmentの名前が一意であるという保証はありません。

-

慣例により、Rippleの開発者は、Amendment名のSHA-512ハーフハッシュをAmendment IDとして使用します。

+

Amendmentは、トランザクション処理における新機能またはその他の変更を表します。

+

変更システムは、XRP Ledger上のトランザクション処理に影響を与える変更を合意形成プロセスを用いて承認します。完全に機能するトランザクション処理の変更は、Amendmentとして提出され、バリデータはその変更について投票します。もしAmendmentが2週間にわたって80%超の支持を得た場合、そのAmendmentは可決され、その後のすべてのレジャーバージョンに変更が恒久的に適用されます。可決されたAmendmentを無効にするには、別の新たなAmendmentが必要です。

+

注記: トランザクションプロセスを変更するバグ修正にも、Amendmentが必要です。

+

Amendmentプロセス

-

256番目毎のレジャーは、「フラグ」レジャーと呼ばれます。Amendmentの承認プロセスは、フラグレジャーの直前のレジャーバージョンで開始されます。rippledのバリデータサーバーは、そのレジャーの検証メッセージを送信するときに、具体的なAmendmentへの賛成票も送信します。バリデータがAmendmentに賛成票を投じない場合は、そのAmendmentに対して反対票を投じていることを意味します。（手数料の投票もフラグレジャーで行われます。）

-

フラグレジャー自体に特別な内容はありません。ただし、その間、サーバーは信頼するバリデータの投票を確認し、EnableAmendment 疑似トランザクションを次のレジャーに挿入するかどうかを決定します。EnableAmendmentの疑似トランザクションのフラグは、サーバーが発生したとみなす内容を示しています。

-
    -
  • tfGotMajorityフラグは、Amendmentのサポートが、信頼できるバリデータの80%以上に増加したことを意味します。
    • -
  • tfLostMajorityフラグは、Amendmentのサポートが、信頼できるバリデータの80%未満に減少したことを意味します。
    • -
  • フラグのないEnableAmendment擬似トランザクションは、そのAmendmentのサポートが有効になっていることを意味します。（トランザクション処理の変更は、これ以降のすべてのレジャーに適用されます。）
    • -
-

次の条件がすべて満たされた場合にのみ、サーバーは疑似トランザクションを挿入してAmendmentを有効にします。

+

XRP Ledgerのコードに貢献するのトピックでは、XRP Ledgerのアイデアから有効化までのワークフローを説明しています。

+

Amendmentのコードがソフトウェアリリースに組み込まれた後、それを有効にするプロセスはXRP Ledgerネットワーク内で行われ、レジャーは フラグ レジャーごとに(通常約15分間隔で)Amendment状況をチェックします。

+

256番目毎のレジャーは、フラグレジャーと呼ばれます。フラグレジャーは特別な内容を持っているわけではありませんが、フラグレジャーの前後ではAmendment作業が行われます。

+
    +
  1. フラグレジャー -1: rippledバリデータが検証メッセージを送信するとき、彼らは自身でAmendmentへの投票も送信します。
    2. +
  2. フラグレジャー: サーバは、信頼できるバリデーターからの投票を処理します。
    3. +
  3. +

    フラグレジャー +1: サーバはEnableAmendment疑似トランザクションを挿入し、発生したと思われることに基づいてフラグを立てます。

      -
    • このAmendmentはまだ有効になっていない。
      • -
    • 前のレジャーには、tfGotMajorityフラグが有効な状態で、このAmendmentに対するEnableAmendment疑似トランザクションが含まれている。
      • -
    • 当該前レジャーは、現行のレジャーの前のバージョンである。
      • -
    • 当該前レジャーの終了時刻は、最新のフラグレジャーの終了時刻の少なくとも2週間前である。
      • -
    • tfGotMajority疑似トランザクションと現行のレジャーの間のコンセンサスレジャーには、この修正に対するEnableAmendment疑似トランザクションで、tfLostMajorityフラグが有効になっているものはない。
      • +
    • tfGotMajorityフラグは、そのAmendmentが80%超の支持を得ていることを意味します。
      • +
    • tfLostMajorityフラグはAmendmentへの支持が80%以下になったことを意味します。
      • +
    • フラグなしは、Amendmentが有効であることを意味します。
    -

    理論的には、tfLostMajority EnableAmendment擬似トランザクションを、Amendmentを有効にするための擬似トランザクションと同じレジャーに含めることができます。この場合、tfLostMajority擬似トランザクションを含む擬似トランザクションは効果がありません。

    +

    注記: Amendmentが有効化されるために必要な2週間の期間に達したのと同一のレジャーで、80%の支持を失う可能性があります。このような場合、両方のシナリオで EnableAmendment擬似トランザクションが追加されますが、最終的にそのAmendmentは有効になります。

    +
    4. +
  4. +

    フラグレジャー +2: Amendmentが有効になった場合、このレジャー以降のトランザクションに適用されます。

    +
    5. +

Amendment投票

-

rippledの各バージョンは、既知のAmendmentのリストとそれらのAmendmentを実装するためのコードでコンパイルされています。デフォルトでは、rippledは既知のAmendmentをサポートし、未知のAmendmentに反対します。rippledバリデータのオペレーターは、特定のAmendmentがrippledバージョンにとって既知でない場合でも、そのAmendmentを明示的にサポートまたは反対するようにサーバーを設定することができます。

-

有効にするには、Amendmentが、信頼済みのバリデータの80%以上に2週間継続してサポートされている必要があります。Amendmentのサポートが信頼できるバリデータの80%を下回ると、そのAmendmentは一時的に拒否されます。Amendmentが信頼済みのバリデータの少なくとも80%のサポートを取り戻した場合は、そこから2週間の期間が再スタートします。（この状況は、バリデータの投票内容が変わった場合や、バリデータの信頼に変化があった場合に発生します。）Amendmentが永続的に有効になるまでに、何度も過半数の支持を得たり失ったりすることがあります。Amendmentが永続的に拒否されることはありませんが、新しいバージョンのrippledの既知のAmendmentのリストにないAmendmentが有効になることはほとんどありません。

-

コンセンサスプロセスのすべてにおいてと同様に、Amendmentの投票は、投票を送信しているバリデータを信頼するサーバーによってのみ有効とみなされます。現時点では、Ripple社は、Rippleが運用するデフォルトのバリデータのみを信頼することを推奨しています。今のところ、新機能のリリースに関してRippleと協力するには、それらのバリデータのみを信頼するだけで十分です。

-

Amendment投票の設定

-

featureメソッドを使用してAmendmentを一時的に設定できます。サーバーのAmendmentに対するサポートを永続的に変更するには、サーバーのrippled.cfgファイルを変更します。

-

サーバーに賛成票を投じさせたくないAmendmentを表示するには、[veto_amendments]スタンザを使用します。各行には1つのAmendmentの一意のIDを含める必要があり、必要に応じて、その後にAmendmentの短縮名を続けます。例:

-
[veto_amendments]
-C1B8D934087225F509BEB5A8EC24447854713EE447D277F69545ABFA0E0FD490 Tickets
-DA1BD556B42D85EA9C84066D028D355B52416734D3283F85E216EA5DA6DB7E13 SusPay
-
-

投票するAmendmentを表示するには、[amendments]スタンザを使用します。（ここで表示しなくても、サーバーは、適用方法を把握しているすべてのAmendmentにデフォルトで賛成票を投じます。）各行には1つのAmendmentの一意のIDを含める必要があり、必要に応じて、その後にAmendmentの短縮名を続けます。例:

-
[amendments]
-4C97EBA926031A7CF7D7B36FDE3ED66DDA5421192D63DE53FFB46E43B9DC8373 MultiSign
-42426C4D4F1009EE67080A9B7965B44656D7714D104A72F9B4369F97ABF044EE FeeEscalation
-
-

Amendment blocked

-

投票プロセス後にネットワークに対してAmendmentが有効になると、そのAmendmentを認識していない、以前のバージョンのrippledを実行しているサーバーは、ネットワークのルールを認識できなくなるため、「Amendment blocked」状態になります。Amendment blockedの状態のサーバーは次のようになります。

+

rippledの各バージョンは、既知のAmendmentのリストとそれらのAmendmentを実装するためのコードでコンパイルされています。rippledバリデータのオペレータは、各Amendmentに投票するようにサーバを設定し、いつでも変更することができます。オペレータが投票を選択しない場合、サーバはソースコードで定義されたデフォルトの投票を使用します。

+

注記: デフォルトの投票はソフトウェアのリリースごとに変更される可能性があります。更新: rippled 1.8.1

+

Amendmentが有効になるには、信頼できるバリデータの80%超から2週間の支持を得なければなりません。支持率が80%以下となると、そのAmendmentは一時的に却下され、再び2週間の支持が必要となります。Amendmentは、恒久的に有効になるまで、何度でも過半数を獲得したり失ったりすることができます。

+

有効化されずにソースコードが削除されたAmendmentは、ネットワークによって撤回されたとみなされます。

+

Amendmentブロックされたサーバ

+

+

AmendmentブロックはXRP Ledgerデータの正確性を守るためのセキュリティ機能です。Amendmentが有効になると、Amendmentのソースコードなしで以前のバージョンのrippledを実行しているサーバは、ネットワークのルールを認識できなくなります。レジャーデータを推測して誤って解釈するのではなく、これらのサーバーはAmendmentブロックされた状態になります。Amendmentブロック状態のサーバは次のことが行えません。。

    -
  • レジャーのバリデータを判断できない
    • -
  • トランザクションを送信または処理できない
    • -
  • コンセンサスプロセスを行わない
    • -
  • 今後のAmendmentに投票しない
    • +
  • レジャーのバリデータの判断
    • +
  • トランザクションの送信または処理
    • +
  • 合意プロセスへの参加
    • +
  • Amendmentへの投票
-

Amendment blockedは、XRP Ledgerに依存するアプリケーションを保護するためのセキュリティー機能です。新しいルールが適用された後のレジャーを推測したり誤解したりしないように、rippledは、Amendmentがどのように動作するか確認できないためにレジャーの状態が不明であると報告します。

-

rippledサーバーが賛成票または反対票を投じるように設定されているAmendmentは、そのサーバーがAmendment blockedの状態になるかどうかに影響を与えません。rippledサーバーは、可能な限り、ネットワークの他の部分によって有効なった一連のAmendmentに従います。有効なAmendmentがサーバーのソースコード内のAmendment定義に含まれていない場合、つまりAmendmentがサーバーよりも新しい場合にのみ、サーバーはAmendment blockedになります。

-

サーバーがAmendment blockedである場合は、新しいバージョンにアップグレードしてネットワークと同期する必要があります。

-

rippledサーバーがAmendment blockedの状態かどうかを確認する方法

-

rippledサーバーがAmendment blockedの状態であるという最初の兆候のひとつに、トランザクションの送信時に返されるamendmentBlockedエラーがあります。amendmentBlockedエラーの例を以下に示します。

-
{
-   "result":{
-      "error":"amendmentBlocked",
-      "error_code":14,
-      "error_message":"Amendment blocked, need upgrade.",
-      "request":{
-         "command":"submit",
-         "tx_blob":"479H0KQ4LUUXIHL48WCVN0C9VD7HWSX0MG1UPYNXK6PI9HLGBU2U10K3HPFJSROFEG5VD749WDPHWSHXXO72BOSY2G8TWUDOJNLRTR9LTT8PSOB9NNZ485EY2RD9D80FLDFRBVMP1RKMELILD7I922D6TBCAZK30CSV6KDEDUMYABE0XB9EH8C4LE98LMU91I9ZV2APETJD4AYFEN0VNMIT1XQ122Y2OOXO45GJ737HHM5XX88RY7CXHVWJ5JJ7NYW6T1EEBW9UE0NLB2497YBP9V1XVAEK8JJYVRVW0L03ZDXFY8BBHP6UBU7ZNR0JU9GJQPNHG0DK86S4LLYDN0BTCF4KWV2J4DEB6DAX4BDLNPT87MM75G70DFE9W0R6HRNWCH0X075WHAXPSH7S3CSNXPPA6PDO6UA1RCCZOVZ99H7968Q37HACMD8EZ8SU81V4KNRXM46N520S4FVZNSJHA"
-      },
-      "status":"error"
-   }
-}
-
-

次のrippledログメッセージも、サーバーがAmendment blockedであることを示しています。

-
2018-Feb-12 19:38:30 LedgerMaster:ERR One or more unsupported amendments activated: server blocked.
-
-

rippledバージョン0.80.0以降を使用している場合は、server_infoコマンドを使用してrippledサーバーがAmendment blockedであるかを確認できます。応答内で、result.info.amendment_blockedを探します。amendment_blockedがtrueに設定されている場合、サーバーはAmendment blockedの状態です。

-

JSON-RPC応答の例:

-
{
-    "result": {
-        "info": {
-            "amendment_blocked": true,
-            "build_version": "0.80.1",
-            "complete_ledgers": "6658438-6658596",
-            "hostid": "ip-10-30-96-212.us-west-2.compute.internal",
-            "io_latency_ms": 1,
-            "last_close": {
-                "converge_time_s": 2,
-                "proposers": 10
-            },
-...
-        },
-        "status": "success"
-    }
-}
-
-

サーバーがAmendment blockedでない場合、応答でamendment_blockedフィールドは返されません。

-

注意: rippled 0.80.0より前のバージョンでは、サーバーがAmendment blockedである場合でもamendment_blockedフィールドは含まれません。

-

Amendment blockedの状態のrippledサーバーのブロックを解除する方法

-

サーバーがAmendment blockedとなる原因となっているAmendmentをサポートするrippledバージョンにアップグレードします。Rippleでは、最新のrippledバージョンにアップグレードしてサーバーのブロックを解除し、ネットワークと再同期できるようにすることを推奨しています。

-

状況によっては、最新のバージョンよりも古いrippledバージョンにアップグレードすることで、サーバーのブロックを解除できる場合があります。これが可能なのは、その古いバージョンが、rippledサーバーをブロックしているAmendmentをサポートしている場合です。

-

警告: 最新のrippledバージョンでセキュリティーまたはその他の緊急の修正が提供されている場合は、できるだけ早く最新バージョンにアップグレードしてください。

-

最新バージョンよりも古いバージョンにアップグレードしてrippledサーバーのブロックを解除できるかどうかを判断するには、サーバーをブロックしている機能を調べ、そのブロックしている機能をサポートしているrippledバージョンを調べます。

-

rippledサーバーをブロックしている機能を調べるには、feature管理コマンドを使用します。"enabled" : trueと"supported" : falseを含む機能を探します。これらの機能の値は、最新のレジャーでAmendmentが現在有効になっている（必須）が、Amendmentをサポートまたは適用する方法がサーバーに認識されていないことを意味します。

-

JSON-RPC応答の例:

-
{
-    "result": {
-        "features": {
-            "07D43DCE529B15A10827E5E04943B496762F9A88E3268269D69C44BE49E21104": {
-                "enabled": true,
-                "name": "Escrow",
-                "supported": true,
-                "vetoed": false
-            },
-            "08DE7D96082187F6E6578530258C77FAABABE4C20474BDB82F04B021F1A68647": {
-                "enabled": true,
-                "name": "PayChan",
-                "supported": true,
-                "vetoed": false
-            },
-            "1562511F573A19AE9BD103B5D6B9E01B3B46805AEC5D3C4805C902B514399146": {
-                "enabled": false,
-                "name": "CryptoConditions",
-                "supported": true,
-                "vetoed": false
-            },
-            "157D2D480E006395B76F948E3E07A45A05FE10230D88A7993C71F97AE4B1F2D1": {
-                "enabled": true,
-                "supported": false,
-                "vetoed": false
-            },
-...
-            "67A34F2CF55BFC0F93AACD5B281413176FEE195269FA6D95219A2DF738671172": {
-                "enabled": true,
-                "supported": false,
-                "vetoed": false
-            },
-...
-            "F64E1EABBE79D55B3BB82020516CEC2C582A98A6BFE20FBE9BB6A0D233418064": {
-                "enabled": true,
-                "supported": false,
-                "vetoed": false
-            }
-        },
-        "status": "success"
-    }
-}
-
-

この例では、次の機能との競合により、rippledサーバーがAmendment blockedになっています。

+

rippledサーバーの投票設定は、そのサーバがAmendmentブロックされることに影響を与えません。rippledサーバは常に他のネットワークで有効になっているAmendmentに従うので、ブロックは単にルールの変更を認識するコードを持っているかどうかに基づいています。つまり、異なるAmendmentが有効になっている並列ネットワークにサーバを接続した場合も、Amendmentブロックされる可能性があるということです。例えば、XRP Ledgerの開発ネットでは通常、実験的なAmendmentが有効になっています。最新のプロダクションリリースのコードを使用している場合、あなたのサーバには実験的なAmendmentのコードが存在しない可能性が高いです。

+

最新バージョンのrippledにアップグレードすることで、Amendmentブロックされたサーバーのブロックを解除することができます。

+

Amendmentの削除

+

Amendmentを有効にすると、修正前の動作のソースコードはrippledに残ります。検証のためにレジャーの結果を再構築するなど、古いコードを保持するユースケースはありますが、Amendmentとレガシーコードの追跡は時間の経過とともに複雑さを増していきます。

+

XRP Ledger Standard 11d では、古いレジャーと関連する以前のレジャーのコードを破棄するプロセスを定義しています。メインネット上でAmendmentが2年間有効である場合、古いコードは削除することができます。Amendmentは自動的にコアプロトコルの一部となり、その後は追跡されず、Amendmentとして扱われず、Amendment前のコードはすべて削除されます。

+

関連項目

-

これらの機能をサポートしているrippledバージョンを見つけるには、既知のAmendmentを参照してください。

-

Amendmentのテスト

-

Amendmentが有効になっている場合のrippledの動作を確認するには、そのAmendmentが実稼働ネットワークで有効になる前に、rippledの構成ファイルを実行して強制的に機能を有効にします。これは、開発目的でのみサポートされています。

-

コンセンサスネットワークの他のメンバーはこの機能を有効にしていない可能性があるため、実稼働ネットワークに接続されている間はこの機能を使用しないでください。機能を強制的に有効にしてテストしている間は、スタンドアロンモードでrippledを実行する必要があります。

-

機能を強制的に有効にするには、[features]スタンザをrippled.cfgファイルに追加します。このスタンザで、有効にする機能の名前の短縮名を1行に1つずつ追加します。例:

-
[features]
-MultiSign
-TrustSetAuth
-
diff --git a/pr-preview/messaging-updates/ja/feature.html b/pr-preview/messaging-updates/ja/feature.html index b455fd43705..5cbf245c003 100644 --- a/pr-preview/messaging-updates/ja/feature.html +++ b/pr-preview/messaging-updates/ja/feature.html @@ -300,7 +300,7 @@

目次

feature

[ソース]

featureコマンドは、Amendmentに関してこのサーバーが認識している情報（Amendmentが有効であるかどうか、サーバーがAmendmentプロセスでこれらのAmendmentに賛成票を投じたかどうかなど）を返します。新規: rippled 0.31.0

-

featureコマンドを使用して、Amendmentへの賛成票または反対票を投じるようにサーバーを一時的に設定できます。この変更は、サーバーの再起動後までは持続しません。Amendment投票で持続する変更を行うにはrippled.cfgファイルを使用します。詳細は、Amendment投票の設定を参照してください。

+

featureコマンドを使用して、Amendmentへの賛成票または反対票を投じるようにサーバーを一時的に設定できます。この変更は、サーバーの再起動後も保持されます。更新: rippled 1.7.0

featureメソッドは、権限のないユーザーは実行できない管理メソッドです。

要求フォーマット

要求フォーマットの例:

@@ -474,12 +474,12 @@

応答フォーマットAmendment blockedになる可能性があります。 +サーバーがこのAmendmentの適用方法を認識しているかどうか。このフィールドがfalse（サーバーがこのAmendmentの適用方法を認識していない）に設定されており、enabledがtrue（このAmendmentが最新レジャーで有効である）に設定されている場合、このAmendmentによりサーバーがAmendmentブロックされる可能性があります。 vetoed -ブール値 -サーバーがこのAmendmentに反対票を投じるように指示されているかどうか。 +ブール値 または 文字列 +ほとんどのAmendmentにおいて、これはサーバがこのAmendmentに反対票を投じるように指示されているかどうかを示すブール値です。コードの中で廃止とマークされているAmendmentについては、代わりにObsoleteという文字列を指定します。更新: rippled 1.11.0 . diff --git a/pr-preview/messaging-updates/ja/known-amendments.html b/pr-preview/messaging-updates/ja/known-amendments.html index 5322fe3a58e..aacadd7b463 100644 --- a/pr-preview/messaging-updates/ja/known-amendments.html +++ b/pr-preview/messaging-updates/ja/known-amendments.html @@ -271,68 +271,76 @@

目次

@@ -354,23 +362,19 @@

目次

既知のAmendment

[ソース]

+

メインネットの既知のAmendment

以下に示すのは、本番環境のXRP Ledgerに関する既知のAmendmentのすべてとそのステータスをまとめた総合リストです。

ヒント: このリストは手動で更新されています。最新のステータスはXRPScan Amendment Dashboard をご覧下さい。

- + - - - - - @@ -383,27 +387,27 @@

既知のAmendmentDisallowIncoming

- + - + - + - + - + @@ -635,50 +639,147 @@

既知のAmendment

名前導入済み登場 ステータス
OwnerPaysFee未定開発中: 未定
fixNFTokenRemint v1.11.0 投票中: 2023-06-21 v1.10.0有効予想: 2023-08-21 有効: 2023-08-21
fixNonFungibleTokensV1_2 v1.10.0有効予想: 2023-08-21 有効: 2023-08-21
fixTrustLinesToSelf v1.10.0有効予想: 2023-08-21 有効: 2023-08-21
fixUniversalNumber v1.10.0有効予想: 2023-08-21 有効: 2023-08-21
ImmediateOfferKilled v1.10.0有効予想: 2023-08-21 有効: 2023-08-21
CheckCashMakesTrustLine有効: 2016/05/19

+

以下は、現在開発中のAmendmentのリストで、変更をテストするためのテストネットが利用可能です。

+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
名前ステータス追加情報
Hooks開発中: 未定XRPL Hooks
XChainBridge開発中: 未定XLS-38d ドキュメント
Clawback開発中: 未定XLS-39d ドキュメント
AMM開発中: 未定XLS-30d ドキュメント
OwnerPaysFee開発中: 未定
+

注記: このリストは手動で更新されています。もしあなたがAmendmentに取り組んでいて、その変更をテストするためのテストネットワークを持っているなら、このページを編集して開発中のamendmentをこのリストに追加することができます。XRPレジャーへの貢献についての詳細は、XRP Ledgerのコードへの貢献をご覧ください。

+

撤回または廃止されたAmendment

+

以下は、以前のバージョンで廃止され削除された、あるいは撤回され削除のマークが付けられた、既知のAmendmentの一覧です。

+ + + + + + + + + - + - + - + - + - + - + - + - +
名前登場ステータス
fixNFTokenNegOffer v1.9.2廃止: 削除未定撤回: 削除予定
fixNFTokenDirV1 v1.9.1廃止: 削除未定撤回: 削除予定
NonFungibleTokensV1 v1.9.0廃止: 削除未定撤回: 削除予定
CryptoConditionsSuite v0.60.0廃止: 削除未定撤回: 削除予定
SHAMapV2 v0.32.1禁止: v1.4.0で削除 廃止: v1.4.0で削除済み
FlowV2 v0.32.1禁止: v0.33.0で削除 廃止: v0.33.0で削除済み
SusPay v0.31.0禁止: v0.60.0で削除 廃止: v0.60.0で削除済み
Tickets v0.30.1禁止: v0.90.0で削除 廃止: v0.90.0で削除済み
-

注記: 多くの場合、旧バージョンのソフトウェアには不完全バージョンの修正用コードが存在します。上の表内の「導入済み」バージョンは最初の安定バージョンです。「未定」は、修正がまだ安定していないと見なされていることを示します。

-

CheckCashMakesTrustLine

+

既知のAmendmentsの詳細

+

AMM

+ + + + + + + + + + + + + + + + + + + + + + + + + +
AmendmentAutomated Market Maker
Amendment ID8CC0774A3BF66D1D22E76BBDA8E8A232E6B6313834301B3B23E8601196AE6455
ステータス開発中
デフォルトの投票(最新の安定版)いいえ
Amendment前の機能は廃止?いいえ
+

既存の分散型取引所と統合された形で、自動マーケットメーカー(AMM)機能に追加します。各アセット（トークンまたはXRP）のペアは、Ledger上に最大1つのAMMプールを持つことができ、誰でも流動性を提供することで、収益と為替リスクを比例配分することができます。各AMMプールのインスタンスはその資産を保持するための特別なアカウントを持ち、流動性プロバイダーに対してその預入額に応じて"LPトークン"を発行します。流動性プロバイダーは、LPトークンのシェアに基づいてAMMプールの取引手数料に投票することができます。ユーザは、一定期間取引手数料が割引される権利にLPトークンを使って入札することができます。

+

追加される新規トランザクション

+
    +
  • AMMBid - 取引手数料を割引するAMMプールのオークション枠に入札します。
    • +
  • AMMCreate - AMMプールの新しいインスタンスを作成し、初期資金を供給します。
    • +
  • AMMDelete - 空となったAMMプールのインスタンスを削除します。
    • +
  • AMMDeposit - 既存のAMMプールに資金を供給し、LPトークンを受け取ります。
    • +
  • AMMWithdraw - LPトークンをAMMプールに返却して資金を引き出します。
    • +
  • AMMVote - AMMプールの取引手数料について投票します。
    • +
+

既存のトランザクションを新たな機能でアップデートします。

+
    +
  • 資産の取引に利用可能なPaymentとOfferCreateトランザクションは、より最良の取引レートを利用可能とするためにOfferとAMMの任意の組み合わせを利用します。
    • +
  • AMMの特別なアカウントに送信できないトランザクションがあります（例えば、AMMはCheckを換金できないため、AMMへのCheckCreateは許可されません）。
    • +
+

新しいタイプのレジャーエントリAMMを追加し、AccountRootレジャーエントリタイプにAMMIDフィールドを追加します。

+

いくつかの新しい結果コードを追加します。

+

CheckCashMakesTrustLine

@@ -708,7 +809,7 @@

CheckCashMakesTrustLineCheckCashトランザクションを修正し、Checkを現金化して発行されたトークンを入手すると、トークンを保持するトラストラインを自動的に作成するようにしました。この新しい動作は、ユーザーが分散型取引所でトークンを購入する際のOfferCreateトランザクションの動作に似ています。自動的に作成されたトラストラインには限度額0が設定されています。これにより、Checkでトークンを受け取る前にトラストラインを設定するという設定ステップがなくなります。(XRPを送信するCheckは影響を受けません)。

この修正を適用しない場合、ユーザーは、Checkを発行トークンと交換する前に、別途TrustSetトランザクションを送信する必要があります。

この修正は、XRP Ledgerにおいて不要なトークンを保持することを誰にも強制できないという原則を変えるものではありません。

-

Checks

+

Checks

@@ -738,8 +839,65 @@

Checks

+

Clawback

+
+ + + + + + + + + + + + + + + + + + + + + + + + +
AmendmentClawback
Amendment ID56B241D7A43D40354D02A9DC4C8DF5C7A1F930D92A9035C4E12291B3CA3E1C2B
Status開発中
デフォルトの投票(最新の安定版)いいえ
Amendment前の機能は廃止?いいえ
+

規制上の目的から、発行者の中には、発行されたトークンがアカウントに配布された後に回収する能力を持たなければならない場合があります。例えば、トークンが違法行為で制裁を受けたアカウントに送られたことが発覚した場合、発行者はその資金を 回収(claw back) することができます。

+

Clawbackはデフォルトでは無効になっています。Clawbackを使用するには、AccountSetトランザクションを使用してlsfAllowTrustLineClawbackフラグを設定する必要があります。

+

この修正の詳細については、Clawback をご覧ください。

+

XChainBridge

+ + + + + + + + + + + + + + + + + + + + + + + + + +
AmendmentXChainBridge
Amendment IDC98D98EE9616ACD36E81FDEB8D41D349BF5F1B41DD64A0ABC1FE9AA5EA267E9C
Status開発中
デフォルトの投票(最新の安定版)いいえ
Amendment前の機能は廃止?いいえ
+

メインネットとサイドチェーンなど異なるネットワーク間でアセットを同期させるための「クロスチェーンブリッジ」を追加します。標準規格: XLS-38d Cross-Chain Bridge 。

+

CryptoConditions

@@ -796,7 +954,7 @@

CryptoConditionsSuite

EscrowCreateトランザクションとEscrowFinishトランザクションで使用するために、公式のCrypto-Conditions仕様 から数種類のCrypto-Conditionsを導入するものでした。

しかし、この修正は実装が完了する前にrippled v0.60.0に追加されました。その結果、このAmendment IDは、ほとんど何もしない不完全なコードを参照することになりました。他のcrypto-conditionsのサポートを追加するために既存のAmendmentを変更すると、すでにリリースされたソフトウェアにある古いバージョンの修正案との衝突が発生します。将来のリリースで追加の暗号条件のサポートが追加される場合、新しい別のAmendment IDを使用する必要があります。

-

DeletableAccounts

+

DeletableAccounts

@@ -826,7 +984,7 @@

DeletableAccountsを削除できるようになります。

この修正を適用しない場合、新しいアカウントはSequence番号が必ず1で始まります。また、レジャーの状態データからアカウントを削除できません。

この修正を適用した場合、新しいアカウントは、そのアカウントが作成されたレジャーのインデックスに一致するSequence番号に等しいSequence番号で始まります。この変更により、一度削除され、その後再作成されたアカウントが、古いトランザクションを再度実行しないように保護することができます。新しいAccountDeleteトランザクションタイプを追加すると、アカウントと、そのアカウントがレジャーに所有する特定のオブジェクトが削除されます。ただし、特定の種類のオブジェクトはこの方法で削除できないため、そのようなオブジェクトに関連付けられているアカウントは削除できません。また、現行のレジャーインデックスから256を引いた値がアカウントの現行Sequence番号より低い場合も、アカウントは削除できません。この修正に関する詳しい解説については、XRP Community Standards Draft 7 を参照してください。

-

DepositAuth

+

DepositAuth

@@ -857,7 +1015,7 @@

DepositAuthChecks amendmentが有効である場合、CheckCashトランザクションを送信することによってXRPまたは発行済み通貨をアカウントで受け取ることができます。

例外として、DepositAuthが有効になっているアカウントでは、現在のXRP残高がアカウントの準備金を下回る場合、少額のXRP（アカウント準備金の最低額以下）のPaymentトランザクションを受け取ることができます。

また、EscrowCreateトランザクションとPaymentChannelCreateトランザクションで誤ってDisallowXRPフラグを適用してしまうバグも修正します。これは強制力のない勧告フラグとするものです。（レジャー自体にDisallowXRPフラグを適用しないことで、アカウント準備金を満たしトランザクションコストを支払うのに必要なXRPを、アカウントが引き続き受け取ることができます。）

-

DepositPreauth

+

DepositPreauth

@@ -888,7 +1046,7 @@

DepositPreauth

+

DisallowIncoming

@@ -903,7 +1061,7 @@

DisallowIncoming

+

EnforceInvariants

有効予想有効
デフォルトの投票(最新の安定版)
@@ -962,7 +1120,7 @@

EnforceInvariantsのタイプは変更できません。（LedgerEntryTypeフィールドは変更できません。）
  • XRPにトラストラインはありません。
    • -

    Escrow

    +

    Escrow

    @@ -991,7 +1149,7 @@

    Escrow

    SusPayおよびCryptoConditions Amendmentを置き換えます。

    XRP Ledger内のEscrowにXRPの「仮払い」機能を提供します。これにはInterledger Protocol Crypto-Conditions のサポートが含まれます。仮払い用のレジャーオブジェクトタイプと、仮払いを作成、実行、取り消すためのトランザクションタイプを新規作成します。

    -

    ExpandedSignerList

    +

    ExpandedSignerList

    @@ -1021,7 +1179,7 @@

    ExpandedSignerListの最大サイズは32エントリになります。さらに、各SignerEntryオブジェクトは、任意のデータを含む256ビットのWalletLocatorフィールドを含むことができます。この修正により、SignerListSetトランザクションもそれに応じて変更されます。

    -

    FeeEscalation

    +

    FeeEscalation

    @@ -1057,7 +1215,7 @@

    FeeEscalationLastLedgerSequenceによって有効期限切れとなる）
  • キュー内にトランザクションコストの高いトランザクションがたくさんあるため除外される
    • -

    fix1201

    +

    fix1201

    @@ -1086,7 +1244,7 @@

    fix1201に限度を正しく導入し、100%の料金にします。これは、TransferRate値の最大値である2000000000を表します。（この場合の100%の料金とは、送信する1ユニットごとに2ユニットの発行済み通貨を送信する必要があることを意味します。）この修正を行わない場合、有効な限度はTransferRate値の232-1、つまり約329%の料金となります。

    この修正を行う場合、AccountSetトランザクションのTransferRateを2000000000より高く設定すると、トランザクションは結果コードtemBAD_TRANSFER_RATEにて失敗します。以前のルールに従って高い値が設定されている既存のすべてのTransferRateには、そのまま高い率が適用されます。

    -

    fix1368

    +

    fix1368

    @@ -1114,7 +1272,7 @@

    fix1368

    +

    fix1373

    @@ -1143,7 +1301,7 @@

    fix1373を作成する際にエラーを引き起こすトランザクション処理の小さなバグを修正します。この結果、有効であっても正しく作成されていないパスを、支払いで使用できなくなりました。この修正を行わない場合、支払い時に好ましくないパスの使用を強制されたり、失敗したりする恐れがあります。

    fix1373 Amendmenによりこの問題は修正されるため、正しく作成されたパスを使用して支払いを行えます。また、現在は許可されているものの適切ではない一部のパスが無効になります。これには、同じオブジェクトを2回以上ループしてコンフリクトを起こすフィールドやパスを含むステップを持つパスが含まれます。

    -

    fix1512

    +

    fix1512

    @@ -1172,7 +1330,7 @@

    fix1512トランザクションが、不正確なエラーコードで失敗するトランザクション処理のバグを修正します。この修正を行わない場合、トランザクションの結果コードはtecクラスとなりますが、レジャーに入力されず、トランザクションコストは支払われません。

    この修正により、トランザクションは適切な結果コードtemBAD_AMOUNTにて失敗します。

    -

    fix1513

    +

    fix1513

    @@ -1201,7 +1359,7 @@

    fix1513

    +

    fix1515

    @@ -1232,7 +1390,7 @@

    fix1515

    +

    fix1523

    @@ -1261,7 +1419,7 @@

    fix1523に追加します。この修正を行わない場合、保留中のEscrowは送信者別にしか追跡できません。この修正により、account_objectsメソッドを使用して支払先アドレスごとに保留中のEscrowを調べることができます。ただし、この修正が有効になる前に作成された保留中のEscrowを除きます。また、この修正では、EscrowCreateトランザクションを支払先のトランザクション履歴に表示することができます。これはaccount_txメソッドによる表示と同様です。

    この修正により、新しいEscrowが送信者と受信者両方の所有者ディレクトリーに追加されます。また、Escrowレジャーオブジェクトに新しいDestinationNodeフィールドも追加され、支払先の所有者ディレクトリのどのページにEscrowがあるかを表示します。

    -

    fix1528

    +

    fix1528

    @@ -1290,7 +1448,7 @@

    fix1528

    +

    fix1543

    @@ -1324,7 +1482,7 @@

    fix1543、EscrowCreate、EscrowFinish
  • Payment Channelトランザクション: PaymentChannelClaim、PaymentChannelCreate、PaymentChannelFund
    • -

    fix1571

    +

    fix1571

    @@ -1356,7 +1514,7 @@

    fix1571にConditionフィールドまたはFinishAfterフィールド（またはその両方）が必要となるように変更します。この修正以前に作成された、ConditionやFinishAfterのいずれも持たないEscrowは、CancelAfter時間より前ならいつでも誰でも終了できます。
  • 時間ベースのEscrowが特定の状況下で終了されるのを誤って妨げる欠陥を修正します。
    • -

    fix1578

    +

    fix1578

    @@ -1388,7 +1546,7 @@

    fix1578を変更して、オファーがtfFillOrKillフラグを使用していて中止された場合に、新しい結果コードtecKILLEDが返されるようにします。この修正を行わない場合、オファーは中止されますが、トランザクション結果はtesSUCCESSになります。
  • TrustSetトランザクションを変更して、トラストラインがマイナス残高であるため、NoRippleフラグを有効にしようとしてもできない場合に、tecNO_PERMISSIONで失敗するようにします。この修正を行わない場合、トランザクションでNoRippleフラグを有効にできなくても、トランザクション結果はtesSUCCESSになります。
    • -

    fix1623

    +

    fix1623

    @@ -1418,7 +1576,7 @@

    fix1623 Amendmentが有効でないかぎり効果がありません。）

    この修正を行うと、トランザクション処理にて変動金額のCheckCashトランザクションのメタデータにDeliveredAmountフィールドが追加されます（DeliverMinフィールドを使用します）。この変更はレジャーデータに書き込まれるため、この修正を行わずにトランザクションを処理した場合とは異なるレジャーハッシュとなります。これは実際に送信される金額には影響しません。また、この修正を有効にすると、txメソッドとaccount_txメソッドによってCheckCashトランザクションのdelivered_amountフィールドが返されます。（delivered_amountフィールドはトランザクションの検索時に計算されるものであり、レジャーに書き込まれるデータの一部ではありません。）

    fix1623 Amendmentは、固定金額のCheckCashトランザクション（Amountフィールドを使用）またはその他のトランザクションタイプには影響しません。

    -

    fix1781

    +

    fix1781

    @@ -1448,7 +1606,7 @@

    fix1781の入力がXRPで、パスの中間ステップでもXRPが出力されるようなパスが存在し得ます。これは「ループ」決済であり、前方と後方で実行すると異なる結果になる可能性があるため、決済エンジンはこのようなパスを禁止しています。

    この修正が適用された場合、これらの支払いは、代わりに結果コードtemBAD_PATH_LOOPで失敗します。

    -

    fixAmendmentMajorityCalc

    +

    fixAmendmentMajorityCalc

    @@ -1477,7 +1635,7 @@

    fixAmendmentMajorityCalc

    +

    fixCheckThreading

    @@ -1506,7 +1664,7 @@

    fixCheckThreading履歴に適切に追加されるようにします。（具体的には、受信アカウントのAccountRootオブジェクトのPreviousTxnIDフィールドとPreviousTxnLedgerSeqフィールドを更新します。これは、アカウントと、アカウントが所有するオブジェクトに影響を及ぼしたトランザクションの「スレッド」を追跡するために使用できます。）

    この修正を適用しない場合、Checksトランザクション（CheckCreate、CheckCash、およびCheckCancel）は送信者のアカウント履歴のみを更新します。この修正を適用した場合、これらのトランザクションは、送信アカウントにも受信アカウントにも影響します。この修正は、Checks Amendmentも有効でないかぎり効果がありません。

    -

    fixMasterKeyAsRegularKey

    +

    fixMasterKeyAsRegularKey

    @@ -1536,7 +1694,7 @@

    fixMasterKeyAsRegularKey

    +

    fixNFTokenDirV1

    @@ -1565,7 +1723,7 @@

    fixNFTokenDirV1 Amendmentが有効でない限り、何の効果もありません。この修正は、その効果がNonFungibleTokensV1_1の一部として含まれているため、廃止されました。

    -

    fixNFTokenNegOffer

    +

    fixNFTokenNegOffer

    @@ -1594,7 +1752,7 @@

    fixNFTokenNegOffer Amendmentのコードにおいて、NFTが負の金額で取引されてしまうバグを修正したものです。この修正が適用されない場合、ユーザーは負の金額でNFTの売買を申し込むことができ、その結果、NFTを「買う」人は「売る」人からお金も受け取ることになります。この修正により、マイナスの金額でのNFTのオファーは無効とみなされます。

    この修正は、NonFungibleTokensV1 Amendmentが有効でない限り、何の影響もありません。この修正は、その効果がNonFungibleTokensV1_1の一部として含まれているため、廃止されました。

    -

    fixNFTokenRemint

    +

    fixNFTokenRemint

    @@ -1609,7 +1767,7 @@

    fixNFTokenRemint

    +

    fixNonFungibleTokensV1_2

    In Development投票中
    デフォルトの投票(最新の安定版)
    @@ -1646,7 +1804,7 @@

    fixNonFungibleTokensV1_2

    Issue 4373 .

    -

    fixPayChanRecipientOwnerDir

    +

    fixPayChanRecipientOwnerDir

    ステータス有効予想有効
    デフォルトの投票(最新の安定版)
    @@ -1702,7 +1860,7 @@

    fixPayChanRecipientOwnerDirPaymentChannelCreateトランザクションタイプを変更し、受取人の所有者ディレクトリに新しいPayment Channelが追加されるようにします。この修正を適用しない場合、新しいPayment Channelは送金者の所有者ディレクトリーにのみ追加されます。この修正を有効にする場合、新しく作成したPayment Channelは両者の所有者ディレクトリーに追加されます。既存のPayment Channelは変更されません。

    この修正により、受取人によるPayment Channelの検索が容易になります。また、アカウントがオープンPayment Channelの受取人だった場合に、そのアカウントが削除されないようにします（ただし、この修正の前に作成されたチャンネルを除きます）。

    -

    fixQualityUpperBound

    +

    fixQualityUpperBound

    @@ -1731,7 +1889,7 @@

    fixQualityUpperBound

    +

    fixRemoveNFTokenAutoTrustLine

    @@ -1762,7 +1920,7 @@

    fixRemoveNFTokenAutoTrustLineこの修正が適用されない場合、攻撃者は意味のない新しい代替可能トークンを作り、そのトークンとNFTを売買することで、発行者に紐づく多数の無駄なトラストラインを作り、発行者の準備金を増加させることができます。

    この修正は、すでにミントされたNFTokenオブジェクトのコードを変更するものではありません。NonFungibleTokensV1_1がすでに有効になっているテストネットワークでは、tfTrustLineフラグが有効なNFTokenをすでにミントしている発行者は、fixRemoveNFTokenAutoTrustLine Amendmentの有効後も脆弱性があることを意味しています。

    この修正は、NonFungibleTokensV1または NonFungibleTokensV1_1が有効になっていない限り、影響を及ぼしません。発行者を保護するため、このamendmentはNonFungibleTokensV1またはNonFungibleTokensV1_1の前に有効にする必要があります。

    -

    fixRmSmallIncreasedQOffers

    +

    fixRmSmallIncreasedQOffers

    @@ -1792,7 +1950,7 @@

    fixRmSmallIncreasedQOffersfixSTAmountCanonicalize

    +

    fixSTAmountCanonicalize

    @@ -1820,7 +1978,7 @@

    fixSTAmountCanonicalize

    デシリアライズにおけるエッジケースの問題を修正しました。この修正が適用されない場合、一部の稀なケースで、この操作により、デシリアライズ中に有効なシリアライズされた金額がオーバーフローしてしまう可能性がありました。この修正により、XRP Ledgerはより迅速にエラー状態を検出し、問題となるようなケースを排除します。

    -

    fixTakerDryOfferRemoval

    +

    fixTakerDryOfferRemoval

    @@ -1850,7 +2008,7 @@

    fixTakerDryOfferRemovalオートブリッジのバグを修正します。ドライオファーとは、オファーを掛け合わせても資金を調達できないオファーのことです。

    この修正を行わなければ、ドライオファーがレジャー上に残り、所有者の必要準備金に加算されることになり、所有者に何も利益をもたらしません。正しいタイプとクオリティで掛け合わせた別のオファーによって、ドライオファーを除去することができます。ただし、タイプとクオリティがうまく掛け合わされたオファーがめったにない場合、ドライオファーの除去には時間がかかることがあります。

    この修正により、これらのドライオファーがオートブリッジで一致した場合に、XRP Ledgerによって除去されます。

    -

    fixTrustLinesToSelf

    +

    fixTrustLinesToSelf

    @@ -1865,7 +2023,7 @@

    fixTrustLinesToSelf

    +

    fixUniversalNumber

    有効予想有効
    デフォルトの投票(最新の安定版)
    @@ -1894,7 +2052,7 @@

    fixUniversalNumber

    は計算のために新しい3つめの計算方法を使用します。

    -

    Flow

    +

    Flow

    有効予想有効
    デフォルトの投票(最新の安定版)
    @@ -1937,7 +2095,7 @@

    Flow

    FlowV2 Amendmentに代わるものです。

    また、Flowエンジンは、さらなるAmendmentを通じて、支払いエンジンの改善や拡張を容易にします。

    -

    FlowCross

    +

    FlowCross

    @@ -1970,7 +2128,7 @@

    FlowCross

    +

    FlowSortStrands

    @@ -1999,7 +2157,7 @@

    FlowSortStrands

    +

    FlowV2

    @@ -2023,7 +2181,7 @@

    FlowV2

    Flow Amendmentの旧バージョンです。バグが原因で不採用となり 、バージョン0.33.0で除外されました。

    -

    HardenedValidations

    +

    HardenedValidations

    @@ -2051,7 +2209,35 @@

    HardenedValidations

    +

    Hooks

    +
    + + + + + + + + + + + + + + + + + + + + + + + + +
    AmendmentHooks
    Amendment IDECE6819DBA5DB528F1A241695F5A9811EF99467CDE22510954FD357780BBD078
    Status開発中
    デフォルトの投票(最新の安定版)いいえ
    Amendment前の機能は廃止?いいえ
    +

    トランザクションの前後にアカウント上で実行できる小さなコードという形式で、オンチェーンのスマートコントラクトを追加します。詳細はHooksドキュメント （英語のみ） をご覧ください。

    +

    ImmediateOfferKilled

    @@ -2066,7 +2252,7 @@

    ImmediateOfferKilled

    +

    MultiSign

    有効予想有効
    デフォルトの投票(最新の安定版)
    @@ -2120,7 +2306,7 @@

    MultiSign

    +

    MultiSignReserve

    @@ -2147,10 +2333,10 @@

    MultiSignReserve SignerListを所有する場合、アカウントに加算される所有者準備金を削減します。

    -

    この修正を行わない場合、SignerListの所有者準備金は、リスト内の署名者数に応じて15～50 XRPの範囲となります。

    -

    この修正により、新しいSignerListの所有者準備金は、署名者数に関係なく5 XRPとなります。以前に作成されたSignerListオブジェクトの準備金は、そのまま変更されません。この修正の後に作成されたSignerListオブジェクトの準備金を削減するには、この修正実施後に、SignerListSetトランザクションを使用してSignerListを置き換えます。（この置き換えは、前のバージョンの場合とまったく同じです。）

    -

    NegativeUNL

    +

    XRP LedgerアカウントがマルチシグSignerListを所有する場合、アカウントに加算される所有者準備金を削減します。

    +

    この修正を行わない場合、SignerListの所有者準備金は、リスト内の署名者数に応じて15～50XRPの範囲となります。

    +

    この修正により、新しいSignerListの所有者準備金は、署名者数に関係なく5XRPとなります。以前に作成されたSignerListオブジェクトの準備金は、そのまま変更されません。この修正の後に作成されたSignerListオブジェクトの準備金を削減するには、この修正実施後に、SignerListSetトランザクションを使用してSignerListを置き換えます。（この置き換えは、前のバージョンの場合とまったく同じです。）

    +

    NegativeUNL

    @@ -2178,7 +2364,7 @@

    NegativeUNL

    +

    NonFungibleTokensV1

    @@ -2222,7 +2408,7 @@

    NonFungibleTokensV1型を変更し、MintedNFTokens、BurnedNFTokens、NFTokenMinterの3つの新しい任意のフィールドを追加しています。

    また、AccountSetトランザクションを変更し、NFTokenMinterフィールドを設定できるようにしました。

    -

    NonFungibleTokensV1_1

    +

    NonFungibleTokensV1_1

    @@ -2258,7 +2444,7 @@

    NonFungibleTokensV1_1

    fixRemoveNFTokenAutoTrustLineは、このAmendmentの既知の問題を修正します。新しいテストネットワークを作成する場合、これらの修正を一緒に有効にするか、またはAmendmentの修正を先に有効にする必要があります。

    -

    OwnerPaysFee

    +

    OwnerPaysFee

    @@ -2288,7 +2474,7 @@

    OwnerPaysFeeOfferCreateトランザクションタイプとPaymentトランザクションタイプで、送金手数料の計算方法に相違があるのを修正します。この修正を行わない場合、オファーがオファープレースメントで実行される際にイシュアンスの保有者が送金手数料を支払いますが、トランザクションの最初の送信者は支払い処理の過程で実行されるオファーの送金手数料を支払います。この修正により、オファーがPaymentトランザクションまたはOfferCreateトランザクションの一部として実行されるかどうかにかかわらず、イシュアンスの保有者が常に送金手数料を支払います。支払い以外のオファー処理は影響を受けません。

    この修正については、Flow Amendmentを有効にする必要があります。

    注記: 不完全なバージョンのこのAmendmentについては、v0.33.0で導入され、v0.80.0で削除されました（有効となったことはありません）。

    -

    PayChan

    +

    PayChan

    @@ -2316,9 +2502,9 @@

    PayChanに役立つと期待しています。ある当事者がPayment Channelを作成し、そのチャンネル内に有効期限を事前に設定してXRPをいくらか確保します。次に、レジャー外部の安全な通信を介して、送信者は「クレーム」メッセージを受信者に送信できます。受信者は有効期限の終了前にクレームメッセージを清算することも、支払いが必要ない場合は清算しないことも選択できます。受信者は、クレームを実際にネットワークに分散させてコンセンサスプロセスで清算されるのを待たなくとも、請求を個々に確認してから、有効期限内であれば多数の少額クレームをまとめて後で清算することができます。

    -

    新たに作成するトランザクションタイプは次の3つです。PaymentChannelCreate、PaymentChannelClaim、PaymentChannelFund。新たに作成するレジャーオブジェクトタイプはPayChannelです。レジャー外のデータ構造Claimを定義し、ChannelClaimトランザクションに使用します。新たに作成するrippled APIメソッドは次のとおりです。channel_authorize （署名されたクレームを作成します）、channel_verify（署名されたクレームを検証します）、account_channels（アカウントに関連するチャンネルをリストを作成します）。

    +

    新たに作成するトランザクションタイプは次の3つです。PaymentChannelCreate、PaymentChannelClaim、PaymentChannelFund。新たに作成するレジャーオブジェクトタイプはPayChannelです。レジャー外のデータ構造Claimを定義し、ChannelClaimトランザクションに使用します。新たに作成するrippledAPIメソッドは次のとおりです。channel_authorize（署名されたクレームを作成します）、channel_verify（署名されたクレームを検証します）、account_channels（アカウントに関連するチャンネルをリストを作成します）。

    詳細は、Payment Channelsのチュートリアルを参照してください。

    -

    RequireFullyCanonicalSig

    +

    RequireFullyCanonicalSig

    @@ -2349,7 +2535,7 @@

    RequireFullyCanonicalSig

    マルチシグのトランザクションはまだ展性であるかもしれません)。すべてのトランザクションは、tfFullyCanonicalSigフラグに関係なく、署名の完全な正規の形式を使用する必要があります。完全に正規化された署名を作成しない署名ユーティリティはサポートされていません。Ripple社が提供するすべての署名ユーティリティは、少なくとも2014年以降、完全に正規化された署名のみを提供するようになっています。

    詳しくは、rippled issue #3042 を参照してください。

    -

    SHAMapV2

    +

    SHAMapV2

    @@ -2374,7 +2560,7 @@

    SHAMapV2

    +

    SortedDirectories

    @@ -2403,7 +2589,7 @@

    SortedDirectories内の項目をソートして、削除されるべき所有者ディレクトリのページが場合によっては削除されないというバグを修正します。

    警告: このが適用されていない旧バージョンのrippledは、新しいルールでソートされたDirectoryNodeによって機能が停止するおそれがあります。この問題を回避するには、rippledバージョン0.80.0以降にアップグレードしてください。

    -

    SusPay

    +

    SusPay

    @@ -2427,7 +2613,7 @@

    SusPay

    Escrow Amendmentに置き換えられました。

    -

    TicketBatch

    +

    TicketBatch

    @@ -2456,7 +2642,7 @@

    TicketBatch

    Ticketsが追加されます。

    標準規格案: XLS-13d .

    -

    Tickets

    +

    Tickets

    @@ -2480,7 +2666,7 @@

    Tickets Amendmentに置き換えられました。

    -

    TickSize

    +

    TickSize

    @@ -2509,7 +2695,7 @@

    TickSizeをランク付けする方法を変更して、通貨発行者がオファーを為替レートでランク付けする際に考慮する有効桁数を設定できるようにします。この修正により、オファーの交換レートが設定された有効桁数に丸められるため、同じ交換レートを持つオファーが増加します。この修正の目的は、以前のオファーよりもランク付けを高くするには、価格面で意味のある改善をしなければならないようにすることです。主要な発行者がこれを採用すれば、既存のオファーよりわずかなパーセンテージだけ上回るオファーでレジャーを攻撃しようとするスパムが低減します。また、よりバラツキの少ない為替レートでオファーをグループ化できるため、レジャー内のオーダーブックを効率的に保管できます。

    アカウントにTickSizeフィールドを追加します。このフィールドはAccountSetトランザクションタイプを使用して設定できます。通貨発行者がTickSizeフィールドを設定すれば、発行者の通貨を取引するオファーの為替レート（資金の入出金率）がXRP Ledgerによって丸められ、丸められた為替レートに合わせてオファーの金額が調整されます。トランザクションにて1つの通貨にのみTickSizeが設定されていれば、その有効桁数が適用されます。異なるTickSize値が設定された2つの通貨を取引する場合は、有効桁数が最も小さいTickSizeが適用されます。XRPにTickSizeは設定されません。

    -

    TrustSetAuth

    +

    TrustSetAuth

    @@ -2538,7 +2724,7 @@

    TrustSetAuth

    承認されたトラストラインを使用する場合に、会計関係の事前承認（ゼロバランストラストライン）を許可します。

    この修正が適用されれば、tfSetfAuthを有効にしたTrustSetトランザクションにおいて、RippleStateノードの他のすべての値をデフォルト状態にしたままでも、新しいRippleStateレジャーオブジェクトを作成できます。新しいRippleStateノードでは、トランザクションの送信者が低いノードと見なされるか高いノードと見なされるかに応じて、lsfLowAuthフラグまたはlsfHighAuthフラグが有効になります。トランザクションの送信者は、asfRequireAuthフラグを有効にしてAccountSetトランザクションを送信することで、事前にlsfRequireAuthを有効にしておく必要があります。

    -

    XRPFees

    +

    XRPFees

    @@ -2571,7 +2757,7 @@

    XRPFees

    validators, which anyone can operate, come to an agreement on the order and outcome of XRP transactions every three to five seconds.

    All servers in the network process each transaction according to the same rules, and any transaction that follows the protocol is confirmed right away. All transactions are public, and strong cryptography guarantees the integrity of the system.

    -

    Currently, over 150 validators are active on the ledger, operated by universities, exchanges, businesses, and individuals. As the validator pool grows, the consensus protocol ensures decentralization of the blockchain over time.

    +

    Currently, over 120 validators are active on the ledger, operated by universities, exchanges, businesses, and individuals. As the validator pool grows, the consensus protocol ensures decentralization of the blockchain over time.

    (Graphic: Validators in Consensus) diff --git a/pr-preview/messaging-updates/style_report.txt b/pr-preview/messaging-updates/style_report.txt index 7ee022de1a3..2aa51d56d80 100644 --- a/pr-preview/messaging-updates/style_report.txt +++ b/pr-preview/messaging-updates/style_report.txt @@ -3,7 +3,7 @@ Spell Checker ------------- Found 87 possible spelling errors: Unknown Words: - gifs: rifs, gins, gifts + gifs: gif, gies, gibs ringtee: kuressaare: lõõtsa: @@ -27,7 +27,7 @@ Found 87 possible spelling errors: Unknown Words: nft_history: - slas: slan, slays, sls + slas: slaps, blas, slask Unknown Words: validnftokenpage: @@ -40,71 +40,71 @@ Found 87 possible spelling errors: xlsd: lsd, xls Unknown Words: - fixnftokenremint: + depositpreauthamendment: fixuniversalnumber: - immediateofferkilled: - fixnonfungibletokensv1_2: disallowincoming: - depositpreauthamendment: xrpfees: - 39d: 3d, 3-d, 3rd - 30d: 3d, 3-d, 3rd + fixnonfungibletokensv1_2: + fixnftokenremint: + immediateofferkilled: + 30d: 3d, 3rd, 3-d + 38d: 3d, 3rd, 3-d + 39d: 3d, 3rd, 3-d xchainbridge: - 38d: 3d, 3-d, 3rd ammdelete: nftokenoffers: nftokenoffer asfdisallowincomingpaychan: asfdisallowincomingcheck: - asfdisallowincomingtrustline: asfdisallowincomingnftoffer: + asfdisallowincomingtrustline: Unknown Words: 0b0: - v3: vb, vc, vs + v3: v8, vu, v. Unknown Words: - mod1: mod, modo, mode + mod1: mod., mods, modi get_account: get_account_info: send_xrp: - lesson1: lesson, lessons - tkinter: tinter, twinter + lesson1: lessons, lesson + tkinter: twinter, tinter getstandbyaccount: get_standby_account_info: standby_send_xrp: Unknown Words: - mod2: mod, modo, mode + mod2: mod., mods, modi send_currency: get_balance: configure_account: - lesson2: lesson, lessons + lesson2: lessons, lesson Unknown Words: - mod3: mod, modo, mode + mod3: mod., mods, modi minttoken: gettokens: burn_token: Unknown Words: - mod4: mod, modo, mode + mod4: mod., mods, modi offer___index: alloffers: - lesson4: lesson, lessons + lesson4: lessons, lesson Unknown Words: buy___offer___index: - broker___fee: sell___offer___index: - lesson5: lesson, lessons + broker___fee: + lesson5: lessons, lesson Unknown Words: - mod6: mod, modo, mode + mod6: mod., mods, modi mint_other: Unknown Words: - 30d: 3d, 3-d, 3rd - v3: vb, vc, vs + 30d: 3d, 3rd, 3-d + v3: v8, vu, v. Unknown Words: fixnftokenremint: @@ -116,7 +116,7 @@ Found 87 possible spelling errors: Unknown Words: networkid: networked - v3: vb, vc, vs + v3: v8, vu, v. Unknown Words: nftokenoffers: nftokenoffer diff --git a/pr-preview/messaging-updates/xrp-ledger-overview.html b/pr-preview/messaging-updates/xrp-ledger-overview.html index 71076434c18..eacf8bf64d2 100644 --- a/pr-preview/messaging-updates/xrp-ledger-overview.html +++ b/pr-preview/messaging-updates/xrp-ledger-overview.html @@ -306,7 +306,7 @@
    Consensus
    To uphold performance, XRPL uses a consensus protocol. Designated servers called validators, which anyone can operate, come to an agreement on the order and outcome of XRP transactions every three to five seconds.

    All servers in the network process each transaction according to the same rules, and any transaction that follows the protocol is confirmed right away. All transactions are public, and strong cryptography guarantees the integrity of the system.

    -

    Currently, over 150 validators are active on the ledger, operated by universities, exchanges, businesses, and individuals. As the validator pool grows, the consensus protocol ensures decentralization of the blockchain over time.

    +

    Currently, over 120 validators are active on the ledger, operated by universities, exchanges, businesses, and individuals. As the validator pool grows, the consensus protocol ensures decentralization of the blockchain over time.

    (Graphic: Validators in Consensus)