efficient revalidation of transactions

[mrBliss]

trafficstars

Consensus has two ways to "apply a transaction":

• applyTx: apply a transaction to the ledger, validating the transaction and returning the updated ledger.

• reapplyTx:

  Re-apply a transaction

  When we re-apply a transaction to a potentially different ledger state expensive checks such as cryptographic hashes can be skipped, but other checks (such as checking for double spending) must still be done.

It would be great if the Shelley ledger provided something we could use to implement reapplyTx.

As this is an optimisation, this is not strictly need for the Shelley testnet, but it would be good to have for mainnet.

[nc6]

There's a few aspects to this:

1. Create an interpreter that discards Predicate clauses. This can be closely modelled on applySTSIndifferently (https://github.com/input-output-hk/cardano-ledger-specs/blob/master/semantics/executable-spec/src/Control/State/Transition/Extended.hs#L185). Then this needs to be wired upwards (variant on applySTS etc)
2. There are some uses of predicates for control flow. These can particularly be spotted by looking for cases where there are multiple transitionRules in an STS. We need to make sure that these do run, so probably the correct solution will be to add an additional constructor for them in Clause (https://github.com/input-output-hk/cardano-ledger-specs/blob/master/semantics/executable-spec/src/Control/State/Transition/Extended.hs#L115)
3. Add an interface to reapply a Tx to the API module (https://github.com/input-output-hk/cardano-ledger-specs/blob/master/shelley/chain-and-ledger/executable-spec/src/Shelley/Spec/Ledger/API/Mempool.hs). This should follow the existing applyTxs, but call the new, non-validating interpreter.

[nc6]

https://github.com/input-output-hk/cardano-ledger-specs/pull/1610 gives us part 1. Part 2 is easy to change, but at the moment we don't have any control flow predicates, so I've left it for the moment. Part 3 will come today

[nc6]

Actually, that's a lie. I hadn't read the comment about still needing to check for e.g. double spending - I thought this was reapplying a transaction to the very same ledger state.

We don't currently distinguish between "expensive" checks and others, so that would also be needed to do this.