Content pfp
Content
@
0 reply
0 recast
0 reaction

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
61 recasts
219 reactions

Kames pfp
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

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

Kames pfp
Kames
@kames
Interesting. Gas costs aside though, this method would require a lot of compute just in terms of proofs? Perhaps with transaction costs being substantially less than the proofs themselves or is there some magic sauce in the works to bring that down?
1 reply
0 recast
0 reaction

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