In the universe of Web2.0, we all hold respective accounts among different apps, which represents our unique identity and is attached with all our generated data in the scope. To many accounts created daily lead to an trouble staff that we have to store or remember all these username&passcode carefully and logon each app with respective unique username&password each time. The root cause of this is that Web2 does not provide a common account(identity) layer, and further, all our accounts generated on application layers cannot easily be shared among most web2 apps. Although it exists some solutions like OAuth2.0 to logon other apps with authorization from Big apps(github, twitter, facebook...) and even further share little data from the latter ones, the accounts issue is not solved at root. On the other hand, in the view of each app, they are also afraid of a mass of zombied accounts and always struggle against these by many solutions.
Furthermore, all data (or asset) generated by users is held by the company behind each app, rather than owned by user themselves, which means user cannot get back their data entirely from these companies and companies can arbitrarily access and totally control all user data including privacy. Besides, the data generated by users in each app is always made usage by these companies to make analysis and make much profit that is not shared with user themselves. Besides, our data stored inside apps(databases actually) encouters hacking&leaking issue easily, many of which you must hear from via news.
Many more cases as above are breaking User Data Sovereignty. On top of these, we desire a pratical solution for series of account issues and get back our rights of data Ownership and Control. And SSI is the popular one and DID is the core and implemention of SSI.
DID(Decentralized IDentity) advocates that everyone has the right to gain access to their own and control over their own digital identity, which can securely store elements of their digital identity and protect privacy. But implementing DID is not easy, which involves the discovery & identification & verification of identities, the trusted storage and computation of related data, the declaration and credentials of identities, and so on.
Based on features from blockchain, People carry out several implementations of DID. Especially with the enrichment of NFT、Gamefi、Metaverse, ID on blockchain also becomes more and more crucial and users need to add more on-chain data to enrich their decentralized identity. In fact, the construction of the Web3 identity itself is significant. First, the on-chain data naturally ensures the transparency and immutableness of user identity and behavior, and establishes the cornerstone of identity trust; Second, Dapp data can be read and called across projects, unlike Web2, which is isolated and stored on a centralized server, thus ensuring the versatility of user identity in the on-chain world.
The core goal of Web3.0 is to empower users by allowing them to control their data, protect their privacy, and ultimately ensure their freedom through an open, censorship-resistant network. With the further enrichment of the crypto circle ecology, Web3 identity will also become an indispensable and important module of the encryption circle.
And now let's go closer to a new implementation of DID: ZKPass.
ZKPass is a cryptographic authenticator based on Mina’s Zero Knowledge Proof and acts as a user’s pass to the cryptographic world. Distinguish features are as below:
ZKPasstransforms wallet addresses into friendly, readable and easy-to-remember identifiers similar to the Ethereum ENS, and gives you full control over your encrypted identity without the fear of losing your private key through an unmanaged email social recovery solution.- Through Mina Protocol’s the unique ZK Oracle zero-knowledge proof solution,
ZKPasscan bring in real-world attributes such as the user’s real and valid identity tag according to the user’s wishes, while maintaining privacy, allowing users to bind multiple chain addresses and verify their social accounts to make their encrypted identity more valuable. At the same time, through these real and valid off-chain data and users’ on-chain behaviour data to form the users verifiable reputation, the users’ encrypted identity formed based on ZKPass can ensure the uniqueness of the user and be integrated by all zkApp in the ecosystem through SSO services, which can be used to avoid Bots (e.g NFT or airdrop campaign) and achieve more valuable voting governance to maintain fairness users will also get more potential airdrop opportunities and additional incentives from the Dapp. - Users can use ZKPass without revealing their external wallet address, which will better protect their privacy through the separation of authorisation and asset control identity keys. We also plan to introduce a contract wallet feature to support a certain level of privacy for transactions.
Based on the features above, zkpass is able to be integrated into all zkApp as their ID component. You know, ID is really important for some activities of zkApp, like avoiding bots in token airdrop or NFT application for a DAO.
As a dapp, zkpass's serving abilities depends much on the underlying blockchain system. On the other hand, as a DID dapp related deeply to privacy, zkpass need a strong mechanism to guarantee protection of user sensitive data. With deep consideration, Zkpass choose Mina!!
Mina is the world’s lightest blockchain. Rather than apply brute computing force, Mina uses advanced cryptography and recursive zk-SNARKs to design an entire blockchain that is and always will be about 22kb, ushering in a new era of blockchain accessibility. Distinguishing features as below:
-
the entire Mina blockchain can be kept constantly about 22kb, equivalent to the size of several tweets. As a result, everyone can quickly synchronize and verify the network.
-
Compared with other heavy protocols that rely on middlemen to run nodes, Mina is very light, and anyone can quickly connect, synchronize and verify the blockchain. It is built on a constant-sized proof of encryption that remains accessible at all times, even as it scales to millions of users.
-
By using Mina, anyone in the sync chain can verify transactions as if they were validating a full node. Mina's design means that any participant can participate in proof-of-stake consensus, gain strong censorship resistance, and secure the blockchain.
-
Mina's zkApp, a decentralized application based on SNARK, gives users complete control over the verification and sharing of personal data, not just the data itself, but even to competitors. Using offline logic, data computing and online verification, zkApp is easy to scale, high-performance computing, and cost-effective. (This fits the requirement about privacy pretection of Zkpass) Mina's zkApp can access any website through a private gateway and use verified real-world data online. As a result, developers can use real-world information to analyze and make decisions without compromising privacy.
As you can see, ZKPass is such a big project with several features. Thus we seperate it into multiple modules: Wallet Based on Smart Contract, DID module (MNS (under development yet)), Shielded Transfer module (Shadow (under development yet)) and so on.
The following, we will present Shadow on a very high level, Since Shadow is the part of Zkpass that mainly joined Mina's Builder Program.
As we talked before, the mixer project is an extracted component from our original design of zkPass(Crypto Identity) for MINA's Builder program. Based on this, this mixer project (named Shadow) is still based on the account model, which means everyone could register and hold a unique name in the scope.
To keep this feature and also to keep privacy, we made great effort on the design of how to maintain Deposition to mixer without name exposure, Transfer internally without any exposure, and Withdraw from mixer without name exposure.
So people could got a unique name in the crypto world and never worry about their asset operations to be traced in the scope.
Firstly, You need some amount of mina tokens on your wallet (plugin);
Secondly, Enter the index page, You are directed to provide your own unique name as well as a complex passcode which needs backuping it and is for Transfer&Withdraw section.
Then, the page will generate a key pairs locally for encryption and decryption of your account info & all transactions data.
Next, wallet plugin would be triggered to encrypte the private key and store it locally.
Last, You passcode above will also be stored as Hash(passcode+name) both on contract and locally.
Firstly, at the initial version, You could only log on Shadow on the original client(e.g. explorer) with the same wallet.(will be improved on future version)
Then, please provide your registered name and passcode.
Underlying, Shadow will load local AccountInfo by your name, and trigger wallet plugin to decrypt private key. Meanwhile, all your historical transaction data will by fetched back and decrypted by private key, and then present them on page to you.
Firstly, you need to prepare some mina tokens on your wallet.
Then, Shadow will direct you to transfer your specified amount of mina tokens by triggering wallet plugin and broadcast your transaction after getting your authorization.
During it, Shadow initials your account and updates your initial balance and generate proof attached insides.
Tips: on this section, Your transaction is from your wallet, which could be tracked.
Firstly, you need to input the amount of depositing tokens as well as your target wallet address.
Then you are prompted for your passcode. Please enter.
Underlyingly, Shadow check if Hash(passcode+name) is equal to that on contract and update related data such as balance, merkle tree root and generating proof.
Then send it as a whole to relayers to help generate valid transaction and broadcast it. Of course, you need to pay some fee(spent by balance on Shadow, consisting of two parts mainly: transaction cost and replayer fee) to relayers for this withdraw.
Firstly, you need to input the amount of depositing tokens as well as your target reciever’s unique name.
Then you are prompted for your passcode. Please enter.
Underlyingly, Shadow check if Hash(passcode+name) is equal to that on contract and update related data such as balance, merkle tree root and generating proof.
Besides, a unrecieved transaction item <hash(to), encryptedTx> will also generated as attached (for target reciever when it logs on), and a transfer transaction item <hash(from), encryptedTx> also is generated for history recording.
Then send it as a whole to relayers to help generate valid transaction and broadcast it. Of course, you need to pay some fee(spent by balance on Shadow, consisting of two parts mainly: transaction cost and replayer fee) to relayers for this withdraw.
When the reciever log on, and will be presented all his/her unrecieved transaction items, then he/she will be directed to receive it by his/her authorization on wallet plugin and send this operation to relayer to generate a transaction and broadcast.