The following is a short summary of a blog post written by Komodo's lead developer, JL777.
Transactionalization is a technology offered as a part of the Antara Framework. At the time this blog post was written, Antara Modules were called "CC contracts," but the underlying technology is the same.
In the Bitcoin protocol, each node in a network needs to run every transaction through the consensus mechanism. Therefore, every inefficient line of code in a consensus mechanism decreases network efficiency by the number of computers executing the code.
If there are 10,000 computers (and users) in a network, that inefficient line of code is run 10,000 times. Therefore, a developer wants to be sure to reduce every inefficient line of code possible.
When dealing with logical contracts, this challenge is especially important to solve.
On the Conceptual Origin of Antara Modules
The Bitcoin protocol can handle many small contract-related tasks, such as those necessary for atomic swaps, but the protocol cannot handle arbitrary code. This is the impetus for including a technology called "CryptoConditions" to the core of Antara Modules.
CryptoConditions is an open-source technology in the cryptocurrency industry that allows developers to add their own arbitrary code to a consensus mechanism, and to call that arbitrary code while the software is running on a user's machine.
CryptoConditions is often called "CC" for short, and this convention is followed here.
On top of CC, Komodo also added a custom technology provided by the Komodo team. This technology is called "Custom Evaluation Functions," or CEF.
CEF operates in coordination with CC and CEF allows for even more flexibility. CEF is capable of handling arbitrary code, and when CEF finishes processing the code it returns the final result as a True/False statement. This statement is passed on to the consensus mechanism
Designing an Antara Module
The first step in designing an Antara Module is to restate the problem you are trying to solve in a way that allows the problem to be solved through transactions: this is transactionalization.
Each node on the Smart Chain network must process all transactions, and therefore there must be an incentive for at least some users to perform the work of validating transactions.
Some of these incentives can be done through having interlocking transactions, where the transaction cannot be spent without first processing the transaction that spent it. Other forms of incentives can also be designed.
These incentives and transactions create an ongoing procession of actions taken by users of the module that leads all users on the network to a desirable final state.
For example, in the Faucet module, one interesting way to solve the problem of processing transactions is to have an address that has a private key that is publicly known to all users. In this manner, the person who is requesting funds from the faucet has the private key to the address that has the funds.
Therefore, the user is able to perform the work necessary to process the transaction. The reward they receive from the faucet provides the incentive necessary to have their computer perform the work to advance the transactions of the Faucet Module.
The aspect of having the private key publicly available is a unique and useful tool offered by the Antara Framework.
For more examples, the reader is invited to read the remaining portion of JL777's original blog post.