Description
As it stands, the trait machinery in mintscript is rather elaborate. Would be nice to put some thought into simplifyintg them.
A chunk of the complexity stems from the fact that as it stands, there are two verification modes: full check and timelock-only check. If these could be unified in some way, it would immediately reduce complexity significantly. However, the two have different requirements on the kind of information needed from the context, which makes it not completely trivial.
There are two parts to the issue: extraction of script from transaction inputs (mintscript::translate module) and script verification (in mintscript::checkers). Let's briefly discuss the two in turn.
Script translation
Script translation currently has three modes:
- Regular transaction
- Block reward
- Timelock-only
The modes are distinguished using a type-based tag. In retrospect, this is probably an overkill. It is somewhat useful to distinguish between the transaction mode and the reward mode at type level. The transaction verifier is parametrized by the kind of transaction (regular/reward) that's being verified so the type helps to pick the correct implementation there. The timelock-only mode, however, could be just a standalone function without much loss.
Script verification
We currently expose the ScriptChecker object, which is paramtetrised by various "sub-checkers" for verifying timelocks, signatures, hashlocks, etc. It seems sufficient to expose just a pair of functions for full script checking and for timelock-only checking:
fn check_full<C: FullContext>(ctx: &mut C, script: WitnessScript) -> Result;
fn check_timelock_only<C: TimelockContext>(ctx: &mut C, script: WitnessScript) -> Result;This is much less flexible than the current approach with parametrized types but may be good enough. Presumably, the FullContext trait would be a subtrait of TimelockContext. As now, these provide the information about the transaction needed to verify it that is not directly part of the script.
The code may need refactoring to avoid duplication of shared parts. Alternatively, the functions may be implemented in terms of the current checkers, just exposing the simplified interface externally.