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

one of the hardest problems with smart contract wallets is how you manage keys across 10s or 100s or 1000s of chains.

@mdehoog from the @base team has been building on @vitalik.eth's initial specification for a keystore rollup - would love folks to review and share feedback!

Devconnect

@base builder #001; onchain cities w/ OAK & city3

I managed to invite @vitalik.eth to share this idea back in /devconnect Istanbul and recall 2 of the many challenges on the idea 

- Can we avoid recursive SNARKs and get L1 gas costs low by batching?
- How can we get enough L2s have L1-reading functionality?

I think there are more but I only jotted down the qs 👆

Contributing @bentobatch FID:12963
My opinions are trash, but Account Abstraction is the future. #ERC4337  
Hosting /bento-batch

Thanks, this is useful info. The first prototype we built avoided recursive SNARKs, but we couldn't figure out how to get the onchain costs to a reasonable place, even with batching. Ignoring the single pairing, napkin math was showing the total MSMs per proof adding up to min $5-10 per transaction.

Have you experimented with other proof systems as a way of simplifying the constraints?

Eg. using 64-bit STARKs for the "inner proofs", which are easier to recurse and make verifiers for, and then using one outer KZG-based layer (PLONK plus lookup-based?) to cut down the on-chain verification costs