Gate your app without doxing your users

Transcript

hello i'm leo i'm from sysmo and today i will talk to you about ziki attestations and an applied use case how we can get your app without doxing your users so in the first step we are going to to see the sismo protocol theory how it works and in the second part we are going to to see a particular use case we did last week so ethereum power users ziki batch so yeah cismo is a modular attestation protocol focused on decentralization privacy and usability so first what is an attestation so it's a certificate that proves a fact

so it has an owner a value a recorder on or an issuer a timestamp and some extra data so attestations are bundled in collections so ziki at the station are just attestation that uh proves a fact with zero knowledge so without revealing anything about the fact how it proves so basically to prove a fact you have three possibilities you can prove it publicly you can prove it through a third party or you you can prove it using the qp and and we are using the qplc smoke so

what we are doing that we are issuing attestation about from claims about group membership so here you can see uh what is an account so an account it's a it's an account identifier and an account value and the groups of accounts is a set of accounts so here you have a very simple example with an extract from the ethereum power users group of accounts so we are proving membership of a source account into a group of accounts and we send this attestation so the owner of the attestation will be on a destination account for example

you can use your private addresses as a source account and you can use a public address as a destination account so for instance if you want to prove that you did a lot of transaction on instagram or you have more than i don't know 1000 ethereum on your private addresses you can put this attestation on your public address so with the key attestation there is no link between the source account and the destination accounts this is what is interesting about the key atta station so in the sysmol protocol we have these attestations that are stored on an attestation registry and we

have some ad testers that are like issuer that can write in this attestation registry also you have budget contract that is a nft and that read directly to the attestation's registry so we can split in three parts so we have the left path we which is how attestations are verified and built how applications are stored in registry and how they are consumed everybody is welcome to create newer testers and new badges contracts because it's it's created to be very very modular so we are going to see how attestations are

issued with their testers in the next part and how bad is what are badges and what can be done using gettystations so yeah a tester verify a user request of a claim of group membership it will then build the attestation and record the attestation on the attestations registry so when you have a z tester it's just that the the verification of the user request is done using a zero knowledge proof so the adjust at the start they issue the key at the stations so

what is their knowledge proof zero knowledge proof the a new cryptography uh crypto cryptographic primitive that allow approver to prove something to a verifier with three main properties the completeness that means that honest verifier will be convinced with a very high probability from an honest prover the thumbness that means no malicious proverb can can can fake statements about a proof to a honest verifier and the theory knowledge one that means mean verifier don't know anything about the what is inside the proof except the

statement so if it's true or false so i like to present it as you can execute a computation without cheating in the computation and the content of this computation remains private so the prover is making the proof it's under proof to the verifier and the verifier will say if it's true or false so for instance if if we know secret ash is the secret you can prove to the verifier that you know the secret with which was hashed without revealing the secret and to be more press with circum so

circuit compiler from island three you can you can make your proof with javascript and you can send this proof to a smart contract verifier so at sysmo we developed our first zikir testers the first attacker we developed for the protocol that used a circuit we created which is named hydra s1 and it allowed to issue knowledge attestation membership so the approver will verify that the user owns a source account

so it will also verify that you either own the destination account it will verify that the accounts is inside a group of accounts with a merkle proof it will verify the account as an associated value as we saw in the last slide and the user will generate a ticket that is a namely named newly fire and that will be stored unchained to avoid double spending to avoid to create multiple attestation for the men is the same source accounts so if if we come back to the uh

at the stations registering on the you know our different smart contracts we we saw the left path that was you know they are testers how they are tested verified proof and how they write the attestation on the attestation registry and now we will see how the badge is made on top of the attestations registry so the badge is a is a stateless contract that read on top of the attestation registry it read the balance of the construct directly read to the attestation already three contracts so it's it's stateless and it allows to be compatible with 1155 standards that mean you will have an nft

associated with your attestations and with this satisfaction you you can do a lot of different things for consumers for instance you can use a snapshot guild lens unchain etc so now maybe you have some questions about the first part um to make to make these proofs um you're putting this in a [Music]

hush tree like poseidon hashes i'm assuming do you also like who's constructing this and is this part of the proof like is there some known signature from your side that you're signing each leaf with and prove that or yeah so so when we create the group of accounts this is formatted as a marker tree and it's all the mark is downloaded on the browser of the user and the user will generate its own merkle proof inside this marker tree for privacy reasons and the for our first ad tester we are the issuer of the attestations so cismo is the issue of the of these

attestations and we are consulting our own merkle tree for this attester hi um i wanted to ask when you say that in the prover the user has to verify the ownership of the source account and the destination account which type of signature if you use signature verification use to prove that we use a off-chain commitment scheme that means that so it's it's really similar to semaphore but

with an off-chain part that means that you you you will send a proof of ownership of your accounts with a it's an ecdsa signature you send it into an often commitment you will create a a world commitment you know an anonymity set which is off chain and hidden and thanks to that we can verify uh the delegated proof of ownership of this of chain commitment inside the zero knowledge so you just have to do it once and after that it will be you will be able to use your your source account for each different type of attestations okay clear so the second question is i

guess you are not using uh directly the acdsa inside the the proverb because it's too yeah it's too much uh computation right yeah okay cool so so yeah to to verify a proof of ownership and to generate a newly fire the the the only uh the really good way to do it is to use directly the private key of the user and to verify the signature the ecdsa signature inside the zero knowledge and to use the private key as a source newly fired to avoid the world spending so this is a really how it should be done

but there is a very huge limitation for now there is two limitations the first one is that verify ecdsa signature inside their knowledge is very uh heavy in terms of computation it's around one million constraints so around one minutes to compute in a border and uh the other problem is that you you can't access to the private key of the of your users so you can't use it as a newly file so the scheme we did use an offchain commitment where the user creates a secret he actually this secret in his brother in the front end and he will send this commitment in the

often commitment scheme he will then prove that he earned this commitment through the secrets he previously hushed and this secret will be part of the will be the source nearly fire thank you okay so we are going to to see a practical concrete example of some power user the keyboard we did last week so uh so here are what we are we want to do we want to generate a group of accounts for from the most the top transaction so

it was the top 50 000 uh users that did the most transaction per year from 2016 to 2021 and we merged them in a huge group of accounts we joined these small groups group of accounts so thanks to that we we then need to provide a badge image and some metadata for the nft and uh in the third part it's how we are going to integrate it with tools so uh guild could have learned to do a gated channel and a snapshot to vote on the evolution of the group

the ideas was to to let users vote privately so through their ziki attestation and the key badge and how they are going to let the group change in the future so if we integrate new user how we are going to integrate them and the stuff like that so um as we need a lot of infrastructure to create another group of accounts on the merkle trees and to provide these marker trees to the user in the frontend we created a wall repository and project that is called sysmo data sources and it helps to provide the infrastructure to

generate some group of accounts with some scalable infrastructure on aws to put those data on a public api so for now it's only an f3 but it can be ipfs very easily and then also under attestation collections so the link between the the groups that you made available from a tester that autosum the transactions for uh you know change the route and chain and also uh it uh make the data public for on this extra and there is an api too so i'm going to just show you how it works and how how it can be easy to create a new group for for developer

so when um you you want to generate a new group you just create you just extend the the group generator class and you are going to put the generation frequency you want for the generation so for your generate function to be called and to create new groups so for instance here it's we can see uh what is a group so it has a name a timestamp some tags for easily matching and searching and it has the data so the data is the the account identify on the icon the value the the value will be

can be associated then in the attestations and the attestations value so here it's an example that is not really interesting because you have just had written two accounts and just that so we we had some data providers so all these open source so you can add yours if you want and we will be really pleased for that so we create a graphql provider bigquery provider that helped to create a lot of data and with very selective way to do it snapshot etc we also created some data operators to join intersect or map these groups so here is an example where we

want to create a e s voters group with all the voters on a snapshot that did a vote on ens space so you just uh answer your snapshot provider and you just need to create all rotors for for space you can also create all routers for a particular proposal so here the generation frequency frequency is uh weekly so that means this new group will be created each week and this those groups are going to be available for the air tester you can see the ap so it's really easy

in the second part you have the attestations collection so it's basically the link you are going to make between the group you have previously computed and the badge you want to be associated to these groups so here for instance we are going for the for this attacher so it's the first tester we deploy we which is named hitra s1 simple attester we are going to take always the latest computed ethereum power users group and we are going to have to say to do is a badge which is an nft so you have the metadata here the name description and the image so the available group so the group which is

here will be automatically transformed in the market tree and you will have an api for the front end also for for the fountain to call all the macro trees the route and stuff like that the same for the badge it will create the metadata json so it looks like a metadata as a open c and stuff like that so it's an 1155 metadata so with that you you can then let your users meet this dispatch and it will appear directly on openc and it will be easy to integrate with all different uh [Music]

consumers that has the standard 1155 so open c here you have also a guild it's very easy to to add a new a negated channel just by looking at the at the the here you have the token id of the badge and the the address of the contract for snapshot it's exactly the same you have some some strategies and you can ask for your users to be eligible to uh to have the attestations and as the attestation is a zq1 you don't know who is the user in

with this attestation so the vote will be fully private so here it's a a vote to to to let self evolve the group yes under maybe you have some questions on and i do have a question so is this available can we can we use and plug our apps on this monitor when you yeah so we are going to be at the hackathon at the end of the week so you can make a project on sysmo we will be really pleased for that and

you cannot to our repositories all these open source hi so um i have a question about the the update of the group so let's say for example the the ethereum power user and group yeah let's say that like you publish or a tester once uh and then in the meanwhile uh i don't know you can update it weekly this group source so who takes care of updating the the state of this tree on chain is it the tester itself or is it cismo that does it automatically

so the tester has you have a contract which is called a available roots registry that contains all the routes that are available from a tester and yeah when you deploy your tester so you are the issuer of your attestations you are also the admin the owner of the available routes registry and you can send the takes to update the the route on these contracts so in this example as we are the issuer and as we have deployed the infrastructure of the data system data sources we can we use a real layer to send to

automatically send the transaction and to update the roots yes perfect thank you um right now it's a single source account et cetera right but in um on this so is it sort of an assertion more than any question um do you have you thought about making this sort of a rollup or are not so much a roll up but a layer two in the sense that you'd uh open the pudding of those roots or is that because right now it's a you putting those roots together right so there's a

bit of it there's a bit of a trust for example you could you could um you could imagine a contract that also outputs like the proof also outputs all the accounts and does all the calls like do you own this nfte etc and and verifies that the tree is actually true yeah so so what we can do very easily to create a smart control a smart contract which is a an incremental merkle tree exactly as the one which is inside the tornado cache and you could directly construct your or on semaphore it's the same also you

could construct automatically your group unchained directly when you do some operations and it will be fresh data you know and you you won't have to wait for the new update as it's made in this tester um sorry so i'm a little bit new but like um would that be possible because you need to do the post site on hashes so can you do this on chain no right yeah you can you can create a merkle tree and chain and and recreate the root and chain and store it on a mapping it exists and it's easy to do so maybe there is other questions so

so may do do you have some ideas for groups or stuff like that group of accounts i see enrico you you post a tweet about idea of groups of accounts or stuff like that okay it's just a question maybe something that um i'm not sure about that the when you're generating uh attestations um it's um 11 55 znfts um when we are deploying it's automatically on l1 or we can choose to deploy it on l2 for example so for now it's in polygon and we are using earlier our own relayer

to relay transaction for better ux for the product because it's it's very difficult for the user to switch between its second destination account to have matic and stuff like that so we think with l2 season the the the price of the transaction will be cheaper and cheaper so it will be uh on yeah an l2 major in italy but we will also deploy them in the main net but now it's only in alpha so our contracts and our circuits are not audited yet so yeah it's really an alpha so it's not

the main net you have to uh update the merkle route every time the group is updated currently is that right yep yes is there is it have you thought about or is it even possible to use like um um something like ceramic where the the root hash or like the hash could stay persistent but you could go to like a data layer to retrieve the updated state so what you can do is you know verifying

an update of a merkle tree directly inside the snark and you could update it like that so more frequently you could even let users update the mercury directly by proving their world updated into the snark and update the root but we we didn't develop that for yet but maybe in the future we will see but and for ceramic i don't know how you are going to prove that you well computed the merkle tree so is

no yeah it's finished i mean uh i yeah i missed the beginning as well but like um you asked for like groups so are you for example working on proving nft ownership i guess so right because you mentioned token gated skilled and collaborate etc like yeah so for assets for now we are more focused on historical data and what we can do with all this historical data for assets we have different ideas but the fact is that uh you know you don't want it to be civil so

what you want to do is so what you can do is verify if you have for instance a tank during one week and update your tree every week so it will be cb resistance but there is different other ideas as you could lock your punk in a smart contract and with this locking you could do a lot of different things so for instance we are just we want to to see what developers are going to do and we have our ideas but we we don't want to start for that so we want to do it with the community right i'm sorry unless

i mean i for a project i've i'm quite interested in these types of topics now and so it's very nice that you guys are here and presenting this work if i need like i'm assuming that at some points you need to write your own circuits as well as is possible like are your circuits public and can you fork them and recontribute them or how do you see the user workflow yeah as they open source too so you can see you can change it um so hydra s1 is s for single source because we just verify one source but we could have a m1 which is a multiple source accounts and we could verify multiple stuff in different source accounts and aggregate

these facts inside the circuits so it will be better for privacy so if you want to do it and the arkansan you are welcome so does someone read the doc that's this mod that i or have questions about the dog or stuff like that okay thank you [Applause]