From b21c89e4943a9068c5c5ff861452fc45309c3812 Mon Sep 17 00:00:00 2001 From: "mergify[bot]" <37929162+mergify[bot]@users.noreply.github.com> Date: Fri, 5 Feb 2021 07:07:00 +0000 Subject: [PATCH] Warn lastValidSlot with some terminology tweaks (#15081) (#15122) * Warn lastValidSlot with some terminology tweaks * Apply suggestions from code review Co-authored-by: Tyera Eulberg * Restore previous arrangment of slot def. and tweak upon it * Apply suggestions from code review Co-authored-by: Tyera Eulberg Co-authored-by: Tyera Eulberg (cherry picked from commit 85ffc8fa1c830052ae90f09430a038673c6255f0) Co-authored-by: Ryo Onodera --- docs/src/developing/clients/jsonrpc-api.md | 2 +- docs/src/integrations/exchange.md | 15 ++++----------- docs/src/terminology.md | 12 ++++++++++-- 3 files changed, 15 insertions(+), 14 deletions(-) diff --git a/docs/src/developing/clients/jsonrpc-api.md b/docs/src/developing/clients/jsonrpc-api.md index 80692fb87d..3062aff1fc 100644 --- a/docs/src/developing/clients/jsonrpc-api.md +++ b/docs/src/developing/clients/jsonrpc-api.md @@ -1193,7 +1193,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