# Product outline

## Assumptions
1. Users want privacy at protocol level: My entire product is based on assumption that users want privacy. Need of privacy can either be for philosophical reasons or practical reasons.
Keeping philosophical reasons aside, I think there is a strong argument for need of privacy for practical reasons. Traditional finance works like blackbox. There are good and bad consequences to this. The good part is your data remains private to most of the world and that's satisfactory for most people. The bad part is, it works like blackbox and, since we are trusting humans, privacy can be compromised given enough motivated actor.
Mass majority of tradfi will only be comfortable in adopting blockchains when blockchains offer privacy, but in addition guarantee that, unlike tradfi, blockchains do not work like blackbox, are verifiable, and are deterministic in their behaviour. Privacy preserving protocols are a way to do exactly that!
2. Protocol level privacy cannot go without infrastructure level privacy: We are assuming that infrastructure privacy is as critical as protocol privacy. This is so because leakage at infrastructure level incentivises creation of a market that extracts information at infrastructure level, hence rendering protocol level privacy useless.
3. OMR is critical for privacy preserving protocols like Aztec, Aleo, Namada: Infrastructure around privacy preserving protocols is lacking. Which necessitates them to use things like trial decryption for retrieving transactions, locally syncing the commitment tree to retrieve the hash path before spending notes.
Trial decryption and local sync do not even provide good UX on zcash at current transaction traffic and, since the cost scales linearly, it will get worse in the future. Protocols providing private smart contracts, expect to process millions of transactions a day. This renders trial decryption and local sync as no go options, since they risk making UX almost useless and hinder adoption.
4. Wallet developers need OMR: Wallet developers need some way to obliviously retrieve user messages from server to make their wallets usable. I am not assuming that OMR in its current form is the solution. I think algorithm improvements, other than just performance improvement are possible.

## Products
Our products will provide privacy infrastructure services around privacy preserving protocols. We will position ourselves as infrastructure as a service providers to wallet developers to make their integration with privacy preserving protocols as seamless as possible.

Value proposition for wallet developers is (a) they wouldn't have to care about building protocols to prevent leaking user privacy at infrastructure level (b) they get best of both worlds, good UX and privacy.

#### There are two products
1. OMR - Oblivious message retrieval
2. Private information retrieval - PIR fits in two places in privacy infrastructure
1. In conjunction with OMR: After discussions with Aztec I realised that since OMR isn't performant enough yet we might require to use PIR in conjunction with OMR. You can think of using OMR with PIR in following way:
1. OMR is used for contact discovery and setting up a shared secret: Unknown contact sends you an intent message to setup a shared secret using OMR. The message is encryption of public key of unknown contact.
2. PIR is used for retrieving transactions received from known contact (after 1). All transactions are stored inside a transaction db with key set as hash of shared secret appended with nonce, where nonce is incremented for each subsequent transaction between given two parties.
2. Private RPC client: Retrieve client state using PIR instead of syncing it locally for transactions.

#### Problems with PIR:
Existing PIR schemes are unfriendly to clients due to their requirement of uploading few Mb of data per query for a dataset of desired size (think of millions ot transactions per day). After discussions with folks at Aztec we concluded that it will be better to prioritise reducing cost of OMR, since it is friendly to clients in its current form and only needs performance improvements, and then focus on PIR. Hence, instead of PIR we will be using mix-nets until we make PIR friendly to clients.

#### Experiment 1
For experiment 1, to test the feasibility of our positioning as an infrastructure provider to wallets, we will be sticking to OMR. This is so because OMR is critical and our most valuable offering. We will be avoiding PIR, since PIR has a replacement, though less desirable one: mix-nets. Moreover, a very performant implementation of OMR can render using PIR in conjunction with OMR unnecessary.

OMR in its current form, assuming no further algorithmic improvements, is friendly to clients and only requires a more performant implementation. Path to a performant implementation is quite deterministic. However, in case of PIR, there are uncertainties around whether we will be able to come up with a scheme that is friendly to clients. Though, I think it will be worth shooting for in future.

#### Performing experiment 1 is cheap:
Existing OMR implementation has evaluation time of 90 minutes per batch (1 batch = 32768 messages). A further optimised implementation can bring the time down to 40-45 minutes. However, the algorithm implementation is still isn't parallelised. I expect parallelised implementation will bring the time down further on CPUs.
For experiment 1, I am aiming for a GPU implementation of OMR. Papers discussing GPU implementation of BFV scheme (FHE scheme used by OMR) observe 30-40x performance improvement over performant FHE libraries. Thus, I expect evaluation time of GPU implementation of OMR pessimistically to be at-least 10x better than existing CPU implementation, that is around 9 minutes.However, I think we can do better than this.

#### Why not start with FPGAs?
FPGAs can give at least one magnitude of performance improvement over GPUs and cost less to run. However, GPUs are easier to iterate with and require lesser engineering resources.

#### Product properties
Our product offering necessitates it to have two very important properties
1. Seamless integration - Wallet developers should be able to seamlessly integrate our product into their wallets. Ideally, the product should have two components from developer's perspective.
1. API keys that provide access to server.
2. SDK for integration: Developer should be able to plug in the sdk into their codebase, supply API keys as arguments, after which everything should work.
2. Open source - Open sourcing is critical to our adoption because
1. Users rely on our codebase for privacy and security vulnerabilities can have massive negative consequences. Open sourcing the codebase gives white hats a chance to safely disclose vulnerabilities before black hats spot them.
2. Self verifiability is important part of our ecosystem and is critical for winning trust of our users. Our users (ie wallet developers) and our users' users would want the verify the codebase.

#### Why not just fork?
Seamless integration and open sourcing makes forking our codebase a lot easier. One way out of this is to make integration a bit harder. But I would not want to explore this route, since it does not makes sense and wouldn't play well with our core competency. Moreover, there exist other reasons why it will still be costly for wallets to fork our service.

Let's divide our entire product cycle into two stages (1) Nascent stage (2) Mature stage. Nascent stage is defined by rapid SDK updates, performance, as well as algorithm improvements. Mature stage is defined by rare SDK and algorithms updates, but still frequent performance updates.

Nascent Stage:
1. We need to make forking irrational during nascent stage:
Cost of forking includes cost of initial fork and then keeping up with the updates.

Cost of initial fork will require understanding the codebase of SDK, understanding the underlying cryptography, understanding GPUs/FPGAs implementation and deploy and maintain servers.

Cost for keeping SDK/algorithm/performance updates will require understanding the changes.

Since SDK updates will be rapid, a dedicated full-time engineer for maintaining wallet's fork of SDK is required. A full time GPU/FPGA engineer is required to understand hadware implementation and further changes. A full time devops engineer is required to maintain servers and deployment cycle. Part-time cryptographer is required to understand the scheme and further updates well enough.

If our product costs less than hiring full-time software developer, GPU/FPGA engineer, Devops engineer, and part-time cryptographer, then it is rational for wallets to not fork our service.

2. Being first to market benefits us in developing economies of scale for mature stage:
Let's say we approach wallets to use our services. Assuming OMR is critical for their product, they can either agree or disagree and fork our service. Since our product is the first in the market, wallets aren't aware of its behaviour. Hence, it does not makes sense for them to put in resources to fork our service without testing it once. Hence, it is very likely that they will agree.
If we are able to make it irrational for wallets to fork our service throughout the nascent stage, either through performance improvements or, as last resort, through subsidising the cost, then we can benefit massively from economies of scale at mature stage.

Mature stage:
1. Cost of forking and maintaining:
Since in mature stage we don't expect many SDK updates nor algorithm updates, but performance improvements, the cost of forking can be reduced to a part-time software developer, full-time devops, and full-time GPU/FPGA engineer.

If our product costs less than a part-time software developer, full-time devops, and full-time GPU/FPGA engineer, then it irrational for wallet to fork our service.

2. We benefit from economies of scale:
Assuming we were successful in convincing many wallets during nascent stage to stick with our service, then we can potentially benefit from economies of scale in mature stage. This means a wallet that forks our service wouldn't be able to provide the same service as cheaper cost than we can. Hence, it will be irrational for wallet to do so.

#### Threat from TEEs
By running nodes inside TEEs (trusted execution environments, like SGX) using ORAM (Oblivious RAM, like PahtORAM), to prevent side channel attacks, it is possible to offer same products as ours but probably at cheaper cost and faster go to market. However there is penalty associated with TEEs based solution:
1. Downgrading from threat model of (F)HE to threat model of TEEs.
2. TEEs are bad publicity and should only be used when no other solutions are practical. However, in our case our solution is a practical alternative. Any service offering TEEs based solution will come out as taking a shortcut and comprimising on user's privacy.

#### Upper bound of cost requirements of using our products
Let A be the penalty cost associated with TEEs based solution. That is, our users are willing to pay A over the cost of TEEs to use our solution. Let B be the cost of using TEEs based solution. A + B defines the upper bound on the cost requirements of using our products.

## Risks
1. Failing to deliver on upper bound cost requirements.
2. Failing to convince wallet developers that OMR is critical in nascent stage. This can happen due to:
1. Privacy preserving protocol is in early stage and the developers don't expect enough txs traffic to make trial decryption infeasible. Thus, they want to take wait and see approach for OMR:
I think if developer understands the private smart contract protocol correctly, then this will not be the case. Private smart contracts will produce a lot more notes than a private payment system like zcash.
2. Wallet wants to avoid using our product as well as trial decryption by storing viewing keys on server: Such a wallet will force us into thinking that users don't care about infrastructure level privacy but in fact, in reality, wallet isn't making users aware of our products. In this case, we need to find just one wallet that is willing to integrate with us. Finding such a wallet should be easy since our product integration should give them competitive edge over other wallets. Hence, this can force other wallet to integrate as well.
If we fail to find a single wallet willing to integrate, then we risk failing in experiment 1 and will have explore other routes, such as building a wallet ourselves.