What if we build an App Rollup for only one use case: storing ERC-20s?

As you all know, Ethereum's biggest problem currently is interoperability. There are 50 rollups, and it feels like 50 different chains, not one ecosystem. Fortunately, we have amazing researchers, and we can solve it through social coordination and an app-specific, rollup-based solution.

No, it does not need a token.

Keystore Rollups:

Before Account Abstraction, identity was managed off-chain, which means if you have a private key and an account address generated from that private key, you get the same address across all EVM rollups. Since key rotation is not possible with EOAs, you can directly set up your RPC and start using any EVM chain you want with your wallet. (This is how MM and Rabby-like EOA wallets work today).

Account Abstraction changed this and moved identity management on-chain, enabling tons of use cases like 1-click onboarding, different recovery methods (e.g., social recovery, ZK-email-based recovery, etc.), gas abstraction, and batch transactions. However, it comes with a drawback: if you want to update your keys, you need to change these keys on every chain where you deployed your account. Also, to have the same account address on another chain, you'll need the same account code that you deployed for the initial account—opening more problems. Image

Keystore rollups try to fix this issue by building a specific rollup just to store keys and manage identity. But why a new rollup?

You could store the keys on L1, but it is expensive. You could also store keys on any L2, but most rollups' finalization takes at least 30 minutes, and most of them are not as censorship-resistant as Ethereum. Thus, we need a new rollup.

Pictures are from https://hackmd.io/@ilikesymmetry/intro-keystore-rollup

Keystore is a ZK rollup designed to be "minimal," and its main function is to:

• Store keys and account addresses.

• Allow developers to configure rules for changing keys.

• Allow instant proving and settling to Ethereum.

• Inherit all security properties from Ethereum, including real-time CR.

As far as I remember, @base and @safe were exploring keystore rollups to build one.

If any user wants to update their account keys, they simply send a transaction on the keystore rollup. After that, the state root of the rollup is updated with the ZK proof. Then, L2s need to listen to L1's state and make the wallet aware of L1's latest state, which also contains the keystore rollup's state and the keys themselves.

However, today it is not possible for other L2s to listen to L1's state. There are some proposals, like L1SLOAD and REMOTESTATICCALL, to solve this problem. If we can get over all of those problems, we can consider utilizing this architecture for other use cases as well.

Solving the Bridging Problem by With the Keystore Rollup Architecture: TokenStore

While reading about the keystore architecture, I thought, why wouldn't we build a specific rollup just to store tokens? It would function almost the same as Keystore but would store ERC-20s. Other rollups would listen to L1's state and recognize token changes.

Users would store the information about "the amount of tokens they're storing on different rollups" on the TokenStore rollup. When a user wants to use their tokens on a rollup, they can directly go and spend their assets. When a user wants to make a cross-chain interaction, the only thing they need is to change the information stored on the TokenStore rollup—nothing else is needed. This can work natively if there's a shared bridge but can also work with wrapped assets.

The idea is to follow the path we have with Keystore rollups: you have the assets on the TokenStore rollup, and there is a wrapped or replicated form of it where users spend their assets on execution rollups while the asset storage resides on the TokenStore rollup. This means if a user wants to spend their tokens, they need to wait for the TokenStore state to be updated on L1. Thus, the transaction time will be equal to L1's block time.

I personally think this path would be the best solution for base and native rollups because they already share block-building with Ethereum. After making the blocks faster and the finality one slot, this design could also allow Ethereum to utilize its network effects for rollups. But it needs faster block and finalization times.

This was just an idea that came into my mind while reading new stuffs, would love to chat more if you have any opinions for this!

What if we build an App Rollup for only one use case: storing ERC-20s?

As you all know, Ethereum's biggest problem currently is interoperability. There are 50 rollups, and it feels like 50 different chains, not one ecosystem. Fortunately, we have amazing researchers, and we can solve it through social coordination and an app-specific, rollup-based solution.

No, it does not need a token.

Keystore Rollups:

Before Account Abstraction, identity was managed off-chain, which means if you have a private key and an account address generated from that private key, you get the same address across all EVM rollups. Since key rotation is not possible with EOAs, you can directly set up your RPC and start using any EVM chain you want with your wallet. (This is how MM and Rabby-like EOA wallets work today).

Account Abstraction changed this and moved identity management on-chain, enabling tons of use cases like 1-click onboarding, different recovery methods (e.g., social recovery, ZK-email-based recovery, etc.), gas abstraction, and batch transactions. However, it comes with a drawback: if you want to update your keys, you need to change these keys on every chain where you deployed your account. Also, to have the same account address on another chain, you'll need the same account code that you deployed for the initial account—opening more problems. Image

Keystore rollups try to fix this issue by building a specific rollup just to store keys and manage identity. But why a new rollup?

You could store the keys on L1, but it is expensive. You could also store keys on any L2, but most rollups' finalization takes at least 30 minutes, and most of them are not as censorship-resistant as Ethereum. Thus, we need a new rollup.

Pictures are from https://hackmd.io/@ilikesymmetry/intro-keystore-rollup

Keystore is a ZK rollup designed to be "minimal," and its main function is to:

• Store keys and account addresses.

• Allow developers to configure rules for changing keys.

• Allow instant proving and settling to Ethereum.

• Inherit all security properties from Ethereum, including real-time CR.

As far as I remember, @base and @safe were exploring keystore rollups to build one.

If any user wants to update their account keys, they simply send a transaction on the keystore rollup. After that, the state root of the rollup is updated with the ZK proof. Then, L2s need to listen to L1's state and make the wallet aware of L1's latest state, which also contains the keystore rollup's state and the keys themselves.

However, today it is not possible for other L2s to listen to L1's state. There are some proposals, like L1SLOAD and REMOTESTATICCALL, to solve this problem. If we can get over all of those problems, we can consider utilizing this architecture for other use cases as well.

Solving the Bridging Problem by With the Keystore Rollup Architecture: TokenStore

While reading about the keystore architecture, I thought, why wouldn't we build a specific rollup just to store tokens? It would function almost the same as Keystore but would store ERC-20s. Other rollups would listen to L1's state and recognize token changes.

Users would store the information about "the amount of tokens they're storing on different rollups" on the TokenStore rollup. When a user wants to use their tokens on a rollup, they can directly go and spend their assets. When a user wants to make a cross-chain interaction, the only thing they need is to change the information stored on the TokenStore rollup—nothing else is needed. This can work natively if there's a shared bridge but can also work with wrapped assets.

The idea is to follow the path we have with Keystore rollups: you have the assets on the TokenStore rollup, and there is a wrapped or replicated form of it where users spend their assets on execution rollups while the asset storage resides on the TokenStore rollup. This means if a user wants to spend their tokens, they need to wait for the TokenStore state to be updated on L1. Thus, the transaction time will be equal to L1's block time.

I personally think this path would be the best solution for base and native rollups because they already share block-building with Ethereum. After making the blocks faster and the finality one slot, this design could also allow Ethereum to utilize its network effects for rollups. But it needs faster block and finalization times.

This was just an idea that came into my mind while reading new stuffs, would love to chat more if you have any opinions for this!