Not signed in (Sign In)

Not signed in

Want to take part in these discussions? Sign in if you have an account, or apply for one below

  • Sign in using OpenID

Discussion Tag Cloud

Vanilla 1.1.10 is a product of Lussumo. More Information: Documentation, Community Support.

Welcome to nForum
If you want to take part in these discussions either sign in now (if you have an account), apply for one now (if you don't).

nLab > Latest Changes: smart contract

Bottom of Page

1 to 5 of 5

  1.  
    • CommentRowNumber1.
    • CommentAuthorzskoda
    • CommentTimeFeb 20th 2019
    • (edited Feb 20th 2019)

    A stub created for smart contracts, primarily focus on the blockchain realization of the idea, with link to the wikipedia and smart contract (zoranskoda).

    v1, current

    • CommentRowNumber2.
    • CommentAuthorzskoda
    • CommentTimeFeb 20th 2019

    Now added a section on the languages and VM used.

    • CommentRowNumber3.
    • CommentAuthorDanil_a
    • CommentTimeFeb 21st 2019
    I think there is a bit of confusion about smart contracts with relation to blockchains. I agree with Fritz Henglein that "Smart contracts are neither" (http://hjemmesider.diku.dk/~henglein/smart-contracts-are-neither.pdf). At least Ethereum-like smart contracts (written in Solidity). Although, there is a trend to implement smart contracts as programs in functional languages (plus some machinery for inter-contract communication). The examples of such developments are: Michelson (https://www.michelson-lang.com/) for Tezos blockchain (and Liquidity http://www.liquidity-lang.org/ that compiles to Michelson), Scilla (https://scilla-lang.org/), Plutus (https://cardanodocs.com/technical/plutus/introduction/). This makes smart contracts a bit more "smart" in a sense that verification of properties becomes easier and it's harder to get things completely wrong. But this does not make them closer to "contracts", these languages are still fairly general-purpose.

    For example, what smart contracts cannot do: read data from the outer world, trigger off-chain events (of course, one can implement a "listener" for contract state, but this is not a contract responsibility), automatically execute transactions (only calls from outside of a blockchain can execute a program). This makes smart contracts more or less similar to stored procedures in databases. But of course, combining off-chain and on-chain computations, one can implement "real" smart contract that will capture certain business process/financial contract etc.
    • CommentRowNumber4.
    • CommentAuthorzskoda
    • CommentTimeFeb 21st 2019
    • (edited Feb 21st 2019)

    I agree. Indeed, I am among many who work on extending the applicability of blockchain smart contracts to off-chain events. On the other hand, thank you very much for additional references. I knew of some of them, but a couple of them are new to me.

    As far as functional languages, I had less time to list developments in those; so far they are sporadic in blockchain community usage.

    • CommentRowNumber5.
    • CommentAuthorDanil_a
    • CommentTimeFeb 21st 2019
    You are welcome, I'm glad you find some of my references useful :)

    Yes, this is true that functional languages are not very wide-spread in the blockchain community. But I think functional languages have good chances to be quite useful in this area because their semantics is well-studied. Type systems like variants of System F are expressive and yet give good safety guarantees. Moreover, some blockchains (like Tezos) directly interpret simple functional language instead of compiling it into byte-code(I guess, one can imagine something like just-in-time compilation for such languages).

    Here is another link that might be useful: https://blockstream.com/simplicity.pdf. Simplicity is a low-level Turing incomplete functional language, which can serve as a target to compile more high-level languages into it.

1 to 5 of 5

  1.