Bitlayer Research: Analysis of DLC Principles and Optimization Thoughts

2024-04-02 12:18:41

Collection

Discreet Log Contract (DLC) is a set of oracle-based contract execution schemes proposed by Tadge Dryja from MIT in 2018. DLC allows two parties to make conditional payments based on predefined conditions. The parties determine possible outcomes and pre-sign them, and use these pre-signatures to execute payments when the oracle signs the outcome. Therefore, DLC enables new decentralized financial applications while ensuring the security of Bitcoin deposits.

Original Title: 《Bitlayer Core Technology: DLC and Its Optimization Considerations》

Authors: lynndell & mutourend, Bitlayer Research Group

1. Introduction

Discreet Log Contract (DLC) is a contract execution scheme based on oracles proposed by Tadge Dryja from MIT in 2018. DLC allows two parties to make conditional payments based on predefined conditions. The parties determine possible outcomes and pre-sign, using these pre-signatures to execute payments when the oracle signs the result. Therefore, DLC enables new decentralized financial applications while ensuring the security of Bitcoin deposits.

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

Privacy: DLC offers better privacy protection than the Lightning Network, as contract details are shared only between the parties involved and are not stored on the blockchain. In contrast, Lightning Network transactions are routed through public channels and nodes, making their information 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 bets, while the Lightning Network is primarily used for fast small payments and cannot support complex applications;
Reduced Counterparty Risk: DLC funds are locked in a multi-signature contract and are only released when the outcome of a predefined event occurs, reducing the risk of either party breaching the contract. Although the Lightning Network reduces trust requirements, it still has some counterparty risk in 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, making channel management complex and resource-intensive;
Scalability for Specific Use Cases: The Lightning Network improves Bitcoin's transaction throughput to some extent, while DLC provides better scalability for complex contracts on Bitcoin.

Although DLC has significant advantages in the Bitcoin ecosystem, there are still some risks and issues, such as:

Key Risk: The oracle's private key and the committed random number are at risk of leakage or loss, leading to user asset loss;
Centralized Trust Risk: The centralization of oracles can lead to denial-of-service attacks;
Decentralization Cannot Derive Keys: If the oracle is decentralized, the oracle nodes only possess key shares. However, decentralized oracle nodes cannot directly use BIP32 for key derivation based on key shares;
Collusion Risk: If oracle nodes collude with each other or with participants, the trust issue of oracles remains unresolved. A reliable supervision mechanism is needed to minimize oracle trust;
Fixed Denomination Change Issue: Conditional signatures require a deterministic enumerable event set to construct transactions before building the contract. Therefore, using DLC for asset redistribution will have a minimum amount limit, leading to fixed denomination change issues.

To address these, this paper proposes some solutions and optimization ideas to mitigate the risks and issues of DLC and enhance the security of the Bitcoin ecosystem.

2. DLC Principles

Alice and Bob sign a betting agreement: betting whether the hash value of the n+k-th block is odd or even. If it is odd, Alice wins the game and can withdraw the assets within time t; if it is even, Bob wins the game and can withdraw the assets within time t. Using DLC, the oracle transmits the n+k-th block information to construct conditional signatures so that the correct winning party receives all assets.

Initialization: The elliptic curve generator is G, with order q.

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

The oracle's private key is z, and the public key is Z, satisfying the relation Z = z ⋅ G;
Alice's private key is x, and the public key is X, satisfying the relation X = x ⋅ G;
Bob's private key is y, and the public key is Y, satisfying the relation Y = y ⋅ G.

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

Contract Execution Transaction: Alice and Bob create two contract execution transactions (Contract Execution Transaction, CET) to spend the funding transaction.

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 their corresponding new public keys

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

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

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

If the hash value of the n+k-th block is odd, the oracle calculates and broadcasts s

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

If the hash value of the n+k-th block is even, the oracle calculates and broadcasts s'

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

Withdrawal: Either Alice or Bob can withdraw assets based on the 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

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

If the oracle broadcasts s', Bob can calculate the new private key sk^{Bob} and withdraw 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 succeed.

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 withdrawal will succeed.

Moreover, if the oracle broadcasts s, it is useful for Alice but not for Bob, as Bob cannot use it to calculate the corresponding new private key sk^{Bob}. Similarly, if the oracle broadcasts s', it is useful for Bob but not for Alice, as Alice cannot use it to calculate the corresponding new private key sk^{Alice}.

Finally, the above description omits the time lock. A time lock needs to be added so that one party can calculate the new private key and withdraw within time t. Otherwise, if the time exceeds t, the other party can use the original private key to withdraw the assets.

3. DLC Optimization

3.1 Key Management

In the DLC protocol, the oracle's private key and the committed random number are crucial. If the oracle's private key and the committed random number are leaked or lost, it can lead to the following four security issues:

(1) Oracle Loses Private Key z

If the oracle loses its private key, the DLC cannot be settled, necessitating the execution of a DLC refund contract. Therefore, the DLC protocol includes a refund transaction to prevent the oracle from losing its private key.

(2) Oracle Leaks Private Key z

If the oracle's private key is leaked, all DLCs based on that private key face the risk of fraudulent settlement. An attacker who steals the private key can sign any desired message, gaining complete control over all future contract outcomes. Furthermore, the attacker is not limited to publishing a single signed message but can also publish conflicting messages, such as simultaneously signing that the hash value of the n+k-th block is both odd and even.

(3) Oracle Leaks or Reuses Random Number k

If the oracle leaks the random number k, during the settlement phase, regardless of whether the oracle broadcasts s or s', the attacker can calculate the oracle's private key z as follows:

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

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

If the oracle reuses the random number k, after two settlements, the attacker can solve the equations based on the signatures broadcast by the oracle according to one of the following four scenarios:

Scenario 1:

$s1=k-hash(OddNumber1, R) ⋅ z$

$s2=k-hash(OddNumber2, R) ⋅ z$

Scenario 2:

$s1'=k-hash(EvenNumber1, R) ⋅ z$

$s2'=k-hash(EvenNumber2, R) ⋅ z$

Scenario 3:

$s1=k-hash(OddNumber1, R) ⋅ z$

$s2'=k-hash(EvenNumber2, R) ⋅ z$

Scenario 4:

$s1'=k-hash(EvenNumber1, R) ⋅ z$

$s2=k-hash(OddNumber2, R) ⋅ z$

(4) Oracle Loses Random Number k

If the oracle loses the random number k, the corresponding DLC cannot be settled, requiring the execution of a DLC refund contract.

Therefore, to enhance the security of the oracle's private key, sub-keys or grandchild keys should be derived using BIP32 for signing. Additionally, to enhance the security of the random number, the hash value of the private key and a counter should be used as the random number k:=hash(z, counter) to prevent random number duplication or loss.

3.2 Decentralized Oracles

In DLC, the role of the oracle is crucial, providing the key external data that determines the contract outcome. To enhance the security of these contracts, decentralized oracles are needed. Unlike centralized oracles, decentralized oracles distribute the responsibility of providing accurate and tamper-proof data across multiple independent nodes, reducing the risk of relying on a single point of failure and lowering the likelihood of manipulation or targeted attacks. Through decentralized oracles, DLC can achieve a higher degree of trustlessness and reliability, ensuring that contract execution fully depends on the objectivity of predetermined conditions.

Schnorr threshold signatures can implement decentralized oracles. Schnorr threshold signatures have the following advantages:

Enhanced Security: By decentralizing key management, threshold signatures reduce the risk of single points of failure. Even if some participants' keys are leaked or attacked, as long as the set threshold is not exceeded, the entire system remains secure.
Distributed Control: Threshold signatures achieve distributed control over key management, with no single entity holding all signing power, thereby reducing the risks associated with excessive concentration of power.
Improved Availability: Signing can be completed with the agreement of a certain number of oracle nodes, enhancing the system's flexibility and availability. 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, adapting to various security requirements and scenarios. Additionally, it is suitable for large-scale networks and has good scalability.
Accountability: Each oracle node generates signature shares based on private key shares for messages, and other participants can use the corresponding public key shares to verify the correctness of the signature shares, achieving accountability. If correct, the signature shares are aggregated to generate a complete signature.

Therefore, the Schnorr threshold signature protocol has significant advantages in decentralized oracles regarding security, reliability, flexibility, scalability, and accountability.

3.3 Coupling Decentralization and Key Management

In key management technology, the oracle possesses a complete key z, and based on the complete key z and increment ω, using BIP32, it can issue a large number of child keys z+{ω}^{(1)} and grandchild keys z+ω^{(1)}+ω^{(2)}. For different events, the oracle can use different grandchild private keys z+ω^{(1)}+ω^{(2)} to generate corresponding signatures σ for the corresponding event msg.

In the application scenario of decentralized oracles, there are n participants, and t+1 participants are needed for threshold signing. Among them, t. Each of the n oracle nodes possesses a private key share zi, i=1,…,n. These n private key shares zi correspond to a complete private key z, but the complete private key z never appears. Under the premise that the complete private key z does not appear, t+1 oracle nodes use private key shares zi, i=1,…,t+1 to generate signature shares σi', which are then combined into a complete signature σ'. The verifier can use 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 the threshold signature, it has high security.

However, in the application scenario of decentralized oracles, the complete private key z does not appear, making it impossible to directly use BIP32 for key derivation. In other words, the technology of oracle decentralization cannot be directly coupled with key management technology.

The paper Distributed Key Derivation for Multi-Party Management of Blockchain Digital Assets proposes a distributed key derivation method in the context of threshold signatures. The core idea of this paper is based on Lagrange interpolation polynomials, where the private key shares z_i and the complete private key z satisfy the following interpolation relationship:

Adding the increment ω to both sides of the equation yields the following equality:

This equality indicates that the private key share zi plus the increment ω still satisfies the interpolation relationship with the complete private key z plus the increment ω. In other words, the child private key share zi+ω and the child key z+ω satisfy the interpolation relationship. Therefore, each participant can use the private key share zi plus the increment ω to derive the child private key share zi+ω for generating child signature shares, and the corresponding child public key Z+ω ⋅ G can be used for validity verification.

However, it is necessary to consider enhanced and non-enhanced BIP32. Enhanced BIP32 takes the private key, chain code, and path as inputs, computes SHA512, and outputs the increment and child chain code. Non-enhanced BIP32 takes the public key, chain code, and path as inputs, computes SHA512, and outputs the increment and child chain code. In the case of threshold signatures, since the private key does not exist, only non-enhanced BIP32 can be used. Alternatively, a homomorphic hash function can be used, which would allow for enhanced BIP32. However, the homomorphic hash function is not compatible with SHA512 and the original BIP32.

3.4 OP-DLC: Minimizing Oracle Trust

In DLC, the contract between Alice and Bob is executed based on the results signed by the oracle, so a certain degree of trust in the oracle is required. Therefore, the correct behavior of the oracle is a major premise for the operation of DLC.

To decentralize trust in the oracle, existing research has executed DLC based on the results of n oracles, reducing reliance on a single oracle.

The "n-of-n" model indicates that contracts are signed using n oracles, and the contract is executed based on the results of all n oracles. This model requires all n oracles to be online and sign. If any oracle is offline or there is a disagreement in results, it affects the execution of the DLC contract. The trust assumption is that all n oracles are honest.

The "k-of-n" model indicates that contracts are signed using n oracles, and the contract is executed based on the results of k of those oracles. If more than k oracles collude, it affects the fair execution of the contract. Additionally, 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 of the n oracles are honest.

Increasing the number of oracles does not achieve decentralization of trust in the oracles. Because when an oracle acts maliciously, the harmed party has no on-chain recourse.

Therefore, this section proposes OP-DLC, introducing an optimistic challenge mechanism in DLC. Before participating in the setup of DLC, n oracles must stake in advance to build a permissionless on-chain OP game, committing to not act maliciously. If any oracle acts maliciously, Alice, Bob, or any other honest oracle or third-party honest observer can initiate a challenge. If the challenger wins the game, the malicious oracle is punished on-chain, losing its stake. Additionally, OP-DLC can also adopt the "k-of-n" model for signing, where k can even be 1. Thus, the trust assumption is reduced to requiring only one honest participant in the network to initiate an OP challenge to punish the malicious oracle node.

When settling OP-DLC based on Layer 2 computation results:

If the oracle signs with incorrect results, causing Alice to suffer losses, Alice can challenge the oracle's pre-staked permissionless on-chain OP game using the correct computation results from Layer 2. If Alice wins the game, the malicious oracle is punished, compensating for her losses;
Similarly, Bob, other honest oracle nodes, and third-party honest observers can also initiate challenges. However, to prevent malicious challenges, the challenger also needs to stake.

Therefore, OP-DLC enables mutual supervision among oracle nodes, minimizing trust in oracles. This mechanism requires only one honest participant, with a fault tolerance rate of 99%, effectively addressing the risk of oracle collusion.

3.5 OP-DLC + BitVM Dual Bridge

When DLC is used for cross-chain bridges, funding allocation is required during the settlement of DLC contracts:

It needs to be pre-set through CET. This means that the funding settlement granularity of DLC is limited, such as the Bison network using 0.1 BTC as granularity. The issue arises: asset interactions of users in Layer 2 should not be limited by the funding granularity of DLC CET.
When Alice wants to settle her Layer 2 assets, it forces user Bob's Layer 2 assets to also be settled to Layer 1. The issue arises: each Layer 2 user should be able to freely choose their deposits and withdrawals without being affected by other users' deposits and withdrawals.
Alice and Bob negotiate spending. The issue arises: both parties must be willing to cooperate.

Therefore, to solve the above issues, this section proposes the OP-DLC + BitVM dual bridge. This solution allows users to deposit and withdraw through BitVM's permissionless bridge, as well as through the OP-DLC mechanism, achieving arbitrary granularity change and improving 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, the CET constructed gives user Alice's output that can be immediately spent on Layer 1, while Bob's output constructs a "DLC game that Alice can participate in challenging" and sets a timelock period. When Alice wants to withdraw:

If the BitVM alliance acts as the oracle and signs correctly, Alice can withdraw on Layer 1. However, Bob can withdraw on Layer 1 after the lock period expires.
If the BitVM alliance acts as the oracle and cheats, causing Alice to suffer losses, 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 since Alice suffers losses, she has the strongest motivation to challenge.
If the BitVM alliance acts as the oracle and cheats, causing Bob to suffer losses, an honest member within the BitVM alliance can challenge the "BitVM game" to punish the cheating oracle node.

Additionally, when user Alice wants to withdraw from Layer 2, but the CET preset in the OP-DLC contract does not match the amount, Alice can choose the following ways:

Withdraw through BitVM, with the BitVM operator advancing the payment on Layer 1. The BitVM bridge assumes that there is one honest participant in the BitVM alliance.
Withdraw through a certain CET in OP-DLC, while the remaining change is advanced by the BitVM operator on Layer 1. OP-DLC withdrawals will close the DLC channel, but the remaining funds in the DLC channel will be directed to the BitVM Layer 1 fund pool, without forcing other Layer 2 users to withdraw. The trust assumption for the OP-DLC bridge is that there is one honest participant in the channel.
Alice and Bob negotiate spending without the oracle's involvement, requiring Bob's cooperation.

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

Using BitVM solves the change issue of DLC channel funds, reducing the number of CET setups, and is not affected by CET funding granularity;
Combining the OP-DLC bridge and BitVM bridge provides users with multiple deposit and withdrawal channels, allowing for arbitrary granularity change;
Setting the BitVM alliance as Bob and the oracle minimizes trust in the oracle through the OP mechanism;
Introducing the remaining withdrawal amount from the DLC channel into the BitVM bridge fund pool improves fund utilization.

4. Conclusion

DLC emerged before the activation of Segwit v1 (Taproot) and has integrated DLC channels with the Lightning Network, extending DLC to update and execute continuous contracts within the same DLC channel. With technologies such as Taproot and BitVM, more complex off-chain contract verification settlements can be achieved within DLC, while combining the OP challenge mechanism to minimize trust in oracles.

References