Implementing security assurance for proposals

[moul]

Similar to QA, but for security.

Should we mandate that all proposals include evidence of maintaining high security standards? Ideally, this could be akin to a 'security coverage' badge, marking proposals as failing if there's any decline in security.

[cryptulien]

We could imagine some analysis scores. We could have a risk score, a security score, a financial score, etc. It's quite complex to implement, but it would allow all voters, regardless of their level of understanding of the issue, to make an informed decision.

[moul]

In the future, we could use models to make scores and visually show how different proposals would change things with graphs.

For now, we should pick important security measures (KPIs), explain how to calculate them, and ask for these calculations in all proposals, done by the person who writes it or someone in the community. We can then check if these numbers are correct and accurate.

We could also set up a CI that stops any proposal that doesn't have these KPIs checked, unless someone with the right authority gives a good reason to allow it.

I think this issue might be coming up too soon, but I see it as a way to stop spam and make sure we follow our rules. It could help us stick to the main ideas of this project and avoid bad proposals or deception.

[Pencil-Yao]

This is an extremely important discussion, and it would be best to delve into different proposals with entirely different voting methods. We all know that the truth is often held by a minority. I believe that the foundation model of Ethereum and the Polkadot Gov could also provide valuable insights for the management of Cosmos.

[jaekwon]

Similar to QA, but for security.

Should we mandate that all proposals include evidence of maintaining high security standards? Ideally, this could be akin to a 'security coverage' badge, marking proposals as failing if there's any decline in security.

I definitely want this for software. And the auditors must check the code against the onchain mandates if there are any.

The idea I had for making this relatively permissionless and not brittle, is to just let any self-organized group within Decentralists (after ensuring real person identity to prevent sybil attacks) allow themselves to comment on proposals, and if there is significant interest based on some liquid-democratic system of measure, and/or if it is whitelisted, then those reviews are highlighted along with the proposal.

So if a proposal is bad, a self-organized security-group should be able to mark it as "BAD" and then most people should be able to vote accordingly.

And then, once we find what sort of group actually works well, proven over time, built on top of a flexible DAO+smartcontract system with many forks and experiments; then the hub can elect one or more of these groups as officially supported; but these should also have quality assurance / accountability / term-limits. And then we can say that all proposals need to also (maybe first) pass the security bar.

But some limited form of proposals may need to / be allowed to be expedited, with no feedback that may happen in a timely way... perhaps validators found a bug and need to enact some emergency measures. If they are confident that they can do it, they should maybe try, but maybe they do need to get the approval of at least one whitelisted security group. For example.

I propose that AtomOne fund the Decentralists as a collection of projects (also allowing for VM layer competition through competing implementations but also with shared interface specs) with one of the long term goals to enable security groups to self-organize, and allow these to be measured by both delegated democracy (with any reasonable criteria) and delegated stake (of $ATOM1) so that the hub may choose among these self-organized groups one or more that independently judge proposals etc; with term-limits etc as mentioned above. This allows for relevant salient voice to be delivered to voters.

As for limitations, like ALL proposals need to first be approved by some security group? Assuming we have the confidence of some group to bare this responsibility in the future, I still find it dangerous for any group to be able to control the vote of $ATOM1 stakers without safety measures, e.g. allowing for override like YES-WITH-VETO (veto the security group); but this would just be confusing specifying it to completion.

I think that merely showing alongside the proposal the recommendation from select groups from the long term Decentralists system is sufficient for AtomOne, and if it isn't, then other parties can create new splits and experiment with governence there and perhaps port it over to AtomOne with a constitutional majority.