Tech Tuesday Development Update - 2019 Week 6: Facebook Crypto Acquisition Comparison & ERC20 Migrations

Komodo Team -

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.

Facebook crypto acquisition - technology comparison

Exciting news about Facebook acquiring the chainspace research project broke this past week. In a couple of hours of reading, I’ve tried to break down some of the technologies in a quick overview and illustrate how advanced Komodo technology is with respect to one of the biggest technology companies acquisitions in the peer to peer field - all page references are to the chainspace whitepaper accessed earlier today.

Sharded Smart Contract Platform

The chainspace solution offers a data model of objects, contracts and transactions (page 2, Section II A). The objects can be in either mutable or immutable state. Each object is cryptographically unique. The contracts are a special type of object that allows procedures to manipulate objects of types specified by the contracts to produce outputs.

So far, nothing particularly different to Komodo.

Each chainspace contract has a checker that takes inputs and checks it. In Komodo and most other blockchains - it is called validation. Each node can validate each transaction/procedure in a deterministic (repeatable) way.

Once a transaction consumes these contract input objects, the contract produces new output objects. The inputs are marked as inactive. This sounds a lot like the UTXO model so far, where UTXOs become spent when they are no longer available for spending.

Komodo’s Custom Consensus framework introduced a new vout, transaction output. Bitcoin introduced pay to public key, pay to public key hash, pay to script hash and some rarer payment types. The CC-vout is a serialized object. Same as chainspace description. Each CC-vout used for input, that has procedures/logic worked on it to becomes “inactive” when it too has an output from the resulting procedures. This output is then the “active” UTXO for this chain of events - from object creation to contract procedures worked on it and back to the chain. Each step in the state becomes inactive, when there is an updated state in its life cycle.

The custom consensus framework allows a blockchain developer to do something a web developer can do with a URL request: routing. More specifically, validation routing to make custom objects that interact with the individual CC modules. The custom consensus framework is an open standard encoding format for representing objects in a multi-chain and algorithm-agnostic way. Komodo basically serializes the objects into the op_return data field, and this field is referenced for validation and lookups with standard UTXO validation.

Smart Contract Security

The chainspace solution offers a novel method of checkpointing from any shard to a chain specifically designed for receiving Merkle roots. Chainspace calls this a “hash chain” (page 3, Section II B).

Komodo has a checkpointing system used for improving the security of blockchains with small networks called delayed proof of work (dPoW), plus the cross-chain abilities of chainspace are available in Komodo through MoMoM technology. This cross-chain capability is used in chain migrations (TT Week 3 blockchain to blockchain tx visibility), which are fundamental to scaling clusters of chains (like chainspace's shards) for real-world use.

Transparency, integrity, and encapsulation of contracts is done on Komodo by having compiled sources of Custom Consensus modules on all nodes in a chain (or multi-chain cluster) validate the inputs and outputs. Every full node validates the transactions and CC logic.

When combined with MoMoM data, other chains or multi-chain clusters can act on a different subset of data. An independent “shard”, because there are references to objects and transactions that act on these objects. The history is available cross-chain, cross-shard or inter-shard.

Further, Komodo chains that are designed to work with one another in this MoMoM cross-chain lookup/verification are secured with dPoW through Komodo's Blockchain Security Service.

This technology is available now for anyone to develop on. There is no need to wait for a company like Facebook to introduce these concepts to the world. Komodo has worked on them since James 'jl777' Lee's declaration of blockchain independence.

Application Interface

In part III of the chainspace whitepaper, "traces" represent what is known in the blockchain world as validation-- a long history of validation that checks the current UTXO set and where they are derived from. This is to make sure the history is correct/valid. The long history is what chainspace refers to as a sequence. So, if you have a valid sequence of traces, you are essentially saying that the UTXO is valid from it’s creation. This likely includes some block rewards or premine, plus all the transactions that led to it being a valid and spendable UTXO.

Working on UTXOs in this manner is what is called atomic. Chainspace calls it atomic, blockchain world calls it atomic. Komodo works atomically for independence from a dominant main chain. Custom consensus modules such as a tokenization system, oracles, gateways to other coins, instant payment channel secured by bitcoin hashrate, dice, sudoku, etc, all of it is atomic utilizing the space in op_return to serialize and deserialize objects. This is the power of the custom consensus framework-- being able to serialize and deserialize objects into blockchain form.

Smart Contract Composability

Custom consensus modules are composable. Chainspace defines composability of smart contracts as something that "allows the creation of a library of smart contracts that act as utilities for other higher-level contracts."

In TT#3 last September we introduced tokens used with gateways. This is a tokenized version of another coin, with UTXO level locking by another object with the spendable pubkey. In TT#4 one of our custom consensus framework testers @TonyL explained how to use tokens on a gateway to create a stablecoin style workflow.

These are examples of using Komodo's custom consensus framework to make blockchain business workflows. They are open source and ready for extending on.

"Reads" in chainspace refer to reading data from other contracts. Let’s take a look at TT#2 for a bitcoin oracle pricefeed dApp. This sample dApp in has been used for more than just bitcoin pricefeeds. It was a test tool for cross-chain contract testing! MoMoM tech for cross-chain proofs reads notarization data. Any chain protected by Komodo dPoW blockchain security reads notarization data in their standard validation, performed by all nodes.

System Design

The Facebook acquisition uses a modified DAG structure. So far, these DAG structures have not been proven to work as well as a blockchain. The security model of chainspace follows that of Komodo's checkpoint-style dPoW notarization with their Node-Hash Chains in part IV on page 5.

A partial audit is very like a cross-chain MoMoM lookup, where as a full audit requires a MoMoM lookup and full validation for the transaction in the MoMoM lookup on the shard.

I’ve glossed over part V Security of their paper on page 8 because part VIII Limitations on page 13, says “The integrity properties of Chainspace rely on all shards managing objects being honest... In case one or more shards are malicious, we provide an auditing mechanism for honest nodes in honest shards to detect the inconsistency and to trace the malicious shard.”

The limitations section is a nice way to say “we have demonstrated a lot, and it’s not a final product," very much like Komodo’s dev/FSM branches of tech that are not yet in the master branch, but are still available for projects to start using, testing, and improving upon, with the help of the Komodo team in a collaborative way.

System Applications and Smart Contracts

On page 10 & 11 of the whitepaper, some sample applications are described. The transaction costs of running smart contracts using a central currency called CSCoin. On Komodo, each blockchain can use it’s own currency - no need to use a central KMD currency. If you create a blockchain (shard) called “BILL”, then your transaction costs are in the native coin, “BILL." Make a “MYLO” chain, the native coin “MYLO” is used for transaction.

How will this work in a multi-chain, multi-organization deployment? Atomic swaps. Part of a custom consensus module can be to check on the balance of the calling wallet address. If it is low in a currency, it can initiate a request to a faucet on behalf of the low balance wallet.

Smart meter private billing as a dApp - this is like an out-of-the-box reference module from Komodo - we’ve chosen tokenization, oracles and gateways - chainspace a smart-meter billing. From the time-locked pool mining solution from TT-Week2 this year, an oracle feeding data to a custom consensus module can be used in a similar way to provide billing templates. Within one week, a competent C++ dev can create this type of solution.

A platform for decision making and voting - this is the work of the Verus project with their PBaaS (public blockchain as a service) statement from their vision paper. For more information please contact Mike Toutonghi at Verus about this service. Mike’s CV is one of the most impressive in tech having designed Microsoft’s dot net platform and is recognized as a distinguished engineer. Following that, he then was CTO at the parallels virtualization platform. Mike chose Komodo because of the independent scale out architecture that was available to build on, plus being able to codify objects into serializable op_return blockchain data. We are so proud to have Mike as an advisor to Komodo and reciprocate major code updates.

We hope anyone or any group that has read through my quick overview is excited about what Komodo offers in comparison. The technology of this acquisition made by a company with an order of magnitude or more of resources to build on is already available and can be used to build interplanetary scale peer-to-peer applications.

ERC20 Migration: Fintech & banking - crypto credit union with a stablecoin

The first migration from ERC20 to Komodo is underway from the O Crypto Union project with assistance from the Indenodes Notary Node operator team. They have launched on Komodo because of the solutions offered by the project.

Already, the crypto union has issued the Komodo Secured Bond (KSB, a stable coin) and are currently doing a swap from ERC20 to their own blockchain OUR.

In previous Tech Tuesdays we had an implementation of Eth in the haskell programming language notarizing to KMD. This paved the way for early research into an automated solution, should demand for ERC20 to a Komodo blockchain solution increase.

Custom Consensus Framework: Basic validation routing for developers considering

The basics of Komodo's Custom Consensus framework can be understood as follows:

  1. Tx needs validation
  2. Type of validation is a CC vout*
  3. Look up which CC by its EVAL code

*The CC vout is a new type of vout compared to the ones offered by bitcoin.

The existing EVAL codes from the early iterations of Komodo custom consensus development are here in the source of eval.h.

A workflow for developers suggested from jl777:

The validation code for cclib (the dynamic custom consensus library/module loader) allows for very convenient chain/height specific exemptions. so to develop a CC, first make the rpc that implements what can be done, without any validation. Then you can add validation to make sure things are not supposed to happen, are not happening. Early versions often have initial edge cases that were missed and so adding a specific exemption for them allows to have full enforcement of rules, subject to the early exemptions

By going from a chain without validation, to weak validation to full validation, the advantage is that nodes running older versions keep running, so as long as they aren't mining it allows to update the field incrementally with versions that have more and more validations.

With these hints, Tech Tuesday tutorials are forthcoming. For those that cannot wait, please read jl777's chapter 4 on getting an RPC interface up and running and read CCcustom.cpp comments for creating new or extending custom consensus modules.

Updating Custom Consensus Framework: blockchain validation routing

In recent weeks, the tokenization internals has been updated. With new developments, new bugs are introduced at an early phase and caught. For projects that have made use of the bleeding-edge of new features available, Komodo core developers can create simple validation routes for older/stale data.

This is not a new concept, but one that dApp developers and ecosystem developers should be aware of if they want to introduce new features to their dApps.

When projects use dynamic loading CClib and manage their own validation, this is a technique that can be used for smooth transition of custom consensus upgrades - like higher level dApp protocol scenarios. https://github.com/jl777/komodo/pull/1229 shows some src code for doing such updates.

Deadline Feb 15 for sapling activation aka move private address funds to a transparent

One of the changes to consensus rules on Feb 15 is the removal of z transactions. Without digging too deeply into the consensus rules, we just want to point out the komodo_defs.h file which is only informational for the majority of people. However for a core dev, this is a handy place to put system wide constants.

  • What is the maximum length for the name of an assetchain?
  • How long are transactions stored in the mempool on komodo?

These questions can be answered in komodo_defs.h

To move funds from private to transparent, use Agama after importing your sapling (or sprout) key.

From command line,

Get balance of z_address

(sprout) komodo-cli z_getbalance "zc……….” (sapling) komodo-cli z_getbalance “zs……”

Send from z to t address

komodo-cli z_sendmany "z….…….” '[{"address": "R….”, “amount”: 20}]’

Get status of transaction

komodo-cli z_getoperationstatus ["opid-........”]

The private funds will resume when KMD becomes a real world multi-chain example of the technology we build, led by jl777.

Crypto Games: Sudoku

This game started off as a test for the dynamically loadable CC libs. The collaboration between jl777 and our tester TonyL (who has been learning python recently) with a GUI. Like most opportunities with prizes involved, we’ve seen an unbelievable number of world record breaking attempts at Sudoku solutions!! These creative opportunists are helping make Komodo p2p games more fair.

To start the sudoku chain you need to be on the bleeding edge of custom consensus technology - don’t cut yourself on the FSM branch from jl777 repo

git clone https://github.com/jl777/komodo
cd  komodo
git checkout FSM
./zcutil/build.sh -j$(nproc)
./src/komodod -ac_name=SUDOKU -ac_supply=1000000 -pubkey=<yourpubkeyhere> -addnode=5.9.102.210 -gen -genproclimit=1 -ac_cclib=sudoku -ac_perc=10000000 -ac_reward=100000000 -ac_cc=60000 -ac_script=2ea22c80203d1579313abe7d8ea85f48c65ea66fc512c878c0d0e6f6d54036669de940febf8103120c008203000401cc &

Then for a GUI, follow these instructions https://github.com/tonymorony/Komodoku

Go to discord #cc-sudoku for more community goodness…

Note: The KMDLABS discord channel (#kmdlabs) is dedicated to testing innovations, upgrades, new features and is a great way to get the necessary skills and knowledge for being a competent Notary Node operator.

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.