A new grin explorer

I’ve created a simple explorer which is currently available at http://107.175.127.117. Since i’m not a devops guy I hope someone else can host it somewhere. I’m hosting it now so that people who are testing stuff can use it.

Functionality:

  • block-list + block-detail
  • search (click on ? icon to find out how to use it)
  • it should display reorgs of length more than 1 and allow following the reorged blocks to see what happened
  • price → for testnet it shows 0, for mainnet it shows the current tradeogre price
  • graphs → currently there’s only one graph showing relation between inputs/outputs/kernels per day
  • testnet explorer is synced on non-archive node and thus lacks early blocks while mainnet explorer is synced on archive node

Disclaimer: I’m not a designer so the page design is not top notch. I’ve made some assumption on what the node sends me when a reorg happens and if this assumption is wrong, then explorer might not report them correctly. The explorer is currently importing older blocks from the mainnet. At the time of writing, it imported around 20% of latest blocks and is expected to reach the genesis block in around 35 hours. I’m also sure that there are bugs :slight_smile:

I’ll release the code for it in the following weeks so that anyone can set one up locally and explain a bit more how one can run it.
In the end I would like to thank @hendi from whom I’ve copied a lot of the models, @xiaojay for his python api work which I’ve used, @yeastplume for adding new api that I needed and @davidtavarez for making grin++ api the same as grin-rust (still in progress).

26 Likes

Love how the block looks especially a block with many inputs and outputs like this one. Thanks for putting in your free time to build this. It’s great having you around.

8 Likes

This is great, is there code on github that we can use to deploy our own or is it more complicated than that

2 Likes

I’ll release it in the following weeks, hopefully people won’t find it hard to run their own (instructions will be included in the readme).

6 Likes

How about the server specification to run this explorer? I’d like to clone one for me.

3 Likes

Wow, this really looks great :rocket: ! I especially love the block input output viewer.
Thanks for making this, I added it to https://github.com/grincc/hub/blob/main/README.md
Anyone who wants to host this with a cool domain name attached to it? Perhaps something within your expertise @Trinitron and @trab (no pressure, just if you feel like it)?

4 Likes

The server where it’s currently hosted is a kvm vps with 2 cores and 3.5 GB ram

3 Likes

I like it so far.
I’m interested in charts that show the the difficulty, graph-rate, spend-output-count, unspend-output-count, spend-unspend-output-cound-ratio, total-fee and fee-coinbase-ratio or similar statistics.

Fun-fact: Exploring Block 2503305 first I thought there is an extra output for the fee. :sweat_smile:

http://107.175.127.117/mainnet/blocks/0000724b5608b35e016c6dc23faab606b07aad35a7a87ecb8b52fb83af9ca3fd/

2 Likes

yeah about the charts i’ve decided to just do the one that i thought was the most basic one and decided to implement others based on the feedback from the community.

1 Like

One feature that might be useful is to display all of the inputs, outputs and kernels. Perhaps you could have a get param &expand_inputs=true and &expand_kernels=true to arrive at a page that has everything already shown and avoid clicking on show more to see everything. Might make searching for the candidate easier in larger blocks.

1 Like

Could this website just be a front end that you could host anywhere like github pages? Maybe just add a grin node address in a config so it knows where to perform the data lookups?

Another idea: bundle this with node software so when you run a node, this front end can be hosted with it. Extra incentive to run a node

Explorer uses its own db to avoid spamming the node with requests. Connecting explorer with a node is done through the website (admin login). If bundling is done (of any tools) then it should be done on top of existing projects, so as a new project which uses other projects in the background - that way bundled projects don’t have to deal with bundling which is better imo.

4 Likes

I like it a lot. We need it. Thank you for making it!

4 Likes

Just one graph I had in min. Would it be interesting to make a transaction graph/network? So linked (UT)TXO’s. Not saying you have to do it, other could also add this as an option. The downside of such a graph would be that it would probably be slow to generate and load. So it would probably be more useful if you run it locally and then want to explore the transaction graph.

1 Like

That’s quite a bit of work to implement for a few reasons:

  • as you’ve mentioned, the graph is big and you would likely need to have incremental loading to make it reasonably fast
  • you would need to start fetching mempool data to get “non-merged” transactions and store them
  • you would need to handle the case where your node sees a merged transaction (kernel1, kernel2) but the accepted block only has kernel1 - so someone published unmerged kernel1 (could be miner without broadcasting it) which, for whatever reason, never reached your node’s mempool

Maybe one day if enough people would want it, but my guess is that that’s a lot of work.

1 Like

I agree, I just liked the thought.
Perhaps I will try to set it up myself, but only using archive node block information, not the mempool. I am not sure if I am capable enough to get it done, I will first have to check your code and see if I can make sense of it.

In general, the big issue with these graphs is that you have to regenerate them from scratch each time which is computationally intensive. I see it more as something I can try to get working locally and if so add as an extra option for whoever wants to play with it. And yes, that would not be that useful, since transactions in each block get merged, but since the chain is mostly empty, it could still be interesting to analyze.

1 Like

I’ve implemented it incrementally because rendering of 1k elements is slow. Could add a “show all” button though or show block data and keep loading inputs/outputs or smth. But when you would click “show all” it would still get stuck for some time (reactivity calculations or whatever is happening in the background).

2 Likes

Makes sense! Like if there was an Umbrel package for a node and one for this viewer, it would be super easy to set up

1 Like

Awesome :sunglasses: this looks cool :saluting_face::saluting_face::saluting_face:

3 Likes

Hopefully the code will be open soon, I’d like to clone this explorer

1 Like