A few months ago I dabbled in solidity development. I’m interested in all things cryptocurrency, and ethereum smart contracts appear to be a very large aspect of the current state of cryptocurrency. As such, I had no choice but to experiment with the technology. This experimentation involved using the truffle.js framework to follow the ethereum foundation tutorials.
During initial smart contract development it’s common to use the testrpc client as this speeds up deployment times allowing for quicker code iterations. There is also less complexity in this chain, so less can go wrong and you can focus explicitly on development. However, given that the eventual goal is deploying smart contracts to the main net, eventually you begin to turn your attention to the ethereum test networks. After testing my contracts using testrpc my next step is typically to test on the parity development chain, which similar, to the testrpc client has less complexity but is an actual blockchain. After testing on the parity dev chain, I move to the kovan or ropsten test networks. At the time the ropsten network was under attack (and looks like it is again). So my only choice for testing was kovan.
This is where I begin to have problems in my development and eventually moved on to other aspects of technology (I think at the time it was react-native). I was working through a tutorial to deploy a DAO like smart contract, and everything was going well, until I attempted to deploy the contract to the kovan test network.
Error encountered, bailing. Network state unknown. Review successful transactions manually.
Error: Contract transaction couldn't be found after 50 blocks
At the time I didn’t really understand what was going on behind the scenes with regard to addresses and transactions. I knew that I had to sign the transaction in parity, but I had already deployed on the parity development chain, created two different accounts on the kovan chain, one email verified in order to get some test ether, and had my main net accounts floating around in the parity files as well. So I tried a number of different key files, unsure of which was correct, none of them were signing the transaction successfully, or if they were, there wasn’t enough ether in the wallet.
At the time I wasn’t even sure I was barking up the right tree, and given that I wasn’t actually trying to deploy to the main net anyway, I posted to stack overflow, never heard back, and shelved the issue.
Enter the ICO
A few weeks ago I posted about proof of stake, and through this post met the CEO of a blockchain start up. I ended up proof reading their white paper, and kept in touch during their ICO. During the pre-sale they were deploying their smart contract for the ICO and were getting the exact same error I was getting months ago. Since this seemed to be a recurring error rather than a one off issue specific to me I felt this warranted more investigation.
I went back to my original DAO smart contract that was giving me issues and tried deploying it again. During this time the CEO made a number of observations eventually leading to a successful deployment of their smart contract.
Here are a few lessons to keep in mind when deploying smart contracts to both the main net and the test nets.
Don’t forget to sign your transaction in parity
Since it’d been a few months since my previous test deployment I had to remind myself how to process works. When you run:
truffle migrate --network kovan
The transaction still needs to be signed by the address set in the truffle.js file for the kovan network settings. If you forget this, truffle will just wait, and after a very long time finally fail with the cryptic error message mentioned above.
There’s no harm in trying different keys
As users we’ve been trained that after too many password attempts you’ll be locked out of your account. In my case I had a bunch of different key files for the same address, if I’d just tried all of them eventually I would’ve found the correct one.
Key management is paramount
I wouldn’t have needed to try every key file if I’d paid more attention to what I was doing with each key while creating test accounts. As an ethereum user, this important, but it becomes even more important as this can introduce inadvertent bugs, adding to the already high cognitive load associated with development.
Make sure you have enough ether to cover the gas costs
I remember this kept coming up while I was troubleshooting the issue a few months ago. The first question asked in forums was always “what did you set your gas price to?” and “does the signing address have enough ether to cover this cost?”
Usually when you sign the transaction in parity it will allow you to set the gas price at that time, and will show you the current average gas price on the network.
You can also set the gas price explicitly in the truffle.js network settings. For example:
from: 'KOVAN ADDRESS',
would set the transaction to use 4712388 gas with a gas price of 25000000000 on the kovan network.
Use the parity transaction viewer
This was one of the jewels passed along to me by the CEO that I wasn’t aware of. Parity comes with a bunch of dApps, and one of them is a transaction viewer. This allows you to keep tabs on the state of your transactions, as well as view other pending transactions on the blockchain. I believe this is what led the CEO to the truffle.js gas price file insight.
At the end of the day, when I finally went to check if my contract deployed successfully on the kovan network, I looked at all transactions made by my kovan address, and some of my transactions from months ago actually made it onto the blockchain. Truffle uses what they call an “initial migration” and then the actual contract deploy. Some of my initial migrations made it into the blockchain, but not the actual contracts, until sorting out the rest of the things discussed above.
This lesson is an obvious one. Always check etherscan. Although, some times this may add to the confusion. Since the kovan network was sluggish at the time, it took awhile for my transactions to show up, this coupled with the cryptic truffle error lead me to believe absolutely nothing was happening.
Most of these are trivial to debug, but when combined lead to difficult debugging, add to that cryptic error messages and it can often be difficult to break down what’s going wrong in a systematic way. But, this is brand new tech, and because of this, if you’re a developer, any help with these frameworks will speed up development iterations and in turn make this tech easier to work with for other developers in the future. parity truffle
That’s all for now. I’ve recently upgraded my miner to a new beta AMD blockchain driver, so I may pass along this bit of info in my next post. Until then!