[docs] updated readme and fix links (solana-labs#34565)

* feat: updated readme

* fix: updated links

* fix: proposal links

* fix: more links

* fix: json-rpc links

* fix: more links

* fix: zk links

* fix: managing forks

* fix: links for deprecated methods

CHANGELOG.md

@@ -1,10 +1,11 @@
 # Changelog
+
 All notable changes to this project will be documented in this file.
 
 Please follow the [guidance](#adding-to-this-changelog) at the bottom of this file when making changes
 The format is based on [Keep a Changelog](https://keepachangelog.com/en/1.0.0/).
 This project adheres to [Semantic Versioning](https://semver.org/spec/v2.0.0.html)
-and follows a [Backwards Compatibility Policy](https://docs.solana.com/developing/backwards-compatibility)
+and follows a [Backwards Compatibility Policy](https://docs.solanalabs.com/backwards-compatibility)
 
 Release channels have their own copy of this changelog:
 * [edge - v1.18](#edge-channel)

CONTRIBUTING.md

@@ -315,17 +315,17 @@ Inventing new terms is allowed, but should only be done when the term is widely
 used and understood. Avoid introducing new 3-letter terms, which can be
 confused with 3-letter acronyms.
 
-[Terms currently in use](docs/src/terminology.md)
+[Terms currently in use](https://solana.com/docs/terminology)
 
 
 ## Design Proposals
 
-Solana's architecture is described by docs generated from markdown files in the `docs/src/`
-directory and viewable on the official [Solana Documentation](https://docs.solana.com) website.
+This Solana validator client's architecture is described by docs generated from markdown files in the `docs/src/`
+directory and viewable on the official [Solana Labs Validator Client](https://docs.solanalabs.com) documentation website.
 
 Current design proposals may be viewed on the docs site:
 
-1. [Accepted Proposals](https://docs.solana.com/proposals/accepted-design-proposals)
-2. [Implemented Proposals](https://docs.solana.com/implemented-proposals/implemented-proposals)
+1. [Accepted Proposals](https://docs.solanalabs.com/proposals/accepted-design-proposals)
+2. [Implemented Proposals](https://docs.solanalabs.com/implemented-proposals/implemented-proposals)
 
 New design proposals should follow this guide on [how to submit a design proposal](./docs/src/proposals.md#submit-a-design-proposal).

README.md

@@ -66,11 +66,13 @@ $ ./cargo test
 ```
 
 ### Starting a local testnet
-Start your own testnet locally, instructions are in the [online docs](https://docs.solana.com/cluster/bench-tps).
+
+Start your own testnet locally, instructions are in the [online docs](https://docs.solanalabs.com/clusters/benchmark).
 
 ### Accessing the remote development cluster
+
 * `devnet` - stable public cluster for development accessible via
-devnet.solana.com. Runs 24/7. Learn more about the [public clusters](https://docs.solana.com/clusters)
+devnet.solana.com. Runs 24/7. Learn more about the [public clusters](https://docs.solanalabs.com/clusters)
 
 # Benchmarking
 

accounts-db/src/append_vec.rs

@@ -2,7 +2,7 @@
 //!
 //! For more information, see:
 //!
-//! <https://docs.solana.com/implemented-proposals/persistent-account-storage>
+//! <https://docs.solanalabs.com/implemented-proposals/persistent-account-storage>
 
 use {
     crate::{

clap-utils/src/nonce.rs

@@ -9,7 +9,7 @@ pub const NONCE_ARG: ArgConstant<'static> = ArgConstant {
     help: "Provide the nonce account to use when creating a nonced \n\
            transaction. Nonced transactions are useful when a transaction \n\
            requires a lengthy signing process. Learn more about nonced \n\
-           transactions at https://docs.solana.com/offline-signing/durable-nonce",
+           transactions at https://docs.solanalabs.com/cli/examples/durable-nonce",
 };
 
 pub const NONCE_AUTHORITY_ARG: ArgConstant<'static> = ArgConstant {

clap-v3-utils/src/nonce.rs

@@ -9,7 +9,7 @@ pub const NONCE_ARG: ArgConstant<'static> = ArgConstant {
     help: "Provide the nonce account to use when creating a nonced \n\
            transaction. Nonced transactions are useful when a transaction \n\
            requires a lengthy signing process. Learn more about nonced \n\
-           transactions at https://docs.solana.com/offline-signing/durable-nonce",
+           transactions at https://docs.solanalabs.com/cli/examples/durable-nonce",
 };
 
 pub const NONCE_AUTHORITY_ARG: ArgConstant<'static> = ArgConstant {

cli-config/src/config.rs

@@ -34,7 +34,7 @@ pub struct Config {
     ///
     /// For local testing, the typical value is `http://localhost:8899`.
     ///
-    /// [rpcdocs]: https://docs.solana.com/cluster/rpc-endpoints
+    /// [rpcdocs]: https://solana.com/docs/core/clusters
     pub json_rpc_url: String,
     /// The address to connect to for receiving event notifications.
     ///

core/tests/fork-selection.rs

@@ -1,6 +1,6 @@
 //! Fork Selection Simulation
 //!
-//! Description of the algorithm can be found in [docs/src/cluster/managing-forks.md](docs/src/cluster/managing-forks.md).
+//! Description of the algorithm can be found in [Managing Forks](https://docs.solanalabs.com/consensus/managing-forks).
 //!
 //! A test library function exists for configuring networks.
 //! ```

docs/README.md

@@ -1,8 +1,17 @@
 # Solana Validator Docs Readme
 
-This validator's docs are built using [Docusaurus v2](https://v2.docusaurus.io/) with `npm`.
+This validator's documentation is built using [Docusaurus v2](https://v2.docusaurus.io/) with `npm`.
 Static content delivery is handled using `vercel`.
 
+> Note: The documentation within this repo is specifically focused on the
+> Solana validator client maintained by Solana Labs. The more "common"
+> documentation which is generalize to the Solana protocol as a whole, and apply
+> to all Solana validator implementations, are maintained within the
+> [`developer-content`](https://github.com/solana-foundation/developer-content/)
+> repo. Those "common docs" are manged by the Solana Foundation within their
+> GitHub organization and are publicly accessible via
+> [solana.com/docs](https://solana.com/docs)
+
 ## Local Development
 
 To set up the Solana Validator Docs site locally:

docs/publish-docs.sh

@@ -121,6 +121,7 @@ cat > "$CONFIG_FILE" <<EOF
     { "destination": "https://solana.com/docs/core/transactions/retry", "source": "/integrations/retrying-transactions" },
     { "destination": "https://solana.com/docs/intro/dev", "source": "/developing/programming-model/overview" },
     { "destination": "https://solana.com/docs/advanced/lookup-tables", "source": "/developing/lookup-tables" },
+    { "destination": "https://solana.com/docs", "source": "/developers" },
     { "destination": "https://solana.com/docs/advanced/state-compression", "source": "/learn/state-compression" },
     { "destination": "https://solana.com/developers/guides/javascript/compressed-nfts", "source": "/developing/guides/compressed-nfts" },
     { "destination": "https://solana.com/docs/programs", "source": "/developing/on-chain-programs/overview" },

docs/src/implemented-proposals/rpc-transaction-history.md

@@ -4,18 +4,17 @@ There's a need for RPC to serve at least 6 months of transaction history. The
 current history, on the order of days, is insufficient for downstream users.
 
 6 months of transaction data cannot be stored practically in a validator's
-rocksdb ledger so an external data store is necessary. The validator's
-rocksdb ledger will continue to serve as the primary data source, and then will
-fall back to the external data store.
+rocksdb ledger so an external data store is necessary. The validator's rocksdb
+ledger will continue to serve as the primary data source, and then will fall
+back to the external data store.
 
 The affected RPC endpoints are:
 
-
 - [getFirstAvailableBlock](https://solana.com/docs/rpc/http/getfirstavailableblock)
-- [getConfirmedBlock](https://solana.com/docs/rpc/http/getconfirmedblock)
-- [getConfirmedBlocks](https://solana.com/docs/rpc/http/getconfirmedblocks)
+- [getConfirmedBlock](https://solana.com/docs/rpc/deprecated/getconfirmedblock)
+- [getConfirmedBlocks](https://solana.com/docs/rpc/deprecated/getconfirmedblocks)
 - [getConfirmedSignaturesForAddress](https://solana.com/docs/rpc/http/getconfirmedsignaturesforaddress)
-- [getConfirmedTransaction](https://solana.com/docs/rpc/http/getconfirmedtransaction)
+- [getConfirmedTransaction](https://solana.com/docs/rpc/deprecated/getConfirmedTransaction)
 - [getSignatureStatuses](https://solana.com/docs/rpc/http/getsignaturestatuses)
 - [getBlockTime](https://solana.com/docs/rpc/http/getblocktime)
 
@@ -41,19 +40,19 @@ store.
 A BigTable instance is used to hold all transaction data, broken up into
 different tables for quick searching.
 
-New data may be copied into the instance at anytime without affecting the existing
-data, and all data is immutable. Generally the expectation is that new data
-will be uploaded once an current epoch completes but there is no limitation on
-the frequency of data dumps.
+New data may be copied into the instance at anytime without affecting the
+existing data, and all data is immutable. Generally the expectation is that new
+data will be uploaded once an current epoch completes but there is no limitation
+on the frequency of data dumps.
 
 Cleanup of old data is automatic by configuring the data retention policy of the
-instance tables appropriately, it just disappears. Therefore the order of when data is
-added becomes important. For example if data from epoch N-1 is added after data
-from epoch N, the older epoch data will outlive the newer data. However beyond
-producing _holes_ in query results, this kind of unordered deletion will
-have no ill effect. Note that this method of cleanup effectively allows for an
-unlimited amount of transaction data to be stored, restricted only by the
-monetary costs of doing so.
+instance tables appropriately, it just disappears. Therefore the order of when
+data is added becomes important. For example if data from epoch N-1 is added
+after data from epoch N, the older epoch data will outlive the newer data.
+However beyond producing _holes_ in query results, this kind of unordered
+deletion will have no ill effect. Note that this method of cleanup effectively
+allows for an unlimited amount of transaction data to be stored, restricted only
+by the monetary costs of doing so.
 
 The table layout s supports the existing RPC endpoints only. New RPC endpoints
 in the future may require additions to the schema and potentially iterating over
@@ -62,15 +61,15 @@ all transactions to build up the necessary metadata.
 ## Accessing BigTable
 
 BigTable has a gRPC endpoint that can be accessed using the
-[tonic](https://crates.io/crates/crate)] and the raw protobuf API, as currently no
-higher-level Rust crate for BigTable exists. Practically this makes parsing the
-results of BigTable queries more complicated but is not a significant issue.
+[tonic](https://crates.io/crates/crate)] and the raw protobuf API, as currently
+no higher-level Rust crate for BigTable exists. Practically this makes parsing
+the results of BigTable queries more complicated but is not a significant issue.
 
 ## Data Population
 
-The ongoing population of instance data will occur on an epoch cadence through the
-use of a new `solana-ledger-tool` command that will convert rocksdb data for a
-given slot range into the instance schema.
+The ongoing population of instance data will occur on an epoch cadence through
+the use of a new `solana-ledger-tool` command that will convert rocksdb data for
+a given slot range into the instance schema.
 
 The same process will be run once, manually, to backfill the existing ledger
 data.
@@ -81,28 +80,30 @@ This table contains the compressed block data for a given slot.
 
 The row key is generated by taking the 16 digit lower case hexadecimal
 representation of the slot, to ensure that the oldest slot with a confirmed
-block will always be first when the rows are listed. eg, The row key for slot
-42 would be 000000000000002a.
+block will always be first when the rows are listed. eg, The row key for slot 42
+would be 000000000000002a.
 
 The row data is a compressed `StoredConfirmedBlock` struct.
 
 ### Account Address Transaction Signature Lookup Table: `tx-by-addr`
 
 This table contains the transactions that affect a given address.
 
-The row key is `<base58 address>/<slot-id-one's-compliment-hex-slot-0-prefixed-to-16-digits>`. The row
-data is a compressed `TransactionByAddrInfo` struct.
+The row key is
+`<base58 address>/<slot-id-one's-compliment-hex-slot-0-prefixed-to-16-digits>`.
+The row data is a compressed `TransactionByAddrInfo` struct.
 
 Taking the one's compliment of the slot allows for listing of slots ensures that
-the newest slot with transactions that affect an address will always
-be listed first.
+the newest slot with transactions that affect an address will always be listed
+first.
 
-Sysvar addresses are not indexed. However frequently used programs such as
-Vote or System are, and will likely have a row for every confirmed slot.
+Sysvar addresses are not indexed. However frequently used programs such as Vote
+or System are, and will likely have a row for every confirmed slot.
 
 ### Transaction Signature Lookup Table: `tx`
 
-This table maps a transaction signature to its confirmed block, and index within that block.
+This table maps a transaction signature to its confirmed block, and index within
+that block.
 
 The row key is the base58-encoded transaction signature.
 The row data is a compressed `TransactionInfo` struct.

docs/src/operations/guides/validator-stake.md

@@ -96,7 +96,7 @@ account.
 This is a normal transaction so the standard transaction fee will apply. The
 transaction fee range is defined by the genesis block. The actual fee will
 fluctuate based on transaction load. You can determine the current fee via the
-[RPC API “getRecentBlockhash”](https://solana.com/docs/rpc/http/getrecentblockhash) before submitting
+[RPC API “getRecentBlockhash”](https://solana.com/docs/rpc/deprecated/getrecentblockhash) before submitting
 a transaction.
 
 Learn more about

geyser-plugin-interface/README.md

@@ -20,6 +20,6 @@ The https://github.com/solana-labs/solana-accountsdb-plugin-postgres repository
 provides an example of how to create a plugin which saves the accounts data into
 an external PostgreSQL database.
 
-More information about Solana is available in the [Solana documentation](https://docs.solana.com/).
+More information about Solana is available in the [Solana documentation](https://solana.com/docs).
 
 Still have questions?  Ask us on [Stack Exchange](https://sola.na/sse)

ledger/src/blockstore.rs

@@ -4629,7 +4629,7 @@ fn adjust_ulimit_nofile(enforce_ulimit_nofile: bool) -> Result<()> {
     // usually not enough
     // AppendVecs and disk Account Index are also heavy users of mmapped files.
     // This should be kept in sync with published validator instructions.
-    // https://docs.solana.com/running-validator/validator-start#increased-memory-mapped-files-limit
+    // https://docs.solanalabs.com/operations/guides/validator-start#increased-memory-mapped-files-limit
     let desired_nofile = 1_000_000;
 
     fn get_nofile() -> libc::rlimit {

program-runtime/src/accounts_data_meter.rs

@@ -4,7 +4,7 @@
 
 /// The maximum allowed size, in bytes, of the accounts data
 /// 128 GB was chosen because it is the RAM amount listed under Hardware Recommendations on
-/// [Validator Requirements](https://docs.solana.com/running-validator/validator-reqs), and
+/// [Validator Requirements](https://docs.solanalabs.com/operations/requirements), and
 /// validators often put the ledger on a RAM disk (i.e. tmpfs).
 pub const MAX_ACCOUNTS_DATA_LEN: u64 = 128_000_000_000;
 

pubsub-client/src/nonblocking/pubsub_client.rs

@@ -3,7 +3,7 @@
 //! The [`PubsubClient`] implements [Solana WebSocket event
 //! subscriptions][spec].
 //!
-//! [spec]: https://docs.solana.com/api/websocket#subscription-websocket
+//! [spec]: https://solana.com/docs/rpc/websocket
 //!
 //! This is a nonblocking (async) API. For a blocking API use the synchronous
 //! client in [`crate::pubsub_client`].
@@ -366,7 +366,7 @@ impl PubsubClient {
     ///
     /// This method corresponds directly to the [`accountSubscribe`] RPC method.
     ///
-    /// [`accountSubscribe`]: https://docs.solana.com/api/websocket#accountsubscribe
+    /// [`accountSubscribe`]: https://solana.com/docs/rpc/websocket#accountsubscribe
     pub async fn account_subscribe(
         &self,
         pubkey: &Pubkey,
@@ -387,7 +387,7 @@ impl PubsubClient {
     ///
     /// This method corresponds directly to the [`blockSubscribe`] RPC method.
     ///
-    /// [`blockSubscribe`]: https://docs.solana.com/api/websocket#blocksubscribe
+    /// [`blockSubscribe`]: https://solana.com/docs/rpc/websocket#blocksubscribe
     pub async fn block_subscribe(
         &self,
         filter: RpcBlockSubscribeFilter,
@@ -404,7 +404,7 @@ impl PubsubClient {
     ///
     /// This method corresponds directly to the [`logsSubscribe`] RPC method.
     ///
-    /// [`logsSubscribe`]: https://docs.solana.com/api/websocket#logssubscribe
+    /// [`logsSubscribe`]: https://solana.com/docs/rpc/websocket#logssubscribe
     pub async fn logs_subscribe(
         &self,
         filter: RpcTransactionLogsFilter,
@@ -422,7 +422,7 @@ impl PubsubClient {
     ///
     /// This method corresponds directly to the [`programSubscribe`] RPC method.
     ///
-    /// [`programSubscribe`]: https://docs.solana.com/api/websocket#programsubscribe
+    /// [`programSubscribe`]: https://solana.com/docs/rpc/websocket#programsubscribe
     pub async fn program_subscribe(
         &self,
         pubkey: &Pubkey,
@@ -458,7 +458,7 @@ impl PubsubClient {
     ///
     /// This method corresponds directly to the [`voteSubscribe`] RPC method.
     ///
-    /// [`voteSubscribe`]: https://docs.solana.com/api/websocket#votesubscribe
+    /// [`voteSubscribe`]: https://solana.com/docs/rpc/websocket#votesubscribe
     pub async fn vote_subscribe(&self) -> SubscribeResult<'_, RpcVote> {
         self.subscribe("vote", json!([])).await
     }
@@ -468,13 +468,13 @@ impl PubsubClient {
     /// Receives messages of type [`Slot`] when a new [root] is set by the
     /// validator.
     ///
-    /// [root]: https://docs.solana.com/terminology#root
+    /// [root]: https://solana.com/docs/terminology#root
     ///
     /// # RPC Reference
     ///
     /// This method corresponds directly to the [`rootSubscribe`] RPC method.
     ///
-    /// [`rootSubscribe`]: https://docs.solana.com/api/websocket#rootsubscribe
+    /// [`rootSubscribe`]: https://solana.com/docs/rpc/websocket#rootsubscribe
     pub async fn root_subscribe(&self) -> SubscribeResult<'_, Slot> {
         self.subscribe("root", json!([])).await
     }
@@ -491,7 +491,7 @@ impl PubsubClient {
     ///
     /// This method corresponds directly to the [`signatureSubscribe`] RPC method.
     ///
-    /// [`signatureSubscribe`]: https://docs.solana.com/api/websocket#signaturesubscribe
+    /// [`signatureSubscribe`]: https://solana.com/docs/rpc/websocket#signaturesubscribe
     pub async fn signature_subscribe(
         &self,
         signature: &Signature,
@@ -509,7 +509,7 @@ impl PubsubClient {
     ///
     /// This method corresponds directly to the [`slotSubscribe`] RPC method.
     ///
-    /// [`slotSubscribe`]: https://docs.solana.com/api/websocket#slotsubscribe
+    /// [`slotSubscribe`]: https://solana.com/docs/rpc/websocket#slotsubscribe
     pub async fn slot_subscribe(&self) -> SubscribeResult<'_, SlotInfo> {
         self.subscribe("slot", json!([])).await
     }
@@ -527,7 +527,7 @@ impl PubsubClient {
     ///
     /// This method corresponds directly to the [`slotUpdatesSubscribe`] RPC method.
     ///
-    /// [`slotUpdatesSubscribe`]: https://docs.solana.com/api/websocket#slotsupdatessubscribe
+    /// [`slotUpdatesSubscribe`]: https://solana.com/docs/rpc/websocket#slotsupdatessubscribe
     pub async fn slot_updates_subscribe(&self) -> SubscribeResult<'_, SlotUpdate> {
         self.subscribe("slotsUpdates", json!([])).await
     }