0x-mesh

0x-mesh copied to clipboard

In the core package, we currently wait for at least one block to be processed before connecting to any peers or validating any orders. We time out after 60 seconds if no block is processed. This causes Mesh to stop and return an error.

This creates two issues:

1. It introduces additional latency when loading Mesh for the first time. Connecting to peers can take a while and it's best to get started as soon as possible. This is particularly relevant for browser use cases.
2. For people using custom networks, it can take longer than 60 seconds for a block to be processed. Even on mainnet and some test networks, it is possible (though unlikely) for 60s to pass between blocks. This leads to Mesh timing out even though nothing is necessarily wrong. Augur specifically complained about this issue.

@fabioberger can we reconsider this mechanism or try and mitigate the issues above? If the main goal is to make sure we are not validating orders on older blocks, maybe we can do a parallel check at startup and stop waiting if the last known block is equal to getBlockByNumbeR("latest")? It also seems like we should go ahead and start the process of connecting to peers, even if we don't want to send them any orders yet.

I'll need to make changes to the p2p package in order to address point (1). Let's keep this issue open until then.