Skip links

Tech Tuesday Update #7: A Summary Of Last Week’s Development

This series of posts is called the Tech Tuesday Updates. Along with AMA Mondays on Komodo’s subreddit and the Five Bullet Fridays weekly newsletter, Tech Tuesday Updates will be another weekly piece of content to look forward to.

Smart Contracts and the UTXO Model

There is a lot of literature online about how the UTXO model is not suitable for smart contracts.  This literature is outdated with the advent of Crypto Conditions UTXOs.

Ten Commandments = Standard Consensus Rules

Modern Legal Framework = Crypto Conditions

Crypto Conditions is a format for expressing contract 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 organisations to have independent and multiple blockchains to suit their needs.   These independent blockchains can implement contracts 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 these Crypto Conditions.

Crypto Conditions UTXO – a new vout

There are 3 main types of vout in a bitcoin blockchain that cover 95+% of usage:

  • p2pk (pay to pubkey)
  • p2pkh (pay to pubkey hash)
  • p2sh (pay to script hash)

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 crypto conditions, and then which crypto condition 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 Crypto Conditions 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 – the basic UTXO that has been enhanced with Crypto Conditions by Komodo (originally proposed by Ripple and Interledger Protocol (ILP) and now with the IEEE for an open industry standard) for cross blockchain functionality, also 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 with Crypto Conditions UTXO Smart Contracts and Custom Consensus.

Previous Tech Tuesdays mention:

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 Crypto Conditions to lock the coins in a smart contract.

Crypto Conditions 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 Crypto Conditions about 4 weeks to create the contract and consensus rules for general supply chain solutions by utilising the Oracle Crypto Condition 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 Crypto Condition.

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 summarised 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 Crypto Condition 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 crypto conditions 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 modelled 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 crypto conditions contract.

Once in a crypto condition 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!

 

To get more updates from Komodo, sign up for our weekly Five Bullet Fridays newsletter and join our active community on Discord.

Join us as we continue to develop and lead the blockchain industry into the future.