Skip to content
This repository has been archived by the owner on Jul 18, 2020. It is now read-only.

ZK Labs: Scalable & Private Voting through Bilinear Pairings #40

Closed
mattdf opened this issue May 13, 2018 · 4 comments
Closed

ZK Labs: Scalable & Private Voting through Bilinear Pairings #40

mattdf opened this issue May 13, 2018 · 4 comments
Assignees

Comments

@mattdf
Copy link

mattdf commented May 13, 2018

ZK Labs: Scalable & Private Voting through Bilinear Pairings

Abstract

The work shall produce a scheme for off-chain signature generation with efficient on-chain verification. The scheme should scale well with the number of participants (sublinearly, super-sublinearly, or logarithmically), and the steps beyond key registration and final verification should be done off-chain.

The goal is to support on-chain ring signing that can handle a member set with size of at least in the multiple thousands. Primary use cases would be voting and authentication, ideally with the option of verifiable anonymity.

Currently, no ring signature implementation can scale to anything beyond 10-15 participants per ring, per block. We hope the R&D undertaken through this grant will serve as a foundation to overcome these limitations.

The end product should be a set of libraries supporting the on-chain and off-chain processes, and a proof of concept implementation for scalable on-chain voting that leverages the Aragon platform. A diagram of the interplay of the components in the final delivery can be seen here.

In terms of prior art, there is an implementation[1] of Linkable Ring Signatures[2] and there is a RingCT Token[3] implemented, however they are not specific to voting and are not tailored to scalability in the 100s to 1000s of participants due to heavy on-chain computation. The work undertaken will hopefully provide a foundation for scalable ring signatures for many different applications.

Roadmap / Deliverables

Below is a breakdown of work, with ordered dependencies. As parts of the work require specific skillets, not all of the team will be working at the same time - e.g. the implementation phase is dependent on the outcome of the research phase.

Q2-Q3 - Research Phase

Month 1

  • Research possible paths (accumulators, bilinear sigs, threshold sigs).
  • Find most feasible/efficient scheme.

Month 2-3

  • Write report with findings (performance and scalability difference between approaches)
  • Formalize final algorithm/approach into a paper
  • Peer review scheme

Q3-Q4 - Smart Contracts / Infrastructure Phase

Month 3-4

  • Prototype/implement chosen scheme in Solidity (on-chain component)
  • Write userland tools for signature generation, testing

Month 4-5

  • Write supporting libraries, server/relay tools in Python/Go/Haskell (off-chain/infrastrucure components)
  • Write test integration into Aragon app
  • Document APIs and write final specification

Month 5-6

  • Formal audit/review of complete implementation

Funding / Burndown

Cost is $145k in development and support costs, working capital to be supplied in ETH.
60k allocated to research phase, and 85k allocated to implementation phase.

Success reward: Up to $50k in ANT, given out when final public release is ready.

Team Name

ZK Labs Research

Team Members

Matthew Di Ferrante - Ethereum Foundation Security, Founder of ZK Labs.

Dean Eigenmann - Founder of Harbour Project, Dev/Auditor at ZK Labs.

Jake Goh - Ethereum Foundation Researcher.

Rebekah Mercer - PhD Cryptography Student at Aarhus University.

Legal Structure

ZK Labs GmbH (Swiss GmbH, Zug domicile)

Code License

All code written by the team will be GPLv3. If the team needs to leverage or modify existing libraries, the modifications shall be under a copyleft license if possible.

@mariapao
Copy link
Contributor

Hi @mattdf thanks for submitting your proposal!

As this proposal is related to this initial proposal that is already approved, what we can do is convert this proposal into a request for funding (RFF), moving to the second phase of the application. This is the guide for submitting the RFF. The only things that you have to add are:

  1. More information about the team (commitment of each member and social profiles[github][linked] [twitter]). You have a template here

  2. A more detailed roadmap. We would like to see a timeline for the deliverables. You have a template here.

  3. PoC or research paper. I know part of the work is research but can you provide us with a sort of initial document/diagram with the components, architecture and tools that you have in mind for the project?

  4. A comment on the state of prior art and how the new proposal is better.

All the above referred points will help us with the assessment of the merits of the project to be approved. Let me know if you any help with the above.

@mariapao
Copy link
Contributor

Hi @mattdf thanks a lot for adding everything we needed :)

Could you convert this into a PR following these instructions (point #3)? We just need to keep the process consistent ;)

@sirpy
Copy link

sirpy commented Dec 6, 2018

Are you familiar with DEDIS implementation for ring signatures?
https://github.com/dedis/kyber/blob/master/sign/anon/sig.go

@LouisGrx
Copy link
Contributor

This proposal hasn't received any love in the past 6 months. I will close it.

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants