Warn lastValidSlot with some terminology tweaks (#15081)
* Warn lastValidSlot with some terminology tweaks * Apply suggestions from code review Co-authored-by: Tyera Eulberg <teulberg@gmail.com> * Restore previous arrangment of slot def. and tweak upon it * Apply suggestions from code review Co-authored-by: Tyera Eulberg <teulberg@gmail.com> Co-authored-by: Tyera Eulberg <teulberg@gmail.com>
This commit is contained in:
Ryo Onodera
GitHub
parent
e908a4b3fc
commit
85ffc8fa1c
|
|
@ -1220,7 +1220,7 @@ The result will be an RpcResponse JSON object with `value` set to a JSON object
|
||||||
|
|
||||||
- `blockhash: <string>` - a Hash as base-58 encoded string
|
- `blockhash: <string>` - a Hash as base-58 encoded string
|
||||||
- `feeCalculator: <object>` - FeeCalculator object, the fee schedule for this block hash
|
- `feeCalculator: <object>` - FeeCalculator object, the fee schedule for this block hash
|
||||||
- `lastValidSlot: <u64>` - last slot in which a blockhash will be valid
|
- `lastValidSlot: <u64>` - last slot in which a blockhash will be valid (NOTE: this can be inaccurate when there are [skipped slots](../../terminology.md#skipped-slot))
|
||||||
|
|
||||||
#### Example:
|
#### Example:
|
||||||
|
|
||||||
|
|
|
||||||
|
|
@ -468,18 +468,11 @@ curl -X POST -H "Content-Type: application/json" -d '{"jsonrpc":"2.0", "id":1, "
|
||||||
|
|
||||||
#### Blockhash Expiration
|
#### Blockhash Expiration
|
||||||
|
|
||||||
When you request a recent blockhash for your withdrawal transaction using the
|
You can check whether a particular blockhash is still valid by sending a
|
||||||
[`getFees` endpoint](developing/clients/jsonrpc-api.md#getfees) or `solana fees`, the
|
|
||||||
response will include the `lastValidSlot`, the last slot in which the blockhash
|
|
||||||
will be valid. You can check the cluster slot with a
|
|
||||||
[`getSlot` query](developing/clients/jsonrpc-api.md#getslot); once the cluster slot is
|
|
||||||
greater than `lastValidSlot`, the withdrawal transaction using that blockhash
|
|
||||||
should never succeed.
|
|
||||||
|
|
||||||
You can also doublecheck whether a particular blockhash is still valid by sending a
|
|
||||||
[`getFeeCalculatorForBlockhash`](developing/clients/jsonrpc-api.md#getfeecalculatorforblockhash)
|
[`getFeeCalculatorForBlockhash`](developing/clients/jsonrpc-api.md#getfeecalculatorforblockhash)
|
||||||
request with the blockhash as a parameter. If the response value is null, the
|
request with the blockhash as a parameter. If the response value is `null`, the
|
||||||
blockhash is expired, and the withdrawal transaction should never succeed.
|
blockhash is expired, and the withdrawal transaction using that blockhash should
|
||||||
|
never succeed.
|
||||||
|
|
||||||
### Validating User-supplied Account Addresses for Withdrawals
|
### Validating User-supplied Account Addresses for Withdrawals
|
||||||
|
|
||||||
|
|
|
||||||
|
|
@ -136,7 +136,7 @@ The role of a [validator](terminology.md#validator) when it is appending [entrie
|
||||||
|
|
||||||
## leader schedule
|
## leader schedule
|
||||||
|
|
||||||
A sequence of [validator](terminology.md#validator) [public keys](terminology.md#public-key). The cluster uses the leader schedule to determine which validator is the [leader](terminology.md#leader) at any moment in time.
|
A sequence of [validator](terminology.md#validator) [public keys](terminology.md#public-key) mapped to [slots](terminology.md#slot). The cluster uses the leader schedule to determine which validator is the [leader](terminology.md#leader) at any moment in time.
|
||||||
|
|
||||||
## ledger
|
## ledger
|
||||||
|
|
||||||
|
|
@ -217,9 +217,17 @@ A 64-byte ed25519 signature of R (32-bytes) and S (32-bytes). With the requireme
|
||||||
This requirement ensures no signature malleability. Each transaction must have at least one signature for [fee account](terminology#fee-account).
|
This requirement ensures no signature malleability. Each transaction must have at least one signature for [fee account](terminology#fee-account).
|
||||||
Thus, the first signature in transaction can be treated as [transacton id](terminology.md#transaction-id)
|
Thus, the first signature in transaction can be treated as [transacton id](terminology.md#transaction-id)
|
||||||
|
|
||||||
|
## skipped slot
|
||||||
|
|
||||||
|
A past [slot](terminology.md#slot) that did not produce a [block](terminology.md#block), because the leader was offline or the [fork](terminology.md#fork) containing the slot was abandoned for a better alternative by cluster consensus. A skipped slot will not appear as an ancestor for blocks at subsequent slots, nor increment the [block height](terminology#block-height), nor expire the oldest `recent_blockhash`.
|
||||||
|
|
||||||
|
Whether a slot has been skipped can only be determined when it becomes older than the latest [rooted](terminology.md#root) (thus not-skipped) slot.
|
||||||
|
|
||||||
## slot
|
## slot
|
||||||
|
|
||||||
The period of time for which a [leader](terminology.md#leader) ingests transactions and produces a [block](terminology.md#block).
|
The period of time for which each [leader](terminology.md#leader) ingests transactions and produces a [block](terminology.md#block).
|
||||||
|
|
||||||
|
Collectively, slots create a logical clock. Slots are ordered sequentially and non-overlapping, comprising roughly equal real-world time as per [PoH](terminology.md#proof-of-history).
|
||||||
|
|
||||||
## smart contract
|
## smart contract
|
||||||
|
|
||||||
|
|
|
||||||
Loading…
Reference in New Issue