Solidity became such a hit phenomenon specifically because it makes people believe they can code Ethereum. After all, a smart contract isn’t that complex (it cannot be too complex, given the platform limitations)… but then, this is coupled with a language structure that is far from obvious (did you even know Solidity had pointers, and even worse, pointer arithmetic?), and a million plus one ways to mess up.
Solidity is overly complicated, full of traps that lead to insecure code, or can be exploited to write intentionally insecure, backdoored code. It doesn’t present idiomatic guidelines for code, it provides dozens of ways to solve the same simplistic task over and over, it does nothing to guide the developer’s hand, or even make them aware of what they are in the process of doing.
I’m doing a series on Vyper, the new Ethereum language, which is a gigantic leap ahead compared to Solidity, but as a general-purposed language, I still think using it should be the exception, not the norm. 90% of smart contracts on Ethereum are either (1) tokens, or (2) value stores with various locking mechanisms. There is no reason whatsoever to re-implement these in generic languages over and over.
The way this is done by others is using domain-specific languages. Chain, probably one of the most influential players in our space, has developed Ivy — a domain-specific language for the exact two use cases mentioned above. Bitcoin is getting an Ivy compiler. So I wonder, if Bitcoin has one, why don’t we have one?
I was talking to a Hyperledger guy recently, and it felt like I was back in the 90s, talking to a mainframe guy who’s only interested in “real computers”, none of these pissant PCs… Well, it turns out, his main problem with Ethereum was none other than Solidity. And I couldn’t agree with him more. If I was doing systems design for a bank, would I consider Solidity as a language I want in our stack? Fuck no. Seriously. No.
And what other options do you have if you’re working on Ethereum? (And why wouldn’t you want to work on Ethereum? Ethereum as an infrastructure is really well-built, and there’s an immense amount of R&D going into it.) Well, it turns out, there aren’t a lot of production-ready, well-maintained languages to begin with, but also we have a problem with ecosystem lock-in.
I still remember the ubiquitiously hated little “Designed for Windows 95” badge. It was on everything from games to floppy disk cases. Well, we now its equally hateful equivalent. Truffle? Designed for Solidity. Ganache? Designed for Solidity. Remix? Designed for fucking Solidity. Using any other language forces you to abandon the existing tooling, and go pedestrian. Sure, it’s not a whole lot of tooling to begin with, and last time I checked, the debugger was completely useless, but it still pisses me off.
Leave the EVM alone!!!
Seriously. It’s not its fault. Ethereum was designed with simplicity in mind. The EVM is almost as simple as a textbook Turing machine. Actually, it’s simpler. It’s the bare minimum of what you can call a processor, real or virtual.
So when new blockchain projects spring up trying to fix Solidity’s issues by replacing the EVM, I can’t help but feel a certain way. Would it be cool if EVM bytecode was more transparent to static analysis? Sure, but in an open source ecosystem it wouldn’t be a killer feature, if…
- the high level language the contract was written in was transparent to static analysis, and
- the compiler was formally audited for correctness (ie. the semantics of the output matches the input.)
The EVM and its simplicity and generality are a feature of Ethereum, not a bug. The bug is that people are using literally the world’s crappiest, most amateurish language ever for coding security-critical applications on it.
The power and limits of going domain-specific
Now I’m not saying that ditching multi-purpose languages is a goal. While I cannot see Solidity with anything but contempt, Vyper is quite cool, and for very specific tasks I see value in using LLL time to time. The weakness of Ethereum is also one of its strengths, a multi-purpose language allows for anything and everything to be developed. (Which is also why I argue for keeping the EVM itself.)
Ivy, being domain-specific, by its nature constricts its uses to a specific domain (tokenized value and transactions with it). It’s beautifully focused and fully declarative, built on verify, unlock and lock statements.
It allows for the verification of credentials and business rules, the conditional unlocking of value based on these verifications, and the locking of value for the recipient. Instead of having to implement balance handling for the n+1th time, you can actually focus on what makes your stuff different.
In Ethereum, the concept of Libraries tried to solve the issue of having to implement basic functionality again and again. It failed so spectacularly and catastrophically (due to no specific fault of the concept, but design faults of Solidity, and the horrid implementation of the Solidity Library pattern itself), that today it’s barely ever used, and raises major flags with auditors and clients when it is.
Domain specific languages, and declarative languages generally need an underlying infrastructure written in more general, and typically imperative languages. Prolog/CLP solvers tends to be written in C++. So Ivy, or other domain specific languages on Ethereum won’t be the be-all-end-all of Ethereum programming.
The infrastructure that will allow DApp developers to use these high-level and high-reliability tools will need some form of the Library concept. However, that underlyning infrastructure will need to be rock solid and secure— Parity multisig wallets have taught us at least this much. And I really cannot imagine this being done in Solidity.
