Market Maker 2: The Engine That Powers The AtomicDEX Protocol

With the beta release of AtomicDEX, Komodo continues to lead the blockchain space in decentralized trading solutions. AtomicDEX is the only product that lives up to the 4 core requirements of a truly decentralized exchange.

This blog post will explain in great detail Market Maker 2, the underlying protocol that powers secure, peer-to-peer atomic swaps on AtomicDEX.

Lessons Learned From Previous DEX Protocols

Komodo’s atomic swap technology has evolved over the years. While Komodo has long led the industry in atomic swaps, BarterDEX, the previous generation of Komodo’s DEX technology, had a few major issues that prevented the application from being mass-adoption ready.

First, traders were required to have a UTXO of the precise value they wished to swap on BarterDEX. If a user wanted to trade, say, 1000 KMD for BTC, then they would need a UTXO of exactly 1000 KMD to make the swap, even if they had more than 1000 KMD in their wallet. In this case, the user would need to manually split the UTXOs in her wallet in order to have one UTXO that was precisely the amount of the fee and a second UTXO that was precisely the amount of the trade.

Second, one party of an atomic swap— the trader who initially posted the trade offer— was required to commit funds to a deposit address. The deposit had to be 112% of the total amount the trader wanted to swap. Although neither party in the trade nor the Komodo team could access the funds in the deposit address, it still gave the appearance of an escrow account or custodial trading.

Third, traders had to use a proxy token called ETOMIC when trading from Ether or an ERC-20 token to Bitcoin or any BTC-protocol altcoin. The trading process was still secure and peer-to-peer, but BarterDEX employed a small workaround to bridge the gap between the Bitcoin and Ethereum protocols. It was not as seamless a process as Komodo hoped to achieve.

Finally, there were connectivity issues with MarketMaker, the decentralized order matching technology upon which BarterDEX relied. As BarterDEX only worked with open ports, meaning it did not have NAT (network address translation) traversal capabilities and could not pass through firewalls. Practically speaking, an atomic swap would only work if the person posting the initial trade offer was on an internet server. BarterDEX would have connectivity problems for anyone trading from a home Wi-Fi router.

Now, with Market Maker 2, all three of these limitations have been resolved. The first step to perfecting an atomic swap protocol was to overcome the challenges presented by the unreliability of the Internet itself.

The Internet Isn’t As Stable As You Think

Despite the fact that humans have come to rely on the Internet more and more, the Internet is not always reliable. We might wish it to be, and we might believe it to be, conveniently forgetting all the times when it wouldn't work for us, explaining away as reasonable the failures on a case-by-case basis. But when it comes to our clients, this illusion of reliability backfires, as people are faster to blame the application they're using than some invisible routing issue.

"I've just checked and site X works" is often enough for somebody to reinforce their belief in the Internet’s reliability and look elsewhere for the cause of their grief. Even if an application’s development team convinces someone that the app had nothing to do with the problem, it is still frustrating for both the developers and the users when the app isn’t working as intended.

Every single second of every single day, there are lesions ("routing anomalies") in the Internet connectivity tissue that impact users. Sometimes small, sometimes nationwide. Here's a graphics depicting connectivity problems between a large set of random hosts (Mislove, Post, Haeberlen, Druschel, 2006):

It shows how some points in the Internet mesh are often unable to communicate with other points, even though the rest of the network appears to be functioning normally.

This is why companies determined to provide a more reliable user experience will often employ alternative content delivery solutions instead of simply relying on the Internet baseline. Some examples of this are the Cloudflare Smart Routing (and Argo), Google Espresso, Microsoft using a peer-to-peer network for Skype, and Valve for Steam.

With Market Maker 2, the Komodo Dev Team keeps pace with the big tech companies in trying to raise above the Internet default reliability baseline. By existing on a decentralized internet, Market Maker 2 is more stable than it would be if it relied upon an ordinary client-server model architecture.

Leveraging A Time-Tested P2P Network

The Komodo Dev Team has monitored the market for peer-to-peer libraries for years now, and, though the idea is simple, there's a big churn in terms of implementations. As a small team, Komodo knew it was necessary to avoid the risks of creating and maintaining a brand-new implementation. Peer-to-peer implementations that are both of outstanding quality and widely adopted are few and far between.

It came as a bit of a surprise initially, but in retrospect it makes a lot of sense, that a well-maintained and widely-adopted peer-to-peer library would be the one used by the Internet's most popular peer-to-peer network: BitTorrent Distributed Hash Table (DHT). There are tens of millions of Internet users utilizing this network every single day.

Market Maker 2 uses Libtorrent, the Arvid Norberg implementation of the BitTorrent DHT. Arvid worked in BitTorrent, maintaining the popular uTorrent client, and his open-source library shows excellent levels of software design and maintenance.

Using libtorrent for communication between nodes, Market Maker 2 gets the whole package: free battle-tested servers for DHT bootstrap; a huge network of DHT peers, helping us to workaround the network address translations (NATs) and routing anomalies; unique performance and reliability DHT optimizations incorporated by Arvid into the library (he talks about some of them in the libtorrent blog); ability to operate while switching IPs (when moving between Wi-Fi routers, cellular towers, etc); and a popular and well-maintained code-base, which is being used in various BitTorrent clients, including mobile devices.

Libtorrent DHT As The Networking Layer

Libtorrent DHT is not used in the order matching process but Market Maker 2 uses libtorrent to facilitate trustless swaps between traders in two major ways.

First, when Alice wants to send a packet to Bob, she would store it in the BitTorrent DHT in a location known to both parties (identified by the Bob's unique public key and a subject). Bob will then fetch the packet from that location. DHT is a distributed key-value database and Market Maker 2 uses it as such.

What's important is that the value is reliably stored in a total of eight DHT nodes, which are randomly distributed across the world, giving the communication a very high probability to continue even in the presence of partial connectivity problems (routing anomalies).

This makes a great deal of sense when we consider an example. If Alice wants to send a packet of encrypted information to Bob, she will send it to 8 different nodes on the peer-to-peer network. So, when Bob goes to fetch that packet, he can retrieve it even if 6 or even 7 of the nodes have run into connectivity issues or dropped off the network completely.

It’s like sending a letter several different times to ensure delivery. If you had an important letter that you had to ensure was delivered properly, you might print the letter out 5 times and post it to the same address through different carriers— UPS, USPS, FedEx, DHL, and TNT. Even if 80 percent of the carriers fail to deliver, the letter still makes its way to the recipient. This is what Market Maker 2 does.

This model is very good at solving the NAT and firewall problems (unless the firewall blocks the DHT protocol specifically) because both Bob and Alice here are clients of the DHT network. They initiate outgoing connections into the DHT, which works well with all the NATs and all the firewalls.

The second way in which Market Maker 2 uses libtorrent is to allow direct peer-to-peer communication whenever possible. When the IP:port endpoint of one of the communicating nodes becomes known to the other, Market Maker 2 sends direct DHT UDP packets between the two nodes, allowing for faster communication whenever such direct connectivity is possible (i.e. not being blocked by NATs, firewalls, or routing anomalies). By reusing the libtorrent DHT packets for this, we're taking advantage of the NAT hole punching techniques employed by the libtorrent.

As of now, both of these methods work. Data is transferred on both channels for maximum reliability, so a part of it might arrive through the DHT and another part with direct UDP communication.

The Market Maker 2 Trading Process

Here is a step-by-step look at how the Market Maker 2 protocol allows peer-to-peer atomic swaps to take place.

Step 0

The Market Maker posts a trade order on AtomicDEX. This is listed as Step 0 because, technically, it’s not part of the atomic swap process. However, this step must happen before the atomic swap can begin.

Step 1: <DEXfee> payment

The Taker sees Maker’s offer and accepts it. She commits to the trade by paying the DEX fee, which is just 0.15% of the total trade amount. The purpose of the DEX fee is to make sure Takers don’t spam the network with rapid requests. Note that Makers do not pay any trading fees on AtomicDEX.

Once Taker has paid the DEX fee, the atomic swap has officially begun. Maker receives the fee payment and initiates the second step of the swap.

Step 2: <MakerPayment> Is Sent

Maker sends his payment, known as the Maker Payment, which is sent to a P2SH address (for Bitcoin-protocol coins) or to a smart contract address (for ETH and ERC-20 tokens).

The Maker Payment is locked with the hash of a 32 byte secret code that Maker randomly generates. Only Maker knows the secret but the hash of the secret is public. This means that Taker knows the hash of the secret but she cannot spend the funds until she knows the 32 byte secret code itself. To better understand the concept of hashes, read this guide on cryptographic hash functions.

The Maker Payment is also time locked. The length of the time lock varies according to the block times of the two assets being swapped. Since Bitcoin has long 10 minute block times, the lock time must be longer, too. In most cases, the lock time for Maker Payment is 15,600 seconds, which is 4 hours and 20 minutes.

If the time lock expires before the atomic swap is complete, then Maker receives the Maker Payment back.

Step 3: <TakerPayment> Is Sent

Taker sees that Maker has sent the hashlocked and timelocked Maker Payment. At that point, she sends the Taker Payment to a second secure P2SH address.

Significantly, the Taker Payment is hashlocked with the same hash that Maker used to lock the Maker Payment. Taker can use the hash to lock the funds, despite the fact that she still does not know the secret code that Maker used to generate the hash.

The Taker Payment is timelocked, but with a length of time that is half of that used to lock the Maker Payment.

Step 4: <TakerPayment> Is Spent

Maker sees that Taker has sent the Taker Payment, which is locked by the hash of the 32 byte secret code he generated in Step 2. Maker reveals the 32 byte secret code, broadcasting it to the blockchain's peer to peer network in order to send the Taker Payment to his own address. Once this transaction has been initiated, the secret code is publicly visible.

Step 5: <MakerPayment> Is Spent

Taker sees that Maker has spent the Taker Payment and also sees that the secret code has been revealed. She uses the same secret code to unlock the Maker Payment and sends the funds to her personal address.

The atomic swap is now complete.

A Timeline Of Komodo’s P2P Trading Innovations

While Market Maker 2 is Komodo’s most recent innovation in decentralized trading, it is just one among many. For more than 5 years, Komodo’s Lead Developer James ‘jl777’ Lee and the rest of the Komodo Dev Team have continuously pioneered decentralized exchange technology.

February 2014 — An alpha version of MultiGateway, one of the blockchain industry’s first proxy token decentralized exchanges, is released.
April 2014 — James ‘jl777’ Lee first conceived of a way to code a cross-chain atomic swap protocol.
September 2015 — One of the earliest atomic swap protocols is developed, allowing direct P2P atomic swaps between BTC and NXT/NXT assets.
February 2016 — With the help of Tier Nolan, James ‘jl777’ Lee found a solution to a major technical problem, improving his atomic swap protocol.
September 2016 — More improvements are made to the existing protocol, allowing direct P2P atomic swaps between BTC and BTC-protocol altcoins.
January 2017 — Decentralized ordermatching is implemented, making it possible to build a fully atomic-swap-powered DEX exchange.
July 2017 — Komodo rebranded its atomic swap DEX technology to BarterDEX and began creating a basic GUI for traders to use.
February 2018 — A public stress test of Komodo’s BarterDEX allows more than 13,900 cross-chain atomic swaps in a 48 hour period.
March 2018 — After bridging the gap between BTC-protocol coins and ERC20 tokens, Komodo enabled direct P2P trading between 95% of all digital assets in existence.
June 2018 — The Komodo Development Team began working on Market Maker 2, the second generation of Komodo’s fully decentralized ordermatching technology.
April 2019 — Internal alpha release of AtomicDEX peer-to-peer trading framework. Private internal testing initiated.
July 2019 — AtomicDEX begins a public beta phase.

As the Komodo team continues to improve upon the AtomicDEX protocol, the product is nearing a state that is fully prepared for mass adoption.

If you’d like to start making your very first atomic swaps, download AtomicDEX now:

Download AtomicDEX

If you'd like to learn more about blockchain technology and keep up with Komodo's progress, subscribe to our newsletter. Begin your blockchain journey with Komodo today.