Ethereum has struggled to process data-heavy blocks in recent weeks, an issue that suggests the network isn’t ready to take full advantage of its December upgrade.

That upgrade, codenamed Fusaka, substantially increased the amount of data that layer 2 blockchains can send to Ethereum.

But blocks containing more “blobs” — packets of data submitted by layer 2 blockchains such as Arbitrum and Base — are far likelier to be dropped by the network, according to research from MigaLabs, a research group that has collaborated with Lido DAO and the Cambridge Centre for Alternative Finance.

If it persists or worsens, the issue could threaten the stability of the network, the firm wrote in its report.

“My intention was not to be alarmist, but to raise a signal to the core developers and researchers that’s saying, ‘We need to take a look at this,’” Leonardo Bautista Gomez, founder of MigaLabs, told DL News.

“It’s important to not increase even more [blob] capacity until we fully understand what’s going on.”

Before Fusaka, layer 2 blockchains could only send Ethereum a maximum of nine blobs per block. After the upgrade, Ethereum’s blob capacity jumped eightfold. But increases would be enabled in a series of smaller upgrades.

“We could say here, in just a few minutes, dial this knob up 8x,” Alex Stokes, an executive at the Ethereum Foundation, said in a December livestream celebrating Fusaka’s deployment.

“Given this is a very new technique, and we’re not sure how the network will respond, this is not the wisest decision.”

The first mini-upgrade came less than a week after Fusaka, and increased maximum blob capacity to 15. Developers released a second upgrade on January 7 that increased max capacity to 21 blobs per block.

Curiously, the average blob count per block has decreased since Fusaka. The few blocks that do test the network’s limit, however, are more likely to cause the succeeding block to fail, MigaLabs found.

Research from PandaOps, a team within the Ethereum Foundation, came to a similar conclusion, but found that some of the issue could be attributed to “timing games” — a practice in which validators delay publishing their blocks in order to boost a revenue stream known as maximal extractable value, or MEV.

“I’m not worried about the network at the moment based on the analysis that I did,” Sam Calder-Mason, the engineer who conducted the analysis for PandaOps, told DL News.

“It was certainly worrying on first inspection though.”

There is a “rough consensus” among developers to push a minor update that would allow Ethereum to spread blob data more efficiently and quickly before increasing blob capacity, according to Calder-Mason.

“I’d personally push back on any further BPOs without it,” he said. “We will also need a more holistic round of analysis done before committing to a higher blob count.”

While Calder-Mason believes timing games might account for “~90% of what we’re seeing at high blob counts,” Gomez was more circumspect.

“We do see some correlation there between high blob count and timing games, but I still think that does not explain everything that I have observed,” the MigaLabs founder said.

Another possible explanation is, it’s simply difficult to propagate substantially more data across a distributed network.

“We are really trying to stress the capacity of the network as much as possible, within the limits that will still make the blockchain alive and efficient and working properly,” Gomez said.

“What we’re seeing now is that when we push the amount of data that we publish over the network a little bit too much, we are seeing some issues. We still don’t fully understand why exactly that happens.”

What has worked, he added, is Ethereum developers’ commitment to treading carefully when making changes to the network.

“If there is an issue, we most likely will be able to solve it,” he said. “We are following perfectly the process that we had in mind.”

Aleks Gilbert is DL News’ New York-based DeFi correspondent. Have a tip? You can reach him at aleks@dlnews.com.