The Witnet explorer: version 1.4
As usual, the newest release of the Witnet explorer is packed with new features (and some bug fixes)!
Monitoring the explorer’s performance
If you run your own local version of the explorer, you may be interested in monitoring resource usage and performance. To achieve this, the repository now includes everything required to run a Prometheus + Grafana dashboard which visualizes useful metrics from all backend components.
You can easily check which processes are online or offline and whether the Witnet nodes servicing the explorer are synced. This is extremely useful to quickly figure out if something is wrong with the explorer!
Furthermore, it is also possible to visualize usage metrics such as the number of requests being sent to the explorer and their distribution.
All scripts and README files required to get this working can be found in the monitoring subdirectory of the Witnet explorer’s backend repository.
Network usage visualizations
Being able to monitor network usage is important for a number of parties that contribute to the Witnet network. People whom create data requests need to know how to select witnesses and their rewards, miners whom solve these data requests need to be able to predict how much collateral they should put on their nodes etc.
In order to achieve this, the network page has been extended with several different graphs visualizing a number of key network metrics. Some of the more important ones are discussed here:
The first figure shows the number of data requests which have been processed by the Witnet network every 1000 epochs. For example, between epochs 1685000 and 1685999, the network resolved 2437 of which 2416 were succesful and 21 failed. By default, all data is shown for the last month, but this interval can be configured.
If you want to create a data request and check how many witnesses are usually requested, the Witnesses figure can be quite interesting. This figure show a histogram of witnesses. During the same 1000 epochs as before, the large majority of data requests required 10 witnesses while some required 100 witnesses.
As a miner, it may be interesting to know what the requested collateral per data request is to estimate how much Witnet coins you want to stake on your node. This is where the Collaterals figure can help you. Similarly to the previous figure, this will show a histogram beakdown of requested collateral. In this example, about 2/3 of data requests required 15 WIT collateral, close to 1/3 required only 5 WIT collateral and the remainder requested 2.5 WIT collateral.
Of course, equally interesting as the required collateral is how many WIT you receive as a reward whenever you truthfully solve a data request. This is what above figure shows, again as a histogram. About 2/3 of data requests executed during the same 1000 epochs payed out a reward of 150 mWIT.
As of WIP0023, collateral staked by nodes to solve data requests is burned when they reveal an out-of-consensus value instead of being distributed amongst honest witnesses. This implies that over time the total supply will shrink. Above figure titled Supply burn shows how much WIT is burned every 1000 epochs.
Above figure shows the amount of Witnet coins the ARS nodes are staking. On the x-axis, percentiles of the ARS are shown. Each percentile indicates how many nodes have less and how many nodes have more than the indicated amount of Witnet coins staked. For example, 38% of the current ARS nodes have more than 1000 WIT staked. Note that this data is a snapshot of the current state only and changing the start or stop epoch does not change anything.
Threshold Activation of Protocol Impovements (TAPI)
The Witnet network uses the TAPI mechanism to enable smooth activation of newly proposed protocol improvements where miners signaling their acceptance of a certain (set of) improvement(s). If more than 80% of miners support a certain upgrade, it will be activated.
You can check which proposals are up for activation on the explorer’s TAPI page. This will show the activation details, a link to the extensive description of the proposal and progress using several graphs. In this release, this page has been extended to be significantly more responsive by creating static progress plots.
Two new API endpoints
The API serving requests to the explorer also contains two new utilitly endpoints.
The first one is the address_info endpoint which allows to query the amount of transactions an address was involved in and at which epoch the address was last active. This can be useful for third-party tools (such as the light wallet) to decide whether it is necessary to perform more expensive API calls. This information is also shown on the address page from now on.
The second one is the address_labels endpoint which allows to fetch all addresses which are labeled in the explorer. These are addresses for which some form of identity is known. Examples include addresses used by the Witnet Foundation or exchange addresses.
Miscellaneous
In the backend, several database optimization have been applied allowing for faster data request report building.
To align the terminology between the witnet-rust implementation and the explorer, the data request bytes hash term has been renamed to DRO hash.
Furthermore, several (reported) bugs have also been fixed improving overall reliability.
