TLDR; uPort, in its quest to create a universal, user-friendly, self-sovereign identity platform, has updated its smart contracts. They are now more scalable and more privacy preserving.
Public blockchains are wonderful things. The need for one is clear when building an identity system like uPort; if we are going to have global self-soverign identity, then we need a censorship-resistant, zero-down-time public chain to manage a few things.
At uPort, we leverage the Ethereum blockchain to accomplish this goal. First, Ethereum serves as the basis of our key management system. Smart contracts allow users to decide what keys have control over their identity. Furthermore, uPort provides a simple and clear way for users to interact with the Ethereum blockchain.
The uPort smart contracts allow for both uses to be rolled into one — the keys that control an identity are also the keys enabling it to interact with the Ethereum blockchain. This means the uPort smart contracts sit at the center of many architecture meetings.
Part 1: History of Old Contracts
Throughout this three-part series about uPort’s smart contracts, we will explore how our smart contract infrastructure has evolved.
This post will start with the original uPort contracts: how they worked, what they accomplished, and what needed to change. In the second and third parts of this series, we will explore our recent improvements and upgrades to these contracts.
These improvements move uPort closer to the Ethereum mainnet, and make uPort significantly more scalable, private, and user-friendly.
Ye Olde uPort Contracts
The old uPort smart contracts have served as the basis of a uPort identity for the past year or so. As we will explore below, they are a wonderful first version, but were likely never meant to be deployed on the Ethereum mainnet.
Proxy Contract:
The Proxy contract is the most basic building block of a uPort identity. A new Proxy is deployed for each new identity, and its address is the identifier of that identity. This means that controlling access to the Proxy is controlling access to the identity.
The Proxy contract does exactly what it sounds like: it allows a certain address to interact with the blockchain through itself. Effectively, it is the avenue through which users interact with the rest of the Ethereum world. This allows a user to continue interacting with other smart contracts from a single address, even in the case of key loss.
RecoverableController Contract:
The RecoverableController is the contract that controls access to a Proxy. It allows a key, which exists only on a user's phone, to use the Proxy contract it has control over.
The RecoverableController, as its name hints, also gives users the ability to recover their Proxy if they lose their phone (and thus their key). Users do so by declaring some recoveryKey — a key with the power to give a user control of their Proxy again.
This recoveryKey could be some secret backup key that the user holds (aka, seed recovery), or it could be a social recovery network.
RecoveryQuorum Contract:
You might have asked yourself: what is a social recovery network? Great question — this is where the uPort recovery mechanism comes in.
The RecoveryQuorum contract allows a user to create a list of “delegates” that act as the recoveryKey mentioned above. Essentially, these delegates can vote to restore a user’s Proxy to its rightful owner in the case of key loss.
The delegates must have a uPort identity, as they are given voting power in the RecoveryQuorum through their own Proxy contracts.
Issues with Ye Olde uPort Contracts
As mentioned, these contracts worked quite well as a first version. They allowed us to quickly onboard users with little worry that one user’s identity would affect others, as they were clearly sandboxed from each other. They were also comprehensive enough feature-wise to allow us to build and test the uPort mobile app in situations like “setting up a recovery network,” or “recovering control of an identity,” or any other interaction with the Ethereum chain.
However, there were a few ways in which these contracts could be improved before being deployed on mainnet.
For one, these contracts were incredibly expensive. For each new identity, all three of the above contracts had to be deployed. This meant that identity creation was far from cheap, costing 2.4 million gas per. On a testnet, this isn’t really a concern; on mainnet (in this day and age), this is far too expensive. Costs had to come down.
Furthermore, these contracts had a variety of privacy concerns. Issues like fee-linking, recovery networking linking, and more, meant that users were limited in how they could use uPort. While currently this is less of a concern, uPort takes privacy very seriously, and thus could improve privacy within the uPort smart contracts.
Conclusion
The original uPort smart contracts helped us launch and served as the foundation to our self-sovereign identity network. With them, we’ve been able to test our mobile app with thousands of users, receive feedback, and make improvements. As we move to scale and improve uPort’s privacy and efficiency with an eye toward mainnet, we have been dedicated to optimizing these smart contracts.
Up Next
In part 2 of our series, we’ll be continuing our look into the uPort smart contract infrastructure, as we unveil the uPort IdentityManager, a critical development in making uPort easily accessible, more private, and cost-effective for everyone.
