Skip to content

Commit

Permalink
Enhancements to Solana's Documentations for Better Clarity (#34386)
Browse files Browse the repository at this point in the history
* fix grammatical error in Incident Response Process section

* Fix typo in setup instructions

* Fixed grammatical errors in documentation: corrected article usage, pluralization, and singular form in database reference

* Fix typos in documentation: Correct 'In oder' to 'In order', fix 'enviroment' to 'environment', correct 'reults' to 'results' in Ping Results section, and change 'engress' to 'egress' in CUDA section.

* Fix grammatical errors in documentation

* Fix grammatical issues in documentation

Correct subject-verb agreement in transaction balance description and clarify execution of instructions in a transaction.
  • Loading branch information
joaolago1113 authored Dec 12, 2023
1 parent a2d7be0 commit 05dae59
Show file tree
Hide file tree
Showing 7 changed files with 15 additions and 15 deletions.
2 changes: 1 addition & 1 deletion SECURITY.md
Original file line number Diff line number Diff line change
Expand Up @@ -50,7 +50,7 @@ comment as such and then close the report.

### 2. Triage
Within the draft security advisory, discuss and determine the severity of the issue. If necessary, members of the solana-labs/security-incident-response group may add other github users to the advisory to assist.
If it is determined that this not a critical network issue then the advisory should be closed and if more follow-up is required a normal Solana public github issue should be created.
If it is determined that this is not a critical network issue then the advisory should be closed and if more follow-up is required a normal Solana public github issue should be created.

### 3. Prepare Fixes
For the affected branches, typically all three (edge, beta and stable), prepare a fix for the issue and push them to the corresponding branch in the private repository associated with the draft security advisory.
Expand Down
2 changes: 1 addition & 1 deletion ci/README.md
Original file line number Diff line number Diff line change
Expand Up @@ -73,7 +73,7 @@ sudo CUDA=1 ./setup-new-buildkite-agent/setup-new-machine.sh

### Configure Node for Buildkite-agent based CI

- Install `buildkite-agent` and set up it user environment with:
- Install `buildkite-agent` and set up its user environment with:
```bash
sudo ./setup-new-buildkite-agent/setup-buildkite.sh
```
Expand Down
6 changes: 3 additions & 3 deletions docs/src/validator/gossip.md
Original file line number Diff line number Diff line change
Expand Up @@ -34,7 +34,7 @@ record with the most recent timestamp.

### Push Message

A node sends a push message to tells the cluster it has information to share.
A node sends a push message to tell the cluster it has information to share.
Nodes send push messages to `PUSH_FANOUT` push peers.

Upon receiving a push message, a node examines the message for:
Expand All @@ -56,7 +56,7 @@ Upon receiving a push message, a node examines the message for:

### Push Peers, Prune Message

A nodes selects its push peers at random from the active set of known peers. The
A node selects its push peers at random from the active set of known peers. The
node keeps this selection for a relatively long time. When a prune message is
received, the node drops the push peer that sent the prune. Prune is an
indication that there is another, higher stake weighted path to that node than
Expand Down Expand Up @@ -133,6 +133,6 @@ The main differences are:
- Push messages have a wallclock that is signed by the originator. Once the
wallclock expires the message is dropped. A hop limit is difficult to
implement in an adversarial setting.
- Lazy Push is not implemented because its not obvious how to prevent an
- Lazy Push is not implemented because it's not obvious how to prevent an
adversary from forging the message fingerprint. A naive approach would allow
an adversary to be prioritized for pull based on their input.
4 changes: 2 additions & 2 deletions docs/src/validator/runtime.md
Original file line number Diff line number Diff line change
Expand Up @@ -28,9 +28,9 @@ At the _execute_ stage, the loaded accounts have no data dependencies, so all th
The runtime enforces the following rules:

1. Only the _owner_ program may modify the contents of an account. This means that upon assignment data vector is guaranteed to be zero.
2. Total balances on all the accounts is equal before and after execution of a transaction.
2. Total balances on all the accounts are equal before and after execution of a transaction.
3. After the transaction is executed, balances of read-only accounts must be equal to the balances before the transaction.
4. All instructions in the transaction executed atomically. If one fails, all account modifications are discarded.
4. All instructions in the transaction are executed atomically. If one fails, all account modifications are discarded.

Execution of the program involves mapping the program's public key to an entrypoint which takes a pointer to the transaction, and an array of loaded accounts.

Expand Down
6 changes: 3 additions & 3 deletions geyser-plugin-interface/README.md
Original file line number Diff line number Diff line change
Expand Up @@ -6,10 +6,10 @@

# Solana Geyser Plugin Interface

This crate enables an plugin to be added into the Solana Validator runtime to
This crate enables a plugin to be added into the Solana Validator runtime to
take actions at the time of account updates or block and transaction processing;
for example, saving the account state to an external database. The plugin must
implement the `GeyserPlugin` trait. Please see the detail of the
implement the `GeyserPlugin` trait. Please see the details of the
`geyser_plugin_interface.rs` for the interface definition.

The plugin should produce a `cdylib` dynamic library, which must expose a `C`
Expand All @@ -18,7 +18,7 @@ interface.

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 databases.
an external PostgreSQL database.

More information about Solana is available in the [Solana documentation](https://docs.solana.com/).

Expand Down
8 changes: 4 additions & 4 deletions metrics/README.md
Original file line number Diff line number Diff line change
Expand Up @@ -4,10 +4,10 @@

## InfluxDB

In oder to explore validator specific metrics from mainnet-beta, testnet or devnet you can use Chronograf:
In order to explore validator specific metrics from mainnet-beta, testnet or devnet you can use Chronograf:

* https://metrics.solana.com:8888/ (production enviroment)
* https://metrics.solana.com:8889/ (testing enviroment)
* https://metrics.solana.com:8888/ (production environment)
* https://metrics.solana.com:8889/ (testing environment)

For local cluster deployments you should use:

Expand Down Expand Up @@ -47,4 +47,4 @@ The fee market dashboard shows:

### Ping Results

The ping reults dashboard displays relevant information about the Ping API
The ping results dashboard displays relevant information about the Ping API
2 changes: 1 addition & 1 deletion net/README.md
Original file line number Diff line number Diff line change
Expand Up @@ -43,7 +43,7 @@ $ ./gce.sh delete #<-- Dispose of the network (billing stops here)

### Running the network over public IP addresses
By default private IP addresses are used with all instances in the same
availability zone to avoid GCE network engress charges. However to run the
availability zone to avoid GCE network egress charges. However to run the
network over public IP addresses:
```bash
$ ./gce.sh create -P ...
Expand Down

0 comments on commit 05dae59

Please sign in to comment.