Why Smart Contracts Fail: Undiscovered bugs and what we can do about them
From what I understand of DAO and the Turing Complete capability of Ethereum, the fundamental &quot;flaw&quot; in smart contracts is <i>not</i> &quot;more testing for bugs&quot;, nor &quot;more static analysis&quot;, nor &quot;case insensitive syntax&quot;. Instead, the gap that will be always there is related to Rice&#x27;s Theorem and&#x2F;or Godel Incompleteness Theorem.   E.g. you can&#x27;t take the rules of a system and use it to prove its own consistency.  The other concept that is relevant is the &quot;limits of correctness.&quot;[1]<p>Based on Godel Incompleteness &amp; Limits of Correctness, you will <i>always</i> require an outer &quot;context&quot; to verify that the smart contract did what was intended.  That outer &quot;context&quot; can&#x27;t be the Ethereum code -- it has to be humans.  Whether it&#x27;s humans in &quot;an open source council&quot;, or arbitrators, or courts.<p>In a similar example with the NASDAQ crash in 2010, they cancelled some &quot;bogus&quot; trades.[2]  NASDAQ is mostly automated by computers -- in fact, the &quot;electronic trading&quot; was its selling point over the NYSE.  Even with NASDAQ&#x27;s computer automation (this includes both the computer code inside NASDAQ and computer code of traders&#x27; computers) being a <i>weaker</i> form of &quot;smart contracts&quot;, NASDAQ still has to have humans be the final judge of which trades were &quot;correct&quot;.  Is it possible to write a NASDAQ decision tree embedded in source code that will handle <i>all</i> errors thereby eliminating the need for <i>any</i> human intervention?  I don&#x27;t believe it&#x27;s possible.<p>The idea of &quot;smart contract&quot; source code being the <i>final</i> authority is an unattainable goal.  The DAO&#x2F;Ethereum had the &quot;NASDAQ 2010 cancel trades&quot; moment by forking the code.  That decision to fork is the outer context of the &quot;smart contract&quot;.<p>In a sibling post, Animats writes,<p><i>&gt;&quot;A declarative representation with guarantees is needed.&quot;</i><p>A declarative syntax can <i>reduce</i> the bug count but it can&#x27;t eliminate them and thereby remove humans from being ultimate judge of what is a &quot;incorrect smart contract&quot;.<p>For a similar example, consider the following super simple function:<p><pre><code>  double convert_Celsius_to_Fahrenheit(double temperature)
  {
    return temperature * 9.0 &#x2F; 5.0 + 32.0;
  }
</code></pre>
According the ideals of Functional Programming, that function is referentially transparent -- it does not reference global variables and just uses what&#x27;s explicitly passed as a parameter.  Also, the operations of multiplication, division, and addition are &quot;well understood.&quot;  There is no overflow flaw because a &quot;double&quot; datatype can handle all temperatures from Kelvin absolute zero -273 to Plank Temperature of 10^38.  It doesn&#x27;t have any gotos or jumps.  It certainly looks like a &quot;zero defect bug free&quot; function.<p>So... what could go wrong with that function that could make it not work the way humans intended?  I leave that as an exercise for the reader.  (Hint: read &quot;Limits of Correctness&quot;.)<p>[1]<a href="https:&#x2F;&#x2F;www.student.cs.uwaterloo.ca&#x2F;~cs492&#x2F;11public_html&#x2F;p18-smith.pdf" rel="nofollow">https:&#x2F;&#x2F;www.student.cs.uwaterloo.ca&#x2F;~cs492&#x2F;11public_html&#x2F;p18...</a><p>[2]<a href="http:&#x2F;&#x2F;money.cnn.com&#x2F;2010&#x2F;05&#x2F;07&#x2F;markets&#x2F;explaining_wall_street_turmoil&#x2F;" rel="nofollow">http:&#x2F;&#x2F;money.cnn.com&#x2F;2010&#x2F;05&#x2F;07&#x2F;markets&#x2F;explaining_wall_stre...</a>