gaspersic/solana
1
0
Fork 0
Code Issues Pull Requests Projects Releases Wiki Activity

Deprecate commitment variants (#14797)

Browse Source 
* 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
This commit is contained in:
Tyera Eulberg
2021-01-26 12:23:07 -07:00
committed by GitHub
parent e08d2e6fcc
commit ffa5c7dcc8
37 changed files with 540 additions and 322 deletions
Download Patch File Download Diff File Expand all files Collapse all files

14
docs/src/developing/clients/jsonrpc-api.md
View File

@ -134,22 +134,20 @@ to report progress and higher levels to ensure the state will not be rolled back
In descending order of commitment (most finalized to least finalized), clients
may specify:
- `"max"` - the node will query the most recent block confirmed by supermajority
- `"finalized"` - the node will query the most recent block confirmed by supermajority
of the cluster as having reached maximum lockout, meaning the cluster has
recognized this block as finalized
- `"root"` - the node will query the most recent block having reached maximum
lockout on this node, meaning the node has recognized this block as finalized
- `"singleGossip"` - the node will query the most recent block that has been voted on by supermajority of the cluster.
- `"confirmed"` - the node will query the most recent block that has been voted on by supermajority of the cluster.
- It incorporates votes from gossip and replay.
- It does not count votes on descendants of a block, only direct votes on that block.
- This confirmation level also upholds "optimistic confirmation" guarantees in
release 1.3 and onwards.
- `"recent"` - the node will query its most recent block. Note that the block
- `"processed"` - the node will query its most recent block. Note that the block
may not be complete.
For processing many dependent transactions in series, it's recommended to use
`"singleGossip"` commitment, which balances speed with rollback safety.
For total safety, it's recommended to use`"max"` commitment.
`"confirmed"` commitment, which balances speed with rollback safety.
For total safety, it's recommended to use`"finalized"` commitment.
#### Example
@ -2966,7 +2964,7 @@ After connecting to the RPC PubSub websocket at `ws://<ADDRESS>/`:
- Submit subscription requests to the websocket using the methods below
- Multiple subscriptions may be active at once
- Many subscriptions take the optional [`commitment` parameter](jsonrpc-api.md#configuring-state-commitment), defining how finalized a change should be to trigger a notification. For subscriptions, if commitment is unspecified, the default value is `"singleGossip"`.
- Many subscriptions take the optional [`commitment` parameter](jsonrpc-api.md#configuring-state-commitment), defining how finalized a change should be to trigger a notification. For subscriptions, if commitment is unspecified, the default value is `"confirmed"`.
### accountSubscribe