Ethereum devs weigh mainnet features against rollup push

The July 4th Ethereum All Core Developers (ACD) call was a mellow affair focused on updates around implementation of the next Ethereum upgrade, Pectra.

Although several clients are making headway, the launch of Devnet-1 is being delayed until a greater number of clients are prepared. Client teams, expecting to be short staffed as developers attend the EthCC conference in Brussels, are looking to launch Devnet-1 in one to two weeks.

A theme on the call was hand wringing over Pectra scope creep.

Core developers refined the account abstraction-focused EIP-7702’s, which was a major topic on the last ACD call. A breakout subcommittee meeting worked out a way forward, to keep Externally Owned Accounts (EOA) more flexible, while addressing outstanding concerns previously raised.

Read more: The jury is still out on Vitalik’s account abstraction proposal

The new modifications are anticipated to be included in Devnet-2, and Devnet-1 will reflect the current specifications of EIP-7702. But the new changes get 7702 very close to a finished specification, according to Ethereum Foundation researcher Ansgar Dietrich.

What should Ethereum mainnet be?

The discussion then turned to EIP-7212, which has garnered support due to its potential to enhance user experience in key and wallet management.

This improvement introduces support for the r1 curve, a cryptographic algorithm widely used in secure communications and digital signatures.

EIP-7212 aims to simplify key and wallet management for users, reducing complexity and improving ease of use.

Hadrien Croubois, a smart contract engineer at OpenZeppelin pointed to the demand for r1 signatures coming from account abstraction work, particularly the desire to use a smartphone as a hardware wallet.

That’s precisely why Daniel Lehrner, developer for the Besu client, said his team is “definitely in favor of including it,” noting that this algorithm is supported by nearly all mobile phones. “So for us, it definitely makes sense to allow them to use that instead of a traditional [hardware wallet].”

Pseudonymous Geth developer Lightclient pushed back on the idea of adding a new precompile to Ethereum’s execution layer, flagging several details yet to be resolved.

“It’s not a difficult thing to implement, but Pectra is already mega, and at some point we need to ship Pectra and stop adding things, and it seems like we’re already way past that point,” Lightclient said on the call.

Danno Ferrin, chief software engineer of Swirlds Labs noted that while it would be better to include the r1 curve at the EVM level, that would delay it by at least a year and a half. Meanwhile, its support from major tech industry players such as Google Passkeys, should make it worth pushing sooner at the protocol level.

The debate underscored a broader theme at play: the need to balance new EIPs and features against the already extensive scope of Pectra.

Geth’s Marius van der Wijden, who is usually grumpy about scope creep, posited that such a feature may no longer be needed on mainnet at all, because no one is using smart contract wallets due to their operational costs.

“In general I’m in favor of it, it’s just I think there’s an argument to be had,” van der Wijden said, adding, “in my view we should focus on getting functionality onto rollups and focus everyone on blob scalability, and not focus too much on the EVM feature set on L1.”

But Richard Meissner from the Safe smart contract wallet team said they still see plenty of reasons to improve the user experience at the base layer of Ethereum.

“At least in the current state, one is not perceived as ‘we want to move away from L1’. If we as an ecosystem agree on this I think this would be a little bit of a mindset shift,” Meissner said. “A lot of teams are still on L1 and a lot of teams do prefer to have better UX and r1 will enable this.”

Despite the generally positive reception, a formal decision on inclusion of the r1 curve precompile in Pectra has been postponed until the next ACD call in two weeks.

Source