Suddenly, it feels like everyone in the Ethereum world is buzzing about something called native rollups. Even Ethereum Foundation researcher Justin Drake mentioned that everyone he’s talked to about this idea is fully on board.

Big names like Optimism, Base, and a bunch of other Layer 2 solutions (L2s) are saying they’re keen to integrate this tech into their platforms. Some are even aiming to become “based rollups” too, just to add another layer.

However, Justin Drake’s initial post about this back in January on EthResearch was quite technical, geared towards blockchain developers. Plus, most explanations out there are filled with complicated blockchain jargon. This leaves many regular Ethereum enthusiasts scratching their heads, wondering what native rollups actually are and how they even function.

That’s why we’ve brought in some experts from the 2077 Collective and the Ethereum Foundation. They’re here to break it all down for us in plain English so we can all understand what’s going on.

What exactly is a native rollup?

In short, native rollups are designed to make L2s just as secure and trustworthy as Ethereum itself. They do this by having the main Ethereum network handle the complex security stuff that currently requires intricate Zero Knowledge (ZK) or fraud-proof systems on each individual L2.

Imagine this: Using a native rollup could feel so safe that you’d be comfortable keeping your entire life savings—say, $10 million—there, just as you would if it were directly on Ethereum.

“Native rollups? They seem like a total no-brainer for rollups,” says Ladislaus, a researcher at the Ethereum Foundation. “They’re way simpler and much more secure.”

“With just a few lines of code, by using a ‘precompile’ in the future, they can inherit the robust security of Ethereum’s main layer (L1).”

That “precompile” he’s talking about is like a special built-in smart contract within the Ethereum protocol. It boosts the capabilities of the Ethereum Virtual Machine (EVM). Drake’s idea is to create a super useful “execute precompile” to turn native rollups into what he calls “programmable execution shards.”

Think of it as a kind of relaunch of the old Eth 2.0 sharding plan.

How do native rollups actually work?

Essentially, native rollups are a revamp of how proofs function within L2s. These proofs are like cryptographic snapshots that capture the state of ownership on rollups, and they get periodically recorded on Ethereum. By saving these L2 states onto the Ethereum blockchain, rollups get to leverage Ethereum’s massive, decentralized network. This means users gain the ability to withdraw their funds from rollups whenever they need to, without needing permission, and even force through transactions if they’re being blocked by the rollup’s sequencer.

Right now, optimistic rollups compatible with the Ethereum Virtual Machine (EVM) basically work by assuming everything that happened on the rollup was correct (hence “optimistic”). They then post this assumption to Ethereum. After that, there’s a seven-day window where certain authorized entities can challenge anything suspicious using a “fraud proof” before users can move their assets back to Ethereum.

On the other hand, EVM-compatible ZK-rollups, like Linea, employ cryptographic proofs that undeniably demonstrate that computations were correctly executed on the rollup. This allows for much quicker withdrawals to the main Ethereum layer (L1).

Also read: Pectra hard fork explained — Will it get Ethereum back on track?

The native rollup proposal would remove the need for L2s to set up these complicated proof systems and security councils they currently use. Instead, they would provide the Ethereum base layer with a “trace,” which is simply a list of all the transactions that occurred.

Then, the “execute precompile” comes in. It utilizes Ethereum’s own processing engine to re-run the computations and confirm the state changes. In simpler terms, it checks to make sure everything that happened on the rollup was valid and correct.

Future iterations are expected to incorporate ZK-proofs, which is when native rollups will really shine and become even more powerful.

What advantages do native rollups offer?

The biggest wins are that rollups won’t need to create their own complicated proof systems or rely on security councils or multisigs. These are often needed as backup plans in case things go wrong or proofs have bugs, and they usually involve a small group of trusted individuals.

“Native rollups eliminate the risk of funds being stolen because of a flaw in their proof system and can confidently do away with security councils, which boosts decentralization,” explains Alex Hook, a researcher at 2077 and CEO of Untronfi.

And for us users? Hook points out, “Your funds on a native rollup gain the same level of security as Ethereum itself, without adding any extra trust assumptions.”

The potential downsides of native rollups

For the main Ethereum network (L1), Hook explains that native rollups bring “fully secure and decentralized scaling, but it comes at the cost of making the protocol significantly more complex.”

Another challenge is that using Ethereum nodes to re-run all the transactions to verify their correctness might be slow. This seems counter to the whole point of rollups, which is to offload processing from the, let’s face it, rather slow Ethereum base layer.

While the “execute precompile” is designed to be a bit more efficient than full transaction re-execution, Drake emphasizes that this first version should be seen as just an “initial step” in the development process.

Ladislaus thinks this approach might actually be a great fit for optimistic rollups.

“That’s because optimistic rollups only need to use the precompile when settling a fraud-proof challenge. So, for L1 validators, the verification of these challenges would be the only (and quite small) overhead they’d need to handle,” he points out.

The long-term plan is to have Ethereum block builders generate ZK-proofs, which would then be verified by nodes. This would eliminate the need for re-executing everything.

The even longer-term dream is that “ideally, creating a ZK-EVM block for Ethereum could eventually be done on something as simple as a Macbook Pro,” Ladislaus muses.

Currently, ZK-proofs aren’t quite fast enough to be incorporated practically. They’re also costly to generate, which explains why ZK-rollups haven’t really become mainstream yet.

One way to boost efficiency might be to use recursive proofs—essentially, a proof that verifies a bunch of other proofs. This is similar to bundling and compressing proofs to make them more manageable.

Early challenges and possible fixes

Right now, each rollup has tweaked its own version of the EVM. Getting the Ethereum execution engine to work seamlessly with all these customized systems could be tricky. It’s likely that standards will need to be established before rollups can upgrade to native rollups. This would ensure their specific optimizations are compatible. Or, they might just opt for using a completely standard copy of the EVM.

Interestingly, this potential standardization could be a good thing, not a drawback. Currently, EVM-compatible rollups are in a constant race to update themselves to keep pace with Ethereum’s regular hard forks. This catch-up game is a security risk and can introduce bugs. Native rollups, however, could potentially update automatically whenever there’s an L1 hardfork.

Hook believes this would make life easier for developers, reducing “dev friction.”

“Currently, most L2s deviate from the main L1 specification to some degree, and developers always need to keep these differences in mind,” he says.

Possible data availability problems for native rollups

As with just about everything on the Ethereum roadmap, data availability is a key consideration.

Native rollups will need to publish “state witnesses,” which is going to take up a lot of space in data blobs. Capacity is already tight. However, the good news is that blob capacity is set to double in the next fork, and then increase by another 2x to 4x in the Fusaka fork, which is being pushed forward for this year.

Ladislaus points out that native rollups must be either “rollups” (meaning they use Ethereum for data availability) or “optimums” (optimistic rollups that use alternative data availability solutions like Celestia or EigenDA). He clarifies that native “validiums”—ZK-rollups using alternative DA—aren’t really in the picture, which “may increase demand for Ethereum DA.”

What’s the expected timeline for native rollups?

It’s still early days for native rollups. Drake’s initial proposal on EthResearch.ch only went live in January, and so far there have been a couple of community discussions about it.

But, the idea is gaining momentum fast. During that January sequencing call, about half a dozen L2 projects expressed their support.

“Optimism is ready to back based sequencing and native execution. We’re in a crucial phase,” declared co-founder Ben Jones.

Jesse Pollak from Base added, “We need to scale and connect the Ethereum ecosystem, and based sequencing along with native execution seems like the right toolkit to achieve this.”

Ladislaus notes that this strong interest from rollup founders “shows a real urgency and ‘product-market-fit’ for the kinds of services Ethereum could offer.”

Even with this enthusiasm, it’s unlikely native rollups will make it into either the Pectra hard fork (currently on testnet) or Fusaka later this year (which is heavily focused on scaling blobs).

That means we’re probably looking at “Glamsterdam”—the early name for the fork after Fusaka—as the earliest possibility. Drake estimates that the first version of native rollups could be included in a fork within about 18 months. However, Uma Roy, co-founder of Succinct, mentioned on Bankless that she thinks the ZK tech part might even be ready by then too.

Native rollups vs. based rollups: What’s the difference?

There’s a related idea floating around called “based rollups.” This is where L2s use Ethereum validators to act as a decentralized sequencer. This opens the door for “synchronous composability,” which, in simple terms, just means everything across the ecosystem of based rollups can interact and work together instantly.

It seems likely that many rollups will eventually aim to become both “based” and “native.” This combo has been nicknamed “ultra-sound”—though it’s still unclear when we might see this in action.

Also read: Ethereum L2s will be interoperable ‘within months’ — Complete guide

“Based rollups unlock powerful synchronous composability features,” Ladislaus explains. “They might be a tougher sell because rollup teams have to give up some control over sequencing. However, there are strong incentives to become both based and native, ultimately achieving what you might call an ‘ultra-sound rollup.’”

Not every rollup can transition to being based and/or native, especially those that use a different virtual machine than the EVM. Examples include Eclipse using SVM, Starknet with Cairo, and Movement using MoveVM.

Rollups like MegaETH are also unlikely candidates for becoming ultra-sound. They rely on a single, centralized sequencer, use alternative data availability, and prioritize speed over all else.

Subscribe

The most engaging reads in blockchain. Delivered once a
week.

Andrew Fenton

Based in Melbourne, Andrew Fenton is a journalist and editor focused on cryptocurrency and blockchain. He previously worked as a national entertainment writer for News Corp Australia, as a film journalist for SA Weekend, and at The Melbourne Weekly.

Follow the author @andrewfenton