Bringing the power of validation closer to you
In this blog post, we will walk you through the journey of how we plan on preventing Sybil Attacks in our Incentivized Test Network (INDUS) and propose MOI’s take on achieving true decentralization.
On the 21st of June 2022, while the MOI team was celebrating one month of INDUS testnet and welcoming more than 150 validator nodes across the globe, on the other hand, the blockchain industry was surprised to learn from a Trail Of Bits report funded by the DARPA (Remember the creators of the internet?) on how centralized some of the decentralized networks really are.
As part of our mission of personalizing the internet, we too are working on helping the industry achieve true decentralization. As such, we were shocked to learn of this report and decided to work on an article that can help understand our attempt towards giving an equal opportunity to everyone and participate as a validator and become an important stakeholder in the ecosystem.
PS: If you have not read AK’s blog post on MOI, you can find it here: A Vision for the Personalized Internet
If you have not read Ganesh’s blog post on INDUS, you can find it here: Indus: Incentivized Testnet of MOI
Before we dive into our approach towards true decentralization, let us first understand the need for validators.
Role of validators explained (In a not-so-sassy way)
A blockchain validator is responsible for verifying transactions in a blockchain network. The verified transaction is added to the distributed ledger and shared with other fellow validators to verify at their end, achieve a common agreement on them, and maintain records. In a way, Validators are the backbone of any blockchain. Without Validators it will not be possible for any blockchain to stay true to its promise of providing decentralized trust for all the users. So, it is only fair to say that the health of the network is also dependent on the intent and the ability that the validators demonstrate in preserving the network.
If the world worked in the most ideal manner, then the blog post would probably end here. But, then there are attacks made by some of the actors in the network who pretend to be validators with good intent. Some of these actors can harm the network and Sybil Attacks is one of them. Let us understand what a Sybil Attack is.
Sybil Attacks
A Sybil attack is a type of attack on a computer network service in which the attacker creates a large pool of dubious identities and uses them to disrupt the services or subverts the reputation system to gain a disproportionately large influence.
Fun Fact: The name “Sybil” is borrowed from the book Sybil, a case study of a woman diagnosed with dissociative identity disorder.
Issues caused by Sybil Attacks:
The honest nodes can get outvoted by fake identities and can even block the honest nodes, thus overtaking the network. This is also referred to by some as Eclipse Attack.
Now that we understand the basic concepts of a Sybil Attack, it’s important to understand how to prevent networks from Sybil Attacks
Preventing Sybil Attacks
We propose four ways of preventing Sybil Attacks:
- ID Checks
Under this mechanism, each actor in the network (it could be an end-user, developer, organization, nation-state, regulator or a validator etc.) will validate themselves by submitting their ID to a Trusted Third Party (TTP) for verification. Subject to successful recognition of their Identity by the TTP, they may be allowed to further interact in the network. In case the actor turns out to be bad, the network must rely on the TTP to backtrack the ID of the bad actor and hold them responsible for any violations.
Pros:
a. Helpful in making people accountable for any violations
Cons:
a. TTP could be centralized and may lead to ID leaks.
b. Liveness checks may fail and fake IDs could fail to hold the actors accountable
2. Trust Quotients
Under this mechanism, let us learn how new users can leverage the trust of other actors in the network and establish Trust Quotients in the absence of ID checks. Here, the existing actors of the network are supposed to extend their trust, as collateral to the new actor. With this, the new actor is allowed to further interact in the network. In case the actor turns out to be malicious, the collateralized trust of the existing actor will be liquidated and the new actor will be expunged from the network.
Pros:
a. This approach is convenient for privacy-first people who are not comfortable sharing their ID with other third parties.
Cons:
a. With the pseudonymous implementation of trust quotients or reputation systems, it is very difficult to hold the actual person accountable on legal grounds.
b. Many actors in the network could be managed by the same person or group at different time intervals thereby compromising the network’s ability from Denial of Service and other availability-centric attacks.
3. Limited resource allocations
Under this mechanism, the network can set a maximum limit on the number of resources each actor can consume in a given time interval.If the actor tries to consume more resources beyond the set limit, the network services are denied until the current time interval is elapsed and a new epoch begins with the same threshold.
Pros:
a. Prevent Denial Of Service attacks without ID checks
b. Better applicable for end users with no skin in the game
Cons:
a. Difficult to prevent Sybil agents from creating new actors in a burst mode and enjoy maximum resources to themselves under the new accounts.
4. Economic penalties
Under this mechanism, any malicious actors are penalized by slashing their digital asset holdings. Based on several factors of the network and token dynamics, the deducted amount of digital assets can either be transferred to a community/foundation account or burnt and reduce the total supply of the tokens.
Pros:
a. Slashing what actors hold dear to their hearts can be painful. Hence, they may fear acting maliciously.
Cons:
a. Improper slashing can harm some innocent users if implemented without deliberate decision mechanisms. (Thank you, Immutability!)
We have understood the basic concepts of Sybil attacks and how to prevent or mitigate them and truly decentralize the network. Let us also observe how other networks have prepared themselves.
Comparing the weakness of other Blockchain networks
The following are the Nakamoto coefficients for popular PoS blockchains as of August 25, 2021:
In the above screenshot, we can observe the Nakamoto Co-Efficient from the Trail Of Bits report. The lower the number, the higher the centralization of such networks. It’s imperative that some of the current prominent networks are yet to achieve better decentralization.
While other prominent blockchain networks had a headstart in the early days and faced issues, we at MOI appreciate their contribution and learn lessons from their failures and work on a truly decentralized network — By People, Of People and For People.
MOI’s approach to Sybil Resistance
At MOI, we are on a mission to onboard more than 50,000 validator nodes by the end of year 2022. Upon successfully participating in the network, each one of the 50,000 validator nodes are eligible for MOI stake drops. To ensure equitable participation from people of all walks of life and further prevent Sybil attackers from spawning nodes to claim these benefits, we at MOI have implemented all the four Sybil resistance mechanisms proposed above.
While Economic Penalties, Limited Resource Allocations (a.k.a. Rate Limiting), and Trust Quotients (a.k.a. Reputation Systems) can be implemented in a pseudonymous system, we believe ID checks enable a much more secure, equitable and truly decentralized network for INDUS. To enable these Sybil Resistance mechanisms, we are leveraging the 10M3 (to be read as eye-oh-mee) app. 10M3 is a Zero-Knowledge enabled solution for your MOI Id.
To address any trust deficit among the prospective validators, let us explain how the KYC data is handled in the 10M3 app.
How KYC data is handled in 10M3
Say the User’s MOI ID is identified as `0x13167127695e59614ED384816A6276108cfdc38A`, 10M3 creates a unique private storage/space entitled with that ID in MOIBit via their own MOI IDs.
This private storage/space consists of Public Key (in PEM format). Here’s an example of the content of the PEM file(image 2):
Apart from the PEM file, the validator’s Digital Me is also stored, and classified into four dimensions. Here’s an example content of a profile-complete Digital Me file:
Whenever users update any information in their Digital Me, a JSON object will be created under the respective dimension and mapped to the respective profile attributes like name, email, KYC etc.
The object structure is as follows
scope: The scope determines whether the information is public or private. If “public”, no decryption from the user is required to access the information and can be accessed by any other actor by simply making necessary API calls.
verified: The verified determines whether the information provided is verified by a Trusted Third Party (TPP) or not. As of now, 10M3 uses SumSub(link) as the TPP for verification of non-Indian IDs and Khosla Labs(link) as the TPP for verification of Indian ID called UIDAI.
value: The value field consists of actual data of the Digital Me attribute. However, if the scope is private this value is Encrypted.
zkpMetaInfo: The zkpMetaInfo is the CID that consists of information that is required to perform Zero-Knowledge based verification of information.
In the case of KYC verification, a JSON Object under the social dimension will be created and mapped to an attribute called “KYC”.
- scope will be private since the KYC information should not be accessed by anyone other than the Users themselves. (duh!)
- verified will be true/false depending on the outcome of the KYC verification from TTPs.
- zkpMetaInfo will be updated only if KYC verification is a success. A sample CID hash of a document that consists of meta information for ZK verification and ZK proof can be found here live on the INDUS testnet.
userId is the MOI Id of the user.
verifier is the name of the TTP used for KYC verification.
validationKeyGenInfo consists of information required to generate validationKey for Zero-Knowledge Verification. This API call requires credentials which are secured by 10M3.
URL, request method and payload under the “fetch” field are the API details to fetch KYC data from the TTP.
params are the parameters from KYC data used to generate the validationKey.
id = Applicant specific ID (Eg., 62b9bdc994dc2c00018e4a1f)
info.country = Country the applicant belongs to. (Eg., Indonesia)It is important to note that we do not use any PI from ID to create the ValidationKey. This way, the validationKey generated is secure enough but does not intrude your privacy.
delimiter used to join the params
Eg., validationKey = “62b9bdc994dc2c00018e4a1f | Indonesia”
calculatedProof is the proof generated during KYC verification
Zero-Knowledge Verification
validateZkp(calculatedProof, validationKey)
- value consists of an encrypted digest of Name, DateOfBirth and country
Encryption details
Type: Hybrid encryption (AES + RSA)
Key Size: 256
AES Standard: AES-GCM (Actual Encryption with Random Key)
RSA Standard: RSA-OAEP (Used for Random Key Encryption)
- This hybrid encryption is to make it possible to encrypt and decrypt large messages efficiently.
- The Random Key of size 256 bits used in AES encryption will be encrypted using the RSA algorithm with OAEP padding.
- The actual information like Name, Date Of Birth etc will be encrypted using AES algorithm in GCM mode with encrypted randomKey.
TL;DR: The KYC information (Name, Date Of Birth and Country) will be encrypted with the user’s Public Key, meaning, the digest can only be decrypted with the corresponding Private Key. To summarize, nobody (including 10M3!) will have access to the KYC info proofs stored other than Users themselves.
We are humbled by the support of our early Validators hosting nodes across India, Germany, Netherlands, Norway, Malaysia, Vietnam and USA. Check out this blog by Madhu Kumble, one of our initial Validators. The support and trust we have earned from our Validators are what keeps us going. We encourage you to go through our Validator Website and start your validator journey today.
I’d like to thank Ganesh Prasad Kumble who helped me in defining Sybil Attack concept, proposing the sybil resistance mechanisms and technically reviewing this blog post and providing feedback and thank Geetika Gahlot for her editorial review. Also, huge kudos to TrailsOfBit for the eye-opening report.
Our team is available on Discord to help you anytime!
FAQs
1. Is the KYC frequent ?
- NO, It’s a one-time setup.
2. Is the KYC chargeable?
- NO, we pay for your KYC, for now.
3. Is the KYC data shared with others ?
- Your KYC data is protected by your own keys. Similar to a cold wallet, nobody has access to your data but you.
4. Once KYC is done how many nodes can an individual run?
- Currently 12 nodes, soon we support 21 nodes.
5. Once KYB is done how many nodes can an organization run ?
- We are currently working on integrating support for organizations, once done each KYB verified organization can run upto 108 nodes.
6. Does MOI have access to my KYC details
- No, we use ZKP (Zero Knowledge Proof). We do not save any personal information thus, eliminating any possibility of misuse of your data.
7. Can a user from any location become MOI Validator ?
- Currently, We support KYC in more than 150 countries. Link to the list of countries is available here.
We look forward to involving the community into our Journey. Join our Telegram, Discord, Twitter communities and interact with us right away!
Reference links
- MOI website: https://www.moi.technology/
- MOI Validators site: https://validator.moi.technology/
- MOI Papers: https://info.moi.technology/
