Adventures in Ethereum Development
About a year ago I submitted an article titled “3 Things I Learned This Week Using Solidity, Truffle, and Web3”. I monitored the space, keeping tabs on some of the ongoing development, including contributing to the community research into the Parity Multi-Sig Hack from November.
Recently I was invited to a company-wide hackathon where some of the challenges involved using new and emerging technology to satisfy business needs. Since software licensing management was something I was directly involved in, I immediately saw a use case where I could leverage my expertise in blockchain development to come up with a rudimentary licensing model on Ethereum.
I began by looking into development of Non-Fungible Tokens (ERC721), as I wanted to build licenses that could be traded, moved around, checked in and out, etc. This led me to looking into how to store metadata associated with NFT’s on the Inter-Planetary File System, which introduced another set of unique challenges.
Eventually, after all this prototyping (before the hackathon), I decided the project was out of scope for a 24 hour event, and my team went in a different direction.
However, I’d like to share some things I discovered in my foray into smart contract development for software licensing management. Enjoy!
1. Truffle now has Ganache and Drizzle!
I finally have a GUI for my locally running testrpc node! This came in really handy when I needed to parse logs, blocks, and transactions while debugging. However, the actual application would slow to a crawl after a few migrations; the amount of logs generated seemed to overwhelm the application.
Additionally, the testing suite seemed way easier to take advantage of this time around. I implemented tests for almost all contract functionality, something I was deeply thankful to Truffle for implementing. However, I had to implement a custom utility function to assert that certain events had fired; it seems like Truffle still has a hard time detecting these events in their test procedures. Note: I did NOT come up with this by myself, it’s pretty much copied from here:
Here it is below:
Additionally, I was able to use Drizzle to integrate an Ethereum connected store into a React application. It requires having access to the contract JSON file generated in your Truffle projects contracts folder. Additionally as a non-React developer I had a bit of difficulty figuring out how to connect Drizzle to my components. This tutorial was very helpful in getting set up.
2. OpenZeppelin has open source contract libraries built to ERC specifications
So OpenZeppelin was a tremendous resource when trying to implement an ERC721 token. It was a breeze to install the library:
npm install zeppelin-solidityAnd then reference/link the library for ERC721:
However, while linking and developing, I learned that ERC721 token holders MUST implement ERC721Receiver and NOT ERC721Holder. It was not immediately clear to me that ERC721Holder was a sample contract, and not a library to build from.
Additionally, you can extend an ERC721 token to hold whatever mappings/data you would like. I extended mine to hold a license checkout duration length.
3. “The contract code couldn’t be stored, please check your gas amount”
This usually meant that I had not fully implemented an interface yet. In one particular instance, I realized I had not implemented the ERC721Receiver constructor properly.
Basically:
constructor (address smartLicenseTokenAddress, string companyUri) public ERC721Receiver() /* <--- IMPORTANT */ {
_smartLicense = SmartProductLicense(smartLicenseTokenAddress);
_companyUri = companyUri;
_owner = msg.sender;
}instead of:
constructor (address smartLicenseTokenAddress, string companyUri){
_smartLicense = SmartProductLicense(smartLicenseTokenAddress);
_companyUri = companyUri;
_owner = msg.sender;
}…oops. Remember your base constructors!
4. IPFS for metadata storage
Remember how it’s really expensive to store data on chain? Well, the solution to this when storing unique metadata for ERC721 tokens is to use the Inter-Planetary File System, which is a decentralized peer-to-peer system of storing immutable hashed files. The hashes (links) to the files can then be stored on chain. Here is a link to js-ipfs-api which I used to connect to a locally running IPFS daemon, add file data, and then retrieve it:
However, storing data in the IPFS became a hassle, as swarm peers were blocked at work (where the hackathon was taking place), so I had to implement a workaround to store and retrieve files locally.
5. Ethereum Alarm Clock for scheduling calls
The Ethereum Alarm Clock was discontinued for a while before being funded again recently, which I was very happy for, as I couldn’t schedule license check-ins without them. I was not able to implement and test scheduled transactions however, since that would require deploying to one of the test nets instead of a locally running private chain (Ganache).
However, discovering and learning about the process involved with decentralizing scheduled transactions on a blockchain protocol was quite a rollercoaster! I would highly recommend reading the documentation for yourself.
The reason I went with a scheduled transaction instead of lazily checking and then computing is because I didn’t want a potential state change on a call that was going to be called very frequently.
In conclusion, I ended up discovering a ton of really cool tools to use when building smart contracts in the Ethereum space. It’s incredible to see the progress that’s been made in the last year by developers passionate about blockchain technology! The Ethereum communities commitment to open-source development in this space is truly inspiring.
Feel free to ask any questions, or check out my Github for more samples of Solidity code!
