diff --git a/docs/src/cli/examples/deploy-a-program.md b/docs/src/cli/examples/deploy-a-program.md index 755d165f4b7297..1025ca6ea8fafa 100644 --- a/docs/src/cli/examples/deploy-a-program.md +++ b/docs/src/cli/examples/deploy-a-program.md @@ -279,7 +279,7 @@ $ sha256sum extended.so dump.so Instead of deploying directly to the program account, the program can be written to an intermediary buffer account. Intermediary accounts can be useful for -things like multi-entity governed programs where the governing members fist +things like multi-entity governed programs where the governing members first verify the intermediary buffer contents and then vote to allow an upgrade using it. diff --git a/docs/src/cli/wallets/hardware/ledger.md b/docs/src/cli/wallets/hardware/ledger.md index 65935b79d0255b..e0060aba803eb2 100644 --- a/docs/src/cli/wallets/hardware/ledger.md +++ b/docs/src/cli/wallets/hardware/ledger.md @@ -94,7 +94,7 @@ solana balance 7cvkjYAkUYs4W8XcXsca7cBrEGFeSUjeZmKoNBvEwyri You can also view the balance of any account address on the Accounts tab in the [Explorer](https://explorer.solana.com/accounts) and paste the address in the -box to view the balance in you web browser. +box to view the balance in your web browser. Note: Any address with a balance of 0 SOL, such as a newly created one on your Ledger, will show as "Not Found" in the explorer. Empty accounts and diff --git a/docs/src/implemented-proposals/abi-management.md b/docs/src/implemented-proposals/abi-management.md index 74505087dbab12..88e27c9a1a9066 100644 --- a/docs/src/implemented-proposals/abi-management.md +++ b/docs/src/implemented-proposals/abi-management.md @@ -130,7 +130,7 @@ name suggests, there is no need to implement `AbiEnumVisitor` for other types. To summarize this interplay, `serde` handles the recursive serialization control flow in tandem with `AbiDigester`. The initial entry point in tests and child `AbiDigester`s use `AbiExample` recursively to create an example object -hierarchal graph. And `AbiDigester` uses `AbiEnumVisitor` to inquiry the actual +hierarchical graph. And `AbiDigester` uses `AbiEnumVisitor` to inquiry the actual ABI information using the constructed sample. `Default` isn't enough for `AbiExample`. Various collection's `::default()` is @@ -142,7 +142,7 @@ On the other hand, ABI digesting can't be done only with `AbiExample`, either. `AbiEnumVisitor` is required because all variants of an `enum` cannot be traversed just with a single variant of it as a ABI example. -Digestable information: +Digestible information: - rust's type name - `serde`'s data type name @@ -152,7 +152,7 @@ Digestable information: - `enum`: normal variants and `struct`- and `tuple`- styles. - attributes: `serde(serialize_with=...)` and `serde(skip)` -Not digestable information: +Not digestible information: - Any custom serialize code path not touched by the sample provided by `AbiExample`. (technically not possible) diff --git a/docs/src/implemented-proposals/reliable-vote-transmission.md b/docs/src/implemented-proposals/reliable-vote-transmission.md index e8520be7e6e6c4..c4632be4a97fea 100644 --- a/docs/src/implemented-proposals/reliable-vote-transmission.md +++ b/docs/src/implemented-proposals/reliable-vote-transmission.md @@ -8,7 +8,7 @@ Validator votes are messages that have a critical function for consensus and con 1. Leader rotation is triggered by PoH, which is clock with high drift. So many nodes are likely to have an incorrect view if the next leader is active in realtime or not. 2. The next leader may be easily be flooded. Thus a DDOS would not only prevent delivery of regular transactions, but also consensus messages. -3. UDP is unreliable, and our asynchronous protocol requires any message that is transmitted to be retransmitted until it is observed in the ledger. Retransmittion could potentially cause an unintentional _thundering herd_ against the leader with a large number of validators. Worst case flood would be `(num_nodes * num_retransmits)`. +3. UDP is unreliable, and our asynchronous protocol requires any message that is transmitted to be retransmitted until it is observed in the ledger. Retransmission could potentially cause an unintentional _thundering herd_ against the leader with a large number of validators. Worst case flood would be `(num_nodes * num_retransmits)`. 4. Tracking if the vote has been transmitted or not via the ledger does not guarantee it will appear in a confirmed block. The current observed block may be unrolled. Validators would need to maintain state for each vote and fork. ## Design diff --git a/docs/src/implemented-proposals/repair-service.md b/docs/src/implemented-proposals/repair-service.md index 2de8105fb87406..ea51a33bc4e85c 100644 --- a/docs/src/implemented-proposals/repair-service.md +++ b/docs/src/implemented-proposals/repair-service.md @@ -54,7 +54,7 @@ The different protocol strategies to address the above challenges: Blockstore tracks the latest root slot. RepairService will then periodically iterate every fork in blockstore starting from the root slot, sending repair requests to validators for any missing shreds. It will send at most some `N` - repair reqeusts per iteration. Shred repair should prioritize repairing + repair requests per iteration. Shred repair should prioritize repairing forks based on the leader's fork weight. Validators should only send repair requests to validators who have marked that slot as completed in their EpochSlots. Validators should prioritize repairing shreds in each slot diff --git a/docs/src/implemented-proposals/staking-rewards.md b/docs/src/implemented-proposals/staking-rewards.md index a85a23e1fec9fe..fb9d437f85fb84 100644 --- a/docs/src/implemented-proposals/staking-rewards.md +++ b/docs/src/implemented-proposals/staking-rewards.md @@ -30,4 +30,4 @@ Solana's trustless sense of time and ordering provided by its PoH data structure As discussed in the [Economic Design](ed_overview/ed_overview.md) section, annual validator interest rates are to be specified as a function of total percentage of circulating supply that has been staked. The cluster rewards validators who are online and actively participating in the validation process throughout the entirety of their _validation period_. For validators that go offline/fail to validate transactions during this period, their annual reward is effectively reduced. -Similarly, we may consider an algorithmic reduction in a validator's active amount staked amount in the case that they are offline. I.e. if a validator is inactive for some amount of time, either due to a partition or otherwise, the amount of their stake that is considered ‘active’ \(eligible to earn rewards\) may be reduced. This design would be structured to help long-lived partitions to eventually reach finality on their respective chains as the % of non-voting total stake is reduced over time until a supermajority can be achieved by the active validators in each partition. Similarly, upon re-engaging, the ‘active’ amount staked will come back online at some defined rate. Different rates of stake reduction may be considered depending on the size of the partition/active set. +Similarly, we may consider an algorithmic reduction in a validator's active staked amount in the case that they are offline. I.e. if a validator is inactive for some amount of time, either due to a partition or otherwise, the amount of their stake that is considered ‘active’ \(eligible to earn rewards\) may be reduced. This design would be structured to help long-lived partitions to eventually reach finality on their respective chains as the % of non-voting total stake is reduced over time until a supermajority can be achieved by the active validators in each partition. Similarly, upon re-engaging, the ‘active’ amount staked will come back online at some defined rate. Different rates of stake reduction may be considered depending on the size of the partition/active set. diff --git a/docs/src/implemented-proposals/testing-programs.md b/docs/src/implemented-proposals/testing-programs.md index 03651293ab72ea..b4054c1fecc98e 100644 --- a/docs/src/implemented-proposals/testing-programs.md +++ b/docs/src/implemented-proposals/testing-programs.md @@ -32,7 +32,7 @@ trait SyncClient { } ``` -Users send transactions and asynchrounously and synchrounously await results. +Users send transactions and asynchronously and synchronously await results. ### ThinClient for Clusters diff --git a/docs/src/operations/guides/vote-accounts.md b/docs/src/operations/guides/vote-accounts.md index 2c411652836dbc..c86b66cb85bba4 100644 --- a/docs/src/operations/guides/vote-accounts.md +++ b/docs/src/operations/guides/vote-accounts.md @@ -165,7 +165,7 @@ Rotating the vote account authority keys requires special handling when dealing with a live validator. Note that vote account key rotation has no effect on the stake accounts that -have been delegate to the vote account. For example it is possible to use key +have been delegated to the vote account. For example it is possible to use key rotation to transfer all authority of a vote account from one entity to another without any impact to staking rewards. diff --git a/docs/src/proposals/accounts-db-replication.md b/docs/src/proposals/accounts-db-replication.md index 2286a709e99bd8..a1b0a2fd6a39fb 100644 --- a/docs/src/proposals/accounts-db-replication.md +++ b/docs/src/proposals/accounts-db-replication.md @@ -88,7 +88,7 @@ During replication we also need to replicate the information of accounts that ha up due to zero lamports, i.e. we need to be able to tell the difference between an account in a given slot which was not updated and hence has no storage entry in that slot, and one that holds 0 lamports and has been cleaned up through the history. We may record this via some -"Tombstone" mechanism -- recording the dead accounts cleaned up fora slot. The tombstones +"Tombstone" mechanism -- recording the dead accounts cleaned up for a slot. The tombstones themselves can be removed after exceeding the retention period expressed as epochs. Any attempt to replicate slots with tombstones removed will fail and the replica should skip this slot and try later ones. diff --git a/docs/src/proposals/blockstore-rocksdb-compaction.md b/docs/src/proposals/blockstore-rocksdb-compaction.md index 85b7e3a8c40afa..39eaa5dece8844 100644 --- a/docs/src/proposals/blockstore-rocksdb-compaction.md +++ b/docs/src/proposals/blockstore-rocksdb-compaction.md @@ -109,7 +109,7 @@ close to 1 read amplification. As each key is only inserted once, we have space amplification 1. ### Use Current Settings for Metadata Column Families -The second type of the column families related to shred insertion is medadata +The second type of the column families related to shred insertion is metadata column families. These metadata column families contributes ~1% of the shred insertion data in size. The largest metadata column family here is the Index column family, which occupies 0.8% of the shred insertion data. @@ -160,7 +160,7 @@ in Solana's BlockStore use case: Here we discuss Level to FIFO and FIFO to Level migrations: ### Level to FIFO -heoretically, FIFO compaction is the superset of all other compaction styles, +Theoretically, FIFO compaction is the superset of all other compaction styles, as it does not have any assumption of the LSM tree structure. However, the current RocksDB implementation does not offer such flexibility while it is theoretically doable. diff --git a/docs/src/proposals/handle-duplicate-block.md b/docs/src/proposals/handle-duplicate-block.md index 923773facc1234..2941f17d2702ba 100644 --- a/docs/src/proposals/handle-duplicate-block.md +++ b/docs/src/proposals/handle-duplicate-block.md @@ -25,7 +25,7 @@ Before a duplicate slot `S` is `duplicate_confirmed`, it's first excluded from t Some notes about the `DUPLICATE_THRESHOLD`. In the cases below, assume `DUPLICATE_THRESHOLD = 52`: a) If less than `2 * DUPLICATE_THRESHOLD - 1` percentage of the network is malicious, then there can only be one such `duplicate_confirmed` version of the slot. With `DUPLICATE_THRESHOLD = 52`, this is -a malcious tolerance of `4%` +a malicious tolerance of `4%` b) The liveness of the network is at most `1 - DUPLICATE_THRESHOLD - SWITCH_THRESHOLD`. This is because if you need at least `SWITCH_THRESHOLD` percentage of the stake voting on a different fork in order to switch off of a duplicate fork that has `< DUPLICATE_THRESHOLD` stake voting on it, and is *not* `duplicate_confirmed`. For `DUPLICATE_THRESHOLD = 52` and `DUPLICATE_THRESHOLD = 38`, this implies a liveness tolerance of `10%`. @@ -38,7 +38,7 @@ For example in the situation below, validators that voted on `2` can't vote any ``` -3. Switching proofs need to be extended to allow including vote hashes from different versions of the same same slot (detected through 1). Right now this is not supported since switching proofs can +3. Switching proofs need to be extended to allow including vote hashes from different versions of the same slot (detected through 1). Right now this is not supported since switching proofs can only be built using votes from banks in BankForks, and two different versions of the same slot cannot simultaneously exist in BankForks. For instance: @@ -73,7 +73,7 @@ This problem we need to solve is modeled simply by the below scenario: ``` Assume the following: -1. Due to gossiping duplciate proofs, we assume everyone will eventually see duplicate proofs for 2 and 4, so everyone agrees to remove them from fork choice until they are `duplicate_confirmed`. +1. Due to gossiping duplicate proofs, we assume everyone will eventually see duplicate proofs for 2 and 4, so everyone agrees to remove them from fork choice until they are `duplicate_confirmed`. 2. Due to lockouts, `> DUPLICATE_THRESHOLD` of the stake votes on 4, but not 2. This means at least `DUPLICATE_THRESHOLD` of people have the "correct" version of both slots 2 and 4. diff --git a/docs/src/proposals/ledger-replication-to-implement.md b/docs/src/proposals/ledger-replication-to-implement.md index 104a214641d4dc..fac6581fcb3016 100644 --- a/docs/src/proposals/ledger-replication-to-implement.md +++ b/docs/src/proposals/ledger-replication-to-implement.md @@ -219,7 +219,7 @@ For each turn of the PoRep game, both Validators and Archivers evaluate each sta For any random seed, we force everyone to use a signature that is derived from a PoH hash at the turn boundary. Everyone uses the same count, so the same PoH hash is signed by every participant. The signatures are then each cryptographically tied to the keypair, which prevents a leader from grinding on the resulting value for more than 1 identity. -Since there are many more client identities then encryption identities, we need to split the reward for multiple clients, and prevent Sybil attacks from generating many clients to acquire the same block of data. To remain BFT we want to avoid a single human entity from storing all the replications of a single chunk of the ledger. +Since there are many more client identities than encryption identities, we need to split the reward for multiple clients, and prevent Sybil attacks from generating many clients to acquire the same block of data. To remain BFT we want to avoid a single human entity from storing all the replications of a single chunk of the ledger. Our solution to this is to force the clients to continue using the same identity. If the first round is used to acquire the same block for many client identities, the second round for the same client identities will force a redistribution of the signatures, and therefore PoRep identities and blocks. Thus to get a reward for archivers need to store the first block for free and the network can reward long lived client identities more than new ones. diff --git a/docs/src/proposals/off-chain-message-signing.md b/docs/src/proposals/off-chain-message-signing.md index b234627dca7f7d..7d5d25b10f726e 100644 --- a/docs/src/proposals/off-chain-message-signing.md +++ b/docs/src/proposals/off-chain-message-signing.md @@ -64,7 +64,7 @@ This may be any arbitrary bytes. For instance the on-chain address of a program, DAO instance, Candy Machine, etc. This field **SHOULD** be displayed to users as a base58-encoded ASCII string rather -than interpretted otherwise. +than interpreted otherwise. #### Message Format diff --git a/docs/src/proposals/optimistic-transaction-propagation-signal.md b/docs/src/proposals/optimistic-transaction-propagation-signal.md index f85b38eedcd1ad..549cea0b08bbb2 100644 --- a/docs/src/proposals/optimistic-transaction-propagation-signal.md +++ b/docs/src/proposals/optimistic-transaction-propagation-signal.md @@ -13,7 +13,7 @@ concatenating (1), (2), and (3) deduplicating this list of entries by pubkey favoring entries with contact info filtering this list by entries with contact info -This list is then is randomly shuffled by stake weight. +This list is then randomly shuffled by stake weight. Shreds are then retransmitted to up to FANOUT neighbors and up to FANOUT children. @@ -37,7 +37,7 @@ First, only epoch staked nodes will be considered regardless of presence of contact info (and possibly including the validator node itself). A deterministic ordering of the epoch staked nodes will be created based on the -derministic shred seed using weighted_shuffle. +deterministic shred seed using weighted_shuffle. Let `neighbor_set` be selected from up to FANOUT neighbors of the current node. Let `child_set` be selected from up to FANOUT children of the current node. @@ -73,7 +73,7 @@ distribution levels. distribution levels because of lack of contact info. - Current node was part of original epoch staked shuffle from retransmitter but was filtered out because of missing contact info. Current node subsequently -receives retransmisison of shred and assumes that the retransmit was a result +receives retransmission of shred and assumes that the retransmit was a result of the deterministic tree calculation and not from subsequent random selection. This should be benign because the current node will underestimate prior stake weight in the retransmission tree. @@ -105,5 +105,5 @@ Practically, signals should fall into the following buckets: 1.2. can signal layer 1 + subset of layer 2 when retransmit is sent 3. layer 2 3.1. can signal layer 2 when shred is received -3.2. can signal layer 2 + subset of layer 3 when retrnasmit is sent +3.2. can signal layer 2 + subset of layer 3 when retransmit is sent 4. current node not a member of epoch staked nodes, no signal can be sent diff --git a/docs/src/proposals/optimistic_confirmation.md b/docs/src/proposals/optimistic_confirmation.md index f2b77ea3316f54..3cb553cdcb9e24 100644 --- a/docs/src/proposals/optimistic_confirmation.md +++ b/docs/src/proposals/optimistic_confirmation.md @@ -86,7 +86,7 @@ the votes must satisfy: - `X <= S.last`, `X' <= S'.last` - All `s` in `S` are ancestors/descendants of one another, - all `s'` in `S'` are ancsestors/descendants of one another, + all `s'` in `S'` are ancestors/descendants of one another, - - `X == X'` implies `S` is parent of `S'` or `S'` is a parent of `S` - `X' > X` implies `X' > S.last` and `S'.last > S.last` @@ -312,7 +312,7 @@ true that `B' > X` ``` `Proof`: Let `Vote(X, S)` be a vote in the `Optimistic Votes` set. Then by -definition, given the "optimistcally confirmed" block `B`, `X <= B <= S.last`. +definition, given the "optimistically confirmed" block `B`, `X <= B <= S.last`. Because `X` is a parent of `B`, and `B'` is not a parent or ancestor of `B`, then: @@ -322,7 +322,7 @@ then: Now consider if `B'` < `X`: -`Case B' < X`: We wll show this is a violation of lockouts. +`Case B' < X`: We will show this is a violation of lockouts. From above, we know `B'` is not a parent of `X`. Then because `B'` was rooted, and `B'` is not a parent of `X`, then the validator should not have been able to vote on the higher slot `X` that does not descend from `B'`. @@ -361,7 +361,7 @@ By `Lemma 2` we know `B' > X`, and from above `S_v.last > B'`, so then From above, `S.last >= B >= X` so for all such "switching votes", `X_v > B`. Now ordering all these "switching votes" in time, let `V` to be the validator -in `Optimistic Validators` that first submitted such a "swtching vote" +in `Optimistic Validators` that first submitted such a "switching vote" `Vote(X', S')`, where `X' > B`. We know that such a validator exists because we know from above that all delinquent validators must have submitted such a vote, and the delinquent validators are a subset of the diff --git a/docs/src/proposals/return-data.md b/docs/src/proposals/return-data.md index 93a546103f0440..3e70e87195e937 100644 --- a/docs/src/proposals/return-data.md +++ b/docs/src/proposals/return-data.md @@ -136,7 +136,7 @@ strings in the [stable log](https://github.com/solana-labs/solana/blob/952928419 Solidity on Ethereum allows the contract to return an error in the return data. In this case, all the account data changes for the account should be reverted. On Solana, any non-zero exit code -for a SBF prorgram means the entire transaction fails. We do not wish to support an error return +for a SBF program means the entire transaction fails. We do not wish to support an error return by returning success and then returning an error in the return data. This would mean we would have to support reverting the account data changes; this too expensive both on the VM side and the SBF contract side. diff --git a/docs/src/proposals/rip-curl.md b/docs/src/proposals/rip-curl.md index 8e2ab9707a39b7..c562f01bd1337e 100644 --- a/docs/src/proposals/rip-curl.md +++ b/docs/src/proposals/rip-curl.md @@ -39,7 +39,7 @@ Easier for validators to support: has no significant resource constraints. - Transaction status is never stored in memory and cannot be polled for. - Signatures are only stored in memory until the desired commitment level or - until the blockhash expires, which ever is later. + until the blockhash expires, whichever is later. How it works: diff --git a/docs/src/proposals/simple-payment-and-state-verification.md b/docs/src/proposals/simple-payment-and-state-verification.md index c8144396c67640..caa8a2d55e1f4c 100644 --- a/docs/src/proposals/simple-payment-and-state-verification.md +++ b/docs/src/proposals/simple-payment-and-state-verification.md @@ -90,7 +90,7 @@ code, but a single status bit to indicate the transaction's success. Currently, the Block-Merkle is not implemented, so to verify `E` was an entry in the block with bank hash `B`, we would need to provide all the entry hashes -in the block. Ideally this Block-Merkle would be implmented, as the alternative +in the block. Ideally this Block-Merkle would be implemented, as the alternative is very inefficient. #### Block Headers @@ -138,7 +138,7 @@ https://github.com/solana-labs/solana/blob/b6bfed64cb159ee67bb6bdbaefc7f833bbed3 Each vote is a signed transaction that includes the bank hash of the block the validator voted for, i.e. the `B` from the `Transaction Merkle` section above. Once a certain threshold `T` of the network has voted on a block, the block is -considered optimistially confirmed. The votes made by this group of `T` +considered optimistically confirmed. The votes made by this group of `T` validators is needed to show the block with bank hash `B` was optimistically confirmed. @@ -150,11 +150,11 @@ vote, and vote account pubkey responsible for the vote. Together, the transaction merkle and optimistic confirmation proofs can be provided over RPC to subscribers by extending the existing signature -subscrption logic. Clients who subscribe to the "Confirmed" confirmation +subscription logic. Clients who subscribe to the "Confirmed" confirmation level are already notified when optimistic confirmation is detected, a flag can be provided to signal the two proofs above should also be returned. -It is important to note that optimistcally confirming `B` also implies that all +It is important to note that optimistically confirming `B` also implies that all ancestor blocks of `B` are also optimistically confirmed, and also that not all blocks will be optimistically confirmed. @@ -164,7 +164,7 @@ B -> B' ``` -So in the example above if a block `B'` is optimisically confirmed, then so is +So in the example above if a block `B'` is optimistically confirmed, then so is `B`. Thus if a transaction was in block `B`, the transaction merkle in the proof will be for block `B`, but the votes presented in the proof will be for block `B'`. This is why the headers in the `Block headers` section above are @@ -174,10 +174,10 @@ important, the client will need to verify that `B` is indeed an ancestor of #### Proof of Stake Distribution Once presented with the transaction merkle and optimistic confirmation proofs -above, a client can verify a transaction `T` was optimistially confirmed in a +above, a client can verify a transaction `T` was optimistically confirmed in a block with bank hash `B`. The last missing piece is how to verify that the votes in the optimistic proofs above actually constitute the valid `T` -percentage of the stake necessay to uphold the safety guarantees of +percentage of the stake necessary to uphold the safety guarantees of "optimistic confirmation". One way to approach this might be for every epoch, when the stake set changes, @@ -191,7 +191,7 @@ block `B` was optimistically confirmed/rooted. An account's state (balance or other data) can be verified by submitting a transaction with a **_TBD_** Instruction to the cluster. The client can then use a [Transaction Inclusion Proof](#transaction-inclusion-proof) to verify -whether the cluster agrees that the acount has reached the expected state. +whether the cluster agrees that the account has reached the expected state. ### Validator Votes diff --git a/docs/src/proposals/timely-vote-credits.md b/docs/src/proposals/timely-vote-credits.md index 418697b1fbc336..39c496ff9dfe1a 100644 --- a/docs/src/proposals/timely-vote-credits.md +++ b/docs/src/proposals/timely-vote-credits.md @@ -47,7 +47,7 @@ transmitted immediately and landed in an earlier slot. If landing a vote with 1 slot latency awarded more credit than landing that same vote in 2 slots latency, then validators who could land votes -consistently wihthin 1 slot would have a credits earning advantage over those +consistently within 1 slot would have a credits earning advantage over those who could not. Part of the latency when transmitting votes is unavoidable as it's a function of geographical distance between the sender and receiver of the vote. The Solana network is spread around the world but it is not evenly diff --git a/docs/src/what-is-a-validator.md b/docs/src/what-is-a-validator.md index c5e2b1b9d8b343..acaef0d27c1586 100644 --- a/docs/src/what-is-a-validator.md +++ b/docs/src/what-is-a-validator.md @@ -6,13 +6,13 @@ A validator is a computer that helps to run the Solana network. Each validator e The more independent entities that run validators, the less vulnerable the cluster is to an attack or catastrophe that affects the cluster. -> For an more in depth look at the health of the Solana network, see the [Solana Foundation Validator Health Report](https://solana.com/news/validator-health-report-march-2023). +> For a more in depth look at the health of the Solana network, see the [Solana Foundation Validator Health Report](https://solana.com/news/validator-health-report-march-2023). By becoming a validator, you are helping to grow the network. You are also learning first hand how the Solana cluster functions at the lowest level. You will become part of an active community of operators that are passionate about the Solana ecosystem. ## Consensus vs RPC -Before, we discuss validators in more detail, it's useful to make some distinctions. Using the same validator software, you have the option of running a voting/consensus node or choosing to instead run an RPC node. An RPC node helps Solana devs and others interact with the blockchain but for performance reasons should not vote. We go into more detail on RPC nodes in the next section, [what is an rpc node](./what-is-an-rpc-node.md). +Before we discuss validators in more detail, it's useful to make some distinctions. Using the same validator software, you have the option of running a voting/consensus node or choosing to instead run an RPC node. An RPC node helps Solana devs and others interact with the blockchain but for performance reasons should not vote. We go into more detail on RPC nodes in the next section, [what is an rpc node](./what-is-an-rpc-node.md). For this document, when a validator is mentioned, we are talking about a voting/consensus node. Now, to better understand what your validator is doing, it would help to understand how the Solana network functions in more depth. @@ -36,4 +36,4 @@ Understanding how PoH works is not necessary to run a good validator, but a very As a validator, you are helping to secure the network by producing and voting on blocks and to improve decentralization by running an independent node. You have the right to participate in discussions of changes on the network. You are also assuming a responsibility to keep your system running properly, to make sure your system is secure, and to keep it up to date with the latest software. As more individuals stake their tokens to your validator, you can reward their trust by running a high performing and reliable validator. Hopefully, your validator is performing well a majority of the time, but you should also have systems in place to respond to an outage at any time of the day. If your validator is not responding late at night, someone (either you or other team members) need to be available to investigate and fix the issues. -Running a validator is a [technical and important task](./operations/prerequisites.md), but it can also be very rewarding. Good luck and welcome to the community. \ No newline at end of file +Running a validator is a [technical and important task](./operations/prerequisites.md), but it can also be very rewarding. Good luck and welcome to the community. diff --git a/zk-token-sdk/src/encryption/elgamal.rs b/zk-token-sdk/src/encryption/elgamal.rs index 1c9bc55942c2dd..5b4e2dba872530 100644 --- a/zk-token-sdk/src/encryption/elgamal.rs +++ b/zk-token-sdk/src/encryption/elgamal.rs @@ -164,7 +164,7 @@ impl ElGamal { } /// On input a secret key and a ciphertext, the function returns the decrypted amount - /// interpretted as a positive 32-bit number (but still of type `u64`). + /// interpreted as a positive 32-bit number (but still of type `u64`). /// /// If the originally encrypted amount is not a positive 32-bit number, then the function /// returns `None`. diff --git a/zk-token-sdk/src/instruction/transfer/mod.rs b/zk-token-sdk/src/instruction/transfer/mod.rs index 736ba937b5ba16..33bc6c08a96a21 100644 --- a/zk-token-sdk/src/instruction/transfer/mod.rs +++ b/zk-token-sdk/src/instruction/transfer/mod.rs @@ -31,8 +31,8 @@ pub enum Role { } /// Takes in a 64-bit number `amount` and a bit length `bit_length`. It returns: -/// - the `bit_length` low bits of `amount` interpretted as u64 -/// - the (64 - `bit_length`) high bits of `amount` interpretted as u64 +/// - the `bit_length` low bits of `amount` interpreted as u64 +/// - the (64 - `bit_length`) high bits of `amount` interpreted as u64 #[cfg(not(target_os = "solana"))] pub fn split_u64(amount: u64, bit_length: usize) -> (u64, u64) { if bit_length == 64 {