Things move fast at Komodo Platform. That’s why the Komodo team has decided to release a weekly briefing to cover all of the progress the Dev Team is making. This series of posts is called the Tech Tuesday Updates.
In case you’ve missed a previous edition and want to catch up, you can find all the previous Tech Tuesday updates here.
Smart Contracts and the UTXO Model
There is a lot of literature online about how the UTXO model is not suitable for smart contracts. However, this literature is now outdated with the advent of Komodo's custom consensus framework.
Ten Commandments = Standard Consensus Rules Modern Legal Framework = Custom Consensus Framework
Komodo's custom consensus framework is a format for expressing specific conditions and their completion. It is an open standard and supports multi algorithm, multi level, multi signature. All it requires is agreement on the description of the condition and the outcome.
It is communicable across blockchains. Komodo allows organizations to have independent and multiple blockchains to suit their needs. These independent blockchains can implement Custom Consensus modules across chains.
This cross chain functionality is not limited to Komodo, just Komodo is one of the first to implement it. Other conditions can go beyond smart contracts, so the consensus across the network can be extended, and included in this extension is off-chain data, external blockchain value, and more.
These conditions carry value and are not limited by (computer) language or borders. Like information, value can also be transmitted in new more compelling ways with custom consensus modules.
Custom Consensus framework UTXO - a new vout
There are 3 main types of vout in a bitcoin blockchain that cover 95+% of usage:
In our updated docs for 2019 we hope to provide all this information in one developer portal, but for now you have to rely on internet literature. For instance, you pay to a pubkey (an address) or you can do more complex things with the p2sh - this type of payment was created to reduce size of transaction (and therefore the transaction fee) for more complex scenarios.
In a transaction, there is an opcode (a command or function) that is performed to solve the cryptographic puzzle. A new opcode has been created to point to the custom consensus modules, and then which particular module is specified by its identifier within the collection of reference implementations.
So where a bitcoin transaction has opcodes for the 3 main types of vout, a 4th vout for custom consensus further specifies which conditions and completion logic to process. In the next paragraphs we will mention Gateways, Channels & Asset Tokenization - all on-chain - all decentralized - all extendable with more identifiers for the puzzle logic to verify:
- On-chain faucet replacing any number of unmaintained faucet projects
- On-chain betting using Pseudo Random Number Generators (PRNG) from both parties to create unpredictable random numbers
- On-chain oracles to provide off-chain data providers access to blockchain services, this is the focus of a project like Chainlink (LINK).
To reiterate - Komodo's custom consensus framework has enhanced the basic UTXO for cross-blockchain functionality. The CC framework allows for more than the basic type of vout. There is more interoperable development in planning for the future - Komodo has these interoperable features in testing for next release of the custom consensus framework
Previous Tech Tuesdays mention:
- Gateways (for converting and locking funds for use downstream in payment channels or in stable coin implementations, Stellar (XLM) calls a similar mechanism an “anchor”)
- Channels (for instant blockchain payments in any configurable denomination, Lightning and Coil use similar mechanisms)
There is no mention of asset tokenization in any Tech Tuesday yet. In future weeks we will describe more of on-chain tokens and how they can be used for supply chain solutions (research details below) and an on-chain DEX - testing is complete.
The on-chain DEX differs from the atomic swap DEX but remains blockchain based by using the aforementioned Gateways CC module to lock the coins in a contract.
The CC framework is a very powerful UTXO enhancing model. The blockchain development cycle has been radically reduced in timeframe and theres extendability of consensus rules goes beyond the main types provided by bitcoin and it’s clones.
Supply Chain Blockchain Research
In August this year, some 10 weeks ago, the following research scenario for blockchain supply chain solutions was used. From initial submission, it took a core developer somewhat familiar with Komodo's custom consensus framework about 4 weeks to create the contract and consensus rules for general supply chain solutions by utilizing the <style="font-weight: 400;">Oracle CC module to provide off-chain data to on-chain services.
These general supply chain rules can be recreated on-chain by any operator or developer using the Oracle CC module.
Scenario
- Warehouse stocking many line items (assets) with an assumption all items are in stock. All times mentioned in days/blocks are arbitrarily described.
- Customer would like to purchase items and submits a request to purchase one line item. The purchase order (PO) provides 2 days (or 3000 blocks if easier) for Supplier to accept, reject or propose a modification to the order. If no response from Supplier - deemed to be accepted.
- Customer can cancel the PO anytime prior to the PO being deemed acceptable.
- Supplier agrees to deliver physical goods by a specific day/blockheight.
- Customer agrees to pay Supplier amount in PO, within number of blocks of delivery acceptance.
- Customer has 3 days to accept delivery as acceptable.
- Prices can be updated and are enforced 15 days after price update notice.
- Attachments for delivery, notices, price feeds and acceptance have not been included in the scenario. These can be linked by url or stored like a binary blob (although not efficient use of storage).
The terms of this Supply Chain Scenario can be summarized in a simple data structure as such, and much inspiration came from the HyperLedger project for a scenario:
{ "CCclass": "SimpleAgreementInOracle", "contractId": "xyz", "effectiveDate": "2018-08-09", "supplier": "jl777", "buyer": "mylo", "shortDescriptionOfTheProducts": "random items of joy and frustration", "noticeWindow": 2, "cancellationWindow": 2, "deliverables": "Random items", "deliveryWindow": 1, "inspectionWindow": 3, "priceUpdateWindow": 15, "account": "Rjl777tomylo5ha5xyzxyz", "termYears": 1 }
Throughout the course of the Supply Chain Scenario, the state of a 000contract000 moves from PurchaseOrder, Approved, Dispatched, Delivered, Paid or something similar.
So we need to use the Oracle CC module again to store our instance of a contract, and as the contract life cycle changes throughout these steps, update the progress on-chain through transactions (and don’t worry about fees, we can make fee-less transactions for dApps with the CC framework, too).
{ “CCclass”: “SimpleSupplyAgreement”, “contractId”: “xyz”, “purchaseId”: “123”, “orderState”: “purchaseOrder”, “orderDetails”: { "products": [ { “sku”: “777555”, "name": “an item of joy and frustration“, "quantity": 333, "unitPrice": 1 } ], "payment": [ { "amount": 0, "transactionId": “” } ], "deliveryLocation": “KMD warehouse“, "deliveryDate": "" }, "transactionId": "45df3d3eae24db0b29671e60173dbd5e48c1c44", "timestamp": "2018-08-22T22:22:22.222Z" }
As the order passes through the life-cycle, the details of the order are updated by off-chain processes. Fields like orderState will pass through the different stages of the dApp/ordering system, the amount will update when payment is processed and a transactionId for the payment are updated.
The final state of this supply chain scenario may look something like this:
{ “CCclass”: “SimpleSupplyAgreement”, “contractId”: “xyz”, “purchaseId”: “123”, “orderState”: “paid”, “orderDetails”: { "products": [ { “sku”: “777555”, "name": “an item of joy and frustration“, "quantity": 333, "unitPrice": 1 } ], "payment": [ { "amount": 333, "transactionId": “9604d3e712998cd3e712720fddbe” } ], "deliveryLocation": “KMD warehouse“, "deliveryDate": "2018-09-01T12:12:12.121Z" }, "transactionId": "00d3e71262168cf9604998c720fddbee814a96ccf", "timestamp": "2018-08-22T22:22:22.222Z" }
Each of these transaction's OP_RETURN field saves the data above. These pieces of data are signed and hashed like any other pieces of transaction data. If one character were to be modified, the whole consensus puzzle would fail. This is the integrity of on-chain data.
Sharing Block Rewards - New Possibilities
One of the members of our discord, @Calem in the channel for his project #zerozed wants to use a different block reward mechanism more closely modeled on the Diffusion of Innovations theory.
Although his goals are specific to mining and can be achieved by modifying the existing mining rewards algorithm, other incentivization techniques on the block reward could be developed and applied by sending all block rewards to a custom consensus module.
Once in a CC address, they can be paid out according to a new set of rules. Perhaps from off-chain data, like participation in certain events in time or some other type of distribution. In the case of a project running on mining, proof of stake and with pre-mine, or any combination of these configurable blockchain options, it provides another adaptable solution for incentivizing your audience.
Interested in GUI dApps development? Discord's #cc_gui channel will be where most of the work will take place in the coming weeks.
Thank you Komodo (& ecosystem) developers, what an exciting week!