Developing a web3 project requires abiding to appropriate development background and best practices for a number of reasons:
Security: Web3 projects typically involve handling sensitive data and transactions on a decentralized platform, which can make them vulnerable to security breaches. By following proper development practices, such as secure coding practices and regular security audits, developers can ensure that the project is secure and minimize the risk of hacking and other cyber threats.
Scalability: Web3 projects are designed to operate in a decentralized environment, which means that they must be able to handle a large volume of transactions and users. Proper development practices, such as optimizing code, implementing caching, and using scalable architecture, can ensure that the project can handle a high volume of traffic and usage.
Reliability: Web3 projects must be reliable and available to users at all times. Proper development practices, such as monitoring system performance, performing regular backups, and implementing failover mechanisms, can ensure that the project is reliable and available to users.
Interoperability: Web3 projects typically involve integrating with other web3 technologies, such as smart contracts, decentralized storage, and blockchain networks. Proper development practices, such as following standard protocols and APIs, can ensure that the project is interoperable with other web3 technologies and can function correctly in a decentralized ecosystem.
Maintainability: Web3 projects are often complex and can be difficult to maintain over time. By following proper development practices, such as using version control, documenting code, and implementing automated testing, developers can ensure that the project is maintainable and can be easily updated and modified as needed.
Here Is the Step-by-Step Guide for the Development Process of a Web3 Project
🎛️Requirement Gathering
Understand the scope of the project and collect requirements from stakeholders.
The first step in any web3 project development process is to gather requirements. This involves understanding the client's needs and expectations and defining the project scope. Here are the key steps involved in requirement gathering:
- Identify the client's goals: The first step is understanding what the client wants to achieve through the project. This involves asking questions to understand the client's business model, target audience, and competition.
- Define the project scope: Once you clearly understand the client's goals, you must define the scope. This involves identifying the features and functionalities the client wants to include in the project and any constraints or limitations.
- Create a required document: Once the project scope is defined, you need to create the following Documents that outline the project's objectives, features, and functionalities. This document should serve as a blueprint for the project and guide the development team throughout the project lifecycle.
Business Process Documentation Requirements
- Description of Each Business Process in the Project
- Detailed Business Process Diagram: business process diagram will include the various steps involved in each process and the inputs and outputs of each step.
- Detailed Funding Link Diagram
Requirements Analysis Document Requirements
- A Requirements Analysis Document (RAD) for a web3 project should include a thorough description of the project, the specific problem that the project is addressing, and a security/privacy risk assessment.
- The project description should provide an overview of the web3 application, including its purpose and intended users. This should be followed by a statement of the specific problem the application aims to address, such as the limitations of centralized financial institutions or the lack of privacy in traditional online transactions.
- The security/privacy risk assessment should identify potential threats to the application's security and privacy, such as unauthorized access or data breaches. It should also outline the measures that will be implemented to mitigate these risks, such as encryption, access controls, and regular security audits.
- Overall, the RAD should clearly understand the project's goals, scope, and security/privacy requirements. It should also serve as a reference for project stakeholders throughout the development process, helping to ensure that the final product meets the project's objectives and user needs.
Development Design Documentation Requirements
- Development Design Documentation (DDD) for a web3 project should include an architectural design diagram, functional descriptions of functions in the code, a description of the relationship between the contracts in the code, and security/privacy requirements.
- The architectural design diagram should illustrate the overall structure of the web3 application, including its layers and components. This may include the front-end layer, middleware layer, and blockchain layer, as well as any smart contracts or other components that will be utilized.
- Functional descriptions of functions in the code should provide detailed explanations of how specific functions within the code will operate, including any inputs, outputs, and dependencies.
- A description of the relationship between contracts in the code should outline how different smart contracts will interact with one another to facilitate transactions and enforce business logic. This may include details on how data will be stored and retrieved, as well as how users will interact with the contracts.
- Security/privacy requirements should be integrated into the DDD at every level, from the design of the architecture to the implementation of specific functions and contracts. This may include measures such as input validation, error handling, encryption, access controls, and data minimization.
🧩Evaluation
The second step is to evaluate the project's feasibility and determine the resources required to complete it.
Here are the key steps involved in the evaluation process:
- Access the technical feasibility: The first step is to assess the project's technical feasibility. This involves analyzing the project requirements and identifying any technical challenges that may arise during the development process.
- Estimates the project costs: Once the technical feasibility is determined, you need to estimate the costs. This involves calculating the resources required to complete the project, including the development team's time, hardware, software, and other resources.
- Define the project timeline: Once the costs are estimated, you need to define the project timeline. This involves determining the project milestones and deadlines and allocating resources accordingly.
🖥️ Implementation And Development
Convert requirements into code, test it, and review it on a regular basis.
a. Documentation and Specifications
- Write clear and concise documentation for the smart contract code, including an overview of the purpose and functionality of the contract, input and output parameters for each function, and possible edge cases or limitations.
- Use a standardized documentation format like NatSpec or Doxygen to improve readability and understandability.
- Include a detailed specification document outlining the smart contract's goals, requirements, and constraints.
- Provide detailed instructions on how to interact with the smart contract, including example input and output parameters and any potential gas costs or fees.
b. Solidity Best Practices and Readability
- Correct Use of Pragma:Avoid using pragma solidity ^0.9.1 when you're setting the compiler version yourself. This can create ambiguity for verifiers regarding the version of solidity used. This pattern should only be used for library code where you're not the one compiling it. Instead, use pragma solidity 0.9.1.
- Refrain from using unexplained constants in your code. It's more effective to use constant variables that describe the value. For instance, instead of using an arbitrary number like 5000, define it as a constant:
public uint256 constant MAXIMUM_TRANSACTION_LIMIT = 5000;
- Require statements should always include an explanatory message. Instead of
❌require(numTokens < MAXIMUM_TRANSACTION_LIMIT)
✅use require(numTokens < MAXIMUM_TRANSACTION_LIMIT, “Number of tokens exceeds transaction limit”)
- Avoid Left-to-Right Character: The Unicode U+202E character, which changes the order in which text is rendered, should be avoided as it's often used for obfuscation purposes.
- Use Descriptive Variable Names, Function Names, and Comments
- Avoid ambiguous names like mapping3 or data. Ensure that variable and function names are precise, accurate, and descriptive. For example, instead of naming a variable as 'data', name it as 'transactionData'. Also, flag any inaccurate or outdated comments.
- Unused variables can hinder readability. Although the tools mentioned above will catch this, it's important to avoid them. For example, if a variable 'unusedVar' is declared but not used anywhere in the code, it should be removed.
- Proper Use of Readability Keywords (hours, days, ether, 1_000_000, etc.) In Solidity, 1 days will automatically convert to 86400 seconds, which is much more readable. Similarly, use 1_000_000 over 1000000 for readability. When dealing with Ethereum quantities, use the ether keyword. For example, instead of writing 1000000000000000000, write 1 ether.
- Proper Use of Readability Keywords (hours, days, ether, 1_000_000, etc.) In Solidity, 1 days will automatically convert to 86400 seconds, which is much more readable. Similarly, use 1_000_000 over 1000000 for readability. When dealing with Ethereum quantities, use the ether keyword. For example, instead of writing 1000000000000000000, write 1 ether.
- Use Inclusive Language in Naming. While it's not about being politically correct, it's important to remember that your code is stored indefinitely and can be read by anyone worldwide. Therefore, exercise decency, politeness, and respect in your naming conventions. Avoid using offensive or derogatory terms in your code.
c. On-Chain vs Off-Chain Computation
- Consider using off-chain computation to minimize gas usage and improve performance.
- Use a suitable off-chain computation mechanism, such as an oracle or external API, to provide real-time data to the smart contract.
- Use on-chain computation only when necessary, such as when executing critical functions that require the security and immutability of the blockchain.
d. Upgradeability
- Implement upgradeability mechanisms to allow for future updates and improvements to the smart contract.
- Use a proxy or delegate contract to separate the contract logic from the contract data, allowing for upgrades without affecting the data.
- Use a versioning system to track changes to the contract and ensure compatibility with existing deployments.
- Implement a governance mechanism to ensure that upgrades and changes are approved by all relevant parties and comply with the requirements of the smart contract.
Development - Aim for simplicity. Always choose the simplest solution that serves your needs. Your solution should be understandable to any member of your team.
e. Function Composition
Use function composition to break down complex functionality into smaller, reusable functions.
Use the
internalvisibility modifier for functions that are intended to be used only within the contract, andpublicorexternalfor functions that can be accessed outside the contract.Use
vieworpurefunctions for read-only functionality that does not modify the state of the contract, to minimize gas usage.Ensure that composed functions are properly validated and tested to avoid potential vulnerabilities.
f. Inheritance
Use inheritance to simplify and modularize contract code.
Use the
iskeyword to indicate that a contract inherits from another contract.Implement abstract contracts to provide a template for child contracts to follow.
Avoid deep inheritance chains, which can make the codebase difficult to manage and increase the risk of bugs or vulnerabilities.
Ensure the child contract's implementation follows the requirements and constraints specified in the parent contract.
g. Events:
Use events to record contract activity and allow for off-chain monitoring and analysis.
Use the
emitkeyword to trigger an event in Solidity.Define the event parameters and their types in the contract to provide a clear and standardized event format.
Use events to provide feedback to users on the status of contract transactions or state changes.
Ensure that events are properly validated and tested to avoid potential vulnerabilities.
h. Avoid Known Pitfalls
Use dependencies like external libraries or APIs to simplify and modularize contract code.
Use the latest version of the Solidity programming language and keep up to date with any security-related updates or bug fixes.
Ensure that external contracts interacting with your business are compatible with each other, including deflation/inflation tokens and reentrant tokens like ERC-777, ERC-677, and ERC-721. Refer to the Reentrancy Vulnerability Case for guidance.
Consider the risk of reentrancy in external function calls.
Avoid excessive loops when reading or assigning contract storage variables.
Avoid concentrating authority, especially the ability to modify critical contract parameters. Instead, use governance mechanisms, timelock contracts, or multi-signature contracts to manage authority.
Maintain linear inheritance relationships between contracts and ensure that inherited contracts are necessary for business.
Avoid using on-chain block data as a seed source for generating random numbers.
Fully consider the possibility of rollback attacks when acquiring and using random numbers.
Use Chainlink's VRF to obtain reliable random numbers. Refer to the Chainlink VRF for more information.
Avoid calculating LP Token price directly from the token quantity of third-party contracts. See How to get the price of LP correctly for guidance.
Use at least three price sources when obtaining prices through third-party contracts to avoid relying on a single source.
Record the status of execution using events in key business processes for data analysis purposes during the project's runtime.
Have an emergency switch in place for suspending global and core business activities to prevent further losses in case of a black swan event.
Ensure that dependencies are properly validated and secure before incorporating them into the contract code.
Use standardized formats like ABI or JSON to ensure compatibility and interoperability with dependencies.
Regularly update and maintain dependencies to ensure compatibility with Solidity's latest version and address potential vulnerabilities.
i. Gas optimization
Use
uint256instead of boolean and small units: A boolean is internally represented as auint256with 255 bits masked out. The extra masking operations incur additional gas costs. It is generally more gas-efficient to useuint256for non-storage variables unless there is a specific need to reduce their size.Prefer bitshifting over division or multiplication by two: Bit shifting operations (
<<and>>) cost three gas, whereas multiplication and division operations cost five gas. If overflow is not a concern, using bitshifts is a more gas-efficient option.Utilize bitmaps for contracts with many boolean variables: Under the hood, a boolean is actually represented as a
uint8. This means auint256can hold up to 32 boolean variables. If you have more than 32 boolean variables, it is more efficient to store them as individual bits within auint256variable.Optimize function names for gas-sensitive functions: Functions with leading zeros in their names can save gas in two ways. First, they are sorted to the top of the bytecode, resulting in fewer checks to determine if that function is called. Second, leading zeros save gas as part of the transaction data. However, this approach can lead to unconventional function names and should only be used when gas savings are significant.
Pack function arguments for gas-sensitive functions: If you need to represent two 128-bit numbers, consider combining them into a single 256-bit number and splitting them into two numbers within the contract. This technique can save gas. However, it may reduce code readability and should only be used for gas-sensitive functions.
Avoid using
require(x >= 0, "...")for units: Unsigned integers cannot be negative, so checking forx >= 0is redundant and wastes gas.Split
requirestatements instead of using boolean operators: Using separaterequirestatements for individual conditions is more efficient than combining them with boolean operators. For example:
require(a, "message a");
require(b, "message b");Compare boolean literals directly: When
conditionis a boolean variable, usingif (condition)is more gas-efficient thanif (condition == true).Prefer
x = x + yoverx += y: Although mathematically identical, the compiler treats these operations differently, andx = x + yis generally more efficient in terms of gas usage.Prefer
++xoverx++: If a variable is incremented in isolation, prefix incrementing (++x) is preferred over postfix incrementing (x++) due to compiler optimizations.Use
unchecked { ++x }when using a loop: If a loop usesuint256(which is recommended), and overflow is not a concern, it is safe to increment the loop variable usinguncheckedto remove overflow checks and save gas.Avoid initializing storage variables to default values: Storage variables are initialized to their default values (zero, false, etc.) automatically, so explicitly initializing them wastes gas.
Swap variables in a single line: To swap variables without using an explicit temporary variable, you can use the following syntax:
(x, y) = (y, x);Use
>or<instead of≤or≥when possible: Solidity represents≥asnot <, which incurs an extranotoperation and costs three gas. Using>or<directly is more gas-efficient.Use
abi.encodePackedoverabi.encodefor fixed-length arguments: Theencodefunction pads the inputs, which incurs additional gas costs. For fixed-length inputs, usingabi.encodePackedis more gas-efficient.Admin functions can be payable: If a function is meant for administrative purposes and can receive Ether, making it payable can save gas compared to explicitly checking
msg.valueand reverting. However, for functions accessible to the general public, it may still be desirable to make them non-payable to prevent unexpected state transitions.Declare the return variable in the function signature: To save a small amount of gas, declare the return variable directly in the function signature instead of using an explicit variable assignment inside the function body.
j. Testing and Verification
Write comprehensive unit tests for each function in the contract
Use a testing framework, such as Truffle or Remix, to automate testing and provide standardized test results
Write integration tests to ensure that the contract works with other components of the system
Verify the contract code on a blockchain explorer, such as Etherscan or BscScan, to ensure that it is properly deployed and functioning as intended
Consider QuillAudits audits to identify potential vulnerabilities and improve the security of the contract
k. Web front-end Security Configuration Requirements
Ensure that the entire website uses HTTPS for HTTP communication.
Configure HSTS to prevent man-in-the-middle attacks, such as DNS hijacking and BGP hijacking. See HSTS Configuration Introduction for more details.
Configure X-FRAME-OPTIONS to prevent Clickjacking attacks. Refer to X-FRAME-OPTIONS Configuration Introduction for more information.
Configure X-Content-Type-Options to prevent browser sniffing behavior that may cause security risks. See X-Content-Type-Options Configuration Introduction for details.
Configure CSP policies to prevent cross-site scripting (XSS) attacks. See CSP Configuration Introduction for more information.
Configure cookies related to permissions and user credentials with HttpOnly, Secure, Expires, and SameSite flags. Refer to Cookie Configuration Introduction for more details.
Strictly separate sub-domains of different businesses to avoid XSS problems in one sub-domain affecting others.
Restrict referenced third-party resources using the integrity attribute to avoid compromising the project's site in case the third party gets hacked. Refer to SRI Configuration Introduction for more information.
Properly configure CORS to allow only the specified origin domain, protocol, and port to access the project's resources. See CORS Configuration Introduction for details.
Ensure that the addEventListener/postMessage implemented in the business checks the message's origin and target. See postMessage Configuration Introduction for more information.
l. Server Environment Security Configuration Requirements
Select a reputable cloud server provider, such as AWS or Google Cloud.
Use a strong password and enable MFA for the cloud platform management account used by the project.
Strengthen the server's security before deploying the project code, including installing HIDS, using SSH Key for login, setting up SSH login alerts, and implementing SSH login Google-auth.
Use professional software monitoring services, such as APM and Zabbix, to ensure server availability.
Regularly test the security of the project using professionals, such as QuillAudits.
m. Github Best Practices
- A commit should be a wrapper for related changes. For example, fixing two different bugs should produce two separate commits. Small commits make it easier for Audit Team members to understand the changes and roll them back if something went wrong. With tools like the staging area and the ability to stage only parts of a file, Git makes it easy to create very granular commits.
- Committing often keeps your commits small and helps you commit only related changes. Moreover, it allows you to share your code more frequently with others. That way it’s easier for everyone to integrate changes regularly and avoid having merge conflicts. Having few large commits and sharing them rarely, in contrast, makes it hard both to solve conflicts and to comprehend what happened.
- Resist the temptation to commit something that you “think” is completed. Test it thoroughly to make sure it really is completed and has no side effects (as far as one can tell). While committing half-baked things in your local repository only requires you to forgive yourself, having your code tested is even more important when it comes to pushing / sharing your code with others.
- Begin your message with a short summary of your changes (up to 50 characters as a guideline). Separate it from the following body by including a blank line. The body of your message should provide detailed answers to the following questions: What was the motivation for the change? How does it differ from the previous implementation? Use the imperative, present tense („change“, not „changed“ or „changes“) to be consistent with generated messages from commands like git merge.
- Branching is one of Git’s most powerful features – and this is not by accident: quick and easy branching was a central requirement from day one. Branches are the perfect tool to help you avoid mixing up different lines of development. You should use branches extensively in your development workflows: for new features, bug fixes, experiments, ideas…
- Mandate PR reviews by Security Auditors before merging code to ensure quality and security checks.
- Implement pre-commit hooks to prevent committing sensitive data (e.g., passwords, API keys).
Reference:
QuillShield: AI-Powered Smart Contract Audit Tool
We're excited to announce the launch of Quillshield, a suite of AI-powered tools designed to strengthen your smart contract security!
Quillshield offers an additional layer of protection alongside our security audits, helping you identify and address potential vulnerabilities before deployment.
Leverage Quillshield for:
- Early-stage bug detection
- Automated code analysis
- Enhanced code clarity and efficiency
Get a Free AI-Powered Smart Contract Audit with QuillShield; Click Here: https://shield.quillai.network/
📝Deployment and Incident Report
Deploy the project, monitor for issues, and establish a process for reporting and resolving incidents.
- Write a deployment script that deploys your smart contract to your chosen network using a tool like Truffle or Remix. This script should specify any deployment parameters and dependencies and handle any errors or exceptions that may occur during deployment.
- Write a deployment test: Create a test suite that verifies that your smart contract was deployed correctly and is functioning as expected. This should include testing for state transitions and verifying that no unexpected changes occurred during deployment. Use a tool like Truffle or Mocha to automate and simplify the testing process.
- Have an audit performed: Consider performing an external security audit on your smart contract to identify and address any vulnerabilities or weaknesses. This will help ensure your contract is secure and can withstand potential attacks.
- Deploy the contract(s): Deploy your smart contract(s) to your chosen network using your deployment script. Verify that the deployment was successful and that your contract functions as expected.
- Setup monitoring service: Set up a monitoring service that tracks the performance and security of your smart contract after deployment. This can help you identify and address any issues or vulnerabilities that may arise over time.
- Prepare/update your Incident Response Plan: Create or update your incident response plan to address any potential security breaches or failures in your smart contract. This plan should outline the steps to take in the event of an incident and designate roles and responsibilities for responding to the incident.
Feedback Needed: Improving QuillShield for You
🗣We hope you've had a chance to explore QuillShield, our AI-powered smart contract security toolkit.
Your feedback is crucial in helping us continuously improve QuillShield. We'd greatly appreciate your insights on:
- Your experience using QuillShield
- The tool's effectiveness in identifying vulnerabilities
Any suggestions for improvement
Please share your thoughts by completing a short survey at the Survey link: https://quillaudits.typeform.com/Dev-Survey?utm_source=xxxxx
Thank you for taking the time to review this Development Process checklist. We hope this document has helped you in Building Your Web3 Project.
If you are looking for a security audit of your project, we would be happy to help. Our team of experienced security professionals can provide a comprehensive audit of your product's security posture to identify any potential vulnerabilities and provide recommendations for improvement.
QuillAudits’ Impact
QuillAudits has audited over a million lines of code across 1000+ projects, securing over $30B AUM. We supercharge web3 security with our product suite, consisting of AI-driven audit, token risk assessment, and monitoring tools. Supporting 15+ blockchains, our team prioritizes holistic evaluation and excellence in safeguarding digital assets.
Audit Process
Our process is thorough and constantly updated to address the latest vulnerabilities. We employ a combination of manual line-by-line review and automated testing to identify any issues within the code.
BD Team Contact
Name: Partho
Telegram: https://t.me/Partho_RoyC
Schedule a Call: https://calendly.com/partho_roy_c/15min?
