HOPR - a metadata private layer0 for the web3

Transcript

hello everyone thank you first of all thank you all for coming here so as sebastian was saying so i am a cryptographer and uh for the last few months i've been working with the harper association analyzing their protocol and today i'm going to talk to you about my findings and what is actually this layer zero privacy protocol does so since we are in city of love so i'm gonna give you a simple example of a love story it's not romeo and juliet it's a different story so you all can follow through and understand what's happening and how this communication uh goes

through harper in a private in a private way so we have alejandro who has a crush on zoe and he needs to send her a love letter anonymously he doesn't want everyone to know about it so he asks few a bunch of people to help him to send this letter so we name them betty chow dimitri and they send that letter and then they get that gate that they get paid for that so just for the context we use names of people here just explain the story and make it easy to under to understand but in real life we're actually using anonymous nodes and no one actually knows the other one and who uh who actually sent that message and who actually receives it so to start with

let's talk about data privacy issue so privacy we all hear a lot about privacy and how important it is how important is data privacy metadata privacy but why actually is that important so we think of data as something that identify people so something that's um uh like for example name country address everything that's uh that's about us about the the hospital record any any type of information work all of that so there are two types of uh of information we have data and metadata and basically metadata is data about data so you might think of it as something not that important but it's actually very very important

and there are big companies big corporations who actually understand that value of that metadata and use it in different ways sometimes it's not harmful and sometimes it's actually uh harmful so let's take an example of two people communicating so as i said alejandro and zoe so they usually use um direct connection between them but because we we are in the 21st century these for these people to communicate they will actually use different platforms like facebook instagram all these different platforms which we call as third parties so these third parties will help these people communicate however these third parties will have access to all that type of information

like i said address for a list of friends pictures all that sort of type of information but can we actually trust those third parties or maybe they can be hacked or whatever we are in i guess since you are in an ethereum conference you basically understand the value of decentralization and not trusting third parties so you must understand the value of this now why metadata must stay private like i was saying so does anyone really understand why that is important so just think about it your ip address is actually metadata think of someone who actually knows where you live

where you send your where you stand your transaction from where you buy where you're sitting when you're by your your if where you sit when you have where you are buy your your bitcoin all of that sort of information can can can that be dangerous and uh trustable to for other parties to know about that so metadata says a lot about human beings so uh it's highly valuable for advertising companies uh because they use it for to send advertisements for people to send for for example to buy products and all that uh which not exactly is harmful and when it's not collected it's not that harmful so you

think of it a dress and someone else has sorry for that so when all that data is not collected together it's not that harmful but think of someone some entity has all that data together it can understand your behavior it can understand everything you're doing and control your behavior which is very dangerous and metadata actually has less legal protection than data and it's of course it's a huge a huge power over behavior so

what is the solution so in harper we propose a solution uh using different entities differently layers and we call them multi-hop so multi-hop routes so instead of sending a direct message we use multi-hops to send that message so think of it as a direct connection like this however so we want to of course to unlink sender and receiver and we don't their identity to be known and we want these people who help and these let's say relay nodes who help doing so um of course relay and make that unlinkability and not get that link which is quite complicated because we have

then we have two different issues the first issue is third party like global passive adversaries let's say for example governments or any adversary who has control over the whole network can see everything that's happening over that network so even if there is no direct communication between one party and the other still having that multi-hops can make us go through the whole path and find actually who sent a message to whom um so the solution is using mix mixnets so mixnet means that we're instead of sending a direct message we're mixing it into the into different directions and so instead of sending it

from a to b to c so we're mixing that and putting it in a black box and then sending uh those different messages in parallel and that would make it really hard to link those two messages together now the second problem is those relay nodes that we're actually using they actually know some type of data so they know to whom they're sending they know the address of the receiver and we don't trust them either so the idea of this is to actually make no one understand more than they need to know so the solution to that is the sphinx packet forma which i'll speak about later so basically this protocol helps us hide any type of unnecessary information from these relay nodes

and they would only know the address of the next relay node and not know anything more than that so uh that we will do that by encrypting that data and then only uh and then they will not find uh the address of the final receiver um so if we go through the first solution like i said mixnet so mixnet they protect against powerful gpa so powerful uh adversaries so it's uh that what differentiates them from tar i don't know if you ever use tor but that's something that makes mixedness better than the better than tor because tor it only protects from local adversaries and if someone controls the whole network they

cannot protect over that so it links via packet mixing so packets are being mixed so instead of sending a message from alejandro to betty and then from um for example chow to to zoe so these messages and packets are mixed inside of black box and then they're sent afterwards which make it really hard to understand who sent a message to whom so you you see it you could it could be like a simple example but when you have a big network then it becomes really hard to track these messages so we add to that basically we unlink these messages and then we add the

delays and cover traffic so what i mean by cover traffic is that think of the messages that we have is are in yellows so these packets and then everything is blue is basically cover traffic so cover traffic is just basically random noise that we add to the network which makes it hard to track the messages so when we add noise it just this random noise will not allow us to track whether message message one went to destination two or went to destination three or four and then we add delays by adding those delays it makes it also hard to uh to do attacks on the network and to know if the message was sent at this time was it actually delivered at the at the

different uh time or was it delivered right after that so by doing that we uh provide a larger set of anonymity uh and of course make it uh more secure and private and like i said imagine it as a big network so when you have a big network and you're having all these nodes doing uh cover traffic and all these nodes helping to send messages then we uh have more privacy to into the network and it's a decentralized no decentralized network of nodes which are anonymous and they don't know one another in this network and they basically just relay

packets now to explain what is actually the sphinx which solves the second problem meaning that relay now should not know more than they need to know it's actually um it provides onion encrypted payload so like i said in tor so instead of sending a message we encrypt it in an onion um in an onion-shaped way so you have layers of encryption and each relay note actually has one key to decrypt one layer so until it arrives to the fi to its final destination and then it's completely decrypted and the message can be read by the final destination so that's something we have in the sphinx and then packets basically are indistinguishable from one

another and they all have the same size this way we cannot conduct any type of attacks based on the size of the packet so let's say if a message has this size and different message has a different size then of course it's easier to track down these different packets but because we pad them all to the same size and it's harder to track them down and also we uh use a header that heather we send in it's a different type of information like the address of the receiver which i'll explain uh later and it will be encrypted so this is how this things packet format looks like so we have a header and we have an uh onion encrypted payload where the actual

message is and in the header we have three steps the key derivation encrypted routine information and the integrity tag so the first one we mean with it is that there is a key derivation process between the sender and every relay node to extract a shared key between all of them that shared key will be used afterwards to encrypt rooting information so each relay node when they receive that written information they can decrypt one layer and then they send it to the other uh to the other relay note and in that routine information there is the address of the final receiver of the payload um yeah basically the the packets so uh when uh so this means relay notes

cannot know that address until it arrives to final uh destination the last relay note will uh know that it's sent into the last uh uh to the final destination and then the integrity tag basically it would allow us to assure that that header was not changed at any point of time but i by any relay node and basically the same message that was sent by the sender it stays the same and basically the payload which is the actual message is also encrypted uh the integrity is being encrypted by um a lioness encryption method which i will not go into but basically we cannot change that message

at any sort of time and if it is changed then it just becomes a random random data that cannot be readable so the key derivation process as i said is basically just normal diffie-hellman process that goes offline between the sender and every layer so that's very let's say the first three layer and then using betty's public key and then the public key that alejandro wilk will have they will create a shared key together and that shared key will be used to blind or let's say encrypt uh the routine information and that this process happens with every relay node in in in this chat and this in this network let's say in this

channel where the message is being sent to packets now uh okay let's say now we have this privacy protocol now we can guarantee that messages cannot be readable we cannot know uh we cannot link the sender to receiver that's cool but as i said it's something similar to tor or maybe to other projects in the system but however of course there is some different differentiation between tor because it doesn't protect from global adversaries but there is also a different uh issue incentivization so in if you ever used uh a tour note i don't know if any

one of you has ever run a turnout but why would you i mean you're not paid for it basically you're just doing it because you believe uh in privacy and you're doing it but you're spending your own money so and in tour basically uh it doesn't it hasn't scaled for the last few years uh because basically the problem is we do not incentivize these people to actually transfer and create these nodes in the network which will increase the anonymity sets to be used in the network uh so we are a believer that tor is a great project but we think that it can be definitely improved by adding incentivization and paying

these people who are providing this great job uh of course so we need to add incentivization so why would uh hey we say alexander's first but again like i said they are not his friends it's just for the story so why would they transfer the message so they need so we want to create an incentivization system uh that's censorship resistant so it's completely decentralized let's say we're using it on ethereum for example and it's efficient so in layer two so we it's layer two protocol so it could be efficient and also it's privacy preserving so we use these uh payment channels to do so

which i'll explain later on how we'll use them now our approach basically to the incentivization system so first of all nodes should only get paid if they actually did a job so they we should not pay these nodes without them doing any job so it becomes harder to attack the network when nodes actually provide a value and do a job and then they get paid so the second thing is that we need to verify if they actually did a good job or not if the of the final receiver actually received the message untucked or not so this verifiability of course it needs to happen

and need this to happen and it's that the payment needs to happen using um let's say a trusted third party emulated trusted third party like something like ethereum so it could be transparent and everything that's happening on that network we can see it is that when people actually provide a job that's verifiable then they get paid for it and they get they don't get paid if that's not the case so we use uh our proof of relay in hopper so where of course we have proof of stake proof of work so we have here proof of relay so when you prove you have done relay in the network then you get paid um so how does this happen so let's imagine a note so i am a relay

node and then uh i want to get paid in this network of course so i would create um a key basically as i zero uh which is not this not the same key that i showed earlier in the um in the key derivation parts that basically was the master key that's used in the sphinx header and then we create different sub-keys each sub-key will be used for a different case and of course we don't use the same key just because it gets hacked for example these sub-keys get hacked or they get revoked so we need to have a sub key for each different case so we have a sub key that's created by

the first three layer then the that relayer would receive another key as i plus one from the next downstream node so the next node after them and that actually the key would prove that okay the next node actually received the message so when the next node receives that packet they send back this uh this value which which then we compute uh a response to uh to receive a payment so that response will be a challenge which i'll explain later which basically would help these nodes respond a certain challenge to get paid in the network for their relay and service

um so um basically then the downstream node can verify the integrity of packets and payments information beforehand in handing back that key help so basically the next downstream node would verify that it was untaxed using the integrity tag and then sending back that half key and of course this way it would allow us to make sure that the packet was uh transferred correctly and of course uh not by not receiving that value from the next downstream node it means that the packet will be dropped and that relay node cannot receive any payment for their service because of course they didn't receive from the next downstream note a

validation for that so this is uh how to visualize this to understand it even better so the same characters that we used before so basically alejandro and zoe in order to connect so when the payments cannot be uh redeemed by anybody unless they receive we send it we use it as a key so basically that's a half key that's sent by the next time stream node to the one before and then payments can be redeemed by the one before okay now um talking about these payments so the idea is

of course we want to pay these different relay notes for their services but we don't want payments to leak any media metadata and we don't want it of course to um to be costly so that's why basically we're using uh um payment channels uh because uh and using probabilistic payment channels uh because basically that would allow payments to be uh redeemed after some point of time so not every payment will be redeemed after every relay that's being done just because we're using probabilistic micro payments and it would mean that not every relay would allow a node to

access a payment which means it's only probabilistic that would incentivize them to continue relaying basically and in order to get paid so let's say you some you send a hundred packets so from those hundred packets when you when some other node would relay them they would only get paid let's say for 10 or 15. so since they don't know which one will actually provide a payment or not they will just continue relaying that and payments will be redeemed at the end so that will not be costly of course unchained um now what i was saying uh i said uh as i explained it later uh before

sorry uh as a half key that's sent by the next downstream node here we explain it as an acknowledgement so the acknowledgements means that okay i have received the package and i send my acknowledgement to you back now you could uh redeem the payments the problem is um in proof of relay these acknowledgements might lead to dependency graphs so we have let's say a b c one c two c three a wants to send uh three packets so he wants to send to c1 to c2 to c3 so he sent these three packets b is only a relay note in the process so basically c1 will send back the

acknowledgement to b that acknowledgement one that they have received the packet c2 will send also c3 will send also let's say acknowledgement one was not received by b so that we have packet loss for example here uh uh so acknowledgement was not received by b or maybe acknowledgement 2 was received before acknowledgement 3 was received so here we we have this uh problem that we ins so in case packets uh have our lost or we have a different order of receiving acknowledgements than the order of packets

so we need to provide a solution for that the solution for that is basically using um the what we're using in hopper uh basically these uh and the independent so acknowledgements are completely independent from one another but as well if you uh the it's um it's the addition so acknowledgement three will have the payment for acknowledgement to an acknowledgement one so even if packets uh if the if the acknowledgement is one was lost by providing acknowledgement three and even if two was received before three three when it's received it has the uh the addition of

all the values of uh payments that should be received by these um packets now it's not charging okay can you can you go to a different slide maybe was this the site that i was going to

present can internet issues um okay so now that i talked about these uh acknowledgments now we have uh two other problems i hope everyone is following a lot of issues right a lot of problems are we trying to solve so two problem is that um the upstream node can try to cheat to make every uh so here we uh

we introduce a different concept called tickets and tickets are basically just tickets for payments tickets will be uh later on uh uh redeemed as payments by these different nodes so what if the upstream node actually try to cheat and make those tickets always lose tickets so make that relay note always losing and because i said it's a probabilistic payment and not every payment provides uh and not every packet provide an actual payment so in order for us to prevent from that happening happening we introduce commitments so a commitment what does it mean it means that the upstream node uh it will ha create this random value

that it will uh need to use to calculate uh the the winning uh so whether whether a ticket is a win or not and that value it will commit it so it computes the hash of it and commits its own chain so it means that it can never change it afterwards so when it can never change it afterwards which means that it can never change whether a ticket is a win or not uh after after it committed that value the second issue is that the downstream node so the node after that could try to cheat and make every ticket a win so in order to prevent from that happening we introduce a different concept called hints and

basically makes the sender you remember that the sender creates shared keys with every uh every node in the process every little node so basically that sender will actually will provide that shared key from the next downstream node to the node before that as a hint so it will compute it uh uh it will provide it not directly but it will be multiplied by a generator of elliptic curve and that hint will basically be used to make sure that the value cannot be changed the value of acknowledgement that is sent back cannot be changed which means the winning whether a ticket a win or not it cannot be changed basically from

neither the upstream nor the downstream node so it could be hard probably to understand but that's basically what's happened so we have to we have the commits the commits and the reveal process so when committing that value uh basically the generated value to to calculate whether a ticket is a win or not so it's committed on chain the entropy um and then when uh a node needs to reveal that and to uh redeem their ticket to win uh of course uh to win let's say hopper tokens so basically they would reveal the the sender the upstream node will reveal that committed that already committed value

um and then tickets will lead to a win if this is this is the case basically the hash of that commitment of the previous commitment with the response that i explained as the half key of the relay node and the half key of the next downstream node so basically if we provide the previous commitment with that response and the signed tickets basically the ticket needs to be signed by the sender of that ticket so if this hash is less than the winning probability then that ticket would that would lead to a win now the next thing as i said the hint which would uh

make us uh make the downstream node not be able to cheat and make the ticket always a win so basically um we the sender will provide this value as i plus one multiplied by a generator of elliptic curve that we're using so that we call the hint so it's the this the value that we're supposed to receive from the next downstream node and then when we have that hint basically we can response to a challenge a challenge basically is the what the value that the relay node is providing and plus the next downstream node uh providing all multiplied by the generator so if we have the hint basically relay node will only provide their value

multiplied by the generator and do the addition of that uh and that it could respond to a challenge if the challenge cannot have a response or the response doesn't match with the already provided hint basically this packet gets dropped and will not be sent afterwards to to other relay notes now going back to the sphinx packet format like i said in the header basically we have the payload and we have the header in the header i said we you we send the destination address we send uh als we we also add some padding to make all these packets have the same size and we also uh add so it's a modified

version that hopper is using of the or of or the original sphinx so we add the hint and the challenge values to uh the sphinx header so this hint and challenge that i explained and basically there is a hint and a challenge to every relay node so every relay node when they receive this header they will decrypt they will unblind this header uh basically to know what is um what is their routine information what is the address of the next relay node and basically the hint value that they would have for the supposed to be value that they should compute to solve the challenge if they cannot solve the challenge they will drop the packet and the packets cannot be sent uh else afterwards um and also there is

an identifier which is basically we're not currently using our hopper it's used for um a single single reply blocks which is uh in things but we're not currently using in hopper probably in the future uh okay now explaining basically the tickets like i said so ticket has to have to be issued by someone basically the sender of the packet so the sender of the package will issue number of tickets in in this when they create a channel of communication between sender and receiver they will uh create uh they will generate amount of tokens um of tickets sorry they will sign those tickets

and then those tickets get be validated afterwards by every relay note and then when every relay node presents a response and that response uh actually matches with the challenge that is they supposed to solve basically that ticket is being validated and the packet is not being dropped and then when they want to uh redeem that ticket afterwards to get a hopper token then of course they they provide the acknowledgement from the next downstream note and they solve that challenge and they get back their tickets so if you see the acknowledgement is sent for example from d to c so it's from the next downstream now to the

uh to this node to acknowledge that they actually have received that packets so another issue also so what if we double spend tickets so what if these tickets can be spent several times by every relay note so in order to solve that we basically introduce ticket index so which are stored in a smart contract so this ticket index will increase by every time ticket is being redeemed and basically tickets cannot be spent uh twice or several times and also uh other um current limitations to the protocol

so basically the current payments um uh payments protocol that is used in hopper leaks the position uh in the relay chain so um in order to send payments so basically the first three layer here in the example let's say would receive three hoppers and then the secondary layer would receive as two hoppers and the third one only one hopper so not all of them receive the same amount and basically by having that different amount will their position in the channel will be known so we know that the one that received three for example is the first three layer the other one is the second and the other one is the third so that can a solution to that this amount could be obfuscated for

example um another limitation is that downstream node might not hand back the key so the acknowledgement key a solution to that is just basically closing the channel and and blocking uh redeeming those tickets so uh that node will not actually win anything so because when they don't send that key back basically they're not going to be paid afterwards for relaying packets another limitation is that uh anonymity sets uh by using all of these relay nodes has to be uh uh where has to be bigger has to be bigger and we need to incentivize more and more nodes to join and we need to create a healthy topology and basically uh we're adding cover

traffic allocation to the network so the more cabbage traffic we have the more the uh the more anime uh um anonymity set going bigger and of course it's getting harder to attack such a network uh going back to our story alexander and zoe basically they um they have a happy ending so she received his letter basically they fell in love the others had tickets to go to rihanna or whatever artist you want to go to or they want to go to i am a fan of rihanna so they went to they went they gained concert tickets and everyone is happy set's cool uh okay so i take this opportunity

because i'm presenting today to tell you that the hopper's taken program has actually started today on the 20th and people can unlock uh there's the stake in the in the hopper protocol and basically can redeem rewards starting from the 27th of july and we also have an nft program which will boost the base of stake in so these uh people who will stake they will gain nfts so check it out go to our website check our medium article which i'll show the link about to understand more how our staking program works basically there is no picture of me

sadly but i'm here basically so it's a small team 19 members uh already already in the team and we are all over the world um well not really all over but yeah anyway maybe all over continents except africa sadly okay so with small team we are believers of privacy uh we are here today to share with you uh our our project and uh looking forward to get questions from you to to get people to interact with us to understand more about what we're doing [Music] so you can find the link to the yellow paper basically the technical paper of

the protocol on github so it's not completely finalized but anyone can see it you can also see the stake in program hopper speaking program on this link and of course you have links to the sphinx packet forma and also to mixnet if you're interested if you're also interested in our project you might go and see tomorrow my colleagues talk you so she will be talking about our dao experiments in hopper so how we use dao so that will be tomorrow uh 6 20 p.m uh in the same room so go there to understand more about the dao that we're using and that's it thank you so much

do you have any questions [Applause] hi harry from nem so hi um i don't know where to begin let's start with the cover traffic so your network does something called free routing right so you can just choose your route as long as you want and that's a kind of known uh not super anonymous design

and you say well we can fix it using cover traffic now unless i'm mistaken as with that design as your network gets larger the amount of cover traffic has to continually increase right so let's say i'm sitting one real packet to be kind of anonymous i'd have to send 10 uh packets let's say i send two packets it's like non-linear right so it's gonna go to like 30. do you see any other ways to deal with that problem of scaling um i mean i can leave sebastian answer to this question he's basically the one working on cover traffic

yeah so i mean you're right right in a naive implementation hopper would just distribute like this thin traffic now the thing is that's not what we're doing like the cool thing about what amir presented is we didn't talk about what topology were using we didn't talk about the traffic allocation so effectively you can run very much like a layer topology on top of hopper you could run effectively on top of hopper you could allocate your traffic to as many nodes as you need to receive sufficient traffic that you can obviously still afford because you know traffic has to come from somewhere and lastly on this topology you could even build like super crazy stuff like

loopback traffic all of that is something that you could do with hopper being basically a mixnet toolbox for you so we didn't talk about the details here we're gonna experiment with various designs for it but yeah basically hopper is open to implement whatever works best thank you any any more questions okay then thank you everyone

um and happy conference and welcome to paris we are distributing t-shirts um next to the room so you can get some yellow t-shirts if you're not tanned as me so it's not will not look beautiful but whatever okay so thank you so much enjoy your stay here bye you