Ethereum ÐApps Programming Distilled — Part 3
Creating the backend of a decentralised app: using Geth, Mist or Truffle to deploy a Smart Contract.
This is a multi-part article. Here are the links to the other parts:
- Part 1: What is a blockchain and how does it work?
- Part 2: What’s special about Ethereum, and how to write a Smart Contract with Solidity?
- Part 4: Creating and deploying the frontend with HTML, JS, Web3 and MetaMask
- Part 5: Publishing live, on either the Ropsten testnet or on the mainnet
What is a decentralised app, and how is it composed?
A decentralised app, or ÐApp, is simply the combination of:
- One or more Ethereum Smart Contracts (hosted on the blockchain) that contain some executable business logic.
- The use of the blockchain to store any new data.
- An HTML frontend, hosted on a typical web server.
In reality to be fully decentralised the frontend should also be hosted in a decentralised way rather than being on Azure, AWS, GitHub Pages or on any other traditional hosting…and that will likely be the evolution of Ethereum, but we’re not there yet. Swarm (decentralised file storage) and Whisper (decentralised messaging) are two other technologies, complementary to Ethereum, that will allow to build fully decentralised applications, but they are only in alpha at the moment, and therefore not finished/reliable/usable for anything real.
Creating and deploying the backend: the traditional way and the easier way
After you’ve written your Smart Contract in Solidity, like in the previous example, you’ll want to deploy it to the blockchain and start playing with it to see if it runs and does what you want. Since deploying a contract means saving it to the blockchain, and because that consumes storage and computation, it would cost you real ETH and therefore real fiat currency if you deployed it to the live/production blockchain (called “mainnet”). But you certainly don’t want to do that until you’re sure that everything’s fine and ready for prime time. Fortunately, in addition to the mainnet there are multiple testnets (Ropsten, Kovan and Rinkeby — more about their differences here): these are still real blockchains, deployed on a network of nodes, that the community agreed to support to have test environments for developers. The difficulty for mining blocks is easier, and ETH is free on them (you can mine them yourself or, better, use a “faucet” like this one for Ropsten and this one for Rinkeby). Deploying here is great, because while being free it still allow the developer to work in real distributed blockchain, where there’s latency etc.
However…before deploying to a distributed testnet there’s something even simpler, which is creating your own private development blockchain, only stored on your dev machine. What you would normally do is create a dedicated folder somewhere, a special file that represents a genesis block (i.e. the first block of the chain) and run the Geth client to start mining a chain there.
After you’ve got a local and private blockchain you do the following:
1. Compile your Smart Contract with the Solidity Compiler (solcjs), or use the browser-based Remix IDE, which gives you a fairly easy UI for compiling, running and debugging your code (but nothing fancy, don’t try to compare to other real IDEs…). The compilation gives you back 2 things: A) an ABI (Application Binary Interface) file…which contains some json describing the classes and functions of your contract (the public interface, in fact).
B) a BIN (binary) file that contains the compiled bytecode, which is what you deploy.
2. Deploy the contract on the private blockchain with Geth from the command line. Alternatively you can do it more easily from a GUI thanks to the Mist Browser (which includes Geth btw, so you could have downloaded directly this). Mist is a browser for Dapps, and allows you to create and manage accounts and wallets, and use any application available on Ethereum. It allows you to upload a new contract, and even dynamically creates a UI to interact with it by calling functions to read data and send transactions to modify data. As you might have guessed it, the Smart Contract’s ABI is used to discover what are the functions exposed by the contract and what inputs/outputs they have, so that a UI can be generated for them automatically. Regardless of the method you use, after deploying the contract you’ll receive the address of where the contract has been deployed, which you later use to invoke it from the frontend part of the dapp (see next section).
If all the above sounds like fun, go ahead, do it and have fun. But because I’m lazy, and because there are nice people building tools and helpers for lazy people like me, I’ve instead used the Truffle Suite for my app. Truffle is described as “Your Ethereum Swiss army knife. Truffle is the most popular development framework for Ethereum with a mission to make your life a whole lot easier.” and at least at the moment they are right. Here’s a quick overview of how to use it:
- Install it with “npm install -g truffle”.
- Move into your project folder and run “truffle init” to create a bare Truffle project. Then move your Smart Contrat’s .sol files (if you’ve written them already) into the “contracts” subfolder, and add a reference to them into the “migrations” folder (I’m skipping a few details here, but refer to their tutorial for the full thing.)
- Run “truffle compile” to compile the project.
- Run “truffle develop” to launch a “development console”. This command also uses Ganache (another tool included in the Truffle suite) to automatically create a private dev blockchain and 10 accounts (public/private keys) to use in your tests.
- From the console run “migrate”. Done, your contract is now deployed to your private blockchain. All in a few minutes, not bad! If you modify the contract’s code, simply run “migrate — reset” to recompile and then immediately redeploy it.
- From the console you can also write javascript to interact with the deployed contract. Say that you’ve deployed a contract called SimpleStorage, with a function called setValue that takes in input a string and stores it as part of its state…here is how you’d invoke it from the console:
SimpleStorage.deployed().then(
function(instance){return instance.setValue("hello");}
);See the next section about the frontend for a more complete example that uses the actual MessageStorage Smart Contract presented before.
What happens if you need to fix/update a contract and redeploy it?
This is a very important point indeed! Redeploying the contract means creating a new version of it on the blockchain, on a new address and with a new state. This means that once you deploy a Smart Contract you can no longer fix/change it…it will be immutable…you can only have a completely new one, separate from the previous, it’s not an actual fix/upgrade. So you better debug and fix all bugs before doing so!
What if you fail at that, or if you anyway need to add things and evolve the functionalities? There isn’t a unique answer for all scenarios, but there are things you can do: for example in my app, should I need to deploy a new version of the contract, I would retrieve past messages from v1 of the contract, and save/load new messages from v2. Bigger apps that are composed by multiple contracts might use a smart contract as a “gateway/proxy” for functionalities implemented by other separate contracts — this proxy could have functions (only usable by the owners) to change the address of the sub-contracts it points to. So if proxyContract uses storeContractV1 deployed at 0x123, and you need to fix storeContract, you might call a function like proxyContract.setStoreContract(address_for_storeContractV2) that changes the address of storeContract in a variable held by proxyContract. Of course in order to be able to do this 1) the public interface of storeContract must be the same between v1 and v2, and 2) you must appropriately structure the code (and create the setStoreContract() function) before the initial release. This article by Jack Tanner explains this and other approaches with more details.
NOTE: if you wanted to make sure previous versions of your contracts are no longer accessible, you’d need to implement a function (call it “kill” or something similar, and make sure it has the onlyOwner modifier defined by the Ownable contract!) that calls selfdestruct as shown in the official docs.
Who am I / what do I do? I proudly work as a Solutions Architect in the Mobile Team @ ASOS.com (iOS app | Android app), and we’re always looking for strong, friendly and talented developers that want to have an impact on how tens of millions of customers shop online. ASOS is the biggest online-only retailer in UK and, let’s be real, the best tech+fashion company in the world. Some of the technologies we use are Swift for iOS, Kotlin for Android, React and Node on the web frontend, .NET and Azure on the backend. If that sounds interesting to you, and you happen to live in beautiful London (or are willing to move here…after all it’s the best city in Europe except for some in Italy!), do get in touch with me!
