Identity for a multi-chain ecosystem
Follow the discussion at https://commonwealth.im/edgeware/proposal/discussion/150-identity-for-a-multichain-ecosystem!
For most blockchain applications besides wallets, there is a single blockchain that runs that application. Be it Aragon on Ethereum or Counterparty on Bitcoin, many protocols and dApps are mono-chain apps. They rely on the underlying public key system as the identity system. The key question we ask: is there a better way to handle identities?
This question presents a new set of user experience challenges. In a multi-chain world, will users even want to maintain multiple private key pairs when they are using an arbitrary web dApplication? I will address this question negatively first, as I believe this is not how users will want to interface with blockchain applications. Instead, the point of the user experience will exist on a spectrum that highlights the difference between the Web2 world and the Web3 world.
Web2 vs. Web3 Authentication
As a motivating example, take Facebook and Google login: a single sign-on service for most applications one uses on the internet today, which only requires access to one username/password pair. This construction allows the user no privacy, but it allows them complete convenience. The user never has to maintain private keys, not even a single keypair, because in the event of losing one’s password, you can redeem it using password recovery methods.
Now consider the growing multi-chain blockchain landscape: different key signing algorithms for each new or existing blockchain in which one holds cryptocurrencies. A plethora of applications, specific to each chain, that requires secure storage of one’s private keys so that funds are never lost or stolen. In some ways this mimics a world akin to password management and as the list of blockchains grows, one is left with similar problems of remembering (storing) passwords in a safe location. Nonetheless, there is money involved and one is never instructed to store private keys on hosted password management solutions.
What do users want?
We know users want an easy experience; often, people will say users don’t want to know anything about the public key infrastructure, abstract it away! Make sure the user has no idea what’s actually going on under the hood. Great..
For those of us building applications in this space, it’s not as clear cut how blockchain products should evolve with this mentality, given the tools we have to decentralise our applications still require heavy amounts of overhead. I, however, claim that users don’t want to be responsible for managing multiple long-term private keypairs in order to use blockchain applications. If people are to use blockchain applications on a daily basis, then perhaps short lived keypairs are the way to go. Even further, in this world, users create keypairs effortlessly, use them for short-periods of time, and retire them, while maintaining connections to their application state across a multi-chain ecosystem. How do we achieve this? Privacy tech and bridges. Lots of bridges.
Identity Infrastructure
At a high level, the convenience provided by Web2 identity services like Facebook and Google boils down to infrastructure. These services are the backbone for large portions of the web’s identity infrastructure. What we want then, in a similar vein, is the backbone for a web3 identity infrastructure. User’s should be responsible for the least amount of data possible, which means other service providers must be incentivised to replicate the necessary data across blockchain applications. If in fact, dApps live on multiple chains such as ETH, Edgeware, Polkadot, then what we are looking for is a single-sign-on for each of these chains.
As a thought experiment, we’re 5–10 years in the future. There are applications that live on multiple blockchains, such as DAOs that take funds in multiple cryptocurrencies and voting mechanisms that span many protocols. An infrastructure provider in this realm builds blockchain bridges that link the necessary state across this ecosystem so that, for example, votes on one chain can be counted on a completely different chain and eventually settled on all participating chains. These infrastructure providers make up the backbone for this new identity ecosystem. How can a user interact with their dApp state without worrying about using the same keypairs repeatedly? For my experiment, they won’t. Instead, they’ll generate new keypairs on the fly and interact with these dApps using arbitrary secrets that they securely store, potentially in a hot mode for ease of use.
With the advent of zero-knowledge proofs, researchers and developers have begun building amazing privacy technology that is now scratching the surface of the identity landscape. Projects like Miximus and Semaphore are key players in understanding some of the ideas I will put hereforth, but nonetheless I will distill them as clear as I can.
Users in this multi-chain ecosystem will generate and store arbitrary secrets (think random bytes of data) and associate their blockchain based keypairs with this data somehow. For example, assume that there exists a smart contract on a number of blockchains that allows users to add random data to a Merkle tree. What this contract does in particular is allow users to associate their blockchain based keypairs with random data, usually hashed so that the data is kept secret. These users can submit zero-knowledge proofs to prove they have added elements into the Merkle tree without exposing which account added such elements. These Merkle trees will be considered as arbitrary membership sets or identity groups that only eligible individuals can add elements to, solidifying claims to the identities inserting items into the Merkle tree.
The process proceeds as follows: users with some eligible claim C can add data to a Merkle tree and eventually the backbone providers maintaining the bridges I mentioned above will replicate and bridge these Merkle roots to all other supporting blockchains. This in turn, allows all the users on the target chain to prove claims about their identities on all other supporting blockchains. Thus, they don’t need access to their original keypairs to interact with dApps in the multi-chain world, but rather only have access to their short-lived secret data. As an added bonus, participating across chains is private, since proving membership in the Merkle tree can be done using zero-knowledge proofs of membership.
We’ve glossed over many implementation details and will present some key questions for this design.
- If users are to use these short-lived secrets to prove knowledge or ownership of claims holding keypairs, how do we refresh these secrets over time.
- How long should short-lived secrets be eligible to be used? Since we are bridging Merkle roots across many blockchains, the time-to-live (TTL) would need to be at least the diameter of these bridges latency.
As always, comment below with any more and any key insights! Another discussion can also be found at: https://commonwealth.im/edgeware/proposal/discussion/150-identity-for-a-multichain-ecosystem
