design: Add validation to the design doc

Add validation for:
  - blocks in the chain, and
  - transactions in the chain and mempool.

Also:
  - Note that zebra-script may do some script validation.
  - Describe the zebra-consensus dependencies.

Part of #428.

design/design.md

@@ -62,8 +62,6 @@ None: these are the core data structure definitions.
   - `ZcashSerialize` and `ZcashDeserialize`, which perform
     consensus-critical serialization logic.
 
-- context-free validation behaviour, e.g., signature, proof verification, etc.
-
 ### Exported types
 
 - [...]
@@ -114,8 +112,8 @@ routing outbound requests to appropriate peers.
 
 ### Responsible for
 
-- block and transaction storage APIs
+- block storage API
-  - operates on parsed block and transaction structs
+  - operates on parsed block structs
     - these structs can be converted from and into raw bytes
   - primarily aimed at network replication, not at processing
   - can be used to rebuild the database below
@@ -131,7 +129,17 @@ routing outbound requests to appropriate peers.
 
 ### Exported types
 
-- [...]
+- `Request`, an enum representing all possible requests in the internal protocol;
+  - blocks can be accessed via their chain height or hash
+  - confirmed transactions can be accessed via their block, or directly via their hash
+- `Response`, an enum representing all possible responses in the internal protocol;
+- `init() -> impl Service`, the main entry-point.
+
+The `init` entrypoint returns a `Service` that can be used to
+send requests for the chain state.
+
+All state management (adding blocks, getting blocks by index or hash) is completely
+encapsulated.
 
 `zebra-script`
 ---------------
@@ -143,6 +151,8 @@ routing outbound requests to appropriate peers.
 ### Responsible for
 
 - the minimal Bitcoin script implementation required for Zcash
+- script parsing
+- context-free script validation
 
 ### Notes
 
@@ -164,21 +174,43 @@ for Zcash script inspection, debugging, etc.
 
 ### Internal Dependencies
 
-- `zebra-chain`
+- `zebra-chain` for data structures and parsing.
-- `zebra-state`
+- `zebra-state` to read and update the state database.
-- `zebra-script`
+- `zebra-script` for script parsing and validation.
 
 ### Responsible for
 
 - consensus-specific parameters (network magics, genesis block, pow
   parameters, etc) that determine the network consensus
 - consensus logic to decide which block is the current block
-- all context-dependent validation logic, e.g., determining whether a
+- block and transaction verification
-  transaction is accepted in a particular chain state context.
+  - context-free validation, e.g., signature, proof verification, etc.
+  - context-dependent validation, e.g., determining whether a
+    transaction is accepted in a particular chain state context.
+  - verifying mempool (unconfirmed) transactions
+- block checkpoints
+  - mandatory checkpoints (genesis block, sapling activation)
+  - optional regular checkpoints (every Nth block)
+- modifying the chain state
+  - adding new blocks to `ZebraState`, including chain reorganisation
+  - adding new transactions to `ZebraMempoolState`
+- storing the transaction mempool state
+  - mempool transactions can be accessed via their hash
+- providing `tower::Service` interfaces for all of the above to
+  support backpressure and batch validation.
 
 ### Exported types
 
-- [...]
+- `block::init() -> impl Service`, the main entry-point for block
+  verification.
+- `ZebraMempoolState`
+  - all state management (adding transactions, getting transactions
+    by hash) is completely encapsulated.
+- `mempool::init() -> impl Service`, the main entry-point for
+    mempool transaction verification.
+
+The `init` entrypoints return `Service`s that can be used to
+verify blocks or transactions, and add them to the relevant state.
 
 `zebra-rpc`
 ------------