Inspecting smart contracts with PyTezos
DYOR series by Baking Bad
In this post I will show you how to convert smart contract data between different formats, and how this can help to understand the idea behind the code.
Introduction
Blockchain data availability is a bit of a controversial thing: theoretically you have access to everything, but when it comes to actions, you realize that things aren’t that simple. In fact, you need to have enough resources, a bunch of middleware, and a particular tech stack knowledge for direct access to the data. Therefore, blockchain explorers play a huge role for the data accessibility, they drastically simplify information retrieving and analyzing.
But that’s not all, proper data representation plays an equally important role, cause humans require much more higher abstractions, visualizations, and main components extraction.
We come to the topic of this post — smart contracts. It’s crucial to understand what is happening inside the smart contract you trust your funds to. Tezos went further than projects that use bytecode virtual machines, and introduced Michelson — a language designed as a readable compilation target. But it’s still not easy to read it because you need to think like a stack machine and transform nested structures on the fly.
I would like to show how simple conversions can improve the perception and help you understand the purpose of a smart contract in general.
Notebook
Run locally
You will need python 3.6+ and Jupyter package to continue.
$ git clone https://github.com/baking-bad/pytezos.git
$ cd pytezos
$ jupyter notebookNavigate to the `examples` folder and run the dyor_smart_contracts.ipynb.
Play on Google Colab
You can also play around with the code online: https://colab.research.google.com/drive/1DICb442LL2hARTxUgV91g_sWURDFwGzK
Or view an embedded version:
Summary
We have shown that rather simple transformations and metadata usage can drastically increase readability of smart contract storage (including big maps) and transaction parameters. And we can use inverse transformations to communicate with a smart contract in a more convenient language. We can also make a visualization of storage differences for a specific operation or period.
All this give us the toolkit for black box analysis, which can help to understand the general idea of the code by matching inputs and resulting side effects.
What’s next
As you may have noticed, we have almost everything to build a unit test platform that depends only on the PyTezos library and public RPC API. While most developers prefer higher abstraction languages, I guess this framework can find its niche. Combined with the excellent PyCharm extension for Michelson, this is a good development environment, what do you think?
Follow us on Twitter for updates and ask anything in our Telegram chat!
Originally published at https://baking-bad.org on March 24, 2019, where you can find full version of the article.
