AllWalletDevs #20

Transcript

cool uh welcome everybody to April's all wallet devs um unfortunately Dan couldn't make it today to talk about the web 3 permission standard um but hopefully he'll be back uh next month to give us an update on that um we have Tyler atot engineer to talk about plume signatures and wallets and then uh I'm assuming there's going to be some discussion about 3074 so I'm throwing that on the end of the agenda um if you're ready Tyler I'll hand it over to you and uh you can talk to us about plume signatures all right um so I you should be joining us soon but I do have his slides um and I can start just kind of

going over what plume is um let me figure out how to screen share here [Music] there we go it's working cool cool all right so um essentially plume is uh aush gupta's Master's thesis uh at MIT and he um basically was trying to tackle the problem of being able to do things like zero knowledge airdrops and being able to post on uh boards anonymously but still carry some kind of reputation um so essentially uh this is determined

istic signatures using ecdsa so right now when you generate some signature using ecdsa it's non-deterministic so like every time you you know sign a message it the actual signature is different and um what plume allows is um you to have some consistency um so with that yeah unique deterministic and you can verify without Secret so um yeah so you can you can use this to basically you know claim an airdrop on a different wallet and to be able to only claim it once so right now the only way to do that is by generating

a proof that takes um you know quite quite a long time to generate client side uh all right I us this here A do you want to present yeah yeah I canar from there that was a was a good um to keep the slides up cool um cool yeah and so I think the big thing here is that you can get like the last property being non- interactive so it's kind of like if you have like you're trying to do ZK voting with semor or like a TR cach style system um the problem is then your like an anonymity set is only people who have signed up versus here you can say oh my anonymity set is like all ethereum wallets and none of them have to opt in um you can just make the anonymity set as large as you want um stateless redeem

only want signatures um yeah it's kind of like that in the sense that each uh public key can only sign a certain message once and there's no way for them to fake another signature versus with something like deterministic ecdsa a user could just go in change a random seed and you would never know okay so does that mean like okay so the same message do you have like a a seed or something that you can pass in to change it if you want or is it okay that's really cool yeah that's sick an argument yep so pretty cool so I guess one thing to and the specific construction is if you want to go to the next slide um there's like a bunch of ideas oh no up there six yeah um okay so determ we already mentioned like if you want to verify it was actually done

deterministically you have to pass in the secret key to verify the randomness was done correctly so that that wouldn't work because since for a ledure you can't even like export the secret key um you can try something like imagine your signature with like hash of message comma public key um the problem with that being like your your signature is that it I mean it doesn't really satisfy the property of the signature one and two like the main issue is that if you like this is supposed to be anonymous right you're not supposed to know who did it but what I could do is I could just iterate through all 400 million public keys that have ever like sent a transaction on ethereum and then I could just Brute Force who this was um okay so how should message come a secret key

what if this was your signature the problem with this is that then you would need like Oracle access to the secret key to be able to verify this within a ZK proof and so again you have to export the secret key to a ZK proofing library and Hardware wallets aren't able to run ZK proof so you can't like do it within the Enclave on the hardware wallet so that's work and the last one that this actually uses is Hash of message Comm public key to the power of secret key so you have some information about the secret key so you need that to be able to reverse engineer who it is but you can actually verify this without the secret key with this like weird trick um so yeah if you go to the next slide eight I think um yeah so basically like the high level

idea you want some deterministic function of the user secret key that can be verified only their public key that keeps them Anonymous within the chosen anity set you can solve this by deploying a new kind of deterministic signature on existing ethereum public private key pairs um and so if you go to the next slide we have a bunch of like math to explain why this hash of message come up public key to the power secret key can be verified without the secret key and the main like trick here is that you have the like G to the power of secret key aka the public key and so if you can prove the discret log of the public key is the same as the discret log of this nullfier then you can prove that you fact like signed this message

um and so the kind of trick here is because we have like the public key available to us within the ZK proof we can actually verify this without the secret key um which is pretty dope the one interesting thing here is that um you'll notice there's like this R term kind of floating around the randomness is not part of the outputed nullifier signature but the randomness is used to generate a new set of like um verifying values each time you could say idea is if somebody can generate these values such that that discrete log proof checks out then they must like this must have been a real nullifier from that public key and you can do this all with than a ZK proof um random just needs to be generated randomly inside like that Enclave um sweet and then there's like some cool stuff with like Quantum

resistance if you go to the next one um where it's kind of like something like semaphor has like a hash in it and so the idea is that any like any deterministic signature it's very difficult to make it quantum proof because um specifically if somebody had the secret key of some ethereum account then they would be able to like reverse engineer what this value was and so actually like one cool way to do plumes you can do plumes directly on the seed phrase um or like a different hash of the seed phrase um and that's interesting because then you can basically say oh like you can prove all the way down to the seed phrase and then prove all the way back up giving it quantum secrecy as well um so there's like some weird modifications you can make to make this Quantum proof that's

like not that hard to make um and then next slide um yeah just some more stuff with Quantum proofness and why you would have to make that change to make it quantum proof and then maybe next one um yeah again more Quantum stuff and then the last slide is just like links to all the different like explanation so we have um like a paper that proves like all the uniqueness all the like signature properties a blog post like blog. a.com plume that explains this more in detail um and then we have we had like a metam mass snap but metam snap disabl signature access so um theoretically they're improving this

sometime I'm not quite sure the status on that but it's not possible to do a snap anymore so it's snap like it's broken um the we had a PR to metamask core but it's seemed like for some reason mamas was not interested in in incorporating it which was odd so if anybody has any ideas for metamask core let us know that's like just an outstanding PR um yeah we have a bunch of PRS to all these wallets we have PR to Tahoe wallet Ravi wallet um there's PRS to two more wallets actually um we have one for Ledger um so that like compiles and run you need to put it in the official Ledger store um yeah metas is here cool yeah we should chat about that um and then we are thinking of also putting it into Phantom and other wallets why is this

not broken um basically there's this thing called coin type 60 which is BAS allows you to access a user's like ethereum public private key pair and that is just just got blocked in snap one day and this sort of makes sense because then snaps can no longer access your private key but it also means that you can't generate new signature algorithms existing key Pairs and so there's like some workarounds here which is like um if you allow allowed two apis to the secret key so for instance you could output um like this nullifier function so like you could say oh if a user passes in a message you could take the hash of it and exponentiate to the secret key and then output that will keep the secret key private but then still allow you to like make enough

query accesses to make plume and then you could also do a thing like blind output of secret key so you output like R plus like secret key times some like I don't know like random like I don't know like uh we call it C so like you can make the API U so that a user can query this with some C and then you output this like R plus SK time c um metamask Improvement proposal cool yeah we can um work together to it would be cool if maybe like make a chat or something and I could send like a metamask Improvement proposal draft something we could jam on that and then post it that would be cool um we had a chat with some metamask folks um if you guys wanted to be added

to that that if you put your Telegram in the chat we can like make that happen um and then the last thing is we had an ERC open ERC 7524 and that one um I think Sam actually left a bunch of comments on it we addressed all of them and now we're just waiting for that one to be merged um if you command if ERC in this uh read me you should see it um um yeah this one yeah maybe the official ERC or something something yeah that's just waiting on me to get back to it sorry oh no you're good um uh sorry yeah the link might be broken if you just uh you use Google plume ERC okay just Google plume

ERC or like ERC 7524 um yeah yeah exactly it's this one um yeah so this one like I mean Sam I discuss is in thread but like Auto closes but at the top of that thread it links to the new like sl242 I think is a yeah this one or at the bottom of the thread um yeah move to 242 so I just reposted it with all Sam's comments here but yeah if there's anything we can do to get this like merged faster I don't know if you have like another round of uh comments or anything you want to do um uh just remind so 242 yeah I'll try to take a look at that um 2 42 it's just

um like I generally review an order and since it got close and reopened it got pushed further down um so sorry about that I'll make sure to get to it as soon as I can no that's good yeah I mean yeah I'm also down to reopen 37 and we can just close this one and then put it back there and that way it can be um in the correct place in the priority queue but yeah yeah especially no I'll just take a look at this one like after this call not a problem um no that's really exciting so so what kind of use cases does this enable like um where do you see people using this most yeah there's a couple of things one is like stealth drop so basically we did this like Anonymous air drop thing with like um like normal ecdsa key but the

problem with that again is that anybody can claim any number of times and I think a6z did one with semaphore but the problem with that is that then all users need to opt in before you start and so when some protocol tried to actually do a ZK air drop they had this problem with like basically users had to like all sign up for the air drop in phase one and then they did the air drop in like phase two and this meant that the anonity set was only the people who like signed up in phase one it was like there was like a big mess so um yeah I think one thing is like ZK air drops like especially for like ZK protocols if they want to do that I think that's like particularly nice um that's the first one the second one is like Message Board

stuff so you kind of need this a lot for Message Board moderation so let's say you want like Anonymous Message Board where someone proves oh I own this nft and so now I'm gonna enter this message board I'm like now I was experimenting with this some other folks are experimenting with this the problem is you can't ban people right like if somebody is like I don't know being abusive something there's no way to say oh like I'm going to ban you they just come back with a new ecsa key but if people sign up with their plume then you can say oh we're going to ban this person from posting in this thread for instance because maybe the plume message is like that thread ID and so now that user you can anonymously ban users which is like kind of cool um for like whatever so they they'd be able to prove

that they own an nft and you'd be able to say they can only generate one proof so when you ban that proof they can no longer access it that's sick yeah exactly so it's it's pretty cool you don't know which you're Banning you're Banning the person who said that like bad thing or whatever um yeah so it's like it's kind of this very nice like this way to add like unique anonymity to any like ethereum key um cool I I don't want how questions oh go ahead go ahead no no go ahead I have more questions so you go ahead yeah um yeah I was gonna say the last interesting I mean there's a bunch of other use Cas but the last interesting use case is like you need this proof of solvency a bunch of people were trying to say oh like exchanges can come in

proove they have some assets and some wallets the problem is two exchanges could just say they have the same wallet they could say oh like we're going to collude and like all of our stuff isn't liquid but if we share this wallet and we both make a proof of it then we could technically approve proof of solvency um anonymously and and share the same wallet so you wouldn't actually have the fund that you claim you have but if you have to publish a plume proof for every like wallet you're proving you have access to then like exchanges can't share the same wallets and so you end up like Anonymous proof of solvency would actually then be possible um and it's not currently possible that's great um does anybody else have any questions otherwise I have two more okay so um how secure is

this yeah um how secure is this um so we have the paper if you go to like i.com thesis we wrote basically like a cryptographic paper where we prove all the like Oracle security of each thing we had the core Library audited once um and we'll probably do a second audit before we release like on mainnet for people just so that people have more confidence that like what is reflected in the repository is actually reflected in the like paper um there's also I guess um Mina and Aztec both had it implementations of it I think Mina's they use Poseidon instead of um sh 86 but that's still fine that just

makes the proof a little bit faster um yeah it's it's pretty secure I mean there if there's any like reservation people have for the um implementations we have docs also for everything people can go into the mpm repo and look at like the different services that are exposed um but yeah I don't I think as long as the audit confirms that the implementation corresponds to like the properties and the paper then everything should be secure if people want to like make sure yeah this one if want to make sure things are it's also on ePrint iicr um there's like a a preprint there if people want to look at it um but basically if people want to like um verify the security I'm happy to do like I don't know coordinate on like a specific audit for the implementation a

specific wallet as well or something um but as long as you correspond to the API that we expose it should be Totally Secure great I think that answers my question and the last one is we have a bunch of wallet developers here um what would you like to ask them for what uh if you can get them to do something what is you want them to do yeah so the two things for wallet developers I guess metamask has already we already talked about it figure out either make those two um apis public in snaps like the things that give you like query access on parts of the secret key but on secret key directly or help us integrate it into core we have this PRD core that's just been open for a while um we don't want to allow arbitrary signing why can't another coin type work so the

problem is you want to often make so coin type 60 allows you to prove you have some ethereum key with some properties and so you could say for instance hey my ethereum key that own this nft is also going to generate this plume signature and this allows you to link this like unique anity to existing properties that your ethereum key has done some action in the past um and so the problem is if you don't use coin type 60 then You' have to make the proof on like some other non- ethereum key and then that's kind of useless because then you lose all the like properties of your ethereum ke you want to make the proof about we ask good question why do we need coin type 60 um does that kind of make sense hopefully um yeah and I guess

metamask um helping us like basically just like pass the pr so like if you are running I don't know like coinbase wallet or whatever like we can make a PR into the wallet and we can say hey like you know this as plume signatures to wallets and then just helping us like figure out who are the right people to talk to to merge this in or if you guys a worded about security to do a second security audit before we merge it in or whatever it is um that would be super helpful also letting us know if you're not one of the walls we've already made a PR to like if you want this property in it and then we can put you guys in and that'll help also I think it'll help like Advance the wallet to like be other ZK apps like if people want to do ZK air

drops or interact with ZK man board this kind of primitive will be critical for those wallets yep those are all the actionables awesome thank you so much um if you've been doing implementations for wallets you should come take a look at wallet test framework um we'd love to have a test for plume in there if you want to play around with it um but yeah thanks for presenting that's that's awesome that's a great presentation yeah I'm glad people liked it um yeah feel free to drop the link to that test thing in the chat and I can go check it out uh yeah

so uh I think that's pretty much it for scheduled stuff um I'll open up the floor to um 3074 discussion since that's been pretty hot lately if anybody has any questions things they want to talk about um yeah thanks for thanks for presenting um yeah uh anybody want to chat about 3074 I guess okay let we start with a more specific question then um out of the wallets that are represented here I think there's metamask coinbase um I don't know if if there's anybody else um will you be supporting 3074 um day one or are you going to be

building support later uh what are your plans with that let's start with metamask can you hear y we can hear you now okay sorry um yeah so uh I believe we are currently um sketching out um I'm not directly involved with this um

but just the just to recap the question is are we are we planning to to support 3074 off the out of the the gate like migrate users help uh allow them to make some kind of signature uh for 3074 yeah yeah so um as I said I'm not directly queued into these questions but um but the yes the plan for sure is is to do so and it's we're we're kind of like sketching around migration paths to to allow users to do so and and sort of then transition the wall at ux accordingly okay cool it's good to hear um what about coinbase do you know what

your plans are for 3074 uh nothing concrete yet I can't really speak through the team um I know that we're interested in using 3074 as a migration path for our e EA users to mod wallet users um and I think we're also like aware of kind of the security risk of 37 for and probably will build some like scanning to uh prevent any loss of funds uh and and kind of like the our transaction simulation um that's that's kind of like the extent of what we've kind of like

spit balled so far but I'm sure as it becomes more real we'll have a more concrete plan great yeah I just want to make sure everybody's thinking about it early so um yeah thanks um that's it I think for schedule discussion oh uh test Net's up uh not yet um we are um planning on setting one up I think reth is working on one um that'll probably be the the soonest um but yeah nothing official yet and uh so you're planning on removing e sign that's awesome because that's a terrifying function um yeah great thanks guys great yeah then we can call it early and

uh thanks everybody for coming out that was a great presentation and we'll uh see you all next month