diff --git a/core/src/accounts_hash_verifier.rs b/core/src/accounts_hash_verifier.rs index 35fe5f6b12..c320a6c47c 100644 --- a/core/src/accounts_hash_verifier.rs +++ b/core/src/accounts_hash_verifier.rs @@ -1,7 +1,7 @@ // Service to verify accounts hashes with other trusted validator nodes. // // Each interval, publish the snapshat hash which is the full accounts state -// hash on gossip. Monitor gossip for messages from validators in the --trusted-validators +// hash on gossip. Monitor gossip for messages from validators in the `--known-validator`s // set and halt the node if a mismatch is detected. use crate::snapshot_packager_service::PendingSnapshotPackage; diff --git a/docs/src/clusters.md b/docs/src/clusters.md index 9d8d133b7d..ce78456f38 100644 --- a/docs/src/clusters.md +++ b/docs/src/clusters.md @@ -44,18 +44,26 @@ solana config set --url https://api.devnet.solana.com $ solana-validator \ --identity validator-keypair.json \ --vote-account vote-account-keypair.json \ - --trusted-validator dv1LfzJvDF7S1fBKpFgKoKXK5yoSosmkAdfbxBo1GqJ \ - --no-untrusted-rpc \ + --known-validator dv1ZAGvdsz5hHLwWXsVnM94hWf1pjbKVau1QVkaMJ92 \ + --known-validator dv2eQHeP4RFrJZ6UeiZWoc3XTtmtZCUKxxCApCDcRNV \ + --known-validator dv4ACNkpYPcE3aKmYDqZm9G5EB3J4MRoeE7WNDRBVJB \ + --known-validator dv3qDFk1DTF36Z62bNvrCXe9sKATA6xvVy6A798xxAS \ + --only-known-rpc \ --ledger ledger \ --rpc-port 8899 \ --dynamic-port-range 8000-8010 \ --entrypoint entrypoint.devnet.solana.com:8001 \ + --entrypoint entrypoint2.devnet.solana.com:8001 \ + --entrypoint entrypoint3.devnet.solana.com:8001 \ + --entrypoint entrypoint4.devnet.solana.com:8001 \ + --entrypoint entrypoint5.devnet.solana.com:8001 \ --expected-genesis-hash EtWTRABZaYq6iMfeYKouRu166VU2xqa1wcaWoxPkrZBG \ --wal-recovery-mode skip_any_corrupted_record \ --limit-ledger-size ``` -The `--trusted-validator`s is operated by Solana +The [`--known-validator`s](running-validator/validator-start.md#known-validators) +are operated by Solana Labs ## Testnet @@ -88,11 +96,11 @@ solana config set --url https://api.testnet.solana.com $ solana-validator \ --identity validator-keypair.json \ --vote-account vote-account-keypair.json \ - --trusted-validator 5D1fNXzvv5NjV1ysLjirC4WY92RNsVH18vjmcszZd8on \ - --trusted-validator 7XSY3MrYnK8vq693Rju17bbPkCN3Z7KvvfvJx4kdrsSY \ - --trusted-validator Ft5fbkqNa76vnsjYNwjDZUXoTWpP7VYm3mtsaQckQADN \ - --trusted-validator 9QxCLckBiJc783jnMvXZubK4wH86Eqqvashtrwvcsgkv \ - --no-untrusted-rpc \ + --known-validator 5D1fNXzvv5NjV1ysLjirC4WY92RNsVH18vjmcszZd8on \ + --known-validator 7XSY3MrYnK8vq693Rju17bbPkCN3Z7KvvfvJx4kdrsSY \ + --known-validator Ft5fbkqNa76vnsjYNwjDZUXoTWpP7VYm3mtsaQckQADN \ + --known-validator 9QxCLckBiJc783jnMvXZubK4wH86Eqqvashtrwvcsgkv \ + --only-known-rpc \ --ledger ledger \ --rpc-port 8899 \ --dynamic-port-range 8000-8010 \ @@ -104,17 +112,16 @@ $ solana-validator \ --limit-ledger-size ``` -The identity of the `--trusted-validator`s are: +The identities of the +[`--known-validator`s](running-validator/validator-start.md#known-validators) are: -- `5D1fNXzvv5NjV1ysLjirC4WY92RNsVH18vjmcszZd8on` - Solana Foundation (testnet.solana.com) -- `7XSY3MrYnK8vq693Rju17bbPkCN3Z7KvvfvJx4kdrsSY` - Solana Foundation (Break RPC node) +- `5D1fNXzvv5NjV1ysLjirC4WY92RNsVH18vjmcszZd8on` - Solana Labs (testnet.solana.com) - `Ft5fbkqNa76vnsjYNwjDZUXoTWpP7VYm3mtsaQckQADN` - Certus One - `9QxCLckBiJc783jnMvXZubK4wH86Eqqvashtrwvcsgkv` - Algo|Stake ## Mainnet Beta A permissionless, persistent cluster for early token holders and launch partners. -Currently, rewards and inflation are disabled. - Tokens that are issued on Mainnet Beta are **real** SOL - If you have paid money to purchase/be issued tokens, such as through our @@ -143,11 +150,11 @@ solana config set --url https://api.mainnet-beta.solana.com $ solana-validator \ --identity ~/validator-keypair.json \ --vote-account ~/vote-account-keypair.json \ - --trusted-validator 7Np41oeYqPefeNQEHSv1UDhYrehxin3NStELsSKCT4K2 \ - --trusted-validator GdnSyH3YtwcxFvQrVVJMm1JhTS4QVX7MFsX56uJLUfiZ \ - --trusted-validator DE1bawNcRJB9rVm3buyMVfr8mBEoyyu73NBovf2oXJsJ \ - --trusted-validator CakcnaRDHka2gXyfbEd2d3xsvkJkqsLw2akB3zsN1D2S \ - --no-untrusted-rpc \ + --known-validator 7Np41oeYqPefeNQEHSv1UDhYrehxin3NStELsSKCT4K2 \ + --known-validator GdnSyH3YtwcxFvQrVVJMm1JhTS4QVX7MFsX56uJLUfiZ \ + --known-validator DE1bawNcRJB9rVm3buyMVfr8mBEoyyu73NBovf2oXJsJ \ + --known-validator CakcnaRDHka2gXyfbEd2d3xsvkJkqsLw2akB3zsN1D2S \ + --only-known-rpc \ --ledger ledger \ --rpc-port 8899 \ --private-rpc \ @@ -162,4 +169,5 @@ $ solana-validator \ --limit-ledger-size ``` -All four `--trusted-validator`s are operated by Solana +All four [`--known-validator`s](running-validator/validator-start.md#known-validators) +are operated by Solana Labs diff --git a/docs/src/developing/clients/jsonrpc-api.md b/docs/src/developing/clients/jsonrpc-api.md index ecb53c0c7d..f8a93b33b5 100644 --- a/docs/src/developing/clients/jsonrpc-api.md +++ b/docs/src/developing/clients/jsonrpc-api.md @@ -205,11 +205,11 @@ health-check mechanism for use by load balancers or other network infrastructure. This request will always return a HTTP 200 OK response with a body of "ok", "behind" or "unknown" based on the following conditions: -1. If one or more `--trusted-validator` arguments are provided to `solana-validator`, "ok" is returned +1. If one or more `--known-validator` arguments are provided to `solana-validator`, "ok" is returned when the node has within `HEALTH_CHECK_SLOT_DISTANCE` slots of the highest - trusted validator, otherwise "behind". "unknown" is returned when no slot - information from trusted validators is not yet available. -2. "ok" is always returned if no trusted validators are provided. + known validator, otherwise "behind". "unknown" is returned when no slot + information from known validators is not yet available. +2. "ok" is always returned if no known validators are provided. ## JSON RPC API Reference @@ -1195,10 +1195,10 @@ Result: Returns the current health of the node. -If one or more `--trusted-validator` arguments are provided to +If one or more `--known-validator` arguments are provided to `solana-validator`, "ok" is returned when the node has within -`HEALTH_CHECK_SLOT_DISTANCE` slots of the highest trusted validator, otherwise -an error is returned. "ok" is always returned if no trusted validators are +`HEALTH_CHECK_SLOT_DISTANCE` slots of the highest known validator, otherwise +an error is returned. "ok" is always returned if no known validators are provided. #### Parameters: diff --git a/docs/src/implemented-proposals/ed_overview/ed_storage_rent_economics.md b/docs/src/implemented-proposals/ed_overview/ed_storage_rent_economics.md index f19246a273..8abd88ad2c 100644 --- a/docs/src/implemented-proposals/ed_overview/ed_storage_rent_economics.md +++ b/docs/src/implemented-proposals/ed_overview/ed_storage_rent_economics.md @@ -8,7 +8,7 @@ Storage rent can be paid via one of two methods: Method 1: Set it and forget it -With this approach, accounts with two-years worth of rent deposits secured are exempt from network rent charges. By maintaining this minimum-balance, the broader network benefits from reduced liquidity and the account holder can trust that their `Account::data` will be retained for continual access/usage. +With this approach, accounts with two-years worth of rent deposits secured are exempt from network rent charges. By maintaining this minimum-balance, the broader network benefits from reduced liquidity and the account holder can rest assured that their `Account::data` will be retained for continual access/usage. Method 2: Pay per byte diff --git a/docs/src/implemented-proposals/ed_overview/ed_validation_client_economics/ed_vce_validation_stake_delegation.md b/docs/src/implemented-proposals/ed_overview/ed_validation_client_economics/ed_vce_validation_stake_delegation.md index 2ea3d3120c..64ab877926 100644 --- a/docs/src/implemented-proposals/ed_overview/ed_validation_client_economics/ed_vce_validation_stake_delegation.md +++ b/docs/src/implemented-proposals/ed_overview/ed_validation_client_economics/ed_vce_validation_stake_delegation.md @@ -23,6 +23,6 @@ Running a Solana validation-client required relatively modest upfront hardware c **Table 2** example high-end hardware setup for running a Solana client. -Despite the low-barrier to entry as a validation-client, from a capital investment perspective, as in any developing economy, there will be much opportunity and need for trusted validation services as evidenced by node reliability, UX/UI, APIs and other software accessibility tools. Additionally, although Solana’s validator node startup costs are nominal when compared to similar networks, they may still be somewhat restrictive for some potential participants. In the spirit of developing a true decentralized, permissionless network, these interested parties can become involved in the Solana network/economy via delegation of previously acquired tokens with a reliable validation node to earn a portion of the interest generated. +Despite the low-barrier to entry as a validation-client, from a capital investment perspective, as in any developing economy, there will be much opportunity and need for competent validation services as evidenced by node reliability, UX/UI, APIs and other software accessibility tools. Additionally, although Solana’s validator node startup costs are nominal when compared to similar networks, they may still be somewhat restrictive for some potential participants. In the spirit of developing a true decentralized, permissionless network, these interested parties can become involved in the Solana network/economy via delegation of previously acquired tokens with a reliable validation node to earn a portion of the interest generated. Delegation of tokens to validation-clients provides a way for passive Solana token holders to become part of the active Solana economy and earn interest rates proportional to the interest rate generated by the delegated validation-client. Additionally, this feature intends to create a healthy validation-client market, with potential validation-client nodes competing to build reliable, transparent and profitable delegation services. diff --git a/docs/src/implemented-proposals/installer.md b/docs/src/implemented-proposals/installer.md index 12fb2742df..a32b59c183 100644 --- a/docs/src/implemented-proposals/installer.md +++ b/docs/src/implemented-proposals/installer.md @@ -4,7 +4,7 @@ title: Cluster Software Installation and Updates Currently users are required to build the solana cluster software themselves from the git repository and manually update it, which is error prone and inconvenient. -This document proposes an easy to use software install and updater that can be used to deploy pre-built binaries for supported platforms. Users may elect to use binaries supplied by Solana or any other party they trust. Deployment of updates is managed using an on-chain update manifest program. +This document proposes an easy to use software install and updater that can be used to deploy pre-built binaries for supported platforms. Users may elect to use binaries supplied by Solana or any other party provider. Deployment of updates is managed using an on-chain update manifest program. ## Motivating Examples diff --git a/docs/src/integrations/exchange.md b/docs/src/integrations/exchange.md index e6edf14318..49f5f161ff 100644 --- a/docs/src/integrations/exchange.md +++ b/docs/src/integrations/exchange.md @@ -13,8 +13,8 @@ operations with a bundled monitoring tool. This setup enables you: -- to have a trusted gateway to the Solana mainnet-beta cluster to get data and - submit withdrawal transactions +- to have a self-administered gateway to the Solana mainnet-beta cluster to get + data and submit withdrawal transactions - to have full control over how much historical block data is retained - to maintain your service availability even if one node fails @@ -37,8 +37,8 @@ solana-validator \ --no-voting \ --enable-rpc-transaction-history \ --limit-ledger-size \ - --trusted-validator \ - --no-untrusted-rpc + --known-validator \ + --only-known-rpc ``` Customize `--ledger` to your desired ledger storage location, and `--rpc-port` to the port you want to expose. @@ -56,7 +56,7 @@ default limit value used by `--limit-ledger-size`. More information about selecting a custom limit value is [available here](https://github.com/solana-labs/solana/blob/583cec922b6107e0f85c7e14cb5e642bc7dfb340/core/src/ledger_cleanup_service.rs#L15-L26). -Specifying one or more `--trusted-validator` parameters can protect you from booting from a malicious snapshot. [More on the value of booting with trusted validators](../running-validator/validator-start.md#trusted-validators) +Specifying one or more `--known-validator` parameters can protect you from booting from a malicious snapshot. [More on the value of booting with known validators](../running-validator/validator-start.md#known-validators) Optional parameters to consider: @@ -97,7 +97,7 @@ announcement. For security-related releases, more urgent action may be needed. ### Ledger Continuity By default, each of your nodes will boot from a snapshot provided by one of your -trusted validators. This snapshot reflects the current state of the chain, but +known validators. This snapshot reflects the current state of the chain, but does not contain the complete historical ledger. If one of your node exits and boots from a new snapshot, there may be a gap in the ledger on that node. In order to prevent this issue, add the `--no-snapshot-fetch` parameter to your @@ -112,7 +112,7 @@ It is important to note that the amount of historical ledger available to your nodes from the rest of the network is limited at any point in time. Once operational if your validators experience significant downtime they may not be able to catch up to the network and will need to download a new snapshot from a -trusted validator. In doing so your validators will now have a gap in its +known validator. In doing so your validators will now have a gap in its historical ledger data that cannot be filled. ### Minimizing Validator Port Exposure diff --git a/docs/src/introduction.md b/docs/src/introduction.md index b4b6d57ff3..7494a51f95 100644 --- a/docs/src/introduction.md +++ b/docs/src/introduction.md @@ -8,11 +8,11 @@ Solana is an open source project implementing a new, high-performance, permissio ## Why Solana? -It is possible for a centralized database to process 710,000 transactions per second on a standard gigabit network if the transactions are, on average, no more than 176 bytes. A centralized database can also replicate itself and maintain high availability without significantly compromising that transaction rate using the distributed system technique known as Optimistic Concurrency Control [\[H.T.Kung, J.T.Robinson (1981)\]](http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.65.4735). At Solana, we are demonstrating that these same theoretical limits apply just as well to blockchain on an adversarial network. The key ingredient? Finding a way to share time when nodes cannot trust one-another. Once nodes can trust time, suddenly ~40 years of distributed systems research becomes applicable to blockchain! +It is possible for a centralized database to process 710,000 transactions per second on a standard gigabit network if the transactions are, on average, no more than 176 bytes. A centralized database can also replicate itself and maintain high availability without significantly compromising that transaction rate using the distributed system technique known as Optimistic Concurrency Control [\[H.T.Kung, J.T.Robinson (1981)\]](http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.65.4735). At Solana, we are demonstrating that these same theoretical limits apply just as well to blockchain on an adversarial network. The key ingredient? Finding a way to share time when nodes cannot rely upon one-another. Once nodes can rely upon time, suddenly ~40 years of distributed systems research becomes applicable to blockchain! > Perhaps the most striking difference between algorithms obtained by our method and ones based upon timeout is that using timeout produces a traditional distributed algorithm in which the processes operate asynchronously, while our method produces a globally synchronous one in which every process does the same thing at (approximately) the same time. Our method seems to contradict the whole purpose of distributed processing, which is to permit different processes to operate independently and perform different functions. However, if a distributed system is really a single system, then the processes must be synchronized in some way. Conceptually, the easiest way to synchronize processes is to get them all to do the same thing at the same time. Therefore, our method is used to implement a kernel that performs the necessary synchronization--for example, making sure that two different processes do not try to modify a file at the same time. Processes might spend only a small fraction of their time executing the synchronizing kernel; the rest of the time, they can operate independently--e.g., accessing different files. This is an approach we have advocated even when fault-tolerance is not required. The method's basic simplicity makes it easier to understand the precise properties of a system, which is crucial if one is to know just how fault-tolerant the system is. [\[L.Lamport (1984)\]](http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.71.1078) -Furthermore, and much to our surprise, it can be implemented using a mechanism that has existed in Bitcoin since day one. The Bitcoin feature is called nLocktime and it can be used to postdate transactions using block height instead of a timestamp. As a Bitcoin client, you would use block height instead of a timestamp if you don't trust the network. Block height turns out to be an instance of what's being called a Verifiable Delay Function in cryptography circles. It's a cryptographically secure way to say time has passed. In Solana, we use a far more granular verifiable delay function, a SHA 256 hash chain, to checkpoint the ledger and coordinate consensus. With it, we implement Optimistic Concurrency Control and are now well en route towards that theoretical limit of 710,000 transactions per second. +Furthermore, and much to our surprise, it can be implemented using a mechanism that has existed in Bitcoin since day one. The Bitcoin feature is called nLocktime and it can be used to postdate transactions using block height instead of a timestamp. As a Bitcoin client, you would use block height instead of a timestamp if you don't rely upon the network. Block height turns out to be an instance of what's being called a Verifiable Delay Function in cryptography circles. It's a cryptographically secure way to say time has passed. In Solana, we use a far more granular verifiable delay function, a SHA 256 hash chain, to checkpoint the ledger and coordinate consensus. With it, we implement Optimistic Concurrency Control and are now well en route towards that theoretical limit of 710,000 transactions per second. ## Documentation Overview diff --git a/docs/src/proposals/rip-curl.md b/docs/src/proposals/rip-curl.md index 23b7247d2b..8e2ab9707a 100644 --- a/docs/src/proposals/rip-curl.md +++ b/docs/src/proposals/rip-curl.md @@ -17,7 +17,7 @@ static content and less appealing for transaction processing. The clients poll for transaction status instead of being notified, giving the false impression of higher confirmation times. Furthermore, what clients can poll for is limited, preventing them from making reasonable real-time decisions, such as -recognizing a transaction is confirmed as soon as particular, trusted +recognizing a transaction is confirmed as soon as particular, known validators vote on it. ## Proposed Solution diff --git a/docs/src/running-validator/restart-cluster.md b/docs/src/running-validator/restart-cluster.md index 1772c14850..caf48b4f8a 100644 --- a/docs/src/running-validator/restart-cluster.md +++ b/docs/src/running-validator/restart-cluster.md @@ -54,9 +54,9 @@ Post something like the following to #announcements (adjusting the text as appro > --hard-fork SLOT_X # <-- NEW! IMPORTANT! REMOVE AFTER THIS RESTART > --no-snapshot-fetch # <-- NEW! IMPORTANT! REMOVE AFTER THIS RESTART > --entrypoint entrypoint.testnet.solana.com:8001 -> --trusted-validator 5D1fNXzvv5NjV1ysLjirC4WY92RNsVH18vjmcszZd8on +> --known-validator 5D1fNXzvv5NjV1ysLjirC4WY92RNsVH18vjmcszZd8on > --expected-genesis-hash 4uhcVJyU9pJkvQyS88uRDiswHXSCkY3zQawwpjk2NsNY -> --no-untrusted-rpc +> --only-known-rpc > --limit-ledger-size > ... # <-- your other --identity/--vote-account/etc arguments > ``` @@ -68,9 +68,9 @@ Post something like the following to #announcements (adjusting the text as appro > --wait-for-supermajority SLOT_X # <-- NEW! IMPORTANT! REMOVE AFTER THIS RESTART > --expected-bank-hash NEW_BANK_HASH # <-- NEW! IMPORTANT! REMOVE AFTER THIS RESTART > --entrypoint entrypoint.testnet.solana.com:8001 -> --trusted-validator 5D1fNXzvv5NjV1ysLjirC4WY92RNsVH18vjmcszZd8on +> --known-validator 5D1fNXzvv5NjV1ysLjirC4WY92RNsVH18vjmcszZd8on > --expected-genesis-hash 4uhcVJyU9pJkvQyS88uRDiswHXSCkY3zQawwpjk2NsNY -> --no-untrusted-rpc +> --only-known-rpc > --limit-ledger-size > ... # <-- your other --identity/--vote-account/etc arguments > ``` diff --git a/docs/src/running-validator/validator-start.md b/docs/src/running-validator/validator-start.md index a7b88bc605..b25df95738 100644 --- a/docs/src/running-validator/validator-start.md +++ b/docs/src/running-validator/validator-start.md @@ -258,15 +258,15 @@ solana create-vote-account ~/vote-account-keypair.json ~/validator-keypair.json Read more about [creating and managing a vote account](vote-accounts.md). -## Trusted validators +## Known validators -If you know and trust other validator nodes, you can specify this on the command line with the `--trusted-validator ` -argument to `solana-validator`. You can specify multiple ones by repeating the argument `--trusted-validator --trusted-validator `. -This has two effects, one is when the validator is booting with `--no-untrusted-rpc`, it will only ask that set of -trusted nodes for downloading genesis and snapshot data. Another is that in combination with the `--halt-on-trusted-validator-hash-mismatch` option, -it will monitor the merkle root hash of the entire accounts state of other trusted nodes on gossip and if the hashes produce any mismatch, +If you know and respect other validator operators, you can specify this on the command line with the `--known-validator ` +argument to `solana-validator`. You can specify multiple ones by repeating the argument `--known-validator --known-validator `. +This has two effects, one is when the validator is booting with `--only-known-rpc`, it will only ask that set of +known nodes for downloading genesis and snapshot data. Another is that in combination with the `--halt-on-known-validator-hash-mismatch` option, +it will monitor the merkle root hash of the entire accounts state of other known nodes on gossip and if the hashes produce any mismatch, the validator will halt the node to prevent the validator from voting or processing potentially incorrect state values. At the moment, the slot that -the validator publishes the hash on is tied to the snapshot interval. For the feature to be effective, all validators in the trusted +the validator publishes the hash on is tied to the snapshot interval. For the feature to be effective, all validators in the known set should be set to the same snapshot interval value or multiples of the same. It is highly recommended you use these options to prevent malicious snapshot state download or diff --git a/docs/src/storage_rent_economics.md b/docs/src/storage_rent_economics.md index 986467da8c..8405c8906f 100644 --- a/docs/src/storage_rent_economics.md +++ b/docs/src/storage_rent_economics.md @@ -8,7 +8,7 @@ Storage rent can be paid via one of two methods: Method 1: Set it and forget it -With this approach, accounts with two-years worth of rent deposits secured are exempt from network rent charges. By maintaining this minimum-balance, the broader network benefits from reduced liquidity and the account holder can trust that their `Account::data` will be retained for continual access/usage. +With this approach, accounts with two-years worth of rent deposits secured are exempt from network rent charges. By maintaining this minimum-balance, the broader network benefits from reduced liquidity and the account holder can rest assured that their `Account::data` will be retained for continual access/usage. Method 2: Pay per byte diff --git a/multinode-demo/validator.sh b/multinode-demo/validator.sh index 97864f0b74..bb596ee67c 100755 --- a/multinode-demo/validator.sh +++ b/multinode-demo/validator.sh @@ -142,10 +142,10 @@ while [[ -n $1 ]]; do elif [[ $1 = --log ]]; then args+=("$1" "$2") shift 2 - elif [[ $1 = --trusted-validator ]]; then + elif [[ $1 = --known-validator ]]; then args+=("$1" "$2") shift 2 - elif [[ $1 = --halt-on-trusted-validators-accounts-hash-mismatch ]]; then + elif [[ $1 = --halt-on-known-validators-accounts-hash-mismatch ]]; then args+=("$1") shift elif [[ $1 = --max-genesis-archive-unpacked-size ]]; then diff --git a/validator/src/main.rs b/validator/src/main.rs index 7924c74f06..45ba748c65 100644 --- a/validator/src/main.rs +++ b/validator/src/main.rs @@ -451,7 +451,7 @@ fn get_rpc_node( .count(); info!( - "Total {} RPC nodes found. {} trusted, {} blacklisted ", + "Total {} RPC nodes found. {} known, {} blacklisted ", rpc_peers_total, rpc_peers_trusted, rpc_peers_blacklisted ); @@ -464,7 +464,7 @@ fn get_rpc_node( blacklisted_rpc_nodes.clear(); Some("Blacklist timeout expired".to_owned()) } else { - Some("Wait for trusted rpc peers".to_owned()) + Some("Wait for known rpc peers".to_owned()) }; continue; } @@ -924,11 +924,12 @@ fn rpc_bootstrap( && trusted_validators.len() == 1 && bootstrap_config.no_untrusted_rpc { warn!("The snapshot download is too slow, throughput: {} < min speed {} bytes/sec, but will NOT abort \ - and try a different node as it is the only trusted validator and the no-untrusted-rpc is set. \ + and try a different node as it is the only known validator and the --only-known-rpc flag \ + is set. \ Abort count: {}, Progress detail: {:?}", download_progress.last_throughput, minimal_snapshot_download_speed, download_abort_count, download_progress); - return true; // Do not abort download from the one-and-only trusted validator + return true; // Do not abort download from the one-and-only known validator } } warn!("The snapshot download is too slow, throughput: {} < min speed {} bytes/sec, will abort \ @@ -1245,10 +1246,10 @@ pub fn main() { .value_name("SLOT_DISTANCE") .takes_value(true) .default_value("150") - .help("If --trusted-validators are specified, report this validator healthy \ + .help("If --known-validators are specified, report this validator healthy \ if its latest account hash is no further behind than this number of \ - slots from the latest trusted validator account hash. \ - If no --trusted-validators are specified, the validator will always \ + slots from the latest known validator account hash. \ + If no --known-validators are specified, the validator will always \ report itself to be healthy") ) .arg( @@ -1492,7 +1493,8 @@ pub fn main() { ) .arg( Arg::with_name("trusted_validators") - .long("trusted-validator") + .alias("trusted-validator") + .long("known-validator") .validator(is_pubkey) .value_name("VALIDATOR IDENTITY") .multiple(true) @@ -1511,9 +1513,10 @@ pub fn main() { ) .arg( Arg::with_name("no_untrusted_rpc") - .long("no-untrusted-rpc") + .alias("no-untrusted-rpc") + .long("only-known-rpc") .takes_value(false) - .help("Use the RPC service of trusted validators only") + .help("Use the RPC service of known validators only") ) .arg( Arg::with_name("repair_validators") @@ -1681,10 +1684,11 @@ pub fn main() { ) .arg( Arg::with_name("halt_on_trusted_validators_accounts_hash_mismatch") - .long("halt-on-trusted-validators-accounts-hash-mismatch") + .alias("halt-on-trusted-validators-accounts-hash-mismatch") + .long("halt-on-known-validators-accounts-hash-mismatch") .requires("trusted_validators") .takes_value(false) - .help("Abort the validator if a bank hash mismatch is detected within trusted validator set"), + .help("Abort the validator if a bank hash mismatch is detected within known validator set"), ) .arg( Arg::with_name("frozen_accounts") @@ -2161,7 +2165,7 @@ pub fn main() { &identity_keypair.pubkey(), &matches, "trusted_validators", - "--trusted-validator", + "--known-validator", ); let repair_validators = validators_set( &identity_keypair.pubkey(),