Original title: "Bitlayer Core Technology: DLC and Its Optimization Considerations"
Original article by: Mutouren Lynndell, Bitlayer Research Group
1 Introduction
Discreet Log Contract (DLC) is an oracle-based contract execution framework proposed by Tadge Dryja of MIT in 2018. DLC allows two parties to make conditional payments based on predefined conditions. The two parties predetermine the possible results and pre-sign them, and use these pre-signatures to execute the payment when the oracle signs the result. Therefore, DLC enables new decentralized financial applications while ensuring the security of Bitcoin deposits.
The previous article "Analysis of DLC Principles and Optimization Thinking" summarizes the advantages of DLC in terms of privacy protection, complex contracts, and low asset risks. It also analyzes the problems of key risk, decentralized trust risk, and collusion risk in DLC, and introduces decentralized oracles, threshold signatures, and optimistic challenge mechanisms into DLC to solve the various problems it should face. Since DLC involves three participants, namely, oracles, Alice, and Bob, the exhaustive enumeration of collusion attacks between different participants is relatively complex, resulting in relatively complex prevention strategies. Complex defense strategies are not perfect, do not conform to the principle of simplicity, and lack the beauty of simplicity.
In Bitcoin, any action of any participant needs to be implemented through UTXO. Therefore, using a consensus mechanism to ensure that UTXO is correct can resist any attack. Similarly, in DLC, any action of any participant needs to be implemented through CET (Contract Execution Transaction). Therefore, using an optimistic challenge mechanism to ensure that CET is correct can resist any attack. Specifically, after the oracle pledges 2B TC, it can sign CET. Add an optimistic challenge mechanism to CET. If CET is not challenged, or successfully responds to the challenge, CET is correct and settlement can be completed. The oracle releases the pledge and obtains the handling fee; if Oracle attempts to do evil, anyone can successfully challenge it, the CET will not be settled, the oracle loses the pledge, and the oracle can no longer sign the same CET. It conforms to the principle of simplicity and has the beauty of simplicity.
2.DLC Principle
Alice and Bob sign a betting agreement: betting on whether the hash value of the ξth block is odd or even. If it is an odd number, Alice wins the game and can withdraw the assets; if it is an even number, Bob wins the game and can withdraw the assets. Using DLC, the ξth block information is transmitted through the oracle to construct a conditional signature so that the correct winner wins all assets.
The generator of the elliptic curve is G and the order is q. The key pairs of the oracle, Alice and Bob are (z, Z), (x, X), (y, Y) respectively.
Funding Transaction (on-chain): Alice and Bob create a funding transaction together, each locking 10 BTC in a 2-of-2 multi-signature output (one public key X belonging to Alice, and one public key Y belonging to Bob).
Building CET (off-chain): Alice and Bob create CET 1 and CET 2, which are used to spend funding transactions.
The oracle computes the commitment R = k · G, then computes S and S'
S := R - hash(OddNumber, R) · Z
S' := R - hash(EvenNumber, R) · Z
Then the new public keys of Alice and Bob are as follows:
PK^{Alice} := X + S
PK^{Bob} := Y + S'.
Settlement (off-chain -> on-chain): When the ξth block is successfully generated, the oracle signs the corresponding CET 1 or CET 2 based on the hash value of the block.
If the hash is odd, the oracle signs s as follows
s := k - hash(OddNumber, R) z
Broadcast CET 1.
If the hash is even, the oracle signs s'
s' := k - hash(EvenNumber, R) z
Broadcast CET 2.
Withdraw (on-chain): If the oracle broadcasts CET 1, Alice can calculate the new private key and spend the locked 20 BTC
sk^{Alice} = x + s
If the oracle broadcasts CET 2, Bob can calculate the new private key and spend the locked 20 BTC
sk^{Bob} = y + s'
The Bitlayer research team found that any behavior in the above process needs to be implemented through CET. Therefore, it is only necessary to use an optimistic challenge mechanism to ensure that CET is correct, and it can resist any attack. The wrong CET will be challenged and not executed, while the correct CET will be executed. In addition, the oracle only needs to pay the price for malicious behavior.
When the challenge program is f(t), CET should be constructed as follows
s = k - hash(f(t), R) z.
Assume that the hash value of the ξth block is an odd number, that is, f(ξ) = OddNumber, the oracle should sign CET 1
s := k - hash(OddNumber, R) z.
However, the oracle behaved maliciously and changed the function value to Even, signing CET 2:
s' := k - hash(EvenNumber, R) z.
Therefore, any user can thwart the malicious behavior based on f(ξ) ≠ OddNumber.
3.OP-DLC 2
OP-DLC includes the following 5 provisions:
The oracle is composed of an alliance with n participants, and any member can sign CET. Only by staking 2B TC can the oracle issue a signature and earn a handling fee. If a member does something malicious, the stake will be lost. Other members can continue to sign CET to ensure that users can withdraw funds. Alice and Bob can also become oracles, and they can truly trust only themselves and minimize trust.
If the oracle acts maliciously and modifies the result, it will inevitably lead to the situation that f 1(ξ) ≠ z 1, f 2(z 1) ≠ z 2. Therefore, any participant can initiate a challenge, that is, conduct a Disprove-CET 1 transaction.
If the oracle signs CET honestly, no participant can initiate a valid Disprove transaction. After 1 week, CET can be settled correctly. In addition, the oracle receives a 0.05 BTC reward as a 1-week fund occupation of its pledged 2B TC and a handling fee for honestly signing CET.
Any participant can challenge Oracle_sign:
If Oracle_sign is honest, the Disprove-CET 1 transaction cannot be initiated, and CET settlement will be executed after 1 week. In addition, the oracle stake is unlocked and the handling fee is obtained;
If Oracle_sign is dishonest, that is, anyone successfully initiates a Disprove-CET 1 transaction and successfully spends the connector A output, the signature of the oracle will be invalid, and the staked 2B TC will be lost. In the future, the oracle will no longer be able to initiate a signature with the same result for the DLC contract, because the Settle-CET 1 that relies on the connector A output will be permanently invalid.
Challenges in OP-DLC are permissionless, meaning that any participant can monitor whether the contract in OP-DLC is executed correctly. Therefore, trust in the oracle is minimized. Compared with the Lightning Network, Alice and Bob can also be offline. Because the oracle will only settle CET with honest signatures, and malicious oracles will be challenged and punished by anyone.
advantage:
High control over assets, trust only oneself: Alice and Bob can both become oracles and sign CET. The optimistic challenge mechanism will defeat the wrong CET, so it cannot do evil. Therefore, OP-DLC allows users to trust only themselves. In BitVM, users need to act as operators and must participate in all subsequent deposits to trust only themselves. If a user only participates in a single UTXO deposit in BitVM as an operator, and the UTXO can be legally reimbursed by any other (n-1) operators, the user's future withdrawals will still need to trust other operators to advance the payment. The reimbursement authority of the BitVM Operator is locked on each single deposit UTXO.
High capital utilization: If users only trust themselves, the amount of capital required is different. In OP-DLC, users rely on themselves to withdraw funds and do not need to use an equal amount of funds to advance; while in BitVM, users need to advance an equal amount of funds and then be reimbursed. This brings greater financial pressure.
The oracle that can sign must be determined when the OP-DLC is deposited, but the user himself can also become an oracle and sign for himself.
shortcoming:
Withdrawal time takes 1 week: In essence, the funding time cost of OP-DLC and BitVM is the same. OP-DLC withdrawals require a challenge period before the funds can be obtained; if BitVM relies on users to advance funds themselves, the same amount of advance funds will also need to go through a challenge period before they can be successfully reimbursed. If BitVM relies on other operators to advance funds for quick withdrawals, it means that the funding time cost of the same amount of funds must be paid to the operator as a handling fee.
The number of signatures that need to be pre-signed increases rapidly, and is linearly related to the number of CETs. As many CETs as possible are needed to enumerate all withdrawal results.
4 Conclusion
OP-DLC introduces the optimistic challenge mechanism into CET, ensuring that the wrong CET is not settled and the corresponding malicious oracle loses the stake; ensuring that the correct CET is executed, and the oracle stake is unlocked and the handling fee is obtained. This method can resist any attack and has a simple beauty.
references
Specification for Discreet Log Contracts
Discreet Log Contracts
DLC principle analysis and optimization thinking
Optimistic Rollup
BitVM 2: Permissionless Verification on Bitcoin
