To carry everyone in a community along, project ideas/concepts should be well explained in a simple and easy-to-understand manner. I wrote about this here:
https://bitcointalksearch.org/topic/m.53827701
It should be explained in summary and detailed.
And you will probably need to do the explaining under each standard or rule.
Example: Under rule 1, 2 & 3 (Decentralization, Transparency, Anonymity):
* Decentralization
[you explain how your project is decentralized - in summary & detail]
* Transparency
[you explain how your project is transparent... in summary & detail]
* Anonymity
[you explain how your project is privacy-friendly...in summary & detail]
Raters and the community members then go through your explanations and rate accordingly.
It has to be explained with proofs.
Topic: Ideals of Blockchain: Suggestions on things to consider when ranking a Blockchain project (Read 119 times)
February 25, 2020, 12:56:45 AM
February 25, 2020, 12:29:47 AM
It is important to understand why Blockchain was invented. Read Bitcoin whitepaper or go through how Bitcoin was run in its early days to to understand what he/they want:
With that in mind, one can conclude that the most core features desired by the inventor/inventors are standards/principles/rules listed below
Principles/rules/standards of Blockchain or decentralization:
Rule 1. Decentralization
Rule 2. Transparency,
Rule 3. Anonymity/Privacy,
Rule 4. Permissionless/Trustless usage
Rule 5. Censorship resistant
Rule 6. Immutablity,
Rule 7. Use of deflationary currency
Rule 8. Secure usage or security
Rule 9. Reputation
Rule 10. Open source
* others include: usefulness, viablity etc
These standards should be seriously taken into account when building a Blockchain/Decentralized projects. No cutting of corners!
Communities and developers need to ensure that any additional feature to a decentralized system do not violate those vital principles or rules .
Rating or Ranking of decentralized applications becomes easy when the 10 rules are rigorously followed.
If I want to build an identity application and I'll need to build it based on the above standard otherwise my project will be poorly rated and deemed unsafe, no matter how nice it works.
Rating my Identity Project (example).
Assuming I am building one and the project is called "SafeID", some qualfied & skillful "raters" will go through the project and rate it in this manner:
✳Project Name: SafeID.
1. Decentralization: 80%
2. Transparency: 70%
3. Anonymity/Privacy: 80%
4. Permissionless/Trustless usage: 68%
5. Censorship resistant: 50%
6. Immutablity: 80%
7. Use of deflationary currency: 70%
8. secure usage or security: 75%
9. Reputation: 50%
10. Open source: 85%
* others include: usefulness, viability etc
Total score: 70.8% (80+70+80+68+50+80+70+75+50+85 = 708/10). *And it passd the vital standard* 45—50% should probably the safe zone.
Now, this rating process must not be abuse. The skilled raters have to be transparent with their ratings to allow the communities to challenge and score their rating. I think this will be well handled in this manner:
https://bitcointalksearch.org/topic/m.53800187
If you don't like a feature in the above standards, like immutablity, you can simply add a feature that let community regulators/moderators or users hide an immutable data from a decentralized network. One of my favorite ways to hide data (image for example) is to get a moderators permanently break the image into tiny pieces if it breaks a community rule but the owner of the image should still be able to view it with his keys. If the data is actually too risky for a society, the owner could be arrested and the keys seized. Such data should be labeled (in its broken/hidden/blurred form) though, so that nodes can choose not to run them
With that in mind, one can conclude that the most core features desired by the inventor/inventors are standards/principles/rules listed below
Principles/rules/standards of Blockchain or decentralization:
Rule 1. Decentralization
Rule 2. Transparency,
Rule 3. Anonymity/Privacy,
Rule 4. Permissionless/Trustless usage
Rule 5. Censorship resistant
Rule 6. Immutablity,
Rule 7. Use of deflationary currency
Rule 8. Secure usage or security
Rule 9. Reputation
Rule 10. Open source
* others include: usefulness, viablity etc
These standards should be seriously taken into account when building a Blockchain/Decentralized projects. No cutting of corners!
Communities and developers need to ensure that any additional feature to a decentralized system do not violate those vital principles or rules .
Rating or Ranking of decentralized applications becomes easy when the 10 rules are rigorously followed.
If I want to build an identity application and I'll need to build it based on the above standard otherwise my project will be poorly rated and deemed unsafe, no matter how nice it works.
Rating my Identity Project (example).
Assuming I am building one and the project is called "SafeID", some qualfied & skillful "raters" will go through the project and rate it in this manner:
✳Project Name: SafeID.
1. Decentralization: 80%
2. Transparency: 70%
3. Anonymity/Privacy: 80%
4. Permissionless/Trustless usage: 68%
5. Censorship resistant: 50%
6. Immutablity: 80%
7. Use of deflationary currency: 70%
8. secure usage or security: 75%
9. Reputation: 50%
10. Open source: 85%
* others include: usefulness, viability etc
Total score: 70.8% (80+70+80+68+50+80+70+75+50+85 = 708/10). *And it passd the vital standard* 45—50% should probably the safe zone.
Now, this rating process must not be abuse. The skilled raters have to be transparent with their ratings to allow the communities to challenge and score their rating. I think this will be well handled in this manner:
https://bitcointalksearch.org/topic/m.53800187
If you don't like a feature in the above standards, like immutablity, you can simply add a feature that let community regulators/moderators or users hide an immutable data from a decentralized network. One of my favorite ways to hide data (image for example) is to get a moderators permanently break the image into tiny pieces if it breaks a community rule but the owner of the image should still be able to view it with his keys. If the data is actually too risky for a society, the owner could be arrested and the keys seized. Such data should be labeled (in its broken/hidden/blurred form) though, so that nodes can choose not to run them
Jump to: