Ethereum

Been working on a prototype and spec for @vitalik.eth's minimal keystore rollup

hackmd.io/@mdehoog/mksr

Please read and comment if you have thoughts

I'd also add that it feels very unlikely for the cost of a blob to go higher than the cost of submitting a SNARK to chain. Verification is around 500k gas, *at calldata-equivalent prices* a blob is 2m gas, so you'd need the L2-verse to be quite saturated for blobs to be above verification.

Great idea, thanks.

Current proposal for txs submitted to rollup nodes is to only post the modified key/value to L1 (64 bytes, essentially a state diff), which means a blob could hold around ~2000 transactions. But depending on blob fees, submitting a partial blob could still be cheaper than calldata.

You could make batches submittable via calldata *or* blobs?

So blobs are the usual path, calldata is the faster path in case there's very low activity.

Is the expectation that wallets inheriting this model would no longer use an internal `owner` list to manage access?

The `key` is always used as a reference for verification of what account is authorized to manage the smart account? And a proof (inclusion/exclusion) must always be generated to submit a transaction?

Interesting. Gas costs aside though, this method would require a lot of compute just in terms of proofs?

Perhaps with transaction costs being substantially less than the proofs themselves or is there some magic sauce in the works to bring that down?

Correct, the expectation is that the "owner list" is now stored in the data encoded in the MKSR state.

Yes, the idea is to generate an exclusion/inclusion proof for all SCW transactions. You could imagine some SCW implementations caching some proof internally for a short amount of time (like a "session") to save gas.

decentralized networking, wallet enthusiast 

The MKSR state root is stored on L1. Most L2s have some ability to read or prove something about L1 state, so it should be immediately usable on new L2s.

what does this look like for the user after deployment of a new chain, i.e. blast? how long before it's usable on new chains?

sounds super interesting! can't wait to dive into this. 🔍💡

wow, this is super cool! can't wait to see how it all comes together. good luck with the project! 🚀

looks awesome! i skimmed through it and it seems like a solid approach. i'm curious about the security aspects—how do you plan on handling potential vulnerabilities? also, is there a timeline for when this could be implemented? keep up the great work!

Cool stuff!

Probably should re-read but, off the cuff, reading L1 data would (should) be much more trivial than I think you're making it seem.

With verkle tree's we can construct super light proofs and just use a light client bridge to pass the data ?