CROWDVOTE – Modular Building Blocks for an Ethereum Voting DApp

The next phase of the Crowdstart XSC plan is CROWDVOTE, a crowd-based voting mechanism to distribute CrowdstartCoins XSC to the best blockchain projects out there. In this post, we’ll give you a preview of the technical underpinnings for our CROWDVOTE decentralized application and a short update on where we’re at in the development process.

The DApp is still a work in progress, but we’ve passed some important internal milestones. We’d like to update the community with an overview of the minimum technical requirements for the DApp, an overview of the development tools we’re using and a description of the tech stack we’re building for the DApp.

We at Crowdstart Capital don’t think that we are the best people to decide who is eligible to receive CrowdstartCoins XSC. It should rather be the responsibility of the entire blockchain community to form opinions and make decisions that define the distribution of the token. We want XSC to be THE token for rewarding contributions to the blockchain ecosystem at-large. The CROWDVOTE DApp is the tool to enable this.

CROWDVOTE Minimum Viable Product DApp Requirements:

Empower XSC Holders and only XSC Holders to vote for their favorite projects

Allow cryptographically verifiable voting without the need to send XSC to any central party or tie up XSC in an escrow contract for the duration of the voting period.

Distribute XSC automatically to the winner at the end of the voting period.

CROWDVOTE Roadmap – Beyond Minimum Viable Product

Provide a mechanism by which XSC holders can nominate developers and projects to vote on

Allow voters to vote on the amount of XSC to be distributed in a voting period

The rest of this post is divided into three sections.

Our Development Tools: DApp development can be a bit daunting due to the number of development tools available. In this section, we’ll list the tools we’re using to build the DApp and why we chose them.

Technology Stack: In this section, we’ll outline the components of our technology stack and describe how they fit together. One of the most challenging things about DApp development is just understanding how all the technology really works together. This section will address our choice of front-end technology, hosting, authentication and finally our smart contracts.

If you’re just anxious to hear about the status of the CROWDVOTE DApp development you can scroll to the very end for an update on our development process.

Our Development Tools:

Truffle: Truffle is one of the most popular development frameworks for Ethereum. It’s written in javascript so it matches the rest of our project quite well and doesn’t require us to switch contexts while developing. We’re using it in this project to handle smart contract compilation, linking, deployment and binary management as well as migrations.

Node.js: Node is a JavaScript runtime which we use for development. It allows us to run JavaScript code locally for development and testing.

npm: This is the largest JavaScript package manager out there. It helps manage the installation of the necessary components via the command line.

http-server: This is a simple command line based http server. It allows us to run the React, JavaScript and associated HTML code locally during development and testing.

Technology Stack

Front-end:

JavaScript: We’re using mostly ES6/ ECMAScript2015. The reasons for picking JavaScript were pretty straightforward. The wide adoption of the language for front-end work and the wide availability of libraries/frameworks were both important factors. The fact that we’re connecting to our smart contracts via web3.js (the Ethereum compatible JavaScript API) was also a deciding factor in favor of JavaScript as our primary development language.

React JS: React is an easy to use JavaScript library which allows us to create a reactive DApp front-end which works on many different devices. We did consider developing using Meteor but Meteor is designed to provide a full tech stack including back-end functionality via a server that’s running Node, MongoDB, etc.. For this project, our backend is essentially the Ethereum blockchain which means Meteor doesn’t really fit our needs. For our purposes the React library allows us to make prettier DApp more quickly than would otherwise be possible.

Babel: Babel is a JavaScript compiler that allows us to use the new EC6/ECMAScript 2015 JS syntax without worrying about browser compatibility. Many of the newest features of JavaScript aren’t available for all browsers. One good example of this is arrow functions which despite being very common in modern JavaScript programming, aren’t uniformly supported across browsers.

Webpack: Webpack is a static module bundler for JavaScript applications. Specifically, this means that it recursively builds a dependency graph that includes every module which our DApp needs and then packages all of those modules into a bundle which can be loaded by the browser. With this approach, any time one file depends on another it is treated as a dependency.

Hosting:

IPFS (Interplanetary File System): IPFS is a peer-to-peer hypermedia protocol. That basically means that it’s a cutting-edge decentralized replacement for the HTTP protocol. We’re initially planning to use IPFS for decentralization and censorship resistance. One potential disadvantage with IPFS at the moment is long loading times. As the network of IPFS nodes scales though it should actually become faster and more efficient than HTTP.

Ethereum API and Authentication Methods

Our front-end communicates with the backend via Web3.js. Web3.js is the JavaScript API which implements the generic JSON-RPC spec. Web3.js can also be described as a collection of libraries which allow one to interact with a local or remote Ethereum node using an HTTP or IPC connection.

The easiest way to allow users to interact with the Ethereum blockchain is by using the MetaMask plugin. It exists as a browser extension that enables the signing of transactions on both testnets, private networks and the public blockchain. MetaMask enables an application (decentralized or otherwise) to read from the blockchain and propose transactions to the current user. It does this by injecting a Web3 object and the Web3.js library into the javascript context of the user’s browser. When the user authorizes a transaction via Metamask we use a web3.js call to trigger the sending of a JSON-RPC request to a node specified by the user in Metamask (e.g. etherscan.io, infura.io, etc.).

RPC is a general API architecture for data exchange and invocation of functionality. In our case we use it for interacting with the nodes and, in extension, the EVM. RPC is an alternative to the common REST architectural style. It’s used because it provides a more direct server-client connection to the blockchain and because given the immutable nature of the blockchain the CRUD model isn’t exactly optimal.

In the other direction, the node sends information via JSON-RPC back to the user over HTTP and it is implemented by the web3.js API installed on the user computer or in the browser. Users with Metamask installed in a normal browser or who are using a web3.js-enabled DApp browser can interpret this information and update the front-end accordingly.

Smart Contracts

Programming smart contracts is a bit different from programming other applications. Once contracts are deployed they can only be swapped out for other contracts, not directly updated, assuming that such a modular handoff was provided for in the initial contract code. Additionally, it is best to use battle-tested contracts that have been peer-reviewed where possible since mainnet Ethereum contracts handle valuable tokens and ether.

To facilitate speedy development and security we’ve based our contracts around the smart contract based voting architecture outlined in Giveth’s MiniMe project.

There are three contracts which act together to provide the voting logic and grant voting rights to XSC holders.

Controlled.sol

TokenController.sol

XSC_Mini_Token.sol

At the heart of this system is a token factory which allows us to clone the XSC token distribution at the start of a given block. You can think of these XSC_Mini tokens like an automatically assigned voter identification card. They are only issued to XSC holders but don’t alter anything about the XSC distribution. Much like you don’t lose your citizenship if you lose your voter identification card, nothing happens to your XSC if you receive or use XSC_Mini in the CROWDVOTE DApp.

Furthermore, the contracts allow us to reset the quantity of XSC_Mini to match the new distribution at the beginning of each voting period. This is achieved through the use of a separate token controller contract which can freeze/generate/destroy/transfer the XSC_Mini tokens at will. The logical consequence of this is that XSC_Mini has no speculative value.

All of this complexity is hidden from the user. CROWDVOTE DApp voters holding XSC will automatically be authorized to vote when they access the DApp either via a normal browser with Metamask installed (assuming they are logged in to the account which holds the XSC tokens) or via a Web3.js enabled DApp browser. Users won’t see or interact with the XSC_Mini tokens except when authorizing the gas costs necessary for casting a vote (which is accomplished by sending XSC_Mini to the voting contract in the background). Non-holders will be redirected to one of the decentral exchanges where XSC can be purchased while developers will be redirected to a form where they can request XSC as a reward for contributions to the blockchain ecosystem.

Votes will be tallied automatically by the smart contract to which they are sent and we will enable the contract to directly distribute the XSC rewards as soon as the voting period ends. Following that the XSC_Mini controller will reset the XSC_Mini balances to match the overall XSC distribution and the process will begin again.

Since the smart contracts are set up in a modular fashion we will be able to eventually reassign control of the XSC_Mini and voting logic in the future. Our long-term vision for CROWDVOTE is that we will be able to allow community members to define both the voting logic and the nominated developer list decentrally.

Development Status Update

Last, but not certainly not least we want to give you a short update on the status of our development efforts. At this point, we have a CROWDVOTE proof of concept up and running. We still need to rebuild the front-end and redesign parts of the smart contracts to facilitate a custom voting logic. The basics are however already running, so we’re confident that we’ll be able to launch this DApp by the Daho.am Tech Conference on July 24, 2018.

We’re also planning to launch our own wallet and DApp browser for the conference but we’ll outline that in a separate post later this week.