Update docs for Sapling to Canopy checkpoint change

book/src/dev/overview.md

@@ -27,8 +27,8 @@ The following are general desiderata for Zebra:
   perform Zcash-related tasks.  Implementation details of each
   component should not leak into all other components.
 
-* Zebra should checkpoint on Sapling activation and drop all
+* Zebra should checkpoint on Canopy activation and drop all
-  Sprout-related functionality not required post-Sapling.
+  Sprout-related functionality not required post-Canopy.
 
 ### Non-Goals
 
@@ -189,7 +189,7 @@ for Zcash script inspection, debugging, etc.
     transaction is accepted in a particular chain state context.
   - verifying mempool (unconfirmed) transactions
 - block checkpoints
-  - mandatory checkpoints (genesis block, sapling activation)
+  - mandatory checkpoints (genesis block, canopy activation)
   - optional regular checkpoints (every Nth block)
 - modifying the chain state
   - adding new blocks to `ZebraState`, including chain reorganisation

book/src/dev/rfcs/0005-state-updates.md

@@ -258,7 +258,7 @@ new chains for `push` when new blocks arrive whose parent isn't a tip of an
 existing chain.
 
 **Note:** The `Chain` type's API is only designed to handle non-finalized
-data. The genesis block and all pre sapling blocks are always considered to
+data. The genesis block and all pre canopy blocks are always considered to
 be finalized blocks and should not be handled via the `Chain` type through
 `CommitBlock`. They should instead be committed directly to the finalized
 state with `CommitFinalizedBlock`. This is particularly important with the
@@ -419,7 +419,7 @@ chain and updates all side chains to match.
 
 Commit `block` to the non-finalized state.
 
-1. If the block is a pre-Sapling block, panic.
+1. If the block is a pre-Canopy block, panic.
 
 2. If any chains tip hash equal `block.header.previous_block_hash` remove that chain from `self.chain_set`
 

book/src/dev/rfcs/0006-contextual-difficulty.md

@@ -225,7 +225,7 @@ Contextual validation is implemented in
 `StateService::check_contextual_validity`, which calls a separate function for
 each contextual validity check.
 
-In Zebra, contextual validation starts after Sapling activation, so we can assume
+In Zebra, contextual validation starts after Canopy activation, so we can assume
 that the relevant chain contains at least 28 blocks on Mainnet and Testnet. (And
 panic if this assumption does not hold at runtime.)
 
@@ -423,7 +423,7 @@ the sum of these difficulty thresholds will be less than or equal to
 `(2^251 − 1)*17 = 2^255 + 2^251 - 17`. Therefore, this calculation can not
 overflow a `u256` value. So the function is infalliable.
 
-In Zebra, contextual validation starts after Sapling activation, so we can assume
+In Zebra, contextual validation starts after Canopy activation, so we can assume
 that the relevant chain contains at least 17 blocks. Therefore, the `PoWLimit`
 case of `MeanTarget()` in the Zcash specification is unreachable.
 
@@ -492,7 +492,7 @@ impl NetworkUpgrade {
 
 #### Implementation notes
 
-In Zebra, contextual validation starts after Sapling activation, so we can assume
+In Zebra, contextual validation starts after Canopy activation, so we can assume
 that the relevant chain contains at least 28 blocks. Therefore:
 * `max(0, height − PoWMedianBlockSpan)` in the `MedianTime()` calculation
    simplifies to `height − PoWMedianBlockSpan`, and
@@ -577,7 +577,7 @@ pub fn is_testnet_min_difficulty_block(
 #### Implementation notes
 
 In Zcash, the Testnet minimum difficulty rule starts at block 299188, and in
-Zebra, contextual validation starts after Sapling activation. So we can assume
+Zebra, contextual validation starts after Canopy activation. So we can assume
 that there is always a previous block.
 
 Therefore, this function is infalliable.
@@ -596,7 +596,7 @@ minimum difficulty gap. We use the existing
 `ExpandedDifficulty::target_difficulty_limit` function to calculate the value of
 `ToCompact(PoWLimit(network))`.
 
-In Zebra, contextual validation starts after Sapling activation, so the genesis
+In Zebra, contextual validation starts after Canopy activation, so the genesis
 case of `Threshold()` in the Zcash specification is unreachable.
 
 #### Block difficulty threshold implementation

zebra-consensus/src/checkpoint/README.md

@@ -1,11 +1,11 @@
 # Zebra checkpoints
 
-Zebra validates pre-Sapling blocks using a list of `Mainnet` and `Testnet` block hash checkpoints:
+Zebra validates pre-Canopy blocks using a list of `Mainnet` and `Testnet` block hash checkpoints:
 
 - [Mainnet checkpoints](https://github.com/ZcashFoundation/zebra/blob/main/zebra-consensus/src/checkpoint/main-checkpoints.txt)
 - [Testnet checkpoints](https://github.com/ZcashFoundation/zebra/blob/main/zebra-consensus/src/checkpoint/test-checkpoints.txt)
 
-Zebra can also be configured to use these checkpoints after Sapling:
+Zebra can also be configured to use these checkpoints after Canopy:
 ```
 [consensus]
 checkpoint_sync = true

zebra-state/src/service/check/difficulty.rs

@@ -217,7 +217,7 @@ impl AdjustedDifficulty {
     ///
     /// Implements `MeanTarget` from the Zcash specification.
     fn mean_target_difficulty(&self) -> ExpandedDifficulty {
-        // In Zebra, contextual validation starts after Sapling activation, so we
+        // In Zebra, contextual validation starts after Canopy activation, so we
         // can assume that the relevant chain contains at least 17 blocks.
         // Therefore, the `PoWLimit` case of `MeanTarget()` from the Zcash
         // specification is unreachable.