For the second time this year, Ethereum is set to receive a major upgrade -- this time called Fusaka.

And, I think this is a much more interesting update than Pectra, which hit mainnet in May.

It not only has a dramatic headline feature in the form of PeerDAS, which makes it technologically more interesting, but it's also Ethereum's most carefully considered and strategically aligned update ever.

In this way, Fusaka is representative of a much larger change in Ethereum's community and culture -- a change that has been clear online in recent months but hasn't, until now, had a truly tangible impact.

Fusaka is proof that Ethereum is on a war footing and finally responding to the ever-increasing competition from chains like Solana.

So, let's dig in and see what Fusaka is all about.

As I've covered before, Ethereum upgrades are really a pair of upgrades: one on the Consensus Layer and one on the Execution Layer. In this case, they are called Fulu and Osaka respectively. "Fusaka" comes from combining those names together.

It's scheduled to arrive on December 3, at slot 13,164,544.

Fusaka contains 12 EIPs (changes) that are designed to increase Ethereum's throughput, make it an even better foundation for Layer 2 chains, and improve the user experience.

I think it's worth noting the context that Fusaka arrives in, as it is the first update to have been properly shaped by changes made at the Ethereum Foundation (EF) earlier this year.

The EF is the non-profit organisation established in 2014 to steward Ethereum and support its development. But it had faced significant and growing criticism for things like poor communication, slow execution of ideas, and a general inability to recognise or respond to the competitive pressure Ethereum has come under in recent years.

As a result, the EF underwent a big shakeup in March of this year, appointing a pair of Co-Executive Directors to oversee things.

Then, after just a month in their new roles, these Directors published a blog post detailing their new strategic objectives. These were scaling the Ethereum mainnet; scaling blobs; and improving UX -- all without compromising Ethereum's existing security or hardness.

Looking at Fusaka, it's notable how every change clearly aligns with these objectives. It's easy to categorise all of the EIPs according to which strategy they support -- though some do span more than one category.

• Scale L1: EIP-7642, EIP-7823, EIP-7825, EIP-7883, EIP-7934, EIP-7935, EIP-7939

• Scale Blobs: EIP-7594, EIP-7892, EIP-7918

• Improve UX: EIP-7917, EIP-7951

Additionally, some of these changes also relate to an implicit, community-driven objective of driving more value accrual to Ether -- something that has been overlooked in the past but would clearly make ETH a more attractive asset.

None of this may sound revolutionary.

Frankly, this is how updates should have been designed from day one.

But, historically, most of Ethereum's upgrades have felt like a grab-bag of different ideas, and therefore they failed to give the impression of a network making meaningful progress towards desired goals.

The last update, Pectra, was a good example of this unfocused approach. My assessment at the time of that update was that, while everything it delivered was good, it lacked a clear focus and therefore felt listless and uninspired. It certainly didn't deliver anything like the change that the Ethereum community was demanding at that particularly dark and challenging time.

And that's what makes Fusaka so exciting. It's not just what it's delivering, it's how it's doing it.

Fusaka is the first update for a long time that makes you feel like Ethereum is delivering meaningful change, that it can solve the key issues that have blighted the platform for so long, and that it can truly compete with the ever-growing collection of supposed 'Ethereum-killers'.

So, let's unpack those changes now and see how they relate to Ethereum's new goals.

We'll start with blob scaling, as this is the focus of Fusaka's headline change.

As a quick reminder, blobs were introduced in early 2024 and provide a temporary storage space for L2 data on Ethereum. They are Ethereum's Data Availability (DA) solution.

You can think of them as literal blobs that stick to the outside of Ethereum blocks so they can be passed around to all the nodes in the network. But, after a short amount of time, they can be picked off and discarded by anyone who doesn't want to permanently store that data.

Each blob is paired with a transaction that remains inside the block, even after the blob has been removed. This transaction contains a commitment to the blob data -- this is essentially a special reference that can be used to prove that some data is indeed in a blob.

There are two key things to remember as we dive into Fusaka's changes. First: every node in the network currently has to download and verify every blob in its entirety. Second, as I just mentioned, every blob has a corresponding transaction that is contained inside the block.

EIP-7594, better known as PeerDAS, focusses on the first of those things to remember.

It will allow nodes to verify blob data using just a fraction of the blob -- so they will no longer need to download the entire thing. In fact, most nodes will download just 1/8th of the blob's data.

What's more, so long as nodes across the network all hold truly random fractions of the blob, the entire blob could be reconstructed with just half of the data.

This is made possible using some clever maths called 'Reed-Solomon erasure-coding', which is the same thing used to make DVDs scratch-resistant.

In Ethereum, it will allow additional blobs to be added to blocks.

Because most nodes will only download 1/8th of the data, you could theoretically add 8 times as many blobs to blocks without increasing a node's workload or bandwidth requirements.

In short, Ethereum could vastly increase its DA capacity without increasing the burden on the network.

Here's how it works.

Under PeerDAS, blob data will be converted into a series of numbers that are taken to be coefficients of a smooth polynomial curve.

You'll probably remember polynomials from school as expressions in a form like: $y = ax^2 + bx + c$. The polynomial created here will obviously be much longer and more complex, but it's essentially the same thing. And, here, it is also a compressed mathematical description of the original data.

Now, here's where it gets really clever.

If we imagine plotting that polynomial on a graph, we'd see that the line would continue on well beyond the original data.

In fact, we could keep plugging new numbers into the expression and generating new points on the same curve. And the crucial thing here is that these new points are still on the same curve -- they are still defined by the same expression.

Therefore, while they are 'fictitious' data points not included in the original blob data, they are closely related to it.

Ethereum will generate enough new points on the curve that it will effectively double the original data -- creating a lot of redundant points that can be used to reconstruct the original blob if necessary.

Next, it will batch all of these data points into 128 groups, called 'columns', so that each column contains a series of consecutive datapoints from the polynomial curve. Then, each column is distributed across its own, specialised subnet.

Every node in the network is randomly assigned at least 4 subnets based on its unique ID -- which should ensure a uniform, random distribution of all blob data.

And it's worth noting that some nodes will be required to subscribe to additional subnets.

Once a validator is tied to a node, meaning the person running that node is staking ETH and participating in block production, they will need to subscribe to 8 subnets.

If they stake more than 287 ETH, they will need to subscribe to more than 8 -- with the total number of subnets depending on the quantity of ETH staked.

Finally, anyone staking 4096 ETH or more -- the equivalent to two maxed out validators -- will be considered a 'supernode' and have to connect to every subnet. Therefore, they would receive every column and download every blob in its entirety. They are also expected to redistribute this information to the rest of the network to heal any gaps that may appear.

Of course, based on the amount of ETH they hold, these supernodes should be able to afford the overheads associated with all of this.

But, to reiterate, the key number here is 8.

The majority of nodes will only subscribe to 8 of the 128 subnets -- and therefore only receive 8 of the 128 columns. That's equivalent to 1/16 of all the data -- including the extended data. And, because the data was doubled for redundancy earlier in the process, this 1/16 is really just 1/8 of the original data.

That is where the big saving comes in. That is why PeerDAS could enable up to 8 times as many blobs.

It's also worth noting that each data point in each column will come with everything necessary to verify the data against the commitment contained in the block. So, no matter how many columns it receives, it can always be completely confident that the data it holds is correct.

Plus, as mentioned earlier, as long as anyone is able to collect at least half of these columns from across the network, they can reconstruct the entire blob. The way the data is distributed should ensure at least half of the data is always available, even in difficult and adversarial conditions.

So that is PeerDAS, an update that enables something Vitalik has described as "pretty unprecedented... a live blockchain that does not require any single node to download the full data".

That will let Ethereum increase the number of blobs it can offer Layer 2s for their data storage needs, making it a better foundation for the modular world and ultimately enabling greater throughput across the whole stack.

Although PeerDAS unlocks additional blob capacity, Fusaka won't immediately take advantage of it.

Instead, EIP-7892 introduces a new process for adjusting blob parameters, called Blob Parameter Only (BPO) forks, which will let Ethereum incrementally increase the number of blobs on offer.

Traditionally, hard forks -- network upgrades -- have involved complex changes and required significant coordination across the Ethereum ecosystem. Fusaka itself is an example of this kind of fork. BPO forks are much, much simpler.

They will only change 3 blob-related parameters: the target number of blobs, the maximum number of blobs, and the base fee adjustment factor that influences the cost of accessing blobs.

The idea is that the community can coordinate one of these BPO forks, increasing the target blobcount to a higher number, then wait and observe how the network handles the change. If everything continues to run smoothly, then it will be safe to arrange another BPO fork and repeat the process.

Perhaps you can think of BPO forks as a kind of 'dimmer switch' that can be gradually dialled up, as opposed to the 'on-off' switch used in traditional forks.

The first two BPO forks are already scheduled.

The first of these will go live on December 9, one week after Fusaka. It will raise the target blob count from 6 to 10 blobs, and the maximum blob count from 9 to 15.

The second is scheduled for about a month after Fusaka on January 7, and it will raise the target to 14 and the maximum to 21 blobs per block.

The expectation is that these BPO forks will continue for some time, slowly expanding Ethereum's blob capacity without endangering the network with any sudden spikes. Ultimately, it could reach something like 72 blobs per block down the line -- but that of course depends on how Ethereum holds up under the load of the additional blobs.

EIP-7918 is the final big change that Fusaka will make to blobs, and it's all about pricing them more effectively.

Essentially, 7918 will introduce a floor price for blobs so they don't get underpriced during periods of low demand. This should keep blob fees closer to the market clearing price which will, in turn, smooth fluctuations in demand and ensure blobspace is allocated more efficiently.

Remember how every blob is submitted alongside a transaction that contains a reference to the blob.

In the current system, this can cause blob pricing problems.

The cost of including the transaction in a block is often very large relative to the cost of the blob itself -- especially at times of low blob demand. Therefore, if blobs are running empty and Ethereum reduces blob fees, it doesn't stimulate demand in the way it should.

For instance, if a transaction costs $10, it doesn't matter if Ethereum charges $0.01 or $0.001 to access a blob: the total cost of the transaction remains largely the same, so no one steps in to make use of the 'cheap' blobs.

As a result, blobs can run empty for long stretches of time. Then, when demand returns, it can take more than an hour of over-target blob production to increase the price back where it should be: the market clearing price, when supply and demand are in balance and only the target number of blobs are being produced.

7918 ties the minimum blob fee to the transaction fee, ensuring blob fees are always a meaningful portion of the total cost paid by blob consumers. That should protect the price signal and prevent fees falling close to zero for lengthy periods.

It will also ensure blob fees better reflect the computational cost that blobs impose on the Ethereum network. And, it will create a stronger alignment between L2 usage and blob fee revenue, which will help Ethereum capture more value from the stack it supports.

Finally, this change can be viewed as Ethereum throwing its weight around in the DA marketplace. Instead of essentially giving blob space away with near-zero fees -- something that all the DA providers are currently doing -- Ethereum wants to sell to generate meaningful revenue.

Ultimately, it's betting that its superior network effects, security, and liquidity give it pricing power relative to competitors like Celestia.

Fidelity Digital Asset's analysis of this change suggest it could be worth hundreds of millions of dollars for Ethereum and that, had it been introduced when blobs first launched, it could already have raised almost $80m in additional revenue.

Of course, this is all revenue that would otherwise be going to L2s -- who may well change their behaviour, or even leave Ethereum altogether -- in an attempt to recapture it. so, it will be fascinating to see how the industry reacts to this change.

While the blob-related changes will grab headlines in Fusaka, the largest number of changes fall into the 'Scale the L1' category.

EIP-7935 is the most obvious change to highlight in this section as it is literally about increasing Ethereum's capacity at the base layer. It raises the block gas limit -- the size of a block in terms of how much computational effort it contains -- from 45m to 60m gas, a 33% increase.

This isn't considered a 'core' EIP, because Ethereum's validators are able to coordinate an increase in gas limit by simply signalling their readiness for it.

However, because any large blocksize increase should be thoroughly tested before going live, the EIP was included in Fusaka to ensure developers were preparing their clients for the additional workload.

As validators across the network have updated their software in preparation for Fusaka, the number of them signalling readiness for 60m gas increased until the network reached quorum at the end of November. Therefore, this change is actually already in effect -- before Fusaka has gone live.

Still, I wanted to mention it here as it's a large break from Ethereum's past.

Until February of this year, Ethereum hadn't increased its gas limit since the Merge in September 2022 -- despite continued improvements in consumer hardware and widespread criticism of Ethereum's limited throughput.

7935 is a sign that Ethereum is finally responding to that criticism, and showcases the EF's and the community's renewed focus on L1 scaling. It means Ethereum has doubled its capacity in just one year.

And it doesn't plan on stopping there. Instead, Ethereum is set to continue growing the base layer for the foreseeable future. Various optimisations and developments could allow Ethereum to triple its capacity each year for the next few years.

Fusaka includes 5 EIPs that will make this kind of scaling both safe and achievable.

This collection of changes includes EIP-7934, which adds a maximum block size measured in bytes to the limit measured in gas. Specifically, it limits blocks to a maximum of 10MB.

Whilst still large, it will stop blocks from becoming unreasonably heavy and propagating slowly across the network -- something that could result in temporary forks and disruption. It will also reduce the risk of denial-of-service attacks against Ethereum.

Another example would be EIP-7939, which introduces a new opcode to counts the number of leading zeros at the start of a 256-bit number. It may not sound like a particularly exciting change, but it will dramatically reduce the cost of certain operations and make some on-chain calculations much more efficient.

7939 is exactly the sort of update that can unlock additional performance from Ethereum's layer 1, especially when it's combination with other such changes.

Finally, I want to mention to EIP-7825, which caps the cost of a single transaction and stops them from hogging all the blockspace.

This change is very clearly focused on protecting Ethereum as it increases its block gas limit -- but it also keeps an eye on the future.

Because it limits how large a transaction can be, it effectively guarantees that blocks will contain multiple transactions. This is important because future Ethereum upgrades will introduce parallel processing of transactions, which would obviously not be possible if a single transaction could occupy all available blockspace.

Taken together, these EIPs, along with some others I haven't mentioned, will ensure Ethereum can scale safely and smoothly in the years to come.

I suspect that the blob and L1 scaling-related EIPs will garner most attention in Fusaka, but that doesn't mean it won't deliver significant UX improvements at the same time.

For me, there are two that stand out.

EIP-7917 makes it clear which validators will be proposing blocks at a much earlier stage than we see today. Not only this, but the list of validators who will be proposing blocks will be completely deterministic and available onchain.

While this may not sound overly useful, it's actually incredibly important for the development of based rollups and preconfirmations.

Without going into all the details of what these terms mean right now, I'll just say that they could enable Layer 2 chains that feel truly rapid and more akin to web2 products -- all without sacrificing Ethereum's decentralisation or security guarantees. Based rollups should also drive more value to the L1 and, therefore, to Ether as an asset.

It's still early days for both based rollups and preconfirmations, so the UX improvements won't be immediate, but this change definitely lays the foundation for them.

And, as a nice bonus, it also closes off some niche attack vectors and further strengthens Ethereum's design.

EIP-7951 is likely to have more of a UX impact in the short-term.

Essentially, it gives Ethereum native support for a cryptographic curve known as P-256 that is used widely used in everyday devices like your phone. In fact, P-256 is used in everything from Apple's Secure Enclave to Android's Keystore to WebAuthn passkeys.

As a result, once Ethereum supports this curve, wallets will be able to do away with seed phrases and rely entirely on device-level biometrics and pass keys. This means they will look and feel much more like the traditional web2 applications that most people are used to.

It's the sort of change that is easy to overlook because of its abstract and technical-sounding name, but it has the potential to completely transform the way people interact with Ethereum and significantly lower the barrier to entry.

Hopefully you not only have a better understanding of what Fusaka means for Ethereum, but you can see how clearly it supports Ethereum's strategic objectives.

This isn't Pectra's loose collection of incremental improvements, this is a bold, laser-focused upgrade promising to boost Ethereum's throughput, scale blobs to support greater L2 activity, and improve the user experience.

Crucially it does all of these things without compromising on security, without compromising decentralisation, and while keeping Ether's value accrual in mind.

Yes, Fusaka doesn't solve all of Ethereum's problems. And yes, some on Twitter will surely mock Ethereum's 'L1 scaling' as throughput continues to lag well behind big-block chains like Solana, even after it's recent doubling.

But Fusaka is 100% a step in the right direction, and it represents a much larger change than it delivers.

It may be too early to say Ethereum is back, but this update suggests its darkest days, wandering aimlessly in the wilderness, are firmly behind it.