Shh! Whisper
Devcon 1 · November 2015 · 26:57
Gavin Wood explains Whisper at Devcon 1, a peer-to-peer protocol for transient messages sent to groups of people, a need not met by the blockchain, which is expensive and public, or by tools such as BitTorrent and IPFS for static content. He describes Whisper as a hybrid of messaging and a distributed hash table (DHT): messages are routed by topics, expire after a time to live, are encrypted to an identity or to topics, may be signed or anonymous, and carry proof of work, while Bloom filters tell peers which topics to pass on. He stresses metadata privacy, a configurable trade-off between efficiency and privacy, and what Whisper is not suited for, then demos its simple API and suggests transaction broadcasting could run on top of it.
Speakers
Topics
From Devcon 1, hosted by Ethereum Foundation.
Transcript
[Music] okay um so this is a quick um talk and hopefully a demo at the end um on whisper hands up if you've heard of whis hey almost everybody um so the first question to answer is why why have whisper at all when we've got the blockchain um the blockchain allows people to communicate we can just make contracts um we can send
transactions to contract they can be like messages um the main obvious answer is that it's really expensive if you use the blockchain to communicate with each other then you're paying essentially to have everybody else know about and archive all of those Communications Min answers also include hey it's open and maybe we don't want everybody else to know about what we're saying but of course that can be um achieved with encryption so in essence there are there are aspects of decentralized application building where we don't need consensus we don't want
consensus and what we actually want to do is is simply do peer-to-peer um communication so within the the framework of doing massively multi-user applications which when I say massively multi-user applications basically what I'm talking about are web apps um but also these days decentralized applications too we see three main um paradigms for communication the first this static um static publication so where we we publish generally quite a lot of data and it doesn't change it's the assets of a of a web page um it's um the text of a
story um it it sort of goes up there it maybe a movie it goes up there it stays the same this is stuff that we already have pretty decent P2P tools for bit torrent ipfs um and potentially even like FTP um we also see obvious sort of peer-to-peer um communication strategies where it's it's point to point right so it's where I want to connect to one particular other identity and I want to feed them information so when we think of this we think of things like Skype um voice over IP you know real-time Communications that's that's generally where we're headed in that direction when it's point to point the final one
is is much more interesting than these two the final one is um transient dat datagrams is what I've called them but this is the kind of communication where we want to generally tell a group of people something for some limited period of time so this is something that we don't really have a um a proper abstraction for yet uh but you see it every day you see it when you use an exchange when you use an exchange you want to communicate to a bunch of people generally the people the other people on the exchange or the people at least on the exchange that want to change a particular Proto uh particular um currency um you want to tell them a particular message and you want that message to run out after a particular period of time so transient messages between groups of people we also see
them in things like Twitter right um I when I use a hashtag I'm actually trying to reference a group of people who might be interested in something that I'm saying I don't want to reference everybody so it's not like publication exactly U but a group of people um and for a particular period we can see some of the um patterns within um um these massively multi-user um applications um in terms of Direction so um when we when we send email it tends to come from a particular identity it tends to go to a particular identity when we use things like mailing lists or uset we're going to a multitude of identities but it's still coming from
one and when we use kind of um there is also a kind of notion of global stuff where it's not really coming from anybody maybe it's an anonymous publication uh but it's going to a whole bunch of people um static content yeah we already have uh answers for that realtime Communication in some sense we have an answer for that within the ethereum framework U using uh the dev P2P stuff maybe a raw connection over that um but uh for the for the final Paradigm that's basically what whisper is designed to um uh to address so in terms of privacy I think it's also important to remember that um and we know this much more than when I first
authored this talk but um it's very important to remember that the metadata of the communications can also can often be almost as important to keep secret as the content of the communications themselves right so we have a notion that you know uh metadata collection actually gives very useful information on um on what's going on so if we want privacy it's important to make sure that the routing itself is kept private as well as the content so what does whisper what what actually is whisper so it's a bit of an odd thing because it's not it's not a messaging system so we don't deal as being a pure point-to-point system for messaging but it's also not a DHT either it's kind of a hybrid between the
two um it has a couple of additional attributes it has probabilistic me method foring which means the the routing itself is kept private it's kept private because actually there's no there's no easy way of doing any analysis on it since it's it's probabilistic um it's also um oddly oriented around um subject key so it's um I'll show you later but basically messages normal normally when we consider messages they have a very particular um two end points they have the end point that they start the endp point that they they eventually arrive at um but within whisper that's actually played down it's not a major part of the system rather the messages have a couple of attributes that are
very very important one of them are topics right so there's a notion that messages um have um Associated topics and it's these topics that are used to root the messages through the system um I'll come on to that in a second so is it a DHT well if we think of it in terms of a DHT then it's it's multi- key which is to say messages may have more than one key these are the topics that I alluded to earlier um it's multivalue which is to say topic um topics or messages that have um the same Keys actually there can be different values Associated to them and it's transient so they don't stick around forever they have an explicit expiry date and if we think of it in terms of a datagram transport layer then which we
can do um then it's also got some interesting attributes um it is inherently multicast which is kind of interesting it allows for um actually reasonably efficient dealing with things like um hashtags on Twitter uh and it's asynchronous so um the messages the the two points from which the messages go between don't actually have to be online at the same time it's also got um a nice little sort of inbuilt anti-dos system it's not um Next Generation but it it basically it's got we've got some good good behavior incentivization in
there um one of the important U sort of tenants that Whispers designed around is always considering identity and never considering endpoint we consider endpoint to be basically an implementation detail um to do with um the hardware that it's actually running on and it's as such it fits a layer below this particular protocol um in terms of whisper we never deal with the end points um this is nice because it has certain um it ties into the Privacy thing if you never deal with end points then um in principle messages can never be tied to any particular physical location rather they're tied to cryptographic identities and that that's
quite an interesting attribute to have um furthermore uh the implementation is configurable in terms of what uh tradeoff the user or perhaps even the application wants um from uh efficiency and privacy so on the one hand um if we want a lot of efficiency we're going to have to give up some privacy because we're necessarily going to be closer to the metal in terms of rooting the packets similarly if we if we don't want um a vast amount of privacy then we'll be able to um trade that off and get substantially faster um faster transmission times it's topic based which means when we want to communicate within whisper we
do so by naming by associating topics which are small cryptographic identifiers with messages in order to um eventually re in these messages we which we may be interested in uh we use the same uh mechanism we use these small cryptographic identifiers um in terms of the encryption it uses uh the difference between unicast a unicast message within whisper and a broadcast message within whisper is essentially the difference in which key it's encrypted with right so we're not doing anything in terms of the um the sort of hardware close to the metal routing with this what we're doing is saying right if
it's unicost I'm going to encrypt it with your identity which means doesn't matter who receives it we want everybody to receive it in principle the only person who can actually decrypt it is the recipient with broadcast rather than encrypting it with a particular identity we encrypt it with the topics which means anybody who knows what those topics are are able in principle to decrypt the message however one of the nice things that's that's tied into this is the notion of root of deniability which is which if I am merely storing a message or passing it on and I was never interested in these topics I will not be able to decrypt the message because I'm only dealing with what is essentially a partial topic a small portion of this
topic uh which is sufficient for rooting but not sufficient for actually decryption of the message itself messages are authenticated as well the difference between um there being an origin so it coming from a particular identity and it being anonymous is simply the difference between it containing a signature and not containing a signature and this kind of ties into you know uh pgp with email when you can sign a message you can encrypt a message or you can encrypt and sign a message same kind of idea except it's actually built into the protocol now it's important to also get across what whisper isn't so it's going to be there's a bunch of stuff which it's definitely not suited for it's not suited for high bandwidth point-to-point
Transmissions so don't think that you're going to do you know Skype over whisper it's not going to happen um it's not particularly suited to low latency Transmissions although it can be traded off to some degree um this isn't an application Level protocol so you're not going to use whisper directly in order to say um take part in a chat room applications are going to be built on this and it's not connection oriented this is entirely about datagram messaging there are two routes into in whisper to rooting itself um one is passive which is essentially a case of gathering nodes that tend to pass you the right messages you throw out nodes that don't um and we call this Pi
steering um this is something that's on the uh road map to being implemented in the dev PTP protocol um and the second one is is active routing this is essentially where we form what I've called topic vortices or where I advertise that I want um uh I'm interested in these particular topics well technically partial topics and my peers pass on messages to me and they select messages they also pass on to their peers the messages that I'm interested in although because obviously it's an exponential tradeoff it does so at a relatively uh lower accuracy level so in terms of um forwarding messages we have this notion of serving
one's one's friends well we want them to stay our peers in general we don't want them to go away and so we uh we want to give them we want to behave well we want to actually give them stuff they're interested in uh what there are three basic ways of determining this within the whisper protocol one is interesting topics so the topics that we've already told them hey we're interested in this stuff you should give us message you should pass on messages um that that are actually uh conform to this another is the lowest time time to live so we want to um prioritize messages that are actually urgent and the third is the highest proof of work so each message actually has an an Associated proof of work which basically um you know similar sort of thing to to
the blockchain it um it Associates particular amount of computation um to this particular message the way that we tell our peers about messages that we are um interested in topics that we're interested in is using this this sort of masking filtering approach you actually use Bloom filters and we pass the bloom filters to our peers and then they can actually test to see whether particular messages match these Bloom filters and if they do they can send on to us they can combine Bloom filters and send on to their peers so that their peers tend to tend to give them messages that we can then uh we may then be interested in these uh this kind of filtering can
be customized potentially per Pier or even per application so that applications that may have very sensitive um topics we tend not to advertise to our peers applications that that are not in sorry that are not sensitive at all but actually do need um to have uh much more real-time characteristics for example maybe um a uh an exchange application um they would uh they would sort of be much more aggressive in telling their in telling the peers what it is that they're interested in um yeah I'll go into that a little later so the API um has three um three functions is super simple right new
identity which creates a new whisper identity um uh post and actually that's changed it was watch it's now filter um post just sets a message off onto the network and uh the filter is able to set up um filters and check to see which messages have already arrived there's an example of new identity it's pretty simple um you get a key back um there's an example of post um this is a bit more interesting we can optionally send a from and a two it's a bit odd to have an optional from right because normally as part of an API we don't get the automatic the automatic ability to anonymize our messages this one does um it's also got a two we canuto we can um actually do a broadcast
um right from within uh from within here that actually means comparatively little because we have topics to identify the sorts of things that this message is going to contain which then allows the potential recipients to actually identify this from all of the various other unicast message sorry broadcast messages um we have the payload that's U simply a bunch of data that that's the actual body of the message and a couple of other things priority which is the amount of work we're going to put in and therefore that's going to alter How likely it is other nodes to um to pass on this message sooner and a time to live which essentially is the expiry date for the message um watch and again this is filter but I'll you'll see that later um optionally has a two now this is this is very
interesting we don't automatically we're not automatically able to filter on the recipient of the message we have to know in advance who the recipient is now if if if we already kind of if we know that we actually are going to want to filter on the recipient of the message and the original sender um knows this they will place that in the topics itself so that we can actually filter for these particular kinds of messages but intrinsically the way that we receive messages are through the topics they're not through the from and the two the from and the two are essentially just the keys that we are um signing with or encrypting with um there's a quick example in this example we're we're
creating an identity we're posting a message the message is going to be from our identity so we are actually being honest about it we're saying who we are um and the uh the topic in this case is the is just an application name and the payload is is just a message sort of saying um you know hi what's your name um we're also going to have this this watch here which is watching for these kinds of messages so it's actually watching for this this kind of broadcast message um identified via the fact it's actually this this application and um when we find this what we're going to do is is just log to the console hey we found someone who's who's asking us what our name is the on the other side what we' we
would actually uh we'd watch this this broadcast um and potentially we could reply to it so we would check to make sure that it's not us who is who is actually asking for people's names um assuming it's not then we're going to um simply form a new message back to them we're going to sign it from ourselves we're actually going to use a two in this case we're actually going to say who we want the message to arrive at it's not a broadcast and we're going to identify it with our topics we're also going to identify ourselves as being uh as one of the topics um we're going to put our identity in there um in terms of where the protocol is going um one of the couple of things that we're going to sort of move uh into soon plausible deniability of the authoring which is essentially a case of
having um a future um uh the ability to have future people looking at messages not be able to be determine um that it was actually us who sent the message um but of of course at the time there will be cryptographic certainty that it was us and um modeling on precisely how scalable uh this approach is and what the tradeoff is going to be precisely between efficiency and privacy so um how much time do I have 10 10 more minutes right yeah okay let's see if I can give a quick demo uh how do I get rid of that escape yeah okay
what happened there uh is there some reason that my ah there we go okay uh very good okay so this is alzero it's running um it's actually running a whisper node here is a console um so I'm first going to um set up a filter so this is going to filter messages that are incoming uh you probably can't see that oh maybe you can it's pretty sharp um basically I've got a a topic set the topic set is
Devcon um and that's the only thing that's in there so it's just filtering on the entire whisper system for all messages that have a topic of Devcon um and when it finds it it's going to uh print something out to the console uh it's going to print out the found message then payload and then whoever it's from okay so that's created that filter and the next thing I'm going to do and this could be done on anyone's computer um but it's going to be done on mine because I've only got one here uh and this is going to post um post the message so the message is posting is a message whose topics are Devcon yeah so the first thing can find it and the payload is going to be World there we are and the there's a time to
live which is a minute uh which is a minute yeah and what we see is uh that found message found message world and it's from is actually from the null address the null address just means that it was not actually signed by anybody so we don't actually know who it's from okay pretty simple next thing let's um create an identity there's an identity that's our key so this is actually just an ndsa um public key that it's returned the actual private key is managed internally in the applic in in alth zero um and what I'm going to do is just send that exact same message but I'm sending it um actually you know what I'm
going to change the payload so we can tell the difference this is going to be uh hello um uh the important thing is that I'm sending it from that identity there it is from ID found message there's our new payload and yes we know now that it's coming from that particular identity right okay um we know that because it's actually been signed so it's not just some insecure sort of thing attached to it it's a proper um uh signature now then we're going to have another identity this is this is my identity so it's gav gav is equaling a new identity there's my identity ox1 1282 FF um and I'm going to set up a new filter this one's just going to filter
um for messages from um uh to uh with the topic Devcon gav right um now we have to tell it actually up front that it needs to decrypt with my key this is to avoid having any additional metadata in the message body itself um so we're saying all messages of topic Dev Kong gav are actually going to be sent to me um now we're going to set up a watch for that and say that it's going to say it's actually going to print a message found message to gav um with a payload and then it's also going to tell us who it's from so I do that and of course nothing comes back because no messages have been sent yet but there you go um here is a uh a post so we're going to
post um using the Devcon gav topic um and the payload there is is well let's change the payload make it something interesting um uh hello uh gav where um from our original identity Ox CB 4D blah blah blah uh but this one it's two gav right and okay did I ah yeah there we are let's use double quotes instead and there we go um found message to gav hello gav where's the beer and
it's sent from that particular identity cool um yeah so that's a uh it's super simple as you can see payload can be whatever you want it to be so you know in principle um bite data um send images around whatever it will be um probably it's going to be mostly asky with a few hashes uh and the hashes would then lead on to some other systems publication ipfs whatever um the uh topics there can be an arbitrary number of topics the topics uh can be anded or Ed together so that we can say right it's got to contain um one of these two topics in the first place uh one of these five topics in the second place and the third place must be this topic that all works fine um and yeah obviously the time to live I
haven't bothered doing anything with the proof of work priority stuff but um the principle is is there and the uh and it works in practice um this is proof PC3 um this is in the CPP um code base um that I understand it is being currently implemented in the go code base I think goes up to PC2 at the moment um and there's uh substantial interest in the other code bases for putting all this stuff in um yeah uh if you want to uh contribute and help uh help uh develop this then get in touch uh and otherwise uh thank you any questions two question
one question so uh two days ago we discussed that one Paradigm of building scalable daps is creating uh sophisticated State channels and I'm wondering whether a whisper is the right protocol to distribute uh transactions that happen on those uh uh on those State channels is Whisperers for that yeah so this is oh cool this is a um actually something that I would like to take forward uh I think um with uh blocks and obviously the stuff that uh Z was talking about before um the various
bits of data regarding the blockchain this is all um static data and fits well into the ipfs Swarm sort of Paradigm uh transactions uh definitely are much more um uh ephemeral data that float around generally have broadcast semantics potentially exist within different networks for maybe private sub networks so yeah whisper would work particularly well and it would be really cool if we can make the transaction uh publication stuff actually be uh just an application that sits on top of whisper yeah definitely cool um thanks guys fantastic