diff --git a/content/concepts/consensus-network/amendments/known-amendments.ja.md b/content/concepts/consensus-network/amendments/known-amendments.ja.md index d4d67952d9..120dfaeec9 100644 --- a/content/concepts/consensus-network/amendments/known-amendments.ja.md +++ b/content/concepts/consensus-network/amendments/known-amendments.ja.md @@ -6,7 +6,7 @@ labels: - ブロックチェーン --- # 既知のAmendment -[[ソース]](https://github.com/ripple/rippled/blob/master/src/ripple/protocol/impl/Feature.cpp "Source") +[[ソース]](https://github.com/xrplf/rippled/blob/master/src/ripple/protocol/impl/Feature.cpp "Source") 以下に示すのは、本番環境のXRP Ledgerに関する既知のAmendmentのすべてとそのステータスをまとめた総合リストです。 @@ -140,6 +140,7 @@ labels: しかし、この修正は実装が完了する前に`rippled` v0.60.0に追加されました。その結果、このAmendment IDは、ほとんど何もしない不完全なコードを参照することになりました。他のcrypto-conditionsのサポートを追加するために既存のAmendmentを変更すると、すでにリリースされたソフトウェアにある古いバージョンの修正案との衝突が発生します。将来のリリースで追加の暗号条件のサポートが追加される場合、新しい別のAmendment IDを使用する必要があります。 + ## DeletableAccounts [DeletableAccounts]: #deletableaccounts @@ -156,6 +157,7 @@ labels: この修正を適用した場合、新しいアカウントは、そのアカウントが作成された[レジャーのインデックス][レジャーインデックス]に一致する`Sequence`番号に等しい`Sequence`番号で始まります。この変更により、一度削除され、その後再作成されたアカウントが、古いトランザクションを再度実行しないように保護することができます。新しい`AccountDelete`トランザクションタイプを追加すると、アカウントと、そのアカウントがレジャーに所有する特定のオブジェクトが削除されます。ただし、特定の種類のオブジェクトはこの方法で削除できないため、そのようなオブジェクトに関連付けられているアカウントは削除できません。また、現行のレジャーインデックスから256を引いた値がアカウントの現行`Sequence`番号より低い場合も、アカウントは削除できません。この修正に関する詳しい解説については、[XRP Community Standards Draft 7](https://github.com/XRPLF/XRPL-Standards/issues/8)を参照してください。 + ## DepositAuth [DepositAuth]: #depositauth @@ -174,6 +176,7 @@ labels: また、EscrowCreateトランザクションとPaymentChannelCreateトランザクションで誤ってDisallowXRPフラグを適用してしまうバグも修正します。これは強制力のない勧告フラグとするものです。（レジャー自体にDisallowXRPフラグを適用しないことで、[アカウント準備金](reserves.html)を満たし[トランザクションコスト](transaction-cost.html)を支払うのに必要なXRPを、アカウントが引き続き受け取ることができます。） + ## DepositPreauth [DepositPreauth]: #depositpreauth @@ -188,6 +191,8 @@ labels: 事前承認の追加または削除のために新しいトランザクションタイプDepositPreauthを、あるアカウントから別のアカウントへの事前承認の追跡のためにDepositPreauthレジャーオブジェクトタイプを追加します。JSON-RPCコマンド`deposit_authorized`を追加します。これは、アカウントが別のアカウントへ支払いを直接送金することが承認されているかどうかを問い合わせるためのものです。 +あるアカウントからそれ自身へのクロスカレンシー決済において、そのアカウントがDeposit Authorizationを必要とする場合の動作を変更しました。このamendmentなしでは、これらの支払いは常に`tecNO_PERMISSION`というコードで失敗します。この修正により、Deposit Authorizationが無効な場合と同様に、これらの支払いは成功します。 + また、アカウントにDeposit Authorizationが必要な場合、アカウントから自身への異なる通貨間での支払いの動作も変更します。この修正を行わない場合、これらの支払いはコードtecNO_PERMISSIONにて常に失敗します。この修正を行う場合、これらの支払いはDeposit Authorization無効時と同様に成功します。 @@ -237,6 +242,7 @@ Checks、Payment Channels、NFTokenOffer、およびトラストラインを自 - [レジャー内のオブジェクト](ledger-object-types.html)のタイプは変更できません。（`LedgerEntryType`フィールドは変更できません。） - XRPにトラストラインはありません。 + ## Escrow [Escrow]: #escrow @@ -268,6 +274,7 @@ XRP Ledger内のEscrowにXRPの「仮払い」機能を提供します。これ この修正により、[SignerListオブジェクト][]の最大サイズは32エントリになります。さらに、各`SignerEntry`オブジェクトは、任意のデータを含む256ビットの`WalletLocator`フィールドを含むことができます。この修正により、[SignerListSetトランザクション][]もそれに応じて変更されます。 + ## FeeEscalation [FeeEscalation]: #feeescalation @@ -290,6 +297,7 @@ XRP Ledger内のEscrowにXRPの「仮払い」機能を提供します。これ * 無効になる（例えば、[`LastLedgerSequence`](transaction-common-fields.html)によって有効期限切れとなる） * キュー内にトランザクションコストの高いトランザクションがたくさんあるため除外される + ## fix1201 [fix1201]: #fix1201 @@ -304,6 +312,7 @@ XRP Ledger内のEscrowにXRPの「仮払い」機能を提供します。これ この修正を行う場合、[AccountSet][]トランザクションの`TransferRate`を`2000000000`より高く設定すると、トランザクションは結果コード`temBAD_TRANSFER_RATE`にて失敗します。以前のルールに従って高い値が設定されている既存のすべての`TransferRate`には、そのまま高い率が適用されます。 + ## fix1368 [fix1368]: #fix1368 @@ -316,6 +325,7 @@ XRP Ledger内のEscrowにXRPの「仮払い」機能を提供します。これ 有効であるべき一部の支払いが失敗となる、トランザクション処理の小さなバグを修正します。具体的には、支払い処理中に、特定金額の通貨を生成する支払いステップの一部で、浮動小数点の表示に関する精度の不良により、わずかに異なる金額が生成されてしまうことがあります。この状況が発生すると、正確な金額を送金できないため支払いが失敗します。fix1368 Amendmentにより、トランザクション処理が修正されれば、このような支払いの失敗はなくなります。 + ## fix1373 [fix1373]: #fix1373 @@ -330,6 +340,7 @@ XRP Ledger内のEscrowにXRPの「仮払い」機能を提供します。これ fix1373 Amendmenによりこの問題は修正されるため、正しく作成されたパスを使用して支払いを行えます。また、現在は許可されているものの適切ではない一部のパスが無効になります。これには、同じオブジェクトを2回以上ループしてコンフリクトを起こすフィールドやパスを含む[ステップ](paths.html#パスの仕様)を持つパスが含まれます。 + ## fix1512 [fix1512]: #fix1512 @@ -344,6 +355,7 @@ fix1373 Amendmenによりこの問題は修正されるため、正しく作成 この修正により、トランザクションは適切な結果コード`temBAD_AMOUNT`にて失敗します。 + ## fix1513 [fix1513]: #fix1513 @@ -358,6 +370,7 @@ fix1373 Amendmenによりこの問題は修正されるため、正しく作成 この修正により、新しい`STAmountCalcSwitchovers`コードが適用されるため、計算の違いによってトランザクション処理に若干の変更を生じる場合があります。金額の四捨五入のやり方が異なり、その結果、オファーが異なる順序で実行される場合があります。 + ## fix1515 [fix1515]: #fix1515 @@ -376,6 +389,7 @@ Paymentトランザクションがオファーを処理していく方法を変 どちらの場合でも、トランザクション処理は他のパスまたは為替レートからの流動性を使用して完了できます。 + ## fix1523 [fix1523]: #fix1523 @@ -390,6 +404,7 @@ Paymentトランザクションがオファーを処理していく方法を変 この修正により、新しいEscrowが送信者と受信者両方の[所有者ディレクトリー](directorynode.html)に追加されます。また、[Escrowレジャーオブジェクト](escrow-object.html)に新しい`DestinationNode`フィールドも追加され、支払先の所有者ディレクトリのどのページにEscrowがあるかを表示します。 + ## fix1528 [fix1528]: #fix1528 @@ -404,6 +419,7 @@ Paymentトランザクションがオファーを処理していく方法を変 この修正は、バリデータがコンセンサスレジャーの終了時刻の交渉方法を変更して、レジャー内容について合意を得ることはできないが、異なるタイムスタンプでレジャーバージョンを構築できるようにします。 + ## fix1543 [fix1543]: #fix1543 @@ -423,6 +439,7 @@ Paymentトランザクションがオファーを処理していく方法を変 - Escrowトランザクション: [EscrowCancel][]、[EscrowCreate][]、[EscrowFinish][] - Payment Channelトランザクション: [PaymentChannelClaim][]、[PaymentChannelCreate][]、[PaymentChannelFund][] + ## fix1571 [fix1571]: #fix1571 @@ -438,6 +455,7 @@ Paymentトランザクションがオファーを処理していく方法を変 - [EscrowCreateトランザクション][]に`Condition`フィールドまたは`FinishAfter`フィールド（またはその両方）が必要となるように変更します。この修正以前に作成された、`Condition`や`FinishAfter`のいずれも持たないEscrowは、`CancelAfter`時間より前ならいつでも誰でも終了できます。 - 時間ベースのEscrowが特定の状況下で終了されるのを誤って妨げる欠陥を修正します。 + ## fix1578 [fix1578]: #fix1578 @@ -453,6 +471,7 @@ Paymentトランザクションがオファーを処理していく方法を変 - [OfferCreateトランザクション][]を変更して、オファーが`tfFillOrKill`フラグを使用していて中止された場合に、新しい結果コード`tecKILLED`が返されるようにします。この修正を行わない場合、オファーは中止されますが、トランザクション結果は`tesSUCCESS`になります。 - [TrustSetトランザクション][]を変更して、トラストラインがマイナス残高であるため、[NoRippleフラグ](rippling.html#norippleフラグ)を有効にしようとしてもできない場合に、`tecNO_PERMISSION`で失敗するようにします。この修正を行わない場合、トランザクションでNoRippleフラグを有効にできなくても、トランザクション結果は`tesSUCCESS`になります。 + ## fix1623 [fix1623]: #fix1623 @@ -516,6 +535,7 @@ Checksトランザクションがアカウントのメタデータに影響を この修正を適用しない場合、Checksトランザクション（[CheckCreate][]、[CheckCash][]、および[CheckCancel][]）は送信者のアカウント履歴のみを更新します。この修正を適用した場合、これらのトランザクションは、送信アカウントにも受信アカウントにも影響します。この修正は、[Checks Amendment](#checks)も有効でないかぎり効果がありません。 + ## fixMasterKeyAsRegularKey [fixMasterKeyAsRegularKey]: #fixmasterkeyasregularkey @@ -669,9 +689,7 @@ NFTオファーに宛先を設定した場合、その宛先のみが仲介で この修正は、すでにミントされた`NFToken`オブジェクトのコードを変更するものではありません。NonFungibleTokensV1_1がすでに有効になっているテストネットワークでは、`tfTrustLine`フラグが有効なNFTokenをすでにミントしている発行者は、fixRemoveNFTokenAutoTrustLine Amendmentの有効後も脆弱性があることを意味しています。 -この修正は、[NonFungibleTokensV1][]または [NonFungibleTokensV1_1][]が有効になっていない限り、影響を及ぼしません。 - -発行者を保護するため、このamendmentは[NonFungibleTokensV1][]または[NonFungibleTokensV1_1][]の前に有効にする必要があります。 +この修正は、[NonFungibleTokensV1][]または [NonFungibleTokensV1_1][]が有効になっていない限り、影響を及ぼしません。発行者を保護するため、このamendmentは[NonFungibleTokensV1][]または[NonFungibleTokensV1_1][]の前に有効にする必要があります。 ## fixRmSmallIncreasedQOffers @@ -765,6 +783,7 @@ XRP Ledger内にドライオファーを残す可能性がある[オートブリ また、Flowエンジンは、さらなるAmendmentを通じて、支払いエンジンの改善や拡張を容易にします。 + ## FlowCross [FlowCross]: #flowcross @@ -808,6 +827,7 @@ XRP Ledgerの分散型取引所において、オファーの掛け合わせの これは[Flow](#flow) Amendmentの旧バージョンです。[バグが原因で不採用となり](https://xrpl.org/blog/2016/flowv2-vetoed.html)、バージョン0.33.0で除外されました。 + ## HardenedValidations [HardenedValidations]: #hardenedvalidations @@ -964,6 +984,7 @@ XRP Ledgerアカウントが[マルチシグ](multi-signing.html) SignerListを **注記:** 不完全なバージョンのこのAmendmentについては、v0.33.0で導入され、v0.80.0で削除されました（有効となったことはありません）。 + ## PayChan [PayChan]: #paychan @@ -980,6 +1001,7 @@ XRPの「Payment Channel」を作成します。Payment Channelは、2名の当 詳細は、[Payment Channelsのチュートリアル](use-payment-channels.html)を参照してください。 + ## RequireFullyCanonicalSig [RequireFullyCanonicalSig]: #requirefullycanonicalsig @@ -1012,6 +1034,7 @@ XRP Ledgerプロトコルの署名要件を変更し、いかなる場合にも この修正が適用されると、ネットワークでハッシュツリー構造への変更を計算している間、XRP Ledgerはしばらく使用できなくなります。 + ## SortedDirectories [SortedDirectories]: #sorteddirectories @@ -1026,6 +1049,7 @@ XRP Ledgerプロトコルの署名要件を変更し、いかなる場合にも **警告:** このが適用されていない旧バージョンの`rippled`は、新しいルールでソートされたDirectoryNodeによって機能が停止するおそれがあります。この問題を回避するには、`rippled`バージョン0.80.0以降に[アップグレード](install-rippled.html)してください。 + ## SusPay [SusPay]: #suspay @@ -1064,6 +1088,7 @@ XRP Ledgerプロトコルの署名要件を変更し、いかなる場合にも この修正は、[TicketBatch][] Amendmentに置き換えられました。 + ## TickSize [TickSize]: #ticksize @@ -1078,6 +1103,7 @@ XRP Ledgerプロトコルの署名要件を変更し、いかなる場合にも アカウントに`TickSize`フィールドを追加します。このフィールドは[AccountSetトランザクションタイプ](accountset.html)を使用して設定できます。通貨発行者が`TickSize`フィールドを設定すれば、発行者の通貨を取引するオファーの為替レート（資金の入出金率）がXRP Ledgerによって丸められ、丸められた為替レートに合わせてオファーの金額が調整されます。トランザクションにて1つの通貨にのみ`TickSize`が設定されていれば、その有効桁数が適用されます。異なる`TickSize`値が設定された2つの通貨を取引する場合は、有効桁数が最も小さい`TickSize`が適用されます。XRPに`TickSize`は設定されません。 + ## TrustSetAuth [TrustSetAuth]: #trustsetauth @@ -1092,6 +1118,7 @@ XRP Ledgerプロトコルの署名要件を変更し、いかなる場合にも この修正が適用されれば、[`tfSetfAuth`を有効にした](trustset.html#trustsetのフラグ)`TrustSet`トランザクションにおいて、`RippleState`ノードの他のすべての値をデフォルト状態にしたままでも、新しい[`RippleState`レジャーオブジェクト](ripplestate.html)を作成できます。新しい`RippleState`ノードでは、トランザクションの送信者が低いノードと見なされるか高いノードと見なされるかに応じて、[`lsfLowAuth`フラグまたは`lsfHighAuth`フラグ](ripplestate.html#ripplestateのフラグ)が有効になります。トランザクションの送信者は、[asfRequireAuthフラグを有効](accountset.html#accountsetのフラグ)にして[AccountSetトランザクション](accountset.html)を送信することで、事前に[`lsfRequireAuth`](accountroot.html#accountrootのフラグ)を有効にしておく必要があります。 + ## XRPFees [XRPFees]: #xrpfees diff --git a/content/concepts/consensus-network/amendments/known-amendments.md b/content/concepts/consensus-network/amendments/known-amendments.md index 73e45d7e30..32b3538337 100644 --- a/content/concepts/consensus-network/amendments/known-amendments.md +++ b/content/concepts/consensus-network/amendments/known-amendments.md @@ -6,7 +6,7 @@ labels: - Blockchain --- # Known Amendments -[[Source]](https://github.com/ripple/rippled/blob/master/src/ripple/protocol/impl/Feature.cpp "Source") +[[Source]](https://github.com/xrplf/rippled/blob/master/src/ripple/protocol/impl/Feature.cpp "Source") The following is a comprehensive list of all known [amendments](amendments.html) and their status on the production XRP Ledger: