Do we want a transaction statistic?

[modersohn]

The Proxy singleton provides loads of interesting information, so I tried building a pie chart with the different transactions counts:

But honestly, after seeing it, I'm not sure if this is actually helpful? It shows that Swaps, Orderbooktrades and Transfers are the 3 big players and I doubt these numbers will change much in relation to each other.

I've stashed the changes away for now as there were still quite a few things to be done to consider this ready.

[fudgebucket27]

Maybe for more stats like this we could put it into a dedicated stats page which has these pretty graphs?

[modersohn]

Yeah I also thought about this, but out of the box, there's not much extra info that would make a good statistic.

But there's one thing I thought about: I think the graph in general is able to be queried up to a certain block "height". So if you would actually walk the graph down by decreasing the block-height, you could generate a timeline over all the stats in the proxy - and that could prove very interesting! Similar to that graph that is tweeted once in a while where you can see the number of wallets grow over time.

The thing is, querying that info is certainly quite "expensive", i.e. lot's of queries before you can generate a meaningful chart. Ideally we would need a persistent cache for that, after all the "old" information should never change (unless the code of the graph is changed and generates different info).

[modersohn]

So now that @danielsolistensvik has given this a shot with https://github.com/danielsolistensvik/LoopStats, I have some additional thoughts.

The current implementation of LoopStats is limited, because it relies on querying the graph at the right times to get the - at that moment - latest statistics from the proxy entity. That is also why it can't generate statistics for the past and couldn't regenerate it, should the graph change in the future. But all of these shortcomings could be solved by using queries with block height params (see example in my comment in #149).

But then what you end up with, is basically your own mechanism of what the graph actually does.

Just so we're on the same page: the subgraph indexes all Ethereum blocks and searches for interactions with the Loopring smart contract. It then parses this information to extract all the info that is stored in those blocks and generates different datasets of the various entities. If the code of the graph changes, it completely reindexes and regenerates everything.

So from a technical standpoint, I think it would be ideal if the graph would collect and store that statistic, just like it already does for volumes and prices of pairs.

But to get that, we would need to get our copy of the graph working again and then extend the code to collect the info we want. It would also make us completely independent (see #50).

To be honest, I'm not really keen to invest the time needed to get everything up and running and learn the code, but I certainly would be willing to help with code reviews.

Let me know what you think about that.

[daniel-soli]

The LoopStats was something I scribbled up in a short time and can be extended easily to get the data we want. For specific types of data you can do as you said and query specific block heigth to get historical data. But it's also expensive calls. I'm all for doing whatever is needed to get at it from the best position. LoopStats was just one way of getting it.

I'm with you on the part about setting up an own graph and extend it, that would cost alot of time setting it up and maintaining it.
It would ofc be the best way, but cost/energy...

The way I was thinking about LoopStats is that those functions do the work, while Lexplorer stays lightweigth and fresh. If another service comes along or the graph suddenly gets us all the data we want, then just drop loopstats alltogether and use the graph directly. But as long as the graph cost more to get all the data, then use LoopStats. If there's more data to collect, use LoopStats to collect and do the powerwork and just add a new endpoint for Lexplorer to use.

Sorry if the explanation is not understandable, doing translation as I write 😄

[modersohn]

Thanks - and no worries BTW, I've never had trouble understanding you.

OK then - as I see it, extending the graph would only be an option if @fudgebucket27 actually wants to do the heavy lifting.

In case he doesn't and if we we want to go beyond just simple "in the last hours/days/months" statistics, then I fully agree with you, a separate service that hides all the details, is the best.

But for what LoopStats is doing right now, it seems overkill to me - because the same thing (and more!) could be achieved with 2x2 simple graph queries. Or am I missing something?

But it's also expensive calls.

I actually don't understand that. How is querying the graph more expensive than querying your service? Or are you already considering something like a chart over time? Then yes, that definitely is something where LoopStats could be way more effective!

[fudgebucket27]

Oh, I am not keen for the idea of extending the graph to be honest. I have much going on right now with my other private side projects so I can't invest to much into that especially with my limited Graph skills too.

It looks like LoopStats does have the chart over time capability? It looks of some use to me at least and is simple enough to use. I'm away from now until Sunday so will join back in on the conversation when I'm back :)

[modersohn]

Have you guys seen the dashboard that brecht made on dune?

https://dune.com/Brecht/loopring

This is really on another level regarding stats. I wonder if we can query these as well?

[fudgebucket27]

Sorry just saw this. Looks like you can request beta access to the api: https://docs.dune.com/faq/does-dune-have-an-api

[fudgebucket27]

Oh embeds could work: https://docs.dune.com/sharing/embeds

[modersohn]

Yeah embeds would work for sure. AFAIU they eventually want to charge for API access, so even if it is free as a beta for now, I'd be hesitant to invest the time if eventually we're not willing to pay for it.