Gonçalo: I assume a 5 year old already knows about (and uses) browsers and ads, so let me take a stab at this one.

Imagine your browser will give you candy based on ads you see. Now, in order to get your candy, you need to tell Brave how many you should receive. However, you want to keep the ads you saw as your secret, so you won't reveal them. THEMIS will make sure that, even though you keep your secrets, you'll be able to receive your candy. Ah! And you don't try to lie and ask for more candy than you deserve—THEMIS will magically know that you are lying and you won't get any candy :O

(This one was harder than I thought. :))

Gonçalo: Thanks for the questions! It is true that the deadline for the RFC&C submission has been extended a couple of weeks—the new submission date is the 31st of March. This should not affect our plans considerably but will allow teams to have stronger submissions. Once we get all the submissions from the teams, we will review them and plan the next steps regarding which technologies to use and how to plan the development and rollout of the protocol.

Gonçalo: Correct, the THEMISv1 protocol relied on a PoA sidechain to calculate the rewards in a privacy-preserving way and to verify and orchestrate the reward payments of Brave Rewards. Due to the drawbacks of sidechains, we designed the THEMISv2 protocol to offload the reward updates and calculation from the sidechain to the users and Brave. In THEMISv2 the users, Brave and advertisers use zero knowledge proofs to verify that the protocol is running correctly. The proofs may be verified on-chain to provide public visibility of the correctness of the protocol. However, THEMISv2 is agnostic to the blockchain used and underlying consensus mechanism. We’ve been working in the RFC&C with L1 projects to find the best option considering decentralization, costs and scalability.

In THEMISv2 there may be the need to batch the proofs before verifying them on a blockchain in order to reduce the on-chain costs. This could open the possibility to create an incentivize network of “batchers”, who would provide computation resources necessary to batch the proofs and be rewarded for that work. However, this is a long-term scheme (if it ever happens) and initially Brave will be the entity batching THEMISv2 reward proofs. Thanks for the questions!

Gonçalo: You can check our careers page here /careers/. We're always looking for great people!

Gonçalo: Hi, thanks for the thoughtful questions! We have released a tech report about THEMIS for the RFC&C that may help answer your questions. We expect THEMIS to support up to 5M concurrent users (with potential for more) and to verify 50M rewards per month, including on-chain verification. In terms of costs, we’re setting the bar at up to $0.1 per reward computation and verification, with on-chain verification and costs for batching proofs (if necessary). In addition, we want to make sure the load on the client is as low as possible—the performance and battery consumption of the protocol should be negligible. These numbers help to steer the protocol design and technology decisions we are currently making.

Gonçalo: This is a great question, and as Ben answered in this thread, cross-chain token migration is a very hot topic nowadays and I believe that will be the case in the future.

Gonçalo: Thanks for the question! The current THEMIS protocol design relies on both L1 and L2: while the reward calculation is performed off-chain and verified using zkproofs, we also plan on verifying the batch of those proofs on a scalable L1 layer.

Currently we're assuming that THEMIS users are using the Brave Browser—as it is the case with Brave Ads nowadays.

Gonçalo: Regarding evaluation of RFC&C proposals, we're considering several different dimensions as outlined in the Section 4 of the RFC&C tech report. Performance is one of them, for sure, both from the user perspective (how much energy and resources will take for the user to compute rewards and prove their correctness?) and from the reward batching and off-chain verification. Besides performance, on-chain costs, decentralization, complexity and moving parts of the protocol are also important metrics to consider.

Gonçalo: Some examples of research questions we keep working on:

- How to build a decentralized ad reward protocol where Brave, users and advertisers can verify that the protocol is running correctly? How to do it in a privacy-preserving manner? (THEMIS is an attempt at answering these questions, by the way.)

- How to distribute Brave assets (e.g., ads catalog, Brave today content, etc.) in a privacy preserving way, having scalability in mind and while reducing bandwidth overhead?

- How can we leverage DeFi and other web3 technologies in the browser? How could BAT improve the web3 experience of the Brave users?

- How to improve privacy-preserving ad targeting on the client?

- How to detect and block fraud given the privacy guarantees we provide to the users?

These are just a sample. 🙂

Gonçalo: Absolutely! The cherry on the cake for me is that working on privacy projects is technically challenging and we are constantly thrown at problems that have hard constraints and tradeoffs. This inevitably forces us to work cool and green technology, which is very intellectually rewarding IMO!