Ldevelopers of tecnología blockchain They are increasingly focused on bringing new functions, especially those that allow the cross-operation of several blockchains, and one of those technologies is the Succinct Atomic Swap (SAS) or Succinct Atomic Exchanges.
The Succinct Atomic Swap or SAS, are actually an evolution of the atomic swaps or atomic swaps that we can already see deployed in several blockchains. The difference is that SAS seek to make the way this technology works simpler, more efficient and more secure.
Succinct Atomic Swap (SAS), improving on atomic swaps
The idea of Succinct Atomic Swap (SAS) has its origin in the mind of Ruben Somsen, who on May 11, 2020, wrote the following message on the Bitcoin development list: SAS: Succinct Atomic Swap. In this message, Somsen described an idea that made it possible to create atomic exchanges quickly, with less complexity of code and scripts, and with low activity on the blockchain. All while exploiting the flexibility of ECDSA, and even looking to the future with the use of Schnorr firms y multi-signature addresses (MultiSig).
Somsen's idea was based on the work of the team of Monero (XMR) y their atomic swap between Monero and Bitcoin. And also, I took ideas about what was presented by the user @TierNolan in 2013 on the well-known Bitcointalk forum. In any of the cases, Somsen's proposal greatly simplifies the way in which atomic swaps can be carried out, reducing at the same time their impact on the blockchain, without sacrificing their security and privacy.
Despite the brilliant idea, this type of protocol has not yet been built, remaining in an experimental model.
How does the protocol work?
Now, the operation of this protocol depends in the first place on technologies that we already have available in Bitcoin. We are talking about crypto ECDSA, or also Schnorr signatures, multi-signature addresses, and additionally from opcodes (OP_CODES) as CLTV, nLockTime y nSequence. Simply put, at its most basic, there is no need to add anything additional to the Bitcoin protocol, and other cryptocurrencies derived from Bitcoin.
Starting the process
The process of running a SAS begins when two people initiate the exchange. In this case, we will refer to those people as Laura and Daniel. Laura has 1 BTC that she wants to exchange in its equivalent with Daniel who has Litecoin (LTC), and all this without going through a centralized exchange.
So we have Laura prepares 1 BTC in a transaction that she has signed with a joint signature using her signature and Daniel's. This first transaction that has not yet been sent will arrive on the blockchain in a waiting state. This is possible using OP_CODES like CLTV and nLockTime, which allow to define a timeout and other conditions necessary to process the transaction. In this case, the condition for the release of said transaction is that Daniel reveals his secret to Laura, something that has not yet happened at this point.
The programming with CLTV of this transaction also obeys another point, and that is that in case the parties do not complete the exchange, said transaction can be sent to the blockchain, and after a while, Laura can unblock it without problems recovering the funds. This is possible because CLTV can transform a multisig address into a single address under certain conditions that can be programmed. At the same time that Laura recovers her funds, she will reveal a secret to Daniel, which will allow him to recover the funds that he blocks in his Litecoin transaction.
Preparing the second transaction
While the first transaction has not yet been sent, Laura and Daniel are preparing the rest of the conditions for the exchange. At this point, Laura and Daniel now create a new and second transaction, but put a transaction-level lock on it (using nSequence). This will prevent the transaction from being taken by the miners until the blocking time passes, this time is decided by Laura and Daniel, and they have decided to give it a blocking hour.
This block on the transaction is made as an insurance that prevents Laura from losing her money in case Daniel acted dishonestly. And, thanks to the lock and the conditions in which that transaction was created, Laura can recover said transaction without problems. Hence, the choice of the lock is the OP_CODE nSequence, since it allows a relative lock. That is, the lock can only be activated when a previous transaction and its associated outputs (the first transaction signed by Laura and Daniel) have already been included in the blockchain.
Now, the next thing is to start sending the transactions. Laura sends the second transaction first, which will be locked indefinitely until the first transaction reaches the blockchain. However, this fact of sending the second transaction to the network is indicative for Daniel that Laura has started the exchange process. So the next thing Daniel does is create a transaction in Litecoin for the total exchange, and for that operation he uses the signatures of Laura and his.
This transaction in Litecoin is seen by Laura who, in accordance with it, proceeds to send the first transaction, which contains 1 BTC for Daniel. Laura will not be able to access the funds in Litecoin because she does not know Daniel's secret necessary to unlock said transaction. So once Laura sends the first transaction to the Bitcoin blockchain, the lock clock starts ticking.
Now, there is another point left, how is it possible that Laura and Daniel know the secrets necessary to unlock their respective transactions in Bitcoin and Litecoin? Well, at this point something known as the ECDSA signature adapter comes into play. This adapter makes it possible for ECDSA under certain conditions to reveal the necessary secret so that Daniel and Laura can unlock their transactions. That way, they can successfully make the exchange, something that we will explain below.
The moment of exchange
Now, as fast as the first transaction is on the Bitcoin blockchain, the exchange process begins. The first transaction is signed in such a way that it is only valid if Daniel reveals his secret. That is, if Daniel wants the Bitcoin, this will only be possible if Daniel reveals the secret when interacting with said transaction. This is because Laura signs said transaction in such a way that it will only be valid under this assumption and the person in charge of it will be the ECDSA signature adapter. The same happens with the second transaction, so Daniel has only one option left, to interact with those transactions to claim the bitcoins he wants.
Thus, when Daniel interacts with the transaction to claim the BTC, he reveals the secret to Laura. At this point, Laura knows Daniel's secret and her own, so she can go to the Litecoin blockchain and with both secrets in her power to unlock the Litecoin transaction that Daniel has sent in exchange for the BTC. In this way, Laura and Daniel have successfully performed a Succinct Atomic Swap (SAS).
If the process completes successfully, this will make the second transaction invalid. But if the process doesn't go through, then the second transaction (blocked with nSequence) will serve as a refund transaction, allowing Laura to get her BTC back without a hitch. In the end, in the best of cases, a SAS can always be carried in two simple transactions within the blockchain.