zkSync has given support to Gemholic, a multi-product platform that faced an issue with their smart contract on zkSync Era. 

Gemholic deployed their token contract and conducted a pre-sale launch on zkSync Era, but faced a problem due to the usage of the .transfer() function. The contracts were deployed on Era mainnet without prior testing on a testnet or local node, which could have identified the issue earlier.

"Funds are safe. We found an elegant solution how to unfreeze the contract.", zkSync stated in a tweet. The team said a solution to unfreeze the contract has been found, which will entail minimal changes to gas metering in the protocol but will allow for complete fund recovery. 

Smart contracts using transfer() or send() rely heavily on gas costs, as these functions forward a hardcoded amount of 2300 gas. However, this isn't guaranteed to work on Ethereum, since the fallback() function can consume more than 2300 gas, and opcode gas pricing may change in future Ethereum versions.

zkSync also highlights that zkSync Era is not EVM equivalent. zkSync Era's deliberate design choice to diverge from EVM equivalence results in dynamic gas metering, allowing some transactions to be 10x to 1000x cheaper than on other EVM rollups.

Read full thread:

@GemholicECO is a multi-product platform that recently deployed their token contract and performed a pre-sale launch on zkSync Era. After deployment they encountered an issue with their contract due to the usage of the .transfer() function.

Unfortunately, the contracts were deployed on Era mainnet without having been tried on the testnet or local node, which would have immediately caught the problem.

Any smart contract that uses transfer() or send() is taking a hard dependency on gas costs, because this functions forward a hardcoded amount of 2300 gas.

This is not guaranteed to work on Ethereum!

1) fallback() function can consume more than 2300 gas,

2) opcode gas pricing can change in future version of Ethereum, and your contract will break.

Developers have been warned about this 3 years ago:  Stop Using Solidity's transfer() Now

@zksync Era is not EVM equivalent. This is a deliberate design choice. Era has a diverging, dynamic gas metering, which allows some transaction types to be 10x to 1000x cheaper than on any other EVM rollup! 

At the current gas pricing levels of Era mainnet, ETH transfers will cost more than 2300 gas. Which is why any .transfer() call without explicit gas stipend will currently fail.

It was clear to us that this problem could arise, so we added a warning about .transfer() directly to the compiler:

We took one more extra step and checked the source code of dozens of popular crypto projects. We didn't find a single one not following the 3 year old warning of not using .transfer(). We concluded that the dev community has since long closed this issue.

However, the GemholicECO situation has demonstrated that this is not the case. We took their problem extremely seriously. We will always do our best to provide support and guidance to developers and communities building on @zksync.

In this case, we identified an elegant solution which can solve a broader class of gas-related problems. It will require minimal changes in the gas metering of the protocol, but will allow for full recovery of the funds. We will publish more details on it tomorrow.

zkEVMs are complex systems that are in the process of maturing. Even though zkSync Era is still in Alpha, we’ve already got a thriving ecosystem.

We’ve seen a tremendous spike in activity, the most any scaling solution has ever undergone in such a short period of time; it’s been two weeks since our launch and we've risen to the 4th highest TVL and 3rd highest usage of all L2s.

With this comes great responsibility and inevitably the occasional friction and today was one of these instances. When there are problems our team will continue to be on alert and be relentless in resolving issues.