gm! It’s been a long while. 👋

Onchain summer is here. A new wave of consumer crypto apps is coming. 🕶️

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:

contract Vault {
  // An external dependency hardcoded at a specific address
  IOracle public constant oracle = IOracle(0x773616E4d11A78F511299002da57A0a94577F1f4);

  function foo() {
    ...
  }
}

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?

Let’s say that you have a contract A which makes a low-level call or delegatecall to another contract B:

contract A {
  function foo(address target, bytes data) external {
    (bool success, bytes memory result) = target.delegatecall(data) // used to call B.bar()
  }
}

The target contract B reverts with a revert message or custom error:

contract B {
  error AccessForbidden(address sender);

  function bar() external {
    revert AccessForbidden(msg.sender);
  }
}

How can you bubble the error up in contract A?

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?

Let’s hunt for an answer.

Computations on Ethereum cost gas. If you’re not careful, you may end up writing contracts that cost more than they should. High gas costs kill usability!

A common cause for high gas costs is an inefficient storage layout in Solidity contracts. In this post, let’s look at some tips you can use to help you write more gas-efficient contracts.

Read on to learn more!

Recently is a periodic retrospective.

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 extraordinarily expensive 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,
• Other smart contract testing best practices.

New (17 August): Typescript & Typechain support!