1. 27
  1.  

  2. 9

    It is depressing to see how far smart contracts have fallen. The original smart-contract concept would have worked fine without blockchains. Indeed, there is something of a bifurcation in the object-capability world, with some folks (Agoric) being very convinced that blockchains and smart contracts are not just compatible but meant for each other, and the rest of us being convinced that they are obviously and horribly wrong.

    In capability theory, we draw a strong distinction between unguessable references vs. unforgeable references. An unguessable reference is a bitvector, and since it is plain data, it is only hard to know because it is hard to guess. However, an unforgeable reference is constructed by the surrounding environment and cannot be reduced to mere bits. Capability theory primarily relies on unforgeability for practical security; unguessability is an acceptable risk at the edges of the system which lets us weaken our proofs to be as strong as our cryptography and privacy permit.

    And from this perspective, hopefully it’s obvious what’s wrong: all data on blockchains is, at best, unguessable, and quite a bit of it is public. We can’t extend unforgeability across networks. This means that a blockchain can’t simply host an object-capability language in a way which is compatible with invoking unforgeable privately-held capabilities.

    I don’t think that anybody involved is acting in bad faith, but they certainly do seem blind to reason because of the potential for obtaining lots of money.

    1. 3

      You are much more generous than me, then! At first one could apply “never attribute to malice what can be explained by stupidity” to some of these things, but in this decade that’s really hard to continue doing.

      1. 6

        this is crypto, it’s always both.

        Szabo’s concept of smart contracts was way more nuanced than the reality we have now, where the number one use case of his Big Idea turned out to be unregistered penny stock scams (which he’s less than thrilled about). Szabo is a computer scientist, and fully understands the engineering problems that smart contracts entail. Unfortunately, his fans didn’t listen.

    2. 6

      I’ve done a fair bit of smart contract dev on Ethereum and at the root of the problem is an impossible to resolve conflict between immutability (which leads to provable decentralization) and the limits of software development as a discipline. People will claim they have a solution to this conflict, but they are really just trading one for the other.

      Now, in addition to this core problem, Ethereum has gone and made things worse with their language being fairly unsuitable for the job. They also change the language rapidly, meaning battle tested code (the most valuable thing you have) is rendered unusable regularly.

      The end result is a very limited system, with a tendency towards worst-case-scenario bugs. That’s not to say it’s worthless, there are a couple very cool things that you couldn’t do any other way, but I’m very skeptical of grand claims beyond those core use cases.

      1. 4

        Haven’t heard anything about the buttcoin circus in ages, I honestly kinda forgot about it. It’s kinda surreal that lots of people work with cryptocurrency as their day job, while I forget that it even exists.

        ERC-777 is an updated version of the ERC-20 standard

        LOL, did they just put a… casino-sounding number instead of a sequential one on a new spec?

        It’s an incorrect function name (optionIDs instead of optionsIDs). This function unlocks liquidity in expired contracts. If it doesn’t work, funds are just forever locked

        Wait, what? Does the compiler just proceed full steam ahead if you call a nonexistent function?? Is this PHP?

        Nah, that would be actually nuts, their official tweet is a bit wrong. Actually they used options.length instead of optionIDs.length while they had options defined in outer scope. Well, still, I’m not the only one who thought of PHP :D

        Why are people iterating over lists with indexes?! Is there no for..of / iterators type thing in Solidity?!?!

        Also now that I think about it, this reminds me even more of C++, where this-> is optional, so you can easily mistype a class member name instead of a similar sounding local variable of the same type.

        1. 8

          Putting millions of (pseudo?) dollars under the control of immutable code written in what is more or less JavaScript is utterly insane. There seems to be a large supply of people to whom that is not immediately obvious.

          1. 3

            Everyone who’s on the JS-hate-bandwagon latched on to this JS comparison, but it’s completely unfair.

            “Solidity was influenced by C++, Python and JavaScript”. All three have proper iteration: for (auto x : xs), for x in xs, for (let x of xs). The Solidity examples have stuff like for (uint p = 0; p < proposals.length; p++), which makes it most inspired by… well known super safe language C, haha.

            1. 8

              I’m told (by early Ethereum guys I can’t name) that they actually wanted to use just JavaScript with added built-ins, but couldn’t make it work. So Solidity is definitely a JavaScript descendant, and more from JS than anything else. And they were absolutely targeting middling JavaScript coders with Solidity.

              Ethereum and Solidity are IMO excellent examples of “worse is better” - if you’re going to do something as self-hobbling as smart contracts, then you’re going to want provable languages, preferably not Turing-complete, preferably functional.

              But middling programmers don’t cope well with that stuff. So, give ’em something easy to use, and add free money as an incentive! And it totally worked … if inelegantly.

              There are better languages for the Ethereum Virtual Machine - but Solidity is still the overwhelming favourite, because its popularity means you can apply standard state of the art software engineering principles to it: that is, cut’n’paste’n’bodge.

              1. 4

                As I occasionally say, you can tell the difference between a salesperson and an engineer this way: the salesperson solves the easiest problem first; the engineer solves the hardest problem first.

              2. 4

                Substitute C++ or Python in my comment and it still stands. I actually can’t think of any language I’d be comfortable doing this in, but it would at least have a theorem prover.

                1. 4

                  Funnily enough, Solidity can use Why3 for verification. In 2017 the translation was “not even tested”, no idea what progress has been made.

                  Either way, the human problem is still the bigger one. You can’t force everyone to verify. Especially if currently some don’t even test.

                  1. 12

                    Some serious PL people looked at this problem years ago but the Solidity language has no defined semantics and is very unprincipled as a language. Basically all these formal verification tools are some 5% finished work that some grad student who got tasked to “do formal verification” purely as a means to pump the value of some token, and then abandoned it when they realised the problem was intractable.

                    From a larger perspective, effectively a 100% of these contracts and DeFi companies are either just gambling products or thinly veiled exit-scams so whether the code works or not isn’t really important so long as the right stakeholders get their winnings out before it blows up. David’s conclusion in the article is spot on.

            2. 1

              Actually they used options.length instead of optionIDs.length while they had options defined in outer scope.

              ah, thank you! I didn’t dive into the github to see if they’d described their “own” code correctly. Unsurprising, given they apparently just copied a pile of it. Correcting …

            3. 1

              Smart contracts are hard or impossible to alter, by design.

              There are a number of patterns for upgrading Ethereum smart contracts. They vary from the simple to the moderately less simple.

              They requires the most painstaking code review and analysis — so that you don’t lose money to an exploit.

              Absolutely.

              Decentralised Finance, or DeFi, uses chains of smart contract programs to automate complex financial transactions — so you can chain the attacks too. Unsurprisingly, it’s a continuing dumpster fire, reliably delivering comedy gold.

              None of this is anything that a competent blockchain dev would disagree with.

              Preston Byrne’s criticisms of DeFi are far more illuminating, and much shorter.