Why subatomic swaps are fast?
A while ago this question was submitted to Komodo Platform community portal which is at the time of this writing is in read mode only. I am uncertain if such portals and forums will be here for long term, so I’m trying to backup some content I posted there which I think is useful to be accessible from perspective of Komodo Platform’s technology history as well as knowledge share.
Q. Why subatomic swaps are fast? If I understand correctly, there’s a channel being opened, large amount of small back and forth continuous transactions occurs and then channel is closed. Is this correct? Why does it last half a minute then? Channel somehow aggregates these small transactions into one and put it to a mempool and makes sure it will come through eventually somehow? Could someone please explain?
If I understand correctly, there’s a channel being opened, large amount of small back and forth continuous transactions occurs and then channel is closed. Is this correct? Why does it last half a minute then?
Yes, that’s correct. The channel is created between 2 trading parties using peer-to-peer (p2p) messages, where the transaction ID and state of it’s receiving/sending and confirmation is shared on this opened channel where finally it closes on either successful or failed trade. And since all this communication only strictly happens over a p2p network, where no blockchain based swap restrictions or logic involved unlike “atomic swaps”, the trades complete as soon as both parties receive their funds and the transaction is confirmed.
Why subatomic swaps are fast?
Channel somehow aggregates these small transactions into one and put it to a mempool and makes sure it will come through eventually somehow? Could someone please explain?
The main reason subatomic swaps being so fast is that the “subatomic swap” method does not involve blockchain based scripts like Komodo’s “atomic swaps” protocol does.
Subatomic swaps use pure peer-to-peer messaging to open communication between two parties to initiate a trade and complete it.
The process of subatomic swaps is somewhat as equal to as you and me sitting on a chat messenger exchanging status update of our trade transactions back and forth along with keeping an eye on the transaction confirmation status on the cryptocurrency chain we are using to trade.
The peer-to-peer (p2p) network is built using a recently developed Komodo feature called DEXP2P, which was developed by James (jl777) around Dec 2019 — Feb 2020 in order to make an alternative scaling solution for AtomicDEX order-book. Using DEXP2P the order-book data is created and shared between the connected peer nodes for a default duration of 1 hour, before these cached order data is expired and removed/erased from run time memory of peer nodes.
The advantage with DEXP2P based order-book is that it uses pretty enhanced p2p network communication layer of Bitcoin technology (built using libevent library) which is much better compared to other solutions for creating a p2p network. As per James he tried to find any existing solution in industry which could allow people to create a p2p network with just a command instead of using a code library. And out of necessity DEXP2P came to existence, which James fine tuned a lot to make it solid enough to be usable for a scalable p2p order-book solution for AtomicDEX.
Since the first use case and necessity was to have a better scalable solution for AtomicDEX order-book, but this DEXP2P code being coded and dependent in Komodo’s core daemon `komodod` it needed to be tested and debugged properly. So, to test James also made a proof of concept version of swapping method which only uses this DEXP2P based p2p network which is created as easily as a creating a new smart-chain with only one command.
Once peers connect to this p2p network, they can issue a `komodo-cli` command to broadcast the message on the network with a standard format, which can be compiled as order-book among connected peer nodes. The subatomic code only issues these `komodo-cli` commands processing the output data and keeping up to date with the state of the trade initiated using subatomic dApp. There is no blockchain logic involved which can insure that if either party leaves the trade in between the sent funds will get back to their rightful owner. This is the risk using subatomic swaps. It is much like a trust based system instead of trustless.
And because of such risk factor it is advised to only do small amount of N number of trades to swap full amount. Example is like if you want to trade $100 you may chose to swap a small amount of $1 100 multiple trades or may be 20 $5 amount of trades, or may be if you trust the other party with whom you are trading with you may chose to trade bigger size of trade amount with less repeat of trades to complete full amount swap. In between it is possible that some trades may fail, due to N number of reasons where it could be a failure of p2p message delivery to either party, could be that either party dropped in between the trade is happening, could be some blockchain level event, etc. In such cases, it is expected that both trading parties be cautious and halt trading. Either try some other trader on the network to do rest of the trades or try again with same trader if you really trust the other party. And because of such risks with subatomic swaps, it is advised to only use small amount of multiple trades instead of big mount trades.
With the above trade scenario explained, it must be clear that the risk of loss of funds is greater with subatomic swaps, but if you are just trading like $1 trade and if it fails you only lose $1 + network transaction fee for this transaction, and not the whole $100 or bigger amount. You stop further trades or may be continue with the known risk with same trader and either complete the full amount swap with rest of the small amount trades or drop next tries. This is the main reason, the subatomic swap amounts are so small or say micro-sized.
The subatomic swap shares each trader’s `pubkey` and `handle` (an alias name which is tied to the `pubkey`) information which is visible on order-book. And there is also a list of `pubkey` from different community members with their handles stored in a reference file called subatomic.json. You can check against the mentioned pubkey/handle list in order-book and decide what minimum amount you want to trade with these traders if they are offering any trades on the network which are listed in order-book list.
You can consider this `subatomic.json` like your local personal phone book on your mobile, where you save/remove the pubkey/handles that you trust or not trust.
So, it’s also like doing a trade with a person repeatedly, and if you both build trust with each other over time, you add each other to this json file and next time you can identify the trusted member’s orders in order-book, and make trades as per your choice and trust level.
Since this subatomic swaps dApp is the first proof of concept it only supports the Komodo ecosystem cryptocurrencies. As per the use case and method the subatomic swap uses it is possible to add almost every cryptocurrency in market to it.
The above detailed explanation should have cleared why and how it’s fast and what are the risk factors.
So, if to chose to increase a size of amount for each trade, what size of bigger amount it can be?
The answer is dependent on the cryptocurrency that you chose to trade. Check out website like https://www.crypto51.app where you can see what estimate value does it cost to attack a cryptocurrency network to reverse a transaction using 51% attack. Have a look at the “1h Attack Cost” column on that website.
You can chose to use that level of big amount, preferably lesser than that amount for the specific cryptocurrency to decide on your trade size, and that too only with the trader party you have a trust on.
It’s because if in case the other party decides to cheat by doing the 51% attack on the chain they are sending a transaction to you, in order to take your cryptocurrency and also reverse the amount on risk, the risk is the amount of funds or hashing power expense which are either equal or less than the needed funds to achieve a successful attack. If the evil counter-party chose to cheat, the winning amount won’t be significant more or probably less than the amount it may cost to attack the network to reverse the transaction, where evil counter-party may consider it as profit.
At this point there is no such automated method in subatomic dApp which automates this risk management, but it is possible to add this feature at client end side so the user is forced to keep the amounts less than the risk factor, also showing the trusted traders highlighted in the client application so they are distinguishable than others. Also, possible to automate all the manual tasks of making N number of multiple trades repeatedly with the risk management rules set based on risk profile settings coded at client application end.
But you might still have a doubt about why go this non-blockchain trusted method of trading instead of atomic swaps?
Let’s cover those:
- With subatomic swaps there is no DEX fee. The user only is paying the network transaction fees for the cryptocurrency they are trading on this network.
- With subatomic swaps, since it’s not blockchain based scripts logic it allows to make trades with those cryptocurrencies which at the moment are not supported by existing “atomic swaps” protocol, such as zk-SNARKs based cryptocurrency like PIRATE. We have even done successful subatomic z2z private transactions swaps using subatomic swaps between PIRATE and Verus zk-SNARKs shielded transactions. Where “atomic swaps” will sure one day support zAtomic Swaps, subatomic swaps already allows swapping zk-SNARKs cryptocurrency with other cryptocurrencies on the network.
- Subatomic swaps roughly completes a single trade in about 20 to 30 seconds each! That’s very fast as compared to “atomic swaps”. And if have the ability to understand and decide the size of your each trade, and a trustful trading partner with whom you want to trade you get cheaper and faster option to trade your funds.
- With 1 hour order expiration time of order, the orders gets removed from the peer nodes’ run time memory, which to some extent also covers a privacy concern where no order-book and exchange methods are recorded on blockchain permanently, except the transaction which looks exactly like any other normal transaction on their respective cryptocurrency blockchain, that it’s harder to correlate with chain analysis. Of course there are still other network level of privacy concerns, which can possibly be covered by using an overlay privacy enhancing networks such as Tor, i2p, freenet, Proxy, VPN, etc.
- Risk factors explained in the above explanations can be handled at client application level or even coded within the subatomic dApp code to enhance it’s capability to lower the chances of loss or to halt at the minimum loss possible, along with facilitating easiness to the end users.
So, using subatomic swaps users may get fast and cheap P2P trading experience with mild level of risk if the client application is coded to take care of the risk factors for user as much it can.
And for bigger amount of trades user would want to use “atomic swaps” instead as for bigger amounts users wouldn’t mind paying a DEX fee.
To summarise, it is a choice between convenience and risk factors. While subatomic swaps are not ideal for big amount trades, these can play a role in micro transaction based decentralised application, now that there is DEXP2P tech which also allows to easily create a p2p network with easy command line tools alone. A combination of this tech among other Komodo based API a variant level of decentralised applications may possibly be developed.
For reference, and to take DEXP2P to its extreme to test its scalability level James and Komodo community tested (1080p-4k) high resolution recorded as well as live video streaming over DEXP2P based p2p network, which worked good in the tests.
A creative mind in my opinion is just limited to his/her imagination how he/she can use the combined tech stack of Komodo and build efficient scalable decentralised applications.
This answer went too long as I started writing. Hope you don’t mind, and find it informative.
Some reference links: