First steps
Before getting started it is typically wise to do some reading about how things work. My first step was to read some of the documentation.
The first place I started looking was the official website: https://ethereum.org/. It contains some general information about the network and smart contracts, but unfortunately not really how to actually make a Dapp.
After discovering that the official website did not contain the information I was looking for I quickly moved on to the unofficial documentation on http://www.ethdocs.org. This site has much information, for me it was too much information to grasp, but it serves as a very welcome reference. The sections I read are:
- http://www.ethdocs.org/en/latest/ether.html
- http://www.ethdocs.org/en/latest/account-management.html
- http://www.ethdocs.org/en/latest/network/index.html
- http://www.ethdocs.org/en/latest/connecting-to-clients/index.html
- http://www.ethdocs.org/en/latest/contracts-and-transactions/developer-tools.html
I found it very interesting and tried to use some the clients to connect to the network and to create an account to be used with the wallet. At first I failed miserably. I’m sure it was possible to do what I wanted to do, but only the third client I tried worked slightly as expected (Mist).
Since this technology and its tools are all still very new and in constant state of development, they can be quite unstable and present you with many difficult to solve problems. Also after finally getting a client to (sort of) run properly, I had no clue what to do with it. It’s like the first time I connected to the internet back in the 90’s: “Yes it’s working! Now what do I do, where do I go from here?!”. Back then I got myself a notebook and start jotting down urls that were broadcasted on TV or in advertisements and visited those sites.
Fortunately it did not take very long for search engines to become popular and allow us to search for websites. Something I applied right after getting the client to work, however I did not have any Ether in my account, so even after finding a Dapp to try I could not do anything noteworthy (more on that later).
After all of this messing around I had somewhat of an idea on how Ethereum Dapps work, but still absolutely no clue on how to start developing. And to be honest I was a little disappointed. Many people tend to praise Dapps like they are the holy grail, but so far I could not even get it to work to a decent extend or find an interesting Dapp, that really shows the value of smart contracts.
Cryptozombies
After being a bit overwhelmed by all the information and not being able to find a good guide on how to get started with this type of development, I found out about the existence of Cryptozombies at work. It sounded a little bit like Cryptokitties (https://www.cryptokitties.co/) of which I had heard before.
Before diving into cryptozombies I first wanted to refresh my memory about Cryptokitties. A quick glance at their official site was enough. It is not really a game, but it allows people to collect digital cards with illustrations of cats.
Personally I really do not understand the fun in collecting digital (or physical for that matter) cards that you can only use to trade or look at, but I do think it provides a good showcase of what is possible using smart contracts. One of its key points is to show that it can provide a very good and secure way to keep track of the ownership of digital assets.
Digital assets can be anything (software license, sword in a medieval game, car in a racing game, if it is digital and you can own it, it qualifies), but games seem to be the most accessible way to introduce this way of safeguarding their ownership.
With Cryptozombies you can basically learn how to develop a smart contract like the one from Cryptokitties, but a bit more advanced.
Cryptozombies currently has 6 different lessons each one digging deeper into a programming language called Solidity. Solidity is one of the high level programming languages that can be used to compile to EVM bytecode.
During the lessons you get a lot of good information, not only on how to program in Solidity, but also some details on how the Ethereum network works.
Currently the following lessons are available:
- Making the Zombie Factory
- Zombies Attack Their Victims
- Advanced Solidity Concepts
- Zombie Battle System
- ERC721 & Crypto-Collectibles
- App Front-ends & Web3.js
Lesson 6 was only added recently, but I’m very happy that they did. Without it Cryptozombies teaches you Solidity, but without any way to provide a Frontend for the user.
Every lesson you will get some explanation of new concepts and some exercises that make you use the new information. The exercises consist out writing code, that is checked when you want to move on to the next chapter of the lesson, you cannot move on if your code is incorrect.
It took me some time to get through all of the lessons, maybe a week or 6 in total. But I’m sure that if you dedicate more time to it then I did, it’s possible to finish all of the lessons in a few days to a week.
Development environment
After completing the Cryptozombies lessons I had some basic knowledge about how to code in Solidity. “Great! So let’s start coding!” I hear you think. Unfortunately I was not ready yet. The main reason being that Cryptozombies teaches you how to code in Solidity, but it does so by allowing you to write the code in an editor on the site. That editor is not an IDE, but a very simple editor that just checks if the lines you wrote are equal to the official solution thought of by the Cryptozombies developers. The course currently also does not point you in any direction to find one.
Remix
After doing some research I found some blog posts and small bits of information distributed over the web. In most of them mentioned Remix (https://remix.ethereum.org), an in-browser IDE that can compile Solidity code as well as provide code completion and debugging tools. Another really nice feature of Remix is that it can do static analysis of your code and advise you to do things differently.
When writing to the blockchain we have to pay gas. For development we need to change our code frequently and thus deploy our code frequently to be able to run our code. If we would have to do that on the “real” ethereum blockchain, it would cost us a lot of money. In the end we pay for the gas with Ether - a cryptocurrency - and it is not cheap to get.
Thankfully Remix provides us with the Javascript VM, which is sort of an emulation of the real blockchain network, but only runs in your browser window. The Javascript VM is quite simple and does not care if you send of enough gas along with your requests. Because of that it is ideal to start with. Allowing you to write good code first (and debug it easily if necessary).
It also makes it easy to test your smart contract by providing very basic UI elements for your public functions and properties. That way after you deployed you can immediately test them, without having to worry about your Frontend and Javascript bridge.
With Remix it is possible to open files from your local filesystem, but you do have to run Remixd on your local machine. (To make this easier I made a Docker image, which can be found here: https://hub.docker.com/r/4c0n/remixd/)
If for some reason you would like to use Remix offline, I’d suggest trying this Docker image:
Truffle framework
After my code started to grow larger and more complex I found myself having to do lots of manual testing with every change, just to confirm that all other functions were still working fine after changing some code.
It started to take up the majority of my development time and becoming quite the nuisance. So it was time to start looking for something to provide some default file structure and means of automated testing.
After a short researching session, I managed to find the Truffle framework (https://truffleframework.com/). Truffle seemed to provide almost everything, so for me it was an easy choice to try it out.
Truffle comes with clean room testing facilities (have a clean environment after executing every test case) when it comes to testing contracts using tests written in Solidity.
It also provides a setup that allows us to test the contracts using Javascript (Mocha + Chai), both very useful.
Another thing that Truffle provides is boxes. Basically boilerplates for writing different kinds of Dapps. Check them out here: https://truffleframework.com/boxes.
For me the webpack box seemed like a good place to start as I had no intentions on using any specific frontend framework, but if you’re into things like React JS I can highly recommend giving the drizzle box a try (https://truffleframework.com/boxes/drizzle).
After moving my files into the new directory structure I decided to start writing test cases (to prevent having to test everything manually all the time). First it seemed like a good idea to write the tests in Solidity and kind of treat them as unit tests. This works well, but it gives no guarantees that you can use your functions like intended from Javascript. Something that became quite apparent when I started writing the tests using Mocha + Chai.
Ganache
Remix provides the Javascript VM and the option of using web3 with a real blockchain (live network or testing network). But since Truffle tests are executed on the command line we are not able to use the Javascript VM from Remix.
However we can use Ganache or Ganache-CLI. The latter is formerly known as TestRPC.
Ganache provides you with a personal Blockchain that you can use for development.
The desktop application is easy to use and by default provides you with 10 accounts for testing. This is great, because we don’t need to care of having to deal with gas too much.
Ganache allows you to see the private keys of any of the accounts and the keys can be used to import the account into MetaMask for example. This way you can have up to ten accounts for testing and development.
Even better when you restart Ganache, everything is reset. It is also possible to use other tools of course, but for me Ganache is definitely the most convenient one to use during development.
The only thing that slightly annoys me about Ganache is that if I want to quit the application using the keyboard, I have to use alt+f4 (but I’m not running Windows!).
Frontend
After having found a good framework with testing facilities and some basic smart contract, I decided to go ahead and start building the UI. To keep things as simple as possible (after all the Dapp I started developing is only a Tic Tac Toe game) I decided not to use any framework, but just pure JS.
Of course this failed and I needed at least Bootstrap and JQuery, to be able to look things nice and not waste lots of time. I could have used npm + webpack to manage those dependencies, but for simplicity’s sake I decided to start of by just loading the js libs and css from the CDN (using script and link tags respectively).
I’m in no way a frontend developer or expert on UI/UX, so a simple UI using JQuery and Bootstrap was enough for me.
The first question I had when setting up the frontend was: “How do I communicate with the blockchain?”.
Well after doing a little research I found out that I needed to use Web3 (https://github.com/ethereum/web3.js/). It is possible to import this as a project dependency, but I found out that typically the web3 library is injected by a browser extension. The most popular one seems to be MetaMask (https://metamask.io/).
MetaMask
As said before I found MetaMask to be the most popular way to manage accounts for use on the ethereum blockchain. It functions as a wallet (holding your ether) and also injects the web3 library in every page. So when you need to pay gas for example, MetaMask will pop up and ask if it is okay to pay the amount that is requested and signs the transaction.
MetaMask also allowed me to easily import the accounts from Ganache, making it not only ideal for existing Dapps, but also for development.
Conclusion
I feel like I’m well on my way with Dapp development and found some great tools to help with the whole process.
There are still some things that are a bit tricky, but they are likely limitations or imperfections of the Solidity language. For example one of my notes reads:
“Find a good way to save the game state
- Initializing a 2D CellState(enum) array in a struct equals hell”
But I’m sure that when the language matures these kind of things will be fixed and will work much better.
I have not yet reached the stage where I want to test my work on a live blockchain, but I can imagine that some new problems will arise at that point. So far I’ve read that Ganache and the live chains do not always function 100% the same and of course paying gas will become of much bigger concern.
What I really like about the whole setup, is that since users have to pay for executing code, it really pays off to make the code as efficient (and cheap to execute) as possible.
0 Comments:
Post a Comment