Not so fast, Ethereum.

Last modified at 2020-10-02 06:38:42 +0000

In the last two years, I’ve had the privilege of interfacing with a number of projects in the Ethereum space.

I put the emphasis on projects, because that’s mostly the type of client I’ve worked with — individuals in relatively small collected groups working together on a common shared product. Occasionally these groups had some sort of corporate structure, usually some innocuous named LLC (or whatever variety may exist in the founder’s country). Some have had venture funding. But for the most part, these groups have just been random people.

That said, I was just a random person. I’ve done some work in this space prior, but the most I’ve done for business development for Bramah has been printing business cards. I think the full pack is still sitting on my desk. Maybe my mom has one. Our site didn’t have a form that actually submitted until this morning. This business has been around for 2 years, and I had still not added a title to our webpage.

So it was a bit weird to me that we started getting inbound emails. A lot of emails. So many emails I needed to start adding email filtering. My business partner and I have been largely doing other things, Bramah a topic we occasionally touch on when not full time on other projects. But the emails kept coming.

For good reason, the emails caused a bit of a stir. Digging a bit deeper into it, we saw that the entire process around smart contract security reviews seemed a bit topsy turvy. For those not in the know, security within the blockchain community is most frequently encountered through a process of code review documents, referred to as “audits” by the community and various security firms.

Now, audit is a bit of an odd word here, given most of these platforms are directly requesting the security team give a critical review of their code. There’s a process of paying between the two parties, usually with the client / customer providing some form of funds. Whether this may be sent fully at this point or held in escrow until some point in time, it really depends on the firm you’re working with. Some take crypto, some don’t. Some endorse the companies they audit, some don’t. There’s really few similarities between the larger firm beyond relatively broad adherence to some application security best practices.

But they aren’t audits, per se. No objective third party is brought in. The code itself stays objective, but reports can be incredibly subjective. Security researchers have more than once told community members to “read between the lines”, suggesting they unravel clever phrasing by the entity performing the review. Treading between the lines of endorsing a client for good security efforts and stating that they’ve done an adequate job but could do more remains a tricky balance. You don’t want to bite the hand that feeds you.

Notably, these reviewers also aren’t always companies. Some of the best research in the space has come from random bloggers. Sometimes they’re just random people in front of a GitHub repo. This is no different on the other side of the table — most of the developers remain the same. This makes diligence and filing taxes for corporations like these an absolute nightmare — sometimes all you have is a handle to go off of.

Now, don’t get me wrong. The lengths these entities go to ensure their code is secure is absolutely warranted. These contracts (self-executing programs on the blockchain) exist for a language that is still being defined. Most groups reviewing these codebases use some form of formal verification (the same sort of technology used by NASA to ensure the space shuttle can do it’s thing) — but even still, vulnerabilities are still found. Recommendations still fall short on developers, and most of our reports come with a caveat — “most of the areas of concern within this report come due to structural limitations in Solidity.”

Why?

The published contracts aren’t designed to change (well, mostly). While there’s some caveats, the premise behind smart contracts (as viewed through a very basic lens) is that a smart contract will keep doing its thing, regardless of whether or not the human in charge of the contract still exists. It can take elements of an agreement and codify them into some sort of eternal code, allowing interactions as long as the network remains alive.

It makes for a fascinating security model — and a developer nightmare. The tools mostly utilize RPC (yay!), but require a menagerie of modules and spaghetti code, sewn together by developers passionate to build the next great system — on few occasions, this code is actually supported beyond the initial launch. Those in the know got rich blazingly fast and now offer support to newcomers, cautioning of history’s tendency to repeat itself. But, as fascinating as it is — there’s one premise of blockchain that I find most exciting — I believe coined by Magoo. The gist of the thought is that blockchain and cryptocurrency is one of the few environments in security in which there’s provable risk (internet money), tangible evidence of something existing (the money is yours), and tangible evidence of a hack (the money is no longer yours).

If you mess up, that’s it. It’s over. Magoo breaks it down a bit more, but the number of teams that have recovered in this space from a hack is staggeringly low.

So Ethereum perhaps may not be the most friendly place starting off. It’s full of risk, basically on every front. But the wisdom the field grants is invaluable, and definitely something I suggest doing. In Ethereum, everything you do has an impact. Setting a variable — it costs money. Sloppy code that doesn’t optimize? Money. Passing something you shouldn’t be? Security risk. Not accounting for inherent risks in the platform? You’ve gotten hacked.

It’s a dark forest and a fascinating one. But the platform isn’t going to be getting off the ground fast. Especially not right now, with virtual yield farming platforms grinding the network to a halt. Costs are skyhigh, and as ever, both consumers and producers must exercise immense diligence to prevent compromise of their funds. Think about that idea for a second — your money getting hacked. Not the bank you use. The literal money.

Nightmare.

But a fascinating one. So for now, we’ll keep up the research. We hope you will too.

Thanks,

Jonathan