Welcome to the first Macro alumni interview! In conducting these interviews we hope to provide insight into what kind of problems developers are solving in web3, as well as learn about tips and tricks they use in their everyday work.

Where do you work and what team are you on?

I’m a Core Contributor at Synthetix, and I primarily focus on V3

Tell us about what libraries and tech-stacks you’re working with :)

Everything is open source. Synthetix’s stack is primarily Solidity with Hardhat and React with ethers. There are some subgraphs and various off-chain tools (typically written in Typescript) as well.

Synthetix uses Cannon and Synpress, both maintained by Core Contributors. I’m also a fan of Chakra UI, Foundry, wagmi, and Rainbowkit.

What types of problems do you solve day-to-day at your job?

Fundamentally, the engineers implement SIPs, though many are involved in authoring them as well. At a high level, the core contributors and the broader Synthetix community work to improve all aspects of the protocol including user experience, developer experience, scalability, capital efficiency, cross-chain functionality, composability, resilience, security, and decentralization.

What is the coolest thing you've shipped in web3? What was cool about it?

I built Cannon with dbeal and mjlescano for the most recent ETHDenver hackathon, where it was a winner in the infrastructure and scalability track. Cannon is a tool to specify protocol deployments with Cannonfiles (inspired by Dockerfiles) and package deployment data. And, since Foundry added functionality to import and export a chain state, it’s super fast.

It’s cool to work on dev tools because you need to do some “meta” thinking about software engineering. The design decisions in the tools need to be opinionated enough to be useful, but flexible enough to accommodate software design patterns that might not even be in use yet. We’re still actively developing Cannon while using it with Synthetix, and we’re interested in gathering more feedback/pull requests from the broader web3 community.

Tell us about something you’ve had to troubleshoot recently, and what tools or techniques you brought to bear on the problem.

Nothing interesting enough to share comes to mind, but I’ll usually reach for Tenderly first if something weird is going on.

Seasoned web2 engineers are very familiar with implementing the "-ilities" (maintainability, extensibility, scalability and so on) in a web2 context. How have you found these system characteristics to play out in a web3 context?

I think there’s a fantasy that you can just write an immutable smart contract, deploy it, and then walk off into the sunset with your bags of cash. Maybe this works in some cases but, even without upgradeability proxies, during development you’re typically doing multiple deployments to local and test networks, performing automated and manual QA, tracking issues, adding features, and iterating. At the end of the day, it’s just software engineering so all of these more abstract concerns are just as applicable.

What excited you about web3 when you first took the plunge, and what excites you about the space now?

If you like building things, web3 is exciting because there’s still so much to improve! The dev tools are very immature compared to web2. And even the most basic use cases for crypto—like storing and sending assets—are only just now catching up to TradFi services like Venmo in terms of user experience.

The pace is also very stimulating. The space is evolving rapidly, with many smart people shipping quickly and large amounts of money at stake. Assuming everything becomes more robust and usable, I’d anticipate that the creation of a fully permissionless financial system will be considered one of the most significant technological breakthroughs in my lifetime.

What aspects of your pre-Macro experience prepared you for the work you're doing?

I was previously working on a TradFi fintech start-up which helped me better understand the contours of the problem space that crypto/DeFi is addressing. If you’re exclusively a consumer of fintech, it’s not obvious how much could go into something like an ACH transfer, let alone that there could be viable alternatives.

How did your experience at Macro prepare you for the real work you're doing?

Macro did a great job of highlighting real use cases for smart contracts and relevant security considerations. Solidity syntax and patterns were covered throughly, but it was especially valuable to dig into the idiosyncrasies of blockchain development and the practical applications of protocols.

What tips would you give to a web2 developer who is looking to join the web3 space?

Most legit projects are open source and have active Discord servers. Build stuff relevant to whatever you’re most interested in and share it with the people involved.

Huge shoutout to Noah for joining us as the first Macro alumni interview :) If you enjoyed the read and want to keep up with Noah, considering following him on twitter.

If you have thoughts on how we can improve these interviews in the future, feel free to DM me.

Thanks for reading!

Fuzzing is a well-known technique in the security industry to discover bugs in software — invalid, unexpected, or random data is generated automatically and injected into the software to find issues.

In the context of smart contract security, fuzzing tools are relatively new but are gaining more attraction recently. It is pivotal that a smart contract — with its immutable character — is tested thoroughly before any deployment to production. Having an adequate test coverage of your code using unit tests is essential, but there will always be edge cases you did not test for. Thus, it is best practice to extend your testing strategy by using additional security tools, such as static analyzers and fuzzers.

After reading this blog post, you should gain the following takeaways:

• The core component of an audit is a manual review — this is where you catch the most bugs.
• Fuzz tests can be very useful for catching edge cases.
• There are different tools available for fuzz testing. One of the better-known tools is Echidna.
• Have a basic understanding of how Echidna works.

Before introducing Echidna in more detail, here is a list of the more popular security-testing tools available today:

1. Slither – static analysis tool (developed by TrailOfBits)
https://github.com/crytic/slither

2. Manticore – uses symbolic execution to detect vulnerabilities (developed by TrailOfBits)
https://github.com/trailofbits/manticore

3. Scribble – allows one to annotate a smart contract with properties and raises exceptions when the property is violated.
https://github.com/ConsenSys/scribble

4. MythX – uses symbolic execution to detect vulnerabilities (developed by Consensys)
https://mythx.io/

5. Mythril – paid cloud service that includes static analysis, symbolic analysis, and fuzzing (developed by Consensys)
https://github.com/ConsenSys/mythril

6. Foundry support for fuzz testing
https://book.getfoundry.sh/forge/fuzz-testing.html

7. Dapptools support for fuzz testing
https://github.com/dapphub/dapptools/tree/master/src/dapp#property-based-testing

8. Certora - paid service that uses formal verification
https://www.certora.com/

9. Echidna – fuzzing tool (developed by TrailOfBits)
https://github.com/crytic/echidna

In the next chapter we will go deeper into Echidna, a program written in Haskell by the security experts from Trail of Bits.

Echidna

Echidna uses a style of fuzzing called property-based fuzzing. Instead of looking for crashes like a traditional fuzzer, Echidna tries to break user-defined invariants (a.k.a. properties).

Invariants are properties of the program state that are expected to always be true. These invariants have to be manually written in Solidity, as opposed to writing unit tests in Javascript. Currently, Echidna does not support automated fuzz tests.

Once these invariants are defined, Echidna tries to falsify these invariants by generating random sequences of calls to the contract.

Enough theory for now — let’s look at the code.

Installation

Run Echidna by using pre-compiled binary:
https://github.com/crytic/echidna/releases/tag/v2.0.2

or

Another neat way to run Echidna is by using the trailofbits eth-security-toolbox docker image:
https://github.com/trailofbits/eth-security-toolbox

Example 1

Consider the following contract (similar vulnerability as Ethernaut’s Fal1Out challenge).

// ICO.sol
contract ICO {
    bool is_paused;
    address owner = msg.sender;

    function IC0() public {
        owner = msg.sender;
    }

    modifier isOwner() {
        require(owner == msg.sender);
        _;
    }
		
    function resume() public isOwner {
      is_paused = false;      
    }
}

The resume() function can only be called by the owner of the contract. Let’s write a fuzz test to see if Echidna can find a way to break the contract and set the is_paused variable to true:

import "./ICO.sol";

// ICOFuzzTest.sol
contract ICOFuzzTest is ICO {

    constructor() public {
        is_paused = true;
        owner = address(0x0);
    }

    function echidna_test_pause() public view returns (bool) {
        return is_paused == true;
    }
}

Initialization code goes into the constructor. In the above code, is_paused is set to true and the owner is set to 0x0.

Next, we write the test which defines that is_paused should always return true. Note that for executing the tests, Echidna randomly uses the following caller addresses: 0x10, 0x20, and 0x30. In other words, the above test says that there shouldn’t be any way for the caller addresses to set the is_paused variable to false.

Note: All fuzz tests must start with echidna_ in order for Echidna to pick them up.

To start the fuzz test, run the following:

echidna-test ICOFuzzTest.sol --contract ICOFuzzTest

Echidna immediately returns the result:

The test failed, as Echidna found a way to falsify the invariant by making the following calls:

1. IC0()
2. resume()

To the trained eye, the vulnerability was pretty obvious. The IC0() function is not a valid constructor as it is written with the number ‘0’ instead of the letter ‘O’. In addition, with Solidity > 4.21 you need to define the constructor using the constructor keyword instead of using the contract name.

As IC0() is a normal function and is lacking an access modifier, it can be called by anyone to gain ownership. After gaining ownership, the resume function can be called to set is_paused to true.

As simple as the above example was, it clearly demonstrates how Echidna works — it automatically generates arbitrary transactions (with random input) to test the invariant.

Example 2

Consider the following contract:

pragma solidity 0.7.0;

contract Pausable {
    bool is_paused;

    function paused() public {
        is_paused = true;
    }

    function resume() public {
        is_paused = false;
    }
}

contract Token is Pausable {
    mapping(address => uint256) public balances;

    constructor() {
        is_paused = true;
    }

    function transfer(address to, uint256 value) public {
        require(!is_paused);

        uint256 initial_balance_from = balances[msg.sender];
        uint256 initial_balance_to = balances[to];

        balances[msg.sender] -= value;
        balances[to] += value;

        assert(balances[msg.sender] <= initial_balance_from);
        assert(balances[to] >= initial_balance_to);
    }
}

Note that the above code uses Solidity version 0.7.0. For Solidity version 0.8.0 and above the compiler has built in underflow/overflow checks but for older versions you need to take care of it yourself.

In the previous Example 1 we used the “property” testing mode. Echidna supports other testing modes such as “assertion” and “dapptest” (see here). In this example, we run Echidna in “assertion” testing mode. Hereby, Echidna looks out for Solidity assertions in your code and tries to falsify them by generating random transactions and inputs.

To start the fuzz test in “assertion” mode run:

echidna-test Token.sol --test-mode assertion --contract Token

Echidna prints out the following result:

It checked every function for assertions and found 1 test that failed in the transfer(…) function.

Can you figure out why?

The test failed by making the following call:

1. resume()
2. transfer(0x0, 1)

Echidna first called resume to set is_paused = false which is necessary to enter the transfer function. In the 2nd step, transfer was called with the parameters 0x0 for the to address and 1 for the value. The interesting line that brought the test to fail is this:

balances[msg.sender] -= value;

The balance for msg.sender is 0 and gets decreased by 1. This results in an underflow that is not handled as we are using Solidity version 0.7.0. As a consequence, balance of msg.sender will be set to the maximum number of uint256. This behavior breaks the first assertion

assert(balances[msg.sender] <= initial_balance_from);

as now the new balance is much higher than the initial one.£

The easiest way to avoid the above issue is to use Solidity 0.8.0 or higher. If for whatever reason you can’t do that, the 2nd best option is to use OpenZeppelin’s SafeMath library.

The best way to start with Echidna is at its official Github page. For advanced configuration and further examples, visit this tutorial page.

Alternatives to Echidna

Scribble

Scribble is a so-called specification language that allows you to annotate your smart contracts with properties. In a second step, Scribble transforms the annotations into Solidity code with concrete assertions.

The aim of Scribble is to have one universal annotation language for defining your fuzz tests and then to reuse this between different tools.

(Source: https://docs.scribble.codes/)

The above picture shows that Scribble can be used with fuzzing tools like Mythril and MythX (likely because all of these three tools have been developed by Consensys).

As Scribble compiles the annotations into simple Solidity assertions, it should also be possible to use Scribble in combination with Echidna, using the “assertion” testing mode (see here). Please reach out to us if you have experience with this setup!

Foundry

Foundry has become more and more popular over the recent months (see here).

So if Foundry is already your development framework of choice, you don’t have to look further. Foundry has built-in support for fuzz testing. When using Foundry, you already write your unit tests in Solidity. If the test function takes at least 1 parameter, then Foundry automatically runs the test as a property-based fuzz test (see here).

The approach Foundry follows is similar to writing fuzz tests with Echidna but quite different to the annotation-based approach Scribble uses.

While both Foundry and Echidna fall under the same category of property-based fuzzing, Echidna uses more advanced techniques like generating random transactions with random inputs and also keeps track of those transactions to achieve high coverage. On the other hand, Foundry focuses on generating random inputs for your test functions and has support for excluding certain values.

Final Thoughts

Nobody said it’s going to be easy!

Writing fuzz tests isn’t trivial. In the beginning, you will probably spend a lot of time writing meaningful tests — there is a deep learning curve. Additionally, there are a lot of different tools and setups available, and you must first find out what fits best for you and your team.

Nevertheless, the effort will pay off and will make your code more secure. As a builder or auditor, you should add fuzz tests to your toolbox.

References/Resources

A list of security tools:
https://github.com/ConsenSys/ethereum-developer-tools-list#security-tools
https://github.com/trailofbits/eth-security-toolbox

Fuzzing complex projects with Echidna: https://ventral.digital/posts/2021/12/21/fuzzing-complex-projects-with-echidna-sushi-bentobox

Comparison of Slither, MythX, Mythril, Manticore, SmartCheck: https://medium.com/@charingane/smart-contract-security-tools-comparison-4aaddf301f01

Scribble:
https://consensys.net/blog/news/introducing-scribble-by-consensys-diligence/
https://consensys.net/diligence/blog/2021/07/introducing-scribble-generator/

Patrick Collins:
https://github.com/PatrickAlphaC/hardhat-security-fcc
https://www.youtube.com/watch?v=TmZ8gH-toX0

Changes to be aware of

• block.difficulty has a new source
• Block times will be shorter by 1-2 seconds
• Less new ETH being added to the ecosystem
• Multi-block MEV == new possible attack vectors

block.difficulty has a new source

In Solidity's PoW era, the global variable block.difficulty existed as a way to access the current difficulty level of the PoW's algorithm. As we shift to PoS and no longer have a concept of 'work' we also no longer have a difficulty level to source block.difficulty from.

To keep the previous Solidity code functioning, the Ethereum Foundation decided to change block.difficulty's underlying opcode 0x44 to return a new PoS field named prevrandao.

In the PoS world, this value is produced by the beacon chain and is used to help determine who the next set of validators are in the block proposal and attestation process. The “prev" part of prevrandao is derived from its value being the previous block’s outputted randao value.

Do I need to take any action?

• If you were using block.difficulty to help create randomness in your code, firstly, don’t do this because it is not actually random. Ultimately, your code should run the same.
• If you were relying on block.difficulty to be in the previous PoW sensible range of 0-2^64, your code could break. block.difficulty will now range from 0-2^256.
• If you had specialized logic to have your contract act differently based on the block.difficulty level, your code will not behave as intended as block.difficulty is now pseudorandom with an increased range.
• Bonus: if you want to write up logic that behaves differently pre and post-merge, you can use block.difficulty's value to reasonably determine if the merge has occurred or not. Values less than 2^64 could be used to see that the chain is still PoW.

Can I use this newfangled prevrandao instead of the fancy techniques like Chainlink’s VRF when I want stronger randomness?

The consensus in the security community is a firm ‘no’. Use existing VRF infrastructure for security critical randomness needs.

Validators who are chosen to propose blocks will be able to know the value of prevrandao while selecting the transactions to construct their blocks out of. In other words, block proposers could choose to add or censor transactions if they find it beneficial to do so based on the current block’s value of prevrandao.

Block times will be shorter by 1-2 seconds

A common misconception about the merge is that it will result in noticeably more capacity. This is not true. Capacity will increase a tiny bit, as block times will decrease from an average of 13 seconds (with a wide variation) to almost exactly every 12 seconds. Important to note: blocks can be skipped if a validator goes offline or chooses to not submit a block when it is their turn. This currently happens < 1% of the time.

Do I need to take any action?

• If your code assumes a block cadence of 13 seconds, be prepared for it to run faster than expected.

Less new ETH being added to the ecosystem

According to the Ethereum Foundation, the change to PoS will slow down the creation of new Ether by a drastic amount: from a current 4.1% per year to a projected 0.3%-0.4% per year.

• In the current PoW system ~14,600 new ETH is produced and ~1,600 ETH is burned each day.
• In PoS, it’s projected that ~1,600 ETH will be produced and ~1,600 ETH will continue to be burned, resulting in a non-inflationary total ETH supply.

Do I need to take any action?

• This is a major change to the native currency in the ecosystem and could have large long-term impact on the value of ETH.
• If you are in the practice of hardcoding ETH values into your protocols, consider adding options in the future to change the required amount of ETH to interact with your projects.

Multi-block MEV == new possible attack vectors

In PoW it is prohibitively computationally expensive to know who the next miner of a block will be. This is changing dramatically in PoS: validators are selected and announced by the beacon chain in schedules of 32. Furthermore, according to FlashBots, it is possible that validator pools could have direct control over consecutive blocks.

Many PoW-era protocols rely on the security assumption that no one in the system can ensure that they will have control across multiple blocks. This has been used as a fundamental building block in protocol designs.

Take, for example, the common pattern of Automated Market Makers (AMMs). Protocols such as Uniswap use a time weighted average price (TWAP) across blocks to serve as a price oracle. If an actor can know that they will have control over a set of blocks, they could use this information to sway the TWAP price to exclusively benefit themselves.

Do I need to take any action?

• Exactly how and if MEV groups will use the new PoS architecture to create new market opportunities is an open question.
• Currently, the only courses of action are:

1. Be aware that new Multi-block MEV opportunities could come into existence using control over consecutive blocks, and
2. Adopt the new PoS protocol system designs which will emerge to accommodate the new security landscape.

Conclusion

The switch from PoW to PoS will be a substantial win for the Ethereum ecosystem but will not change your life as a Solidity developer in a major way.

Remember to:

• Practice good randomness hygiene
• Keep up to date on new MEV strategies, and
• Stay up to date for the Ethereum Foundation to roll out the rest of the planned next-gen Ethereum upgrades.

Extended Learnings

If reading this has tickled your curiosity and you are itching to learn more, we love that! Here are the sources that we used to construct this post to help you dive deeper:

• Ethereum’s previous and planned execution upgrades. This is the place to look to see which EIPs are planned to be included in the next upgrade. Here is the spec specific to the PoS ‘Paris’ upgrade.
• EIP-3675: Included in the Paris upgrade, this EIP explains all of the major changes to the execution environment required to change from PoW to PoS.
• EIP-4399: Also included in the Paris upgrade, this EIP changes the opCode 0x44 from returning the difficulty field to the prevrandao field. Solidity’s block.difficulty global variable compiles down to opCode 0x44.
• An information goldmine on how the beacon chain constructs the randao value which prevrandao refers to.
• An in-depth FAQ on the merge unrelated to Solidity changes. Useful as a starting source if you want to learn how to participate in staking ETH with a validator.
• A blog of all of the application layer changes due to the merge. Good to read if you’re responsible for more than just your protocol’s Solidity code.
• A fun web app showing the current and merge-simulated ETH issuance and burn rates.
• For the hardcore learners, here is one of the Ethereum Engineering Group’s information stuffed video on the PoW to PoS upgrade. This is an in-depth video directly from the people who are writing the EIPs for the merge.

Context

Synthetix’s StakingRewards is a battle-tested smart contract that distributes rewards to stakers. Synthetix has been a pioneer in DeFi and has established a well-audited standard for staking rewards that is used by many protocols across the Ethereum ecosystem.

Recently, Macro Audits did an audit of Sommelier’s cellar staking smart contract.

During the audit, one of Macro’s auditors, Abhishek Vispute, found a medium-to-low severity bug that, in certain cases, a portion of rewards can remain unused within the Sommelier's StakingRewards contract.

Macro Audits brought this issue to the attention of both the Sommelier and Synthetix teams.

This brief post summarizes the issue; and while the issue is not an exploitable bug, and therefore not a “must fix” issue, the Ethereum community should be made aware of it, in case your project — or another project you know of — is using the Synthetix StakingRewards contract.

As you may know, many projects either (a) fork the Synthetix StakingRewards contract or (b) implement a similar pattern. Therefore, we hope that sharing this issue will help any relevant projects out there.

Details can be found below. If you’re interested in working with Macro Audits, please contact us by filling out our Audit Request Form.

Summary

If stake() is not called in the same block of notifyRewardAmount(),

depending on delay, a portion of rewards will remain unused inside the contract.

Description:Let’s consider that you have a StakingRewards contract with a reward duration of one month seconds (2592000):

Block N             Timestamp = X

You call notifyRewardAmount() with a reward of one month seconds (2592000) only. The intention is for a period of a month, 1 reward token per second should be distributed to stakers.

State :

rewardRate = 1

periodFinish = X +**2592000**

Block M          Timestamp = X + Y

Y time has passed, and the first staker stakes some amount:

1.stake()
2. updateReward
rewardPerTokenStored = 0
lastUpdateTime = X + Y

Hence, for this staker, the clock has started from X+Y, and he or she will accumulate rewards from this point.

Please note, though, that the periodFinish is X + rewardsDuration, not X + Y + rewardsDuration. Therefore, the contract will only distribute rewards until X + rewardsDuration, losing  Y * rewardRate => Y * 1  inside of the contract, as rewardRate = 1 (if we consider the above example).

Now, if we consider delay(Y) to be 30 minutes, then:

Only 2592000-1800= 2590200 tokens will be distributed, and these 1800 tokens will remain unused in the contract until the next cycle of notifyRewardAmount().

Whenever a protocol starts a reward cycle, it intends to distribute X amount of rewards during that time.

If a certain amount remains unused (like the above example inside the contract), and a new reward cycle is not started, that amount remains dormant inside the contract.

Even if the given protocol decides to start a new reward cycle to cover this unused amount, it is a redundant execution.

As there will likely be a delay between the first stake and the reward cycle initiation, consider resolving this issue.

Recommended Remediation

Consider defining periodFinish in the first stake() that is done after notifyRewardAmount(), when total deposits are zero.

Check out how the Sommelier team tackled this issue with _startProgram():

cellar-contracts/CellarStaking.sol at afd970c36e9a520326afc888a11d40cdde75c6a7 · PeggyJV/cellar-contracts

Cellar Contracts for Sommelier. Contribute to PeggyJV/cellar-contracts development by creating an account on GitHub.

GitHubPeggyJV

One of those things is gas optimizations. On Ethereum, gas is very expensive. While we don't recommend going crazy for minimal savings, below is a list of low-hanging fruit you can apply to your contracts today.

💡 Also see Gas Numbers Every Solidity Dev Should Know

1. Packing of storage variables

Pack variables in one slot by defining them in a lower data type. Packing only helps when multiple variables of the packed slot are being accessed in the same call. If not done correctly, it increases gas costs instead, due to shifts required.

Before:

contract MyContract {
  uint32  x; // Storage slot 0
  uint256 y; // Storage slot 1
  uint32  z; // Storage slot 2
}

After:

contract MyContract {
  uint32 x;  // Storage slot 0
  uint32 z;  // Storage slot 0
  uint256 y; // Storage slot 1
}

2. Local variable assignment

Catch frequently used storage variables in memory/stack, converting multiple SLOAD into 1 SLOAD.

Before:

uint256 length = 10;

function loop() public {
    for (uint256 i = 0; i < length; i++) {
        // do something here
    }
}

After:

uint256 length = 10;

function loop() {
    uint256 l = length;

    for (uint256 i = 0; i < l; i++) {
        // do something here
    }
}

3. Use fixed size bytes array rather than string or bytes[]

If the string you are dealing with can be limited to max of 32 characters, use bytes[32] instead of dynamic bytes array or string.

Before:

string a;
function add(string str) {
    a = str;
}

After:

bytes32 a;
function add(bytes32 str) public {
    a = str;
}

4. Use immutable and constant

Use immutable if you want to assign a permanent value at construction. Use constants if you already know the permanent value. Both get directly embedded in bytecode, saving SLOAD.

contract MyContract {
    uint256 constant y = 10;
    uint256 immutable x;

    constructor() {
        x = 5;
    } 
 }

5. Using unchecked

Use unchecked for arithmetic where you are sure it won't over or underflow, saving gas costs for checks added from solidity v0.8.0.

In the example below, the variable i cannot overflow because of the condition i < length, where length is defined as uint256. The maximum value i can reach is max(uint)-1. Thus, incrementing i inside unchecked block is safe and consumes lesser gas.

function loop(uint256 length) public {
	for (uint256 i = 0; i < length; ) {
	    // do something
	    unchecked {
	        i++;
	    }
	}
}

6. Use calldata instead of memory for function parameters [Ref]

It is generally cheaper to load variables directly from calldata, rather than copying them to memory. Only use memory if the variable needs to be modified.

Before:

function loop(uint[] memory arr) external pure returns (uint sum) {
    for (uint i = 0; i < arr.length; i++) {
        sum += arr[i];
    }
}

After:

function loop(uint[] calldata arr) external pure returns (uint sum) {
    for (uint i = 0; i < arr.length; i++) {
        sum += arr[i];
    }
}

7. Use custom errors to save deployment and runtime costs in case of revert

Instead of using strings for error messages (e.g., require(msg.sender == owner, “unauthorized”)), you can use custom errors to reduce both deployment and runtime gas costs. In addition, they are very convenient as you can easily pass dynamic information to them.

Before:

function add(uint256 _amount) public {
    require(msg.sender == owner, "unauthorized");

    total += _amount;
}

After:

error Unauthorized(address caller);

function add(uint256 _amount) public {
    if (msg.sender != owner)
        revert Unauthorized(msg.sender);

    total += _amount;
}

8. Refactor a modifier to call a local function instead of directly having the code in the modifier, saving bytecode size and thereby deployment cost [Ref]

Modifiers code is copied in all instances where it's used, increasing bytecode size. By doing a refractor to the internal function, one can reduce bytecode size significantly at the cost of one JUMP. Consider doing this only if you are constrained by bytecode size.

Before:

modifier onlyOwner() {
		require(owner() == msg.sender, "Ownable: caller is not the owner");
		_;
}

After:

modifier onlyOwner() {
		_checkOwner();
		_;
}

function _checkOwner() internal view virtual {
    require(owner() == msg.sender, "Ownable: caller is not the owner");
}

9. Use indexed events as they are less costly compared to non-indexed ones [Ref]

Using the indexed keyword for value types such as uint, bool, and address saves gas costs, as seen in the example below. However, this is only the case for value types, whereas indexing bytes and strings are more expensive than their unindexed version.

Before:

event Withdraw(uint256, address);

function withdraw(uint256 amount) public {
    emit Withdraw(amount, msg.sender);
}

After:

event Withdraw(uint256 indexed, address indexed);

function withdraw(uint256 amount) public {
    emit Withdraw(amount, msg.sender);
}

10. Use struct when dealing with different input arrays to enforce array length matching

When the length of all input arrays needs to be the same, use a struct to combine multiple input arrays so you don't have to manually validate their lengths.

Before:

function vote(uint8[] calldata v, bytes[32] calldata r,  bytes[32] calldata s) public {
		require(v.length == r.length == s.length, "not matching");
}

After:

struct Signature {
        uint8 v;
        bytes32 r;
        bytes32 s;
    }

function vote(Signature[] calldata sig) public {
    // no need for length check
}

11. Provide methods for batch operations

If applicable, provide a method for batch action to users, reducing the overall gas costs.

For example: In the following case, if the user wants to call doSomething() for 10 different inputs. In the optimized version, the user would need to spend the fixed gas cost of the transaction and the gas cost for msg.sender check only once.

Before:

function doSomething(uint256 x, uint256 y, uint256 z) public {
		require msg.sender == registeredUser
		....
}

After:

function batchDoSomething(uint256[] x, uint256[] y, uint256[] z) public {
		require msg.sender == registeredUser
    loop
			_doSomething(x[i], y[i], z[i])
}
function doSomething(uint256 x, uint256 y, uint256 z) public {
		require msg.sender == registeredUser
		_doSomething(x, y, z);
}
function _doSomething(uint256 x, uint256 y, uint256 z) internal {
		....
}

12. Short-circuit with || and &&

For || and && operators, the second case is not checked if the first case gives the result of the logical expression.  Put the lower-cost expression first so the higher-cost expression may be skipped (short-circuit).

Before:

case 1: 100 gas
case 2: 50 gas

if(case1 && case2) revert 
if(case1 || case2) revert 

After:

if(case2 && case1) revert 
if(case2 || case1) revert 

General Rules

Optimize For

1. Common cases >> Rare cases

One should optimize for common cases. Optimizing for rare cases can increase gas costs for all other cases. For example, skipping balance update in case of 0 amount transfer.

As 0 amount transfer is not common, it doesn't make sense to add the cost of one condition for all other cases.

However, if the case is common, like transfer in case of infinite allowance, one should do it.

Unlimited ERC20 token allowance · Issue #717 · ethereum/EIPs

2. Runtime cost >> Deployment cost

Deployment costs are one-time, so always optimize for runtime costs.
If you are constrained by bytecode size, then optimize for deployment cost.

3. User Interaction >> Admin Interaction

As user interaction is most common, prioritize optimizing for it compared to admin actions.

Soon we will follow up with degen gas optimizations, which go to extreme lengths to save gas costs.

For example: Function Ordering, ≥ and > comparison, payable, address with leading zeros…

We hope you found this post helpful. If you want to get in touch with us to chat about audits, please click the link below:

Audits | Macro

References :

Some generic writeup about common gas optimizations, etc.

https://mudit.blog/solidity-gas-optimization-tips/

The Macro Audits team audited only 2 of Sommelier’s cellar-contracts, at commit hash: 4409661be89308e5c3a60f84e898bc068337b13d

1. CellarStakingRewards
2. AaveV2StablecoinCellar

CellarStakingRewards is an upgraded version of the OG Synthetix Staking Rewards, with unique features such as un-bonding, emergency actions, and locking boost.

AaveV2StablecoinCellar is an ERC4626 vault intended to optimize stablecoin yields on AAVE. As a user, one simply deposits stables into the cellar, and then the cellar takes care of rebalancing the stables so that the user gets the best possible yield.

In our first review of AaveV2StablecoinCellar, we found a significant number of issues originating from the use of inactive assets. The Sommelier team was already thinking of changing the approach of using inactive assets, and after seeing our reported issues, they diligently decided to take the time required to change the approach they were taking.

After the approach changed, we proceeded with our second review.

The report of our second audit can be found here.

We found 1 High, 3 Medium, 2 Low, 4 Informational, and 1 Quality Issues, as well as Several Gas optimizations.

For our first review, we didn't publish the report; the findings were shared with the Sommelier team and were fixed.

Regarding our interaction with the Sommelier team, we were satisfied with their technical capability and open-mindedness. They were comfortable with delaying their launch until both parties were satisfied, which is generally a good sign.

We can’t say that we are a catch-all service, as no audit is. Though we may miss some things, one thing we pride ourselves on is our effort and thoroughness. We had some good eyes going through the code, and we wish Sommelier the best for mainnet.

This is what Sam Patel, Head of Product @Sommelier Finance has to say:

This is what Kevin Kennis, Co-Founder @Sommelier Finance has to say:

If you are interested in an audit, check us out:

Audits | Macro

Macro is trusted by multiple leading industry names in Defi and Crypto for Smart Contract auditing.

Macro

https://0xmacro.com/audits

We will do our best to exceed your expectations.

So, what are some things we look for that makes an audit customer a good fit?

Overview

Here we offer a quick set of tips on how you can prepare your smart contract project for an audit. The goal is to make your project attractive to work with, even for the busy top smart contract audit firms.

1. Write Great Documentation ✍️
2. Write Great Tests 🧠
3. Prepare your Repo for the Audit 📐

1. Write Great Documentation ✍️

Quality of documentation is a major factor in how auditors assess your project. Too often do we see projects with little to no documentation.

Poor documentation makes it a pain to give a proper estimate for how long an audit would take. Not everything is deducible from the code, and even if it is, it's much faster and more accurate to get intent from the authors themselves.

Poor documentation may even lengthen the audit itself, either costing you more money, or leaving less time for a high quality audit.

With that said, great documentation usually has at least these:

• High level intentions, features, and goals. What are you trying to accomplish?
• Detailed use case descriptions. Who is using your protocol, and why?
• Explanations of technical decisions. Why did you take your approach?
• Architecture diagrams. How do components of the system interact?
• Perhaps most importantly, how the contracts in question fit in the overall system. We often see projects provide overall documentation, but then leave us to ask or figure out which parts of those docs apply to which contracts they want audited.

For an example of great documentation, see any of ThirdWeb's design docs, such as their marketplace contract docs.

2. Write Great Tests 🧠

It goes without saying that testing is critical to writing secure code. A project with a lack of tests is guaranteed to have problems, and is not something we're interested in booking.

Of course, testing does not catch all bugs either. But here are some quick tips for writing tests for smart contracts.

Test all use cases

This may seem obvious, but it needs to be said. Every use case needs a proper test. Don't miss a single one.

Ideally, each use case has an end-to-end test. This isn't strictly necessary when developing smart contracts, but doing so helps you iterate on your contract's ABI design, since you'd be using it in frontend code.

Test as many edge cases as possible

Missed edge cases are the primary reason smart contracts lose money. But it's almost impossible to think of them all by yourself, and you shouldn't treat auditors as a bug-free guarantee.

The best, low-hanging fruit you can do for your project today is introduce fuzz testing. Fuzz testing is essentially an automated way of finding edge cases in your code. It will try input combinations on your code that you'd never thought to test.

Fuzz testing is built into Foundry. Hardhat users are not completely out of luck, but they will need to learn and implement a tool like Echidna.

Achieve high test coverage

High test coverage is not an end-goal, but it is a decent measurement of health. Low test coverage means you certainly don't have enough tests. High test coverage means you might. 100% coverage is desirable for smart contracts, but beware, as even that won't even save you – we've found bugs in a project with 100% test coverage before!

Use solidity-coverage to measure your test coverage in your hardhat projects. Foundry users are currently out of luck, but may have access to superior mutation testing in the future.

3. Prepare your Repo for the Audit 📐

Handing your code to the auditor is not a simple matter of git push and link to GitHub. There are certain things that you should do to save everyone valuable time you're paying for.

Be code complete

Changes to code are inevitable. However, during the audit, you should not make major changes to the codebase – doing so may change the audit timeline, and could even require a full re-audit!

Fixes to the issues an auditor finds are usually covered, given they are not large enough to trigger the above.

Tag the commit you want audited

Adding a git tag on a commit helps ensure everyone is on the same page on what exactly is being audited.

When auditors find issues and you fix them, create another tag when those fixes are ready for review.

Clean up the codebase

Another seemingly-obvious point, but be sure to do things such as:

• Write Natspec docs for your external/public functions
• Document expected invariants
• Use standard terminology over "cute" or "creative" terminology (e.g. "LendingPool" over "DragonHoard")
• Comment on unconventional design choices
• Remove any commented out code / unused files

Conclusion

Audit bookings are hard to get. By following this advice, you'll make your project more attractive to auditors and more likely to get booked.

We hope you found this post helpful. If you want to get in touch with us to chat about audits, please click the link below:

Audits | Macro

Macro is trusted by multiple leading industry names in Defi and Crypto for Smart Contract auditing.

Macro

https://0xmacro.com/audits