Map out dataflow dependencies for block verification.

[hdevalence]

To implement the block verifier (#428), we need to have mapped out the data flow dependencies of all of the components of block validation. This will allow us to split the validation work into tasks with explicit dependencies.

[teor2345]

One possible design here is #516.

[hdevalence]

I think that #516 is mapping out how the validation code should be structured and which parts should be responsible for which parts of the consensus rules. That seems related but slightly different to this problem, which is mapping out what the logical data dependencies between the different components are and trying to classify work as "semantic" or "contextual" verification checks.

For instance:

• To validate Bitcoin-style transactions we need to do script evaluation, checking signatures, etc, and to check that the input UTXOs are actually UTXOs and haven't already been spent. The latter clearly depends on the chain state, but the former might not.
• As noted in §3.6 of the spec, the anchor of each spend description must refer to some earlier block's final sapling tree state. We'd like to separate the verification of the proof from the consistency check, but this means that we must plan the verification logic accordingly.

So I think that before finalizing the design of how verification should be laid out in the code (#516) we should make a map of all of the data required to verify a block and what the dependency relationships are.

[hdevalence]

Another reason to do this is that it will highlight exactly what data we need to store in our datastore and how. Right now we're not doing any indexing of transactions, etc., but we'll need to do that to be able to do verifications.