Files
rippled/src
RichardAH 4f95b9d7a6 Prevent replay attacks with NetworkID field: (#4370)
Add a `NetworkID` field to help prevent replay attacks on and from
side-chains.

The new field must be used when the server is using a network id > 1024.

To preserve legacy behavior, all chains with a network ID less than 1025
retain the existing behavior. This includes Mainnet, Testnet, Devnet,
and hooks-testnet. If `sfNetworkID` is present in any transaction
submitted to any of the nodes on one of these chains, then
`telNETWORK_ID_MAKES_TX_NON_CANONICAL` is returned.

Since chains with a network ID less than 1025, including Mainnet, retain
the existing behavior, there is no need for an amendment.

The `NetworkID` helps to prevent replay attacks because users specify a
`NetworkID` field in every transaction for that chain.

This change introduces a new UINT32 field, `sfNetworkID` ("NetworkID").
There are also three new local error codes for transaction results:

- `telNETWORK_ID_MAKES_TX_NON_CANONICAL`
- `telREQUIRES_NETWORK_ID`
- `telWRONG_NETWORK`

To learn about the other transaction result codes, see:
https://xrpl.org/transaction-results.html

Local error codes were chosen because a transaction is not necessarily
malformed if it is submitted to a node running on the incorrect chain.
This is a local error specific to that node and could be corrected by
switching to a different node or by changing the `network_id` on that
node. See:
https://xrpl.org/connect-your-rippled-to-the-xrp-test-net.html

In addition to using `NetworkID`, it is still generally recommended to
use different accounts and keys on side-chains. However, people will
undoubtedly use the same keys on multiple chains; for example, this is
common practice on other blockchain networks. There are also some
legitimate use cases for this.

A `app.NetworkID` test suite has been added, and `core.Config` was
updated to include some network_id tests.
2023-04-11 17:11:17 -07:00
..
2019-03-18 16:19:24 -07:00

rippled Source

Some of these directories come from entire outside repositories brought in using [git-subtree][]. This means that the source files are inserted directly into the rippled repository. They can be edited and committed just as if they were normal files. [git-subtree]: https://github.com/apenwarr/git-subtree

If you create a commit that contains files both from a subtree, and from the rippled source tree, please use care when designing the commit message, since it will appear in the subtree's individual repository when the changes are pushed back to the upstream. Better yet, do not mix files from subtrees and ripple in the same commit at all.

Source folders:

Folder Upstream Repo Description
beast N/A legacy utility code that was formerly associated with boost::beast
ed25519-donna https://github.com/floodyberry/ed25519-donna Ed25519 digital signatures
ripple N/A Core source code for rippled
secp256k1 https://github.com/bitcoin-core/secp256k1 ECDSA digital signatures using the secp256k1 curve
test N/A Unit tests for rippled

The following dependencies are downloaded and built using ExternalProject (or FetchContent, where possible). Refer to CMakeLists.txt file for details about how these sources are built :

Name Upstream Repo Description
lz4 https://github.com/lz4/lz4 LZ4 lossless compression algorithm
nudb https://github.com/vinniefalco/NuDB Constant-time insert-only key/value database for SSD drives (Less memory usage than RocksDB.)
snappy https://github.com/google/snappy "Snappy" lossless compression algorithm.
soci https://github.com/SOCI/soci Abstraction layer for database access.
sqlite https://www.sqlite.org/src An embedded database engine that writes to simple files.
rocksdb https://github.com/facebook/rocksdb Fast key/value database. (Supports rotational disks better than NuDB.)
protobuf https://github.com/google/protobuf Protocol buffer data interchange format. Only downloaded/built if a suitable version is not found by find_package, or if the local_protobuf option is explicitly set