|
| 1 | +<pre> |
| 2 | + xls: 18 |
| 3 | + title: Standard For Bootstrapping XRPLD Networks |
| 4 | + description: An experimental procedure to bootstrapping XRP Ledger Network |
| 5 | + author: Richard Holland (@RichardAH) |
| 6 | + created: 2021-03-25 |
| 7 | + status: Stagnant |
| 8 | + category: Community |
| 9 | +</pre> |
| 10 | + |
| 11 | +This procedure is experimental and additions amendments or recommendations based on experience to this standard draft are welcome. |
| 12 | + |
| 13 | +### Problem Definition |
| 14 | +`Xrpld` / `rippled`[[1]](https://github.com/ripple/rippled) is the software that processes, achieves consensus upon and serves the decentralised public XRP Ledger, as well as numerous other public and private ledgers. |
| 15 | + |
| 16 | +From time to time a decentralised network may stall, fork, or otherwise fail to achieve consensus because of a bug, network instability, unreliable nodes or operators, a deliberate attack, or any combination of these. In this event the bootstrapping procedure to return the network to normal operation is important and should be followed correctly to avoid (further) forks and halts. |
| 17 | + |
| 18 | +### Terminology |
| 19 | +`Validator` refers to a rippled instance configured to publish validations of ledgers. |
| 20 | +`UNL` refers to a list of validator public keys that the network has collectively agreed are allowed to validate ledgers. |
| 21 | +`Node` refers to a validator currently listed in the network's `UNL`. |
| 22 | + |
| 23 | + |
| 24 | +### Procedure — Cold Start |
| 25 | +Cold start describes a situation in which *none* of the validators in a network are currently running. This situation can arise because they crashed, were terminated automatically or were terminated manually (or any combination of these.) |
| 26 | + |
| 27 | +1. Select a node from your UNL to be the `leader`. The remaining nodes will be referred to as `followers`. |
| 28 | +2. On the `leader` run rippled from your terminal in the foreground with the following flags: |
| 29 | + `./rippled --valid --quorum 1 --load` |
| 30 | +3. On each follower run rippled from your terminal in the foreground with the following flags: |
| 31 | + `./rippled --net --quorum 1` |
| 32 | +4. In a seperate terminal, on each of the `followers` and on the `leader` you may monitor whether or not ledgers are closing correctly using: |
| 33 | + `./rippled ledger closed` |
| 34 | + In particular ensure the ledger index is incrementing and the ledgers are validated. |
| 35 | +5. On the `leader` terminate the foreground rippled process. (Ctrl + C) |
| 36 | +6. On the `leader` run rippled normally as a daemon. |
| 37 | +7. On the `leader` in the second terminal continue to monitor the last closed ledger until validation is consistently achieved, as per 4. |
| 38 | +8. Select one `follower` node. |
| 39 | +9. Terminate the foreground process on the selected `follower` and start rippled normally. |
| 40 | +10. Monitor for LCL validation as per 4. |
| 41 | +11. Repeat from step 8 until all nodes are running normally. |
| 42 | + |
| 43 | +### Troubleshooting |
| 44 | +Small networks may require the `quorum` size to be permanently overridden for network stability. To do this modify the control script that runs rippled to include `--quorum X` where X is the number of nodes in your UNL less 1. |
| 45 | + |
| 46 | + |
| 47 | +### Other cases TBD |
| 48 | + |
| 49 | + |
0 commit comments