# Commentary on DeSoc I (Draft v0.2)

By Kevin Yu
---

## Introduction

The latest publication [^fn10] from Microsoft’s [Glen Weyl](https://twitter.com/glenweyl), Flashbots’ [Puja Ohlhaver](https://twitter.com/pujaohlhaver), and [Vitalik Buterin](https://twitter.com/VitalikButerin), on **decentralized society** (or **DeSoc**), has made waves in the crypto community. Some have even associated it with the potential launch of the next “DeFi/NFT summer”. The piece overall is drafted with several meta-narratives, all of which are centered around the idea of "**publicly visible, non-transferable, but potentially revocable" tokens**, or the so-called [Soul-bound tokens](https://twitter.com/VitalikButerin) (SBT).

The authors have clearly detailed the exciting future that non-transferable tokens (and their off-chain counterpart, verifiable credentials), as **signals of reputation** and **tools** for broader **decentralized network coordination**, can bring to the currently **hyper-financialized** crypto space. Since this topic is also something I have been exploring with the [Clique](https://twitter.com/clique2046) team for the past few months, I'm writing a commentary here on the pros, cons, potential design specs, and technical implementation challenges of the DeSoc ecosystem.

The commentary is broken into two pieces. This is the first part that mainly explores the **trade-offs** between hosting the credentialing system **on-chain** and **off-chain**, as well as the **legacy compatibility** aspect of designing an identity system. The second part will be more focused on plurality, quadratic voting/funding, and generic mechanism designs for reputation systems.

## Summary of The DeSoc Piece

A specter is haunting the crypto space -- the specter of over-financialization. **DeSoc** aims to solve this with "**Souls**" and "**SBTs**", a duality of **accounts** (wallets) and publicly visible but non-transferable **credentials** (tokens) for signaling reputation, representing memberships, and granting access rights. Keep in mind the definition of "accounts" and "credentials" can be highly **abstract**, without the constraints of necessarily being located on a **public blockchain**. Some of the important design specs of such a system include the **issuance** of SBTs, staking SBTs for **reputation**, **programmable privacy** for different SBTs, and community-based **key recovery** schemes.

"Souls" and "SBTs" are analogous to "**decentralized identifiers**" and "**verifiable credentials**" in the **decentralized identity** space. The authors themselves have detailed this in section 8.4 as well, and pointed to DID's "**uni-lateral privacy**" as a primary drawback and a limiting factor to the scope of applications. The **lack of community recovery mechanisms**, which can be crucial to general user security, as well as the **lack of programmability and composability** among large groups of users, are some of the other problems with the current DID design space that **SBTs** are attempting to solve.

While I firmly agree there are numerous applications that thrive on **network effects** and are dependent on some level of pre-established **publicity** (reputation staking, etc.), there are multiple drawbacks for directly using a **layer-1 blockchain** in their current forms (like Ethereum) as the main **execution layer** to *store, update*, and *retrieve* **credential states** (in this case SBT states). This has already generated [some debate](https://twitter.com/AnastasiaU/status/1532584511107698689) between the original authors and early adopters of verifiable credentials. Thus, I will try to offer a neutral analysis here on SBTs with **scalability**, **interoperability**, **privacy**, and **composability** in mind. Two potential implementations (both are hybrid approaches) are also proposed for further discussion.

## Should We Make Credentials On-chain?
### Benefits of Having Fully On-chain SBTs
Why put SBT on-chain, if it's not transferable? **Non-transferability** would suggest that a **permissionless blockchain consensus mechanism** is not strictly necessary, as the only transactions involved would be the **issuance**, **state updates**, and **verification** of credentials. The first two steps need to be triggered by a **trusted third party (such as a set of committee nodes)**, which is a source of truth for the **state changes** [^fn14]. All the write operations are delegated to the TTP, and the state updates can then be broadcasted through any **peer-to-peer** protocol and verified by other nodes (e.g. for **decentralized storage**, which maintains **availability** of states for all clients). The verification of credentials can basically happen anywhere (on-chain with a smart contract or off-chain with some SDK).

However, there are indeed numerous benefits of having native on-chain non-transferable credentials. For one, the **integration with existing on-chain protocols** would be much easier. For example, issuing on-chain SBTs based on DeFi farming track records can happen natively on-chain without any oracle. A similar case applies to **reputation-based on-chain governance** with DAOs.

Aside from **composability**, **full decentralization** can also be enforced if all the issuance logic is hardcoded into **smart contracts** that automatically grant authority to the accounts that already have good reputation (e.g. with a lot of high-quality SBTs). This would remove the need of running a **separate network** of **permissioned issuer nodes**, as **issuer entities** can directly setup smart contracts that are triggered by certain criteria. Simply, one can make the ```claim``` function for SBTs public and open for anyone to call, as long as they can fulfill certain standards (e.g. owning certain other SBTs).

Another advantage of SBTs against VCs is its ability to serve as **flags** for accounts. If one wants to verify on-chain whether a statement is true and attempts to use a VC, it would need to have the holder be **available** and **willing to cooperate**, which is a huge limitation for **unilateral privacy**. In addition, one can only query the statement status **at time $t$ when it’s presented**. **IDX**[^fn5] would be a good option for a central repository that queries credentials and their states if on-chain verification is not strictly necessary.

Now, let's talk about some of the potential nuances of putting everything on-chain.

### Scalability
The **design space** of credentials due to **overhead** for frequent state updates, which incur **high gas fees**, will be limited. For example, one wants to have a credential that details the number of followers it has across different social media platforms (can just be a set of threshold values). In this case, whenever the number is changing, an on-chain transaction needs to be initiated to update the state. This becomes even more unscalable if one is trying to store a **social graph**. Under most circumstances, users won't even have the **financial incentive** to pay for gas fees.

On the other hand, if the token is stored as a **pointer** to some off-chain credential (like an NFT), we would need to introduce a permissioned node committee again to manage these off-chain credentials. This is different from normal NFTs (Jpegs aren't supposed to change) as **smart contracts** would need to write to **off-chain** storage in a verifiable way (similar to a oracle problem, which is proven to be hard for being completely permissionless).

### Interoperability
Putting the credentials fully on-chain makes the **reputation system** **chain-specific**. This introduces an additional problem of **interoperability**. Unlike normal transferable and financial assets that can be **bridged** across different chains, a credential-like **SBT** is not transferable, and it must also be **Sybil resistant**, i.e. the same credential needs to be de-duplicated across multiple chains (especially if involved with off-chain data). Which chain is going to be the **single source of truth** then? How would cross-chain interoperability work? Who is to maintain the state changes across **different execution layers**?

The **issuer itself** likely needs to maintain separate instances of SBTs in sync across different chains. This would give it, for instance, the right to **revoke** all credentials at once. Obviously this is quite problematic if the issuer itself lies on one chain, and it has the access to **manipulate credential states** in a **separate chain**. The **oracle problem** would exist equally for all interoperable actions, similar to if one has to verify off-chain VC statements on-chain.

In the future, the problem can be much more alleviated when chains become more **application-specific** -- under this scenario the pressure on interoperability will be much lower as for example GameFi credentials usually wouldn't leave a game-specific chain (similar to internal reputation systems for web2 gaming platforms, e.g. Steam badges). Still, users may need to prove ownership of multiple accounts on different chains in order to cross-reference credentials. **De-duplication** and **linkage** of different identities, again, become a problem.

### Privacy

The authors have already made a discussion on the **unilateral privacy** feature of **verifiable credentials**. The debate right now lies with the fact that putting everything on-chain **automatically** enforces **publicity** (unless with some privacy-preserving chains where states are managed with trusted hardware/TEEs or specific zk sigma protocols). However, using an off-chain network to maintain the credentials can be much more versatile: users can choose to either store the credentials **locally** (private) or store them in a **backup network** with or without encryption (private/public). This would also ensure the credentials having the same interface.

The problem with on-chain **zk-attestations** is that the states are difficult to update. Current applications seem to be only focused on proving one-time claims. Mapping a zk-attestation (e.g. belonging to some identity group) to on-chain SBTs seems ideal, given that users don't just leave that identity group after completing the proof.

Ultimately, different application scenarios would require different privacy and trust assumptions. An important point to make for a **smart contract** based setup, **programmable privacy** is potentially easier to achieve. Research such as FLAX (Wei) [^fn12] has already been exploring in this direction. Running computation in a decentralized way (e.g. certain **MPC algorithms**) with verifiable credentials seems to be quite hard, compared to if the same computation is run with states managed by **privacy-preserving chains**.

### Sybil Resistance
**Sybil-resistance** seems easier with small locally-run networks. The "**proof-of-personhood**" protocol [^fn15] use cryptographic tools like *linkable ring signatures* [^fn16] to achieve this goal, albeit in a non-scalable way. The authors have mentioned running **correlation check** between a user's public on-chain SBTs and those of other known reputable users. This easily creates a **bootstrap** problem for the network when very few people are reputable enough. It may also further **centralize** the network around certain individuals as time evolves.

### Implementing Non-transferable Tokens
Let's say it is optimal to put the credentials on-chain in the form of non-transferable tokens. The question then becomes: how to actually implement it? The community has explored various solutions before, with most suggesting some kind of modification to the `transfer` and `transferFrom` methods. An abstract interface under [**EIP-1238**](https://github.com/ethereum/EIPs/issues/1238) looks like this:

contract ERC1238 is ERC165 {

    bool internal _transfersEnabled;

    /*
     *     bytes4(keccak256('transfersEnabled()')) == 0xbef97c87
     */
    bytes4 private constant _INTERFACE_ID_ERC1238 = 0xbef97c87;

    constructor () public {
        _registerInterface(_INTERFACE_ID_ERC1238);
    }

    function transfersEnabled() external view returns (bool) {
        return _transfersEnabled;
    }
}   

A number of problems under this design have been detailed by the community:
- Once the account (wallet) is compromised, **who will manage the transfer of credentials**? And more importantly, how? Under this implementation, it seems hard. DeSoc proposes a **community-based key recovery mechanism**, improving on the usual social recovery scheme by expanding the set of **trusted parties** to all the "communities" that the account lies within. In implementation though, the set of guardians will be constantly changing, and the wallets that each guardian has access to will be changing as well. This significantly increases the **complexity of the recovery graph**. There is no easy solution against malicious actors in the guardian set (if not trusted) colluding.
- Mechanisms such as recency and correlation discounts across guardians can be applied as basic checks. Trusted collusion resistance mechanisms such as MACI[^fn17] are more robust, but rotating with trusted setups might be hard.
- Maybe a standard like [**EIP 121**](https://github.com/ethereum/EIPs/issues/121), where a unified **proxy** contract design for asset management and transfer is proposed. However, this also introduces new problems regarding the granularity of the transfer (e.g. single asset or all assets associated with a key?)

Ultimately, there's probably no easy way around having the **issuer** to re-issue the badge or initiate a permissioned transfer. This is a subject that has undergone significant community debate. If you're interested in this topic, please also check out the following GitHub issues: [ERC-1888: Transferable Certificate](https://github.com/ethereum/EIPs/issues/1888), [Investigate the appropriateness of Open Badges for what we need](https://github.com/topiahq/badges/issues/1), [CDIP 2 - Non-transferable Badges for Maker Ecosystem Activity](https://github.com/makerdao/community/issues/433).

## Alternative Solutions
To address the problem mentioned above, I will detail two types of solutions. Since under any circumstance, **private credentials** should be stored **locally** by users (and potentially being backed up by a network with encrypted data), the difference between the two mainly lies in the issuance, update, and verification of **public credentials**.

### First Solution: Off-chain DID with On-chain Anchoring (VC-based)

The first solution is similar to a layer-2 design as it **anchors** in batches the **PKI state changes** (public key infrastructure, basically facilitating the CRUD of digital certificates) of credentials stored **off-chain** into an underlying decentralized network (can be any public ledger), which basically serves as a **settlement layer** here. The **public credentials** themselves can be stored **off-chain** in any **decentralized storage system** (depending on different trust assumptions that can be IPFS, Arweave, or even just a set of storage nodes run by a credential issuance committee).

The decentralized identifier network can be implemented through something like **Sidetree protocol** [^fn6], which can run atop any existing decentralized anchoring system (Bitcoin, Ethereum, etc.) for permissionless credential management, making the system chain-agnostic. The **committee nodes** under Sidetree are responsible for the writing, observation, and processing of all DID PKI state operations with deterministic protocol rules.

A core set of **state change operations**, such as CRUD (Create, Update, Recover, and Deactivate), are defined in advance. The **committee nodes** anchor the **CAS** (content-addressable storage) references to an aggregated bundle of operations in the underlying anchoring system, which serves as a **linear chronological sequencing oracle**. The DID PKI operations are thus stored with an immutable history that can be replayed and validated, thus achieving a consistent view of the DIDs.

Under this setup, Soul/SBT can be re-formulated to a set of **verifiable credentials** that have the following specs according to W3C VC standards [^fn7][^fn8]. Customized privacy can be arranged, while cross-chain interoperability can be solved with a chain-agnostic oracle that interacts with the DID system.
- $pk^{U}$, or user identifier: pseudonymous identifier of credential subject
- $ctx$, or context: string denoting context of issuance
- $\{claim_{i}\}$, or claims: each $claim_{i} = \{a_i, v_i, P_i\}$, where $a_i$ denotes the attribute, $v_i$ denotes the value (serves as a key-value pair with $a_i$), and $P$ denotes the data provider (i.e. where the claim orginates from, either through a legacy issuer like YouTube or some on-chain DeFi application, etc.)
- $\sigma$, or signature: signature by issuer over $pk^{U}$, $ctx$, and $\{claim_i\}$. The signature is denoted as $\sigma = Sig_{sk^{C}}(\{pk^{U}, ctx, \{claim_{i}\}^k\})$, where $C$ is the set of committee nodes and $k$ is the number of claims.

Notably, the same design can be replicated with an actual rollup and use a major chain like Ethereum directly as a settlement layer for SBTs, instead of simply anchoring the transactions. In this case, smart contracts can be better utilized to manage credential state changes. Scalability wouldn't be a huge issue either as gas fees would be cheap.

### Second Solution: Modified Sharding (SBT-based)
The second solution puts credentials on-chain (e.g. in the form of SBTs), but instead it leverages **sharding** to increase scalability and reduce overhead. Basically, different sets of credentials are managed under shards maintained by a network of **verified/permissioned issuers**, with each subset taking care of the **state changes** of credentials within itself. Each shard comes into consensus on its own state and produces a Merkle root signed by a quorum of shard validators. Then, the beacon chain combines the shard roots into a beacon root as settlement.

The benefit of this design relies on the **limited requirement** of **cross-shard communications**, as most credentials are simply **non-transferable**. Thus, there's no need for accounts to try and find Merkle paths to a transaction in the **source shard** atomically. Of course, this would require a very careful design for the specific domains each **shard** should take care of to minimize such communication.

This design aligns with the direction **Ethereum** is currently moving toward, so it might also be interesting to explore. The privacy issue can be somewhat addressed if a subset of shards are implemented with additional trust assumptions (e.g. with **trusted hardware**, or a specific set of zk sigma protocols/commitment scheme like **Aztec** [^fn13]). This would require different shards to have different properties, though (similar to phase 1/2 sharding for Eth, when some shards can handle code execution while others serve as availability engines). The cross-chain interoperability issue might be harder to tackle here, as bridging would still be a necessity.

## Legacy Support for Credentials
The DeSoc paper hasn't addressed enough on how to **bootstrap** the credentials. To tackle the **over-financialization** in web3 right now, you can't just rely on these on-chain financial applications to be the sole source of an identity's credibility. The only primary data sources on-chain right now seem to be that of transactions (tokens, NFTs), staking, yield farming, etc. A really important thing one can do is to somehow leverage **off-chain user data** on **legacy platforms** to bootstrap reputation. For example, for an **under-collateralized** lending protocol to be executed, aside from relying on past on-chain DeFi behaviors, one can also generate proof statements about their **bank savings** and **credit history** in real life. Another example might be **importing current social graphs (or their subgraphs)** on **Twitter** to on-chain social protocols. Yet another example might be **Sybil resistance** enacted through proving an identity through government websites (SSN).

To achieve this, one would need some kind of **decentralized oracle** scheme that allows users to prove to third-parties (such as on-chain applications) the **provenance** of **public or private** data on pre-existing social platforms, without the need for **server-side** modification. For example, a user can easily prove to an on-chain service that she (the owner of the address that's interacting with the service) follows a creator on YouTube, without YouTube itself proving data provenance through server-side SDKs, authenticated APIs, etc.

The primary academic research referred to here is **DECO** [^fn1]. The general idea is to **export private TLS session data** with the data provider from **the user's end** and to **prove its provenance** to a third-party application (the verifier). In implementation, it establishes a secure **three-party handshake** among the prover, the verifier, and the data provider during a TLS session, before executing queries for desirable data and proving to the verifier in a **zero-knowledge** fashion. The process is powered by a 2-party variation of Secure Multi-Party Computation (SMPC). Basically, the client key for the TLS session is **split into two shares**, one held by the user, the other held by the oracle. The user needs to **commit** to the returned data packet from query **first**, before the oracle revealing the other share for the user to actually open the packet and generate the proof (in zero-knowledge). Thus, data provenance is ensured while the private data itself never leaves the client side.

An alternative solution to DECO is **Town Crier** [^fn2], which introduces additional security assumptions based on trusted hardware (such as SGX). An earlier open-source attempt at exporting TLS data with provenance, **TLSNotary**[^fn3], which only supports deprecated TLS versions and offers no privacy from the oracle. Theoretically, the DeSoc framework can be supplemented with any of the three frameworks mentioned above to enrich its reputation system.

## Conclusion
This commentary encapsulates a lot of thought processes I have undergone with the Clique team w.r.t. the reputation system/identity/credential space in the past months.

Overall, the DeSoc paper is an amazing piece of research that introduces a matrix of new primitives behind more diverse web3 applications. I've seen a lot of criticism on putting credentials on-chain compared to a full implementation of off-chain VCs, but there's definitely more nuance to that. As discussed in this piece, having an off-chain layer for credential CRUD may be better for **scalability** and **interoperability** (having a single source of truth for claims that can be mapped to different on-chain accounts), while on-chain credentials are much better for **composability** (with smart contracts), and potentially for **privacy** and **security** as well (programmable privacy, community recovery, etc.). In the end, a hybrid approach based on specific trade-offs might be better.

The second part of this series will be primarily about the generic mechanism designs of such a reputation system under DeSoc.

---
*I am a Math+CS student at Duke University. Currently, I am building DID middlewares connecting web2 data and web3 applications at [Clique](https://twitter.com/Clique2046). In the past, I was a national Physics Tournament winner in China, a computer vision researcher at Megvii, and a tech investor at Zhenfund. If you find this piece to be interesting, please follow me on [Twitter](https://twitter.com/kvny2046), shoot me an email at [[e-mail]](mailto:[e-mail]), or grab a coffee with me in NYC.*

*Thanks for the technical feedback from Puja, Glen, Wei, Raphael, Will Robinson, Kydo, and Lushuo. In addition, thanks for proofreading from Yinhong, DCBuilder, Jessy, Priyanka, Jaden, and Robert.*

## References
[^fn1]: [DECO: Liberating Web Data Using Decentralized Oracles for TLS](https://arxiv.org/abs/1909.00938)
[^fn2]: [CanDID: Can-Do Decentralized Identity with Legacy Compatibility, Sybil-Resistance,and Accountability](https://eprint.iacr.org/2020/934.pdf)
[^fn3]: [TLSNotary: How It Works](https://tlsnotary.org/how_it_works)
[^fn4]: [Town Crier: An Authenticated Data Feed for Smart Contracts](https://town-crier.netlify.app/)
[^fn5]: [IDX: A Devkit for Open Identity](https://medium.com/3box/idx-a-devkit-for-open-identity-48edc88e8e85)
[^fn6]: [Sidetree v1.0.0](https://identity.foundation/sidetree/spec/)
[^fn7]: [Verifiable Credentials Data Model v1.1](https://www.w3.org/TR/vc-data-model/#what-is-a-verifiable-credential)
[^fn8]: [Decentralized Identifiers (DIDs) v1.0](https://w3c.github.io/did-core/)
[^fn9]: [Torus Technical Architecture](https://docs.tor.us/key-infrastructure/technical-architecture)
[^fn10]: [Decentralized Society: Finding Web3's Soul](https://deliverypdf.ssrn.com/delivery.php?ID=558024120114006070087079014069121028033081036015093092028097097121122029094121022006001026024056060127015100113118068085072090049035005060074067079013076066068111098003017087074084099004088113016089107122101090090102003012100026071087126104083098072073&EXT=pdf&INDEX=TRUE)
[^fn11]: [UniRep DevConnect Presentation.pdf](https://github.com/Unirep/presentation/blob/main/UniRep%20DevConnect%20Presentation.pdf)
[^fn12]: [Flexible Anonymous Transactions (Flax): Towards Privacy-Preserving and Composable Decentralized Finance](https://eprint.iacr.org/2021/1249.pdf)
[^fn13]: [The AZTEC Protocol
](https://github.com/AztecProtocol/AZTEC/blob/master/AZTEC.pdf)
[^fn14]: [Do you need a Blockchain?](https://eprint.iacr.org/2017/375.pdf)
[^fn15]: [Proof-of-Personhood: Redemocratizing Permissionless Cryptocurrencies](https://berkeley-defi.github.io/assets/material/Proof%20of%20Person.pdf)
[^fn16]: [Linkable Spontaneous Anonymous Group
Signature for Ad Hoc Groups](https://eprint.iacr.org/2004/027.pdf)
[^fn17]:[Minimal anti-collusion infrastructure](https://ethresear.ch/t/minimal-anti-collusion-infrastructure/5413?u=weijiekoh,%20https:/medium.com/privacy-scaling-explorations/release-announcement-maci-1-0-c032bddd2157)