Episode 316 - Alin Tomescu on Distributed On-Chain Randomness and Keyless Accounts

Transcript

[Music] welcome to zero knowledge I'm your host Anna Rose in this podcast we will be exploring the latest in zero knowledge research and the decentralized web as well as new paradigms that promise to change the way we interact and transact online this week NCO and I chat with alen tesu head of cryptography and part of the founding team at Aptos in this episode we cover what led him to join Aptos his work on distributed onchain Randomness as well as the Aptos keyless accounts a construction which is similar

to ZK email and ZK login which we've covered previously on the show in this conversation we dig into the architecture and discuss some of the choices that Aptos took as they built out their system now before we kick off I wanted to highlight the ZK jobs board for you there you will find jobs from Top teams working in ZK so if you're looking for your next opportunity be sure to check it out and if you're a team looking to find great talent be sure to add your job to the jobs board today I've added the link in the show notes we also have our upcoming ZK Summit 11 event to look out for it's happening in Athens on April 10th the event is shaping up we have been adding speakers to the website and we'll share the schedule very soon as always this is invite only and space is limited there

is an application process to attend and you need to apply to be eligible for a ticket if you've already received an invite to buy your ticket be sure to grab it we expect the event to sell out I've added the link to apply in the show notes hope to see you there now Tanya will share a little bit about this week's sponsor launching soon namada is a proof of stake L1 blockchain focused on multi-chain asset agnostic privacy via a unified set namada is natively interoperable with fast finality chains via IBC and with ethereum using a trust minimized Bridge any compatible assets from these ecosystems whether fungible or non-fungible can join nada's unified shielded set effectively erasing the fragmentation of privacy sets that has

limited multi-chain privacy guarantees in the past by remaining within the shielded set users can utilize shielded actions to engage privately with applications on various chains including ethereum osmosis and Celestia that are not natively private nada's unique incentivization is embodied in a shielded set rewards these rewards function as a bootstrapping tool rewarded multi-chain users who enhance the overall privacy of namada participants follow namada on Twitter @ namada for more information and join the community on Discord discord.gg NADA and now here's our episode today Nico and I are here with alen tesu head of cryptography at Aptos and part of the founding team hi alen

welcome back to the show thank you Anna thank you Nico thanks a lot for having me really good to be back nice hi Nico Hello both happy to be here so alen last time you were on the show you were actually working at VMware and you came on we talked about like stateless validation scaling blockchains new Merkel tree designs the challenge of sinking sharded system there's like all this terminology for today's episode I feel like we're taking a pretty far leap but can you tell us what has happened with you since we talked about all of that research and is is there anything from that time that you've carried forward yeah sure um first of all thanks a lot for having me

it's really great to be back um so we spoke in I believe April 2020 or something of that sort uh and at the time I was doing a lot of work on authenticated data structures Vector commitments and I was very interested in stateless validation at that time particularly because it leveraged these authenticated data structures since then I've uh spent two years at VM research doing academic uh paper writing and research projects with other people and my work has focused on a mix of authenticated data structures and threshold cryptography and uh towards the end of my VMware year I worked on a sensibly Anonymous payment scheme that

balances uh accountability or or compliance with privacy and being at VMO research was amazing for me uh I really loved my time there and my co-workers but I wanted to have a little bit more skin in the game let's say uh with the work I do so I found it incredibly exciting to work on cryptography that sees the light of day and you know a lot of is at stake when you deploy that cryptography it sort of forces you to rethink your approach to the work that you do and so I had this opportunity to join apos Labs very early on as part of the founding team and I really couldn't help myself and I did so that was in in February 2022 okay uh and I should

actually say like uh I've had a lot of opportunities to join cryptocurrencies since my years as a grad student and never have I ever been so compelled to join the team as as appos Labs interesting our team is really fantastic um and I'm I'm very very proud and and I'm having a lot of fun to be there was that the differentiator for you like the the team for me yeah yeah absolutely absolutely yeah the and and sort of the technology stack that we were building upon that was a huge huge motivator for me yeah I had wondered if you had maybe done a detour through Facebook meta on your way because I know Aptos and misten these are both projects that spun out of the meta cryptography team right but in your case you were just coming straight

from VMware I guess yeah I was coming straight from VMware yes that that's exactly right and a lot of people ask me if I had spent time at Novi and Facebook and nope never been there okay what was it about sort of aptose the stack that was unique or is unique in your mind uh at this moment or or when I joined well actually just generally because like there ISU at least with this show we've covered Su a little deeper we've had a few more guests we know that like Sam costess like we kind of know their history like is apto significantly different from s and if so like what's kind of unique and interesting about it so there's differences first at the consensus protocol level so we are

building up on the jolon consensus protocol which sort of is an iteration on pbft and hot stuff okay and on top of Jolan we are now deploying dag based protocols like SCH which iterates over bullshark um at the language level both sui and apos move but the subset of move is starting to sort of fork a little bit interesting and so for example Aptos supports scripts which we think are much more powerful than than ptbs uh which are supported in suie move then let's see what else is worth emphasizing in terms of cryptography on chain we have a very nice summary of all of our

cryptographic features on on our apt. deev website so for example we have native support for arbitrary elliptic curve arithmetic and move so you can pick any supported curve right now we support BLS 12381 and B and 254 and you can do arbitrary arithmetic you can do additions multiplications pairings multi pairings multi- exponentiations and this is really powerful because we can write things like gr 16 zero knowledge proof thiers in move with a generic parameter that is the curve type right um and we're also getting contributors externally that are adding new curves so we recently had an

external contributor that added BN 254 as a new curve so we're very excited about empowering developers to build on top of move uh really powerful cryptographic D apps another differentiator between Aptos and sui that we're working on recently and we'll talk about later is this distributed Randomness effort so we have something that we call instant onchain Randomness and the idea behind this feature is to give smart contracts immediate access to unbias unpredictable Randomness um and improve the developer experience of smart contract writers who want to write things like games uh lotteries Raffles um randomized nfts or

even interactive zero knowledge proof verifiers and once again the the whole philosophy there of apos is to improve the user experience and improve the developer experience and bring web3 to the next billion users I wonder would you say that there is a f focus on ZK on the research team at aptose it depends what you mean by ZK so typically if you're doing cryptography one way or another you're going to use a zero knowledge proof I mean even if you look at a signature scheme it can be regarded as a zero knowledge proof of knowledge of the secret key right made non- interactive by using a message in the challenge which yields a signature so one way or another you're using zero knowledge proofs whether you like it or not in your cryptocurrencies at opos we

have found zero knowledge proofs useful for many things so the first thing that we started looking at was adding some privacy to our coin transfers one one thing that can be done there is this traditional technique called confidential transfers which employs A Primitive called the zero knowledge range proof which argues that a committed number is within a certain range like 0 to 4 billion I'm not going to explain how that need for a zerge range proof arises I'll just say that it arises even in things like U confidential transfers another area where zero L proof might arise would be for example in distributed Randomness if you employ protocols such as publicly verifiable secret sharing it turns out that even there you might

benefit from a zero knowledge range proof in particular if you want to to deal to secret share a field element you have to employ an additively homomorphic encryption scheme to encrypt that the shares of that field element and the most efficient schemes we know actually employ elgamal encryption with a zero knowledge range proof that's another use case of zero knowledge proofs then lastly for account management you might find Zer knowledge very useful so we're doing a line of work that we're calling apos keyless accounts which leverages the open ID connect standard and zero knowledge proofs to add privacy and once again we'll touch up upon this later in the podcast but those are three examples where zero knowledge proofs arise and of

course there's more as you know from talking to your guests there's a lot of Hope in Zer knowledge proofs being useful for scaling blockchains via rollup techniques interesting is there work on your team on that kind of ZK like on the scaling type as well because so far I think you've mentioned Randomness you've mentioned privacy but I'm just wondering if like do you expect rollups to exist on Aptos or do you have other ways of thinking about like ZK on aptose things like co-processors stuff like that so we're thinking about it one big fundamental challenge I see with scaling blockchains via rollups is the Laten aspect of computing an expensive zero knowledge proof uh and for us latency is very important and this comes back to

the story I was telling earlier about user experience if I have to wait 30 seconds for my transaction to be final that's not good for my users we really believe in this so in that sense we have not looked very deeply at using rollups to scale because we don't see how to solve this latency problem immediately now I'm very excited for the research that's being done in the ziz space on people really doing amazing math and amazing engineering to lower the latency of the system so there was a recent announcement I think by polygon where they I think got around 30C latency for a block of ethereum transactions which is very very impressive is this the circle Starks stuff that they did with starkware possibly or are you thinking

was this the meren 31 or was this the planky 3 I think it's based on planky 2 or three but I don't think the Tweet said do you know Nico I think these were yeah engineering efforts based on plunky 2 or similar Primitives all the newer stuff like meren 31 and the CER stock construction that comes from it is not yet sort of at that level of implementation yeah and you you've had Brandon Farmer on and and they've done amazing work on really speeding up the prover in planky 2 and the subsequent work so that's really exciting and I hope to the extent that people figure out how to paralyze the prover M there might be a chance in making UPS uh actually practical for scaling

blockchains and lowering the latency and the alternative is to just not care about latency and use economic mechanisms to deal with with high latency but uh I think that complicates the stack and I think that complicates the user experience and I just don't think that'll be practical in in the long term when you know you want to buy a coffee or a motorcycle and you have to wait you know maybe for a motorcycle it's fine for a coffee not so much right uh sense and getting back to the original question was if if we're looking at rollups to scale appos because of the scalability issue I guess uh we're not putting a lot of effort in it but once we see that there's sort of a really exciting development I think we'll we might give it more attention got it yeah well I'm very eager to get

started with all these cool constructions that you've been talking about so onchain Randomness probably being the first one yeah so he said we provide smart contracts with Randomness that they can access during their execution is that correct mhm amazing how how does that work uh How Deeply do you want to get into it um I don't know should we start with a first like a high level description and uh slowly work our way down yeah so that's that's a great idea so let's start with the high level so we actually have an apos improvement proposal AIP 41 that describes to move apis used to give contracts unbias unpredictable randomness and these apis

are very simple it's literally a function called get random integer for example a contract calls it and it gets a random integer instantly it doesn't have to wait for the next block it doesn't have to wait for 8 minutes it doesn't have to commit ahead of the time to a future Randomness that will be generated just gets gets it instantly and the question is how is that possible and the way we do it is we make sure that every appos block has a Randomness seed and from that randomness a seed we can derive individual Randomness for these contract calls that's sort of the again high level how do we put that Randomness SE in there and how do we make it unbias and unpredictable at a high level we're using a PVSS based

publicly verifiable secret sharing based distributed key generation protocol and a verifiable unpredictable function or a vuf and I'm happy to go into the details and the challenges of making that work because it's not very easy to make dkg practical in the proof of stake setting that we have at apos Network and it's not very easy also to make VFS or weighted VFS practical in that setting so for us that was a very nice Challenge and and we wrote an academic paper about our solution and it was sort of like very in line with our philosophy at apos Labs as research group we want to work on really hard problems for actual

deployed systems solve them and then publish a paper about it so these two components the the dkg I think probably listeners are going to be more familiar with so right we spread a key amongst a a committee yeah this VF thing that you're talking about yeah what does it provide and is it anything similar to a vdf which we are more familiar with yeah it's not at all similar uh I will I will expand on it so but but actually even before I go into the vuf even the dkg is a little bit challenging and the the reason it's challenging is is because we have a committee-based consensus protocol that proceeds in Epo of 2 hours so every 2 hours the validator set might change and

whenever a new Epoch begins with the new validator set you want the dkg protocol to be finished basically so that the new new epox committee has the shared secret and they can compute the VF which allows them to put the block seat in the block the randomness seat in the block so how do you get that to work it turns out if you want to have the new Committee in the new uh Epoch have the shared secret you kind of have to start dealing it in the previous epok so what's happening is the old committee is starting a dkg and dealing to the new committee right and to to make that work you have to use a publicly verifiable secret sharing algorithm because the new committee might not even be online so you need to

encrypt the shares of the secret for the new committee using publicly verifiable secret sharing and actually getting the public verifiable secret sharing to be efficient enough to work at this scale is tricky so we actually started by looking at a line of work that Kobe and I did back in 20 and 21 on scaling the scrape PVSS protocol and that had some uh performance issues at the scale that we have at eptos because we have to deal transcripts of around a th000 shares which is pretty pretty large the verification of such transcripts would have taken seconds and it it was a little bit too much work for the validators to do so we came up with a new PVSS protocol and that allowed us to

get good performance so once you have a PVSS protocol you get a dkg once you have a dkg the validators have a shared secret every new Epoch and now they're ready to evaluate this verifiable unpredictable function or vuf which is completely different than a vdf verifiable delay function yeah it's just weird like so when when I've heard about Randomness and like we've done episodes back in the day on randomness vdfs were the way that people were achieving it so yeah are VFS like completely standard and I just like missed that story or is it sort of unique to this project they're very standard in fact the BLS the BLS signature scheme which I'm sure Anna you've talked about a lot in this

podcast oh yeah it is actually a VF scheme also so any any deterministic signature scheme or I should say any unique signature scheme that only has one Val signature for a message is a VF okay um this is a known result but I think you're asking a very interesting question which is most projects have looked at using vdfs for Randomness so why haven't we done that and I'm not saying it's impossible to use vdfs in our settings I'm just I we couldn't do it in a way that lowers the latency because with vdfs fundamentally you have this problem that you're Computing a delay function over a long period of time right and that means you you can't have the randomness until this delay

yeah goes by but we need Randomness very fast and we don't want to tie the latency of our protocol to the delay in the vdf at all that makes sense like what you said too it sounds like it's all about timing like you're trying to time it for the correct round so if you added on this like some sort of delay function I can imagine it wouldn't work yeah not if done naively at least I really am very curious if there's a way to use a vdf in such a way that the delay can be decoupled from the latency of the consensus protocol and there's some line of work on something called continuous vdfs that kind of makes me wonder if um there might be some ideas to explore there and I urge the research Community to think about that problem because vdfs are in a way much better

than VFS for Randomness they have Better Properties but it's just unclear how to make them work in these low latency protocols that want to proceed as fast as the network and once again we care about latency latency means good user experience so I was going to say say it's also unclear just how to make them work at all um and this is a debate I I have with Kobe very often um he just says vdfs aren't real like we can't to make them I didn't know that that's funny uh he doesn't buy for example the uh uh the RSA assumptions that they're predicated on or even the snark based vdf assumptions the sort of snark based ones says aren't real can't Implement them and people will come up with faster

Hardware it's reallying on this assumption that this hardware and this scheme that we've put out is the best you can ever do to compute this function and this snark right and um he sort of argues that it's not a feasible assumption even for things like RSA oh that I'm not sure that would be an interesting uh discussion to have with him yeah but back to the VF thing why are we calling them verifiable unpredictable functions and not verifiable random functions if that's what we want them to be ah uh that's a great point it's actually we do use a verifiable random function it's just that once you have a vuf getting a vrf is Trivial right all you do is you hash the vuf output and that gives you a vrf output so I just like to focus on the

vuf as the key primitive but yes it's a vrf is it just by creating this hash output that it becomes unpredictable like how does that work yeah so so why is a verifiable unpredictable function called unpredictable and how does hashing the the output to achieve a verifiable random function so for the first part the unpredictability in a VF is really the same thing as the unforgeability in a signature scheme so in a signature scheme if I give you a message you cannot come up with the signature on that message unless someone has signed it before and you have a previous signature right that that's what it means to be unforgeable VF unpredictability is exactly the same it's basically you cannot come up with a VF on a new message unless you've seen

it before so it's just a synonym um as cryptographers we like to rename things yes right and the verifiable random function part is kind of a subtle cryptographic thing so in the signature or VF output you might actually be able to predict some bits for example you might be able to predict the most significant bit in a signature I don't know maybe it's always one so it's technically not random so if you actually want to get Randomness you have to apply a random Oracle and that's what gives you a verifiable random function it's kind of boring subtle detail yeah the joys of cryptography yeah I want to understand where this is used in aptose like is this your

validator selection random function like once you create this Randomness what do you do with it so so like I mentioned earlier what we are using this for is to give smart contracts access to Randomness so they could enable a new class of applications that we call randomized the apps or Rand apps and that's it uh it's possible that we might use it to uh select a subcommittee in the future to sort of get an asynchronous consensus protocol rather than a partially synchronous consensus protocol we have not looked at that yet but there's many things you can do with this once you have it the main application though is smart contracts and why once again developer experience I think is very important it's really

difficult to write randomized D apps right now with with sources of external Randomness I've tried it it's kind of Tri tricky we believe in good developer experience we think that's going to empower cool applications and bring billions of users to web 3 something that really caught my attention earlier is you said as part of these randomized daps you could have an interactive verifier as a smart contract yeah so we haven't explored this in depth but in principle you know right now all Zer knowledge proofs on chain are non-interactive zero knowledge proofs right mhm but technically the chain if you have onchain instant Randomness the chain can be an interactive zkp verifier where it generate some public Randomness and verify the zkp of course that's for

public coin zkps not for private coin zkps right this is kind of interesting because I think for some zkps and for some cryptographic protocols when you interaction is much more powerful than arithmetic this is something that I think Rafael OSI once told me in 2017 when I when I met him and we were talking about some problem and uh I didn't really understand what he land at the time but but now I do right so if you've done cryptography and youve tried to use a lot of arithmetic tricks you know you can get your test done but interaction is so much more powerful and as a result sometimes interaction can let you get really much more efficient protocols so it's kind of interesting to to to think about what you could do with interactive zkp verifiers on chain it's very interesting especially an example

that listeners might be familiar with when we talk about the security of starks for example we have to consider this non-interactive version of it and we have to consider another adversary that grinds and keeps trying keeps trying keeps trying in the interactive case you can't keep trying forever cuz the verifier is going to reject you right if you try too many times I'm going to say no I don't want to cure from you anymore yeah so that means we could have sort of an interactive star verifier that maybe works with much looser parameters but still gets high security that's really cool looking forward to to see where this goes oh my God you should build that yeah please build that and move so I think we just covered the onchain Randomness feature but like what other kind of ZK or yeah cryptography is

coming out of this lab yeah so this is probably the most exciting thing uh for me right now uh it's a feature that we're calling apos keyless accounts so when we started appos a big problem for us was and really for any cryptocurrency in the space uh onboarding new users onto web 3 these users have to download a wallet write down a neonic remember it understand how important it is and if eventually they lose it they lose all of their assets and they never engage with the space okay so the user experience in in web 3 life cycle is very depressing so once again coming back to apos our goal is to improve the ux and

bring the next billion users into web 3 so we have to solve this problem if we want to do that so in sort of 2023 we were thinking a lot about solving this problem with NPC protocols that manage the key for the users but when you think about that you kind of immediately realize that you're not really solving the problem because your users still have to authenticate themselves to the MPC system so they still need some credential to prove they are the user uh so that the NPC system gives them the secret key right so when we looked at NPC companies around a lot of a lot of them were using open ID connect to let users prove their identity to the MPC system using a Google account for examp

and initially it didn't click for us but after about a month or two it was pretty obvious that if the NBC system can verify this open ID connect credential then so can the blockchain and you don't actually need the NPC system uh and you know as as with all ideas when when you first have them you wonder like why the hell are people doing this stuff like you can just verify the stuff on chain it's completely unnecessary so when we realized this we started thinking about the problem and we came up with this idea of let's let's use open ID connect signatures on chain as a way to prove that you are the user that you claim to be so basically now your blockchain account can be for example your Google account you don't have a secret key you

don't have a pneumonic there's nothing you can lose unless you lose your Google account you won't lose your blockchain account MH so that's that's that's the Approach at a really high level that's what we're trying to do now the challenges around that is our privacy and I can talk about that more but so far does that make sense for me this sounds a lot like ZK login ZK email TLS notary maybe a little bit like there's a bunch of projects coming out where they're dealing with email addresses connecting it to an onchain identity yeah is this in the same category is it using similar techniques it's in the same category of basing the security of a blockchain account on the security of

oidc account so so in AIP 61 uh we describe this approach technically and we reference a lot of previous work on this idea of using jwt's from open ID connect to bootstrap blockchain accounts and yeah you you can take a look at all of the prior right there and it's kind of yeah if you've done research you kind of observe over time that what tends to happen in research is there's the world with with its current state in terms of ideas and typically people often come up with the same idea around the same time like if Nico you must know this for example having written papers and gotten scooped and stuff like that that that usually uh yeah an idea kind of tends to

arise in a lot of people's minds around the same time and I think for this idea probably it's been around for 2 three years it's quite surprising that it hasn't been around for 10 years because we could have done this 10 years ago on ethereum for example without any zero knowledge proofs because you don't really need zero knowledge proofs to make this approach work you only need zero knowledge proofs if you care about privacy does that make sense well I guess there are there is one question which is you know not your key not your coins right yeah like does this apply here of course I mean absolutely but that's one way to think about it uh if you are an expert user and you want to manage a secret key please go ahead but

uh you are not the target user for this product if you are that uh the target user is like at least the 90% of cryptocurrency users the target user is you know our parents our friends who have never written down a pneumonic before and don't ever want to do so um and for most people it's really cumbersome to to sign up for a wallet even the fact that when you use a d app you have to install a wallet is a really big uh entry barrier like when we talk to Partners or applications they tell us that no wallets are sort of unacceptable we cannot have our users go to a website uh to buy a concert ticket and have to install a wallet that's ridiculous so

another advantage of this approach is that you can actually completely avoid wallets diab can directly sign you in with your Google account and can derive a d app specific account associated with the DS identity and your email address right no more wallets and the nice thing is that that D specific account is completely isolated to the D app so that D app cannot steal other assets from other apps right M so I want to add a link in the show notes to that previous episode we actually had costess from s talk about ZK login and aush from ZK email talk about his system and those two kind of we knew those had emerged at the same moment they talked about kind of the similarities which there were a lot of

and a few differences the reason I wanted to sort of link to that is I know that goes into the general architecture I have a question left over from that that I kind of want to ask you which is like what I understood this says is it would almost like create a new account on chain but what I don't get is like if you use this subsequently how does it always connect to the same account on chain like I I get the idea that it's like in a short second there's that connection made but yeah this is still like this question mark for me on how you keep that connection so are you essentially asking you know when you sign in with Google into a d app or into your wallet and you get access to the account for the first time and then you

log out and then you sign in back again how do you get access to the same account yeah because it all had to do with like salt and this and the salt yeah forget the salt the salt is irrelevant the salt is just for privacy okay okay okay but it sounded as as you log on you're creating a new account at least that was the way it was described to me and so that's why I'm like well how do you always connect to that same one okay I I have I I can describe this as well as I I can think of and I can also share some slides that you can link into the YouTube video which describes the approach cool cool so let's forget about privacy and zero knowledge proofs and salts okay because in order to actually understand how this approach

works all you have to look at is open ID connect and the signatures from Google so how does the approach work at a really high level without privacy your blockchain address will be a hash or a commitment to your email address and the application that your account is associated with like a wallet for example or a DM that's it so your blockchain address is these two things your email address and the application ID now the question is once you have a blockchain address that is associated with your email and the application ID how do you authorize a transaction for it how does the blockchain verify that a transaction is allowed to modify that blockchain address yeah and the answer is very simple when you sign in with Google what Google does after you've

completely signed in uh successfully signed in is it gives you a signature and guess what that signature will be over one your email address which is committed in your blockchain address and two the application that you use to sign in to Google like your wallet which is also in your blockchain address and three any arbitary data that you want Google to sign which by the way can be the transaction that you want to authorize so I have a blockchain address with my email and application ID Google will gladly sign over those two things and any data I ask to right so I can put a transaction in there so now I'm basically getting Google to sign my transactions for me and the validators can very easily check that the signature

on the transaction is over the same email and application ID as in the blockchain address so I hope that's sort of clear but if not please please ask some questions I mean I don't know how the Google sign in exact like I'm assuming this is something that's outputed but like if you've signed in do you have to use your actual email account to sign like do you have to send an email being like sign this no no no Google so so you you've used the sign in with Google on websites like notion for example yeah but I always think of it like you use it once to sign in and then you never like Google disappears but am I wrong exactly that's what's happening uh there's a detail that I'm leaving out

here but that's what's happening you sign in once and Google gives you this digital signature yeah over your email address your application ID like notion or your wallet and any arbitrary data so what we do is we leverage this idea from 2022 by Ethan hailman at all where instead of signing the transaction directly we sign an ephemeral public key MH when when you sign in with Google so now your wallet asked you to sign in with Google you did so and Google gave you a signature on this fmal public key okay so if you present a signature to the blockchain on the Emeral public key then you can use the Emeral public key to sign transactions repeatedly without resigning into Google so there's a layer of indirection this is a classic idea in

computer science all computer science is just layers of indirection like this don't sign the transaction directly sign another thing which signs the transaction so you don't have to sign in a million times into Google in order to authorize a transaction okay um this is the main trick we have probably the only trick as computer scientists that we have would it be an application then like the D app is what's doing that in between like you basically give over power to the D app to do the on on your behalf kind of correct just like with the wallet you give the the power to any wallet right now even with a secret key or aonic to sign transactions for you so if the wallet is malicious it can sign bad transactions um and there are even now D apps that derive a secret key for you in the browser and then use that

secret key to sign transactions behind your back so even now users are trusting D apps to to correctly manage their dup specific account okay so so far we've talked about just sort of the General construction and thank you I think this has added Clarity into how you can log in multiple times to the same thing that they are tied to each other and how you can actually sign transactions but let's add the Privacy component yeah and the salt yes which I still don't understand what that is but anyway oh yes oh I'm going to confuse you even more so uh CU we're not calling it ass salt we're calling it a pepper of course someone had to do it it's well it's actually the right name for it so a privacy

preserving salt a salt whose purpose is to provide privacy is typically referred to as a pepper in cryptography so that's what we're calling it and if you look at past projects like cell who also have a employ the use of peppers they do the same thing uh so anyway that was kind of a a parenthesis uh to make things more confusing okay so the question was how do you add privacy to this approach so let's first identify the problem so the problem is that if the validators are to verify the signature from Google they must know your email address and the application ID because that's the message that's being signed in order to verify the signature on the message right so that that leaks to the

blockchain oh yeah who you are in terms of your email address which would be pretty bad right it's bad enough that on a blockchain you see a transaction history for all addresses now you see a transaction history for all email addresses that's kind of terrifying there's a an Associated problem too which is that Google when you ask it to sign over this ephemeral public key that I mentioned earlier now Google knows your ephemeral publicy and can track your transaction history on the blockchain too so that's not good either so we want to solve both of these problems at the same time so how do you do that of course the answer is you use a zero knowledge proof and you throw it at the problem and that's it done and we can end the conversation right here all right it was a great episode thank you

so much uh but of of course in practice it's a little bit more complicated so of course we throw a zero knowledge proof at it what does a zero knowledge proof do in a zero knowledge proof will argue that Google did sign over the message which is committed in the blockchain address so it's a zero knowledge proof of knowledge of a signature from Google on the email address and the application ID committed in the address and committed is really key here because you cannot do a commitment unless you have some Randomness and that Randomness is what people refer to as a Pepper or a salt so now this pepper and the salt is

what hides your email address and the application ID inside your blockchain address yeah so that's at a high level the most extent statement of how you use your knowledge proofs to provide privacy now there's the other side of the story too which is how do you hide the ephemeral public key from Google and the answer there once again again is to use a commitment instead of having Google signed directly over the ephemeral public key you you have Google sign a commitment to an ephemeral public key and the snark now argues that the EPK the eeral publicy is committed in the signed message by Google but in this case does your email show up somewhere but it's just disconnected from what

you're actually doing cuz I'm just picturing that line of thinking that you described before we like Google does the signature allows this you know D app to then do more signatures for you but like that first signature it's not really private is it or is it just like is it public but you don't know what it's connected to oh it's private uh it is private even okay so even the like the Google signing that thing you had said like the email address the you kind of had all these things that would go into that signature yeah so the first whenever you sign in with Google you get the signature so even the first time you create the account you will get a signature this signature you use locally and you

compute the zero knowledge proof that argues its existence you never leak the signature to the blockchain you never send it you just keep it locally and you create a zero knowledge proof arguing that you know the signature over the email address and the application ID committed in the blockchain address using the pepper and then you also argue that the signature is over the ephemeral public key committed in the message that is signed but then there's a verifier on chain I guess that's saying like yes this is correct but I still don't get how it then connects like how do you then connect it cuz all that I feel you've said is like there is a Google account doing something correct and the verifier is like yes but like I don't know how it interacts without it revealing let's look at the verifier

component what is the verifier check so in a ZK snark you have public inputs and private inputs and the verifier is checking that a particular relation holds over the public inputs and the private inputs and the whole point of the ZK is that the private inputs are not leaked to the verifier while the public inputs are known to the verifier so what are the public inputs the public inputs will be the blockchain address and the ephemeral public key okay at a high level I might be missing something but let's go with this I guess Google's public key as well right yes I don't want to I don't want to get into that level of details but yeah okay yes of course so those are the public inputs that the verifier the blockchain will know hey I have an address and I want to make sure that this FML public key is

allowed to sign for this address right and what am I going to verify in zero knowledge I'm going to verify that there exists a signature from Google on a commitment of this seal public key and that that signature is over the same email address and application ID as in the blockchain address okay and from a high L perspective that's that's what the verifier sees does that make sense I think so so the nection to the address is just with this ephemeral output yeah what what the zero knowledge proof effectively achieves is it to temporarily tie the blockchain address to this Emeral public key which can then later be used to authorize transactions

for the blockchain address but does it get replaced the next time you log in yeah the fal public key you could use it as long as you you want it it it does have an expiration date after which you have to replace it you could use it although it would probably not be good practice yeah it's probably a good thing to have expiration dates yeah but then on the other side the verifier still needs to understand like you need to recreate a new connection with a new ephemeral output each time correct and the verifier will will be glad to do so as long as it sees a zero knowledge proof that ties together the blockchain address with a new FM public key it doesn't care that it's new that it's old all that it cares is that the zero knowledge proof successfully argued

existence of an open ID signature sure that's consistent on the blockchain address on that EPK I think I'm getting a little closer to understanding this okay the way I sort of see it is like there's two sides to this like there's the thing that's happening onchain the things that's happening offchain and I feel like every time I dig into this topic I get like a little closer to each other but the exact thing that's going on I think I probably need a graphic and someone to draw this for me cuz I've done it just picture like all of my learning for this has been purely through conversations extremely hard it's in your defense one day I need to see this drawn out well I got good news for you I have slides and I'm happy to share them and I think they'll be very useful

great okay I think you already said this we can share these as part of the show notes absolutely awesome so about this snark we're saying all right the snark is going to verify a signature it's going to sort of open my commitments and verify that it matches the contents of the signature mhm um that sounds pretty expensive to run yeah um is a plan for people to do that locally on their devices or how long does that take yeah good uh great and I think that's kind of a great segue also into the challenges of this approach CU so far the way we've described it we looked at it as a black box that can be instantiated efficiently but in practice there are a lot of

difficulties and one of the difficulties that Niko rightfully points to is the high pro time associated with creating this zero knowledge proof so what the snark has to do is verify an RSA signature which involves doing a shat two hash uh so we are able to achieve this in around 1.5 million constraints with R1 CS uh using grat 16 as a zero knowledge proof system and some of the tricks that we use to achieve this are some polinomial based protocols for concatenating Strings and for checking substring matches inside the sign message because we have to match things like the email address in the sign

message but the message is much larger right and we have to concatenate a header with the payload and then verify that this concatenation is signed by Google which once again adds overhead um so what we've done there is came up with some you know neat cute tricks that use polinomial to really uh lower the complexity of the approach and makes our circuit much simpler and we believe easier to audit by external people uh and also efficient because if you don't do this concatenating stuff in in snarks is horrendous it's really complex what was your quote earlier interaction is stronger than uh any algebraic tricks then algebra yeah then arithmetic that's Rafael stoski in all fairness not me

yeah yeah and to answer your question Nico if you were to compute this proof in a browser it would take you around 30 seconds so it's kind of expensive right you don't want to wait for 30 seconds before you can sign a transaction because you have to wait for the zero knowledge proof before you can sign with the associated fmal pup key it sounds somewhat acceptable no if I only do it once for the duration that I use the app for yeah maybe people like if it's a game you know like loading the first screen and then I can play the game maybe in some settings you're right it could be accept 2018 that was a lot but but going back to to our philosophy at apas we care about ux so for a d apppp there will be a large class of D apps where it's probably

completely unex acceptable to wait 30 seconds and once again people wait tens of seconds and minutes and hours on blockchains already we don't want to make the problem worse we want to make it better we care about user experience a lot so fortunately there's a trivial fix but it does have caveats the trivial fix is to use an external proving service to to solve the problem unfortunately the proving service will have to know both the public input and the private input to the snark in order to compute the proof so the proving the with respect to the Pro or service you don't get privacy so for us a a really important future line of work is to completely remove this Prov service or make it privacy preserving either via MPC or via other techniques FHA some people have suggested like you fhe eyes

it and then you send it to provs uh I think that'll make performance worse not better but but in in in in 20 years maybe okay exactly I was going to say in the near future probably not but one day yeah one day yeah I wondered actually about like who's doing the proving I think really wouldn't you want this like could you ever make this client side though like where it's just yeah yeah yeah and we're really excited to work with with folks in the space on making the proving practical client side I think for for a reasonable goal might be to make sure that you can compute a proof in a couple of seconds yeah because then you can kind of do it in the background and it usually takes a user a second or two to click on something to transact and I

think that might be practical I mean with all of the exciting developments in the Nar space like lookups and uh you know these U um um what's it called folding based schemes and so on I think there's a lot of stuff we can do we had to use grat 16 and circom because it's probably the only sane language at the moment that you can use to specify AAR relation and that's saying a lot because it's a very difficult language to write safe cod in yeah yeah well it's the most well trod and there are a lot of new languages coming out but but they're often tied to particular blockchains as well so I don't know if you can like in your case actually you just said you're using sirom and like but CC's not move

specific like did you have to rethink it to do this or you could just use it as is not at all um so circom will gladly generate a R1 CS file for your approver so you can use it in any R1 CS compliance nark including gr 16 once we have a gr 16 proof we generated by Circ or any other tooling we can verify it in move because like I mentioned earlier we can verify gr 16 proof over any arbitrary curve including BN 254 which is what we use I think I have this sort of like misconception of circom being like deeply tied to a theum because there's so much use and I think there's so many libraries like in that like T like solidity to circom kind of

connection but I guess you're right the language itself is kind of Standalone I think Nico you had a question oh no it was more of a comment in passing because you were saying you can do the proofs in the background and um I just wanted to give a shout out to penumbra actually who do that extremely well I don't know if you've tried any of their um tools but it is Groth 16 but they do it as soon as you launch any program and while you're doing your thing you're typing instructions by the time you press enter your proof is done and so it looks instantaneous and it's very nice so I recommend the amazing looking at their tooling or playing around with it that's very useful thanks thanks for mentioning that we'll definitely take a look yeah but unless

you want to talk about something specifically I did want to go a little bit into the other subtleties of the approach and how we're dealing with them because it's actually quite an intricate uh project I think so one thing that I want to say is we mentioned this Emeral public key right that authorizes transaction so the problem with this AAL public key is typically it'll be in your wallet and if you sign in with Google in your wallet once you're signed in you have to ask the user for a pin code to authorize transactions for example right because otherwise anybody who sees your laptop open you're signed into Google they can just sign transactions I think this is one of the reasons why you don't see sign in with Google approaches for

online banking because like you can't really have a userfriendly way to secure them unless use a pin code so what we've done there is we're using something called pass keys which are these uh public key credentials that are backed up on the cloud for you in apple in Google um and their the secret key component of that credential is secured in trusted Hardware like on your iPhone for example so we actually allow the fmal public key to be a pass key so that means that for example if you have a wallet on a mobile phone and you sign in with Google into that wallet and now somebody has your phone and they're trying to sign a transaction on your behalf to steal your money well they will get a face ID prompt when and they try to sign that transaction because the

phone is trying to access the pass key so this is a way to sort of secure this this approach and make it more robust right because otherwise it's kind of if you don't do this the alternative is to use a pin code which is very user arm friendly yeah right so we're very excited about this and another reason why we're excited about it is because it secures the ephemeral secret key associated with the APK much better than any other approach now it's usted Hardware so and another reason we're excited about it is because Pas keys are actually not backed up online on all platforms yet like Microsoft so we actually have a way now of using pass keys in a completely reliable way without users ever ever using them there's something also very nice about the almost the security theater that comes with this face ID prompt you know

like you're on your phone you're like oh I'm going to do this super secure thing o face ID bam like pasis give you that experience yeah yeah yeah yeah yeah yeah yeah in in a way sure if if you're trying to point out that the face ID there's sort of uh attacks on face ID right oh not necessarily I was just saying users who aren't accustomed to cryptography will feel safer when they see this face ID prompt yeah yeah absolutely absolutely I I think so too and even though there might be machine learning based adversarial attacks on face ID uh the class of such attackers is probably very small and uh I suspect it's still way more secure than a pin code which has way less entropy agreed yeah in an a conversation I had with Dan

Bonet last fall we were talking a bit about kind of the P key cryptography and how it's just it's different in that the EDSA version or like type is definitely different from what they have on ethereum from what I gather yes corre so there was this issue connecting the two things but in the case of Aptos is it the same so you don't have that issue okay I love that question do you want to explain like do you want to say what I'm trying to say this is like EDSA something something K1 versus EDSA something something R1 I don't remember which one it was but yeah great so it's ecdsa actually not Ed DSA and ecdsa is a digital signature algorithm that works

over any elliptic curve but most often it's deployed on these popular curve called secp 256 K1 and I believe the reason this curve is so popular is because Satoshi used it for Bitcoin ecdsa signature when Bitcoin was first created but I may be wrong so this this curve became very popular and ethereum natively supports verifying ddsa signatures on SEC p256 K1 however for reasons that I haven't looked into yet Pas Keys use a different curve also ecdsa signatures the curve is SEC p256 R1 to make things very confusing like we like them to be yes so now ethereum doesn't support verifying signatures over R1 okay unless you implement the

arithmetic manually in solidity the nice thing about apos is that we really believe in upgradeability so we've designed our system to make it very easy to upgrade our validator notes so we ship upgrades every month so one of the upgrades that we've shipped in particular our engineer Andrew Hariri big shout out to him who is very passionate about paskis he shipped a transaction validation logic that can verify ecdsa signatures over SEC b256 R1 mhm so we we previously had AC cdsa over K1 but Andrew added over R1 so so now we can verify Pass key signatures natively on chain so in fact an apos you can use pass keys without the apos keyless

infrastructure so you can just have a pass key based account it's just if you're going to do that you have to be really careful because if you're on Microsoft Windows and a website or a d app or a wallet generates a pass key for you that pasy may not be backed up MH unless you do it manually and are very careful about it so so but if you're an iPhone if you're on Apple in the ecosystem paskis are nicely backed up for you you don't have to worry about it so for some applications I believe they might just want to use the pasy accounts natively other applications might want to use appas keyis combined with paskis to get the benefit of of both cool yeah so you have done that I mean I I just wonder like couldn't ethereum also upgrade themselves though like well uh I

don't see why not it depends how easy it is for their code to change sometimes times when you when you write code the way you serialize messages over the network can be very difficult to upgrade in a backwards compatible manner so you kind of have to like uh look a little bit ahead into the future and structure your code in a particular way we've we we are very careful about that we care a lot about upgradability because we don't believe the solutions are all determined now things change in the future and you know our consensus algorithm has been upgraded already once and we're currently working on the third upgrade which is a SCH de based algorithm and you know the reason we can do keyless the reason we can do pass keys or distributed Randomness is because we have an upgradeable infrastructure cool

yeah there's there's much more to be said about challenges with keyless but I I we could talk for another 30 minutes so I'm just going to mention like a list okay so when you verify these signatures like Nico pointed out you need a public key of Google this thing changes and it's published at a URL so you actually need to achieve consensus by having the validators pull this URL so we have a very effic implementation of this uh in in our validators once again upgradeability if you're doing Zer knowledge proofs you know that it's really hard to write code securely in circum so there might be bugs in your circuit so we have a training wheel safety option in our code where we can make sure that if there's a bug in the circuit the training wheels will save us so this basically is enforced by the

Prov service who signs over the gr 16 proofs that we generate so this is very important for a responsible deployment because until a lot of people look at the circuit um and until a lot of people look at code in general you really don't know what's going to get you right so so we're trying to be very safe and very cash cautious about this you know if you don't want privacy you can just use open ID signatures directly you don't even have to use Zer knowledge proofs in our implementation so we have that option too and there's also another satty associated with d apps or applications disappearing and users not being able to access the accounts associated with that application so we actually have a recovery service that will allow users to recover their applications if the uh wallet or the app

disappears yeah and then we have some other cool things like U revealing a public field in this message signed by Google which could allow for things like kyc um that's that's an extra feature that that we've added in and we're very excited about this too and yeah there's much more to be said here but uh maybe so can you do things like checking that you know the account is at least 5 years old old or some kind of age to make sure that there is some form of reputation if Google exposes that sure and if not Google then if whatever oidc provider you use like Facebook or apple or yeah yeah uh you could expose anything they expose so then in a contract You could argue hey this account is this many years old or coinbase think of coinbase

as an oidc provider they might expose some Fields about you having P the kyc check and now contracts can know about that and then you could do reasonable uh sensible Anonymous payments for example predicated on that kyc check nice MH yeah if anyone I guess wants to find out more about this I mean you will be giving a talk at CK Summit correct on this topic I assume so in that I'm sure there'll be slides Graphics that describe this flow and maybe you can cover more on that as well there absolutely yeah and I have to to write a block post too it's just there's too many block posts I have to write in too little time left to write them nice as a last question on this topic at what stage is it like is this deployed is

this in the works is this still kind of like theoretical yeah it's deployed on our developer Network devet we have not yet announced it because we are still polishing the final product and the documentation in ddk but you know if a really brave soul wants to play with it technically they could play with it now on devet um by looking at our code and and and using the SDK that's public now but I think by the time the podcast will come out it should be announced on on on devet and possibly testnet too so yeah it'll it'll be released very very soon we'll try to grab any of those links to put in the show notes as well if people want to check it out yeah I'm going to inundate you guys with links yeah

perfect very cool alen thanks for coming back on the show thanks for sharing the update on the randomness as well as on the apos keyless feature and how that works under the hood yeah thanks so much for the questions and it's always fun to try and explain some complicated cryptography uh that the details have to carefully be left out uh but I hope things made some sense and if not please look at the slides and at the AIP AIP 61 I'll provide you with the links and it's been a joy to talk to you guys thank you thanks yeah thanks so much so I want to say thank you to the podcast team Rachel Henrik and Tanya and to our listeners thanks for listening