These two keyboard wizards are working together at MIT (Massachusetts Institute of Technology) under the Digital Coin Initiative.
It was at one of the events organized by this branch of MIT in 2018 to explore second layer solutions that the two developers presented their project for the first time.
The challenges of smart contracts
They begin by mentioning the challenges of implementing intelligent contracts in the financial field, i.e. their scalability, as well as the difficulty of gathering external information from the financial market. Another major challenge of smart contracts published on a public network such as Bitcoin Future is confidentiality it can be very disadvantageous for two parties to make their financial bets visible.
The main idea of a CSD is the creation of a monetary contract that specifies the distribution of funds between two parties on a contingency basis with conditions specified a priori from the formation of the contract. The result needed for the determination is controlled by an external entity independent of the contractors, either an Oracle or a combination of Oracles chosen by the parties.
The CSD has a structure similar to a 2 out of 2 multi-signature contract. Funds can only be distributed following the publication of a valid signature by the oracle who then specifies the results in it through an API (Application Programming Interface). The time of publication of these data is programmed in advance. To avoid collusion between the oracle and one of the potential contract agents, the conditions of fund distribution are not visible to the oracle.
Graphic representation of a CSD by the firm Crypto Garage
Nevertheless, the oracle is the unique link between the blockchain and the real world, so it must necessarily be a legitimate and reliable source of information. In order to mitigate the risks of corruption of an oracle, parties may decide to use several oracles at the same time and calculate the average result. This risk mitigation is currently not yet possible, but is already under development.
The Evolution of CSDs – The „Adaptors signatures“.
The first major readjustment of the CSD project was the adaptation of their general structures to allow the use of „Signature Adaptors“. This type of signature allows a scaled and more anonymous integration of the CSDs than the type of signatures previously used. In short, the „Adaptors signatures“ allow the creation of two invalid signatures by the contractors, of which only one could ultimately be validated in conjunction with the signature issued by the Oracle. This allows a unilateral resolution from a cryptographic point of view.
Obviously, the science and cryptography of „Adaptor signatures“ goes far beyond the objective of this article, which is more general in scope. For those who would like to know more, I invite you to consult these more detailed explanations made by Tari labs.
DLC’s and the Lightning Network
CSDs are mainly developed for the implementation of smart contracts directly on the first layer. So there are currently four main compatible implementations : Bitcoin-S, NDLC, Rust-DCL and CFD-DLC, aimed at achieving this goal. Respectively in order of mention, these implementations use the programming languages Scala, C#, Rust and Python. So there will be something for everyone.
This type of signature allows a scaled and more anonymous integration of the CSDs than the type of signatures previously used. In short, the „Adaptors signatures“ allow the creation of two invalid signatures by the contractors, of which only one could ultimately be validated in conjunction with the signature issued by the Oracle.
This allows a unilateral resolution from a cryptographic point of view.