Enhancements to Solana's Documentations for Better Clarity (#34386)
* 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.
This commit is contained in:
parent
a2d7be0d07
commit
05dae592f4
|
@ -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.
|
||||
|
|
|
@ -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
|
||||
```
|
||||
|
|
|
@ -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:
|
||||
|
@ -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
|
||||
|
@ -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.
|
||||
|
|
|
@ -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.
|
||||
|
||||
|
|
|
@ -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`
|
||||
|
@ -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/).
|
||||
|
||||
|
|
|
@ -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:
|
||||
|
||||
|
@ -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
|
||||
|
|
|
@ -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 ...
|
||||
|
|
Loading…
Reference in New Issue