Smart Contracts

Discussion in 'Questions' started by Alexoz, Sep 1, 2016.

  1. 2017/12/15 - Decred v1.1.2 released! → Release Notes  → Downloads
  1. Alexoz

    Alexoz Member

    Hi,

    I'd like to open a topic on the smart contracts that will be attached to Decred's blockchain!

    As financial instruments added to the blockchain, they represent a real asset to the use of any blockchain applying it!

    Could the developers give us an idea of what type of smart contracts will be use with Decred?

    Smart contract code or smart legal contract?

    Thanks to explain this to the community!

    Best regards
     
  2. davecgh

    davecgh Hero Member
    Developer Organizer

    Dec 31, 2015
    642
    788
    Male
    United States
    First, I do want to point out that Decred development is not limited to the c0 devs. Thanks to its PoS component, it's completely in the hands of the stake holders what actually does and does not get accepted. I mention that because the question appears to be worded to the contrary.

    At any rate, the following is a summary of the current thoughts of c0 developers in regards to the topic.

    HIgh-level Goal

    The aim for smart contracts is to provide the tools needed to do simple smart contracts safely. Unlike some other blockchains, the aim of the smart contracts in Decred is not to provide the means to provide large, immutable smart contracts, but rather to enable certain new features and offer an easy to use and secure higher level language for contract creation. These new features could include the simple creation of things like MASTs (Merkelized abstract syntax trees), now also being created for Bitcoin, and access to global blockchain data, such as UTXOs (unspent transaction outputs) and information in block headers.

    Examples

    The purpose of these features may not immediately be clear, so here are a couple of examples:

    "Reusable" Lamport-style signatures:

    Lamport-style signatures are simple and quantum computing secure, but are not reusable. To work around this deficiency, it is possible to construct a tree of public keys corresponding to a deterministic tree of private keys. The root of the tree can then be added into the block, and then each time the user wishes to sign for a transaction output spending to the same root they can sign using a different public key after proving that a pay to the public key exists from the root.

    UTXO-based "kill switches" for pool voting rights:

    With the current stake pool set up, either the pool or the user can vote how they want to on some blockchain-related issue. It is certainly the case that current pools allow the user to select how they want to vote and casts that vote according to their selections on the user's behalf, and pools would be unwise to violate that trust because it would cause them to lose users and hence commissions. Nevertheless, there is currently no way to actually enforce pools to honor the user's selection as users are currently unable to later revoke those voting rights from the pool in the event the pool were to become malicious. In that case, both parties would have to issue conflicting votes and the end user would hope that the miner chooses theirs. On the other hand, if a smart contract had access to UTXO data, the user could effectively construct a revocable vote as follows:
    • Create an output in the blockchain for a small amount to be used as a "kill switch"
    • Create a ticket that gave the pool voting rights if and only if this kill switch output exists (i.e the output is not spent)

    With this setup, a user could then effectively revoke the voting rights from the pool by simply spending this "kill switch" output (naturally back to themselves) if the pool were to do something malicious.

    Security Considerations

    There are also many peripheral issues to worry about in terms of security for contracts with the ability to access blockchain data. Consider the case of an output that can only be spent if a certain UTXO owned by an attacker exists in the blockchain. A malicious attacker might reorganize the blockchain to not include this output on their chain, effectively preventing inclusion of the transaction and stealing money from the end user. So, clearly, there need to be rules around the maturity of contracts with global information access.

    Summary

    Smart contracts have openly been hyped for grandiose applications that could defeat previous systems of human trust and increase efficiency across diverse markets, but there's little to suggest that such applications can reliably exist and much to suggest that there are widespread security issues surrounding large, immutable smart contracts. A higher level smart contract language should give users just enough rope not to hang themselves while still providing powerful, flexible, and useful properties. That's what Decred is focusing on.
     
    jy-p and Alexoz like this.

Share This Page