
Learned helplessness and the languages of DAO - prostoalex
https://techcrunch.com/2016/10/01/learned-helplessness-and-the-languages-of-dao/?ncid=rss&utm_source=feedburner&utm_medium=feed&utm_campaign=Feed%3A+Techcrunch+%28TechCrunch%29
======
carsongross
_And in the interim, let’s do everything we can to finally start to fix
traditional programming. It is not a quixotic dream; it actually is possible.
Once we just accept that, everything can, and I believe will, be better._

This is literally magical thinking.

Formally verifying software, being disciplined about not adding unnecessary
features, favoring simplicity over sophistication, using the tried and true
instead of The New New Thing: all of these require a huge amount of willpower
and fighting against the entire grain of the tech culture.

You will be branded a reactionary. You will be told you are stuck in the past.
The person willing to promise marketing the moon will be promoted, you will be
labeled "difficult to work with."

It's pretty black pill, but, as with our government: we are getting the
software we deserve, good and hard.

~~~
jacquesm
Think of it as an opportunity. There is an insane amount of money to be made
rescuing crashed projects built by people that were too focused on using the
latest and the greatest tech rather than actually focusing on delivering what
the customer asked, on time and within the alloted budget.

And by the time the project has crashed those promising marketing the moon
will be fired, and you'll be labeled 'the guy/gal that saved the project'.

It's a pretty easy sell at that point, assuming the company survived the
carnage.

~~~
hinkley
You will still run into a lot of sunk cost thinking, and they will assume
often that you will deliver everything the charlatans promised them.

Often it's the requirements that are the big part of the problem. Requests
that defy physics aren't unheard of. Often the customer grasp how hard it is
to change decisions in the structure after the fact. And what they have
learned from this is to demand that everything in the system be "flexible".
Which is how the giant white tower over engineered fiasco that preceded your
arrival happened in the first place.

Infinitely flexible software requires infinite test infrastructure. Nobody
teaches that, and many don't even recognize when it's happening to them. My
observations suggest that most don't learn from the mistake. they blame the
failure on the preventable mistakes in execution they imagine were under their
control and they just try harder the next time.

------
jasode
_> Everything is terrible because the fundamental tools we use are, still, so
flawed that when used they inevitably craft terrible things. This applies to
software [...] like the $150 million Ethereum DAO catastrophe._ [...] _> In
principle, code can be proved correct with formal verification._

Formal verification is not applicable to the DAO hack that lead to some humans
to decide on forking the blockchain.

Correctness in that example was in the eye of the beholder and from the
perspective of the hacker that received the digital currency, it would have
been formally verified as "correct".

~~~
ahelwer
Software correctness does not work like that. The DAO code as written allowed
the theft, yes, and indeed was fully correct with regard to its specification
- that is, itself.

Formal specification would involve writing safety properties in a higher-level
language, and a machine-checked proof that the Solidity code enforced these
properties. This ensures correctness of the Solidity code subject to
correctness of the proof checker, execution model equivalence with reality,
consistency of ZFC, etc. etc.

As you pointed out below, the safety properties validated could be irrelevant,
poorly-formed, or (as a whole) incomplete. This is true, and also
insurmountable - the chain of correctness has to start _somewhere_. Right now
we have only an idea in someone's head, then Solidity code. The gap between
the two is enormous and equivalence unverifiable. A higher-level spec greatly
reduces the size of this gap and will catch the vast majority of bugs.

~~~
jasode
_> writing safety properties in a higher-level language,_

 _> This is true, and also insurmountable - the chain of correctness has to
start somewhere. _

Exactly!

We can _shift_ the "correctness" test to correspond with the spec of the
hypothetical higher language. But, we haven't actually _solved_ for universal
correctness as it corresponds with how humans would ultimately decide what's
correct.

In other words, the following function can be (trivially) formally verified:

    
    
      int increment_by_one(int x) { return x+1;}
    

If _int_ is signed 32-bits, one could brute force the tests for all
4,294,967,295 possible inputs. If x happens to be 2,147,483,647 and depending
on the higher-level spec, one could define "correct" to abort with an error,
or simply wrap around to a negative number.

However, the standard of "correctness" for Ethereum is much higher than that.
Let's say there's an unwanted event called _Humans Will Decide To Fork
Ethereum Because Of Unforseen Solidity Behavior_ which we'll abbreviate as
HWDTFEBOUSB.

I contend the following static checker that correctly returns TRUE or FALSE is
impossible to write:

    
    
      bool HWDTFEBOUSB(string Solidity_code)
    

In the context where you mentioned "insurmountable", I believe we are using
the same frame of reference and are in agreement.

Is my insistence on universal correctness an unfair standard? I don't think so
because Ethereum creators wanted the programming code in "smart contracts" to
be the _ultimate and final arbiter_. No follies of human judgement or politics
to "pollute" the transactions. If that's the goal, just using a higher level
language as a specification language for formal verification engines _is not
enough_.

~~~
ahelwer
Ah, I see what you mean. The fork would break the execution model/reality
equivalence and thus (possibly) invalidate the verified properties. It could
also modify the Solidity code itself, as in the DAO fork. Formal verification
still provides benefit here: the proposed changes are easy to check for
backwards-compatibility breakage prior to the fork, providing a valuable
political tool to either oppose the change or require a rider contract code
fix in the fork.

I do think your requirement of universal correctness is unfair. We can
rightfully criticize the naivete or misleading marketing of Ethereum, but the
system isn't valueless despite its limitations, and formal verification
enables us to capture more of that value.

