Published in ·
--
The following presents a brief description of how we build and deploy smart contracts on the Ethereum blockchain.
Discovery and User Stories
At the start of any web3 project we first begin with our Discovery process. We use our Discovery process to evaluate the current state of a project as well as identify software requirements in the form of user stories. To do this we interview project stakeholders, perform necessary technical research, and map out feedback-driven iterations of the user stories. The length of Discovery depends on the current state of a project as well as its size and scope. In general it takes anywhere from two weeks (one sprint) to two months to complete Discovery.
Architecture
We then transition and map out the architecture for the smart contracts. This phase is extremely important and requires a great deal of attention and foresight. If the wrong architecture is implemented it will introduce long-term technical debt and introduce inefficiencies that often compound over time.
As we design the architecture, it’s critical we focus on storage considerations, operational complexity, logic flows, on-chain vs. off-chain functionality, use of layer 2 or sidechain solutions, and upgradability (if necessary). Most importantly, we strive to design smart contract systems that are as modular and lightweight as possible. This enables us to extend them when necessary and to mitigate against “unknown unknowns”. Lastly, because the smart contracts we build and deploy are transparent and composable, we need to ensure the architecture and system designs are intuitive and easy for other developers to build on top of.
Implementation
For implementation we use an agile scrum process that consists of two-week sprints. We kickoff each sprint with a 1-hr sprint planning meeting. There we assign user stories (i.e., tickets) and their corresponding scenarios and acceptance criteria to the engineering team to implement. Engineers will estimate how much effort they believe will be required to implement the user stories they’ve been assigned. These story point estimates are used to track sprint velocity over time. After sprint planning, we transition into daily 15-minute standups where the team shares their progress, outstanding questions, and any blockers. At the end of each sprint we have a sprint retrospective where we discuss what went well during the sprint, what could be improved and what will we commit to improve in the next sprint.
In order to monitor code quality we have a two part review process. The first phase is automated. That is, we use workflows and pipelines to perform automated linting and unit / integration tests to ensure everything is passing. We also incorporate storage and security scanners into our workflows to make sure we’re not at risk of running out of storage space, overwriting storage or introducing common security vulnerabilities (e.g.,reentrancy). We typically use tools like hardhat-storage-layout, MythX and Slither for this.
The second phase of our review process is manual. That is, the Senior Smart Contract Engineer on the project will review all pull requests, provide feedback and questions, and ensure the code is in a state that warrants merging the pull request into the master or staging branches.
Lastly, throughout the implementation process we ensure all code is well documented and conforms to the NatSpec format.
Security Audit: Preparation and Response
After the contracts have been implemented we prepare for a security audit from a trusted third party. First, we ensure all security warnings from MythX and Slither have been addressed. Then, we confirm that we have test coverage for all functionality and use cases before we deploy to testnet for manual testing. For manual testing we create a spreadsheet for each contract and list out each and every test scenario and the corresponding acceptance criteria we account for in our unit and integration tests. We then test the contracts manually through Etherscan’s interface and update the spreadsheet for each test scenario with pass or fail. After everything passes manual testing we “freeze”the codebase for the auditors and ultimately address any issues they uncover during their audit.
Deployment and Monitoring
Throughout the entire process, and in particular, after the audit is complete, we work closely with the front-end team to integrate the smart contracts with the front-end interface on testnet before ultimately deploying to mainnet. Once on mainnet we use tools like Tenderly to monitor our contracts and ensure we’re alerted if anything anomalous happens.
Then we celebrate!
