Skein Systems operates a cluster on the XRP ledger main network. Provided here is some information that we hope will be useful.
Skein Systems XRP Ledger Information
You can find the canonical details of our validator and stock peers through the recommended XRP ledger TOML description. This is a simple but verifiable descriptor that helps engender trust in the organisations and people operating XRPL validators. Skein Systems XRPL TOML file is located at the specification URL. Here are the basic details:
[[VALIDATORS]] public_key = "nHDpmRw3nYVWsbTrBaSScqHDQvNvnZJSAo7pxa3CQXbG571MVGHo" [[SERVERS]] peer = "r.skein.systems"
We also have a
TXT DNS record that matches the validator public key noted in the TOML file. Thanks to @AlloyNetworks for this suggestion.
dig -t TXT _xrpl.skein.systems
Peering With Skein Systems
Our stock nodes are available to the XRPL operator community at large to publicly peer with, however we do operate with some restrictions.
On our peer hub we run a service that monitors for the stability of the connecting peer. We have no wish to exclude new XRPL node operators but at the same time we want to encourage XRPL validator and stock node operators to stay in consensus with the main chain.
To that end we examine incoming peer connections and apply the following filtering:
- If the peer is running what we consider to be an “old” version of rippled it will be disconnected, usually within a minute or so. Currently we accept
(current patch version -1)- e.g. if the current version is 1.2.4 we accept 1.2.3+
- We provide a grace period of 30 minutes for connecting peers to sync with the main XRPL chain. This is sufficient time for a new node with a sound configuration and sufficient hardware resources to stabilise.
- After 30 minutes, if a peer is not synced we disconnect it and place it in a temporary ban list for
2hr. In our view this gives the operator time to tweak the configuration to try and stabilise the node.
Our thanks go to seasoned validator operator @RabbitKickClub for advice and example peer filtering code in this regard.
We will be happy to discuss and potentially provide permanent peering with other operators. At the very minimum to be considered for permanent peering you should at least observe the following requirements:
- You must have an XRPL validator that has been domain verified.
- You must identify yourself or your organisation to the XRPL community using the xrp-ledger.toml specification
- Optionally, but strongly encouraged, you should provide a DNS TXT entry in the following format:
Type: TXT, Hostname: _xrpl.verified.domain, Value: <validator pubkey>
Please note - we offer no guarantee of permanent peering. Since the expectations of the operators that Skein Systems peers with are high, we believe it is our responsibility to also hold our own peers to similar standards.
In so far as it’s possible, we endeavour to take a paranoid first approach to securing our systems. Outlined here are some of the steps we have taken so far to mitigate threats against the cluster. This is not an exhaustive list of measures taken, rather it should be seen as a baseline upon which Skein Systems strives to mitigate threats.
- OS & data volumes are encrypted.
- The root volume is read only, with only few places such as
/etchaving a write enabled overlay.
- Symetric multi-threading is disabled.
- SSH access is restricted to encryption keys only.
- SSH private keys are generated and stored on hardware security tokens and thus cannot be accidentally leaked.
- Encryption keys are subkeys, with the master offline.
- SSH access for configuration and admin is only available through bastion hosts and IP whitelists.
- Root login is disabled, SSH access is tightly restricted to a service account authorised through the hardware tokens.
- Hosts running
rippledonly run other services that are neccessary for metrics/alerts and management.
- Server and service configuration are deployed and updated through change management/devops practices to avoid human error.
- XRPL validator keys are never stored on the servers.
- OS and essential systems security updates are monitored through CVE lists and applied promptly