A Technical Commentary on DeSoc: Part I

Jun 06, 2022

Introduction

The latest publication 1 from Microsoft’s Glen Weyl, Flashbots’ Puja Ohlhaver, and Vitalik Buterin, 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 (SBT).

The authors have detailed the exciting future that non-transferable tokens (and their off-chain counterpart, verifiable credentials) can bring to the currently hyper-financialized crypto space. These SBTs can serve as signals of reputation and tools for broader decentralized network coordination. Since this topic is also something I have been exploring with the Clique 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 tradeoffs 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 social/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 numerous applications thrive on network effects and are dependent on some level of pre-established publicity (reputation staking, etc.), there are multiple drawbacks to 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 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 2. 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 the availability of states for all clients). The verification of credentials can 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 a 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 set up 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 their 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 the time t when it’s presented. IDX3 would be a good option for a central repository that queries credentials and their states, given that 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 will be limited due to overhead for frequent state updates, which incur high gas fees. 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. As a reference, this is an oracle problem that Chainlink is implementing with their evolving NFTs.

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. 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 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 to cross-reference credentials. Deduplication 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 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 zero-knowledge 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 remove unilateral privacy while ensuring that public and private credentials have 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) 4 has already been exploring 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 5 uses cryptographic tools like linkable ring signatures 6 to achieve this goal, albeit in a non-scalable way. The authors have mentioned running a 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 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 looks like this:

Several 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 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 MACI7 are more robust, but rotating with trusted setups might be hard.
Maybe a standard like EIP 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, Investigate the appropriateness of Open Badges for what we need, CDIP 2 - Non-transferable Badges for Maker Ecosystem Activity.

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 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 the Sidetree protocol 8, 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 9 10. 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 the 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_i denotes the data provider (i.e. where the claim originates from, either through a legacy issuer like YouTube or some on-chain DeFi application, etc.)
σ, or signature: signature by issuer over pk^U, ctx, and{claim_i}. The signature is denoted as σ=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 to consensus on its 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 is implemented with additional trust assumptions (e.g. with trusted hardware, or a specific set of zk sigma protocols/commitment schemes like Aztec11). 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 transactions (tokens, NFTs), staking data, yield farming data, 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 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 DECO12. 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). During 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). The client key for the TLS session is split into two shares, one held by the user, and the other held by the oracle. The user needs to commit to the returned data packet from the query first before the oracle reveals the other share for the user to 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 Crier13, which introduces additional security assumptions based on trusted hardware (such as SGX). An earlier open-source attempt at exporting TLS data with provenance, TLSNotary14, 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 full implementation of off-chain VCs, but there’s 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 tradeoffs 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. 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, shoot me an email at kevin@2046inc.xyz, 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, LW, Jessy, Priyanka, Jaden, and Robert.