Differences between KMDLabs Komodo (STAKED) and KMD 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.
- 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
- This has been updated and is now active in the main KMD codebase also.
- Temp 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.
MoMoM differences between STAKED (KMDLabs) and FSM (Komodo)
- Extra set of pubkeys possible (libscott and blackjok3r’s code, required for dPoW) in STAKED (KMDLabs).
- Can’t send a migrate from a chain to itself in STAKED (KMDLabs).
- Can’t send more than 1 million coins at once in STAKED (KMDLabs). (Along with a change in max money that prevents the sending of coins that can’t imported.)
Gives a tally of stakes from chain tip back a specified number of blocks. An improvement over getsnapshot as it gives an idea of what is being staked.
Returns a valid JSON for the current ERA. In this way Iguana config is not separate from komodod. This prevents human error when changing keys, ports and other information.
Returns a JSON object with all Notary addresses and the amount of coins specified in input. Used for Notary Stats and for funding Notaries.
See StakedNotary Github readme for information on this soft wallet reset . A patch is available for mainnet should anyone need.
changes to zmergetoaddress
Allows a simple, one RPC call to merge all notary utxos into a single utxo ready for splitting. Ignores the utxos needed for notarizations.
Notary pubkey arrays are in a 3 dimensional array, making it much easier to have a very large number of eras and to loop over them. This makes changing keys very easy. It also makes the code much simpler and easier to follow.
There is a function in one of the Komodo.h files where, on block receive, the ERA it is in is determined and an array of Raddresses is created into a global var. The array is only updated after the era has finished. This is mainly used only for the wallet filter and will likely be depreciated in the future, being replaced with an improved, more reliable method.
The main LABS chain also uses ERAs, merged down from Verus Coin, allowing a slow ramp-up of block rewards over a week-long period. This has been implemented to realize the most fair launch possible.
The basic idea is that Notary Nodes are paid for each notarization they make. The ac_param itself, is `ac_notarypay=”number of sats per notarization”`.
This means specifically, that each time a notarization occurs this amount of sats is created. This is not part of the normal block reward of 7 coins, but rather an extra on top of that.
On the main chain, this number is `1500000000` once the first week is finished.
The math behind this is:
`7 + 3 = 10` Which has always been the block reward for STAKED.
Notarizations on LABS happen every 5 blocks, so
`1500000000 / 5 = 300000000` which equals 3 coins. This will mean that under perfect conditions the total emitted coins per block for LABS is 10 coins a minute.
However the conditions are not always perfect. LABS notarizations can only happen if 3 KMD blocks have passed. What this means is that if 5 blocks of LABS have passed before 3 KMD blocks have passed it will wait another 5 LABS blocks to create a notarization. Therefore notarizations do not happen exactly every 5 blocks, it can be 10 or sometimes in extreme cases 15 blocks.
Notarizations, by design, do not always happen on schedule. There could be some connection problem or a chain reorg (between notarizations) that prevents the notaries all agreeing on what chain is the correct chain. As such, they will skip that round.
With more notary nodes and a higher hash rate, this becomes less of a problem but it does exist so has to be mentioned here. Rather than account for these possible conditions, we have decided to assume perfect conditions for the amount paid as that caps the coin emission to the rate that we would like.
Now for the technical description of the code. This payment mechanism went through a few iterations until we got to something that actually works. It’s not perfect, but nothing is.
Create a notarization which then propagates to mempool.
1) Miner scans its mempool to create a block and check whether each tx is to the “crypto” address.
2) When miner finds a tx to the crypto address it then checks if the vins are from the current set of notary nodes. It does this by looking up the ERA with the timestamp of the block that it is going to create.
3) If it finds a tx with enough vins from notary node pubkeys it then checks if each vin is unique.
4) If all vins are from different notaries it then checks what block height the notarization is notarizing.
5) The miner then saves the Notary IDs (location of pubkey in array of current eras pubkeys).
6) It sets the notarization that it selected to mine at the maximum mining priority.
7) It then sets any other transactions that have max priority at `max – 10`. This ensures that there is 1 notarization allowed in each block. This is a consensus rule. There cannot be more than 1 notarization in a block, and it must always be the first tx in a block that is mined. Any blocks mined without these conditions are rejected by `connect block` and will not be accepted by any nodes in the network.
8) Then the miner uses the Notary IDs it has found when searching the notarization vins to construct a coinbase that pays these pubkeys the desired amount that is specified by the -ac_notarypay param.
9) This amount is divided by the number of notaries who made the notarization. ie. it is shared equally between them.
10) The block is mined and propagates to all nodes. At this point the notarization check point is created and the notaries receive their pay, unless this block is subject to a reorg.
11) If a reorg is to happen, this notarization goes back into the mempool and will be once again at the top of the list to me mined and the notaries will be paid again in the same manner. Even if notarizations are mined out of order, any notarization that is mined will be inside its own block, and notaries must be paid in the coinbase of that block. It is important to note here that by a reorg we mean a reorg of the block the notarization transaction is included in, it is usually setting a checkpoint for about 3 blocks prior. That block cannot be reorged due to dPoW.
All nodes on validation with no slowflag (when a block has arrived out of order, does not have all prior blocks):
1) Check that the coinbase tx contains only 1 vout, if there are more than 1, then it assumes that Notaries have been paid.
2) It checks that the first tx is to the crypto address. If it isn’t the block is rejected.
3) It then checks the amount of vins in this transaction meets the minsigs for the current ERA, if this is not met it rejects the block.
4) Also to note here, while both these things are easily faked to create fake blocks that are stored in the local block DB, we have a special mode where all blocks are saved into a different file which dynamically allocates space until `connect block`. Once a notarization happens, any blocks left in this file are automatically purged. They are never added to the main chains block files. So there is no problem with people attempting to spam blocks in this way. They are only wasting their own resources, and gaining nothing.
All nodes with full validation:
1) At `connect block` a full validation is carried out before the block is added to the main block files . As stated before, if this block is invalid at this step it is left in the temp file and will eventually be deleted in run time.
2) Does a full block scan to get notarization position and to ensure a valid notarization is in position 1. If a notarization in the block it must be in position 1 and the coinbase must pay Notaries. If not the block is rejected. This is a normal check that all dPoW coins must do. We just used this scan to determine if the block contains a notarization, and that it is in the right place. This full block scan is only done once. After this we know exactly where it is.
3) When it sees that a block has a notarization in tx position 1, it now knows that Notaries must be paid. It then uses the same process as the miner to create the coinbase from this notarization, to compare whether the two transactions pay the same amount, and to pay the same pubkeys.
4) If all of this then passes the total amount that notaries are owed is added to the usual block subsidy amount. This allows the block to pass the coinbase amount validation later in `connect block`.
That’s pretty much it. All the code is open source on our GitHub and quite well commented. I want to make sure people understand that notaries cannot create any extra coins, only less coins.
Extra info for 0 Block Reward cluster chains:
I have added a new feature for notarypay chains that do not have their own coin emission. There is a burn address, that you can send coins to. The total amount paid by ac_notarypay is tracked inside the block index as a new parameter. When the total paid, is more than the amount in the burn address, iguana stops working. And will refuse to notarize until some more coins have been sent to the burn address. This is disabled on LABS itself, as notarypay is part of the coin emission. For 0BR chains, or testing chains, if they are needed to continue being notarized, for extended periods, coins can be migrated from LABS and sent to the burn address. The RPC to check this is `getnotarypayinfo`.
The KMDLabs main cluster is where the bulk of testing occurs. The KMDLabs blockchain is the center of a fungible grouping of independent blockchains. New chains are added as needed and you can add your own chains to perform tests.
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 do so. This allows you to spend your time on testing, not setup.