Simple is secure: Streamlining smart contract design

The deceptive simplicity of smart contracts

Smart contracts appear straightforward at first glance: business logic can be captured in a few small and concise lines, with business requirements easily translated into code. The allure of smart contracts is to permanently codify building blocks of larger systems into distinct, simple systems. While all of this is largely good and true, there is another truth: as digital ledgers continue to store high-value assets, attackers have shifted their focus to smart contracts, which act as routers or storage containers for these assets.

In an ideal world, a perfect smart contract ensures that only those who should be able to access the digital assets are able to do so. Much like an online shopper must authenticate before their purchase to ensure that only an authorised individual can access their own account, a smart contract checks an account against contract-defined roles to ensure they are allowed to execute the function they are accessing. In practice, implementations that seem secure may have pitfalls unbeknown to the smart contract’s developers. While there is inevitably some custom code in each smart contract, the entire contract does not need to be new; there are smart contract standards.

How ERCs and standards work

There are many different blockchain platforms, each with their own ecosystems and standards. One frequently used platform is Ethereum, which has well-documented standards implemented by third parties.

Ethereum sets new standards (referred to as ERCs) with feedback from the community to help provide a unified understanding and framework for smart contract and decentralised application developers to build around. This allows different parties to build unique applications and implementations that will work across applications on the network, permitting all parties followed the same ERC recommendations.

Other parties can build smart contract libraries that use these standards. Developers can carry out standards into their own applications.

Libraries and permissioning schemes

Several groups have set out to create contract libraries for the most used standards (ERC-20, ERC-721, ERC-1155, etc.). The contracts comprising these libraries are extensively tested and reviewed, with security at the forefront of their open-source implementation. In addition to common smart contract implementations, these groups have also built out role-based permissioning schemes, as well as other reusable Solidity components.

As all smart contracts inherently have unique designs and implementations that businesses require to develop their decentralised applications, there will be more code reviews and security tests for new functionality and applications. But the secure starting point provided by an open source, reviewed smart contract library cannot be overstated: it provides a cleanroom of sorts to begin design and implementation of the unique parts of our application.

Don’t build access controls from scratch

What’s the danger of diverging from security reviewed contract implementations? Why not just build our own from scratch? Many well-intentioned development teams have set out to build their own implementation of various access controls and other permissioning standards when those implementations already existed in smart contract libraries.

For simpler mechanisms with adequate testing and security review, this may be fine. However, many exploits and bugs have been found in contracts where development teams created custom implementations of access controls and other permissioning standards instead of relying on established, reviewed and open-source standards.

This should serve as a cautionary tale: when smart contract components have already been designed, are available in an open-source standard, and have received extensive security reviews and scrutiny, there is little reason to feel the need to rebuild them from scratch. For most organisations, the ultimate goal is to build new functionality that delights customers. It is possible to lean into new and exciting challenges while relying on tried-and-true mechanisms designed with security input from the larger security and blockchain communities.

Still intimidated by custom smart contract functionality and security? The final blog in this three-part series covers security and shifting to the left when developing smart contracts and dApps.

To learn more about our security and privacy solutions, contact us.