DID and Verifiable Credential—Let’s Talk About Something New

A technical overview & recap of world’s first zk-Guessing event for the World Cup Games

1. Basics of DID and VC

DID (Decentralized Identifier) :

A DID is a type of unique identifier (URI) that enables entities to generate and control their identifiers in the digital world. A DID may represent an entity — for example, a person, an organization, or even a machine. The user has complete control over how the DID is generated, where it is stored, and how it is shared.

VC (Verifiable Credential) :

In the DID system, VC is a descriptive statement issued by one entity to endorse some attributes of another entity to prove its authenticity. So VC can be considered as a type of digital certificate.

In the world of digital identity, DID and VC are closely related. VC provides authentication for a decentralized identity.

The application of DID and VC is similar to that of digital certificates. In Web3, digital identities are usually used in job hunting, recruitment, credit lending, social communication, games, DAO, etc., these are also some established application scenarios of DID and VC.

If you are familiar with DID and VC, you may have already seen official introductions similar to this one.

Now let’s talk about something new!

2. Use VC for self-commitment

As mentioned above, a VC is used to prove some attributes of an entity. There are three key roles in the use of a VC: a claimer, an attester, and a verifier. A claimer claims certain attributes about him/herself; an attester checks these claims and makes an attestation if the information is valid. The attester usually signs the VC during the attestation process using a private key. Then, a verifier can determine the validity of a VC without contacting the attester directly — the verifier simply verifies the signature data against the public key of the attester. In order to prevent privacy leakage, these parties usually communicate using a peer-to-peer encrypted channel.

But in certain scenarios, we simply want to make a commitment to some data—proving we know about these data at a certain moment without disclosing the data to the outside world. A convenient way is to let the claimer also act as the attester by signing their own VC data. In this article, we call this signing process “self-commitment”. A verifier can verify this commitment by simply verifying the validity of the claimer’s signature against their public key. If the commitment data is shared with other parties at a certain moment or written to a blockchain, a time stamp will be attached to this commitment. This self-commitment can be combined with other technologies, such as Zero-Knowledge Proof (ZKP), to enable more complex and interesting cases.

3. The betting industry and its dilemma

Since the beginning of the betting industry, people were never able to put a stop to cheating and fraud. Along with the information asymmetry between the host and the players, the industry is filled with unfairness. So it is important for both players and hosts to trust each other, which can lead to a better game experience more player engagement.

The lack of trust in the betting industry is due to the following reasons:

• Information asymmetry: in traditional betting events, participants often have to share their betting directly with the event organizer or a third party platform in advance. The host knows exactly who have betted on what and by how much. The host thus has the advantage to influence the game result in such a way that leads to most of the participants losing.
• Hosts may find it difficult to prove that they wouldn’t or haven’t influenced the outcome of a game, since they are naturally in a better position with more information.

zCloak proposes a new solution to end this dilemma. Enter Zero-Knowledge Proof (ZKP).

ZKP is a cryptographic technology that allows one party (the prover) to prove to another party (the verifier) that they have a piece of information without revealing what the information is. When ZKP is applied in guessing events, players can prove to the host that they have completed the guessing behavior before the match without disclosing to the host which team they guessed. In the same way, the players can prove to the host whether the team they guessed entered the semifinals, finals, etc., without the host knowing how the bets were placed beforehand.

As such, the host does not know the guessing results of the players, and this information is known only by the players themselves. So there is no problem of information inequality when the centralized organization holds all users’ data. It helps to enhance the trust between the players and host, and to sloves the dilemma in the traditional betting industry.

4. World’s First zk-Guessing for the World Cup Games

zCloak Network held the world’s first zero-knowledge based World Cup Guessing Event with its partners from Nov. 30 to Dec.21 in 2022. In this event, players can prove whether their guesses are correct (e.g. their teams enter semi-finals), without telling anyone what their guesses are. And later they can prove it with ZKP. Now, let’s review the whole process and the technical highlights of the event:

Phase I — Guess and Record

Nov. 30 — Dec. 9

During this phase, players can guess the winner of the World Cup Game, sign it as a verifiable credential (VC), and share some information of the VC with the zCloak verifier to make a self-commitment.

Highlight: Players can selectively disclose the information in the VC—players only share their discord usernames and the verification code with the event host for Discord identity verification. Their guessed team was not revealed. By sharing this commitment data with the zCloak verifier, each player has made a self-commitment of their guess with a time stamp.

Phase II — Zero-Knowledge Proof for Semi-Finals

Dec.12 — Dec.16

At this phase, the four teams entering the semi-finals have been known. Players can prove to the event host whether the team they guessed got in the semi-finals without disclosing their guesses at all.

Highlight: The players generated a ZKP using the zCloak zkID wallet—the first crypto wallet in the world that enables general-purpose ZK-VM based computation in user device. The ZKP is then sent to the zCloak ZKP verifier for verification.

Phase III — Who is the champion?

Dec.18 — Dec. 20

At this phase, players announced their guesses and zCloak verifier verified if their guesses were the champion team (in this case Argentina).

Highlight: By showing the VC (i.e. the VC obtained in Phase I) to the platform, the guessing platform can judge whether the results of the players’ guesses are correct and whether the players have completed the guessing behavior within the specified time range.

Phase IV — Claim your prizes

Dec. 21

At this phase, players who won the raffles received a reward pre-set by zCloak. At the same time, all valid participants were able to claim different commemorative badges from zCloak’s partners.

5. Technology highlights

5.1 How does zCloak’s Verifiable Credential guarantee the validity of self-commitment?

zCloak’s VC uses several cryptographic primitives to ensure its authenticity, validity, and tamper resistance.

In the zCloak Network project, we have registered the zk method DID in W3C. Each VC is tied to a specific W3C DID so only the owner of the VC can use it.

In addition, a VC must match its Credential Type, which specifies what fields the VC contains, what data types these fields are, what order they are in, and so on. (Note that the order of the fields is also important in zCloak’s VC, because zCloak’s VC uses the Merkle Tree structure. Invert the leaf node will lead to two completely different Merkle Trees.) In this zk-guessing event, the VC contains some identity information of the user, the team the user supported, as well as some cryptographic proof to ensure the security of the VC.

To ensure that the VC is tamper-proof and that no privacy data of users’ VC will be exposed, zCloak utilizes Merkle Tree Construction and Hashing Method. First, the user’s private data is combined into a Merkle Tree, and then the Roothash of this Merkle Tree is hashed with other data (Credential Type, user DID, etc.) to obtain the final hash (DigestHash). This final hash will not expose any private data of the VC, but it can provide users with sufficient self-commitment assistance. (Any change of the VC’s content will result in a completely different hash result.)

Due to the special construction of Merkle Tree and the uniqueness of the Hash function, if the user tampered with the VC data, the Digest Hash is guaranteed to be different. In case a user’s VC were stolen, the thief would not be able to use the stolen VC as he does not own the DID of the original user.

5.2 How to perform Select Disclosure via zCloak’s Verifiable Credential?

Thanks to the special Merkle Tree Construction of VC, implementing selective disclosure becomes very efficient. For example, if users want to selectively disclose their Discord username and verification code, they can do so by showing Merkle Tree’s Authentication Path without exposing the team they supported. All the user needs to do, is to offer a correct authentication path.

As illustrated in the following diagram, a user can disclose their Discord name and Verification code to get Hash A and Hash B and eventually Hash AB. They can then disclose Hash C without mentioning the name of the team they picked. With Hash AB and Hash C, we can easily re-construct the Roothash. A verifier can verify this Roothash against the commitment a user made before without learning anything about the team that had been picked.

5.3 How do VC and ZKP work together?

In the process of selective disclosure, the user shows part of the VC to the verifier (e.g. Discord username). Using ZKP technology, the user can prove that the team he supports has reached the semi-finals during Phase II without showing any part of VC to the verifier. After the semi-finals schedule was released, zCloak wrote a ZKP program which can be used to prove whether the user’s supported team enters the semi-finals. Users ran the ZKP program locally to generate a ZKP which is later sent to the zCloak verifier for proof verification.

The verifier verifies the ZKP of the user in order to tell if the ZKP generated at user side is correct. The ZKP generation process took place in the zkID wallet (with Polygon Miden ZK-VM built-in). The proof verification process was carried out in zCloak’s verification server. The ZKP verification result can be used to generate a whitelist for a blockchain smart contract to drive its business logic. As such, we can link the attributes of user data to any on-chain logic without disclosing user privacy.

6. Final words

The relationship between the DID (Decentralized Identifier) and the VC (Verifiable Credential) is really close, and their application scenarios are plenty. In this article, we discussed a new idea of “self-commitment” plus “zero-knowledge proof”, and used the sports guessing scenario to demonstrate the concept. This method can completely change the betting industry by taking away the information advantage of the host platform. There are plenty of other innovative use cases when combining DID, VC and ZKP. zCloak Network will continue to explore in this field and deliver true self-sovereignty to the Web3 community!