Original title: Bitlayer Core Technology: DLC and Its Optimization Considerations》
Original author: lynndell mutourend, Bitlayer Research Group
1 Introduction
Discreet Log Contract (DLC) is a set of oracle-based contract execution solutions proposed by Tadge Dryja of MIT in 2018. DLC allows two parties to make conditional payments based on predefined conditions. Each party determines and pre-signs possible outcomes, and uses these pre-signatures to execute the payment when an oracle signs the results. As a result, DLC enables new decentralized financial applications while keeping Bitcoin deposits safe.
Compared with the Lightning Network, DLC has the following significant advantages:
Privacy:DLC is superior to the Lightning Network in terms of privacy protection, as contract details are only shared between participants and not stored on the blockchain. In contrast, Lightning Network transactions are routed through public channels and nodes, and their information is public and transparent;
Complexity and Flexibility of Financial Contracts:DLC can create and execute complex financial contracts directly on the Bitcoin network, such as derivatives, insurance, and gambling contracts, while the Lightning Network is mainly used for fast small payments and cannot support complex applications;
Reduce counterparty risk:DLC funds are locked in a multi-signature contract and will only be released when the outcome of a predefined event occurs, reducing the risk of either party not complying with the contract. Although the Lightning Network reduces the need for trust, there is still some counterparty risk in terms of channel management and liquidity provision;
No need to manage payment channels:DLC operations do not require the creation or maintenance of payment channels, a core component of the Lightning Network. Channel management is complex and resource-intensive;
Scalability for specific use cases:The Lightning Network improves Bitcoin’s transaction throughput to a certain extent, while DLC provides better scalability for complex contracts on Bitcoin.
Although DLC has great advantages in Bitcoin ecological applications, there are still some risks and problems, such as:
Key risk:The private key of the oracle machine and the promised random number are at risk of being leaked or lost, resulting in the loss of user assets;
Centralized trust risk:The problem of oracle centralization can easily lead to denial of service attacks;
Decentralized key derivation is impossible:If the oracle is decentralized, the oracle node only owns the private key shard. However, decentralized oracle nodes cannot directly use BIP 32 for key derivation based on private key sharding;
Collusion risk:If the oracle nodes collude with each other or with participating parties, the trust issue of the oracle machine is still not solved. A reliable supervision mechanism is needed to minimize trust in oracles;
Fixed denomination change problem:Conditional signatures require a deterministic set of enumerable events before building a contract to build a transaction. Therefore, DLC will have a minimum amount limit for asset redistribution, resulting in a fixed denomination change problem.
To this end, this article proposes some solutions and optimization ideas to solve the risks and problems of DLC and improve the security of the Bitcoin ecosystem.
2.DLC principle
Alice and Bob sign a betting agreement: betting that the hash value of the n+kth block is an odd or even number. If it is an odd number, Alice wins the game and can withdraw the asset in t time; if it is an even number, Bob wins the game and can withdraw the asset in t time. Using DLC, the n+kth block information is passed through the oracle to construct a conditional signature so that the correct winner wins all assets.
initialization:The generator of the elliptic curve is G and the order is q.
Key generation:The oracle, Alice, and Bob generate their own private and public keys independently.
The private key of the oracle is z and the public key is Z, satisfying the relationship Z=z⋅G;
Alice’s private key is x and her public key is X, satisfying the relationship X=x⋅G;
Bob’s private key is y and his public key is Y, satisfying the relationship Y=y⋅G.
Capital injection transaction:Alice and Bob create a funding transaction together, each locking 1 BTC in a 2-of-2 multi-signature output (one public key X belongs to Alice, one public key Y belongs to Bob).
Contract execution transaction:Alice and Bob create two Contract Execution Transactions (CET) for spending capital injection transactions.
Oracle Computes Commitments
Then, calculate S and S
broadcast(R, S, S).
Alice and Bob each calculate the corresponding new public key
Settlement:When the n+kth block appears, the oracle generates the corresponding s or s based on the hash value of the block.
If the hash of n+k block is odd, the oracle computes and broadcasts s
If the hash value of n+k block is even, the oracle calculates and broadcasts s
Withdraw coins:One of the participants, Alice or Bob, can withdraw assets based on s or s broadcast by the oracle.
If the oracle broadcasts s, Alice can calculate the new private key sk^{Alice} and withdraw the locked 2 BTC
If the oracle broadcasts s, Bob can calculate the new private key sk^{Bob} and withdraw the locked 2 BTC
Analysis: The new private key sk^{Alice} calculated by Alice and the new public key PK^{Alice} satisfy the discrete logarithm relationship
In this case, Alices currency withdrawal will be successful.
In the same way, the new private key sk^{Bob} calculated by Bob and the new public key PK^{Bob} satisfy the discrete logarithm relationship
In this case, Bobs withdrawal will be successful.
Furthermore, if the oracle broadcasts s, it is useful to Alice but not to Bob. Because Bob cannot be used to calculate the corresponding new private key sk^{Bob}. In the same way, if the oracle broadcasts s, it is useful to Bob, but not to Alice. Because Alice cannot be used to calculate the corresponding new private key sk^{Alice}.
Finally, the above description omits time locks. A time lock needs to be added to allow one party to calculate a new private key and withdraw coins within t time. Otherwise, if the t time is exceeded, the other party can withdraw the assets using the original private key.
3.DLC optimization
3.1 Key management
In the DLC protocol, the private key of the oracle and the promised random number are crucial. If the private key of the oracle and the promised random number are leaked or lost, it will easily lead to the following 4 security problems:
(1) The oracle machine loses the private key z
If the oracle loses the private key, the DLC cannot be settled, resulting in the need to execute the DLC refund contract. Therefore, a refund transaction is set up in the DLC protocol to prevent the oracle from losing its private key.
(2) The oracle machine leaks the private key z
If the private key of the oracle is leaked, all DLC based on the private key will face the risk of fraudulent settlement. An attacker who steals the private key can sign any message they want, achieving complete control over the outcome of all future contracts. Furthermore, an attacker is not limited to publishing a single signed message, but can also publish conflicting messages, such as signing the n+kth block with odd and even hashes at the same time.
(3) The oracle machine leaks or reuses the random number k
If the oracle leaks the random number k, then during the settlement phase, regardless of whether the oracle broadcasts s or s, the attacker can calculate the oracles private key z as follows
If the oracle machine reuses the random number k, then after 2 settlements, the attacker can solve the system of equations according to the signature broadcast by the oracle machine and calculate the private key z of the oracle machine according to one of the following four situations:
Case 1:
Case 2:
Case 3:
Case 4:
(4) The oracle machine loses the random number k
If the oracle loses the random number k, the corresponding DLC cannot be settled, and the DLC refund contract needs to be executed.
Therefore, to improve the security of the oracle private key, BIP 32 should be used to derive a child or grandchild key for signature. In addition, to improve the security of the random number, the hash value k:=hash(z, counter) of the private key and counter should be used as the random number k to prevent the random number from being repeated or lost.
3.2 Decentralized Oracle
In DLC, the oracle plays a vital role, providing key external data that determines the outcome of the contract. To improve the security of these contracts, decentralized oracles are needed. Unlike centralized oracles, decentralized oracles spread the responsibility for providing accurate and tamper-proof data across multiple independent nodes, which can reduce the risk of relying on a single point of failure and reduce the possibility of manipulation or targeted attacks. Through decentralized oracles, DLC can achieve a higher degree of trustlessness and reliability, ensuring that contract execution relies entirely on the objectivity of predetermined conditions.
Schnorr threshold signatures enable decentralized oracles. Schnorr threshold signature has the following advantages:
Enhanced security:Through decentralized key management, threshold signatures reduce the risk of single points of failure. Even if the keys of some participants are leaked or attacked, the entire system is still safe as long as the set threshold is not exceeded.
Distributed control:Threshold signature realizes distributed control of key management, and no single entity has all the signing power, thus reducing the risk caused by excessive concentration of power.
Improve usability:The signature only needs to be agreed by a certain number of oracle nodes, which improves the flexibility and availability of the system. Even if some nodes are unavailable, it will not affect the reliable operation of the overall system.
Flexibility and scalability:The threshold signature protocol can set different thresholds as needed to adapt to various security requirements and scenarios. In addition, it is also suitable for large-scale networks and has good scalability.
Accountability:Each oracle node generates signature fragments for messages based on private key fragments, and other participants can use the corresponding public key fragments to verify the correctness of the signature fragments to achieve accountability. If correct, the signature fragments are accumulated to generate a complete signature.
Therefore, the Schnorr threshold signature protocol has significant advantages in decentralized oracles that improve security, reliability, flexibility, scalability, and accountability.
3.3 Coupling decentralization and key management
In the key management technology, the oracle machine has a complete key z, based on the complete key z and the increment ω, using BIP 32, it can send out a large number of sub-keys z+{ω }^{(1)} and Sun secret Key z+ω ^{( 1)}+ω ^{( 2)}. For different events, the oracle can use different grand private keys z+ω ^{(1)}+ω ^{(2)} to generate the corresponding signature σ for the corresponding event msg.
In the decentralized oracle application scenario, there are n participants, and t+1 participants are required to perform threshold signatures. Among them, t. n oracle nodes each have a private key shard z_i, i= 1,..., n. These n private key fragments z_i correspond to a complete private key z, but the complete private key z does not appear from beginning to end. Under the premise that the complete private key z does not appear, t+ 1 oracle nodes use private key fragments z_i, i= 1,..., t+ 1 to generate signature fragments σ_i and signature fragments σ_i for message msg merged into the complete signature σ. The verifier uses the complete public key Z to verify the correctness of the message signature pair (msg,σ ). Since t+ 1 oracle nodes are required to jointly generate a threshold signature, it has high security.
However, in the decentralized oracle application scenario, the complete private key z does not appear, and BIP 32 cannot be used directly for key derivation. In other words, oracle decentralization technology and key management technology cannot be directly coupled.
paperDistributed Key Derivation for Multi-Party Management of Blockchain Digital AssetsA distributed key derivation method in the threshold signature scenario is proposed.The core idea of this paper is that according to the Lagrangian interpolation polynomial, the private key fragment z_i and the complete private key z satisfy the following interpolation relationship
Adding increment ω to both sides of the above equation, we get the following equation
This equation shows that: the private key fragment z_i plus the increment ω still satisfies the interpolation relationship with the complete private key z plus the increment ω. In other words, the sub-private key fragment z_i+ω and the sub-key z+ω satisfy the interpolation relationship. Therefore, each participant can use the private key fragment z_i plus the increment ω to derive the sub-private key fragment z_i+ω for generating sub-signature fragments, and use the corresponding sub-public key Z+ω ⋅ G to perform Validity verification.
However, enhanced versus non-enhanced BIPs need to be considered 32 . Enhanced BIP 32 takes the private key, chaincode and path as input, calculates SHA 512, and outputs the delta and sub-chaincode. Non-enhanced BIP 32 takes the public key, chain code and path as input, calculates SHA 512, and outputs the delta and sub-chain code. In the case of threshold signatures, the private key does not exist, so only non-enhanced BIP 32 can be used. Or use homomorphic hash functions, there is enhanced BIP 32. However, the homomorphic hash function is different from SHA 512 and is not compatible with the original BIP 32.
3.4 OP-DLC: Minimizing Oracle Trust
In DLC, the contract between Alice and Bob is executed based on the result of the oracle signature, so the oracle needs to be trusted to a certain extent. Therefore, the correct behavior of the oracle machine is a major prerequisite for the operation of DLC.
To distrust oracles, there has been research on performing DLC based on the results of n oracles to reduce reliance on a single oracle.
"n-of-n"The model represents using n oracles to sign a contract and executing the contract based on the results of the n oracles. This model requires n oracles to all sign online. If an oracle goes offline or has disagreements about the results, it will affect the execution of the DLC contract. The trust assumption is that all n oracles are honest.
"k-of-n"The model indicates that n oracles are used to sign a contract, and the contract is executed based on the results of k oracles. If more than k oracles collude, it will affect the fair execution of the contract. Additionally, use"k-of-n"model, the number of CETs that need to be prepared is a single oracle or"n-of-n"C_n^k times of the model. The trust assumption is that at least k oracles out of n oracles are honest.
Increasing the number of oracle machines does not achieve the distrust of oracle machines. Because when the oracle does something evil, the injured party in the contract has no appeal channel on the chain.
Therefore, this section proposes OP-DLC, which introduces an optimistic challenge mechanism in DLC.Before participating in setting up DLC, n oracles need to pledge in advance to build the OP game on the permisssionless chain and promise not to do evil. If any oracle acts evil, Alice or Bob, or any other honest oracle or other third-party honest observer, can initiate a challenge. If the challenger wins the game, the evil oracle will be punished on the chain and its deposit will be forfeited. In addition, OP-DLC can also be used"k-of-n"model to sign. where k can even be 1. Therefore, the trust assumption is reduced to that as long as there is an honest participant in the network, an OP challenge can be launched to punish the evil oracle node.
When settling OP-DLC based on Layer 2 calculation results:
If the oracle uses an incorrect result signature, causing Alices interests to be damaged, Alice can use Layer 2 to correctly calculate the result and challenge the OP game on the permisssionless chain where the oracle has pledged in advance. Alice wins the game, punishes the evil oracle, and makes up for the loss;
In the same way, Bob, other honest oracle nodes, and third-party honest observers can all initiate challenges. However, to prevent malicious challenges, the challenger also needs to stake.
Therefore, OP-DLC enables oracle nodes to supervise each other, minimizing oracle trust. This mechanism only requires one honest participant and has a fault tolerance rate of 99%, which better solves the risk of oracle collusion.
3.5 OP-DLC + BitVM dual bridge
When DLC is used as a cross-chain bridge, fund allocation is required when the DLC contract is settled:
Requires pre-setup via CET. This means that the DLC’s fund settlement granularity is limited, such as the Bison network’s 0.1 BTC granularity. There is a problem: Users’ asset interactions in Layer 2 should not be limited to the funding granularity of DLC CET.
When Alice wants to settle her Layer 2 assets, user Bobs Layer 2 assets will also be forced to be settled to Layer 1. There is a problem: Each Layer 2 user should be able to freely choose to deposit and withdraw funds without being affected by the deposits and withdrawals of other users.
Alice and Bob negotiate the cost. There is a problem: both parties are required to be willing to cooperate.
Therefore, to solve the above problems, this section proposes OP-DLC + BitVM dual bridge. This solution allows users to deposit and withdraw money through BitVMs permissionless bridge, and also deposit and withdraw money through the OP-DLC mechanism, achieving change at any granularity and improving capital liquidity.
In OP-DLC, the oracle is the BitVM Alliance, Alice is an ordinary user, and Bob is the BitVM Alliance. When setting up OP-DLC, in the constructed CET, the output to user Alice can be spent immediately on Layer 1, and in the output to Bob, a DLC game that Alice can participate in the challenge is constructed and a timelock locking period is set. When Alice wants to withdraw money:
If the BitVM Alliance acts as an oracle and signs correctly, Alice can withdraw money on Layer 1. However, Bob waits for the lock-in period to expire before he can withdraw money on Layer 1.
If the BitVM Alliance acts as an oracle and cheats, Alices interests will be damaged. However, Alice can challenge Bobs UTXO. If the challenge is successful, Bobs amount can be forfeited. Note: One of the other BitVM Alliance members can also initiate a challenge, but Alice is most motivated to initiate a challenge because her interests are harmed.
If the BitVM Alliance acts as an oracle and cheats, Bobs interests will be damaged. However, an honest member of the BitVM Alliance can challenge the BitVM Game and punish cheating oracle nodes.
In addition, when user Alice wants to withdraw funds from Layer 2, but the preset CET in the OP-DLC contract does not match the amount, Alice can choose the following methods:
Withdrawal through BitVM is advanced by BitVM operator on Layer 1. The BitVM bridge assumes an honest participant in the BitVM consortium.
Withdraw money through a certain CET in OP-DLC, and the remaining change is advanced by the BitVM operator in Layer 1. OP-DLC withdrawals will close the DLC channel, but the remaining funds in the DLC channel will be transferred to the BitVM Layer 1 fund pool without forcing other Layer 2 users to withdraw funds. OP-DLC bridge trust assumes that there is an honest participant in the channel.
Alice and Bob negotiate the cost without the participation of the oracle machine, requiring Bobs cooperation.
Therefore, the OP-DLC + BitVM dual bridge has the following advantages:
Using BitVM solves the DLC channel fund change problem, reduces the number of CET settings, and is not affected by the CET fund granularity;
Combining the OP-DLC bridge and the BitVM bridge provides users with multiple withdrawal and deposit channels and change at any granularity;
Set the BitVM alliance to Bob and the oracle, and minimize the trust of the oracle through the OP mechanism;
Introduce the withdrawal balance of the DLC channel into the BitVM bridge fund pool to improve fund utilization.
4 Conclusion
The DLC appeared before the activation of Segwit v1 (Taproot), and the integration of the DLC channel with the Lightning Network has been implemented, and the DLC has been extended to update and execute continuous contracts within the same DLC channel. With the help of technologies such as Taproot and BitVM, more complex off-chain contract verification and settlement can be achieved within DLC, while combined with the OP challenge mechanism, minimization of oracle trust can be achieved.
references
IOS
Android