Product Engineering \nA digital commerce agency with capabilities including strategy, creative, marketing, systems integration, technology services, and managed services

echidna software

Survey and Analysis of Smart Contract Quality Assurance: Conclusions, Acknowledgement and References

Survey and Analysis of Smart Contract Quality Assurance: Defense Methodologies

Testing smart contracts is really important. Why? Smart contracts are generally in production, , , and often involve . The short story? With smart contracts, you don’t want to screw up. You need to test a lot, test often, and test thoroughly. Smart contract testing involves all the usual suspects—unit testing, integration testing, automated testing— but also highly recommended is fuzzing—a way to bombard your code with a bunch of random inputs just to see what happens. immutable public targets of hackers significant financial implications Let’s take a look at exactly what fuzzing is as a testing method and how you can easily include it in your software testing workflow using tools such as ConsenSys . We’ll walk through a tutorial using an to see how it's done. Diligence Fuzzing example defi smart contact What is fuzzing testing and why would I use it? (or fuzz testing) involves sending millions of invalid, unexpected, and (semi) random data against a smart contract in an effort to cause unexpected behavior and detect vulnerabilities. It’s a fast, efficient, brute-force way to test edge cases and scenarios you might not think of. It complements your other testing flows and your audits. Fuzzing testing Fuzzing has been around for a while in traditional full-stack development, but a new class of tools is here that can apply fuzzing to smart contract testing in web3. Some of the fuzzing tools include the open source and . Echidna MythX In this article, however, I will take a deep dive into , which offers fuzzing as a service—a pretty cool and easy way to fuzz. Diligence Fuzzing To use Diligence Fuzzing, you annotate your smart contracts using . Basically, you use Scribble annotations in your code to tell the fuzzer what type of output to expect for that function. Scribble It looks something like this: /// #invariant {:msg "balances are in sync"} unchecked_sum(_balances) == _totalSupply; You call the fuzzer from a web UI where you submit the smart contract code. You hit run, and approximately 10 minutes later, you get a report with the issues found, location of issues, coverage %, and more. This is an easy and powerful way to check some edge cases. Testing a DeFi Smart Contract Let’s say we have a new DeFi protocol and corresponding token that we want to launch. DeFi is cutting-edge finance, fun to write, and it’s critical that we don’t have any bugs. DeFi smart contracts often involve millions (or more) in user funds. So we want to be sure our smart contracts are tested (and audited) as thoroughly as possible. IMPORTANT NOTE: This code has vulnerabilities in it ON PURPOSE! It’s so we can show how fuzzing can catch these mistakes. Please don’t really use this code for anything. Let’s get started. An example using Diligence Fuzzing (FaaS) Step 1: Set up a Diligence account. First, we need our Diligence account. Sign up at . You get 10 hours of fuzzing for free to try things out. Diligence Step 2: Create a new API key. Click your account name at the top right, click “create new API key”, and give it a name. This API key allows us to connect to the FaaS. Step 3: Set up your local environment. Clone the following repository: https://github.com/ConsenSys/scribble-exercise-1.git From the command line, navigate to the repository folder, which will now be your project root folder. If necessary for your machine, activate a Python venv. Then, run the following commands to install your project dependencies: $ npm i -g eth-scribble ganache truffle
$ pip3 install diligence-fuzzing Step 4: Enter your API key. Edit the file to use your Diligence account API key for the value of key. .fuzz.yml Your resulting file should look like this: .fuzz.yml

fuzz:
# Tell the CLI where to find the compiled contracts and compilation artifacts
build_directory: build/contracts

...
campaign_name_prefix: "ERC20 campaign"

# Point to your ganache node which holds the seed
rpc_url: "http://localhost:8545"

key: "DILIGENCE API KEY GOES HERE"

... Step 5: Write and annotate your contract. Now let’s check out our smart contract at . Here we have a vulnerable token (as it’s named!) for our new DeFi protocol. We clearly need to test it as much as possible. So let’s add a check using Scribble that the fuzzer will hopefully catch. contracts/vulnerableERC20.sol Above the contract definition, add: /// #invariant "balances are in sync" unchecked_sum(_balances) == _totalSupply; And above the transfer function, add: /// #if_succeeds msg.sender != _to ==> _balances[_to] == old(_balances[_to]) + _value;
/// #if_succeeds msg.sender != _to ==> _balances[msg.sender] == old(_balances[msg.sender]) - _value;
/// #if_succeeds msg.sender == _to ==> _balances[msg.sender] == old(_balances[_to]);
/// #if_succeeds old(_balances[msg.sender]) >= _value; So now let’s see if the fuzzing tester will catch something. Notice the annotations we’ve added to the contract to help the tester understand what we expect to happen. And notice in the config the tester is set to run for 10 minutes max, so it might not catch everything. Step 6: Fuzz around. Now we’re ready to test! From the project root folder, run to call the make file, which will compile, build, and send everything over to the FaaS. make fuzz Step 7: See the results. Go back to your dashboard, and you should see something similar to the below. Wait several seconds for the campaign to start. After it’s finished generating, you should see something similar to what is shown below: We even see code coverage! And after a few minutes, we see a failure! Clicking through to properties, we see any violations. And yes we have a bug! Click on the line location to see the details of our potential code vulnerabilities. We’ll stop there, but if you let the fuzzer keep running, it might find more! Conclusion Fuzzing can be a crucial step in your software development and testing process. It helps you identify potential vulnerabilities that otherwise may go unnoticed. By using it, you start to recognize and understand common pitfalls and challenges. Take advantage of tools such as , write better smart contracts, and become a better developer! Diligence Fuzzing

Fuzzing Around: Smart Contract Testing Through Random Inputs

Fuzzing Around: prueba de contrato inteligente a través de entradas aleatorias

Fuzzing Around : Test de contrat intelligent via des entrées aléatoires

फ़ज़िंग अराउंड: रैंडम इनपुट के माध्यम से स्मार्ट अनुबंध परीक्षण

ファジーアラウンド: ランダム入力によるスマート コントラクト テスト

Fuzzing Around: Teste de contrato inteligente por meio de entradas aleatórias

Fuzzing Around: Thử nghiệm hợp đồng thông minh thông qua đầu vào ngẫu nhiên

模糊测试：通过随机输入进行智能合约测试

Smart Contract auditing has been a growing industry and is always in demand in the DeFi, crypto startups in NFT, and many other spaces. However, compared to the booming market, few blockchain security companies are now. Why the Need to Audit Smart Contracts? Once the smart contracts are deployed, there is no looking back. Once programmed and deployed on the blockchain, it cannot be changed. So, if there is even a minor bug, the entire protocol will break and drain the entire fund. In the last two years, we have seen billions of dollars vanish into thin air due to bugs in smart contracts. The creator of the smart contract might very easily add a backdoor to steal the money. However, human error is usually to blame. The idea of a smart contract is relatively new and has only been around for a few years. There aren't many developers with extensive experience in this area. Billions of dollars could simply be lost due to a minor error. Therefore, it is crucial to have each smart contract element examined. Things to Consider When Choosing a Smart Contract Auditor Are you someone who wants to use audit services? Then, it is mandatory to keep certain things in mind. These include: First, not all auditing firms have experienced professionals and have tried their hands in this field for some time. Some security firms have been long-time players in this field and have the best talents, while others are not so reliable. Second, you need to be clear about what you require. While most of the auditors have a strong command of the Ethereum foundation, a few also possess the expertise to deal with other chains like Solana or the Binance chain. Also, you must know the level of penetration testing that you want your smart contract to pass through. The third is the audit's cost. Hiring the smartest professionals to audit and analyze your smart contract will cost a lot of money. Some of the best auditing companies bill six figures for each audit. Therefore, depending on your budget, you could choose your auditing business. Who are the Most Reliable Blockchain Security Firms? When it comes to going for security consulting for your code audits, these companies are considered the best ones in the blockchain ecosystem. Certik Undoubtedly, there is no question about Certik being the most promising name in the smart contract auditing industry. Starting in 2018, two Columbia University and Yale University professors founded this company. Over the years, they have conducted more than 1,800 audits. Some of the world's most significant DeFi protocols, like Huobi, Binance, OKEx, etc., rely upon this company to get their audit reports. Having had a strong reputation within the industry for years, they are primarily known for carrying out robust smart contract audits for a colossal clientele profile. The point that distinguishes them from the rest is that, in addition to performing the audit, they also suggest recommendations when they find vulnerabilities. ImmuneBytes They are a cybersecurity consulting firm dedicated to providing proactive and cutting-edge blockchain and crypto security solutions to make security a lifelong affair for enterprises. Using the most recent smart contract audit tools and penetration testing techniques, the company has worked with organizations of various sizes since its founding in 2020, including primary and mid-sized enterprises, non-profits, and small businesses, to provide security help. With more than 175 completed successfully, they have an excellent track record. Clients like Ethernity, Good Dollar, Maha Dao, Poly Trade, retreeb, Sheesha Finance, and Sports Icon rely on them to support them in becoming leaders in their sectors. Additionally, they have extensive knowledge of virtualization, software attacks, blockchains, and cryptography. Hacken White hat hackers, Big Four employees, and cybersecurity specialists formed the Hacken ecosystem. Hacken has been developing Web 3.0 cybersecurity firms since its founding in 2017 and educating and expanding the ethical hacker community. Clients include, but are not limited to, Solana, VeChain, Gate.io, KuCoin, FTX, Huobi, 1inch, and Avalanche. Over $10 billion in assets belonging to clients and users have been protected by Hacken. Coingecko and Coinmarketcap recognize Hacken certification as a Web 3.0 security standard. A smart contract security assessment, a KYC background check, pentests, and a bug bounty program are all included in the one-stop solution service package. The company has even provided security services to non-blockchain companies like Air Asia. Not just this, but it has shown its commitment to the blockchain industry every time by organizing several security meetups. In order to shield the user from security concerns and account compromises, Hacken has developed the HackenAI security platform. Users are quickly notified of compromised passwords and potential darknet assaults via key features like darknet monitoring. HackenAI is accessible on iPhone and Android smartphones. Consensys Diligence ConsenSys is a big player in the Ethereum industry. Joe Lubin, the founder of Ethereum, founded this company. Auditing smart contracts are one of their products. As a blockchain developer, you can get several services on the Ethereum ecosystem. They have provided thorough smart contract testing, threat modeling, audits, and automated analysis for clients worldwide. Several tools were used for smart auditing contracts on the Ethereum chain. MythX is a potent product of this company that is an automated scanner for Ethereum smart contracts. Trail of Bits Since 2012, the company has expanded massively to help secure a wide range of targeted organizations and devices. To mitigate the risks associated with smart contracts and fortify the open source, they amalgamate high-end security research together with the mentality of a real-world attacker. Some areas in which they specialize include software security, reverse engineering, cryptography, blockchain, osquery, machine learning, binary analysis, and blockchain. They provide a vast array of software security services, including software development, smart contract audits, blockchain security audits, and more. Crytic, Echidna, and Slither are some of their blockchain-focused solutions; AlgoVPN is another. Their clients include MakerDAO, Compound, NuCypher, and 0x Protocol. Openzeppelin The OpenZeppelin team is well known for creating the OpenZeppelin Contracts and Solidity libraries. Most Solidity projects use these libraries as a tried-and-true model for deployable contracts on decentralized applications. Through the native SDK of OpenZeppelin, developers can implement this solution. In addition to development, OpenZeppelin places a lot of emphasis on audit and security services for smart contracts. Additionally, OpenZeppelin was among the first groups to reimagine blockchain security by including gamification components to find flaws in smart contracts. One of its other products is Ethernaut, a Web3/Solidity war game that requires players to hack smart contracts to advance. Interestingly, OpenZepplin is known to be one of the first teams who reinvented blockchain security with the help of gamification, which is responsible for recognizing different types of loopholes in smart contracts. Slowmist Slowmist is China's leading blockchain security company. They perform extensive blockchain security services that include smart contract audits, blockchain security audits, wallet security testing, and much more. Slowmist also has a safe staking project for blockchain ecologies, which delivers real-time data on EOS, Cosmos, Vechain's growth and security patterns, and other top blockchain projects. Another interesting detail about this platform is its powerful firewall project for EOS smart contracts, named FireWall.X. Omniscia Omniscia has a centralized staff of skilled smart contract developers and auditors who are into building and securing intricate decentralized networks and applications. Since 2017, their engineers have built and audited distributed systems that drive multimillion-dollar economies. They provide services like security audits, code optimization, and collaborative development to big names in the industry which include Polygon, Tokemak, AllianceBlock, Fetch.ai, Olympus, Hot Cross, etc. The company has audited more than 210 blockchain projects till now, with over 855+ high severity issues discovered, and 65b+ dollars protected. Solidity.finance They offer thorough yet reasonably priced smart contract audits. Their skilled staff of Solidity smart contract auditors performs audits for tokens, NFTs, crowd sales, marketplaces, gaming platforms, financial protocols, and more! To offer project teams industry-leading security advice, they combine static analysis, automated technologies, and a thorough manual review process. Over 1300+ projects now have over $10 billion in on-chain value that is being protected! Techrate They have a team of blockchain tech and business analytics experts with extensive knowledge of the cryptocurrency market. Their core team is renowned for its market analyses produced during the bullish market of 2017–2018 and for its technical project evaluation. At the height of the ICO rush, they began as an audit and development company for smart contracts and then broadened their skills to include market research, exchange analytics, security, and valuation of technical projects. Conclusion In today’s generation, getting smart contract audits has become the new normal. With such a wide range of hacks, vulnerabilities, and exploits every now and then, the demand for this has increased exponentially. Interestingly, companies rely more on external parties for this process before deploying it. One relief is that there are so many alternatives to choose from. Choose any of these companies as per your budget and projects, and eliminate the risks associated with your smart contracts. Visit their websites, research the projects that they have handled so far, the pricing that they quote, and more before selecting one for your business organization. After all, who would want to lose their hard-earned digital assets?

Top 10 Smart Contract Auditing Companies 

It's been since the infamous DAO hack that shook the entire web3 world. The one where we witnessed more than 3.5 million Ether being stolen away due to a bug in the smart contract. 6 years, 3months, and 25 days This hack introduced us to one of the most dangerous attacks, possible in a smart contract. The Re-Entrancy attack, Since then there have been enormous improvements and attempts to mitigate the risk of introducing such attack vectors in smart contracts. Automated testing tools started including warnings about re-entrancy bugs, smart contract auditors became particularly cautious with codes dealing with external calls, and loads of blogs as well as video content were created ( ) explaining the re-entrancy attack. and are still being made However, if you have observed the exploits in the past few years, along with all other new attack vectors, re-entrancy exploits are still a major concern and can be seen as a considerable bug behind many smart contract exploits. In fact, the latest re-entrancy exploit that I read about was just a few weeks ago when with the exact same very well-known re-entrancy bug & $830,000 were lost. Stader’s NearX smart contract was exploited Well, this isn’t just about re-entrancy bugs in smart contracts and neither is the blog going to explain re-entrancy bugs ( ). not again Re-entrancy attacks are just one of the many well-known attacks that the smart contract dev community is well aware of but we find traces of such bugs in smart contracts even today, which leads to incredibly massive exploits. Now the question is — WHY? Despite having enormous tools, libraries, and educational content around such common bugs and attack vectors in solidity, why do we still witness such well-known attacks time and again? This is undoubtedly one of those that might have multiple narratives or answers. broad or open-ended questions However, after being involved in multiple smart contract security audits now, interacting with quite a few smart contract devs, and being part of some really active smart contract developer communities, I came across 2 extremely simple but imperative reasons behind this. Most importantly, these reasons revolve around the very basics of how we approach Smart Contract development and learn Solidity, especially in the initial stages. mindset 1. The “ ” Security-is-NOT-my-job It can unquestionably be stated that the majority of the developers in the web3 space believe contract development and smart contract security to be two different things, which is true, to some extent. However, completely denying any correlation between these two things is probably a mistake. The rationale behind this is the fact that, at the very heart of it, the process of smart contract development broadly includes 3 most significant steps: Design & Development Optimizations Security Validations of the Contract While we are quite well aware of the first two steps, we most often forget, or even worse, do not consider to be part of the contract development procedure at all. Security Validations It’s concerning because even if we consider a basic fact about smart contracts, i.e., their immutable nature after on-chain deployment, we can quite clearly see the significance of adding as a mandatory step in the smart contract development process. security checks and validations The fact that you cannot change a line of code in your contract even if you found a major bug just seconds after deployment, is daunting in itself. Well, just in case you think you can always upgrade your smart contracts or upgradeable contracts are extremely secure, let me stop you right there. 🛑 and think again. Read about the Wormhole Proxy Bug Upgradeable contracts can have bugs too. 🪲 What should you do? In very simpler terms, consider as an imperative part of any smart contract you develop, and learn at least the basics of smart contract security if you haven’t already. security checks & validations Once you consider this, you can no more rely on just writing test cases for your smart contracts. Test scripts are undoubtedly helpful, however, they are more inclined towards ensuring the contract functions execute as intended while the security of a contract is much more than that. Even as a smart contract developer, you should definitely be good with at least one of the following ( ) security tools to validate the security of your contract: actually more than just 1 These tools effectively help you identify any well-known smart contract bugs that you might have in your contract. Static analysis tools like , Slither , Mythril . Mythx help identify potential exploit scenarios or contract execution failures by throwing random & unexpected data into your contract. Fuzz Testing tools like Echidna or Harvey , which is an amazing runtime verification tool by that allows you to annotate a solidity smart contract with crucial properties. Scribble ConsenSys While auditing complex & bulky smart contracts, the one thing you need the most is a , and that’s exactly where comes in. It provides an incredibly simplified version of all crucial details about a contract’s structure including call graphs, inheritance graphs, etc. visualization tool Surya extension is an extremely helpful tool that provides security-oriented syntax as well as semantic highlighting and quite a few other tools that make the secure development of contracts easier. VS Code visual auditor My favorites → . Slither, Surya, VS Code visual auditor, and Echindna Why should you do it ( )? If you can get smart contracts Audited Well, to begin with, no one will ever care about the security of your smart contracts more than you ( ). The very first person responsible for the security of your code should be . and your team YOU Secondly, the smart contract audit industry has been ( ) in a “ phase. and still is “ High Demand & Low Supply of good security auditors This basically means there are just a handful of extremely experienced auditors and relying on just a few of them won’t really be scalable enough for the web3 world to expand its boundaries exponentially. Additionally, there is a huge line of projects waiting for their contracts to get audited, which is why, when it's your turn you need to be ready with the right set of contracts, adequate test cases, coverage reports, and most importantly, the crucial discussion points you might want to have with your security auditor. However, you won’t really be capable of having any effectual discussion with smart contract security experts if you yourself don’t understand, at least, the basics of smart contract security. The inclusion of the step in your smart contract development journey allows you to filter out all the well-known bugs beforehand with the help of static analysis tools. security validations This allows security auditors to specifically concentrate on the more important potential threats of the contracts instead of identifying and reporting the ones that could be easily found with the tools mentioned above. Therefore, performing your own security checks before an audit doesn’t just shorten the lengthy audit durations, it helps achieve an adequate & better result out of the whole procedure. This is a concept that the brilliantly defines as which intends to prepare your contracts before an audit to ensure that the outcome from the security audit is comparatively better and effective. Secureum community CARE ( Comprehensive Audit Readiness Evaluation ) It’s important to note that including security as a part of your smart contract development process isn’t a substitution for an audit of your contract, but a preparation for an adequate security audit. 2. Avoiding Mistakes & Experimentations with Solidity ( ) and the lessons that come from them Alright, while the first point was for developers already familiar with solidity( ), this part is more inclined towards those starting out with learning solidity or the ones in the very early phases of smart contract development. and basics of smart contract security Here is a quick tip for you: Along with learning and developing simple solidity smart contracts, don’t be scared of experimenting and making mistakes while learning solidity. Since its inception or smart contract development, in general, has been incredibly interesting but daunting as well as difficult for many developers at the early stage because of some very obvious reasons: Solidity The immutable nature of Smart Contracts and the idea of getting almost everything right in one single shot before on-chain deployment. The open-source nature of smart contracts and the fact that every single line of code is accessible/readable by anyone. The whole concept of programming and storing money within Smart Contracts and the security risks that come with it. Solidity still being at a very nascent stage and the difficulties in keeping up with the rapidly changing/evolving language. Now, the concerns and risks associated with making mistakes while developing a smart contract can’t be overlooked. However, these have an adverse effect on the journey toward learning smart contracts effectively. With so much at stake, it becomes harder for developers to experiment with Solidity or make mistakes on their own. The popular idea of “ stops developers from exploring different concepts of solidity and thus limits their potential with smart contract development, as a whole. Not reinventing the wheel or trying something new, to avoid introducing new bugs in the contract” In fact, it is now considered a lot safer to simply fork an already existing audited contract instead of writing one from scratch. While this definitely does minimize the risk of contracts having bugs in production, it does stop developers from dealing with all the complications one might( ) go through while developing the same. And, therefore, keeps us from deep-diving into solidity concepts more often than not. and should While simply following a blockchain development course or consuming online content on smart contracts might help you get started with any specific topic, it won’t let you dive in deep and learn the fundamentals. Not unless you get your hands dirty with the same. Most importantly, not experimenting with Solidity smart contracts also keeps us from learning about the various kinds of security vulnerabilities a contract might have and the plethora of ways a contract can be broken. For instance, going back to the re-entrancy example: Every smart contract developer might have heard, read, or discussed the reentrancy attack vector, but how many of us actually went ahead and tried to experiment with the same on some dummy contract, just to understand what happens behind the scenes? This is precisely where smart contract security-based war games or CTFs like also play such a significant role in learning smart contract development and security. They allow you to directly interact with a contract directly, make mistakes and eventually figure out the vulnerabilities. Ethernaut or Damn Vulnerable Defi Now, there are definitely some smart contract developers who experiment with Solidity and smart contracts a lot and therefore are becoming the best in the industry ( ). check the Underhand Solidity Contest winners or their , for instance Challange Submissions However, as I previously mentioned, for the web3 world to expand its boundaries and scale with utmost security measures, we cannot simply rely on a handful of experts in the space. Instead, every smart contract developer should aspire to learn more and dive in deep by not simply learning the basics but experimenting, making mistakes, learning from them, and then sharing them with the community. Because, quite similar to life in general, the best learnings in software development also comes from mistakes. every smart contract dev should have at least once: Mistakes or Learning Experiences If you are just starting out with Solidity, there are a bunch of mistakes/experiments you can ( ) do while learning. and should Dropping off some of them from the top of my head. Solidity 101 mistakes/learnings: Using keyword instead of and then realizing you never really stored the crucial contract states permanently on the contract. memory storage Relying on blog time stamps for random calculation and realizing how they can be manipulated by the miners is therefore a bad practice. More details are . here Storing secret information on smart contract state variables with a private visibility modifier only to find out that nothing is private on a smart contract. Every state variable value can be seen by anyone. Read more about this in SWC-136 You will always believe that a contract with no payable function ( ) will never receive any ether unless you learn how or payable fallback function selfdestruct can forcefully fund such a contract with ETH. Failing to provide required in functions & realizing how this can lead to unwanted scenarios any invalid arguments can be passed without proper validation. ( ) input validation SWC-123 Gas Optimization & Security mistakes/learnings : 5. Writing expensive loops only to find out how this could lead to a issue and fail the complete transaction. for block gas limit 6. Violating and realizing how this could lead to the classic Rentrancy attack. check-effects-interaction patterns 7. Using delegate calls between two contracts with different storage layouts and realizing why storage layouts must be exactly similar for delegate calls to work. It's extremely important to ensure storage layout between two contracts involved in a is exactly the same. Otherwise, this leads to storage collisions. Read more about storage collisions . delegatecall() here 8. Including inadequate access controls for imperative functions of the contract and realizing how this could lead to any bad actor executing transactions without approval. covers this topic quite adequately. SWC-105 9. Trying to send ether from one contract to another using the function only to find out that it always sends a hard-coded gas only. This will help you realize the significance of the function which allows adjusting the gas to be sent with a transaction. Read more about why transfer 2100 .call.value(…)(“ ”) . . call() might be better than transfer() 10. Realising how tricky it is to delete mappings values in struct or in general and learning the right way to do it. 11. Trying to swap with using Uniswap and being vulnerable to sandwich attacks. This might help you realize the dark side of transaction order dependencies and MEVs and the Token A Token B DARK Forest of Ethereum . While these are just some examples, there are way more interesting topics in smart contract development, from basic solidity to advanced deep dives in EVM Opcodes, that one can learn and experiment with. Wrapping it UP 😊 Web3 has come a long way in a very short span of time, however, the security of smart contracts is still a major concern. The two ideas discussed above aren’t gonna make it all sunshine and rainbows at one go. There is undoubtedly a lot more we need to do to make Web3 a safer place. However, imagine a whole generation of developers that includes the two ideas mentioned above while learning or developing smart contracts, prioritizes learning the basics of security, experiments with Solidity, learn from their mistakes, and then shares those learnings with the community. That will, slowly but surely, lead us to a much safer and more secure web3 world than what we have now. All it takes is some commitment be to consistent, the will to learn more from mistakes and experiments, and the aspiration to be the better version of the smart contract developer that you already are. About myself Who am I? 🙋🏻‍♂️ 𝙃𝙞, 𝙄 𝙖𝙢 𝙕𝙖𝙧𝙮𝙖𝙗 👋🏻 A Smart Contract Engineer and Dev Team Lead at . Push Protocol I work on smart contracts development as well as security audits of smart contracts. Drop a ‘HI’ and Get in Touch 🤝 My Socials |Follow my Weekly Newsletter |My Web3 Speech & Presentations Also Published Here

Another Re-entrancy Attack  -  What's Stopping Us from Being a Better Smart Contract Developer?

New developers often don’t know how to set up a framework for smart contract development to make the process as efficient and secure as possible. For developing Solidity smart contracts, we In HashEx, use Hardhat, and for our internal needs, we have created a pre-configured project with the most useful development projects connected to it and set up according to the developers’ needs. The Useful Effects of Boilerplate By using boilerplate you can get ready-for-use software out of the box, immediately starting the development of the project. A prepared README can help with the usage of preset plug-ins: shows how well the contracts are covered during testing. Coverage formats the code to provide a better code style. Prettier automatically generates contract documentation. Docgen is a Solidity code linter Solhint is an automated analyzer for Solidity code with the purpose of vulnerability detection. Slither is required for fuzzing/property-based contract testing. Echidna README also includes instructions on contract testing and deployment. It also describes testing if there’s a need to create a fork of a public network. How to Use the Initial Repository To start using the initial repository, you have to clone repository and install the packages it requires. This can be done using the following commands: this If you’re installing it through npm npm install If you’re installing it through yarn yarn After that, you have to familiarize yourself with the README.md, create a config.js file following the example of the file, then insert API keys as well as private keys (this file is located in .gitignore so it won’t be uploaded to GitHub). config.example.js After that, you can attempt compilation of the project and launch the tests. You can also try to run different plugins and make sure that they function properly. When all this is finished, you can start developing the project. The repository contains many useful plugins. Coverage This plugin assists with writing tests and contract testing. It allows finding the spots within the contract that are not covered by tests and because of that, can potentially contain an error or a vulnerability. Prettier This plugin helps with keeping the repository in a presentable condition, including its visual aspect. The main goal is to achieve a quality code style. It’s recommended to run this plugin every time before the commit or deployment. Docgen This plugin assists with writing the documentation for the contract. The documentation written in a specific way (NatSpec) within the contract files, will be converted into a presentable .md file so that anyone attempting to figure out exactly how the contract works, could do it using said documentation. Solhint This plugin serves for checking the code’s Security, Style Guide, and Best Practices. It suggests changes that have to be made for the code to follow the commonly used rules of contract writing. Slither This plugin specializes in finding potential vulnerabilities within the code, using static analysis. Vulnerabilities such as reentrancy, non-secure external calls, etc. can be discovered with this plugin. Echidna This plugin is used for fuzzing/property-based contract testing. It requires writing specific contracts that will be tested. Examples can be found in the repository in the  /contracts/echidna-test folder. The point of this type of testing is to attempt to break the in-contract invariants, that are supposed to always be run. This is how the contract is checked. It attempts to apply random actions by calling functions in random order with random arguments. This type of testing isn’t a universal cure, it only assists with testing. There have been cases of a contract passing Echidna testing without a vulnerability being discovered. This happens because not every possible combination is tried, but a specific subcollection.

ECHIDNA SOFTWARE

echidna.co

-- employees

Since n.d.

COMPANY RANKING

ECHIDNA SOFTWARE

EVERGREEN INDEX #4474

Representing this company? Click here to claim and customize this page!

echidna software WIKI

Apply to get your Tech Company News Page live on HackerNoon.com today!

ECHIDNA SOFTWARE

echidna.co

-- employees

Since n.d.

COMPANY RANKING

ECHIDNA SOFTWARE

EVERGREEN INDEX #4474

RELATED COMPANIESRANK

STORIES ABOUT ECHIDNA SOFTWARE

Representing this company? Click here to claim and customize this page!

echidna software WIKI

Apply to get your Tech Company News Page live on HackerNoon.com today!