ZKV presents... Privacy on Celo (Full event video)

Transcript

alrighty are we live can people see us i think uh yeah if you are here just maybe say something in the chat to let us know that you are hearing us seeing us that we're coming in clear not not not seeing anything yet so i don't know okay hey i don't know if that's reference to us or maybe we'll just give it a second to see if people start to just confirm that we are live that they see us yes great fantastic okay so um great well i want to say actually just one note i think there

might be a slight lag between us going live and and you've seen us so if there is a bit of a delay in our answering of anything don't worry we got it covered so yeah i wanna i wanna just introduce you to privacy on sello this is our mid-summer event online we're very excited to be exploring the cello ecosystem this time around so um yeah this is brought to you by the zk validator i'm one of the co-founders of that and i want to tell you a little bit about the ck validator we are a validator like many others we do we run infrastructure we are you know running validators but we also do something kind of unique we support privacy and zero knowledge research we do this by being advocates for privacy participation in governance supporting teams on these ecosystems

within these ecosystems as well as launching initiatives to promote and fund zk tech this is our awesome team i have actually up here with me agnieszka and hector agnieszka is going to be running the show for most of today um but and they're going to both be helping me with this intro and we did leave one spot open so if you are interested in finding out more you know we're always looking to hire great talent to join us so let me tell you a little bit about the initiatives that we work on one of the initiatives that zk validator um kind of incubated was the zk hack platform initiative basically what that is is a place for people to learn about zero knowledge tech it's very very much an educational spot we have workshops

events and content being created around that that was host that was basically incubated by the validator and my other org which is the zk podcast and it's kind of becoming an initiative of its own so if you're interested just in zero knowledge tech and learning more about how it works that's a great place to check it out we also at zk validator we run we co-run the zk tech get coin side rounds so this is on the git coin clr matching platform it's on git coin it uses quadratic voting to basically deliver funds kind of more equitably to projects and we along with xerox park put together these matching rounds we've done three of them so far i don't have the number off the top of my head but

i'm pretty sure it's like in 300k range of funding that we've gotten into the hands of great zk projects um i should actually note that down for the next time i give this presentation but it's really really a cool initiative that we're happy to be part of other things we do are run zika education research focused events like this one in different networks and we also run validators on cello and abacus now so this is maybe something to note if you're learning about us for the first time we are a validator on cello and it would be cool for you to check us out all right hector take it away tell us a little bit about why this event hi everyone so i'm hector uh and why this event right so there are two

main uh milestones that need to happen for what tree to reach my mass adoption um one of them is to build products that are better than what's out there on on webtoon and the second one is to have privacy by default right um right now blockchains as you know uh are anonymous but are not private your information is out there in the chain available for everyone uh to to look at it so uh we do this type of events in the networks that we work to promote privacy and to help showcase the work that is being done out there by many teams and many builders and also

to make a case for builders who are maybe not prioritizing privacy to actually uh take a look at it and and to consider it uh to build products that are better than what's out there but also uh private in themselves um so as you can see uh on what agnieszka is going to to tell you uh regarding the agenda we have today um an event full of uh awesome talks and speakers to to talk about this topic and especially on the cello community as hector mentioned for the past few months we were learning about the community learning about its needs in terms of privacy and

when we started designing the program for this event we wanted it to be both entertaining and educational and we're pretty sure that we're going to deliver it for you today so right after this intro we're going to jump to the fireside on privacy together with anna president here with us and with marigold chefsky after that we're going to learn about oblivious prf plumber for planck plumo itself and at the end poverty of alleviation digital payments and fraud with our special guest from give directly at the end we also prepared something very special for you so hector take it over yeah so um for this event we have prepared a special

pull-up inspire on the silo logo so make sure you scan the qr code now or click on the link that we will be sharing on the on the chat uh to claim your po and then let us know on twitter what do you think about it and if you like it or not so make sure you you claim your co-app um by the end of the event of course you're gonna get all those links in the chat so be sure to to click on them we thank you once again for joining for you to join us today if you want to support us directly please take your cello with us all the information you have over here and also please remember that there is a little tab at the end

ask a question you should see it at the bottom of the of the screen this is the place for you to ask the question to all the speakers that's going to be on stage and right this moment i would like to thank hector for this uh wonderful introduction uh we're staying with anna and i would like to invite on the stage marek marek i hope you're with us okay marek is joining i think it's just me for now but hopefully you're joining soon merrick yes marek is joining at the moment cool

hello hey hey hey how's it going good good it's good to be here thanks for having me and uh yeah really big fan of of the series and and what you guys are doing around privacy this is awesome cool i realized something i didn't really introduce myself at the start of this but i will now so i have this you know i i guess i did say i'm the co-creator of ck validator i'm also the co-host of zk podcast that's what i do a lot of the times interview people um and what we're going to be doing over the next 20 minutes is basically doing sort of short form live interview and marek you've been on the show before actually i think that's when we met this

is like three years ago and i actually wanted recovery yeah pre-covert for sure and back then we were talking about i think we already had started talking about plumo so this is kind of cool that we come now full circle for it to be live and for us to be able to talk about its impact but i wanted to kind of go back to that time and ask you like what was cello when we first spoke and what do you think it's evolved into today yeah great great question um and apologies uh up front if i come across loopy or anything today i literally just got off a flight uh over the pacific uh to korea i'm here for um middle asia and east seoul

uh and and it's middle of the night here so thanks for jumping on yeah i know it's uh i guess it's fun to do this in the state you can ask me like difficult questions anything and i won't be able to like evade them be too tired yeah but thinking back to the early days you know maybe just um uh oh i'm not loopy enough for kobe okay okay [Laughter] um but yeah thinking back to the early days of cello um so i guess you know five years ago so a little before we we last chatted in that podcast the the origin story for cello started

with us trying to build a kind of a global decentralized venmo wallet on top of ethereum and we and for those of you who who aren't familiar with venmo venmo is a p2p payments application mobile application that's pretty common uh in the u.s um and it just really makes it quite easy on your phone to send value to anyone sadly only in the us and so we really uh wanted to to bring something like that um um to um to a fully global audience um and we realized quite early on that ethereum wasn't the right platform to

deliver something that the consumers could be able to use in a really easy to use way it just had a few um a few i guess platform features that were missing um and so what we ended up doing is actually building uh focusing our efforts on cello which you can think of as a fully evm compatible platform but with a few extra bonus features that make it easy for you to build really easy to use mobile applications for you know the general public and um you know you might be wondering what

those extra features were yeah i would say there's three really big ones in addition to being proof of stake and highly scalable um the the features um are like one the ability to pay for gas with tokens um we knew that sending stable coins would be important for this use case and you know is an important use case in all of d5 but the idea of having to need a volatile asset to pay for those transaction fees we knew that that would be too complicated for most people and so we worked hard to enable you to pay for transaction fees uh with tokens and therefore with stable coins um the second one was around identity we

wanted to make it really easy for for folks to be able to send value to phone numbers um and not to you know these difficult uh and um intimidating public key derived addresses and so we built a decentralized phone verification protocol that uh i think serves two purposes you can use it for civil resistance lightweight civil resistance but you can also use it to send value to a phone number even before the recipient has created a wallet which is pretty neat and then the third feature which was the one that we focused on last time you had me on and that was the the like client we wanted mobile apps to be able to communicate

with the p2p network in a fully decentralized manner without needing our pc servers that you know are prone to surveillance and and censorship and so we worked really hard to create a consensus protocol that uses ek snarks to effectively prove that a header is part of the chain which lets you sync in with just a few kilobytes of data which is really neat cool and there that example you've given is just like using zkp's but in that case it's more almost i've often used the kind of idea of compressing it's using using zkp for compression potentially for scaling but um i do want to bring in the topic

of privacy given the name of this event where does privacy fit in to this vision for sello is it on the right roadmap is it something still in the future or is it something you're thinking about today no hugely um yeah and i think because of the the origins in in payments um you know i think privacy was just really um an important focus for us and continues to be i think if you i think hector said it perfectly just now right like i think if we really want web3 to be adopted by everyone you know privacy is one of these primitives that needs to be universally available to everyone and it is certainly one of the things holding us back

and i think it's even more so important in payments than it is in d5 today because i think with defy today it's mostly a single-player use case you're interacting with you know smart contracts that actually take away the other counterparty in these neat ways and so you don't have to worry too much about about revealing your identity when you're just using a pseudo-anonymous wallet address but the second that there's two parties involved with every transaction every transaction that you're doing is revealing who you are um and you've done before potentially exactly everything everyone you've paid

any time you've bought something yeah yeah and so so i think you know defy today i think of as just a sliver of what it will be in the future um we want to decentralize all the finance payments are a big part of finance and and that's something that that's going to really require required privacy and then you know i think the other interesting element here too is uh because sello is good for sending stable coins around there's been some really interesting use cases on top of the platform impact market is a great example

of a of a protocol that that's been uh giving out universal basic income uh like payments uh to um i think on the order of 50 000 beneficiaries globally in some really adversarial um places they operate in the ukraine for example in in afghanistan in venezuela among many other places and i think for these programs where you're you're giving away aid and we're going to hear obviously also if you can give directly later today highly recommend sticking around for that you know for these programs i think you know privacy is equally if not even more important

um and and so certainly um that's that's another reason why we're we're very uh just given the kinds of applications that have been built on the platform um it's just becoming more and more important every day i i want to talk a little bit more generally about the priorities in the cell of ecosystem like maybe to also help us figure out kind of where it falls like yeah what what are the what are the general focuses or yeah priorities would you say are currently there and yeah where is where's privacy on that yeah that's really great question um so i would say there's two trends happening right now on solo uh one is

around mobile payments and that kind of has been there from the beginning based on kind of the origin story that i just kind of mentioned um there's a lot of effort right now for example around creating a stablecoin for every country in the world uh and creating on and off ramps in every one of those countries using kind of an open standard called fia connect but there's another trend that's happening too around refi um cello um when we launched it the first governance proposal that we did was to um was one that would

um effectively have the network pay uh programmatically to buy carbon offset credits from project ren to offset the carbon that that it was emitting it was only a little bit of carbon because cello's a proof of stake network um but uh but still we wanted to um like the community felt strongly about about the network being fully carbon neutral it turns out it's actually carbon negative because we end up buying more than we're actually estimated to be to be emitting um and i think because of that yeah it's neat uh i think because of that um there's been a lot of interest from the broader refi community

uh to build on top of cello and and now um zelo is is becoming this really nice um kind of hub for refi um and so that certainly is is quite interesting i do see the two things um having some overlap which is uh which is pretty great and i can get into more details in a bit um but yeah those are the two kind of higher level um i would say trends that are happening on the platform i i want to ask a question that i feel is going to show like some ignorance on my part i don't think i've ever actually covered refi uh what does it stand what does it stand

for is it renewable what like what does it stand for and where does it actually come from as a concept it's confusing because you know people refine their house refinance their house from time to time but this is not that kind of refi the refi stands for regenerative finance um i would say it's broadly a category that you know draws from d5 but um but tries to or aspires to have positive externalities um rather than negative ones these can be around climate change a lot of refi protocols today um have elements that help fight climate change uh people do a lot of people uh

in the broader community feel that climate change is a you know massive existential threat to uh to the whole planet and if we you know whatever we do outside of that may not matter uh for too long if we don't get a grip on this and so um i think these web 3 platforms one of the really nice things about you know just having programmable money is that you can really experiment with new and interesting ideas at a much faster rate than you could before and creating economic systems that have those positive externalities that's like perfectly right for experimentation

cool i want to go back to sort of link those that back into privacy is there really a need for privacy in refi yeah um so i think one way where refi and payments really fit in nicely together is this idea of creating stable coins that are backed by natural capital or by refi assets that are kind of helping fight climate change so a lot of stable coin protocols today are you know ultimately backed their stable assets with other assets usdc backs it with fiat but you know even protocols like dye

ultimately back their stable coins with other crypto assets and refi assets like for example tokenized carbon offset credits or tokenized trees or even i've heard people talk about tokenized affordable housing these assets tend to be a little bit more stable and so you actually get benefits from a stability perspective to to put them in the reserves that back these stable coins but the other thing that um i think is really neat and we had this advisor charles eisenstein he's a fairly well-known author highly recommend his books especially sacred economics in that book he had this idea that um

before even bitcoin was around that you know whatever backs money uh people value more of in the world and so why not back money by things that we want to see more of in the world and so he talked about backing money by by trees um and he had this big difficult convoluted plan for how central banks could work together to make this happen of course it didn't happen but now um at the rate of experimentation that we're going through with defy we can actually try these things um and so i think that's the link um i truly think privacy is super important for payments um but at the same time i'm really excited about

not just being able to vote with my dollar but also to be able to vote on which dollar i use um is it one that um that is ultimately having these positive externalities um and so so that that gets me excited um well beyond that um you know i think there is this belief that the voluntary carbon offset credit market is going to just explode a lot of companies that have made commitments to go carbon neutral by 2030 and a lot will hopefully reduce their emissions but

they're not going to be able to reduce them to zero and so there's going to be a lot of people buying these carbon offset credits um and one of the big kind of goals of refi is to make all these companies do it on on public chains and it's really nice because it prevents double spending of these of these assets which is a problem it makes certification also more clear and also you can have much more efficient markets around purchasing them and so i was thinking before this talk like is privacy important there on one hand when you retire the asset you want to do that in a very public way because you're making a commitment for climate change um

but when you're purchasing those credits i think maybe then you won't want to be front run you may want to actually you might make an announcement but you may yeah and i want to be front run around that so maybe there's some interesting yet to be i think yeah um discovered use cases there yeah i have i have a small idea here it's like if it became sort of automated that part of some payment always goes towards these things actually keeping those private would be as important as the payment itself because you might actually be able to figure out what someone's spending even if they've somehow made their payment private if you're actually seeing the credit come through definitely women i think donations are a huge

huge area where privacy is needed um i think typically people donate for causes they care about but some of these causes may um [Music] may be causes where there isn't 100 agreement but they could get in trouble for supporting those things yeah i mean there's i think if you know like the classical example is donating for abortion rights uh with credit cards you know anti-abortion um kind of organizations sometimes buy like that credit card data and actually target folks who are doing that so i think obviously this is an area where privacy is really important

i want to take i want to sort of pivot a little i think we have five minutes left in this portion of the event and i wanna talk a little bit about this is maybe going back to zk for scaling this idea of multi-chain versus cross-chain this conversation that had been happening should people like should all blockchain scaling happen through rollups the most secure of bridges are bridges okay i mean there's constant conversation about this and we're hearing about you know things happening in the bridge front so i'm curious here just like does cello have a roll-up strategy or and like we are also validators on abacus so we know that like there's also a bridging strategy i'm just curious what you're

thinking about in terms of security when it comes to that yeah really great question um yeah i think this is a fascinating topic and it's so interesting to try to imagine where the world will go um i think the all of the different bridge hacks clearly show that getting bridges right is difficult and i'm not 100 convinced that roll ups won't have the same types of vulnerabilities that we've seen in these bridges i think in many cases they tend to be implementation related issues and and the fact that these bridges just have really big um

holdings of assets just make them targets coming to cello you know i think abacus is a really great protocol um we're uh huge fans of what they're building abacus spun out of c labs the companies that i work for that helped build that a lot of the core infrastructure for cello um and um really big fan of their design and their approach and and just the team behind it at the same time and i think one of the advantages of bridges is that you can bridge more freely to more places people like to move access to lots of places

uh that freedom i think will always be something that people will value and so i think multi i think bridges will will always exist um i do think the roll-ups offer interesting security guarantees that are certainly worth exploring you asked about the seller roadmap one of the things that we're doing at cello is bringing narwhal which is a [Music] really interesting mempool protocol and when you pair it with bull shark it creates a very very efficient consensus protocol that allows a lot of high throughput transactions

missed labs one of the um western labs is is kind of the main company that's working on this um and then they're also um they have a long-term strategic partnership with the cell foundation they're also bringing move support so sello will hopefully soon be the first chain that supports side-by-side evm and move support which i think will be fairly interesting for developers who are excited by both languages you know i think no one like solidity is clearly here to stay it's the amount of code written the amount of

value that's being secured by it means that it's like just leagues ahead of everyone else um but if you want to have high throughput if you want to do payments if you want to do these things um move allows you to paralyze a lot of transactions in interesting ways and so we think there's a place for for both languages in the cell ecosystem um and then on the topic of rollups one of the nice things about narwhal is that it is a it can play a really interesting data availability role in the network and so we are also looking at using it as a place for for roll-ups to post fraud proofs as well we think that's pretty interesting as

well very cool um i think we're basically at time i did have more questions about plumo but luckily we have an entire we have actually two talks which are going to be touching upon plumo coming up very soon so yeah i want to say thank you so much for the fireside chat slash rapid fire interview when you're jet lagged in seoul so i appreciate it okay i got my tea here keeping me going keeping you going very good okay thanks so much merrick yes thank you thank you very much for both of you thank you anna thank you marek i hope you're gonna stay with us for the rest of the event if there's any questions remember about

the ask question tab uh below and now i would like to introduce to the stage victor graf that is going to talk about oblivious prf just a second let me pull vector on the stage okay victor i hope you hear us if you're there just let us know maybe

in the chat because i already send you an invitation for the stage okay once again yeah this is what always happens right okay i see victor is joining hello hello how's it going so yeah perfect so the stage is yours for the next 20 minutes all right great yeah so i guess i am here to talk about oblivious prfs uh and what are they good for um let me just share my slides real

quick all right so we're going to try a few things and i'm kind of a very kind of application purpose oriented person so we're going to kind of focus on you know what we're using them for and then we're going to get into the math um and additionally there's quite a few additional use cases so we should focus on two to start with contact discovery and account recovery um and then we'll talk about kind of additional use cases and maybe some other places that oprf show up after the fact so let's talk about contact discovery first so

why what is calm discovery account why do we need it so essentially the idea is if you start out with some well-known identifier your dns name your ens name phone number email address twitter handle people use those identifiers as roots of trust to know how to contact no identity for people online and these rich trusts are important because they are kind of short easily memorable uh pieces of information that can identify individuals uh and can be used for all kinds of other interactions so basically bootstrapping from one identifier to another is a really common pattern so signal telegram whatsapp they all use phone numbers as their source of trust even though the phone the phone the

phone number itself is kind of is not the important part but the fact that you have something to start off with something that basically people are identifiable by uh allows you to then uh actually if a bootstrap for a whole lot didn't be system email addresses are also used by like things like paypal and zell as well as phone numbers and then kind of key bases is a example application whereas where it is designed explicitly to take all the all your identifiers and kind of tie them together into more of a unified global identity that can be used to contact people in a secure manner so uh when we want to one of the problems you end up with here is that you may want a one-way mapping so you may want your

someone to who's your phone number to find your telegram handle but it's definitely not the case that you always want a reverse mapping these like if you are nothing from one direction so if someone has my telegram handle i do not want them to be able to find my phone number for instance uh and if you uh additionally like my abs has my email address i want to find my ethereum ethereum address so i can send it send me a payment uh and on solo in particular uh this is basically that we have a system which i'm going to talk about a bit more called otis that allows you to take a phone number and then map it to your your cello address and so

because these sort the source identifier has such low entropy uh they're not very big they uh you can easily guess the entire space you could also you can also start off a list of let's say well-known emails you can try all those uh it makes it difficult to make sure this one up one way mapping actually stays one way and so in order to make that the case you need some kind of rate money solution or some way of having queries cost the uh person who's querying something and so in this case uh messaging apps such as telegram signal whatsapp they'll implement kind of a contact discovery service which has uh rate limiting that they control centrally so basically they might use

captchas they might use other information they might use they use some kind of combination of identifiers which allow them to rate limit uh queries for contacts from from users and these systems are not always perfect in fact there's been some research in the past about breaking these kind of centralized mechanisms and by no means all the right winning functions always uh perfectly designed uh password hashes which actually have a very similar problem low entropy uh take a low entropy space which is passwords and map it to one map it through one-way function to a password hash which allows them to do authentic authentication checks uh they use they usually use computationally expensive functions so like script argon 2

they're hard computes basically it makes it it turns into a one-way function through that that way having a rate limited prf service will kind of be a similar idea that's what we're going to talk about this year so i see if you have a prf service yeah the core idea is that you have alice who actually has a message the message might be a password might be a phone number might be something they just some kind of some something they want to kind of uh use for this this mapping idea and they'll pass it to this this oracle or the service and the the oracle at this point is kind of vaguely defined but the key here is the oracle does some kind of authorization check this might be just a simple rate limit saying like you know no more than x messages per second can be can be

mapped uh or monthly brf it might be uh a cost like each message requires a payment it might be some kind of authorization check where they have to have some some credential in order to use the service basically the oracle applies some kind of authorization predicate and then if the cricket passes they'll pass back uh a keyed prf uh that to which the oracle owners key for over the message that's kind of the high level idea although there are some kind of issues with this uh if implemented in the most simple way so let's talk about some of those issues so i see the first one being that the oracle in this case like if you actually implement it as a single server is both

trusted uh it's basically with the rate limiting function basically they alone control the rate limit and the and if you're staking your privacy of your contacts if i say for example in the case of solo if you're using this as a as a directory service and you're passing your phone number and getting out the account like an account identifier um then like that rate limit is important to ensure that nobody can reverse the account account to reverse the mapping and from the account to get the phone number which we would not want and so basically that is this trust there is also additionally the oracle sees that sees the message if you if implemented naively and so that's gonna be one of the main focuses we're going to talk about with

operfs which is which basically make the oracle oblivious they do not see the message at all when they do this so they only the oracle only sees information that they use for authorization um and the other the first the first one we'll talk about in this a little bit later so let's talk about let's actually get into the the math a bit more and talk about oprfs so we're gonna need some kind of cryptography primitive to start with we're gonna use uh bilinear pairing groups so basically have g1 and g2 which are two elliptic curves uh they there is a asymmetric pairing which maps the which maps to a point from each curve to a tarp group generators uh so and so forth and key here is addition

additional pieces that predicate so this predicate is essentially as a stand-in uh takes in context information and basically just returns true or false whether or not the service should on the request and that's key because that is the predicate basically is the main kind of value that the prf service is adding to the system uh over just simple offline prf such as you know hmac um in order to do keychain in this in a single server example which we're going to start with uh you just pick a secret key uniformly from uh the scalar field so basically just kind of this is exactly the same as you might imagine for an ec ecdsa key um and then the public keys exist in g2 for this uh

example and so what does the actual protocol look like so in this case uh the the message itself is m and the client basically starts out with by blinding the message so that's this is the first part that you see on the left basically uh the client samples a random value from from the scalar field raises the takes takes a hash a hash to group of the message and then raises the message to that power so basically this produces what's called blinded point this this blended point is actually information theoretically indistinguishable from random at this point and so that the key there is anyone who sees this x-hat with which is the blinded message

without without knowing the binding factor get uh obtains absolutely zero information about the underlying message itself and that and that blend messages basically is what the server receives so basically we can guarantee that no matter what the service does they can't learn anything about the message that you said you send to it now the service basically over here the first that they do is they check this authorization project this might this would be a rate limit cost function whatever chemistry mentioned before uh basically they want check to make sure that actually you pass before they serve you serve your requests now in order to actually uh do the prf uh the prf in this case is a fairly simple one basically just take the

uh x hat take the binder message raise this visit your key essentially this is you know one half of a diffie-hellman oracle uh effectively um and then that results in the blinded output so this this output additionally has uh conveys no information about the input itself at least in absence of of the binding factor r and sends the blinded output back to back to the client now the client at this point can actually use a pairing check uh very similar to how bls signature works to verify that the output matches the input in the public key once they're convinced that they say that that is the case that this is a verified interaction and this is not always true of all prfs i mean all opr's

so actually some of the more more widely deployed opr's do not include verifiability but in the one we're talking about here the this is basically a vls signature based oprf does include verifiability and once they're convinced that that the output matches the input they can unblind it by raising it to the inverse of the blinding factor so now they have the output of the prf basically uh if you were to take this like this oracle system before uh the the combined interaction between the two now influenced this prf function which can take your phone number map it to a hash and the hash can basically be used as a somewhat public value you can put that on you can put that on chain

you put it wherever you want and basically people without access to without additionally going through the prf service can't can't really figure out can't do a uh there's cannot do a reverse mapping from the identifier back to your phone number again and now so far we talked about the the sometimes we talked about the issue of the oracle learning about your message and we kind of solved that we haven't talked about the the uh rate limiting trust so in this case we're going to uh use a distributed trust assumption instead of trusting any any single service um in this case uh so what we what we actually want instead of trusting a single service is to trust maybe a threshold of distributed parties and

this is kind of what we can what we're able to achieve uh with the cryptography that we have and so in this case in the case of otis which is currently deployed on monsello we have uh like five of seven parties are required to evaluate the function and so instead of having a single key for the prf you split the key across all seven parties or all nine parties or however many parties you have um and basically you set a somewhat arbitrary threshold depending on what your security level what you security versus availability you want and have that threshold be the minimum number in order to actually evaluate the function so this is we're going to introduce some threshold cryptography uh

and so and so uh the in this case we need a new key gen so basically we're going to select in parties and a threshold of tau um we're going to generate key shares so in this case i don't talk about exactly how these keys are generated but but you could for example use a petterson dkg or you can use a different dkg as long as you get kind of an algebraiculated set of keys and that's that is defined right here in this slide so basically you generate a key shares each secret key is is f i for some f that you generated via the dkg and every party i holds s k sub i um

f is a polynomial in the scalar scalar field of order tau minus one and so f of zero is is the kind of like global secret key of the master key and the public key is g choose to raise the power of f zero so this is very analogous to the to the the single server case so this is this is the same protocol again the the the only difference the two differences here instead of everything one server there are now in servers uh each each server server sub i and each server survive uses their secret key secret key sub sub i to uh calculate a partial a partial blinded output and the client receives all the

partial blinded outputs combines them to to form the single uh full blended output does the verification check on the full blinded output and then returns the unblinded version um so in this case now uh not only is that that none of the servers see any information about the message they additionally um they additionally uh cannot individually uh evaluate the prf and you need a threshold of five of seven so you need to corrupt at least five parties before the prf rate limiting function uh becomes invalid invalid all right so this is that was talking about like contact discovery but this another use case is kind of an account recovery uh

in particular here we are talking about the challenge of you know if we want to empower the um banks if we want to actually make a real system that causes that creates makes a massive change for people people cannot be at risk of losing their savings now especially when you're talking about people with one device uh you kind of end up coming back to passwords and paying codes uh we kind of try to avoid them because you know everyone knows the problems with passwords but they are actually useful tool they're a source of entropy that people can remember they do not they don't rely on fancy techniques and people are fairly familiar with them so passwords and pin codes are actually a fairly useful primitive for account recovery and this is kind of validated by the fact that a lot of systems out there you

know still use them uh what we're going to talk about right now is an example of an account recovery system you can build that although there are many so this is encrypted backup so backup basically you want to store your uh stored encrypted backup file in some place with authenticated storage so you need at least an account one account to access it which is like google drive or icloud you need google account buy cloud or an icon account to access your that storage and then additionally because that's definitely not good enough you need a strong encryption on that backup and the strong encryption com these come from something that that the user knows so password or pin code are good options but those are not those are also those those are not strong enough as encryption keys so this is where we're

talking about using it using the prf service as a way to harden these keys this is kind of similar to apple icloud keychain signal svr or whatsapp intent backups but distributed and using uh oblivious prfs um right and so actually instead of uh one of the kind of issues we see here is we don't just need one prf we need a prf for every single user in this case we're gonna introduce a partially oblivious prf and so this is this is one slightly more complicated i'm gonna get into i'm not gonna go through all the different all the math here but the core here is that in addition to the message m you see in the request function there's also additional input tag t and that tag t is visible to both

the client and it's also visible to the server you can think of it kind of as a salt like a password like a salt you'd use for password hashing so they're very similar there's a very similar flow overall but slightly more kind of elements at play uh but the the key effect here is that instead of just doing the kind of the simple uh the the the the halfy helmet function before we're gonna use the pairing group in the uh the prf output that allows us to combine together the the tag and the message into one output and then that will give us a blinded output that's in the target group uh which can be aggregated and unblinded just as just as before it's also

verifiable um via a interactive construction between between the two that requires no additional messages so the flow is is very very similar to 34 that the properties are very similar to as before but now we have an initial input a tag t and this is a very useful primitive and also basically is an extension upon the opr which has a lot of uses so oprs are also found in password authentic key exchange through like an opic protocol anonymous credentials through privacy paths google vpn uses a similar construction or they use blind rsa um uh pretty good phone privacy basically is automatic control based phone network authentication apple airdrop uses air

uses opr's between two phones in order to figure out if they overlaps uh as apple's csun detection uses oprs to figure out if something is matching a contact content hash without actually revealing the hash itself from the local device uh there's also privacy preserving log collection through a number of parties like facebook and mozilla that also utilizes oprs so super useful broadly applicable primitive um really excited i really like excited about it a lot so talk about deployment just very very briefly which basically uh oh the opr and opr has been deployed on cell main net since april 2020 since may net launch we use it in the oblivious directory service i mentioned very briefly before this is used for

phone number mappings the pio prf is currently being rolled out as an extension to otis and includes a flexible framework for rate looking for defining rate limiting functions that will first be used in account recovery but is extendable to a large number of other applications all right thanks y'all thank you very much victor i hope you will stay with us till the end and now a little bit of change in the agenda and i would like to introduce to the stage kobe kirken that is going to talk about blue more i hope kobby is ready yes i see we're connecting with kobe

fantastic no worries luke is going to be back right after the speech so everything is okay we just had to switch a little bit and then we're gonna go back to pluma for plonk hello hello hello the stage is yours thank you very much right hello everyone i'm kobi i am thanks for the for the compliment on the head uh yeah i'm doing cryptography on cello also today i'm head of research in geometry and yet today i want to tell you about

what we've been doing with pluma over the last few years and since we've presented it and you know did a few things with it i want to show you where we are okay so let me share my screen and let's talk about the slides okay all right so first i want to start with a recap of plomo what it is so mark touched on that a bit in the fireside chat with anna and i want to to give a longer recap to to show you what it's like so plomo is an ultra light client for

cello it uses snarks to basically compress the blockchain and enable you to sync directly to the latest state of the cell blockchain by verifying a very small proof a few kilobytes and you know what's the latest state so how can that happen and why is it important so just one second because we can't see your slides oh you cannot no we still cannot see your slides oh oh no [Music] okay i think it may be my fault but the hat is amazing

thank you oh no i think i might have a problem sharing okay maybe that works yes now we can see it can still see it yeah we can see it yeah okay awesome good all right so we're going to cover why we're doing drama and why is it important so when you're talking about uh doing simple payment verification which was described a while ago now it was described by satoshi in 2008

and for that you need to get the headers of the bitcoin blockchain and once you have headers you can verify inclusion of transactions because a header contains um a list of transactions that have been performed and in each block and using that property you can use the merkle tree that is committed in that block to show that the transaction is included so that's a very efficient method and lightweight method for clients like mobile phones to show or to verify the transactions have been really been broadcasted and accepted on the chain

but in order to do that you still have to download a bunch of bitcoin headers or if you look at ethereum you still have to download a bunch of ethereum headers and that's quite a lot of the data to download it's like megabytes gigabytes depends on the chain and that's not really suitable when you're talking about doing this in resource-constrained environments and which we would include mobile phones in places where you have bad data connection or that you want to keep seeing or you're talking about let's say a browser experience where you just want to instantly and be able to check something about the latest state in the chain

um so that's why we designed the consensus protocol in cello to use the cryptographic primitives that would allow it to be efficiently verifiable so first of all cello is a proof of stake network um it's permission lats um it's a decentralized network that has more than 100 validators running at the same time it uses a bft protocol meaning that you have a set of validators um that's validating the correctness of each block and every day or more correctly every epoch which today is around the day and

a validator set election happens and the validator set changes so if we're thinking about what that let's say naive proof of stake like client would be in order to verify the validity of the cello consensus what we need to do is to if we talk about naively we need to download each block we need to check that it's signed by a majority of the validator set we need to verify that validator set elections happen and update the validator set accordingly like replace the public keys and um

yeah so that's not you because [Music] um cello has a five second block time which means that if we verified the signatures for each block and if we did it let's say with ecdsa signatures which would be you know hundreds of signatures per block this would be quite heavy in a day you have around 17 000 blocks so that's not very nice so in order to do that we introduced a few improvements one of them is that you change the validator set every day and the other one is that we use billa signatures

which allow you to collect all the signatures from different validators and bring them all into one single signature and the latest thing is that you know now we we improved quite a bit let's say that we now need to in order to reload the validity of the latest state we only need to check what is the current validator set and check that the current validator set has signed the latest state and but additionally if we do this over a long period of time let's say a year or two and then this already becomes heavy because then you have to verify the election for every day so you know 360

headers that already brings us back to something which becomes heavy so this is why we use snarks in order to compress all of that into a single proof so that you have let's say the block on the genesis block where you have some initial validator set and the block a year after where you have the output validator set after all this 360 and i guess a quarter days uh all right just shortly um recapping what the snarks prove and we check that the values have progressed according to election results we check in the snark that the aggregate

bls signature is correct and we do the election and processing and show the transition and eventually we have as an output from the snark only two things the initial validator set and the final validator set we don't need to output all the intermediate ones and we do that using techniques um that we learned from the sexy paper and it's adapter recursion it uses these elliptic curves which one of them sits on top of the other and the bls 12 37 and bmw 6 on top of it i'm not going to go into too much detail

about that because i want to show you what we've been doing on the application level but i would encourage you to reach out if you're interested in that specific area all right so what happened since we you know last last i talked about pluma let's say in a in a presentation first of all we got pluma to a stage where it can be run on the minute so cip 22 has been a major upgrade which has been deployed a while ago and and it defined the the structure of some special field in the cell block header that

is happening every day which creates a snark friendly representation of the validator set and this is a kind of the magic ingredient which allows us to verify this efficiently in the snark and the second thing is since we're using a growth 16 snark we've done the multi-party computation setup we had tens of participants in each of the phases the growth setup needs two phases phase one phase two and anna was deeply involved in making that happen and and the last thing is that we created this persistent proving service

which every day whenever there is an epoch changes a new validator set is elected we are producing we're actually producing on this huge server that we rent and the pluma proofs and we provide two libraries and which are called plumbo verifier and plum verifier web and which one of them is a node.js library and the other is a packaging of it into webassembly that allow you to consume pluma proofs and run them on on these devices it could be even a mobile phone and by that getting access to the latest

state now maybe some of you may think you know i have access to the state of cello which is a commitment to to the state which is a state route it's a microsoft merchant patricia tree it's the same storage layout as ethereum and that gets you somewhere but it's not the end because now that you have access to the state you you need to do some queries on the state so you can think about you know what you can do with this so now that you have a small proof where you have proof of the correctness of the state

you can combine it with another proof it could be either a proof in plain text or it could be a snark proof so you can prove ownership of an nft you can prove balance of a user and you can maybe even prove ownership of nft privately and i will show a project that can do it which is called zika tester and but basically and the message that i'm trying to convey here is now that you have access to this numerical route which is the commitment to the state you can basically do any query and using and you can do that in a snark in a zika snare completely privately

and prove something some insight from the blockchain so you can think about if you want to get to some party and you have a board ape or whatever and then you know board a equivalent on on sello but you can show that you're the owner of one but you don't really have to show which one of those you are or if you want to show that you have above some balance of some token you can do that as well and because all these things are quite small because there are snarks you can embed them into some kind of qr codes i i will tell that you may be needing the those gif qr codes which are animated

but you you can do that yeah so this is one cool thing that you can do and yeah some other directions that you can think about now that you have access to a snark verified state of cello you can also think about building this kind of bridges which are light plant bridges and which use snark to snarks to verify validity of the state on another blockchain and since cello has um instant finality that is very attractive uh yeah so that's

more or less what they had to show just quickly for anyone that is interested in trying these things out oh you're seeing all my calendar now then um you can see here this is the repository that i mentioned diploma verifier and some code examples on how to verifiably fetch your balance and this is the method that actually does it and this is something the zika tester project that i mentioned which can take a state route from ethereum or cello it doesn't matter and proving zero knowledge is something about the state of ethereum

yeah that's pretty much it for me thank you very much kobe and we are ready for our next speaker which is luke pearson and luke is gonna talk about plumo for plong so look this stage is yours just the second look is connecting there we go hello how is that

oh we can't see you you won't be able to see me um unfortunately i've used a laptop where the camera is broken but you can imagine a very smiling face okay so this stage is yours now okay let me go to the screenshot can you see my screen not yet i'm looking for the screen share button you should have it if you hover above your uh name and last name should be like a little computer with an

arrow pointing pointing right yeah where is this oh there i am yes sorry with a strange very digitized emoji now not yet english philip is asking if you have a hat shall we imagine you're in a hat imagine a a big big heart and a smile and a very dark room very is that working now

no not yet i will tell you once we can see it okay that's strange maybe it requires me to just i'll share a window and not full screen thank you kobe yeah there's three options you can you can share so try all of them windows does it work now

not yet okay um let me try this like this that's what always happens at the live events on the world yeah just there's i see it says screen window let's even just try chrome tab yeah i think chrome is the best chrome is the best so i can take you off the stage and oh oh now it's something is happening yeah yeah now we can see it yeah perfect perfect well um first of all thank you for the uh the

patience had a bit of a disaster i'm away i'll soon be in korea like marek but but not there not there yet and all five other parties of crypto people here did not bring a laptop charger so they're borrowing mine very aggressively shall we say but yeah um thanks for the the invitation to come to the to the seller community to anna kobe agnes is going to be very fun um i'm going to be talking today about uh plumo for plonk so i was kind of slightly happy that kobe went before me anyway so he gave a bit of overview of what the protocol is and um and and and how it looks and during this presentation i'm going to go into some

of the inner workings and some of the parts that he uh that he described so the the sinking of blocks and the epochs and even a little bit at the end there we saw the the diagram with the merkle trees it's interesting i think at this stage of the uh the global zk snark roadmap to look into what existing techniques and potentially alternative uh proving systems to the to the to the flagship one where um pluma was currently implemented in the the seller github the graph 16 and what kind of advantages that can be brought to to potentially improve potentially add privacy

um yeah to uh to work so let's look um what the contents are gonna be so have a little quick look at this little hoppy snark that allows people to jump around sets at epochs firm half year intervals or however people choose to to implement and design the plumer protocol and then talk about r1cs or flexi and i use the word flexi here quite loosely because what's actually happening um at the moment in a side project that i'm i'm doing or or working on is that zed prize is it is for planck uh however

the the main point of uh how you can get higher degrees of expressionism is sort of an r1cs style so this a times b equals c for all gates or this sort of flexible gate style so it's kind of started with plonk but now we're seeing plonk and all of its variants all of its plunkish and blank open plonky and plunky ii and a little bit kind of the improvements that come in the new very sexy paper which is super relevant and super exciting for this but then also halo 2 and the ability to you know potentially modularize um a commitment scheme a gate expression and then also maybe even like a pairing operation if you even have a pairing operation some people are

putting some of these uh options and some of these improvements into into like transparent snarks that are coming and then the two particular examples i'm going to go through is hashing so fast hashing and elliptic curve operation so one for hashing these epoch blocks and the following one for doing operations as as kobe spoke about on the the two chain curve so the bw the bls 12377 sorry into the um the bw6 and how some of these operations be made a little bit cheaper and a little bit more efficient and at what cost within different types of proving systems so the aim of pluma very i think uh naively

is fast blockchain thinking to allow resource-constrained devices even more so than um you know ethereum nodes attempting to be run on relatively low latency computers but actually mobile phones to catch up with the latest state of um of of the chain knowing that only at this given point sorry knowing that at this given point so long as some proof passes everything in the past um some some proof representing the past six months everything since the chain's history can be uh can be trusted and it's very important on the top right the state of the art here that we're thinking about the cell implementation because i have been going through this

quite a lot um quite recently and it's it's a rust implementation it's authored by by many of the people uh listening in today and some people who aren't here but also it's uh it's it's the mo was the only i think end-to-end complete one correct me if i'm i'm wrong but it's also the most robust and i think it's the one that's uh definitely worth poking holes and seeing what the next iterations could look like and as i said the tools used here are gonna be the two chain kevs and the epoch syncing in this this block hashing the reason i got asked i think to do this and kind of my relevance and pertinence to the issue at the moment is because as part of the zed

prize or z prize depending on which side of the atlantic you you stem from is uh as an open competition at the moment for those who can implement and plumo inside of a plonk proving system and there'll be some some hints as i could say given today or some recommended methods to definitely try out to get lower constraint counts than will be required as well as a couple of the other advantages that can come from planck or flexi style so the first one we're going to talk about this this comp this uh comparison between the two so just to remind ourselves what r1cs systems look like these random constraint systems just take three sparse matrices

we'll call them a b and c you can call them one two and three and it just sums up all of the values of some a times by all the values of some b and show that it should be c so it's kind of your your left wire times by your right wire equals output y and it's done for every single index around the circuit so standardly because these allow for for free linear combinations up to a a very high ratio of um editions these systems are pretty inexpensive on the prover quite inexpensive on the verifier and have small clutch size however often because of the way in which you can express operations the way in which you could do like a hashing operation which could be you know as an algorithm quite complex

in its form you could say narrowed down in scope like you're really you're really taking something that has quite large levels of expressionism for for for moving around um like non-native uh efficient hashes and you're you're compiling it or you're putting it sort of in a box or you just have this a times b equals c and in some cases especially with some more um well-designed protocols that aren't just a fixed expression of polynomials like let's say like plumo we're doing lots of different types operations to try and leverage high flexibility and really high creativity it might not be best always to go okay we must force everything down to this

lower constraint even if it is a little bit quicker um or a little bit you know more easily verified or a little bit cheaper so the other option or the alternative is some kind of flexible zero knowledge construction so rather than compiling things down to this a times b equals c we could even have like a to the n times b to the n is c to the n so high degree polys you could even have a times b times c times d times e times f times g and all the way to the last of the 26 equals some output and even more so you could do a times b times c plus d plus e and and i'll go through and i'll work but basically its

expressionism is is far greater and now with some of the more interesting techniques coming out we see a bit of a better setup standard it's not on all of these proving systems but cello based on what was you know in the in the initial sexy paper is um a a one-time and like a non-updated one a non-universal uh trusted setup that's kobe talked about so once it exceeds the number of participants the numbers of those powers that have to sort of be redone so whereas if this was instantiated with a an updatable snarf one that usually falls into this uh more flexible pruning system you would see

a way of um we're able to just run this just itself at once and people will be able to just add on um additionally beyond the number of setup the number of participants that it was initially instantiated for there are of course some down downsides here you can have larger verification cost the verification cost it's pretty easy to understand in the r1cs it's basically linear in the number of um letters of the alphabet so you get your abc so it's you know three times um some cost but if you start to go a b c d e l m n o right to the end you get okay so you have actually much higher much higher cost in terms of verifying

all of these at once in you know we see this with with plonky 2 style where you have 128 polynomials which is great um for being able to chop down the operations in the prover side but it's just insane to deal with and on the verification side you then have to lean into looking to some kinds of levels of recursion and things that can make the protocol uh a bit more difficult to handle with and maybe a bit more in some ways uh nonsensical so to look at some of the things we have in that one of the current uh is sorry in the current implementation we look at clear tricks and like alternative hashings and some work that i did last year with uh a cryptographer from from a noma was an implementation

of blake 2s so looking at some in-circuit hashing done if we have blake 2s as a chosen primitive which is a fantastic chosen primitive for its security it falls much more into the bracket of uh what i've called t.o.t here so the test of time i don't know if many or taught even acronym or initialism you want to go for basically ones where we've seen over some time that the cryptanalysis is pretty strong and the um we're quite sure of the algebraics occurred to these hash functions which i understand given that some people see a lot of the new zero knowledge style with the the s boxes is some

slightly more questionable security so if you're using that and you want to do it and you want to do it where you have an epoch block and i picked seven fields here to describe um the different things that go into this hash so the validators the numbers the public keys designers because it does not grow linear in complexity it's super linear we end up with what's on number three here so non-native field operations these um standardly renowned algebraically secure hashes some of you like you know well plausibly post quantum ones like char 256 they work with bits they work with these um bits and bit shifting for for chunks but when you operate over snarks a lot of this bit bit shifting and

these big chunk things are uh really quite inefficient it's difficult to express um some of these operations inside of a finite field inside of some large prime number line so you end up having reasonable uh trade-offs with security and and with some of the other functions blake2s is not as bad um it's really quite expensive on the protocol to run some of these exclusive ore operations etc and tables however if you're able to use a uh approving system which allows to leverage let's say an example a new technique like lookups where you pre-compute these

operations these exclusive or operations between um different size different size bits and just bring them in as a table so you can like look them up let's say index and look up like it's done a lot in the the standard computing world you you can omit the cost of very expensive operations and sort of have them pre-done and just prove that they were done correctly so this this kind of operations done a lot quicker it allows you when when when when josh and i did it we had a four bit also please tell me if there's too much background noise i will put my headphones in um josh and i did it for for four bit it looks like we got a 50 improvement and this was a very unoptimized version we ended up having a look at eight bit

operations so much wider or much larger inputs into this table but it became too memory intensive so again we're following ourselves into the world of quite significant trade-offs where if you're having somebody sync um to the cello chain through a mobile phone you don't want them to have to download also gigabytes worth of table it'd be great if you could just import tables with pre-computed answers for everything but uh but we don't we don't get the luxury of that so seeing that you can you can take some more modern techniques with more flexible proven systems or with more feature intensive proving systems you know can can potentially improve

the some of the aspects or components within uh within the um pluma protocol so the next one to look at is gonna be two chain improvements a lot of this if you guys haven't haven't seen it yet comes from the new sorry came from the new very sexy paper it was kind of a next iteration or a bit of an augmentation to to sexy done by the espresso systems teams you know where they kind of take the main um expensive operations like pairing checks doing multi-scale multiplications polynomial evaluations over fields and then different fs or different uh hmir operations and improve the way they do by actually specially curating each of those gate checks so rather than the gate checks b

as i said a b equals c can be some a plus b times d plus this selector polygon plus that one um you can kind of ad hoc design around what you're looking for best in your protocol and that can be all the way down to what is the best way to um to to to express you know a cheap elliptic care operation whilst not making it super inefficient for all of our you know range checks or some so the quick example here is um to look at this two chain elliptic curve operation which is if you're checking multiple signatures on the on the bottom left here in this white box with the the the little the bls 12377 and bw six

you're just basically aggregating lots and lots of these signatures donut on bls and you can check them for free which is really really nice in one check irrespective and you do it on this this outer curve and you you have that right now in the implementation you end up with reasonably high sorry reasonably high circuit complexity uh one of the reasons is because you could say compared to a lot of other snot protocols which just aim for the the golden window of security of the kind of 128 bits you end up getting more um more more bid intensive operations and then you get these formulae which i'll show you the formula

on the next slide which is standardly quite expensive sorry sorry which is standardly uh quite malleable and they've ended up being if you look at the hisselwong papers uh from 2008 on the you know the fast edwards editions they've ended up being quite expressive and quite far away from the the a b equals c and putting them down to fix fixed constraints can have a much a much larger um cost than what is just linear to the to the change in number of variables and the last quick one on the bottom right um the the elliptic curve being in addition if inefficient for additions and multiplications basically what i'm

saying there is r1cs boils down to additions and multiplications and whilst everything in a circuit boils down to well boils down technically to just lots and lots of additions just many many many times over there are ways we look up tables and in in this this ecc some constants and some inversions and some embedding some amounts of some scalars and some elliptic curve inversion tricks where you're able to sort of hop you can kind of hurdle over um standardly expensive operations like we're like with multi-scale and multiplication like being able to break down a scalar and do it in in parts rather than just actually do um

p you know get to your public you'll get to some point in the curve by doing p times itself n times time just secret key times there's ways to hop around otherwise computers really will be there forever some would say exponentially so the the example i'm gonna example and then i'm gonna show today is just how to uh leverage uh a more flexible consent system to present to you say rework a gate instead of being this and i'd say probably for the last time this this a times b is equal to c into being able to to express some um a times b times d divided by c times d

times e to f plus et cetera i'll show you on the next slide which um which gives us a way to sort of tailor to the operations they're doing rather than have the operations kind of be tailored back into to what to what the proving system is fixed us so if we yeah i'll try and i'll try to not make this this this too intensive i promise it does it does make some sense because in the in the jellyfish library the elliptic curve editions are done in two constraints whereas many many operations uh and many many existing libraries out there will be doing a bit cares of that size and operations of like 300 and such constraints and you see the same with different hash

implementations like the poseidon it's done in one gate in planky two in 953 gates in a in the in the dust plank in 400 and maybe like 400 gates in uh the file coin neptune uh hyper optimized one so you see the ability to make slightly different level and then oh they're not sorry into the thousands into the arc works graph 16. so you can see the different types of proving system giving different levels of uh of constraint counts so if you look at the uh these gate equations at the top if we're looking for like a point x three and y three so we're not going np a trillion times or whatever this huge key is we're just trying to get to

number three so you've got our first point our x1 and our x2 you you have this system check this um this this x uh this this x1 times y2 plus x2 times y1 divided by one plus d which is some curve constant times x one plus y one x two y two if we could check all of these at the same time we'd be um i think we'd really be in there that that golden window would be in the money so if you can rewrite your your gate check to look into um some multiplication selective of when you need to have some amount and also embed a constant like this this d into a selector which is the qecc some selector

polynomial you can get to the sort of next gate check uh not necessarily the next point in in two checks by just creating the flexible constraint system to fit those two equations at the top um and then just selectively turning on whatever um of the larger equation so you know whichever sorry uh polynomials are going to describe this um this operation and just to sort of wrap a little bit i think some things that are worth adding because we're at the the stage in the zero knowledge community where this can be so ad hoc and back and forth is maybe some little pointers one on the on

the top left it's not impossible for example to add lookups to r1cs i had a little look into it well it did a little hackmd in it recently for some memory checks i know i actually won't say the other people who are doing it because maybe it's a little stealthy um but you know they just add um extra extra row checks into the larger matrices but you're looking at rather than one look up one constraint that you're looking like one one lock of eight constraints so it is more inefficient but it's not impossible nor is it impossible to find different ways in in fixed proving systems to work nor is it if you were to pick the mile improvement system you know is it required to have this uh this one this um non-updatable setup you can have a

universal uh reference string without needing to use planck or to use or even go into you know um a trustless setup i think it's very very important in the to think about the one on the top right about how high degree constraints must they absolutely must be handled with care the last thing you want is to just allow for 500 variables um or gate um checks inside of some uh inside of some equation sorry proving system and then end up with the the need for the verifier to to wait for an hour on its phone to check a proof but it's okay because he he proved it in one

second and something that i didn't touch on today but feel free to get me afterwards because i've got all of this written down is it kind of extra optimizations um the most interesting one of these is for me is the online lookup tables so actually not even having them downloaded but having them just checkable um with some indexing operation to it to a cloud or to some kind of kind of server that you know potentially allow it for for much larger operations which is uh gets rid of they can get rid of the memory problem and then the merkle variants that was um written at the end whether you go for american mountain ranges or you look for for medical inclusion proofs these are also things that can be improved obviously by

the hashing unlikely or or not recommended to be doing too much with the blake 2s but but definitely with some circuit friendly and it allows you to shoot your way up this discrete log base structure as as fast as possible so you can sort of check what you have in your leaf against the state the state route and then i didn't really talk about but it's because um even though it's the title of the whole thing uh privacy uh there's different ways to to look at adding privacy into this product it might require an extra level of uh abstraction the kind of way you have the zkz roll ups or or encodings or or something like for um

adding i guess definitely more expressive gate operations inside of a plumer implementation and the last one would be um changing the the level of recursion such you could uh have a much higher verifier cost to something like proof carrying data so i hope that was as enjoyable for everybody to listen to as it was for me to present it uh if there are any questions feel free to ask maybe this if there's some in the chat i can i'll stop sharing and i'll jump to that uh yes we can leave the questions in the ask a question tab and over there you can answer everything that's gonna pop up thank you very much once again enjoy your holidays

very welcome thank you very much for having me all right so we are arriving at the end of our uh event we have one more speaker poverty alleviation digital payments and fraud with andrew vaziri andrew i'm inviting you to the stage i hope no more technical problems okay i see that andrew is accepting and connecting so we're waiting hello hello hello the stage is yours sir

well thank you for having me and uh happy to be here i didn't know about the hat theme in advance so luke had an unseen hat and kobe had a augmented reality hat and victor had x hat but no hats were required but um so now let's begin and uh i will share my screen okay enough of that great so uh poverty alleviation digital payments and fraud um no cryptography in

this presentation but um hope to provide value to everyone here uh by giving you a really concrete example of what it means to say that privacy is the next thing we've heard from victor about oblivious pseudorandom functions i'm your oblivious presenter relating feature requests so please email me sharon chat anything that you think would be relevant as i describe what we do always happy to learn more about every amazing thing that's being made by the community who is give directly give directly is a charity that sends cash to those living in poverty with no strings attached we're one of the fastest growing ngos focused on international issues so we've reached over a million recipients we

have given away almost a billion dollars worked in 11 countries and um our approach generally follows four phases so first we target then enroll and transfer the monitor in the targeting stage we're trying to assess uh who would benefit from our programs who's in extreme poverty in the enrollment stage we're going out in person we're finding them we're making sure that we're not double counting people that we haven't passed over anyone and we're teaching them how to use uh perhaps a feature phone perhaps mobile money um various technologies that they would use in the next phase which is transfer so here we're integrated with local payment providers and we will send um payments actually

even to the most poor people in the world we found that sending them digital payments is preferable uh there's less risk of theft even in many of these villages people don't have windows at all they might not have doors that can lock so having a pin code that protects your finances is more feasible than even lower tech solutions and finally we monitor so we have follow-up surveys we make sure that we speak with each recipient we know that they receive their money that they had no issues we have a hotline that they can call if they're having issues and we have dashboards where we monitor for anything out of the normal um

what about when there is something out of out of the normal what what kind of uh fraud have we seen so give directly has lost 241 000 633 in 2021 and that's about what we expect we think it's very important to be extremely candid about the challenges we face every major nonprofit does experience losses from external fraud but few rigorously investigated and safeguard against it and we're very happy to be able to share these um metrics with you so the the three types of of losses that we track would be theft imposters and bribes so theft is when somebody transfers funds or property without the

consent of the recipient bribes would be when someone coerces a recipient to give or transfer funds as a way to pay back for some sort of favor and then imposters are people who through some false pretenses uh sneak their way into a program for which they would not normally be eligible and that sort of loss is a loss to give directly but it doesn't uh it doesn't uh represent a loss to a particular recipient so for the rest of this presentation i'll be speaking more so about bribes and theft when we try to reduce fraud we have a number of methods i described in our standard approach a number of things training hotlines follow-ups but we have an additional

team that's completely separate called recipient advocacy so they're firewalled from our other teams they have their own reporting structure in fact the two teams don't know each other's identities and they will go and reach out being local members of the communities uh able to speak to people in their native language and uh just double check that everything was above board and this is especially useful when we want to do an internal audit to make sure that our partners or our own staff aren't doing anything they shouldn't and finally we perform risk assessments so we will seek out to understand if there's something about a particular community that requires more precautions and in the cases where we we see this

higher risk um we will do a couple things we might randomize when and where to send staff so we won't go geographically to each village down a one road will kind of go to different uh areas of the county in a random order to prevent uh fraudsters or impostors from knowing where to meet us in advance we'll also conceal who's participating by registering person recipients in private it's more efficient to register everybody together as a group but in some cases that's just not feasible for their safety and then we'll also stagger payments so there isn't a day when everybody gets their money and everybody who's part of the program is going to the store and is seen shopping but instead it gradually

rolls out and they're we're not leaking through some side channel uh who was or was not participating and despite all of that we still see the fraud that i mentioned on the last slide and this is while using payment methods that are certainly um centralized at the current moment but also private the only people who have access to that information are the telecoms who operate these mobile money payment networks uh governments and the parties who sent and receive the payments and so we would we would see that level of fraud even in a relatively locked down privacy situation and how would give directly uh continue our mission and continue to

integrate more deeply in web three well first of all we already get a lot of funds in from uh crypto donors we have accepted donations since 2014 um which was fairly early and because of that it was before um a lot of the more convenient ways so we still do uh accept direct crypto donations to our wallet addresses we've raised 50 million in direct crypto donations that's about 5 of our total revenue as an organization so very very healthy amount of donations and we appreciate the support from the community in terms of funds out presently as i said we're using mobile money these are centralized digital payment platforms operated by telcos

and they are fit for purpose uh but we are interested in exploring potential benefits of using distributed technology and we've seen that this is possible to echo what merrick said in the beginning because of uh the ability to use stable coins to pay your fees in stable coins and have interfaces for feature phones so phones that are not even as computationally powerful as a smartphone that are the most common sort of phone held by the unbanked i won't go into detail about the benefits of a centralized versus decentralized approach but um take it that this audience appreciates those

and let's let's move to what are the fraud risks and what are the mitigations and essentially where is the place of privacy so in a naive implementation of a blockchain some people might say well it's anonymous but i think the anonymization should be assumed in a naive implementation the first time you transact with someone if you can view them in public making a payment at a local vendor any of these things could immediately let you look up their um address and de-anonymize their balance you know de-anonymize their their past transactions uh we should also be careful whenever we

link mobile phones to these public financial records um we've talked a little bit about the risks associated in victor's talk um but it does make everything more convenient to be able to use uh some sort of signifier like a mobile phone and unfortunately a subset of everything is crime so we definitely want to be careful around that and lastly we should be aware that public transactions and balances increase risks already present in mobile money contexts so i'm going to talk about a few examples which have absolutely happened to give directly recipients in a mobile money context and in that case remember their transactions were private so

in the case of theft you might uh imagine somebody pay at a local store and you could check the blockchain for their balance and then follow them home and threaten them with violence on the road once your uh no passers-by will find you to receive their their transfer in bribery you could imagine that once an official takes a payment they now know the identity of the person who paid them they could check their balance they could start adding fees or other ways to coerce more money for a promised service we could have phishing attacks by reviewing transaction history people could be called and the the person who's phishing them could pretend to be a representative of a recent transaction

so we we have people call recipients and pretend to be staff of give directly already and i'm sure that that would be even more uh convincing when they knew the details of every moment when the transactions were sent their exact amount things that people might not intuit would be available um lastly scams they target the most vulnerable people generally the elderly the illiterate uh people in marginalized groups and so we need to be careful not to make it easy for scammers to cross-reference uh phone numbers with the vulnerable and understand their ability to pay by knowing their balances and finally maybe the one that's not actually a crime but is important to to

recognize is that we're trying to give unconditional cash we find that it has the most benefit when people can really spend it freely according to what they think is best and they might need to spend it on things that would be not socially uh promoted in their local context but which they think is right for their life perhaps they need to move somewhere else perhaps they want to send a female child to school whatever it is we want them to be able to do that without the social pressure of being observed so we have mitigations we can have balance in transaction privacy we can enable these sorts of technologies by default to protect the most vulnerable those are the people who aren't going to be tech savvy enough to kind of

redirect their funds through multiple steps they're going to need it to be private and secure by by default and lastly we need the fees to remain low to drive usage that people won't disable such features so very happy to hear about all the improvements and proof technologies that could keep the costs of such things uh reasonable for people who are making most of their transactions for less than a dollar so in summary just uh one um thing we have two more minutes yep yep um in summary we want to protect our recipients from adverse outcomes we want to gain the confidence of funding organizations i want to be really concrete here when people say that that

privacy is the next frontier uh when i am talking with funders when we were talking about potentially million dollar grants that would onboard many thousands of people onto the blockchain we run into this issue of how are we going to protect them and until we have better privacy protections a lot of those contracts are on hold so i want to be your face to the problem that that we are already in a position where cello has done a great job lining up all of the things that we need to have a cache like venmo like transaction and this is really the the final stepping stone before i think we would see uh really increased adoption and thank you everyone for your work on

these problems uh and finally we want to compete with existing centralized payment systems uh privacy is built into the centralized systems to some extent we don't see a lot of leaks of information from the people who are running them and so reaching parity there will help us make the case that it's worth it to move to web 3 and it's worth it for the other benefits uh thank you for inviting me if you have any uh poverty alleviation universal basic income or humanitarian work please reach out we'd love to hear from you i also would love if you would upvote some of our privacy related feature requests and if you'd like to donate to give

directly i will paste those addresses into the chat thank you thank you very much andrew and we arrived to the end of our event so thank you very much for uh joining us one more thing remember to uh claim your pop we're gonna send it in the chat once again and thank you for joining us and if you want to directly support us please remember to vote for us here is our website our twitter account you can follow us on twitter for more news on seller and all the networks that

we are validating read our blog post on medium and if you want to directly contact us please email us at evens zkvalidator.com [Music] let me just uh see if all the links are in yes all the links are in oh we don't see the slides okay so you have all the links in the chat i think that's enough thank you once again thank you to all the speakers i'm pretty sure you enjoyed it as much as i did and see you hopefully on the next privacy on cello