April 9 (Cointime) - zkSync, a Layer 2 scaling solution for Ethereum, has announced an update on their support for legacy Solidity functions in the zkSync Era, after the Gemholic case. GemSwap, the decentralized exchange operated by Gemholic, lost temporary access to 921 ETH (approximately $1.7 million) raised in a token sale due to a bug in their smart contract.

GemSwap is the fifth-largest DeFi protocol on zkSync Era, with a total value locked (TVL) of $3.7 million, according to DeFi Llama. The project accounts for 5.6% of Era's combined TVL.

In response to this incident and other challenges, zkSync has shared that .transfer() and .send() functions will now work exactly as they do in the Ethereum Virtual Machine (EVM), with no need for a reorg or regenesis. The solution involves a normal protocol upgrade aimed at addressing the issues users have been experiencing with calls that have a value greater than zero.

Read full thread:

First of all, and most importantly, the solution does not involve any kind of reorg or regenesis. It will be a normal protocol upgrade.

Buckle up: the rest of this thread will be highly technical.

On zkSync Era, calls with value>0 go through the MsgValueSimulator system contract, consuming some gas (more than the 2300 stipend for the transfer function on L1). This is why calling transfer without providing gas fails on the zkEVM.

The change: calls to the MsgValueSimulator, which had no minimum gas requirements, will now require at least 2*64*pubdata_bytes + K ergs. The pubdata is needed to transfer value, and K will be chosen high enough to process the transfer.

At the end of the MsgValueSimulator, it will be ensured that at least 2*64*pubdata_bytes + K' was spent to process the transfer (if fewer ergs were spent, the refund will go to the caller). K - K' will be zkSync Era stipend.

To protect from reentrancy we'll make sure that storage write costs are at least K - K' ergs. This approach is very much aligned with Ethereum: charge users more when value > 0 with some stipend granted.

Effectively, this means that the stipend will enable one and only one storage update, and nothing else (exactly as in EVM).

The change might slightly impact the estimate of the tx costs and the actual tx cost after refund. However, the gap between estimation and actual fee will be drastically reduced in the future.

This new behavior will take some time to implement, and will be deployed after diligent testing, auditing, and community review with the next protocol upgrade. We’ll do our best to expedite this process.

If you want to learn more, we will be happy to welcome you in our Discord developer community and answer all the questions: https://join.zksync.dev