# Major update of Tezos smart contract meta-explorer by Baking Bad
It’s been a month since we released an early prototype of Better Call Dev [BCD], we have made significant progress, and now we are introducing a bunch of cool features and completely redesigned user interface.
We want to thank Tezos Foundation for supporting us, TzScan and TzBeta for the Index/RPC access, and all the Tezos and Michelson developers for that huge amount of metadata and on-chain debugging information that let this project exist.
# The idea behind
Our mission is to increase blockchain data availability through a nice user interface and high-level data abstractions. Better Call Dev is a tool both for smart contract developers and users. Our goal is to present the interaction with the smart contract as a set of input parameters and side effects so that one can understand what is happening inside by looking at those values.
Let’s quickly go through the main features and interface elements.
# Operations tab
The first thing you see after you query an address is a list of Tezos operations for the smart contract requested. Operations are sorted by time in descending order. Inside each operation, there is the main transaction and there can be several internal ones, also sorted by time but in ascending order.
# Operation header
Operation header contains basic information, such as timestamp, block height, the operation hash, fees, gas and storage limits. In the right corner of the header, the contract state at the end of the operation is shown: resulting storage size and resulting balance.
# Transaction information
Each transaction block begins with the transaction type and extended status (applied, failed, skipped, or backtracked). Then come the source/destination accounts, and transaction amount. Addresses matching the requested one are colored in pink, or linked with the corresponding BCD page otherwise.
Each transaction is accompanied with spent gas and paid storage diff information, it’s shown how much is spent as a percentage of the operation limit.
If there are some errors, BCD will show you text descriptions and passed data in case FAILWITH instruction was reached.
# Call parameters
Transaction parameters and storage changes are hidden by default and shown for the latest transaction only. Press show button to expand the view.
BCD applies numerous transformations to make the data look better: collapse nested pairs and or instructions, utilize field and type annotations, pretty-format known types. Additionally, long values are shortened by default and can be expanded by a click.
# Storage diffs
A few more tricks applied to the contract storage: for each transaction, BCD compares the current state with the previous one and produces a simple JSON diff. Additions, replacements, and removals are colored green, yellow and red respectively. In case of replacement, both the previous and new values are shown. Unchanged parts of the diff are collapsed by default in order to ease the perception.
Big Map is an essential part of the storage, and its changes are shown together with the rest. Moreover, BCD produces “true big map diffs” by querying previous value for each changed key. This allows distinguishing replacements from insertions.
# Script tab
A contract in Michelson consists of three sections: a description of the types of input parameters and storage, and the code itself. BCD shows decoded versions of type schemes, and extended source code on this tab.
It should be noted that this is not a valid Michelson code, but rather an enhanced visual representation:
- Adaptive collapse-friendly code indentation;
- Code coloring (instructions, types, expandable types, values, annotations);
- $ELSE pseudo-annotation;
- Inline type descriptions (Click on the underlined type names to expand).
Instructions that spawn operations or execute code are marked bold in order to attract attention.
# State tab
You can find current contract balance, storage size, and last modification timestamp on the state tab, as well as the storage data plus latest Big Map entries (loaded on the operations tab).
BCD also supports inline lambda body rendering, using the same enhancements applied to the contract code. We believe it’s extremely important to show this information as clearly as possible because the use of a smart contract whose behavior is changeable can be dangerous.
# What’s next
Try Better Call Dev, click on the _Pick Random Contract _link and explore smart contacts we chose for demonstration.
In the next release we plan to include the following features:
- Support originations (self and spawned), delegations, and chained transactions;
- Better entity recognition;
- Support sandboxnet environment used by developers, integrate with Granary; This mode will also allow operating completely offline.
- Performance tuning: BCD caches RPC requests, but networking is still a bottleneck. We consider using other data sources and optimizing request count;
- Improve code viewer: add collapse/expand feature, line numbers, macros folding, and more.
Any feedback is highly appreciated, if you have a feature request or a bug report please welcome to our issue tracker.
Cheers!