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:
- Enable Crowdstart Capital to manage an initial list of candidate developers
- 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:
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
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.
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.
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.