<divclass="textblock"><p>The <ahref="https://xrpl.org/">XRP Ledger</a> is a decentralized cryptographic ledger powered by a network of peer-to-peer nodes. The XRP Ledger uses a novel Byzantine Fault Tolerant consensus algorithm to settle and record transactions in a secure distributed database without a central operator.</p>
<h1><aclass="anchor"id="autotoc_md302"></a>
<h1><aclass="anchor"id="autotoc_md303"></a>
XRP</h1>
<p><ahref="https://xrpl.org/xrp.html">XRP</a> is a public, counterparty-free asset native to the XRP Ledger, and is designed to bridge the many different currencies in use worldwide. XRP is traded on the open-market and is available for anyone to access. The XRP Ledger was created in 2012 with a finite supply of 100 billion units of XRP. Its creators gifted 80 billion XRP to a company, now called <ahref="https://ripple.com/">Ripple</a>, to develop the XRP Ledger and its ecosystem. Ripple uses XRP to help build the Internet of Value, ushering in a world in which money moves as fast and efficiently as information does today.</p>
<h1><aclass="anchor"id="autotoc_md303"></a>
<h1><aclass="anchor"id="autotoc_md304"></a>
rippled</h1>
<p>The server software that powers the XRP Ledger is called <code>rippled</code> and is available in this repository under the permissive ISC open-source license. The <code>rippled</code> server software is written primarily in C++ and runs on a variety of platforms. The <code>rippled</code> server software can run in several modes depending on its <ahref="https://xrpl.org/rippled-server-modes.html">configuration</a>. <br/>
</p>
<h2><aclass="anchor"id="autotoc_md304"></a>
<h2><aclass="anchor"id="autotoc_md305"></a>
Build from Source</h2>
<ul>
<li>Read the build instructions in `BUILD.md`</li>
</ul>
<h1><aclass="anchor"id="autotoc_md305"></a>
<h1><aclass="anchor"id="autotoc_md306"></a>
Key Features of the XRP Ledger</h1>
<ul>
<li><b><ahref="https://xrpl.org/xrp-ledger-overview.html#censorship-resistant-transaction-processing">Censorship-Resistant Transaction Processing</a>:</b> No single party decides which transactions succeed or fail, and no one can "roll back" a transaction after it completes. As long as those who choose to participate in the network keep it healthy, they can settle transactions in seconds.</li>
@@ -89,7 +89,7 @@ Key Features of the XRP Ledger</h1>
<li><b><ahref="https://xrpl.org/xrp-ledger-overview.html#modern-features-for-smart-contracts">Modern Features for Smart Contracts</a>:</b> Features like Escrow, Checks, and Payment Channels support cutting-edge financial applications including the <ahref="https://interledger.org/">Interledger Protocol</a>. This toolbox of advanced features comes with safety features like a process for amending the network and separate checks against invariant constraints.</li>
<li><b><ahref="https://xrpl.org/xrp-ledger-overview.html#on-ledger-decentralized-exchange">On-Ledger Decentralized Exchange</a>:</b> In addition to all the features that make XRP useful on its own, the XRP Ledger also has a fully-functional accounting system for tracking and trading obligations denominated in any way users want, and an exchange built into the protocol. The XRP Ledger can settle long, cross-currency payment paths and exchanges of multiple currencies in atomic transactions, bridging gaps of trust with XRP.</li>
</ul>
<h1><aclass="anchor"id="autotoc_md306"></a>
<h1><aclass="anchor"id="autotoc_md307"></a>
Source Code</h1>
<p>Here are some good places to start learning the source code:</p>
<ul>
@@ -97,7 +97,7 @@ Source Code</h1>
<li>Read <ahref="./Builds/levelization">the levelization document</a> to get an idea of the internal dependency graph.</li>
<li>In the big picture, the <code>main</code> function constructs an <code>ApplicationImp</code> object, which implements the <code>Application</code> virtual interface. Almost every component in the application takes an <code>Application&</code> parameter in its constructor, typically named <code>app</code> and stored as a member variable <code>app_</code>. This allows most components to depend on any other component.</li>
<p>Some of the directories under <code>src</code> are external repositories included using git-subtree. See those directories' README files for more details.</p>
<h1><aclass="anchor"id="autotoc_md308"></a>
<h1><aclass="anchor"id="autotoc_md309"></a>
See Also</h1>
<ul>
<li><ahref="https://xrpl.org/">XRP Ledger Dev Portal</a></li>
<p>This document contains the release notes for <code>rippled</code>, the reference server implementation of the XRP Ledger protocol. To learn more about how to build, run or update a <code>rippled</code> server, visit <ahref="https://xrpl.org/install-rippled.html">https://xrpl.org/install-rippled.html</a></p>
<p>Have new ideas? Need help with setting up your node? <ahref="https://github.com/xrplf/rippled/issues/new/choose">Please open an issue here</a>.</p>
<h1><aclass="anchor"id="autotoc_md310"></a>
<h1><aclass="anchor"id="autotoc_md311"></a>
Introducing XRP Ledger version 1.10.0</h1>
<p>Version 1.10.0 of <code>rippled</code>, the reference server implementation of the XRP Ledger protocol, is now available. This release introduces six new amendments, detailed below, and cleans up code to improve performance.</p>
<p><ahref="https://groups.google.com/g/ripple-server">Sign Up for Future Release Announcements</a></p>
<h2><aclass="anchor"id="autotoc_md311"></a>
<h2><aclass="anchor"id="autotoc_md312"></a>
Action Required</h2>
<p>Six new amendments are now open for voting according to the XRP Ledger's <ahref="https://xrpl.org/amendments.html">amendment process</a>, which enables protocol changes following two weeks of >80% support from trusted validators.</p>
<p>If you operate an XRP Ledger server, upgrade to version 1.10.0 by March 21 to ensure service continuity. The exact time that protocol changes take effect depends on the voting decisions of the decentralized network.</p>
<h2><aclass="anchor"id="autotoc_md312"></a>
<h2><aclass="anchor"id="autotoc_md313"></a>
Install / Upgrade</h2>
<p>On supported platforms, see the <ahref="https://xrpl.org/install-rippled.html">instructions on installing or updating <code>rippled</code></a>.</p>
<h2><aclass="anchor"id="autotoc_md313"></a>
<h2><aclass="anchor"id="autotoc_md314"></a>
New Amendments</h2>
<ul>
<li>**<code>featureImmediateOfferKilled</code>**: Changes the response code of an <code>OfferCreate</code> transaction with the <code>tfImmediateOrCancel</code> flag to return <code>tecKILLED</code> when no funds are moved. The previous return code of <code>tecSUCCESS</code> was unintuitive. <ahref="https://github.com/XRPLF/rippled/pull/4157">#4157</a></li>
@@ -98,9 +98,9 @@ New Amendments</h2>
</li>
<li>**<code>fixTrustLinesToSelf</code>**: Trust lines must be between two different accounts, but two exceptions exist because of a bug that briefly existed. This amendment removes those trust lines. <ahref="https://github.com/XRPLF/rippled/pull/4270/commits/69bb2be446e3cc24c694c0835b48bd2ecd3d119e">69bb2be</a></li>
</ul>
<h2><aclass="anchor"id="autotoc_md314"></a>
<h2><aclass="anchor"id="autotoc_md315"></a>
Changelog</h2>
<h3><aclass="anchor"id="autotoc_md315"></a>
<h3><aclass="anchor"id="autotoc_md316"></a>
New Features and Improvements</h3>
<ul>
<li><b>Improve Handshake in the peer protocol</b>: Switched to using a cryptographically secure PRNG for the Instance Cookie. <code>rippled</code> now uses hex encoding for the <code>Closed-Ledger</code> and <code>Previous-Ledger</code> fields in the Handshake. Also added <code>--newnodeid</code> and <code>--nodeid</code> command line options. <ahref="https://github.com/XRPLF/rippled/pull/4270/commits/5a15229eeb13b69c8adf1f653b88a8f8b9480546">5a15229</a></li>
@@ -115,7 +115,7 @@ New Features and Improvements</h3>
<li><b>Reduce default reserves to 10/2</b>: Updated the hard-coded default reserves to match the current settings on Mainnet. <ahref="https://github.com/XRPLF/rippled/pull/4329">#4329</a></li>
<li><b>Improve self-signed certificate generation</b>: Improved speed and security of TLS certificate generation on fresh startup. <ahref="https://github.com/XRPLF/rippled/pull/4270/commits/0ecfc7cb1a958b731e5f184876ea89ae2d4214ee">0ecfc7c</a></li>
</ul>
<h3><aclass="anchor"id="autotoc_md316"></a>
<h3><aclass="anchor"id="autotoc_md317"></a>
Bug Fixes</h3>
<ul>
<li><b>Update command-line usage help message</b>: Added <code>manifest</code> and <code>validator_info</code> to the <code>rippled</code> CLI usage statement. <ahref="https://github.com/XRPLF/rippled/pull/4270/commits/b88ed5a8ec2a0735031ca23dc6569d54787dc2f2">b88ed5a</a></li>
@@ -127,7 +127,7 @@ Bug Fixes</h3>
<li><b>Don't try to read SLE with key 0 from the ledger</b>: Fixed the <code>preclaim</code> function to check for 0 in <code>NFTokenSellOffer</code> and <code>NFTokenBuyOffer</code> before calling <code>Ledger::read</code>. This issue only affected debug builds. <ahref="https://github.com/XRPLF/rippled/pull/4351">#4351</a></li>
<li><b>Update broken link to hosted Doxygen content</b>: <ahref="https://github.com/XRPLF/rippled/pull/4270/commits/5e1cb09b8892e650f6c34a66521b6b1673bd6b65">5e1cb09</a></li>
</ul>
<h3><aclass="anchor"id="autotoc_md317"></a>
<h3><aclass="anchor"id="autotoc_md318"></a>
Code Cleanup</h3>
<ul>
<li><b>Prevent unnecessary <code>shared_ptr</code> copies by accepting a value in <code>SHAMapInnerNode::setChild</code></b>: <ahref="https://github.com/XRPLF/rippled/pull/4266">#4266</a></li>
@@ -144,11 +144,11 @@ Code Cleanup</h3>
<li><b>Remove inaccessible code paths and outdated data format wchar_t</b>: <ahref="https://github.com/XRPLF/rippled/pull/4321/commits/95fabd5762a4917753c06268192e4d4e4baef8e4">95fabd5</a></li>
<li><b>Improve move semantics in Expected</b>: <ahref="https://github.com/XRPLF/rippled/pull/4326">#4326</a></li>
</ul>
<h3><aclass="anchor"id="autotoc_md318"></a>
<h3><aclass="anchor"id="autotoc_md319"></a>
GitHub</h3>
<p>The public source code repository for <code>rippled</code> is hosted on GitHub at <ahref="https://github.com/XRPLF/rippled">https://github.com/XRPLF/rippled</a>.</p>
<p>We welcome all contributions and invite everyone to join the community of XRP Ledger developers to help build the Internet of Value.</p>
<h3><aclass="anchor"id="autotoc_md319"></a>
<h3><aclass="anchor"id="autotoc_md320"></a>
Credits</h3>
<p>The following people contributed directly to this release:</p>
<ul>
@@ -179,31 +179,31 @@ Credits</h3>
</ul>
<p>Bug Bounties and Responsible Disclosures: We welcome reviews of the rippled code and urge researchers to responsibly disclose any issues they may find.</p>
<p>To report a bug, please send a detailed report to: </p><preclass="fragment">bugs@xrpl.org
</pre><h1><aclass="anchor"id="autotoc_md320"></a>
</pre><h1><aclass="anchor"id="autotoc_md321"></a>
Introducing XRP Ledger version 1.9.4</h1>
<p>Version 1.9.4 of <code>rippled</code>, the reference implementation of the XRP Ledger protocol is now available. This release introduces an amendment that removes the ability for an NFT issuer to indicate that trust lines should be automatically created for royalty payments from secondary sales of NFTs, in response to a bug report that indicated how this functionality could be abused to mount a denial of service attack against the issuer.</p>
<h2><aclass="anchor"id="autotoc_md321"></a>
<h2><aclass="anchor"id="autotoc_md322"></a>
Action Required</h2>
<p>This release introduces a new amendment to the XRP Ledger protocol, **<code>fixRemoveNFTokenAutoTrustLine</code>** to mitigate a potential denial-of-service attack against NFT issuers that minted NFTs and allowed secondary trading of those NFTs to create trust lines for any asset.</p>
<p>This amendment is open for voting according to the XRP Ledger's <ahref="https://xrpl.org/amendments.html">amendment process</a>, which enables protocol changes following two weeks of >80% support from trusted validators.</p>
<p>If you operate an XRP Ledger server, then you should upgrade to version 1.9.4 within two weeks, to ensure service continuity. The exact time that protocol changes take effect depends on the voting decisions of the decentralized network.</p>
<p>For more information about NFTs on the XRP Ledger, see <ahref="https://xrpl.org/nft-conceptual-overview.html">NFT Conceptual Overview</a>.</p>
<h2><aclass="anchor"id="autotoc_md322"></a>
<h2><aclass="anchor"id="autotoc_md323"></a>
Install / Upgrade</h2>
<p>On supported platforms, see the <ahref="https://xrpl.org/install-rippled.html">instructions on installing or updating <code>rippled</code></a>.</p>
<h2><aclass="anchor"id="autotoc_md323"></a>
Changelog</h2>
<h2><aclass="anchor"id="autotoc_md324"></a>
Changelog</h2>
<h2><aclass="anchor"id="autotoc_md325"></a>
Contributions</h2>
<p>The primary change in this release is the following bug fix:</p>
<ul>
<li><b>Introduce fixRemoveNFTokenAutoTrustLine amendment</b>: Introduces the <code>fixRemoveNFTokenAutoTrustLine</code> amendment, which disables the <code>tfTrustLine</code> flag, which a malicious attacker could exploit to mount denial-of-service attacks against NFT issuers that specified the flag on their NFTs. (<ahref="https://github.com/XRPLF/rippled/4301">#4301</a>)</li>
</ul>
<h3><aclass="anchor"id="autotoc_md325"></a>
<h3><aclass="anchor"id="autotoc_md326"></a>
GitHub</h3>
<p>The public source code repository for <code>rippled</code> is hosted on GitHub at <ahref="https://github.com/XRPLF/rippled">https://github.com/XRPLF/rippled</a>.</p>
<p>We welcome all contributions and invite everyone to join the community of XRP Ledger developers and help us build the Internet of Value.</p>
<h3><aclass="anchor"id="autotoc_md326"></a>
<h3><aclass="anchor"id="autotoc_md327"></a>
Credits</h3>
<p>The following people contributed directly to this release:</p>
<p>Version 1.9.3 of <code>rippled</code>, the reference server implementation of the XRP Ledger protocol is now available. This release corrects minor technical flaws with the code that loads configured amendment votes after a startup and the copy constructor of <code>PublicKey</code>.</p>
<h2><aclass="anchor"id="autotoc_md328"></a>
<h2><aclass="anchor"id="autotoc_md329"></a>
Install / Upgrade</h2>
<p>On supported platforms, see the <ahref="https://xrpl.org/install-rippled.html">instructions on installing or updating <code>rippled</code></a>.</p>
<h2><aclass="anchor"id="autotoc_md329"></a>
Changelog</h2>
<h2><aclass="anchor"id="autotoc_md330"></a>
Changelog</h2>
<h2><aclass="anchor"id="autotoc_md331"></a>
Contributions</h2>
<p>This release contains the following bug fixes:</p>
<ul>
<li><b>Change by-value to by-reference to persist vote</b>: A minor technical flaw, caused by use of a copy instead of a reference, resulted in operator-configured "yes" votes to not be properly loaded after a restart. (<ahref="https://github.com/XRPLF/rippled/pull/4256">#4256</a>)</li>
<li><b>Properly handle self-assignment of PublicKey</b>: The <code>PublicKey</code> copy assignment operator mishandled the case where a <code>PublicKey</code> would be assigned to itself, and could result in undefined behavior.</li>
</ul>
<h3><aclass="anchor"id="autotoc_md331"></a>
<h3><aclass="anchor"id="autotoc_md332"></a>
GitHub</h3>
<p>The public source code repository for <code>rippled</code> is hosted on GitHub at <ahref="https://github.com/XRPLF/rippled">https://github.com/XRPLF/rippled</a>.</p>
<p>We welcome contributions, big and small, and invite everyone to join the community of XRP Ledger developers and help us build the Internet of Value.</p>
<h3><aclass="anchor"id="autotoc_md332"></a>
<h3><aclass="anchor"id="autotoc_md333"></a>
Credits</h3>
<p>The following people contributed directly to this release:</p>
<p>Version 1.9.2 of <code>rippled</code>, the reference server implementation of the XRP Ledger protocol, is now available. This release includes several fixes and improvements, including a second new fix amendment to correct a bug in Non-Fungible Tokens (NFTs) code, a new API method for order book changes, less noisy logging, and other small fixes.</p>
<h2><aclass="anchor"id="autotoc_md334"></a>
<h2><aclass="anchor"id="autotoc_md335"></a>
Action Required</h2>
<p>This release introduces a two new amendments to the XRP Ledger protocol. The first, <b>fixNFTokenNegOffer</b>, fixes a bug in code associated with the <b>NonFungibleTokensV1</b> amendment, originally introduced in <ahref="https://xrpl.org/blog/2022/rippled-1.9.0.html">version 1.9.0</a>. The second, <b>NonFungibleTokensV1_1</b>, is a "roll-up" amendment that enables the <b>NonFungibleTokensV1</b> feature plus the two fix amendments associated with it, <b>fixNFTokenDirV1</b> and <b>fixNFTokenNegOffer</b>.</p>
<p>If you want to enable NFT code on the XRP Ledger Mainnet, you can vote in favor of only the <b>NonFungibleTokensV1_1</b> amendment to support enabling the feature and fixes together, without risk that the unfixed NFT code may become enabled first.</p>
<p>These amendments are now open for voting according to the XRP Ledger's <ahref="https://xrpl.org/amendments.html">amendment process</a>, which enables protocol changes following two weeks of >80% support from trusted validators.</p>
<p>If you operate an XRP Ledger server, then you should upgrade to version 1.9.2 within two weeks, to ensure service continuity. The exact time that protocol changes take effect depends on the voting decisions of the decentralized network.</p>
<p>For more information about NFTs on the XRP Ledger, see <ahref="https://xrpl.org/nft-conceptual-overview.html">NFT Conceptual Overview</a>.</p>
<h2><aclass="anchor"id="autotoc_md335"></a>
<h2><aclass="anchor"id="autotoc_md336"></a>
Install / Upgrade</h2>
<p>On supported platforms, see the <ahref="https://xrpl.org/install-rippled.html">instructions on installing or updating <code>rippled</code></a>.</p>
<h2><aclass="anchor"id="autotoc_md336"></a>
<h2><aclass="anchor"id="autotoc_md337"></a>
Changelog</h2>
<p>This release contains the following features and improvements.</p>
<ul>
@@ -270,13 +270,13 @@ Changelog</h2>
<li><b>Improve comments and contributor documentation.</b> Various minor documentation changes including some to reflect the fact that the source code repository is now owned by the XRP Ledger Foundation. (<ahref="https://github.com/XRPLF/rippled/pull/4214">#4214</a>, <ahref="https://github.com/XRPLF/rippled/pull/4179">#4179</a>, <ahref="https://github.com/XRPLF/rippled/pull/4222">#4222</a>)</li>
<li><b>Introduces a new API book_changes to provide information in a format that is useful for building charts that highlight DEX activity at a per-ledger level.</b> (<ahref="https://github.com/XRPLF/rippled/pull/4212">#4212</a>)</li>
</ul>
<h2><aclass="anchor"id="autotoc_md337"></a>
<h2><aclass="anchor"id="autotoc_md338"></a>
Contributions</h2>
<h3><aclass="anchor"id="autotoc_md338"></a>
<h3><aclass="anchor"id="autotoc_md339"></a>
GitHub</h3>
<p>The public source code repository for <code>rippled</code> is hosted on GitHub at <ahref="https://github.com/XRPLF/rippled">https://github.com/XRPLF/rippled</a>.</p>
<p>We welcome contributions, big and small, and invite everyone to join the community of XRP Ledger developers and help us build the Internet of Value.</p>
<h3><aclass="anchor"id="autotoc_md339"></a>
<h3><aclass="anchor"id="autotoc_md340"></a>
Credits</h3>
<p>The following people contributed directly to this release:</p>
<p>For a real-time view of all lifetime contributors, including links to the commits made by each, please visit the "Contributors" section of the GitHub repository: <ahref="https://github.com/XRPLF/rippled/graphs/contributors">https://github.com/XRPLF/rippled/graphs/contributors</a>.</p>
<h1><aclass="anchor"id="autotoc_md340"></a>
<h1><aclass="anchor"id="autotoc_md341"></a>
Introducing XRP Ledger version 1.9.1</h1>
<p>Version 1.9.1 of <code>rippled</code>, the reference server implementation of the XRP Ledger protocol, is now available. This release includes several important fixes, including a fix for a syncing issue from 1.9.0, a new fix amendment to correct a bug in the new Non-Fungible Tokens (NFTs) code, and a new amendment to allow multi-signing by up to 32 signers.</p>
<h2><aclass="anchor"id="autotoc_md341"></a>
<h2><aclass="anchor"id="autotoc_md342"></a>
Action Required</h2>
<p>This release introduces two new amendments to the XRP Ledger protocol. These amendments are now open for voting according to the XRP Ledger's <ahref="https://xrpl.org/amendments.html">amendment process</a>, which enables protocol changes following two weeks of >80% support from trusted validators.</p>
<p>If you operate an XRP Ledger server, then you should upgrade to version 1.9.1 within two weeks, to ensure service continuity. The exact time that protocol changes take effect depends on the voting decisions of the decentralized network.</p>
<p>The <b>fixNFTokenDirV1</b> amendment fixes a bug in code associated with the <b>NonFungibleTokensV1</b> amendment, so the fixNFTokenDirV1 amendment should be enabled first. All validator operators are encouraged to <ahref="https://xrpl.org/configure-amendment-voting.html">configure amendment voting</a> to oppose the NonFungibleTokensV1 amendment until <em>after</em> the fixNFTokenDirV1 amendment has become enabled. For more information about NFTs on the XRP Ledger, see <ahref="https://xrpl.org/nft-conceptual-overview.html">NFT Conceptual Overview</a>.</p>
<p>The <b>ExpandedSignerList</b> amendment extends the ledger's built-in multi-signing functionality so that each list can contain up to 32 entries instead of the current limit of 8. Additionally, this amendment allows each signer to have an arbitrary 256-bit data field associated with it. This data can be used to identify the signer or provide other metadata that is useful for organizations, smart contracts, or other purposes.</p>
<h2><aclass="anchor"id="autotoc_md342"></a>
<h2><aclass="anchor"id="autotoc_md343"></a>
Install / Upgrade</h2>
<p>On supported platforms, see the <ahref="https://xrpl.org/install-rippled.html">instructions on installing or updating <code>rippled</code></a>.</p>
<h2><aclass="anchor"id="autotoc_md343"></a>
<h2><aclass="anchor"id="autotoc_md344"></a>
Changelog</h2>
<p>This release contains the following features and improvements.</p>
<h2><aclass="anchor"id="autotoc_md344"></a>
<h2><aclass="anchor"id="autotoc_md345"></a>
New Features and Amendments</h2>
<ul>
<li><b>Introduce fixNFTokenDirV1 Amendment</b> - This amendment fixes an off-by-one error that occurred in some corner cases when determining which <code>NFTokenPage</code> an <code>NFToken</code> object belongs on. It also adjusts the constraints of <code>NFTokenPage</code> invariant checks, so that certain error cases fail with a suitable error code such as <code>tecNO_SUITABLE_TOKEN_PAGE</code> instead of failing with a <code>tecINVARIANT_FAILED</code> error code. (<ahref="https://github.com/ripple/rippled/pull/4155">#4155</a>)</li>
<li><b>Introduce ExpandedSignerList Amendment</b> - This amendment expands the maximum signer list size to 32 entries and allows each signer to have an optional 256-bit <code>WalletLocator</code> field containing arbitrary data. (<ahref="https://github.com/ripple/rippled/pull/4097">#4097</a>)</li>
<li><b>Pause online deletion rather than canceling it if the server fails health check</b> - The server stops performing online deletion of old ledger history if the server fails its internal health check during this time. Online deletion can now resume after the server recovers, rather than having to start over. (<ahref="https://github.com/ripple/rippled/pull/4139">#4139</a>)</li>
</ul>
<h2><aclass="anchor"id="autotoc_md345"></a>
<h2><aclass="anchor"id="autotoc_md346"></a>
Bug Fixes and Performance Improvements</h2>
<ul>
<li><b>Fix performance issues introduced in 1.9.0</b> - Readjusts some parameters of the ledger acquisition engine to revert some changes introduced in 1.9.0 that had adverse effects on some systems, including causing some systems to fail to sync to the network. (<ahref="https://github.com/ripple/rippled/pull/4152">#4152</a>)</li>
@@ -322,13 +322,13 @@ Bug Fixes and Performance Improvements</h2>
<li><b>Fix unit test failures for DatabaseDownloader</b> - Increases a timeout in the <code>DatabaseDownloader</code> code and adjusts unit tests so that the code does not return spurious failures, and more data is logged if it does fail. (<ahref="https://github.com/ripple/rippled/pull/4021">#4021</a>)</li>
<li><b>Refactor relational database interface</b> - Improves code comments, naming, and organization of the module that interfaces with relational databases (such as the SQLite database used for tracking transaction history). (<ahref="https://github.com/ripple/rippled/pull/3965">#3965</a>)</li>
</ul>
<h2><aclass="anchor"id="autotoc_md346"></a>
<h2><aclass="anchor"id="autotoc_md347"></a>
Contributions</h2>
<h3><aclass="anchor"id="autotoc_md347"></a>
<h3><aclass="anchor"id="autotoc_md348"></a>
GitHub</h3>
<p>The public source code repository for <code>rippled</code> is hosted on GitHub at <ahref="https://github.com/ripple/rippled">https://github.com/ripple/rippled</a>.</p>
<p>We welcome contributions, big and small, and invite everyone to join the community of XRP Ledger developers and help us build the Internet of Value.</p>
<h3><aclass="anchor"id="autotoc_md348"></a>
<h3><aclass="anchor"id="autotoc_md349"></a>
Credits</h3>
<p>The following people contributed directly to this release:</p>
<ul>
@@ -343,17 +343,17 @@ Credits</h3>
</ul>
<p>For a real-time view of all lifetime contributors, including links to the commits made by each, please visit the "Contributors" section of the GitHub repository: <ahref="https://github.com/ripple/rippled/graphs/contributors">https://github.com/ripple/rippled/graphs/contributors</a>.</p>
<p>We welcome external contributions and are excited to see the broader XRP Ledger community continue to grow and thrive.</p>
<h1><aclass="anchor"id="autotoc_md349"></a>
<h1><aclass="anchor"id="autotoc_md350"></a>
Change log</h1>
<ul>
<li>API version 2 will now return <code>signer_lists</code> in the root of the <code>account_info</code> response, no longer nested under <code>account_data</code>.</li>
</ul>
<h1><aclass="anchor"id="autotoc_md350"></a>
<h1><aclass="anchor"id="autotoc_md351"></a>
Releases</h1>
<h2><aclass="anchor"id="autotoc_md351"></a>
<h2><aclass="anchor"id="autotoc_md352"></a>
Version 1.9.0</h2>
<p>This is the 1.9.0 release of <code>rippled</code>, the reference implementation of the XRP Ledger protocol. This release brings several features and improvements.</p>
<h3><aclass="anchor"id="autotoc_md352"></a>
<h3><aclass="anchor"id="autotoc_md353"></a>
New and Improved Features</h3>
<ul>
<li><b>Introduce NFT support (XLS020):</b> This release introduces support for non-fungible tokens, currently available to the developer community for broader review and testing. Developers can create applications that allow users to mint, transfer, and ultimately burn (if desired) NFTs on the XRP Ledger. You can try out the new NFT transactions using the <ahref="https://xrpl.org/xrp-testnet-faucet.html">nft-devnet</a>. Note that some fields and error codes from earlier releases of the supporting code have been refactored for this release, shown in the Code Refactoring section, below. <ahref="https://github.com/ripple/rippled/commit/70779f6850b5f33cdbb9cf4129bc1c259af0013e">70779f</a></li>
@@ -369,10 +369,10 @@ New and Improved Features</h3>
<li><b>Improve asynchronous database handlers:</b> This commit optimizes the way asynchronous node store operations are processed, both by reducing the number of times locks are held and by minimizing the number of memory allocations and data copying. <ahref="https://github.com/ripple/rippled/commit/6faaa91850d6b2eb9fbf16c1256bf7ef11ac4646">6faaa9</a></li>
<li><b>Cleanup AcceptedLedger and AcceptedLedgerTx:</b> This commit modernizes the <code>AcceptedLedger</code> and <code>AcceptedLedgerTx</code> classes, reduces their memory footprint, and reduces unnecessary dynamic memory allocations. <ahref="https://github.com/ripple/rippled/commit/8f586870917818133924bf2e11acab5321c2b588">8f5868</a></li>
</ul>
<h3><aclass="anchor"id="autotoc_md353"></a>
<h3><aclass="anchor"id="autotoc_md354"></a>
Code Refactoring</h3>
<p>This release includes name changes in the NFToken API for SFields, RPC return labels, and error codes for clarity and consistency. To refactor your code, migrate the names of these items to the new names as listed below.</p>
<li><b>Fix deletion of orphan node store directories:</b> Orphaned node store directories should only be deleted if the proper node store directories are confirmed to exist. <ahref="https://github.com/ripple/rippled/commit/06e87e0f6add5b880d647e14ab3d950decfcf416">06e87e</a></li>
</ul>
<h2><aclass="anchor"id="autotoc_md358"></a>
<h2><aclass="anchor"id="autotoc_md359"></a>
Version 1.8.5</h2>
<p>This is the 1.8.5 release of <code>rippled</code>, the reference implementation of the XRP Ledger protocol. This release includes fixes and updates for stability and security, and improvements to build scripts. There are no user-facing API or protocol changes in this release.</p>
<h3><aclass="anchor"id="autotoc_md359"></a>
<h3><aclass="anchor"id="autotoc_md360"></a>
Bug Fixes</h3>
<p>This release contains the following bug fixes and under-the-hood improvements:</p>
<ul>
@@ -424,24 +424,24 @@ Bug Fixes</h3>
<li><b>Correctly add GIT_COMMIT_HASH into version string:</b> When building the server from a non-tagged release, the build files now add the commit ID in a way that follows the semantic-versioning standard, and correctly handle the case where the commit hash ID cannot be retrieved. (d23d37f)</li>
<li><b>Update RocksDB to version 6.27.3:</b> Updates the version of RocksDB included in the server from 6.7.3 (which was released on 2020-03-18) to 6.27.3 (released 2021-12-10).</li>
</ul>
<h2><aclass="anchor"id="autotoc_md360"></a>
<h2><aclass="anchor"id="autotoc_md361"></a>
Version 1.8.4</h2>
<p>This is the 1.8.4 release of <code>rippled</code>, the reference implementation of the XRP Ledger protocol.</p>
<p>This release corrects a technical flaw introduced with 1.8.3 that may result in failures if the newly-introduced 'fast loading' is enabled. The release also adjusts default parameters used to configure the pathfinding engine to reduce resource usage.</p>
<h3><aclass="anchor"id="autotoc_md361"></a>
<h3><aclass="anchor"id="autotoc_md362"></a>
Bug Fixes</h3>
<ul>
<li><b>Adjust mutex scope in <code>walkMapParallel</code></b>: This commit corrects a technical flaw introduced with commit [7c12f0135897361398917ad2c8cda888249d42ae] that would result in undefined behavior if the server operator configured their server to use the 'fast loading' mechanism introduced with 1.8.3.</li>
<li><b>Adjust pathfinding configuration defaults</b>: This commit adjusts the default configuration of the pathfinding engine, to account for the size of the XRP Ledger mainnet. Unless explicitly overriden, the changes mean that pathfinding operations will return fewer, shallower paths than previous releases.</li>
</ul>
<h2><aclass="anchor"id="autotoc_md362"></a>
<h2><aclass="anchor"id="autotoc_md363"></a>
Version 1.8.3</h2>
<p>This is the 1.8.3 release of <code>rippled</code>, the reference implementation of the XRP Ledger protocol.</p>
<p>This release implements changes that improve the syncing performance of peers on the network, adds countermeasures to several routines involving LZ4 to defend against CVE-2021-3520, corrects a minor technical flaw that would result in the server not using a cache for nodestore operations, and adjusts tunable values to optimize disk I/O.</p>
<h3><aclass="anchor"id="autotoc_md363"></a>
<h3><aclass="anchor"id="autotoc_md364"></a>
Summary of Issues</h3>
<p>Recently, servers in the XRP Ledger network have been taking an increasingly long time to sync back to the network after restartiningg. This is one of several releases which will be made to improve on this issue.</p>
<h3><aclass="anchor"id="autotoc_md364"></a>
<h3><aclass="anchor"id="autotoc_md365"></a>
Bug Fixes</h3>
<ul>
<li><pclass="startli"><b>Parallel ledger loader & I/O performance improvements</b>: This commit makes several changes that, together, should decrease the time needed for a server to sync to the network. To make full use of this change, <code>rippled</code> needs to be using storage with high IOPS and operators need to explicitly enable this behavior by adding the following to their config file, under the <code>[node_db]</code> stanza:</p>
@@ -455,14 +455,14 @@ Bug Fixes</h3>
<li><b>Adjust the number of concurrent ledger data jobs</b>: Processing a large amount of data at once can effectively bottleneck a server's I/O subsystem. This commits helps optimize I/O performance by controlling how many jobs can concurrently process ledger data.</li>
<li><b>Two small SHAMapSync improvements</b>: This commit makes minor changes to optimize the way memory is used and control the amount of background I/O performed when attempting to fetch missing <code>SHAMap</code> nodes.</li>
</ul>
<h2><aclass="anchor"id="autotoc_md365"></a>
<h2><aclass="anchor"id="autotoc_md366"></a>
Version 1.8.2</h2>
<p>Ripple has released version 1.8.2 of rippled, the reference server implementation of the XRP Ledger protocol. This release addresses the full transaction queues and elevated transaction fees issue observed on the XRP ledger, and also provides some optimizations and small fixes to improve the server's performance overall.</p>
<h3><aclass="anchor"id="autotoc_md366"></a>
<h3><aclass="anchor"id="autotoc_md367"></a>
Summary of Issues</h3>
<p>Recently, servers in the XRP Ledger network have had full transaction queues and transactions paying low fees have mostly not been able to be confirmed through the queue. After investigation, it was discovered that a large influx of transactions to the network caused it to raise the transaction costs to be proposed in the next ledger block, and defer transactions paying lower costs to later ledgers. The first part worked as designed, but deferred transactions were not being confirmed as the ledger had capacity to process them.</p>
<p>The root cause was that there were very many low-cost transactions that different servers in the network received in a different order due to incidental differences in timing or network topology, which caused validators to propose different sets of low-cost transactions from the queue. Since none of these transactions had support from a majority of validators, they were removed from the proposed transaction set. Normally, any transactions removed from a proposed transaction set are supposed to be retried in the next ledger, but servers attempted to put these deferred transactions into their transaction queues first, which had filled up. As a result, the deferred transactions were discarded, and the network was only able to confirm transactions that paid high costs.</p>
<h3><aclass="anchor"id="autotoc_md367"></a>
<h3><aclass="anchor"id="autotoc_md368"></a>
Bug Fixes</h3>
<ul>
<li><b>Address elevated transaction fees</b>: This change addresses the full queue problems in two ways. First, it puts deferred transactions directly into the open ledger, rather than transaction queue. This reverts a subset of the changes from <ahref="https://github.com/ximinez/rippled/commit/62127d725d801641bfaa61dee7d88c95e48820c5">ximinez@62127d7</a>. A transaction that is in the open ledger but doesn't get validated should stay in the open ledger so that it can be proposed again right away. Second, it changes the order in which transactions are pulled from the transaction queue to increase the overlap in servers' initial transaction consensus proposals. Like the old rules, transactions paying higher fee levels are selected first. Unlike the old rules, transactions paying the same fee level are ordered by transaction ID / hash ascending. (Previously, transactions paying the same fee level were unsorted, resulting in each server having a different order.)</li>
@@ -476,10 +476,10 @@ Bug Fixes</h3>
<li><b>Improve handling of HTTP X-Forwarded-For and Forwarded headers</b>: Fixes the way the server handles IPv6 addresses in these HTTP headers. (<ahref="https://github.com/ripple/rippled/pull/4009">#4009</a>, <ahref="https://github.com/ripple/rippled/pull/4030">#4030</a>)</li>
<li><b>Other minor improvements to logging and Reporting Mode.</b></li>
</ul>
<h2><aclass="anchor"id="autotoc_md368"></a>
<h2><aclass="anchor"id="autotoc_md369"></a>
Version 1.8.0</h2>
<p>Ripple has released version 1.8.0 of rippled, the reference server implementation of the XRP Ledger protocol. This release brings several features and improvements.</p>
<h3><aclass="anchor"id="autotoc_md369"></a>
<h3><aclass="anchor"id="autotoc_md370"></a>
New and Improved Features</h3>
<ul>
<li><b>Improve History Sharding</b>: Shards of ledger history are now assembled in a deterministic way so that any server can make a binary-identical shard for a given range of ledgers. This makes it possible to retrieve a shard from multiple sources in parallel, then verify its integrity by comparing checksums with peers' checksums for the same shard. Additionally, there's a new admin RPC command to import ledger history from the shard store, and the crawl_shards command has been expanded with more info. (<ahref="https://github.com/ripple/rippled/issues/2688">#2688</a>, <ahref="https://github.com/ripple/rippled/pull/3726">#3726</a>, <ahref="https://github.com/ripple/rippled/pull/3875">#3875</a>)</li>
@@ -494,7 +494,7 @@ New and Improved Features</h3>
<li><b>More fields in the <code>validations</code> stream:</b> The <code>validations</code> subscription stream in the API now reports additional fields that were added to validation messages by the HardenedValidations amendment. These fields make it easier to detect misconfigurations such as multiple servers sharing a validation key pair. (<ahref="https://github.com/ripple/rippled/pull/3865">#3865</a>)</li>
<li><b>Reporting mode supports <code>validations</code> and <code>manifests</code> streams:</b> In the API it is now possible to connect to these streams when connected to a servers running in reporting. Previously, attempting to subscribe to these streams on a reporting server failed with the error <code>reportingUnsupported</code>. (<ahref="https://github.com/ripple/rippled/pull/3905">#3905</a>)</li>
</ul>
<h3><aclass="anchor"id="autotoc_md370"></a>
<h3><aclass="anchor"id="autotoc_md371"></a>
Bug Fixes</h3>
<ul>
<li><b>Clarify the safety of NetClock::time_point arithmetic</b>: * NetClock::rep is uint32_t and can be error-prone when used with subtraction. * Fixes <ahref="https://github.com/ripple/rippled/pull/3656">#3656</a></li>
@@ -508,26 +508,26 @@ Bug Fixes</h3>
<li><b>Simplify SHAMapItem construction</b>: The existing class offered several constructors which were mostly unnecessary. This eliminates all existing constructors and introduces a single new one, taking a <code>Slice</code>. The internal buffer is switched from <code><aclass="elRef"href="http://en.cppreference.com/w/cpp/container/vector.html"title="STL class.">std::vector</a></code> to <code>Buffer</code> to save a minimum of 8 bytes (plus the buffer slack that is inherent in <code><aclass="elRef"href="http://en.cppreference.com/w/cpp/container/vector.html"title="STL class.">std::vector</a></code>) per SHAMapItem instance.</li>
<li><b>Redesign stoppable objects</b>: Stoppable is no longer an abstract base class, but a pattern, modeled after the well-understood <code><aclass="elRef"href="http://en.cppreference.com/w/cpp/thread/thread.html"title="STL class.">std::thread</a></code>. The immediate benefits are less code, less synchronization, less runtime work, and (subjectively) more readable code. The end goal is to adhere to RAII in our object design, and this is one necessary step on that path.</li>
</ul>
<h2><aclass="anchor"id="autotoc_md371"></a>
<h2><aclass="anchor"id="autotoc_md372"></a>
Version 1.7.3</h2>
<p>This is the 1.7.3 release of <code>rippled</code>, the reference implementation of the XRP Ledger protocol. This release addresses an OOB memory read identified by Guido Vranken, as well as an unrelated issue identified by the Ripple C++ team that could result in incorrect use of SLEs. Additionally, this version also introduces the <code>NegativeUNL</code> amendment, which corresponds to the feature which was introduced with the 1.6.0 release.</p>
<h2><aclass="anchor"id="autotoc_md372"></a>
<h2><aclass="anchor"id="autotoc_md373"></a>
Action Required</h2>
<p>If you operate an XRP Ledger server, then you should upgrade to version 1.7.3 at your earliest convenience to mitigate the issues addressed in this hotfix. If a sufficient majority of servers on the network upgrade, the <code>NegativeUNL</code> amendment may gain a majority, at which point a two week activation countdown will begin. If the <code>NegativeUNL</code> amendment activates, servers running versions of <code>rippled</code> prior to 1.7.3 will become <ahref="https://xrpl.org/amendments.html#amendment-blocked">amendment blocked</a>.</p>
<h3><aclass="anchor"id="autotoc_md373"></a>
<h3><aclass="anchor"id="autotoc_md374"></a>
Bug Fixes</h3>
<ul>
<li><b>Improve SLE usage in check cashing</b>: Fixes a situation which could result in the incorrect use of SLEs.</li>
<li><b>Address OOB in base58 decoder</b>: Corrects a technical flaw that could allow an out-of-bounds memory read in the Base58 decoder.</li>
<li><b>Add <code>NegativeUNL</code> as a supported amendment</b>: Introduces an amendment for the Negative UNL feature introduced in <code>rippled</code> 1.6.0.</li>
</ul>
<h2><aclass="anchor"id="autotoc_md374"></a>
<h2><aclass="anchor"id="autotoc_md375"></a>
Version 1.7.2</h2>
<p>This the 1.7.2 release of rippled, the reference server implementation of the XRP Ledger protocol. This release protects against the security issue <ahref="https://www.openssl.org/news/secadv/20210325.txt">CVE-2021-3499</a> affecting OpenSSL, adds an amendment to fix an issue with small offers not being properly removed from order books in some cases, and includes various other minor fixes. Version 1.7.2 supersedes version 1.7.1 and adds fixes for more issues that were discovered during the release cycle.</p>
<h2><aclass="anchor"id="autotoc_md375"></a>
<h2><aclass="anchor"id="autotoc_md376"></a>
Action Required</h2>
<p>This release introduces a new amendment to the XRP Ledger protocol: <code>fixRmSmallIncreasedQOffers</code>. This amendments is now open for voting according to the XRP Ledger's amendment process, which enables protocol changes following two weeks of >80% support from trusted validators. If you operate an XRP Ledger server, then you should upgrade to version 1.7.2 within two weeks, to ensure service continuity. The exact time that protocol changes take effect depends on the voting decisions of the decentralized network. If you operate an XRP Ledger validator, please learn more about this amendment so you can make informed decisions about how your validator votes. If you take no action, your validator begins voting in favor of any new amendments as soon as it has been upgraded.</p>
<h3><aclass="anchor"id="autotoc_md376"></a>
<h3><aclass="anchor"id="autotoc_md377"></a>
Bug Fixes</h3>
<ul>
<li><b>fixRmSmallIncreasedQOffers Amendment:</b> This amendment fixes an issue where certain small offers can be left at the tip of an order book without being consumed or removed when appropriate and causes some payments and Offers to fail when they should have succeeded <ahref="https://github.com/ripple/rippled/pull/3827">(#3827)</a>.</li>
@@ -538,13 +538,13 @@ Bug Fixes</h3>
<li><b>Properly encode metadata from tx RPC command:</b> Fixes a problem where transaction metadata in the tx API method response would be in JSON format even when binary was requested <ahref="https://github.com/ripple/rippled/pull/3843/commits/73116297aa94c4acbfc74c2593d1aa2323b4cc52">(7311629)</a>.</li>
<li><b>Updates to Windows builds:</b> When building on Windows, use vcpkg 2021 by default and add compatibility with MSVC 2019 <ahref="https://github.com/ripple/rippled/pull/3843/commits/36fe1966c3cd37f668693b5d9910fab59c3f8b1f">(36fe196)</a>, <ahref="https://github.com/ripple/rippled/pull/3843/commits/30fd45890b1d3d5f372a2091d1397b1e8e29d2ca">(30fd458)</a>.</li>
</ul>
<h2><aclass="anchor"id="autotoc_md377"></a>
<h2><aclass="anchor"id="autotoc_md378"></a>
Version 1.7.0</h2>
<p>Ripple has released version 1.7.0 of <code>rippled</code>, the reference server implementation of the XRP Ledger protocol. This release <ahref="https://blog.ripplex.io/how-ripples-c-team-cut-rippleds-memory-footprint-down-to-size/">significantly improves memory usage</a>, introduces a protocol amendment to allow out-of-order transaction execution with Tickets, and brings several other features and improvements.</p>
<h2><aclass="anchor"id="autotoc_md378"></a>
<h2><aclass="anchor"id="autotoc_md379"></a>
Upgrading (SPECIAL ACTION REQUIRED)</h2>
<p>If you use the precompiled binaries of rippled that Ripple publishes for supported platforms, please note that Ripple has renewed the GPG key used to sign these packages. If you are upgrading from a previous install, you must download and trust the renewed key. Automatic upgrades will not work until you have re-trusted the key. </p>
<h3><aclass="anchor"id="autotoc_md379"></a>
<h3><aclass="anchor"id="autotoc_md380"></a>
Red Hat Enterprise Linux / CentOS</h3>
<p>Perform a <ahref="https://xrpl.org/update-rippled-manually-on-centos-rhel.html">manual upgrade</a>. When prompted, confirm that the key's fingerprint matches the following example, then press <code>y</code> to accept the updated key:</p>
</div><!-- fragment --><h3><aclass="anchor"id="autotoc_md380"></a>
</div><!-- fragment --><h3><aclass="anchor"id="autotoc_md381"></a>
Ubuntu / Debian</h3>
<p>Download and trust the updated public key, then perform a <ahref="https://xrpl.org/update-rippled-manually-on-ubuntu.html">manual upgrade</a> as follows:</p>
</div><!-- fragment --><h3><aclass="anchor"id="autotoc_md381"></a>
</div><!-- fragment --><h3><aclass="anchor"id="autotoc_md382"></a>
New and Improved Features</h3>
<ul>
<li><b>Rework deferred node logic and async fetch behavior:</b> This change significantly improves ledger sync and fetch times while reducing memory consumption. (<ahref="https://blog.ripplex.io/how-ripples-c-team-cut-rippleds-memory-footprint-down-to-size/">https://blog.ripplex.io/how-ripples-c-team-cut-rippleds-memory-footprint-down-to-size/</a>)</li>
@@ -587,7 +587,7 @@ New and Improved Features</h3>
<li><b>Improvements to shard downloading:</b> Previously the download_shard command could only load shards over HTTPS. Compressed shards can now also be downloaded over plain HTTP. The server fully checks the data for integrity and consistency, so the encryption is not strictly necessary. When initiating multiple shard downloads, the server now returns an error if there is not enough space to store all the shards currently being downloaded.</li>
<li><b>The manifest command is now public:</b> The manifest API method returns public information about a given validator. The required permissions have been changed so it is now part of the public API.</li>
</ul>
<h3><aclass="anchor"id="autotoc_md382"></a>
<h3><aclass="anchor"id="autotoc_md383"></a>
Bug Fixes</h3>
<ul>
<li><b>Implement sticky DNS resolution for validator list retrieval:</b> When attempting to load a validator list from a configured site, attempt to reuse the last IP that was successfully used if that IP is still present in the DNS response. (<ahref="https://github.com/ripple/rippled/issues/3494">https://github.com/ripple/rippled/issues/3494</a>).</li>
@@ -604,10 +604,10 @@ Bug Fixes</h3>
<li><b>Fixed a potential thread deadlock with history sharding.</b> ( <ahref="https://github.com/ripple/rippled/pull/3683">https://github.com/ripple/rippled/pull/3683</a> )</li>
<li><b>Various fixes to typos and comments, refactoring, and build system improvements</b></li>
</ul>
<h2><aclass="anchor"id="autotoc_md383"></a>
<h2><aclass="anchor"id="autotoc_md384"></a>
Version 1.6.0</h2>
<p>This release introduces several new features including changes to the XRP Ledger's consensus mechanism to make it even more robust in adverse conditions, as well as numerous bug fixes and optimizations.</p>
<h3><aclass="anchor"id="autotoc_md384"></a>
<h3><aclass="anchor"id="autotoc_md385"></a>
New and Improved Features</h3>
<ul>
<li>Initial implementation of Negative UNL functionality: This change can improve the liveness of the network during periods of network instability, by allowing servers to track which validators are temporarily offline and to adjust quorum calculations to match. This change requires an amendment, but the amendment is not in the <b>1.6.0</b> release. Ripple expects to run extensive public testing for Negative UNL functionality on the Devnet in the coming weeks. If public testing satisfies all requirements across security, reliability, stability, and performance, then the amendment could be included in a version 2.0 release. [<ahref="https://github.com/ripple/rippled/pull/3380">#3380</a>]</li>
@@ -623,7 +623,7 @@ New and Improved Features</h3>
<li>Various Build and CI Improvements including updates to RocksDB 6.7.3 [<ahref="https://github.com/ripple/rippled/pull/3356">#3356</a>], NuDB 2.0.3 [<ahref="https://github.com/ripple/rippled/pull/3437">#3437</a>], adjusting CMake settings so that rippled can be built as a submodule [<ahref="https://github.com/ripple/rippled/pull/3449">#3449</a>], and adding Travis CI settings for Ubuntu Bionic Beaver [<ahref="https://github.com/ripple/rippled/pull/3319">#3319</a>].</li>
<li>Better documentation in the config file for online deletion and database tuning. [<ahref="https://github.com/ripple/rippled/pull/3429">#3429</a>]</li>
</ul>
<h3><aclass="anchor"id="autotoc_md385"></a>
<h3><aclass="anchor"id="autotoc_md386"></a>
Bug Fixes</h3>
<ul>
<li>Fix the 14 day timer to enable amendment to start at the correct quorum size [<ahref="https://github.com/ripple/rippled/pull/3396">#3396</a>]</li>
@@ -638,7 +638,7 @@ Bug Fixes</h3>
<li>Add the <code>ledger_cleaner</code> command to rippled command line help [<ahref="https://github.com/ripple/rippled/pull/3305">#3305</a>]</li>
<li>Various typo and comments fixes.</li>
</ul>
<h2><aclass="anchor"id="autotoc_md386"></a>
<h2><aclass="anchor"id="autotoc_md387"></a>
Version 1.5.0</h2>
<p>The <code>rippled</code> 1.5.0 release introduces several improvements and new features, including support for gRPC API, API versioning, UNL propagation via the peer network, new RPC methods <code>validator_info</code> and <code>manifest</code>, augmented <code>submit</code> method, improved <code>tx</code> method response, improved command line parsing, improved handshake protocol, improved package building and various other minor bug fixes and improvements.</p>
<p>This release also introduces two new amendments: <code>fixQualityUpperBound</code> and <code>RequireFullyCanonicalSig</code>.</p>
<li>Lag ratchet code fix to use proper ephemeral public keys instead of the long-term master public keys.<ahref="https://github.com/ripple/rippled/commit/6529d3e6f7333fc5226e5aa9ae65f834cb93dfe5"><code>6529d3e6f</code></a></li>
</ul>
<h2><aclass="anchor"id="autotoc_md387"></a>
<h2><aclass="anchor"id="autotoc_md388"></a>
Version 1.4.0</h2>
<p>The <code>rippled</code> 1.4.0 release introduces several improvements and new features, including support for deleting accounts, improved peer slot management, improved CI integration and package building and support for <ahref="https://en.wikipedia.org/wiki/C%2B%2B17">C++17</a> and <ahref="https://www.boost.org/users/history/version_1_71_0.html">Boost 1.71</a>. Finally, this release removes the code for the <code>SHAMapV2</code> amendment which failed to gain majority support and has been obsoleted by other improvements.</p>
<p><b>New and Updated Features</b></p><ul>
@@ -681,7 +681,7 @@ Version 1.4.0</h2>
<li>Properly update the <code>server_state</code> when a server detects a disagreement between itself and the network.</li>
<li>Allow Ed25519 keys to be used with the <code>channel_authorize</code> command.</li>
</ul>
<h2><aclass="anchor"id="autotoc_md388"></a>
<h2><aclass="anchor"id="autotoc_md389"></a>
Version 1.3.1</h2>
<p>The <code>rippled</code> 1.3.1 release improves the built-in deadlock detection code, improves logging during process startup, changes the package build pipeline and improves the build documentation.</p>
<p><b>New and Updated Features</b></p>
@@ -690,7 +690,7 @@ Version 1.3.1</h2>
<li>Add a LogicError when a deadlock is detected (355a7b04)</li>
<li>Improve logging during process startup (7c24f7b1)</li>
</ul>
<h2><aclass="anchor"id="autotoc_md389"></a>
<h2><aclass="anchor"id="autotoc_md390"></a>
Version 1.3.0</h2>
<p>The <code>rippled</code> 1.3.0 release introduces several new features and overall improvements to the codebase, including the <code>fixMasterKeyAsRegularKey</code> amendment, code to adjust the timing of the consensus process and support for decentralized validator domain verification. The release also includes miscellaneous improvements including in the transaction censorship detection code, transaction validation code, manifest parsing code, configuration file parsing code, log file rotation code, and in the build, continuous integration, testing and package building pipelines.</p>
<p><b>New and Updated Features</b></p><ul>
@@ -702,7 +702,7 @@ Version 1.3.0</h2>
<li>Improve ledger trie ancestry tracking to reduce unnecessary error messages.</li>
<li>More efficient detection of dry paths in the payment engine. Although not a transaction-breaking change, this should reduce spurious error messages in the log files.</li>
</ul>
<h2><aclass="anchor"id="autotoc_md390"></a>
<h2><aclass="anchor"id="autotoc_md391"></a>
Version 1.2.4</h2>
<p>The <code>rippled</code> 1.2.4 release improves the way that shard crawl requests are routed and the robustness of configured validator list retrieval by imposing a 20 second timeout.</p>
<p><b>New and Updated Features</b></p>
@@ -712,7 +712,7 @@ Version 1.2.4</h2>
<li>Use public keys when routing shard crawl requests</li>
<li>Enforce a 20s timeout when making validator list requests (RIPD-1737)</li>
</ul>
<h2><aclass="anchor"id="autotoc_md391"></a>
<h2><aclass="anchor"id="autotoc_md392"></a>
Version 1.2.3</h2>
<p>The <code>rippled</code> 1.2.3 release corrects a technical flaw which in some circumstances can cause a null pointer dereference that can crash the server.</p>
<p><b>New and Updated Features</b></p>
@@ -721,7 +721,7 @@ Version 1.2.3</h2>
<ul>
<li>Fix a technical flaw which in some circumstances can cause a null pointer dereference that can crash the server.</li>
</ul>
<h2><aclass="anchor"id="autotoc_md392"></a>
<h2><aclass="anchor"id="autotoc_md393"></a>
Version 1.2.2</h2>
<p>The <code>rippled</code> 1.2.2 release corrects a technical flaw in the fee escalation engine which could cause some fee metrics to be calculated incorrectly. In some circumstances this can potentially cause the server to crash.</p>
<p><b>New and Updated Features</b></p>
@@ -730,7 +730,7 @@ Version 1.2.2</h2>
<ul>
<li>Fix a technical flaw in the fee escalation engine which could cause some fee metrics to be calculated incorrectly (4c06b3f86)</li>
</ul>
<h2><aclass="anchor"id="autotoc_md393"></a>
<h2><aclass="anchor"id="autotoc_md394"></a>
Version 1.2.1</h2>
<p>The <code>rippled</code> 1.2.1 release introduces several fixes including a change in the information reported via the enhanced crawl functionality introduced in the 1.2.0 release, a fix for a potential race condition when processing a status change message for a peer, and for a technical flaw that could cause a server to not properly detect that it had lost all its peers.</p>
<p>The release also adds the <code>delivered_amount</code> field to more responses to simplify the handling of payment or check cashing transactions.</p>
@@ -743,7 +743,7 @@ Version 1.2.1</h2>
<li>Display validator status only in response to admin requests (2d6a518a)</li>
<li>Add the <code>delivered_amount</code> to more RPC commands (f2756914)</li>
</ul>
<h2><aclass="anchor"id="autotoc_md394"></a>
<h2><aclass="anchor"id="autotoc_md395"></a>
Version 1.2.0</h2>
<p>The <code>rippled</code> 1.2.0 release introduces the MultisignReserve Amendment, which reduces the reserve requirement associated with signer lists. This release also includes incremental improvements to the code that handles offers. Furthermore, <code>rippled</code> now also has the ability to automatically detect transaction censorship attempts and issue warnings of increasing severity for transactions that should have been included in a closed ledger after several rounds of consensus.</p>
<li>Add safe_cast to sure no overflow in casts between enums and integral types (a7e4541)</li>
</ul>
<h2><aclass="anchor"id="autotoc_md395"></a>
<h2><aclass="anchor"id="autotoc_md396"></a>
Version 1.1.2</h2>
<p>The <code>rippled</code> 1.1.2 release introduces a fix for an issue that could have prevented cluster peers from successfully bypassing connection limits when connecting to other servers on the same cluster. Additionally, it improves logic used to determine what the preferred ledger is during suboptimal network conditions.</p>
<p><b>New and Updated Features</b></p>
@@ -781,7 +781,7 @@ Version 1.1.2</h2>
<li>Properly bypass connection limits for cluster peers (#2795, #2796)</li>
<p>The <code>rippled</code> 1.1.1 release adds support for redirections when retrieving validator lists and changes the way that validators with an expired list behave. Additionally, informational commands return more useful information to allow server operators to determine the state of their server</p>
<p><b>New and Updated Features</b></p>
@@ -793,7 +793,7 @@ Version 1.1.1</h2>
<ul>
<li>Properly handle expired validator lists when validating (#2734)</li>
</ul>
<h2><aclass="anchor"id="autotoc_md397"></a>
<h2><aclass="anchor"id="autotoc_md398"></a>
Version 1.1.0</h2>
<p>The <code>rippled</code> 1.1.0 release release includes the <code>DepositPreAuth</code> amendment, which combined with the previously released <code>DepositAuth</code> amendment, allows users to pre-authorize incoming transactions to accounts, by whitelisting sender addresses. The 1.1.0 release also includes incremental improvements to several previously released features (<code>fix1515</code> amendment), deprecates support for the <code>sign</code> and <code>sign_for</code> commands from the rippled API and improves invariant checking for enhanced security.</p>
<p>Ripple recommends that all server operators upgrade to XRP Ledger version 1.1.0 by Thursday, 2018-09-27, to ensure service continuity.</p>
@@ -829,7 +829,7 @@ Version 1.1.0</h2>
<li>Improve JSON exception handling (#2605)</li>
<li>Add missing virtual destructors (#2532)</li>
</ul>
<h2><aclass="anchor"id="autotoc_md398"></a>
<h2><aclass="anchor"id="autotoc_md399"></a>
Version 1.0.0.</h2>
<p>The <code>rippled</code> 1.0.0 release includes incremental improvements to several previously released features.</p>
<p><b>New and Updated Features</b></p>
@@ -843,7 +843,7 @@ Version 1.0.0.</h2>
<li>Add <code>check</code>, <code>escrow</code>, and <code>pay_chan</code> to <code>ledger_entry</code> (RIPD-1600)</li>
<li>Clarify Escrow semantics (RIPD-1571)</li>
</ul>
<h2><aclass="anchor"id="autotoc_md399"></a>
<h2><aclass="anchor"id="autotoc_md400"></a>
Version 0.90.1</h2>
<p>The <code>rippled</code> 0.90.1 release includes fixes for issues reported by external security researchers. These issues, when exploited, could cause a rippled instance to restart or, in some circumstances, stop executing. While these issues can result in a denial of service attack, none affect the integrity of the XRP Ledger and no user funds, including XRP, are at risk.</p>
<p><b>New and Updated Features</b></p>
@@ -859,7 +859,7 @@ Version 0.90.1</h2>
</li>
<li>Use lock when creating a peer shard rangeset</li>
</ul>
<h2><aclass="anchor"id="autotoc_md400"></a>
<h2><aclass="anchor"id="autotoc_md401"></a>
Version 0.90.0</h2>
<p>The <code>rippled</code> 0.90.0 release introduces several features and enhancements that improve the reliability, scalability and security of the XRP Ledger.</p>
<li>Reduce noise in log (<ahref="https://github.com/ripple/rippled/issues/2352">#2352</a>)</li>
</ul>
<h2><aclass="anchor"id="autotoc_md401"></a>
<h2><aclass="anchor"id="autotoc_md402"></a>
Version 0.81.0</h2>
<p>The <code>rippled</code> 0.81.0 release introduces changes that improve the scalability of the XRP Ledger and transitions the recommended validator configuration to a new hosted site, as described in Ripple's <ahref="https://ripple.com/dev-blog/decentralization-strategy-update/">Decentralization Strategy Update</a> post.</p>
<p><b>New and Updated Features</b></p>
@@ -913,7 +913,7 @@ Version 0.81.0</h2>
<ul>
<li>Optimize queries for account_tx to work around SQLite query planner (<ahref="https://github.com/ripple/rippled/issues/2312">#2312</a>)</li>
</ul>
<h2><aclass="anchor"id="autotoc_md402"></a>
<h2><aclass="anchor"id="autotoc_md403"></a>
Version 0.80.2</h2>
<p>The <code>rippled</code> 0.80.2 release introduces changes that improve the scalability of the XRP Ledger.</p>
<p><b>New and Updated Features</b></p>
@@ -924,7 +924,7 @@ Version 0.80.2</h2>
<li>Increase the number of transaction handlers that can be in flight in the job queue and decrease the relative cost for peers to share transaction and ledger data.</li>
<li>Make better use of resources by adjusting the number of threads we initialize, by reverting commit <ahref="https://github.com/ripple/rippled/commit/68b8ffdb638d07937f841f7217edeb25efdb3b5d">#68b8ffd</a>.</li>
</ul>
<h2><aclass="anchor"id="autotoc_md403"></a>
<h2><aclass="anchor"id="autotoc_md404"></a>
Version 0.80.1</h2>
<p>The <code>rippled</code> 0.80.1 release provides several enhancements in support of published validator lists and corrects several bugs.</p>
<p><b>New and Updated Features</b></p>
@@ -941,7 +941,7 @@ Version 0.80.1</h2>
<li>Explictly use <aclass="elRef"href="http://en.cppreference.com/w/cpp/container/deque.html"title="STL class.">std::deque</a> for missing node handler in SHAMap code (<ahref="https://github.com/ripple/rippled/issues/2252">#2252</a>)</li>
<p>The <code>rippled</code> 0.80.0 release introduces several enhancements that improve the reliability, scalability and security of the XRP Ledger.</p>
<p>Highlights of this release include:</p>
@@ -969,7 +969,7 @@ Version 0.80.0</h2>
<li>Fix an issue where <code>setAmendmentBlocked</code> is only called when processing the <code>EnableAmendment</code> transaction for the amendment (<ahref="https://github.com/ripple/rippled/issues/2137">#2137</a>)</li>
<li>Track escrow in recipient's owner directory (<ahref="https://github.com/ripple/rippled/issues/2212">#2212</a>)</li>
</ul>
<h2><aclass="anchor"id="autotoc_md405"></a>
<h2><aclass="anchor"id="autotoc_md406"></a>
Version 0.70.2</h2>
<p>The <code>rippled</code> 0.70.2 release corrects an emergent behavior which causes large numbers of transactions to get stuck in different nodes' open ledgers without being passed on to validators, resulting in a spike in the open ledger fee on those nodes.</p>
<p><b>New and Updated Features</b></p>
@@ -978,7 +978,7 @@ Version 0.70.2</h2>
<ul>
<li>Recent fee rises and TxQ issues (<ahref="https://github.com/ripple/rippled/issues/2215">#2215</a>)</li>
</ul>
<h2><aclass="anchor"id="autotoc_md406"></a>
<h2><aclass="anchor"id="autotoc_md407"></a>
Version 0.70.1</h2>
<p>The <code>rippled</code> 0.70.1 release corrects a technical flaw in the newly refactored consensus code that could cause a node to get stuck in consensus due to stale votes from a peer, and allows compiling <code>rippled</code> under the 1.1.x releases of OpenSSL.</p>
<p><b>New and Updated Features</b></p>
@@ -989,7 +989,7 @@ Version 0.70.1</h2>
<li>Log invariant check messages at "fatal" level (<ahref="https://github.com/ripple/rippled/pull/2154">2154</a>)</li>
<li>Fix the consensus code to update all disputed transactions after a node changes a position (<ahref="https://github.com/ripple/rippled/pull/2156">2156</a>)</li>
</ul>
<h2><aclass="anchor"id="autotoc_md407"></a>
<h2><aclass="anchor"id="autotoc_md408"></a>
Version 0.70.0</h2>
<p>The <code>rippled</code> 0.70.0 release introduces several enhancements that improve the reliability, scalability and security of the network.</p>
<p>Highlights of this release include:</p>
@@ -1025,28 +1025,28 @@ Version 0.70.0</h2>
<li>JobQueue occasionally crashes on shutdown (#2025)</li>
<p>The <code>rippled</code> 0.60.2 release further strengthens handling of cases associated with a previously patched exploit, in which NoRipple flags were being bypassed by using offers.</p>
<p><b>New and Updated Features</b></p>
<p>This release has no new features.</p>
<p><b>Bug Fixes</b></p>
<p>Prevent the ability to bypass the <code>NoRipple</code> flag using offers (<ahref="https://github.com/ripple/rippled/commit/4ff40d4954dfaa237c8b708c2126cb39566776da">#7cd4d78</a>)</p>
<h2><aclass="anchor"id="autotoc_md410"></a>
<h2><aclass="anchor"id="autotoc_md411"></a>
Version 0.60.1</h2>
<p>The <code>rippled</code> 0.60.1 release corrects a technical flaw that resulted from using 32-bit space identifiers instead of the protocol-defined 16-bit values for Escrow and Payment Channel ledger entries. rippled version 0.60.1 also fixes a problem where the WebSocket timeout timer would not be cancelled when certain errors occurred during subscription streams. Ripple requires upgrading to rippled version 0.60.1 immediately.</p>
<p><b>New and Updated Feature</b></p>
<p>This release has no new features.</p>
<p><b>Bug Fixes</b></p>
<p>Correct calculation of Escrow and Payment Channel indices. Fix WebSocket timeout timer issues.</p>
<h2><aclass="anchor"id="autotoc_md411"></a>
<h2><aclass="anchor"id="autotoc_md412"></a>
Version 0.60.0</h2>
<p>The <code>rippled</code> 0.60.0 release introduces several enhancements that improve the reliability and scalability of the Ripple Consensus Ledger (RCL), including features that add ledger interoperability by improving Interledger Protocol compatibility. Ripple recommends that all server operators upgrade to version 0.60.0 by Thursday, 2017-03-30, for service continuity.</p>
<p>Highlights of this release include:</p>
@@ -1088,21 +1088,21 @@ Version 0.60.0</h2>
<li>Check for malformed public key on payment channel (#2027)</li>
<li>Send a websocket ping before timing out in server (#2035)</li>
</ul>
<h2><aclass="anchor"id="autotoc_md412"></a>
<h2><aclass="anchor"id="autotoc_md413"></a>
Version 0.50.3</h2>
<p>The <code>rippled</code> 0.50.3 release corrects a reported exploit that would allow a combination of trust lines and order books in a payment path to bypass the blocking effect of the <ahref="https://ripple.com/build/understanding-the-noripple-flag/"><code>NoRipple</code></a> flag. Ripple recommends that all server operators immediately upgrade to version 0.50.3.</p>
<p><b>New and Updated Features</b></p>
<p>This release has no new features.</p>
<p><b>Bug Fixes</b></p>
<p>Correct a reported exploit that would allow a combination of trust lines and order books in a payment path to bypass the blocking effect of the “NoRipple” flag.</p>
<h2><aclass="anchor"id="autotoc_md413"></a>
<h2><aclass="anchor"id="autotoc_md414"></a>
Version 0.50.2</h2>
<p>The <code>rippled</code> 0.50.2 release adjusts the default TLS cipher list and corrects a flaw that would not allow an SSL handshake to properly complete if the port was configured using the <code>wss</code> keyword. Ripple recommends upgrading to 0.50.2 only if server operators are running rippled servers that accept client connections over TLS.</p>
<p><b>New and Updated Features</b></p>
<p>This release has no new features.</p>
<p><b>Bug Fixes</b></p>
<p>Adjust the default cipher list and correct a flaw that would not allow an SSL handshake to properly complete if the port was configured using the <code>wss</code> keyword (#1985)</p>
<h2><aclass="anchor"id="autotoc_md414"></a>
<h2><aclass="anchor"id="autotoc_md415"></a>
Version 0.50.0</h2>
<p>The <code>rippled</code> 0.50.0 release includes TickSize, which allows gateways to set a "tick size" for assets they issue to help promote faster price discovery and deeper liquidity, as well as reduce transaction spam and ledger churn on RCL. Ripple expects TickSize to be enabled via an Amendment called TickSize on Tuesday, 2017-02-21.</p>
<p>You can <ahref="https://ripple.com/build/rippled-setup/#updating-rippled">update to the new version</a> on Red Hat Enterprise Linux 7 or CentOS 7 using yum. For other platforms, please <ahref="https://wiki.ripple.com/Rippled_build_instructions">compile the new version from source</a>.</p>
@@ -1155,7 +1155,7 @@ Version 0.50.0</h2>
<p>We expect the previously announced Suspended Payments feature, which introduces new transaction types to the Ripple protocol that will permit users to cryptographically escrow XRP on RCL, to be enabled via the <ahref="https://ripple.com/build/amendments/#suspay">SusPay</a> Amendment on Tuesday, 2017-02-21.</p>
<p>Also, we expect support for crypto-conditions, which are signature-like structures that can be used with suspended payments to support ILP integration, to be included in the next rippled release scheduled for March.</p>
<p>Lastly, we do not have an update on the previously announced changes to the hash tree structure that rippled uses to represent a ledger, called <ahref="https://ripple.com/build/amendments/#shamapv2">SHAMapV2</a>. At the time of activation, this amendment will require brief scheduled allowable unavailability while the changes to the hash tree structure are computed by the network. We will keep the community updated as we progress towards this date (TBA).</p>
<h2><aclass="anchor"id="autotoc_md415"></a>
<h2><aclass="anchor"id="autotoc_md416"></a>
Version 0.40.1</h2>
<p>The <code>rippled</code> 0.40.1 release increases SQLite database limits in all rippled servers. Ripple recommends upgrading to 0.40.1 only if server operators are running rippled servers with full-history of the ledger. There are no new or updated features in the 0.40.1 release.</p>
<p>You can update to the new version on Red Hat Enterprise Linux 7 or CentOS 7 using yum. For other platforms, please compile the new version from source.</p>
@@ -1163,7 +1163,7 @@ Version 0.40.1</h2>
<p>This release has no new features.</p>
<p><b>Bug Fixes</b></p>
<p>Increase SQLite database limits to prevent full-history servers from crashing when restarting. (#1961)</p>
<h2><aclass="anchor"id="autotoc_md416"></a>
<h2><aclass="anchor"id="autotoc_md417"></a>
Version 0.40.0</h2>
<p>The <code>rippled</code> 0.40.0 release includes Suspended Payments, a new transaction type on the Ripple network that functions similar to an escrow service, which permits users cryptographically escrow XRP on RCL with an expiration date. Ripple expects Suspended Payments to be enabled via an Amendment named <ahref="https://ripple.com/build/amendments/#suspay">SusPay</a> on Tuesday, 2017-01-17.</p>
<p>You can update to the new version on Red Hat Enterprise Linux 7 or CentOS 7 using yum. For other platforms, please compile the new version from source.</p>
@@ -1178,7 +1178,7 @@ Version 0.40.0</h2>
<p>Correct an issue in payment flow code that did not remove an unfunded offer (#1860)</p>
<p>Sign validator manifests with both ephemeral and master keys (#1865)</p>
<p>The <code>rippled</code> 0.33.0 release includes an improved version of the payment code, which we expect to be activated via Amendment on Wednesday, 2016-10-20 with the name <ahref="https://ripple.com/build/amendments/#flow">Flow</a>. We are also introducing XRP Payment Channels, a new structure in the ledger designed to support <ahref="https://interledger.org/">Interledger Protocol</a> trust lines as balances get substantial, which we expect to be activated via Amendment on a future date (TBA) with the name <ahref="https://ripple.com/build/amendments/#paychan">PayChan</a>. Lastly, we will be introducing changes to the hash tree structure that rippled uses to represent a ledger, which we expect to be available via Amendment on a future date (TBA) with the name <ahref="https://ripple.com/build/amendments/#shamapv2">SHAMapV2</a>.</p>
<p>You can <ahref="https://ripple.com/build/rippled-setup/#updating-rippled">update to the new version</a> on Red Hat Enterprise Linux 7 or CentOS 7 using yum. For other platforms, please <ahref="https://wiki.ripple.com/Rippled_build_instructions">compile the new version from source</a>.</p>
@@ -1203,7 +1203,7 @@ Version 0.33.0</h2>
<p><code>PaymentSandbox::balanceHook</code> can return the wrong issuer, which could cause the transfer fee to be incorrectly by-passed in rare circumstances. [RIPD-1274, #1827]</p>
<p>Prevent concurrent write operations in websockets [#1806]</p>
<p>Add HTTP status page for new websocket implementation [#1855]</p>
<h2><aclass="anchor"id="autotoc_md418"></a>
<h2><aclass="anchor"id="autotoc_md419"></a>
Version 0.32.1</h2>
<p>The <code>rippled</code> 0.32.1 release includes an improved version of the payment code, which we expect to be available via Amendment on Wednesday, 2016-08-24 with the name FlowV2, and a completely new implementation of the WebSocket protocol for serving clients.</p>
<p>You can <ahref="https://ripple.com/build/rippled-setup/#updating-rippled">update to the new version</a> on Red Hat Enterprise Linux 7 or CentOS 7 using yum. For other platforms, please <ahref="https://wiki.ripple.com/Rippled_build_instructions">compile the new version from source</a>.</p>
@@ -1222,7 +1222,7 @@ protocol = wss2
<p>Fix bug that could cause a previously fee queued transaction to not be relayed after being in the open ledger for an extended time without being included in a validated ledger. Fix bug that would allow an account to have more than the allowed limit of transactions in the fee queue. Fix bug that could crash debug builds in rare cases when replacing a dropped transaction. (RIPD-1200)</p>
<p>Remove incompatible OS X switches in Test.py (RIPD-1250)</p>
<p>Autofilling a transaction fee (sign / submit) with the experimental <code>x-queue-okay</code> parameter will use the user’s maximum fee if the open ledger fee is higher, improving queue position, and giving the tx more chance to succeed. (RIPD-1194)</p>
<h2><aclass="anchor"id="autotoc_md419"></a>
<h2><aclass="anchor"id="autotoc_md420"></a>
Version 0.32.0</h2>
<p>The <code>rippled</code> 0.32.0 release improves transaction queue which now supports batching and can hold up to 10 transactions per account, allowing users to queue multiple transactions for processing when the network load is high. Additionally, the <code>server_info</code> and <code>server_state</code> commands now include information on transaction cost multipliers and the fee command is available to unprivileged users. We advise rippled operators to upgrade immediately.</p>
<p>You can update to the new version on Red Hat Enterprise Linux 7 or CentOS 7 using yum. For other platforms, please compile the new version from source.</p>
@@ -1268,7 +1268,7 @@ Version 0.32.0</h2>
<li>Remove obsolete sendGetPeers support (RIPD-164)</li>
<p>The <code>rippled</code> 0.31.2 release corrects issues with the fee escalation algorithm. We advise <code>rippled</code> operators to upgrade immediately.</p>
<p>You can <ahref="https://ripple.com/build/rippled-setup/#updating-rippled">update to the new version</a> on Red Hat Enterprise Linux 7 or CentOS 7 using yum. For other platforms, please <ahref="https://wiki.ripple.com/Rippled_build_instructions">compile the new version from source</a>.</p>
@@ -1279,7 +1279,7 @@ Version 0.31.2</h2>
<li>A defect in the fee escalation algorithm that caused network fees to escalate more rapidly than intended has been corrected. (RIPD-1177)</li>
<li>The minimum local fee advertised by validators will no longer be adjusted upwards.</li>
</ul>
<h2><aclass="anchor"id="autotoc_md421"></a>
<h2><aclass="anchor"id="autotoc_md422"></a>
Version 0.31.1</h2>
<p>The <code>rippled</code> 0.31.1 release contains one important bug fix. We advise <code>rippled</code> operators to upgrade immediately.</p>
<p>You can <ahref="https://ripple.com/build/rippled-setup/#updating-rippled">update to the new version</a> on Red Hat Enterprise Linux 7 or CentOS 7 using yum. For other platforms, please <ahref="https://wiki.ripple.com/Rippled_build_instructions">compile the new version from source</a>.</p>
@@ -1290,7 +1290,7 @@ Version 0.31.1</h2>
<ul>
<li>Correctly handle ledger validations with no <code>LedgerSequence</code> field. Previous versions of <code>rippled</code> incorrectly assumed that the optional validation field would always be included. Current versions of the software always include the field, and gracefully handle its absence.</li>
</ul>
<h2><aclass="anchor"id="autotoc_md422"></a>
<h2><aclass="anchor"id="autotoc_md423"></a>
Version 0.31.0</h2>
<p><code>rippled</code> 0.31.0 has been released.</p>
<p>You can <ahref="https://ripple.com/build/rippled-setup/#updating-rippled">update to the new version</a> on Red Hat Enterprise Linux 7 or CentOS 7 using yum.</p>
@@ -1332,7 +1332,7 @@ Version 0.31.0</h2>
<li>Improve error message when signing fails (RIPD-1066)</li>
<li>Fix websocket deadlock</li>
</ul>
<h2><aclass="anchor"id="autotoc_md423"></a>
<h2><aclass="anchor"id="autotoc_md424"></a>
Version 0.30.1</h2>
<p>rippled 0.30.1 has been released. The commit can be found on GitHub at: <ahref="https://github.com/ripple/rippled/tree/0.30.1">https://github.com/ripple/rippled/tree/0.30.1</a></p>
<p>Prior to building, please confirm you have the correct source tree with the <b>git log</b> command. The first log entry should be the change setting the version: </p><preclass="fragment"> commit c717006c44126aa0edb3a36ca29ee30e7a72c1d3
<p>rippled 0.30.0 has been released. The commit can be found on GitHub at: <ahref="https://github.com/ripple/rippled/tree/0.30.0">https://github.com/ripple/rippled/tree/0.30.0</a></p>
<p>Prior to building, please confirm you have the correct source tree with the <b>git log</b> command. The first log entry should be the change setting the version: </p><preclass="fragment"> commit a8859b495b552fe1eb140771f0f2cb32d11d2ac2
<p>rippled 0.29.0 has been released. The commit can be found on GitHub at: <ahref="https://github.com/ripple/rippled/commits/0.29.0">https://github.com/ripple/rippled/commits/0.29.0</a></p>
<p>Prior to building, please confirm you have the correct source tree with the <b>git log</b> command. The first log entry should be the change setting the version: </p><preclass="fragment"> commit 5964710f736e258c7892e8b848c48952a4c7856c
<p>rippled 0.28.2 has been released. The commit can be found on GitHub at: <ahref="https://github.com/ripple/rippled/commits/release">https://github.com/ripple/rippled/commits/release</a></p>
<p>Prior to building, please confirm you have the correct source tree with the <b>git log</b> command. The first log entry should be the change setting the version: </p><preclass="fragment"> commit 6374aad9bc94595e051a04e23580617bc1aaf300
<p>rippled 0.28.1 has been released. The commit can be found on GitHub at: <ahref="https://github.com/ripple/rippled/tree/0.28.1">https://github.com/ripple/rippled/tree/0.28.1</a></p>
<p>Prior to building, please confirm you have the correct source tree with the <b>git log</b> command. The first log entry should be the change setting the version: </p><preclass="fragment"> commit 399c43cae6e90a428e9ce6a988123972b0f03c99
<p>rippled 0.28.0 has been released. The commit can be found on GitHub at: <ahref="https://github.com/ripple/rippled/tree/0.28.0">https://github.com/ripple/rippled/tree/0.28.0</a></p>
<p>Prior to building, please confirm you have the correct source tree with the <b>git log</b> command. The first log entry should be the change setting the version: </p><preclass="fragment"> commit 7efd0ab0d6ef017331a0e214a3053893c88f38a9
<p>rippled 0.27.4 has been released. The commit can be found on GitHub at: <ahref="https://github.com/ripple/rippled/tree/0.27.4">https://github.com/ripple/rippled/tree/0.27.4</a></p>
<p>Prior to building, please confirm you have the correct source tree with the <b>git log</b> command. The first log entry should be the change setting the version: </p><preclass="fragment"> commit 92812fe7239ffa3ba91649b2ece1e892b866ec2a
<p>rippled 0.27.3-sp2 has been released. The commit can be found on GitHub at: <ahref="https://github.com/ripple/rippled/tree/0.27.3-sp2">https://github.com/ripple/rippled/tree/0.27.3-sp2</a></p>
<p>Prior to building, please confirm you have the correct source tree with the <b>git log</b> command. The first log entry should be the change setting the version: </p><preclass="fragment"> commit f999839e599e131ed624330ad0ce85bb995f02d3
<p>rippled 0.27.3-sp1 has been released. The commit can be found on GitHub at: <ahref="https://github.com/ripple/rippled/tree/0.27.3-sp1">https://github.com/ripple/rippled/tree/0.27.3-sp1</a></p>
<p>Prior to building, please confirm you have the correct source tree with the <b>git log</b> command. The first log entry should be the change setting the version: </p><preclass="fragment"> commit 232693419a2c9a8276a0fae991f688f6f01a3add
<p>rippled 0.27.3 has been released. The commit can be found on GitHub at: <ahref="https://github.com/ripple/rippled/tree/0.27.3">https://github.com/ripple/rippled/tree/0.27.3</a></p>
<p>Prior to building, please confirm you have the correct source tree with the <b>git log</b> command. The first log entry should be the change setting the version: </p><preclass="fragment"> commit 70c2854f7c8a28801a7ebc81dd62bf0d068188f0
<p>rippled 0.27.2 has been released. The commit can be found on GitHub at: <ahref="https://github.com/ripple/rippled/tree/0.27.2">https://github.com/ripple/rippled/tree/0.27.2</a></p>
<p>Prior to building, please confirm you have the correct source tree with the <b>git log</b> command. The first log entry should be the change setting the version: </p><preclass="fragment"> commit 9cc8eec773e8afc9c12a6aab4982deda80495cf1
<p>rippled 0.27.1 has been released. The commit can be found on GitHub at: <ahref="https://github.com/ripple/rippled/tree/0.27.1">https://github.com/ripple/rippled/tree/0.27.1</a></p>
<p>Prior to building, please confirm you have the correct source tree with the <b>git log</b> command. The first log entry should be the change setting the version: </p><preclass="fragment"> commit 95973ba3e8b0bd28eeaa034da8b806faaf498d8a
<p>rippled 0.27.0 has been released. The commit can be found on GitHub at: <ahref="https://github.com/ripple/rippled/tree/0.27.0">https://github.com/ripple/rippled/tree/0.27.0</a></p>
<p>Prior to building, please confirm you have the correct source tree with the <b>git log</b> command. The first log entry should be the change setting the version: </p><preclass="fragment"> commit c6c8e5d70c6fbde02cd946135a061aa77744396f
<p>rippled 0.26.4 has been released. The repository tag is <em>0.26.4</em> and can be found on GitHub at: <ahref="https://github.com/ripple/rippled/commits/0.26.4">https://github.com/ripple/rippled/commits/0.26.4</a></p>
<p>Prior to building, please confirm you have the correct source tree with the <b>git log</b> command. The first log entry should be the change setting the version: </p><preclass="fragment"> commit 05a04aa80192452475888479c84ff4b9b54e6ae7
<p>rippled 0.26.3-sp1 has been released. The repository tag is <em>0.26.3-sp1</em> and can be found on GitHub at: <ahref="https://github.com/ripple/rippled/tree/0.26.3-sp1">https://github.com/ripple/rippled/tree/0.26.3-sp1</a></p>
<p>Prior to building, please confirm you have the correct source tree with the <b>git log</b> command. The first log entry should be the change setting the version: </p><preclass="fragment"> commit 2ad6f0a65e248b4f614d38d199a9d5d02f5aaed8
<p>rippled 0.26.2 has been released. The repository tag is <em>0.26.2</em> and can be found on GitHub at: <ahref="https://github.com/ripple/rippled/tree/0.26.2">https://github.com/ripple/rippled/tree/0.26.2</a></p>
<p>Prior to building, please confirm you have the correct source tree with the <b>git log</b> command. The first log entry should be the change setting the version: </p><preclass="fragment"> commit b9454e0f0ca8dbc23844a0520d49394e10d445b1
<p>rippled v0.26.1 has been released. The repository tag is <b>0.26.1</b> and can be found on GitHub at: <ahref="https://github.com/ripple/rippled/tree/0.26.1">https://github.com/ripple/rippled/tree/0.26.1</a></p>
<p>Prior to building, please confirm you have the correct source tree with the <b>git log</b> command. The first log entry should be the change setting the version: </p><preclass="fragment"> commit 9a0e806f78300374e20070e2573755fbafdbfd03
<p>rippled v0.26.0 has been released. The repository tag is <b>0.26.0</b> and can be found on GitHub at: <ahref="https://github.com/ripple/rippled/tree/0.26.0">https://github.com/ripple/rippled/tree/0.26.0</a></p>
<p>Prior to building, please confirm you have the correct source tree with the <b>git log</b> command. The first log entry should be the change setting the version: </p><preclass="fragment"> commit 9fa5e3987260e39dba322f218d39ac228a5b361b
<p>rippled v0.25.2 has been released. The repository tag is <b>0.25.2</b> and can be found on GitHub at: <ahref="https://github.com/ripple/rippled/tree/0.25.2">https://github.com/ripple/rippled/tree/0.25.2</a></p>
<p>Prior to building, please confirm you have the correct source tree with the <b>git log</b> command. The first log entry should be the change setting the version: </p><preclass="fragment"> commit ddf68d464d74e1c76a0cfd100a08bc8e65b91fec
@@ -2250,7 +2250,7 @@ Version 0.25.2</h2>
<li>Transactions with unreasonably long path lengths are rejected. The maximum is now eight (8) hops.</li>
</ul>
<hr/>
<h2><aclass="anchor"id="autotoc_md461"></a>
<h2><aclass="anchor"id="autotoc_md462"></a>
Version 0.25.1</h2>
<p><code>rippled</code> v0.25.1 has been released. The repository tag is <code>0.25.1</code> and can be found on GitHub at: <ahref="https://github.com/ripple/rippled/tree/0.25.1">https://github.com/ripple/rippled/tree/0.25.1</a></p>
<p>Prior to building, please confirm you have the correct source tree with the <code>git log</code> command. The first log entry should be the change setting the version: </p><preclass="fragment"> commit b677cacb8ce0d4ef21f8c60112af1db51dce5bb4
@@ -2286,7 +2286,7 @@ Version 0.25.1</h2>
<li>Reduced number of asynchronous fetches.</li>
</ul>
<hr/>
<h2><aclass="anchor"id="autotoc_md463"></a>
<h2><aclass="anchor"id="autotoc_md464"></a>
Version 0.25.0</h2>
<p>rippled version 0.25.0 has been released. The repository tag is <b>0.25.0</b> and can be found on GitHub at: <ahref="https://github.com/ripple/rippled/tree/0.25.0">https://github.com/ripple/rippled/tree/0.25.0</a></p>
<p>Prior to building, please confirm you have the correct source tree with the <b>git log</b> command. The first log entry should be the change setting the version: </p><preclass="fragment"> commit 29d1d5f06261a93c5e94b4011c7675ff42443b7f
@@ -2320,7 +2320,7 @@ Version 0.25.0</h2>
<li>Reduced number of asynchronous fetches.</li>
</ul>
<hr/>
<h2><aclass="anchor"id="autotoc_md465"></a>
<h2><aclass="anchor"id="autotoc_md466"></a>
Version 0.24.0</h2>
<p>rippled version 0.24.0 has been released. The repository tag is <b>0.24.0</b> and can be found on GitHub at: <ahref="https://github.com/ripple/rippled/tree/0.24.0">https://github.com/ripple/rippled/tree/0.24.0</a></p>
<p>Prior to building, please confirm you have the correct source tree with the <b>git log</b> command. The first log entry should be the change setting the version: </p><preclass="fragment"> commit 3eb1c7bd6f93e5d874192197f76571184338f702
@@ -2349,7 +2349,7 @@ Version 0.24.0</h2>
<li>Build process enforces minimum versions of OpenSSL and BOOST for operation.</li>
</ul>
<hr/>
<h2><aclass="anchor"id="autotoc_md467"></a>
<h2><aclass="anchor"id="autotoc_md468"></a>
Version 0.23.0</h2>
<p>rippled version 0.23.0 has been released. The repository tag is <b>0.23.0</b> and can be found on GitHub at: <ahref="https://github.com/ripple/rippled/tree/0.23.0">https://github.com/ripple/rippled/tree/0.23.0</a></p>
<p>Prior to building, please confirm you have the correct source tree with the <b>git log</b> command. The first log entry should be the change setting the version: </p><preclass="fragment"> commit 29a4f61551236f70865d46d6653da2e62de1c701
@@ -2389,7 +2389,7 @@ Version 0.23.0</h2>
<li>Fix typos in transaction engine error code identifiers</li>
</ul>
<hr/>
<h2><aclass="anchor"id="autotoc_md469"></a>
<h2><aclass="anchor"id="autotoc_md470"></a>
Version 0.22.0</h2>
<p>rippled version 0.22.0 has been released. This release is currently the tip of the <b>develop/</b> branch and can be found on GitHub at: <ahref="https://github.com/ripple/rippled/tree/develop">https://github.com/ripple/rippled/tree/develop</a> The tag is <b>0.22.0</b> and can be found on GitHub at: <ahref="https://github.com/ripple/rippled/tree/0.22.0">https://github.com/ripple/rippled/tree/0.22.0</a></p>
<p><b>This is a critical release affecting transaction processing. All partners should update immediately.</b></p>
@@ -2446,7 +2446,7 @@ Version 0.22.0</h2>
<li>Optimized transaction node lookup circumstances in the node store.</li>
</ul>
<hr/>
<h2><aclass="anchor"id="autotoc_md471"></a>
<h2><aclass="anchor"id="autotoc_md472"></a>
Version 0.21.0</h2>
<p>rippled version 0.21.0 has been released. This release is currently the tip of the <b>develop/</b> branch and can be found on GitHub at <ahref="https://github.com/ripple/rippled/tree/develop">1</a>. The tag is <b>0.21.0-rc2</b> and can be found on GitHub at <ahref="https://github.com/ripple/rippled/tree/0.21.0-rc2">2</a>.</p>
<p><b>This is a critical release. All partners should update immediately.</b></p>
<li><b>Note</b>: HyperLevelDB and RocksDB are not available on Windows platform.</li>
</ul>
<hr/>
<h2><aclass="anchor"id="autotoc_md473"></a>
<h2><aclass="anchor"id="autotoc_md474"></a>
Version 0.20.1</h2>
<p>rippled version 0.20.1 has been released. This release is currently the tip of the <ahref="https://github.com/ripple/rippled/tree/develop">develop</a> branch and the tag is <ahref="https://github.com/ripple/rippled/tree/0.20.1">0.20.1</a>.</p>
<p><b>This is a critical release. All partners should update immediately.</b></p>
@@ -2637,7 +2637,7 @@ file_size_mult=2
<li><b>Note</b>: HyperLevelDB and RocksDB are not available on Windows platform.</li>
</ul>
<hr/>
<h2><aclass="anchor"id="autotoc_md475"></a>
<h2><aclass="anchor"id="autotoc_md476"></a>
Version 0.19</h2>
<p>rippled version 0.19 has now been released. This release is currently the tip of the <ahref="https://github.com/ripple/rippled/tree/release">release</a> branch and the tag is <ahref="https://github.com/ripple/rippled/tree/0.19.0">0.19.0</a>.</p>
<p>Prior to building, please confirm you have the correct source tree with the <code>git log</code> command. The first log entry should be the change setting the version: </p><preclass="fragment">commit 26783607157a8b96e6e754f71565f4eb0134efc1
@@ -2690,7 +2690,7 @@ file_size_mult=2
<li><b>Note:</b> HyperLevelDB and RocksDB are not available on Windows platform.</li>
</ul>
<hr/>
<h2><aclass="anchor"id="autotoc_md477"></a>
<h2><aclass="anchor"id="autotoc_md478"></a>
Version 0.16</h2>
<p>rippled version 0.16 has now been released. This release is currently the tip of the <ahref="https://github.com/ripple/rippled/tree/master">master</a> branch and the tag is <ahref="https://github.com/ripple/rippled/tree/v0.16.0">v0.16.0</a>.</p>
<p>Prior to building, please confirm you have the correct source tree with the <code>git log</code> command. The first log entry should be the change setting the version: </p><preclass="fragment">commit 15ef43505473225af21bb7b575fb0b628d5e7f73
@@ -2738,7 +2738,7 @@ path=db/hashnode
<p><b>Issues</b></p>
<p>None known</p>
<hr/>
<h2><aclass="anchor"id="autotoc_md479"></a>
<h2><aclass="anchor"id="autotoc_md480"></a>
Version 0.14</h2>
<p>rippled version 0.14 has now been released. This release is currently the tip of the <ahref="https://github.com/ripple/rippled/tree/master">master</a> branch and the tag is <ahref="https://github.com/ripple/rippled/tree/v0.14.0">v0.12.0</a>.</p>
<p>Prior to building, please confirm you have the correct source tree with the <code>git log</code> command. The first log entry should be the change setting the version: </p><preclass="fragment">commit b6d11c08d0245ee9bafbb97143f5d685dd2979fc
@@ -2786,7 +2786,7 @@ path=db/hashnode
<p><b>Issues</b></p>
<p>None known</p>
<hr/>
<h2><aclass="anchor"id="autotoc_md481"></a>
<h2><aclass="anchor"id="autotoc_md482"></a>
Version 0.12</h2>
<p>rippled version 0.12 has now been released. This release is currently the tip of the <ahref="https://github.com/ripple/rippled/tree/master">master branch</a> and can be found on GitHub. The tag is <ahref="https://github.com/ripple/rippled/tree/v0.12.0">v0.12.0</a>.</p>
<p>Prior to building, please confirm you have the correct source tree with the <code>git log</code> command. The first log entry should be the change setting the version: </p><preclass="fragment">commit d0a9da6f16f4083993e4b6c5728777ffebf80f3a
<divclass="textblock"><p>Classes and functions for handling data and values associated with the Ripple protocol.</p>
<divclass="textblock"><p>Classes and functions for handling data and values associated with the XRP Ledger protocol.</p>
<h1><aclass="anchor"id="autotoc_md260"></a>
Serialized Objects</h1>
<p>In ripple objects transmitted over the network must be serialized into a canonical format. The prefix "ST" refers to classes that deal with the serialized format of ripple objects.</p>
<p>Objects transmitted over the network must be serialized into a canonical format. The prefix "ST" refers to classes that deal with the serialized format.</p>
<p>The term "Tx" or "tx" is an abbreviation for "Transaction", a commonly occurring object type.</p>
<h2><aclass="anchor"id="autotoc_md261"></a>
Optional Fields</h2>
@@ -83,7 +83,13 @@ Optional Fields</h2>
</li>
</ul>
<p>Typically, for things that are guaranteed to exist, you use <code>x[sfFoo]</code> and avoid having to deal with a container that may or may not hold a value. For things not guaranteed to exist, you use <code>x[~sfFoo]</code> because you want such a container. It avoids having to look something up twice, once just to see if it exists and a second time to get/set its value. (<ahref="https://github.com/ripple/rippled/blob/35f4698aed5dce02f771b34cfbb690495cb5efcc/src/ripple/app/tx/impl/PayChan.cpp#L229-L236">Real example</a>)</p>
<p>The source of this "type magic" is in <ahref="./SField.h#L296-L302">SField.h</a>.</p>
<p>The source of this "type magic" is in <ahref="./SField.h#L296-L302">SField.h</a>.</p>
<li>Provide an interface to share load information in a cluster.</li>
<li>Warn and/or disconnect endpoints for imposing load.</li>
</ul>
<h1><aclass="anchor"id="autotoc_md264"></a>
<h1><aclass="anchor"id="autotoc_md265"></a>
Description</h1>
<p>To prevent monopolization of server resources or attacks on servers, resource consumption is monitored at each endpoint. When consumption exceeds certain thresholds, costs are imposed. Costs could include charging additional XRP for transactions, requiring a proof of work to be performed, or simply disconnecting the endpoint.</p>
<p>Currently, consumption endpoints include websocket connections used to service clients, and peer connections used to create the peer to peer overlay network implementing the Ripple protocol.</p>
<p>The current "balance" of a Consumer represents resource consumption debt or credit. Debt is accrued when bad loads are imposed. Credit is granted when good loads are imposed. When the balance crosses heuristic thresholds, costs are increased on the endpoint. The balance is represented as a unitless relative quantity. This balance is currently held by the Entry struct in the <aclass="el"href="Entry_8h_source.html">impl/Entry.h</a> file.</p>
<p>Costs associated with specific transactions are defined in the impl/Fees files.</p>
<p>Although RPC connections consume resources, they are transient and cannot be rate limited. It is advised not to expose RPC interfaces to the general public.</p>
<h1><aclass="anchor"id="autotoc_md265"></a>
<h1><aclass="anchor"id="autotoc_md266"></a>
Consumer Types</h1>
<p>Consumers are placed into three classifications (as identified by the Resource::Kind enumeration):</p>
<ul>
@@ -88,15 +88,15 @@ Consumer Types</h1>
<li>Admin</li>
</ul>
<p>Each caller determines for itself the classification of the Consumer it is creating.</p>
<h1><aclass="anchor"id="autotoc_md266"></a>
<h1><aclass="anchor"id="autotoc_md267"></a>
Resource Loading</h1>
<p>It is expected that a client will impose a higher load on the server when it first connects: the client may need to catch up on transactions it has missed, or get trust lines, or transfer fees. The Manager must expect this initial peak load, but not allow that high load to continue because over the long term that would unduly stress the server.</p>
<p>If a client places a sustained high load on the server, that client is initially given a warning message. If that high load continues the Manager may tell the heavily loaded server to drop the connection entirely and not allow re-connection for some amount of time.</p>
<p>Each load is monitored by capturing peaks and then decaying those peak values over time: this is implemented by the DecayingSample class.</p>
<h1><aclass="anchor"id="autotoc_md267"></a>
<h1><aclass="anchor"id="autotoc_md268"></a>
Gossip</h1>
<p>Each server in a cluster creates a list of IP addresses of end points that are imposing a significant load. This list is called Gossip, which is passed to other nodes in that cluster. Gossip helps individual servers in the cluster identify IP addreses that might be unduly loading the entire cluster. Again the recourse of the individual servers is to drop connections to those IP addresses that occur commonly in the gossip.</p>
<h1><aclass="anchor"id="autotoc_md268"></a>
<h1><aclass="anchor"id="autotoc_md269"></a>
Access</h1>
<p>In rippled, the Application holds a unique instance of Resource::Manager, which may be retrieved by calling the method <code>Application::getResourceManager()</code>. </p>
<p>By default, an RPC handler runs as an uninterrupted task on the JobQueue. This is fine for commands that are fast to compute but might not be acceptable for tasks that require multiple parts or are large, like a full ledger.</p>
<p>For this purpose, the rippled RPC handler allows <em>suspension with continuation</em></p><ul>
<li>a request to suspend execution of the RPC response and to continue it after some function or job has been executed. A default continuation is supplied which simply reschedules the job on the JobQueue, or the programmer can supply their own.</li>
</ul>
<h1><aclass="anchor"id="autotoc_md271"></a>
<h1><aclass="anchor"id="autotoc_md272"></a>
The classes.</h1>
<p>Suspension with continuation uses four <code><aclass="elRef"href="http://en.cppreference.com/w/cpp/utility/functional/function.html">std::function</a></code>s in the <code><aclass="el"href="namespaceripple_1_1RPC.html">ripple::RPC</a></code> namespace: </p><preclass="fragment">using Callback = std::function <void ()>;
using Continuation = std::function <void (Callback const&)>;
<p>A <code>Continuation</code> is a function that is given a <code>Callback</code> and promises to call it later. A <code>Continuation</code> guarantees to call the <code>Callback</code> exactly once at some point in the future, but it does not have to be immediately or even in the current thread.</p>
<p>A <code>Suspend</code> is a function belonging to a <code>Coroutine</code>. A <code>Suspend</code> runs a <code>Continuation</code>, passing it a <code>Callback</code> that continues execution of the <code>Coroutine</code>.</p>
<p>And finally, a <code>Coroutine</code> is a <code><aclass="elRef"href="http://en.cppreference.com/w/cpp/utility/functional/function.html">std::function</a></code> which is given a <code>Suspend</code>. This is what the RPC handler gives to the coroutine manager, expecting to get called back with a <code>Suspend</code> and to be able to start execution.</p>
<h1><aclass="anchor"id="autotoc_md272"></a>
<h1><aclass="anchor"id="autotoc_md273"></a>
The flow of control.</h1>
<p>Given these functions, the flow of RPC control when using coroutines is straight-forward.</p>
<p>Copies are made with the <code>snapShot</code> function as opposed to the <code>SHAMap</code> copy constructor. See the section on <code>SHAMap</code> creation for more details about <code>snapShot</code>.</p>
<p>Sequence numbers are used to further customize the node ownership strategy. See the section on sequence numbers for details on sequence numbers.</p>
<p>There are two different ways of building and using a <code>SHAMap</code>:</p>
<oltype="1">
@@ -102,7 +102,7 @@ Mutability</h1>
<p>Most <code>SHAMap</code>s are immutable, in the sense that they don't modify or remove their contained nodes.</p>
<p>An example where a mutable <code>SHAMap</code> is required is when we want to apply transactions to the last closed ledger. To do so we'd make a mutable snapshot of the state trie and then start applying transactions to it. Because the snapshot is mutable, changes to nodes in the snapshot will not affect nodes in other <code>SHAMap</code>s.</p>
<p>An example using a immutable ledger would be when there's an open ledger and some piece of code wishes to query the state of the ledger. In this case we don't wish to change the state of the <code>SHAMap</code>, so we'd use an immutable snapshot.</p>
<h1><aclass="anchor"id="autotoc_md275"></a>
<h1><aclass="anchor"id="autotoc_md276"></a>
Sequence numbers</h1>
<p>Both <code>SHAMap</code>s and their nodes carry a sequence number. This is simply an unsigned number that indicates ownership or membership, or a non-membership.</p>
<p><code>SHAMap</code>s sequence numbers normally start out as 1. However when a snap-shot of a <code>SHAMap</code> is made, the copy's sequence number is 1 greater than the original.</p>
@@ -110,19 +110,19 @@ Sequence numbers</h1>
<p>When a <code>SHAMap</code> needs to have a private copy of a node, not shared by any other <code>SHAMap</code>, it first clones it and then sets the new copy to have a sequence number equal to the <code>SHAMap</code> sequence number. The <code>unshareNode</code> is a private utility which automates the task of first checking if the node is already sharable, and if so, cloning it and giving it the proper sequence number. An example case where a private copy is needed is when an inner node needs to have a child pointer altered. Any modification to a node will require a non-shared node.</p>
<p>When a <code>SHAMap</code> decides that it is safe to share a node of its own, it sets the node's sequence number to 0 (a <code>SHAMap</code> never has a sequence number of 0). This is done for every node in the trie when <code>SHAMap::walkSubTree</code> is executed.</p>
<p>Note that other objects in rippled also have sequence numbers (e.g. ledgers). The <code>SHAMap</code> and node sequence numbers should not be confused with these other sequence numbers (no relation).</p>
<h1><aclass="anchor"id="autotoc_md276"></a>
<h1><aclass="anchor"id="autotoc_md277"></a>
SHAMap Creation</h1>
<p>A <code>SHAMap</code> is usually not created from vacuum. Once an initial <code>SHAMap</code> is constructed, later <code>SHAMap</code>s are usually created by calling snapShot(bool isMutable) on the original <code>SHAMap</code>. The returned <code>SHAMap</code> has the expected characteristics (mutable or immutable) based on the passed in flag.</p>
<p>It is cheaper to make an immutable snapshot of a <code>SHAMap</code> than to make a mutable snapshot. If the <code>SHAMap</code> snapshot is mutable then sharable nodes must be copied before they are placed in the mutable map.</p>
<p>A new <code>SHAMap</code> is created with each new ledger round. Transactions not executed in the previous ledger populate the <code>SHAMap</code> for the new ledger.</p>
<h1><aclass="anchor"id="autotoc_md277"></a>
<h1><aclass="anchor"id="autotoc_md278"></a>
Storing SHAMap data in the database</h1>
<p>When consensus is reached, the ledger is closed. As part of this process, the <code>SHAMap</code> is stored to the database by calling <code>SHAMap::flushDirty</code>.</p>
<p>Both <code>unshare()</code> and <code>flushDirty</code> walk the <code>SHAMap</code> by calling <code>SHAMap::walkSubTree</code>. As <code>unshare()</code> walks the trie, nodes are not written to the database, and as <code>flushDirty</code> walks the trie nodes are written to the database. <code>walkSubTree</code> visits every node in the trie. This process must ensure that each node is only owned by this trie, and so "unshares" as it walks each node (from the root down). This is done in the <code>preFlushNode</code> function by ensuring that the node has a sequence number equal to that of the <code>SHAMap</code>. If the node doesn't, it is cloned.</p>
<p>For each inner node encountered (starting with the root node), each of the children are inspected (from 1 to 16). For each child, if it has a non-zero sequence number (unshareable), the child is first copied. Then if the child is an inner node, we recurse down to that node's children. Otherwise we've found a leaf node and that node is written to the database. A count of each leaf node that is visited is kept. The hash of the data in the leaf node is computed at this time, and the child is reassigned back into the parent inner node just in case the COW operation created a new pointer to this leaf node.</p>
<p>After processing each node, the node is then marked as sharable again by setting its sequence number to 0.</p>
<p>After all of an inner node's children are processed, then its hash is updated and the inner node is written to the database. Then this inner node is assigned back into it's parent node, again in case the COW operation created a new pointer to it.</p>
<h1><aclass="anchor"id="autotoc_md278"></a>
<h1><aclass="anchor"id="autotoc_md279"></a>
Walking a SHAMap</h1>
<p>The private function <code>SHAMap::walkTowardsKey</code> is a good example of <em>how</em> to walk a <code>SHAMap</code>, and the various functions that call <code>walkTowardsKey</code> are good examples of <em>why</em> one would want to walk a <code>SHAMap</code> (e.g. <code>SHAMap::findKey</code>). <code>walkTowardsKey</code> always starts at the root of the <code>SHAMap</code> and traverses down through the inner nodes, looking for a leaf node along a path in the trie designated by a <code>uint256</code>.</p>
<p>As one walks the trie, one can <em>optionally</em> keep a stack of nodes that one has passed through. This isn't necessary for walking the trie, but many clients will use the stack after finding the desired node. For example if one is deleting a node from the trie, the stack is handy for repairing invariants in the trie after the deletion.</p>
@@ -140,7 +140,7 @@ Walking a SHAMap</h1>
<li>In the database.</li>
</ol>
<p>If the node is not found in the trie, then it is installed into the trie as part of the traversal process.</p>
<h1><aclass="anchor"id="autotoc_md279"></a>
<h1><aclass="anchor"id="autotoc_md280"></a>
Late-arriving Nodes</h1>
<p>As we noted earlier, <code>SHAMap</code>s (even immutable ones) may grow. If a <code>SHAMap</code> is searching for a node and runs into an empty spot in the trie, then the <code>SHAMap</code> looks to see if the node exists but has not yet been made part of the map. This operation is performed in the <code>SHAMap::fetchNodeNT()</code> method. The <em>NT</em> is this case stands for 'No Throw'.</p>
<p>The <code>fetchNodeNT()</code> method goes through three phases:</p>
@@ -151,29 +151,29 @@ Late-arriving Nodes</h1>
<li>If the node is not in the TreeNodeCache, we attempt to locate the node in the historic data stored by the data base. The call to to <code>fetchNodeFromDB(hash)</code> does that work for us.</li>
<li>Finally if a filter exists, we check if it can supply the node. This is typically the LedgerMaster which tracks the current ledger and ledgers in the process of closing.</li>
</ol>
<h1><aclass="anchor"id="autotoc_md280"></a>
<h1><aclass="anchor"id="autotoc_md281"></a>
Canonicalize</h1>
<p><code>canonicalize()</code> is called every time a node is introduced into the <code>SHAMap</code>.</p>
<p>A call to <code>canonicalize()</code> stores the node in the <code>TreeNodeCache</code> if it does not already exist in the <code>TreeNodeCache</code>.</p>
<p>The calls to <code>canonicalize()</code> make sure that if the resulting node is already in the <code>SHAMap</code>, node <code>TreeNodeCache</code> or database, then we don't create duplicates by favoring the copy already in the <code>TreeNodeCache</code>.</p>
<p>By using <code>canonicalize()</code> we manage a thread race condition where two different threads might both recognize the lack of a SHAMapLeafNode at the same time (during a fetch). If they both attempt to insert the node into the <code>SHAMap</code>, then <code>canonicalize</code> makes sure that the first node in wins and the slower thread receives back a pointer to the node inserted by the faster thread. Recall that these two <code>SHAMap</code>s will share the same <code>TreeNodeCache</code>.</p>
<h1><aclass="anchor"id="autotoc_md281"></a>
<h1><aclass="anchor"id="autotoc_md282"></a>
<tt>TreeNodeCache</tt></h1>
<p>The <code>TreeNodeCache</code> is a <code><aclass="elRef"href="http://en.cppreference.com/w/cpp/container/unordered_map.html"title="STL class.">std::unordered_map</a></code> keyed on the hash of the <code>SHAMap</code> node. The stored type consists of <code>shared_ptr<SHAMapTreeNode></code>, <code>weak_ptr<SHAMapTreeNode></code>, and a time point indicating the most recent access of this node in the cache. The time point is based on <code><aclass="elRef"href="http://en.cppreference.com/w/cpp/chrono/steady_clock.html">std::chrono::steady_clock</a></code>.</p>
<p>The container uses a cryptographically secure hash that is randomly seeded.</p>
<p>The <code>TreeNodeCache</code> also carries with it various data used for statistics and logging, and a target age for the contained nodes. When the target age for a node is exceeded, and there are no more references to the node, the node is removed from the <code>TreeNodeCache</code>.</p>
<h1><aclass="anchor"id="autotoc_md282"></a>
<h1><aclass="anchor"id="autotoc_md283"></a>
<tt>FullBelowCache</tt></h1>
<p>This cache remembers which trie keys have all of their children resident in a <code>SHAMap</code>. This optimizes the process of acquiring a complete trie. This is used when creating the missing nodes list. Missing nodes are those nodes that a <code>SHAMap</code> refers to but that are not stored in the local database.</p>
<p>As a depth-first walk of a <code>SHAMap</code> is performed, if an inner node answers true to <code>isFullBelow()</code> then it is known that none of this node's children are missing nodes, and thus that subtree does not need to be walked. These nodes are stored in the FullBelowCache. Subsequent walks check the FullBelowCache first when encountering a node, and ignore that subtree if found.</p>
<h1><aclass="anchor"id="autotoc_md283"></a>
<h1><aclass="anchor"id="autotoc_md284"></a>
<tt>SHAMapTreeNode</tt></h1>
<p>This is an abstract base class for the concrete node types. It holds the following common data:</p>
<oltype="1">
<li>A hash</li>
<li>An identifier used to perform copy-on-write operations</li>
</ol>
<h2><aclass="anchor"id="autotoc_md284"></a>
<h2><aclass="anchor"id="autotoc_md285"></a>
<tt>SHAMapInnerNode</tt></h2>
<p><code>SHAMapInnerNode</code> publicly inherits directly from <code>SHAMapTreeNode</code>. It holds the following data:</p>
<oltype="1">
@@ -182,22 +182,22 @@ Canonicalize</h1>
<li>A bitset to indicate which of the 16 children exist.</li>
<li>An identifier used to determine whether the map below this node is fully populated</li>
</ol>
<h2><aclass="anchor"id="autotoc_md285"></a>
<h2><aclass="anchor"id="autotoc_md286"></a>
<tt>SHAMapLeafNode</tt></h2>
<p><code>SHAMapLeafNode</code> is an abstract class which publicly inherits directly from <code>SHAMapTreeNode</code>. It isIt holds the following data:</p>
<p><code>SHAMapAccountStateLeafNode</code> is a class which publicly inherits directly from <code>SHAMapLeafNode</code>. It is used to represent entries (i.e. account objects, escrow objects, trust lines, etc.) in a state map.</p>
<h3><aclass="anchor"id="autotoc_md287"></a>
<h3><aclass="anchor"id="autotoc_md288"></a>
<tt>SHAMapTxLeafNode</tt></h3>
<p><code>SHAMapTxLeafNode</code> is a class which publicly inherits directly from <code>SHAMapLeafNode</code>. It is used to represent transactions in a state map.</p>
<p><code>SHAMapTxPlusMetaLeafNode</code> is a class which publicly inherits directly from <code>SHAMapLeafNode</code>. It is used to represent transactions along with metadata associated with this transaction in a state map.</p>
<p>Unit tests are bundled in the <code>rippled</code> executable and can be executed using the <code>--unittest</code> parameter. Without any arguments to this option, all non-manual unit tests will be executed. If you want to run one or more manual tests, you must specify it by suite or full-name (e.g. <code>ripple.app.NoRippleCheckLimits</code> or just <code>NoRippleCheckLimits</code>).</p>
<p>More than one suite or group of suites can be specified as a comma separated list via the argument. For example, <code>--unittest=beast,OversizeMeta</code> will run all suites in the <code>beast</code> library (root identifier) as well as the test suite named <code>OversizeMeta</code>). All name matches are case sensitive.</p>
<divclass="textblock"><p>The Consensus Simulation Framework is a set of software components for describing, running and analyzing simulations of the consensus algorithm in a controlled manner. It is also used to unit test the generic Ripple consensus algorithm implementation. The framework is in its early stages, so the design and supported features are subject to change.</p>
<h1><aclass="anchor"id="autotoc_md291"></a>
<h1><aclass="anchor"id="autotoc_md292"></a>
Overview</h1>
<p>The simulation framework focuses on simulating the core consensus and validation algorithms as a <ahref="https://en.wikipedia.org/wiki/Discrete_event_simulation">discrete event simulation</a>. It is completely abstracted from the details of the XRP ledger and transactions. In the simulation, a ledger is simply a set of observed integers and transactions are single integers. The consensus process works to agree on the set of integers to include in the next ledger.</p>
<divclass="image">
@@ -82,7 +82,7 @@ CSF Overview</div></div>
<li><code>Collector</code>s that aggregate, filter and analyze data from the simulation. Typically, this is used to monitor invariants or generate reports.</li>
</ul>
<p>Once specified, the simulation runs using a single <code>Scheduler</code> that manages the global clock and sequencing of activity. During the course of simulation, <code>Peer</code>s generate <code>Ledger</code>s and <code>Validation</code>s as a result of consensus, eventually fully validating the consensus history of accepted transactions. Each <code>Peer</code> also issues various <code>Event</code>s during the simulation, which are analyzed by the registered <code>Collector</code>s.</p>
<h1><aclass="anchor"id="autotoc_md292"></a>
<h1><aclass="anchor"id="autotoc_md293"></a>
Example Simulation</h1>
<p>Below is a basic simulation we can walk through to get an understanding of the framework. This simulation is for a set of 5 validators that aren't directly connected but rely on a single hub node for communication.</p>
</div><!-- fragment --><p>The simulation code starts by creating a single instance of the <ahref="./Sim.h"><code>Sim</code> class</a>. This class is used to manage the overall simulation and internally owns most other components, including the <code>Peer</code>s, <code>Scheduler</code>, <code>BasicNetwork</code> and <code>TrustGraph</code>. The next two lines create two differ <code>PeerGroup</code>s of size 5 and 1 . A <ahref="./PeerGroup.h"><code>PeerGroup</code></a> is a convenient way for configuring a set of related peers together and internally has a vector of pointers to the <code>Peer</code>s which are owned by the <code>Sim</code>. <code>PeerGroup</code>s can be combined using <code>+/-</code> operators to configure more complex relationships of nodes as shown by <code>PeerGroup network</code>. Note that each call to <code>createGroup</code> adds that many new <code>Peer</code>s to the simulation, but does not specify any trust or network relationships for the new <code>Peer</code>s.</p>
<p>Lastly, the single <code>Peer</code> in the size 1 <code>center</code> group is switched from running as a validator (the default) to running as a tracking peer. The <ahref="./Peer.h"><code>Peer</code> class</a> has a variety of configurable parameters that control how it behaves during the simulation.</p>
<h1><aclass="anchor"id="autotoc_md294"></a>
<h1><aclass="anchor"id="autotoc_md295"></a>
<tt>trust</tt> and <tt>connect</tt></h1>
</div><!-- fragment --><p>Although the <code>sim</code> object has accessible instances of <ahref="./TrustGraph.h">TrustGraph</a> and <ahref="./BasicNetwork.h">BasicNetwork</a>, it is more convenient to manage the graphs via the <code>PeerGroup</code>s. The first two lines create a trust topology in which all <code>Peer</code>s trust the 5 validating <code>Peer</code>s. Or in the UNL perspective, all <code>Peer</code>s are configured with the same UNL listing the 5 validating <code>Peer</code>s. The two lines could've been rewritten as <code>network.trust(validators)</code>.</p>
<p>The next lines create the network communication topology. Each of the validating <code>Peer</code>s connects to the central hub <code>Peer</code> with a fixed delay of 200ms. Note that the network connections are really undirected, but are represented internally in a directed graph using edge pairs of inbound and outbound connections.</p>
<p>Note that the collector lifetime is independent of the simulation and is added to the simulation by reference. This is intentional, since collectors might be used across several simulations to collect more complex combinations of data. At the end of the simulation, we print out the total duration by subtracting <code>simDur</code> members.</p>
</div><!-- fragment --><p>In this basic example, we explicitly submit a single transaction to each validator. For larger simulations, clients can use a <ahref="./submitters.h">Submitter</a> to send transactions in at fixed or random intervals to fixed or random <code>Peer</code>s.</p>
<h1><aclass="anchor"id="autotoc_md297"></a>
<h1><aclass="anchor"id="autotoc_md298"></a>
Run</h1>
<p>The example has two calls to <code>sim.run(1)</code>. This call runs the simulation until each <code>Peer</code> has closed one additional ledger. After closing the additional ledger, the <code>Peer</code> stops participating in consensus. The first call is used to ensure a more useful prior state of all <code>Peer</code>s. After the transaction submission, the second call to <code>run</code> results in one additional ledger that accepts those transactions.</p>
<p>Alternatively, you can specify a duration to run the simulation, e.g. <code>sim.run(10s)</code> which would have <code>Peer</code>s continuously run consensus until the scheduler has elapsed 10 additional seconds. The <code>sim.scheduler.in</code> or <code>sim.scheduler.at</code> methods can schedule arbitrary code to execute at a later time in the simulation, for example removing a network connection or modifying the trust graph. </p>
Reference in New Issue
Block a user
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
intelliot