---
title: THEMIS RFC&C L1 submission - directions and ideas
tags: rfcc, themis
---

# THEMIS RFC&C L1 submission - directions and ideas

1. **Use blockchain to run the reward proof verification**

The first trivial direction is to estimante/measure the performance and tx of the batch proof verification necessary to validate user's reward calculation.

On the other hand, I'd expect many new blockchains to enable tx and low costs would that would make betching unecessary. 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 (as in the THEMISv2 proposal):

 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 smart contract to validate batch/single proofs on-chain;
- MVP to perform scale up measurements

2. **Implement the broadcast encryption channel for TAA using a blockchain**

(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 a L1 for implementing the broadcast encryption channel? Provided that the blockchain can provide tx necessary, low costs and, optionally, ways to drop data, I think this is a great fit for a L1 project (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 the blockchain would work as the "glue" or channel between users and advertisers + Brave.

Next steps in this direction:
- Costs and t estimates for using the blockchain 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).
- MVP to perform scale up measurements

3. **Propose an alternative THEMIS protocol**

THEMISv2 leverages zk proofs and the Transparent Ad Attribution system to achieve the goals and requirements outlined in the [tech report](https://github.com/brave-intl/themis-rfcc/blob/main/rfcc-themis-tech-report-v1.0.pdf).

Could the THEMISv2 protocol be redesigned to use only a blockchain?

Next steps in this direction:
- Redesign analytics and reward calcuation protocol to leverage L1 without the need to zk proofs;
- Cost and tx estimates of such system;
- MVP to perform scale up measurements.