Yos Riady · Software Craftsman

Building for Onchain Builders

2025-10-29T00:00:00+00:00

This article was originally posted on the Formo Blog.

Building a successful onchain app is hard. It gets even harder when you don’t know how people are using it. You’re shipping features, running campaigns, and trying to find product-market fit, but without clear data, you’re lost in a dark forest. Analytics remains as one of the biggest challenges in crypto.

Think about the questions you’re trying to answer every day:

Who are my top users?
What drove them to us? Where do they come from?
Which channels or campaigns are working?
How are users using my app?
What’s my CAC? LTV? ROI?
What is moving the needle onchain?

To answer the above in web3 you’d need an in-house data team, complicated data pipelines, and juggle multiple fragmented tools. What if there’s an easy way to understand who your users are and what they do so you can build a better app, faster?

Introducing Formo

Formo is the data platform for onchain apps and builders. It’s the tool we wished we had as builders when we were struggling to turn raw onchain data into something useful.

Formo transforms the messy data silos of wallets, transactions, web, and in-app events into clear, actionable insights for your whole team from product to marketing.

We built Formo to give scrappy founders, product, and marketing teams in web3 the clarity they need to grow. It helps you:

See the full user journey from offchain to onchain, to spot exactly where users are dropping off, helping you fix bottlenecks and improve your app.
Identify your most valuable users—the whales and power users—so you can more effectively engage and retain them.
Segment wallets into cohorts based on their behavior to see which users stick around and to help refine your ICP.
When you ship a new feature or launch a marketing campaign, you can measure its impact immediately on metrics that matter, not vanity metrics.

Many builders we talk to went so far as to cobble together their own analytics solution in-house, because of data silos and fragmented tools. There wasn’t an existing solution that worked for them. A few scripts, an internal database, Google Analytics, and BI tools. But that DIY stack quickly becomes a time sink. It’s expensive to run, complex to maintain, and the data is often out of date.

Formo replaces that headache. From analytics to forms, we handle the infrastructure so you can focus on your core product, not data plumbing. Built with privacy and security in mind, Formo integrates with the tools you already use, allowing you to push insights into dashboards, set up alerts, or export data in less time.

Stop guessing and start measuring what matters in crypto.

Next Steps

Getting started is simple. Spin up a workspace and get actionable insights in less than an hour.

If you’re building onchain, give Formo’s free plan a try so you can focus on growth.

—Yos Riady, Founder

Actionable Insights for Onchain Apps

2025-05-22T00:00:00+00:00

This article was originally posted on the Formo Blog.

Developer tools remove barriers to innovation. Analytics remove barriers to growth

Data is the lifeblood of any business. It helps you understand your customers and where they came from, make impactful data-driven decisions, and drive sustainable growth. Without data, you’re lost in a dark forest.

However, understanding onchain user behavior is hard. Teams struggle to set up analytics and attribution from fragmented tools, data pipelines, and databases. Many teams give up altogether.

Formo is the data platform for onchain apps. Formo makes analytics easy for crypto. Get the best of web, product, and onchain analytics on one versatile platform.

The biggest challenges in web3

User acquisition and product analytics remain among the biggest challenges in crypto.

A web3 user’s journey spans across both on-chain and off-chain channels. Instead of email or IRL identifiers, users log in through crypto wallets. Key conversion events such as swapping on a DEX or purchasing on an NFT marketplace happen onchain, beyond the reach of existing tools. Traditional analytics tools like Mixpanel and Google Analytics cannot see onchain data, so you miss out on crucial information.

Today’s top engagement and retention tools ignore the wealth of data available onchain. For example, marketing solutions like Hubspot and Klaviyo do not support on-chain actions and events, while product analytics systems like Mixpanel and Amplitude do not natively handle blockchain data. Data about user acquisition, drop-off, and retention from a large chunk of the web3 user’s journey is missing.

Answering even simple queries is hard in Web3:

Where do my users come from?
Which channels/campaigns are driving the most revenue? What’s the ROI?
Who are my top users, and how can I retain them?
What were the biggest retention factors, and at which step of the funnel did most users drop off?
What is my ARPU or LTV : CAC ratio, and how can I increase it?

Uncovering your true growth and retention drivers and acquisition channels has been a big challenge in Web3. The vast percentage of onchain activity is disconnected from Web2 and hard to decipher. A side-effect of this problem is web3’s unhealthy obsession with vanity metrics, which is much easier to get (and easy to fake.) Vanity metrics help projects get exchange listings and investment, but it doesn’t translate to building meaningful products.

Data is the lifeblood of any business. It helps you understand your customers, make data-driven decisions, and drive growth. Without accurate data and attribution, you are lost in a dark forest.

High barriers for onchain attribution and profiling

Web3 projects struggle to get the data they need to make impactful decisions. Data is scattered across separate blockchains and data silos. Blockchains are optimized for writes, and reading data efficiently and reliably at scale is challenging. It takes serious engineering work to collect all this data, much less analyze it. Collecting and aggregating data from multiple blockchains and offchain sources requires deep expertise and complex tools (such as Databricks, Looker, Snowflake, BigQuery, and more.)

To do it right, you need extensive SQL and data engineering expertise to collect, process, and analyze data. You’d need a dedicated team of data engineers and analysts to create data pipelines and dashboards for your project. As a result, product teams spend valuable resources on infrastructure and integrations instead of shipping user-facing features.

Building in-house data pipelines and analytics infrastructure is beyond the means of many web3 teams. Not every team can allocate resources away from building their core product. As a result, analytics often falls by the wayside. They remain in the backlog forever.

Teams across web3 struggle to get the data they need to measure what matters and make impactful decisions. The absence of tools has made measuring the impact of growth initiatives and targeting users unsolved.

Onchain data is an untapped wealth of insights

On the other hand, data on blockchains provides unparalleled accessibility and insight into user behaviour. Onchain, you can observe any onchain users’ holdings and past activity, even when they don’t interact directly with your product. In Web2, this is unheard of. Onchain data is a public and permissionless data goldmine. We need only a better tool to access it.

In web2, third-party data, cookies, and sessions are foundational building blocks of cohort segmentation. They perform two core functions: attribution and identity.

Attribution refers to granular event analytics around who, how, and when users interact with your apps and websites (funnels, UTM, referral headers).
Identity refers to the sum of user activity used to construct a profile for targeting (country, device, onchain activity).

Blockchain networks represent a paradigm shift in the transfer of information and value. We believe it will reshape the foundations of trust within legacy systems. To get there, we need accessible data tools for onchain users, builders, and apps.

With unified onchain attribution, we can construct rich profiles and user segments that can be targeted more effectively. Minting, staking, swapping, and voting are high-intent actions that signal meaningful interest in a topic. Wallet addresses, tokens, attestations, and onchain user activity offer a new, meaningful set of attributes that can be used to construct customer profiles. Blockchain data opens up new doors for you to identify and target real, active users.

Identity and attribution are key ingredients for growth, and linking crypto-native web3 data (wallets, tokens, and transactions) with web2 data (dapp and browser interactions) unlocks a clear path for growth and retention.

Formo makes it easy to digest web3 data

User acquisition and product analytics remain among the biggest challenges in crypto. As we transition from infrastructure to apps, we need meaningful and accessible data about apps and users. Formo is a data platform that helps crypto teams measure what matters and make impactful decisions with data, without a dedicated data team of SQL wizards. Instead of juggling several tools (GA, Looker, Mixpanel, Dune, block explorers), use a single data platform that gives you the full picture of what matters in less time.

Designed to be an alternative to Mixpanel and Google Analytics for onchain teams, it combines the best features from web, product, and onchain analytics into one versatile platform. Save time and money from having to manage your own data infrastructure and dashboards.

Formo makes it easy to digest web3 data, streamlining data collection, processing, and analysis for data-driven product teams. Unify offchain & onchain data with web3-native product analytics to get full onchain attribution. Understand who your users are and how they engage with your app with powerful wallet intelligence.

Focus on building amazing onchain experiences. Leave the data engineering to us.

Key Features

Here’s a quick overview of what Formo can do: product analytics, wallet intelligence, and forms.

Say hello to Web3-native Product Analytics:

Growth analytics: Track visitor counts, DAU, WAU, MAU, transactions, retention, and churn. Measure engagement and growth over time.
Real-time activity feed: See what users are doing in real-time. Uncover hidden drop-off points and retention drivers.
Onchain Attribution: Identify the top channels and growth initiatives that drive onchain activity. Understand where users come from.
Privacy-friendly: No third-party cookies, no IP, and no fingerprinting. Just clear, privacy-friendly insights. Formo helps your dapp align with GDPR standards and avoid collecting unnecessary data.
Lightweight: Formo’s tracking script ensures your site remains fast.

Wallet intelligence activates your high-intent users and whales:

Wallet profiles: Turn anonymous wallets into high-value users with unified onchain and offchain data. Track usage of specific, high-value wallets on your dapp.
Wallet scoring: Use wallet labels, onchain attestations, and proof-of-personhood to segment and rank your users.
Wallet holdings: View your users’ token holdings and top apps. Uncover users using similar apps.

Token Gated Forms helps you effortlessly launch waitlists, forms, and surveys:

Verified socials: Verify Twitter accounts, Discord usernames, Farcaster, and more.
Token gating: Capture wallet data, token balances, attestations, and other onchain signals.
Zapier integration: Connect Formo with thousands of other apps to get things done faster.

Formo handles the data so you can focus on building

Formo makes analytics for onchain apps easy.

Spend less time building analytics and more time building products. Get data superpowers with the data platform designed for crypto-native teams:

Resilient Infrastructure: Zero-maintenance, high-reliability data pipelines built on a modern data engineering stack. Formo uses industry-leading technologies such as Clickhouse and data streaming.
Universal Data Access: Capture web2 and web3 data as standardized event schemas with the Formo SDK. Easily track attribution from initial engagement offchain to transactions onchain.
No-code Analytics: Formo eliminates the need for a dedicated data team of SQL wizards to create dashboards and data pipelines.

Leading crypto teams use Formo to drive growth and impact onchain. Understand your onchain users, where they come from, and what they do so you can build a better product.

Next steps

Create a workspace

Install Formo

Install Formo. The Formo SDK supports Browser, React, and Next.js.

Success!

Light up the dark forest with Formo. Book a demo or learn more.

Onchain is the New Online

2024-09-02T00:00:00+00:00

gm! It’s been a long while. 👋

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

What’s happening?

In the past year, consumer dapps have driven substantial growth in unique active wallets.

Web3 social apps are no longer a niche use case. Farcaster and Lens are breaking records in user activity.

Prediction markets entered the mainstream

Last month, Polymarket, an onchain prediction market, saw a massive increase in activity with a volume of $472.87 million and over 50,000 active users.

Stablecoins are everywhere, with TradFi joining in

Stablecoins are experiencing rapid growth.. Today, 56% of Fortune 500 companies are working on on-chain projects. Stablecoins now process more than twice as much transaction value as Visa every month. Bitcoin ETFs counts $63b in assets under management. BlackRock & Fidelity have launched tokenized Treasury products with nearly $1b in assets combined. Stripe now allows its merchants to accept payments in Ethereum, Solana, & Polygon without transaction fees. PayPal’s stablecoin has more than $0.5b in assets.

This trend continues as stablecoin APIs are laying more and more crypto rails. I believe stablecoin-based products will replace traditional payment networks. It’s already faster (days vs seconds) and cheaper (10s of dollars vs cents). It will bring billions of new users onchain.

Blockchains are now scalable

On the infrastructure side, network fees are at an all-time low thanks to the Dencun upgrade and new L2s. Today, builders can deploy new consumer-friendly rollups in a few clicks with Conduit and Caldera.

Usability in web3 is getting better

Embedded wallets and social logins are ubiquitous, enabling seamless UX for new users. Builders can onboard users with Privy and Dynamic.

These are all promising adoption signals. We are at the cusp of a new crypto consumer wave in web3, but…

What’s next?

Building a successful consumer product is hard. According to Binance Research, web3 has yet to break into the mainstream:

Average retention rate in web3 stands at 5.4%. Web2 retention rates are significantly higher, with a good rate considered between 25-40%.
A prime example of crypto’s retention struggles is seen in Starknet, where user retention fell sharply from 18.0% post-March to just 4.3%. This decline was likely driven by the conclusion of their airdrop campaign, illustrating the limited impact of speculative incentives on long-term engagement.

The data indicates that beyond broadening crypto’s reach to mainstream audiences, we must expand crypto’s adoption frontier beyond mere speculation and profit-making purposes. This means creating compelling consumer crypto products that generate intrinsic demand and keep users engaged.

We need better tools

In the 2010s Hubspot and Mixpanel transformed online marketing and product analytics respectively. Analytics tools like theirs made it easier for internet builders to understand and use data about online users. Alongside them came a wave of web2 consumer apps we still use today.

Building a successful consumer product is hard. It gets harder when you don’t know who your users are and how they use your product. Analytics and data tools are fundamental for the success of consumer apps. Soon they will play a critical role in consumer crypto.

For the next while, I’ve decided to focus on solving challenges at the intersection of blockchain, data, and product analytics.

Are you building in web3? Say hi.

How to Replace the Bytecode of Deployed Solidity Contracts

2022-08-07T00:00:00+00:00

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 we want to replace the oracle contract in our unit tests with a local mock.

// Our own mock IOracle contract, for testing purposes
contract MockOracle is IOracle {
  ...
}

First, we deploy our oracle contract locally with Hardhat:

const MockOracle = await ethers.getContractFactory("MockOracle");
const mockOracle = await MockOracle.deploy();

Next, we need to replace the bytecode in IOracle(0x773616E4d11A78F511299002da57A0a94577F1f4) with our MockOracle:

We use the Ethereum JSON-RPC API eth_getCode() to get bytecode of the newly deployed contract.
Then, we use Hardhat’s eth_setCode() to substitute the contents of the hardcoded address:

const code = await hre.network.provider.send("eth_getCode", [
  mockOracle.address,
]);
await hre.network.provider.send("hardhat_setCode", [
  "0x773616E4d11A78F511299002da57A0a94577F1f4",
  code,
]);

In the above snippet, we get the bytecode of our deployed contract and set it to MyOracle and set it to the hardcoded IOracle address.

That’s it! We now know how to change the bytecode of an existing contract for testing purposes. This feature lets you write more exhaustive tests and ship well-tested smart contracts.

Bubbling Up Errors in Solidity

2022-07-16T00:00:00+00:00

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?

Low-level calls do not revert

First of all, it’s important to know that a low-level call or delegatecall doesn’t revert while calling a function that reverts:

// These won't revert even if the target contract reverts!
(bool success, bytes memory result) = target.call(data);
(bool success, bytes memory result) = target.delegatecall(data);

In the above example, when contract A calls contract B with a low-level call, The success variable signals whether the call was successful (true) or unsuccessful (false).

Using this, we could revert in the calling contract like so:

contract A {
  function foo(address target, bytes data) external {
    (bool success, bytes memory result) = target.delegatecall(data);
    require(success);
  }
}

However, the above code swallows any errors returned from the target contract! We don’t know what went wrong because no errors are bubbled up even though contract B reverts.

Bubbling up errors

Let’s examine the following solution:

(bool success, bytes memory result) = address(this).delegatecall(data);
if (!success) { // If call reverts
  // If there is return data, the call reverted without a reason or a custom error.
  if (result.length == 0) revert();
  assembly {
    // We use Yul's revert() to bubble up errors from the target contract.
    revert(add(32, result), mload(result))
  }
}

An inline assembly block is marked by assembly { ... }, where the code inside the curly braces is code in the Yul language.
result is a dynamic-size byte array. If the external contract call fails, the error object is returned in result.
The Yul revert function takes in two inputs: 1) the pointer of where the error byte array starts, and 2) how long the byte array is.
For dynamic-size byte arrays, the first 32 bit of the pointer stores its size.
- To fill in 1), we do add(32, result) to calculate the pointer where the byte array starts.
- To fill in 2), we do mload(result) to retrieve this value.
- Combining the above, we get revert(add(32, result), mload(result)), which reverts the error raised in contract B.
When there is no revert data returned by the target contract, we terminate early with an empty revert.

Now, when you call contract B from contract A you get the following revert message:

"AccessForbidden(0x123...)"

In unit tests, you can write the following (with Hardhat):

it('reverts', async function () {
  await expect(
    myContract.foo(TEST_ADDRESS, TEST_BYTES),
  ).to.be.revertedWith('AccessForbidden()');
});

Nice! By bubbling up errors we ensure that contracts do not fail silently and fail with additional context when they are available.

Auditing Smart Contracts with Slither and Echidna

2022-02-20T00:00:00+00:00

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.

Thank you for reading.

Note that automated tools cannot replace manual code analysis and review from experienced smart contract security experts. However, they do help you move in the right direction by highlighting important best practices and common security vulnerabilities. An audit remains a critical step that a protocol should undergo before going live.

Utilizing these tools in your development workflow helps you write more secure contracts so fewer security issues remain before the audit phase.

Background

I’m Yos, a Solidity engineer. I recently participated in the Secureum smart contract security audit bootcamp (and ranked in the Top 25 out of 1000 participants.) The 3 month+ program ends with a practical component where the top participants would audit a real protocol, review the code, and raise any security vulnerabilities over the course of a month.

Auditors generate a summarized report for the project team that highlights their findings ranked by severity from high to low, as well as exploit details and recommended mitigations. I applied a combination of manual code analysis based on Solidity best practices and security vulnerabilities alongside automated tools to audit Solidity smart contracts.

The open source tools we’re about to cover in this article (Slither and Echidna) are frequently used by top smart contract auditors to supplement manual code analysis. They help automate the process of reviewing code quality and correctness in an increasingly sophisticated smart contract ecosystem.

In the rest of this article, we’ll first learn about common security pitfalls and how an audit helps, before finally jumping into the tools: Slither and Echidna.

Common Security Pitfalls

Smart contract bugs occur more frequently than it should, with hefty consequences for everyone involved, for both users and project teams.

Common real-world security vulnerabilities include:

Inadequate access controls (giving malicious actors access to sensitive operations)
Invalid input sanitation (failing to prevent exploits)
Incorrect inheritance (leading to other issues)
Arithmetic errors (underflow and overflow errors)
Business logic errors (failing to match technical specifications)
Non-conformance to standards (e.g. ERC20 return values)
External interactions with other contracts (e.g. flashloans, ERC777 callbacks, transfer fee ERC20 tokens, etc.)
State machine traps leading to locked contracts (e.g. invalid balances reverting require statements)
And many others

Even the smallest of smart contract bugs can render the largest of DeFi products useless or open to exploits. This is exacerbated by the fact that most smart contracts are difficult or impossible to upgrade.

How can we mitigate the risk of smart contract bugs and exploits? Can we identify and fix these issues before we launch?

Smart Contract Audits

A smart contract audit is an external security assessment of a project codebase, typically requested and paid-for by the project team. For most projects, the scope is typically the on-chain smart contract code and occassionally any critical off-chain components that interact with the contracts.

The goal of an audit is to assess and alert the project team, typically before launch, of potential security-related 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 (such as the ones highlighted above.) The auditor will share their findings of underlying vulnerabilities, severity, difficulty, sample exploit scenarios, and recommended mitigations. The project team will fix these issues and review them with the auditor before moving forward with the launch.

Here are some examples of audit reports.

Smart Contract Security Tools

Alongside manual code review, smart contract auditing tools automate many of the tasks that can be codified into rules with different levels of coverage, correctness and precision. They enable the auditor to cover more ground and focus on high-level design review.

They are fast, cheap, scalable and deterministic compared to manual analysis.
They are a snapshot of distilled smart contract security knowledge.
Well-suited to detect common security pitfalls and best-practices at the Solidity and EVM level.
With manual assistance, they can be programmed to check for application-level, business-logic constraints.

Note that automated tools are a supplement, not a replacement for security expertise and manual code analysis by experienced smart contract developers. Interpreting the outputs of these tools demand some level of familiarity with Solidity.

In the next section, we’ll learn about the following smart contract security auditing tools:

Slither, a static analysis tool for Solidity code.
Echidna, a fuzz testing tool.

You’ll learn about what they are, what they’re used for, and how you can start using them to audit Solidity smart contracts.

Slither

Slither is a static analysis tool for Solidity code. It takes in one or more contracts and generates a list of security vulnerabilities and other best-practice recommendations.

Static analysis is a technique of analyzing program properties without actually executing the program. This is in contrast to software testing where programs are actually executed with different inputs. Static analysis typically is a combination of control flow and data flow analyses.

Examples of other static analysis tools are ESLint for Javascript and Solhint for Solidity.

Slither performs control-flow and data-flow analyses on smart contracts in the context of their set of detectors which encode common security pitfalls and best-practices. It comes with 70+ built-in detectors covering issues such as uninitialized variables, inheritance, access control, and structural issues. You can also add your own detector functions to look for specific patterns.

Here’s an excerpt of Slither’s built-in detectors:

When you run slither on a contract like so:

slither contracts/strategies/AaveStrategy.sol

Slither will enumerate over each detector and generate a report:

BaseStrategy._swap(uint256[],address[],address).i (contracts/BaseStrategy.sol#312) is a local variable never initialized
UniswapV2Library.getAmountsOut(address,uint256,address[]).i (contracts/libraries/UniswapV2Library.sol#73) is a local variable never initialized
Reference: https://github.com/crytic/slither/wiki/Detector-Documentation#uninitialized-local-variables

AaveStrategy._harvest(uint256) (contracts/strategies/AaveStrategy.sol#77-81) ignores return value by aaveLendingPool.withdraw(address(strategyToken),uint256(amountAdded),address(this)) (contracts/strategies/AaveStrategy.sol#80)
AaveStrategy._withdraw(uint256) (contracts/strategies/AaveStrategy.sol#83-85) ignores return value by aaveLendingPool.withdraw(address(strategyToken),amount,address(this)) (contracts/strategies/AaveStrategy.sol#84)
AaveStrategy._exit() (contracts/strategies/AaveStrategy.sol#87-97) ignores return value by aaveLendingPool.withdraw(address(strategyToken),tokenBalance,address(this)) (contracts/strategies/AaveStrategy.sol#92)
AaveStrategy._exit() (contracts/strategies/AaveStrategy.sol#87-97) ignores return value by aaveLendingPool.withdraw(address(strategyToken),available,address(this)) (contracts/strategies/AaveStrategy.sol#95)
AaveStrategy._harvestRewards() (contracts/strategies/AaveStrategy.sol#99-104) ignores return value by incentiveController.claimRewards(rewardTokens,reward,address(this)) (contracts/strategies/AaveStrategy.sol#103)
Reference: https://github.com/crytic/slither/wiki/Detector-Documentation#unused-return

In each section are the line number of the problematic code as well as reference links to details about the issue:

You can use this information to learn about Solidity best practices and mitigate common security vulnerabilities. However, bear in mind that Slither will generate false positives or non-issues. Determining which issues are relevant requires some familiarity with Solidity and smart contract security.

In addition to general reporting, Slither also comes with a set of printers which helps you inspect your contract’s inheritance tree and variable dependencies.

You can run a printer like so:

slither MyContract.sol --print [printer name]

For example, the vars-and-auth printer gives you a useful summary of modifiers and variable dependencies for your contracts:

Contract Ownable
Contract vars: ['_owner']
Inheritance:: ['Context']

+----------------------------+------------+---------------+----------------+------------+---------------------------------------+----------------+
|          Function          | Visibility |   Modifiers   |      Read      |   Write    |             Internal Calls            | External Calls |
+----------------------------+------------+---------------+----------------+------------+---------------------------------------+----------------+
|        _msgSender()        |  internal  |       []      | ['msg.sender'] |     []     |                   []                  |       []       |
|         _msgData()         |  internal  |       []      |  ['msg.data']  |     []     |                   []                  |       []       |
|       constructor()        |  internal  |       []      |       []       |     []     |      ['_msgSender', '_setOwner']      |       []       |
|          owner()           |   public   |       []      |   ['_owner']   |     []     |                   []                  |       []       |
|    renounceOwnership()     |   public   | ['onlyOwner'] |       []       |     []     |       ['onlyOwner', '_setOwner']      |       []       |
| transferOwnership(address) |   public   | ['onlyOwner'] |       []       |     []     | ['onlyOwner', 'require(bool,string)'] |       []       |
|                            |            |               |                |            |             ['_setOwner']             |                |
|     _setOwner(address)     |  private   |       []      |   ['_owner']   | ['_owner'] |                   []                  |       []       |
+----------------------------+------------+---------------+----------------+------------+---------------------------------------+----------------+

The above is useful for auditors to quickly review if access control modifiers are correctly implemented.

Running the inheritance-graph, cfg, call-graph printers generates visualizations of your contract’s inheritance tree, control flow graph and more. For example, an inheritance tree:

In summary, Slither is a low-cost static analysis tool that you can simply run on your contracts. It helps detect common vulnerabilities and enforce known best practices. Slither Printers are helpful to review a contract’s structure in detail.

Slither analyzes contracts within seconds. However, static analysis often leads to false positives and is not suitable for complex checks against high-level proxies and business logic. For that, we have Echidna.

Echidna

If we model smart contracts as state machines, we want to make sure that no invalid state can be reached. This usually means that there’s inadequate input sanitation or a business logic error somewhere in our code.

Echidna can help us detect invalid state machines. Echidna is a fuzz testing tool for Solidity code.

Fuzz testing is an automated software testing technique that involves providing invalid, unexpected, or random data as inputs to a computer program. The program is then monitored for exceptions such as crashes, failing built-in code assertions, or potential memory leaks.

Echidna work as follows:

You start by writing invariants, or high-level properties about your system. For example, an invariant of a stablecoin or DeFi lending protocol may be ‘undercollateralied vaults should always be open for liquidation.’ This is expressed as boolean Solidity expressions like so:

Next, Echidna will then call your contracts with a pseudo-random generation of transactions, where it will try to find a sequence of transactions to violate your invariants.
Finally, if Echidna manages to break an invariant, it will give you the list of contract calls (state transitions) that it used to get there.

In summary, Echidna is a higher cost, but also higher impact tool compared to Slither.

Echidna requires more time investment than Slither (it takes longer to run, and needs high-level invariants written by humans) but will only produce true positives. The true positives Echidna discovers are usually significant and extreme corner cases missed even by the best manual analyses.

In addition, The act of writing invariants helps ensures key system invariants to be documented and tracked somewhere. As the codebase grows, Echidna tests makes sure that there are no regressions in the contracts’ state machine over time.

Echidna Exercise

Learn by doing and try running Echidna on these sample contracts I’ve written. Each contract has a security vulnerability that needs to be fixed. See if you can identify the underlying issue with Echidna and fix it. Then, rerun Echidna to fuzz test and verify that your fix is correct.

// Sample insecure contract

pragma solidity ^0.7.6;

contract Token {
    mapping(address => uint) public balances;

    function transfer(address to, uint value) public {
        balances[msg.sender] -= value;
        balances[to] += value;
    }
}

contract EchidnaTest is Token {
    address echidna_caller = 0x00a329C0648769a73afAC7F9381e08fb43DBEA70;

    constructor() {
        balances[echidna_caller] = 10000;
    }

    // add the property
    function echidna_test_balance() view public returns(bool){
        return balances[echidna_caller] <= 10000;
    }
}

I recommend checking out Crytic’s guidelines to fully utilize these open source tools.

Summary

Over the course of this article, we learned to:

Recognize the impact of smart contract bugs,
Review the latest attack vectors and best practices,
Use Slither to catch common issues,
Use Echidna to test high-level properties,
And finally, ship contracts with confidence.

Start with Slither’s built-in detectors to ensure that no simple bugs are present now or will be introduced later. Use Slither to check properties related to inheritance, variable dependencies, and structural issues. As the codebase grows, use Echidna to test more complex properties of the state machine.

Now you too can write more secure contracts by using Slither and Echidna to audit your Solidity code!

Easy, Instant Mocks for Solidity Contracts

2021-09-18T00:00:00+00:00

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.

Are you new to smart contracts? Check out the open source Hardhat starter kit! It comes with several useful tools preconfigured such as Typescript, type generation, linting, formatting, and test coverage. Just hit clone and run!

Instant Mocks with Waffle / Smock

You can instantly create mocks with the Waffle (or Smock) testing libraries. Just provide the ABI of the smart contract you want to mock:

// Waffle example

import { deployMockContract } from '@ethereum-waffle/mock-contract';
import contractABI from '../artifacts/MyContract.json'

// Set up mock contract
const myContract = await deployMockContract(wallet, contractAbi);

You can set the return values for any of your mock’s functions with mock.<nameOfMethod> helpers:

// You can mock specific functions, down to specific inputs
await myContract.mock.<nameOfMethod>.returns(<value>)
await myContract.mock.<nameOfMethod>.withArgs(<arguments>).returns(<value>)

You can also set up reverts using reverts() and revertsWithReason() helpers:

await myContract.mock.<nameOfMethod>.reverts()
await myContract.mock.<nameOfMethod>.revertsWithReason(<reason>)
await myContract.mock.<nameOfMethod>.withArgs(<arguments>).reverts()
await myContract.mock.<nameOfMethod>.withArgs(<arguments>).revertsWithReason(<reason>)

Behind every mock is a real smart contract (with actual Solidity code!) This means you can modify the behavior of individual functions, and leave some functions unmocked. Any values from mocked calls will pass through to be used in the actual contract code.

Full Example

Let’s try to mock the following contract:

interface IERC20 {
    function balanceOf(address account) external view returns (uint256);
}

contract MyContract {
    IERC20 private token;
    uint private constant THRESHOLD = 1000000 * 10 ** 18;

    constructor (IERC20 _token) public {
        token = _token;
    }

    function check() public view returns (bool) {
        uint balance = token.balanceOf(msg.sender);
        return balance > THRESHOLD;
    }
}

In our unit tests, we will to mock the token.balanceOf() function to return specific values. Mock contracts will be used to supply exactly the values we need to test different scenarios of the MyContract.check() method.

Here’s our unit test using mocks:

describe("Mocking example", function () {
  beforeEach(async function () {
    this.signers = {} as Signers;
    const signers: SignerWithAddress[] = await hre.ethers.getSigners();
    this.signers.owner = signers[0];
    this.signers.receiver = signers[1];

    const MyContractArtifact: Artifact = await hre.artifacts.readArtifact('MyContract');
    this.contract = <MyContract>await deployContract(this.signers.owner, MyContractArtifact, []);

    const ERC20Artifact: Artifact = await hre.artifacts.readArtifact('MyContract');
    this.token = await deployMockContract(this.signers.owner, ERC20Artifact.abi);
  });

  it('returns false if the wallet has less then 1000000 coins', async () => {
    await this.token.mock.balanceOf.returns(utils.parseEther('999999'));
    expect(await this.contract.check()).to.be.equal(false);
  });

  it('returns true if the wallet has at least 1000000 coins', async () => {
    await this.token.mock.balanceOf.returns(utils.parseEther('1000001'));
    expect(await this.contract.check()).to.equal(true);
  });

  it('reverts if the ERC20 reverts', async () => {
    await this.token.mock.balanceOf.reverts();
    await expect(this.contract.check()).to.be.revertedWith('Mock revert');
  });

  it('returns 1000001 coins for my address and 0 otherwise', async () => {
    await this.token.mock.balanceOf.returns('0');
    await this.token.mock.balanceOf.withArgs(this.signers.owner.address).returns(utils.parseEther('1000001'));

    expect(await this.contract.check()).to.equal(true);
    expect(await this.contract.connect(this.signers.receiver.address).check()).to.equal(false);
  });
});

That’s it!

Summary

Mocks are most effectively used when you need some behavior of a real smart contract but still want the ability to modify things on the fly.

Use the ethereum-waffle (or smock) testing libraries to instantly mock smart contracts, all without writing mock contracts yourself.

Real World Contract Development with Forked Mainnet

2021-09-11T00:00:00+00:00

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.

Mock Contracts

A common approach to interfacing with third-party contracts at development time is with a Mock contract. Short of deploying the entire third-party protocol yourself, this seems like a low-hanging fruit. Here’s an example Mock contract you might write in place of the real thing:

contract MockContract {
  string public mockValue;

  // Mocked function
  function greet() public view returns (string memory) {
    return mockValue;
  }

  // Function to change mock value for test cases
  function setMockGreet(string newMockValue) {
    mockValue = newMockValue;
  }
}

However, Mock contracts comes with some drawbacks:

You need to spend time to rewrite existing third-party contracts as mocks. To get exhaustive mock coverage, you’ll end up rewriting whole protocols for the sake of testing.
There’s a parity risk where your mock contract’s API or behaviour may not match what’s on production. Mocks are ultimately simplified models of the real thing. As DeFi protocols continue grow in complexity, it’s simply not possible to simulate every single side effect using mocks.
As both contracts and your mocks grow in complexity, additional development effort is required to enable each mocked function to be configurable.

Mock contracts are a common approach to smart contract development, but are limited in many ways. The time you spent on your mocks is time better spent on your own contracts. So how can we do better? Can we use real-world building blocks during the development phase?

Let’s consider an alternative to mock contracts: forking mainnet.

Forking Mainnet

Instead of writing Mock contracts, you can fork mainnet. As its name suggests, this means running a copy of the production network locally. Forking mainnet gives you full access to a snapshot of the Mainnet network with all its building blocks, all ready for use.

Forking mainnet is easy and straightforward. With Hardhat, you can connect to a mainnet fork by updating your hardhat.config.ts:

const config: HardhatUserConfig = {
  defaultNetwork: "hardhat",
  networks: {
    hardhat: {
      accounts,
      chainId: 31337,
      forking: {
        url: process.env.MAINNET_RPC_URL,
      },
    },
    mainnet: {
      url: process.env.MAINNET_RPC_URL,
      accounts,
      chainId: 1,
    },
  }
}

Enabling mainnet forking is as simple as adding the following lines:

forking: {
  url: "https://eth-mainnet.alchemyapi.io/v2/<key>",
  blockNumber: 11095000,
},

Here are the forking parameters:

url: Your RPC url should point to a node with archival data for this to work. Alchemy is a good free option. Note that you are not limited to Ethereum mainnet (you can work with a fork of Kovan or other networks.)
blockNumber: Pinning a block number enables caching. Every time data is fetched from mainnet, Hardhat caches it on disk to speed up future access. You can get massive speed improvements with block pinning. If you intend to set up automated CI tests, pinning is a must.

Are you new to smart contracts? Check out the open source Hardhat starter kit! It comes with several useful tools preconfigured such as Typescript, type generation, linting, formatting, and test coverage. Just hit clone and run!

Now that you have a local instance of mainnet protocols, setting them in a specific configuration for your tests need is your likely next step. Let’s look at how to do that.

Impersonating as other accounts

While connected to a forked mainnet, you can call contract functions as another account. This ‘impersonation’ feature is especially useful to prepare specific contract states for your tests. For example, you may want to act as a MakerDAO vault owner or a Uniswap liquidity provider, and operate on contracts on their behalf.

Here’s an impersonation example:

  it("example test case", async function () {
    const impersonatedAddress = '0x...'

    // Impersonate as another address
    await hre.network.provider.request({
      method: "hardhat_impersonateAccount",
      params: [impersonatedAddress],
    });
    const impersonatedSigner = await ethers.getSigner(impersonatedAddress);

    // Make contract call as an impersonated address
    await MyContract.connect(impersonatedSigner).doSomething(...);

    ...
  });

In the above test case:

First, we make a hardhat_impersonateAccount call with an Ethereum address to impersonate another address
This lets us make a contract call as if we were the impersonated account with connect(impersonatedSigner) on the MyContract contract. Impersonation lets you bypass ownership msg.sender checks.
Contract calls made here will apply any state changes locally.

Compared to mocking contracts, forking mainnet comes with several advantages:

You’re working with contracts whose APIs and behaviour are an exact match of what’s on production. There’s no parity risk.
As protocols continue to grow in complexity and composition, writing mocks for them becomes less and less feasible. Forking mainnet continues to be useful as it lets you capture all downstream side effects locally.
Forking mainnet consumes much less development time compared to writing mock contracts.

That’s it!

Summary

Interfacing with other protocols is a key part of smart contract development. You now know how to interface with mainnet contracts at development time, in a more efficient & robust way without using mock contracts.

How to Write Gas Efficient Contracts in Solidity

2021-05-17T00:00:00+00:00

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!

Storage Layout in Solidity

When state variables of Solidity contracts are stored in storage, they are stored in a compact way such that multiple values sometimes use the same storage slot. Except for dynamically-sized arrays and mappings, data is stored contiguously as 32-byte words, item after item starting with the first state variable, which is stored in slot 0.

The size of each variable is determined by its type. Here is a summary of Solidity value types and their size in bytes:

type	bytesize
bool	1
bytes1	1
bytes8	8
bytes32	32
address	20
contract	20
uint8	1
uint16	2
uint32	4
uint128	16
uint256	32
int256	32

Here’s an example of how a contract’s storage might be laid out:

In Example #2, multiple variables of value types may share a storage slot, within which each variable only takes up as much space as it need to.

Any items with a size under 32 bytes are packed into a single storage slot if possible, according to the following rules:

Value types use only as many bytes as are necessary to store them.
If a value type does not fit the remaining part of a storage slot, it is stored in the next storage slot.
Structs and array data always start a new slot, but their items are packed tightly according to these rules.
Items following struct or array data always start a new storage slot.

In short, optimizing storage layout in Solidity is like trying to pack items into the least number of boxes. The less boxes we need, the better.

Inspecting Storage Layout

Before we proceed, we need a way to inspect what our contracts’ storage layout looks like.

The storage layout of a contract can be viewed in the Standard JSON interface files which comes from the Solidity compiler. The output file is a JSON object containing two keys, storage and types:

{
    "storageLayout": {
      "storage": [],
      "types": {}
    }
}

If you’re using Hardhat, you can find these files in the artifacts/build-info/ directory that’s generated when you run hardhat compile.

Let’s inspect these two fields more closely. We’ll inspect the storage layout of the following Solidity contract:

contract MyContract { address owner; }

The storage field for the above contract is an array where each element has the following form:

"storage": [{
    "astId": 2,
    "contract": "contracts/MyContract.sol:MyContract",
    "label": "owner",
    "offset": 0,
    "slot": "0",
    "type": "t_address"
}]

Each storage element contain the following fields:

astId is the id of the AST node of the state variable’s declaration
contract is the name of the contract including its path as prefix
label is the name of the state variable
offset is the offset in bytes within the storage slot according to the encoding
slot is the storage slot where the state variable resides or starts. This number may be very large and therefore its JSON value is represented as a string.
type is an identifier used as key to the variable’s type information (described in the following)

In addition to the storage, the JSON file contains types. In the following example, t_uint256 represents an element in types, which has the form:

"types": {
  "t_address": {
    "encoding": "inplace",
    "label": "address",
    "numberOfBytes": "20"
  }
}

You can inspect the storage and types fields to understand how much space each type consumes and how they are packed. Here’s a larger example:

"types": {
  "t_address": {
    "encoding": "inplace",
    "label": "address",
    "numberOfBytes": "20"
  },
  "t_bool": {
    "encoding": "inplace",
    "label": "bool",
    "numberOfBytes": "1"
  },
  "t_uint96": {
    "encoding": "inplace",
    "label": "uint96",
    "numberOfBytes": "12"
  }
  "t_struct(MyInfo)476_storage": {
    "encoding": "inplace",
    "label": "struct MyContract.MyInfo",
    "members": [
      {
        "astId": 471,
        "contract": "contracts/MyContract.sol:MyContract",
        "label": "account",
        "offset": 0,
        "slot": "0",
        "type": "t_address"
      },
      {
        "astId": 473,
        "contract": "contracts/MyContract.sol:MyContract",
        "label": "balance",
        "offset": 20,
        "slot": "0",
        "type": "t_uint96"
      },
      {
        "astId": 475,
        "contract": "contracts/MyContract.sol:MyContract",
        "label": "alive",
        "offset": 0,
        "slot": "1",
        "type": "t_bool"
      }
    ],
    "numberOfBytes": "64"
  }
}

In the above file, we can see that:

An address takes up 20 bytes
A boolean takes up 1 byte
A uint96 takes up 12 bytes
A struct MyInfo occupies 64 bytes, and has 3 variables packed inside it:
- address account takes up 20 bytes, in slot 0
- uint96 balance takes up 12 bytes, starting from offset 20 and still in slot 0
- bool alive takes up 1 byte in slot 1, because slot 0 is already full at 32 bytes

You can generate and use this report to inspect how your contracts’ storage is laid out. Try it out with some dummy contracts!

Armed with this knowledge, let’s learn some tips to optimize our Solidity contracts!

Tip #1: Variable packing

Reading and writing from each storage slot cost gas. Packing variables lets us reduce the number of slots our contract needs.

To allow the EVM to optimize your storage layout, make sure to order your storage variables and struct members such that they can be packed tightly. For example, instead of declaring your storage variables in the order of:

// First approach

uint128, // 16 -> slot 0 16/32
uint256, // 32 -> slot 1 32/32 (doesn't fit slot 0)
uint128 // 16 -> slot 2 16/32

you can do:

// Second approach

uint128, // 16 -> slot 0 16/32
uint128, // 16 -> slot 0 32/32 (fits slot 0)
uint256 // 32 -> slot 1 16/32

The first approach results in no variable packing. It takes up three storage slots.

In comparison, the second approach benefits from variable packing and takes only two slots.

Here’s another variable packing example:

In short, group Solidity variables into chunks of 32-byte words to optimize gas usage.

Tip #2: `uint256` can be cheaper than `uint8`

When using types that are smaller than 32 bytes such as uint8, your contract’s gas usage may in some cases be higher than if you use uint256.

This is because the EVM operates on 32 bytes at a time. The EVM will still occupy 256 bits, fill 8 bits with the uint variable and fill the extra bites with zeros. Therefore, if the element is smaller than that, the EVM has to do more operations to convert the element between 32 bytes and the desired size.

It might be beneficial to use smaller-size types if you can get the compiler to pack multiple types into one storage slot (see the previous section on Variable packing), and thus, combine multiple reads or writes into a single operation.

However, if you are not reading or writing all the values at the same time, this can have the opposite effect. When defining a lone variable, it can be more optimal to use a uint256 rather than uint8.

Tip #3: Use `bytesN` instead of `bytes[]`

The value types bytes1 … bytes32 hold a sequence of bytes from one to up to 32. You should use bytes over bytes1[] because it is cheaper, since bytes1[] adds 31 padding bytes between the elements. Due to padding rules, this wastes 31 bytes of space for each element.

If you can limit the length to a certain number of bytes, always use one of the value types bytesN because they are more gas efficient.

Tip #4: Use fixed-size `bytes32` instead of `string` / `bytes`

Fitting your data in fixed-size 32 byte words is much cheaper than using arbitrary-length types. Remember that bytes32 uses less gas because it fits in a single EVM word. Basically, Any fixed size variable in solidity is cheaper than dynamically sized ones.

Tip #5: Write to `storage` last

Only update storage variables with the final results of your computation, after all intermediate calculations instead of at each step. This is because operations on storage is more expensive than operations on memory / calldata.

Let’s look an example contract:

pragma solidity ^0.8.0;

contract Test {
  uint internal count;

  function A() public {
      for (uint i = 0; i < 10; i++){
          count++; // Writes to storage at every intermediate step
      }
  }

  function B() public {
      uint j;
      for (uint i = 0; i < 10; i++){
          j++;
      }
      count = j; // Writes only the final result to storage
  }
}

In the sample code above, function B() is more gas-efficient than A() because it does less storage writes. Use local variables to store your intermediate results, and write to storage last.

Here is a cost comparison:

SSTORE (saving a 32-byte word to storage): 22100 gas when storage value is set to non-zero from zero, OR 5000 gas when the storage value’s zeroness remains unchanged or is set to zero. This assumes first-time access.
SLOAD (loading a word from storage): 2100 gas on first-time access, 100 gas if already accessed
MSTORE (saving a word to memory): 3 gas
MLOAD (loading a word from memory): 3 gas

As you can see, the difference is potentially massive. Minimize writes to storage and do them last. Note that are numbers are post-Berlin upgrade numbers (EIP 2929.)

You might also notice that ‘cold’ reads on the EVM are more expensive than ‘warm’ reads. This is yet another reason for miniziming the number of storage slots and variable packing (Tip #1.)

Tip #6: Free up unused storage

You get a gas refund when you ‘empty out’ variables. Deleting has the same effect as reassigning the value type with the default value, such as the zero address for addresses and 0 for integers.

uint internal count;

delete count; // Clears count to the default uint value (0)

Deleting a variable refunds 15,000 gas up to a maximum of half the gas cost of the transaction.

Tip #7: Use `constant` and `immutable` keywords

Add constant and immutable type annotations to variables:

contract C {
    bytes32 constant MY_HASH = keccak256("abc");
    address immutable owner;

    constructor() public {
        owner = msg.sender
    }
}

Reading constant and immutable variables is no longer considered a storage read (SSTORE) because it uses EXTCODE* opcodes instead which is much cheaper.

Tip #8: Cache storage values in memory

Anytime you are reading from storage more than once, it is cheaper to cache variables in memory. An SLOAD cost 100 GAS while MLOAD and MSTORE only cost 3 GAS.

This is especially true in for loops when using the length of a storage array as the condition being checked after each loop. Caching the array length in memory can yield significant gas savings when the array length is high.

// Before
for(uint 1; i < approvals.length; i++); // approvals is a storage variable

// After
uint memory numApprovals = approvals.length;
for(uint 1; i < numApprovals; i++);

Tip #9: Cache external values in memory

When making repeated external calls when the values between calls do not change, cache the values:

// Before
require(core.controller().hasRole(core.controller().MANAGER_ROLE(), msg.sender));

// After
IController memory controller = core.controller();
require(controller.hasRole(controller.MANAGER_ROLE(), msg.sender));

Tip #10: > 0 is more expensive than != 0 for unsigned integers

!= 0 costs 6 less GAS compared to > 0 for unsigned integers in require statements with the optimizer enabled. Learn more.

// Before
require(_value > 0);

// After
require(_value != 0);

Tip #11: Splitting require() statements that use && saves gas

Instead of using the && operator in a single require statement to check multiple conditions,using multiple require statements with 1 condition per require statement will save 3 GAS per &&:

// Before
require(result >= MIN_64x64 && result <= MAX_64x64);

// After
require(result >= MIN_64x64);
require(result <= MAX_64x64);

Tip #12: ++i costs less gas compared to i++ or i += 1

++i costs less gas compared to i++ or i += 1 for unsigned integers. This is because the pre-increment operation is cheaper (about 5 GAS per iteration).

i++ increments i and returns the initial value of i. This means:

uint i = 1;
i++; // == 1 but i == 2

In the first example, the compiler has to create a temporary variable (when used) for returning 1 instead of 2.

In contrast, ++i returns the actual incremented value:

uint i = 1;
++i; // == 2 and i == 2 too, so no need for a temporary variable

This tip is applicable for loops as well.

Tip #13: Shorten require messages to less than 32 characters

Strings that are more than 32 characters will require more than 1 storage slot, costing more gas. Consider reducing the message length to less than 32 characters or use error codes:

// Before
require(value > 2, "This require statement message exceeds thirty two characters.");

// After
require(value > 2, "A201")

Tip #14: Use Custom Errors instead of Revert Strings to save Gas

Consider replacing revert strings with custom errors. Custom errors from Solidity 0.8.4 are cheaper than revert strings (cheaper deployment cost and runtime cost when the revert condition is met.)

function withdraw() public {
    if (msg.sender != owner)
        revert Unauthorized();

    owner.transfer(address(this).balance);
}

Starting from Solidity v0.8.4, there is a convenient and gas-efficient way to explain to users why an operation failed through the use of custom errors. Until now, you could already use strings to give more information about failures (e.g., revert(“Insufficient funds.”);), but they are rather expensive, especially when it comes to deploy cost, and it is difficult to use dynamic information in them.

Tip #15: Usage of uint8 may increase gas cost

When using elements that are smaller than 32 bytes, your contract’s gas usage may be higher. This is because the EVM operates on 32 bytes at a time. Therefore, if the element is smaller than that, the EVM must use more operations in order to reduce the size of the element from 32 bytes to the desired size. The EVM needs to properly enforce the limits of this smaller type.

It is only beneficial to use reduced-size arguments if you are dealing with storage values because the compiler will pack multiple elements into one storage slot, and thus, combine multiple reads or writes into a single operation. When dealing with function arguments or memory values, there is no inherent benefit because the compiler does not pack these values.

Using smaller-size uints such as uint8 is only more efficient when you can pack variables into the same storage slot, such as in structs. In other cases and in loops, uint256 is more gas efficient than uint8.

Tip #16: Non-strict inequalities are cheaper than strict ones

In the EVM, there is no opcode for non-strict inequalities (>=, <=) and two operations are performed (> + =.) Consider replacing >= with the strict counterpart >:

// Before
require(value >= 2);

// After
require(value > 3);

Tip #17: Use `external` instead of `public` where possible

Functions with the public visibility modifier are costlier than external. Default to using the external modifier until you need to expose it to other functions within your contract.

contract Test {

    string message = "Hello World";

    // Execution cost: 24527
    function test() public view returns (string memory){
         return message;
    }

    //Execution cost: 24505
    function test2() external view returns  (string memory){
         return message;
    }
}

Tip #18: `internal` functions are cheaper than `public`

If a function is only callable by other functions internally, specify it as internal. Internal functions are cheaper to call than public functions.

- function _foo() public {...}
+ function _foo() internal {...}

Tip #19: Enable the Solidity Gas Optimizer

Set the Solidity optimizer runs value to a low number to optimize for contract deployment costs. Alternatively, set the optimizer to a high number to optimize for run-time gas costs when functions are called on a contract.

module.exports = {
  solidity: {
    version: "0.8.16",
    settings: {
      optimizer: {
        enabled: true,
        runs: 1000,
      },
    },
  },
};

Tip #20: Skip initializing default values

When Solidity variables are not set, they refer to a set of default values:

address = address(0)
uint256 = 0
bool = false

Gas is spent when you unecessarily initialize variables to its default value:

uint256 foo = 0; // bad
uint256 bar; // better

Tip #21: Short circuit expensive operations

Short-circuiting works by ordering the lower-cost operation first so that the higher-cost operation is skipped if the first operation evaluates to true. For example:

// f(x) is low cost
// g(y) is expensive

// Ordering should go as follows
f(x) || g(y)
f(x) && g(y)

Summary

In this post, we learned:

How storage is laid out in Solidity contracts
How to inspect the storage layout of your contracts
Patterns and techniques to optimize the gas usage of your contracts

Keep in mind that storage optimization techniques can run counter to code readability. When in doubt, be sure to aim for a balance between efficiency and readability.

Recently

2020-07-31T00:00:00+00:00

Recently is a periodic retrospective.

Reading
Listening

Reading

Highlights

Curse of Knowledge: The inability to communicate your ideas because you wron gly assume others have the necessary background to understand what you’re talking about.

Base-Rate Neglect: Assuming the success rate of everyone who’s done what you’re about to try doesn’t apply to you, caused by overestimating the extent to which you do things differently than everyone else.

Hard-Easy Effect: Hard tasks promote overconfidence because the rewards are high and fun to dream about; easy tasks promote underconfidence because they’re boring and easy to put off.

Hedonic Treadmill: Expectations rise with results, so nothing feels as good as you’d imagine for as long as you’d expect.

Positive Illusions: Excessively rosy views about the decisions you’ve made to maintain self-esteem in a world where everyone makes bad decisions all the time.

Ostrich Effect: Avoiding negative information that might challenge views that you desperately want to be right.

Fluency Heuristic: Ideas that can be explained simply are more likely to be believed than those that are complex, even if the simple-sounding ideas are nonsense. It occurs because ideas that are easy to grasp are hard to distinguish from ideas you’re familiar with.

The only true authority stems from knowledge, not from position. Knowledge engenders authority, and authority engenders respect – so if you want respect in an egoless environment, cultivate knowledge.

Don’t be “the coder in the corner.” Don’t be the person in the dark office emerging only for soda. The coder in the corner is out of sight, out of touch, and out of control. This person has no voice in an open, collaborative environment. Get involved in conversations, and be a participant in your office community.

Fight for what you believe, but gracefully accept defeat. Understand that sometimes your ideas will be overruled. Even if you are right, don’t take revenge or say “I told you so.” Never make your dearly departed idea a martyr or rallying cry.

Follow the principles of extreme ownership.

You need to face the consequences of your mistakes and learn from your mistakes. If you don’t make mistakes, you won’t learn anything, and you won’t grow up

Novelty is a risk. Too much of it, and you’re almost certain to fail. But too little of it and you’re just a redundant copy of someone else — which is also a recipe for failure.

Be curious. Read widely. Try new things. What people call intelligence just boils down to curiosity.

We should all work on projects that interest us, where we have insights that others don’t have, and that motivate and inspire us and others.

You must work on something that inspires you and others, you must work on something with a significant impact, and you must do it in a way that makes getting where you want to go as easy as possible and keeps you there as long as possible.

If you can teach yourself how to solve problems, you have a bright career ahead of yourself. No matter where you live, you will find problems galore in need of solving. Those who would benefit from solutions of their problems will pay you handsomely to solve them.

Take initiative: The most common misconception in software is that there are grown-ups out there who are on top of things. Own your team’s and company’s mission. Don’t wait to be told; think about what needs doing and do it or advocate for it. Managers depend on the creativity and intelligence of their engineers, not figuring it all out themselves.

Unblock yourself: Learn to never, ever accept being blocked; find a way by persuasion, escalation, or technical creativity. Again, your job isn’t just to write the code and wait for everything else to fall into place; your job is to figure out how to create value with your efforts.

Own your project management: Understand the dependency graph for your project, ensure key pieces have owners, write good summaries of plans and status, and proactively inform stakeholders of plans and progress. Practice running meetings! All this enables you to take on much bigger projects and is great preparation for leadership.

Own your education: Pursue mastery of your craft. Your career should be a journey of constant growth, but no one else will ensure that you grow. Find a way to make learning part of your daily life (even 5 minutes/day); get on mailing lists, find papers and books that are worth reading, and read the manual cover to cover for technologies you work with. Consistency is key; build habits that will keep you growing throughout your career.

Communicate proactively: Regular, well-organized communication builds confidence and goodwill in collaborators; knowledge-sharing creates an atmosphere of learning and camaraderie. Shar e knowledge and set a regular cadence of informing stakeholders on project goals, progress, and obstacles. Give talks and speak up judiciously in meetings.

The key observation is that while your technical programming ability may plateau, the impact of your technical contributions doesn’t have to. Your ability to decide where to spend your efforts to maximize your impact — what code to write, what software to build, and which business problems to tackle — is unbounded. It’s this ability that distinguishes the most valuable and effective engineers from everyone else.

What makes for a world-class software engineer is the ability to consistently deliver business value. Effectively communicate with the non-technical stakeholders and be the bridge between technology and business goals. Make sure they’re aware of pros and cons of every development related decision.

You identify and solve problems that are core to the business, or you enable those around you to more effectively solve those core business problems. It’s in this alignment of your technical efforts with business value that your career grows.

Yos Riady · Software Craftsman

Building for Onchain Builders

Introducing Formo

Next Steps

Actionable Insights for Onchain Apps

The biggest challenges in web3

High barriers for onchain attribution and profiling

Onchain data is an untapped wealth of insights

Formo makes it easy to digest web3 data

Key Features

Formo handles the data so you can focus on building

Next steps

Onchain is the New Online

What’s happening?

Decentralized social is booming

Prediction markets entered the mainstream

Stablecoins are everywhere, with TradFi joining in

Blockchains are now scalable

Usability in web3 is getting better

What’s next?

We need better tools

How to Replace the Bytecode of Deployed Solidity Contracts

Bubbling Up Errors in Solidity

Low-level calls do not revert

Bubbling up errors

Auditing Smart Contracts with Slither and Echidna

Background

Common Security Pitfalls

Smart Contract Audits

Smart Contract Security Tools

Slither

Echidna

Echidna Exercise

Summary

Easy, Instant Mocks for Solidity Contracts

Instant Mocks with Waffle / Smock

Full Example

Summary

Real World Contract Development with Forked Mainnet

Mock Contracts

Forking Mainnet

Impersonating as other accounts

Summary

How to Write Gas Efficient Contracts in Solidity

Storage Layout in Solidity

Inspecting Storage Layout

Tip #1: Variable packing

Tip #2: uint256 can be cheaper than uint8

Tip #3: Use bytesN instead of bytes[]

Tip #4: Use fixed-size bytes32 instead of string / bytes

Tip #5: Write to storage last

Tip #6: Free up unused storage

Tip #7: Use constant and immutable keywords

Tip #8: Cache storage values in memory

Tip #9: Cache external values in memory

Tip #10: > 0 is more expensive than != 0 for unsigned integers

Tip #11: Splitting require() statements that use && saves gas

Tip #12: ++i costs less gas compared to i++ or i += 1

Tip #13: Shorten require messages to less than 32 characters

Tip #14: Use Custom Errors instead of Revert Strings to save Gas

Tip #15: Usage of uint8 may increase gas cost

Tip #16: Non-strict inequalities are cheaper than strict ones

Tip #17: Use external instead of public where possible

Tip #18: internal functions are cheaper than public

Tip #19: Enable the Solidity Gas Optimizer

Tip #20: Skip initializing default values

Tip #21: Short circuit expensive operations

Summary

Recently

Table of Contents

Reading

Highlights

Listening

Tip #2: `uint256` can be cheaper than `uint8`

Tip #3: Use `bytesN` instead of `bytes[]`

Tip #4: Use fixed-size `bytes32` instead of `string` / `bytes`

Tip #5: Write to `storage` last

Tip #7: Use `constant` and `immutable` keywords

Tip #17: Use `external` instead of `public` where possible

Tip #18: `internal` functions are cheaper than `public`