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

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.

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?

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?

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.