Is DeFi also possible on Bitcoin? Discrete Log Contract (DLC) could represent the first step towards a truly decentralised and peer-to-peer finance
Over the last few months there has been a growing hype in the world of DeFi, i.e. „Decentralised Finance“, a fairly generic concept in itself, but one that has been used very intensively for the promotion of various projects on Ethereum. Decentralised finance, however, is by no means a new phenomenon; on the contrary, one could argue that it is even older than centralised finance, as historically most financial exchanges took place without intermediaries. Suffice it to say that for millennia, value has been exchanged all over the world simply using gold coins, without financial intermediaries or central banks, and that most loans were peer-to-peer within households or local communities.
In the modern era, however, partly with the aim of achieving higher performance and efficiency and partly due to progressively stricter regulations, financial exchanges have become increasingly centralised, both with the advent of central banks and the evolution of commercial banks and the development of payment intermediaries. In fact, Bitcoin was born as an attempt to reverse this trend, eliminating the need to rely on trusted third parties to manage our economic interactions and exploiting the state of the art of cryptography to be able to exchange value securely even with strangers.
As a result of Bitcoin’s success, many people have begun to look for ways to manage even more complex financial transactions in a decentralised manner, with the aim of being able to replicate all the activities of traditional finance without the need for intermediaries. It was with this objective in mind that Ethereum was promoted and developed, which sought to offer advanced smart contracts using a more generic and less specialised transaction scripting language than Bitcoin’s, thus creating its own ecosystem which then adopted the term „DeFi“ for the marketing of many of its projects.
However, what was developed on Ethereum was achieved with trade-offs that were in some ways very limiting. First of all, Ethereum’s choice to keep all the logic of smart contracts on the blockchain with global consensus immensely limits the scalability of the system, making it increasingly difficult for users without high-performance hardware to validate the Ethereum blockchain without having to rely on external services, and increasingly expensive, in terms of fees, to execute contracts with complex conditions. Furthermore, by keeping all the data for the execution of contracts in a public ledger, the level of confidentiality for users is obviously very low, which makes the system less attractive for those who need privacy (e.g. a company that does not want its competitors to know what derivatives it is exposed to).
Fortunately, while many projects were born on Ethereum, other working groups have invested time and resources to build, in parallel, a more scalable and confidential smart contract infrastructure, working directly on Bitcoin, which is a cheaper blockchain to validate and with a more security oriented approach to innovation. Although some people criticize the Bitcoin ecosystem for this excess of prudence and slowness in innovation, in recent years it is undeniable that the technological infrastructure built on it has grown immensely. Just think of the enormous progress on Lightning Network and Sidechain, the less appreciated but equally important tools for developers like Miniscript and the many ambitious projects under development, such as RGB to enhance tokens on Bitcoin and Statechain to further improve scalability complementary to the Lightning Network.
However, the most relevant development for the DeFi and smart contract world on Bitcoin is undoubtedly the Discrete Log Contract, or in short DLC, proposed for the first time in a 2017 paper by Thaddeus Dryja (also author of the first paper on the Lightning Network). The term refers to discrete logarithms which, without going into too much technical detail, are the basis of the elliptical curve cryptography used in these special smart contracts. What is more important, however, is what they allow. In fact, DLC smart contracts allow two or more counterparties to make generic bets whose result will be determined by an oracle (i.e. data source), without this oracle ever knowing the existence of the bet and how the data it provides about events in the real world will affect the execution of the contract.
Now, to better understand how this mechanism works, let us try to see a practical example. Let’s assume that Alice and Bob want to bet 1 BTC on the outcome of the US elections in November, with Alice betting on Trump and Bob betting on Biden’s win. To create the contract first both parties put the collateral of 1 BTC each in a multisig address 2 of 2, of which they control one key each. From this address three transactions will be created: one to a smart contract that can be unlocked by Alice if the oracle certifies that it has won Trump, one to a smart contract that can be unlocked by Bob if the oracle certifies that it has won Biden and one that sends back 1 BTC each if the oracle does not certify either.
But how can the oracle certify within a smart contract without being aware of the existence of the smart contract itself? The innovation brought by DLCs is precisely in exploiting a cryptographic trick within the elliptical curves used for digital signatures in Bitcoin, which allows the oracle to treat the signature of a message by the oracle (where the message would be the output of the bet, „TRUMP“ or „BIDEN“), as if it were a private key that can in turn sign the transaction that unlocks the funds to the winning side.
This way, if Alice wins Trump, she can unlock the funds using her private key plus the oracle signature of the „TRUMP“ message to sign the transaction; if Biden wins, Bob can do the same using his private key plus the oracle signature of the „BIDEN“ message. If, on the other hand, the oracle disappears, or is unable to sign either output because the election result remains disputed and there is no obvious winner, Alice and Bob can take back the collateral put in the contract with the refund transaction.
This is clearly an extremely simplified explanation that omits several mechanisms necessary to mitigate some malicious behaviour that the two parties might undertake in particular situations, but it is still sufficient to understand the potential of this scheme.
In fact, beyond betting on political or sporting events, DLCs can also be used to create real financial derivatives where the object of the bet can be the price of an asset (e.g. Alice and Bob bet on the bitcoin price at the end of the year) and the outputs can be not only binary but also granular, through the preparation of hundreds of different payouts for hundreds of different price ranges for the future BTC/EUR rate, thus creating very censorship resistant futures, confidential and with an extremely reduced need of trust towards third parties. Precisely with regard to the problem of the trust also, to mitigate the risk that an oracle makes an incorrect reporting on an event, it is possible to rely on several oracles, so that the payout between the two parties is distributed according to the average prices reported by the various oracles.
Last but not least, DLCs are also compatible with the Lightning Network, at present only within bidirectional channels but, thanks to the next evolutions of LN (i.e. payment points), it will also be possible to routing economic relationships regulated by contracts of this type, thus allowing to obtain great scalability and reduced costs.
The first experimental DLC was performed in 2019 between CryptoGarage and Blockstream, who bet on BTC’s future price by creating a forward peer-to-peer contract. Subsequently, other companies and researchers began to experiment, working on shared formal specifications and implementing DLCs in some open source bitcoin libraries. But what will probably unlock the potential of DLCs for good is the next soft fork on Bitcoin, which will introduce a new type of digital signature called Schnorr and the new Taproot smart contract scheme. These innovations will significantly increase the complexity of creatable contracts without increasing the size of their settlement transactions.
It is important to note that what distinguishes Bitcoin’s approach to smart contracts more than the Ethereum approach is the fact that Bitcoin holds most of the complexity at the application level: it is the clients who will have to store the transactions for all possible contract outputs in the user’s local memory, thus using the blockchain only for the final settlement of the winning outcome. On Ethereum, on the other hand, smart contracts are executed in their entirety on the blockchain with global consensus, thus limiting their future development and users‘ ability to carry out independent auditing of the system due to the excessive amount of data to be validated.
DLCs are the first step in creating truly decentralised and peer-to-peer finance, where it will be possible to engage in arbitrarily complex financial relationships with untrustworthy counterparties without having to switch from traditional finance gatekeepers. It is important to keep in mind that building the technological infrastructure to make this possible without compromising the decentralisation of the system is an enormous undertaking, which will require years of work and the allocation of many resources to finance its development, but the way to create a real alternative finance is now marked.
