Iguana’s relationship with Komodo

There are some questions about how iguana relates to komodo.

I have been working on a single codebase for the last 2 years. It is usually about 100,000 lines of C, though it fluctuates in size as I deprecate parts that I am able to improve and of course I am always adding to it.

Basically all my crypto code goes into the iguana codebase and docs.supernet.org shows the external API set. However, there is a lot more functionality that is purely internal. Think of it as a wide ranging toolkit that has code to do pretty much anything related to crypto and even some things that are just OS independent ways of dealing with large realtime datasets and networking.

One of the things komodo needs are notary nodes. Inside iguana there is support for special purpose relays. So, what I did was create an instance of these iguana relays and customized it to be notary nodes. I extracted the lowest level pubkey messaging and the notary nodes now support just this. However, creating a p2p network is not exactly a matter of a simple function call, so I also created a special coin called “NOTARY”. This is a coin without a blockchain and I made it so I can use the existing iguana peer management to spawn the notary nodes network.

As you can see, there is no simple way to explain how iguana relates to komodo. I will be adding voting support into the notary nodes and they will inject into the komodo network special “notarized” messages using an extended bitcoin protocol. Ths way, the amount of code that has to go inside the komodo is minimized and the less code there is, the less bugs.

One benefit of splitting out the NOTARY functionality is now, the DEX code can be run on even a basilisk node, which means you can run an LP node on a basilisk instance for a coin, though probably best to have a full iguana node if you will be competing with the realtime auctions.

I made some simple scripts that allows a node to add itself to the NOTARY network either as a notary node or as a client. For the voting, all the stakeholders would connect to the NOTARY network and vote. I came up with an interesting way to do the voting for the notary nodes that allows anybody to join as a candidate node, but only the nodes with the most votes will be actively participating in the block generation. I still need to finish coding it, but it avoids the problem of notary nodes creating blocks with the info that elects notary nodes. I also think it can be made to be near realtime performance, though I need to get it running first to verify its performance level.

Once we can get a validated and ranked list of notary nodes, then it will be possible to write the komodo side code that accepts the notarized messages.

Bitcointalk Topic Entry

0 replies

Leave a Reply

Want to join the discussion?
Feel free to contribute!

Leave a Reply

Your email address will not be published. Required fields are marked *

twenty − 9 =