Skip to content

Support correlating different watchers #135

@SebastienGllmt

Description

@SebastienGllmt

Right now, the design of utxorpc is such that you have to create multiple watchers for different actions

The problem with the current design is that it makes it hard to know if you've received all the data up to a specific block. For example, imagine you have two watchers A and B:

A receives event for block 30
B received event for block 40

You can't know if this means there are no events for A at block 31, or if it's just because you haven't received the result yet. Even worse, you don't even know if the event for B is the only event for block 40 (there maybe more you just haven't seen yet)

There are a few ways to solve this problem I think:

  1. Instead of watching, poll with a max slot. Since you're providing a max slot for the request, you know there is no data up to that slot once you get the return (downside: polling frequently is less efficient than watching). This is basically equivalent to allowing DumpHistory to have filters similar to the search endpoints
  2. Return objects that indicate a lack of any events (ex: at block 41, there are no events for B) or, equivalently (but perhaps more efficiently when syncing from genesis) no event up to a certain point (ex: there are no events for B for the range [28, 41])

Note that in either case, this has a non-trivial increase in the number of requests made. In Ethereum land, they try to solve this by allowing you to combine multiple watchers as a single request (see eth_subscribe and eth_newFilter), but these are non-trivial to implement and require server-side state (which maybe goes against the design of utxorpc if the goal is to be stateless)

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions