Improving Security on Ethereum

How Majoolr does it.

It has been quite a year for Ethereum as evidenced by the tremendous announcements at Devcon3. Our team is excited about small things like ethjs from Nick Dodson and big things like the virtual machine being developed by our friends Jason Teutsch and Robbie Bent at TrueBit. This year has seen the biggest ups and downs any revolution could hope for; billions of dollars invested and millions of dollars lost or stolen. Wait.. what?!? Millions of dollars lost or stolen? Is this acceptable within the Ethereum ecosystem? Absolutely not, but it’s a necessary evil to learn important lessons. So what lessons have we learned and what are we doing about it?

Insecure code will be exploited

We obtain a lot of benefits when putting applications in a distributed network. Automated changes in a shared global database has unlocked efficiency in the transfer of value never before seen in human history. Every value producing team in the ecosystem can literally mint millions of dollars of their value in a few seconds and distribute it. It’s amazing what this Ethereum thing can do, you should try it. Well…. maybe not yet, usability and scale just isn’t quite there, but we’re getting close! More importantly though is the downside to this automated machine being cloned into everyone’s device, everyone has a clear view of the systems in it.

There are no secrets in the Ethereum network, that’s the whole point. This means that anyone can look under the hood and, with the right tools, can see exactly what will happen when they make any call to any application. It works great when you need to validate that you will receive funds from someone else through an agreed upon automated means. It doesn’t seem to work so well when a keen eye notices your funds are actually available right now without question because the code is written to allow it. Probably by mistake, but written that way nonetheless.

Notice I didn’t say hacker nor did I say steal. You see, there is a certain framework of thought being developed in this system which I would say I believe in. Code is law. This seems to be the only way we can confidently move forward as a community with a consistent standard. Now I understand the difference between action and intent but the fact is, more often than not, you’re swimming in a pool of subjectivity. If the intent of a bit of logic was to keep your funds safe in a certain location within the global database, and not allow anyone to withdraw it, the code should have been written as such. If the code was written such that it allowed someone to withdraw those funds, we must assume intent in all cases in order avoid subjectivity. Yes, for those familiar, this was not the position taken by folks at a key point in time, but that was then and this is now.

What’s the point? Source code security, defining the exact intent and purpose of the logic, in the logic, is of paramount importance for all systems in Ethereum.

The ok way

Any legitimate team developing distributed applications must maintain basic coding hygiene at the very least. This includes passing contracts between developers, clear documentation, and robust testing. This meets a bare minimum standard for custom development but probably not suitable for any live application on mainnet. There could be knowledge gaps within a small group as a whole or bad practices not being checked by an outsider’s perspective.

A better way

In the wake of famous events that gave ownership of assets to unexpected accounts, security standards really picked up. Tools were developed and teams such as ConsenSys Diligence were hired to provide code audits which gave an independent expert’s perspective into the code written. These became, and still are, an important step to take when developing applications that handle real assets within the Ethereum network. There’s no telling how many vulnerabilities have been avoided by taking this precautionary step. There’s a catch with these though, a good audit takes a significant amount of expertise, attention to detail, and time to produce. The cost is high. This leads to the question, when it comes to common logic such as tokens, do we actually need independent instances of this logic requiring an audit?

The best way

The Ethereum Virtual Machine provides us the ability to develop and deploy code libraries that are shared among contracts. It is obvious to me, in a distributed ledger, with immutable code, that internal libraries should be the most abused feature of the whole thing, YET they’re not.

Let’s take the most obvious common logic for example, an ERC-20 token. ERC-20 defines a code standard which EVERY compliant token contract must have. The fact that we have independent token contracts being written, complete with all logic included, and subsequently audited tells me that there is still a lack of understanding in development circles. Majoolr has a token library deployed at 0x02d509d0af485c8da54d8aeb42c624e7d9e2eeb6 on mainnet which includes all standard ERC-20 functions. This library contract is permanently and verifiably placed at this location, check it out on etherscan. What does this mean? Never again, for the history of Ethereum does any development team need to write logic for an ERC-20 contract, they simply need to link it to this library. Currently this goes for any array utility we have available, math, tokens, multisig wallets, and yes, even crowdsales. The implementation of crowdsales using our libraries must be understood but the logic is there and deployed. To ensure you get it properly deployed you should contact us to do it ;) .

The point is libraries are highly effective and we at Majoolr have an open source repo full of them. These are completely open for inspection, testing, validation, and usage. Using what is already tested and available in a distributed network is by far the best way to ensure those pieces of your logic are good go.

We have a strong team at Majoolr and are making exciting developments. I can’t wait to share them with you in the near future. In the meantime, come holler at us in our discord!!