>> Understanding how Komodo's security protects a developer in the Komodo ecosystem <<
tl;dr: If you're developing on the Komodo ecosystem, you program your transactions to be considered "complete" according to the level of security you desire. More time, more security. It's about 20 minutes until the Bitcoin hash rate backs you up.Wall of text warning: If you're only mildly curious and in a rush, just read the first section. The rest is just written examples of how Komodo's Security Services work in practice, to help you visualize what the Komodo ecosystem is, and what it is capable of.
Disclaimer: None of this is investing advice. Do your own research.
I've had a lot of people ask me this question over the last month. In fact, I find that most of my time over the last month is simply relaying information from one person to another. Since I keep having to explain myself, and since it seems like useful information, I suppose it's time to put some of this stuff into documented form.
Komodo's Security Services ExplainedDuring the ten minutes before notarization, an asset chain using delayed Proof of Work is only backed up by the security that the asset chain developer has. This will likely be a quite small level of security (though, if the developer knows what they are doing, it can be roughly comparable and/or better than the security of a DPoS blockchain). However, so long as the developer understands the nature of this vulnerability, this does not actually prevent a danger to their asset chain or to their subset of the Komodo ecosystem.
Assuming they are using a vanilla version of the Komodo asset-chain setup, the developer simply needs to program their smart contracts and other ecosystem transactions to never consider a transaction to be complete until the transaction's data has penetrated the desired level of Komodo's security.
Within ten minutes, any transaction made on an asset chain will be notarized into the Komodo main chain. This provides a baseline level of security, though it is not as strong a defense as what occurs within another ten minutes: their data is then notarized into the Bitcoin blockchain. (See the whitepaper for full details.)
Developers simply need to make sure that the speed of transactions in their ecosystem matches the value of the transaction to the necessary level of security.
Link to documentationA generic exampleFor example, consider this line of defense against a double-spend attack.
Let us first suppose an
honest user makes a transaction on an asset chain requesting an item of value. The mindful developer will write a smart contract that sends back a signal to the user indicating to them that their funds have been received and the blockchain product is on its way. The developer can even program software that allows the user to see that the item now belongs to them–but with one caveat: the blockchain product is locked in a smart contract for a few minutes while the asset chain waits to make sure that everything was done properly. Once the user's transaction hits the desired level of security (as determined by either the developer, the user, or both), the smart contract releases the blockchain product to the user, and they are free to use it as they wish.
Now let us suppose a malicious user intending to perform a double spend attack. They send their transaction requesting an item of value. The mindful developer sends back the item of value on the blockchain, using the protective smart contract. This smart contract is watching to make sure that the item of value is not fully released to the malicious user until the transaction reaches the desired level of security.
If, during that time period, the malicious user performs a double spend attack, what they are doing in effect is simply erasing the transaction where they sent their money. It is now as though they never sent it. The developer's smart contract sees that the transaction disappeared from the asset chain's record, and the smart contract realizes there's been an attack. It returns the item of value to its original owner. The malicious user may get to keep their original money, but they do not receive the item of value. The seller keeps it.
(In actual practice, the double spend attack may even wipe out the existence of the smart contract in the first place, thus returning all money to where it was before the transaction even began. It's as though nothing even happened.)
All of this is performed through automation, removing the need for a developer to manually manage these situations.
There are many other methods that developers can also take to facilitate smooth and hazard-free transactions on their system. For instance, they can also create their own network of trustless and verifiable notary nodes, similar to the notary nodes of the main Komodo chain. This can give them the option of lowering the required number of notarizations they desire on the Komodo main chain, and on the Bitcoin network, thus speeding up transaction time.
Two specific ideas on how that might come into playThe following is just my own imagination of how this might play out. The developers on the team could probably present an even better scenario that would solve even more problems.
Let us suppose someone designing a decentralized MMORPG (like World of Warcraft), using the Komodo network.
(Decentraland, are you listening? We might be able to solve a lot of your current problems. 
)Everyone in the MMORPG community has heard of people spending $10,000 worth of the game's currency for a particularly desirable sword.
A developer wanting to use Komodo's blockchain to securely decentralize their in-game currency, in-game stats, the data that supports their network, or whatever.
They design their software to behave like normal. (Yes, that's right. Assuming the regular talent, they can design their decentralized/blockchain-based game to perform with as high a speed as the gaming standard is currently.)
They simply design their software to sync and keep an eye on their asset chain's history.
The game can now perform with the same high-speed stats that gamers today are used to. They cruise around and do whatever, never having to wait for the ridiculous load times that decentralized data management etc. requires in some of these other decentralized gaming systems people are creating.
When a player comes to a moment when it is time to perform an event worth recording on the asset chain's history, they commit to this event by making a "transaction" on the game's asset chain.
This could be the purchase of a sword (or a house, or access to new territory, or an agreement to a battle, etc.).
Once the transactionID has hit the mempool of the miners of the asset chain, the game would then initiate the other side of the smart contract, sending the blockchain representation of that sword into a temporary holding address.
The software running locally on that user's machine, and which has been designed by the game developer, now shows the user a visual representation of that sword in their inventory.
However, it displays some kind of "warming up" animation, or some other story element, as created by the designer of the game. If you're a good designer, you could even come up with ways to make this process part of the experience.
The player could already be carrying it around, playing in non-scored practice rings and duels, etc.
The big trick is, the sword is not able to be used in any important event (as decided by the designer) until the ownership is backed up by the Bitcoin blockchain.
Once the notarization hits Bitcoin, from there on, the user can use it throughout the entire game. That sword is proven to belong to the wallet address of the user wielding it, and any attack they make with it is backed up by the Bitcoin hash rate.
The software running on every other user's machine will only recognize the stats of this player, including the ownership of this new powerful sword, if the proper notarizations are in place. Otherwise, the software just ignores it.
If some die-hard malicious gamer were to try to buy the sword and then do a double spend, the game would have to be designed such that it can't be used until the ownership of that sword is backed up by the required level of security.
The double spend attack on the asset chain would be nothing more than a waste of the malicious user's time.
The software itself can be written to simply be verifying information before any battles/events between any players who are participating. Unverified data cannot be used in any important event. The software running on each game player's machine would be syncing to the asset chain's history, ensuring that no events/outcomes that are not verified can adversely affect game play.
The data history of the game can also be hashed and included in the asset chain, in whatever manner the developer imagines.
This is obviously a lot of work for the developers.
But ask yourself, what World of Warcraft be like today if not just its "gold" currency was decentralized and secured by Bitcoin's hash rate, but even the game data itself?
(Blizzard, are you listening?)Is there enough of a financial incentive there to get some talented developers to come do the work?
(Ready Player One? Oasis?)
The second exampleConsider someone selling houses.
They just tell the purchaser of the house that it will be ready in twenty minutes.
Voila.
A final point, since wall of text status is already well achievedHere's something else that I've had to explain at least ten times in the last four weeks. While I'm writing things out, let's just get it out there.
Most people do not yet realize the value of tiered-levels of notarization in the Komodo ecosystem.
Komodo's default notary nodes do not have to be the only ones in existence in the Komodo ecosystem. Furthermore, what happens if we get to a point where the value of KMD rises?
Every ten minutes of Komodo's security costs 0.005 KMD, regardless of KMD/USD market value. That's simply the cost that the notary nodes have to make, to get notarization to work.
(Notary nodes do not make money off of this. They make their money from having a handicap when mining the KMD chain. Notarization is just one of the tasks they do. The KMD you pay them is used solely for the notarization cycle.)
We're not sure what the lump sum payment to the notary nodes is yet, but somewhere in the neighborhood of 333 $KMD for a little over one year's worth of security.
What happens if KMD attains the value of NEO GAS? Last I checked it was around $75 USD.
Komodo's security services suddenly get quite expensive--too expensive for garage band startups.
Well, either someone who currently owns ~7770 KMD, or someone who does a dICO at this point, can start a new network of notary nodes. Off the top of my head, that amount would last for about twenty-five years.
(We sometimes refer to this point in our future economic plans, as it is the projected time period of Singularity--the point where AI intelligence surpasses human intelligence, and all economic assumptions can experience radical change.)
Back on topic: this second set of notary nodes is now a tier-two notarization.
This set of notary nodes notarizes all of the asset chains in their sub-ecosystem into their main chain.
Everyone in their sub-ecosystem is paying in TIER-TWO security coin to notarize into the tier-two asset chain.
The tier two chain notarizes itself into the KMD chain.
KMD is then notarized into the KMD chain, which is then notarized into Bitcoin.
Everyone is now backed up by the Bitcoin hash rate. Voila.
The only difference is an extra ten minutes for people on Tier 2 (and, presumably, a reduced price, for that ten minutes).
Then imagine tier three, tier four, and as far as this thing will go.
Furthermore, consider that for yourself (speaking to the entrepreneurs in the community), you only have to notarize into KMD once.
You could easily set yourself up so that you have one main chain notarizing into KMD, and then a bunch of your own other PoW blockchains that notarize into your main chain. You set up your own miners, and even notary nodes if you wish, to manage your network. Each blockchain has different purposes and use cases, but you only pay one fee to get them all backed up.
And yet furthermore, let's say that one day you find that your business has grown so wealthy, you think you can afford to notarize to the Bitcoin blockchain itself, and skip the whole KMD notarization.
We've probably mentioned a few times by now that Komodo is focused around Freedom.
Because your main chain is independent, you just detach from the Komodo main chain and link up directly with the Bitcoin chain.
Assuming you have the requisite talent on your development team to plan it out, the only thing users in your ecosystem would notice is that all of a sudden, security would show up ten minutes faster.
So, if you, dear reader, belong to a large organization (like Blizzard/World of Warcraft) and you're not sure about all of this blockchain stuff and how you want to approach it, you can start with us as a launching platform. Then, when you have generated the XXXX required amount of BTC to head off, on you go. You have complete freedom to make that call.
Finally, consider this: the Bitcoin hash rate (which is what prevents Bitcoin's history from being altered while maintaining an accurate and un-manipulated decentralized history) currently consumes more electricity than the country of Denmark.
And that hash rate continues to grow.
It continues to grow at a rate that is faster than even the Bitcoin Cash hash rate is growing (the only one that is even in the ball park).
(The Ethereum hash rate doesn't even register on the scale.)
It is said that within the decade, the Bitcoin network will likely consume more electricity than the entire world combined.
All things being equal, and assuming the Network Effect that even today continues to increase the hash rate/security/price cycle of the Bitcoin network, the USD equivalent value of the
transaction fees for Bitcoin will continue to increase.
Last I checked, the cost for us to do one year's worth of notarization is about $2.5M USD worth of Bitcoin.
The Komodo main chain continues to rely on our reserves of Bitcoin to notarize to Bitcoin (we have enough BTC for over twenty years, regardless of BTC's USD market price. And that's before any business models we may implement to replenish it our reserves).
In that sense, in the crypto world, Bitcoin becomes the heart of hash-rate security, and Komodo is the pulmonary artery that connects the heart to many other veins.
I'm frequently asked by people who our main competitors are, within crypto.
In truth, the only ones of which I am aware are the historical whales of Bitcoin, and thus have the same amount of access to the Bitcoin hash rate that we do.
All other projects that are trying to do something similar to what we're doing (Ethereum, NEO, Ark, Waves, and other Proof of Stake-based coins, etc.), do not have anything of which I am aware that can provide this level of security while allowing independent blockchain developers to do whatever they want with their own independent chains.
What else am I explaining constantly?I think this is enough wall-of-text for now, but readers who are interested should know that the Komodo Smart Contract API has intriguing angles, and unrealized potential. Stay tuned for more, I suppose! We'll get the explanation out there soon enough.
You may also be asking, "But what about high-speed transaction situations"?
The implementation that we have for this situation is currently already in place with our Speed Mode feature on BarterDEX. The developer of an asset chain can also implement their own notary nodes, which provide a level of security on their asset chain that is equal to (and arguably better than) the DPoS security that other blockchain platforms are using. I'll have to explain more another time. Also, the CHIPS asset chain we're building helps to handle high-speed transaction situations. It ties in with BET and PANGEA. They are all well into development, but won't be marketed for a long, long time. But just fyi, for those of you who managed to make it all the way to the end.
And that's about all. Peace out.
