## UniRep V2

We have some exciting changes planned for UniRep V2. You can read about how UniRep works [here](https://mirror.xyz/privacy-scaling-explorations.eth/FCVVfy-TQ6R7_wavKj1lCr5dd1zqRvwjnDOYRM5NtsE). In this post I'm going to talk about how we've been thinking differently about UniRep applications.

## Reputation vs User Data

Historically we've used the term "reputation" in Universal Reputation to mean positive/negative reputation. This definition is very limiting in application, and does not express what UniRep is capable of storing.

Instead reputation should be thought of as **user data**, including things like historical actions, preferences, associations, balances, ownership, friends, etc.

UniRep allows applications to associate user data with anonymous users. Applications attest to changes to user data using anonymous identifiers (epoch keys). A users data is the combination of all changes to all identifiers controlled by the user. The application cannot determine what changes belong to what user.

Thus we can build non-custodial applications: applications that never have custody of user data. Users can interact with UniRep based applications trustlessly. Applications negate the risk of user data being hacked/stolen by never _knowing_ user data. Think Coinbase vs Uniswap, but for _every kind of application_.

## Identity Trapdoor

For the purpose of this post let's define three levels of identity.

1. Fully identified. e.g. That's John, he lives on Fig Street and works at the bank
2. Pseudonymous. e.g. That's trundleop, they write posts about bridges and trolls.
3. Anonymous. e.g. Identifier 0x219fa91a9b9299bf wrote a post about bees. This identifier will never be seen again.

It's very hard to go from lower levels of identity to higher levels of identity. If I see John spraypaint a scythe on the back of the bank he works at, he's going to have a hard time convincing me it was someone else.

Conversely, it's very easy to go from higher levels to lower levels. If I control identifier 0x219fa91a9b9299bf I can always make a ZK proof showing control or linking it to a pseudonym, identity, or another anonymous identifier.

Because identification is basically a trapdoor it makes sense to build primitives that are _anonymous by default_. Users, or even applications, can choose to operate at lower levels of identity. But to support anonymity for anyone, everything must be anonymous by default.

## Physical Security

The identity trapdoor is secured by cryptography. Modern cryptography is physically secure: it's physically difficult to look for a needle in a haystack with 2^128 straws of hay.

Imagine a sphere with a radius of 100 meters, with the following layers

- layer 1: 20 meter depleted uranium
- layer 2: 30 meter steel
- layer 3: 5 meter platinum
- layer 4: 5 meter aluminum
- layer 5: 20 meter gold

Imagine this sphere is dropped in New England in the year 1700. Assume every human on the planet is aware of the composition of the sphere.

What year might humans access the gold?

Physical items can only be secured by physical means; information can be secured by mathematics. Mathematics offers exponentially better security than any physical material.

If we encrypted a 32 byte key using 4096 bit RSA the key would not be be seen until humans have a working quantum computer that can calculate the prime factorization of a large number.

If the same key were encrypted with 256 bit SALSA20 it would not be accessed until either:
- Binary computers can search 2^256
- Quantum computers can search 2^128

The security of information is defined in terms of what information systems can do. Information security is physical because it requires a physical device to exist/breach.

e.g. you probably can't search 2^128 using pen and paper. If every human (8 billion) participated and searched 1 value per second it would take 13487853800000000000 **centuries** to search 2^128.

## Anonymous Applications

With UniRep we can build secure, non-custodial applications with robust user experiences for **anonymous users** like:
- Tracking what movies you've watched
- Tracking what movies you like
- Tracking what products you buy
- Tracking which humans you are friends with
- Tracking what information you often need e.g.
- email
- calendar
- documents

For example, say I log on to a website dniester.com that sells all sorts of goods.

My web browser connects to an Ethereum node and constructs my user data. It then requests a list of all products from dniester.com.

I can locally calculate which products I have bought in the past using only public data. The website is then able to, in the client only, show things like:
- recently purchased items
- similar/recommended items

When I want to make a purchase I make a **single ZK proof** with the following:
- 100 DAI
- Proof that I am approved to make purchases
- A current **epoch key** I control
- Symmetrically encrypted purchase list (encrypted for me to see in the future)
- Hash of purchase list and delivery address

When I click "buy" this proof is generated and then sent to dniester.com. The unencrypted purchase data is included with the proof.

dniester.com validates the proof and checks the purchase info against the hash in the proof. They then decrypt the purchase info, check their inventory, and create an order in their database. They also attest to the **epoch key**, with the symmetrically encrypted purchase data for the user. The website cannot see the contents of the symmetrically encrypted data, but knows it contains only the purchase data, because the encryption happened in ZK.

Thus the website is able to accept orders from anonymous entities and the user is able to see their purchase history by decrypting data from public data storage systems (Ethereum/IPFS/ARWeave/etc).

The user may **anonymously** request updates (e.g. processing/delivery) from dniester.com by proving ownership of a purchase in ZK.

The user may **anonymously** leave a rating for a product by proving ownership of a purchase and generating a nullifier.

The user may **anonymously** request a refund by proving ownership of a purchase, generating a nullifier, and providing information about the refund request.

The user can make proofs about symmetrically encrypted data in ZK. e.g. to reveal information from a purchase request, or purchase.

## Min-Profit Systems

Public/anonymous systems can be built with clearly defined/enforced economics. A good example is the operation of an Ethereum node. Participation is public/pseudonymous, and a fixed profit is taken based on participation. A fixed cost is incurred for hardware, internet access, and Ether collateral.

Using UniRep we can build pub/anon systems with robust minimum profit economics. For example, a grocery delivery service could be built using UniRep. A user makes an order and pays $100. This $100 is split like
- $90 cost of groceries
- $9 payment to shopper
- $1 payment to system operation fund

In this contrived example, the shopper, the person doing the work; takes \~90% of the profit. The system itself takes 10% profit to cover transaction fees and cost of operating web services.

Contrast this to something like Instacart where the bulk of the profit is taken by the corporation while the people doing the work rely on tips.

In practice min-profit system operators would likely be a team of 1-5 people **maintaining** a piece of software. The system would be built to the point that it works, then operated indefinitely - until people stop using it or the operators choose to stop. The corporation stays as small as possible while still providing value to the users.

Such min-profit systems are hard to build because they require an upfront investment of engineering resources. This cost can be recuperated as a temporary fee on each order until the full cost has been repaid (or full cost + $X, where X is the profit on investment).

## Conclusion

Hopefully this post gives an idea of what is possible with anonymous user data. You can read more about UniRep V2 [here](https://developer.unirep.io). You can try a demo application using the protocol [here](https://canon.party).