-
Notifications
You must be signed in to change notification settings - Fork 2.1k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Mass adoptions issue with Zksync-era and other L2s #2172
Comments
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 WalletLet'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 |
|
🐛 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
The text was updated successfully, but these errors were encountered: