Sententia

Inspiration- We wanted to select a problem statement that is a pressing issue in Web 3 space, solving which will make us satisfied, and a problem statement that is challenging. We never wanted to have a problem statement for sake of hackathon but instead a real-life problem statement that can be turned into a product to be used by real users to solve some of their problem

We loved to debate about the current governance systems of the DAOs and brainstorm ways to improve them. We have always believed in using Blockchain technology to create a decentralized and fairer world for everyone.

It seemed pretty ironic that the governance of a decentralized protocol was trusting a centralized system for collecting and calculating votes. We were pretty surprised when we realized that voting of most of the protocols relies on an offchain platform. We understood that onchain voting is not encouraged by most of the DAOs due to the gas fees. But settling for a centralized voting system

Offchain voting heavily relies on a third party-

Trusted to be a good actor while collecting the votes from the voters and the final computation for the vote counts. (Current solutions have plenty of scope to play foul)

Given access to complete information of who has voted for which option (this information is also available to the voter community, which can lead to bribery)

This led to the genesis of Sententia (which literally means Opinion in Latin).

We created a problem statement for ourselves- Enable an offchain voting system where the calculation of final votes is verifiable and who has voted for whom is not known to anyone (including the third party)

What it does- Sententia is making an Off-chain vote counting system reliable and trustworthy without having any third party acting as a central point of failure.

Users generate a Proof of Vote for the options voted. The count of the Proof of Votes will lead to transparent and back trackable calculations of the final results. The Proof of Votes will be encrypted, with only voters having the power to decrypt it. The third party will fail to tamper with the votes, and hence the results in an off-chain voting system.

Smooth, third-party free conducting of off-chain voting will be done.

More on this in detail soon.

(Note- Proof of Vote is a ZK Proof of someone has voted for some option, note ‘someone’ here is a private input)

How we built it- We need to create a solution where-

A voter has cast a vote is publicly known and verifiable (who the voter voted for is concealed from everyone). The pool of votes for each option is being collected without knowing their source. They cannot be tampered with, manipulated, or changed by any third party and be calculated accurately, with trust, traced back, and verified. There is a trusty Black box in the middle- We believe Proof of Vote (ZK Proof) and Encryption can be that trustworthy Black box. Initiation of a Proposal-

If a person has valid governance tokens in his wallet, the person would be able to initiate a proposal. Once the proposal is initiated, the information about the proposal (Title, Description, Options, Start Date, End Date, Wallet Address of the initiator, etc.) is stored on IPFS.

Voting on a Proposal and Calculation of Votes-

A voter would be generating a Proof of Vote which will be encrypted by him/her. The encryption key pair is deterministically randomly generated by proposal title and description as input for each proposal, to which only the voters have access.

The Proof of Vote needs to be generated from the end of the User and not on the backend. This will ensure that the encrypted Proof of Vote coming from the voter’s side is not being tampered with or copied by the third party (including us).

The user needs to generate the Proof of Vote (ZK Proof) in the command prompt and upload it. (We had aimed to generate the Proof of Vote (ZK Proof) on the browser end of the User: Browser native ZK Proofs. We realized this would take more learning from our end.)

The encrypted Proof of Votes would be streamlined to the backend and saved based on whichever voting option they belong to. The hash of the Proofs would also be stored on a smart contract. The list of voters who have voted is also maintained on a separate smart contract.

Once the Proposal voting time is over, the Proof of Votes will be uploaded on IPFS. Any voter can paste the private key to see the results. Decrypting the Proof of Vote by any voter will lead to the computation of results.

This will ensure that any third party (including the one who is handling this voting system) will not be able to add, delete or change the Votes by the voters. The final counting done by Third-party is verifiable.

This process will help ensure-

A list of voters who have voted is being maintained on a smart contract, The Proof of Votes (without revealing who has voted for that option) is maintained on a smart contract. The total number of Proof of Votes for each option helps get the end result of the voting. Encryption is used to make sure that no third party can imitate the Proof of Votes and hence tamper with their total count. Challenges we ran into We ran into a few challenges, but it was very interesting to try to overcome them. It helped us have a roller coaster ride during our project.

The problem statement we had chosen was a tough one to crack. Coming to a solution to satisfy our problem statement was a happening journey in itself.

We wanted to make the user journey of voters simpler by letting voter have automated Proof of Vote on his/her browser. As we couldn't do this in the time required for the hackathon, we had to settle for the solution of voters uploading the Proof of Vote manually

Accomplishments that we're proud of We are proud to do the project teamwork. As this is the first project for each of our team members, we are proud of our enthusiasm and our dedication to not just brainstorming ideas but also trying to implement them.

We also hold pride in participating in such an elite hackathon and competing with the best brains in this space.

We are proud to choose a real-life problem statement that will have a real-life impact as governance is a pressing issue in Web 3 space.

What we learned We learnt management and execution of tasks. We also learnt how to research some existing solutions and create better solutions across some parameters of the existing solution.

We learnt to keep in mind all the stakeholders while presenting a solution. We also learnt how to break down a problem statement and reach a solution.

We learnt firsthand why deploying a project on Polygon is better than deploying on Ethereum. We also learnt ZK Proof and its pioneer Iden3

What's next for Sententia This hackathon has inspired us to take Sententia forward. We look at this project as a genesis of a platform for DAOs to use.

The next steps include-

Developing the product (Covering the edge cases, expanding the solution horizon to cater to other Voting problems, making UI and UX better) Encouraging DAOs to use Sententia and take feedback from them. This will help us understand better what DAOs really desire and how to iterate towards catering to their needs Developing the product includes a Roadmap

Project Roadmap- Walking the Edge-

Covering all the edge cases is always an uphill battle. And we are up for it! We have brainstormed and strived hard to present a solution that covers all the edge cases. We are also aware of a few edge cases that need to be solved.

In our next version, we aim to cover the edge cases present in our current solution to make a better holistic solution.

Browser-driven Proof of Vote-

Currently, the voter needs to generate a Proof of Vote on the command prompt and submit the file to us. We understand this process is not desirable to the user, and we should strive to minimize the number of steps for a user and make the entire process of casting a vote simpler.

We had tried the possibility of creating a ZK Proof on the browser end of the user so that the Proof of Vote is generated in just one click, and yet we would not be having access to it at the back end.

We realized we would need more time to figure this out. Our first next goal is to make this happen

Time-lock on Tokens- To make sure that a voter doesn’t manipulate a proposal by buying tokens just for voting on a proposal and dumping it later, there can be a minimum time lock period for the tokens to be eligible for consideration as credits in voting.

One Token One Vote- Currently, for demonstration purposes, the voting system is One-Person-One-Vote. It will be updated to One Token One Vote by duplicating the Proof of Votes of the voter according to the number of tokens he/she has in the wallet

Distribution of Private key- We had created a private and public key pair to make sure that the Proof of Vote submitted by the voter is not being replicated by any bad actors (including us- a third party computing the final vote counts off-chain). Any Third party could manipulate the proposals in the current system by addition and subtraction of Proof of Votes if they get access to the private key. The possibility of getting access to the private key is decent as the Third-party can themselves become the voter by buying governance tokens (this will help them get access to the private key, which is accessible to all voters once they vote)

This problem can be countered by randomizing the distribution of the private keys. X number of voters would be randomly shared with the private key. Everyone would be able to see the result of the voting when at least one person uses the private key to access the result

Conducting more than 2 options Voting-

For the hackathon purpose, we had restricted the options to two. But these can be further expanded to execute voting for any N options.

Verification of Proof of Vote-

Currently, we are assuming that the Proof of Vote generated and shared by the voter is accurate. This assumption is on the basis that the voter sharing Proof of Vote is a governance token, he is able to vote only for one option.

In our next steps, we will be verifying the Proof of Vote to make sure there are no edge cases left

Expanding solutions to tackle other Voting problems

Increasing the participation in voting-

The number of token holders voting on proposals has been low across all protocols. This could be possibly due to 2 reasons- Low motivation and missing the timely notification of Proposals.

We are looking forward to brainstorming some incentive models or protocol transferrable reputation layer for enabling more voting participation.

We will also integrate EPNS to enable timely notification of proposals of the protocols of which the voter holds a governance token.

Enabling distribution of votes to all options-

The voters should be able to voice the intensity of one option to the other. This will help have fairer voting as the intensity of all options across each other could be compared. This can be done by enabling the conversion of a voter’s governance tokens into credits (according to the voting system chosen- linear or quadratic), which can be distributed across each option by the voter.

The project's contracts are deployed on Polygon. The data is stored in IPFS. The data being stored includes the hash of the new voting proposal, data of who all have voted, the hash of the Proof of Votes, Results of the Votes. This makes it possible to let the computation of voting be verifiable and tampered proof.