The Chainlens team have been busy these past few months with a number of significant updates to the platform. The intent behind these is to further cement Chainlens' position as a modern, user-friendly and fast explorer for blockchain networks.
There have been three key priorities for the team to this end.
We'll be unpacking each of them below.
This was first mentioned in our Future of Blockchain Exploration post, but we're now ready to start rolling out our new UI to our live instances. You can see it running on the Holesky network at holesky.chainlens.com and it will be deployed to our other instances imminently.
The new UI for Chainlens provides an uncluttered experience for our users. We want to ensure that it is just as accessible for teams running networks that want to see overall network health and activity, as it is for web3 curious users who are testing the waters with on-chain assets.
There are three categories of data used by blockchain explorers. These are raw blockchain data, decoded data and enriched data.
Raw blockchain data is the information that comes directly from blockchain nodes. It is the blocks and transactions in their basic form returned by JSON-RPC calls such as eth_getBlockByHash and eth_getTransactionByHash.
Example of eth_getBlockByHash
This raw data is the base data set upon which further processing is performed by indexers and blockchain explorers. It's the data that makes up the blocks, transactions and event views in the explorer.
Decoded blockchain data is where the magic starts. This is the place where transaction payloads associated with smart contracts are decoded to understand what the outcome of a certain transaction was. For instance, information about token and NFT transfers via the ERC-20 and ERC-721 standards requires searching for specific signatures in transaction payloads.
Also the ability to understand internal transactions where a smart contract invokes a transaction on another contract requires additional processing to decode.
The outcome of this decoding process is that you can start to display information about assets deployed to the network and account specific balances of those assets.
Some of this additional information is what you see displayed in the NFTs, Tokens and Accounts view in Chainlens.
Finally you have enriched blockchain data which is where off-chain data sources are used to provide additional information about on-chain assets.
Sources of this data include:
With this enriched data, users of Chainlens get a far better insight into the assets deployed on blockchain networks. They can see information about the individual NFTs deployed on the network.
They can also understand what the majority of the transactions associated with smart contracts represent, thanks to the data provided by Sourcify and bytecode data stores.
Chainlens has provided high quality raw and decoded blockchain data for some time now, as well as enriched NFT data. However our Sourcify support was limited and we didn't have a bytecode database for unverified contracts.
The team has been focussed on addressing this shortcoming to ensure that Chainlens provides as much decoded information about contracts deployed on a network as possible.
This includes function and event names and their parameters for both verified and partially verified contracts.
And for those unverified contracts, our bytecode database can decode a significant proportion of the remaining method and event names in Chainlens.
(Read our recent post for a primer on the smart contract verification process)
The upshot of this is far less hexadecimal for users and a more intuitive experience.
The final part of the puzzle for the Chainlens team has been setting aggressive performance targets for it. When someone is using any digital product, delays frustrate users. There is nothing worse than spinning wheels telling someone that they need to wait for some activity to happen.
People have a very low tolerance for waiting when using any interface and there are two numbers that really matter here — 0.1 and 1 second.
Usability pioneer Jakob Nielsen defined the importance of these numbers where:
We want to ensure that the user experience of Chainlens is responsive to these tolerances. 0.1 second load times or less is the ideal number we want to hit and we're under or just over this threshold on a number of pages.
But we want nothing to take users more than a second to load. We want to ensure that the flow of thought of our users remains uninterrupted.
We're all too aware of the fact that in today's digital world, as soon as we go over one second waiting for something to happen, the urge to context switch kicks in, and all of a sudden you've lost half an hour.
With Chainlens, we want our users to find what they need to quickly, then move onto their next task.
You can see the impact this work has had with our Holesky instance of Chainlens. When you click on the navigation menu items you should find that data is returned rapidly. In our testing most of these pages are loading within the 0.1 second threshold, and those that aren't are still loading within 0.2 seconds.
This is significantly faster than a number of other blockchain explorers running on Holesky, and we encourage you to try it yourself.
These three major improvements we've been focusing on for Chainlens this past few months are on the cusp of being widely rolled out to all of our instances.
We believe these foundational changes will greatly enhance Chainlens for its users. From here we have a number of other significant features we will be working on. For a preview of some of them, you can refer to the Roadmap page of our docs.
In the meantime, you can road test these enhancements yourself at holesky.chainlens.com.
Happy exploring!