Ticking.md: fix typos

Author: nfrisby

docs/website/contents/for-developers/Ticking.md

@@ -10,7 +10,7 @@ The ledger state that resulted from some block thus needs to be ticked across so
 Some crucial things can happen when ticking between blocks: deadlines come and go, epochs end and begin, protocol parameters change, or even the ledger rules themselves might change.
 
 However, applying blocks is not the only reason the Consensus Layer ticks.
-If it were, then ticking wouldn't need to be separately identified: it'd just be the first of however many "hidden" steps involved in applying a block.
+If it were, then ticking wouldn't need to be separately identified: it'd just be the first of however many "hidden" steps are involved in applying a block.
 Instead, ticking is used in a few places, some of which don't involve immediately subsequent header/block application.
 
 - Ticking advances protocol state between headers.
@@ -33,10 +33,9 @@ In Cardano, the only thing we ever need to forecast is the part of the ledger st
 This can be fully determined regardless of intervening blocks because the ledger rules ensure the relevant parts of the ledger state do not change without a minimum duration of forewarning (eg by retaining occasional snapshots of this data).
 That minimum duration of stability is therefore _the forecast range_, beyond which the code cannot necessarily do correct forecasting.
 
-Thus forecasting from an (unticked) ledger state in slot X to slot Y -- within the forecast range --- must be equivalent to ticking from X to Y and then "forecasting" from X to Y.
+Thus forecasting from an (unticked) ledger state in slot X to slot Y -- within the forecast range --- must be equivalent to ticking from X to Y and then "forecasting" from Y to Y.
 That'd be visualized as a square commuting diagram.
-Note that ticking from X to Y is usually only sound if there's no blocks in that slot interval.
-But the part of the ledger that we forecast is stable, and so cannot be affected by those blocks, and so the ticking is sound in the specific context of constraining forecasting.
+Note that ticking from X to Y is usually only sound if there's no blocks in that slot interval, but the part of the ledger that we forecast is stable, and so cannot be affected by those blocks, and so the ticking is sound in the specific context of characterizing forecasting.
 
 ## `Ticked` data family
 
@@ -49,7 +48,7 @@ By encoding this alternation between ticking and application in the types of the
 
 In our code base, ticking is a total function.
 Forecasting, on the other hand, is partial, since it is able to reject requests that violate the forecast range.
-(It's important to node that such a request is not doomed: the node might need to process another block or two before the slot of interest will be within the forecast range of its selected chain's tip.)
+(It's important to note that such a request is not doomed: the node might just need to process another block or two before the slot of interest will be within the forecast range of its selected chain's tip.)
 
 However, the Consensus Layer itself will never need to tick farther than the forecast range.
 The ledger rules might actually be able to do so, since it's mostly just a matter of the state _not_ changing.
@@ -63,9 +62,9 @@ The inductive argument is that all the ticking the Consensus Layer does is ultim
   The mint only proceeds if the leadership succeeded.
 - The ChainSync client forecasts the `LedgerView` before it applies any header.
 - The ChainSel logic only applies blocks whose headers arrived via a ChainSync client or were minted by this node.
-  The node also processes blocks from its on-disk storage when initializing, but those blocks were either minted by this node, acquired by this node via ChainSync, written by another trusted node (eg via Mithril) between executions, or written by some other means that is not explicitly unsupported.
+  The node also processes blocks from its on-disk storage when initializing, but those blocks were either minted by this node, acquired by this node via ChainSync (and BlockFetch), written by another trusted node (eg via Mithril) between executions, or written by some other means that is not explicitly unsupported.
 
-Thus, it's reasonable for the ticking function to have a total type because none of its calls within the node can fail; it's always guarded a forecast.
+Thus, it's reasonable for the ticking function to have a total type because none of its calls within the node can fail; it's always guarded by a forecast.
 
 ## Cross-Era Ticking
 
@@ -82,10 +81,10 @@ We could introduce a similar interface for ticking across eras.
 The implementation, which is lower-level than the `Ticked`-based interface, could use the less surprising tick-translate-tick scheme.
 
 Moreover, that cross-era ticking would still be guarded by cross-era forecasting, and so it would be bounded by the cross-era forecast range (which is not necessarily equivalent to either era's internal forecast range).
-In particular, the cross-era forecast range cannot cross multiple era boundaries, which is justified due and other assumptions about how much warning there is ahead of an era transition.
+In particular, the cross-era forecast range cannot cross multiple era boundaries, which is justified by lower bounds on how much warning there is within an era ahead of the next era transition.
 Thus the HFC only requires a cross-era ticking function from each era to the next, rather than to even later eras.
 
-## Bounding Ticking/Forecasting Computations
+## Bounding Ticking and Forecasting Computations
 
 On a single valid chain, the Consensus Layer will never tick across the same slots multiple times.
 However, Ouroboros involves short forks and potentially invalid blocks.
@@ -94,6 +93,6 @@ On the other hand, even for a single chain, the Consensus Layer would forecast a
 Ideally all ticks would be inexpensive, but the occasional spike is managable, since short forks are short lived.
 An expensive forecast, on the other hand, can be disastrous.
 If the leadership check's forecast takes too long, then the node might be late to produce its block.
-If that forecast takes longer than a slot, then the node might not check every slot, which is unacceptable.
+If that forecast takes longer than a slot, then the node might not even check every slot, which is unacceptable.
 
-For these reasons, there the ledger rules contain certain optimizations that either prevent forecasts from ever paying certain costs or else ensure that forecasting across some particular slot is only expensive the first time it happens and subsequent forecasts will then avoid those costs via memoization.
+For these reasons, the ledger rules contain certain optimizations that either prevent forecasts from ever paying certain costs or else ensure that forecasting across some particular slot is only expensive the first time it happens and subsequent forecasts will then avoid those costs via memoization.