Thank you for your interest in this post! We’re undergoing a rebranding process, so please excuse us if some names are out of date.
This week started off with the finding of malicious code injected into a dependency of a popular open source npm package. The attacker found an inactive library, volunteered to help with the project, and published a compromised version.
This incident was further relevant to the crypto community as the malware specifically targeted Copay libraries, which are used in several Bitcoin wallets. As we all know, crypto is a very attractive spot for hackers, given the large amount of funds involved and the complete lack of legal recourse for rolling back a transaction associated with a hack or theft.
This should come as no surprise. The state of the JavaScript ecosystem is well known to be fragile, and we have had our fair share of warnings. The wonderful world of open source collaboration has a dark side when it comes to ensuring the security of the code we pull from thousands of GitHub repositories on every project we write.
But one of the advantages we have as Ethereum developers is that we are starting anew. The Ethereum ecosystem is fresh and just starting to bloom. We can take our lessons learned and make sure the open source contracts code we share is vetted and secure.
One of the main reasons why we work on Ethereum is that it is a decentralized and programmable consensus platform. Smart contracts, as a decentralized programmable platform, allow us to foster particular behaviours in the users of the networks we build, based on the mechanics we code into them. As such, we can leverage Ethereum itself as the medium where we build the missing layer of trust around code dependencies.
On this network, trust in a package can be signalled explicitly by vouching value (in the form of tokens) behind trusted code. This way, due diligence performed by a user on a piece of code they depend on can be shared with the rest of the community. Maintainers can actively stand behind their own packages or withdraw their support as they move to other projects. And security experts can become naturally drawn to the most supported projects to analyze them— and can profit from their discoveries by reaping a fair share of the value staked.
These skin-in-the-game mechanics place an economic (and reputation) value on open source code. Through them, we envision a dependency ecosystem in which the most secure code bubbles to the top and end users can be confident of the dependencies they rely upon.
This is our goal at ZeppelinOS. We propose EVM packages as the standard unit of reusable code, where code resides on the blockchain itself as actual code developers can link, not as data. And we are building a layer of economic incentives, powered by the ZEP token, for developers to vouch for their packages and the packages of others they trust, creating incentives for security researchers to sign on the security of the code they review and profit from the ones they can break.
The wheels to build this ecosystem are already in motion. We are working together with over 100 developers and security researchers vouching for dozens of EVM packages, in the context of a private beta. During this time, we will be testing, iterating, and refining the network mechanics to build the secure pool of reusable smart contract libraries that is needed.
Once we have achieved that, we can go back to other development communities and share our learnings.
So, one day, you may be able to vouch for your favourite JavaScript package using ZEP.