DEV Community: Samarth Saxena

Mainnet Forking in Foundry

Samarth Saxena — Fri, 15 Nov 2024 15:53:25 +0000

Introduction

When developing smart contracts, we often need to interact with contracts that have already been deployed. It would not be a smart decision to deploy the contract and test it on Mainnet using real ETH. But, thankfully for us, there is a solution and that is what we will be covering in this guide. We'll keep it short and simple for now.

What is forking?

Forking in this context is very similar forking a GitHub repository. Just like you are able to get the entirety of the repo in your account and make changes to it without affecting the original repo, forking a blockchain makes its entire state up till the time of fork available to you for interaction locally without actually sending transactions to that chain. No changes are made to the state of the chain you fork from and all your interactions remain on your local blockchain node.

Forking any Network

The process of forking a chain is pretty simple in Foundry. All you need is an RPC URL for the network you want to fork. Mind you, if you use a public RPC, chances are that it won't contain the entire state of the blockchain up till that time and calling functions on contracts may not work as you'd expect them to. Moreover, you may get rate limited. If you have a key from QuickNode, Infura or other providers, you should use that instead.

For this example, we'll fork Ethereum Mainnet. Spin up a local blockchain node using Anvil like so:

anvil --fork-url mainnet_rpc_url

This might take more time than when we run just anvil, as it should, since we are connecting an RPC endpoint to our node for interacting with the state of the chain up till that point. All the transactions we perform after this will remain on our local anvil node, unless we specify that we want to send them to some other network.

Check if it worked

Let's see if we were able to successfully fork Ethereum Mainnet

cast block-number

For a node started using just anvil, ie. without the fork-url option, we would have received 0 as the output. But in our case, you should see something like this:

This is the block number at which the fork was created. So our local node can query the state of the blockchain upto this block in the live chain.

For further checking, let's try to see the balance of the account with the ENS name ben.eth, whose address is 0xcd2e72aebe2a203b84f46deec948e6465db51c75. Run this command in your terminal

cast balance 0x91364516d3cad16e1666261dbdbb39c881dbe9ee

If the result is 0, make sure you've followed all the steps correctly. If the result is 0 even after that, ben.eth's wallet probably got hacked and drained. Unfortunate.

A glimpse of what can be

When you want to run tests on the forked blockchain, you'll do so in the following manner:

function setUp() public { 
// vm is a variable included in the forge standard library that is used to manipulate the execution environment of our tests 
// create a fork of Ethereum mainnet using the specified RPC URL and store its id in mainnetFork 
mainnetFork = vm.createFork(MAINNET_RPC_URL); 
//select the fork thus obtained, using its id vm.selectFork(mainnetFork); 
//.... calls on contracts which exist on the forked chains}

Don't worry, we'll cover smart contract testing soon in this series. I added this snippet just to show you how what's possible.

Conclusion

That's it! You've successfully forked a live chain and called functions on it! In the next guide, we'll learn how to verify smart contracts using Etherscan's API via Foundry. Stay tuned till then. Thanks a lot for reading to the end. Bye for now👋👋

How to deploy smart contracts using Foundry

Samarth Saxena — Fri, 01 Nov 2024 13:09:45 +0000

Introduction

If you've been following this series so far, you already know how to write and compile smart contracts in Foundry. You also know how to use keystores to safely store and use your private keys. Now it is time to learn how you can deploy smart contracts. This article will cover both local and on-chain deployment.

Which way, Solidity dev?

There are two ways you can deploy your contracts using Foundry- the first is by using the forge create command and the second is by using Solidity scripts. Solidity scripting is a way to declaratively deploy contracts using Solidity, instead of using the more limiting and less user friendly forge create. If you are deploying a simple contract which has no constructor arguments and no reliance on other contracts that need to be deployed, it makes sense to just use forge create instead of making a separate script.

If you're coming from a Hardhat background, think of Solidity scripts as the scripts you write in Hardhat, except they're in Solidity instead of JavaScript, and they are run on the fast Foundry EVM backend, which provides dry-run capabilities.

We'll cover both ways in this article.

Initial Setup

If you haven't created a foundry project, go ahead and create one using this command:

forge init project-name

Open src/Counter.sol and add a constructor function to the contract

constructor (uint _initNumber){ number= _initNumber;}

Your final code should look like this:

// SPDX-License-Identifier: UNLICENSEDpragma solidity ^0.8.13;contract Counter { uint256 public number; constructor (uint _initNumber){ number= _initNumber; } function setNumber(uint256 newNumber) public { number = newNumber; } function increment() public { number++; }}

Navigate to your projects folder using your terminal and compile the contract like so:

cd project-nameforge build# you can also use forge compile

You should see something like this in your terminal:

We'll use anvil to start a local blockchain with chainId 31337. Go to your terminal and run:

anvil

You'll then see a list of accounts and their corresponding private keys which already have a balance of 10000 ETH on chain ID 31337. Copy one of these private keys, make a .env file in the root of your project and paste it there like so:

LOCAL_PRIVATE_KEY=thecopiedkey

We're not using keystores for local deployments since this is a known private key which everyone sees when using Foundry and is only used locally.

Now enter the URL of a Sepolia RPC endpoint in the .env file. I'm using a public RPC in this example:

SEPOLIA_RPC_URL=https://1rpc.io/sepolia

Now open your foundry.toml file. It should be present in the root of the project. At the end of the file, add:

[rpc_endpoints]sepolia = "${SEPOLIA_RPC_URL}"

This creates an RPC alias for Sepolia and provides cheatcodes to access the RPC endpoint we added.

Keep your anvil terminal running. Open a new terminal and run:

source .env

This updates your terminals environment variables and adds the ones we added in the .env file.

Awesome! Now let's see how we can deploy our contract

Deploying via forge create

The contract that needs to be deployed is a pretty simple one and it takes one constructor argument. Let's see how we can deploy it using forge create

Local Deployment

In your terminal, run:

forge create --rpc-url http://localhost:8545 --private-key $LOCAL_PRIVATE_KEY src/Counter.sol:Counter --constructor-args 23

We've specified the constructor argument as 23 here, so the value of number in our contract will be set to 23. If the transaction goes through, you'll see something like this:

Sepolia Deployment

This process is pretty similar to deploying locally. After all, we're only deploying to a chain which has a different ID. The only things we'll need are an account which has Sepolia ETH and an RPC URL. For accessing an account which has Sepolia ETH, we'll use keystores. We already set up one such account in the previous article and named it dev. You can read it here.

In your terminal, run this command:

forge create --rpc-url $SEPOLIA_RPC_URL --account dev src/Counter.sol:Counter --constructor-args 23

This time we're using our keystore, so it will ask you to enter its password. If you enter the right password and the transaction goes through, you'll see something like this:

Deploying via scripts

Open script/Counter.sol. For the most part, the required code is already written there. Lets go through it step-by-step

// SPDX-License-Identifier: UNLICENSEDpragma solidity ^0.8.13;import {Script, console} from "forge-std/Script.sol";import {Counter} from "../src/Counter.sol";contract CounterScript is Script { Counter public counter; function setUp() public {} function run() public { vm.startBroadcast(); counter = new Counter(); vm.stopBroadcast(); }}

The import statements get Script and console from the forge standard library, and the Counter contract we modified.

We then specify that the contract in this file inherits the Script contract from the forge standard library. Notice that everything in Foundry is a Solidity smart contract.

Then, we declare a new variable counter of the type Counter (our contract)

setUp is a function that runs every time we run a script. Since we don't have anything to set up right now, we'll leave this empty.

By default, scripts are executed by calling the function named run. In run, everything between vm.startBroadcast and vm.stopBroadcast creates transactions that can later be signed and sent on-chain- local, testnet, or mainnet.

If you have the right extensions for Solidity, you might be seeing an error in the line which creates a new instance of Counter.

This is because we now need to specify a value of type uint256 as the argument of our contracts constructor. Just add a number in the brackets like so:

counter = new Counter(2);

This will set the number to be 2 when the contract is deployed.

Local Deployment

Just run this command in your terminal:

forge script script/Counter.s.sol:CounterScript --fork-url http://localhost:8545 --broadcast --private-key $LOCAL_PRIVATE_KEY

Here http://localhost:8545 is the URL that is used to fetch the state of the local chain (id 31337) and then sending the transaction to it. You should see something like this:

and in the terminal running anvil:

Sepolia Deployment

Again, this process is pretty similar to deploying locally and we only need an account which has Sepolia ETH along with an RPC URL for Ethereum Sepolia. We'll use keystores for this case too.

Open your terminal and write:

forge script --chain sepolia script/Counter.s.sol:CounterScript --rpc-url $SEPOLIA_RPC_URL --broadcast --account dev

It will ask you to enter the password of the keystore (dev). If you enter the correct password, it attempts to send your transaction using the account corresponding to the keystore. If it succeeds, you'll get something like this

Conclusion

That's pretty much it! You now know how you can deploy your contracts locally and on-chain using keystores and environment variables. In the next lesson, we'll learn how we can fork Ethereum Mainnet to get the entire state of the blockchain locally. Sounds interesting? Well that's because it is! Stay tuned, see you all soon. Thanks a lot for reading to the end 🫡🫡

The best way to import your private key in Foundry

Samarth Saxena — Sat, 12 Oct 2024 08:42:07 +0000

Introduction

In my 2-something years of being a web3 dev, I've seen quite a lot of my frens and oomfs on Twitter lose all their funds because of one silly mistake: pushing their private keys to GitHub. It may sound like a very obvious and easy-to-avoid mistake but its more common than one may think. In this guide, we'll cover the most correct method of using your private key in Foundry. This method optimally balances convenience and safety. Let's get started!

Development Account

It is considered best practice to create a separate account in your wallet for development purposes and not add any Mainnet tokens to it. Wallets like MetaMask and Rainbow allow you to give names to your accounts, so make sure to give it a name like dev as it will help you to easily identify which account you're on. If you have to deploy a contract to Mainnet, add just enough funds to ensure your transaction goes through. This separation of accounts will prevent you from getting rugged even if your private key somehow gets leaked.

account with testnet funds

Keystores in Foundry

Cast will allow you to import your private key into an encrypted keystore. The command for doing this is:

cast wallet import account_name --interactive

It will then ask you to enter your private key. Once you do that, it will ask you to enter a password for that key. Whenever you want to use that key, you'll have to enter your password for authorization, so make sure you remember it. Once you've entered a password, it will be used to encrypt your private key and a keystore will be created. By default, its location will be ~/.foundry/keystores.

This method ensures that your private key is not stored in plaintext anywhere and can only be decrypted by someone who has its password. You can import more accounts in a similar fashion and for each one, you'll be asked to enter a corresponding password.

You can also import wallets by using their mnemonic phrases like so:

cast wallet import arbitrary_name --mnemonic "test test test test test test test test test test test test"

Using private keys

When you're deploying a contract, you will have to use your private key. For getting the list of available keystores, run this command in your terminal

cast wallet list

This will show you a list of imported keystores

We still haven't covered how to deploy contracts using Foundry, but for now, just know that for using the private keys you imported into keystores, the process is as simple as adding the account name to the command and then entering your password. Here's what one of the methods of deployment looks like:

forge create ContractName --rpc-url rpc_url --account account_name

Once you run this command, you will be prompted to enter the password that corresponds to account_name. If the password is correct, your private key gets decrypted and is used to deploy the contract via the RPC URL specified. Don't worry too much if you don't understand this command as well cover it in the next guide.

The Pledge and a word of caution

In May 2022, Patrick Collins created the .env pledge, by taking which you promise to never use .env files for storing private keys of accounts that have mainnet funds in them. This pledge has evolved over time as now you don't even need env files for deploying contracts, like we just did. You can go ahead and read the pledge here. Make sure to read it to the end and comment I WILL BE SAFE if you agree to take this pledge.

A leaked .env file is not the only reason why developers wallets get hacked. If someone on Twitter or anywhere else asks you to download their software for testing and debugging, consider it an immediate red flag and run as fast as you can. Any shady software that you install has the potential to be a tool for stealing your private keys, because in the end, even MetaMask stores your keys offline and encrypts them with your password. If this password somehow gets stolen by the shady software in question, it can use it to decrypt your keys and steal your funds.

The bottom line is, you have to be safe at every step of the way in your web3 dev journey.

Conclusion

Congratulations! You now know how to safely import your private key into a keystore and use it to deploy contracts. There is more than one way of deploying contracts using Foundry. In the next guide well dive deeper into this process and learn how to deploy smart contracts locally and on-chain. See you then 🫡🫡

How to easily import dependencies and use remappings in Foundry

Samarth Saxena — Thu, 03 Oct 2024 10:13:47 +0000

Introduction

In this series of blogs, we've so far seen how we can install Foundry and write and compile simple contracts in it. If you have dependencies like ERC20 by OpenZeppelin in your contract, the process of importing and using them is slightly different from what you might be used to. In this short guide, let's see how were supposed to go about it.

Importing dependencies

We will not be getting our dependencies from npm. So, instead of writing npm install dependency like in Hardhat, you'll be using forge install dependency and here, dependency can be a raw URL (https://foo.com/dep), an SSH URL (git@github.com:owner/repo), or the path to a GitHub repository (owner/repo). If you still have the Foundry project we made in the last blog, point your terminal to it. For this guide, let's suppose we want to use OpenZeppelins ERC20 contract. To do that, run

forge install openzeppelin/openzeppelin-contracts

This clones OpenZeppelins openzeppelin-contracts repository and installs it as a git submodule.

Now, create a new contract called Token.sol inside src and past the following code inside it

// SPDX-License-Identifier: MITpragma solidity ^0.8.25;import "@openzeppelin/contracts/token/ERC20/ERC20.sol";contract NewToken is ERC20 { constructor(string memory _name, string memory _symbol) ERC20(_name, _symbol) { _mint(msg.sender, 10 * 10 ** 18); }}

At this point, your IDE may be giving you many errors saying that it cannot find OpenZeppelin contracts, but running forge compile works without errors. Whats going on?

Forge remappings

When you run forge install, Foundry adds your dependencies to the lib folder. If you click on it right now, you will see 2 folders: forge-std and openzeppelin-contracts. The contract we want to use is stored in lib/openzeppelin-contracts/contracts/.ERC721Enumerable.sol so we can either import it using this path or we can remap lib/openzeppelin-contracts/contracts/ to @openzeppelin/contracts/ so that we can use the format were so used to. Well heres the good part: Foundry does this for us automatically! To see all the remappings inferred by Foundry, run

forge remappings

Now to get rid of the errors that we see in our IDEs, we just need to create a file with all the remappings inside. We can do this easily by using:

forge remappings > remappings.txt

This will create a file called remappings.txt which will have all the remappings. It should look like this:

@openzeppelin/contracts/=lib/openzeppelin-contracts/contracts/ds-test/=lib/openzeppelin-contracts/lib/forge-std/lib/ds-test/src/erc4626-tests/=lib/openzeppelin-contracts/lib/erc4626-tests/forge-std/=lib/forge-std/src/openzeppelin-contracts/=lib/openzeppelin-contracts/

The path on the left hand side of the = sign is equivalent to the path on its right hand side in each line.

Conclusion

That's it! You've successfully installed, imported and remapped dependencies in your Foundry project. Great work! As we inch closer to actually deploying a contract it is important to understand how private your private key is supposed to be. So, in the next blog, well be discussing how you can safely store and use your private key for deploying contracts. See you then 🫡🫡

How to write and compile smart contracts in Foundry

Samarth Saxena — Sat, 28 Sep 2024 13:56:11 +0000

Introduction

In the previous lesson of this series, we saw how we can install Foundry on our machines. ICYMI, go ahead and read it here. What good is a tool if it isn't being put to use? So, in this lesson, we'll learn how to create a new Foundry project, write smart contracts in it, and compile these contracts. Like the last one, this is also going to be a short guide as there's not really much to it.

Creating a new Foundry project

For creating a new Foundry project, open your terminal and run this command

forge init name-of-folder

Just this one command will initialize a Foundry project with some boilerplate code written for us already. Now cd into the folder you just created and open your code editor there. If you're using VS Code, you can just do:

cd name-of-foldercode . -r

What does what

Here's what your file structure should look like at this point:

Contracts

All your contracts should be inside src. As visible, we've been provided with a contract called Counter that is written in the file Counter.sol. This is a simple contract which allows the users to arbitrarily set the number variable or just increment it. Feel free to make changes to this contract.

Scripts

Your scripts should go inside the scripts folder. Unlike Hardhat, scripts are written in Solidity itself and are used to deploy contracts declaratively. You can take a look at the example script for our Counter contract which has been provided in this folder already and you'll see that the run function starts a broadcast, ie. allows making transactions (here, using the default Foundry sender 1804c8AB1F12E6bbf3894d4083f33e07309d1f38 since we haven't provided an account in startBroadcasts parameters) that can be sent onchain, creates a new instance of the Counter contract and then stops the broadcast.

Tests

Tests for your smart contracts should go inside the tests folder. Again, unlike Hardhat, we use Solidity to write tests instead of JavaScript. A sample test file with 2 tests has been provided to us. Go through the file Counter.t.sol and you'll see that the first test is checking whether the increment functionality of the contract is working, and the second test is trying to use a random number as the parameter of the setNumber function in the Counter contract. We'll discuss testing in more details as this series progresses.

Writing contracts

Now let's write a contract. Create a new file called Greeter.sol in the src folder. In it, write the following code:

//SPDX-License-Identifier: MITpragma solidity ^0.8.24;contract Greeter { string public greeting; function setGreeting(string memory _greeting) public { greeting = _greeting; }}

This is another very simple contract that lets the user change a public variable called greeting.

Compiling contracts

To compile all the contracts inside the src folder, just write this one-line command in your terminal

forge build# orforge compile

The output should be something like this

If you want to only compile a particular file, change the command in this fashion:

forge build directory/name_of_file.sol# for example:forge build src/Greeter.sol

You'll now see something like this:

Conclusion

That's it! Youve successfully created and compiled a smart contract! You now also know what the file structure of a Foundry project looks like and which files go where. Note that we haven't deployed any contracts yet. There are two more blogs that precede it. Ill be publishing those 2 in the coming few days. Till then, stay tuned. Thanks a lot for reading to the end. I hope you learnt something new! See you in the next one 🫡🫡

How to Install Foundry on Windows/macOS/Linux

Samarth Saxena — Tue, 24 Sep 2024 13:17:06 +0000

Introduction

If you are a web3 developer, I'm sure you must have heard of Foundry somewhere- maybe in a YouTube video, maybe in a Twitter thread, or maybe from a friend of yours. Foundry is a smart contract development toolchain. You can write, compile, deploy and test smart contracts as well as interact with them using Foundry.

Foundry vs Remix IDE

You may be asking yourself: why should I choose Foundry over Remix IDE? Well, first of all, Foundry is installed locally on your system. So if you're making, let's say, a website, you can initialize a Foundry project alongside your other files and then make changes there directly. This allows you to structure your files in an organized manner and work quickly. Moreover, Remix can be pretty unreliable sometimes and you might end up losing all your progress unexpectedly. Most importantly however, Foundry shines through with its testing suite which allows you test your contracts significantly faster than Remix and it thus provides a seamless development experience.

OK enough yapping. Now without further ado, let's see how we can install this Swiss Army Knife on our machines.

Installing on Linux/macOS

If you have Linux or macOS, the process is pretty straightforward.

First download Foundryup, which is the official installer for the Foundry toolchain, by running this command in your terminal

curl -L https://foundry.paradigm.xyz | bash

Follow the on-screen instructions and the foundryup command will become available in your terminal. Then, just run:

foundryup

This will automatically install the latest (nightly) versions of the: forge, cast, anvil, and chisel tools, which are a part of Foundry.

And that's pretty much it lmao. Linux users have it easy this time. A welcome change, I'm sure. Jump to the Did it work section.

Installing on Windows

You can just use WSL and then refer to the commands in the previous section. However, if you don't want to install WSL, read on.

Make sure you have the Rust compiler and Cargo already installed on your machine. If you don't, download rustup from this link and run it to install both. You'll also need a recent version of Visual Studio, with the Desktop Development With C++ workload installed. Rustup will prompt you to install it. This is what you'll see when you run the downloaded file:

Enter 1 here and let the setup run

Once Visual Studio is installed, you will get this screen:

(just press enter here)

If everything is successful, you will get something like this:

Awesome! Now press enter, relaunch your terminal and run this command

cargo install --git https://github.com/foundry-rs/foundry --profile release --locked forge foundry-cast chisel anvil

This command will install the Foundry suite, ie. Forge, Cast, Anvil and Chisel on your machine. This might take some time as it will download and compile multiple crates. This will happen for all 4 tools so grab a cup of coffee or something while you wait. Once that is done, you'll see:

💡

Don't worry if it seems stuck at any point

Did it work?

To check if it worked, relaunch your terminal and run these commands one by one. Each should give you some output

forge --version

anvil --version

chisel --version

cast --version

The output should be something like this:

Conclusion

Congratulations, you've successfully installed Foundry on your machine! In the next instalment of this series, we'll see how we can create a new Foundry project and write smart contracts in it. Stay tuned till then. Bye for now! 👋👋