In this tutorial, we will create a simple Voting dapp (very similar to our popular ‘Hello world voting dapp’ many of you might know!). The Solidity contract will be the same but we will use Ethers.js instead of Web3.js for the frontend. The application is extremely simple, all it does is initialize a set of candidates, let anyone vote for those candidates and display the total votes received by each candidate.

If you are new to Ethereum, here are some courses that can help you get started.

The goal of this tutorial is to:

1. Set up the development environment
2. Learn the process of writing a contract, compiling it and deploying it in your development environment
3. Interact with the contract using ethers.js through a nodejs console
4. Interact with the contract using ethers.js in a simple web page to display the vote counts and vote for candidates through the page

If you have already worked through the ‘Hello world voting dapp’, you can skip to Step 3.

This is how I would visualize this application we are going to build.

1. Setting up the development environment

Instead of developing the app against the live blockchain, we will use an in- memory blockchain (think of it as a blockchain simulator) called ganache. Below are the steps to install ganache, ethersjs, solc (to compile our contract) and start the test blockchain on a macos. The exact same instructions work on linux as well.

zastrin@macbook$ brew update
zastrin@macbook$ brew install nodejs
zastrin@macbook$ mkdir -p ethereum_voting_dapp/chapter1-ethersjs
zastrin@macbook$ cd ethereum_voting_dapp/chapter1-ethersjs
zastrin@macbook$ npm install ganache-cli ethers solc@0.5.3
zastrin@macbook$ node_modules/.bin/ganache-cli

Ganache CLI v6.0.3 (ganache-core: 2.0.2)

Available Accounts

==================

(0) 0x5c252a0c0475f9711b56ab160a1999729eccce97
(1) 0x353d310bed379b2d1df3b727645e200997016ba3
(2) 0xa3ddc09b5e49d654a43e161cae3f865261cabd23
(3) 0xa8a188c6d97ec8cf905cc1dd1cd318e887249ec5
(4) 0xc0aa5f8b79db71335dacc7cd116f357d7ecd2798
(5) 0xda695959ff85f0581ca924e549567390a0034058
(6) 0xd4ee63452555a87048dcfe2a039208d113323790
(7) 0xc60c8a7b752d38e35e0359e25a2e0f6692b10d14
(8) 0xba7ec95286334e8634e89760fab8d2ec1226bf42
(9) 0x208e02303fe29be3698732e92ca32b88d80a2d36

Private Keys

==================

(0) a6de9563d3db157ed9926a993559dc177be74a23fd88ff5776ff0505d21fed2b
(1) 17f71d31360fbafbc90cad906723430e9694daed3c24e1e9e186b4e3ccf4d603
(2) ad2b90ce116945c11eaf081f60976d5d1d52f721e659887fcebce5c81ee6ce99
(3) 68e2288df55cbc3a13a2953508c8e0457e1e71cd8ae62f0c78c3a5c929f35430
(4) 9753b05bd606e2ffc65a190420524f2efc8b16edb8489e734a607f589f0b67a8
(5) 6e8e8c468cf75fd4de0406a1a32819036b9fa64163e8be5bb6f7914ac71251cc
(6) c287c82e2040d271b9a4e071190715d40c0b861eb248d5a671874f3ca6d978a9
(7) cec41ef9ccf6cb3007c759bf3fce8ca485239af1092065aa52b703fd04803c9d
(8) c890580206f0bbea67542246d09ab4bef7eeaa22c3448dcb7253ac2414a5362a
(9) eb8841a5ae34ff3f4248586e73fcb274a7f5dd2dc07b352d2c4b71132b3c73f

HD Wallet

==================
Mnemonic: cancel better shock lady capable main crunch alcohol derive alarm duck umbrella
Base HD Path: m/44'/60'/0'/0/{account_index}
Listening on localhost:8545

Notice that the ganache-cli creates 10 test accounts to play with automatically. These accounts come preloaded with 100 (fake) ethers.

2. Simple voting contract

We are going to use the solidity programming language to write our contract. If you are familiar with object oriented programming, learning to write solidity contracts should be a breeze. We will write a contract (think of contract as a class in your favorite OOP language) called Voting with a constructor which initializes an array of candidates. We will write 2 methods, one to return the total votes a candidate has received and another method to increment vote count for a candidate.

Note: The constructor is invoked once and only once when you deploy the contract to the blockchain. Unlike in the web world where every deploy of your code overwrites the old code, deployed code in the blockchain is immutable. i.e, If you update your contract and deploy again, the old contract will still be in the blockchain untouched along with all the data stored in it, the new deployment will create a new instance of the contract.

Below is the voting contract code with inline comment explanation:

Copy the above code to a file named Voting.sol in the ethereum_voting_dapp/chapter1-ethersjs directory. Now let’s compile the code and deploy it to ganache blockchain. Follow the commands below to compile the contract.

zastrin@macbook$ node_modules/.bin/solcjs — bin — abi Voting.sol
zastrin@macbook$ ls
Voting.sol Voting_sol_Voting.abi Voting_sol_Voting.bin

When you compile the code successfully using the command above, the compiler outputs 2 files that are important to understand:

1. Voting_sol_Voting.bin: This is the bytecode you get when the source code in Voting.sol is compiled. This is the code which will be deployed to the blockchain.
2. Voting_sol_Voting.abi: This is an interface or template of the contract (called abi) which tells the contract user what methods are available in the contract. Whenever you have to interact with the contract in the future, you will need this abi definition. You can read more details about ABI here

We will now use ethersjs library to deploy our application and interact with it.

First, run the ‘node’ command in your terminal to get in to the node console and initialize the ethers object. All the code snippets below need to be typed in the node console. To compile the contract, load the bytecode and abi from the file system in to a string like shown below

zastrin@macbook$ node
> ethers = require(‘ethers’)
> bytecode = fs.readFileSync(‘Voting_sol_Voting.bin’).toString()
> abi = JSON.parse(fs.readFileSync(‘Voting_sol_Voting.abi’).toString())

Next is to initialize the provider which is a generic interface to connect to the blockchain. Since we are running the blockchain locally, we will use the JsonRPCProvider to connect to it. If you wanted to connect to a real blockchain, you have many other provider options. Once connected, you can test the connection by querying ganache and listing all the accounts. Running the below commands in your nodejs console should list 10 accounts.

> provider = new ethers.providers.JsonRpcProvider()
> provider.listAccounts().then(result => console.log(result))

The next step is to initialize the signer which is used to sign the transactions. We can select which account we want to use (we have 10 accounts ganache in setup) by passing the index to getSigner as shown below. Once the wallet is intialized, create a contract factory and deploy the contract as shown. The deploy function takes an array of arguments that is passed to the constructor of the contract. In our case, we pass in the names of the candidates. We have to explicitly convert string to bytes32 because our contract takes bytes32 as argument.

> signer = provider.getSigner(0)
> factory = new ethers.ContractFactory(abi, bytecode, signer)
> contract = null
> factory.deploy([ethers.utils.formatBytes32String(‘Rama’), ethers.utils.formatBytes32String(‘Nick’), ethers.utils.formatBytes32String(‘Jose’)]).then(© => { contract = c})

If you successfully deployed the contract, your contract object should have all the details of the deployed contract. There are hundreds of thousands of contracts deployed on the blockchain. So, how do you identify your contract in that blockchain? Answer: contract.address. When you have to interact with your contract, you need this deployed address and abi definition we talked about earlier.

3. Interact with the contract in the nodejs console

> contract.totalVotesFor(ethers.utils.formatBytes32String(‘Rama’)).then((f) => console.log(f.toNumber()))
> contract.voteForCandidate(ethers.utils.formatBytes32String(‘Rama’)).then((f) => console.log(f))
> contract.totalVotesFor(ethers.utils.formatBytes32String(‘Rama’)).then((f) => console.log(f.toNumber()))

Try the above commands in your node console and you should see the vote count increment. Every time you vote for a candidate, you get back a transaction id: Example: ‘0xdedc7ae544c3dde74ab5a0b07422c5a51b5240603d31074f5b75c0ebc786bf53’ above). This transaction id is the proof that this transaction occurred and you can refer back to this at any time in the future. This transaction is immutable. This immutability is one of the big advantages of blockchains such as Ethereum.

4. Webpage to connect to the blockchain and vote

Now that most of the work is done, all we have to do now is create a simple html file with candidate names and invoke the voting commands (which we already tried and tested in the nodejs console) in a js file. Below you can find the html code and the js file. Drop both of them in the ethereum_voting_dapp/chapter1-ethersjs directory and open the index.html in your browser.

You should now see the vote counts and you should also be able to vote for candidates.

If you are using a wallet like Metamask, you will need to use a Web3 provider instead of JsonRPCProvider we used earlier. To do that, simply change the provider in your index.js to:

provider = new ethers.providers.Web3Provider(web3.currentProvider);

If you want to interact through Metamask, you can’t just open index.html and interact in your browser anymore. You have to server the file through a server. So, install a simple webserver and start like below

zastrin@macbook$ npm install http-server
zastrin@macbook$ http-server

You can now go to localhost:8080 and interact with your application. Below is a quick demo which includes loading test ether account into metamask.

I hope you were able to follow along and get the application working.

If you run into issues getting the application working, feel free to DM me on twitter @zastrinlab or email mahesh@zastrin.com.

Thanks to Richard for the feedback.

If you liked this tutorial, check out more interesting real-world project based courses

Build an Ethereum dapp using ethers.js was originally published in Zastrin on Medium, where people are continuing the conversation by highlighting and responding to this story.

At Zastrin, we focus on creating the best online courses possible to help developers learn blockchain programming. Our courses are self-paced and hands-on where you learn by building an end to end real-world product.

We are also constantly thinking how blockchain can be leveraged in the education space. One of the common use cases some companies are tackling is certification (issuing certificates on the blockchain). We believe there are many more areas where blockchain can be used effectively. At Zastrin, we wanted to explore the use case related to licensing the courses as Non Fungible Tokens (NFT). The following section explains our experiment, thought process, what we hope to learn from this experiment and our implementation details.

This article assumes that you know what Non Fungible Tokens are. If not, here is a quick primer or we have a complete developer’s guide course that teaches you NFTs in depth and implementing an NFT application.

Problem description

When you purchase a (paper) book, you can hold on to it forever, gift it to someone or resell it in a marketplace like eBay, Amazon etc. You can also borrow books from a library for certain duration. Why can’t ebooks (online courses in our case) be bought and sold similarly in an open market? There are a number of edtech companies where you buy a course and you own it for the lifetime. Majority of the people don’t go back to the course once they have completed it. Wouldn’t it be nice if you could just resell it or gift it to someone?

It doesn’t make much sense to just copy the offline world to the online world because they are fundamentally different. It doesn’t take much additional resources to create multiple copies of the ebook/course. You should do it only if there are additional things you can do online (course software license) which you could never do offline (books). Few such use cases are:

1. Compensating the author: Every time the license changes hands, the course author should earn some commission. It is impossible to do this with books.
2. Resale price: When you buy a second hand book, the price is mostly based on the condition of the book (new, good, acceptable etc). What if someone has done a really good job of highlighting important content, taken notes and want to sell all of it? That can’t be done with books but can definitely be done with online content.

What other benefits can you think of? (Please let me know in the comments).

We wanted to see what would happen if these features are enabled for Zastrin courses. Would people start reselling their tokens, would they gift it, would they trade their Zastrin courses for Cryptokitties :) or would they just hold on to it forever? The next section explains how we used NFTs to accomplish this.

How Zastrin NFTs work?

To enable trading of Zastrin courses, we tokenized the course licenses using NFTs. What that means is, each course license is represented by a Non Fungible Token. If you own one of these tokens, you have the right to access that particular course on Zastrin. You can see all our courses on our website and you can see a few corresponding NFTs minted and listed on OpenSea NFT marketplace https://opensea.io/assets/zastrincourses.

Anyone who owns one of these NFTs can visit the link https://www.zastrin.com/courses/redeem on a web3 enabled browser and get access to the course. There are a number of Ethereum wallets in the market that support NFTs. You can easily transfer it to another address or use OpenSea to transfer your token. If at some point you transfer your NFT to another user, you will lose access to the course as soon as they redeem the NFT.

Why do you need Blockchain/NFT for this?

If you understand how Zastrin NFTs work, I hope your next question is, why do you need blockchain/NFTs to implement these features? It could have been implemented with in the Zastrin webapp and it would work without any friction.

Here is why we feel it was worth tokenizing the courses:

1. Once the course license is tokenized, any Ethereum wallet can automatically handle the license. License can be sent and received seamlessly since the token adheres to ERC721 standard. You only need to rely on zastrin website for accessing the course and not for trading.
2. There are many NFT exchanges and course licenses can be listed on all of them without any additional work (Our NFTs are currently listed on OpenSea and it was a smooth process). This will help with discovery and act as a new distribution channel.
3. Most of these exchanges allow you to set commission on sale. So the author gets compensated for every trade.
4. You can bundle multiple NFTs (courses) and innovate in pricing.
5. We plan to add highlighting and notes feature that will be associated with a license. NFTs will be priced differently based on these properties.

Outside of these benefits, we believe this will be a good way to introduce people to the world of crypto and NFTs.

As mentioned in the beginning, this is an experiment. It might succeed or it might fail, we hope to learn from this experiment. If you can think of ways to improve, please let us know. Also, if you are an author who is interested in tokenizing your content, you can reach out to us at nft@zastrin.com.

You can buy some courses for yourself or gift it to others by purchasing tokens at https://opensea.io/assets/zastrincourses

Happy #buidling!

Zastrin course licenses as NFTs was originally published in Zastrin on Medium, where people are continuing the conversation by highlighting and responding to this story.

One of the friction points for Ethereum dapp adoption is that the users have to pay gas(txn fee) to get their transactions recorded on the blockchain. For example, I have a simple voting dapp that lets anyone vote for candidates and the votes are stored on the blockchain. A user who wants to record her vote on the blockchain has to pay a transaction/gas fee. This is not ideal because as a dapp owner, you are expecting your application users to have Ether to pay for gas when all they want to do is perform a simple action which has nothing to do with transferring money. But if the transaction needs to be executed on the blockchain, there is no other option but to pay the fee. What if there was a way for users to execute transactions securely (vote for a candidate in our example) and let someone else (potentially contract owner) record the transaction on the blockchain and pay for it?

Thanks to this tweet from John Backus which had just enough information to help me implement such a solution for my voting dapp.

John Backus on Twitter

Ethereum dApps will probably move to users signing blobs of data using private keys that don't actually hold any funds. dApp operators will submit txs including these signatures, proving the end user gave the 👍. Lets business pay for gas, deal with nonces, retry TXs, etc.

The entire working code is here: https://github.com/maheshmurthy/ethereum_voting_dapp/tree/master/chapter4

The demo application is here: https://www.zastrin.com/voting-dapp-without-paying-gas.html

I wanted to share details on how I implemented this solution for my simple dapp so more people can adopt this technique in their own dapps and could hopefully improve upon it. This post covers the following:

1. A very high level overview of the public key cryptography and digital signatures which are key to understanding this solution
2. The solution details and the new application flow
3. Implementation details (frontend js and Solidity contract code)
4. Discuss potential issues and enhancements

Digital Signatures

For this solution to make sense, you will need a basic understanding of how digital signatures work in cryptography. Feel free to skip this section if you know public key cryptography. I will try to explain the concept of public/private keys and digital signatures at a very high level but I highly recommend learning more in detail - wikipedia is a good place to start.

Public key cryptography is a cryptographic system where you have 2 keys — public key (Pu) and a private key(Pr). You give out your public key to the entire world and keep the private key to yourself. Ex: You Ethereum address is a public key (It’s actually derived from Public key but for this exercise, let’s just think of it as public key) and your private key is stored either in your browser or on your phone/computer. As you know, for someone to send you Ether, they just need to know your public (account) address. However, only you can access the funds you own because you are the only one who knows your private key.

Public key cryptography has algorithms that let you encrypt, decrypt, sign and verify messages using your pair of keys.

Let’s see what signing and verifying a message means through an example. Let’s say user Kim has a pair of public/private keys

Pu = “0x44ac12c1e3dfd8edaf83b6f65918229d5279a6f5”

Pr = “dbc226043e390cf39280e5edfd418d7ad61931c76509270867d300f110c46506”

To sign a message, Kim executes a function sign(“Vote for Alice”, Pr) which outputs an alpha-numeric string

signature = 0x9127112de0033555c7f6508d963d484965a953844dfcff092712102c236467a25af57edc53b63880ea39af8ce7334f6d77a8206e805305e7c6ad919d12bfae5c1b

This is the digital signature of the message “Vote for Alice” signed by Kim using her private key Pr.

Now anyone can verify that message “Vote for Alice” was signed by Kim by executing the verify function, verify(“Vote for Alice”, signature) which outputs “0x44ac12c1e3dfd8edaf83b6f65918229d5279a6f5”. If you notice, that output is Kim’s public key Pu (remember, everyone knows it’s Kim’s public key) which means the message was definitely signed by Kim. If you tamper with the signature or message (by say changing even one character), the verify algorithm outputs a completely different public key and you will know that the message was tampered because the public key will be different from Pu.

Solution Details

If you understand digital signatures, the solution is extremely trivial. Let’s see how it can be used in our voting application to save users from paying gas fee without compromising their vote. You can see below all the users of dapp and the actions they perform.

1. A voter indicates their intention to vote for a candidate by signing a message using their private key. They won’t submit their transaction to the blockchain, so no txn fee is paid. The message queue in the diagram above is just an off chain location where all the vote details are stored.
2. Anyone willing to pay txn fee (usually the contract owner) takes the signature, candidate name and voter’s account address and submits them to the blockchain.
3. The smart contract uses the verify function to derive the public key (Ethereum account address) based on the candidate name and signature. If the derived public key matches the address of the user who signed the message, it records the vote or else fails the transaction.

Implementation Details

Let’s now look at the actual implementation and how all the pieces fit together.

Step 1: Sign the message

The first step is to sign the message as a voter. We will use eth_signTypedData function to sign our message. This function has been implemented in Metamask which makes it really easy to sign messages. You can find more details and discussion about this proposal here: https://github.com/ethereum/EIPs/pull/712. You can find the code to sign the message below.

One really important thing to note is, internally eth_signTypedData hashes the message and the hashed message is what gets signed. You can refer to typedSignatureHash function here for more details on hashing.

Step 2: Submit the signed vote to the blockchain

Since this is just a demo application, we don’t store the signature and other details anywhere. It is directly displayed on the page after the message is signed. Anyone can take these details and submit to the blockchain. Here is the code that submits the vote to the blockchain:

Step 3: Verify the vote details in the smart contract

We now verify in the smart contract if the submitted vote info is valid and record the vote.

Zeppelin has a handy library called ECRecovery we use to verify the signed message. The voteForCandidate function verifies the signed message (recover function) and updates the vote count if the verification succeeds.

If you remember, I mentioned earlier that eth_signTypedData hashes the message (“Vote for Alice”) before signing it? The solidity recover function doesn’t have any knowledge of the hashing function used within eth_signTypedData and so it can’t verify the message “Vote for Alice”. It has to generate the hash of the message “Vote for Alice” and then verify it. Instead of generating the hash inside the contract, we pre-hash all the messages beforehand and pass it in the constructor so it is easy to lookup when verifying. The code to generate the hash is in the migration file below

That is all the code you need to get the new application working!

I created a quick demo to show how this application works

The entire working code is here: https://github.com/maheshmurthy/ethereum_voting_dapp/tree/master/chapter4

The demo application is here: https://www.zastrin.com/voting-dapp-without-paying-gas.html

Potential issues to address

There are a few issues to consider when building a real dapp using this technique. Some of them are listed below:

1. Where are the signed messages stored? You can use some kind of a queuing system to store these messages.
2. What is the guarantee that the signed message eventually is submitted to the blockchain?
3. Storing the hash of all the messages in the blockchain is not ideal, so what is the best solution for it?

If you have thoughts on how to address these issues or if you see any flaws in this solution, please leave a comment!

Note: Apparently, eth_signTypedData API is still not stable and has been implemented by only metamask. Please beware of this if you are planning to use this technique in mainnet/production.

Further Reading

https://en.wikipedia.org/wiki/Public-key_cryptography

https://en.wikipedia.org/wiki/Digital_signature

https://github.com/danfinlay/js-eth-personal-sign-examples/

https://danfinlay.github.io/js-eth-personal-sign-examples/

https://github.com/ethereum/EIPs/pull/712

Thanks Chris Whinfrey and Febin John James for reviewing drafts of this article.

Learn More

If you are interested in learning to build Ethereum decentralized applications, I have a few interesting courses at www.zastrin.com

If you would like to get notified when I write more tutorials, you can subscribe here.

How to save your Ethereum Dapp users from paying gas for transactions was originally published in Zastrin on Medium, where people are continuing the conversation by highlighting and responding to this story.

Blockchain is so fascinating and revolutionary that I wanted to do my part in helping this technology go mainstream. What better way to do that than bring more developers in to this space and help them learn and build products and solutions?! That was the reason I started Zastrin. If I can help one developer learn this and she goes on to create a decentralized bank and brings 1,000,000 unbanked in to the system, I would have indirectly helped 1,000,000 people!

I have always believed that you best learn new technologies by tinkering and building projects. This is what I am trying to emulate at Zastrin. I want this to be a place where people learn, build and share their projects. The response and support I have received since I started Zastrin has far exceeded my expectations. I hope to continue creating more courses and trying new things. I want Zastrin to be more than just offer courses. I want to run more blockchain experiments and share the lessons here. I have many projects in the works. So stay tuned!

Many people have asked, what does Zastrin mean? It means ‘Armed with knowledge’ in Sanskrit — an ancient Indian language. So, arm yourself with knowledge and go #buidl something!

If you want to learn more about my thoughts and ideas, you can reach me at mahesh@zastrin.com.

Happy Learning!

Hello, World! was originally published in Zastrin on Medium, where people are continuing the conversation by highlighting and responding to this story.