New consensus mechanism

[AminMemariani]

Proposal: Proof-of-Consciousness Consensus Mechanism

Summary:

This proposal introduces a new consensus mechanism called Proof-of-Consciousness (PoC). Under PoC, only users who actively participate in both staking and governance receive rewards. This incentivizes community engagement and decision-making.

Key Features:

• Reward Distribution: Rewards are distributed to users who delegate their tokens to the staking program and vote in OpenGov proposals.
• Voting Mechanisms: Users can vote "yes," "no," "abstain," or delegate their voting power to a representative.
• Security and Decentralization: Active participation helps deter malicious actors and ensures the network remains decentralized.

Potential Benefits:

• Increased Network Security: Discourages malicious actors.
• Stronger Community Governance: Encourages informed decision-making.
• Fairer Reward Distribution: Rewards those who actively contribute.

Potential Drawbacks and Considerations:

• Barriers to Entry: New users may find it challenging to participate in governance.
• Centralization Risks: Large stakeholders could dominate voting power.
• Technical Complexity: Requires careful implementation of secure voting systems and reward distribution.
• Sybil Attack Vulnerability: Users could create multiple accounts to inflate voting power.

Mitigating Drawbacks:

• Educational Resources: Provide clear guidance for new users.
• Simplified Voting Mechanisms: Implement user-friendly voting interfaces.
• Tokenomics Design: Discourage malicious behavior and incentivize long-term participation.
• Robust Security Measures: Protect against Sybil attacks and other threats.

Next Steps:

1. Community Feedback: Gather feedback from the Polkadot community on the Polkadot forums and social media.
2. Technical Analysis: Conduct a detailed technical analysis to assess feasibility and potential challenges.
3. GitHub Contribution: Contribute to the Gray Paper repository with detailed specifications and rationale.
4. Direct Outreach: Engage with core developers and validators to build support.

Please provide feedback and suggestions to help refine this proposal.

[bkchr]

How do you prevent that people just vote randomly, or always no or whatever, just to get the rewards?

[AminMemariani]

How do you prevent that people just vote randomly, or always no or whatever, just to get the rewards?

On the one hand, since the voters themselves are the stakeholders. It is not beneficial for them to vote unconsciously.
On the other hand to prevent this to happen some actions can be done like:

• Education and Outreach: Provide clear guidelines and educational resources to encourage informed and responsible voting.
• User Experience: Improve OpenGov's UX to simplify the voting process and reduce barriers to entry.
• Continuous Monitoring: Regularly monitor the voting behavior of users(AI and bots can help) flag the malicious voters and consider slashing or excluding them from participating in the next epoch.

[xlc]

I don’t really think it is possible to propose a new consensus with AI.

[bkchr]

• Continuous Monitoring: Regularly monitor the voting behavior of users(AI and bots can help) flag the malicious voters and consider slashing or excluding them from participating in the next epoch.

Maybe someone is just against all the proposals? IMO including some kind of AI to determine if some user is malicious, will backfire quite easily. Plus what @xlc said.

[AminMemariani]

• Continuous Monitoring: Regularly monitor the voting behavior of users(AI and bots can help) flag the malicious voters and consider slashing or excluding them from participating in the next epoch.

Maybe someone is just against all the proposals? IMO including some kind of AI to determine if some user is malicious, will backfire quite easily. Plus what @xlc said.

Being just against all proposals is not rational since the person is the stakeholder. But let's assume they would do it. There were mechanisms in Polkadot like the Fisherman. What I mean by saying AI and bots could help is to automate the process of flagging the irrational voters. What we can do with the flagged voters can be arguable.

For instance, a random question designed to verify whether the voter is rational can be asked during the voting process. (Something like what Stackoverflow is doing to verify their moderators are rational in the Review queues)

[bkchr]

For instance, a random question designed to verify whether the voter is rational can be asked during the voting process.

And how you do this on chain? All the things you are proposing here would be somehow be proved to on chain. Doing AI on chain is not really easy.

[burdges]

This has nothing to do with concensus. It's just a rule on nominators.

As a practical matter, we lack the wallet infrastructure for anything like this: We absolutely cannot make people have regular access to their DOTs, because they might store them in a bank vault, another country, etc. We originally had free proxies called controller accounts, but we never really did enough outreach for them. We've since removed controller so now proxies are no longer free, which makes their adoption even harder. We'll add off-chain certificates eventually, but these sound technically more difficult, and thus require more outreach. This cannot happen with current wallet technologies. The operational security cosequences would be disasterous. In particular, if this worked then polkadot users would become higher priority targets for criminates than other blockchain users.

All sane blockchains assume 2/3rd of their validators are not byzantine, which really means in independent, competent, and contentious. This RFC does not improve any of those, and has a dramatic effect, which means this RFC worsens them. In particular, dishonest nominators can easily game the system using scripts, while honest nominators get excluded. This RFC makes polkadot less secure.

---

We definitely have harmful actors involved in governance now, who spend waste tresury money on useless advertising instead of new parachain product development.

If I were going to change anything here, I'd maybe make coretime spends create treasury-vote-DOTs with which the parachain team could vote on treasury proposals, or maybe only vote no. These treasury-vote-DOTs would be non-transferable, but delegatable by the parachain governance, and expire after say 2 years. I think parachain teams are fairly involved, so this gives them a chance to vote against the stupid using all the DOTs they spent. At present, that's not much but it'll become larger if we attract more usage.

[AminMemariani]

For instance, a random question designed to verify whether the voter is rational can be asked during the voting process.

And how you do this on chain? All the things you are proposing here would be somehow be proved to on chain. Doing AI on chain is not really easy.

What about projects like Bittensor which hit-or-miss is a substrate based chain

[AminMemariani]

We definitely have harmful actors involved in governance now, who spend waste tresury money on useless advertising instead of new parachain product development.

Thank you for addressing that. Could you plesae shed some light for me why do you think involving the voting process into consensus reward distribution is compromisimg the security of the network.? I appretiate it