Empowering Developers: rippled 2.0 Presents Exciting Upgrades
Published: 2024-01-10 20:08:00

The XRP Ledger developers are pleased to announce the release of `rippled` 2.0. This update introduces two new feature amendments: XLS-38 Cross-Chain Bridge and XLS-40 Decentralized Identity. Additionally, there are two fix amendments, as well as numerous other improvements. 

## Why is this being released now?

With the holiday season behind us and an exciting year ahead, validator and node operators have more time to learn about the 2.0 release and new amendments as they update their software and reconsider votes.

## New Feature Amendments

### [XLS-38 Cross-Chain Bridge](https://xrpl.org/cross-chain-bridges.html)
- The Cross-Chain Bridge would enable XRP and fungible tokens issued on the XRPL to move efficiently between XRPL Mainnet and [XRPL Sidechains](https://xrpl.org/xrpl-sidechains.html), as well as XRPL Mainnet and the upcoming EVM sidechain.
- The Cross-Chain Bridge is secured by independent [witness servers](https://xrpl.org/witness-servers.html) that attest to any transactions moving between chains.
- Learn more technical details in the [XLS-38 spec on GitHub](https://github.com/XRPLF/XRPL-Standards/tree/master/XLS-0038d-cross-chain-bridge#readme).

### [XLS-40 Decentralized Identity](https://xrpl.org/decentralized-identifiers.html)
- Decentralized Identity (DID) is a technology that enables users to control their online identity in a self-sovereign way. The XLS-40 DID implementation will use the World Wide Web Consortium (W3C) standard to enable verifiable, self-sovereign digital identity and will be compatible with any distributed ledger or network.
- DID on the XRPL satisfies the following principles: Decentralized, Persistent and Portable, Cryptographically Verifiable, Universally Resolvable and Interoperable. 
- XLS-40 is a lightweight amendment and adds a new ledger object. Associated transactions can create, update, and delete this object.
- Learn more about XLS-40 in the official documentation and [spec on GitHub](https://github.com/XRPLF/XRPL-Standards/tree/master/XLS-0040d-decentralized-identity#readme).

## API Updates

- Introduces API v2.
- Cleans up the API with the removal of deprecated fields and methods, renaming fields which were frequently misinterpreted, and improving consistency in responses.
- The new `server_definitions` command returns SDK-compatible binary format definitions, making it easier for client libraries to adopt support for the latest features over time.

## Core Ledger Updates

- [fixDisallowIncomingV1](https://github.com/XRPLF/rippled/pull/4721): Fixes an issue that occurs with authorized trustlines and the “lsfDisallowIncomingTrustline” flag.
- [fixFillOrKill](https://github.com/XRPLF/rippled/pull/4694) - Fixes an issue that occurs with a combination of flags under circumstances where an exchange rate on an offer differs from the orderbook rate. 

## The XRPL Amendment Voting Process

- To bring new features to the XRPL Mainnet, XLS specs that involve breaking changes to the core protocol must undergo the amendment process, in which the validator community votes on the feature.
- In blockchain protocols, a breaking change occurs when structures that were invalid under the old rules become valid under the new rules. For example, XLS-38 introduces new transactors and ledger objects. After the amendment activates, transactions and ledger objects that were previously invalid will now be valid. All nodes must update their software in order to work together after the change.
- Every server on the network independently tallies the votes of the validators it is configured to listen to, as part of the consensus process.
- For an amendment to pass:
    - At least 80% of validators must approve the amendment by setting their vote to “yes” or "accept".
    - This threshold must be maintained for at least 2 weeks.
- If both conditions are met, the amendment will activate and the feature defined in the XLS spec will become live on Mainnet. This process happens independently for each amendment.
- All members of the validator community are encouraged to review the code and documentation to make an informed decision.

### Casting a Ballot

To vote in favor of a particular amendment, the command to execute is:
```
/opt/ripple/bin/rippled feature NAME accept
```

To vote against a particular amendment, the command to execute is:
```
/opt/ripple/bin/rippled feature NAME reject
```

Replace `/opt/ripple/bin/` with the path to your `rippled` binary, and `NAME` with the name of the amendment.

The names of the amendments introduced in 2.0.0 are `DID`, `XChainBridge`, `fixDisallowIncomingV1`, and `fixFillOrKill`.