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.
In case you’ve missed a previous edition and want to catch up, you can find all the previous Tech Tuesday updates here.
Without further ado, here are the past week’s tech highlights!
Private transaction mining pool opens and OTC trades
Last Tuesday we mentioned the zk-SNARK only blockchain – PIRATE which enforces only private transactions on the network. The hashrate for this blockchain has steadily increased as solo miners jumped on following the bitcoin talk thread announcement and general community involvement.
CPU/GPU miners are outclassed by the ASICs that provide efficient mining that are now joining the network. The Komodo Notary Network operator webworker has spent the good part of two weeks testing, with the Komodo community in discord #pirate channel, various methods for mining to a pool and published a getting started guide for mining on the first PIRATE mining pool.
The community is also in early testing for dPoW notarizations of PIRATE to again recycle bitcoin’s hash rate for securing blockchain innovations against 51% attacks. The impressive part is that these blockchain rules are new this week – thus, Komodo’s innovative marketmaker software from BarterDEX (the pioneering atomic swap powered DEX), will be put to work by the notary network to split funds for notarizations in the near future for the first time on a private transactions only blockchain.
Where a private transaction enforced blockchain like PIRATE goes from here will follow the path of many other blockchain project’s that adopt Komodo technology. PIRATE will inherit many of the other innovations of the Komodo ecosystem. PIRATE’s unique enforcement of privacy does limit it’s availability to trade in a decentralized exchange – atomic swaps are not possible. It will also not inherit the smart contract capabilities until homomorphic encryption has been created within the ecosystem.
OTC trading is happening and as hashrate/difficulty goes up, so does the price. 1 PIRATE bid / ask is about 0.02 – 0.025 KMD. Pretty cheap for an XMR equivalent if you were to ask me on a Tuesday.
Bounty to port solidity to Komodo
Last week we introduced the possibility of a developer being able to make their own custom consensus through Komodo’s Crypto Conditions implementation. This news excited a long time community member who then posted a bounty for a solidity interpreter to be integrated into Crypto Conditions.
There are already questions around the internet asking if solidity can be ported to EOS. The similarity between requests is that EOS contracts are written in C++ which is the same as Komodo’s first language to support UTXO-based Smart Contracts (and extending consensus through custom rules). The most popular response for the EOS platform is to use a porting tool from solidity to C++.
Whether this is the best way for a Komodo solidity port is questionable because Komodo offers developers a flexible framework for extending consensus. Instead of forcing a developer to use the platform’s language, an alternative to solidity transpiling looks achievable.
The first respondent to the bounty appeared in Komodo discord #crypto-conditions channel (join with a link in the footer of the Komodo Platform website) and after a brief introduction asked how it could possibly be done:
“I think for a solidity one, it would create a contract by posting the script in an opreturn with a soliditycreate rpc call then it can be invoked via its txid”
So it looks like if we can compile solidity to it’s byte code and have an interpreter run it to do all the “smart” stuff with the inputs and outputs, we can store the compiled byte code in an OP_RETURN (Komodo’s maximum size OP_RETURN is 8kB, many bitcoin protocol blockchains have a 40 byte size limit).
This further shows the power of Crypto Conditions and UTXO Based Smart Contracts by allowing a custom consensus to be created – in this case a transaction used to trigger some logic in an external contract language. In the case for solidity, the interpreter needs to handle the primitives used in solidity which Komodo does not handle natively.
Komodo’s robust architecture can be leveraged by any ecosystem blockchain. If and when a developer claims the bounty of porting solidity to Komodo’s Crypto Conditions implementation, every project within the ecosystem can benefit. Each ecosystem blockchain can independently update on their own schedule to optionally adopt any new developments and technology as they become available.
Tokens, Gateways, Oracles and a rhetorical question
Rebuilding smart contracts under heavy development is part of the compilation, especially the development of the first reference contract that is linked to another contract, from a testers point of view, is like breathing. Doesn’t have to be done for 5 minutes but may not be testing the most up to date code. “Do I need to rebuild now” became the rhetorical question of the week. We all enjoy compiling code and making it do new stuff within the Komodo ecosystem.
If you drop into the testers channel and want to test what an oracle feed does to expedite our testers workflow:
build when you are in src gcc cc/dapps/oraclefeed.c -lm
Whether “Oracle Feed” dApp becomes useful in the real world as it is or whether it provides some learning resource, it is certainly useful in the developer/tester workflow. Last week Oracle Feed was mentioned because jl777 used it for testing other things that are not BTC price feeds.
What is a Gateway smart contract?
The basic idea is to tokenize other crypto coins (like BTC) and then use the assets crypto conditions contract (or assets trading infrastructure provided by the assets reference contract) to transact/swap against the tokenized crypto. Enforcing, by blockchain enforcement, a 1:1 peg between a specific token and BTC (or any other peg) as well as an automated deposit/withdraw mechanism – it is possible to trade virtual BTC without any delay or expensive tx fees. Redeeming the token will unlock the BTC used to create the token. All blockchain enforced – across blockchains where necessary. Redeeming implies a lock between two different transaction types – the asset-token and the gateway.
When will this be ready?
Active testing is already underway. The testing process has been expedited by this “Oracle Feed” dApp mentioned in week #2 so the turnaround time in testing new development is expedited.
Business use for this blockchain technology?
Komodo’s architecture allows anyone to create a blockchain and remain independent, and build this gateway, token and oracle functionality out-of-the-box. There is no barrier to creating your own trading platform – be it crypto-currency, security tokens or other secured assets, trading cards and game assets – all with the security of bitcoin’s enormous mining infrastructure via Komodo dPoW.
Business case how to:
- Create your blockchain using Komodo’s Assetchain
- Create tokens for on-chain representation of real world assets
- Convert tokens to gateway enforcement (so they can be redeemed when “cashed out”)
- Create an oracle (used to maintain the price feed of the real world asset onto the blockchain)
- Bind the token and gateway to the oracle so prices reflect accurate data on-chain when fed updates
- Use the sample “Oracle Feed” dApp to feed the accurate pricing from the real world to on-chain data
- Use the gateway to redeem (cashout) the token value when customer requests
Software & Platform Architecture for Designers in the Infographic Contest
There are two main competing architectures in blockchain (and many other) technology industries.
This kind of architecture is NOT how Komodo has been designed. This kind of architecture is also known as Enterprise Architecture or if an image search doesn’t clear things up – try looking at traditional tiered architecture. This is like how other blockchain platforms have been designed unfortunately and they suffer from scaling problems.
This is the most compatible way to view Komodo and its ability to offer an ecosystem to create ecosystems and platforms with it, not on it. Independence is the key for project stakeholders and this is what the spirit of Komodo is about. Other names for scale out might be multi-chain syncing architecture or the comparison of hadoop vs rdbms architecture (rdbms = relational database management system. E.g. database. Hadoop is a database).
Image searching “scale up vs scale out” and you will find the comparison of umbrellas/pyramids/top-down representation and then the foundational style to build on. The foundational style is Komodo.
Independence to build with adaptability in mind
Adaptability in mind = a free mind. The architecture mentioned above is one aspect of Komodo that is appealing but the configurations available to a project adopting this technology is mind blowing. Not mind numbing – there are not hundreds of options, but using only 5,6 or 7 options in different combinations can give very flexible solutions.
To put it in perspective, take a look at your colour palette – using RGB values, as a designer you can create millions of colours by tweaking those 3 colour ranges. CMYK, same but on a different medium.
This adaptability is required on a blockchain ecosystem because there is no one-size-fits-all design. This reflects the values of different cultures, industries and incentives of the people in our world that we hope our technology can reach.
Some solutions require scarcity which are produced by halvening periods, where the reward for mining/minting a block are halved each time period. Others require energy efficient and controllable consensus (PoS proof of stake vs PoW proof of work). Yet others are for enforcing a fee to be paid to a central address on each transaction (like a tax). These are examples of blockchain options on the Komodo Platform like your RGB colour ranges. They are not just switches, they are also ranges.
Most Secure Private Blockchain – 51% attack resistance
Since the first draft of this article was written, only the mining pool and some wallet integration was complete on the PIRATE blockchain. What happens when a team of developers work on a concept with determination? The PIRATE project gets bitcoin level security by implementing Komodo’s dPoW security service.
Oh, and they integrated tor settings. So if your project needs tor settings – it can be done with Komodo.
Thank you Komodo developers, what an exciting week!
Join us as we continue to develop and lead the blockchain industry into the future.