orderwatch: Rare double re-org race-condition that can lead to missed order events

[fabioberger]

Currently, a rare race-condition exists in Mesh that could cause it to miss some order events for newly added orders. We are currently unable to validate incoming orders at a specific block hash and must instead rely on validating them at a specific block number. Since a re-org could cause differing blocks to have the same block number at different points in time, after a validation completes, we check to ensure that no block re-org occured while it was ongoing.

In the rare event that a block gets re-org'd out before we valid an order, and gets re-org'd back in after we finish our validation, there is still a change that our validation is not performed against the right block.

EIP1898 solves this problem but allowing us to validate orders at a specific block hash. Once it is supported in Parity, Geth, Infura and Alchemy, we should refactor our code to use it. It describes the above double re-org in it's rationale section.

Current status of EIP1898

• EIP approved
• Geth support released in v1.9.6
• Parity beta support released in v2.6.5 beta
• Infura uses Geth exclusively now, and they are on version v1.9.7, so they support it
• Alchemy only supports stable releases of Parity, so they do not support this EIP yet. Once they do, we should switch over to using it in Mesh.