blockworks-foundation
/
solana
mirror of https://github.com/blockworks-foundation/solana.git
1
0
Fork 0
Code Issues Projects Releases Wiki Activity

Fix some typo in the documentation (#34058) 

Co-authored-by: Andrew Fitzgerald <apfitzge@gmail.com>
This commit is contained in:
hugo-syn 2023-11-14 19:58:42 +01:00 committed by GitHub
parent aa991b6ab7
commit 71dcf77d73
No known key found for this signature in database
GPG Key ID: 4AEE18F83AFDEB23
5 changed files with 6 additions and 6 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

4
docs/src/cli/deploy-a-program.md
View File

@ -173,8 +173,8 @@ solana program show --buffers
To specify a different authority:
```bash
solana program show --programs --buffer-authority <AURTHORITY_ADRESS>
solana program show --buffers --buffer-authority <AURTHORITY_ADRESS>
solana program show --programs --buffer-authority <AUTHORITY_ADDRESS>
solana program show --buffers --buffer-authority <AUTHORITY_ADDRESS>
```
To close a single account:

2
docs/src/implemented-proposals/reliable-vote-transmission.md
View File

@ -20,7 +20,7 @@ Validator votes are messages that have a critical function for consensus and con
Each vote transaction should maintain a `wallclock` in its data. The merge strategy for Votes will keep the last N set of votes as configured by the local client. For push/pull the vector is traversed recursively and each Transaction is treated as an individual CrdsValue with its own local wallclock and signature.
Gossip is designed for efficient propagation of state. Messages that are sent through gossip-push are batched and propagated with a minimum spanning tree to the rest of the network. Any partial failures in the tree are actively repaired with the gossip-pull protocol while minimizing the amount of data transfered between any nodes.
Gossip is designed for efficient propagation of state. Messages that are sent through gossip-push are batched and propagated with a minimum spanning tree to the rest of the network. Any partial failures in the tree are actively repaired with the gossip-pull protocol while minimizing the amount of data transferred between any nodes.
## How this design solves the Challenges

2
docs/src/proposals/accounts-db-replication.md
View File

@ -72,7 +72,7 @@ slot for which it has not completed accounts db replication. The `ReplicaAccount
the `ReplicaAccountMeta`, Hash and the AccountData. The `ReplicaAccountMeta` contains info about
the existing `AccountMeta` in addition to the account data length in bytes.
The `ReplicaAccountsServer`: this service is reponsible for serving the `ReplicaAccountsRequest`
The `ReplicaAccountsServer`: this service is responsible for serving the `ReplicaAccountsRequest`
and sends `ReplicaAccountsResponse` to the requestor. The response contains the count of the
ReplAccountInfo and the vector of ReplAccountInfo. This service runs both in the validator
and the replica relaying replication information. The server can stream the account information

2
docs/src/proposals/handle-duplicate-block.md
View File

@ -18,7 +18,7 @@ potential forks that the cluster has to resolve.
## Protocol
1. When WindowStage detects a duplicate slot proof `P`, it checks the new `gossip_root` to see if `<= 1/3` of the nodes have rooted a slot `S >= P`. If so, it pushes a proof to `gossip_duplicate_slots` to gossip. WindowStage then signals ReplayStage about this duplicate slot `S`. These proofs can be purged from gossip once the validator sees > 2/3 of people gossiping roots `R > S`.
2. When ReplayStage receives the signal for a duplicate slot `S` from `1)` above, the validator monitors gossip and replay waiting for`>= DUPLICATE_THRESHOLD` votes for the same hash which implies the same version of the slot. If this conditon is met for some version with hash `H` of slot `S`, this is then known as the `duplicate_confirmed` version of the slot.
2. When ReplayStage receives the signal for a duplicate slot `S` from `1)` above, the validator monitors gossip and replay waiting for`>= DUPLICATE_THRESHOLD` votes for the same hash which implies the same version of the slot. If this condition is met for some version with hash `H` of slot `S`, this is then known as the `duplicate_confirmed` version of the slot.
Before a duplicate slot `S` is `duplicate_confirmed`, it's first excluded from the vote candidate set in the fork choice rules. In addition, ReplayStage also resets PoH to the *latest* ancestor of the *earliest* `non-duplicate/confirmed_duplicate_slot`, so that block generation can start happening on the earliest known *safe* block.

2
docs/src/proposals/timely-vote-credits.md
View File

@ -10,7 +10,7 @@ vote credits earned by validator votes.
Vote credits are the accounting method used to determine what percentage of
inflation rewards a validator earns on behalf of its stakers. Currently, when
a slot that a validator has previously voted on is "rooted", it earns 1 vote
credit. A "rooted" slot is one which has received full committment by the
credit. A "rooted" slot is one which has received full commitment by the
validator (i.e. has been finalized).
One problem with this simple accounting method is that it awards one credit