Brownie ❤’s Vyper
…and sneks love that chocolatey goodness, too.
A long winded preamble…
If you’ve ever written a smart contract, you probably have a few strong opinions about Solidity. It’s the language we all love to hate —syntax close enough to JavaScript to lull you into a false sense of security, but riddled with bizarre design choices and hidden gotchas. Many a developer has confidently dove in, written what appeared to be quality code, and proceeded to get absolutely rekt. But over the years we have collectively learned from our mistakes as we embraced Solidity’s peculiarities. We have constructed financial behemoths from it, placing our trust (and our life savings) in immutable and esoteric gas efficient spaghetti.
I like to think that I can write confusing Solidity with the best of them, and a lot of Brownie’s debugging capabilities are a result of my experiences. But I’ve also often wondered if maybe we’re doing it wrong? Solidity can be a powerful tool when wielded by the initiated, but there is an inverse correlation between an efficient smart contract and a readable smart contract. Be clever; but not too clever or you might lose all the funds. And when the majority of smart contracts are ERC20s or crowdsales, with simple logic handling the very real money of many people who lack an ability to read code — should we really be clever at all?
Enter Vyper 🐍
Vyper is a smart contract language focused on security, auditability, and simplicity. It is a community-driven project inspired largely by experiences that the developers have had in writing and auditing smart contracts.
The syntax and flow of Vyper is designed to maximize readability and security. To achieve this, Vyper includes features such as overflow checks, strong typing, and fixed point decimals. On the other hand, certain functionality is intentionally limited to prevent opportunities for insecure or hard-to-read code. Modifiers, inheritance, overloading, infinite-loops; these simply aren’t possible in Vyper.
“Vyper does not strive to be a 100% replacement for everything that can be done in Solidity; it will deliberately forbid things or make things harder if it deems fit to do so for the goal of increasing security.”
Ultimately, it’s about having the right tools for the job. Vyper doesn’t allow contracts to be as complex as those written in Solidity so there are some situations where it just won’t fit. But for cases where the job doesn’t require a high degree of complexity (I’m talking to you, ICO tokens), it provides more readable code with significantly less hidden pitfalls.
Love at first bite!
So I’m thrilled to announce that as of v1.4.0, Brownie offers full support for Vyper smart contracts. Tracebacks, coverage analysis, developer revert strings, stateful testing— if Brownie can do it in Solidity, it can do it in Vyper. And I’ve gotta say, I’m definitely biased but it feels pretty damn good using a Python framework on a Pythonesque smart contract language. 🐍 🐍
I’ve also been working with the Vyper team on further developing the language and compiler. Nobody is keeping score and I’m aware that coding isn’t meant to be competitive, but I’m currently #4 in commit count (suck it, Vitalik). We’re getting along so well that they even let me feature Brownie in the Vyper documentation for testing contracts.
“…but I heard the Vyper compiler is full of errors!”
The Vyper compiler is still in beta and not without issues. Unfortunately it’s had a run of bad press lately as a few prominent folks in the community decided to distance themselves from it. And while I do agree that we need to be cautious when compiling code that’s destined for immortality on our favorite blockchain, I think a sanity check is in order.
Here’s the thing: building a compiler is a big job! And it’s done by humans, those squishy pink things with a proven track record of getting stuff wrong. Regardless of if you’re using Vyper or Solidity, operating on the assumption that your compiler is bug-free is a flawed stance to take. You should always assume that the compiler might be wrong. And for this reason it is absolutely vital to have multiple layers of verification of your code before the actual deployment.
An audit is not the be-all-end-all golden stamp of error free code. Prior to external review, a well developed project will employ practices such as static analysis, thorough unit testing and fuzz testing. As a good friend of mine says, these techniques “are the holy trifecta of what makes code good enough”.
Which.. oh hey, what do you know? Brownie can help you with all of that 😎
Now go write some code!
