Subject: [ANN][labs][dPoW][cc][Incentivized Testing] KMDLabs - Scalable and Customizable Development Laboratory for Komodo based Blockchains
Welcome to the official bitcointalk.org topic of the KMDLabs project!
We are happy to announce that after around 8 months <!---FIXME 9? ---> of relentless and constant development, the project is ready to go live on <!---FIXME insert date here --->.


Introduction
KMDLabs is a fully scalable and customizable test bed for testing and developing your Komodo (KMD) based assetchains and Crypto-Conditions based contracts (hereby refered to as CC). We provide an incentivized test network/environment, technical services and a support knowledge base. KMDLabs’ ease of use and rapid deployment features allow projects of any technical level or size, a place to experiment with the depth of Komodo and Crypto-Conditions technology. Testing is conducted on the KMDLabs fungible cluster. Additional fungible and non-fungible chains and clusters can be added as needed for more customized or private development. It is possible for these chains to be notarized to the Bitcoin blockchain through the main Komodo (KMD) chain using Komodo’s Delayed Proof of Work (dPoW).
We are looking to extend our community to the broader crypto ecosystem and create a space where anyone can learn, test and launch independent, secure and smart blockchain projects that support utxo based contracts. Click here to join the revolution.


Highlights

Free
Testing on the KMDLabs cluster is free. To add your own chain(s), only notarization fees are required. These fees decided by the notaries and are very reasonable.

Testing Crypto-Conditions based contracts
KMDLabs provides thorough contract testing services for those developing with Crypto-Conditions. Testing plans catering to your specific project's needs can be implemented.

Incentivized Testing
In addition to offering a testing platform, KMDLabs also incentivizes testers and developers to participate in projects.
Opportunities are readily available for those interested in gaining knowledge and practical experience in this fast developing field. Anyone who can contribute is welcome. Developers will certainly find worthy challenges to overcome. Relative newcomers will have ample opportunity to break things. Bounties in KMDLabs are paid for breaking test chains, finding bugs and also for finding solutions.

KMDLabs Main Cluster
KMDLabs (LABS) is the main blockchain in a cluster of fungible Komodo assetchains that provide incentivized testing, debugging and development of Komodo Platform’s Crypto-Conditions contracts and the underlying software. The value of one coin in the cluster is equal to that of any other (1 KMDLabs(LABS)), regardless of what chain it exists on. Therefore a coin mined or staked on XCHAIN is evenly exchangeable for 1 KMDLabs(LABS) and vice versa. Komodo’s MoMoM technology allows the transfer of assets (coins) across multiple blockchains without inflating the supply.
The total coin supply is balanced across the cluster. Adding a new chain to the cluster requires the provable burning of an amount of KMDLabs(LABS) equal to the amount of coins added. Chains other than KMDLabs(LABS) will have a 0 block reward for the time being (-ac_end=1). There is a consensus rule in the KMDLabs' komodod that restricts any chain launched in the main cluster to not have any block reward past block 1, no matter what params are used. Please contact us on Discord to find the correct method to do this.

Auto deployment of chains and setup of Notary Nodes

Through the creation of a set of bash + python scripts deploying new chains is as easy as writing a json and running a script. Details: https://github.com/KMDLabs/staked

The notary nodes that secure the KMDLabs cluster can also be run using a "set and forget till the next update" script too. Details: https://github.com/KMDLabs/StakedNotary



Tier 2 Notary Node Network
A unique and key feature of KMDLabs is that it has its own notary node network, seperate from the main Komodo (KMD) notary network. In addition to ensuring dPoW for assetchains as KMD notaries do, the KMDLabs’ notaries also enable the MoMoM based crosschain migration and Multichain scaling mechanisms. The notarization process is a necessity for MoMoM based cross-chain imports, particularly between low hash rate chains as it ensures that the export transactions can’t be reversed by a chain reorganization. This MoMoM notarization prevents the creation of coins “out of thin air”.
The majority of test chains in the KMDLabs cluster are powered by PoS combined with CPU PoW hashrate the chain creator is able to provide. Apart from transaction fees, they have a zero block reward. Consequently, they need to make use of dPoW to secure themselves against double spends. The PoS component of the chains prevents them from stalling due to a hash attack. The PoW component of the chains will move the chain forward and allow the transfer of staking funds back into the chain in a case where all staking coins are (accidentally) removed. There are mechanisims in place that allow a chain to move along (although very slowly) with even very small staking weights.


A Brief History
When the initial chain of KMDLabs was launched <!---FIXME insert date here --->, 4000 coins were pre-mined. Of these, 2100 coins were distributed to 21 participants. The difference was sent to an on-chain faucet contract along with all coins mined up until the chain parameters were made public. The goal of the project then was to simply launch new chains, test new asset chain parameters, the CC that were developed to that point and reward the testers with these coins in a weekly cycle. Each week a new chain with diffrent parameters and CC was launched with the previous chains' balances airdropped. Total weekly emissions were capped at 100k coins. That doesn't mean the maximum emission was reached every week, unclaimed bug bounties were burned at the end of the week. If someone managed to break a chain or find a bug in a contract, they received extra coins from the pre-mine of the next week's chain. The initial 4 weeks of high intesnity testing proved the value of and need for an incentivized testing platform. From week 5 onwards, the focus shifted to setting up the KMDLabs platform for development and testing on the Main Cluster. Information on various chains launched, the CC tested and bounties awarded can be found in the legacy site: https://staked.CC/
The final parameters used for the KMDLabs (LABS) chain have been reached after many iterations of testing since the week 4 snapshot. During this time many new features have been developed specifically for the LABS chain making it quite unique. As week 4 of the incentivized testing phase was the final testing period in which bounties were paid, that is the snapshot to be airdropped to the final version of the LABS chain. By the end of the 4 week period, the total number of coins mined/staked and bug bounties paid added up to: <!---FIXME insert airdrop supply here--->. The snapshot can be explored here: <!---FIXME snapshot link --->

Participants
KMDLabs finds its origins in the testing conducted on the PoS64 staking algorithm created by jl777 for staking on KMD assetchains.
This algorithm was tested and improved by jl777 and the members of this PoS64 test group. From these experiments the need for a state of the art, dedicated testing platform became very clear.
Testing expanded its scope and STAKED was born. STAKED furthered its experience with incentivized testing while developing and refining the STAKED software over various cluster networks through its seven iterations.

Who?
A group of core contributors are joined by members of the Komodo community at large.
Some of the more well-known participants include:

blackjok3r
Alright
smk762
CrisF
jorian
gcharang
zatJUM
SHossain
CHMEX
TonyL
CMaurice
gt
metaphilibert
ComputerGenie
Nabob
daemonfox
webworker01
Bar_F1sh_Rel (Scottrock)
mylo5ha5
dimxy

Advisor – jl777


Details

Official Website
https://kmdlabs.io/

KMDLabs coin details

Coin Name: KMDLabs
Ticker: LABS
Blocktime: <!---FIXME --->
Total Supply: <!---FIXME --->
Platform: Komodo


Explorer


Github

Home: https://github.com/KMDLabs/

KMDLabs' version of Komodo: https://github.com/KMDLabs/komodo

Notary Repository: https://github.com/KMDLabs/StakedNotary

Easy launch and update for chains in the cluster: https://github.com/KMDLabs/staked



Contact

email: KMDLabs@protonmail.com

Discord: https://discord.gg/tDKq5Mb




Instructions to launch the chain

Compile the KMDLabs' fork of the Komodo daemon (komodod) from the repository: https://github.com/KMDLabs/komodo

Instructions: https://github.com/KMDLabs/komodo#build-komodo

Navigate to the src directory in the cloned komodo repository
Launch command:

./komodod -ac_name=LABSRCTEST -ac_supply=350689 -ac_staked=51 -ac_eras=3 -ac_reward=0,0,800000000 -ac_decay=0,100000000,100000000 -ac_end=128,10080,0 -ac_notarypay=64,100000000,1000000000 -ac_halving=129,1 -ac_sapling=1 -ac_cc=102 -ac_ccenable=226,236 -addnode=195.201.20.230 -addnode=195.201.137.5 -addnode=103.6.12.112
Descriptions of the launch parameters can be found at the Komodo Platform's Documentation site


KMDLabs' Notary Nodes

Current state
The original 20 notary nodes were selected through a ‘trial-by-fire’ conducted on one of the final testnets (CFEK/LABS) leading up to KMDLabs. The notary candidates were required to set up their node and be in the first 20 to notarize a test chain.

Compensation
KMDLabs developed a pay-per-notarization (-ac_notarypay=) system where a special coinbase is created for any block that contains a notarization. This means that notary nodes are paid directly for each notarization they create. The draw back to this model is that coin emission is not an exact known amount. Emission, however, can only be less than the set maximum, never more, and that is what is relevant in this situation.

Selection
The goal of the KMDLabs Notary selection process is to accrue a team of 64 extremely trustworthy and efficient Notary Nodes, testers and developers.
In KMDLabs, the number of Notary Nodes is dynamic, up to a maximum of 64 nodes. Every two months up to two additional Notary Nodes can be added until the maximum of 64 is reached. The process for this is still under development with the currently implemented system being as follows:
Every two months, the lowest performing nodes on the network will be put to a vote for possible replacement. Unless a node has been performing extremely poorly, and there is no expectation of this, nodes will not be involuntarily removed from the network. Only two nodes can be added per two month period regardless of whether notaries leave the network.
Those who desire a Notary position are advised to participate in the community, join in tests and possibly collect bounties, mine/stake or develop contracts until a Notary role opens up for them. In addition to Notary candidates gaining experience through this process it also helps protect the network from possible Sybil attack. (An attack where a single entity creates multiple identities to subvert a network.) Through something of a waiting period and random selection KMDLabs can somewhat ensure that each node is operated by a unique individual.

Bounty system
The bounty system is in the process of being finalized and is the top priority on the KMDLabs' project list. This development process will use the system under creation to bring about the final bounty mechanism. Aiming for the simplest solution. CC may or may not be made use of.
As it stands pre-launch, the basic mechanism looks like this:

A separate chain, is mined/staked by notaries.
There is a daily payment of coins that is ABOVE the supply of 10 coins per minute.
This supply is suggested to be between 0.5-5% of the supply and is locked in a multisig address. (ie. 0.5% would be 720 coins per day available for bounty payouts)
The funds expire if not used. The best mechanism for going about this is has yet to be determined.
If the bounty coins are not claimed they will cease to exist and will not inflate the supply.
Bounties only inflate the supply if bugs are found and fixed.
Project devs are also able to put up their own bounties, over and above this supply, if they want or need to get something done faster or take priority over other projects.
Bounty signers are responsible for signing bounty claims that they agree are fair.
This mechanism will evolve and change as the working implementation is developed and optimized. There are a number of possible solutions being considered. KMDLabs developers and community excel at finding the best solution for a problem. This has been, and is being, demonstrated in the creation and beginnings of the KMDLabs project itself.


Setup
For detailed setup instructions, please visit the KMDLabs' Notary Github repo.


Expected cycle of a Project that uses KMDLabs' Services
As previously stated, KMDLabs is a testing and development platform, suitable for research on many scales. From gaining experience using Crypto-Conditions contracts to debugging multi-contract clusters, KMDLabs provides you with the tools, platform and resources to accomplish all the Blockchain development needs of your Project. This allows you to spend your time on the virtuous cycle of development and debugging, not setup.
There might be minor changes to the details of the following steps as the project is launched and better workflows are found
Note that you might wish to use RPC to the existing CC modules to solve your usecase. If the ones in the linked document are not sufficient for your purposes, you may follow the below steps.

Creating a Chain


Step 1: Create a well commented CC contract or modify an existing one’s functionality.


Step 2: Very simple testing done on non-LABS testing chains. This testing period can be used for fixing any bugs that are very obvious. These chains can hardfork as much as necessary. These chains are not CFEK or LABS chains. They are not notarized.


Step 3: Send a Pull Request to the KMDLabs repo with the code. Detail and discuss the purpose and implementation in the PR comments. Wait until it is merged.


Step 4: Start a chain whose name starts with CFEK. This chain’s emissions can be anything. It does not have to match the emissions of the planned LABS chain. If the contract being tested relies on coins from the coinbase transaction, these coins will need to be burned on the main chain.


Step 5: Prove that you are capable of maintaining the CFEK chain. This means you keep it from stalling, and that you fix any bugs in a timely matter. Help will be provided in the form of documentation and support in the Discord chat to help you achieve this.


Step 6: Create the LABS chain. This chain must be staked with at least 2000 LABS to keep it from stalling. A chain might run with <2000 coins, but it would be susceptible to chain stalls if UTXOs are not distributed efficiently. You must have atleast minsigs number of notaries willing to notarize this chain for the -ac_notarypay price you have setup. (minsigs: the minimum number of notaries that must come to a consensus for a notarization to occur)


Once you are sure you have enough notaries willing to notarize the chain, burn the 1st block's coinbase amount. Please note this number will differ from the -ac_supply amount. Use the getnotarysendmany command to distribute 5 LABS per notary (amount subject to change as we finalise the details).
To continue paying the notaries, the “burn address” on the chain must be funded. This has been created in a way that allows the chain to extend the period of notarization, rather than have a fixed notarization lifespan. Coins can be migrated to and from other chains throughout the cluster and sent to the burn address as required.
To check the balace of the notarization funds, the getnotarypayinfo RPC can be used.

Step 7: Notaries sync the chain and begin notarizing.


The Testing Process


Step 8: Testers can now sync the chain and transfer coins to it from another LABS chain. Testers should be aware that coins could be stolen, lost or burned due to a faulty CC. As testing is done, testers can begin to rely on a CC for larger and larger amounts of coins.


Step 9: If coins are stolen, lost or burned due to a bug in the CC, the tester can make a bounty claim to the notary nodes. If a tester can steal, lose or burn coins due to a bug, the tester can make a bounty claim to the notary nodes. Whether the bounty is paid out is at the discretion of a vote by the notary nodes.


Notaries must be able to determine if a bounty is fair. If the notary nodes determine it is not fair, the tester can create a new bounty claim based on feedback from the notaries. This amount is limited to 0.5% of the weekly emissions. This amount does not carry over from week to week. If the limit is not reached for a given week, these coins simply never come into existence. (The percentage is sugject to change as we finalise the details)


Step 10: The tester will now need to work with the contract developer and the community to fix this bug. The bounty will not be paid until the bug fix is implemented into the chain. This process will involve repeating steps 1-4 until a bug fix is ready for the LABS network.


Step 11: Bounty is paid 🙂


Repeat steps 8-11 as necessary.


The above workflow can be illustrated with this image
[img]https://i1.wp.com/kmdlabs.com/wp-content/uploads/2019/03/KMDLabs_proposal_diagram_V2.0.png?w=885&ssl=1[/img]


Differences between KMDLabs' Komodo (STAKED) and Komodo Platform's Komodo
KMDLabs Komodo (STAKED) is fully compatible with KMD Komodo. The KMDLabs version of Komodo has been modified to give it a great deal of additional functionality. These modifications are all merged back to KMD now. Listed below is a glimpse of the innovations by KMDLabs. For more details, visit: https://kmdlabs.com/technical/ and https://kmdlabs.com/works/

Some of the Enhancements

Protocol version / different notary pubkeys

-ac_notarypay described in technical detail at the bottom of this page.
Komodo seeds are disabled for staked chains
Wallet filter for staked notaries
Temporary file for received blocks

Any blocks received that pass early validation and fail slow validation, will be left in this file. This is cleared once there has been a notarization past the highest height of blocks that are left inside of it. This means that any block that cannot be reorged back into the main chain, because of a notarization, will be purged from the local DB automatically. This stops almost all possible spam attacks that could fill a node’s disk.




Differences regarding MoMoM based crosschain migration

Extra set of pubkeys possible
Can’t send a migrate from a chain to itself KMDLabs
Can’t send more than 1 million coins at once KMDLabs. Along with a change in max money that prevents the sending of coins that can’t imported.