[validator_key_revocation] JP////9xIe0hvssbqmgzFH4/NDp1z|3ShkmCtFXuC5A0IUocppHopnASQN2MuMD1Puoyjvnr jQ2KJSO/2tsjRhjO6q0QQHppslQsKNSXWxjGQNIEa6nPisBOKlDDcJVZAMP4QcIyNCadzgM= ``` #62
Description
nHUtNnLVx7odrz5dnfb2xpIgbEeJPbzJWfdicSkGyVw1eE5GpjQr
validator public key: nHUtNnLVx7odrz5dnfb2xpIgbEeJPbzJWfdicSkGyVw1eE5GpjQr
[validator_token] eyJ2YWxpZGF0aW9uX3NlY3J|dF9rZXkiOiI5ZWQ0NWY4NjYyNDFjYzE4YTI3NDdiNT QzODdjMDYyNTkwNzk3MmY0ZTcxOTAyMzFmYWE5Mzc0NTdmYT|kYWY2IiwibWFuaWZl c3QiOiJKQUFBQUFGeEllMUZ0d21pbXZHdEgyaUNjTUpxQzlnVkZLaWxHZncxL3ZDeE hYWExwbGMyR25NaEFrRTFhZ3FYeEJ3RHdEYklENk9NU1l1TTBGREFscEFnTms4U0tG bjdNTzJmZGtjd1JRSWhBT25ndTlzQUtxWFlvdUorbDJWMFcrc0FPa1ZCK1pSUzZQU2 hsSkFmVXNYZkFpQnNWSkdlc2FhZE9KYy9hQVpva1MxdnltR21WcmxIUEtXWDNZeXd1 NmluOEhBU1FLUHVnQkQ2N2tNYVJGR3ZtcEFUSGxHS0pkdkRGbFdQWXk1QXFEZWRGdj VUSmEydzBpMjFlcTNNWXl3TFZKWm5GT3I3QzBrdzJBaVR6U0NqSXpkaXRROD0ifQ== $ validator-keys sign "your data to sign" $ validator-keys revoke_keys Update rippled.cfg file with these values:
validator public key: nHUtNnLVx7odrz5dnfb2xpIgbEeJPbzJWfdicSkGyVw1eE5GpjQr
[validator_token]
eyJ2YWxpZGF0aW9uX3NlY3J|dF9rZXkiOiI5ZWQ0NWY4NjYyNDFjYzE4YTI3NDdiNT
QzODdjMDYyNTkwNzk3MmY0ZTcxOTAyMzFmYWE5Mzc0NTdmYT|kYWY2IiwibWFuaWZl
c3QiOiJKQUFBQUFGeEllMUZ0d21pbXZHdEgyaUNjTUpxQzlnVkZLaWxHZncxL3ZDeE
hYWExwbGMyR25NaEFrRTFhZ3FYeEJ3RHdEYklENk9NU1l1TTBGREFscEFnTms4U0tG
bjdNTzJmZGtjd1JRSWhBT25ndTlzQUtxWFlvdUorbDJWMFcrc0FPa1ZCK1pSUzZQU2
hsSkFmVXNYZkFpQnNWSkdlc2FhZE9KYy9hQVpva1MxdnltR21WcmxIUEtXWDNZeXd1
NmluOEhBU1FLUHVnQkQ2N2tNYVJGR3ZtcEFUSGxHS0pkdkRGbFdQWXk1QXFEZWRGdj
VUSmEydzBpMjFlcTNNWXl3TFZKWm5GT3I3QzBrdzJBaVR6U0NqSXpkaXRROD0ifQ== $ validator-keys create_token Validator keys stored in /home/ubuntu/.ripple/validator-keys.json $ validator-keys create_keys$ ./validator-keys create_token --keyfile /PATH/TO/YOUR/validator-keys.jsonValidator keys stored in /home/my-user/.ripple/validator-keys.json This file should be stored securely and not shared.$ ./validator-keys create_keys$ cd /opt/ripple/bin/# Run rippled as a Validator A rippled server running in validator mode does everything a stock server does: - Connects to a network of peers - Relays cryptographically signed transactions - Maintains a local copy of the complete shared global ledger What makes a validator different is that it also issues validation messages, which are sets of candidate transactions for evaluation by the XRP Ledger network during the consensus process. Issuing validation messages does not automatically give your validator a say in the consensus process, so the system is not vulnerable to a Sybil attack. Other servers ignore your validation messages unless they add your validator to their Unique Node List (UNL). If your validator is included in a UNL, it is a trusted validator and its proposals are considered in the consensus process by the servers that trust it. Even if your validator isn't a trusted validator, it still plays an important role in the overall health of the network. These validators help set the standard that trusted validators are measured against. For example, if a trusted validator is disagreeing with a lot of these validators that aren't listed in UNLs, that might indicate a problem. Validators should not be accessible to the public. Do not allow public WebSocket access to your validator server or any other form of public access. ## 1. Understand the traits of a good validator Strive to have your validator embody the following properties. Being a good validator helps rippled server operators and validator list publishers (such as https://vl.ripple.com and https://vl.xrplf.org) trust your validator before adding it to their UNLs. - Available A good validator is always running and submitting validation votes for every proposed ledger. Strive for 100% uptime. - In agreement A good validator's votes match the outcome of the consensus process as often as possible. To do otherwise could indicate that your validator's software is outdated, buggy, or intentionally biased. Always run the latest rippled release without modifications. Watch rippled releases and subscribe to the Google Group to be notified of new releases. - Issuing prompt votes A good validator's votes arrive quickly and not after a consensus round has already finished. To keep your votes on time, make sure your validator meets the recommended system requirements, which include a fast internet connection. It is possible to submit new transactions and query data using a validator, but heavy loads of API queries may make the validator less reliable at keeping up with consensus. If your API needs are light enough, then you can use a server for both purposes. Ideally, a validator should be dedicated to participating in consensus. - Identified A good validator has a clearly identified owner. Providing domain verification is a good start. Ideally, XRP Ledger network UNLs include validators run by different owners in multiple legal jurisdictions and geographic areas. This reduces the chance that any localized events could interfere with the impartial operations of trusted validators. It is strongly recommended that operators use the list providers that are present in this example file. ## 2. Install a rippled server For more information, see Install rippled. ## 3. Enable validation on your rippled server Enabling validation on your rippled server means providing a validator token in your server's rippled.cfg file. You can use the validator-keys tool (included in rippled packages) to securely generate and manage your validator keys and tokens. In a secure location not on your validator: 1. Generate a validator key pair using the validator-keys tool, which is included in the rippled package: $ cd /opt/ripple/bin/ Then run: $ ./validator-keys create_keys Sample output on Ubuntu: Validator keys stored in /home/my-user/.ripple/validator-keys.json This file should be stored securely and not shared. Sample output on macOS: Validator keys stored in /Users/my-user/.ripple/validator-keys.json This file should be stored securely and not shared. Store the generated validator-keys.json key file in a secure, offline, and recoverable location, such as an encrypted USB flash drive. Do not store keys on the validator where you intend to use the keys. If your secret_key is compromised, revoke the key immediately. Do not modify the contents of validator-keys.json, except to update the backup after generating a new token. If you generate more than one token from the same backup without updating, the network ignores the later tokens because they use the same token_sequence number. For more information about the validator-keys tool and the key pairs it generates, see the Validator Keys Tool Guide. 2. Generate a validator token using the create_token command. [Make sure you are at /opt/ripple/bin/] $ ./validator-keys create_token --keyfile /PATH/TO/YOUR/validator-keys.json Sample output: Update rippled.cfg file with these values: # validator public key: nHUtNnLVx7odrz5dnfb2xpIgbEeJPbzJWfdicSkGyVw1eE5GpjQr [validator_token] eyJ2YWxpZGF0aW9uX3NlY3J|dF9rZXkiOiI5ZWQ0NWY4NjYyNDFjYzE4YTI3NDdiNT QzODdjMDYyNTkwNzk3MmY0ZTcxOTAyMzFmYWE5Mzc0NTdmYT|kYWY2IiwibWFuaWZl c3QiOiJKQUFBQUFGeEllMUZ0d21pbXZHdEgyaUNjTUpxQzlnVkZLaWxHZncxL3ZDeE hYWExwbGMyR25NaEFrRTFhZ3FYeEJ3RHdEYklENk9NU1l1TTBGREFscEFnTms4U0tG bjdNTzJmZGtjd1JRSWhBT25ndTlzQUtxWFlvdUorbDJWMFcrc0FPa1ZCK1pSUzZQU2 hsSkFmVXNYZkFpQnNWSkdlc2FhZE9KYy9hQVpva1MxdnltR21WcmxIUEtXWDNZeXd1 NmluOEhBU1FLUHVnQkQ2N2tNYVJGR3ZtcEFUSGxHS0pkdkRGbFdQWXk1QXFEZWRGdj VUSmEydzBpMjFlcTNNWXl3TFZKWm5GT3I3QzBrdzJBaVR6U0NqSXpkaXRROD0ifQ== On your validator: 1. Add [validator_token] and its value to your validator's rippled.cfg file. If you previously configured your validator without the validator-keys tool, delete [validation_seed] and its value from your rippled.cfg file. This changes your validator public key. 2. Restart rippled. $ sudo systemctl restart rippled.service 3. Use the server_info command to get information about your validator to verify that it is running as a validator. $ rippled server_info - The pubkey_validator value in the response should match the public_key in the validator-keys.json file that you generated for use with your validator. - The server_state value should be proposing. Security Tip: Change the permissions on your rippled.cfg file to be more restrictive. On Linux it is recommended to be 0600. You can do this with chmod 0600 rippled.cfg ## 4. Connect to the network This section describes three different configurations you can use to connect your validator to the XRP Ledger network. Use the configuration that best suits your use case. - Discovered peers: Connect to any servers in the peer-to-peer network. - Proxies: Run stock rippled servers as proxies between your validator and the rest of the peer-to-peer network. - Public hubs: Connect only to specific public servers with a high reputation. For a comparison of these approaches, see Pros and Cons of Peering Configurations. ### Connect using discovered peers This configuration connects your validator to the XRP Ledger network using discovered peers. This is the default behavior for rippled servers. To connect your validator to the XRP Ledger network using discovered peers, omit the [peer_private] stanza or set it to 0 in your validator's rippled.cfg file. The example rippled.cfg file is delivered with this configuration. ### Connect using proxies This configuration connects your validator to the network through stock rippled servers that you run yourself. These proxy servers sit between your validator and inbound and outbound network traffic. To connect your validator to the XRP Ledger network using proxies: 1. Set up stock rippled servers. For more information, see Install rippled. 2. Configure your validator and stock rippled servers to run in a cluster. 3. In your validator's rippled.cfg file, set [peer_private] to 1. This prevents your validator's IP address from being forwarded. For more information, see Private Peers. It also prevents your validator from connecting to servers other than those defined in the [ips_fixed] stanza you defined to run your validator in a cluster. Be sure that you don't publish your validator's IP address in other ways. 4. Configure your validator host machine's firewall to allow the following traffic only: - Inbound traffic: Only from IP addresses of the stock rippled servers in the cluster you configured. - Outbound traffic: Only to the IP addresses of the stock rippled servers in the cluster you configured and to your UNL list providers through port 443. 5. Restart rippled. $ sudo systemctl restart rippled.service 6. Use the Peer Crawler endpoint on one of your stock rippled servers. The response should not include your validator. This verifies that your validator's [peer_private] configuration is working. One of the effects of enabling [peer_private] on your validator is that your validator's peers do not include it in their Peer Crawler results. $ curl --insecure https://STOCK_SERVER_IP_ADDRESS_HERE:51235/crawl | python3 -m json.tool ### Connect using public hubs This configuration connects your validator to the network using three public hubs. This configuration is similar to connecting using proxies you run yourself, but instead you connect through public hubs. To connect your validator to the network using public hubs: 1. In your validator's rippled.cfg file, include the following [ips_fixed] stanza. This stanza tells rippled to always attempt to maintain peer connections with these public hubs. [ips_fixed] r.ripple.com 51235 sahyadri.isrdc.in 51235 hubs.xrpkuwait.com 51235 hub.xrpl-commons.org 51235 Note The above list may evolve over time. To ensure you're using the most current set of public hubs, refer to the official rippled-example.cfg maintained by XRPLF. This configuration connects your validator to the network using default public hubs. Because these are the default public hubs, they may sometimes be too busy to provide your validator with a connection to the network. To help avoid this issue, connect to more public hubs and, even better, connect to non-default public hubs. You can include the IP addresses of other rippled servers here, but only if you can expect them to: - Relay messages without censoring. - Stay online consistently. - Not DDoS you. - Not try to crash your server. - Not publish your IP address to strangers. 1. Also in your validator's rippled.cfg file, include the following [peer_private] stanza and set it to 1. This instructs your validator’s peers not to broadcast your validator’s IP address. This setting also instructs your validator to connect to only the peers configured in your [ips_fixed] stanza. This ensures that your validator connects to and shares its IP with only peer rippled servers you know and trust. [peer_private] 1 Be sure that you don't publish your validator's IP address in other ways. With [peer_private] enabled, rippled ignores any connections suggested by the [ips] stanza. If you need to connect to an IP currently in your [ips] stanza, put it in the [ips_fixed] stanza instead, but only if you can expect them to behave responsibly as described in step 1. 2. Restart rippled. $ sudo systemctl restart rippled.service ## 5. Verify your network connection Here are some methods you can use to verify that your validator has a healthy connection to the XRP Ledger network: - Use the peers command to return a list of all rippled servers currently connected to your validator. If the peers array is null, you don’t have a healthy connection to the network. If you've set up your validator using the instructions in this document, the peers array should include the same number of objects as the number of peers defined in your [ips_fixed] stanza. If you listed a public hub in your [ips_fixed] stanza and it is busy, it may reject your validator's connection. In this case, you may end up with fewer connections than configured in your [ips_fixed] stanza. Your validator retries the connection if it's initially rejected. If you are having trouble maintaining a reliable and safe connection to the network and haven't set up connections using public hubs or proxies, see 4. Connect to the network. Using one of the methods described in the section may help your validator remain healthily connected to the network. - Use the server_info command to return some basic information about your validator. The server_state should be set to proposing. It may also be set to full or validating, but only for a few minutes before moving into proposing. If the server_state does not spend the majority of its time set to proposing, it may be a sign that your validator is unable to fully participate in the XRP Ledger network. For more information about server states and using the server_info endpoint to diagnose issues with your validator, see rippled Server States and Get the server_info. - Use the validators command to return the current list of published and trusted validators used by the validator. Ensure that the validator_list_expires value is either never or not expired or about to expire. ## 6. Provide domain verification To help validation list publishers and other participants in the XRP Ledger network understand who runs your validator, provide domain verification for your validator. At a high level, domain verification is a two-way link: - Use your domain to claim ownership of a validator key. - Use your validator key to claim ownership of a domain. Creating this link establishes strong evidence that you own both the validator key and the domain. Providing this evidence is one aspect of being a good validator. To provide domain verification: 1. Choose a domain name you own that you want to be publicly associated with your validator. As a precaution against DDoS attempts, your domain name should not resolve to the ip address of your validator. 2. Serve an xrp-ledger.toml file at your domain, and complete the domain verification steps. Once you have completed these steps, your validator should be visible to the livenet explorer or any other site that monitors the validator network and supports decetralized domain verification. 3. Share your validator's public key with the public, especially other rippled operators. For example, you can share your validator's public key on your website, on social media, in the XRPChat community forum, or in a press release. ## Revoke validator keys If your validator's master private key is compromised, you must revoke it immediately and permanently. For information about how to revoke a master key pair you generated for your validator using the validator-keys tool, see Key Revocation. ## See Also - Concepts: - XRP Ledger Overview - The rippled Server - Tutorials: - Cluster rippled Servers - Install rippled - Capacity Planning - References: - Validator Keys Tool Guide - consensus_info method - validator_list_sites method - validators method# Introduction The XRP Ledger is a blockchain that permanently records digital transactions of tokens between accounts. The sections below expand on the concepts introduced in that sentence.# What is the XRP Ledger? The XRP Ledger is a decentralized blockchain that uses its own digital currency to process and record financial transactions. ## What Is a Blockchain? A blockchain is a continuously growing list of records. The blockchain starts with a block of data. 
A group of trusted validator nodes reach consensus that the data is valid. 
The block is uniquely identified with a very elaborate, complicated, computer-generated, cryptographic Hash number that is 64 hexadecimal characters long. 
The block is also identified by a timestamp with its creation time. 
Each validator node gets its own copy of the data block. There is no single central authority. All copies are equally valid. 
Each block contains a hash pointer as a link to the previous block. It also has a timestamp, new data, and its own unique hash number. 
Using this structure, each block has a clear position in the chain, linking back to the previous data block. This creates an immutable chain of blocks. You can always verify all current information on the chain by tracing back through the previous blocks. 
By design, blockchains are resistant to modification of the data. Every ledger node gets an exact copy of the blockchain. 
This creates an open, distributed ledger that records transactions between parties efficiently and in a verifiable and permanent way. Once recorded, the data in any given block cannot be altered retroactively, unless a majority of the validators agree to the change. If so, all subsequent blocks are changed in the same way (a very rare and extreme occurrence). ### How Does the Federated Consensus Process Work? Most of the rippled servers in the XRPL monitor or propose transactions. An important subset of servers are run as validators. These trusted servers accumulate lists of new transactions into a new possible ledger instance (a new block in the block chain). 
They share their lists with all of the other validators. The validators incorporate proposed changes from one another and distribute a new version of the ledger proposal. 
When 80% of the validators agree on a set of transactions, they create a new ledger instance at the end of the chain and start the process again. This consensus process takes 4-6 seconds. You can monitor as ledger instances are created in real time by visiting https://livenet.xrpl.org/. ### What Networks Are Available? The XRPL is open to anyone who wants to set up their own instance of the rippled server and connect. The node can monitor the network, perform transactions, or become a validator. The active XRPL network is typically referred to as Mainnet. For developers or new users who want to try out the features of XRPL without investing their own funds, there are two developer environments, Testnet and Devnet. Users can create an account funded with 1,000 (fake) XRP and connect to either environment to interact with the XRPL. Next: What is XRP?apex-omniX_SIM_API_KEYcurl --request GET
--url 'https://api.sim.dune.com/v1/evm/balances/0xd8dA6BF26964aF9D7eEd9e03E53415D37aA96045?limit=1000'
--header 'X-Sim-Api-Key: 'const options = {method: 'GET', headers: {'X-Sim-Api-Key': ''}};
fetch('https://api.sim.dune.com/v1/evm/balances/0xd8dA6BF26964aF9D7eEd9e03E53415D37aA96045?limit=1000', options)
.then(res => res.json())
.then(res => console.log(res))
.catch(err => console.error(err));