Multi Protocol Peer Network Framework: Vision and Roadmap
Devcon 0 · November 2014 · 51:28
RPX was proposed as a stable, encrypted peer-to-peer protocol for multiple applications, with flow control intended to stop one application consuming all available bandwidth. Network addresses would derive from public keys, while authentication would operate on the stream by inserting a hash every 8 kilobytes rather than authenticating each message. The nonce's placement inside or outside the encrypted payload and the derivation of shared secrets still required review; peer discovery and constraints were next steps, while peer ratings remained outside RPX as an implementation detail.
Speakers
Topics
From Devcon 0, hosted by Ethereum Foundation.
Transcript
[Music] so uh subtitle here is vision and road map however the slides will be more somewhat Technical and maybe philosophical um uh but the vision is um is simple it's to create a protocol that multiple applications can run over that is encrypted and provides certain
guarantees um and this has become more apparent over this week that this is uh this is an interest and it's in demand from uh from many people so people who are building daps um we we saw a few on Monday uh and ethereum itself so in in in turning complete flash fashion uh we are doing a similar thing with the network protocol and in that it can be used for uh for more than what for more than just ethereum so um a
little bit about me uh was born and raised in Texas so um the yagy thing that been pointed out we would say y'all ain't going to need that um uh which is important in networking uh because we don't uh we don't want to put things on a network that we don't need um it adds complexity and uh and that's that's that's not good um so before I started programming I worked in uh in networking at a strong interest in networking network security um and uh uh helped build internet service providers uh that kind of thing got into programming uh wrote helped write a C++ bit torrent
tracker that um that uh was so bitor itself was controversial um and and the reason that I I mentioned this is because um it's it's a important to remember that we're adding encryption um here and this can this can be a double-edged sword so our objective is is to build what we need for for the protocol um to have integrity and and that includes encryption um anything beyond that uh is is um we would like any anything beyond
that to be able to be built on this protocol uh if it's feasible something else could come along that's better there may be other protocols out there uh uh already uh that they have the potential to to facilitate this role um so uh what what what we would like is a multi-protocol uh peer-to-peer protocol so right now if you use bit torrent um the uh the peer Network that you're connected to and the things that you can do with that Network and those code bases is to uh send and receive files um and it's really efficient um because of uh because of how it's done
so now if we want to allow multiple protocols to use a similar peer-to-peer Network um we're we're we're we're starting to layer things and if you have two layers um that's usually that's usually not not too difficult to do something just needs to be lighter than the other different properties whatever or you you know just go back and forth it keeps it really simple um when we want to start adding more layers to this uh it gets really complicated um really fast so uh with with the protocol um for ethereum uh scalability efficiency and usability are are really important uh if
if if if if the network is slow um I I think we can all agree that that that wouldn't be a good thing um faster network uh that's not the goal that's not the most important thing um but between the two this helps with robustness so the network can respond to events faster um DHT tables uh can be kept more up to dat so the general status of the network um can be more robust and and stable if if if it's quick if it's efficient um uh privacy um we'll uh talk a little bit
about privacy um later I think um to me I think that um that encryption is is is a form of privacy um so so if we are encrypting traffic we are automatically um adding some form of privacy so the internet as most applications as most application developers know it um is is is pretty can be laid out simple so uh a lot of Networks run on Ethernet or perhaps they run a cell phone or ADSL
um these things um a lot of those so for example DSL actually most DSL connections use a form of ethernet um Internet Protocol uh TCP and and UDP so an interesting thing about these protocols is um they have their own sort of uh form of how you use the protocol so if you want to build an application that uses TCP there's a lot of things that are going on in the background to to allow that to work to begin with so if you just took TCP and you put it on a on a
small network uh you're fine if you take TCP uh IP and you put it on the internet um with just the simplest uh ethernet IP and you know tsp I it it won't really there's a lot of problems um so uh an important part uh also um each of these well these two have address resolution so ethernet has addresses and we have address resolution protocol um IP has addresses which um some kind there's ways that you can uh that you have Discovery so on on the routing side of things uh we have
protocols that are used for infrastructure um notably NLS is is is on all of them so um the interesting thing is is that a lot of a lot of problems that uh large peer-to-peer networks need to solve to to be to be robust um are really problems uh that uh Engineers um uh working on uh keeping the internet up uh they they are problems that these Engineers are also researching solutions for so uh to give an example of this um
here's a diagram of a just a network diagram from a like a test thing and um uh it gets complex really quick um we don't have cell phones in here um um uh there there's there's a lot of things going on with with the internet so this isn't here but there could be a Sonet ring here so that if one part of the fiber gets cut everything uh just goes the other direction around the ring um so uh yeah um uh the diagram I have a hard time reading it from behind
uh so this is uh this is an example of different kinds of networks so um frame relay switched um and then for for other connectivity just imagine that every single one of these connections is is a different uh is a different way of the connection routes messages differently but yet they all get along on the internet most of the time um so can can I ask very silly question yeah like for software developer like why do I I'm going to get to that okay so um so uh do we have do we have
Solutions um so considering privacy uh as well as scalability of the internet um there there's a lot there's a lot of people working on this um IPv6 uh is um um there's there's a part of IPv6 that tries to help with privacy um now uh one interesting thing about IPv6 is they are 128bit addresses so they're not quite large enough for us for to to to use um on a on a peer-to-peer Network that that depends on cryptographic properties uh for um uh
for shaping the network or for um peers connecting and we'll get to that later so uh recent issue um this is a blog post from from an engineer at at MIT and uh IPv6 has this really interesting thing where everybody who actually gets an who gets an address um doesn't get a full address and they can generate their own um private addresses just ad hoc out of nowhere um and uh so it's kind of like an ephemeral address but the problem is is that uh routing equipment relies on addresses that don't change um uh
because because it can do so quickly um so if every computer in the world changed its address um uh every 5 minutes uh it would be really really difficult to scale that so that uh every message can go from its source to its destination um the amount of memory and and processing power for uh core Network equipment would uh would have to change or algorithms have to change so um yes so uh um if you're interested in IPv6 um and how how um there there is there is a project that's trying to build on IPv6
um for privacy and encryption it's called cjdns um that's pretty cool if you want to check that out um so so a lot of what I'm covering here is is the internet as we know it today for most application developers um so all major browsers today should be using TLS uh which is like version four of SSL or something like that they they change the name of it um yeah so TLS is a protocol that run that that runs on tcpip so it's similar
to http or IMAP or pop or um uh any application protocol um except TLS is to say well use TLS so start your connection with with TLS and then it will be encrypted and then just start sending messages once you know that that that it's encrypted so a few of the things with with TLS is that TLS itself um uh is is is is pretty good it's well researched um the attacks against uh against TLs are often edge cases and rely on attacks on other um uh cryptographic uh algorithms or the at
the end of the day U the issue is is the implementation so um TLS used by everyone uh today everybody uses uh root certificate authorities um and and this is centralized um uh that that works for certain use cases but ethereum is is decentralized so the usability of TLS is is is also somewhat of a black box because um if you're a developer and um and you write JavaScript uh web application or something there's no way for your web application to determine if it's running on an encrypted connection or not um and
and if your web application wanted to determine if it's running on an encrypted connection it couldn't find out um like who it's connected to over this encrypted connection um the only way that we could do this right now is to actually Implement TLS inside of TLS with JavaScript or something which would just be uh not fun um so on a on a on a more um concerning level uh TLS most of its problems have have had to do with browsers implementing it and making it really easy to downgrade the connection and so um this has been used as a as an attack Vector to basically when the
browser goes to connect con you intercept a packet and you quickly get the browser to connect with a lower uh uh security so say 56-bit encryption instead of um uh as or as and uh uh and and downgrade the line um uh and and implementations are really geared towards running HTTP over it uh not not other protocols um so one last thing um uh maybe maybe some of us here have seen this slide before um and uh and and again uh to your question I I I'll I'll cover uh what this stuff is about and
why um so this is a a p this is an image from a paper from researchers I think at at Harvard and they're basically saying okay you can use um net flow analysis to figure out out what's going on uh with tour um and the reason that I present this is is because um so this isn't necessarily a problem um but it's something that uh that I guess you could say uh Freedom Fighters and people interested in privacy and freedom um uh there's there's ongoing research here so
um how how do we actually have have privacy like how can we send and receive information over the internet and there's no way for somebody to figure out um what what is being uh sent and and received um so what's important here um is really not the attack or its tour or anything like that um what's important to know is that uh in data centers all over the world there's there's there's equipment for net net flow analysis and what this does is this equipment read reads every packet that comes into the network um some of them do this based on sampling so they'll read 5% of every packet that comes onto the network and extrapolate information
from that so the purpose of this equipment is to help um is is to help their Network they they don't install this equipment to EAS drop on traffic or figure out what people are doing they they often times they install this equipment because it helps uh figure out where denial service attacks are coming from so back back to the double-edged sword thing there's a lot of cases um uh where um where there's there's a balance um and uh yeah so um when uh when I started working on the networking stuff
um G was like uh yeah so we're going to run everything on this um uh no no press um this is actually really really really applicable um and I'll get to that in a bit uh so yeah so uh the ethereum network protocol uh as we have it today is um uh ethereum relays transactions blashes and BLX whisper messages and filters right now uh presumably swarm will be content hashes and content blocks um I'm probably missing something here uh later
I expect that we're going to add things like simple payment verification um and uh and uh so right now we also sort of have P2P here um and all it does is uh exchange peers um so each of these protocols sort of has um different requirements kind of um so ethereum and swarm are both kind of hybrid so um that's a typo uh um the relaying of transactions is is fairly important relaying of blocks that can be that can be fairly important uh same
with relay hashes but the throughput of relaying blocks is much higher than the throughput uh of relaying transactions naturally um so uh so if you wanted to send uh 10 transactions down the line and and and 10 blocks the 10 blocks are always going to use uh more bandwidth than the 10 transactions um now by the way not not for sure it depends on the size of the contract yeah if you have 10 10 empty blocks yeah so so if you sampled 10,000 blocks this is true
okay um uh because the blocks contain the transactions so blocks are actually groups of yeah transactions um so uh it it it could be argued that some of these messages need higher priority than than others and what does high higher priority mean on a network um that means that there's lower latency the message gets there faster than the others um so uh on to answering the question earlier um about everything uh with routing and privacy um uh we won't be solving those problems with this
protocol um this this protocol is for a stable robust Network protocol that's encrypted and multiple applications are are running over the protocol so um so there won't be anything to do with routing priorities um multicast or broadcast right now multicast and broadcast is written in code so send to every peer and so uh it's it's it's really it's unicast um uh or the direction of the flow so um some protocols similar to what will be proposed as provide a mechanism such
that you can connect to something and say um uh don't send me data I'm just going to send you data uh or or they can they can say the same thing are you okay with me asking question from uh no wait till the end yeah um so some uh yeah um so some good reading material for all of this uh if if if you're interested or you're working on similar um uh similar uh similar systems um is the uh the Speedy draft from Google uh this blog post which is really recent and does a great great job of describing
um uh Network buffering and and what do you do when you have to send out 100 megabytes of messages and um and you can only send out one megabyte um and more in the context of of scalability not necessarily a single application um bit torent uh is is excellent um the idea of uh bit torr is takes a file and breaks it into a whole bunch of piece pieces creates a uh Merkel um Merkel root hash of it uh and then uses that as to being able to hand out pieces um and the way that um uh the way that's
done is is alol um for the DHD stuff which which I won't cover um uh Amazon Dynamo blog post and cadima um these are both really good um the Amazon Dynamo is just a great uh sort introduction um so uh I couldn't come up with with a name so it's it's it's called RPX and um uh so it will provide an encrypted line um multiplexing multiple applications over the line um flow control uh and then later uh constraints peer Discovery and and peer
rating um each of these sort of fit with privacy scalability efficiency or or usability um and uh and and the constraints this could say constraints uh and metrics um which uh which is sort of connected with the with the peer rating system um and uh I don't have I don't have sides for that um but that um so I can swear there was picture or something here yeah okay um so in in encryption is uh the way that we're using encryption
um relatively new so last I don't know five years there's there's other projects that that are doing this um we're not the only ones um but most of the web right now is encrypted with TLS and uh uh and and we know how this works with certificates and the server has a certificate and they send it back and forth and things like that so um what we're doing is every node uh every endpoint of the connection of a connection if you want to call it that is uh is generated via a public private key pair and the address of the public key is the address on the on the network
or uh yeah yeah um so uh of course everything should always be encrypted um and uh and authenticated um so I'll I'll get to the authentication bit um but um so a lot of protocols you they they authentic they they authenticate every packet or every message um and uh and what's being proposed here is to um is to have authentication essentially out of band from the application so the wir line is
doing authentication um in fact this network protocol is is authenticating the traffic rather than rather than the the cipher the Box Cipher um or the application itself um so uh there was an article posted on Skype about um uh about using crypto and I'm just going to read this designers and implementers should refrain from optimizing well studied protocols to achieve some specific application need unless they're prepared to revisit and reevaluate the above security proofs small small in significant changes in protocols can
result in invalidating the guarantees of such proofs um so a lot of factors in here um in this paper were about uh or about key sizes and and and parameters um and uh this was released by enisa um you you to link this paper earlier um so with encryption we are not changing in parameters um we are using the cryptographic prim Primitives um as as they're expected to be used however we're com combining a few things because we are multiplexing
application traffic over a cryptographic channel so um so it's uh we're basically changing the time in which we are processing uh information uh about uh authentication um uh it's it's streamed um instead of coming up with some new protocol or using uh using a self authenticating block Cipher yeah so uh encryption um the the first version of proposed encryption protocol is uh is is
this so uh the uh the implementation is that um I want to connect to a peer so I need to get their public IP address uh sorry there yeah public IP uh port and public key so um so I will always have the the other uh the remote public key um they might not have mine um and I I might get it from the DHT I might get it from another peer um or of course I already knew uh I already know this this Beer's public key so when the connection is started the
first message that's sent by the by the side that initiates the connection is uh uh they using ECI they use the remotes public key to encrypt um their address concatenated by um a signature of of uh of information so um ethereum in general is relying on our ability to recover public keys from ecdsa signatures and so um what we're doing here is we can extract we can recover the public key from this signature so when the connection is started I'm
sending uh my public key encrypted with their public key so this also means that if I send this to the wrong person they're not going to be able to decrypt it um and they won't know my address and can you please explain the sign brief um this this is uh signing with uh with ecdsa and uh the private the private key is used to sign uh the the ticket or or the non so the ticket is is essentially um uh the previous uh based on the previous session um uh and then concatenate a a
random uh value which is used um to do uh um ephemeral Diffy helmet um so th this part and and how this works um this is this is similar to TLS um we're just uh we're doing a lot of things in one message and we're relying on the fact that we know the other side's public key uh with with web browsers today um you have to connect and find out what the public key is and they have to tell you the public key um and so we're not doing that as a part of starting the connection um and then uh
this knot um the details of this knots is in the is in the proposal and uh it could move into the encrypted payload or not um uh this needs to be reviewed um uh as as to whether it's better to do one way or the other and um uh uh I'm I'm open at the end of uh afterwards of getting together with anyone who's interested in helping determine what the best thing to do is because this potentially changes um uh has side effects based on where it's at so what does that
non um it it's used it's used for uh it's used for um for changing for updating the session so after every successful connection uh you you update the session and so um when that is combined with using uh ephemeral um uh public Keys then if somebody steals your laptop or they steal your server and they have your private Keys um they could have they could have packet logged everything coming out of your server and they won't be able to decrypt it um so so that's a part of
that yeah yeah um so can you just say again what the nons ticket are from uh they they are used as uh in the in the that uh yeah the uh so so so the ticket is a value that have stored from a previous session from a previous connection and and the not is because there there is no value and so this this uh um establishes a new value um so this is similar to what's being done
with TLS um so TL TLS uses this for uh for uh uh driving key material for the shared secret um and and uh that's what we're using that for as well um as I said and and I want to reiterate um the the the purpose here is to create something that we can we can use this needs to be uh reviewed um uh because while um while we're not doing anything that's that's not by the book um there's implications on how um on on how we use
this information to derive shared Secrets um and to and to update them so um so multiplexing uh is really simple because we already have it um uh right now the way that that uh that we're doing it is um each sub protocol has like 10 packets um and uh or or five or whatever and and we're stacking those into one um packet type and then based on what's what what protocols both connections agree on um uh is how
we determine which packet type is which packet type uh when we receive it the um I think the the networking guys are familiar with this um and that that's called adap message IDs and there's a there's a weaky article page on this actually it was last why you can well so that's the question marks um uh so so it's been proposed that uh uh that uh that we go to a system where we have a protocol type and a packet type and it's just two values in instead of instead of stacking one um so whether we do that or not we have
to we have to get together we have to decide maybe tomorrow and uh so but it's it's a it's an implementation thing so I think the idea behind the Adaptive message was to to to make it harder for filters to filter us one of one doesn't give serious prote in any sense yeah it's one of them but okay I kind of like like it it wasart yeah I mean I like it too um it uh who's well well there are people that don't like it I don't think that they that they hate it um I'm I'm 5050 I I I like both um but the Adaptive message idea I
think is was sort of a little artistic yeah ums bys it's very much like rlp so yeah uh maybe a style thing it's like to say hey we have SM um so flow control um uh so we're not actually going to do this but I think it's funny um uh that uh messages are on the internet are obviously information on a journey through space and time so what
what's interesting is these vehicles can uh operate differently um when mixed together in the same environment um and with running multiple protocols over a single line we we have a very similar thing um in Berlin there's a lot of cyclists um which is really interesting because um I can ride my bicycle to this office faster than I can drive a car here um so uh usually five minutes faster and it takes 10 minutes to cycle here um so um also uh applicable um buses planes mass transportation are carrying a lot
of people from from point A to point B um and uh it's it's uh in most cases it's economical to to maximize um how the vehicle are are built and and and how they travel um flying around an empty plane across the ocean uh is is is not a good idea um and so uh for for the same reason uh flow control um helps ensure that the bandwidth that we have available uh is is um uh is is used is maximized um so one of the most similar
implementations to to this is speedy um which is for uh HTTP over TLS this should really maybe say Google's data centers um instead of Google Plex um and I haven't read the latest draft but prior drafts essentially the flow control for Speedy is for Infinite Space and Time um so my understanding of speed is that you can have as many applications or channels as as you want and each channel does its own flow control um uh which um that can work really well in an environment where I
have a browser and my browser connects using Speedy to a uh application server running a certificate which matches who I'm who I'm talking to so in a peer-to-peer Network we are connecting to peers and uh and we don't know who they are um so uh uh so uh where where this is relevant is um that um it it might not make sense uh for us to uh go this route because what Google can do with this under the under the assumption that of how browsers are working is that Google
can optimize their systems from the browser all the way to the source of the to the multiple sources of data within their own system so for Google Speedy is multiplexing their entire operations which uh which is mostly web applications search and uh and Gmail and Maps um and uh and and this works great for them it also works good for browsers because browsers are um you hit the page it downloads and it's done and so the goal of Speedy is that is is so that that happens as fast as possible and while the protocol itself allows for all
of these channels um a web browser when you click and you open a page only has a finite amount of of information and so the web browser will only uh will only um you know nothing out there is is is going to uh really exploit that um so with uh with with RPX we have the ethereum protocol as as it is with just a slight change on the packet type um it's encrypted uh and the the flow control is is is simple um and uh deterministic um so for the flow control
um what I want to do is uh is is is talk about that with with the with the Whiteboard um as sort of a part of the the the Q&A um uh by the way uh how many people by chance have read the Speedy white paper okay cool okay uh okay so how how does this work um uh uh so um the application needs to send data so it sends a message um compression I'm
sure uh there's some questions on that um uh uh header is is is added so these three steps so the header may be first um the the authentication is done uh uh based on on the B stream not on the messages um and so what we say is that uh every 8 kilobytes we insert a Shaw 3 hash of of of of the previous of the previous 8 kilobytes um and then so our our overhead for authenticating the traffic is is reduced
substantially and and in addition to that um uh it it um it it operates on the same signal that's used for the uh for for framing um then uh then uh then encryp the bites send it out um and uh and and we get out the other side so why is FL control um important so a uh a network connection has a limited
bandwidth so in many cases network connections have a fixed bandwidth um ethernet uh ethernet typically does um although uh to a single application you don't know how much bandwidth is available um it's it's it's it's an it's an unknown factor that changes over time and it can change substantially um and and only the operating system has control over this um so when when uh with ethereum uh we we want to allow daps to run over the same peer
protocol and sometimes you have to make decisions um so if if you have a network connection that is only 1 megabit per second and you need to send 10 megabytes um you're going to have to you're going to have to wait and if your application needs that 10 megabytes sent uh in a certain amount of time um you need to you need to do something about this um uh at least be able to tell your application the data's the data is not going to get there in time um more more importantly when you're running multiple applications over over one connection um we don't want one application to be able to take up all
all of the bandwidth so when when when the network connection gets to the point to where it's full uh you can't make the network connection bigger um and in fact it's it's quite likely that if the network connection gets full um congestion actually goes up and it's going to even get smaller and and your choices are to drop drop the packets that you're wanting to send or um the the the other option is to block the application from sending more packets um in order to do this uh the
application our networking layer needs more information about the con connection because as is um uh if if if if I want to relay 100 megabytes of blocks um I can I can tell the OS to send 100 megabytes of blocks um and and the OS might stop me at 2 megabytes or 4 megabytes or 16 megabytes it's it's different different for every operating system um so uh so we want to employ a mechanism so that um so that there's essentially a pipe there's bandwidth for each subprotocol
that's that's running on the line and we want to do so in a way that there's enough information exchanged between the two peers that they know when it's overflowing or we can also use this to know when uh when there's more bandwidth available um and if there's more bandwidth available maybe we can use this for swarm maybe we can use this for for something else um that's not that's not a part of the protocol uh right now because that's that's an implementation detail so uh this is the Ros speec and um uh I I this part was not in the um in the in
The Ether pad or or on GitHub this is currently on on uh on on both and um and and as can be seen uh it needs to be cleaned up and formalized um and I think it would be helpful to have some diagrams um so that uh so that the implementations uh are similar so next steps um in addition to to implementing this um um is uh is peer Discovery constraints um on the way that the flow control system works um and and that will imply guarantees and that will also
um that will also imply that uh we will have some insight into into what's happening on the network at scale when we're doing uh testing and simulations um uh and things like that because we can we can we can log we can log what's happening with flow control and change some parameters and then and then see what happens and so essentially uh we can actually work over over a long period of time to optimize the throughput of the entire network to optimize the throughput and the latency of the of the entire network um and uh and and uh what what RPX does is it just
says that uh uh uh that that we have Framing and and that there's information that the peers will send uh Delta window updates uh back back and forth with each other um and then the peer rating system um which uh which is definitely an implementation detail um that's not a part of this um but it's a part of Li P2P so that an an application that is actually appear PE to-peer application um and and depends on an exchange of peer-to-peer messages um uh can ensure that it's connecting to to good peers for what it
needs um so maybe your needs are swarm right now and you aren't Mining ethereum and you don't need to download all of the you know you're just doing transactions and and swarm um because you're using simple payment verification um and uh and so you'll want you'll want good peers that that provide uh responsive simple payment verification and obviously uh however swarm works that could be another protocol um or another implementation but uh um yeah so you're ratings okay um that that that's it so e