Adventures in Ethereum
The Ethereum blockchain offers plenty of excellent features that make perfect sense for Blockchain applications: immutability, transparency, and verified distribution across the globe.
But as a developer experience? Oof, it’s not fun. There are a number of tools and frameworks out there that support building a program that runs on the Ethereum virtual machine (EVM). Unfortunately, they all suffer, to a lesser or greater degree, from a lack of maturity. As a result, when developing day-to-day I spend just as much time wrestling with tooling issues as with my smart contracts.
Solidity
The most important tool is the Solidity compiler which is the canonical method of generating machine code for the EVM. The compiler itself, in my experience, is pretty solid. Then again, we use Solhint before every test we run so any errors I have in my contracts are usually caught before it gets too far.
Documentation is the biggest failing here: the information is there but the structure makes it hard to quickly find basic information. As a short example, I wanted to verify that now, the built-in global variable, returns a timestamp in Unix epoch seconds. But instead of there being a reference page that has an alphabetical list of functions, variables, etc, I have to dive down several levels in the documentation to see it grouped in with other global variables in the Block and Transaction Properties section.
Frameworks
Compiling your Solidity contracts and generating EVM opcodes is only one part of developing for the Ethereum blockchain. We need to be able to deploy our contract to the blockchain too. It’s entirely possible to create an ad-hoc build and deploy system from shell scripts or whatever your favourite automation method might be. This being the wonderful world of open source though, we have several frameworks that aim to take away the grunt work.
There are a few of them out there, the most popular being:
Choosing which framework is difficult because each have their own pros and cons. We chose Truffle in the end due to the extensive documentation and good automated testing support. But there’s a difference between evaluating a tool and using it in anger.
Truffle
Truffle’s built-in migration system supports automatic deploy of contracts to any blockchain. But, due to the aforementioned lack of maturity, it doesn’t have all the features you might expect from a well-rounded migration system (like Django’s DB migrations, Liquibase, etc.). For example, you might have written several migrations but only want to deploy the first two to the mainnet because the third is still under development. The only way to do this is manually move the offending migration out of the migrations directory temporarily while you run the `migrate` command.
I’ve been an advocate of automated testing for many years now. The times tests have saved me from myself numbers in the thousands. Therefore, the test features of Truffle really appeal to me. Being able to write Solidity unit test contracts to test other contracts is an excellent feature, even if they are hamstrung by the nature of the EVM environment.
The Javascript integration tests are a good complement to those unit tests. But a big flaw with them is the inability to roll back state easily or correctly. Truffle tests depend on Ganache (previous known as TestRPC, it’s an EVM implementation developed within the same Truffle Suite umbrella) and the evm_snapshot/evm_revert RPC commands it has. But Truffle only runs these commands per test file and does not offer any library function to the tests to invoke them manually. So your lovingly constructed JS test (that looks very similar to any other standard JS test) will fail in potentially random ways because your expectation of having state rolled back at the end of the contract() block is plain wrong.
These are just a small sample of the issues you’ll come across as you grok the Ethereum developer toolchain. A lot of these problems come from a lack of understanding of how the tools work and, sometimes, an incorrect assumption of how they should work based on the similarity to JS tooling. But the documentation on the tools could do with explaining and highlighting these differences too.
Hopefully, Ethereum documentation and tooling will mature with time so it reaches the same level as Python, Java, et al. For now though, here be dragons!
Originally published at www.zeto.ie on June 1, 2018.
