Cryptoconditions library v2 'mixed mode' notes
The cryptoconditions technology () is designed to build logical circuits of cryptographic functions such as validating electronic signatures or preimages.
Komodod team added a 'evalcode' extension to cryptoconditions that provides a condition based on the result of arbitrary code execution. This allows to extend the cryptoconditions technology virtually unlimited.
There have been several implications with the eval code extension that have required cryptoconditions version 2.
A cryptocondition is a pair of a condition and a fulfilment. The condition is an expected result of evaluation of the fulfilment. The fulfilment is a complete cryptocondition structure with all the data required to evaluate the fulfilment. For example, a signature condition contains a pubkey and the corresponding fulfilment contains the same pubkey and the signature. The resulting condition is a small fixed data array with a fingerprint of all sub conditions.
To validate a cryptocondition its fulfilment is validated and it must evaluate to true and the fingerprint is obtained to check against the condition.
This is similar to the PayToPubkeyHash script pair, where the scriptPubKey has a pubkey hash (condition) and the scriptSig has the pubkey itself and the signature. To validate a P2PKH the signature in the scriptSig is checked with the scriptSig's pubkey, then the hash of the pubkey is checked against the other pubkey's hash in the scriptPubKey.
The condition is the fingerprint of the root condition and all its subconditions, what prevents deriving the source fulfilment and improves security.
Cryptoconditions technology itself is blockchain agnostic.
But when we use cryptoconditions in komodo blockchain, with the eval extension, we often need to know about the condition content. For example when a cc tx spends a cc vout with some evalcode we need to know that its cc value goes to the same cc evalcode vouts. This means that cc value is kind of locked to a cc module and does not leak outside or injected from other cc modules or normal vouts. To ensure this locking we need to know that cc vouts have this module evalcode inside the condition in the tx scriptPubKeys. As normally conditions are hashes we needed a way to expose the evalcodes from inside.
For this purpose the cryptoconditions v2 were designed. It basically changes the condition structure in that evalcodes are exposed but the other content is still hashed. This allows for the cc module validation code to identify its own vouts and validate that the cc value is not leaked or injected.