Transparent Voting on Hedera Consensus Service - The Origin of Attica
Headshot Waylon
Jun 03, 2020
by Waylon Jepsen
Developer Evangelist

In the fall of 2019, I was hired as a cybersecurity intern by the Academic Computing and Networking Services at Colorado State University. It was the last semester of my undergraduate career pursuing a degree in mathematics and philosophy and I was grateful for the opportunity to work in a field of great interest to me.

The internship was divided into teams. As I had prior interest in distributed ledger technology (DLT) and my experience building an Ethereum mine, I was placed in the DLT team where I met my coworker Derek Larkins, the team lead, and a fellow student of mathematics. Derek and I made up our whole team. We were assigned to innovate upon DLT networks and formally explore use cases.

The first couple of weeks on the job Derek and I each spent time writing our own blockchains so that we really understood the technology of chain coding. We learned lots. However, we kept running into issues regarding scalability and longevity of chain coded networks that are innate to the foundation of chain coding. Every time a transaction occurs there is additional data written into the blockchain increasing the validation time of each block which raises questions around the longevity of the technology. As a result, we kept our ears open for DLT’s that were not chain coded.

With some influence from my philosophy of law course in combination with the current voting security problems across the nation, we had decided to build a voting security application. We spent lots of time trying to figure out what to call our project and eventually settled on the name Attica. Attica is the region of ancient Greece in which democracy was founded.

From Smart Contract to Consensus Service

We spent cycles writing a smart contract in solidity that we planned to deploy on the Ethereum network. In October of 2019, we were supported by ACNS to attend the Global Blockchain Summit in Westminster, Colorado, where we met Cooper Kunz, a developer evangelist for Hedera Hashgraph. Derek and I both knew that there was a lot of snake oil in the land of DLT’s. We were prepared for this. As such, it was refreshing when we heard Cooper give his presentation on Hedera, a Directed Acyclic Graph (DAG) DLT that showed to be promising and have clear technical advantages to other DLT’s.

We were impressed with the capabilities of the hashgraph consensus algorithm. The algorithm dissolved our current apprehension regarding scalability and longevity and presented additional advantages. Additionally, Hedera supported smart contracts written in solidity. I nervously introduced myself to Cooper, then complimented his presentation and the technology he was working with.

After the summit, Derek and I decided that we would not deploy our smart contract on the Ethereum network but deploy the project on Hedera. We followed up with Cooper and connected to talk about the project that Derek and I were working on. Cooper recommended we build our application on Hedera’s soon to be released Consensus Service, an API for sending messages to the network, rather than using our smart contract. This would allow for an even lower transaction cost, while still implementing the security and transparency we desired for our application.

The Consensus Service provides a scalable log of immutable messages with each and every message verified by the hashgraph consensus algorithm. Each message reaches finality and the information is verifiable by a network explorer. The Consensus Service provided additional advantages over a smart contract. A smart contract had higher transaction costs and the limitations of development native to the solidity programing language. The Consensus Service provided an in-between of decentralized security without the limitations of smart contracts.

Within the next few months, we had a working prototype. ACNS gave us some additional help from the web team within our internship and we have since been able to build Attica to what it is now.

Verifiable votes with Attica

Attica provides consensus validation for every vote cast. Currently, no technology provides this service with provable security up to the asynchronous Byzantine fault tolerance that Hedera provides. Attica is built primarily in JavaScript and can be described as a Node.JS server interacting with the Hedera Consensus Service to facilitate elections.

We assign each “election” as a Hedera topic where votes are cast by users as “messages” under the election topic identifier. To prevent voter bias, all votes are encrypted with PGP keys until the election is over, abiding by a commit and reveal structure. The votes are committed through the Hedera Consensus Service under the designated election topic identifier to be sure there is no double sending, counting, or voting from unregistered individuals.

This model also allows any individual to check to see that their encrypted vote has been cast at any time by utilizing a network explorer such as HashScan without revealing who the voter is and who/what they have voted for. Once the election has ended, the private key, that is used to encrypt the votes with, is provided in a final message to the topic with the tallied votes. This way, the voters have the power to verify that the votes are counted correctly, and that the election is facilitated fairly.

A critical component of voting security is voter identity authentication. It is necessary to be able to ensure that a voter is who they say they are. This can be done in a variety of ways, for example for the Hedera 2020 hackathon we issue unique identifier codes to the registered participants’ emails. The unique identifier codes are then hashed with the emails of the users they were issued to ensure anonymity. One potential piece of criticism here is that this assumes that the user’s emails are secure. There are many different ways to authenticate identity and while Attica is still young, we are still exploring the best way to do this. In upcoming the CSU student elections, we will be utilizing an identity service provider (ISP). This is also due to the ease of integration within the network infrastructure used by Colorado State University. We don’t claim that our identity authentication is without imperfection. However, we take identity authentication very seriously and are working diligently to identify flaws and integrate the most secure solutions. We will not move forward with aspirations of integration to state jurisdiction until we have the utmost confidence in our method of identity authentication. The value of our application lies within its security properties.

Moving voting forward

We hope that the use of Attica by a state founded university will set an example of how voting can be improved. Digital voting is a topic of high interest among cybersecurity professionals and we are optimistic about having a large positive contribution to the direction of this technology.

We plan to continue to improve the capabilities and security of Attica and to set an example for legislators to see this valuable use case of distributed ledger technology. For those participating in the Hedera 20 hackathon, keep an eye out for your chance to try out Attica to vote for your favorite project. Following this test, we aim to deploy our application at Colorado State University for the student government elections. As voting jurisdiction is handled by states, we hope to eventually implement our application within the state of Colorado, and later across the nation, setting a standard, and increasing the ease and security of democratic processes.

We have been blown away by the support by Hedera, and we have lots of gratitude for Cooper and his brother Gehrig for communicating with us and presenting us with opportunities to test our application and demonstrate our value to larger audiences. If you'd like to get in touch with me, please don't hesitate to do so.