Discreet Log Contracts
What are Discreet Log Contracts (DLCs)?
zkDLCs are fundamentally powered by Discreet Log Contracts (DLCs), which is capable of facilitating conditional payments on Bitcoin and compatible blockchains.
By creating a DLC, two parties can form a monetary contract redistributing their funds to each other, based on preset conditions, without revealing any details of those conditions to the blockchain. The final event outcome to process the settlement is provisioned by an oracle.
The appearance of a DLC on the blockchain is no different than an ordinary multi signature output. Therefore the contract is discreet in the sense that no external observer can learn its existence or details from the public ledger.
Modified Implementation of Schnorr Signatures
Discreet Log Contracts use Schnorr signatures, but with a modified implementation.
Typical Schnoor Signatures
A typical Schnoor signature is created by a user first choosing a secret key a to compute a public key A using , the group generator: . To sign a message, the user generates a secret nonce, k and compute R = kG. R is the elliptic curve point representing a commitment to the nonce.
The user hashes together the message and public nonce to create c, the challenge: c = h(m,R) where h() is a hash function and m is the message to be signed.
The user then computes s = k - ca. The signature on m is (R,s). s is called the response (to the challenge).
To verify the signature, compute sG and check whether it is equal to R - cA. This works since sG = (k - ca)G = kG - caG = R - cA.
Schnoor Signatures in DLCs
In contrast to the usual Schnoor signature where the signature is (R,s), in DLCs, R is published as part of the public key, leaving only s as the signature.
DLC Framework
DLCs provide a framework for on-chain/off-chain stateful bitcoin contracts, relying on observations from a third-party, the oracle, to determine the contract outcome.
Imagine three parties in the contract process: Alice, Bob, and Olivia. Alice and Bob are contract counterparties, while Olivia is the oracle.
Alice and Bob do not trust each other and do not need to know any legal identifying information about each other, but they must be able to communicate over an authenticated channel, and they must be able to persistently recognize each other. Alice and Bob also must be able to receive signed broadcast messages from Olivia.
Olivia does not need to be aware of Alice and Bob, and ideally she has no contact other than broacasting information.
Assume that Alice borrow USDT on Arbitrum from Bob, and pledge BTC into a DLC as collateral. There are two possible outcomes: (i) Alice repays the borrowings and claims back her BTC or (ii) Alice is unable to repay and Bob takes her collateral as repayment.
Alice and Bob create a set of Contract Execution Transactions (CETs), which are pre-signed signatures for both potential outcomes. The CETs are constructed so that the signature on each CET one participant gives to the other is encrypted using adapter signatures. Each signature for the settlement of the contract can only be decrypted with information from the signed oracle message.
zkOracle Signing
The oracle signs messages in reaction to real-world events. Before an event occurs, the oracle advertises a public nonce that will be used to produce a signature later. The public key used for signing must be known in advance, but does not need to be unique for each event. Once the event occurred, the oracle releases a signed message over the event outcome using the previously advertised nonce and public key.
An important feature of DLC is that oracle signatures can be used without an explicit request from the contract parties, allowing parties to hide traces of their contract to the oracle:
In the above example between Alice and Bob, as the loan scenario unfolds and the outcome becomes clear, Olivia as the oracle confirms the event outcome (Alice has repaid the USDT therefore Alice can reclaim her BTC OR Alice has defaulted on the USDT therefore Bob can claim the BTC), then publishes the signature for the outcome.
Alice and Bob can now only sign the CET that sends the BTC to its rightful owner. The CETs that do not correspond to the event outcome are now obsolete, and discarded.
References: MIT Digital Currency Initiative: Discreet Log Contracts (Thaddeus Dryja) Github DLC Specs Introduction (SachinMeier) Conditional Payments on Bitcoin using Discreet Log Contracts (Lovesh Harchandani)
Last updated
