Around Sept. 15, the blockchain Ethereum will make a crucial software update known as “the merge,” which will significantly reduce Ethereum’s energy usage and set the stage for the network to become faster and cheaper. (You can read more about the significance of the merge here.)

To learn more about the merge’s importance and its rollout, TIME spoke with Justin Drake, who is one of Ethereum’s key researchers leading the transition. Drake is well-known in the Ethereum community. He is based in Cambridge, U.K., and coordinates and guides the work of other Ethereum researchers and developers around the world. He says that the merge will make cyberattacks upon Ethereum more expensive and make its building blocks cheaper and easier to use. And while he expects glitches on the day of the merge, he’s not worried about them having widespread damaging effects.

Here are excerpts from the conversation, which has been condensed and edited for clarity.

TIME: You’ve been working on the merge since 2017. Why have you decided to dedicate five years of your life to Ethereum and this transition?

Justin Drake: I’m extremely passionate about Ethereum. I see its mission as becoming the settlement layer of the internet: a low-level piece of infrastructure that helps humans coordinate things of value.

I also really enjoy the idea of permissionless innovation: the idea that Ethereum consists of Legos, and that anyone can assemble them with other Legos and build their own structures. This is very different to traditional companies. If I have an idea to improve Uber, I need to put on a suit, fly to California, meet the executive team, prepare a deck and pitch them an idea.

On Ethereum, you can have a random 12-year-old in India with a clever idea and some coding skills, and they can start single-handedly building with these Legos. I find that pretty exciting: Removing intermediaries that take a fee or gate-keep, or operate in a single country as opposed to the whole world.

I also like the idea that we’re building World War III-grade infrastructure that is not built on top of the internet, but is actually the internet itself. You’ll be able to build an application that will last for decades and centuries.

You’ve talked about wanting Ethereum to be “World War III-resistant” in past interviews. What does that mean and how does the merge get you closer to that idea?

The idea of World War III infrastructure is an attractive narrative for internet lovers. The internet was designed to be this system that would survive a nuclear war.

It also resonates strongly with people who want to build stuff. There are these famous stories of entrepreneurs building businesses on top of Twitter and Facebook, and these platforms changing their APIs, so the businesses just disappear. That’s led to the concept of platform risk: when you build on something, you risk that the platform changes the rules on you.

One of the rules of World War III-grade resistance is that even the most powerful nation-states can’t co-opt Ethereum and impose their rules upon you. If Ethereum was to become the settlement layer of value on the internet, then it would be one of the prime targets to attack in a war. And if it can be attacked, a specific nation-state could impose its rules on the chain, and it could become the China chain, the Russia chain or the U.S. chain. It wouldn’t be a neutral piece of infrastructure.

And the merge dramatically increases the security of Ethereum. An attacker needs 51% of the blockchain’s value to [take control]. With Proof of Work [the previous mechanism that powered Ethereum], you need on the order of $5 billion, which allows you to buy enough computers and transformers, connect all of them to the grid, and then carry out an attack. With Proof of Stake [the system Ethereum is transitioning to in the merge], we will have about $20 billion in economic security today—and this is a number I expect will grow dramatically.

The other interesting aspect about the merge is that with Proof of Stake, if we do suffer a 51% attack, we can precisely identify the attacker and eject them from the system. More than that, we can penalize them, including by destroying all their stake. And if they want to do a second attack, they have to rebuy.

So not only is an attack temporary, but it’s also extremely expensive. This is unlike Proof of Work, in which there’s no way to eject a hacker once they have taken control of the system.

You and many others in the crypto community have stressed the importance of Ethereum being a “neutral piece of infrastructure” that is resistant to government censorship. But is there a way to maintain that neutrality while also stopping hackers from laundering billions of dollars in stolen money?

Ethereum is the creation of a new, internet-native jurisdiction. Balaji Srinivasan [the former CTO of Coinbase and an influential crypto thinker] talks about the concept of a network state, which is the digital analog of a physical nation-state.

Whenever you have a boundary between two systems, you have to play by the rules of both systems simultaneously. Coinbase, for example, straddles the nation-state and network state, so they have to play by the rules of both.

But if you are interacting solely within the realm of Ethereum as a network state and not crossing that boundary, then now you’re playing by Ethereum rules. You’re no longer by nation-state rules. And one of the pillars of Ethereum as a network state is to be credibly neutral.

It almost doesn’t make sense to be compliant with a nation-state. First of all, every nation-state has contradictory requirements with other nation-states. What if one nation-state bans you from using a specific address and another says that every transaction must go through the address? There’s no way you can be compliant with both at the same time.

And the boundary of Ethereum as a network state keeps on expanding. Now we have decentralized exchanges that live solely within Ethereum, and only have to play by the rules of Ethereum. That dramatically reduces the amount of friction.

We’ve seen huge amounts of innovation around Uniswap, which is now a building block for vast swaths of decentralized finance. I think what will happen as a general trend is that just as we have decentralized exchanges, we will have decentralized everything.

Imagine a decentralized equivalent of Uber. In order to get decentralized Uber, we need several building blocks: we need stablecoins, scalability with rollups, identity and storage, all of which we have, to varying degrees. But insurance and reputation may be missing building blocks. We need all these building blocks to be decentralized before we can think of unlocking this complex application. And that’s something we’re going to see in the next few years, after the merge.

How are you planning for the day of the merge, which is scheduled for September 15? What are you most cautious or worried about?

In a very meaningful way, the merge and the dynamics around it are outside my control. It’s now in the hands of the developers who have written these clients and the operators running the clients. [“Clients” are software applications that verify the status of the network via different programming languages.]

There’s a lot of clients and a lot of code, and quite a bit of complexity. So I expect there are going to be bugs. Most likely it won’t be 100% smooth. But the good news is we have client diversity.

That’s important because if two-thirds of validators are running a client with the same critical bug, that can lead to a bad Ethereum chain being finalized. Recovering from these bad finalized chains is extremely expensive. It’s messy, it needs to be done manually at the social layer [human users coordinating together to take actions upon the blockchain], and it might involve rolling back transactions. Just thinking about it makes me uneasy.

But the good news is that there’s no single client that’s close to 50% of the validators. So if we have a bug in one of the clients, that is not a systemic risk: it’s not like Ethereum will suddenly crash. Most likely, some fraction of the validators will have some issues producing or attesting to blocks, and the participation rate will go down. Then, the developers for that specific buggy client can issue a patch in the hours or days, and those can be adopted by operators to update the software.