With the recent discussions around how to prioritize and focus community efforts, it’s been realized that an authenticated submission and voting mechanism is required for improvements to the network. Bitcoin has the notion of “Bitcoin Improvement Proposals (or BIPs)” where people can submit their ideas for introducing features or information to Bitcoin.
I was brainstorming how this could work on Zenon and have come up with the below, circulating for input and discussion.
Note: Key to any proposal is how the community discusses and agrees on a way forward, thus the focus on Voting.
Polls are created on a website (either Discourse polls on the forum or a standalone site) and when attempting to vote you are asked to connect to your wallet via the browser (like with Trust wallet and MetaMask) - votes are collated and verified against wallet IDs automatically. Data on who voted for what could either be hidden or public. This would likely require SC capability and a fair amount of development work.
Re-hash of A-Z voting mechanism. Create a new tab or section within Syrius and modify the code for the A-Z voting mechanisms. Instead of submitting proposals, you would submit a Poll question and then anyone with Syrius can vote (not just Pillars). This has some key benefits in that the base code already exists and the votes are verifiable, but on the other hand Syrius is already very heavy and this just adds to it.
Manual message signing with an automated backend that verifies message source and collates votes to another online mechanism (such as the forum polls). Would require research and development
Creating a poll involves issuance of a unique token and distribution to every address (could be limited to those with voting ability = those holding funds). Every token is an eligible vote (with weight defined by the balance at time of distribution, if that is a wanted feature.)
To vote, send the token to an address representing one of the possible outcomes. This would still require a central service to register polls, which also generates and distributes voter tokens, but the actual vote is completely on-chain and transparent. Later on the central service could be replaced by a sc, and then this could be integrated into wallets to function similar to the az tab. Voter tokens could quickly become annoying, but this is an ui issue similar to the az spam problem.
Any others?
Discussions like this go hand in hand with deciding on the best way forward for the network - hoping some of you can add your thoughts also.
a great example of this is the compound voting mechanism that has been shared elsewhere:
Although I don’t know how they verify the votes.
Interesting to note, their key reason for going this route is “Voting by signature lets you place votes across Compound Governance proposals, without having to send your transactions on-chain, saving fees.”
We obviously wouldn’t have an issue voting on-chain on the NoM due to there being no fees
Re 1: my problem with that approach is that a centralized service seems to stand between the voter and corresponding on-chain activity, so it would be hard or impossible to validate exhaustively (if I understood it correctly.) I don’t think that it would require smart contracts, but I’m also not sure how the proof-of-address would work - likely signing?
Re 2: this is a very nice idea, but the real problem is not that syrius would have to be extended, but that the associated smart contract is not generic enough to support this use case. That means we would have to add support to znnd.
Another idea, which seems a bit clumsy to me, is derived from the voting mechanism we initially wanted to use for warpdrive:
Creating a poll involves issuance of a unique token and distribution to every address (could be limited to those with voting ability = those holding funds). Every token is an eligible vote (with weight defined by the balance at time of distribution, if that is a wanted feature.)
To vote, send the token to an address representing one of the possible outcomes.
This would still require a central service to register polls, which also generates and distributes voter tokens, but the actual vote is completely on-chain and transparent. Later on the central service could be replaced by a sc, and then this could be integrated into wallets to function similar to the az tab.
Voter tokens could quickly become annoying, but this is an ui issue similar to the az spam problem.
high level flow for the Zenon Improvement Proposal process, obviously key is the Voting mechanism and how it looks. The more I think of it the more it makes sense the the A-Z mechanism is the answer here
would need a formal way to store proposals (success or fail) - on-chain voting solves this as the proposal will be stored in the network (assuming appropriate information is required to be submitted as part of the submission in Syrius)
Other issues:
how to prevent the spam issue
who can submit and when
voting thresholds (noting it would be open to all users and not just Pillars)
I wish I knew of an equitable way (1 human = 1 vote) to achieve virtual polling but I can’t think of one that doesn’t involve kyc measures => basically Proof of Humanity. Instead, the next best thing is weighted voting. Remember that time we won a blockchain popularity contest? Mitigating Sybil attacks is hard.
Anyways, I’ve considered this problem for Zenon and I’ll address the points in the OP.
I like the idea of using this forum for some* voting purposes. Ideally, we would have a similar voting mechanism natively in Syrius (see #2). My suggestion would be to host polls for community-related topics on this forum and authenticate votes with Zenon signatures. I think I have a proof-of-address PoC here. I wrote a Dart script to derive the source address from a signature generated by Syrius. We can use this or port it to znn.js (I don’t think the signing methods have been written yet) and use it as logic to empower a forum voting system. As Dumeril mentioned, I also don’t think it will require a smart contract to achieve this, but we might need a custom Discourse plugin and a Syrius feature implementation for browser URI calls that interact with the wallet (I think vilkris is working on this). I’d also propose a snapshot of UTXOs at the time the poll; this allows for weighted voting and eliminates some sybil attack surface.
*I’m not sure how I feel about this approach of using a centralized voting system for Zenon code/protocol/consensus changes…
Agreeing with Dumeril here. It’s a lift for znnd and syrius but I believe it’s 100% worth the effort to have seamless voting in our official wallet. I believe this is feasible today, but it would require devs who are comfortable with Dart+Flutter and Go. I may be able to contribute to this change.
Similar to #1 post (including what I wrote ^) but instead of waiting for the URI feature to be implemented, members can manually type their vote in Syrius>Sign and paste the signature+pkey in the Discourse plugin to submit their vote. IMO this is the path to an MVP for authenticated address voting on the forum.
I initially thought this was a bad idea due to token clutter, but that could be fixed with a Syrius UI update… I’ll ponder on it and get back to you on this.
We could potentially use the data field in transactions to embed a vote, similar to how the Zenon Wall works. I’m personally trying to update the Transfer page in Syrius to include an optional message but I still can’t build Syrius. I’ll succeed eventually.
Currently Pillar owners are verified on the forum by verifying their signature. It’s been discussed here. This has also been planned to be implemented as a plugin but it’s a centralized solution for now at least and like you said, I’m also not too keen on the idea of having a centralized voting system even as a temporary solution.
This could work, at least until smart contracts are a available. Thinking out loud here; the flow could be something like this:
User wants to vote for proposal XYZ on the forum or some other website
Presses “Vote now” button
syrius is opened up via a custom URI scheme
A UI is presented with the pre-filled information for the vote transaction
User confirms and presses “Vote now” button in syrius and the vote transaction is submitted on chain (by default it could be a transaction to the AZ donation address with a value of 0.000001 ZNN or whatever)
A week later the voting period ends and some open source tool is used to check all the transactions that have “Vote XYZ Yes/No” in their data field and adds the addresses weight to the proposal.
Was it something like this you had in mind? Obviously showing the results of votes etc. would still propably be presented with a centralized solution (like on the forum or a website) but at least anyone could verify the votes themselves.
Re: the flow
Yes, I think that’s a viable solution. I’d even suggest having voters send the ZNN to their own address, effectively just casting their vote to the ledger for free. They could also re-cast their votes, as long as the last tx is recognized as the final answer.
Part of the URI scheme you mentioned could be encoded in the tx’s data field as a preamble or as part of a json structure and a scraping algo can find those tx’s at a later date.
I’d have to benchmark this kind of payload for plasma consumption but I’m hoping it’s feasible to cram this much data in a tx. The payload could be condensed if we needed it to be smaller.
Yes that could work. One thing I’m wondering is how to determine what momentum height the snapshot should be taken from. Does the poll also need to be broadcasted on chain with the snapshot height included in the data field?
I didn’t include a timestamp because answer transactions would already have that property (confirmationDetail.momentumHeight), but maybe there’s also a tx to announce the poll and it includes start/end momentum heights.
There could also be an end tx that announces the winning answer in order to avoid re-calculations.
The height would be necessary if you want to do weighted votes (which would be mandatory I think to prevent sybils). Unless you want to define that the transaction announcing the poll is also the snapshot time. Some advance notice would be good probably, so that people can collect their weight from exchanges.
Although, we should not blow this up too much as I think this is a temporary solution only, or maybe the first step in a process, which in the end would likely involve some sort of contract.
When you vote you don’t have to include all that data I think. Just a ref id for the poll and a vote would be enough. Also (I know it’s been just a first draft) a generic answer format would be good, i.e. a simple number representing the vote option.
If we were to do on-chain voting with transaction data outside an embedded contract, I think we’d have two or three types of messages.
Initiate Poll
Submit vote
Result
Each would have their respective set of parameters. I agree with your assessment to reduce the vote’s (#2) payload and I’m sure we can align on a proper format that doesn’t strain the network. Less is more.
The initial message (#1) to announce the poll would have explicit start and end momentum heights, preferably starting the poll with enough notice for others to move funds around before the snapshot occurs. That should be left to the initiator’s discretion.
I think weighting should be calculated by an impartial entity (embedded or smart contract). Until we can achieve that, we may have to trust some sort of infrastructure to calculate the votes and present the results. Whatever we decide to use for the snapshot mechanism will calculate the UTXOs at that starting height.
I’ve been thinking about this more lately - I feel we need something in place now with a view to improve the process in the future. For example how do we obtain consensus on something like a UI change in the wallet? Or something more significant like a SC runtime?
Obviously we aren’t yet in a position to implement some of the ideas listed above, so a staged approach is likely necessary. Something like:
Zenon Improvement Process (ZIP) v0.1
Voting via polls on the forum - can obviously be gamed via spoof accounts etc. but on the other hand the awareness of the network is not really at a point where we will attract malicious or spam actors in large volumes. Admins can also identify and remove bot accounts. This mechanism only has to be in place for a short period while we identify a community dev to start working on v0.2
Zenon Improvement Process (ZIP) v0.2
Some form of integration with Syrius for voting or signing - or an adjustment to A-Z within Syrius to allow voting on ZIPs as opposed to funding proposals
Zenon Improvement Process (ZIP) v1.0
A network wide, robust voting mechanism with verification of voters identity to ensure validity of votes. Can either be integrated into Syrius or some external web interface - or maybe even mobile.
I might start drafting up some policy documents around this to get the ball rolling - it obviously won’t be focused on the technology or solutioning but more so what will govern the process and what mechanisms need to be in place to ensure its usefulness.
