ARCHIVE/xrpl-dev-portal
1
0
Fork 0
mirror of https://github.com/XRPLF/xrpl-dev-portal.git synced 2025-11-20 11:45:50 +00:00
Code Issues Packages Projects Releases Wiki Activity

Merge branch 'rippled_170'

Browse Source
This commit is contained in:
mDuo13
2021-02-23 22:50:44 -08:00
parent 970ca50281 8852dfe1f4
commit 429d8e3386
87 changed files with 2460 additions and 467 deletions
Download Patch File Download Diff File Expand all files Collapse all files

4
content/concepts/consensus-network/amendments/amendments.md
View File

@@ -10,7 +10,7 @@ For a complete list of known amendments, their statuses, and IDs, see: [Known Am
## Background
Any changes to transaction processing could cause servers to build a different ledger with the same set of transactions. If some _validators_ (`rippled` servers [participating in consensus](rippled-server-modes.html#reasons-to-run-a-validator)) have upgraded to a new version of the software while other validators use the old version, this could cause anything from minor inconveniences to full outages. In the minor case, a minority of servers spend more time and bandwidth fetching the actual consensus ledger because they cannot build it using the transaction processing rules they already know. In the worst case, [the consensus process][] might be unable to validate new ledger versions because servers with different rules could not reach a consensus on the exact ledger to build.
Any changes to transaction processing could cause servers to build a different ledger with the same set of transactions. If some _validators_ (`rippled` servers [participating in consensus](rippled-server-modes.html#validators)) have upgraded to a new version of the software while other validators use the old version, this could cause anything from minor inconveniences to full outages. In the minor case, a minority of servers spend more time and bandwidth fetching the actual consensus ledger because they cannot build it using the transaction processing rules they already know. In the worst case, [the consensus process][] might be unable to validate new ledger versions because servers with different rules could not reach a consensus on the exact ledger to build.
Amendments solve this problem, so that new features can be enabled only when enough validators support those features.
@@ -223,7 +223,7 @@ To look up which `rippled` version supports these features, see [Known Amendment
If you want to see how `rippled` behaves with an amendment enabled, before that amendment gets enabled on the production network, you can run use `rippled`'s config file to forcibly enable a feature. This is intended for development purposes only.
Because other members of the consensus network probably do not have the feature enabled, you should not use this feature while connecting to the production network. While testing with features forcibly enabled, you should run `rippled` in [stand-alone mode](rippled-server-modes.html#reasons-to-run-a-rippled-server-in-stand-alone-mode).
Because other members of the consensus network probably do not have the feature enabled, you should not use this feature while connecting to the production network. While testing with features forcibly enabled, you should run `rippled` in [stand-alone mode][].
To forcibly enable a feature, add a `[features]` stanza to your `rippled.cfg` file. In this stanza, add the short names of the features to enable, one per line. For example:

136
content/concepts/consensus-network/amendments/known-amendments.ja.md
View File

@@ -7,47 +7,50 @@
| 名前 | 導入済み | ステータス |
|:--------------------------------|:-----------|:------------------------------------|
| [NegativeUNL][] | 未定 | [開発中: 未定]( "BADGE_LIGHTGREY") |
| [CryptoConditionsSuite][] | 未定 | [開発中: 未定]( "BADGE_LIGHTGREY") |
| [NegativeUNL][] | 未定 | [開発中: 未定]( "BADGE_LIGHTGREY") |
| [OwnerPaysFee][] | 未定 | [開発中: 未定]( "BADGE_LIGHTGREY") |
| [Tickets][] | 未定 | [開発中: 未定]( "BADGE_LIGHTGREY") |
| [fixAmendmentMajorityCalc][] | v1.6.0-b8 | [開発中: 未定]( "BADGE_LIGHTGREY") |
| [HardenedValidations][] | v1.6.0-b5 | [開発中: 未定]( "BADGE_LIGHTGREY") |
| [fix1781][] | v1.6.0-b1 | [開発中: 未定]( "BADGE_LIGHTGREY") |
| [FlowCross][] | v0.70.0 | [投票中: 未定](https://xrpl.org/blog/2017/rippled-0.70.0.html "BADGE_80d0e0") |
| [fixQualityUpperBound][] | v1.5.0 | [有効: 2020/07/09](https://xrpcharts.ripple.com/#/transactions/5F8E9E9B175BB7B95F529BEFE3C84253E78DAF6076078EC450A480C861F6889E "BADGE_GREEN") |
| [RequireFullyCanonicalSig][] | v1.5.0 | [有効: 2020/07/03](https://xrpcharts.ripple.com/#/transactions/94D8B158E948148B949CC3C35DD5DC4791D799E1FD5D3CE0E570160EDEF947D3 "BADGE_GREEN") |
| [Checks][] | v0.90.0 | [有効: 2020/06/18](https://xrpcharts.ripple.com/#/transactions/D88F2DCDFB10023F9F6CBA8DF34C18E321D655CAC8FDB962387A5DB1540242A6 "BADGE_GREEN") |
| [DeletableAccounts][] | v1.4.0 | [有効: 2020/05/08](https://xrpcharts.ripple.com/#/transactions/47B90519D31E0CB376B5FEE5D9359FA65EEEB2289F1952F2A3EB71D623B945DE "BADGE_GREEN") |
| [fixCheckThreading][] | v1.4.0 | [有効: 2020/05/01](https://xrpcharts.ripple.com/#/transactions/74AFEA8C17D25CA883D40F998757CA3B0DB1AC86794335BAA25FF20E00C2C30A "BADGE_GREEN") |
| [fixPayChanRecipientOwnerDir][] | v1.4.0 | [有効: 2020/05/01](https://xrpcharts.ripple.com/#/transactions/D2F8E457D08ACB185CDE3BB9BB1989A9052344678566785BACFB9DFDBDEDCF09 "BADGE_GREEN") |
| [fixMasterKeyAsRegularKey][] | v1.3.1 | [有効: 2019/10/02](https://xrpcharts.ripple.com/#/transactions/61096F8B5AFDD8F5BAF7FC7221BA4D1849C4E21B1BA79733E44B12FC8DA6EA20 "BADGE_GREEN") |
| [MultiSignReserve][] | v1.2.0 | [有効: 2019/04/17](https://xrpcharts.ripple.com/#/transactions/C421E1D08EFD78E6B8D06B085F52A34A681D0B51AE62A018527E1B8F54C108FB "BADGE_GREEN") |
| [fixTakerDryOfferRemoval][] | v1.2.0 | [有効: 2019/04/02](https://xrpcharts.ripple.com/#/transactions/C42335E95F1BD2009A2C090EA57BD7FB026AD285B4B85BE15F669BA4F70D11AF "BADGE_GREEN") |
| [fix1578][] | v1.2.0 | [有効: 2019/03/23](https://xrpcharts.ripple.com/#/transactions/7A80C87F59BCE6973CBDCA91E4DBDB0FC5461D3599A8BC8EAD02FA590A50005D "BADGE_GREEN") |
| [DepositPreauth][] | v1.1.0 | [有効: 2018/10/09](https://xrpcharts.ripple.com/#/transactions/AD27403CB840AE67CADDB084BC54249D7BD1B403885819B39CCF723DC671F927 "BADGE_GREEN") |
| [fix1515][] | v1.1.0 | [有効: 2018/10/09](https://xrpcharts.ripple.com/#/transactions/6DF60D9EC8AF3C39B173840F4D1C57F8A8AB51E7C6571483B4A5F1AA0A9AAEBF "BADGE_GREEN") |
| [fix1543][] | v1.0.0 | [有効: 2018/06/21](https://xrpcharts.ripple.com/#/transactions/EA6054C9D256657014052F1447216CEA75FFDB1C9342D45EB0F9E372C0F879E6 "BADGE_GREEN") |
| [fix1623][] | v1.0.0 | [有効: 2018/06/20](https://xrpcharts.ripple.com/#/transactions/4D218D86A2B33E29F17AA9C25D8DFFEE5D2559F75F7C0B1D016D3F2C2220D3EB "BADGE_GREEN") |
| [fix1571][] | v1.0.0 | [有効: 2018/06/19](https://xrpcharts.ripple.com/#/transactions/920AA493E57D991414B614FB3C1D1E2F863211B48129D09BC8CB74C9813C38FC "BADGE_GREEN") |
| [DepositAuth][] | v0.90.0 | [有効: 2018/04/06](https://xrpcharts.ripple.com/#/transactions/902C51270B918B40CD23A622E18D48B4ABB86F0FF4E84D72D9E1907BF3BD4B25 "BADGE_GREEN") |
| [fix1513][] | v0.90.0 | [有効: 2018/04/06](https://xrpcharts.ripple.com/#/transactions/57FE540B8B8E2F26CE8B53D1282FEC55E605257E29F5B9EB49E15EA3989FCF6B "BADGE_GREEN") |
| [fix1201][] | v0.80.0 | [有効: 2017/11/14](https://xrpcharts.ripple.com/#/transactions/B1157116DDDDA9D9B1C4A95C029AC335E05DB052CECCC5CA90118A4D46C77C5E "BADGE_GREEN") |
| [fix1512][] | v0.80.0 | [有効: 2017/11/14](https://xrpcharts.ripple.com/#/transactions/63F69F59BEFDC1D79DBF1E4060601E05960683AA784926FB74BC55074C4F6647 "BADGE_GREEN") |
| [fix1523][] | v0.80.0 | [有効: 2017/11/14](https://xrpcharts.ripple.com/#/transactions/97FD0E35654F4B6714010D3CBBAC4038F60D64AD0292693C28A1DF4B796D8469 "BADGE_GREEN") |
| [fix1528][] | v0.80.0 | [有効: 2017/11/14](https://xrpcharts.ripple.com/#/transactions/27AEE02DA4FE22B6BB479F850FBBC873FDC7A09A8594753A91B53098D726397E "BADGE_GREEN") |
| [SortedDirectories][] | v0.80.0 | [有効: 2017/11/14](https://xrpcharts.ripple.com/#/transactions/6E2309C156EBF94D03B83D282A3914671BF9168FB26463CFECD068C63FFFAB29 "BADGE_GREEN") |
| [EnforceInvariants][] | v0.70.0 | [有効: 2017/07/07](https://xrpcharts.ripple.com/#/transactions/17593B03F7D3283966F3C0ACAF4984F26E9D884C9A202097DAED0523908E76C6 "BADGE_GREEN") |
| [fix1373][] | v0.70.0 | [有効: 2017/07/07](https://xrpcharts.ripple.com/#/transactions/7EBA3852D111EA19D03469F6870FAAEBF84C64F1B9BAC13B041DDD26E28CA399 "BADGE_GREEN") |
| [Escrow][] | v0.60.0 | [有効: 2017/03/31](https://xrpcharts.ripple.com/#/transactions/C581E0A3F3832FFFEEB13C497658F475566BD7695B0BBA531A774E6739801515 "BADGE_GREEN") |
| [fix1368][] | v0.60.0 | [有効: 2017/03/31](https://xrpcharts.ripple.com/#/transactions/3D20DE5CD19D5966865A7D0405FAC7902A6F623659667D6CB872DF7A94B6EF3F "BADGE_GREEN") |
| [PayChan][] | v0.33.0 | [有効: 2017/03/31](https://xrpcharts.ripple.com/#/transactions/16135C0B4AB2419B89D4FB4569B8C37FF76B9EF9CE0DD99CCACB5734445AFD7E "BADGE_GREEN") |
| [TickSize][] | v0.50.0 | [有効: 2017/02/21](https://xrpcharts.ripple.com/#/transactions/A12430E470BE5C846759EAE3C442FF03374D5D73ECE5815CF4906894B769565E "BADGE_GREEN") |
| [CryptoConditions][] | v0.50.0 | [有効: 2017/01/03](https://xrpcharts.ripple.com/#/transactions/8EB00131E1C3DB35EDFF45C155D941E18C3E86BC1934FF987D2DA204F4065F15 "BADGE_GREEN") |
| [Flow][] | v0.33.0 | [有効: 2016/10/21](https://xrpcharts.ripple.com/#/transactions/C06CE3CABA3907389E4DD296C5F31C73B1548CC20BD7B83416C78CD7D4CD38FC "BADGE_GREEN") |
| [TrustSetAuth][] | v0.30.0 | [有効: 2016/07/19](https://xrpcharts.ripple.com/#/transactions/0E589DE43C38AED63B64FF3DA87D349A038F1821212D370E403EB304C76D70DF "BADGE_GREEN") |
| [MultiSign][] | v0.31.0 | [有効: 2016/06/27](https://xrpcharts.ripple.com/#/transactions/168F8B15F643395E59B9977FC99D6310E8708111C85659A9BAF8B9222EEAC5A7 "BADGE_GREEN") |
| [FeeEscalation][] | v0.31.0 | [有効: 2016/05/19](https://xrpcharts.ripple.com/#/transactions/5B1F1E8E791A9C243DD728680F108FEF1F28F21BA3B202B8F66E7833CA71D3C3 "BADGE_GREEN") |
| [fixSTAmountCanonicalize][] | v1.7.0 | [投票中: 未定](https://xrpl.org/blog/2020/rippled-1.7.0.html "BADGE_80d0e0") |
| [FlowSortStrands][] | v1.7.0 | [投票中: 未定](https://xrpl.org/blog/2020/rippled-1.7.0.html "BADGE_80d0e0") |
| [TicketBatch][] | v1.7.0 | [投票中: 未定](https://xrpl.org/blog/2020/rippled-1.7.0.html "BADGE_80d0e0") |
| [fix1781][] | v1.6.0 | [投票中: 未定](https://xrpl.org/blog/2020/rippled-1.6.0.html "BADGE_80d0e0") |
| [fixAmendmentMajorityCalc][] | v1.6.0 | [投票中: 未定](https://xrpl.org/blog/2020/rippled-1.6.0.html "BADGE_80d0e0") |
| [HardenedValidations][] | v1.6.0 | [投票中: 未定](https://xrpl.org/blog/2020/rippled-1.6.0.html "BADGE_80d0e0") |
| [FlowCross][] | v0.70.0 | [有効: 2020/08/04](https://livenet.xrpl.org/transactions/44C4B040448D89B6C5A5DEC97C17FEDC2E590BA094BC7DB63B7FDC888B9ED78F "BADGE_GREEN") |
| [fixQualityUpperBound][] | v1.5.0 | [有効: 2020/07/09](https://livenet.xrpl.org/transactions/5F8E9E9B175BB7B95F529BEFE3C84253E78DAF6076078EC450A480C861F6889E "BADGE_GREEN") |
| [RequireFullyCanonicalSig][] | v1.5.0 | [有効: 2020/07/03](https://livenet.xrpl.org/transactions/94D8B158E948148B949CC3C35DD5DC4791D799E1FD5D3CE0E570160EDEF947D3 "BADGE_GREEN") |
| [Checks][] | v0.90.0 | [有効: 2020/06/18](https://livenet.xrpl.org/transactions/D88F2DCDFB10023F9F6CBA8DF34C18E321D655CAC8FDB962387A5DB1540242A6 "BADGE_GREEN") |
| [DeletableAccounts][] | v1.4.0 | [有効: 2020/05/08](https://livenet.xrpl.org/transactions/47B90519D31E0CB376B5FEE5D9359FA65EEEB2289F1952F2A3EB71D623B945DE "BADGE_GREEN") |
| [fixCheckThreading][] | v1.4.0 | [有効: 2020/05/01](https://livenet.xrpl.org/transactions/74AFEA8C17D25CA883D40F998757CA3B0DB1AC86794335BAA25FF20E00C2C30A "BADGE_GREEN") |
| [fixPayChanRecipientOwnerDir][] | v1.4.0 | [有効: 2020/05/01](https://livenet.xrpl.org/transactions/D2F8E457D08ACB185CDE3BB9BB1989A9052344678566785BACFB9DFDBDEDCF09 "BADGE_GREEN") |
| [fixMasterKeyAsRegularKey][] | v1.3.1 | [有効: 2019/10/02](https://livenet.xrpl.org/transactions/61096F8B5AFDD8F5BAF7FC7221BA4D1849C4E21B1BA79733E44B12FC8DA6EA20 "BADGE_GREEN") |
| [MultiSignReserve][] | v1.2.0 | [有効: 2019/04/17](https://livenet.xrpl.org/transactions/C421E1D08EFD78E6B8D06B085F52A34A681D0B51AE62A018527E1B8F54C108FB "BADGE_GREEN") |
| [fixTakerDryOfferRemoval][] | v1.2.0 | [有効: 2019/04/02](https://livenet.xrpl.org/transactions/C42335E95F1BD2009A2C090EA57BD7FB026AD285B4B85BE15F669BA4F70D11AF "BADGE_GREEN") |
| [fix1578][] | v1.2.0 | [有効: 2019/03/23](https://livenet.xrpl.org/transactions/7A80C87F59BCE6973CBDCA91E4DBDB0FC5461D3599A8BC8EAD02FA590A50005D "BADGE_GREEN") |
| [DepositPreauth][] | v1.1.0 | [有効: 2018/10/09](https://livenet.xrpl.org/transactions/AD27403CB840AE67CADDB084BC54249D7BD1B403885819B39CCF723DC671F927 "BADGE_GREEN") |
| [fix1515][] | v1.1.0 | [有効: 2018/10/09](https://livenet.xrpl.org/transactions/6DF60D9EC8AF3C39B173840F4D1C57F8A8AB51E7C6571483B4A5F1AA0A9AAEBF "BADGE_GREEN") |
| [fix1543][] | v1.0.0 | [有効: 2018/06/21](https://livenet.xrpl.org/transactions/EA6054C9D256657014052F1447216CEA75FFDB1C9342D45EB0F9E372C0F879E6 "BADGE_GREEN") |
| [fix1623][] | v1.0.0 | [有効: 2018/06/20](https://livenet.xrpl.org/transactions/4D218D86A2B33E29F17AA9C25D8DFFEE5D2559F75F7C0B1D016D3F2C2220D3EB "BADGE_GREEN") |
| [fix1571][] | v1.0.0 | [有効: 2018/06/19](https://livenet.xrpl.org/transactions/920AA493E57D991414B614FB3C1D1E2F863211B48129D09BC8CB74C9813C38FC "BADGE_GREEN") |
| [DepositAuth][] | v0.90.0 | [有効: 2018/04/06](https://livenet.xrpl.org/transactions/902C51270B918B40CD23A622E18D48B4ABB86F0FF4E84D72D9E1907BF3BD4B25 "BADGE_GREEN") |
| [fix1513][] | v0.90.0 | [有効: 2018/04/06](https://livenet.xrpl.org/transactions/57FE540B8B8E2F26CE8B53D1282FEC55E605257E29F5B9EB49E15EA3989FCF6B "BADGE_GREEN") |
| [fix1201][] | v0.80.0 | [有効: 2017/11/14](https://livenet.xrpl.org/transactions/B1157116DDDDA9D9B1C4A95C029AC335E05DB052CECCC5CA90118A4D46C77C5E "BADGE_GREEN") |
| [fix1512][] | v0.80.0 | [有効: 2017/11/14](https://livenet.xrpl.org/transactions/63F69F59BEFDC1D79DBF1E4060601E05960683AA784926FB74BC55074C4F6647 "BADGE_GREEN") |
| [fix1523][] | v0.80.0 | [有効: 2017/11/14](https://livenet.xrpl.org/transactions/97FD0E35654F4B6714010D3CBBAC4038F60D64AD0292693C28A1DF4B796D8469 "BADGE_GREEN") |
| [fix1528][] | v0.80.0 | [有効: 2017/11/14](https://livenet.xrpl.org/transactions/27AEE02DA4FE22B6BB479F850FBBC873FDC7A09A8594753A91B53098D726397E "BADGE_GREEN") |
| [SortedDirectories][] | v0.80.0 | [有効: 2017/11/14](https://livenet.xrpl.org/transactions/6E2309C156EBF94D03B83D282A3914671BF9168FB26463CFECD068C63FFFAB29 "BADGE_GREEN") |
| [EnforceInvariants][] | v0.70.0 | [有効: 2017/07/07](https://livenet.xrpl.org/transactions/17593B03F7D3283966F3C0ACAF4984F26E9D884C9A202097DAED0523908E76C6 "BADGE_GREEN") |
| [fix1373][] | v0.70.0 | [有効: 2017/07/07](https://livenet.xrpl.org/transactions/7EBA3852D111EA19D03469F6870FAAEBF84C64F1B9BAC13B041DDD26E28CA399 "BADGE_GREEN") |
| [Escrow][] | v0.60.0 | [有効: 2017/03/31](https://livenet.xrpl.org/transactions/C581E0A3F3832FFFEEB13C497658F475566BD7695B0BBA531A774E6739801515 "BADGE_GREEN") |
| [fix1368][] | v0.60.0 | [有効: 2017/03/31](https://livenet.xrpl.org/transactions/3D20DE5CD19D5966865A7D0405FAC7902A6F623659667D6CB872DF7A94B6EF3F "BADGE_GREEN") |
| [PayChan][] | v0.33.0 | [有効: 2017/03/31](https://livenet.xrpl.org/transactions/16135C0B4AB2419B89D4FB4569B8C37FF76B9EF9CE0DD99CCACB5734445AFD7E "BADGE_GREEN") |
| [TickSize][] | v0.50.0 | [有効: 2017/02/21](https://livenet.xrpl.org/transactions/A12430E470BE5C846759EAE3C442FF03374D5D73ECE5815CF4906894B769565E "BADGE_GREEN") |
| [CryptoConditions][] | v0.50.0 | [有効: 2017/01/03](https://livenet.xrpl.org/transactions/8EB00131E1C3DB35EDFF45C155D941E18C3E86BC1934FF987D2DA204F4065F15 "BADGE_GREEN") |
| [Flow][] | v0.33.0 | [有効: 2016/10/21](https://livenet.xrpl.org/transactions/C06CE3CABA3907389E4DD296C5F31C73B1548CC20BD7B83416C78CD7D4CD38FC "BADGE_GREEN") |
| [TrustSetAuth][] | v0.30.0 | [有効: 2016/07/19](https://livenet.xrpl.org/transactions/0E589DE43C38AED63B64FF3DA87D349A038F1821212D370E403EB304C76D70DF "BADGE_GREEN") |
| [MultiSign][] | v0.31.0 | [有効: 2016/06/27](https://livenet.xrpl.org/transactions/168F8B15F643395E59B9977FC99D6310E8708111C85659A9BAF8B9222EEAC5A7 "BADGE_GREEN") |
| [FeeEscalation][] | v0.31.0 | [有効: 2016/05/19](https://livenet.xrpl.org/transactions/5B1F1E8E791A9C243DD728680F108FEF1F28F21BA3B202B8F66E7833CA71D3C3 "BADGE_GREEN") |
| [Tickets][] | v0.30.1 | [禁止: v0.90.0で削除]( "BADGE_RED") |
| [SHAMapV2][] | v0.32.1 | [禁止: v1.4.0で削除](https://xrpl.org/blog/2019/rippled-1.4.0.html "BADGE_RED") |
| [FlowV2][] | v0.32.1 | [禁止: v0.33.0で削除](https://xrpl.org/blog/2016/flowv2-vetoed.html "BADGE_RED") |
| [SusPay][] | v0.31.0 | [禁止: v0.60.0で削除](https://xrpl.org/blog/2017/ticksize-voting.html#upcoming-features "BADGE_RED") |
@@ -329,7 +332,7 @@ fix1623 Amendmentは、固定金額の[CheckCashトランザクション][]（`A
| Amendment ID | ステータス |
|:-----------------------------------------------------------------|:----------|
| 25BA44241B3BD880770BFA4DA21C7180576831855368CBEC6A3154FDE4A7676E | 開発中 |
| 25BA44241B3BD880770BFA4DA21C7180576831855368CBEC6A3154FDE4A7676E | 投票中 |
Fixes a bug where certain XRP endpoints were not checked when detecting circular paths.
@@ -341,9 +344,9 @@ With this amendment, those payments fail with the [`temBAD_PATH_LOOP` result cod
## fixAmendmentMajorityCalc
[fixAmendmentMajorityCalc]: #fixamendmentmajoritycalc
| Amendment ID | Status |
| Amendment ID | ステータス |
|:-----------------------------------------------------------------|:----------|
| 4F46DF03559967AC60F2EB272FEFE3928A7594A45FF774B87A7E540DB0F8F068 | 開発中 |
| 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.
@@ -385,6 +388,16 @@ Checksトランザクションがアカウントのメタデータに影響を
この変更により、受取人によるPayment Channelの検索が容易になります。また、アカウントがオープンPayment Channelの受取人だった場合に、そのアカウントが削除されないようにします（ただし、この修正の前に作成されたチャンネルを除きます）。
## fixSTAmountCanonicalize
[fixSTAmountCanonicalize]: #fixstamountcanonicalize
| Amendment ID | ステータス |
|:-----------------------------------------------------------------|:----------|
| 452F5906C46D46F407883344BFDD90E672B672C5E9943DB4891E3A34FEEEB9DB | 投票中 |
Fixes an edge case in [deserializing](serialization.html) 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
[fixTakerDryOfferRemoval]: #fixtakerdryofferremoval
@@ -425,7 +438,7 @@ This amendment has no known impact on transaction processing.
| Amendment ID | ステータス |
|:----------|:----------|
| 3012E8230864E95A58C60FD61430D7E1B4D3353195F2981DC12B0C7C0950FFAC | 投票中 |
| 3012E8230864E95A58C60FD61430D7E1B4D3353195F2981DC12B0C7C0950FFAC | 有効 |
XRP Ledgerの分散型取引所において、オファーの掛け合わせのロジックを合理化します。[Flow](#flow) Amendmentから更新されたコードを使用してオファーの掛け合わせを行うため、[OfferCreateトランザクション][]と[Paymentトランザクション][]は多くのコードを共有します。オファーの処理方法には微妙な違いがあります。
@@ -433,6 +446,19 @@ XRP Ledgerの分散型取引所において、オファーの掛け合わせの
- 丸め方の違いが原因で、一部のオファーの組み合わせのランク付けが以前のロジックより上下したり、優先されたりします。
- 新しいロジックによって、以前のロジックより多めまたは少なめにオファーが削除される場合があります。（これには、丸め方の違いによるケースや、以前のロジックによって資金供給なしとして不正に削除されたオファーが含まれます。）
## FlowSortStrands
[FlowSortStrands]: #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
[FlowV2]: #flowv2
@@ -447,7 +473,7 @@ XRP Ledgerの分散型取引所において、オファーの掛け合わせの
| Amendment ID | ステータス |
|:-----------------------------------------------------------------|:----------|
| 1F4AFA8FA1BC8827AD4C0F682C03A8B671DCDF6B5C4DE36D44243A684103EF88 | 開発中 |
| 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.
@@ -493,7 +519,7 @@ XRP Ledgerアカウントが[マルチ署名](multi-signing.html) SignerListを
## NegativeUNL
[NegativeUNL]: #negativeunl
| Amendment ID | Status |
| Amendment ID | ステータス |
|:-----------------------------------------------------------------|:----------|
| B4E4F5D2D6FB84DF7399960A732309C9FD530EAE5941838160042833625A6076 | 開発中 |
@@ -561,7 +587,7 @@ For more information, see [`rippled` issue #3042](https://github.com/ripple/ripp
[DirectoryNodeレジャーオブジェクト](directorynode.html)内の項目をソートして、削除されるべき所有者ディレクトリのページが場合によっては削除されないというバグを修正します。
**警告:** この修正が適用されていない旧バージョンの`rippled`は、新しいルールでソートされたDirectoryNodeによって機能が停止するおそれがあります。この問題を回避するには、`rippled`バージョン0.80.0以降に[アップグレード](install-rippled.html)してください。
**警告:** このが適用されていない旧バージョンの`rippled`は、新しいルールでソートされたDirectoryNodeによって機能が停止するおそれがあります。この問題を回避するには、`rippled`バージョン0.80.0以降に[アップグレード](install-rippled.html)してください。
## SusPay
[SusPay]: #suspay
@@ -572,16 +598,26 @@ For more information, see [`rippled` issue #3042](https://github.com/ripple/ripp
この修正は、[Escrow](escrow-object.html) Amendmentに置き換えられました。
## TicketBatch
[TicketBatch]: #ticketbatch
| Amendment ID | ステータス |
|:-----------------------------------------------------------------|:----------|
| 955DF3FA5891195A9DAEFA1DDC6BB244B545DDE1BAA84CBB25D5F12A8DA68A0C | 投票中 |
This amendment adds [Tickets](tickets.html) as a way of sending transactions out of the typical sequence number order.
Standards Draft: [XLS-13d](https://github.com/xrp-community/standards-drafts/issues/16).
## Tickets
[Tickets]: #tickets
| Amendment ID | ステータス |
|:----------|:----------|
| C1B8D934087225F509BEB5A8EC24447854713EE447D277F69545ABFA0E0FD490 | 開発中 |
| C1B8D934087225F509BEB5A8EC24447854713EE447D277F69545ABFA0E0FD490 | 禁止 |
後で実行できるようトランザクションシーケンス番号を予約する方法としてTicketsを導入します。`Ticket`レジャーオブジェクトタイプと、`TicketCreate`および`TicketCancel`のトランザクションタイプを作成します。
**注意:** この修正は開発中です。
この修正は、[TicketBatch][] Amendmentに置き換えられました。
## TickSize
[TickSize]: #ticksize

51
content/concepts/consensus-network/amendments/known-amendments.md
View File

@@ -7,13 +7,15 @@ The following is a comprehensive list of all known amendments and their status o
| Name | Introduced | Status |
|:--------------------------------|:-----------|:------------------------------|
| [NegativeUNL][] | TBD | [In Development: TBD]( "BADGE_LIGHTGREY") |
| [CryptoConditionsSuite][] | TBD | [In Development: TBD]( "BADGE_LIGHTGREY") |
| [NegativeUNL][] | TBD | [In Development: TBD]( "BADGE_LIGHTGREY") |
| [OwnerPaysFee][] | TBD | [In Development: TBD]( "BADGE_LIGHTGREY") |
| [Tickets][] | TBD | [In Development: TBD]( "BADGE_LIGHTGREY") |
| [fixSTAmountCanonicalize][] | v1.7.0 | [Open for Voting: TBD](https://xrpl.org/blog/2020/rippled-1.7.0.html "BADGE_80d0e0") |
| [FlowSortStrands][] | v1.7.0 | [Open for Voting: TBD](https://xrpl.org/blog/2020/rippled-1.7.0.html "BADGE_80d0e0") |
| [TicketBatch][] | v1.7.0 | [Open for Voting: TBD](https://xrpl.org/blog/2020/rippled-1.7.0.html "BADGE_80d0e0") |
| [fix1781][] | v1.6.0 | [Open for Voting: TBD](https://xrpl.org/blog/2020/rippled-1.6.0.html "BADGE_80d0e0") |
| [fixAmendmentMajorityCalc][] | v1.6.0 | [Open for Voting: TBD](https://xrpl.org/blog/2020/rippled-1.6.0.html "BADGE_80d0e0") |
| [HardenedValidations][] | v1.6.0 | [Open for Voting: TBD](https://xrpl.org/blog/2020/rippled-1.6.0.html "BADGE_80d0e0") |
| [fix1781][] | v1.6.0 | [Open for Voting: TBD](https://xrpl.org/blog/2020/rippled-1.6.0.html "BADGE_80d0e0") |
| [FlowCross][] | v0.70.0 | [Enabled: 2020-08-04](https://livenet.xrpl.org/transactions/44C4B040448D89B6C5A5DEC97C17FEDC2E590BA094BC7DB63B7FDC888B9ED78F "BADGE_GREEN") |
| [fixQualityUpperBound][] | v1.5.0 | [Enabled: 2020-07-09](https://livenet.xrpl.org/transactions/5F8E9E9B175BB7B95F529BEFE3C84253E78DAF6076078EC450A480C861F6889E "BADGE_GREEN") |
| [RequireFullyCanonicalSig][] | v1.5.0 | [Enabled: 2020-07-03](https://livenet.xrpl.org/transactions/94D8B158E948148B949CC3C35DD5DC4791D799E1FD5D3CE0E570160EDEF947D3 "BADGE_GREEN") |
@@ -48,9 +50,10 @@ The following is a comprehensive list of all known amendments and their status o
| [TrustSetAuth][] | v0.30.0 | [Enabled: 2016-07-19](https://livenet.xrpl.org/transactions/0E589DE43C38AED63B64FF3DA87D349A038F1821212D370E403EB304C76D70DF "BADGE_GREEN") |
| [MultiSign][] | v0.31.0 | [Enabled: 2016-06-27](https://livenet.xrpl.org/transactions/168F8B15F643395E59B9977FC99D6310E8708111C85659A9BAF8B9222EEAC5A7 "BADGE_GREEN") |
| [FeeEscalation][] | v0.31.0 | [Enabled: 2016-05-19](https://livenet.xrpl.org/transactions/5B1F1E8E791A9C243DD728680F108FEF1F28F21BA3B202B8F66E7833CA71D3C3 "BADGE_GREEN") |
| [Tickets][] | v0.30.1 | [Vetoed: Removed in v0.90.0]( "BADGE_RED") |
| [SHAMapV2][] | v0.32.1 | [Vetoed: Removed in v1.4.0](https://xrpl.org/blog/2019/rippled-1.4.0.html "BADGE_RED") |
| [FlowV2][] | v0.32.1 | [Vetoed: Removed in v0.33.0](https://xrpl.org/blog/2016/flowv2-vetoed.html "BADGE_RED") |
| [SusPay][] | v0.31.0 | [Vetoed: Removed in v0.60.0](https://xrpl.org/blog/2017/ticksize-voting.html#upcoming-features "BADGE_RED") |
| [FlowV2][] | v0.32.1 | [Vetoed: Removed in v0.33.0](https://xrpl.org/blog/2016/flowv2-vetoed.html "BADGE_RED") |
**Note:** In many cases, an incomplete version of the code for an amendment is present in previous versions of the software. The "Introduced" version in the table above is the first stable version. The value "TBD" indicates that the amendment is not yet considered stable.
@@ -421,6 +424,16 @@ Fixes a bug in unused code for estimating the ratio of input to output of indivi
This amendment has no known impact on transaction processing.
## fixSTAmountCanonicalize
[fixSTAmountCanonicalize]: #fixstamountcanonicalize
| Amendment ID | Status |
|:-----------------------------------------------------------------|:----------|
| 452F5906C46D46F407883344BFDD90E672B672C5E9943DB4891E3A34FEEEB9DB | Open for Voting |
Fixes an edge case in [deserializing](serialization.html) 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
[fixTakerDryOfferRemoval]: #fixtakerdryofferremoval
@@ -461,6 +474,18 @@ Streamlines the offer crossing logic in the XRP Ledger's decentralized exchange.
- The new logic may delete more or fewer offers than the old logic. (This includes cases caused by differences in rounding and offers that were incorrectly removed as unfunded by the old logic.)
## FlowSortStrands
[FlowSortStrands]: #flowsortstrands
| Amendment ID | Status |
|:-----------------------------------------------------------------|:----------|
| AF8DF7465C338AE64B1E937D6C8DA138C0D63AD5134A68792BBBE1F63356C422 | Open for Voting |
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
[FlowV2]: #flowv2
@@ -608,17 +633,25 @@ Sorts the entries in [DirectoryNode ledger objects](directorynode.html) and fixe
This amendment was replaced by the [Escrow](escrow-object.html) amendment.
## TicketBatch
[TicketBatch]: #ticketbatch
| Amendment ID | Status |
|:-----------------------------------------------------------------|:----------|
| 955DF3FA5891195A9DAEFA1DDC6BB244B545DDE1BAA84CBB25D5F12A8DA68A0C | Open for Voting |
This amendment adds [Tickets](tickets.html) as a way of sending transactions out of the typical sequence number order.
Standards Draft: [XLS-13d](https://github.com/xrp-community/standards-drafts/issues/16).
## Tickets
[Tickets]: #tickets
| Amendment ID | Status |
|:-----------------------------------------------------------------|:----------|
| C1B8D934087225F509BEB5A8EC24447854713EE447D277F69545ABFA0E0FD490 | In Development |
Introduces Tickets as a way to reserve a transaction sequence number for later execution. Creates the `Ticket` ledger object type and the transaction types `TicketCreate` and `TicketCancel`.
**Caution:** This amendment is still in development.
| C1B8D934087225F509BEB5A8EC24447854713EE447D277F69545ABFA0E0FD490 | Vetoed |
This amendment was replaced by the [TicketBatch][] amendment.
## TickSize
[TickSize]: #ticksize

2
content/concepts/introduction/software-ecosystem.md
View File

@@ -19,7 +19,7 @@ The XRP Ledger is home to a deep, layered ecosystem of software projects powerin
The peer-to-peer network at the heart of the XRP Ledger requires a highly-reliable, efficient server to enforce the rules of consensus and transaction processing. Ripple manages and publishes a reference implementation of this server software, called [**`rippled`**](the-rippled-server.html) (pronounced "ripple-dee"). The server is available under [a permissive open-source license](https://github.com/ripple/rippled/blob/develop/LICENSE), so anyone can inspect and modify their own instance of the server, and re-publish with few restrictions.
Every instance of `rippled` syncs to the same network (unless it's configured to follow a [parallel network such as a test net](parallel-networks.html)) and has access to all communications across the network. Every `rippled` server on the network keeps a complete copy of the latest state data for the entire XRP Ledger, along with a slice of recent transactions and a record of the changes those transactions made, and every server processes every transaction independently while verifying that its outcome matches the rest of the network. Servers can be configured to keep more [ledger history](ledger-history.html) and to participate in the consensus process as a [validator](rippled-server-modes.html#reasons-to-run-a-validator).
Every instance of `rippled` syncs to the same network (unless it's configured to follow a [parallel network such as a test net](parallel-networks.html)) and has access to all communications across the network. Every `rippled` server on the network keeps a complete copy of the latest state data for the entire XRP Ledger, along with a slice of recent transactions and a record of the changes those transactions made, and every server processes every transaction independently while verifying that its outcome matches the rest of the network. Servers can be configured to keep more [ledger history](ledger-history.html) and to participate in the consensus process as a [validator](rippled-server-modes.html#validators).
This server exposes [`rippled` APIs](rippled-api.html) for users to look up data, administer the server, and submit transactions.

75
content/concepts/payment-system-basics/accounts/tickets.md Normal file
View File

@@ -0,0 +1,75 @@
---
html: tickets.html
funnel: Build
doc_type: Concepts
category: Payment System Basics
subcategory: Accounts
blurb: Send transactions in non-sequential order.
status: not_enabled
---
# Tickets
_(Requires the [TicketBatch amendment][] :not_enabled:)_
A Ticket in the XRP Ledger is a way of setting aside a [sequence number][Sequence Number] for a transaction without sending it right away. Tickets allow transactions to be sent outside of the normal sequence order. One use case for this is to allow for [multi-signed transactions](multi-signing.html) where it may take a while to collect the necessary signatures: while collecting signatures for a transaction that uses a Ticket, you can still send other transactions.
## Background
[Transactions](transaction-basics.html) have sequence numbers so that any given transaction can execute no more than once. Sequence numbers also make sure any given transaction is unique: if you send the exact same amount of money to the same person multiple times, the Sequence Number is one detail that is guaranteed to be different each time. Finally, Sequence Numbers provide an elegant way to put transactions in a consistent order, even if some of them to arrive out of order when sent throughout the network.
However, there are some situations where sequence numbers are too limiting. For example:
- Two or more users share access to an account, each with the ability to send transactions independently. If these users try to send transactions around the same time without coordinating first, they may each try to use the same Sequence number for different transactions, and only one can succeed.
- You may want to prepare and sign a transaction in advance, then save it in some secure storage so that it can be executed at any future point if certain events occur. However, if you want to continue using your account as normal in the meantime, you don't know what Sequence number the set-aside transaction will need.
- When [multiple people must sign a transaction](multi-signing.html) to make it valid, it can be difficult to plan more than one transaction at a time. If you number the transactions with separate sequence numbers, you can't send the later-numbered transactions until everyone has signed the previous transactions; but if you use the same sequence number for each pending transactions, only one of them can succeed.
Tickets provide a solution to all of these problems by setting aside sequence numbers that can be used later, outside of their usual order, but still no more than once each.
## Tickets Are Reserved Sequence Numbers
A Ticket is a record that a sequence number has been set aside to be used later. An account first sends a [TicketCreate transaction][] to set aside one or more sequence numbers as Tickets; this puts a record in the [ledger's state data](ledgers.html), in the form of a [Ticket object][], for each sequence number reserved.
Tickets are numbered using the sequence numbers that were set aside to create them. For example, if your account's current sequence number is 101 and you create 3 Tickets, those Tickets have Ticket Sequence numbers 101, 102, and 103. Doing so increases your account's sequence number to 104.
{{ include_svg("img/ticket-creation.svg", "Diagram: Creating three Tickets") }}
Later, you can send a transaction using a specific Ticket instead of a sequence number; doing so removes the corresponding Ticket from the ledger's state data and does not change your account's normal sequence number. You can also still send transactions using normal sequence numbers without using Tickets. You can use any of your available Tickets in any order at any time, but each Ticket can only be used once.
{{ include_svg("img/ticket-usage.svg", "Diagram: Using Ticket 102.") }}
Continuing the above example, you can send a transaction using sequence number 104 or any of the three Tickets you created. If you send a transaction using Ticket 102, doing so deletes Ticket 102 from the ledger. Your next transaction after that can use sequence number 104, Ticket 101, or Ticket 103.
**Caution:** Each Ticket counts as a separate item for the [owner reserve](reserves.html), so you must set aside 5 XRP for each Ticket. (The XRP becomes available again after you use the Ticket.) This cost can add up quickly if you create a large number of Tickets at once.
As with sequence numbers, sending a transaction uses up the Ticket _if and only if_ the transaction is confirmed by [consensus](consensus.html). However, transactions that fail to do what they were intended to do can still be confirmed by consensus with [`tec`-class result codes](tec-codes.html).
To look up what Tickets an account has available, use the [account_objects method][].
## Limitations
Any account can create and use Tickets on any type of transaction. However, some restrictions apply:
- Each Ticket can only be used once. It is possible to have multiple different candidate transactions that would use the same Ticket Sequence, but only one of those candidates can be validated by consensus.
- Each account cannot have more than 250 Tickets in the ledger at a time. Therefore, you cannot create more than 250 Tickets at a time, either.
- You _can_ use a Ticket to create more Tickets. If you do, the Ticket you used does not count towards the total number of Tickets you can have at once.
- Each Ticket counts toward the [owner reserve](reserves.html), so you must set aside 5 XRP for each Ticket you have not used yet. The XRP becomes available for you to use again after the Ticket is used.
- Within an individual ledger, transactions that use Tickets execute after other transactions from the same sender. If an account has multiple transactions using Tickets in the same ledger version, those Tickets execute in order from lowest Ticket Sequence to highest. (For more information, see the documentation on consensus's [canonical order](consensus.html#calculate-and-share-validations).)
- To "cancel" a Ticket, use the Ticket to [perform a no-op](about-canceling-a-transaction.html) [AccountSet transaction][]. This deletes the Ticket so that you don't have to meet its reserve requirement.
## See Also
<!-- TODO: add a tutorial for creating & using a Ticket -->
- **Concepts:**
- [Multi-Signing](multi-signing.html)
- **References:**
- [TicketCreate transaction][]
- [Transaction Common Fields](transaction-common-fields.html)
- [Ticket object](ticket.html)
- [account_objects method][]
<!--{# common link defs #}-->
{% include '_snippets/rippled-api-links.md' %}
{% include '_snippets/tx-type-links.md' %}
{% include '_snippets/rippled_versions.md' %}

2
content/concepts/payment-system-basics/transaction-basics/finality-of-results.md
View File

@@ -40,7 +40,7 @@ When you initially submit a transaction, the `rippled` server tentatively applie
- A [Payment transaction][] that tentatively failed because the sender did not have enough funds may later succeed because another transaction delivering the necessary funds came first in the canonical order. The reverse is also possible: a transaction that tentatively succeeded may fail because a transaction delivering the necessary funds did not come first after being put into canonical order.
**Tip:** For this reason, when running tests against the XRP Ledger, be sure to wait for a ledger close in between transactions if you have several accounts affecting the same data. If you are testing against a server in [stand-alone-mode](rippled-server-modes.html#reasons-to-run-a-rippled-server-in-stand-alone-mode), you must [manually close the ledger](advance-the-ledger-in-stand-alone-mode.html) in such cases.
**Tip:** For this reason, when running tests against the XRP Ledger, be sure to wait for a ledger close in between transactions if you have several accounts affecting the same data. If you are testing against a server in [stand-alone mode][], you must [manually close the ledger](advance-the-ledger-in-stand-alone-mode.html) in such cases.
## See Also

2
content/concepts/payment-system-basics/transaction-basics/transaction-basics.md
View File

@@ -54,7 +54,7 @@ Sending a transaction to the XRP Ledger involves several steps:
3. Submit a transaction to a `rippled` server. If the transaction is properly formed, the server provisionally applies the transaction to its current version of the ledger and relays the transaction to other members of the peer-to-peer network.
4. The [consensus process](consensus.html) determines which provisional transactions get included in the next validated ledger.
5. The `rippled` servers apply those transactions to the previous ledger in a canonical order and share their results.
6. If enough [trusted validators](rippled-server-modes.html#reasons-to-run-a-validator) created the exact same ledger, that ledger is declared _validated_ and the [results of the transactions](transaction-results.html) in that ledger are immutable.
6. If enough [trusted validators](rippled-server-modes.html#validators) created the exact same ledger, that ledger is declared _validated_ and the [results of the transactions](transaction-results.html) in that ledger are immutable.
See [Send XRP](send-xrp.html) for an interactive tutorial in sending XRP payments.

2
content/concepts/payment-types/escrow.md
View File

@@ -66,7 +66,7 @@ The diagram shows three different cases for three possible combinations of the e
Conditional payments have been enabled by the ["Escrow" Amendment](known-amendments.html#escrow) to the XRP Ledger Consensus Protocol since 2017-03-31. A previous version of the same functionality was available on the [XRP Ledger Test Net](xrp-test-net-faucet.html) by the name "Suspended Payments" (SusPay) in 2016.
When testing in [stand-alone mode](rippled-server-modes.html#reasons-to-run-a-rippled-server-in-stand-alone-mode), you can force the Escrow feature to be enabled locally regardless of the amendment status. Add the following stanza to your `rippled.cfg`:
When testing in [stand-alone mode][], you can force the Escrow feature to be enabled locally regardless of the amendment status. Add the following stanza to your `rippled.cfg`:
[features]
Escrow

2
content/concepts/the-rippled-server/peer-protocol.md
View File

@@ -60,7 +60,7 @@ Normally, a `rippled` server attempts to maintain a healthy number of peers, and
In the following cases, a `rippled` server does not connect to untrusted peers:
- If the server is configured as a [private peer](#private-peers), it connects _only_ to its fixed peers.
- If the server is running in [stand-alone mode](rippled-server-modes.html#reasons-to-run-a-rippled-server-in-stand-alone-mode) it does not connect to _any_ peers.
- If the server is running in [stand-alone mode][] it does not connect to _any_ peers.
## Private Peers

13
content/concepts/the-rippled-server/rippled-server-modes.ja.md
View File

@@ -60,6 +60,17 @@ XRP Ledgerの堅牢性は、バリデータが相互に接続されたネット
**注意:** スタンドアロンモードでは[レジャーを手動で進める](advance-the-ledger-in-stand-alone-mode.html)必要があります。
## レポーティングモード
[導入: rippled 1.7.0][][]
<!-- TODO: translate this section -->
Reporting mode is specialized mode for serving API requests more efficiently. In this mode, the server gets the latest validated ledger data over [gRPC](https://xrpl.org/configure-grpc.html) from a separate `rippled` server running in P2P Mode, then loads that data into a relational database ([PostgreSQL](https://www.postgresql.org/)). The reporting mode server does not directly participate in the peer-to-peer network, though it can forward requests such as transaction submission to the P2P Mode server it uses.
Multiple reporting mode servers can share access to a PostgreSQL database and [Apache Cassandra](https://cassandra.apache.org/) cluster to serve a large amount of history without each server needing a redundant copy of all the data. Reporting mode servers provide this data through the same [`rippled` APIs](rippled-api.html) with some slight changes to accommodate for the differences in how they store the underlying data.
Most notably, reporting mode servers do not report pending, non-validated ledger data or transactions. This limitation is relevant to certain use cases that rely on rapid access to in-flux data, such as performing arbitrage in the [decentralized exchange](decentralized-exchange.html).
## 関連項目
@@ -70,7 +81,7 @@ XRP Ledgerの堅牢性は、バリデータが相互に接続されたネット
- **チュートリアル:**
- [`rippled`の構成](configure-rippled.html)
- [バリデータとしての`rippled`の実行](run-rippled-as-a-validator.html)
- [スタンドアロンモードでのrippledの使用](use-stand-alone-mode.html):
- [スタンドアロンモードでのrippledの使用](use-stand-alone-mode.html):
- [スタンドアロンモードでの新しいジェネシスレジャーの開始](start-a-new-genesis-ledger-in-stand-alone-mode.html)
- [スタンドアロンモードでの保存済みレジャーの読み込み](load-a-saved-ledger-in-stand-alone-mode.html)
- [スタンドアロンモードでレジャーを進める](advance-the-ledger-in-stand-alone-mode.html)

66
content/concepts/the-rippled-server/rippled-server-modes.md
View File

@@ -2,32 +2,43 @@
The `rippled` server software can run in several modes depending on its configuration, including:
* Stock server - follows the network with a local copy of the ledger.
* Validating server, or _validator_ for short - participates in consensus (and does everything a stock server does, too).
* `rippled` server in stand-alone mode - for testing. Does not communicate to other `rippled` servers.
- [**P2P Mode**](#p2p-mode) - This is the main mode of the server: it follows the peer-to-peer network, processes transactions, and maintains some amount of [ledger history](ledger-history.html). This mode can be configured to do any or all of the following roles:
- [**Validator**](#validators) - Helps secure the network by participating in consensus
- [**API Server**](#api-servers) - Provides [API access](get-started-with-the-rippled-api.html) to read data from the shared ledger, submit transactions, and watch activity in the ledger. Optionally, this can be a [**Full History Server**](#full-history-servers), which keeps a complete record of transaction and ledger history.
- [**Hub Server**](#public-hubs) - Relays messages between many other members of the peer-to-peer network.
- [**Reporting mode**](#reporting-mode) - A specialized mode for serving API requests from a relational database. Since it does not participate in the peer-to-peer network, it requires a connection to a P2P Mode server. [New in: rippled 1.7.0][]
- [**Stand-alone mode**](#stand-alone-mode) - An offline mode for testing. Does not connect to the peer-to-peer network or use consensus.
You can also run the `rippled` executable as a client application for accessing [`rippled` APIs](rippled-api.html) locally. (Two instances of the same binary can run side-by-side in this case; one as a server, and the other running briefly as a client and then terminating.)
For information on the commands to run rippled in each of these modes, see the [Commandline Reference](commandline-usage.html).
For information on the commands to run `rippled` in each of these modes, see the [Commandline Reference](commandline-usage.html).
## Reasons to Run a Stock Server
## P2P Mode
There are lots of reasons you might want to run your own `rippled` server, but most of them can be summarized as: you can trust your own server, you have control over its workload, and you're not at the mercy of others to decide when and how you can access it. Of course, you must practice good network security to protect your server from malicious hackers.
P2P Mode is the main and default mode of the `rippled` server, and it can handle almost anything you might want your server to do. These servers form a peer-to-peer network that processes transactions and maintains the shared state of the XRP Ledger. If you want to submit transactions, read ledger data, or otherwise participate in the network, your requests must go through a P2P Mode server at some point.
You need to trust the `rippled` you use. If you connect to a malicious server, there are many ways that it can take advantage of you or cause you to lose money. For example:
P2P Mode servers can be further configured to provide additional functionality. A server running in P2P Mode with a minimally-modified config file is also called a _stock server_. Other configurations include:
* A malicious server could report that you were paid when no such payment was made.
* It could selectively show or hide payment paths and currency exchange offers to guarantee its own profit while not providing you the best deal.
* If you sent it your address's secret key, it could make arbitrary transactions on your behalf, and even transfer or destroy all the money your address holds.
- [Validator](#validators)
- [API Server](#api-servers)
- [Public Hubs](#public-hubs)
Additionally, running your own server gives you admin control over it, which allows you to run important admin-only and load-intensive commands. If you use a shared server, you have to worry about other users of the same server competing with you for the server's computing power. Many of the commands in the WebSocket API can put a lot of strain on the server, so `rippled` has the option to scale back its responses when it needs to. If you share a server with others, you may not always get the best results possible.
P2P Mode servers connect to [Mainnet](parallel-networks.html) by default.
### API Servers
All P2P Mode servers provide [APIs](rippled-api.html) for purposes like submitting transactions, checking balances and settings, and administering the server. If you query the XRP Ledger for data or submit transactions for business use, it can be useful to [run your own server](the-rippled-server.html#reasons-to-run-your-own-server).
#### Full History Servers
Unlike some other blockchains, the XRP Ledger does not require servers to have a complete transaction history to know the current state and process new transactions. As a server operator, you decide how much [ledger history](ledger-history.html) to store at a time. However, a P2P Mode server can only answer API requests using the ledger history it has locally available. For example, if you keep six months of history, your server can't describe the outcome of a transaction from a year ago. API servers with [full history](ledger-history.html#full-history) can report all transactions and balances since the inception of the XRP Ledger.
Finally, if you run a validating server, you can use a stock server as a proxy to the public network while keeping your validating server on a private network only accessible to the outside world through the stock server. This makes it more difficult to compromise the integrity of your validating server.
### Public Hubs
A public hub is a stock server with lots of [peer protocol connections](peer-protocol.html) to other servers. You can help the XRP Ledger network maintain efficient connectivity by running a stock server as a public hub. Successful public hubs embody the following traits:
A hub server is a P2P Mode server with lots of [peer protocol connections](peer-protocol.html) to other servers. Hub servers, especially _public hubs_ that allow connections from the open internet, help the XRP Ledger network maintain efficient connectivity. Successful public hubs embody the following traits:
- Good bandwidth.
@@ -35,28 +46,39 @@ A public hub is a stock server with lots of [peer protocol connections](peer-pro
- Ability to relay messages reliably.
To configure your server as a hub, increase the maximum number of peers allowed and make sure you've [forwarded the appropriate ports](forward-ports-for-peering.html) through your firewall and NAT (network address translation) router as appropriate.
## Reasons to Run a Validator
### Validators
The robustness of the XRP Ledger depends on an interconnected web of validators who each trust a few other validators _not to collude_. The more operators with different interests there are who run validators, the more certain each member of the network can be that it continues to run impartially. If you or your organization relies on the XRP Ledger, it is in your interest to contribute to the consensus process.
The robustness of the XRP Ledger depends on an interconnected web of _validators_ who each trust some other validators _not to collude_. In addition to processing each transaction and calculating ledger state just like other P2P Mode servers, validators participate actively in the [consensus protocol](consensus.html). If you or your organization relies on the XRP Ledger, it is in your interest to contribute to the consensus process by running _one_ server as a validator.
Not all `rippled` servers need to be validators: trusting more servers from the same operator does not offer better protection against collusion. An organization might run validators in multiple regions for redundancy in case of natural disasters and other emergencies.
Validation uses only a small amount of computing resources, but there is not much benefit to a single entity or organization running multiple validators because doing so does not provide more protections against collusion. Each validator identifies itself with a unique cryptographic key pair that must be carefully managed; multiple validators must not share a key pair. For these reasons, validation is disabled by default.
If your organization runs a validating server, you may also run one or more stock servers, to balance the computing load of API access, or as a proxy between your validation server and the outside network.
You can safely enable validation on a server that is also used for other purposes; this type of configuration is called an _all-purpose server_. Alternatively, you can run a _dedicated validator_ that does not perform other tasks, possibly in a [cluster](clustering.html) with other P2P Mode `rippled` servers.
For more information about running a validator, see [Run `rippled` as a Validator](run-rippled-as-a-validator.html).
## Reporting Mode
[New in: rippled 1.7.0][]
## Reasons to Run a `rippled` Server in Stand-Alone Mode
Reporting mode is specialized mode for serving API requests more efficiently. In this mode, the server gets the latest validated ledger data over [gRPC](https://xrpl.org/configure-grpc.html) from a separate `rippled` server running in P2P Mode, then loads that data into a relational database ([PostgreSQL](https://www.postgresql.org/)). The reporting mode server does not directly participate in the peer-to-peer network, though it can forward requests such as transaction submission to the P2P Mode server it uses.
You can run `rippled` in stand-alone mode without a consensus of trusted servers. In stand-alone mode, `rippled` does not communicate with any other servers in the XRP Ledger peer-to-peer network, but you can do most of the same actions on your local server only. Stand-alone provides a method for testing `rippled` behavior without being tied to the live network. For example, you can [test the effects of Amendments](amendments.html#testing-amendments) before those Amendments have gone into effect across the decentralized network.
Multiple reporting mode servers can share access to a PostgreSQL database and [Apache Cassandra](https://cassandra.apache.org/) cluster to serve a large amount of history without each server needing a redundant copy of all the data. Reporting mode servers provide this data through the same [`rippled` APIs](rippled-api.html) with some slight changes to accommodate for the differences in how they store the underlying data.
When you run `rippled` in stand-alone mode, you have to tell it what ledger version to start from:
Most notably, reporting mode servers do not report pending, non-validated ledger data or transactions. This limitation is relevant to certain use cases that rely on rapid access to in-flux data, such as performing arbitrage in the [decentralized exchange](decentralized-exchange.html).
* Create a [new genesis ledger](start-a-new-genesis-ledger-in-stand-alone-mode.html) from scratch.
* [Load an existing ledger version](load-a-saved-ledger-in-stand-alone-mode.html) from disk.
<!-- TODO: link setup steps for Reporting Mode when those are ready -->
## Stand-Alone Mode
In stand-alone mode, the server operates without attempting to connect to the peer-to-peer network or follow the consensus process. The server still provides API access as normal and uses the same transaction processing engine, so you can test `rippled` behavior without being tied to the live network. For example, you can:
- [Test the effects of Amendments](amendments.html#testing-amendments) before those Amendments have gone into effect across the decentralized network.
- [Create a new genesis ledger](start-a-new-genesis-ledger-in-stand-alone-mode.html) from scratch.
- [Load an existing ledger version](load-a-saved-ledger-in-stand-alone-mode.html) from disk, then replay specific transactions to re-create their outcomes or test other possibilities.
**Caution:** In stand-alone mode, you must [manually advance the ledger](advance-the-ledger-in-stand-alone-mode.html).

31
content/concepts/the-rippled-server/the-rippled-server.md Normal file
View File

@@ -0,0 +1,31 @@
---
html: the-rippled-server.html
funnel: Build
doc_type: Concepts
category: The rippled Server
template: template-landing-children.html
blurb: rippled is the core peer-to-peer server that manages the XRP Ledger. This section covers concepts that help you learn the "what" and "why" behind fundamental aspects of the rippled server.
---
# The `rippled` Server
`rippled` is the core peer-to-peer server that manages the XRP Ledger. This section covers concepts that help you learn the "what" and "why" behind fundamental aspects of the `rippled` server.
## Reasons to Run Your Own Server
For lighter use cases and individual servers, you can often rely on free [public servers](https://xrpl.org/get-started-with-the-rippled-api.html#public-servers). However, the more serious your use of the XRP Ledger becomes, the more important it becomes to have your own infrastructure.
There are lots of reasons you might want to run your own `rippled` server, but most of them can be summarized as: you can trust your own server, you have control over its workload, and you're not at the mercy of others to decide when and how you can access it. Of course, you must practice good network security to protect your server from malicious hackers.
You need to trust the `rippled` you use. If you connect to a malicious server, there are many ways that it can take advantage of you or cause you to lose money. For example:
* A malicious server could report that you were paid when no such payment was made.
* It could selectively show or hide payment paths and currency exchange offers to guarantee its own profit while not providing you the best deal.
* If you sent it your address's secret key, it could make arbitrary transactions on your behalf, and even transfer or destroy all the money your address holds.
Additionally, running your own server gives you [admin access](get-started-with-the-rippled-api.html#admin-access), which allows you to run important admin-only and load-intensive commands. If you use a shared server, you have to worry about other users of the same server competing with you for the server's computing power. Many of the commands in the WebSocket API can put a lot of strain on the server, so `rippled` has the option to scale back its responses when it needs to. If you share a server with others, you may not always get the best results possible.
Finally, if you run a validating server, you can use a stock server as a proxy to the public network while keeping your validating server on a private network only accessible to the outside world through the stock server. This makes it more difficult to compromise the integrity of your validating server.
## rippled Server Features
<!-- provided by the auto-generated table of children -->