search

matter-labs / zksync-era

zkSync era
Apache License 2.0
3.1k stars 2.07k forks source link

Mass adoptions issue with Zksync-era and other L2s #2172

Open CaptainSantiago opened 5 months ago

CaptainSantiago commented 5 months ago

🐛 Bug Report

📝 I have a problem which is a mass adoption issue. I think this will be a common problem among new users. If a new user sends an asset, for example ETH, to a Zksync-era address that does not exist, then that transaction should bounce back, fail, or be recoverable through some mechanism. As it currently stands I believe the ETH would sit in that non-existent address until the unlikely time when that address is created. A case in point is the following transaction in which case the ETH was being sent from a Zksync-era address to an Ethereum address improperly without using a bridge, so the program code interprets the receiving address as a Zksync-era address, but that address is non-existent within Zksync-era:

0x098d454d9dcdfcd01d6780b525d45f544566197b28de46cb0fce51feb6615feb

Am I correct that, in the current environment of Zksync-era, these funds can never be recovered even though they are sitting in a non-existent Zksync-era address? This seems like a problem that could be addressed automatically within the blockchain contract execution process.

🔄 Reproduction Steps

Steps to reproduce the behaviour

🤔 Expected Behavior

Describe what you expected to happen.

😯 Current Behavior

Describe what actually happened.

🖥️ Environment

Any relevant environment details.

📋 Additional Context

Add any other context about the problem here. If applicable, add screenshots to help explain.

📎 Log Output

Paste any relevant log output here.
PatrickAlphaC commented 5 months ago

Technically, all addresses are created, and users just need to "mine" the private key. There are no such thing as an "address that does not exist".

I bet that sounds confusing, but let me explain in a second.

It's for this reason that it wouldn't make sense at the moment to do the suggestion you say, and let me illustrate a few reasons why, and hopefully this will clarify why the architecture is as it is.

Scenario 1 | New Wallet

Let's say you're a new user, and you download metamask. Metamask will generate you a new random private key, and give you an associated address. If you look on chain at that address, it will be blank, and no transactions.

If zkSync implemented a system where ETH sent to an unused wallet address revert, then this new wallet would never be able to get funds!

Well, what if we make them identify their wallet as "active"?

The EVM / EraVM system could 100% do this, but it would require more work from both users and EVM nodes. People could "attack" the system, make nodes use unnecessary power to mark wallets as active.

That's an interesting proposal, but it also means that we wouldn't be able to do clever stuff like scenario two.

Scenario 2 | CREATE2 deployed contract

Let's say you want to make a smart contract that can hold ETH, but only right when the contract is deployed, and it should never be able to accept ETH again. Well, one way you can do this today, is to send the ETH to where you expect that contract to be deployed. Developers today can deterministically deploy smart contracts. If we had ETH transactions revert on "un-used addresses", then we'd lose this functionality of:

  1. Dev sends ETH to address where they will deploy smart contract
  2. They then deploy the smart contract there, and it's already funded!

Summary

I hope for the reasons stated above you understand why this wouldn't be possible. Please let me know if otherwise.