既知のAmendment

[ソース]

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

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

名前 導入済み ステータス
CryptoConditionsSuite 未定 開発中: 未定
NegativeUNL 未定 開発中: 未定
OwnerPaysFee 未定 開発中: 未定
fixSTAmountCanonicalize v1.7.0 投票中: 未定
FlowSortStrands v1.7.0 投票中: 未定
TicketBatch v1.7.0 投票中: 未定
fix1781 v1.6.0 予定: 2021/04/08
fixAmendmentMajorityCalc v1.6.0 予定: 2021/04/08
HardenedValidations v1.6.0 予定: 2021/04/08
FlowCross v0.70.0 有効: 2020/08/04
fixQualityUpperBound v1.5.0 有効: 2020/07/09
RequireFullyCanonicalSig v1.5.0 有効: 2020/07/03
Checks v0.90.0 有効: 2020/06/18
DeletableAccounts v1.4.0 有効: 2020/05/08
fixCheckThreading v1.4.0 有効: 2020/05/01
fixPayChanRecipientOwnerDir v1.4.0 有効: 2020/05/01
fixMasterKeyAsRegularKey v1.3.1 有効: 2019/10/02
MultiSignReserve v1.2.0 有効: 2019/04/17
fixTakerDryOfferRemoval v1.2.0 有効: 2019/04/02
fix1578 v1.2.0 有効: 2019/03/23
DepositPreauth v1.1.0 有効: 2018/10/09
fix1515 v1.1.0 有効: 2018/10/09
fix1543 v1.0.0 有効: 2018/06/21
fix1623 v1.0.0 有効: 2018/06/20
fix1571 v1.0.0 有効: 2018/06/19
DepositAuth v0.90.0 有効: 2018/04/06
fix1513 v0.90.0 有効: 2018/04/06
fix1201 v0.80.0 有効: 2017/11/14
fix1512 v0.80.0 有効: 2017/11/14
fix1523 v0.80.0 有効: 2017/11/14
fix1528 v0.80.0 有効: 2017/11/14
SortedDirectories v0.80.0 有効: 2017/11/14
EnforceInvariants v0.70.0 有効: 2017/07/07
fix1373 v0.70.0 有効: 2017/07/07
Escrow v0.60.0 有効: 2017/03/31
fix1368 v0.60.0 有効: 2017/03/31
PayChan v0.33.0 有効: 2017/03/31
TickSize v0.50.0 有効: 2017/02/21
CryptoConditions v0.50.0 有効: 2017/01/03
Flow v0.33.0 有効: 2016/10/21
TrustSetAuth v0.30.0 有効: 2016/07/19
MultiSign v0.31.0 有効: 2016/06/27
FeeEscalation v0.31.0 有効: 2016/05/19
Tickets v0.30.1 禁止: v0.90.0で削除
SHAMapV2 v0.32.1 禁止: v1.4.0で削除
FlowV2 v0.32.1 禁止: v0.33.0で削除
SusPay v0.31.0 禁止: v0.60.0で削除

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

Checks

Amendment ID ステータス
157D2D480E006395B76F948E3E07A45A05FE10230D88A7993C71F97AE4B1F2D1 有効

「Checks」をXRP Ledgerに導入します。Checksは個人用の紙の小切手と同様の機能を持っています。送信者はトランザクションに署名して、具体的な最高額と受取人を入力したCheckを作成します。その後、受取人はCheckを換金して、指定された金額を上限として現金を受け取ることができます。金銭の移動が実際に発生するのはCheckが換金されるときなので、送信者の現在の残高と流動性の状況によっては、Checkを換金できない場合があります。Checkを換金できない場合、Checkオブジェクトはレジャーに残るため、後日換金できるようになる場合があります。

送信者と受信者は、換金前であればいつでもCheckを取り消すことができます。Checkには有効期限を設定できます。有効期限が過ぎた後は換金できなくなり、誰でもそのCheckを取り消すことができます。

新たに導入するトランザクションタイプは次の3つです。CheckCreate、CheckCancel、CheckCash。また、新しいレジャーオブジェクトタイプはCheckです。新たに追加するトランザクション結果コードtecEXPIREDは、有効期限が過去の日時であるCheckを作成しようとすると発生します。

この修正はまた、有効期限が過去の日時であるオファーを作成しようとすると、OfferCreateトランザクションがtecEXPIREDを返すように変更しています。この修正を行わない場合、OfferCreateの有効期限が過去の日時であってもtesSUCCESSが返されますが、オファーの作成や実行は行われません。

CryptoConditions

Amendment ID ステータス
1562511F573A19AE9BD103B5D6B9E01B3B46805AEC5D3C4805C902B514399146 有効

この修正は有効ですが、SusPay Amendmentも有効にならなければ効果がありません。RippleではSusPayを有効にする予定はありません。代わりに、Crypto-ConditionsをEscrow Amendmentに組み込む予定です。

CryptoConditionsSuite

Amendment ID ステータス
86E83A7D2ECE3AD5FA87AB2195AE015C950469ABF0B72EAACED318F74886AE90 開発中

EscrowCreateトランザクションとEscrowFinishトランザクションで使用するために、公式のCrypto-Conditions仕様 から数種類のCrypto-Conditionsを導入します。この修正を行わない場合、サポートされるのはPREIMAGE-SHA-256タイプのみです。

注意: この修正は開発中 です。rippledv0.60.0以降のバージョンでは、完全な機能は導入されません。

DeletableAccounts

Amendment ID ステータス
30CD365592B8EE40489BA01AE2F7555CAC9C983145871DC82A42A31CF5BAE7D9 有効

アカウントを削除できるようになります。

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

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

DepositAuth

Amendment ID ステータス
F64E1EABBE79D55B3BB82020516CEC2C582A98A6BFE20FBE9BB6A0D233418064 有効

新しいアカウントフラグDepositAuthを追加します。これにより、他のアカウントから送信されたトランザクションに係る入金が厳密に拒否されます。企業はこのフラグを使用することで、あらゆる送金人からの送金を受け入れる前に規則に準拠して適切に対処することができます。

支払先のアカウントのこのフラグが有効になっている場合、支払いがXRPでなされるか、発行済み通貨でなされるかにかかわらず、Paymentトランザクションは失敗となります。アカウントが支払先である場合、支払先アカウント自体から上記のトランザクションが送信されなければ、EscrowFinishトランザクションとPaymentChannelClaimトランザクションは失敗します。Checks amendmentが有効である場合、CheckCashトランザクションを送信することによってXRPまたは発行済み通貨をアカウントで受け取ることができます。

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

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

DepositPreauth

Amendment ID ステータス
3CBC5C4E630A1B82380295CDA84B32B49DD066602E74E39B85EF64137FA65194 有効

Deposit Authorizationのユーザーに特定の送信者を事前承認する手段を提供して、承認された送信者が支払いを直接送信できるようにします。

事前承認の追加または削除のために新しいトランザクションタイプDepositPreauthを、あるアカウントから別のアカウントへの事前承認の追跡のためにDepositPreauthレジャーオブジェクトタイプを追加します。JSON-RPCコマンドdeposit_authorizedを追加します。これは、アカウントが別のアカウントへ支払いを直接送金することが承認されているかどうかを問い合わせるためのものです。

また、アカウントにDeposit Authorizationが必要な場合、アカウントから自身への異なる通貨間での支払いの動作も変更します。この修正を行わない場合、これらの支払いはコードtecNO_PERMISSIONにて常に失敗します。この修正を行う場合、これらの支払いはDeposit Authorization無効時と同様に成功します。

EnforceInvariants

Amendment ID ステータス
DC9CA96AEA1DCF83E527D1AFC916EFAF5D27388ECA4060A88817C1238CAEE0BF 有効

トランザクション処理にサニティーチェックを追加して、所定の条件が常に満たされるようにします。これにより、トランザクション処理時のバグを防ぐ独立した追加のレイヤーができます。このレイヤーがなければXRP Ledgerが脆弱なものとなり悪用される可能性が生じます。Rippleは、Amendmentを追加せずに、将来バージョンのrippledに不変性チェックをさらに追加する予定です。

2つの新しいトランザクションエラーコード、tecINVARIANT_FAILEDとtefINVARIANT_FAILEDを導入します。新しいチェックを追加するためにトランザクション処理を変更します。

不変性チェックの例:

Escrow

Amendment ID ステータス
07D43DCE529B15A10827E5E04943B496762F9A88E3268269D69C44BE49E21104 有効

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

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

FeeEscalation

Amendment ID ステータス
42426C4D4F1009EE67080A9B7965B44656D7714D104A72F9B4369F97ABF044EE 有効

提案されたトランザクションにトランザクションコストを適用する方法を変更します。トランザクションコストの高いトランザクションの優先順位が高くなるよう、コンセンサスプロセスを変更します。

この修正により、前のコンセンサスラウンドに含められなかったトランザクションに固定サイズのトランザクションキューが導入されます。コンセンサスネットワーク内のrippledサーバーに重い負荷が課されている場合、トランザクションコストの低いトランザクションは後のレジャーのキューに入れられます。各コンセンサスラウンドでは、トランザクションコスト（Fee値）が高いキューのトランザクションが優先され、コンセンサスネットワークで処理できる限りのトランザクションが含められます。トランザクションキューが一杯になると、トランザクションコストが最も低いトランザクションから順にキューから完全に除外されます。

コンセンサスネットワークに重い負荷がかかる一方で、正規のユーザーは高めのトランザクションコストを支払い、トランザクションを確実に処理することができます。この状況は、未処理の低コストのトランザクションが完全に処理または除外されるまで続きます。

1つのトランザクションは、以下のいずれかが発生するまでキュー内に残ります。

  • 検証済みレジャーに適用される（成功か失敗かには関係ありません）
  • 無効になる（例えば、LastLedgerSequenceによって有効期限切れとなる）
  • キュー内にトランザクションコストの高いトランザクションがたくさんあるため除外される

fix1201

Amendment ID ステータス
B4D44CC3111ADD964E846FC57760C8B50FFCD5A82C86A72756F6B058DDDF96AD 有効

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

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

fix1368

Amendment ID ステータス
E2E6F2866106419B88C50045ACE96368558C345566AC8F2BDF5A5B5587F0E6FA 有効

有効であるべき一部の支払いが失敗となる、トランザクション処理の小さなバグを修正します。具体的には、支払い処理中に、特定金額の通貨を生成する支払いステップの一部で、浮動小数点の表示に関する精度の不良により、わずかに異なる金額が生成されてしまうことがあります。この状況が発生すると、正確な金額を送金できないため支払いが失敗します。fix1368 Amendmentにより、トランザクション処理が修正されれば、このような支払いの失敗はなくなります。

fix1373

Amendment ID ステータス
42EEA5E28A97824821D4EF97081FE36A54E9593C6E4F20CBAE098C69D2E072DC 有効

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

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

fix1512

Amendment ID ステータス
6C92211186613F9647A89DFFBAB8F94C99D4C7E956D495270789128569177DA1 有効

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

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

fix1513

Amendment ID ステータス
67A34F2CF55BFC0F93AACD5B281413176FEE195269FA6D95219A2DF738671172 有効

FeeEscalation Amendmentが行われると、新しいSTAmountCalcSwitchoversコードが使用されないトランザクション処理のバグを修正します。

この修正により、新しいSTAmountCalcSwitchoversコードが適用されるため、計算の違いによってトランザクション処理に若干の変更を生じる場合があります。金額の四捨五入のやり方が異なり、その結果、オファーが異なる順序で実行される場合があります。

fix1515

Amendment ID ステータス
5D08145F0A4983F23AFFFF514E83FAD355C5ABFBB6CAB76FB5BC8519FF5F33BE 有効

Paymentトランザクションがオファーを処理していく方法を変更して、支払処理とオファー処理における流動性の消費の仕方のわずかな違いをなくします。（FlowCrossが有効の場合、オファーCreateトランザクションの処理方法にも影響します。）

この修正を行わない場合、トランザクションが同じ為替レートで2000を超えるオファーを消費すると、支払い処理は特定のオーダーブックを使用しなくなります。この場合、支払いはそれらのオファーの流動性を使用せず、支払いを完了するときにそのオーダーブックに残された流動性を考慮しません。

この修正により、同じ為替レートで1000を超えるオファーを処理するトランザクションはすべて、そのトランザクションの最初の1000のオファーの流動性を消費し、支払いを完了時にはそのオーダーブックに残された流動性は考慮されません。

どちらの場合でも、トランザクション処理は他のパスまたは為替レートからの流動性を使用して完了できます。

fix1523

Amendment ID ステータス
B9E739B8296B4A1BB29BE990B17D66E21B62A300A909F25AC55C22D6C72E1F9D 有効

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

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

fix1528

Amendment ID ステータス
1D3463A5891F9E589C5AE839FFAC4A917CE96197098A1EF22304E1BC5B98A454 有効

バリデータがさまざまなタイムスタンプでコンセンサスレジャーを構築できることが原因で、検証済みレジャーの宣言プロセスに遅れをもたらす可能性があるバグを修正します。このような状況の発生は正確なタイミングを要するため、管理テスト環境の外部にいるバリデータがこのバグに遭遇することはあまりありません。

この修正は、バリデータがコンセンサスレジャーの終了時刻の交渉方法を変更して、レジャー内容について合意を得ることはできないが、異なるタイムスタンプでレジャーバージョンを構築できるようにします。

fix1543

Amendment ID ステータス
CA7C02118BA27599528543DFE77BA6838D1B0F43B447D4D7F53523CE6A0E9AC2 有効

予約済のフラグ範囲を、まだ正しく適用されていないトランザクションタイプに適用します。未定義または未知のフラグ、または予約された範囲のフラグが有効になっている場合、影響を受けるトランザクションタイプのトランザクションは無効と見なされるようになります。（この変更による影響を受けないトランザクションには、すでに同じルールが正しく適用されています。）

この修正を行わない場合、特定のタイプのトランザクションで未定義または予約されたフラグが有効になっていても、そのトランザクションタイプは有効と見なされます。

影響を受けるトランザクションタイプは以下のとおりです。

fix1571

Amendment ID ステータス
7117E2EC2DBF119CA55181D69819F1999ECEE1A0225A7FD2B9ED47940968479C 有効

以下のようにEscrowの問題を修正します。

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

fix1578

Amendment ID ステータス
FBD513F1B893AC765B78F250E6FFA6A11B573209D1842ADC787C850696741288 有効

以下の2つのトランザクションタイプから返される結果コードを変更します。

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

fix1623

Amendment ID ステータス
58BE9B5968C4DA7C59BA900961828B113E5490699B21877DEF9A31E9D0FE5D5F 有効

変動金額で換金されたCheckCashトランザクションのメタデータに送金額を追加します。（Checks Amendmentが有効でないかぎり効果がありません。）

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

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

注意: rippled1.0.0では、fix1623 Amendmentの前にChecks Amendmentを有効にした場合、fix1623 Amendmentが行われる前の変動金額のCheckCashトランザクションについては、トランザクションがゼロ以外の金額であっても、delivered_amountに「0」と表示される場合があります。Rippleでは、fix1623をChecks Amendmentと同時に本番ネットワーク環境で有効にするよう計画していますが、この状況は並列ネットワーク上で発生する可能性があります。

fix1781

Amendment ID ステータス
25BA44241B3BD880770BFA4DA21C7180576831855368CBEC6A3154FDE4A7676E 予定

Fixes a bug where certain XRP endpoints were not checked when detecting circular paths.

Without this amendment, it is possible to have a payment path where the input to the path is XRP, and an intermediate path step also outputs XRP. This is a "loop" payment, and the payment engine disallows such paths because they can have different results when executed forward compared to backwards.

With this amendment, those payments fail with the temBAD_PATH_LOOP result code instead.

fixAmendmentMajorityCalc

Amendment ID ステータス
4F46DF03559967AC60F2EB272FEFE3928A7594A45FF774B87A7E540DB0F8F068 予定

Fixes a bug that could cause an amendment to achieve a majority and later activate with support of slightly less than 80% of trusted validators due to rounding semantics.

Without this amendment, the minimum threshold for amendment activation is any value that rounds to 204/256 of trusted validators, which depends on the number of trusted validators at the time. For example, an amendment could activate with exactly 28 out of 36 validators (approximately 77.8%). With this amendment, the actual minimum number of validators needed is never less than 80% of trusted validators.

fixCheckThreading

Amendment ID ステータス
8F81B066ED20DAECA20DF57187767685EEF3980B228E0667A650BAF24426D3B4 有効

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

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

fixMasterKeyAsRegularKey

Amendment ID ステータス
C4483A1896170C66C098DEA5B0E024309C60DC960DE5F01CD7AF986AA3D9AD37 有効

アカウントのレギュラーキーペアがマスターキーペアと一致するように設定できるものの、マスターキーが無効になった場合に、そのキーによって署名されたトランザクションを送信できなくなるバグを修正します。

この修正を適用しない場合、ユーザーは、レギュラーキーがマスターキーと一致するように設定し、その後マスターキーを無効にすることで、意図せずアカウントを「ブラックホール」にしてしまうおそれがあります。ネットワークは、マスターキーペアとレギュラーキーペアの両方で署名されたトランザクションを拒否します。コードは、トランザクションが現在有効なレギュラーキーで署名されていると認識する前に、無効なマスターキーで署名されていると解釈するためです。

この修正を有効にした場合、SetRegularKeyトランザクションはレギュラーキーがマスターキーに一致するよう設定できないため、そのようなトランザクションでは、トランザクションコードがtemBAD_REGKEYになります。また、この修正により、署名検証コードが変更されるため、レギュラーキーがマスターキーに一致するよう_すでに_設定しているアカウントは、そのキーペアを使用して正常にトランザクションを送信できます。

fixPayChanRecipientOwnerDir

Amendment ID ステータス
621A0B264970359869E3C0363A899909AAB7A887C8B73519E4ECF952D33258A8 有効

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

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

fixSTAmountCanonicalize

Amendment ID ステータス
452F5906C46D46F407883344BFDD90E672B672C5E9943DB4891E3A34FEEEB9DB 投票中

Fixes an edge case in deserializing Amount-type fields. Without this amendment, in some rare cases the operation could result in otherwise valid serialized amounts overflowing during deserialization. With this amendment, the XRP Ledger detects error conditions more quickly and eliminates the problematic corner cases.

fixTakerDryOfferRemoval

Amendment ID ステータス
2CD5286D8D687E98B41102BDD797198E81EA41DF7BD104E6561FEB104EFF2561 有効

XRP Ledger内にドライオファーを残す可能性があるオートブリッジのバグを修正します。ドライオファーとは、オファーを掛け合わせても資金を調達できないオファーのことです。

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

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

fixQualityUpperBound

Amendment ID ステータス
89308AF3B8B10B7192C4E613E1D2E4D9BA64B2EE2D5232402AE82A6A7220D953 有効

Fixes a bug in unused code for estimating the ratio of input to output of individual steps in cross-currency payments.

This amendment has no known impact on transaction processing.

Flow

Amendment ID ステータス
740352F2412A9909880C23A559FCECEDA3BE2126FED62FC7660D628A06927F11 有効

支払い処理エンジンを、より堅固で効率的に作られたFlowエンジンに置き換えます。この新バージョンの支払い処理エンジンは、旧バージョンと同じルールを踏襲しますが、浮動小数点の丸め処理により異なる結果をもたらすことがあります。この修正はFlowV2 Amendmentに代わるものです。

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

FlowCross

Amendment ID ステータス
3012E8230864E95A58C60FD61430D7E1B4D3353195F2981DC12B0C7C0950FFAC 有効

XRP Ledgerの分散型取引所において、オファーの掛け合わせのロジックを合理化します。Flow Amendmentから更新されたコードを使用してオファーの掛け合わせを行うため、OfferCreateトランザクションとPaymentトランザクションは多くのコードを共有します。オファーの処理方法には微妙な違いがあります。

  • 丸め方が一部のケースで少し異なります。
  • 丸め方の違いが原因で、一部のオファーの組み合わせのランク付けが以前のロジックより上下したり、優先されたりします。
  • 新しいロジックによって、以前のロジックより多めまたは少なめにオファーが削除される場合があります。（これには、丸め方の違いによるケースや、以前のロジックによって資金供給なしとして不正に削除されたオファーが含まれます。）

FlowSortStrands

Amendment ID ステータス
AF8DF7465C338AE64B1E937D6C8DA138C0D63AD5134A68792BBBE1F63356C422 投票中

Improves the payment engine's calculations for finding the most cost-efficient way to execute a cross-currency transaction.

Without this change, the engine simulates a payment through each possible path to calculate the quality (ratio of input to output) of each path. With this change, the engine calculates the theoretical quality of each path without simulating a full payment. With this amendment, the payment engine executes some cross-currency payments much faster, is able to find the most cost-efficient path in more cases, and can enable some payments to succeed in certain conditions where the old payment engine would fail to find enough liquidity.

FlowV2

Amendment ID ステータス
5CC22CFF2864B020BD79E0E1F048F63EF3594F95E650E43B3F837EF1DF5F4B26 禁止

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

HardenedValidations

Amendment ID ステータス
1F4AFA8FA1BC8827AD4C0F682C03A8B671DCDF6B5C4DE36D44243A684103EF88 予定

Allows validators to include a new optional field in their validations to attest to the hash of the latest ledger that the validator considers to be fully validated. The consensus process can use this information to increase the robustness of consensus.

MultiSign

Amendment ID ステータス
4C97EBA926031A7CF7D7B36FDE3ED66DDA5421192D63DE53FFB46E43B9DC8373 有効

トランザクションの承認方法としてマルチ署名を導入します。SignerListレジャーオブジェクトタイプとSignerListSetトランザクションタイプを作成します。省略可能なSignersフィールドをすべてのトランザクションタイプに追加します。一部のトランザクション結果コードを変更します。

この修正により、マルチ署名のアドレスからトランザクションを承認できる署名者のリストをそのアドレスに保持できるようになります。このリストには定数があり、1から8で重み付けされた署名者が記載されています。これにより、「5人のうち任意の3人」や「Aの署名とその他任意の2人の署名」などの多様な設定が可能になります。

署名者は資金供給のあるアドレスでも資金供給のないアドレスでも可能です。署名者リストのうち資金供給のあるアドレスは、レギュラーキー（定義済みの場合）またはマスターキー（無効でない場合）を使用して署名できます。資金供給のないアドレスは、マスターキーを使用して署名できます。マルチ署名済みトランザクションは、レギュラーキーで署名されたトランザクションと同じ権限を持ちます。

SignerListを持つアドレスは、レギュラーキーが定義されていなくてもマスターキーを無効にすることができます。また、SignerListを持つアドレスは、マスターキーが無効な場合でもレギュラーキーを削除することができます。tecMASTER_DISABLEDトランザクション結果コードはtecNO_ALTERNATIVE_KEYに名前が変更されます。tecNO_REGULAR_KEYトランザクション結果コードは廃止となり、tecNO_ALTERNATIVE_KEYに代わります。さらに、この修正は以下の新しいトランザクション結果コードを追加します。

  • temBAD_SIGNER
  • temBAD_QUORUM
  • temBAD_WEIGHT
  • tefBAD_SIGNATURE
  • tefBAD_QUORUM
  • tefNOT_MULTI_SIGNING
  • tefBAD_AUTH_MASTER

MultiSignReserve

Amendment ID ステータス
586480873651E106F1D6339B0C4A8945BA705A777F3F4524626FF1FC07EFE41D 有効

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

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

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

NegativeUNL

Amendment ID ステータス
B4E4F5D2D6FB84DF7399960A732309C9FD530EAE5941838160042833625A6076 開発中

Implements a "Negative UNL" system, where the network can track which validators are temporarily offline and disregard those validators for quorum calculations. This can improve the liveness of the network during periods of network instability.

OwnerPaysFee

Amendment ID ステータス
9178256A980A86CF3D70D0260A7DA6402AAFE43632FDBCB88037978404188871 開発中

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

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

注記: この修正の未完成のバージョンがv0.33.0で導入されましたが、v0.80.0で削除されました。（適用されませんでした。）Rippleは、コードが十分に安定してからAmendmentを再度追加する予定です。

PayChan

Amendment ID ステータス
08DE7D96082187F6E6578530258C77FAABABE4C20474BDB82F04B021F1A68647 有効

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

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

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

RequireFullyCanonicalSig

Amendment ID ステータス
00C1FC4A53E60AB02C864641002B3172F38677E29C26C5406685179B37E1EDAC 有効

Changes the signature requirements for the XRP Ledger protocol so that non-fully-canonical signatures are no longer valid in any case. This protects against transaction malleability on all transactions, instead of just transactions with the tfFullyCanonicalSig flag enabled.

Without this amendment, a transaction is malleable if it uses a secp256k1 signature and does not have tfFullyCanonicalSig enabled. Most signing utilities enable tfFullyCanonicalSig by default, but there are exceptions.

With this amendment, no single-signed transactions are malleable. (Multi-signed transactions may still be malleable if signers provide more signatures than are necessary.) All transactions must use the fully canonical form of the signature, regardless of the tfFullyCanonicalSig flag. Signing utilities that do not create fully canonical signatures are not supported. All of Ripple's signing utilities have been providing fully-canonical signatures exclusively since at least 2014.

For more information, see rippled issue #3042 .

SHAMapV2

Amendment ID ステータス
C6970A8B603D8778783B61C0D445C23D1633CCFAEF0D43E7DBCD1521D34BD7C3 禁止

rippledがレジャーを表示する際に使用するハッシュツリー構造を変更します。新しい構造は以前のバージョンよりもコンパクトで効率的です。この修正はレジャーハッシュの計算方法が変わりますが、その他にユーザーに与える影響はありません。

この修正が適用されると、ネットワークでハッシュツリー構造への変更を計算している間、XRP Ledgerはしばらく使用できなくなります。

SortedDirectories

Amendment ID ステータス
CC5ABAE4F3EC92E94A59B1908C2BE82D2228B6485C00AFF8F22DF930D89C194E 有効

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

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

SusPay

Amendment ID ステータス
DA1BD556B42D85EA9C84066D028D355B52416734D3283F85E216EA5DA6DB7E13 禁止

この修正は、Escrow Amendmentに置き換えられました。

TicketBatch

Amendment ID ステータス
955DF3FA5891195A9DAEFA1DDC6BB244B545DDE1BAA84CBB25D5F12A8DA68A0C 投票中

This amendment adds Tickets as a way of sending transactions out of the typical sequence number order.

Standards Draft: XLS-13d .

Tickets

Amendment ID ステータス
C1B8D934087225F509BEB5A8EC24447854713EE447D277F69545ABFA0E0FD490 禁止

この修正は、TicketBatch Amendmentに置き換えられました。

TickSize

Amendment ID ステータス
532651B4FD58DF8922A49BA101AB3E996E5BFBF95A913B3E392504863E63B164 有効

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

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

TrustSetAuth

Amendment ID ステータス
6781F8368C4771B83E8B821D88F580202BCB4228075297B19E4FDC5233F1EFDC 有効

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

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