Skip to content
This repository has been archived by the owner on Feb 1, 2019. It is now read-only.

P2P sharding network(s) #34

Open
jamesray1 opened this issue Apr 17, 2018 · 13 comments
Open

P2P sharding network(s) #34

jamesray1 opened this issue Apr 17, 2018 · 13 comments
Assignees
Labels
M4: core Core client code / Rust. P5: some time soon The issue is worth doing soon. phase 1 Refer to https://ethresear.ch/t/sharding-phase-1-spec/1407

Comments

@jamesray1
Copy link
Member

jamesray1 commented Apr 17, 2018

Have the ability of building and sending collations across those networks.

https://github.com/libp2p/specs

https://github.com/libp2p/rust-libp2p (this is a WIP), but devp2p is not maintained and is poorly documented, so it's still our best option.

@jamesray1 jamesray1 added the phase 1 Refer to https://ethresear.ch/t/sharding-phase-1-spec/1407 label Apr 17, 2018
@jamesray1
Copy link
Member Author

@jamesray1 jamesray1 added the help wanted Extra attention is needed label Apr 18, 2018
@jamesray1 jamesray1 changed the title 99 sharding peer to peer networks P2P sharding network(s) Apr 27, 2018
@jamesray1 jamesray1 self-assigned this May 10, 2018
@ltfschoen
Copy link
Collaborator

ltfschoen commented May 10, 2018

Please review the following questions that I've prepared after reading through the libp2p spec at https://github.com/libp2p/specs. Try to challenge/answer the questions collectively as a team:

  1. What libp2p protocol categories/roles and associated properties, security models, and respective network size are we using on each layer of our stack, and what are scenarios where multiple protocols would run simultaneously?
  1. What collection of transport protocols will we be running libp2p protocol over?
  1. i) What port(s) will we use on the libp2p network layer to perform operations for each of the transport protocols that we’ll be using?
    ii) What is an example scenario where we’ll be protocol multiplexing multiple transport protocols (i.e. UTP, UDT, WebSockets, SCTP, WebRTC, TCP Remy) through a single port?
    iii) What is an example scenarios where we'll be multiplexing reliable stream(s) or unreliable datagram(s) in a connection from an IPFS node to other node(s) on the a transport protocol in the network layer of the communication model?
    iv) What protocol(s) would we be mounting on top of libp2p with the connection?
    v) What type of connection would we be using?
    vi) What platforms and network setups will we need to libp2p to support?
    vii) How will we build a multiaddr-based network package module like go-multiaddr-net in Rust, for IPFS to delegate the transport dialing to, and for scoping the implementation of other transport protocols.
    viii) What portable format encodings do we need to use for protocol messages (i.e. protobuf)?
    ix) What are scenarios when we will use multistream, multistream-select, and Stream Multiplexing? What default multiplexor will we use with Stream Multiplexing (i.e. HTTP/2, SPDY, QUIC, or SSH)?
    x) How will we use Multicodecs for each IPFS Protocol that we use?
  1. i) How do we need to encrypt communications on libp2p for security in our implementation? Under what scenarios would users not need to operate with encrypted communications?
    ii) Is libp2p's application of cyphers with only a minimal portion of the whole TLS standard used sufficient for our implementation?
  1. i) How will users running a node behind a NAT traverse it in order to establish connections to peers in our implementation of libp2p's IPFS?
    ii) Will we use libp2p's ICE-like protocol for full NAT traversal or will we use a different NAT traversal library instead of libnice, such as libwebrtc or natty?
    iii) How will we check if our implementation of NAT traversal is interoperable?
    iv) How will we implement optional fallback to connection relaying communication as a transport that may be turned off by users to ensure a full connectivity graph?
  1. What network topologies will we be using for our system's routing mechanisms, peer discovery, and message propagation?
  1. i) What information will records (IPFS Linked Data) in our network store for discoverability?
    ii) How will we use libp2p to locate resources in the network and side channels?
    Reference: https://github.com/libp2p/specs/blob/master/3-requirements.md#37-resource-discovery

  2. What libp2p messaging protocols will we let users use after they open a new stream and register a stream handler and why?

  1. How will we adopt naming conventions in our implementation of the network?
  1. What is a scenario where different libp2p subsystem interfaces (i.e. Peer Routing, Swarm, Distributed Record Store, and Discovery) would use each other in our system implementation?
    Reference: https://github.com/libp2p/specs/blob/master/4-architecture.md#4-architecture

  2. What Peer Routing subsystem mechanism will we implement and why?
    Reference: https://github.com/libp2p/specs/blob/master/4-architecture.md#41-peer-routing

  3. What are different Swarm scenarios that we need to handle (where we are using a stream)?

  1. What Distributed Record Store system will we use and why?
  1. i) What Discovery Protocols will we use and for what scenarios?
    ii) Will our Discovery Protocol need encrypted discovery beacons (i.e. mDNS)?
    iii) Would we use a Bootstrap-List Discovery Protocol and make it use configurable?
  1. Which of the libp2p modules (transports) listed at the following reference link will we be using with the Rust implementation of libp2p https://github.com/libp2p/rust-libp2p?
  1. How will we use the Swarm Dialer?

@jamesray1
Copy link
Member Author

I don't think we'll use Swarm as data will be stored on the blockchain, but it could also be done with Swarm as a complementary storage service.

i) How will users running a node behind a NAT traverse it in order to establish connections to peers in our implementation of libp2p's IPFS?

For discovery mDNS-discovery looks like a low priority since it's designed for LANs. random-walk seems like it may be a good candidate. Due to the partial trust with bootstrap list, that is another low priority / enhancement alternative.

For relay when it is not feasible to reach a peer through a NAT, https://github.com/libp2p/specs/tree/master/relay would be useful, however rust-libp2p is unfortunately not listed as an implementor of it.

@jamesray1
Copy link
Member Author

libp2p/rust-libp2p#187

@jamesray1 jamesray1 added M4: core Core client code / Rust. meta P5: some time soon The issue is worth doing soon. and removed M4: core Core client code / Rust. meta help wanted Extra attention is needed labels May 14, 2018
@jamesray1
Copy link
Member Author

jamesray1 commented May 20, 2018

@jamesray1
Copy link
Member Author

rustlib-p2p has implemented relay-0.1.0: https://github.com/libp2p/rust-libp2p/tree/master/relay.

@jamesray1
Copy link
Member Author

jamesray1 commented May 25, 2018

I'll probably implement gossipsub since it is preferable to floodsub.

@jamesray1
Copy link
Member Author

#94

@jamesray1
Copy link
Member Author

"Exploring Ethereum on libp2p" libp2p/libp2p#33 (comment)

@jamesray1
Copy link
Member Author

jamesray1 commented Jun 5, 2018

I just want to clarify that we don't need to design a libp2p implementation from scratch, a lot of work has already been done with rust-libp2p, plus other Rust modules. I've created a wiki page with your questions here, and will try to answer them in due course.

@jamesray1
Copy link
Member Author

I've answered about half of the questions, might come back to them some time later after writing gossipsub and looking at other priorities.

@ghost
Copy link

ghost commented Jun 25, 2018

@jamesray1 hey, I'll be joining the meetings in Berlin later this week for the libp2p team and starting to prep for it -- is the current state of the questions in the comment above or on the wiki page you mentioned?

@jamesray1
Copy link
Member Author

jamesray1 commented Jun 25, 2018

@lgierth hi, it's on the wiki page. I haven't bothered to answer all of them yet as I was tending to repeat myself by referring back to rust-libp2p, which Luke didn't seem to be aware of.

Right now I'm reading through tokio (a Rust crate for async networking), and before that was reading up on libp2p, rust-libp2p, Go, gossipsub, etc. Will start developing gossipsub soon.

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
M4: core Core client code / Rust. P5: some time soon The issue is worth doing soon. phase 1 Refer to https://ethresear.ch/t/sharding-phase-1-spec/1407
Projects
None yet
Development

No branches or pull requests

2 participants