
Simplicity: A New Language for Blockchains [pdf] - TD-Linux
https://blockstream.com/simplicity.pdf
======
adamnemecek
This field is a killer app of coq. Nowhere else do your bugs cost more while
the program size is small.

~~~
DennisP
Someone at the Ethereum Foundation is working full-time on formal
verification, and building a smart contract language to make it easier:
[https://medium.com/@pirapira/bamboo-compiler-started-
produci...](https://medium.com/@pirapira/bamboo-compiler-started-producing-
evm-bytecode-6a55e4633de9)

"Currently I’m confident I can write an interpreter of Bamboo in Coq or
Isabelle/HOL. I don’t want to expand the language much further until I write
one so that I can prove properties of Bamboo programs. Ultimately I’d like to
replace the compiler with a proven-correct one, but for that, a Bamboo
interpreter needs to exist in a theorem prover."

~~~
adamnemecek
I'm pumped cause this will popularize theorem provers and pump a lot of money
into their development. There was that Stephan Diehl talk on the front page
yesterday
[https://news.ycombinator.com/item?id=15582429](https://news.ycombinator.com/item?id=15582429)
where he concluded that it's gonna be a while before see a language based on
homotopy type theory.

He made a good argument. But these developments make me question whether
crypto wont make them popular. This "early future" is kinda amazing.

~~~
hiker
Cubical
[https://github.com/mortberg/cubicaltt](https://github.com/mortberg/cubicaltt)
is a proof of concept programming language based on constructive (cubical type
theory [https://arxiv.org/abs/1611.02108](https://arxiv.org/abs/1611.02108))
interpretation of HoTT.

Agda also added recently support for cubical paths
[https://agda.readthedocs.io/en/latest/language/cubical.html](https://agda.readthedocs.io/en/latest/language/cubical.html)
.

I'm also waiting on Lean
[https://leanprover.github.io](https://leanprover.github.io) to introduce
cubical type theory for HoTT. Version 2 of the language had HoTT based on the
univalence axiom which was dropped in version 3. With cubical type theory the
univalence axiom can be constructively proved and is no longer an axiom.

------
tw1010
What I love about all this is that it is almost entirely developed by the
community, without any central authority preventing it from going in any
particular direction. (There might be powerful players incentivizing certain
branches, but that has limited effect for a thing like this.) So despite what
critics say (and I admit to agreeing with them on some points), it just feels
like this whole thing has such a momentum and enthusiasm behind it that
_something_ really cool will come out of it within 5-10 years, no matter what
problems people point out about it at the moment.

~~~
nosuchthing
Wait what?

Blockstream's business model depends on selling services to enterprises,
that's why they keep attempting to prevent upgrades to the blocksize, to the
detriment of high fees and a clogged network.

The paper here is written by a single member employed by Blockstream.

~~~
grubles
The block size limit has been increased for a number of months now, which was
supported by everyone at Blockstream AFAIK.

>to the detriment of high fees and a clogged network.

Sigh. It is _astonishingly_ cheap to spend bitcoin right now. In fact, I paid
the absolute minimum fee (1000 satoshis, or a handful of cents) the other day.

~~~
uncletammy
> It is astonishingly cheap to spend bitcoin right now.

Yep, that's what happens when demand decreases for a good or service.

Someone put it very well the other day when they said "The only winners in the
scaling debate has been alt coins"

~~~
grubles
When the demand for a good increases, the price increases - which is why
currently a single bitcoin goes for ~$6,400.

~~~
nosuchthing
Well, hardly anyone is using it for anything other than speculating it might
be useful one day. Everyone buys and lets the coins sit and for some reason
people think this is a good useful thing to do?

Also it's quiet interesting that every major price increase, and nose dive has
been associated with multi-million dollar margin trading on Bitfinix via
Tether markets (which are suspected to be created out of thin air).

If the allegations are true, Bitcoin's price is mostly the result of a market
controlled by a single exchange, who now holds a significant percentage of the
supply.

[https://medium.com/@bitfinexed/latest](https://medium.com/@bitfinexed/latest)

~~~
grubles
It's perfectly reasonable to simply buy bitcoin and sit on it, if only for the
reason it acts as a store of value relative to unstable government currency
(eg. Venezuela, Zimbabwe).

The Bitfinex conspiracy is fun and entertaining to read about but more likely
than not the guy probably sold early and is trying to affect the markets with
FUD.

~~~
nosuchthing
The store of value is a myth, as the value requires buyers on the markets.

The unregulated exchanges are able to act in fractional reserve as they're not
required to audit their deposits. The exchanges are also able, and have been
wash trading, front running, and spoofing orders, creating a false sense of
volume and activity.

[https://i.imgur.com/ZwQ63OE.png](https://i.imgur.com/ZwQ63OE.png)

Transaction volume took a cliff dive once Chinese regulators forced exchanges
to charge per transaction.

Bitcoins are produced for a nominal value, it's not magic or limited in
supply, it's reproducible software. The same service is offered by many other
blockchain networks.

------
unboxed_type
I do appreciate the author's attempt to create a new worthy language really, I
do a research on this topic myself.

What concerns me is that the presented language is not suitable for any
practical programming. Even for the most simple smart contracts, the final
Simplicity program will be huge and unreadable due to the lack of familiar
data structures and constructs. The language resembles me some kind of lambda
calculus which is good for theoretical investigation, but not suitable for
practical stuff. I am not ready to exchange a language convenience for better
provability: it must have both issues addressed at the same time, only then
the mix will be right for an end-user.

~~~
cousin_it
Yeah. It seems equivalent in power to combinatorial logic, which is weaker
than finite state machines, which are weaker than Turing machines. In fact I
don't even understand why a blockchain language must emphasize provability.
Why not use something like LLVM IR and let compilers handle verification?

~~~
unboxed_type
>In fact I don't even understand why a blockchain language must emphasize
provability.

For two reasons:

1) A smart contract can not be changed in a BC after deployment, so it has to
be correct up-front (I am not sure if this fact is obvious for readers, so I
decided to add it).

2) A compiler is able to deduce only a limited set of properties. Actually,
the less expressive language you have, the more properties you can deduce at
compile-time.

The proposed language have chosen to be less expressive to get a higher degree
of decidability. But, in my opinion, it goes to the extreme where it becomes
no longer useful. The real thing would be to find the right intersection of
decidability and expressiveness.

~~~
cousin_it
That doesn't answer my question at all! Which of these sounds better to you:

1) Have Simplicity running on the blockchain

2) Have dumb old JS running on the blockchain, and transpile Simplicity (or
anything else) to it using formally verified tools

I think (2) is better in every way. It lets everyone choose their own tradeoff
of safety vs convenience, and leaves the door open for future advances in
verification instead of locking in Simplicity forever.

~~~
naasking
You're neglecting the vulnerabilities associated with full abstraction
failures: [http://lambda-the-ultimate.org/node/5364](http://lambda-the-
ultimate.org/node/5364)

Approaches like your (2) are unfortunately fraught with easy vulnerabilities.

~~~
cousin_it
That doesn't seem like an argument against (2). You're just making the
reasonable point that linking your code with someone else's unverified code is
a bad idea.

~~~
naasking
"Unverified code" isn't the problem, because a module could do exactly what
it's verified to do. The problem is that the underlying execution model
exposes capabilities that the high-level language cannot represent. This lets
attackers silently violate invariants that your language is supposed to
enforce.

For instance, at one point on the CLR you could throw an object of any type,
it didn't have to inherit from System.Exception. But the C# compiler required
you to inherit from System.Exception, so a properly crafted callback from a
"malicious" module could escape the your C# program's control-flow by throwing
an exception that you couldn't catch.

There are loads of full abstraction failures in the JVM and other languages.
So if your cryptocurrency VM can execute arbitrary programs, but your surface
language is a non-Turing complete language, unless you're very, very careful,
you're virtually guaranteed to introduce vulnerabilities due to full
abstraction failures.

This property is incredibly subtle, so I wouldn't discount it so easily,
particularly when there's so much money involved.

------
tbodt
Blockchain programming is fundamentally different from all other programming,
and we need a new language to handle that. "Solidity" is _far_ from solid.

~~~
kobeya
This is fundamentally different from Solidity.

~~~
tbodt
Which is what makes it better.

------
johnbender
A few thoughts/questions if the authors stop by since I can't seem to find a
link to the Coq source:

I'm curious if there is an interpreter written in Gallina that implements the
semantics? Maybe with a simulation proof (or similar)? It would be pretty
sweet to have a verified interpreter.

Also, found this in the corresponding blog post while search for the Coq
source.

> It is Turing incomplete, disallowing unbounded loops and allowing for static
> analysis

It's definitely possible (and not so hard depending) to do proofs and static
analysis of looping programs provided the specification can be encoded as an
invariant. To be fair I'm not sure what the implications of non-terminating
programs are in this setting and with respect to a specification.

~~~
netsec_burn
Stupid question, isn't this the Halting Problem?

~~~
johnbender
Not a stupid question at all!

An invariant that is true of all loop iterations is true of all loop
iterations even if the loop diverges. Again, I'm not sure what the
implications are for divergence in this setting but it doesn't prevent one
from proving loop invariants.

~~~
schoen
I keep encountering what I think is a misunderstanding of Rice's Theorem.
Rice's Theorem says no program can correctly decide any nontrivial property
for every program. However, there are programs that can correctly decide
nontrivial properties for _many_ programs! To avoid the Rice's Theorem issue,
you just need to be able to say "Don't know"/"Couldn't decide".

~~~
kobeya
The important word there was “every”.

~~~
schoen
Right, exactly! The theorem doesn't forbid the possibility of software that
decides properties of _some_ programs (including many useful properties for
many useful programs).

~~~
nullc
This frustrates me a lot too-- I view it as an example of a general peeve of
mine that people read too much into formal results often in a pretty cult like
manner.

An example I like to use is that many people seem to believe that there is no
reason to use anything other than the obvious greedy approximation algorithm
for the minimal set cover problem because of a celebrated result in
approximation theory that shows that no algorithm can achieve a better worst
case approximation gap. Last I checked, the Wikipedia article-- for example--
pushes people in that direction.

It turns out in practice, however, on many problem cases the obvious greedy
algorithm is pretty bad and simple heuristics on top of it do a LOT better.
People are mistaking worst case with "average" or "typical" case.

In the problem space we're discussing here with Simplicity though, there are
cases where undecidable isn't really an option: For example, if the consensus
rules of a system impose execution cost limits, the result of evaluating the
costs can't permit "undecidable", and so it's arguably better to work from a
framework which guarantees that it won't be by construction... rather than
attempting a game-of-operation where minor modifications to your program might
seemingly randomly knock into undecidable-land.

~~~
unboxed_type
> it's arguably better to work from a framework which guarantees that it won't
> be by construction... rather than attempting a game-of-operation where minor
> modifications to your program might seemingly randomly knock into
> undecidable-land.

I presume that a programming language is a compromise between expressiveness
and decidability. Cost estimation feature is definitely a good one until
having that feature stops you from being able to develop your business logic
in a convenient-enough manner. Regarding the latter, I am not convinced that
Simplicity is a nice fit.

------
runeks
This looks really interesting! I think purity is a perfect fit for smart
contracts, since there’s no global state to access — at least in the Bitcoin
blockchain — and side effects don’t make much sense.

Question: speaking in Haskell-terms, is this Simplicity Core language similar
to GHC Core in that it’s a typed intermediate language (not intended to be
written by programmers)?

Would be nice to see a higher-level language that compiles to, first,
Simplicity Core and then Bitcoin script — including example contracts
implemented in that language (ie. the various contracts used for Lighting
Network).

------
thinkloop
The biggest difference from Ethereum is not the lack of Turing Completeness
but:

> Maintain Bitcoin’s design of self-contained transactions whereby programs do
> not have access to any information outside the transaction.

This drastically changes the use cases, and may keep both chains
complimentary.

~~~
nullc
> This drastically changes the use cases,

I don't agree. It is possible to keep the interaction pure without any
practical loss of functionality-- a transaction still has access to its own
casual state, in particular using a technique we call covenants (which is
mentioned in the paper).

This kind of controlled state management avoids the destruction of scalablity
(no caching, no parallelism, no out of order processing, no skipping activity
when overloaded) that we've seen in other systems.

Using covenants Russel was, in earlier work, able to implement "Vaults"\-- a
kind of useful smart contract some have described as impossible in Bitcoin--
in the elements implementation of Bitcoin Script (it uses opcodes that are
currently disabled in Bitcoin) with no changes to any of the system's state
management. Part of the overall intent with Simplicity is to make this kind of
approach efficient and accessible.

------
domainkiller
doesn't feel simple :|

~~~
fnordsensei
It might refer to the objective "simple" as opposed to "complex", rather than
the subjective "easy" (as opposed to "hard").

------
udfalkso
FYI for the authors. Typo on page 3: " All Bitcoin Script operations are pure
functions of the machine state expect for the signature-verification
operations. "

And page 4: "As such, we expect it to be a target for other, higher-level,
languages to be complied to."

~~~
tbodt
They should have formally verified the paper as well as the language.

~~~
amingilani
Or, if you're lazy like me, get a subscription to grammarly.com. As a
technical publications editor I can say that it's worth every penny.

~~~
jcahill
> Or, if you're a technical publications editor, get a subscription to
> Grammarly⁽¹⁾.

[ed: you almost certainly will not achieve a net benefit from paying a
_subscription_ to an orthographic linter.]

____________________

¹ [https://grammarly.com](https://grammarly.com)

~~~
amingilani
There's a free tier too but it's definitely great for me! Where I work, we
have a policy about using perfect English in every message we send.

------
maxxxxx
For the German speakers: Omega Tau has a pretty good podcast about Ethereum
and Solidity: [http://omegataupodcast.net/265-ethereum-and-
solidity/](http://omegataupodcast.net/265-ethereum-and-solidity/)

~~~
kobeya
What does that have to do with Simplicity?

~~~
maxxxxx
Nothing :-( . I confused Solidity with Simplicity. Seems I was a little too
excited reading "language" and "blockchain". Still a good podcast though.

------
sciyoshi
Looks exciting - will need to take some time to read this in more detail. Off-
hand, will this not be able to handle ASN.1 certificates due to their Turing
completeness?

~~~
nullc
You can express reading ASN.1 certificates in Simplicity so long as you have
an additional explicit constraint on their depth.

In practice one always exists, just not explicitly, and instead
implementations will randomly fail or disagree with each other where you
exceed their hidden limits... limits which might arise out of their
construction implicitly (and depend on the user's configuration) and not even
be known to the program authors.

------
Frogolocalypse
The Reddit post also has some good discussion on it :

[https://www.reddit.com/r/Bitcoin/comments/79ohjw/bitcoindev_...](https://www.reddit.com/r/Bitcoin/comments/79ohjw/bitcoindev_simplicity_an_alternative_to_script/)

------
pankajdoharey
After reading the paper you will see why Simplicity is not the right language
for this semantics. Lisps are better fit for such tasks.

~~~
4lch3m1st
I will need to take a more careful look, mostly because it was too complex for
my understanding, but some of the code indeed look a little like Lisp.

EDIT: Why do you say that?

