Network Level Privacy With HOPR: Fixing Ethereum's Achilles Heel by Sebastian Buergel

[Applause] it's a pleasure to be here it's very nice to be talking at Def Con and four years after just these events make me quit my job that I had so far indicted to be pretty full of function so alright so I would like to start off with what back then was actually the vision of ethereal right and the vision of a theorem was actually not just a define magic Turing machine but it was going towards an the web 3 right and in fact the theory has priced many parts and adoption was just one of them there was supposed to be he centralized storage messaging like swarm whisperer and then I guess somehow crypto winter and happens a lot of things shifted around and we're happy that we still have the ferredoxin round but to me this this whole vision of this web 3 vision of building decentralized and privacy-preserving applications and something that I find very appealing to to going beyond just financial applications because me personally I mean my banking is not the most exciting application I have and in the meantime a bunch of things happen in a bunch of things and have also quite a focus of privacy like we heard already the town right now that we have mixers right so transaction value can relatively well in a decent manner compassion we've seen a lot of publications there we also see quite a movement on the storage front right so obviously I give this Falcon guys what else is store Jade which I heard runs negative as I and a bunch of others we also see a lot of computational focus projects which in turn again many of which have quite an emphasis on on privacy but what I would like to talk about more is that from many of these applications we really need the fundamental privacy foundation to enable communication between users and apps and between different components of these fancy right so this is what we're is only aiming to build with opera and I would like to go a little bit into the why like why would we do that from an yeah from an in theorem perspective so one thing and I don't know if the tornado guys are still problem but this is from the tornado website right so if you try to use who you're used to tornado actually anybody use mixers okay so you just need some metadata by the way so yeah this is what you find on the website make sure to use different IP addresses for deposited withdrawals we prevent bruising tor browser or VPN right that sounds fine and but actually neither door nor VPN are suitable in my mind to this defy level privacy which we're striving for here so tor is not decentralized at all it's relatively easy to Indian on amaizing there's like a body of research on that fault and VPNs are primarily corporate entities that are in all encountering some data and making it available for whoever needs them and or for whoever pays for it right so this is the business model of VPNs now more specifically broadcasting is not privacy-preserving and or electra mellon is here because i see a lot of inflation between cannot broadcast place schemes and mesh networks i think especially Bitcoin ecosystem you hear that every now that we and then we have this mesh networking this mesh network and that's why it's private right no mesh network is not prank privacy and the same goes for any other broadcasting basis scheme so I would like to briefly go through an example so we come up with a hypothetical network so topology is having some notes and initially no no particular transaction once they do no transaction we market as X in between we draw some lines that show the edges of the connections of these notes and what's important is that this is totally public information right anybody can create you know anything can can find out who has what transaction at what time so our hypothetical and network topology looks like this right and what we see is that as and of ripples through the network and gradually reaches all of the notes in the network you can of course what you were just seeing you were a passive observer of the network and you as a passive observer of the network we're just finding out where this transaction originated from and this is something that touches you can do this is basically something that anybody out there can do which is pretty bad for a decentralized system that wants to bring us privacy and has all sorts of nice features on chain and then again it's the reason why the tornado guys made this suggestion right to use and cannot talk and finally one one example that I find particularly striking is today I think we still live in this frontier world right so to me this is we're really mostly at least here in 0.1 stage right so what we see is that when you near Denver and Osaka you have minimized and connects to well default if you are right let's face it that connects them to the so-called decentralized aetherium and what we increasingly seen am happy that we have projects like that know about oh and some others and if you have your note in your living room that you can connect to all right so this is this is what we can do and still like your hotel Wi-Fi provider their eyes pee and everybody in between can pretty easily find out that you're accessing your service and that you probably just broadcasted a transaction or tornado so what I would like to see is like a less less less revealing link between you and your dad and actually the knows that interface so this is what we want to do with Humber to connect you your wallet and to metadata private now popper is decentralized incentivize privacy-preserving messaging protocol so we don't build a chat application people can build on top off on top of that poppers also it makes net so now we are just very briefly in how we achieve this privacy so makes that basically means that notes and sending messages these messages are received by every layer which is short term caching them and we keep this updatable so that it can cater to different types of applications is then mixing the ordering of the transaction before they are replaying them in a different order and what is important is that incoming transaction and an outgoing transaction cannot be linked right they look different and there are some packet formats that are optimized for exactly that so that your traffic cannot be linked between incoming and outgoing transactions now we use only encryption so basically we don't just do that once but you did it in multiple times so basically if you pass that message through a chain of three layers and that each chain one one in the layer of an encryption of it you have a link ability that is hard to establish beyond guessing why would they do that well this is this is an important point to me and one that makes the whole design of this network a lot hotter is because they earn money for it who here is running a tor node one two two and a half so we have to the hub on earth is two and a half how many exit nodes we have in the room okay why does that mean sweets okay yeah so I mean the question is why would you write you have something that comes at quite nonzero across especially quite not as their legal cost so why would you do it right so any any system that runs at scale needs incentives and I think we've seen all this well just kind of works but still not very works really well for you theory or any sort of blockchain systems where nodes don't have incentives to to run a full node right so this is why we want to incentivize three layers so basically your hopper comprises a message and a payment layer and a message there and as described on encryption and distinct format which I will go into in a second a bit more detail and of course we built this on the p2p every javascript imputation belcher layer and we have payment channels who will also discuss a little bit later in detail with a POC I'm going to be right now so briefly on a message there what's going on so Alice is sending a message to make Dave via two hypothetical readers they're friends Bob and Charlie so Alice is formatting a message which has a header which comprises two components what is routing information and a second one is payment information right and then of course there's the body which contains the onion encrypted message so what she does is she basically she defines the root source for religion and she then assembles he had her and sensit to Bob now what mom can see in the header is so far only that charlie is the next downstream downstream node but what what does not is not able to do it is not able to extract a payment just and because that would allow us to to be susceptible to kind of take the money and run attacks right so we just take all the money out and not do anything so what actually needs the collaboration of Charlie so once Charlie helps Bob will receive a key hub with which he can unbind the payment channel and of course it could be that Charlie is just not very nice to Bob and simply doesn't do that but then Bob basically in the future deny any traffic to Charlie so that's that's of course something I mean it's kind of this it goes in the direction of the verifiers dilemma but we basically see with incentives you can you can improve that because charlie simply won't get any payment for succeeding transaction that she denies Bob so it continues to the same fashion charlie takes the packet with the help of Dave she will then get her payment valves and with that we basically have a cyclic operators so this is in simple terms of our message to the air works like now let's look at the Univ there so on a payment there what we see is that we see these kind of encrypted payments going around and we have to key half so it's a secret sharing mechanism which we have in place there and Bob can to obtain his payment Bob can derive the first key half and second one who needs Charlie's help form and was that he can get his payment and Charlie gets his her payment and now if we look at traditional payment journal Communications we see a couple of limitations here that we are trying to improve upon the first one is of course that we want to have a tight coupling of the packet and the payment leader and the second one is kind of a proof of relay right so we only want you to be able to extract a payment if the next downstream node has actually come sent your confirmation what we also want is we want you I mean in a realistic scenario there is packet loss right things don't always know well so we need to be able to have partial payouts and with traditional payment channel implementations you see that payment shells are always set to absolute values right we don't just have Delta mounts we send a payment channel to an absolute value so if I sent you a transaction or if I send you a million transaction and you were only ever successfully relaying the last one of them you would still get the full payment because it sets it to the absolute value of the last transaction so that's one problem and the second one is you could say well we kind of unlock a payment on on a packet by packet basis but that would be kind of a huge proof size which you would deliver to the blockchain and then what could be said is because we've heard quite some of the things about snarks and stars and fancy crypto stuff so the goal of Harper is that this ideally runs on IOT devices on really small devices that are somewhere out there in the field in which do not have the capabilities of doing really complex computations on there that's what we try to go for relatively simple protocol here so this is a bit more in detail how there is proof of really works and to understand and I will work you once through a setting of a payment channel so our players on the left is of course smart contracts or payment channel smart contracts it's Alice Bob and Charlie and this interaction here is Bob closing is his and channel so basically getting his money out that he got one way or another for madness so first of all a the smart contract is validating a signature or a curve point that one gets from analysis Estonia and this my contract is then also validating a free image of this point so basically we have this we have this probably known perform kind of a pretty image tiers of this multiplication is an elliptic curve operations they cannot easily inverters and it could also be as I mentioned before impartial they all should be possible so it could be that some secrets will not be but Bob will not be able to derive all three images so there's some parts of that which is which is which is failed now basically we need to walk through where did we get all these values from what do they mean right so Alice sends kind of an updated curve point with every single packet and she signs it this is an analogy to to the updated values of traditional payment channel implementations okay so we have the s total from the difference between two succeeding as totals we enough have the Delta s from which we could also assemble the s failure if something goes wrong I got a package from Alice but I can't pass it on to Charlie so I basically add that to my to my guess fail now for the for the parts where things did go wrong and they go right so for successfully reading packets Bob can derive the first half in the second Kiev which means the operation from downstream known so the first key half begins himself where's the second key half gets delivered from the next downstream note alright so basically just sum them all up and then gives you the preimage of the social circle like you could say the secret would you deliver to the smart contract for four payout right so because this one here still gets gets multiplied it's basically a secret that was known by Ellis gets gets transmitted in a different form over the wire and then can be used by you and only you in order to unlock your payment so this is basically how we achieve a payout conditional to the to the delivery of a packet evidenced by having a key half from a downstream note and having an efficient settlement that is basically yeah that is basically constant in effort and data overhead so you can sell that on in theory em today cool and yeah with that I think we're running out of time my connection is pretty poor so I let you I need to check out ours now okay I expected that and sorry for them so we have that we have a smart contract on here you see some transactions of opening and closing payment shells and receiving a payout maybe you have better connections than I do so you can check it out and with them open for questions thank you very much so does the sentiment of the payment not kind of like engineers like Leake who sent want to go yeah that's all person good question right and yes of course it does make something but it leads kind of minimal information about what payment channels you have and kind of what you used involved so you would if you would do something super stupid like you would settle on a packet by packet basis which is not even economical then yeah that would be pretty bad but what I imagine Moore said you would do it on a monthly or quarterly basis so you would then say okay every month I want to take my money out and basically what we would see is that you got X out of this right so you would see here you would get unknown 0.5 Eve out of it so yes it leaves some information but not more than is publicly known anyway and yeah we're working on right now is how do we incentivize people to open as many like reasonably many payment channels useful naman channels to reduce the meaningfulness of this information thank you for the talk and I actually have a bunch of questions so first one said I know the mixed networks actually suffer from high latency so how is the openness of the problem and second one is the recently I noted protocol seed mix it's a juicing machine as well so I wondered if you guys had a study on that and what subpoena that poverty of computer dismal and nm is a proposal on appearance is to use Jungian routing to to prevent from sensor in front of oh don't so is there any a possible that you can use an offer protocol to cheder us deal with the problem and also Pina no thank you cool let me try to remember all these so yes basically this sort of this sort of peer-to-peer communication is certainly slower than direct communication that's clear the question is how bad right and the question was the comment we want to keep customizable by the application layer so if you build hmm like we check to find out you want some one second latency you have like okay privacy so there's this fundamental and trade-off between privacy legacy and if you want to do kind of like I don't know some some activist group emails then probably you want hardcore privacy and you need like 30 minute latencies so it should be possible to define that on application layer your second question is ceilings and we will need to look in the implementation details so I guess a lot of ideas right now out there and not all are really implemented so it's kind of hard to tell this is far away it's all open source and check it out on our github feel free and third period idea suppose on is yes so right now there are dozens unlike Bitcoin etherium does not as important in running out of the box and yeah that was one of the inspirations when we started first of all absolutely brilliant so so do you think that this is going to like enhance it here on computer it's probably best to go again for us that's the goal and admittedly we are pretty early on here right so we're looking at a largely unfunded project except for some donations so yeah but that's absolutely go well thank you any more questions do you have to open up a Machado with every neighbor that you have I guess with every relay like how do you how does that work and also is in their turn in terms of IQ relays popping up and other ones going away you have to constantly be opening up new payment channels is that any kind of in it yeah so how does this work right now right now we have a slightly optimistic scenario where we open them on demand for you which is quite easy to exploit right and but the idea is that you have some strategies as to what payment shells you want to open so we would actively and you actively open them we would have some default strategy that you could you could change yourself because it is right you will have some churn but also some notes will be decent relays and others would not be so basically to reduce churn and we are currently working on some mechanism of slashing those three layers that are offline for it to long amount of time so basically something that would be annoying is if you're in the London Underground and you're like oh so you have like some maximum traffic loss right so that's what we want to prevent here I think we've tied for one very last question or otherwise we just closed it here and I'm around afterwards if anybody has questions in that one-to-one basis thank you very much [Applause]