Approved Grant Initial-Grant-On-Chain-Voting-Protocol

BobbyEK

Federate This
Secured
#2
You’ve gone to great lengths to describe the project but lack details on expenditure.

Can you elaborate on the costs involved? How is $220k getting spent?

Thanks
 

KiwiWithLazerEyes

The Factoid Authority
Secured
#3
Hi BobbyEK,

Thanks for the question. Hopefully the level of detail to describe the project offers some reassurance in the professionalism in our planning.

For this grant, after considerable discussion, we opted to apply with the use of a sponsor, Factoshi (@AlexanderSuperloth). Alex has good standing as a trusted and long serving community member. This means each entity will be sharing an extensive breakdown of costs with Alex under NDA.

What we have provided is a breakdown of costs by Milestone and by entity. We have also provided detailed tasks for each Milestone. This should allow Alex to independently ensure that our work is being completed and provide the community with progress reporting.

Most costs from each entity are in development hours. There’s also a considerable cost ($6,000 USD) in materials for a Ledger Distribution Fee.

Some additional notes:
  • The “Final Report” Milestone is a culmination of a substantial effort put forth to see if zkp is possible in Factom and what would be required to implement it
  • The “MFW Beta Released on Test Net” Milestone is a full force effort to push the client-side wallet across the finish line, and same with the Ledger
  • There is considerable development needed in extending the wallet to support voting
  • There is also an in-depth data structure design that needs to be accomplished that not only will support the simple voting schemes but also must be robust enough to be expanded to support advanced functionality such as automation of authority node promotion and demotion and integration of coinbase transactions. This design cost includes detailed discussions by the team and we will need to undertake an in-depth design review with Factom, Inc. These fall under Milestones “Voting Specification Released for Review” & “Voting Specification Finalized”
  • There is backend development that also needs to be done to validate the results in a timely manner. There is an equivalent client-side tool that needs to be developed as well, so that votes can be independently verified. Both of those development items fall under Milestone “Voting System Released to Test Net”
  • There is the design specification, the Ledger app, EC support in the Ledger, there are the software products such as the voting api which will be open source along with the client-side validation tool.
  • There is also the MFW site that will go live
  • There is an acceptance test that will be designed and performed to give a rudimentary level of confidence of stable tools and with a certain level of security. An in-depth security review could be performed on a follow-on effort and we have discussed options internally
 
Last edited:

Niels

Guide
BI Foundation
Secured
#4
I really like the total grant. What I like less is that it is an all or nothing grant, since it is a single grant with a lot of separate parts, that could be separate grants in itself.

Some of the parts could be argued to be essential, but having a nice integrated ledger, MFW, Explorer experience with voting is a bonus. The one that really stands out in this whole grant proposal is the research part for ZKsnarks and homomorphic encryption. A lot of recent research has already been done in this area. It is definitely something you want in the future. Could you elaborate on why it is essential currently?

The anonymous vote would be a nice research grant to be voted on using the voting-solution you created btw ;)
 

bunfield

The Factoid Authority
Secured
#5
Hi Niels,

On the surface, some of these activities may seem separable. However, as we were scoping this project, we wanted to make a solid foundation for a usable voting system that we could build upon with smaller separate grants to add more advanced features at a later date. While items such as wallet integration and explorer integration seem separable on the surface, we deemed them essential to have them all work in concert to have something usable by everyone from the start. We wanted to avoid simply building a command line tool, which we feel limits the overall usability of the system, and go with a proper web-based UI from the start. As such, we derived some base requirements for the voting tool. To vote, we need a way to manage identities, to manage identities, you need a wallet. To use a wallet, it is best to have user friendly interface where we keep the security critical components on the client side, like key management, signing the txs, etc. We also want to build the voting tool so that it can be expandable in the future, so we need to explore future requirements as to not lock ourselves into a limited design. The design we start with should be one we can build upon rather than suffer from significant refactoring or rewrite later on which will ultimately lead towards higher development costs and longer timelines. The explorer is an integral part of our design as well. To use identities, you need to parse the identity chains. To parse identity chains to the spec, you need to parse the main register chain. That's already 40-60 entry calls with today's APIs. We can probably make shortcuts, but it's an unbounded number. Thus, the issue we saw of keeping everything client side is that the amount of data to parse to calculate a vote is unbounded since the identity chains can grow unbounded, be spammed, etc. For example, if 1 identify chain is DDoSed, the voting app may need to churn through hundreds of entries taking an ever increasing amount of time. Thus, we need a way to manage that. By splitting the responsibilities, we can develop the voting daemon as part of the explorer and an API to access that. The daemon can be launched by anyone wishing to independently verify the votes as well. It would run constantly as part of the explorer, giving users access to a stable and responsive interface. Ultimately, we could have built the identity wallet management tools from scratch, but we thought it was best to give the community a user friendly common tool by helping finish a project that was already started.


Thus, we feel the value added to the protocol will be much larger if those are all done in one chunk, as a collaborative effort, which ensures the end result is a coherent expandable system, rather than the alternative of voting on them separately and potentially postpone one or multiple of the sub parts thus resulting in a piecemealed system of partially functional components.


On-chain voting with digital identities would allow for immutable, auditable, etc voting. However, this would not remove any potential liability for people/entities that approve grants, as the votes and identities are non-anonymous. If we have an anonymous system, as ZKP would provide, it would be mathematically impossible to hold anyone liable for any governance related matters. Having a properly implemented anonymous, secure, and distributed voting system could help facilitate a distributed governance system, in particular, if this is tied to coinbase txs. Therefore, we believe it is essential that we start exploring this option within this phase of the grant.


In closing, we feel ZKP is also “essential” in that we are in strong need of some exciting news around the protocol in order to attract attention and increase liquidity. We strongly believe that getting ZKP on Factom will be truly newsworthy and a great way to further the protocol.
 

Niels

Guide
BI Foundation
Secured
#6
Thx for the reply. I get the why and interconnections, and let it be clear I support this grant. I do still believe is should have been seperate grants, so you can better decide on them and track their individual progress. I am a little woried this sets a little of a precedent, just like the Factom Inc grant is huge in the amount of items.

Well the ZKP is kinda agnostic and is good to have, but in the scope of current project and state of Factom would not label it as essential. Given the "objection" on it being one single grant, there is no way to vote that out currently.

So will support this grant with the above remarks 🙂
 
Secured
#13
Thx for the reply. I get the why and interconnections, and let it be clear I support this grant. I do still believe is should have been seperate grants, so you can better decide on them and track their individual progress. I am a little woried this sets a little of a precedent, just like the Factom Inc grant is huge in the amount of items.

Well the ZKP is kinda agnostic and is good to have, but in the scope of current project and state of Factom would not label it as essential. Given the "objection" on it being one single grant, there is no way to vote that out currently.

So will support this grant with the above remarks 🙂
The grants could vest based on milestones achieved which may relieve some concern, no? Probably too late for this idea though. Im not sure if we already decided how to distribute the grants. Been AFK for a bit
 

Niels

Guide
BI Foundation
Secured
#14
Yes it could, but only to a limited extent. Although the amount of money involved is a little more roughly 200k isn't that much to do software development. So my point wasn't about getting grip on the monetary aspect of the grant. It was about whether some aspects in the grant itself were really essential at this stage ;)

And yes it is to late now since the vote has already started, but no harm in answering this question I think