Update Scoringmodel.md
This commit is contained in:
Mykola Siusko
GitHub
rodič
7409aad7e5
revize
bc37535387
|
|
@ -73,6 +73,14 @@ _Questions to be observed_
|
|||
4. How is information collected + processed + disseminated
|
||||
5. How completely you can participate with total privacy?
|
||||
|
||||
1) network privacy - (how do you connect to the chain? can you do it via Tor?)
|
||||
2) blockchain privacy - (do the resulting on chain transactions offer the user any on chain obfuscation?)
|
||||
3) censorship resistance - (how resistant is the project to external pressure. will the project censor you?)
|
||||
4) permission - (do I need to create an account to access the thing or is the thing open access?)
|
||||
5) custody of funds - (at any point is the user out of control of their own keys?)
|
||||
|
||||
**Categories**
|
||||
|
||||
**Docs**
|
||||
- read the documentation
|
||||
- Good and comprehensive documentation
|
||||
|
|
@ -82,6 +90,70 @@ _Questions to be observed_
|
|||
- Number of peer reviewed articles at conferences and journals of team members
|
||||
- Where's the code, has it been audited
|
||||
|
||||
**VCs**
|
||||
- Who are the VCs
|
||||
- not funded by big US VCs like a16z
|
||||
|
||||
**Team**
|
||||
- ideological team
|
||||
- Reputation of team
|
||||
- is it purely marketing oriented or it seems created by researcher/developers, are the developers anons?
|
||||
|
||||
**Privacy policy**
|
||||
- Privacy Policy content
|
||||
- Non-vague, and non-intrusive privacy policy
|
||||
- #privacy protection policies
|
||||
|
||||
**Token**
|
||||
- is there a token since the beginning ?
|
||||
- if token since beginning, weird
|
||||
|
||||
**Infrastructure**
|
||||
- How much to run a node.
|
||||
- Where are the nodes
|
||||
- Number of nodes/servers/ -> the larger the footprint the best privacy
|
||||
|
||||
**Storage**
|
||||
- -e2e encrypted LOCAL storage
|
||||
- What user information is stored? (username, IP address, last connectino, wallets associate, etc)
|
||||
- Where is it stored? (centralized server, certain jurisdictions, on chain, in browser/local cache)
|
||||
|
||||
**Data aggregation**
|
||||
- no email or tel nr for signup
|
||||
- control over personal data
|
||||
|
||||
**Traction**
|
||||
- Amount of transactions
|
||||
- number of people using it
|
||||
- is it famous
|
||||
|
||||
**Governance**
|
||||
- DAO structure (if applied)
|
||||
|
||||
**Privacy execution**
|
||||
- How is it being transmited? (encrypted, unencrypted, offuscated, etc)
|
||||
- Confidentiality of transactions
|
||||
- ability to hide transactional data from the public
|
||||
- strong encryption algorithms
|
||||
- If the speed in connection is too fast most probably there no privacy there and rather a direct channel between user - app
|
||||
- p2p / no central server
|
||||
- Reliant on one encryption method or multiple
|
||||
- Combined those encryption methods effectively (holistic solution)
|
||||
- Trustless - No ID required (this is where ZK's are useful)
|
||||
|
||||
**Other**
|
||||
- Time of test and battletested code - (e.g. how BSC had passed the stress time of withdrawals with FTX drama or crypto schemes such as ECDSA with more than 2-3 decades alive)
|
||||
Metadata privacy
|
||||
- Cost
|
||||
- Latency
|
||||
- Entropy (non-trivial to estimate, different measurements for type of service) some examples:
|
||||
- https://arxiv.org/abs/2211.04259
|
||||
- https://blog.nymtech.net/an-empirical-study-of-privacy-scalability-and-latency-of-nym-mixnet-ff05320fb62d…
|
||||
- Censorship-resistant (how hard it's for a powerful party to block/censor a given service)
|
||||
- Onboarding steps
|
||||
- Immutability
|
||||
- Decentralised throughout, including hosting
|
||||
- Permissionless & accessible to all
|
||||
- try to trace a transaction
|
||||
- Precise description of the concrete privacy properties. Privacy is complicated so if they don't say exactly what they protect, then its likely vapor
|
||||
- Usability - for end users or in the developer experience if it is a B2B project.
|
||||
|
|
@ -93,76 +165,9 @@ _Questions to be observed_
|
|||
- Open source/FOSS
|
||||
- Minimal to no metadata capture
|
||||
- Doesn’t sell your data
|
||||
- Non-vague, and non-intrusive privacy policy
|
||||
- protects against global passive adversary
|
||||
- does not implement kyc or aml
|
||||
- strong secure anonymity tech
|
||||
- Decentralized
|
||||
- Credibly neutral
|
||||
- Usage of ZKP
|
||||
|
||||
**VCs**
|
||||
- Who are the VCs
|
||||
- not funded by big US VCs like a16z
|
||||
|
||||
**Team**
|
||||
- ideological team
|
||||
- Reputation of team
|
||||
|
||||
- Privacy Policy content
|
||||
- Time of test and battletested code - (e.g. how BSC had passed the stress time of withdrawals with FTX drama or crypto schemes such as ECDSA with more than 2-3 decades alive)
|
||||
- If the speed in connection is too fast most probably there no privacy there and rather a direct channel between user - app
|
||||
|
||||
1) network privacy - (how do you connect to the chain? can you do it via Tor?)
|
||||
2) blockchain privacy - (do the resulting on chain transactions offer the user any on chain obfuscation?)
|
||||
3) censorship resistance - (how resistant is the project to external pressure. will the project censor you?)
|
||||
4) permission - (do I need to create an account to access the thing or is the thing open access?)
|
||||
5) custody of funds - (at any point is the user out of control of their own keys?)
|
||||
|
||||
privacy audit, number of people using it, is it famous, is it purely marketing oriented or it seems created by researcher/developers, are the developers anons?
|
||||
|
||||
**Token**
|
||||
- is there a token since the beginning ?
|
||||
- if token since beginning, weird
|
||||
|
||||
**Infrastructure**
|
||||
- How much to run a node.
|
||||
- Where are the nodes
|
||||
- Number of nodes/servers/ -> the larger the footprint the best privacy
|
||||
|
||||
1. Reliant on one encryption method or multiple
|
||||
2. Combined those encryption methods effectively (holistic solution)
|
||||
3. Decentralised throughout, including hosting
|
||||
4. Trustless- No ID required (this is where ZK's are useful I think
|
||||
5. Permissionless & accessible to all
|
||||
|
||||
|
||||
**Storage**
|
||||
- -e2e encrypted LOCAL storage
|
||||
- What user information is stored? (username, IP address, last connectino, wallets associate, etc)
|
||||
- Where is it stored? (centralized server, certain jurisdictions, on chain, in browser/local cache)
|
||||
|
||||
-no email or tel nr for signup
|
||||
-p2p / no central server
|
||||
|
||||
2) Immutability
|
||||
3) Amount of transactions
|
||||
|
||||
**Governance**
|
||||
- DAO structure (if applied)
|
||||
|
||||
Encryption /
|
||||
Metadata privacy
|
||||
|
||||
- Cost
|
||||
- Latency
|
||||
- Entropy (non-trivial to estimate, different measurements for type of service) some examples:
|
||||
- https://arxiv.org/abs/2211.04259
|
||||
- https://blog.nymtech.net/an-empirical-study-of-privacy-scalability-and-latency-of-nym-mixnet-ff05320fb62d…
|
||||
- Censorship-resistant (how hard it's for a powerful party to block/censor a given service)
|
||||
- Onboarding steps
|
||||
|
||||
Confidentiality of transactions, control over personal data, ability to hide transactional data from the public, strong encryption algorithms, and user #privacy protection policies…
|
||||
|
||||
3. How is it being transmited? (encrypted, unencrypted, offuscated, etc)
|
||||
|
||||
|
|
|
|||
Načítá se…
Odkázat v novém úkolu