Another day, another contract?! Hm, maybe that isn’t quite the saying used by the masses. But that doesn’t mean there isn’t another contract on the horizon. If we remember correctly, we experienced excitement around the announcement of the smart contract. So what could be so different this time? Like everything in the blockchain world, this contract addresses the problems that arose in its predecessor. With that, the new and improved discreet log contract (or DLC for short) or invisible smart contract was born.
Before you get too excited, we wanted to take a deeper dive into the smarter smart contract and just what this could mean for how we conduct business on the blockchain. After all, executing trusted exchanges hinges on a lot of different technologies.
Smart Contract Turned Discreet
You might have remembered our initial discussion on Smart Contracts. As a quick reminder, the Smart Contract is a self-executing contract that contains the details of the agreement in the blockchain. Since the blockchain is public, all the interactions with the contract are also public. This might not sound secure, but keep in mind the exact details are hidden in the code. Since the details are locked into the blockchain, it is impossible to make any changes, offering a level of security to users.
We agree we love the Smart contract. But, that doesn’t mean that there isn’t any room for improvement. After careful analysis, a couple of key areas for improvement became apparent. These reasons include the inability to produce and execute smart contracts at scale, ensuring the contracting parties have privacy when conducting their transactions. Most importantly, integrating data from off the blockchain to the contract needed to be more seamless.
It was in these times of uncertainty, the Discreet Log Contract was born.
Welcome The Discreet Log Contract
Simply defined, a Discreet Log Contract is a contract holding monetary value. When enacting a DLC, a third-party announces the outcome and the funds are distributed accordingly. The blockchain disguises the exact conditions of the contract. You might think this sounds familiar. We sure hope so, this model has been based on the initial smart contract. The difference? Discreet Log Contracts are a system which addresses the scalability and privacy concerns. This means we need a third-party, also known as an oracle. To minimize risk, the oracle may not even know who the two contracting partners are.
Thaddeus Dryja initially proposed this concept in the MIT Digital Currency Initiative. Thaddeus was also the co-author of the original LN paper, which also draws some parallels to his work with DLC’s.
Okay wait, let’s back up a bit. Where does the term discreet come from? The contracts remain discreet in the sense that external observers can’t detect the presence of the contract in the transaction log. They also hinge on knowledge of a discrete log problem also referred to as the DLP. Typically, we can more closely consider the Elliptic Curve DLP. To bring the DLC dream to life, some pretty interesting technology must underlie it.
The Elliptic curve is public-key cryptography that uses properties of the curve to determine a random private key counterpart for each value. We know it sounds complicated. Let’s break it down a little bit more. Looking at the curve, we can then select two points. If we were to draw a line through them we could then find the point of intersection. After identifying this point, we would then find the point on this same curve with the opposite y coordinate.
Still following? It’s okay if you aren’t, this seems like a very long and inefficient way to calculate each value. Nobody has yet to find an easier way to calculate any given multiple which has posed quite the problem, without trying every value. This problem is what we like to call the discrete log problem. This means that the Elliptic Curve DLP used allows for private keys to sign the discreet log contract but only public keys for validation.
Knowing that there are both public and private keys, we can now consider the next piece of the discreet log contract. That is the schnorr signature. This is a necessary part of the contract since we would like our online signature to be unique, not easily replicated. Since this agreement occurs on the blockchain, naturally the signature would need to take the shape of a mathematical equation. For those mathematicians out there, you might have even heard of this referred to as a trapdoor function.
To leverage this, the Discreet Log Contracts use something we like to call the Schnorr Signature. This is far from a new concept and has actually been around since the 1980s. This is when the idea was invented by a German cryptographer named Claus-Peter Schnorr. To avoid complexity, the hash function allows a party to sign using a public key. This public key is equal to an equation that would otherwise be impossible to solve if she didn’t know it. On the other end of the transaction, the opposing party needs to verify the signature on the contract is equal to a value, let’s say x. We use this value inside the hash.
This means other than the signer, it would be very difficult, if not impossible, to figure out what this value x is without knowing the function. Therefore, we can attribute a given signature to a user of the blockchain. The value that the contracting party uses will need to change every time to avoid anyone plugging these values back in to discover their private key. Values can then be inputted and their messages hashed. By doing this, any modifications to the original message will prove the signature invalid.
The equation used in the standard schnorr signature is the same in the DLC. The only difference? The signing key is re-classified as part of the public key instead of as part of the signature.
Executing the Contract
To start things off, the contracting parties must first agree that they want to enter into a contract together and agree on its terms. Since the contract oftentimes involves a certain outcome in the future, the counterparties create many transactions. This accounts for the different variations in the outcome. To determine which transaction occurs, we involve a third party. The third party is the oracle.
To kick the discreet log contract into high gear, your oracle will lock up any funds involved in the contract. These funds are then allocated based on the outcome of a specified event. To ensure the contract is executed properly, the oracle will broadcast the result to the public. On the day the contract executes, the oracle will record the result of the futures contract.
For the winning party, the resulting signature is taken and used as a private key when accompanied by the winner’s own private key. The resulting function will then allow the party to claim the amount indicated. If one of the two parties were to try and claim the winnings without the signature from the oracle, the counterparty will receive the proceeds.
The Oracle Requirement
Every DLC requires an oracle. This oracle is simply a 3rd party source of data or information that the parties to the DLC look to as the source of truth for the contract. Consider this, perhaps you wanted to purchase something on your region’s local eBay. The person has agreed that they will provide you with the product if and only if you send over the money beforehand. You are skeptical. After all, you’ve never met this person before and you really don’t know anything about them. However, if you had a mutual friend that you both trusted you could use them as a go-between to ensure you get the product and the individual receives their money. You know this go-between as your oracle.
Unfortunately, this concept has been heavily simplified and would also require the intermediary to abide by legal policies and both identify this trusted individual. An oracle is necessary since it provides a connection between events in the “real” world and the blockchain.
To ensure the oracle remains neutral, the oracle does not know the price data or the actual details of the contract. In fact, the oracle doesn’t even know they are signing a contract. However, the oracle’s signature is public. This means that an incorrect signature would be noted by the members of the blockchain. This means the oracle cannot manipulate the contract with bad pricing data.
Creating The Contract
The contract itself is made up of many transactions that we call contract execution transactions (CETs). Since there can only ever be one result of the contract, only one of these predetermined transactions will be posted onto the blockchain. The caveat, neither of the contracting parties know which one. This is why a transaction for each possible outcome requires a signature by both contracting parties.
When timing is involved, each contract execution transactions (CETs) will require two outputs. The first output is for the immediate spending of the funds. The second is to account for time to elapse before the funds are allocated.
Each contracting party holds the opposite CETs. When the time comes for the contract to be executed a verifier can execute the predetermined point. However, the outcome is unknown. This means the oracle must notify the verifier which alternative should be calculated for. This means the oracle simply signals for which transaction should occur. These transactions already exist and just need to be verified to occur.
The Funding Transaction
To ensure any contract is executed fairly, all collateral must be posted in the channel upfront. This means in a betting situation, both parties will typically contribute the amount bet into the contract. Since the contract holds both their funds it will also require both of their signatures for any transactions that occur afterward. This sounds complicated, but both of these contracting parties can use the same transaction to fund the contract. Once this transaction is created, the parties will determine the transaction ID (TxID).
You can create a contract executing transactions using this TxID. This ensures users are unable to add additional details or collateral after executing the contract. These funds are then shared in a multi-signature address. With one key from each party involved in the contract. Afterward, the contract is signed and the two involved parties wait.
Addressing Privacy Concerns
One of the major issues with the smart contract was the lack of privacy. If we remember correctly the smart contract was completely public with the contents of the contract displayed for anyone on the blockchain. While this was believed to improve security, let’s remember that each time either party wants to interact with the contract this would also be displayed.
The Discreet log contract seeks to address this issue by allowing signatures from the counter-parties and the oracle to validate the contract. Other members of the blockchain will not see evidence of the contract. Rather they will see a normal buy/sell interaction between parties.
The lightning network is another important piece to this contract. Why? Remember when we mentioned earlier that scalability is a big concern. The lightning network helps us to mitigate against this by reducing the number of records stored on the blockchain. This is done by adding another layer to the blockchain and enabling all transactions to occur on this layer. This means any transactions will happen instantaneously and fees will be virtually non-existent.
Creating this channel allows two parties to transact with each other and posting the necessary transactions to the network. This technology is utilized in a DLC although it limits the transaction to broadcasting only the channel state, reflecting the correct outcome of the bet as determined by the oracle.
Risks of A Discrete Log Contracts
Like any new technology, there are a couple of risks you should watch out for. First consider that since the funds are locked up beforehand, they can’t handle all the variations in price. In the case where transactions do not account for a given price, both parties will have to provide more funds to the existing contract.
Additionally, we now have included an oracle in our decision which means we have to put some trust in them. If the oracle doesn’t sign, you might never see the results of your contract go through. This sounds like a problem, however, using multiple oracles can provide you some security. What are the chances that none of your oracles sign?
Finally, if you wanted to switch your place in the contract with another party you might have a tiny problem with your hands. Without the counterparty signing an identical agreement with your replacement, there isn’t really a whole lot you can do about it. That said, this is a topic that has been brought up a few times in discussion and more research is believed to be in progress.
The Future of DLC’s
Let’s face it we need DLC’s in our life since they will allow more users than ever before to enter into futures contracts. This could apply to anything every day, including any pre-existing agreements. This could include the delivery of goods, services like teaching a class or legal assistance on any small business matter.
While the applications are one of the key areas for future consideration, it doesn’t account for all the potential opportunities for research. Thaddeus’ whitepaper, also brings up the point that to execute a contract you need two parties. But finding the counterparty is another story if you don’t already know who you are going into business with. Finding a decentralized method that will match counterparties that are hoping to enter into an agreement will be necessary as things become more widespread.
You’re probably wondering where you can start using your new favorite contract. The answer is pretty much everywhere. You can use a DLC for a wide variety of contracts. Currently, the most common are currency futures contracts. While this is a use we likely expected, this is far from all the potential uses. To get you started, consider that any real agreements for delivery, legal contracts or exchanging for any goods or services can also be helped to execute using a DLC.
Additionally, when applying to DeFi (decentralized finance) there is also potential to unleash contracts on hedging risks on commodities, derivatives and other financial instruments. We might even see futures contracts applied to insurance claims. Especially when it comes to receiving a payout after something goes wrong.
It’s Time To Execute
It’s hard for us to say how many people have been using DLC’s so far. This is because each DLC transaction appears the same as Lightning Network transactions on the blockchain.
You might find this comforting as this means you won’t be one of the first to let this transaction occur. This also provides a unique opportunity to incorporate the use of bitcoin (or any of our other favorite cryptocurrencies) into our day-to-day lives. Consider that many of us may be afraid to make agreements in bitcoin since the price fluctuates so frequently. After all, it is likely you might end up on the losing end of the stick. However, using a futures contract in DLC form can help you lock in the value of your offering and see the contract executed as such.