
Underhanded Solidity Coding Contest - ingve
http://u.solidity.cc/
======
serhei
It sure makes me wonder if Ethereum would do better with a less forgiving
programming language. The fact that the syntax resembles Javascript is not
reassuring, neither is the fact that the very first code snippet in "Solidity
By Example" [1] is littered with comments like this:

    
    
            // Forward the delegation as long as
            // `to` also delegated.
            // In general, such loops are very dangerous,
            // because if they run too long, they might
            // need more gas than is available in a block.
            // In this case, the delegation will not be executed,
            // but in other situations, such loops might
            // cause a contract to get "stuck" completely.
    

[1]: [https://solidity.readthedocs.io/en/develop/solidity-by-
examp...](https://solidity.readthedocs.io/en/develop/solidity-by-example.html)

In general, the easier the code is to read and the harder it is to write, the
better. (Force the programmer to think carefully, not the reader!) Anything
that gets a comment like that in the Solidity examples should at the very
least refuse to compile without the programmer adding some attention-grabbing
_UNSAFE annotation. Better, there should be mechanisms to make sure the code
is written in a way that everyone understands the consequences of e.g. running
out of gas in the middle of a function.

~~~
spopejoy
> It sure makes me wonder if Ethereum would do better with a less forgiving
> programming language.

This will be hard. While Solidity certainly has problems unto itself, some of
its insecurity comes from the EVM's design, which is almost laughably low
level and thus very hard to reason about. It certainly doesn't seem to be
informed by modern VMs like LLVM, JVM or BEAM, which know a great deal more
about the semantics of the program they're running and have things like
dispatching features. My guess is the approach was "Bitcoin with a few more
opcodes" and therefore more like a 80s-era CPU than a "VM".

As a result, the compiler is tasked with running the whole show. Add to this
the coupling of RPC to Solidity's mangle-check-and-jump dispatch approach, and
you start to see why there's been so little innovation in this area: Solidity
has a tight grip on the Ethereum ecosystem. Also, writing a compiler to this
substrate is not easy, and you're penalized for code size (there's a limit on
how big a contract can be).

I'm opinionated, as an author of a competing smart contract language
([http://kadena.io/pact](http://kadena.io/pact)) that runs in an interpreter,
is Turing-incomplete, has single-assignment variables etc etc which we think
makes a lot more sense for the kind of stylized computing you're doing on a
blockchain. We even have the ability to compile our code to SMT-LIB2 for use
with the Z3 theorem prover and will be talking more soon about our DSL for
writing proofs. Interestingly though, we find that _choosing the right domain_
for your language goes a long way towards safety AND expressiveness, so that
you're not constantly cursing your compiler/interpreter while also worrying
less about $50M exploits :)

~~~
eric_bullington
Oh awesome, glad you mentioned your project. I've actually been writing a blog
post that parallels a lot of your complaints right here about Ethereum. For
safety as well as implementation complexity, Turing completeness is a
significant disadvantage for Ethereum, and I'm sorry to see it played up by so
many as an advantage. Making a Turing-incomplete DSL need not be limiting and
inexpressive, as you clearly know (and have shown).

I was thinking about creating a functional contract DSL that Coq could extract
to. Not as familiar with Z3 and SMT solvers, but that's clearly another good
approach to safety (I think Ethereum has finally started looking at formal
verification after the DAO debacle, not sure what the status is. EDIT: looks
like they've made a good bit of progress the past few months).

What about the status of your project? I see you've bootstrapped the contract
language and a consensus protocol, do you plan on bootstrapping a P2P network?
Or have you done that already and I missed it?

~~~
spopejoy
Pact is live and in-use in enterprise settings on our permissioned blockchain
platform; you can download the interpreter which when launched with "-serve"
presents the RPC REST API, allowing you to write whole applications with just
the interpreter; indeed there's a sample "TODO MVC" app showing just how easy
this is (see [https://github.com/kadena-
io/pact/blob/master/README.md](https://github.com/kadena-
io/pact/blob/master/README.md)).

As for a public platform, stay tuned, we will have an annoucement very soon.
Suffice to say for now: any work you do using Pact will have a public chain to
run on in the very near future; you can use the O/S releases to develop Pact;
and if you have an idea about permissioned (think "B2B only") blockchain
applications, get in touch!

------
airza
There's an underhanded solidity coding contest running 24/7, it's called
'Ethereum'

------
Animats
This is why Turing-complete procedural smart contracts are a bad idea. As the
DAO debacle demonstrated in practice.

Decision tables would be better. Not as general, but understandable.

~~~
DonbunEf7
The original smart-contract language, E, is almost nothing like Solidity. To
focus on Turing-completeness, it's true that E is Turing-complete and has an
`eval()` primitive, which normally would be dangerous. However, E both comes
with sufficient tools to prove that any given instance of `eval()` is safe,
and also to limit Turing-complete behavior when needed.

Specifically, in E and Monte, we can write _auditors_ , which are objects that
can structurally prove facts about other objects. A common auditor in both
languages is `DeepFrozen`; writing `as DeepFrozen` on an E or Monte object
causes the `DeepFrozen` auditor to examine the AST of that object and prove
facts.

There's a Monte community member working on an auditor for primitive recursive
arithmetic, inspired IIUC primarily by the EVM's failings.

The DAO hack happened because of a bug class known as "plan interference" in
the object-capability world; these bugs happen because two different "plans",
or composite actions of code flow, crossed paths. In particular, a plan was
allowed to recursively call into itself without resetting its context first.
EVM makes this extremely hard to get right. E and Monte have builtin syntax
for separating elements of plans with concurrency; if you write
`obj.doStuff()` then it happens now, but `obj<-doStuff()` happens later.

So, uh, yeah. Smart contracts aren't a bad idea, but Ethereum's not very good.

~~~
Animats
That's a classic form of GUI bug. Some widget calls something which calls
something else which eventually calls the original widget, which is not in a
stable state. Classic bugs in this area involve using "save file", and then
"new folder", and then renaming some folders in a way which invalidates
something upstream.

------
bshimmin
I presume this is the Solidity they're talking about, for anyone baffled by
this:
[https://solidity.readthedocs.io/en/develop/](https://solidity.readthedocs.io/en/develop/)

------
gruez
serious question: why would any rational actor participate in this? if you
actually had an underhanded exploit, you would sneak it into an actual ICO.
sure, it would require a bit more work (thinking up a plausible purpose for
the token), but i'm sure you can partner up with someone good for that. it
would have better payoff than 10 tokens or a pass to a convention. all this
can be done anonymously and would leave the victims with little recourse,
assuming the etherum developers don't pull off another DAO "fix".

this is as opposed to the underhanded c contest, where it's much harder to
monetize an exploit, since getting access to the code and/or cashing out
requires some sort of interaction in meatspace (getting hired, then turning
the exploit into $$$ respectively).

~~~
AlphaWeaver
The same reason people participate in bug bounty programs instead of
exploiting the bugs themselves: ethics/morals are important to that person.

------
kensai
Jokes apart, the contest is actually fairly useful cause it will put some
light on the state-of-the-art evil practices that may lead to smart contracts
outsmarting (no pun intended!) their investors... ;)

------
nemild
For anyone needing context, last year I wrote a Learn X in Y about Solidity:

[https://learnxinyminutes.com/docs/solidity/](https://learnxinyminutes.com/docs/solidity/)

Please note that it is fairly old at this point (contributors welcome) - so
this is just to give you a sense of the syntax and key concepts.

------
clamprecht
"Second place prize is 10 MLN tokens from Melonport." I love it.

------
kang
While it is still not clear that turing complete scripts in blockchains are
even required, this is a clever ploy by ethereum to ride some hacker to a spot
in devcon, by giving it out as a prize. Ethereum really understands marketing
the tech sector.

