๐Ÿ‘ฉโ€๐Ÿ’ป
Galactica Network Dev Documentation
  • ๐Ÿ“™Galactica Network Overview
  • ๐ŸงฌGalactica Concepts
    • โ›“๏ธBlockchain Base
    • ๐ŸงพZero-Knowledge KYC
      • Holder Commitment
      • DApp specific HumanID
      • Verification SBT
      • KYC Guardian
      • Galactica Investigation Module
      • Privacy Precautions
    • ๐ŸŒŸReputation
    • ๐Ÿ›‚Contingent Transactions
  • โš™๏ธGalactica Components
    • ๐ŸฆŠGalactica Snap for Metamask
    • ๐ŸŒณRoot Contracts
  • ๐Ÿ—๏ธBuilding a Galactica DApp
    • Example DApps
      • Compliant ERC20
      • Cypherbook
      • Compliant DEX
      • Sybil resistant airdrop
    • Front End
      • Guided Example
        • Connect to Galactica Snap
        • Prepare ZK proof generation
        • Generate and submit ZK proof
        • Handle Verification SBTs
      • Galactica Snap JSON-RPC API
    • Smart Contracts
    • Custom Zero Knowledge Disclosures
  • ๐Ÿ“Guardian Guide
    • Setup to become a Guardian
    • Create and issue ZK certificate
      • ๐ŸชชzkKYC (GIP-1)
      • Arbitrary ZK data certificate (GIP-2)
      • X/Twitter ZK certificate (GIP-3)
      • REY X/Twitter Score ZK certificate (GIP-4)
      • Decentralised Exchange (DEX) ZK certificate (GIP-5)
      • Centralised Exchange (CEX) ZK certificate (GIP-6)
      • Telegram ZK certificate (GIP-7)
  • โ›๏ธValidator Guide
    • ๐Ÿ”งInstallation
    • ๐Ÿ”—Become a Validator
    • ๐Ÿš€galacticad CLI Usage Cheat Sheet
    • ๐Ÿ”’Security Best Practices
  • ๐ŸงชTestNet: Reticulum
    • Release Notes
  • ๐ŸงชDevNet: Andromeda
    • Release Notes
  • ๐Ÿ“ŽChangelog
Powered by GitBook
On this page
  • Purpose
  • Concept
  • Generation
  • Registration of the salt for the HumanID

Was this helpful?

  1. Galactica Concepts
  2. Zero-Knowledge KYC

DApp specific HumanID

PreviousHolder CommitmentNextVerification SBT

Last updated 8 months ago

Was this helpful?

Purpose

The personal data represented in zkKYC provides the basis for self sovereign identity (SSI) on the Galactica blockchain. It allows to combine the pseudonymous nature of wallet addresses with personal identities. So Galactica can support uses cases, such as human based DAO voting (instead of token based) and .

Concept

The concept is based on the idea to assign each human a unique id, the HumanID. This id is derived from personal data in the zkKYC: The name, date of birth and citizenship. Thus even when creating another zkKYC with another Guardian Node, the HumanID derived from it will be the same. Also when using another blockchain wallet, the id of a user stays the same. It is as hard to change as the personal details it is based upon.

Because a unique id for a human is prone to being tracked online, Galactica uses a DApp specific HumanID instead. The id is a hash of the personal details combined with the DApp address it is used for. So users receive different ids for every DApp they interact with. If this is combined with using different wallet addresses, no one besides the user him/herself can track the on-chain activity across DApps.

See Privacy Precautionsfor more details on how to prevent tracking effectively.

To prevent guessing the HumanID, it also contains a salt. By default the salt is derived from a secret signature of the user's EdDSA key holding the zkKYC. The hash of it is the Holder Commitmentand registered on-chain for the hash of the user's name, birthday and citizenship. This is implemented in the and limits each user to one salt and and therefore one unique HumanID for each DApp.

Generation

Users can generate and provide their DApp specific Human ID in a ZKP about their zkKYC. A smart contract can verify it on-chain. The personal details making up the HumanID stay private. DApps can then use the HumanID for reputation scores, voting etc.

If required, it is also possible to prove the connection between HumanIDs on different DApps. By combining multiple ZKPs into one, the user can prove which human IDs belong to him for different DApps by providing them in public ZKP inputs.

Registration of the salt for the HumanID

The following diagram shows the registration process that limits the user to a single salt. When issuing a new zkKYC, the zkKYC registry checks with the HumanIDSaltRegistry if there is a different salt hash registered. In this case, the user has to switch to the same account that was used to derive the previous holder commitment. In the unfortunate case that a user lost his previous holder account, the salt registry has a reset function. It can be called by whitelisted guardians and requires that all zkKYCs previously registered for that holder commitment were made invalid by expiration, revocation or de-listing the guardian that issued it.

๐Ÿงฌ
๐Ÿงพ
negative reputation
HumanIDSaltRegistry
Diagram illustrating how a DApp specific HumanID is determined.