Social Graphs

An Introduction to Sending.Network’s NFT-based Group Relations

Social network is a term popularized by tech giant Facebook, but its existence in our society predates Facebook or even the Internet. A social network can be regarded as a construct made up of a set of participants (such as people or other entities) and the social interactions among the participants. For many years, social networks, either offline or online, have been used by individuals to exchange messages, share information, and sometimes collaborate on joint activities.

If we start with an individual and trace her relationships to others, we may reach a small group of individuals. If we trace their relationships further, we will reach a bigger group and repeat the process. For social network platforms such as Facebook or Twitter, the social graph of their users is stored on their servers. They are key assets of the company utilized to target users for ads and generate enormous profits for the companies in the process.

Here at Sending.Network (SDN), we are building social networks for our users like Facebook or Twitter, but unlike them, we are making it on top of the Blockchain and Web3 technologies. We don’t intend to control users’ data (including the social graph of user relationships) and profit from them; instead, we let users own and control their data, and at the same time, while maintaining privacy, users can still verify the integrity of the data using Zero Knowledge Proof (ZKP) technology. In the following sections, we will describe our design and technical implementation of the SDN social network and social graphs in detail.

1. Background

SDN social graph contains the user’s contact list and Squad relations, forming a map of social connections. This information is stored in a decentralized storage e.g., IPFS, and can be backed up on the blockchain at the user's choice. Like any social network, there is a contact list for every user recording the friends you have added as contacts from direct messages or group chats.

The Squad is a community-oriented space where users from the same community can hang out and have fun. The squad comprises chat rooms dedicated to a specific topic where you can text or voice/video chat with others. You can also share images, make a trade, receive Decentralized App (DApp) notifications, and more. Users can choose to join any interested squad or simply enjoy the seamless one-to-one private chats.

There are three types of squads in SDN:

Public Squad: Everyone could join the Squad through an open invitation link or squad ID.
Private Squad: Only invited members can join the squad.
NFT Squad: Members need an NFT pass to enter this token-gated space.

For the NFT squad, every member has an NFT token pass representing their access right, empowering users with complete squad-relation ownership. The squad creator holds a SquadNFT, while the other members hold MemberNFT.

2. Glossary

NFT: Non-Fungible Token is a digital asset recorded on the blockchain. Holding an NFT represents ownership of a digital asset. NFT is unique and cannot be tampered with or copied.
EVM: The Ethereum Virtual Machine (EVM) is the runtime environment for transaction execution in Ethereum. It is a piece of software that executes smart contracts and computes the state of the Ethereum network after each new block is added to the chain.
IPFS: The InterPlanetary File System (IPFS) is a peer-to-peer file-sharing protocol for storing and sharing data in a distributed file system. IPFS uses content-addressing to uniquely identify each file in a global namespace connecting IPFS hosts.
Zero-knowledge Proof: A zero-knowledge proof is a method by which one party (the prover) can prove to another party (the verifier) that a given statement is true while the prover avoids conveying any additional information apart from the fact that the statement is indeed true.

3. Design Goals

SDN NFT-based social graph achieves at least the following goals:

Accessibility: Equipped with all the basic interfaces that the social graph should implement, including the creation, modification, and backup/restoration of social graph;
Tradability: Realize the crypto association of the squad owners and squad members;
Decentralization: The data is entirely owned by the user, and the NFT is in the user's wallet, so no third party controls the user's squad relationship;
Privacy: Protect privacy and not expose sensitive information of user assets;
Verifiability: Without leaking privacy, users can verify the ownership of assets through zero-knowledge proof.

4. NFT Contract Design

4.1 Overall Structure

In SDN, two types of NFT contracts are defined based on the group owner and group membership: SquadNFT and MemberNFT. Both NFT contracts conform to the ERC721 protocol, and in addition, common operations such as dedicated mint and burn have been expanded.

Mint: The mint operation is the operation for creating NFT. In SDN, data is stored in IPFS, and the information contained in the generated NFT is the IPFS CID obtained after storing the data, so we define the corresponding mint function by the wallet address that owns the NFT, and the CID of the data stored in IPFS corresponding to the NFT.
Burn: The burn operation is the operation for destroying NFT. In the EVM state, canceling the association between the account and the CID is equivalent to destroying the corresponding NFT, so we define the corresponding burn function by the address of the wallet account that owns the NFT, and the CID of the data stored in IPFS corresponding to the NFT.

The NFT contract is deployed on the EVM-compatible blockchain. Developers can interact with social graph through the SDK which encapsulates and handles all the contract calls.

TokenURI maps to the NFT metadata (name, description, image, etc.) stored in IPFS. All original data can be queried and modified on IPFS through TokenURI.

4.2 NFT Contract

The NFT contract includes the SquadNFT contract and the MemberNFT contract, which convert the squad or member information into the agreed TokenID, and then call the unified NFT contract to mint the NFT for the specific user.

SquadNFT contract: SquadNFT is owned by the squad owner, proving the squad's ownership. Its TokenID is defined as:
```
TokenID = Hash(SquadID)
```
MemberNFT Contract: MemberNFT is held by squad members as a token pass for the squad, proving their membership. Its TokenID is defined as:
```
TokenID = Hash(SquadID+InvitationCode)$
```

Users can acquire proof of NFT possession through the input of Account Address and Token ID. Each NFT corresponds to a verifiable Zero Knowledge Proof that proves related squad ownership or membership. This correspondence has two characteristics:

Privacy: No one can determine which squad a specific wallet address belongs to based on the public data on the blockchain, nor can anyone infer which wallet addresses belong to the same squad.
Verifiability: The squad owner or squad members can quickly verify whether a specific wallet address belongs to the group.

5. Zero-knowledge Proof

The zero-knowledge proof uses cryptography principles to enable users to prove to others that a particular statement is true without disclosing any additional information.

NP problems are used in zero-knowledge proofs. NP problems, such as elliptic curve encryption, are challenging to solve in polynomial time but easy to verify. In zero-knowledge proof, there are two subjects, prover and verifier. The verifier needs to generate a series of challenges and send them to the prover. The prover completes the proof according to the information to be proved and sends the results back to the verifier, and the verifier verifies the results. Since the challenge is difficult to solve, returning a correct result safely indicates holding the corresponding (secret) information. Through the combination of multiple proofs, reliable proof of data possession can be obtained.

Let's take the Schnorr protocol as an example. Suppose the prover owns the private key sk, pk = sk * G, G is a generator on the elliptic curve group, and the verifier owns pk. Now the prover wants to prove to the verifier that he owns the private key.

The steps are as follows:

The prover selects a random number k, calculates K = k * G, and sends K to the verifier;
The verifier selects a random number c and sends it to the prover;
The prover calculates r= k + c * sk, and sends r to the verifier;
The verifier verifies that r * G ?= K + c * pk.

In SDN, we implement zero-knowledge proof based on the ZK-SNARK protocol. ZK-SNARK has the following characteristics:

Succinct: The amount of generated Proof data is small, and the verification algorithm is fast and efficient.
Non-interactive: Prover and verifier can complete proof verification without direct interaction. ZK-SNARK significantly reduces the proof size through random sampling and simultaneously breaks the proportional relationship between proof and verification time overhead, making it easier to verify and improving the algorithm's efficiency.

We define a Constraint function (C) and use the Generator algorithm (G) to generate a Proof Key (PK) and a Verify Key (VK) shared by the SDN network.

function C(x,w) {
    return hash(w) == x}
(pk,vk) = G(C)

The user generates a series of proofs based on TokenID and stores the proofs in the NFT contract, thus hiding the relationship between NFT and TokenID, and at the same time can quickly verify whether a given NFT is a group (squad?) owner or member of a certain squad. The proof and verification process in SDN is as follows:

The user generates a proof based on the NFT TokenID and stores the proof in the NFT contract. The verification works as follows:

The prover uses the Prover(P) algorithm to generate proof for identifying the squad owner or member identity and stores it in the NFT contract.
```
proof = P(pk, SquadID, hash(SquadID))
```
The prover sends the generated proof to the verifier.
The verifier uses the Verifier(V) algorithm to verify the results' correctness.
```
result = V(vk,proof,hash(SquadID))
```

6. Squad Operations

6.1 Create squad NFT

Users can choose to create a regular squad or an NFT-based squad. When a user wishes to have the identity of the squad owner recorded on the blockchain, SquadNFT can be created by the following process.

Create a squad in SDN.
Set rules allowing only users with MemberNFT to join.
SDN mints the SquadNFT according to the SquadID through the NFT contract.

6.2 Invite a user to the squad

Users can join an NFT-based squad by an invitation code. Before joining, the user needs to create a MemberNFT for membership authentication.

The squad owner generates an invitation code for a specific user or publishes an invitation link.
The squad owner sends the invitation code to the target user.
The user accepts the invitation and SDN automatically creates the MemberNFT with the squad ID and the invitation code through the NFT contract.
The squad owner verifies the MemberNFT and accepts the entrance.

6.3 Exit squad

When a user leaves the squad, SDN will burn the corresponding MemberNFT.

The user chooses to leave the squad and SDN calls the burn function from the NFT contract.
The account holding MemberNFT loses ownership of MemberNFT.

6.4 Squad ownership transfer

The squad owner can transfer the owner's identity by selling the SquadNFT.

Squad owner transfers a squad and SDN transfers the SquadNFT to the new owner.
The original owner immediately loses ownership of the squad.
The new owner acquires SquadNFT and verifies its validity.

6.5 Squad membership transfer

If the squad owner allows membership transfer, users can transfer the membership by trading their MemberNFT.

The squad member leaves the squad and SDN transfers the MemberNFT to the new member.
The new squad members get the MemberNFT and verify its validity.
The squad owner verifies the MemberNFT and accepts the entrance.
The original squad member immediately loses the squad membership.

When a user logs into multiple devices with the same DID, SDN can back up Social Graph data from the original device and restore them on the new devices. SDN provides two backup methods:

Blockchain-based backup and restoration. Users can back up the data on their desired blockchain with the cost of gas fee.
Backup and on the decentralized Edge Network. Users get the same data security and immutability level as blockchain, but no gas fee is required.

The backup data contains profiles, contacts, created or joined squads, etc. Both backup methods are stored with AES encryption to protect user privacy. Any data stored on the Edge Node will be encrypted and signed to ensure security and verifiability. Please refer to the Edge Node introduction for more information regarding the Edge Network.

8. Summary

Social Graph is one of the essential data for users. To sum up, the SDN Social Graph uses NFTs to ensure users own the squad relations, turning the squad into a crypto asset. The squad privacy, e.g., members in the squad, is protected by the zero-knowledge proof mechanism so users can prove that they hold an asset without exposing sensitive information about it.

PreviousDecentralized Identity NextEdge Node

Last updated 1 year ago