* Document AppendVec
* Remove the almost-duplicate state in AppendVec
AppendVec was maintaining two offsets, `current_len` and
`append_offset`. Despite the different looking names, the two
values have the same meaning, but were updated at slightly different
times. When appending a batch of accounts, `current_len` updates would
be immediately available to other threads after each append, whereas
`append_offset` would only be updated after its mutex was unlocked.
`append_offset` is redundant. By removing it, we eliminate potential
bugs and no longer need to suppress clippy warnings.
* Remove get_mut() from AppendVec design
Only the offset into the AppendVec memory is thread-safe. The memory
itself is only threadsafe because it is append-only and is otherwise
unprotected. Adding get_mut() would only be safe if the memory was
protected by a ReadWrite lock.
* docs: add token balances response info
* docs: add blockTime to getConfirmedSignatures and getConfirmedTransaction
* docs: update example responses
* fix: remove space
* reorg validator economics
* overview cleanup
* terminology
* terminology formatting
* katex for docusaurus
* adjusted staking yield writeup
* more reorg
* move section header
* rm unlinked mds
* add new mds
* Update docs/src/inflation/terminology.md
Co-authored-by: Dan Albert <dan@solana.com>
* Update docs/src/inflation/terminology.md
Co-authored-by: Dan Albert <dan@solana.com>
* Update docs/src/inflation/terminology.md
Co-authored-by: Dan Albert <dan@solana.com>
* Update docs/src/inflation/terminology.md
Co-authored-by: Dan Albert <dan@solana.com>
* Update docs/src/inflation/terminology.md
Co-authored-by: Dan Albert <dan@solana.com>
* Update docs/src/transaction_fees.md
Co-authored-by: Dan Albert <dan@solana.com>
* addressing Dans comments in #14868
* incorporating pr commits
* trailing whitespaces
* more trailing whitespaces
* remove services link and add plot
* add plots
Co-authored-by: Dan Albert <dan@solana.com>
* Deprecate commitment variants
* Add new CommitmentConfig builders
* Add helpers to avoid allowing deprecated variants
* Remove deprecated transaction-status code
* Include new commitment variants in runtime commitment; allow deprecated as long as old variants persist
* Remove deprecated banks code
* Remove deprecated variants in core; allow deprecated in rpc/rpc-subscriptions for now
* Heavier hand with rpc/rpc-subscription commitment
* Remove deprecated variants from local-cluster
* Remove deprecated variants from various tools
* Remove deprecated variants from validator
* Update docs
* Remove deprecated client code
* Add new variants to cli; remove deprecated variants as possible
* Don't send new commitment variants to old clusters
* Retain deprecated method in test_validator_saves_tower
* Fix clippy matches! suggestion for BPF solana-sdk legacy compile test
* Refactor node version check to handle commitment variants and transaction encoding
* Hide deprecated variants from cli help
* Add cli App comments
* Make exchange listening-for-deposits language stronger
* Update docs/src/integrations/exchange.md
Co-authored-by: Trent Nelson <trent.a.b.nelson@gmail.com>
* Update from deprecated method
Co-authored-by: Trent Nelson <trent.a.b.nelson@gmail.com>
* Add optimistically_confirmed field to TransactionStatus
* Update docs
* Convert new field to confirmation_status
* Update docs to confirmationStatus
* Update variants
* Update docs
* Just Confirmed
* Add stake programming documentation
We had some questions about stake programming documentation, and there
wasn't a place that contained information about the stake-o-matic and
other stake development in one place. This adds a page with that
information.
* Update docs/src/staking/stake-programming.md
Co-authored-by: Eric Williams <eric@solana.com>
* Update docs/src/staking/stake-programming.md
Co-authored-by: Eric Williams <eric@solana.com>
* Update docs/src/staking/stake-programming.md
Co-authored-by: Eric Williams <eric@solana.com>
* Update docs/src/staking/stake-programming.md
Co-authored-by: Eric Williams <eric@solana.com>
* Update docs/src/staking/stake-programming.md
Co-authored-by: Eric Williams <eric@solana.com>
* Apply suggestions from code review
* Remove trailing whitespace
Co-authored-by: Eric Williams <eric@solana.com>
* docs: Use "msg!" instead of "info!"
* Update docs/src/developing/deployed-programs/developing-rust.md
Co-authored-by: Michael Vines <mvines@gmail.com>
* Fix typo / format
Co-authored-by: Michael Vines <mvines@gmail.com>
To my understanding, the Solana process always logs a UTC timestamp
anyway, so this is not needed. Plus, using PST on servers is really
weird from a systems engineering point of view.
The --rpc-pubsub-enable-vote-subscription flag may be used to enable it.
The current vote subscription is problematic because it emits a
notification for *every* vote, so hundreds a second in a real cluster.
Critically it's also missing information about *who* is voting,
rendering all those notifications practically useless.
Until these two issues can be resolved, the vote subscription is not
much more than a potential DoS vector.
* Test for different ancestors with mismatch bank hash
* Test cleanup
* Remove nondeterministic ancestor check
* Update timestamp bounding feature key
* Update design doc
* Filter recent_timestamps to nodes voting within the last epoch
Co-authored-by: Stephen Akridge <sakridge@gmail.com>
* Clarify the commitment levels based on questions
Many people have asked about what commitment levels mean, and which to
choose. This update includes some of the language at
`sdk/src/commitment_config.rs` and a recommendation for different use
cases.
Additionally, the preflight commitment documentation was out of date,
specifying that "max" was always used, and this is no longer the case.
* Update docs/src/developing/clients/jsonrpc-api.md
Co-authored-by: Tyera Eulberg <teulberg@gmail.com>
* Update docs/src/developing/clients/jsonrpc-api.md
Co-authored-by: Tyera Eulberg <teulberg@gmail.com>
* Update docs/src/developing/clients/jsonrpc-api.md
Co-authored-by: Tyera Eulberg <teulberg@gmail.com>
* Fix typo
Co-authored-by: Tyera Eulberg <teulberg@gmail.com>