iguana daemon = Full Mode + Basilisk Mode
komodod daemon = Native Mode
Native Mode = uses Level DB database files to store and manage blockchain database
Full Mode = SuperNET innovation -> uses Memory Mapped Files and bundles to store blocks on system.
Both totally different formats and does different things.
iguana deamon = only supports Transparent Transactions
komodod daemon = supports Private + Transparent Transactions
James writes at bitcointalk:
Finally I see questions about this and since it is yet another new tech in komodo, it isnt quite like anything else.
Having 64 high performance nodes that are PoS elected provides the infrastructure that enables basilisk mode. Namely 64 servers each with the same set of full nodes running for all of the following coins:
[“KMD”, “BTC”, “USD”, “EUR”, “JPY”, “GBP”, “AUD”, “CAD”, “CHF”, “NZD”, “CNY”, “RUB”, “MXN”, “BRL”, “INR”, “HKD”, “TRY”, “ZAR”, “PLN”, “NOK”, “SEK”, “DKK”, “CZK”, “HUF”, “ILS”, “KRW”, “MYR”, “PHP”, “RON”, “SGD”, “THB”, “BGN”, “IDR”, “HRK”, “REVS”, “SUPERNET”, “DEX”, “PANGEA”, “JUMBLR”, “BET”, “CRYPTO”, “HODL”, “SHARK”, “BOTS”, “MGW”, “MVP”, “WIRELESS”, “KV”, “CEAL”, “MESH”]
Since all the notary nodes are running all these chains anyway and additionally they are in a position of having some trust, it does not increase the trust exposure to rely on them for blockchain data.
the basilisk client does all of the wallet management, signing, rawtx construction and anything that directly affects your funds. At no point does any notary node obtain any sensitive information. Rather, the notary nodes are providing data that is available to any node with the current blockchain.
If you analyze this as a system, you will find that there is only one way that a basilisk client can lose money and it is of a vandalism nature. Since each basilisk is signing its own transaction and it knows how much is being paid, the only exposure is if a utxo is believed to be smaller than it actually is. Notice that it cant be represented to be larger than it actually is, as that would create an invalid transaction. However, if a basilisk node is fooled into thinking a utxo has a value that is smaller, then it would end up creating a giant txfee.
Since the mining is randomized, an evil notary node cant know that it will get the oversized txfee. Additionally, I have capped txfee to 1 KMD, so even after all the work to fool a basilisk node to over spend and to be lucky and get the block with the overspend, it needs to be less than 1 KMD. Seems a lot of work for very small gain. Also, all basilisk packets are signed by a notary’s privkey and can be traced to the specific provider. Any evil notary node will quickly be identified and lose notary status.
A big risk for the 1 KMD “windfall”
However, I added a threeway validation for each utxo lookup. That means three random notaries all need to return the identical data for each utxo that is used in rawtx construction. Ultimately, the client GUI can track each utxo and its value and we can store this locally so we dont need to rely on the notary nodes for utxo lookup. However, to get the data needed to know what the tx value is, requires relying on the notaries, so I dont see it as a big priority to get this implemented. It would speed up the tx creation process though so after the must have functions are there, something like this could be scheduled.
For bitcoind experts, you will be saying, “utxo lookups are all nice and good, but you cant do listunspent for addresses that are not in the notary server’s wallet” and a basilisk node’s address wont be in the wallet, right?
With recent bitcoin versions, the support for watch only addresses was added and the komodo notary nodes utilizes this so it can keep track of transactions for addresses not directly in its wallet. One reason why it takes me so long to do the payouts is because I trigger an importaddress for all the notary nodes for all destination addresses. Also, the GUI does a network importaddress on wallet creation. this way, all transactions after a new wallet is created will have a watch only address and thus listunspent and listtransaction will work.
However, keep in mind that it is possible that sometimes a specific server wont have a certain address being watched for all the time after it is created and there could be occasional intermittent errors when creating basilisk transactions. So far, we are not seeing much of this, but it is a theoretical possibility.
I hope this explains basilisk mode well enough for people to understand.
The atomic explorer also uses the notary nodes for displaying the blockexplorer level data. Also, if you notice the notarychains array has BTC as one of the coins, so it means that you can do BTC basilisk transactions too.