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.
Digital Asset: Tokenization With Non-Fungible Tokens (NFTs)
In November 2018 Tech Tuesday #10 we introduced the development work around fungible tokens to use for an security token offering (STO). Komodo business development includes making valuable partnerships for the ecosystem to leverage for any project, and these developments include the ability to plug into KYC providers.
Today we show how easily it is to create a non-fungible token and introduce the fundamental principle of the non-fungible token. The tokenization system on Komodo is built using Komodo's custom consensus technology. In October’s Tech Tuesday #8 Custom Consensus framework main net and information can be read for full details.
For today’s quick explanation on what the difference between a fungible and non-fungible token is, comes down to one simple concept in the smart UTXO based system of Komodo's custom consensus framework.
Learn more about Non-Fungible Tokens here.
Learn more about Unspent Transaction Output (UTXO) here.
How to create fungible tokens and non-fungible tokens as an example use-case
Creating a digital asset of concert tickets, one could create 1,000 non-fungible tokens to represent the tokenization of seated tickets, one for each seat. Plus the fungible tokenization of a general admission (standing area) for a dance area of an additional 300 fungible tokens.
1000 seated tokenized concert tickets = 1 UTXO of 1 satoshi creates 1 tokenized seated ticket, this call to the tokencreate RPC call is looped and transaction broadcast. 300 dance area tokenized fungible tickets = 1 UTXO of 300 satoshi creates 300 tokenized dance area tickets, this call to the core is issued once.
Tony demonstrated this on a team chat for me with a simple TEST ticket on his test chain. The RPC calls tokencreate and tokeninfo are described at the developer docs - a non-fungible token has a supply of 1. Read the last section below about our dev portal project!
Pool Mining: Paying Time-Locked Block Rewards
Time locked block rewards in the Komodo ecosystem was introduced by the Verus Coin project in 2018. This incentivized early cryptocurrency mining (and security) for greater reward (384 halving once to 192 coins) compared to the current 24 coin block reward currently available. Many block rewards are still time-locked, but since the time-locked block rewards has stopped, mining pools now operate.
Learn about the Marmara project from Turkey aiming to provide a blockchain solution to a peer to peer credit system. Turkey’s $200 billion USD GDP has a culture of post-dated cheques.
Credit Loop? Click the image to go to information about the Marmara project.
Marmara will use time-locked coins. It also needs to provide this functionality in a way for a whole community to operate and secure its own assets. Blockchain security and communities have strong ties to mining pools. Marmara needed time-locked pool mining rewards and this has been realized by advisor to the project and komodo lead dev jl777.
“... it isn’t possible without the custom consensus framework.”
A sample of mining pools paying out 2 shares to a time-locked custom consensus module address indicates that miners no longer have to worry about a pool going out of business.
marmarapoolpayout 0.5 2 '[ ["024131032ed90941e714db8e6dd176fe5a86c9d873d279edecf005c06f773da686",1000], ["02ebc786cb83de8dc3922ab83c21f3f8a2f3216940c3bf9da43ce39e2a3a882c92",100] ]';
That takes half percent pool fee, scans coinbases starting from height 2 and distributes to the pubkeys with shares of 1000, and 100 & it generates a signed rawtx that spends all the eligible coinbase.
"firstheight": 2,"lastheight": 59,"total": 87,"totalpayout": 86.56706466999999,"totalshares": 1105.5,"poolfee": 0.43293533,"perc": 0.5001155250560722,"payouts": [{"024131032ed90941e714db8e6dd176fe5a86c9d873d279edecf005c06f773da686": 78.69733152000001},{"02ebc786cb83de8dc3922ab83c21f3f8a2f3216940c3bf9da43ce39e2a3a882c92": 7.86973315}]
So pools would need to use this for their payout, but they feed in pubkeys and shares. the end result is CC locked payments to each miner groups of 60 blocks all unlock at the same height, so they can be combined hourly (however many coinbases a pool mined)
The zCash community forums have been discussing time-locked rewards. They discuss various problems they need to overcome, time-locked block rewards for pool mining has been brought up. I don’t think they could create a solution in less than a week or a month, let alone this solution built on Komodo's custom consensus framework by jl777 in less than a day. (Incidentally, one keen researcher finds Verus mining concentration - however they also don’t realize they are looking at old data. Hope this doesn’t prove to be a costly error for their community - in Week 2 Tech Tuesday this year we covered Verus’ perfect fork away from secret FPGA miners).
The custom consensus framework gives so much power to the developer to create new blockchain solutions-- solutions required for the real world, like Marmara!
Coin Migrations: Blockchain to Blockchain Transaction Visibility
The #kmdlabs channel has been working towards a scalability test of chain migrations and one popular request during the initial AWS scalability work was to be able to make things visible - charts, graphs or a meter.
For chain migrations, the user will have coins in their wallet on one chain and then after migration the balance will be available in another chain.
For joe-public, there will be explorers to see the transactions in a block and a link to the exported transaction from the originating chain.
Chain with exported transaction shown
Imported coins shown on the block explorer with a link to the exported transaction on the export blockchain.
A very detailed walkthrough of the process for devops and scaling blockchain engineers is available through one of our Komodo dApp developer's blog with article on blockchain coin migrations.
Bug Hunting: Running komodod for blockchain debugging
Install gdb then start the daemon with
gdb --args ./komodod -ac_name=... ... ...
Then type run into the gdb terminal.
Wait for it to crash then type backtrace into the terminal
Post that output to a pastebin and link to it for other developers to look at or do your own debugging!
Always better to use a compiled from source komodod to be more effective in your bug hunting!
Agama Wallet: Electrum Protocol Update Development Begins
Komodo's engineering team have begun a new branch of development to support the updates
From the community: Bring more developers, hackathons and high quality documentation for devs
Komodo formed an internal team to tackle the problem of not enough documentation. We successfully created two cross functional teams (CFT) to tackle other problems we identified internally, one resulted in more clarity on what dPoW was for the blockchain industry. On internal success, it led to the formation of the CFT-Dev-Resources team, including some marketing, business development, developers from the core team, dapp developers and the marketmaker v2 team.
Some months into 2018 it became clear we needed better docs. Team member gcharang took the lead and compiled the best docs the project had ever had. We immediately had what I refer to “handbooks” in my notes - the Komodo docs site. Contributions from the team continue to be added and the updates are viewable on the github repo which is tracked in the discord channel #feed-github.
In Tech Tuesday #11 we explained why we chose the VuePress framework for our developer docs. The result was a comprehensive look at some of the newer custom consensus tech of Komodo, to have it published and realize what workflow existed and most importantly if there were any early blockers to our goals.
Fast forward to the current week, the current draft framework and mobile friendly dark template has 5 categories. These 5 categories separate 14 sections, which are composed of 100+ feature documents in various stages of draft. This does not even include marketmaker v2 because of the heavy development cycle it is currently in (an update was provided in Week 2 2019 Tech Tuesday).
Developer portal empty dashboard with expanded menus to navigate to specific sections. Getting Started section "Blockchain" expanded and partial view of the dApps & Custom Consensus framework sections in dev docs.
As an example of one category, Getting Started, a section called People aims to help the following learn about how they can use Komodo’s technology to create their vision or aid in making a smooth & successful collaborative project integrating blockchain tech:
- Introduction
- Network Engineers
- Devops Engineers
- Backend Developers
- Frontend Developers
- Game Developers
- Coin Developers
- Marketers
- Economists
- Sociologists
- Psychologists
This is not a final list of people we want to help navigate the Komodo technology offering. At initial launch some may be omitted due to time constraints and lack of access to people with expertise in these disciplines but we’ll be continually looking for making contact with people possessing expertise in these knowledge domains.
Tech Tuesday has been my way of keeping “live” notes of what happens week to week. It wasn’t my idea to do it - but I’m very grateful - thank the marketing team for this idea and the weekly output. It’s definitely helping keep track of what can help people develop on Komodo. As a team, we’re just doing it first!
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!