Writing correct smart contract is hard (a recent study estimated that 3% of Ethereum contracts in the wild have some sort of security vulnerability; we all know of the DAO and Parity exploits, …). There are two main reasons for this. First and foremost developing for the blockchain is quite different than what most programmers are used to. The level of concurrency is far beyond our (von Neumann) intuition and mental models. And you can’t stop and inspect running code like you can in other systems. Taken together blockchain is closer to a physical/living system than conventional software — a fact not reflected in the tools available. Compared to other domains our tooling and programming languages are somewhere between rudimentary and bad; and a far cry from where they would need to be to augment developers and help make programming for the blockchain less alien and less error prone. In this talk we will first unpack what makes programming for the blockchain hard, and what are the most common types of vulnerabilities and their causes. Then we will look at the state of art programming language research in correctness proving and programming massively concurrent systems; and how these can be applied to programming smart contracts; revisit some technologies from the past that didn’t get traction at the time, but are nevertheless worth studying; and finishing off by trying to imagine how programming for the blockchain should, and perhaps one day will, look like.

1. Writing smart
contracts the sane way
simon@metabase.com
@sbelak

2. 94% of deployed smart
contracts are (potentially)
vulnerable*
*Zeus: Analyzing safety of smart contracts, Kalra et al., NDSS’18

3. An alien world

4. Massive concurrency

5. Non-deterministic
execution ordering

6. Live system, can’t
stop the world

7. System paradigmLanguage paradigm

9. Everything is inspectable,
no division between
runtime and IDE

10. “We shape our tools, and
thereafter our tools shape us”
— J. Culkin

11. *A Large-Scale Study of Programming Languages and Code Quality in Github, Baishakhi et al., Communications of the ACM, Vol. 60 No. 10
Relative bug propensity per programming language*

12. Language vs. tool

13. Transpilation

14. How high-level can
we go?

15. On Turing
completeness

16. Tension between privacy
and determinism

17. A web of VMs
(+DSLs)

18. Formal verification

19. Type holes

20. Property-based testing

21. github.com/trailofbits/echidna

22. Property based testing
+ Markov chain

23. Agent simulation
Adversarial reinforcement learning

24. CAD

25. Building bottom up using
a library of standardised
reusable components
(not only for code but
also economic dynamics)

26. Hot-loading — live
evolving systems

27. Introspection and
versioning everywhere

28. http://www.onyxplatform.org/jekyll/update/2017/02/08/Pyroclast-Preview-Simulation.html

29. Putting it all together
• Bottom up
• A web of small well-defined specialised VMs encapsulating state
• Library of standardised reusable components
• DSLs everywhere
• Interactive type-hole driven development
• Hot loading with versioning
• Introspection for everything
• Simulations to capture dynamics and optimize

30. Questions
simon@metabase.com
@sbelak

31. Further reading & cool projects
https://zenroom.dyne.org
https://medium.com/@laurentmt/introducing-boltzmann-85930984a159
https://docs.ivy-lang.org/bitcoin/
https://fc18.ifca.ai/preproceedings/101.pdf
https://blog.oceanprotocol.com/towards-a-practice-of-token-engineering-b02feeeff7ca
https://blockstream.com/simplicity.pdf
http://incentivai.co/
https://medium.com/level-k/flexible-upgradability-for-smart-contracts-9778d80d1638
https://medium.com/@laurentmt/introducing-boltzmann-85930984a159
https://github.com/trailofbits/echidna
http://wp.internetsociety.org/ndss/wp-content/uploads/sites/25/2018/02/ndss2018_09-1_Kalra_paper.pdf
https://github.com/b-mueller/smashing-smart-contracts/blob/master/smashing-smart-contracts-1of1.pdf
https://www.youtube.com/watch?v=IqA-mI2olFA