The Ethereum community has been discussing recently the .transfer function and its use on Ethereum and other EVM chains versus zkSync, a Layer 2 scaling solution built on Ethereum. According to a tweet by 0xedenau, the transfer() function does not work on zkSync, which has caused some confusion and concern among users.
The .transfer function is a widely used method to send Ether or other tokens from one address to another on the Ethereum blockchain. It is an essential function for many dApps and smart contracts, and its inability to work on zkSync has raised questions about the network’s usability and compatibility with Ethereum.
However, it’s important to note that while the .transfer function may not work on zkSync, there are other ways to transfer funds on this network. For example, users can utilize
payable(address).call[value: <X>]("").Here are some changelogs mentioned on February 20th, 2023 in the Zksync documents.
- Fixes a bug that detected ERC20
transfercalls as ETHtransferand produced a compilation error. - Detection of
transferandsendmethods in smart contracts now returns a warning message (similar tov1.3.1). The new warning message reminds developers that using these methods to transfer ETH can cause issues and suggest replacing them withpayable(address).call[value: <X>]("").
In recent news, zkSync has claimed to have found a solution to unlock the 921 ETH ($1.7 million) that is stuck in a smart contract used by a team called Gemholic on its Era network. The funds became trapped in the contract due to an issue with using the .transfer function, which resulted in a hard dependency on gas costs. When the .transfer function is used to send Ether to a smart contract, the fallback() function is triggered. If the fallback() function requires more than the allocated 2300 gas, the transaction may fail, and the funds get stuck.
The zkSync team further stated that Gemholic deployed contracts on the Era mainnet without testing on the testnet or a local node. It’s worth noting that zkSync gives a warning about the .transfer function directly in the compiler to mitigate gas issues, which was likely ignored by the Gemholic team.
However, zkSync claims that they have “discovered an elegant method to unlock the frozen contract,” and they assure users that their funds are safe. It’s important to note that zkSync is a ZK-Rollup Layer 2 scaling solution developed by Matter Labs that can support Ethereum smart contracts.
Here is a link to an article about zkSync unfreezing millions of stuck tokens: https://www.theblock.co/post/225364/zksync-unfreeze-millions-stuck
💡Conclusion
Despite zkSync’s fast and cheap transactions, the inability to use the widely used .transfer function may still be a significant issue for some developers and users. While there are alternative solutions available, zkSync may not be the best option for dApps or smart contracts that heavily rely on the .transfer function. It’s important to carefully consider the limitations and drawbacks of zkSync when deciding which Layer 2 scaling solution to use.
It is also worth noting that other Layer 2 scaling solutions, such as Optimism, Arbitrum, and Polygon, are EVM equivalent where as Zksync is not. Although zkSync is language-compatible it is not EVM-equivalent. This means that all code written for the Ethereum mainnet does not function the same way on zkSyncEra.
It’s worth noting that the compilers in zkSync don’t flag all incompatibilities, so please make sure to test your code before using it in production. What do you think about this situation?
