Hardhat 3 Preview: Overhauled & Rust-Powered by Patricio Palladino | Devcon SEA

[Music] Hi everyone. Thanks for being here. Uh my name is Patricio. I'm the co-founder and CTO of Nomic Foundation. Which is a nonprofit dedicated to Ethereum developers like you.

Uh Nomic, what we do is building open-source infrastructure and tooling for the Ethereum community. And the most well-known that we of our tools is Hardhat. And during this presentation, what we are or I'm going to talk about is Hardhat V3 or Hardhat 3, the new version of Hardhat, which is still in development because it's a whole overhaul of Hardhat with a tons of changes. Uh but first, let's take a look at Hardhat at Hardhat 2 for a for a second, especially its limitations and why we decided to rewrite it. The first one and main one is that Ethereum changed a ton during the lifetime of Hardhat.

We started working on it almost 7 years ago, about 2018. And back then, Ethereum was a single chain, I think way more simple ecosystem. There was mainnet and a few testnets. Those testnets aren't even live alive uh nowadays. And the applications were simpler, right?

There wasn't even uh stablecoins back then. Now, applications are larger and Ethereum turned to be a single chain into an ever-increasing ecosystem of different chains, each of them with a slightly different behavior. Another problem that we have in Hardhat 2 or Hardhat is that we wrote everything in in JavaScript, including our network simulator, and that had several performance issues. We also focused a ton on on the Node.js ecosystem cuz we envision uh building a platform for developers to be able to customize and extend their own setups, but that focus on on JavaScript only also meant that you could only write tests in JavaScript or TypeScript.

Uh and the the final limitation is that as when we designed Hardhat, there was only one chain, mainnet. We designed it in a way where uh for every single Hardhat process, there is a single chain, a single network connection. You just import Hardhat, you have your network connected there. Mostly most of the time, it's going to be simulated by us. And all the boilerplate, all of your libraries, all your plugins get configured for you, but it's a single chain.

As soon as you want to work with multiple chains, you you hit this limitation and you start making workarounds. We created RPCs for switching the hard forks or forking other networks. People use different configurations and and things like that. So, Hardhat 3, we rewrote it from scratch to circumvent these limitations and offer more functionality. And how does it look?

Well, it looks a bit like this. It's a bit uh like Hardhat, it's still Hardhat, but Hardhat from the future or more tech technical Hardhat, but at the end, it's just a Hardhat, right? Like it feels and looks like Hardhat. So, as I mentioned, it's a complete revamp of the product. The scope is massive.

Hardhat grew during these 6, 7 years. It has tons and tons of plugins and functionality, and I can't cover everything here. I'm only going to focus on this list of things, which are the network simulator that we rewrote in Rust, the Solidity test support support that it's added in Hardhat 3, uh our deployment solution, and how to ergonomically work in with multiple networks so that you don't have to do those workarounds that I just described. And finally, how we correctly simulate off-chain The first thing, as I mentioned, is that we rewrote uh our simulator in Rust, and we ship it just as an NPM package. Nobody know or some people noticed this, but in Hardhat 2, we are already running every simulation in Rust, and that led to significant performance improvements.

For some people, that it's even 10 times faster uh in real-world scenarios. It's not just benchmarks, but they just got a new version of Hardhat, and without noticing, their tests were 10 times faster 10 times faster. And you shouldn't have to notice that. The TS interface is still the same. It's just that the at the core, it's Rust.

It's a project that we call EDR from Ethereum Development Runtime. And if you want to learn more about that project, someone from our team is going to give you a presentation about it tomorrow. The other big change that comes along with EDR is that now that our runtime is written in Rust and we can run things quickly, we decided to add support for Solidity test. If we did that previously with our previous infra, that was probably going to be more challenging and slower. So, we added support thanks to EDR.

It's also written in in Rust. It's Foundry compatible, which means that it's mostly a drop-in replacement. All of the features that you would expect like fuzzing, invariant testing, force casting, whatever you would normally use in Foundry, you can still use it in in Hardhat 4, but under the hood, it's going to be run using Hardhat. The other point that I want to explain here is our solution for deployments called Hardhat Ignition, which is also available in Hardhat V2 if you want to try it try it out now. And it's basically a declarative deployment solution.

And by that, I mean that what you do in Hardhat Ignition is describing your end goal, how the system should look like in production, and Ignition will do everything it it needs to do to take your system there. It looks a bit like this. Instead of focusing on transaction and execution of a of a deployment, you don't write a script, but rather define a module. You an Ignition module. You can think of a module as a JavaScript module, Rust module, Python module, like a programming language module where you define certain things cer- certain entities, and you export some of them, the ones that are going to be interested by other modules.

In this case, modules in Ignition are futures, are not transactions or anything execu- execution-wise. Instead, as I mentioned, they describe the intent of the user to perform something on chain. In this case, in this example, we have two uh contract deployment futures. Basically, what we are telling there using an API is doing to Ignition is that it needs to deploy a contract called parent with a first and single argument B, and a contract called child with a C as its name, I guess. Uh and finally, there's an extra a different kind of future that it's something like once the parent is deployed, please call add add child with the child address as its single argument.

But this is, as I mentioned again, or I will mention this again once more. This is just your intention. Here, when you do this, there's nothing being run. There's no transaction. This those addresses don't exist yet.

It's Ignition that will deploy them later. And given that it's just a static description of what you want to do, that gives it Ignition a ton of freedom to do what whatever it do whatever it needs to do to get there. It will analyze the graph of futures that you define in your modules and automatically detects how to or batch them and come up with a plan so that they can be run in parallel as long as they are safe to run in parallel. That leads to faster deployments, but that same feature or that same capability of it being static and Ignition taking hold the whole control of execution allows us to do things that are much more, I guess, smarter or better for you. If you are running a a deployment deployment script and it fails for any reason, let's say that your network fails, you forgot to fund your account, or something like that, Ignition can detect that and recover.

And how do you recover from tho- those kind of errors? Well, normally, if you were writing a script, you would probably modify the script. Maybe add an if or comment out part of it just so that it only continues running the things that are missing. In Ignition, it's not like that. You just rerun it, and Ignition will automatically compare its local state with the network state.

It will validate that they are in sync and decide how to continue. That allows us to handle a ton of errors. Just to name a few, things like gas gas price spikes, we can bump transactions. If a transaction is is dropped from the mempool and disappear, we just resend it. If there's a problem with nonce management, we detect that.

Those kind of things we can do just because we aren't giving control of the user to the control of the execution to the user, but keep it to Ignition and doing it ourselves. Then, while Ignition has more features, the only other one that I will uh talk about here is that modules like the one I showed here can also be evolved and and iterated. Let's say that I deployed this system, everything goes right, I get traction, maybe I need to add another contact, another tile, I guess. Um that's common, right? Successful software always evolve, always requires changes.

Maybe in smart contracts that means adding a new smart contract or running a an upgrade if your if your system is upgradeable. And you to do that in Ignition, all you need to do is modify your module, rerun it again, the same module, the same command, and it will detect if they are compatible, complain if they aren't, but if they are, it will diff the state and only run the things that needs to be run to get it to the new version. And finally, the only big feature of Hardhat 3 that I Hardhat 3 that I want to touch is its new multi-chain support, which is fairly complex one, so I'll explain it bit by bit. There are many things happening here. I'll use these two lines of code to explain them.

First, as I mentioned, in Hardhat 2, when you just import Hardhat, you get a a single connection to a single network, right? And that brings a ton of problems. In Hardhat 3, that's different. We give full control to the user about network connections, and instead of exposing already uh I guess prepared connection for you, we instead give you access to a what we call a network manager object with has a connect method, and that method takes a network config name by parameter, and it allows you to connect to whatever you want. In this case, mainnet would be one of the networks that is configured in our config, but it could be any other network, right?

And it could also be an EDR power network. You can create many network connections to simulated networks and create many simulations, and all of them are going to be independent. Then, while you do that, deploying system that has been rewrote in Hardhat 3, it's going to initialize all the usual libraries and helpers and things that Hardhat does for each of those networks. So, here this VM is connected to the network connection mainnet, but not to any other one that you create. And you can Doing that, you can create anything that you want and avoid any kind of work around like switching networks or having multiple config files or things that people used to do in V2.

At the same time, we introduce a new concept. As you can see, connect takes a second param. That concept we call it chain type, and as the name says, it's the type of chain that you're connecting to. I guess you could you could explain it like if you were to take all the different EVM networks, some of them will be shaped very similar to each other. Like Op Stack networks behave close to each other, maybe with some smaller param param differences.

L2 behaves similar to Sepolia. Arbitrum may have different deployments, and so on and so forth. Each of those we call them chain types, and what you do by providing a chain type while you connect is two things. First, you inform the connection or deploying mechanism that those libraries and helpers that you are you you are using and you installed should be aware of that chain type, which can mean that they include differences in the JSON RPC, how they interact with the JSON RPC, or they may even like in the case of VM here, they may even install extensions to their API. If you you if you were use VM with Op Stack, you will you may know that you can add special Op specific actions, and that's this will be done automatically both at runtime and at type level.

So, if you were to use Op VM to run an Op specific thing like estimating L1 gas, uh and you just switch the chain type to L1, it will stop compiling, it will give you a type level error, so that it will lead to a very smooth developer experience, while at the same time automatically initializing it for you when you are doing the when you're using the right chain type. Now, that's not the only thing that the chain type does. If the chain type if you're connecting to an EDR network and you use a chain type, you will also inform EDR that it should be running on a different mode. EDR in Hardhat 2 only supports only simulates mainnet, but in Hardhat 3, it simulates different different chain types. Right now, we only simulate three three different chain types, L1, which is focused on mainnet, Sepolia, and Holesky, or something like that.

We have Optimism mostly focused on Op Stack, mostly right now mostly Op Op mainnet and Op Sepolia. And we have another one that is called generic. It's for every other network that we haven't fully supported yet, which is kind of a base common denominator. And what EDR will do when you provide a chain type is change its behavior to be to well, to actually behave as close as possible to the real network. And what does that mean?

It means a ton of things, it depends on the network, right? But it could mean JSON RPC change changes, sometimes an object has extra fields or some fields are removed. Some chain types have extra JSON RPC methods. Um maybe some of them have extra opcodes. Optimism I think has one or two opcodes.

They have extra precompiles, predeployed contracts, different gas cost. All of those things we want EDR to be very precise at simulating, cuz otherwise what we end up doing is just using L1 or or tooling designed for L1, testing the L state L1 and deploying to different networks that behave slightly different, and just hope for the best. Um that those things sometimes go wrong, and that's has already happened. So, the idea here, combining all these features, would lead to you being able to handle multi-chain workflows while very smoothly, while also having very precise simulation of those chains. Uh finally, the project status I I want to mention to you how the project is going.

As the title suggests, this is just a preview. This is not ready to use, it's not in production. We have an internal alpha. It's not ready, it's pretty rough. Uh we are doing some demos with some teams.

Unfortunately, we can't do it with everyone, but if you're interested and you see you you meet us somewhere, just let us know, or just get in touch through the internet, I guess. Uh but in a few months we'll make that alpha public. Um Finally, if you want to know more about what we do at Nomic, we have a few extra presentations. If you scan the QR code on the left, you can see a list of our presentations. Tomorrow I'll give a keynote explaining the high-level technical vision of Nomic Foundation.

Somebody else from our team will give a presentation about how EDR implements these chain types and simulates different L2s. And on Friday we have a presentation about Slang, our Solidity compiler as as an API, and in particular some cool APIs that it offers to do code analysis for Solidity, like imagine CSS for Solidity code, something like that. Um And well, and if you enjoy what we do and you like to work with us, scan the other QR code and you'll get info about our job openings. And that's it. Thanks, everyone.

Amazing, Patricio. I'm already very excited. Great presentation and great features. So, all right. Remember, you can scan the QR code.

You can send love. There's already a lot of like hearts. And you can vote for the questions that you want most. I think we're going to hopefully, yeah, I think we can have There's a lot of questions, so let's start uh right now. What's the killer feature over Foundry?

Yeah, so I think um I think there are a ton of different features. I think developer experience it's a hard topic because there is a ton of uh smaller pain points that you need to fix to have a a great a a great development experience, and sometimes there is not a single killer feature. Well, I do think that the multi- multi-chain support that I mentioned is is great. I think that's something fairly unique. I haven't said there into other more advanced things that Hardhat 3 does way better over Hardhat 2.

Uh but eventually we'll release more information. Great. How does Ignition handles proxy upgrades? Yeah, so proxy upgrades for Ignition are just other features. A a proxy upgrade is just a call, so you can encode the call.

You can also um create very useful functions like any any function. A module is just code, so you can create a function that will be run this upgrade, and it takes other futures and returns a future something like that. We have examples of of that on our website. Great, great answer. Next, is VM the future of Hardhat, or do you plan to support both VM and Ether.

js equally moving forward? Um Both or yes, I guess would be this answer. Uh, I think that the default experience will be VM, as we saw uh it's more advanced, especially for L2s. Uh, it it brings very support for certain L2s. That's great.

It's also way more advanced with TypeScript, but moving forward we'll support both. Um, we'll even support both. Um We'll even provide a smooth transition for people that use Ethers in V2 to use Ethers in V in V3, and to use both in V3. Yeah. Great.

Next one is about deployed state managed. How How is the deployment state managed? For example, if multiple devs are working in the same project, but the state is local, there may be conflicts. Yeah, so the state is local. Uh, we think that it's just another artifact that you should version and share.

Um, just treat it as if it were code. It's just code. Yeah. Okay. All right.

Next one, will Hardhat 3 provide full traces of failing tests like Foundry does? Uh, yes. Um, and we'll also provide other features that Hardhat V2 does, like recognizing uh common error scenarios. Uh, in Hardhat V2, if you I don't know send a transaction to a method that it's with gas sorry, with value to a method that it's not payable, um things like that, Hardhat will detect that and gives you a clear error message saying, "Hey, you are sending funds to a non payable thing." Um, things like that.

Uh, those will also be supported in Solidity test, too. Uh, maybe I didn't mention this, but the chain types thing, the ability of precisely simulating a different chain, that will also be available in Solidity test. How it will look like exactly, we are still exploring it. It may look exactly the same, but just a flag at the command line, or it may be more present through the Solidity testing framework. Great, great answer.

So, why not build in public since the beginning of V3? I think people really want to get their hands on it. Oh, it's on GitHub. Uh, it's a branch called be next. It's just a It's not ready for production.

Yeah, just clone it, build it. Uh just don't complain if it breaks too often. Yeah, still very helpful. Yeah, excited to see you. All right.

Ignition question, it doesn't let you pull the state of the contract in the middle of the deployment. Isn't it a great limitation? Uh Not sure if I understand this question. I guess uh if it means if you can read a contract, yes, uh you can read it. It's just another future.

I didn't show it here, but just as you do call, which would be a bright operation, you can have a future for a read operation. Uh, and it's it's just a future. Right. When launch of Hardhat V3? Time nuts.

Uh, it will be early next year. Exactly when, uh we don't know. Yeah. Right. Can Ignition module be used as a fixture in tests?

Yes, they can be used as fixture in tests, both with VM and Ethers. All right, all right, all right. Will Hardhat provide better debugging like Symbio- symbolic by runtime verification experience or better experience than Foundry, and how or how? Uh Well, we'll focus very strongly on debugging after our release. Uh, how exactly It's fairly complex.

We have five 15 seconds. Uh, but we'll integrate it in the IR on on our compiler to be able to provide better debugger experience, and and that's part of what I will talk in my keynote tomorrow, so feel free to go there. Don't miss it. Is multi-chain support compatible with awesome plugins that already exist like Hardhat deploy? If not, how hard is it to uh is going to be to be migrate?

Uh, yeah, so uh every plugin If there is plugin authors here, you might hate me, but every plugin will have to go through a pre-mechanical migration. Plugins are easier, in my opinion, to build in Hardhat V3. Uh, but it's not automatic. Uh, you have to migrate them. Right, right.

Uh, are you thinking about uh smart contract mocking support? Yeah, so for Solidity test, they are supported. As I mentioned, uh Solidity test is a the opinion replacement of Foundry, so we did the IR at its core. Um, and for JavaScript test, um we would like to see smoke return, but we'll have to, I guess chat with with the team, and we'll see in the future. Right.

Does Hardhat Ignition support OpenZeppelin's upgrade plugin? No, not yet. Uh, it's something that we'd love to see happening. Uh, and I've been chatting a bit with some of them. Uh That some of them may be here.

Uh, but we'll eventually get there. All right. There are seven more questions, but we are over time, so let's take the maybe two. Okay, two more. Ignition is like Terraform for Is Is Ignition like Terraform for contracts?

I guess you could say yes or somewhat. Uh, it's a a biggest inspiration. Nice, nice. And what is the difference in supported chains like ED or OP versus general chain support? What difference or lack of features can we expect with the generalized chains?

Well, the generalized chain or generic chain, uh doesn't have any extension. It's more like it's It's the base common denominator of EVM. Uh, it's even less strict than mainnet. Uh, when you run on L1 mode, we are strict about simulating mainnet as closely as possible. With generic, it would be closer to what Hardhat 2 does.

Um It's It doesn't have any extension that any L2 has, and it's a bit more I guess forgiving. Right. There are more questions, but we're sadly run out of time. So, if you want to catch Patricio later after the talk, I think he'll be available. There was online as well.

Uh, please give a great round of applause to Patricio. Great talk. We're all very excited.