5 ms·

Show HN: Ouroboros – A Decentralized Packet Network

116 points by despair3435 7y ago

jqueryin 7y ago
And here I was thinking this was directly related to the Cardano project. https://www.cardano.org/en/ouroboros/ https://www.cardano.org/en/ouroboros/ https://iohk.io/en/research/library/papers/ouroborosa-provably-secure-proof-of-stake-blockchain-protocol/ https://iohk.io/en/research/library/papers/ouroborosa-provab...
- geoah 7y ago
  Something that always bugged me with cardano's Ouroboros is the name. Ouroboros means eating (usually your own) tail, and the symbol that usually goes with it is a snake/dragon as a loop/circle. Blockchain is basically an ever expanding chain (or tree if you include the shorter branches that didn't make it) so I can't understand the relation to ouroboros loop/circle. I assume they have a different reason for naming it that but didn't ever find it.
  - exdsq 7y ago
    I understood it to be that Ouroboros went around the world? And Jormungandr is a type of Ouroboros (the Rust implementation of Ourorboros).
  - despair3435 7y ago
    We chose Ouroboros since there is a single type of network layer that can be repeated ad infinitum, similar to the dragon eating its own tail.
hardwaresofton 7y ago
Ouroboros is really cool, here's their old site: https://ouroboros.ilabt.imec.be/index.html https://ouroboros.ilabt.imec.be/index.html And a direct link to a fantastic introductory video from FOSDEM: https://www.youtube.com/watch?v=6fH23l45984 https://www.youtube.com/watch?v=6fH23l45984 I'm really interested in ouroboros as a transit layer for systems like kubernetes -- of course you have to kind of rethink the interconnections between resources an but ouroboros look simple and cleanly composable -- it really feels like it could fit well.
- lapinot 7y ago
  Hi, i watched the video but they didn't seem to talk about something i would find important in the description of a packet network: what's the routing algorithm? Is there actually any? If this is meant to run large-scale only on top of some ip network using already configured routing tables then this lowers the interest a lot for me: this ends up "just" being another overlay network, albeit with cool concepts and pretty adaptable tunneling possibilities.
  - despair3435 7y ago
    The routing algorithm can be chosen in every layer, as addressing is per layer. We didn't reinvent the algorithms. So it would still be link state, distance vector, geometric routing, ... Since the addressing is internal to the layer, you probably won't have the same issues with geometric routing as currently in TCP/IP. Ouroboros can run over the current internet so you can reuse existing hardware, but the end goal is to get rid of TCP/IP. We have layers over L1 and L2. In lab setups we never run it over TCP/IP.
    - 0xdeadbeefbabe 7y ago
      If there were an internet what routing algorithm would it use?
      - hardwaresofton 7y ago
        As the previous commenter stated, since you can choose the routing algo at every layer, you could completely reproduce the current internet -- or choose to implement something better on some axis.
- challenged 7y ago
  But what problem does it solve? How is it better than what we have? What are the practical uses? What is a concrete example of the benefits? I read the documentation and the FAQ, but it's all very nebulous. It's supposedly better, but no explanation is given to how or in what way. I'd love to have a clear and understandable answer. I'm sure the project would benefit from having such an explanation on their web page.
bn7t 7y ago
Is this similar to cjdns or yggdrasil?
- despair3435 7y ago
  No, Ouroboros rethinks the whole network architecture, from the ground up. cjdns and yggdrasil build on top of IPv6, which we believe has the same architectural flaws as IPv4.
  - neilalexander 7y ago
    For accuracy, Yggdrasil doesn't "build on top of IPv6", it merely uses IPv6 over TUN in the current binaries because that most closely translates to a usable experience for real people today without having to rewrite their applications. It has been a good way to get users to help scale-test. The underlying routing scheme, virtual switch/router implementation, specification etc are not aware of (nor do they care about) IP.
LockAndLol 7y ago
Isn't IP implemented at the hardware level nowadays? Is it still possible to buy any consumer-grade network hardware that allows to replace IP? It would be great if the site presented a side-by-side comparison of IP vs ouroboros (and had an acronym btw) for people to have a quick overview instead of digging through documentation.
- convolvatron 7y ago
  there may be various kinds of accelerations...but it pretty much has to be possible to send and receive ethernet frames (edit: and operationally you probably want to just make an overlay/tunnel network to develop your new network layer)
  - dstaesse 7y ago
    In most of our Ouroboros deployments (meaning: in the lab) we did just that. We use a raw packet interface (bpf on mac, raw sockets on linux) and send Ouroboros traffic on top of Ethernet. The fun thing is that when we compared throughput to UDP/IP, Ouroboros is a bit slower for packets below 1460 bytes, because the NIC has something called "Generic Segment Offload (GSO)" which cheats a bit and send UDP traffic as larger chunks over the kernel boundary. We have no such optimization (yet). But when we started sending jumbo frames, Ouroboros was faster than UDP/IP over Ethernet because the GSO wasn't implemented for UDP jumbo frames (not pointing fingers, nobody does that). And this brings me to another thing. Nitpicking of course. But that is what Ouroboros is about. Picking all the nits we could find. It's one for the connoisseurs. Ethernet has a minimum frame size that is dictated by Layer 1 and has to do with collision detection and the transmission delay/cable length. For good ol' 10 base-T it's 64 bytes. For GbE the minimum frame size for Ethernet is 512 bytes. Small Ethernet frames under 64 bytes are called runt frames. Ethernet has a length field to allow for padding. Now the interesting part in the standards. Ethernet frames are padded to 64 bytes. But GbE ethernet frames are not padded to 512 bytes. They use something called carrier extension (and frame bursting, but let's not complicate things too much). So there is a Layer 1 problem (minimum frame size because of cable length). The original Ethernet "fixed" this with a LENGTH field in Layer 2. While the receiver was reading the correct amount of received bytes, if it was 64, it could mean a padded Ethernet frame. Ethernet II (DIX) made things worse. The Ethernet length field is now interpreted as an EtherType, indicating the Layer 3 protocol. And the layer 3 protocol now has to have a length field to fix the Layer 1 problem. Sigh. GbE solves it right here, right now. It does carrier extension and reports the correct amount of bytes to layer 2. But it pads to 64 bytes for compatibility. Ouroboros' protocols have no length field. Read the details on the heartbleed bug if you want to know why this matters.
slumdev 7y ago
Are there any papers on this? I can only find references to the consensus algorithm.
- despair3435 7y ago
  We have a paper under review (since a year) describing the architecture in detail. We plan to extend the documentation on the website in the meantime. As a sidenote: Our implementation predates the Cardano blockchain name
- lapinot 7y ago
  Can't find anything either, not sure if there is. On the other hand, they seem to reference research done around "Recursive InterNetwork Architecture" (RINA). Publication page is at [0]. Maybe also of interest some other RINA implementations: [1], [2]. [0] http://www.pouzinsociety.org/research/publications http://www.pouzinsociety.org/research/publications [1] https://irati.github.io/stack/ https://irati.github.io/stack/ [2] https://github.com/rlite/rlite https://github.com/rlite/rlite
gz5 7y ago
very promising - looking forward to digging in and seeing the architecture. i like the developer focus, e.g. use the C library to write ouroboros-native programs. from a developer perspective, what types of developers for what types of use cases would benefit the most by leveraging ouroboros?
magdemsolrem 7y ago
I'm fairly new to decentralization technology and web3, how would this relate to let's say libp2p?
still_grokking 7y ago
How does this relate to GNUnet? The high level description could be the exact same for both. So how architecture and implementation differ?
deleted 7y ago
[deleted]
drummer 7y ago
I read the overview and it sounds a lot like QuantumGate http://quantumgate.org/ http://quantumgate.org/
- dstaesse 7y ago
  I looked at Quantumgate and it looks interesting :) Thanks for the pointer!
firethief 7y ago
I want to like it for the cleaner architecture, but this site isn't helping me find reasons to do so. The FAQ seems to be the only place that "Why would I want this" is considered, and they evade a real answer. I'm sure the referenced paper supports that it's theoretically cool, but I already believe that. The only concrete benefit I see proposed is that it has a simpler API, but considering that they've punted on name resolution (for now) and async is a WIP, the API seems more complicated than BSD sockets--which everyone has experience with, has support in every language and framework, and has endless learning materials available. For a project whose value depends on a networking effect, I'm not compelled to invest energy in it until they get their marketing act together enough that I think other people might want it too.
- hardwaresofton 7y ago
  Please check out the FOSDEM video: https://www.youtube.com/watch?v=6fH23l45984 https://www.youtube.com/watch?v=6fH23l45984 The ideas take a while to sink in but @ 1.5/2x speed it should be a quick watch and you can slow down if you hear something you like. Hopefully they get their "marketing act together" but also it's probably unreasonable to expect that from what was once a research project and is now very early software (that I assume they are trying to commercialize/market somehow, hence the spiffy new site).
  - dstaesse 7y ago
    I'm sorry to disappoint, but we are not looking at commercializing... Ouroboros will remain free "as in beer" and free "as in freedom". I do take "spiffy" as a compliment :)
    - hardwaresofton 7y ago
      > I'm sorry to disappoint, but we are not looking at commercializing... Ouroboros will remain free "as in beer" and free "as in freedom". Aaaaand you've just gained me as a lifelong fan (I mean I was already very interested) -- that's a big stand to take, and I appreciate that you guys refreshed the site & marketing materials just to get it in front of more people. I'm not in any way disappointed by your choice not to commercialize, quite the opposite in fact (as long as you guys are personally fine financially and feel comfortable contributing this work to the public domain). You'll hear from me when I build something worth mentioning with Ouroboros!
dstaesse 7y ago
I'm one of the developers. Thank you all for your interest in this project. This website is still under construction, and we're well aware that it's severely lacking in information, I'll try to find some time to update everything. Unfortunately marketing is not one of my skills. The cleaner architecture is the whole point of the exercise. I'm trying to avoid arguments why this would be "better" than anything else. Just some examples of things that I personally don't like about IP, and that Ouroboros does differently. These points may not matter to you, and that is perfectly fine. I'm not a salesman trying to make a sell. 1) IP (and Ethernet etc) has source addresses in every packet. Ouroboros negotiates them at the start of the communication, and only has the destination address in the packets. This improves end-user privacy a great deal. 2) The Ouroboros end-to-end protocol, (which has the RTT estimator and retransmisison timeout (RTO) timer), runs in the library between the actual server and client programs. It runs at sub-millisecond accuracy. If there is an underestimation of RTT, at worst it retransmits a few extra packets (See 3). But these improve the RTT estimate. 3) Default TCP congestion control doesn't play nice in lossy situations, having severe issues with throughput because of AIMD. Ouroboros completely splits the network and end-to-end protocol. Therefore the architecture only allows congestion control using Forward ECN at the network protocol (and only the network protocol). This is similar to the operation of DCTCP, but DCTCP has the ECN in the network protocol (IP), and the notification in the end-to-end protocol (TCP). I'm not fond of that as a solution (however, if I would run a commercial datacenter, I would run DCTCP, no doubt about that). 4) The Ouroboros end-to-end protocol is based on Delta-t, which doesn't require the 3-way handshake of TCP. It does have a two-way handshake (called flow allocation) to negotiate endpoints and the peer addresses (as to avoid sending src in every packet). But it can also do a ECDHE key exchange at that time. So it can establish an encrypted end-to-end connection in 1 RTT. The implementation still does it in 2 phases, (it's on my to-do list to piggyback the public keys). 5) Ouroboros has 2 types of layers, one for unicast and one for broadcast. This is where I think it really shines. The broadcast layer allows easy implementation of what is known as a "multicast service". A PoC is in the obc program. Some of this may still seem nebulous, and I apologize. It's an unfunded pet project. But if I find interested people that ask interested questions, it will help me to update the documentation and make things more digestible/palatable. Thank you again for your interest.
- 7y ago

116 points by despair3435 7y ago

And here I was thinking this was directly related to the Cardano project. https://www.cardano.org/en/ouroboros/ https://www.cardano.org/en/ouroboros/ https://iohk.io/en/research/library/papers/ouroborosa-provably-secure-proof-of-stake-blockchain-protocol/ https://iohk.io/en/research/library/papers/ouroborosa-provab...

geoah 7y ago
Something that always bugged me with cardano's Ouroboros is the name. Ouroboros means eating (usually your own) tail, and the symbol that usually goes with it is a snake/dragon as a loop/circle. Blockchain is basically an ever expanding chain (or tree if you include the shorter branches that didn't make it) so I can't understand the relation to ouroboros loop/circle. I assume they have a different reason for naming it that but didn't ever find it.
- exdsq 7y ago
  I understood it to be that Ouroboros went around the world? And Jormungandr is a type of Ouroboros (the Rust implementation of Ourorboros).
- despair3435 7y ago
  We chose Ouroboros since there is a single type of network layer that can be repeated ad infinitum, similar to the dragon eating its own tail.

hardwaresofton 7y ago

Ouroboros is really cool, here's their old site: https://ouroboros.ilabt.imec.be/index.html https://ouroboros.ilabt.imec.be/index.html And a direct link to a fantastic introductory video from FOSDEM: https://www.youtube.com/watch?v=6fH23l45984 https://www.youtube.com/watch?v=6fH23l45984 I'm really interested in ouroboros as a transit layer for systems like kubernetes -- of course you have to kind of rethink the interconnections between resources an but ouroboros look simple and cleanly composable -- it really feels like it could fit well.

lapinot 7y ago
Hi, i watched the video but they didn't seem to talk about something i would find important in the description of a packet network: what's the routing algorithm? Is there actually any? If this is meant to run large-scale only on top of some ip network using already configured routing tables then this lowers the interest a lot for me: this ends up "just" being another overlay network, albeit with cool concepts and pretty adaptable tunneling possibilities.
- despair3435 7y ago
  The routing algorithm can be chosen in every layer, as addressing is per layer. We didn't reinvent the algorithms. So it would still be link state, distance vector, geometric routing, ... Since the addressing is internal to the layer, you probably won't have the same issues with geometric routing as currently in TCP/IP. Ouroboros can run over the current internet so you can reuse existing hardware, but the end goal is to get rid of TCP/IP. We have layers over L1 and L2. In lab setups we never run it over TCP/IP.
  - 0xdeadbeefbabe 7y ago
    If there were an internet what routing algorithm would it use?
    - hardwaresofton 7y ago
      As the previous commenter stated, since you can choose the routing algo at every layer, you could completely reproduce the current internet -- or choose to implement something better on some axis.
challenged 7y ago
But what problem does it solve? How is it better than what we have? What are the practical uses? What is a concrete example of the benefits? I read the documentation and the FAQ, but it's all very nebulous. It's supposedly better, but no explanation is given to how or in what way. I'd love to have a clear and understandable answer. I'm sure the project would benefit from having such an explanation on their web page.

bn7t 7y ago

Is this similar to cjdns or yggdrasil?

despair3435 7y ago
No, Ouroboros rethinks the whole network architecture, from the ground up. cjdns and yggdrasil build on top of IPv6, which we believe has the same architectural flaws as IPv4.
- neilalexander 7y ago
  For accuracy, Yggdrasil doesn't "build on top of IPv6", it merely uses IPv6 over TUN in the current binaries because that most closely translates to a usable experience for real people today without having to rewrite their applications. It has been a good way to get users to help scale-test. The underlying routing scheme, virtual switch/router implementation, specification etc are not aware of (nor do they care about) IP.

LockAndLol 7y ago

Isn't IP implemented at the hardware level nowadays? Is it still possible to buy any consumer-grade network hardware that allows to replace IP? It would be great if the site presented a side-by-side comparison of IP vs ouroboros (and had an acronym btw) for people to have a quick overview instead of digging through documentation.

convolvatron 7y ago
there may be various kinds of accelerations...but it pretty much has to be possible to send and receive ethernet frames (edit: and operationally you probably want to just make an overlay/tunnel network to develop your new network layer)
- dstaesse 7y ago
  In most of our Ouroboros deployments (meaning: in the lab) we did just that. We use a raw packet interface (bpf on mac, raw sockets on linux) and send Ouroboros traffic on top of Ethernet. The fun thing is that when we compared throughput to UDP/IP, Ouroboros is a bit slower for packets below 1460 bytes, because the NIC has something called "Generic Segment Offload (GSO)" which cheats a bit and send UDP traffic as larger chunks over the kernel boundary. We have no such optimization (yet). But when we started sending jumbo frames, Ouroboros was faster than UDP/IP over Ethernet because the GSO wasn't implemented for UDP jumbo frames (not pointing fingers, nobody does that). And this brings me to another thing. Nitpicking of course. But that is what Ouroboros is about. Picking all the nits we could find. It's one for the connoisseurs. Ethernet has a minimum frame size that is dictated by Layer 1 and has to do with collision detection and the transmission delay/cable length. For good ol' 10 base-T it's 64 bytes. For GbE the minimum frame size for Ethernet is 512 bytes. Small Ethernet frames under 64 bytes are called runt frames. Ethernet has a length field to allow for padding. Now the interesting part in the standards. Ethernet frames are padded to 64 bytes. But GbE ethernet frames are not padded to 512 bytes. They use something called carrier extension (and frame bursting, but let's not complicate things too much). So there is a Layer 1 problem (minimum frame size because of cable length). The original Ethernet "fixed" this with a LENGTH field in Layer 2. While the receiver was reading the correct amount of received bytes, if it was 64, it could mean a padded Ethernet frame. Ethernet II (DIX) made things worse. The Ethernet length field is now interpreted as an EtherType, indicating the Layer 3 protocol. And the layer 3 protocol now has to have a length field to fix the Layer 1 problem. Sigh. GbE solves it right here, right now. It does carrier extension and reports the correct amount of bytes to layer 2. But it pads to 64 bytes for compatibility. Ouroboros' protocols have no length field. Read the details on the heartbleed bug if you want to know why this matters.

slumdev 7y ago

Are there any papers on this? I can only find references to the consensus algorithm.

despair3435 7y ago
We have a paper under review (since a year) describing the architecture in detail. We plan to extend the documentation on the website in the meantime. As a sidenote: Our implementation predates the Cardano blockchain name
lapinot 7y ago
Can't find anything either, not sure if there is. On the other hand, they seem to reference research done around "Recursive InterNetwork Architecture" (RINA). Publication page is at [0]. Maybe also of interest some other RINA implementations: [1], [2]. [0] http://www.pouzinsociety.org/research/publications http://www.pouzinsociety.org/research/publications [1] https://irati.github.io/stack/ https://irati.github.io/stack/ [2] https://github.com/rlite/rlite https://github.com/rlite/rlite

gz5 7y ago

very promising - looking forward to digging in and seeing the architecture. i like the developer focus, e.g. use the C library to write ouroboros-native programs. from a developer perspective, what types of developers for what types of use cases would benefit the most by leveraging ouroboros?

magdemsolrem 7y ago

I'm fairly new to decentralization technology and web3, how would this relate to let's say libp2p?

still_grokking 7y ago

How does this relate to GNUnet? The high level description could be the exact same for both. So how architecture and implementation differ?

deleted 7y ago

[deleted]

drummer 7y ago

I read the overview and it sounds a lot like QuantumGate http://quantumgate.org/ http://quantumgate.org/

dstaesse 7y ago
I looked at Quantumgate and it looks interesting :) Thanks for the pointer!

firethief 7y ago

I want to like it for the cleaner architecture, but this site isn't helping me find reasons to do so. The FAQ seems to be the only place that "Why would I want this" is considered, and they evade a real answer. I'm sure the referenced paper supports that it's theoretically cool, but I already believe that. The only concrete benefit I see proposed is that it has a simpler API, but considering that they've punted on name resolution (for now) and async is a WIP, the API seems more complicated than BSD sockets--which everyone has experience with, has support in every language and framework, and has endless learning materials available. For a project whose value depends on a networking effect, I'm not compelled to invest energy in it until they get their marketing act together enough that I think other people might want it too.

hardwaresofton 7y ago
Please check out the FOSDEM video: https://www.youtube.com/watch?v=6fH23l45984 https://www.youtube.com/watch?v=6fH23l45984 The ideas take a while to sink in but @ 1.5/2x speed it should be a quick watch and you can slow down if you hear something you like. Hopefully they get their "marketing act together" but also it's probably unreasonable to expect that from what was once a research project and is now very early software (that I assume they are trying to commercialize/market somehow, hence the spiffy new site).
- dstaesse 7y ago
  I'm sorry to disappoint, but we are not looking at commercializing... Ouroboros will remain free "as in beer" and free "as in freedom". I do take "spiffy" as a compliment :)
  - hardwaresofton 7y ago
    > I'm sorry to disappoint, but we are not looking at commercializing... Ouroboros will remain free "as in beer" and free "as in freedom". Aaaaand you've just gained me as a lifelong fan (I mean I was already very interested) -- that's a big stand to take, and I appreciate that you guys refreshed the site & marketing materials just to get it in front of more people. I'm not in any way disappointed by your choice not to commercialize, quite the opposite in fact (as long as you guys are personally fine financially and feel comfortable contributing this work to the public domain). You'll hear from me when I build something worth mentioning with Ouroboros!

dstaesse 7y ago

I'm one of the developers. Thank you all for your interest in this project. This website is still under construction, and we're well aware that it's severely lacking in information, I'll try to find some time to update everything. Unfortunately marketing is not one of my skills. The cleaner architecture is the whole point of the exercise. I'm trying to avoid arguments why this would be "better" than anything else. Just some examples of things that I personally don't like about IP, and that Ouroboros does differently. These points may not matter to you, and that is perfectly fine. I'm not a salesman trying to make a sell. 1) IP (and Ethernet etc) has source addresses in every packet. Ouroboros negotiates them at the start of the communication, and only has the destination address in the packets. This improves end-user privacy a great deal. 2) The Ouroboros end-to-end protocol, (which has the RTT estimator and retransmisison timeout (RTO) timer), runs in the library between the actual server and client programs. It runs at sub-millisecond accuracy. If there is an underestimation of RTT, at worst it retransmits a few extra packets (See 3). But these improve the RTT estimate. 3) Default TCP congestion control doesn't play nice in lossy situations, having severe issues with throughput because of AIMD. Ouroboros completely splits the network and end-to-end protocol. Therefore the architecture only allows congestion control using Forward ECN at the network protocol (and only the network protocol). This is similar to the operation of DCTCP, but DCTCP has the ECN in the network protocol (IP), and the notification in the end-to-end protocol (TCP). I'm not fond of that as a solution (however, if I would run a commercial datacenter, I would run DCTCP, no doubt about that). 4) The Ouroboros end-to-end protocol is based on Delta-t, which doesn't require the 3-way handshake of TCP. It does have a two-way handshake (called flow allocation) to negotiate endpoints and the peer addresses (as to avoid sending src in every packet). But it can also do a ECDHE key exchange at that time. So it can establish an encrypted end-to-end connection in 1 RTT. The implementation still does it in 2 phases, (it's on my to-do list to piggyback the public keys). 5) Ouroboros has 2 types of layers, one for unicast and one for broadcast. This is where I think it really shines. The broadcast layer allows easy implementation of what is known as a "multicast service". A PoC is in the obc program. Some of this may still seem nebulous, and I apologize. It's an unfunded pet project. But if I find interested people that ask interested questions, it will help me to update the documentation and make things more digestible/palatable. Thank you again for your interest.

7y ago