diff --git a/docs/src/developing/clients/jsonrpc-api.md b/docs/src/developing/clients/jsonrpc-api.md index 241bd111d6..a8fc682f6a 100644 --- a/docs/src/developing/clients/jsonrpc-api.md +++ b/docs/src/developing/clients/jsonrpc-api.md @@ -1220,7 +1220,7 @@ The result will be an RpcResponse JSON object with `value` set to a JSON object - `blockhash: ` - a Hash as base-58 encoded string - `feeCalculator: ` - FeeCalculator object, the fee schedule for this block hash -- `lastValidSlot: ` - last slot in which a blockhash will be valid +- `lastValidSlot: ` - last slot in which a blockhash will be valid (NOTE: this can be inaccurate when there are [skipped slots](../../terminology.md#skipped-slot)) #### Example: diff --git a/docs/src/integrations/exchange.md b/docs/src/integrations/exchange.md index ffc7234e45..92ae18c760 100644 --- a/docs/src/integrations/exchange.md +++ b/docs/src/integrations/exchange.md @@ -468,18 +468,11 @@ curl -X POST -H "Content-Type: application/json" -d '{"jsonrpc":"2.0", "id":1, " #### Blockhash Expiration -When you request a recent blockhash for your withdrawal transaction using the -[`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 +You can check whether a particular blockhash is still valid by sending a [`getFeeCalculatorForBlockhash`](developing/clients/jsonrpc-api.md#getfeecalculatorforblockhash) -request with the blockhash as a parameter. If the response value is null, the -blockhash is expired, and the withdrawal transaction should never succeed. +request with the blockhash as a parameter. If the response value is `null`, the +blockhash is expired, and the withdrawal transaction using that blockhash should +never succeed. ### Validating User-supplied Account Addresses for Withdrawals diff --git a/docs/src/terminology.md b/docs/src/terminology.md index 77cffd3562..37b3702a40 100644 --- a/docs/src/terminology.md +++ b/docs/src/terminology.md @@ -136,7 +136,7 @@ The role of a [validator](terminology.md#validator) when it is appending [entrie ## 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 @@ -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). 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 -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