Content
@
0 reply
0 recast
0 reaction
jesse.base.eth 🔵
@jessepollak
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!
3 replies
5 recasts
57 reactions
Joethebeast.eth 🎩🍱
@joethebeast1221
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 👆
5 replies
0 recast
2 reactions
Michael de Hoog
@mdehoog
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.
1 reply
0 recast
2 reactions
Michael de Hoog
@mdehoog
The ideal end state would be some ability to read L1 state directly on L2s, like Optimism's Remote Static Call proposal or Brecht's L1CALL proposal. It seems it will take some time before we standardize on this.
0 reply
0 recast
2 reactions
Michael de Hoog
@mdehoog
Re L2s having L1-reading functionality: this is a big missing piece. The options today are to either do MPT proofs on L2s that have access to an L1 state root, or for L2s that support it, send deposit messages on the L1 to L2s to update their MKSR root.
0 reply
0 recast
2 reactions
Michael de Hoog
@mdehoog
Admittedly we pivoted to recursion pretty early on; would love to hear from anybody who has optimized this.
0 reply
0 recast
1 reaction
jesse.base.eth 🔵
@jessepollak
cc @mdehoog
0 reply
0 recast
1 reaction
