---
title: Solana <> THEMISv2 RFC&C
tags: rfcc, themis
---

# Solana <> THEMISv2 RFC&C

**THEMISv1 work:**
- [THEMISv1 upper bounds](https://docs.google.com/spreadsheets/d/1-luZUGtAeivfQQJzwhV4RJaws1WukRPldReIW1TcwXM/edit#gid=0)
- [THEMISv1 benchmarking on Solana](https://docs.google.com/document/d/1fLhvHxXzNxUZy7bn6jAWa_7FOZQ9o3D28wWPhziBLSc/edit)
- [Solana fees for Brave workloads](https://docs.google.com/document/d/1mqxQ-acas17L29-9hiyTKxwGO7umNiBVQEKWGuySfpY/edit)
- [THEMISv1 implementation on Solana](https://github.com/solana-labs/solana-program-library/tree/master/themis)

## Adapting to THEMISv2:
1. **Use Solana (Rust + BPF smart contracts) to run verification of the proof reward calculation on Solana**

Could we estimante the batch verification of proofs of correct reward calculation generated by the user based on the measurements from the Ristretto implementation for THEMISv1? The concrete values may depend on the L2 proof verification scheme (not sure which we'll use yet), but probably we can extrapolate the thorughput, scalability and costs anyways;

On the other hand, I'd expect that Solana's tx and costs would allow us to bypass the batch of proofs altogether -- this would allow the users to directly push their reward request to a smart contract, instead of sending it to Brave or a computing unit that would batch multiple user proofs. Cutting on this intermediary would defenitely be a plus.

So instead of having:

 User_1  -<proof>-->  |
 User_2  -<proof>-->  | --> Brave -<batch_proof>--> Blockchain
 ..                   |
 User_n  -<proof>-->  |

We have:

 User_1  -<proof>-->  |
 User_2  -<proof>-->  | --> Blockchain
 ..                   | 
 User_n  -<proof>-->  |

Which is a better design since it i) less dependency on Brave; ii) simpler; iii) cheaper for Brave (no need to batch proofs, which may be expensive);

Next steps in this direction:
- Estimates for single proof verification using e.g. PLONK or ZK-STARKs;
- Roadmap/requirements to build the Rust smart contract on Solana for batch/single proof verification;

2. **Propose THEMISv1 on Solana as an alternative to THEMISv2**

The main reasons for redesigning THEMISv1 and leveraging zk proofs are twofold: a) scalability, decentralization and costs -- which Solana seems to solve; b) advertising metrics.

In THEMISv1 the advertising metrics system relied on MPC computation by a P2P network which is very complex to build, deploy and perhaps not so robust for what we needed. The Transparent Ad Attribution (TAA) system in THEMISv2 allows the advertisers to validate the ad budget expenditures, without needing to trust Brave. The fundamental difference with the TAA is that each encrypted ad interaction is sent through a broadcast channel (alongside with the BBA for the update). The Brave and the advertiser who "owns" the ad that the user interacted with can decrypt the payload published in the broadcast channel.

Could the TAA system be redesigned to leverage Solana? i.e. instead of relying on a broadcast encryption, could the analytics be implemented on a Solana smart contract so that it would allow the advertisers know how many ad interactions the users have made over their ad campaigns, without linking those interactions to users? (IP, wallets, etc..)?

Next steps in this direction:
- Redesign analytics to leverage Solana
- Cost and tx estimates of such system

3. **Implement the broadcast encryption channel for TAA using Solana**

(note: this is my favorite!)

We haven't decided how to implement the TAA broadcast channel for THEMISv2. Our current understanding is that the users will send the encrypted reward calculation with the BBA through a proxy to a pubsub system (e.g. Redis, Kafka..) where advertisers and Brave will be consuming from. Now, how about relying on Solana for implementing the broadcast encryption channel? Given the high thorughput, low costs and data management capabilities of Solana, I think this is a great fit (better than anything else at this point, actually.)

So in this case, THEMISv2 would still rely on BBAs and ZK-S*ARKS for provably calculating the user rewards. And Solana would work as the "glue" or channel between users and advertisers + Brave.

Next steps in this direction:
- Costs and t estimates for using Solana as a Broadcast Channel for TAA;
- Implementation requirements (i.e. how to make sure users are not linked to the request made to the chain? -- perhaps using Nym or smth along those. lines).