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

Deprecate commitment variants (bp #14797) (#14858)

Browse Source 
* Deprecate commitment variants (#14797)

* 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

(cherry picked from commit ffa5c7dcc8)

* Fix 1.5 stake-o-matic

Co-authored-by: Tyera Eulberg <teulberg@gmail.com>
Co-authored-by: Tyera Eulberg <tyera@solana.com>
This commit is contained in:
mergify[bot]
2021-01-26 20:49:04 +00:00
committed by GitHub
parent d380b9cef7
commit 3c67f71695
37 changed files with 541 additions and 323 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

2
docs/src/proposals/simple-payment-and-state-verification.md
View File

@@ -149,7 +149,7 @@ 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 "SingleGossip" confirmation
subscrption 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.