Facebook Crypto Acquisition – Technology Comparison Exciting news with Facebook acquiring the chainspace research project. 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 outputs new output objects. The inputs are marked as inactive. This sounds a lot like the UTXO modelso far, where UTXOs become spent when they are no longer available for spending. Komodo's Crypto Conditions (guide) (and Tech Tuesday #7) 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 lifecycle. Crypto Conditions allows a blockchain developer to do something a web developer can do with a URL request – routing. Validation routing – to make custom objects. That interact with contracts. Crypto Conditions 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 securing weaker blockchains called 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 contracts on all nodes in a chain (or multi-chain cluster) validate the inputs and outputs. Every full node validates the transactions and contract 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 by dPoW to receive bitcoin-level security. This technology is available to anyone to develop on and is available now. There is no need to wait for a company like Facebook to introduce these concepts to the world. Komodo has worked on them since the declaration of 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 they refer to as a sequence. So, if you have valid sequence of traces – you are essentially saying, the UTXO is valid from it's creation – likely some block reward or premine, plus all the transactions that led to it being valid and spendable UTXO. This is all atomic. 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 – Crypto Conditions tokenization system, oracles, gateways to other coins, instant payment channel secured by bitcoin hashrate, dice, sudoku etc. All of it is atomic utilising the space in op_return to serialize and deserialize objects. This is the power of Crypto Conditions – being able to serialize and deserialize objects into blockchain form.
Smart Contract Composability
Crypto Conditions are composable. Chainspace defines composability of smart contracts as "It allows the creation of a library of smart contracts that act as utilities for other higher-level contracts:" on page 4. 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 Crypto Conditions testers @TonyL explained how to use tokens on a gateway to create a stablecoin style workflow. These are examples of using Komodo's composable reference crypto conditions 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 Komodos 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, whereas a full audit requires a MoMoM lookup and full validation for the transaction in the MoMoM lookup on the shard. It is at this time my eyes are starting to blur, compounded by the need to have this post ready in time for publishing. 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." I hope the reader is not too harsh on my overview – it is a Tech Tuesday update for the week of tech, not a final word comparison. 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 on – with our help 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 a transaction. How will this work in a multi-chain, multi-organisation deployment? Atomic swaps. Part of a smart contract (crypto condition) 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 contract 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 crypto condition 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 recognised 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 opreturn 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. Crypto Conditions: Basic Validation Routing For Developers Considering The basics of UTXO based contracts can be understood as follows: - Tx needs validation
- Type of validation is a CC vout*
- 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 Crypto Conditions development are here in the source of eval.h.
A workflow for developers suggested from jl777: The validation code for cclib (the dynamic crypto conditions 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 arent 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 crypto conditions.
Updating Crypto Conditions – Blockchain Validation Routing – A Simple Solution For Beta Testing New Features 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 the 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-........"] 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 Crypto Conditions 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… | 
