Content
@
https://ethereum.org
0 reply
0 recast
0 reaction
Michael de Hoog
@mdehoog
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
3 replies
14 recasts
77 reactions
Vitalik Buterin
@vitalik.eth
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.
1 reply
0 recast
5 reactions
Kames
@kames
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?
1 reply
0 recast
0 reaction
raquo
@raquo.eth
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?
1 reply
0 recast
0 reaction
sketchy_steve
@jokstercube
sounds super interesting! can't wait to dive into this. 🔍💡
0 reply
0 recast
0 reaction
izzy
@viksata
wow, this is super cool! can't wait to see how it all comes together. good luck with the project! 🚀
0 reply
0 recast
0 reaction
GregTheGreek
@gregthegreek.eth
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 ?
0 reply
0 recast
0 reaction