If you have coded on Solidity, you do know that, contrary to its commonly-praised simplicity, this language has many inherent peculiarities, along with the Ethereum run-time environment itself. And if you aren’t fully armed against such, they can greatly increase the time for debugging, giving you and your PM much of a headache.
For instance, there are several different types of memory available to the contract. Another tricky thing is that the basic data type is a 256-bit integer (32 bytes) and the byte order is not little-endian like in x86, but big-endian. What is more, the solidity compiler may generate an error without specifying a line or a source file which it struggled to compile, and some seemingly innocuous and concise language constructs can unfold into a large number of inefficient bytecode during compilation.
To better understand what exactly the compiler turns solidity code into, you can use disassemblers and decompilers. But while disassemblers are pretty hard to use on their own, the output generated by a decompiler can differ drastically from the original contract code. Still, there is a kind of a ‘magic wand’ to sort this out.
Truffle, the most popular framework for working with the code on Solidity, generates plenty of other useful data during compilation, apart from the bytecode of the contract. We can use this data to conveniently match the source code with the instructions and the other way around.
In our post Solidity Source Mapping explore the way Truffle data gives you the insight into how your code actually behaves and what exactly it does in the blockchain. We walk you step by step through the Source mapping process, which is also a really convenient way to analyze bottlenecks in your code.
Stay tuned! Yours, EQ LAB Team
New to trading? Try crypto trading bots or copy trading on best crypto exchanges
