An identity represents a collection of data of a natural person. An actively generated cross-platform identity provides credit for accessing dedicated services, for example, a good Alipay credit could get a microloan or free borrowing services. A cross-platform identity could also make the accounts management easier like Facebook login enables single sign-on for different applications.
But the data is not only collected actively by user inputs, it is sometimes passively collected by the scripts monitoring user behaviors, and it is always leveraged by data brokers without notifying users.
Pseudo-anonymous blockchain networks come in and prevent the identity profile from being monitored, but it also eliminates the benefits of having a cross-platform identity. Without a cross-platform identity, the user experience of identity management on DApps would not be as competent as Web2.0 Apps, and most importantly, it is hard to validate and accredit identities, which will lead to the following problems:
- A common problem for new blockchain projects is how to attract real users. Blockchain projects always use air-drop, but projects cannot prevent a user from creating multiple accounts to get the rewards. For example, Uniswap’s generous token gifting to all the historical liquidity providers does not have any differentiation of the users.
- A missing point in the DeFi world is credit loan. Without the credit or financial history of users, financial institutes need to charge a collateralized deposit for issuing a microloan or flash loan.
- In the on-chain governance of a Proof of Stake(PoS) network, the voting power is mainly decided by the distribution of tokens, the network will need sophisticated algorithms to make sure the voting power is not controlled by individual major stakeholders.
The activities of an on-chain identity nowadays are more than token transfers and it could reflect the characteristics of the identity. For example, to know if a user is a long-term liquidity provider on Uniswap we could check the liquidity deposit and withdrawal actions, or know if a user is active as an on-chain governance participant on Polkadot by checking its data of nominating and voting for democracy. In addition, the blockchain runtime tends to have more complex states, like tweeting in a decentralized blog system that has its record on-chain. A transaction should more properly be called an “extrinsic”, which indicates any message from the outside world that would change the state of the blockchain. Once combined with different accounts across different chains, we may derive more information about the identity behind these accounts and solve all the above problems.
That is the reason we need a cross-chain identity, a user picks identities from different chains to be linked together, then on-chain data of linked identity are collected and quantified, and eventually, a user could provide a cross-chain identity as a first-order logic for different networks and DApps. With such a cross-chain identity, blockchain projects could offer dedicated graded services/functions according to the identity’s quantified data. For example, if a new project knows that an account is a Polkadot validator, and it spends hundreds of DOTs on another Parachain for half a year, then the project could directly gift this specific user some token to start to play with, or send him/her an attractive offer of the new DeFi product, or accredit him to be a validated voter.
The cross-chain identity as a first-order logic enables validation and accreditation of identities and also could provide a single sign-on with linked identities. It completes the missing part in the pseudo-anonymous networks and is essential for the development of DApps in Web3.0.
So we see the bright future of a cross-chain identity, but why not just create a web app and link the data to a central server?
Creating a credit according to the user data is a centralized behavior in the banking world. But we want to make it in a transparent, decentralized, and trustless way. The network participants have the right to adjust the following mechanism and thus prevent Sybil attacks:
- How to link an account from a different chain to a Litentry account.
- How to evaluate a specific credit, and which parameter to use.
- From which resource should the parameter be fetched.
Here is an example to show a process to get the “long liquidity provider” credit of Uniswap and record it in Litentry Network. Litentry is a network built with Substrate and will join Polkadot as a Parachain.
1. The community decides how to link an Ethereum account to a Litentry account, for example, to sign a message by the private key of the Ethereum account, the message is the combination of the Litentry account ID and the current block number of Litentry network. In the future, this could be implemented by a cross-chain message with XCMP.
2. The community agrees upon an accreditation function on Uniswap by voting, to take the longest liquidity duration and the ETH value as the parameter, and compute a credit to show if a user was a long-term liquidity provider based on these two parameters.
3. Currently, Ethereum is not bridged to Relay Chain yet, the community needs to upload the functions to get the parameters, for example, which HTTP endpoints to use for querying on-chain data. To make the process decentralized and prevent a single point of failure, variant resources should be used, e,g Ethplorer, Etherscan. Once XCMP is enabled and Ethereum is bridged to Polkadot, the computing process could directly happen on the Parachain.
So once a user links his Ethereum account on Litentry network and requires a credit on Uniswap. The off-chain worker of the validator will automatically query and process the data on the appointed smart contract. If all the validators agreed upon the result (a boolean or a number), a credit with a timestamp will be generated and be recorded on the chain.
As mentioned in the above example, If the target account is also on a Parachain, The account linking and accreditation process leverages Polkadot’s XCMP and could be significantly simplified and get even better performance.
By using the blockchain to build a cross-chain identity, we create a transparent, decentralized, and trustless way to provide identity as a first-order logic service.
And why not just use one Polkadot account for all the Parachains?
On Polkadot, the accounts are generated by a seed’s derivation paths, a key pair on different blockchains has different representatives (SS58 Address). So in theory a user could use one account to interact with all the Parachains. But for security reasons, it is not safe to have a single key-pairs for every Parachain, it is like the same password for different web apps.
Another important reason is there is still a lot of blockchains systems running out of Polkadot, we want to connect all of these chains, by our protocol, so that Litentry could also link accounts from other chains which have not bridged to Polkadot in a trustless way, and implement an identity “Oracle”.
Why not use Polkadot’s native identity module? Why create an independent Parachain?
Firstly, as a Parachain, it is possible to offer incentives for users to create a cross-chain identity, to have flexible token economics not be limited by the price of DOT.
Secondly, the current identity module on Polkadot aims to offer a basic identity for on-chain governance, it has some limitations like high fee, offline contact, no automation judgment, and limited fields. In our opinion, Polkadot is focusing on providing security for Parachains, and the aforementioned trustless on-chain governance for identity linking and credibility should mostly happen in a Parachain. And that’s why Litentry comes in and tries to solve it.
In addition to that, Litentry is not limited to the identities in the Blockchain world, we will build the protocol and related tools that help users collect user’s off-chain data from web apps with privacy protection. Once we connect identity across chains and off-chain apps, the user would have more dedicated control on identity and be able to use more dedicated services/functionalities of networks and applications on Web3.0.
Looking forward to partnerships with other blockchain project and for more information please check our website: https://www.litentry.com/
