0x Mesh Architecture Doc

Hi everyone! Since announcing our plans to build 0x Mesh, we have been hard are work putting the finishing touches on our architecture doc outlining it’s MVP design.

0x Mesh MVP Architecture Doc

We would love to hear your thoughts and answer any questions you might have about the proposed design. Although we have begun building 0x Mesh, we are still open to valuable contributions and improvements to the proposed design. Feel free to post your suggestions & questions in this thread.



Excited for this new architecture, esp the low barrier-to-entry for potential 0x mesh relayers.
Questions and comments at first glance:

1/ Introducer. Noted that the nomenclature used is “Introducer”, which does not necessarily indicate that its a more traditional Signaling server used in WebRTC architectures. Ex: “We have only one introducer.” Will introducer be a centralized signaliing server or will it be some other mechanism? What other options are under consideration? Will “introducing” be connected to ZRX token in any way?

2/ Arbitrary messages and/or data. Would it be possible to include arbitrary messages/data among trusted peers (that does not incur gas overhead) ? Could this be integrated with the “project agnostic introducer layer” you mention in the Limitations & Extensions section?

3/ Database storage. Sorry if i am being dense, can’t tell if this is what is hinted at here or not: Would it be possible to make on-disk storage less opinionated than current relayer iteration that uses Sqlite? Have you considered key/value pairs with some sort of routing table instead? maybe this is what you are hinting at already(?)

4/ Ether reserve. Would this mechanism create an oligopoly of network spammers who keep a high reserve of the reserve token in order to censor others or hog bandwidth ?

5/ Neighborhood establishment aglorithm and physical location: Yes please!

Nice work.


1/ Unfortunately a lot of the existing p2p terminology for centralized components (signaling server, rendezvous server, tracker, etc…) are overloaded with multiple definitions. We chose “Introducer” because unlike other constructions, it’s sole role is to facilitate the WebRTC handshake. Peer discovery will probably also be provided, but the Mesh node will be implemented such that it could use a whole host of other peer discovery mechanisms (e.g., DHTs, bootstrap lists/nodes, etc…) and will not be limited to using a centralized entity to do so. It will be centralized for the MVP release but we plan to decentralize this part of the network before the 1.0 release. We are considering a construction where peers could be introduced on any arbitrary introducer server that happens to be online and available. One could imagine peers adding their peer ids to a DHT, along with the URL of the signaling server they have associated themselves with. A peer wishing to connect would connect to the specified signaling server and request an introduction to that peer. This is not very different from the current construction, but in order to make sure a signaling server is available and has high uptime, we intend to implement and run the first one as well as hard-code it’s use into every 0x Mesh node.

2/ There is no concept of gas in the 0x Mesh network. Can you elaborate on what you mean by this?

3/ Unfortunately the on-disk storage used for operating the 0x Mesh node will be opinionated. The current iteration is using LevelDB which is a low-level key/value store. We do not intend for relayers to query this data-store directly. Rather, a WS endpoint will be provided that will deliver a stream of discovered orders, as well as order state updates for stored orders (filled, cancelled, expired, etc…). Our intention is for an operator/relayer to ingest this stream and store/update the orders in a database of their choice. This operator-chosen database will power a relayer’s API & frontend, and it can be optimized for such use-cases.

4/ The reserves required by a spammer are much higher then those required by an honest user. A users reserve gets divided by the number of orders they send into the network. As such, a spammer with a balance of 10 ETH and 10,000 orders in the network can have it’s order displaced by any user with 0.0011 ETH and a single order (displacements only happens once nodes hit full capacity). Remember that orders take up very little space and therefore the total capacity per node in the network is quite high. Because of this, we expect the ETH requirements to start out at slightly above zero (ask me about this if you are curious why not 0). As the network becomes more popular and grows, the ETH requirement will raise slightly, but when nodes are at capacity, it’ll still be very easy for genuine users to replace the orders of spammers. Since ETH has a real world value, and one must have control over the private key in order to use them as “reserves”, it’ll be hard for spammers to borrow ETH to conduct an attack. They will need to own the ETH, and cannot use it for other purposes while maintaining the attack.

5/ Haha, noted. That will make order spreading much more efficient. We just need to do it properly so that we maintain a desirable network topology.

Feel free to ask any follow-up questions.

1 Like

If I want to pass arbitrary data to peers in the mesh network, in this design I would have to somehow add the data into 0x orders. When I discussed it with Jacob earlier he gave the example of the 0x Dutch Auction contract where additional data can be added to the assetData field of an order. He also pointed out that adding an additional field for arbitrary data would cost all users of the mesh network more gas once the orders are filled. So I suppose I’m looking for an efficient way to send arbitrary data, but maybe that could be handled by integrating a level up from the 0x orders, at the Introducer level, once the mesh swarms are broken out into sub-networks of markets (?).

3/ Very cool re: on-disk architecture. I just wanted to make sure that it would still have the flexibility for operators that it currently has under v2. Big fan of LevelDB and it sounds like this setup would lend itself to what I want to do for scaling. Thanks

One final question: Has anyone proposed a ZEIP for a 0x Escrow smart contract? Once you add in the location-based discovery, it opens up interesting use-cases for exchanging goods & services. So the scenario would be:

  • I hold an auction for my service
  • I accept a bid
  • Bidders tokens are locked in escrow contract
  • I perform the service
  • Bidder is satisfied with service delivered, bidder tokens are released to my address

I see. If the extra data must be sent on-chain then you could add it to the assetData fields of an order. If it’s needed for your application but not used on-chain, your other option will be to create a sub-network of peers that share 0x orders + metadata. This will be possible post-MVP and makes sense if the assets being traded in the sub-network need this additional metadata to be useful.

What additional data did you have in mind?

I don’t think anyone has written a ZEIP for an escrow contract.

Re: Additional data we might want to tack on:

  • Location
  • Keywords
  • Urls

And yes – the subnetwork of peers that share orders + metadata post-MVP would be GREAT. (and you are correct – the data would not be required on-chain at all so that sounds like an excellent solution)