[docs] updated page metadata and minor fixes (#35059)
feat: updated metadata
This commit is contained in:
Nick Frostbutter
GitHub
parent
dd30175e55
commit
919b306733
|
|
@ -58,6 +58,6 @@ in_subcommands=0
|
|||
while read -r subcommand rest; do
|
||||
[[ $subcommand == "SUBCOMMANDS:" ]] && in_subcommands=1 && continue
|
||||
if ((in_subcommands)); then
|
||||
section "$(cargo -q run -p solana-cli -- help "$subcommand" | sed -e 's|'"$HOME"'|~|g' -e 's/[[:space:]]\+$//')" "####" >> "$out"
|
||||
section "$(cargo -q run -p solana-cli -- help "$subcommand" | sed -e 's|'"$HOME"'|~|g' -e 's/[[:space:]]\+$//')" "###" >> "$out"
|
||||
fi
|
||||
done <<<"$usage">>"$out"
|
||||
|
|
|
|||
|
|
@ -62,7 +62,7 @@ cat > "$CONFIG_FILE" <<EOF
|
|||
{ "source": "/wallet-guide/file-system-wallet", "destination": "/cli/wallets/file-system" },
|
||||
{ "source": "/wallet-guide/hardware-wallet", "destination": "/cli/wallets/hardware-wallet" },
|
||||
{ "source": "/wallet-guide/hardware-wallet/ledger", "destination": "/cli/wallets/hardware-wallet/ledger" },
|
||||
{ "source": "/cluster/overview", "destination": "/clusters/index" },
|
||||
{ "source": "/cluster/overview", "destination": "/clusters" },
|
||||
{ "source": "/cluster/bench-tps", "destination": "/clusters/benchmark" },
|
||||
{ "source": "/cluster/performance-metrics", "destination": "/clusters/metrics" },
|
||||
{ "source": "/running-validator", "destination": "/operations" },
|
||||
|
|
|
|||
|
|
@ -79,10 +79,6 @@ module.exports = {
|
|||
type: "category",
|
||||
label: "Operating a Validator",
|
||||
// collapsed: false,
|
||||
link: {
|
||||
type: "doc",
|
||||
id: "operations/index",
|
||||
},
|
||||
items: [
|
||||
{
|
||||
type: "autogenerated",
|
||||
|
|
|
|||
|
|
@ -1,7 +1,8 @@
|
|||
---
|
||||
title: Architecture
|
||||
sidebar_label: Overview
|
||||
title: Solana Validator Architecture
|
||||
sidebar_position: 0
|
||||
sidebar_label: Overview
|
||||
pagination_label: Solana Validator Architecture
|
||||
---
|
||||
|
||||
In this section, we will describe the architecture.
|
||||
In this section, we will describe the architecture of the Solana Validator.
|
||||
|
|
|
|||
|
|
@ -1,5 +1,6 @@
|
|||
---
|
||||
title: Solana CLI Reference and Usage
|
||||
pagination_label: Solana CLI Reference and Usage
|
||||
sidebar_label: Reference & Usage
|
||||
sidebar_position: 3
|
||||
---
|
||||
|
|
|
|||
|
|
@ -1,5 +1,7 @@
|
|||
---
|
||||
title: Connecting to a Cluster
|
||||
title: Connecting to a Cluster with the Solana CLI
|
||||
pagination_label: "Solana CLI: Connecting to a Cluster"
|
||||
sidebar_label: Connecting to a Cluster
|
||||
---
|
||||
|
||||
See [Solana Clusters](../../clusters/available.md) for general information about the
|
||||
|
|
|
|||
|
|
@ -1,10 +1,7 @@
|
|||
---
|
||||
title: Staking
|
||||
---
|
||||
|
||||
For an overview of staking, read first the
|
||||
[Staking and Inflation FAQ](https://solana.com/staking).
|
||||
|
||||
title: Staking SOL with the Solana CLI
|
||||
pagination_label: "Solana CLI: Staking"
|
||||
sidebar_label: Staking
|
||||
---
|
||||
|
||||
After you have [received SOL](./transfer-tokens.md), you might consider putting it
|
||||
|
|
@ -15,6 +12,11 @@ valid block of transactions in the blockchain. Solana then generates new SOL
|
|||
periodically to reward stakers and validators. You earn more rewards the more
|
||||
stake you delegate.
|
||||
|
||||
:::info
|
||||
For an overview of staking, read first the
|
||||
[Staking and Inflation FAQ](https://solana.com/staking).
|
||||
:::
|
||||
|
||||
## Create a Stake Account
|
||||
|
||||
To delegate stake, you will need to transfer some tokens into a stake account.
|
||||
|
|
|
|||
|
|
@ -1,5 +1,7 @@
|
|||
---
|
||||
title: Deploy a Program
|
||||
title: Deploy a Solana Program with the CLI
|
||||
pagination_label: "Solana CLI: Deploy a Program"
|
||||
sidebar_label: Deploy a Program
|
||||
---
|
||||
|
||||
Developers can deploy on-chain
|
||||
|
|
@ -23,9 +25,7 @@ to:
|
|||
Once deployed, anyone can execute the program by sending transactions that
|
||||
reference it to the cluster.
|
||||
|
||||
## Usage
|
||||
|
||||
### Deploy a program
|
||||
## How to deploy a program
|
||||
|
||||
To deploy a program, you will need the location of the program's shared object
|
||||
(the program binary `.so`):
|
||||
|
|
@ -60,7 +60,7 @@ generated automatically by the program build tools:
|
|||
./path-to-program/program-keypair.json
|
||||
```
|
||||
|
||||
### Showing a program account
|
||||
## Showing a program account
|
||||
|
||||
To get information about a deployed program:
|
||||
|
||||
|
|
@ -89,7 +89,7 @@ Data Length: 5216 (0x1460) bytes
|
|||
- `Data Length` is the size of the space reserved for deployments. The actual
|
||||
space used by the currently deployed program may be less.
|
||||
|
||||
### Redeploy a program
|
||||
## Redeploy a Solana program
|
||||
|
||||
A program can be redeployed to the same address to facilitate rapid development,
|
||||
bug fixes, or upgrades. If a program id is not provided, the program will be
|
||||
|
|
@ -111,7 +111,7 @@ size (in bytes) that the program is expected to become (plus some wiggle room).
|
|||
solana program deploy --max-len 200000 <PROGRAM_FILEPATH>
|
||||
```
|
||||
|
||||
### Extend a program
|
||||
## Extend a program
|
||||
|
||||
If a program has already been deployed, and a redeployment goes beyond the
|
||||
`max_len` of the account, it's possible to extend the program to fit the larger
|
||||
|
|
@ -121,7 +121,7 @@ redeployment:
|
|||
solana program extend <PROGRAM_ID> <ADDITIONAL_BYTES>
|
||||
```
|
||||
|
||||
### Resuming a failed deploy
|
||||
## Resuming a failed deploy
|
||||
|
||||
If program deployment fails, there will be a hanging intermediate buffer account
|
||||
that contains a non-zero balance. In order to recoup that balance you may resume
|
||||
|
|
@ -159,7 +159,7 @@ Then issue a new `deploy` command and specify the buffer:
|
|||
solana program deploy --buffer <KEYPAIR_PATH> <PROGRAM_FILEPATH>
|
||||
```
|
||||
|
||||
### Closing program and buffer accounts, and reclaiming their lamports
|
||||
## Closing program and buffer accounts, and reclaiming their lamports
|
||||
|
||||
Both program and buffer accounts can be closed and their lamport balances
|
||||
transferred to a recipient's account.
|
||||
|
|
@ -214,7 +214,7 @@ To show all buffer accounts regardless of the authority
|
|||
solana program show --buffers --all
|
||||
```
|
||||
|
||||
### Set a program's upgrade authority
|
||||
## Set a program's upgrade authority
|
||||
|
||||
The program's upgrade authority must be present to deploy a program. If no
|
||||
authority is specified during program deployment, the default keypair is used as
|
||||
|
|
@ -245,7 +245,7 @@ they do not have access to. The `--skip-new-upgrade-authority-signer-check`
|
|||
option relaxes the signer check. This can be useful for situations where the new
|
||||
upgrade authority is an offline signer or a multisig.
|
||||
|
||||
### Immutable programs
|
||||
## Immutable programs
|
||||
|
||||
A program can be marked immutable, which prevents all further redeployments, by
|
||||
specifying the `--final` flag during deployment:
|
||||
|
|
@ -260,7 +260,7 @@ Or anytime after:
|
|||
solana program set-upgrade-authority <PROGRAM_ADDRESS> --final
|
||||
```
|
||||
|
||||
### Dumping a program to a file
|
||||
## Dumping a program to a file
|
||||
|
||||
The deployed program may be dumped back to a local file:
|
||||
|
||||
|
|
@ -283,7 +283,7 @@ $ truncate -r dump.so extended.so
|
|||
$ sha256sum extended.so dump.so
|
||||
```
|
||||
|
||||
### Using an intermediary Buffer account
|
||||
## Using an intermediary Buffer account
|
||||
|
||||
Instead of deploying directly to the program account, the program can be written
|
||||
to an intermediary buffer account. Intermediary accounts can be useful for
|
||||
|
|
@ -328,7 +328,7 @@ account are refunded to a spill account.
|
|||
|
||||
Buffers also support `show` and `dump` just like programs do.
|
||||
|
||||
### Upgrading program using offline signer as authority
|
||||
## Upgrading program using offline signer as authority
|
||||
|
||||
Some security models require separating the signing process from the transaction broadcast, such that the signing keys can be completely disconnected from any network, also known as [offline signing](offline-signing.md).
|
||||
|
||||
|
|
|
|||
|
|
@ -1,5 +1,7 @@
|
|||
---
|
||||
title: Durable Transaction Nonces
|
||||
title: Durable Transaction Nonces in the Solana CLI
|
||||
pagination_label: "Solana CLI: Durable Transaction Nonces"
|
||||
sidebar_label: Durable Transaction Nonces
|
||||
---
|
||||
|
||||
Durable transaction nonces are a mechanism for getting around the typical short
|
||||
|
|
|
|||
|
|
@ -1,5 +1,7 @@
|
|||
---
|
||||
title: Offline Transaction Signing
|
||||
title: Offline Transaction Signing with the Solana CLI
|
||||
pagination_label: "Solana CLI: Offline Transaction Signing"
|
||||
sidebar_label: Offline Transaction Signing
|
||||
---
|
||||
|
||||
Some security models require keeping signing keys, and thus the signing
|
||||
|
|
|
|||
|
|
@ -1,5 +1,7 @@
|
|||
---
|
||||
title: Off-Chain Message Signing
|
||||
title: Off-Chain Message Signing with the Solana CLI
|
||||
pagination_label: "Solana CLI: Off-Chain Message Signing"
|
||||
sidebar_label: Off-Chain Message Signing
|
||||
---
|
||||
|
||||
Off-chain message signing is a method of signing non-transaction messages with
|
||||
|
|
|
|||
|
|
@ -1,5 +1,6 @@
|
|||
---
|
||||
title: Solana Test Validator
|
||||
pagination_label: "Solana CLI: Test Validator"
|
||||
sidebar_label: Test Validator
|
||||
---
|
||||
|
||||
|
|
|
|||
|
|
@ -1,5 +1,7 @@
|
|||
---
|
||||
title: Send and Receive Tokens
|
||||
title: Send and Receive Tokens with the Solana CLI
|
||||
pagination_label: "Solana CLI: Send and Receive Tokens"
|
||||
sidebar_label: Send and Receive Tokens
|
||||
---
|
||||
|
||||
This page describes how to receive and send SOL tokens using the command line
|
||||
|
|
|
|||
|
|
@ -1,7 +1,8 @@
|
|||
---
|
||||
title: Solana CLI Tool Suite
|
||||
sidebar_label: Overview
|
||||
sidebar_position: 0
|
||||
sidebar_label: Overview
|
||||
pagination_label: Solana CLI Tool Suite
|
||||
---
|
||||
|
||||
In this section, we will describe how to use the Solana command-line tools to
|
||||
|
|
@ -19,6 +20,6 @@ secure access to your Solana accounts.
|
|||
To get started using the Solana Command Line (CLI) tools:
|
||||
|
||||
- [Install the Solana CLI Tool Suite](./install.md)
|
||||
- [Choose a Cluster](./examples/choose-a-cluster.md)
|
||||
- [Create a Wallet](./wallets/index.md)
|
||||
- [Introduction to our CLI conventions](./intro.md)
|
||||
- [Create a Wallet using the CLI](./wallets/index.md)
|
||||
- [Choose a Cluster to connect to using the CLI](./examples/choose-a-cluster.md)
|
||||
|
|
|
|||
|
|
@ -1,5 +1,6 @@
|
|||
---
|
||||
title: Install the Solana CLI
|
||||
pagination_label: Install the Solana CLI
|
||||
sidebar_label: Installation
|
||||
sidebar_position: 1
|
||||
---
|
||||
|
|
|
|||
|
|
@ -1,5 +1,6 @@
|
|||
---
|
||||
title: Introduction to the Solana CLI
|
||||
pagination_label: Introduction to the Solana CLI
|
||||
sidebar_label: Introduction
|
||||
sidebar_position: 2
|
||||
---
|
||||
|
|
@ -45,7 +46,7 @@ solana-keygen pubkey <KEYPAIR>
|
|||
Below, we show how to resolve what you should put in `<KEYPAIR>` depending
|
||||
on your wallet type.
|
||||
|
||||
#### Paper Wallet
|
||||
## Paper Wallet
|
||||
|
||||
In a paper wallet, the keypair is securely derived from the seed words and
|
||||
optional passphrase you entered when the wallet was created. To use a paper
|
||||
|
|
@ -59,7 +60,7 @@ To display the wallet address of a Paper Wallet:
|
|||
solana-keygen pubkey prompt://
|
||||
```
|
||||
|
||||
#### File System Wallet
|
||||
## File System Wallet
|
||||
|
||||
With a file system wallet, the keypair is stored in a file on your computer.
|
||||
Replace `<KEYPAIR>` with the complete file path to the keypair file.
|
||||
|
|
@ -71,7 +72,7 @@ For example, if the file system keypair file location is
|
|||
solana-keygen pubkey /home/solana/my_wallet.json
|
||||
```
|
||||
|
||||
#### Hardware Wallet
|
||||
## Hardware Wallet
|
||||
|
||||
If you chose a hardware wallet, use your
|
||||
[keypair URL](./wallets/hardware/index.md#specify-a-hardware-wallet-key),
|
||||
|
|
|
|||
|
|
@ -1,5 +1,7 @@
|
|||
---
|
||||
title: File System Wallets
|
||||
title: File System Wallets using the CLI
|
||||
pagination_label: File System Wallets using the CLI
|
||||
sidebar_label: File System Wallets
|
||||
sidebar_position: 2
|
||||
---
|
||||
|
||||
|
|
|
|||
|
|
@ -1,5 +1,6 @@
|
|||
---
|
||||
title: Using Hardware Wallets in the Solana CLI
|
||||
pagination_label: "Using Hardware Wallets in the Solana CLI"
|
||||
sidebar_label: Using in the Solana CLI
|
||||
sidebar_position: 0
|
||||
---
|
||||
|
|
|
|||
|
|
@ -1,5 +1,6 @@
|
|||
---
|
||||
title: Using Ledger Nano Hardware Wallets in the Solana CLI
|
||||
pagination_label: "Hardware Wallets in the Solana CLI: Ledger Nano"
|
||||
sidebar_label: Ledger Nano
|
||||
---
|
||||
|
||||
|
|
|
|||
|
|
@ -1,5 +1,6 @@
|
|||
---
|
||||
title: Command Line Wallets
|
||||
title: Solana Wallets with the CLI
|
||||
pagination_label: Command Line Wallets
|
||||
sidebar_label: Overview
|
||||
sidebar_position: 0
|
||||
---
|
||||
|
|
|
|||
|
|
@ -1,5 +1,7 @@
|
|||
---
|
||||
title: Paper Wallets
|
||||
title: Paper Wallets using the Solana CLI
|
||||
pagination_label: Paper Wallets using the CLI
|
||||
sidebar_label: Paper Wallets
|
||||
sidebar_position: 1
|
||||
---
|
||||
|
||||
|
|
|
|||
|
|
@ -1,5 +1,7 @@
|
|||
---
|
||||
title: Solana Clusters
|
||||
title: Available Solana Clusters
|
||||
sidebar_label: Solana Clusters
|
||||
pagination_label: Available Solana Clusters
|
||||
---
|
||||
|
||||
Solana maintains several different clusters with different purposes.
|
||||
|
|
|
|||
|
|
@ -1,7 +1,8 @@
|
|||
---
|
||||
title: A Solana Cluster
|
||||
sidebar_label: Overview
|
||||
title: Overview of a Solana Cluster
|
||||
sidebar_position: 0
|
||||
sidebar_label: Overview
|
||||
pagination_label: Overview of a Solana Cluster
|
||||
---
|
||||
|
||||
A Solana cluster is a set of validators working together to serve client transactions and maintain the integrity of the ledger. Many clusters may coexist. When two clusters share a common genesis block, they attempt to converge. Otherwise, they simply ignore the existence of the other. Transactions sent to the wrong one are quietly rejected. In this section, we'll discuss how a cluster is created, how nodes join the cluster, how they share the ledger, how they ensure the ledger is replicated, and how they cope with buggy and malicious nodes.
|
||||
|
|
|
|||
|
|
@ -1,5 +1,7 @@
|
|||
---
|
||||
title: Performance Metrics
|
||||
title: Solana Cluster Performance Metrics
|
||||
sidebar_label: Performance Metrics
|
||||
pagination_label: Cluster Performance Metrics
|
||||
---
|
||||
|
||||
Solana cluster performance is measured as average number of transactions per second that the network can sustain \(TPS\). And, how long it takes for a transaction to be confirmed by super majority of the cluster \(Confirmation Time\).
|
||||
|
|
|
|||
|
|
@ -1,5 +1,7 @@
|
|||
---
|
||||
title: Commitment Status
|
||||
title: Solana Commitment Status
|
||||
sidebar_label: Commitment Status
|
||||
pagination_label: Consensus Commitment Status
|
||||
description:
|
||||
"Processed, confirmed, and finalized. Learn the differences between the
|
||||
different commitment statuses on the Solana blockchain."
|
||||
|
|
|
|||
|
|
@ -1,5 +1,7 @@
|
|||
---
|
||||
title: Leader Rotation
|
||||
title: Solana Leader Rotation
|
||||
sidebar_label: Leader Rotation
|
||||
pagination_label: Leader Rotation
|
||||
---
|
||||
|
||||
At any given moment, a cluster expects only one validator to produce ledger entries. By having only one leader at a time, all validators are able to replay identical copies of the ledger. The drawback of only one leader at a time, however, is that a malicious leader is capable of censoring votes and transactions. Since censoring cannot be distinguished from the network dropping packets, the cluster cannot simply elect a single node to hold the leader role indefinitely. Instead, the cluster minimizes the influence of a malicious leader by rotating which node takes the lead.
|
||||
|
|
|
|||
|
|
@ -3,10 +3,10 @@ slug: /
|
|||
id: home
|
||||
title: Home
|
||||
sidebar_label: Home
|
||||
pagination_label: Solana Validator Documentation Home
|
||||
description: "Solana is a high performance network that is utilized for a range
|
||||
of use cases, \
|
||||
including finance, NFTs, payments, and gaming."
|
||||
# displayed_sidebar: introductionSidebar
|
||||
---
|
||||
|
||||
# Solana Validator Documentation
|
||||
|
|
|
|||
|
|
@ -2,9 +2,5 @@
|
|||
"position": 4,
|
||||
"label": "Operating a Validator",
|
||||
"collapsible": true,
|
||||
"collapsed": true,
|
||||
"link": {
|
||||
"type": "doc",
|
||||
"id": "operations/index"
|
||||
}
|
||||
"collapsed": true
|
||||
}
|
||||
|
|
|
|||
|
|
@ -1,6 +1,7 @@
|
|||
---
|
||||
title: Validator Operations Best Practices
|
||||
title: Solana Validator Operations Best Practices
|
||||
sidebar_label: General Operations
|
||||
pagination_label: "Best Practices: Validator Operations"
|
||||
---
|
||||
|
||||
After you have successfully setup and started a
|
||||
|
|
|
|||
|
|
@ -1,6 +1,7 @@
|
|||
---
|
||||
title: Validator Monitoring Best Practices
|
||||
title: Solana Validator Monitoring Best Practices
|
||||
sidebar_label: Monitoring
|
||||
pagination_label: "Best Practices: Validator Monitoring"
|
||||
---
|
||||
|
||||
It is essential that you have monitoring in place on your validator. In the event that your validator is delinquent (behind the rest of the network) you want to respond immediately to fix the issue. One very useful tool to monitor your validator is [`solana-watchtower`](#solana-watchtower).
|
||||
|
|
|
|||
|
|
@ -1,6 +1,7 @@
|
|||
---
|
||||
title: Validator Security Best Practices
|
||||
title: Solana Validator Security Best Practices
|
||||
sidebar_label: Security
|
||||
pagination_label: "Best Practices: Validator Security"
|
||||
---
|
||||
|
||||
Being a system administrator for an Ubuntu computer requires technical knowledge of the system and best security practices. The following list should help you get started and is considered the bare minimum for keeping your system safe.
|
||||
|
|
|
|||
|
|
@ -1,4 +1,10 @@
|
|||
## Restarting a cluster
|
||||
---
|
||||
title: "Restarting a Solana Cluster"
|
||||
# really high number to ensure it is listed last in the sidebar
|
||||
sidebar_position: 999
|
||||
sidebar_label: Restart a Cluster
|
||||
pagination_label: "Validator Guides: Restart a Cluster"
|
||||
---
|
||||
|
||||
### Step 1. Identify the latest optimistically confirmed slot for the cluster
|
||||
|
||||
|
|
|
|||
|
|
@ -1,5 +1,8 @@
|
|||
---
|
||||
title: Failover Setup
|
||||
title: "Validator Guide: Setup Node Failover"
|
||||
sidebar_position: 9
|
||||
sidebar_label: Node Failover
|
||||
pagination_label: "Validator Guides: Node Failover"
|
||||
---
|
||||
|
||||
A simple two machine instance failover method is described here, which allows you to:
|
||||
|
|
|
|||
|
|
@ -1,5 +1,8 @@
|
|||
---
|
||||
title: Publishing Validator Info
|
||||
title: "Validator Guide: Publishing Validator Info"
|
||||
sidebar_position: 1
|
||||
sidebar_label: Publishing Validator Info
|
||||
pagination_label: "Validator Guides: Publishing Validator Info"
|
||||
---
|
||||
|
||||
You can publish your validator information to the chain to be publicly visible to other users.
|
||||
|
|
|
|||
|
|
@ -1,5 +1,8 @@
|
|||
---
|
||||
title: Monitoring a Validator
|
||||
title: "Validator Guide: Monitoring a Validator"
|
||||
sidebar_position: 2
|
||||
sidebar_label: Monitoring a Validator
|
||||
pagination_label: "Validator Guides: Monitoring a Validator"
|
||||
---
|
||||
|
||||
## Check Gossip
|
||||
|
|
|
|||
|
|
@ -1,5 +1,8 @@
|
|||
---
|
||||
title: Staking
|
||||
title: "Validator Guide: Staking"
|
||||
sidebar_position: 3
|
||||
sidebar_label: Staking
|
||||
pagination_label: "Validator Guides: Staking"
|
||||
---
|
||||
|
||||
**By default your validator will have no stake.** This means it will be
|
||||
|
|
|
|||
|
|
@ -1,5 +1,8 @@
|
|||
---
|
||||
title: Starting a Validator
|
||||
title: "Validator Guide: Starting a Validator"
|
||||
sidebar_position: 0
|
||||
sidebar_label: Starting a Validator
|
||||
pagination_label: "Validator Guides: Starting a Validator"
|
||||
---
|
||||
|
||||
## Configure Solana CLI
|
||||
|
|
|
|||
|
|
@ -1,5 +1,8 @@
|
|||
---
|
||||
title: Troubleshooting
|
||||
title: "Validator Guide: Troubleshooting"
|
||||
sidebar_position: 4
|
||||
sidebar_label: Troubleshooting
|
||||
pagination_label: "Validator Guides: Troubleshooting"
|
||||
---
|
||||
|
||||
There is a `#validator-support` Discord channel available to reach other
|
||||
|
|
|
|||
|
|
@ -1,5 +1,8 @@
|
|||
---
|
||||
title: Vote Account Management
|
||||
title: "Validator Guide: Vote Account Management"
|
||||
sidebar_position: 5
|
||||
sidebar_label: Vote Account Management
|
||||
pagination_label: "Validator Guides: Vote Account Management"
|
||||
---
|
||||
|
||||
This page describes how to set up an on-chain _vote account_. Creating a vote
|
||||
|
|
|
|||
|
|
@ -1,7 +1,8 @@
|
|||
---
|
||||
title: Solana Validator Prerequisites
|
||||
sidebar_label: Prerequisites
|
||||
sidebar_position: 2
|
||||
sidebar_label: Prerequisites
|
||||
pagination_label: Prerequisites to run a Validator
|
||||
---
|
||||
|
||||
Operating a Solana validator is an interesting and rewarding task. Generally speaking, it requires someone with a technical background but also involves community engagement and marketing.
|
||||
|
|
|
|||
|
|
@ -1,7 +1,8 @@
|
|||
---
|
||||
title: Validator Requirements
|
||||
sidebar_label: Requirements
|
||||
title: Solana Validator Requirements
|
||||
sidebar_position: 3
|
||||
sidebar_label: Requirements
|
||||
pagination_label: Requirements to Operate a Validator
|
||||
---
|
||||
|
||||
## Minimum SOL requirements
|
||||
|
|
|
|||
|
|
@ -1,7 +1,8 @@
|
|||
---
|
||||
title: Consensus Validator or RPC Node?
|
||||
sidebar_label: Validator vs RPC Node
|
||||
sidebar_position: 1
|
||||
sidebar_label: Validator vs RPC Node
|
||||
pagination_label: Consensus Validator vs RPC Node
|
||||
---
|
||||
|
||||
Operators who run a [consensus validator](../what-is-a-validator.md) have much
|
||||
|
|
|
|||
|
|
@ -1,5 +1,7 @@
|
|||
---
|
||||
title: "Native Programs"
|
||||
title: "Native Programs in the Solana Runtime"
|
||||
pagination_label: Runtime Native Programs
|
||||
sidebar_label: Native Programs
|
||||
---
|
||||
|
||||
Solana contains a small handful of native programs, which are required to run
|
||||
|
|
|
|||
|
|
@ -1,5 +1,7 @@
|
|||
---
|
||||
title: Sysvar Cluster Data
|
||||
title: Solana Sysvar Cluster Data
|
||||
pagination_label: Runtime Sysvar Cluster Data
|
||||
sidebar_label: Sysvar Cluster Data
|
||||
---
|
||||
|
||||
Solana exposes a variety of cluster state data to programs via
|
||||
|
|
|
|||
|
|
@ -1,5 +1,7 @@
|
|||
---
|
||||
title: ZK Token Proof Program
|
||||
title: Solana ZK Token Proof Program
|
||||
pagination_label: Native ZK Token Proof Program
|
||||
sidebar_label: ZK Token Proof Program
|
||||
---
|
||||
|
||||
The native Solana ZK Token proof program verifies a number of zero-knowledge
|
||||
|
|
|
|||
|
|
@ -1,7 +1,8 @@
|
|||
---
|
||||
title: Anatomy of a Validator
|
||||
sidebar_label: Anatomy
|
||||
sidebar_position: 1
|
||||
sidebar_label: Anatomy
|
||||
pagination_label: Anatomy of a Validator
|
||||
---
|
||||
|
||||
|
||||
|
|
|
|||
|
|
@ -1,6 +1,8 @@
|
|||
---
|
||||
title: Blockstore
|
||||
title: Blockstore in a Solana Validator
|
||||
sidebar_position: 3
|
||||
sidebar_label: Blockstore
|
||||
pagination_label: Validator Blockstore
|
||||
---
|
||||
|
||||
After a block reaches finality, all blocks from that one on down to the genesis block form a linear chain with the familiar name blockchain. Until that point, however, the validator must maintain all potentially valid chains, called _forks_. The process by which forks naturally form as a result of leader rotation is described in [fork generation](../consensus/fork-generation.md). The _blockstore_ data structure described here is how a validator copes with those forks until blocks are finalized.
|
||||
|
|
|
|||
|
|
@ -1,5 +1,7 @@
|
|||
---
|
||||
title: Geyser Plugins
|
||||
title: Solana Validator Geyser Plugins
|
||||
sidebar_label: Geyser Plugins
|
||||
pagination_label: Validator Geyser Plugins
|
||||
---
|
||||
|
||||
## Overview
|
||||
|
|
|
|||
|
|
@ -1,6 +1,8 @@
|
|||
---
|
||||
title: Gossip Service
|
||||
title: Gossip Service in a Solana Validator
|
||||
sidebar_position: 5
|
||||
sidebar_label: Gossip Service
|
||||
pagination_label: Validator Gossip Service
|
||||
---
|
||||
|
||||
The Gossip Service acts as a gateway to nodes in the
|
||||
|
|
|
|||
|
|
@ -1,6 +1,8 @@
|
|||
---
|
||||
title: Runtime
|
||||
title: Solana Runtime on a Solana Validator
|
||||
sidebar_position: 6
|
||||
sidebar_label: Runtime
|
||||
pagination_label: Validator Runtime
|
||||
---
|
||||
|
||||
The runtime is a concurrent transaction processor. Transactions specify their data dependencies upfront and dynamic memory allocation is explicit. By separating program code from the state it operates on, the runtime is able to choreograph concurrent access. Transactions accessing only read-only accounts are executed in parallel whereas transactions accessing writable accounts are serialized. The runtime interacts with the program through an entrypoint with a well-defined interface. The data stored in an account is an opaque type, an array of bytes. The program has full control over its contents.
|
||||
|
|
|
|||
|
|
@ -1,7 +1,8 @@
|
|||
---
|
||||
title: Transaction Processing Unit
|
||||
sidebar_label: TPU
|
||||
title: Transaction Processing Unit in a Solana Validator
|
||||
sidebar_position: 2
|
||||
sidebar_label: TPU
|
||||
pagination_label: Validator's Transaction Processing Unit (TPU)
|
||||
---
|
||||
|
||||
TPU (Transaction Processing Unit) is the logic of the validator
|
||||
|
|
|
|||
|
|
@ -1,7 +1,8 @@
|
|||
---
|
||||
title: Transaction Validation Unit
|
||||
sidebar_label: TVU
|
||||
title: Transaction Validation Unit in a Solana Validator
|
||||
sidebar_position: 3
|
||||
sidebar_label: TVU
|
||||
pagination_label: Validator's Transaction Validation Unit (TVU)
|
||||
---
|
||||
|
||||
TVU (Transaction Validation Unit) is the logic of the validator
|
||||
|
|
|
|||
Loading…
Reference in New Issue