DLC principle analysis and optimization considerations

Original title: "Bitlayer Core Technology: DLC and Its Optimization Considerations"

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. Therefore, DLC enables new decentralized financial applications while ensuring the security of Bitcoin deposits.

Compared with Lightning Network, DLC has the following significant advantages:

• Privacy:

  • Privacy:

    strong >DLC is superior to the Lightning Network in terms of privacy protection. Contract details are only shared between participants and will not be stored on the blockchain. In contrast, Lightning Network transactions are routed through public channels and nodes, and their information is open and transparent;

  • The complexity and flexibility of financial contracts:

  • strong>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;

    < /li>

  • Reduced counterparty risk: DLC funds are locked in multi-signature contracts and will only be released when the results of predefined events occur, reducing the risk of non-compliance by either party Contractual Risks. 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, which are a core component of the Lightning Network. Channel management is complex and resource-consuming;

  • Scalable for specific use cases Performance:The Lightning Network improves Bitcoin’s transaction throughput to a certain extent, while DLC provides better scalability in terms of 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 and the promised random number are at risk of being leaked or lost, resulting in the loss of user assets;

  < li>

  Centralized trust risk:The centralization problem of oracle machines can easily lead to denial of service attacks;

  • Decentralization cannot Key derivation:If the oracle is decentralized, the oracle node only owns the private key shard. However, decentralized oracle nodes cannot directly use BIP32 for key derivation based on private key sharding;

  • Collusion risk:If the oracle Collusion between machine nodes or collusion with participating parties still does not solve the problem of trust in the oracle machine. A reliable supervision mechanism is needed to minimize oracle trust;

  • Fixed denomination change problem:Conditional signatures need to be determined before building a contract A collection of enumerable events to construct transactions. Therefore, there will be a minimum amount limit for DLC to be used 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: bet on whether 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 assets within t time; if it is an even number, Bob wins the game and can withdraw the assets within 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 elliptic curve generator is G and the order is q.

  Key generation:The oracle, Alice and Bob independently generate their own private keys and public keys.

  • The private key of the oracle is z, the public key is Z, and the relationship Z=z⋅G is satisfied;

  • Alice’s private key is x and public key is X, satisfying the relationship X=x⋅G;

  • Bob’s private key is y and public key is Y, satisfying the relationship Y=y⋅G.

  Capital transaction: Alice and Bob create a funding transaction together, each locking 1BTC in a 2-of-2 multi-signature output. (A public key X belongs to Alice, and a public key Y belongs to Bob).

  Contract Execution Transaction:Alice and Bob create two Contract Execution Transactions (CET) for spending capital injection transactions.

  The oracle calculates the commitment

  $R:=k ⋅ G$

  Then, calculates S and S'

  $S:=R-hash(OddNumber,R) ⋅  Z,$

  $S':=R-hash(EvenNumber,R) ⋅  Z$

  Broadcast(R,S,S').

  Alice and Bob each calculate the corresponding new public key

  $PK^{Alice}:=X+ S,$

  $PK^{Bob}: =Y+ S'.$

  Settlement: When the n+k block appears, the oracle machine generates the corresponding s or s based on the hash value of the block '.

  • If the hash value of the n+kth block is an odd number, the oracle calculates and broadcasts s

  $s:=k-hash(OddNumber,R) ⋅ z$

  • If n+k If the hash value of a block is an even number, the oracle calculates and broadcasts s'

  $s':=k-hash(EvenNumber,R) ⋅ z$ < /p>

  Withdrawal:One of the participants, Alice or Bob, can withdraw assets based on s or s' broadcast by the oracle machine.

  • If the oracle broadcasts s, Alice can calculate the new private key sk^{Alice} and extract the locked 2 BTC< /p>

  $sk^{Alice}:= x + s.$

  • If The oracle broadcasts s', then Bob can calculate the new private key sk^{Bob} and extract the locked 2 BTC

  $sk^{Bob}:= y + s'.$

  Analysis:The new private key sk^{Alice} calculated by Alice and the new public key PK^{Alice} satisfy the discrete logarithm relationship

  $sk^{Alice} ⋅  G= (x+s) ⋅  G=X+S=PK^{Alice}$

  In this case, Alice’s withdrawal will success.

  Similarly, the new private key sk^{Bob} calculated by Bob and the new public key PK^{Bob} satisfy the discrete logarithm relationship

  $sk^{Bob} ⋅ G = (y+s') ⋅ G=Y+S'=PK^{Bob}$

  In this case, Bob's currency withdrawal will be successful.

  In addition, 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 so that one party can calculate the new private key and withdraw the currency 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 committed random number are crucial. If the private key of the oracle machine and the promised random number are leaked or lost, it will easily lead to the following four 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 machine is leaked, all DLC based on the private key will face fraudulent settlement risk. An attacker who steals the private key can sign any message they want, achieving complete control over the outcome of all future contracts. Furthermore, the 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 machine leaks the random number k, then in the settlement phase, regardless of the oracle machine broadcasting s or s', the attacker can calculate the private key z of the oracle machine as follows

  $z:=(k-s)/hash(OddNumber, R)$

  $z:= (k-s')/hash(EvenNumber, R)$

  If the oracle reuses the random number k, then after 2 settlements, the attacker can use the signature broadcast by the oracle according to the following four situations Solve the system of equations to find the private key z of the oracle machine,

  Case 1:

  $s_1=k-hash(OddNumber_1, R) ⋅ z$

  $s_2=k-hash(OddNumber_2, R) ⋅ z$

  Case 2:

  $s_1'=k-hash(EvenNumber_1, R) ⋅ z$< /p>

  $s_2'=k-hash(EvenNumber_2, R) ⋅ z$

  Case 3:

  $s_1=k-hash(OddNumber_1, R) ⋅ z$

  $s_2'=k-hash(EvenNumber_2, R) ⋅ z$

  Case 4:

  $s_1'=k-hash(EvenNumber_1 , R) ⋅ z$

  $s_2=k-hash(OddNumber_2, R) ⋅ z$

  (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, in order to improve the security of the oracle private key, BIP32 should be used to derive the child key 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 role of the oracle is crucial, 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 signature can realize a decentralized oracle. Schnorr threshold signatures have the following advantages:

  • Enhanced security:Through the management of decentralized keys, threshold signatures are reduced eliminates 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. No single entity has all the signing power, thus reducing the power Risks from too much concentration.

  • Improving availability: Only a certain number of oracle nodes need to agree to complete the signature, 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 needs 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 The public key fragment verifies the correctness of the signature fragment to achieve accountability. If correct, the signature fragments are accumulated to generate a complete signature.

  Therefore, Schnorr threshold signature protocol has obvious advantages in decentralized oracles that improve security, reliability, flexibility, scalability and accountability. advantage.

  3.3 Decentralization and key management coupling

  In key management technology, the oracle has a complete key z, based on the complete key z and the increment ω, using BIP32 can generate a large number of subkeys z+{ω }^{(1)} and grandchild keys 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. Each of the n oracle nodes has a private key fragment 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' for message msg', and the signature fragments σ_i' is merged into the complete signature σ '. The verifier can verify the correctness of the message signature pair (msg',σ ') using the complete public key Z. Since t+1 oracle nodes are required to jointly generate a threshold signature, it has high security.

  However, in the application scenario of decentralized oracles, the complete private key z does not appear, and BIP32 cannot be used directly for key derivation. In other words, oracle decentralization technology and key management technology cannot be directly coupled.

  The paper Distributed Key Derivation for Multi-Party Management of Blockchain Digital Assets proposes a distributed key derivation method in the threshold signature scenario. The core idea of ​​this paper is that according to the Lagrange interpolation polynomial, the private key fragment z_i and the complete private key z satisfy the following interpolation relationship

  

  Add increment ω to both sides of the above equation, the following equation is obtained

  

  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+ω, which is used to generate the sub-signature fragment, and use the corresponding sub-public key Z+ω ⋅  G Able to perform validity verification.

  However, enhanced and non-enhanced BIP32 need to be considered. Enhanced BIP32 takes the private key, chain code and path as input, calculates SHA512, and outputs the increment and sub-chain code. The non-enhanced BIP32 takes the public key, chain code and path as input, calculates SHA512, and outputs the increment and sub-chain code. In the case of threshold signature, the private key does not exist, so only non-enhanced BIP32 can be used. Or use homomorphic hash function, there is enhanced BIP32. However, the homomorphic hash function is different from SHA512 and is incompatible with the original BIP32.

  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 it needs to be done to a certain extent. Trust the oracle. Therefore, the correct behavior of the oracle machine is a major prerequisite for the operation of DLC.

  In order to distrust oracle machines, there have been studies on executing DLC ​​based on the results of n oracle machines to reduce dependence on a single oracle machine.

  • The "n-of-n" model means 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.

  • The "k-of-n" model means using n oracles to sign a contract, according to k The contract is executed based on the results of the oracle machine. If more than k oracles collude, it will affect the fair execution of the contract. In addition, when using the "k-of-n" model, the number of CETs that need to be prepared is C_n^k times that of a single oracle or the "n-of-n" model. The trust assumption is that at least k oracles among 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 n oracles participate in setting up DLC, they need to pledge in advance to build a permissionless on-chain OP game and promise not to do evil. If any oracle does 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 signed using the "k-of-n" model. Among them, the k value can even be 1. Therefore, the trust assumption is reduced to that as long as there is an honest participant in the network, the OP challenge can be launched to punish the evil oracle node.

  When settling OP-DLC based on Layer2 calculation results:

  • If the oracle uses the wrong result signature , causing Alice's interests to be damaged, Alice can use Layer2 to correctly calculate the results and challenge the OP game on the permisssionless chain where the oracle is pledged in advance. Alice wins the game, punishes the evil oracle, and makes up for the loss;

  • Similarly, 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 requires only 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:

  • Needs to be preset by CET. This means that the DLC fund settlement granularity is limited, such as the Bison network with a granularity of 0.1 BTC. There is a problem: users’ asset interaction in Layer 2 should not be limited to the fund granularity of DLC CET.

  • When Alice wants to settle her Layer2 assets, user Bob's Layer2 assets will be forced to be settled to Layer1. 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, in order to solve the above problems, this section proposes OP-DLC + BitVM dual bridge. This solution allows users to deposit and withdraw money through BitVM’s 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 given to user Alice can be spent immediately on Layer1, and in the output given 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 at Layer1. However, Bob can withdraw money on Layer 1 after the lock-in period expires.

  • If the BitVM Alliance acts as an oracle and cheats, Alice's interests will be damaged. However, Alice can challenge Bob's UTXO. If the challenge is successful, Bob's amount can be confiscated. 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, Bob’s 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 method: < /p>

  • Withdraw money through BitVM, which is advanced by BitVM operator on Layer1. The BitVM bridge assumes an honest participant in the BitVM alliance.

  • Withdraw money through a certain CET in OP-DLC, and the remaining change will be advanced by BitVM operator in Layer1. OP-DLC withdrawals will close the DLC channel, but the remaining funds in the DLC channel will be transferred to the BitVM Layer1 fund pool without forcing other Layer2 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 Bob to cooperate.

  Therefore, OP-DLC + BitVM dual bridge has the following advantages:

  • Using BitVM solves the change problem of DLC channel funds, reduces the number of CET settings, and is not affected by the granularity of CET funds;

  • Combining OP-DLC bridge and BitVM bridge, Users are provided with a variety of withdrawal and deposit channels, and change can be made at any granularity;

  • Set the BitVM alliance to Bob and the oracle, and use the OP mechanism to minimize trust in the oracle;< /p>

  • Introduce the withdrawal balance of the DLC channel into the BitVM bridge fund pool to improve fund utilization.

  4. Conclusion

  DLC appeared before the activation of Segwit v1 (Taproot), and the integration of DLC channel and Lightning Network has been implemented, and DLC It has been extended to allow continuous contracts to be updated and executed 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

  1. Specification for Discreet Log Contracts

  2. Discreet Log Contracts< /p>

  3. Scaling DLC Part1: Off-chain Discreet Log Contracts

  4. Scaling DLC ​​Part2: Free option problem with DLC

  5. Scaling DLC ​​Part3: How to avoid free option problem with DLC

  6. Lightning Network

  a>

  7. DLC on Lightning< /p>

  8. DLC Private Key Management Part 1

  9. DLC Private Key Management Part 2: The Oracle's private keys

  10. DLC Key Management Pt 3: Oracle Public Key Distribution

  11. BitVM: Compute Anything on Bitcoin

  12. BitVM 2: Permissionless Verification on Bitcoin

  13. BitVM Off-chain Bitcoin Contracts

  14. BIP32BIP44

  15. Schnorr signature

  16. FROST: Flexible Round-Optimized Schnorr Threshold Signatures

  17. A Survey of ECDSA Threshold Signing

  18. Distributed Key Derivation for Multi-Party Management of Blockchain Digital Assets

  19. Segregated Witness

  20. Optimistic Rollup

  21. Taproot

  Original link