The Construction of the Soul Part 2: Implementations of SBT
Contents
1. Ideas for Implementation
1.1 Comparison with NFTs
1.2 Basic SBT
→ 1.2.1 Mint and Burn
→ 1.2.2 Off-chain storage
→ 1.2.3 Verification of SBT Attributes
→ 1.2.4 Updating of SBT Data
→ 1.2.5 Usage of Basic SBT
→ 1.2.6 The need for privacy in SBT
2. SBT with Private Storage of Data
2.1 Storing the data on-chain but hashing the address
→ 2.1.1 Example Usage
→ 2.1.2 Discussion of SBT with On-Chain Hashing
2.2 Storing the item off-chain on a third-party provider like IPFS
→ 2.2.1 Connecting Off-chain data with On-chain hash link
→ 2.2.2 Risks of off-chain secrets.
3. Conclusion
This is a three-part article series on the fundamentals of SBT, our vision for SBT, its technical implementation and the possibilities of leveraging ZK technology. Part 1 discusses what SBT is and its essential characteristics. Part 2 discusses the basic implementation and how we may add privacy using SBTs. Finally, Part 3 will discuss how we might employ ZK technology to improve the privacy of SBTs. The goal of this article series is to demystify SBT technical ideas and provide an implementation to construct a Web3 future with social identity integration.
Abstract
In the first article of the series, we proposed the vision, use cases, and key features for SBTs.
In summary, the design guidelines around the implementation of SBT are:
- Non-Fungible
- Non-Transferable
- Issuance and Verification of Souls for Composability
- Privacy
- Off-chain data storage for SBT
In part 2 of the series, we will be going through the implementation of SBT according to the design guidelines proposed previously.
1. Ideas for Implementation
In this section, we would be discussing the implementation of SBT and its tradeoffs.
1.1 Comparison with NFTs
Since NFTs and SBTs do sound really similar, what are the key differences between these data structures in terms of implementation?
Non Transferability
Unlike NFTs, which are designed to be tradable, SBTs should intrinsically be tied to the soul and should be non-transferable.
Privacy
The data of NFTs is meant to be viewed publicly. However, SBT projects might want to leave their data private.
Privacy can be implemented in various different methods.
Composable
The data from the SBT should be easily read by other on-chain or off-chain projects.
With the following features as a guideline, we have implemented SBT in Solidity.
We will discuss our implementation in the section below.
1.2 Basic SBT
The basic SBT serves as a template for projects that might want to build on top of SBT. The basic implementation does not include the discussion on privacy, which would be in Section 2 of the article.
1.2.1 Mint and Burn
The design of the contract is such that the mint is gated by the owner. This is to prevent any potential exploits where the user can mint any SBT information, like minting a good credit score even if that is not what the projects have determined. The idea is that the project should determine and verify and mint correct data associated with the SBT.
Similarly for the burning of SBT associated with the address, we believe that users should not be able to easily remove their data, especially if it is a negative attribute. Users should be able to propose the burning of their SBT, but the execution of the burn should be up to the owner.
Burning could be implemented by projects who want to allow users the option to remove their data. For instance, a user who wants all their information removed from a project because he does not align with the goals should have the option to.
Another consideration is how projects might want to curate their SBT community and remove users if they breach their terms and conditions. A user in a community that issues SBT, for example, may not follow the rules and demonstrate inappropriate behaviour. As a result, the community can decide whether or not to remove the user’s SBT from their project. Such communities may want to further implement a suggestion mechanism to allow for suggestions of self-burn to remove data or suggest burning the SBT of another individual.
1.2.2 Off-chain storage
The data could be stored either on-chain or off-chain. In our implementation, we assume that the data for the SBT is stored off-chain with a provider such as IPFS. In our implementation, the URI of the off-chain storage can be coupled with identity in the data structure `Struct Soul`.
Projects are able to adapt the struct proposed based on whether they want to store SBT attributes off-chain or on-chain.
1.2.3 Verification of SBT Attributes
Other counterparty projects should be able to retrieve data from the SBT easily.
This is useful for counterparties who want to verify a user’s SBT attributes. Other projects would be able to check if an address has a soul and verify the attributes that the soul contains.
This is important for the composability of the SBT with different projects where other projects might want to interact and verify the attributes of a user. However, users and projects might not want the data to be public, and there are a few ways the data can be made private.
1.2.4 Updating of SBT Data
We do not want the user or other parties to update the soul other than the permissioned authority, as we want the changes to their data to be verified.
Instead, projects implement the contract such that users can propose the changes to a soul off-chain, and the project can verify if the changes are valid and update the changes on-chain.
1.2.5 Usage of Basic SBT
The basic implementation of SBT is suitable for projects that want to assign data to users that are not private in nature. For example, projects that want to reward whitelisters on the basis of their support towards an NFT collection could make use of this SBT. In the future, the project can airdrop rewards to these addresses with SBTs.
In our previous article, we proposed how SBT can be a potential use case for the recognition of NFT lockers.
For example when the NFT is locked within TimeLock.sol, the locker may still wish to “show” that they indeed own such a locked NFT. However, it would be weird to reference locked NFTs from a developers’ standpoint. Therefore “Soulbound” tokens could be a representation of how long users locked NFT and they could be admitted to the hall of fame. On unlock, a non-transferrable wrapped token needs to be “burnt” to unlock NFT, and the locker would no longer have “hall of fame” status.
Link to the previous article:
Link to the contract for SBT:
1.2.6 The need for privacy in SBT
However, the basic SBT suggested above does not take into account the aspect of privacy.
As mentioned in the previous article, the future of web3 would necessitate some integration with your real identity. Therefore, it is critical to keep one’s identity after integration on-chain private in order to protect oneself from malicious actors that can view blockchain’s public data and dox the identity of an individual.
Any relationship that is recorded on-chain is immediately visible to anyone in the entire world, not just the participants. By correlating SBT data, hostile actors may be able to dox users’ real identities from their Souls.
For instance, if proof of humanity gets more widely used, privacy will become even more crucial because the alternative is that everything we do will be linked on-chain straight to a human face.
2. SBT with Private Storage of Data
In his research paper, Vitalik proposed a few possible implementations of SBT with privacy, and this could be possible with both on-chain and off-chain storage.
In this section, we will discuss the possible implementations of the private storage of SBT data.
2.1 Storing the data on-chain but hashing the address
- Store the item at an address which is the hash of (i) an index, (ii) the recipient address, and (iii) a secret belonging to the recipient.
- You could reveal your secret to an interface, which would then search for all possible items that belong to you, but no one would know which items are yours unless you revealed your secret.
- The secret provided by the user would allow the platform to find all the data associated with the user’s SBT
- This method is also known as Keyed-Hashing for Message Authentication (HMAC). It’s a message authentication code obtained by running a cryptographic hash function over the data and a shared secret key.
- Why does this work? Ethereum addresses are generated from the Keccak-256 hash and are represented as hexadecimal numbers. The last 20 bytes of the Keccak-256 hash are used to generate the address.
- Since one hex digit is 4 bits, we would take the last 40 digits of the keccak 256-hash to be our address. We could deploy our item at the address.
- However, do note that the hashing with a secret should be performed off-chain, as everything on the blockchain (including private state variables) is public.
- Therefore on deployment or mint, only the hash should be provided and not the secret.
2.1.1 Example Usage
For instance, Bob wants to mint an SBT with a credit-based lending dApp.
- The lending platform first performs KYC on Bob.
- The deployment address is generated with the customer id of Bob, his on-chain address, and “Peanut” — a secret that he comes up with.
- Bob’s customer Id, address, and secret are hashed together to obtain an address which is used for the data deployment address.
- An SBT which contains KYC data of Bob is then deployed on-chain at the deployment address.
- Nobody else, except for people who know Bob’s secret, can scan for Bob’s KYC data
- When a project wants to view Bob’s KYC data, all Bob needs to do is to provide his secret “Peanut” and they will be able to obtain all of Bob’s KYC data.
2.1.2 Discussion of SBT with On-Chain Hashing
Advantages:
This method allows for easy interoperability with protocols as all we need is the secret, index, and address to retrieve the item.
Disadvantages:
However, the deployment of the item to the specific address is troublesome and gas intensive.
Furthermore, It does not make sense to store all data related to SBT on-chain, some data might be more suitable for off-chain storage.
More importantly, the trust of a user’s secret is in the hands of projects; long-term use may result in leaks, similar to password leaks today.
2.2 Storing the item off-chain on a third-party provider like IPFS
As mentioned in the previous section, it is too expensive to store most of the data on the chain. Therefore, a better approach would be to store the data off-chain on a third-party platform such as IPFS or other cloud services. This approach of storing data off-chain closely resembles NFTs, whose data is usually stored off-chain as well.
The difference is that in order to ensure privacy, we would first have to hash the URI string with cryptographic hash functions such as SHA256. The hashing of the URI data should be done off-chain as all data on the blockchain is public, even private state variables.
In order to prevent a brute force attack to identify the link which contains the off-chain data, the hash should not just be the hash of the link itself. It could be a function of the user’s secret with the link to the off-chain data storage or hashed recursively, among other methods. This is also known as salting.
An example implementation in Python with SHA256:
This is only an example implementation. There are many other ways to obscure the URI, such as appending the secret randomly, generating random secrets, peppering, and using other algorithms specifically designed for securely storing passwords.
The on-chain chain SBT is then deployed with the hash of the data instead of the data itself.
2.2.1 Connecting Off-chain data with On-chain hash link
How might we be able to connect the off-chain data with the on-chain hash link?
One possible approach is for the contract owner to standardise the structure of data stored at the off-chain location. Therefore, the owner of SBT could reveal the link of the off-chain data, and projects (not necessarily the same as the deployer) could hash the link to check if it is equivalent to the on-chain hash. If the hashes are identical, the project could use a query to retrieve the data stored in an off-chain location.
In order to maintain the secret of the user, the verification of the link containing the user’s data has to be done off-chain with a trusted and secure third party.
2.2.2 Risks of off-chain secrets.
The passing of secrets off-chain could expose users to vulnerability and different attacks.
Projects would have to look into securing the secret transfer and preventing common attacks such as the playback attack, man-in-the-middle attack, replay attack, and many other common attacks.
Once the security of the third party who handles the retrieval of SBT is breached, the secret of an individual becomes public.
Projects should also be mindful of phishing attacks as users could be prompted to enter their passwords on malicious sites that replicate the original.
In addition, the only way to prove that a user has a certain attribute is to expose the secret. However, in order to create pseudonymous composability of SBTs, where different protocols can retrieve data from SBT, the user should be exposing the minimum required amount of data.
If all the project requires is to verify an attribute, the user should not reveal the entire secret. Users should limit their secrets’ exposure to as few projects as feasible.
Therefore, we need to consider another approach where projects are able to verify that the user has a certain attribute without the user giving up their secret.
3. Conclusion
In this article, we went through the implementation of SBT based on the design guidelines that were introduced in part 1 of the series. We implemented the basic SBT as well as the SBT with both private on-chain and off-chain storage. However, off-chain storage may not be truly private as users would have to give up their secrets in order to prove a certain attribute that they have.
The usage of ZK technology may assist us in reducing the user’s sharing of secrets in order to keep their SBT data truly private. That brings us to the third part of the essay series, in which we will write about SBT with zk-SNARK implementation, where users’ secrets can remain concealed, preventing them from being attacked in a variety of ways.
Disclaimer: This post is for general information purposes only. It does not constitute investment advice or a recommendation or solicitation to buy or sell any investment and should not be used in the evaluation of the merits of making any investment decision. It should not be relied upon for accounting, legal or tax advice or investment recommendations. This post reflects the current opinions of the authors and is not made on behalf of Spartan Labs or its affiliates and does not necessarily reflect the opinions of Spartan Labs, its affiliates or individuals associated with Spartan Labs. The opinions reflected herein are subject to change without being updated.
About the Author
This is part 2 of a 3-part Soul Bound Token Tech Research Article Series that is co-authored by Yong Kang Chia and Jun Hao Yap of Spartan Labs.
Spartan Labs is a venture studio under Spartan Group that advises and co-builds projects with the most optimal and effective design at launch and beyond by providing tokenomics design and project implementation. Spartan Labs also produces research reports and articles that are aimed at helping web3 users gain insightful perspectives with regard to the developments and issues within the space.
