Web3 teams face many obstacles when trying to securely design a system. Many Web3 developers lack vital security expertise that is necessary when designing a secure system. Founders, product owners, and program managers may not be familiar with quantifying risk and risk mitigation. Additionally, hiring talent with security expertise and Web3 experience has its own challenges, and trying to retain top security teams can be prohibitively expensive. Without first-hand security experience, how can Web3 projects successfully design a system that minimizes security risks?

As mentioned in our Introduction to the Web3 SDLC blog post, the first phase of the Web3 Secure Development Life Cycle (SDLC) is Design. Before you write any code, deploy on chain, get an audit, or even think about monitoring and response, you must first design your protocol. Design lays the foundation for your Web3 project, so it is important to put time and effort into fleshing it out before you begin writing code.

Careful design is important for two reasons. System design will guide your team throughout the development process. The more effort you put into design, the smoother development will go. Design is also important for spotting flaws and other potential pitfalls early. Design flaws in your project can make development or bug fixes difficult or even impossible, with the worst-case scenario being a total refactor of your product. You want to spot design flaws before you start writing code, not during an expensive smart contract audit.

The overall goal of the Design phase of the Web3 SDLC is to provide guidelines and key concepts to consider as you plan your Web3 project. Having a plan before you start development is critical to keeping on track and avoiding the numerous security pitfalls that lie ahead as you build a protocol. This blog post will highlight several important areas to consider during design:

  • Documentation
  • Design Patterns and Architecture
  • Risk Analysis and Management

Documentation

While documentation is important at every stage of the Web3 SDLC, it is vital as you design your system. The documentation and specification for your project will guide development work on the implementation of both on-chain and off-chain components. Therefore, the higher the quality of your design docs, the easier it will be to build your project according to the specifications of your design.

Most projects begin with a whitepaper, which outlines the motivation, new or applicable mathematical models, and expected behavior of the system. As you create a whitepaper and initial design for the project, double-check your calculations and assumptions because no amount of development can fix a flawed design. Your project should have a detailed whitepaper that has ideally been peer-reviewed by individuals outside your organization.

Diagrams are another documentation tool that should be used; they help you visualize the system you will be building, and will be useful later when you build a threat model for your project. They will also be great additions to user and developer documentation once your team begins writing code. When the time comes to get an audit, diagrams are great for reducing spin-up time for auditors as they become familiar with your codebase. As you design your protocol, consider creating diagrams for system properties such as:

  • Internal and External Dependencies
  • Dataflow
  • Administrative Privilege Levels
  • User Workflows

Design Patterns and Architecture

When designing your Web3 project, there will likely be unique logic that requires the development of custom smart contracts. However, taking the time to design and architect how your system will interact with external contracts, third-party libraries, and think about how users will interact with your system is important to ensure consistent, safe behavior from your smart contracts. Additionally, evaluating what logic in your project can safely be implemented by a trusted third-party library versus what logic truly does need to be custom implemented can both save development time and help reduce the attack surface within your project. Special design considerations should be taken for more unique or complex logic in your project, such as governance components or potential upgrade logic.

It is also important to architect your Web3 project with design patterns in mind. Several Web3 code patterns draw inspiration from well-known design patterns from the traditional software world. For example, the reentrancy guard implementation uses a flag as a lock; this lock/unlock design is patterned from mutex locks, which are typically used to prevent race conditions when dealing with concurrent systems.

Risk Analysis and Management

Historically, Web3 companies are bad at assessing risk. This can be seen in the numerous Web3 centralized institutions and protocols that have gone bankrupt over the course of 2022. Poorly assessing risk, or not assessing risk at all, has consequences for everyone in Web3. Moving forward, it is vital that all current and upcoming Web3 projects learn to properly analyze the inherent risks that exist within the design, development, deployment, and post-deployment phases of a Web3 project's life cycle.

It is important for both technical and business teams of a Web3 project to consider risk. On the development side, risk comes in many forms; deciding whether to use existing libraries, creating novel logic in smart contracts, and integrating with external platforms are just some of the areas where developers will need to analyze, plan for, and manage risk. On the project management and ownership side, understanding risk is important in ensuring product fit with users. Understanding the risk tolerance of your users should help guide the overall development of your project. Poor risk assessment and management can have expensive consequences for not only your business, but your users.

Within risk analysis and management, there is also the topic of threat modeling. At a high level, threat modeling consists of identifying categories of bad actors (called threat agents), listing the potential actions threat agents can carry out and their impact, and determining the likelihood of those actions being carried out by an attacker. Threat modeling is useful at the design stage of a project, because you may uncover threats that can be eliminated by redesigning certain components of your protocol, which can save precious time and money during development. Having good documentation for your system design (architecture diagrams, library use, external interactions, and critical administrative roles) will make it easier to create a comprehensive threat model for your project. A successful threat modeling exercise will enable your team to identify the trust boundaries, security controls, threat actors, and some abuse cases for your project well before writing a single line of code.

Secure Design in Action

There are several factors to consider when designing a new system, and this blog post provides some high-level guidance to get you started. Arbitrary Execution aims to make the Web3 SDLC a comprehensive resource for all aspects of secure design. We will continue to expand upon the SDLC in the future, so make sure you're following us to get alerts when we publish new Web3 SDLC content.

Why You Can Trust Arbitrary Execution

Arbitrary Execution (AE) is an engineering-focused organization that specializes in securing decentralized technology. Our team of security researchers leverage their offensive security expertise, tactics, techniques, and hacker mindset to help secure the crypto ecosystem. In the two years since the company’s inception, Arbitrary Execution has performed more than 40 audits of Web3 protocols and projects, as well as created tools that continuously monitor the blockchain for anomalous activity. For more information on Arbitrary Execution's professional services, contact info@arbitraryexecution.com. Follow us on Twitter and LinkedIn for updates on our latest projects, including the Web3 SDLC.