diff --git a/docs/src/cli/examples/delegate-stake.md b/docs/src/cli/examples/delegate-stake.md index 04ef9377545432..58a20d73857b28 100644 --- a/docs/src/cli/examples/delegate-stake.md +++ b/docs/src/cli/examples/delegate-stake.md @@ -7,7 +7,7 @@ sidebar_label: Staking After you have [received SOL](./transfer-tokens.md), you might consider putting it to use by delegating _stake_ to a validator. Stake is what we call tokens in a _stake account_. Solana weights validator votes by the amount of stake delegated -to them, which gives those validators more influence in determining then next +to them, which gives those validators more influence in determining the next 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. diff --git a/docs/src/consensus/stake-delegation-and-rewards.md b/docs/src/consensus/stake-delegation-and-rewards.md index 72f29d5c0c4f6b..8d2f6b31c61d79 100644 --- a/docs/src/consensus/stake-delegation-and-rewards.md +++ b/docs/src/consensus/stake-delegation-and-rewards.md @@ -178,7 +178,7 @@ custodian must also sign the transaction. - `account[0]` - RW - The StakeStateV2. - `StakeStateV2::authorized_staker` or `authorized_withdrawer` is set to to + `StakeStateV2::authorized_staker` or `authorized_withdrawer` is set to `Pubkey`. ### StakeInstruction::Deactivate diff --git a/docs/src/implemented-proposals/ed_overview/ed_mvp.md b/docs/src/implemented-proposals/ed_overview/ed_mvp.md index a66974ebe3af8c..bb7cc87bcc7cd6 100644 --- a/docs/src/implemented-proposals/ed_overview/ed_mvp.md +++ b/docs/src/implemented-proposals/ed_overview/ed_mvp.md @@ -12,7 +12,7 @@ been described above. We intend to fully engage with network stakeholders throughout the implementation phases \(i.e. pre-testnet, testnet, mainnet\) to ensure the system supports, and is representative of, the various network participants' interests. The first step toward this goal, however, is outlining -a some desired MVP economic features to be available for early pre-testnet and +some desired MVP economic features to be available for early pre-testnet and testnet participants. Below is a rough sketch outlining basic economic functionality from which a more complete and functional system can be developed. diff --git a/docs/src/implemented-proposals/epoch_accounts_hash.md b/docs/src/implemented-proposals/epoch_accounts_hash.md index 2eeca2d75df326..ba16f3f869b788 100644 --- a/docs/src/implemented-proposals/epoch_accounts_hash.md +++ b/docs/src/implemented-proposals/epoch_accounts_hash.md @@ -302,7 +302,7 @@ normal behavior. #### parent slot: `B`, warp slot: `B` A new EAH will be calculated at parent slot, which will be included in `stop -slot 1`, _not_ the previously-calculated EAH from `start slot 1`. This behaior +slot 1`, _not_ the previously-calculated EAH from `start slot 1`. This behavior is different. diff --git a/docs/src/proposals/blockstore-rocksdb-compaction.md b/docs/src/proposals/blockstore-rocksdb-compaction.md index 39eaa5dece8844..f4281ffb121833 100644 --- a/docs/src/proposals/blockstore-rocksdb-compaction.md +++ b/docs/src/proposals/blockstore-rocksdb-compaction.md @@ -201,7 +201,7 @@ two different formats and panic. ## Single Node Benchmark Results To verify the effectiveness, I ran both 1m slots and 100m slots shred insertion benchmarks on my n2-standard-32 GC instance (32 cores 2800MHz cpu, 128GB memory, -2048GB SSD). Each slot contains 25 shreds, and the shreds are inserted with with +2048GB SSD). Each slot contains 25 shreds, and the shreds are inserted with 8 writers. Here are the summary of the result: * FIFO based validator: Shred insertion took 13450.8s, 185.8k shreds/s