Ahmedabad upgrade: Scope refinement

PIP-37: Ahmedabad Hard Fork: The main focus of the next call, scheduled in two weeks, will be on the Ahmedabad upgrade. There have been recent developments on the L1 side related to PIP-37 and PIP-24. Changes in Ethereum's plans, specifically dropping EIP-3074 in favor of EIP-7702, have significantly impacted the scope of the Ahmedabad hard fork. The team has decided to wait for the finalization of EIP-7702 specs before proceeding with the upgrade to ensure compatibility and a smooth transition.

Other PIPs: In addition to PIP-37, several other PIPs were discussed during the meeting. PIP-30 proposes increasing the maximum code size to allow for the deployment of more complex contracts without the need for alternative development patterns. PIP-36 aims to fix a bug in the state sync mechanism and provide an option to re-sync failed state sync transactions. PIP-35 addresses the nonuniform UX caused by config differences at the validator level by fixing the 30 Gwei parameter in the protocol.

Sync issues: The team has received reports of nodes syncing to the tip of the chain and suddenly stopping. While this issue is not widespread, it has been encountered by the team and a few partners. An investigation is currently ongoing to determine the root cause of the problem and develop a fix. The team has some promising leads and is working diligently to resolve the issue as soon as possible.

Coordination with Ethereum: Polygon intends to move ahead of Ethereum on the implementation of EIP-7702, similar to how they have handled previous upgrades like EIP-7212. Protocol developers are working closely with rollup teams to maintain compatibility and ensure a smooth transition. The team believes that waiting to include EIP-7702 in the hard fork is the best course of action, as it is a key feature that requires careful consideration and implementation.

PIP-25: Adjust POL Total Supply 

PIP-25, which was proposed in October of the previous year, involves a trivial upgrade to the Migrator contract. The upgrade calls a burn function to burn previously burned Matic via EIP-1559, bringing the POL supply in line with the Matic burned to the 0x00...Dead and Matic token addresses. The payload for this upgrade has been prepared, and the security team is conducting a final review. The next steps involve the Protocol Council executing the initial phase and pushing the upgrade into a 10-day timelock period. Following the timelock period, a transparency report will be posted on the forum detailing the individual moving parts and how they will be affected by the payload.

Heimdall Release v1.0.6 

Heimdall Release v1.0.6 was an emergency rollout to fix a bug reported through the ARB Bounty program. The bug allowed a milestone message to be posted as a checkpoint message under rare conditions, enabling malicious validators to exploit the system. The team fixed the issue by removing the spoofable message and adding hard checks around the milestone ID format. Internal testing has been conducted, and no issues have been observed since the release.

Other Business

Dimitri reported an odd rewind issue that affected three nodes on different DCs last week. The issue caused the nodes to rewind to about 65,000 logs instantly without any obvious reason in the logs. The team is currently monitoring the situation and has asked to be notified if the issue occurs again.

Blockworks Research View

Few key PIPs were discussed on this month’s PPGC, the main one being PIP-37: Ahmedabad Hard Fork. The Ahmedabad hard fork will include 4 PIPs alongside:

PIP-30: Increase Max Code Size Limit to 32KB

• Increasing the max code size limit will be beneficial for developers who are hitting code size limits, especially when deploying more complex contracts.

PIP-22: EIP-7702-style Account Abstraction

• EIP-3074 (which has been dropped) proposes the introduction of two new opcodes, AUTH and AUTHCALL, which would allow externally owned accounts (EOAs) to delegate control of their account to a smart contract, enabling more flexibility and programmability in account management.
• EIP-7702 introduces a new transaction type that allows a temporary upgrade to smart contract accounts for a single transaction. The motivation behind this proposal is to ensure forward compatibility.
• EIP-7702 avoids introducing new opcodes, aligns with ERC-4337, provides flexibility, and makes minimal changes to the Ethereum protocol. This helps address some of the concerns raised about EIP-3074 while still moving towards the goal of account abstraction.

PIP-36: Replay Failed State Syncs

• Replacing TRANSFER with CALL in the Matic token contract, preventing failed deposits to contracts (requires a hard fork).
• Enabling replay of past and future failed state syncs using a Merkle tree of failed state IDs and storing receiver and calldata, while ensuring security and immutability.

PIP-35: MinGas Increase

• Goal is to reduce spam transactions.

Our research view on PIP-36, PIP-30 and PIP-35 were discussed also in the last PPGC notes, which you can find here. The only notable change since then has been the adoption of EIP-7702 over EIP-3074. Both are related to account abstraction, but EIP-7702 was proposed by Vitalik to eliminate vulnerabilities and ensure forward compatibility, by improving upon EIP-3074.

EIP-7702 avoids introducing new opcodes, unlike EIP-3074, to ensure forward compatibility as Ethereum evolves. Instead, EIP-7702 introduces a new transaction type that allows a temporary upgrade to smart contract accounts for a single transaction, rather than a permanent change. This approach aligns with ERC-4337, allowing existing wallets and infrastructure to leverage the temporary upgrade mechanism. Furthermore, EIP-7702 leaves the specifics of the temporary upgrade mechanism open for future iterations, providing more flexibility. By introducing a minimal set of changes to the Ethereum protocol, EIP-7702 reduces the risk of compatibility issues with future upgrades.