Michael de Hoog pfp

Michael de Hoog

@mdehoog

9 Following
413 Followers
Michael de Hoog pfp
Michael de Hoog
@mdehoog
We have an implementation of the minimal keystore rollup working internally, current timeline is a public testnet in Q2 and mainnet in Q3 after audits.
2 replies
0 recast
3 reactions
Michael de Hoog pfp
Michael de Hoog
@mdehoog
I followed the same steps as the loom video: simply replay the safe creation tx on the other chain. Safe has done a good job of deploying their factory + proxy contracts at the same address on many chains, even if their Github points to another address.
2 replies
0 recast
1 reaction
Michael de Hoog pfp
Michael de Hoog
@mdehoog
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.
1 reply
0 recast
3 reactions
Michael de Hoog pfp
Michael de Hoog
@mdehoog
The exclusion / inclusion proofs are quite cheap to generate, as they are just a merkle proof with 65 poseidon hashes (<1s on my laptop).
0 reply
0 recast
1 reaction
Michael de Hoog pfp
Michael de Hoog
@mdehoog
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.
1 reply
0 recast
1 reaction
Michael de Hoog pfp
Michael de Hoog
@mdehoog
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.
0 reply
0 recast
2 reactions
Michael de Hoog pfp
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 pfp
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 pfp
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
Michael de Hoog pfp
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 pfp
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
78 reactions
Michael de Hoog pfp
Michael de Hoog
@mdehoog
would love feedback on this proposal
0 reply
0 recast
1 reaction
Michael de Hoog pfp
Michael de Hoog
@mdehoog
16GB will work for both, though it depends on usage. Heavy debug / trace usage or large range logs reqs will require more than simple block requests. The min for L1 geth is 4GB: https://github.com/ethereum/go-ethereum#hardware-requirements
0 reply
0 recast
0 reaction
Michael de Hoog pfp
Michael de Hoog
@mdehoog
Yes that's correct, same as the L1 👍
1 reply
0 recast
0 reaction