Skip to content
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

Open
CaptainSantiago opened this issue Jun 6, 2024 · 1 comment
Open

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

CaptainSantiago opened this issue Jun 6, 2024 · 1 comment
Labels
bug Something isn't working

Comments

@CaptainSantiago
Copy link

🐛 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.
@CaptainSantiago CaptainSantiago added the bug Something isn't working label Jun 6, 2024
@PatrickAlphaC
Copy link

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working
Projects
None yet
Development

No branches or pull requests

2 participants