Depreciate the graph for indexing statistics #15

New Issue

2022-12-27T18:31:53+03:00

gozzy commented

2022-12-27 18:31:53 +03:00

(Migrated from development.tornadocash.community)

After the censorship from the previous tornado subgraph that was apart of the graph protocol's hosted service, efforts were taken to depreciate it in place of legacy RPC event indexing.

Although when it came to fetching a subset of the most recent events, it is proving inefficient to fetch events in a reverse order; as there is arbitary dispersed ranges that can span over magnitudes of 10,000 block increments.

Not only does this add a UX hurdle when attempting to browse the anonymity sets but some sets have insufficient events to even fufill such subset. We need a lightweight and censorship resistant solution not at the expense of the onboarding flow.

After the censorship from the previous tornado subgraph that was apart of the graph protocol's hosted service, efforts were taken to depreciate it in place of legacy RPC event indexing. Although when it came to fetching a subset of the most recent events, it is proving inefficient to fetch events in a reverse order; as there is arbitary dispersed ranges that can span over magnitudes of 10,000 block increments. Not only does this add a UX hurdle when attempting to browse the anonymity sets but some sets have insufficient events to even fufill such subset. We need a lightweight and censorship resistant solution not at the expense of the onboarding flow.

Sign in to join this conversation.