Whiteboard Series with NEAR Protocol | Ep: 46 Dr. Sebastian Bürgel from HOPR

Captions as YouTube publishes them, usually machine-generated, so product and people names can be misheard.

1. 0:07

   hello everyone this is ilya from uh not so sunny zurich but it was really nice mountain view and i'm here with sebastian founder of hopper and we're going to dive in and learn more about it do you want to introduce a little bit about yourself and then yeah sure thanks first of all for coming to not so sunny zurich to talk about privacy here yeah um sebastian founder of oper we're as we say changing data privacy for good

2. 0:37

   what we're doing specifically is a metadata private data relay network that provides data privacy on a transport layer so bringing data from a to b okay uh maybe let's dive into the problem first so can i understand why do users and developers care about this sure so let's take for example we have a data exchange between alejandro and zoe right so we have our first protagonist

3. 1:07

   alejandro and for example alejandro might be using emitter mask wallet right and what do we actually do when we submit for example ethereum transactions right so we send it to somebody else in this case to zoe and zoe might be an rpc provider and what is kind of interesting is that today when these two exchange data they also make to each other visible their ip address so for example in the case of a

4. 1:40

   minimized user and an rpc provider the rpc provider sees where you live they can link your accounts and all sorts of other things so we want to solve that now interestingly people sometimes say hey you know i get privacy by decentralized technologies by for example running my own node but interestingly enough running your own full node is not enough because you basically just have the ip

5. 2:05

   address of that node which becomes a synonym of your wallet's ip so yeah basically what what people sometimes then do is you use a vpn right so in our case maybe we have uh chao as a new actor in our model here and um you know we just relay everything we had showed so far so good but i guess as we know well with vpns we're just trusting that guy now with everything right your browsing history and if they know what power you have

6. 2:39

   when you submit crypto transactions which they can now link it's probably going to get even worse than vpns already are yeah so much fun training extracted value vpn extracted value i like that exactly yeah it's like like what if like these guys find out that for example like your transactions which you're submitting like for example to estimate gas price right so typically people just submit this transaction say hey tell me you

7. 3:04

   know what gas amount i should send typical example you can front run the whole thing for nfts d5 whatever okay well i mean if you have ssl messaging here that would be harder to it will be harder but interestingly so many times only by looking at the packet size you can infer a lot of information right and this is exactly what we mean by metadata by how frequently like how big data packets you can still infer a lot

8. 3:33

   so one thing that does better than just a vpn is tor and what tor actually does is it introduces two additional nodes right so let's call this one here betty and then we have one other note over here and um that one is ciao no jon we already got in our story too bad so that one is dimitro and now what you can do in in this story is basically so all our five friends are acting together and you're relaying data packets from one to another

9. 4:12

   and by doing so you are basically not really knowing where data came from where it goes to and who is exchanging data with who so so far so good with tor maybe let's dive into onion encryption which is uh something that is quite typical for for tor here so mentioned that this is probably run by russian federation this is by the united states exactly for example right that's that's actually kind of good

10. 4:44

    right because you want different actors which are ideally you know ideally not colluding no exchange information no exchange of information that's perfect right that's perfect so effectively what we would like to see is that there is a data packet which gets forwarded along the way right and this data packet is encrypted but it's not just encrypted once but it's and that's why it's called onion

11. 5:08

    encrypted multiple times right so we have multiple layers of encryption that are being um that are being passed around so basically when we have the first relayer in our in our chain alejandro he is like encrypting this packet four times betty gets the package he peels off the outer layer of this encryption that's why onion right and passes it on and so on so that finally only zoe can see the data that is actually being sent around

12. 5:41

    so that is on a high level what what tor is really doing and so when you're sending this you actually need to know the full route to your destination exactly so in case of tor um er tor source rooted right so you select the path and this path that alejandro is is choosing is typically like long living so typically something like multiple minutes so that's actually one of the weaknesses so you can look at the packet like let's

13. 6:12

    say i'm the internet service provider of alejandro and zoe i can link these i can basically see exactly how big is the packet here how big is it over there and link these two and if i don't do that just for one packet but you know take these take this long living route that is is persisting i can eventually you know even with not so hard resources find out what's going on good so well not so good that's it yes

14. 6:44

    that's the weakness of twitter just to question like zoe presumably elsa should receive an encrypted message for zoe so yeah what mitro is seeing is metadata about this exactly yes so basically the rightmost packet like it contains the actual payload which is still encrypted and zoe takes off the last layer of encryption yeah good okay so uh how do we get better than that um so one thing as i mentioned like this

15. 7:14

    weakness of the trust assumption of tor is that the first and last node is not colluding and it specifically is the thing that we are wanting to improve and maybe one thing to mention because we'll pick it up later on is the economic sustainability of tor tor's been around for longer than bitcoin but tourism been growing really for the past at least half a decade so we see tor has under 10k nodes and

16. 7:40

    tor has you know under 2 000 exit nodes so this last one which is of course a very touchy one because it gets accessed to the wide internet so you know bringing economic incentives to that game is the second major uh difference here so how does that work what uh we do in a mix net like hopper is actually there's not just a packet coming along this route here to chow but there's actually multiple other packets that are also being sent to chao

17. 8:11

    and chow is sending these data packets out also to to other people so what happens there is actually you receive a packet you cash it for a short amount of time while you're also receiving other packets you transform them so they look different between incoming and outgoing packets so you cannot link them and you mix them up and send them out in a different order and this combination of like transformation of mixing and having this artificial delays

18. 8:43

    is actually what brings significant better privacy than what you have at tor because only if you have like access to that machine do you know which packet corresponds to what so what we call this global passive adversary you know either your internet service provider or like the you know three-digit agency of your choice will not be able to find out which packet corresponds to which and they cannot link incoming and outgoing traffic good so that's

19. 9:16

    the the fundamentals of a of a mixnet um yeah no yeah i mean let's let's actually then go to uh the second thing which is uh the weakness of tor which which we mentioned in the beginning is this linkability by just observing like not even caring about all that but just mixing packets if you observe here and you preserve over there so effectively what we're doing in hopper is packets we make packets look

20. 9:48

    indistinguishable from one another and how we do that is by basically either shrinking them or padding them all to the same size and interestingly it's not just about the packet itself but also about the header so the header gives away usually a whole lot about what like who you're communicating with and so on again worst case you know you can just see to whom is this packet addressed

21. 10:14

    now that is being protected by using a packet format that's called sphinx it's used by the bitcoin lightning network and by a bunch of other projects so it's it's made for such mixnets and it's basically called sphinx because we don't just have this unencrypted payload in the packet but we also have a have a header that has a bunch of a bunch of information in here for you know relaying that relaying that packet

22. 10:47

    and we augment that in case of hopper by also having like some some payment information that we that we append to it now um the first step maybe to uh to realize for what's going for what's going on here is we have like some some key material here so there's some some alpha a key material that is that is um defined by the center of the packet and basically this alpha is an offline diffie-hellman that alejandro is doing with all these

23. 11:21

    downstream notes so effectively by knowing their pub key alejandro is choosing a is choosing a secret and his secret x um he does an elliptic curve multiplication times g times the base point here um yeah so that is like the the immediate material which is then multiplied with the pop keys of these uh of all these notes and thereby you establish a shared secret and this master secret we will i

24. 11:54

    mentioned because we'll get back to it many times we will use it to derive all sorts of keys good now um so this is this is the first part of the of the information of this packet and um there's other stuff as for example you need some some routing information right so that's that's this beta in here which tells basically betty well where do you send this thing and some other stuff and finally there's an integrity tag in here which is just

25. 12:27

    allowing you to make sure that nobody altered the packet while it was in transport but isn't routing information responds in this case no in this case not because the the onion really is only the um is only the encrypted payload and what is interesting is how do we protect this header such that you cannot in transport extract stuff from it and actually sphinx does something pretty interesting here so if we look at the header um

26. 13:00

    this header contains information like when alejandro like formats the packet for all the downstream nodes right so they all need to be able to process this so in a naive implementation you could basically say okay well betty just pulls out her information and passes on the rest but that exposes some metadata information in the header because you could just observe how the header shrinks and you know where you

27. 13:25

    are in the relay chain so what sphinx actually does is it takes all these these pieces of the header information for the individual nodes and that is then blinded so it is first blinded with a blinding factor that only betty can derive i mark it with this hatching here so basically only betty is able to like remove this hatching right so only betty can can remove that then there's a second layer which can then only be removed by ciao so that's everything from here downwards

28. 14:05

    generates because yeah yeah like each layer encrypts exactly exactly it's not part of the payload but it's following the exact same principle exactly like you say so basically you repeat the same thing right so like this first part can only derived be derived by betty the second by chao and so on so we have like a bunch more hatchings for each of the of the notes that participate there and now what what sphinx basically does is like when betty receives this packet

29. 14:36

    she removes this and she pads then um in the end like some kind of noise data which is indistinguishable from the um which is indistinguishable from actual information and what that means is for us as outside observers we can tell like what's going on right so she would just remove this part here and the pen decided so that are some of the pretty pretty interesting neat things that

30. 15:08

    sphinx is doing to protect metadata in the header all right um then i said the second kind of interesting thing of hopper is that um we want to bring in incentives so what we want to do is that you know child for participating in here is receiving a payment but for doing that we don't want to reveal who's spending exactly right so there's a bunch of things that could go wrong so in a naive version it's like you know especially maybe bitcoin people

31. 15:47

    say hey you know you can solve all of the world's problems with bitcoin lightning networks solve everything for example right but so one thing like in a naive example even like on chain right so in a native example what we don't want is we do not want to see okay first like you know alejandro is sending money to betty betty is sending money to child child sending money to dementia and dimitri desiree right so that one

32. 16:10

    you take so even better exactly so that would that would reveal everything that's going on here so that's bad how do we hide it by going l2 basically so what we have at hopper is a payment channel network so alejandro has a payment channel open to betty betty to child child dimitri and so on interestingly we do not have an incentivization between dimitra and zoe because we say you know zoe is part of a service provider who has an inherent interest to receiving set data

33. 16:41

    so maybe as a quick recap what does that mean it basically just means that you commit funds which can then be released by the other party with off-chain information which is being passed along so effectively alejandro is staking some hopper token in a payment channel towards betty betty is taking upper tokens in a payment channel towards ciao so if you want to think like ultra high level it's a little bit like pys where you stake money in order to secure a network just in our case it's not an l1

34. 17:13

    right we don't secure a blockchain here this is used to incentivize packet information which are being sent around yes and then after we have established these payment channels they can be used for sending actual packets around and uh one interesting thing is that basically alejandro sends like a locked uh a locked amount of money to to betty here so it's locked up because like there's a free writer problem in a naive implementation here so

35. 17:50

    the free writer implementation uh the free writer problem is what if betty just exactly she just says hey thank you and off i go so what we bring in here is to solve this free writer problem it's basically a a key sharing mechanism so this money let's say initially it's like three hopper realistically it's less but just for you know explaining this betty needs two pieces of information in order to unlock this payment so basically she needs two keys

36. 18:32

    the first key she can derive herself and the second key will be passed on to her um maybe let's remove some of some of the arrows otherwise it gets a bit messy um so the second part this the second key gets delivered by child to her so this second key half here gets delivered and those two together um are giving her the information for how to release that payment of the payment channel

37. 19:12

    cool so let's maybe dive one layer one layer deeper into what's actually happening here so i mentioned that actually we have this we have this key information out of out of the sphinx format so this alpha which we then use to derive further keys so we have a master secret which is it's not just this but it's actually we have an alpha zero which is derived for betty with an alpha one which is derived for chao and so on and um

38. 19:45

    basically this alpha is it shouldn't be the same because if it was always the same what could happen is that maybe dmitry down there is extracting some of that learning about the alpha and maybe dimitro is colluding with one of these gpas this you know bad guys who have network level overview and can de-anonymize information from the network so that's why these alphas are basically iteratively changing so every

39. 20:19

    one of them is calculating the alpha for the next party which also then ensures that the path is being followed because if anybody else would like you know forward this packet to somebody else they wouldn't have access to the private key of that party and therefore they could not modify the alpha so what we have here is actually um the secret that we're using here i will call um s1 and that is the one that betty um

40. 20:50

    derived herself right so let's call it s1o and the second key half that we get back from chaos or ciao is basically sending this this key half is um s2 and it's effectively an acknowledgement right so betty is taking the packet passing it to ciao and charles as an acknowledgement coming back to to us with this key half um good so and what we then want to validate because that is something that needs to be validated by our smart contract is actually are these values here legit right so we

41. 21:31

    don't want betty um exactly right and it could be two things right it could be she made up this thing because she's not actually betty or it could be that you know she made a gap acknowledgement exactly yeah so how do we do that well we do it by basically doing an elliptic curve multiplication so again we multiply this here with some base point again it's a plus here and effectively this value is something that has been signed off by alejandro i'll i'll get to that in a in a second

42. 22:10

    in detail um but for now so we have we have basically this this secret value here the sum of s own plus s acknowledgement which betty needs to provide to the smart contract but um now basically um another thing could happen right here so what what could happen is here that she doesn't know if she got betrayed so before she does the actual work she wants to know well is this stuff actually legit

43. 22:42

    so what we actually have here so we can basically just uh re rewrite this this equation here so this is s on times g plus s2 the acknowledgement times g and this value we actually provide in the header ahead of time and we call this value here actually a hint and this hint is actually part of the beta which we which we have up here now what what is this what does this do so we have this as own which she can derive herself and we have this value

44. 23:31

    from this together she can validate if the payment information of these two skis exactly that's exactly what we what we wanted to what we wanted to establish here um and she can do that before she get that stuff from the smart contract uh sorry before she got it to chow and check with a smart contract hey is this is this legit or not and then everything is fine um just a little nuance basically we have this this elliptic curve multiplication

45. 24:02

    which unfortunately you can't do in ethereum so there's just like this very relatively silly easy verify so you can kind of abuse easy verify um actually to do an elliptic curve multiplication which is a bit weird but yeah you have to work with what you got all right so so let's maybe like just kind of mechanically right so let's say i'm the alejandro i'm just joining the network so the first thing i do i go to smart contract and i pretty much commit to

46. 24:34

    lock some of my funds with betty like i explicitly on smart contract revealed that correct i i like specifically to betty specifically to bet yeah okay why because we want to of course avoid double spends right so that's why if you would commit to anybody you know maybe one of these is your friend and you're just you know extracting funds so so if we have a smart contract right so alejandro came in

47. 25:05

    with you know storing like let's say 10 for betty yeah now and a bunch of others right so probably he wants to open a bunch of other payment channels as well right so also when i was ciao there was um and so then when when they're actually constructing this message they are kind of committing like actually on the smart contract none of this is so far stored on this no i'm more i'm more thinking like this like three hopper right like they're

48. 25:58

    committing based on the route that they consider to take so initially when you open your payment channel on a smart contract you're committing something only on an individual edge base in this network so you're committing only money to the edge of alejandro to betty alejandro to chow and so on but what i'm saying like when i'm sending this message i need to put some like i'm putting the amount of here yes this amount is this amount that you send is committed to this edge at first

49. 26:29

    and then the what happens is actually betty will commit to forwarding funds to chow so what is actually happening is that betty is sending again like a hopper packet here which contains in this case now two hopper yeah so so my question here if i'm committing to three will that reveal that they have a three hops in that case so in the current version of the protocol it does reveal that yes so we're thinking about some numbers to obfuscate this number here right so you

50. 27:00

    could like obfuscate it up or down um that is currently a version that is that is revealed that's correct all right again i mean presumably you can have like some zero like if if if this smart contract actually had uh was the zero key right yeah then you can just send uh that is true although we are trying to avoid that for now because like we're thinking about throughput here right so ideally we want this like packet transmission to be fast so that's why

51. 27:31

    we're trying to avoid i know zero knowledge stuff is like very hot and stuff but it's very slow it's very slow especially if we're thinking you know you want to send like dozens of packets a second all right so so then um you're still encrypting kind of useful layer so so i'm as alejandra i joined this network yeah first thing i need to do i need to discover kind of as much many

52. 27:55

    nodes as possible exactly in the network all right and so are the nodes registered on a smart contract somehow so effectively if you're thinking about it who would you want to open a payment channel to it you would only want to open payment channels to other nodes who are already kind of committed to the smart contract yes by having payment channels themselves so effectively what you're doing is we

53. 28:18

    are also using the smart contract as a discovery mechanism okay so you're basically going there and saying hey you know what's your like who's there and you do see the pop key there and from that you know to whom you can uh commit stuff all right so they have a pop key which is kind of their their official pub key and then i'm assuming they also registered their id address yep that's correct

54. 28:43

    actually there's the ip address is not there but we have a dht for that but you could as well just store it actually there yeah that's that's totally possible but yeah you can potentially just when you're registering yep yeah exactly okay so then yeah so i come in i'm like okay here's some cool folks um look up maybe the latency for the sap address is fine exactly we're doing a health check so what we're doing is actually um we're trying to probe the network so far the current version which we have is

55. 29:15

    like quite simple like i'm probing it but we're thinking about like some transitive trust or something that's a bit better to get a view yeah that's a very interesting but let's let's put a note on that um just like basic mechanics right so have pub key i discovered some i'm like okay i'll commit to this folks i'm sending so so then i build a route right so yeah how do i build a route yeah so basically what you want to what

56. 29:45

    you want to assure is basically you're the new guy you open something to betty and if you want to build a route you want to find out well where does benty have open payment channels too yeah so you're basically consuming the topology of the of the graph and but the interesting thing is you remember when i mentioned initially that this last hop here is not incentivized so it's basically not a path finding problem but it's more path selection

57. 30:10

    because you know any sort of connection of these guys is possible because your last hop is going to be here disconnected off the screen yeah because you can't go like this exactly exactly yeah we're assuming they're they're like we're assuming that on the tcpip level they are like connectable to one another but that if they don't like your budget let's say you you build a path but the pass is deadly to

58. 30:34

    for example withdrawal yeah and there don't have uh nothing not a valid path not about that so then it would just drop better than right uh actually you would as as you do the path selection like we we basically uh implemented it just a path selection you you wouldn't find that yeah but let's say somebody did send it yeah then it would just it would just like oh like that that thing is not fun that it

59. 30:58

    doesn't work packet drops okay and similar like it better see some from someone who had not opened a challenge same thing and actually another one so it could be that a channel is like other funds right so it could be that you have you know not enough you know if you only have one hopper left in the balance but the packet costs two well you drop the packet also okay so potentially i mean and then kind of eventually the packets

60. 31:23

    can get lost because of this yep uh because somebody saw it didn't top it off exactly so it's basically it's it's kind of similar you know as as packets hop around the internet if there's you know somebody pull the plug somewhere packets get lost and you need to like retransmit and try a different route so okay then yeah that's your turn back yeah so so i like i can generate this hint which is for the next uh next one in the route house actually sorry the hint got gets uh created by

61. 31:55

    the sender by elephant that's right i i in this case is center yeah and then so how um like how is it generated such a child can actually set the acknowledgement yeah so basically the same thing which we which we have done here is is repeating right so basically this uh this key derivation uh which is being done by chao uh repeats right so chow gets the packet so chow again has an alpha which is you know their alpha yeah so from that he

62. 32:27

    extracts this one he gets this one from dimitro he gets this downstream thing and uh compares it to a value which is signed off by the previous um by the by the previous note so what is actually happening here is that part of this payment information i just wrote hopper here but what is actually happening is we are also sending a signature i as betty am signing off on the funds that i'm willing to transfer to ciao which is a signature actually

63. 33:00

    over over these values here so uh over the hint over the amount and and some other stuff that we can get to and uh we're doing that because and it's maybe next problem we don't want anybody here like to modify the amount for example right so we we want um in this case ciao to be able to only extract two hopper and not an arbitrarily much higher amount and since this amount differs like depending where you are in the route and potentially you know whoever send it um this amount is being signed off by

64. 33:35

    betty and then the smart contract is um is basically validating that this hint is matching something that that has been signed off um by the upstream note all right but how is this this uh computed um the hint is basically you know well this this acknowledgement so the ass acknowledgement is not something that betty knows right because yeah but he knows so how does ciao called coincidence so for example he calculated his so he got that judgement and then he sends back after already calculating

65. 34:13

    this he can send the knowledge yes exactly so the packet goes from betty to charlotte yeah i understood first so so he already receives his like s3 arc yeah right um that he gets from dimitro yeah so he goes how does he sound as true what's so basically the the packet gets formatted the entire packet gets like transformed betty calculates the alpha for chao and forwards the entire packet to chow yeah and then the first thing that child does before passing it on is get back

66. 34:51

    with the s to act to betty and ciao extracts this as to ack again by his alpha in the packet that he got from from betty deriving the master secret which was established with alejandro but nice enough chao doesn't know it was actually alejandro from that he is basically doing a key expansion um and from this key expansion he's getting the s2 egg which you know he knows and in that case alejandro new

67. 35:22

    already to send the hint value in a header so so i see so i i actually thought that as to arc actually contained in some way that actually no it's it's actually all derived from the pack and that's kind of the nice thing if you're thinking about it on a high level right so the nice thing is that betty will format will uh forward the packet to chow chow will again check some stuff like is this legit and if yes then get back then send the acknowledgement exactly so this

68. 35:54

    is this is kind of neat and that this stuff why why does chow wants to send the quality that's a really good question um what if ciao is like not not such a nice person and not sending this stuff back um that is a problem but in that case betty would just close the channel because they would just assume ciao is offline so it's the same as if ciao like from betty's view it's the same behavior

69. 36:17

    as if child just dropped the packet and in such a case she would just close the channel and saying you know what like i don't play with you anymore because you never get back to me so i'm i'm not in business with you anymore so even though like eventually like got charged one for one of the messages yes yeah just closed yeah it depends like this this will depend a little bit how we how we see this thing

70. 36:42

    happening in action right so we will need to find out how bad is like a free rider and churn problem here and saying you know maybe once i forgive you but if you do it like three times in a row i'm just saying you know what cut it okay is there a minimum like let's say i want to be a child yes uh is there a minimum limits that you need to have no not really well actually one thing that is the minimum is like for three hops you need like three times the

71. 37:12

    minimum amount of uh of tokens that is required for one packet it doesn't make sense to stay less but that amount is super low so there's there's virtually no no minimum limit so i can register like a million of those you could but there is basically a cost to that right which is the on-chain transaction fee and you block some some capital so yeah you can you but in in principle you could absolutely do it now the interesting thing is let's let's

72. 37:43

    consider that as an attack scenario right so let's consider you're doing you're launching a million nodes here which are all symbols of one another and um kind of coming a bit to the trust assumption of hopper we're assuming that there's at least one honest and effectively mixing node now if it's all you i'm right right so uh what do we do to mitigate that um effectively it's it's kind of hard right because on the one hand we want this to be a permissionless network on the other

73. 38:15

    hand like this is a problem so in the in a path selection um that is implemented you are literally defining who do i trust trust is something very subjective so we make it like very easy for people to implement their own path selection strategies the one that we have implemented so far is weighing the uh probability of selecting a note with the total stake that they have staked so effectively yes you could like you know launch notes but

74. 38:47

    i would only select one of them once in a blue moon so that's how we defend against that one okay so it is kind of ish proof of stakish yeah it has some it has some properties which are very similar to pos systems yep okay there's actually some more problem that i think we haven't talked about and that is the problem of um i don't want if i'm in this relationship right off between betty and chow um if i'm ciao i don't want to be tricked into always receiving losing

75. 39:26

    losing payment information right so in just not winning something and another thing that that we're doing here is uh we're actually not settling this every single time what we're doing is probabilistic payments because again like in this scheme in a naive implementation if you have a hundred percent win probability you see okay betty is claiming something on change house claiming something on chain dimitro let's assume this blockchain is like super fast and stuff and doesn't cost us anything so

76. 40:00

    exactly i i have some in mind which are also evm compatible so um the thing that is kind of interesting is in such a setting uh we we really want to make sure that this um that this can't be tricked so what we do is probabilistically you would win once every millionth payment only you would receive a payout so it's probabilistic now if we make it probabilistic it solves some issues in a it doesn't

77. 40:30

    disclose the path to the general public by on-chain information two we save a bunch of time and money because even the fastest blockchains are probably you know not going to be fast enough for kind of packet relay networks so it's kind of two birds one stone but uh what we want to make sure is that this probability can be tweaked and it shouldn't be tweakable from two sides betty shouldn't trick ciao

78. 40:55

    into char always losing child should not trick betty into um into always winning the payout and what we do um for the for for the one side is basically on this smart contract that you have here you are basically committing a pre-image and this pre-image is not known to the issue of this we call them by the way tickets so what you're issuing issuing here is not a payment like payment is something you will you know you will receive it's more like a like a lottery

79. 41:26

    ticket exactly so when betty is issuing a ticket for ciao this probability is containing an element which is only known to chao and not to betty in order to not get tricked so when chao is actually redeeming a ticket he will provide um he will provide like the the pre-image to the image which is stored on the smart contract which is basically just just a hash and then um the smart contract evaluates well was this really a win or not and this is information which is not known

80. 41:59

    to betty it can also not be cheated by ciao because they they committed to it ahead of time and that's how we avoided it so just practically speaking like ready to generate some number right and then child has a like committed to a hash of number yes of the problem the child number the study number and so smart contract like when chao actually finds like like the winning condition is like mb plus and c you know modular

81. 42:29

    a million is zero or something yeah it's it's similar to that exactly so the only thing is that this this number is uh stored on a on a smart contract per image for each channel for each chat so so but when he wins you submit your ticket then exactly he rotates it which also means by the way just to come back to what he said when you join the network you basically um compute uh precompute a few of these hashes and uh commit this to the smart contract

82. 43:00

    and we don't need to in each channel in each channel you have like an a1 and a2 yeah exactly okay exactly yeah and in that way um we can avoid that you know the the ticket ticket gets gets tweaked um good okay we talked about the probabilistic payments um and what it what it solves we talked a little about a little bit about uh path selection so what if you just send exactly the same number all the time like the number is not chosen by betty

83. 43:42

    the number is what chao committed to this was a larger ticket the lottery ticket is not actually a number that gets uh sent along there what is happening there is actually it only depends on the number that is here along with a challenge which is sent along with the packet yeah so what how does it charge for so the challenge is actually formed by the sender which is alejandro in this case so

84. 44:10

    alejandro is providing the challenge for all for all downstream nodes and then we combine this challenge with the with the hash that is only known to chow and therefore you know chow can not um yeah can cannot tweak it because chow committed to it and that he doesn't know the pre-image but so i mentioned a hundred can just like what if i just send the same challenge all the time

85. 44:42

    what if you send the same challenge all the time the winning probability includes the pre-image of this number here so if you send the same number all the time the randomness is influenced by what is locked here yeah but so so let's say like this specific challenge does not hit anybody's and so i just keep sending you so you keep sending it as they change this himself right correct but

86. 45:09

    ah okay so we have a replay protection that does not allow you to send this challenge multiple times so basically um yeah you you cannot send us so yeah this is like alexander's gnomes and um yeah okay good maybe one thing to talk about on the network on a network overview is a little bit what is required for this to be private so what is required for this to be private is that there's at least one

87. 45:44

    honest note so not colluding with any gpa who was overview of the other parts of the network or colluding with others as well but also needs to be effectively mixing so it doesn't help you you know if you have a good guy yeah exactly and you're the only one that utilizes this note so what we're doing here is um to launch this network we are using something that's called cover traffic and what cover traffic is is is kind of fake traffic that is indistinguishable from real traffic

88. 46:16

    and um yeah the question when you introduce such a mechanism in an incentivized network is a little bit well a who's paying and b how do we incentivize it in a way that is um that is is kind of safe so in the first version uh what we're doing is well who is paying we we basically finance it from token inflation so this is a little bit similar if you want to think by analogy of like block rewards right yeah so block rewards are basically

89. 46:48

    like kicking off yeah exactly exactly so when ethereum launched right they were just empty blocks but still people would just you know mine that stuff why because they got if and this is kind of a similar a similar concept here on the cover traffic um and in the first version the the the interesting thing is not just as in a you know mining network where you just need to think about you know who pays for it but also who sends it so the first version that we're having

90. 47:21

    built right now which is naive is that's us hopper association is like blasting out cover traffic in order to bootstrap the network now what's the problem with that the problem is that in theory hopper association sees all these routes right so effectively the cover traffic is meaningless if you assume that hopper association would be colluding with this with this network so that's what we're looking in a v2 which is using a you know

91. 47:53

    trusted compute setup such as a you know trusted execution environment um or like some other multi-party computation schemes which are allowing you to disperse this cover traffic in a fashion that you can a not cheat again if you send cover traffic all to yourself that would suck right and that two is still providing significant traffic for all the participants in the network in order to yeah have effective mixing of all the nodes and participants in this network

92. 48:24

    in a new execution environment because like presumably it's going to be running on every of these nodes but there's no way outside of execution around like a secure executive environment to actually like create random path which they cannot like route to themselves yeah so the cool thing the cool thing this is again it's it's not built like this is a bit speculative here but the cool thing about the te is also like you have actual deniability of knowing

93. 49:00

    which route your packet took which is kind of cool right so you can effectively do the entire packet formatting and like send it out to the first note show you need to send where you send it out to the first note but afterwards you don't know what where it goes right because what you get out of the te is basically just like this this box here which is you know pre-assembled but like

94. 49:23

    you can make any use of that yeah um and maybe one other thing are these these numbers which we put here right so whenever you have token numbers in there the question is what happens if token goes 10x or goes down minus 90 right um yeah so that would be a bit bad right because if if this just gets too pricey for um for for people to to utilize then yeah it's it's just not useful anymore so typically what we see in decentralized networks uh when we have

95. 50:03

    such issues um again by analogy um would be the block size right so um or or like some fees some on chain fees that you have you have a market model right so you have supply and demand and somehow this system equilibrates itself the problem is in case of hopper we want to provide privacy if you want to provide privacy and we see you know somebody's sending like 1.111111 tokens and the other one is always sending like two you can pretty easily make out who are sending a packet if you observe their behavior so we

96. 50:36

    cannot use the typical model that is used for example for gas prices of transactions on the other hand it needs to be dynamic so what we're envisioning here is that there is some sort of a dynamic kind of voting system to adjust this price up or down but this process must be slow so it cannot happen like on seconds or minutes but like on you know weeks every couple of weeks there is like this this thing can be adjusted up or downwards and in order to make sure that the

97. 51:07

    utility of the network is not in danger basically a badly behaving betty extracting too much money and like sending out only one hopper is actually mitigated by having that embedded in the header information so actually um apart from like part of this beta i mentioned that we have uh this hint in there already actually also the the challenge which you mentioned is in there and what is also in there for every single one of them is an amount

98. 51:40

    which every single one of the downstream nodes is expected to receive so to prevent anybody from manipulating it but again you can only read yours so if we're looking again back in these hatchings and how information is hidden um you can only ever like read what is what is meant for you so in the header we have basically this this trust anchor to say okay i you know nobody nobody was misbehaving before and

99. 52:13

    i will always extract the one like for example if um if i got if i'm left with less than one like i wouldn't forward the packet i would just drop it so how does when you're submitting this right to the smart contract with you know what is the challenge and your number yeah how do you submit the amount because you're submitting the you're submitting the amount the full amount that betty said which is like part of it is yeah you you only like the alejandra are

100. 52:46

     assigned to you you know the amount that's for ciao yeah this is full amount what is exactly so what is what is received there in the in the payment channel is like is the full amount of two hopper but this is something that has been signed off on by betty so betty has provided a signature over this and plus uh some some other values all right but this is probabilistic right alejandro actually didn't pay baji so i i yeah so what could happen what could happen is that you're just damn

101. 53:19

     unlucky right so what could happen is that betty didn't actually receive a payment but she gets to pay ciao yeah that is true that can happen but you know over time that should average out that's basically by equivalence like that lucky bitcoin miner with the usb miner was mining a block maybe one thing to highlight on this thing on a on a high level is this um it's a trade-off

102. 53:42

     what we have in here we talked about the delays in the beginning we talked about this cover traffic and like the the route here so one thing that is interesting is that there's a fundamental trend of trade-off between strong anonymity low bandwidth overhead and low latency right so if you want to have something which has you know super high quality privacy you would want each of these nodes to like cage the packet for a long time and you would to have like a super long uh

103. 54:16

     relay chain right but what it means is you would have a lot of bandwidth overhead for the network which you have to pay for and the second one is it would take longer so um what we want to do here is to basically make this configurable for the sender alejandro right so alejandro can choose how many hops um he wants to send now one funny thing is like since if if we looked at at this whole setup is in the sphinx packet format we need to define a maximum number of hubs in the network

104. 54:49

     so otherwise you know you can everybody sees what what you're doing so um yeah effectively you should have like fast packets and full packages exactly so we're thinking like having having two tiers right so one is like for you know maximum three and maybe one is for longer but actually uh if you look at the uh anonymity set how it grows as you increase the root is actually like it's flattening out somewhere and there's some analysis that have been done also there seven is planning

105. 55:22

     actually like three is already pretty good so that's also the reason apparently why tor has has a choice of three and not something much more because it just it just flattens out eventually it doesn't add much um but what it does add is of course trust in each individual one right so again it the anonymity set might not grow significantly but what does change quite a bit is you know the likelihood that you have one note at least in your chain which is

106. 55:51

     which is honest so um yeah it's just something that you unfortunately always have to consider because when you use a network like hopper like people are going to say well like performance is poor yeah well yeah that's because of this very fundamental so what's your latency like you said i mean the cash flow period of time they said in different order what's the latency yeah so we are actually

107. 56:16

     trying that out right now so right now um what we're doing is we're having a fixed delay of um a few hundred milliseconds i don't remember the exact number but what is interesting is actually uh it shouldn't be just fixed so there's you know some research yeah exactly there's some some uh research uh going into into that saying you know that you should ideally have like some poisson personal distribution now the

108. 56:42

     interesting thing with the poisson distribution is you know there's non-zero probability that's almost infinitely long now an infinitely long latency is pretty bad so what that means is there's inherent packet loss in such a protocol if you want proper anonymity but again that's something that is required because you want to have kind of deniability of what is what is going on and yeah another thing to to add there is on this on this cover traffic front which

109. 57:16

     is uh something that we're we're thinking about is not just sending this linear um flow that we have have here but there's like some some other research where people like people loop it back actually so and by doing that by looping a small fraction of the of the packets back to you you can observe what is going on in the network and you say hey i receive fewer packets as i should receive per this distribution so probably there's something nasty

110. 57:47

     going on like somebody's deliberately trying to censor me for example so that is something that you can do in such a you know free routing scheme as we have with hopper so you can you know build a lot of other mechanisms on top of it which is just part of your path selection right so you use path selection however you wanted to in your in your application got it and then your kind of liveness is mostly depends on pretty much like peer-to-peer but if appears is not

111. 58:18

     responding you're just dropping them yeah it's actually a pretty interesting design space that we have here with this incentives that we bring into such networks because like you could i'm not saying it's necessarily a great idea but you could bring punishments right so if you have too high churn like churn really harms this network yeah so if you'll close a lot of state channels at the same time exactly or like if they were not online for long enough or you know if if downstream notes didn't like make any

112. 58:53

     revenue like you you can just punish it in the account like some of the same they're too easy to game and then yeah explain a bunch of channels and then dropping the exact things yeah so yeah yeah there's definitely a lot a lot more things to innovate here awesome well thanks for watching when we're seeing this in production on in browsers near you and browsers near you so we are

113. 59:25

     currently working on so we are currently working on stabilizing the infrastructure layer so basically making this network stable for node operators actually one thing that we didn't talk about which is a big headache for us we want to make this truly decentralized so if you're using that from your home router like from a laptop between your home router and me also and they should

114. 59:50

     still talk to one another having that in a decentralized fashion is something that's you know not so easy connection so uh the whole nit topic is a big one yeah so we are actually right now having an uh a test net online that people can just play around with and uh over the course of uh 2022 we want to bring overlay features that you have from you know i would call it more you know higher level protocols near you um so like tcp like features when we

115. 1:00:20

     have tcp like features then you can build stuff like socket connections and with that off you go but we'll need the course of 2022 to build these overlay features in so that you cannot just use it for trivial first applications that we're showing right now so we have like this chat application how you can um you know just just send some stuff through it but you want to get delivery guarantees

116. 1:00:44

     you want to there's also another thing we didn't talk about this return path right so how does zoe send stuff back so in things it's again not something something new there's a very cool way of um ensuring that you can in a privacy preserving fashion send stuff back so zoe can send stuff back to alejandro without knowing to whom she's actually sending stuff so that's very very cool

117. 1:01:08

     and yeah that's that's the roadmap uh for the year awesome sounds good well thank you check out hopper and um see you for the next episode thanks for having me here you