Interface AuthenticationVirtualMachine<ResolvedTransaction, AuthenticationProgram, ProgramState>

Debug a program by fully evaluating it, cloning and adding each intermediate ProgramState to the returned array. The first ProgramState in the returned array is the initial program state, and the last ProgramState in the returned array is the result of the evaluation.

Note, If the virtual machine is multi-phasic (as is the case with all known bitcoin forks due to P2SH), the initial program state at the start of each phase will appear in the debug trace. For example, all inputs in all bitcoin forks use at least two phases 1) the unlocking phase 2) the locking phase. Inputs that match the P2SH format perform a third P2SH phase. Other virtual machines may include different phases (e.g. the SegWit phase in BTC). For each phase performed, the count of program states in the final debug trace will increase by one, even if the phase includes no instructions.

Remarks

Even for simple virtual machines, this method includes one final program state in addition to the output that would otherwise be produced by stateDebug. This occurs because the evaluate method of the instruction set must return one final program state after stateContinue has produced a false. Often, this is cloned from the previous program state, but it is also possible that this final state will include changes produced by the remaining portion of the instruction set's evaluate method (e.g. P2SH evaluation). In any case, this final program state is not a "duplicate": it is the finalized result of the complete virtual machine evaluation.

Fully evaluate a program, returning the resulting ProgramState.

Clone the provided ProgramState.

Test the ProgramState to determine if execution should continue.

Return an array of program states by fully evaluating state, cloning and adding each intermediate state to the returned array. The first ProgramState in the returned array is the initial program state, and the last ProgramState in the returned array is the first program state that returns false when provided to stateContinue.

Note, this method is typically an implementation detail of the virtual machine and cannot produce a final result. In most cases, debug is the proper method to debug a program.

Return a new program state by cloning and fully evaluating state.

To evaluate a state, the state is cloned and provided to stateStepMutate until a final result is obtained (a ProgramState that returns false when provided to stateContinue).

Note, this method is typically an implementation detail of the virtual machine and cannot produce a final result. In most cases, evaluate is the proper method to evaluate a program.

Clones and return a new program state advanced by one step.

A faster, less-safe version of step that directly modifies the provided program state.

Verify that a program state has completed evaluation successfully.

Remarks

This method verifies a final ProgramState as emitted by the evaluate or debug methods. When manually using the stateStep or stateStepMutate methods, ensure the ProgramState has finished evaluation using the stateContinue method.

Statelessly verify a fully-resolved transaction (e.g. the decoded transaction and an array of source outputs that are spent by its inputs).

Returns true if the transaction is valid or an error message on failure.

Remarks

While the virtual machine can perform all stateless components of transaction validation, many applications also require stateful validation – e.g. checking for conflicting transactions (double-spends) – before accepting a transaction.

For example, before a statelessly verified BCH transaction can be added to a block, node implementations must confirm that:

• All spentOutputs are still unspent.
• The transaction's claimed relative and absolute locktime values meet consensus requirements. (For determinism, time and confirmation-related VM operations are performed using the precise locktime and sequenceNumber values encoded in the transaction rather than "current" values on the network at validation time. While these values may allow the VM to verify the transaction, implementations must still ensure that the values are consistent with reality before accepting the transaction. See BIP65, BIP68, and BIP112 for details.)