Document how we review consensus rule changes after audits

[teor2345]

Motivation

We are about to finish implementing all the Zcash consensus rules for a validating node, and get Zebra audited. After the audit, we will need to make sure Zebra keeps implementing the same consensus rules.

Consensus rule changes can happen due to:

• spec or ZIP changes
• Zebra consensus rule bugs
• refactors
• dependency updates

Scheduling

We should spend an hour or two creating a draft document, then update it later as needed.

This should include the mempool rule documentation in #3188.

Process Changes

We should document the requirements for new consensus rules, and consensus rule updates:

• quote the consensus rule from the spec or ZIP
• link to the relevant section in the spec or ZIP
• explain how Zebra implements it
• test success and failure cases for the consensus rule
• validate test vectors from zcashd, if available

We should also document how we identify the code that can change consensus rules:

• the function that implements the consensus rule
• all code that it calls, including other Zebra crates, and external dependencies
• any code that changes the data that's given to the function (for example, calling the function on different transaction versions)

Here is the ECC's policy for zcashd reviews:
#5996 (comment)

Related Work

• Document how we review dependency changes #3183
• Document how we review network protocol changes after audits #3187
• Document how we review mempool behaviour changes after audit #3188

[mpguerra]

Hey team! Please add your planning poker estimate with ZenHub @conradoplg @dconnolly @jvff @oxarbitrage @teor2345 @upbqdn

[teor2345]

This is effectively a duplicate of #5996, and it's a bit outdated.