The heir tutorial by komodo developer dixmy is the best resource i have found for the guts of making a crypto condition apart from jl777 explanations throughout online chats.
An important concept to also understand with utxo programming is the patterns used, like baton and marker.
Komodo CC are powerful and have full access to all blockchain features. Creating crypto conditions covers:
- blockchain functions
- wallet functions
- transaction functions
- bitcore optimized integration
- consensus augmenting and customization
- other crypto conditions
- external systems and data
In order to begin creating crypto conditions, understanding the CCinclude.h header file is fundamental which is included by the CCtx.cpp (crypto conditions transaction) logic. CCinclude.h pulls in some parts of blockchain tech that come from bitcoin and zcash development as well as well as Komodo's innovations.
To keep things easy there are three types of descriptors: Informational, Fundamental & CC-Fundamental.
- CC-Fundamental are the parts of Komodo tech that I need to become familiar with in order to make industry leaps in p2p dApp developments.
- Fundamental are principles that apply to blockchain or cryptography.
- Informational is just that, usually only core-devs will find this of more stimulating use.
All about signing crypto condition transactions. No modifications are required, but reading through the function names to know what happens in the signing process may be useful but not as important as following the code in CCcustom.cpp as an example. CCtx function FinalizeCCTx will properly sign both CC and normal inputs, adds normal change and the opreturn. This allows the contract transaction functions to create the appropriate vins and vouts and have FinalizeCCTx create a properly signed transaction.
By using -addressindex=1, it allows tracking of all the CC addresses.
The CCtx by calling CCinit to return a struct with information of the crypto condition. This is in CCcustom.cpp and most of the functions needed to extend or create new crypto conditions can be found in this file.
A CC scriptPubKey can only be spent if it is properly signed and validated. By constraining the vins and vouts, it is possible to implement a variety of functionality. CC vouts have an otherwise non-standard form, but it is properly supported by the enhanced bitcoin protocol code as a "cryptoconditions" output and the same pubkey will create a different address.
This allows creation of a special address(es) for each crypto condition type, which has the privkey public. That allows anybody to properly sign and spend it, but with the constraints on what is allowed in the validation code, the contract functionality can be implemented.
IMPORTANT: make sure that all CC inputs and CC outputs are properly accounted for and reconcile to the satoshi. The built in utxo management will enforce overall vin/vout constraints but it wont know anything about the CC constraints. That is what your Validate function needs to do.
Generally speaking, there will be normal coins that change into CC outputs, CC outputs that go back to being normal coins, CC outputs that are spent to new CC outputs.
Make sure both the CC coins and normal coins are preserved and follow the rules that make sense. It is a good idea to define specific roles for specific vins and vouts to reduce the complexity of validation.
This file pulls in the core of crypto conditions. The first application of crypto conditions was importing coins, a way of migrating coins from chain to chain in Komodo's multi-chain architecture responsible for scaling.
When creating a new crypto condition, a new EVAL code needs to be created by the developer for consensus code. A basic validation route can be describe as:
- Tx needs validation
- Type of validation is a CC vout (not a bitcoin protocol P2SK, P2PK...)
- Look up which CC by it's EVAL code to evaluate it's validation rules
Beyond needing to know which eval code is being referenced in the CC vout, other evaluation done in eval.cpp tests the validity of an Eval node and includes validation of blockchain artifacts like a block and transactions. Evaluation of notary specific functions like MoM from a notarization tx hash and checking the merkle roots and branches for these types of applications.
CCutils has low level functions that are universally useful for all crypto conditions. They are defined in CCinclude.h and implemented in CCutils.cpp. Understanding what functions are already available will rapidly progress dApp development from weeks to days.
Base58 is group of binary-to-text encoding schemes used to represent large integers as alphanumeric text. It is similar to Base64 but has been modified to avoid both non-alphanumeric characters and letters which might look ambiguous when printed. It is designed for human users who manually enter the data and also allows easy copy/paste because a double click usually selects the whole string. More info can be read in the Mastering Bitcoin book or from wikipedia.
This has information like maximum length of an assetchains name, sapling activation time and other core developer variables to not worry about.
Any C structure can be stored in a hash table using uthash. Just add a UT_hash_handle to the structure and choose one or more fields in your structure to act as the key. More information can be found in the copyright notice of the files.
These files are included with KV & notarized data operations.
Aligned with RFC 7159, the JSON data interface format is lightweight, text-based language independent data interchange format. The RFC has been updated to RFC 8259.
Crypto conditions have their own addresses. The types of addresses need wallet functionality, this is where it comes from.
Bitcoin script related stuff and the implementation of CC signing is done in sign.cpp
A file that parses, encodes and decodes hex.
This file defines some of the standard scripts in bitcoin protocol (P2PK, P2...). Parsing, solving and extraction of puzzles and destinations. The most current documentation for this file in particular is in the bitcoin code base. The comments are particular helpful to understand the bitcoin protocol https://github.com/bitcoin/bitcoin/blob/master/src/script/standard.h
Bitcoin script is the low level protocol, this file defines the protocol. Crypto conditions extends bitcoin script by creating a new vout. Tech Tuesday https://komodoplatform.com/tech-tuesday-update-7/ and UTXO information on KMD website explains more https://komodoplatform.com/crypto-conditions-utxo-based-smart-contracts/
Here is where the Crypto Conditions module comes alive in Komodo. Such low level understandings are not required for nearly all developers. It is like a dApp developer needing to know high level concepts of transactions and UTXOs in a wallet, but not necessarily the low level bitcoin protocol and script.