What if there is a hardcoded contract address in another contract you need to test? External dependencies in smart contracts are sometimes stored as immutable and constant variables:
In unit tests, we may need to modify external dependecies to produce specific answers behaviours and test multiple scenarios.
We can use forked mainnet and testnet networks to test against live external dependencies locally. However, hardcoded addresses prevent us from swapping them out with a local version deployed at another address. We need a way to mock an already deployed contract at a specific hardcoded address.
How can we replace the bytecode of an existing contract?
The goal of smart contract audits is to assess code (alongside technical specifications and documentation) and alert project team of potential security issues that need to be addressed to improve security posture, decrease attack surface, and mitigate risk.
An audit helps to detect and resolve security issues before launch, summarized as a set of findings with underlying vulnerabilities, severity, difficulty, sample exploit scenarios, and recommended mitigations.
Given the high cost of smart contract bugs, it’s no surprise that an audit is a key step in the smart contract development lifecycle. However, engaging an auditor can be costly and difficult due to high demand.
In this article, we’ll learn how you can use the open source tools Slither and Echidna to audit Solidity contracts, in order to identify any potential security vulnerabilities.
In a previous post, we learned about forking mainnet as an alternative to mock contracts in Solidity. The major drawback with mock contracts is that you need to spend time to rewrite existing smart contracts as mocks. To get exhaustive mock coverage, you’ll end up rewriting whole protocols for the sake of testing.
What if there’s a magical way to mock contract functionality without writing mock contracts? Read on to learn more.
Ethereum and other permissionless blockchains are innovation machines. Developers are free to build with completely public building blocks, stitching them together to create sophisticated systems out in the open.
When building a protocol of your own (DeFi, NFTs, etc), you’ll quickly realize that you need to interface with existing contracts. In a single transaction, your contracts may call several others. These contracts may include DeFi lending protocols, AMM pools, and marketplace contracts that are live on mainnet.
Interfacing with other protocols is a key part of smart contract development. But how do you develop against these building blocks?
Software systems are becoming more and more interconnected. Service-oriented architecture transforms software into smaller, independently deployable units that communicate over the network. APIs are eating the world, rapidly becoming the primary interface for business. Smart contracts go a step further - creating public, immutable protocols that anyone can run without permission.
Software is being broken down into and being offered as modular services. It’s innovation legos on steroids: By composing multiple building blocks together we can bootstrap new ventures much more rapidly at lower cost.
However, this new world of distributed systems introduces its own challenges. What happens if a service on a critical path fails? Can the system recover from faults? Or will a single failure cascade to downstream services in a catastrophic explosion of fire and death?
In the world of smart contracts, faults can be an extraordinarilyexpensive affair. With DeFi continuing to grow - can we do better, somehow?
In an ultra-interconnected system, fault tolerance is key. The COVID-19 pandemic showed everyone the importance of resiliency in the real world. A fault-tolerant design enables a system to continue its intended operation, possibly at a reduced level, rather than failing completely, when some part of the system fails.
In this article, we’ll explore:
The dangers of cascading failure in service oriented architectures,
Fault tolerance and resiliency patterns,
How circuit breakers can improve fault tolerance in smart contracts, and
An implementation of a Circuit Breaker in Solidity.
Unit testing is a critical part of smart contract development. The high stakes and rigid immutability of smart contracts demands even more emphasis on testing compared to traditional software. Unit tests ensures your contracts are performing correctly at the most fundamental level, acting as a vanguard in your defense against bugs.
In this article, we’ll learn:
Why unit testing is important for smart contracts,
How to write unit tests for smart contracts,
How to use static types and Typescript to test smart contracts,
Helpful tools and utilities you can use for complex assertions,
‘Smart contracts’ is a misnomer. Despite its name, smart contracts on Ethereum are not self-executing digital agreements. Smart contract code only run when triggered by an external account. In other words, you need an external process to trigger the smart contract.
In this article, we’ll build a solution to this problem. You’ll learn:
Why you need off-chain smart contract automation
Use cases for smart contract automation
How to deploy serverless functions with the Serverless framework
Finally, we’ll go through serverless-ethers, a fully-functional smart contract automation service that you can run and deploy out-of-the box! Feel free to use this project as a base for building custom smart contract automation that fit your needs.
The serverless-ethers sample application is open source and available on Github. Just clone and hit deploy! 🚀
Read on to learn why we need automation and how it works.