An Overview of PPGC #19

PIP 22 (EIP 3074)

Manav Darji from the Bor client team provided an update on their progress in implementing EIP 3074 style account abstraction. The Bor team has a PR open that implements the AUTH and AUTH_CALL opcodes. Over the past two weeks, they have been adding more tests and accommodating changes to match the latest spec of EIP 3074. Bor is currently testing their implementation internally on a devnet. There are patches for Solidity and Foundry available to test these new opcodes. The next step is to do as much adversarial testing as possible before deploying to Polygon's testnet. 

Harry Rook, Polygon Governance PM, noted recent discussions about potentially including EIP 5003 in the fork after Pectra on Ethereum to mitigate some concerns with EIP 3074. This will likely be a topic in the next PPGC meeting.

PIP 36 (Replay Failed State Syncs)

Dhairya Sethi, the author of PIP 36, explained that the purpose is to add the ability to replay failed state syncs until the full migration to the LXLY bridge is complete. It also patches a bug in the Matic token contract related to the gas cost increase of SLOAD in Ethereum's Berlin hard fork which broke contracts using TRANSFER to send ETH to contracts with code in the RECEIVE or FALLBACK functions. 

PIP 36 aims to fix failed state syncs in two ways:

1) Replace TRANSFER with CALL in the Matic token contract to provide sufficient gas and prevent failed deposits when the receiver is a contract with code. This requires a hard fork since the contract is not upgradeable.

2) Add the ability to replay failed state syncs, both past and future. For past failed state syncs between the Shanghai fork and, a Merkle tree will be constructed of the failed state IDs so users can prove and replay their failed state sync. For future failed state syncs, the contract will store the receiver and calldata so it can be replayed externally. Security considerations are taken to prevent reentrancy and ensure immutability of the replayed transaction.

The failed state syncs that occurred from block 38,457,210 (around Nov 30, 2023) up to the fork will be replayable.

PIP 30 (Increase Max Code Size Limit)

David Silverman explained PIP 30 which proposes increasing the max code size and max initcode size by 33% to allow deploying more complex contracts. The current limits were set arbitrarily in the Spurious Dragon hard fork and developers are now frequently hitting these limits. Analysis shows this increase would not negatively impact the ZK migration plans. The intent is to slowly raise this limit, potentially moving to even higher values later in conjunction with the rollup coordination group.

Minimum Gas Price Increase

Marcelo Ardizzone presented a new PIP to increase the default minimum gas price to 30 gwei to reduce spam transactions. Currently this is just a node client setting, not a network level parameter. Having different minimum gas prices across validators leads to transactions getting stuck if they are priced for a validator with a lower minimum. 

The PIP enforces the 30 gwei minimum at the network level in three ways:

1) Sets the default minimum gas price for validators to 30 gwei

2) Sets the default gas price limit for accepting txs into the transaction pool to 30 gwei  

3) Sets the threshold below which the gas price oracle ignores transactions to 30 gwei

This is implemented via code changes in the Bor and Erigon clients. Validators can still set custom gas parameters if desired by modifying the client code and running a custom version.

With no major concerns expressed, developers seemed ready to move forward with this inclusion list for the upgrade. The Bor and Erigon teams confirmed they are okay with the proposed changes.

Coordination with Ethereum

When asked about coordination with Ethereum's Pectra upgrade that also plans to include EIP 3074, David Silverman said the intention is for Polygon to move ahead of Ethereum on this as they have done with previous upgrades like EIP 7212. Protocol developers are working closely with rollup teams who are also implementing 3074 to maintain compatibility. The hope is that Ethereum does not intentionally try to break this compatibility.

Next Steps

With the inclusion list finalized, protocol developers will target shipping these changes at the end of May or early June depending on testnet deployment timelines. The next PPGC meeting is tentatively scheduled for May 30 but may shift a week or two to align with the rollout.

Blockworks Research View

A few key developments were discussed on the call this month. Firstly, the Bor client team provided an update on their progress in implementing EIP 3074 style account abstraction through PIP 22. As previously discussed, EIP 3074 introduces AUTH and AUTHCALL which are set to allow for control of externally owned account (EOA) to be delegated to a smart contract. Similar to EIP 3074, PIP 22 aims at extending the functionality of "accounts", i.e. contracts or EOAs. PIP 22 would enable EOAs to authorize other addresses to spend its assets, improving user experience by allowing gas payments in ERC20 tokens and removing the need for approve-and-transfer (i.e. multiple transactions). Overall, account abstraction is often hailed as a critical step towards reducing friction, enabling more intuitive wallet, payment and account management and improving user experience, so it's exciting to see the Polygon network take active steps towards implementing it.

Polygon core developers also discussed PIP 30, which relates to increasing max code size limit and max initcode size by 33%. As of now, developers have reportedly been hitting code size limits, especially when deploying more complex contracts. According to Mudit Gupta, Vitalik had previously raised some concerns regarding increasing max code size limits, citing that it might make light clients slightly less light. There are no significantly negative repercussions from increasing max code size. As David Silverman mentioned on the call, it would have no negative impact on ZK migration plans, and the original max code size was chosen arbitrarily.

Apart from these two PIPs, there was also discussion surrounding increased minimum gas price and PIP 36, which are both relatively straightforward.