[On ice] Gossipsub: an extensible baseline pubsub protocol, based on randomized topic meshes and gossip

[jamesray1]

This partially implements the spec, with some variations around error handling and using message hashes and topic hashes. Control-message piggy-backing is not implemented, however you can graft_peers_to_topics(), graft_peer_to_topics(), graft_peers_to_topic(), graft_peer_to_topic(), and the same for prune. i_have(), i_want(), and heartbeat() are not implemented, as well as GossipSubConfig, floodsub compatibility, testing and examples. I suggest that it is reviewed in addition to #898, and could possibly be merged wtih that.

Gossipsub is a scalable, efficient, extensible baseline pubsub (publish-subscribe, messaging) protocol for p2p networks and decentralized applications on top of them.

See the spec here.

This is the specification for an extensible baseline pubsub protocol, based on randomized topic meshes and gossip. It is a general purpose pubsub protocol with moderate amplification factors and good scaling properties. The protocol is designed to be extensible by more specialized routers, which may add protocol messages and gossip in order to provide behaviour optimized for specific application profiles.

Unlike floodsub, which broadcasts or publishes a message of a topic to all peers that are subscribed to a topic in the network, gossipsub publishes to a subset of peers, known as the target mesh degree, which is chosen as 6 here and in go-gossipsub. Peers request messages of a topic with an IWant message and state what they have recently seen in their cache of messages with an IHave message. This gossipsub implementation in Rust, once complete, will be scalable for decentralized, p2p networks, unlike floodsub, and is thus suited for networks that aim to be mainstream, such as Ethereum 2.0 (as developed in Rust with paritytech/shasper and sigp/lighthouse), parity-ethereum, Polkadot, as well as any other p2p network that uses Rust.

Closes #521. Updated for the latest API with handlers like ProtocolsHandler and NodeHandler, NetworkBehaviour, Topology, etc.

Because gossipsub extends on floodsub and needs to be backwards compatible with it, gossipsub reimplements and adapts much of floodsub. Therefore, please let me know if any changes are made to floodsub, and avoid making changes if feasible.

Donations

Donations to jamesray.eth are appreciated via https://gitcoin.co/grants/42/gossipsub. Thanks to Philippe Castonguay, Peter Kieltyka and Ric Burton from 0xHorizon Games for a 30 ETH one-off donation. Donations also help for previous contributions towards Eth 2 development; Eth docs such as the wiki, Yellow Paper; reviewing research on https://ethresear.ch and papers such as Casper FFG and CBC; plus potential future contributions towards Ethereum development e.g. with paritytech/shasper, which unlike sigp/lighthouse uses substrate, providing various benefits e.g. modularity, flexibility, integration of Wasm, libp2p, GRANDPA consensus, blockchain interoperability, automatic upgradability and governance.

See these timesheets for details of previous contributions from June 2017 until now: https://tinyurl.com/DoDspsht and https://tinyurl.com/Ethtimesht. I think it seems reasonable to work on this full-time after I get ~$36000 USD or DAI / $50000 AUD per year, or $3000 DAI per month. That's not much, and is probably undervalued, particularly given ~1.25 years FTE has been mostly unfunded, but it's enough to work on gossipsub and Eth 2, which will of course be very useful. I will work on this in proportion to how much funding I have. >3000 DAI/m, FT. 1500 DAI/m, at least 18 hours per week, etc. By linear interpolation and dimensional analysis, H/w = X DAI/m / 3000 DAI/m * 35 h/w = X * 0.016667 hr/wk, if total funding per average month is less than 3000 DAI, otherwise at least 35 hours per week.

Grant applications

• Protocol Labs. Applied around June. They initially said that we should fund this, then requested a plan/timeline. I said I am not a big fan of them (probably because at that time I was still studying rust-libp2p, tokio, futures, libp2p, gossipsub, etc.) and would keep working on it. I think this was probably a dealbreaker for them.
• Ethereum Foundation (typeform): applied Jan 14 2019, also Jan 2018 for eth 2.0 development / Drops of Diamond, with which I have made several other grant applications for.
• Gossipsub w3f/General-Grants-Program#69: rejected since they are taking a different direction with messaging protocols, and referring me upon my querying to https://github.com/w3f/messaging.
• ECF: Jan 30 2019 (typeform)
• Aragon Nest Proposal: implementing Gossipsub aragon/nest#132
• Spoke with Sigma Prime about getting support for gossipsub development, however they also have limited funding and have a deadline to meet the Serenity testnet by the end of March, and feel that their implementation of gossipsub (Gossipsub Protocol #898) is sufficient for their needs.
• WeTrust

See also https://twitter.com/JamesCRay01/status/1082138888037003264.

[tomaka]

If gossipsub needs to be compatible with floodsub on the protocol layer, I don't think you need to duplicate everything. You should be able to add a dependency on libp2p-floodsub and use the FloodsubHandler from gossipsub.

[jamesray1]

Thanks for the suggestion, yeah I was thinking about this more.

[jamesray1]

I started duplicating FloodsubHandler and also relevant parts, but am thinking it may perhaps be better to nest a FloodsubHandler in a GossipsubHandler, although it remains to be seen how that will work.

// TODO: use the FloodsubHandler, figure out the best way to do so.
// Also probably don't need to re-implement the same functionality from
// Floodsub, just reuse from FloodsubHandler, and implement the
// additional functionality.
// Could either have a FloodsubHandler nested in a GossipsubHandler, or // reduplicate FloodsubHandler and other needed stuff. It seems like the
// former option might be best, but not sure.

[dvdplm]

Feel free to ping me when you want a review. :)

[jamesray1]

Sure, will do. I think I only need to duplicate FloodsubHandler and import the rest. But since FloodsubHandler is a struct I can't implement it as a trait for GossipsubHandler, so I think it needs to be nested within it.

[jamesray1]

Ah I think I'll use ProtocolsHandlerSelect.

[tomaka]

Theoretically I think that you only need to implement a Gossipsub struct that implements NetworkBehaviour and uses Floodsub.

[miketang84]

Hi, I am ready to do some works on this, what's your problem now when implementing? @jamesray1

[jamesray1]

@daogangtang, I've been preparing/working on gossipsub since June, but lately have been getting into development again. TBH it's probably simpler for me to just work on this solo. There are plenty of TODOs and issues in this repo, why not have a look at some of those and see if any of those wet your whistle?

[jamesray1]

Accidentally closed.

[jamesray1]

I think I'm going to stop working on this as it seems that it will not get funded due to #898 (@AgeManning working on the same project, while he has apparently made more progress, he is in the testing/debugging stage) while efforts on that are funded. I think it's best if I just get a job, I can't keep working on projects and not getting funded. I have been working with Ethereum since June 2017 without any funding from the industry, apart from the donation of 30 ETH listed above. Note that this almost completely implements the spec, with some variations around error handling and using message hashes and topic hashes, and with the exception of the heartbeat procedure and only graft actually notifies the grafted peer, with a node_inject_event. I suggest that it is reviewed in addition to #898.

[jamesray1]

I can't afford to keep self-funding development.