The Witnet explorer: version 1.3
Added features
This release adds a number of features which were requested by various users through Github, Discord or Telegram.
Most blockchain explorers allow to search a block based on its epoch. Up until now, this feature was missing from the Witnet explorer, but not anymore! Are you curious about the genesis block? Now you don’t have to remember the block hash anymore and you can just search for epoch 0.
Are you tired of always having to type the full address of your node or have to remember the hash of your favorite block? Don’t worry! The explorer frontend will now locally track your last searches and display them in a dropdown menu.
An important aspect for node operators to monitor is how much reputation their nodes have at any point in time. Up until now, it was impossible to see when a node had reputation in the past, you could only see its current reputation. Therefore, I extended the explorer with some proper historical reputation analysis tools. Anyone can now check the composition of the Total Reputation Set at any epoch in the past. Furthermore, if you look up the address of your node, you will see that it now contains an extra tab which shows a graphical representation of its reputation through time. Note that these graphs are generated live and on-demand, so if you just looked up your address, it will take a little while before the graph is available.
The previous release sped up request responses significantly by adding server-side caching to a number of items which were particularly slow if you searched for them such as data request reports. What was still missing was caching of views generated when you searched for an address. This release adds an address caching process in the backend which auto-updates the default views for a set of addresses which users looked up recently. Just like the other cached request responses, this should significantly shorten the response time.
One of the latest witnet-rust releases allows a node operator to fetch an estimation of the transaction fees required to resolve them in a given amount of time. The explorer now also exposes this RPC call via its API enabling third-party tools to show or use this data.
Bugfixes
Of course, every release also contains a number of minor and major bug fixes. Two of these bug fixes are noteworthy enough to warrant a small description here.
The first is a fix to the data request fee and priority calculation which is used in the memory pool visualizations and data request reports. The former is particularly important as it gives users of the Witnet network a way to view historical network traffic and a way to estimate the fees required to send a transaction into the network.
The second major bug which was fixed in collaboration with parody_bit entailed an incorrect calculation of the data request bytes and RAD request bytes hashes. This fix allows users who create data requests on any of the integrated chains to look them up on the Witnet explorer. It also enables looking for repeat requests or requests which are similar to each other.
