Devconnect ARG - Nogal Room Red Pavilion

Perfect. Almost all of you. So you'll should be very familiar with mappings. Um and mapping is essentially you you map between like this in the left is how all ERC20 contracts work, right? You have a mapping between an address and a balance.

In the FHRC20 use case, the balance is encrypted. Technically, we can also decrypt the address. The problem is that if I transfer if you know Alice transfers to Bob some encrypted tokens their balance changes and so while we don't see what actually changed under in the underlying cipher text because it's encrypted obviously we can still see that two records in the mapping changed and even if the key in the mapping is encrypted I can over time analyze this and understand and like build you know pattern graphs and like I can essentially over time leak the entire thing and understand who is communicating with whom. Um so this is not perfect. We need to protect access pattern to this um u uh storage system as well for anonymity.

Um so what we've started uh uh experimenting with is a bucketing system. Now a bucketing system is a sort of I I imagine well maybe you've heard about ORAM. ORM stands for oblivious RAM random access uh memory. Essentially it means that you obiscate your access pattern to the collections of data. So to an outside looker it won't be uh an outside looker won't be able to tell what record you are reading and what record you are writing.

Okay, this is ORAM. This is the uh perfect solution to kind of obfuscate storage access. The problem with ORAM and there are a lot of um implementations and a lot of research on that topic, but ORM usually is too heavy in the context of blockchains, right? It's too hard to implement efficiently. And so you have to introduce some relaxations and for the context specifically of token transfers, we believe that a bucketing system goes a really long way to provide essentially almost all of the properties that you need.

So what we essentially what we do is that we take um this um um you know storage mapping that we showed before and we access we we um use this as an entire bucket. Meaning that if we split our mapping into multiple buckets, every bucket has to change um to get like in a in a bulk, right? We can't only change one record in the b in the in the bucket because this is what we had before. If we want to change anything in the bucket, we actually have to change the entire bucket. So, how does it actually work?

And for uh simplification, let's think of only one single bucket. So what we do and what actually FH lets us do uh fairly easily is that we have a collection of encrypted addresses and encrypted amount. If we want to change an address in this bucket, we actually want to um to change two two records in this bucket. We want to for example if Alice sends to Bob we want to in uh decrease Alice's balance and we want to decrease Bob's address but we also want to change all the other balances. So what we actually do in practice is that we add zero to all the other balances and by this method we actually like reshuffle all of the cipher texts.

So essentially to an outside looker we iterate over the entire thing. We change all the balances and to an outside looker it's indistinguishable which balances were actually updated. Okay. So in the case that we have only a single bucket in the entire system this essentially gives you perfect anonymity because you cannot distinguish between any of the participants of the protocol. Right?

But this is very poorly this po scales very poorly right because the more participants that we'll have the more iterations over this uh storage uh um uh primitive will need and the gra the gas will increase and so on. So this is a problem. So what we'll actually do instead is that we'll have multiple buckets. The buckets will be of constant size. It will be configurable.

uh it's actually a trade-off between performance and uh the quality or privacy guarantees of the the anonymity and the protocol. And so if Alice and Bob are actually in two different buckets, the only thing that will be visible to the outside is that two buckets in the system were touched. We don't know if they're changed. We don't know if the transaction succeeded or not. We only know that two addresses in two different buckets were communicating with each other, but we don't actually know what happened or we don't know which exact addresses um uh were touched in the in the internally in the bucket.

How it actually looks like in the code. Um so if you are familiar with multiplexers, this should this should be uh fairly understandable to you. So we have the select method which essentially um uh well we can skip straight to the simpler version where you check if there like you iterate over the entire bucket. You have as you see uh receiver at the top of the function. The receiver is actually encrypted address.

All of the addresses in the bucket are encrypted as well. And then you go address by address and you compare between them. And the comparison actually gives you a boolean, a zero or a one. And you take this boolean and you multiply it by the value. So that for every record, you either add zero because you multiply it by zero because they're they're they're not uh comparable or you actually adding um yeah adding the value.

In this case, you need to also do the other side of the sub subtraction as well. Uh obviously, but this is essentially how it works. Fairly simple. This is here to demonstrate that actually writing with FHE in Solidity is essentially quite simple. Uh you don't need to like build special circuits or anything like that.

So uh it's still solidity. It's still composable with other uh protocols. So that's pretty cool. Um yeah, so what did we ended up with? uh we essentially ended up with a system that looks very much like very much like ERC20s as we know them but they're encrypted.

We also received some uh degree of anonymity and so again this is like configurable the the larger the buckets the performance uh we will hurt performance a little bit but then the anonymity set will grow between the between the or like for every participant. Um the only thing that is known to the outside is that two buckets have communicated or touched in the protocol but we don't know which record inside the bucket. Um and uh this again very similar to the other protocols uh with the rail guns and so on that mainly helps the receiver privacy and we still have this problem of who pays for the gas for the transaction right so here we can just adapt to other solutions of like using um uh in or sorry private relay networks and so on. So this is essentially like a problem that uh you know we can we can just it's essentially solved in a way can be definitely can be improved but uh we we we have a solution for this problem. Now to the elephant of the room and you know uh again as was said before me FH is slow and so on.

So it's actually more of a stigma uh these days and this you can see what we actually managed to achieve with this PC. So we ran the PC on CPUs and GPUs. We essentially got um a performance of one TPS with a bucket size of 100. So that's not perfect, but that's not too bad. I would argue that I'm way more comfortable um or I would argue that some people would much rather um using actual MetaMask and like you know the existing tools for their transaction while being indistinguishable with 100 other or 99 other users of the protocol which is not bad at all.

But as you see the problem is that as you stack uh hardware on top of each other we actually get diminishing returns. So it's it's not improving the performance linearly and we kind of get this logarithmic graph of um of the the size of the bucket that I can actually uh achieve. And this by the way the size size of the bucket and the TPS is interchangeable. So if I have you know a size of 100 with one TPS I can actually achieve 10 TPS with 10 with a size of 10 with a bucket size of 10. So again this uh does not scale very well and the question is can we scale this better and what I'm about to show you in the next slide is actually we showcased this for the first time.

So we are uh fairly excited about this or rather very excited about this. uh we are building um in Phoenix a new novel FH scheme where our goal is to reach Visa level performance and throughput right we we saw the graphs I don't know if you guys saw like um comparisons between like Visa and X42 like we we're seeing like uh the the the blockchain uh throughut kind of increases over Visa already but Visa uh essentially gets uh 10,000 transactions a second more or less and uh we want to reach the same. This is very rough numbers very like you know PC level but essentially um we get somewhere in the realm of uh 1,00x throughput from the current state-of-the-art. Um the scheme is very good at arithmetics and very highly paral parallelizable. So it's a very good match for a use case like um like uh uh transactions and um yeah this is something that we're very excited about and you know more details will uh will come next year.

We hope to release a paper soon and ob obviously integrated into our core processor. Um this is essentially it. Uh we have a few links here. Uh if you're builders and you're interested, we can uh you can keep in touch in our uh blog and documentation. Uh you can follow us on Twitter and if you guys have any question, I'm out of time, but you can catch me afterwards.

Uh and I'll be happy to talk. Thank you very much. Hello. Uh slide is a fifthearium. Okay.

Um nice to meet you guys. My name is Eugene. Um I haven't been in crypto since can you hear me right? uh since 2018 and I started by running a fund at the time as a CTO and co-founder of the crypto fund and we invested many great project like you guys and then we recently won a Sony's incubation program last year and now we are um moving into this FHE furtherium using our um web to proven tax. So what Fiserium is?

Um so Foreum is a like kind of web three initiative from the crypto lab which has been in FHE for web 2 for last seven years and we are bringing this uh tax tech named CKKS um into Ethereum. So we are not like so I think the this like general FH co-processor uh for Ethereum and blockchain I think the Java and Fenix are already doing very well. So we are not getting into that path. We are more like we are trying to find what would be the best fit for our FH stacks. So some directions like we are exploring right now is like one is universal digital passport for uh running on Ethereum.

Another is a federated AML risk scoring and also private payment for uh institutional um uh finance. So these are more like when you see the first two examples like a digital passport and AML risk scoring these are more like um AI and vector operations and then we are bringing we can bring that to onchain. So privacy is a core to ethereum and we have a more to improve so we are working on that or together here. So onchain we have developed the GK for last seven eight years and now we have some more like like we have some like trust assumption of chain data and computation. So uh we still trust some centralized data silo and we also have some trust on the regulator and audit not purely on mass.

So yeah so yeah so actually I prepared this slides for more like a novice people but I don't need to explain to you guys I think but um major difference between GK and FA is uh you know so GK proves the ver like is like verifiability but um when you first generate this proof uh you have to trust the com the computer that generate the proof so uh we can protect the data side. So um yeah, so I'm going to skip that. So a little more about the our text tech CKKS it's uh so we have been working on web two side and we are we started with the approximate floating number FH then uh last couple of years we made a very uh great improvement on the discrete um numbers FH2. So we are very strong at the privacy preserving AI stack and also we are very great at scaling arithmetics. So uh for example when you train AI model and then when you run inference on AI model we can run it with the encrypted features and this vectorz and then SIMD the single instruction multiple data friendly APIs are already used in production.

So we have a working demo that we have tuned llama AI model and we trained it privately and then we inference it and then we also did some rag private rag demo on encrypted data. Um so it it's a little so the taurus f that like jama and phoenix are working on that scheme is very different from our tech scheme that cks are doing right now. So it has uh its own pros and cons and we are more strong at vector operation. So who are using our tax tech right now? So we have been uh de deployed and validated by South Korean uh military secure analytics and also some enterprises like a Samsung and IBM and to is like a VMO in South Korea.

So uh we are using it we have been used by them. So how it's working is so when you see the data uh previously like when you even though when you even though you encrypt the vector data when you query it you have to decrypt the vector and then do the searching but from the CKS uh the query is encrypted as well. So the wizard is also encrypted. So it's a fully encrypted, fully uh private. I'm going to skip this.

We all understand this. So the point of this slide is we can use both GK and FH so that we can complement each other as the Phoenix already mentioned. So one example that we are thinking right now is the KYC reality. Though currently though we when we do the KYC we have to trust or we we have to collect the full KYC data first and then retain it for years because government agency and enforcing agencies they require to keep the original data for the auditability. When accident happens they will come and look at the original data.

GK is very great technology to prove that this person already passed the KYC but in case of the XNET you still need the original data then that's where Ferarion can come comes in so or data is encrypted in the database so only when it's required the data is decrypted or data can be evaluated in a in our FH circuit so that this person uh original data is there and then we have done correctly the the KYC. So how it works is the person um first send the KYC data. So the KYC issuer can do some like they um do the verification of the KYC data and then they verify and sign and store the data to our database. that we hold or encrypted um some identity information and also net worth income address and plus some signature. So we encrypt we store the encrypted data as a escrow and we send encrypted credential to the hoarder.

So the user's wallet hold encrypted credential. Then let when the user uses that KYC proof to some D5 protocol or other use cases then they the protocol want to verify the KYC for let's say institutional finance or other cases then it first request hey you you should prove that your net worth is more than 1 million then it fetches the user fetches data from our data as crow and then fetch the encrypted data and then decrypt from their wallet so from the client side. So still we don't know any row data from our side only user can decrypt it and then generate the GK proof from user device or they can also use a TE. So um any so they can use other text tag for keeping their privacy. Then the public input is threshold that the protocol required and the private input is actual net worth and the proof is their net worth is uh more than threshold.

Then send that proof proof to protocol. Then the protocol uh verify the proof on chain then they grant the access to their protocol. So once they proved their KYC on Ethereum first then it can be used for multiple pro protocols. So um just pro uh verify once on Ethereum and multiple use cases. So we are exploring this idea about privacy preserving passport oops yeah passport anchored on Ethereum and underlying identity and KYC attributes are stored as a FH encrypted vector.

So you prove once and reuse safely and depth see the risk scores and attribute never PII. So it can be compliant and or private and auditable. So in this case the furium as a confidential we work as a confidential data and computation layer. So uh we can generate multi keys like for example one is user key that's always needed and some regulator key and all the arbitrator key in case of the some claims and dispute and we store the encrypted data and access policy and the regulator in only in the emergency access like uh when they uh deem that there's an accident then they require uh to decrypt the original data But uh users should agree with it or in like there we have a more design on this time log and other more details but I will skip it this time. Another case we are also seeking is a federated AML on encrypted feature.

So more institutions the traditional in institution coming into the web three and that they hold a lot of bitcoin and ethereum and other digital asset they re they want to be safer when they store their data but you know we all see a lot of accidents happening every year right so a lot of hackings and they but the problem is each institutions they have their own data they cannot share the data each other because of this regulation. So, Coinbase only sees their own transaction. If it's a suspicious then they report to the finen. So, this kind of um schemes are implemented for every country and the criminal moves to the Binance then they cannot see it right then from the Binance they cannot see the Coinbase data or other exchange data. So there's no context from other than the Binance database.

So they see oh it should be okay but they approve then boom there's an accident. So that's the how current uh AML and then hacking or like a attacks are working. So if what if these institutions can cooperate and work together. So they share the data together but not the row data but encrypted data. So they cannot see the row data but share the data within encrypted way and then they can run they can run the shared machine learning model to detect better detect the fraud learned actions.

Then this uh fisorium AML scoring model can return the risk score to all participating entities then they can better detect the fraudulent actions. So this uh encrypted MR model like it can be logistic uh regressions or other model. So we are very strong at this kind of vectorized operation very fast and scalable and it can run on both CPU and GPU. When you add more GPU it's more scalable. So when a high risk detected then it's not it's notifying to every institution.

So maybe the institution can like freeze that fund or they can um work on their own prevention um actions. So the problem was every custodians, exchanges and institutions they run their AML model in isolation with only partial data but we enable uh collaboration uh without revealing PIA or row data. So they can run the shared AML model and yeah we are very strong at this case. uh why was it wasn't it was not available before why it's available right now uh because this FAC bootstrapping was very heavy and it's very costly action in FAC um operations and ftherum was is a very made a very great improvement in this actions boot and bootstrapping and also we made a very good um improvement on the SIMD threat packing and also GPU acceleration. So now our performance is now practical.

So until last year it was like a very limited limited practical level but this year also we made another great improvement and now we believe we can we are prepared to be in the market. So the benchmarks so the configurations are like something like so it's some specific demo benchmarks that we have done before. So when you run this bootstrapping uh on one GPU one thread it took like 6.7 seconds with a 16 thread 1.1 second but one GPU with the RTX 1590 which cost only $2,000.

It's not like H100. H100 is like 20 or $30,000 in this market, but this one is a very cheap one. So, but in this chip GPU, we achieved 14 millisecond for one bootstrapping. And one example is uh you know what the to which is a financial institutions in South Korea. Uh we they use the this face ID payment.

So, it should be very secure. is already running and this case biometric searches one to n authentication against the 65k database search it took 25 millisecond for with using one GPU the RTX 5090 and against the 2.6 six million database it took one second. Uh so it can be scalable with a multiple GPU and so think about if we add 10 GPU or 100 GPU as like succinct or other GK provers they are running huge size of the GPU machines. So if we scale like that then it can be way faster.

So this is another performance benchmark. So we had this uh benchmark in our paper against the open FH. So basically you know the we compared the addition and multiplication and bootstrap. So uh it has a different numbers uh when we use a CPU and GPU but the best benchmark is at the right size. Um so now it's uh like multiplication and addition are in microscond level.

Um we don't say we are perfect at this moment. Uh we are still improving our the constraints that so when we like expanding into the web three and ethereum uh domain then there are still things that we have to consider like a first is a more performance and better performance. The second is the key management and trust. So Jamaics already um covered that so I'm going to skip it. But you know the decryption key management is a very important and also developer UX.

So um we are thinking about what would be the best developer UX uh developer experience uh for using the CKKS. So we are like eventually we can be generic uh in the future but when we first start uh we want to be focusing on very specific use cases that where our CK stack can be really strong and perfect at so I believe some a AI decentralized AI initiatives can be our good example. So we want to co-work and collaborate with the Ethereum community. So especially people here. So our tag has a our own pros and cons and we are just starting in this space.

So um we have a better tested FHS tag in web two but you know creating uh gener making the Ethereum and web3 product is a little different story. So we are still exploring and we we are looking for some um teams uh to cork on this together. So, Ethereum of course and some infra teams or layer 2 and also privacy focused project uh with a uh application layer or uh infra layer. We are welcome to cork. So, please join us.

It's a Google form. So you can join and then you can hear um faster than others about how we improve and then what would be the the latest status of of CKKS and Varium. Thank you. [applause] Hello everyone. Yeah, my name is Gorgan and today I will talk about uh how we at our team trying to build F more practical for developers and bring it to production.

As all of us knows that privacy is one of the important issue that we have in blockchain. We solved almost all significant part during the last decades and privacy looks like the main issue for the blockchain [clears throat] and the FHE as fully work encryption looks like the great technology with great potential that can solve this problem and since the beginning uh different schemes were developed. This is only just the main directions, three families of the scheme and which is important to understand that there is no universal skin for everything and uh when you want to have scalability you can use something like CKS BGV if you need to have token transfers TF family few family maybe better but all of these families and all of these schemes has limitations and advantages. the same about libraries. We have different FH libraries with different licenses with different models, different languages etc.

And uh the challenges that we have today I groped it in three main parts. The first one is efficiency and uh to be honest I believe that issue with performance will be solved in a couple of years and uh at least right now we already have great progress FH is more than enough for a lot of applications but if we talk about some general computations FHE more slow than operations so incript plain text the second one for me looks like the most difficult hard because approach using global FH keys that we see when we try to build some encrypted private uh private shared state based on very weak security assumption and uh decrease security quantum security of a ph to the security of the threshold protocol at the same time if we you don't need to have private shared state and if you don't need join computations you can eliminate this factor. Another thing that was also mentioned in the previous talk, the lack of developers ecosystem, the lack of what's we called application layer. This is user experience for developers. And I will focus today on the third part and explain how we are solving it.

This is the general FH stack for developers and not only for developers how it looks like. Developers working on the first two layers. Usually developers may work with transpiler or compilers or directly with libraries. And the problem that current compilers we can't say that compilers can help a lot for developers because the main issue for developers is the limited basis of operation that you have from FHE scheme side and compilers will not solve this issue for you and to understand better the problem I like to consider the case based on neural network. Let's consider that we have some general neural network and we want to have uh privacy preserving inference and all computations significant part of the computations usually happens in neurons the same for all neurons and uh we have plain [snorts] text input in the open way and we want to have we want to have opportunity to put encrypted input in this case we just need to change the computation inside neuron which usually looks like this two parts uh weight at sum at the first step and sum evaluation function activation function as the second step.

And if we change the input to encrypted data, we will face as a developer, we will face the issue with the second part because it will not clear how to relate functions like ReLU when you have very limited biases when you can do only addition and multiplication and compilers will not help to you because compilers will probably simplify the writing the code and communication with the library but will not provide your opportunity to relate this kind of function and developers will work as I said on the cryptography libraries layer or transpiler compilers layer and the way how you can try to solve it usually can be grouped in two ways three ways you can try to build some polinomial approximations you can try to play with different packing technique and add more informations or you can play what's called functional bootstrapping sometimes also called programmable bootstrapping but uh initially what's really needed for developers it's some kind of black box that will evaluate what we need in this case just blackbox where we can provide encrypted input and get result of the evaluation the function relu and we need a lot of these kind of components we call it of components and we need a lot of these components to be able to provide good experience to build applications if we have these components we can just consider all of each applications like some kind of circuit which consist of different components and these components may be with different schemes you can just run computation over some part of your logic with one FH scheme then make scheme switching use different schemes and the scheme I uh mentioned like bridge that can be used to make different scheme switching etc and this is the layer that missed in my opinion so it's the layer between cryptography libraries and the developers tooling like compilers is the layers of components and the first thing we do we build this layer And we do it through our platform which is called firmize benchmarking and challenges platform where everyone can try to contribute with components. We recently published the first part of components is the joint work of strong community state-of-the-art components with great performance. It's published. You can find it uh source code also available. Another interesting thing about execution part okay we built execution uh we built developers tool but how to launch evaluation and again the problem that even if you can use GPU even if you can use async you don't have some universal execution layer and for some components for some execution uh for some uh execution logic GPU may be the good choice for another one CPU may be more than enough And um in our vision the best choice to provide execution layer is some kind of heterogeneous network of different actors with different capabilities to evaluate different functions.

Some actors may be focused on evaluation some specific components. At the same time you may choose another actor which will provide better performance for another components. And in our vision it should be looks like this. You have the application which consists of different components and you have the network of heterogeneous actors with some kind of ver verification on top of it that can evaluate components and your application. We publish this work uh call it the centralized f computer uh it's published uh opensourced and general computation looks like this.

You have application that on orchestration layer uh presented as the graph and you have different two layers of actors main actors and fallback actors which commit communicate with each others that launch and evaluate your logic and in general the stack for developers and for each ecosystem. uh in our vision looks like this. At least we are building this kind of stack. On the first level, you have developers tools like compiler. You have components layer, cryptography layer and mass layer and execution layer.

And our team is working on three of them. We are working on execution layer at least to provide orchestration for it. And we built two of the first layers. On top of it, we built different applications. uh I didn't put in the slide but the recent work regarding PI that we have allows us currently to make P request to Ethereum network without communication.

So it's not interactive protocol but we can uh do it with some kind of sharding and do request for encrypted address and get result about encrypted addresses in this model with less than the five seconds. So in the database you have uh hundreds of million address and you can just get information in just some kind of 5 seconds. We will publish it a little bit later with more details. And that's it. Uh thank you for your attention and any question if you have [applause] Thank you.

Yeah. [clears throat]

I was super fast. Um a question. So you showed the FH computer with the different uh different uh computations for different parts of of a you know. So my question would be do you see um different components running also different schemes and if so like specialized schemes for each u component and if so how easy it is to actually scheme switch between them and how latency does that?

Yeah good question thank you. Schemic generally is the some kind of bottleneck. It's not too easy right now. But uh in the compiler infrastructure that we built based on uh if you know MLA stack, you have some intermediate layer that allows you to make this scheming more easily. But it's still hard part.

It's just uh but it's not needed for most of use cases. It's just the vision for the for the next future when if you when you will have new schemes etc. Yeah, thank you.

[music]

Okay. Can you hear me?

Yeah. Um okay so um my name is Mika and u I will talk about um what could be some lessons from uh ZKPS uh for for FHE so to to speed up to help speed up the adoption of uh FH um because the thing is uh the evolution of Zikaps was was really fast. So um the progress in the research of zero knowledge proofs has been remarkable but perhaps even more impressive is uh the the adoption of of this research in in web 3. And I think there might be no no other industry actually where where the research comes so quickly into the industry as it is uh with ZKPs in in web 3. Just just for example, these two papers uh uh grow 16 and plunk which you all know the these two papers are kind of uh household names in in in web 3 which is really surprising and uh fascinating to me because it's very high-end research which is yeah now part of the community.

Um so but um yeah what about ZKPS uh before web 3? Um even before I joined uh before I started working uh in in web 3, I was um interested uh by the concept of anonymous credentials and there was uh for example this paper by young kamish and analysis about anonymous credentials and really nice paper and already in 2001 so it's 25 years old um and it was not only a paper with a nice idea It was also that uh IBM actually wanted to make a product out of it. So they they uh built identity mixer which is a cryptographic protocol uh suite for privacy preserving a authentication which should be very much familiar to all of us but there was no adoption basically. Uh so I was thinking a bit uh what might be the reasons that uh the adoption of ZKPs in the last years uh was so rapid in in web three and I think the the main three reasons are actually uh the shift to general purpose proofs. uh then we of course have now blockchain as a deployment layer and also which is I guess very important is is the culture of web 3 uh and its openness.

Um so the first one the shift to general purpose proofs. So like the one that I mentioned u by Kamishanskaya was uh very specific proof of about anonymous credentials while later growth system and and plong basically transformed zero knowledge proofs uh from a toolkit for identity to to general purpose uh proofs and this unlocked many possibilities like uh rollups zkvms and all kind of other things. Uh yeah. So what about um general purpose FHE? Is this a problem for FHE?

I I would say no because uh we already have different schemes there. So we have integer FHE for integer arithmetic. We have approximate FHE schemes which are very suitable for machine learning and AI. And we also have scheme switching. So we can for example uh for example the number comparison might be difficult to achieve for CKKS but but you can switch to to TFHE for example and do the comparison there uh and then switch back to CKKS.

So I think that's not a problem for FHE. Um then the the second reason for this fast adoption uh blockchain as a deployment layer um of course this kind that's kind of the same because um yeah with blockchain suddenly there was a real test bed where new cryptographic ideas could be deployed almost immediately but this is uh pretty much the same for FH as well right and this created an ecosystem where fast prototypes and shared libraries uh could emerge almost overnight and also One important important thing was that snarks turned out to be a perfect match for blockchain because they are short and can be checked quickly on chain. So for FHE, yeah, it's it's similar. We have a deployment test bed uh and a live adversarial environment that forces real engineering uh and also I think new research is actually happen happening in public now also in FHE context. However, it's it's true that the situation is a bit uh different um considering that FH is not a perfect match for blockchain because of the large cipher texts uh which mean um large gas costs and uh latency because of bootstrapping but people found workarounds uh for this like co-processors as we heard so uh we that's kind of solved as well.

Um but what about the the culture of of web 3? So when I started working uh at EF like in 21 I was we we were working on ZKVM and uh what was really surprising to me was that um we openly collaborated with with other companies like scroll and looping. Um of course the the common goal was was clear. We wanted we all wanted to build a robust layer 2 solution for Ethereum. But still for for most industries I think you you would expect competition uh and and secrecy not engineers from different organizations actually openly exchanging ideas and debugging uh each other's code.

Um and also from from the very beginning there were uh there were uh open- source libraries in in web free like uh Lipnark, Belman, uh Arcworks, Halo 2 and um there was a great community behind this uh be behind these libraries and most of these libraries were actually uh permissively licensed. uh there were some projects which were closed source or or perhaps they were not permissively licensed but uh I think they are mostly gone so this is something I would say um then also there were there are various platforms which helped with the abduction a lot uh for example the zero knowledge podcast then the zk heck hack also for example a nice thing from zero x park spark is zk buck tracker where the common vulnerabilities uh found in the libraries are are published so the developers can be uh attentive to these kind of things. Um and also uh I think people realized from from the very beginning that uh they need to provide uh DS this D this DSLs and uh compilers and uh in intermediate representation languages because for for like from the beginning we were writing uh A1CS constraints directly and custom constraint gadgets but this is kind of difficult for people that are not uh cryptographers. So in um in Zikaps a lot of uh this new intermediate languages were built and the moment this happened actually uh other normal kind of developers uh started to write ZK programs and uh proof of concepts were were built fast and and new teams were entering the field. Um so what about um this intermediate languages for for FHE?

I think that's even more important uh for FHE than for ZKP and that's actually also what what Gorgan was talking about uh because FHE is in a way even more complex than uh ZKP because you need to consider parameters like noise growth modulus switching uh scheme specific optimizations and and and much more actually. So if you just have a look at at a simple number comparison. So if if you have encrypted two numbers and you you would like to homorphically compare whether they are the same this should be kind of simple right it's very simple operation. So you have uh encryption of x1 encryption of x2 and just homorphically compute whether uh encryption uh whether x1 is the same as x2. uh but it turns out this is very difficult actually and and there are many many parameters to be configured to to uh to enable you to compute this.

Uh so in general the idea is you you subtract one number from the other compute x1 minus x2 and then you can use bootstrapping functional bootstrapping for example tf bootstrapping uh to compute it because bootstrapping is not only uh for reducing the error is also for uh for the evaluation of a function and this comes pretty much for free right uh but there is a catch this actually works only for very small numbers for like you can directly use TFH bootstrapping only for numbers that are smaller than 16 and of course we there are many use cases which require bigger numbers. So of course uh and and so if uh when x1 minus x2 is not small then then you can you need to actually do the composition into some base b then you need to iteratively use homamorphic floor function and then for each function you actually call two or three bootstrapping uh operations. So and and and obviously the uh the the performance goes up a lot. So this is if you this is the log p is the uh size of the plain text. So the size of the numbers that is supported how big x1 - x2 can be.

Uh so if you if you increase it then the performance obviously goes down because of the number of bootstrappings. Uh but there are many other parameters involved which needs to be conf which needs to be configured like the uh cipher text uh space the base that you are using for the compositions and all kind of uh these kind of things and um also for example uh that's that's not the only thing that you need to configure. You only need to configure beta which is bootstrapping noise and beta 1 which is the error of the input cipher text and so and uh based on this you compute actually the cipher text space. So uh q uh you compute it using by this formula. So logarithm of q is logarithm of p plus logarithm beta plus beta 1 + 1.

And the bigger the queue is, the more bootstrappings are needed. Uh because the complexity scales linearly with with Q. Um what's more uh you need to configure the probability of an error. So for example, these schemes usually are configured to have the probability of an error uh smaller than two to the 30 to the minus uh 32. But for blockchain, this is not enough because of the number operations.

you need to have this probability much lower. So you need to configure actually uh beta differently because beta is u so error is uh which brings noise to the cipher text is zampled from gausian distribution which is kind of this kind of uh graph and the bigger the beta is here the less probable is that you will sample the error. Um so uh when when you you need if you have a use case which where you need uh the smaller probability of an error then you need to configure for example different beta which needs to be large and that means the cipher text will uh the cipher text space will be large uh and also the computations will be slower. Then also you need to compute you need to configure the security level for example because the cipher text is computed cipher text is computed as message m scaled by some uh k plus the inner product of two vectors a and s plus some uh noise e and um the security level is basically basically depends on on the on the dimension of these two vectors. So that's another thing to be considered and also different methods different schemes actually have their own merits and and the selection which one to choose is actually uh application dependent u and that was just for simple number comparison.

So if you want to go to arbitrary evaluation evaluation it's even more complex. So you have different schemes uh and some are better when the precision reaches 10 bits for example. Some do not support multiplications between cipher texts. Some are better suited for large larger number of evaluations. So uh for for somebody who's not cryptographer who is not f expert it's kind of impossible to set up all these kind of uh parameters.

So I think if um if we need uh to convince users to start playing with uh with FHE to adopt FHE uh I think we need to engage the community and um and this can be done by the following things by by having approachable DSLs and uh intermediate representation languages that actually hide cryptographic details uh and let developers write normal code. I think there needs to be playful sandboxes, sandboxes and and interactive demos and uh there there needs to be high level compilers that translate for example uh Python and ML AI workflows into efficient FH circuits. Uh and we we need to have benchmarking tools and visualizers so developers can see how parameters actually affect the noise and cost and all other things. Um so in this way I think uh FHE can also become kind of a household name as as ZKP is today. I think it's important to do this.

Um so yeah that that's all from from my side. No questions.

Yeah.

How would you what would be your message to companies maybe like

what would be your message to a company maybe like a crypto lab for example that we heard from on how to engage with the Ethereum Foundation to accomplish some of the goals that you um set forth in in the in the last slide. Yeah, I already told Eugene what I think and this is actually open source your libraries under permissive licenses and engage the community because one one other thing that was really strange um I mean kind of surprising when I before I was working in web 3 uh still on this kind of communist Lissian skaya kind of proofs um I was talking with a researcher from from Vienna uh and I I said to him that I think everything should be open source but and he said come on if it will be open source nobody will actually read it who who reads the code nobody nobody actually spends time on this and but and and this was like 10 years ago and now we see in web 3 that's actually not the case people people audit the code read the code contribute to the project so I think that's important

thank Um Jay uh how much of a role do patents play in sort of inhibiting the growth of FG in the ecosystem?

Sorry,

how much of a role do patents in FG systems play uh in inhibiting the growth of adoption of FG in the web3 ecosystem?

So I I didn't get it. Can you say it's so uh Patents.

Patents. Patents.

Patent. Ah, patents.

Ah, right. Right.

Uh, so what what about patents? like do you do you I mean how much of role do they play in sort of inhibiting the you know the adoption of u these these systems generally

that's actually one of the problems this scheme how many skaya was actually patented patented

and this I guess that's that's not the way to go because you hinder the collaboration and and the the adoption of I'm not familiar with it. Okay, thank you. [applause] Yeah. Watch this. I think you need to select the screen you wanted to mirror.

Yeah.

Screen or window.

It is screen. Wait, I'm not able to Do you have

Oh, I see. Okay, fine. I'll do this. Hello. Hello.

Um uh uh today I'll be talking about Phantom, how it works. First, I'll introduce Phantom, what Phantom is, and u then I'll be talking about how it works, performance, and so on and so forth. And I'm Jan Mai. I work for a research organization called Phantom Zone, and the website is Phantom Zone. Um, okay.

Wait, there you go. Uh, what is Phantom? Well, the way I like like to think about Phantom is that it's a it's a FG virtual machine built using FG circuits and it can execute encrypted programs on encrypted inputs. Okay. So, you can take a programs for someone else.

So, as a developer, I can write a program on my laptop. I can encrypt it. I'll tell you what encryption is like you know just just take the binary encrypt it and then you can give it to a beefy server. Now this beefy server can execute the encrypted program on encrypted inputs coming from anyone. Okay and I'll get into the details of what this means and first why develop phantom in the first place.

Well Phantom is a virtual machine. You know since it's a virtual machine it can execute any arbitrary program. So you're not limited to a circuit model. It can have uh input dependent execution. So you can you know the way a normal virtual machine works it can uh there's no exponential increase with the branching.

So normally in circuit model if you have multiple if else like nested falls you'll have to pay for each and every branch that the nested else uh executes. In this case, you just you you just put a program counter and that's it. So you do not have to pay for exponential increase with um every nested else. Um you also do not need to fortunately make your program constant in runtime because it's it's no more a circuit model. It's a virtual machine.

So it works like a virtual machine. Um the second thing is that it's easy to work with. So in uh in phantom you simply write your program as a simple rust program as you usually would. You do not have to think about what is a circuit, what is f and so on and so forth. You simply write your rest program as it is in rust and that's it.

Phantom would execute it. One consequence of building a VM, it was I we didn't realize it when we was we were starting with this. Uh, one pretty good consequence of building a VM is that you can write programs and since you encrypted the programs, you can have programs with hidden constants, hidden routines and uh what else? Um, and and instructions as well. So even the you know you can have a function in your program that itself is hidden from somewhere else.

So probably what you can do is like you can have a program that um would uh have a hidden secret and the hidden secret would sign things for you if some particular condition is satisfied. Um okay so how to use phantom? Well to do that uh before that you know you just write your rest program as it is and that's it. like all you have to do to use phantom is like just write your rest program and that is it. But in this case I'm I'm I'm being a bit uh optimistic here because you have to account for the performance bottleneck of f and that would limit the type of programs that you can write but if f was very fast you can just you know write any program that you wish and that's it.

Um and to make this more concrete I would uh I would I would show an example. Okay. Okay, so let's take an example. The goal for the example is that let's just write u OTC code generation program. What does OTC mean?

OTC is uh over the counter tests that would facilitate bigger trades for you. For example, if you're a big whale, you want to trade I don't know BTC to USD. You cannot go to centralized exchange or even unis swap. you all you have what you have to do is like contact uh OTC desk tell them you want to trade from BTC to USD and they would facilitate trade for you. The goal that we want to have uh the goal that we have is that we want to facilitate OTC trades or at least OTC code generation so the desk can quote you what the trade would look like with encrypted intents.

So my trade intent of going from BTC to USD is encrypted. Okay, how does it look like? So the client sends an encrypted intent to the trade to trade BTC to USD pair and the OTC D executes their code generation algorithm on the encrypted intent and sends it back. Okay. And now I'll be showing you a simple example of how to code this out.

I have already coded it out so that I don't waste my time over here and not run into bugs. But uh I'll I'll show you uh what the program looks like. And to be you know to be more real the program actually sort of like tries to simulate what an OTCX would really do. So for example the cotic algorithm would take multiple variables. For example it can take the client profile for client dependent rates.

So if if the if the client is a prime institution then they the the OTC desk would want would want to offer better rates to them. Um the OTC code algorithm would also adjust for the size. So for example, if the size of the trade is very large, it can move the market and hence you'll have to account for the spread. Um the OTC desk would also want to provide volume discounts. You know, just be nice with the customer if the if the volume is large and if the customer is a prime customer.

Cool. So how do we code this out? Which is why I have an example. Okay. Okay, so this is the structure of uh how a phantom program is structured.

Okay, so you have a host rate host crate and you have a guest crate. Guest crate is where you write your phantom program which is essentially encrypted afterwards. Um so I'll go to the guest crate and I've already written the program for OTC code generation here. Um the main function to focus on is this particular function as and as you can see this this particular function is simple rust you know are you guys able to see this prop oh you're able to see this properly correct um do you want me to sort of increase the font size

cool okay so as you can see you're simply writing Rust programs here nothing else and this particular main function essentially does what I described fore it takes in the code sorry it takes in the market order which is the input and this is you know at the moment it's not that developer friendly in the sense like the the things you need to do but this is the way to read the input in the VM u it takes the market order uh which includes the client information the trade and the market data market data is like what is the market what is the volat volatility of BTC USD pair and so on and so forth um and then it first computes the base spread And the base spread is is another function. Okay. So I'll go to the function. The base spread simply checks whether the whether the client is either institutional, retail or prime and then returns the base spread as that. And then it computes the and then and then it adjusts the base spread as the size which is why we call this particular function.

And uh as you can see this particular function sort of like takes the size of the trade computes how big of a volume it is compared to the volume traded in the spare for the past 24 hours and then as per that sort of returns a size factor and size factor would change the base spread. You do not need to understand you know how technic like why this is done but I'm just trying to show you that uh if you were writing this OTC program yourself as an OTC desk that's all you have to do you just have to take your Python code and put it in Rust um and then there's another function called volume discount to give you know uh discount based on volumes and this is this function so if you're a prime instit prime or an institutional player or like a prime or institutional client um you would get get a volume discount if your volume is large enough and then you calculate the final spread and then you convert that to USD and then you give the ask price and the bid price again the ask price and the best price which is the returned value is encrypted and it is it is sent back to the client make sense surprisingly u you would notice that all of this is done on f32 we not using you know integer arithmetic here we're using floating points here and we had we did not develop special routines for floating points. It just like the compiler works out of the box. We just simply leveraging rust to risk 5 compiler and all all we had to do was build a circuit for the virtual machine of risk 5 for a particular instruction set. Okay.

And everything works out of the box. You do not have to care about the thing that we have Mia was mentioning before. You do not have to care about noise growth. You do not have to care about failure probability. All of that is taken care by fixing a particular circuit which is the VM circuit and everything works out of the box with the developer.

Okay. Now I've shown you one program which is this OTC program but I would like to stress the point that uh in this case although in although in this particular use case I suppose the OTC desk would be running this encrypted program. So nothing needs to be encrypted. Everything can be public. Only the trade intent needs to be encrypted.

But it could be the case that someone else was running this program and there was some proprietary information in this particular encrypted program in this particular program. So the there's no reason why this particular routine cannot be hidden from the third party. Right? Right. So what the OTC desk could do is that you know in this program this particular routine becomes encrypted and it is sent to a you know beefy server which executes trade intents from clients.

Um to make this a bit more concrete I'll show you another example for which I'll have to spin it up. Uh so in this particular example there's a hidden string I I'll show you just give me one minute. So this is another very simple example and the goal of this particular example is that you know just just pay some money out to person who guesses the right string and the right string in this particular case is Mississippi. So uh it showcases the idea of you know hiding constants inside the program. So you can have a program with hidden constants and if you know in this case if you're able to guess the correct string you can you can probably get some money but u you can there's no reason you cannot have a secret that signs or something else or sign the Ethereum transaction for you if something matches some predicate matches.

Okay. Um cool. So this sort of showcases uh you know how to use phantom and it sort of like you know nails the point that uh um you know as a developer all you have to do is write the program. Everything is taken care of at the back end. U we do not have to care about the noise growth.

You do not have to care about the circuit model and so on and so forth. Just write the code and that's it. Okay. So architecture and performance. Um coming to the architecture of phantom.

This is a particular um schematic that uh John Phillip from a team sort of drew out to explain how this works. It has I would say four main components and this middle routine is sort of like facilit connects all these bottom three components. What it essentially does first is that it will first read the instructions from the room. Okay, just to give you more clarity on what a what a VM is. VM has a you know a place where it stores an instruction.

It has a cycle and the cycle has a RAM and so on and so forth and it has registers as well. Okay, so first you read the instructions, you execute the cycle and the cycle has three side effects. Um it updates the RAM or it updates the registers or it updates the PC. Okay. So the first task to do is you read the instructions from the Rome.

Rome is like read only memory and then in the phantom VM which is the FG virtual machine you have to prepare them and I'll get into details of how to prepare them. But once that is done you have to execute these three boxes in parallel. The first box here updates the RAM. The second box here updates the register and the third box here updates a PC. But obviously not every cycle would update all three of them.

Um so you have to somehow homorphically you know signal that this particular update is valid because you know everything is encrypted. You have to execute everything. Um all these three three boxes will be executed all the time. Only one of them would be updated and that would be updated and that that sort of is you know taken care by a signal. Okay.

Um so uh coming to the the the the most expensive parts of this VM, you would notice that in this entire schematic um there are things called CBT like this. This is a CBT. Uh and there are many of them and this thing stands for circuit bootstrapping. And I would say that this and the RAM forms the major component like major time component of of the entire VM. And surprisingly to be very honest we were not expecting this before but uh after developing we realized that the entire VM uses this one core routine called circuit bootstrapping entirely and if you're able to excelate this particular core routine we'll be able to accelerate the VM a lot.

Um so what is what is circuit bootstrapping? Well, if you how many of you are familiar with GLWE cipher text? Okay, cool. So, what is a GLW cipher text? Well, you know, GLW cipher text is a form of FG cipher text.

I would say um you can do things with it, but it does not necessarily need to be f cipher text. What needs to be done in circuit with bootstrapping is that you send a GLW cipher text that encrypts a plain text K to a GGSW cipher text. GGSW cipher text is you know a bigger uh think of like many GW cipher text. You need to send a GW cipher text to a GGSW cipher text that encrypts X to the power K. That's one variant of circuit bootstrapping.

The second variant is like you just send GJ GW cipher text to a GGSW cipher text that encrypts K. Okay, these are the two core routines that happen and that that that sort of like that on that comprise of the majority of the VM and the second thing is the RAM. Okay. Um the problem with RAM is that since the RA the memory is encrypted um at the moment there's no practical way of uh having anything better than linear cost. So if you want to retrieve an element from the RAM or write to the RAM you have to pay for the entire RAM.

You have to mutate the entire RAM at the end of the day. There are results that sort of like you know make this better with some pre-processing models and so on so forth but uh those those results have big constants. since they're not practical. Okay. Right.

Okay. So, um we have a I would say pretty efficient construction for RAM. As you can see the size the the runtime for right to the RAM increases linearly with the size of the RAM over here. If you look at the the the the uh the plot over here, a 4 mgabyte RAM takes a right to a 4 megabyte RAM takes around 100 milliseconds. So the VM is you know the RAM is not the dominant cost for reasonably sized RAM but it will become a dominant cost if you have like I don't know a gigabyte of RAM or like 16 GB of RAM.

If the if the if the RAM of the VM that you if the RAM of if the if the RAM used by the program is small enough let's just say I don't know 10 megabytes then circuit bootstrapping remains the dominant cost. Um okay cool so what's the performance at the moment it only runs at like 1.5 hertz uh on 32 cores and now you may be wondering this is pretty slow and that's true. Are there any hope for improvements? And I would say yes.

Okay. So what are the hope for improvements? Well, first the as I how many of you are familiar with FG like engineering and FG? FG is embarrassingly paralyzable. uh you can paralyze FHE circuits very well and we expect that we we haven't tested on like 256 coursees we've only tested up to 64 cores the performance doubles with um every double every doubling of the cores so if you go from 32 cores to 50 uh 256 cores it would essentially double by every time so 1.

5 would go to 12 Hz right so every by adding more cores you can essentially you know speed it up but even 12 Hz is not enough then you can use hardware acceleration. In practice I've seen that GPU acceleration sort of like adds sort um shaves off two orders of magnitude so it gives you like you know to performance it improves by two orders of magnitude so you can expect the performance on a GPU to be 1 kHz but if you go to GP FPGA then it would you know add another zero to the performance improvement uh perhaps it you would get 10 kHz. Now the question is will we ever get into megahertz? I don't know but uh seems like there are there are uh there are few improvements that we can make. Um first as I said CBT is the only routine that is used in the entire circuit so entire circuit of the VM.

So if you implement CBT directly on hard hardware instead of implementing it as composition of uh FH routines implemented hardware you definitely get more boost. So in my opinion if you were to do it on hardware we would implement CBT and we we can expect much better performance improvements than just two or three orders of magnitude improvement. Um there can also be algorithmic improvements. For example, if you're a researcher in the room, try to figure out how to do better BCBT, that is like better bootstrapping at the end of the day. How to have better RAM and how to have better arithmetic circuits as well.

By arithmetic circuits, I mean circuits for multiplication, division as all of us know is pretty hard in FG or addition and subtraction. And with that, I will end. This is the u this is the uh QR code to the Phantom GitHub repository. It's under permissive license. You can sort of use it forkit whatever you want to do with it.

Um it's built using a pulp library. Pulp is a library which is which is quite fast. I would say it's again under permissive license that you can use and for whatever you want to do with it. Thank you.

Thank you. Very interesting. Uh I was wondering about encrypted program and encrypted data. I assume that it should be encrypted with the same secret key, right?

Yes.

If so, could you just provide some use case that you find more interesting where I need to have encrypted program with encrypted data and that will be encrypted with the same key, some use case for it. Think of a smart contract where you have hidden the secret key and for example if you receive uh you have a smart contract and you want to hide a secret key inside the smart contract.

Okay, thanks. Like just to sort of iterate on top of that it's it's uh if you're able to do that you it's essentially offication with threshold assumption and that opens a lot more use cases. Thank you for your presentation. My question is about the uh expected optimization by GPU and FPGA. So do you have any concrete reasons that you expect or FPGA provides I think 10 times our throughput compared to the GPU?

Yeah, I mean look at the papers they FPG provides much better performance than GPU in general. So, so like

and and it's it's most it's it's it's not true for schemes like CKS, but it's true for schemes like you know FU and TFG that FPG is much better because you can isolate the memory because because the bootstrapping keys in DFG and FGW is like smaller. You can just put it on the chip. It's not the chip on on the on in the memory of the FPGA and you do not have to pay for the communication cost uh from the processor to the FPGA.

Thank you.

Yeah. Is this possible to use this to use for AI private AI uh to protect user data

and AI inference

you I I wouldn't suggest you to use phantom for it but you can use pulpy library that using which phantom is built for encrypted uh llm you know execution we haven't built it but for no there's no reason why one cannot do that. It supports uh schemes using which you can sort of like build I know encrypted computation on encrypted LM evaluation if you wish to or AI evaluation.

Thank you.

Okay. [applause] Oh, thank you. Where's that? All right. Hi everyone.

Can you hear me? Yeah, I guess so. Um, so today we're going to be looking at some practical examples of building with FHE. I'm Alexandro. I'm part of Nosis Guild and we've built uh we're building Enclave which is an open source uh protocol for confidential compute.

Uh this is going to be mostly from an engineering perspective. uh not every math concepts just some lesson learned and stuff that we built which we think is quite interesting and um useful for the future. So just um some sort of background um why do we think this is important? Uh today there's a lot of data that is used uh that is sold and people profit from it like Facebook, Google, these corporations they can profit from your data and what do you get in return? Sure, you give your data in plain text, you access certain systems, you get the benefits.

But what if it be possible to actually uh control your data, keep it private and still benefit from such systems? Uh if you do choose to opt out from these systems, of course, like there is less collaborations and even stuff like um AI models, they might not be trained on um all the relevant data as well. Um so this kind of brings us to more collaborative ideas of uh building and so many examples of like uh confidential collaborative compute would be like uh medical research which is usually like a hot topic for FHE. Um how can we collab can we collaborate on analyzing data and keep it private? um private voting is just a very simple use case which a lot of people are trying to solve and as well as auctions or like training AI models.

Uh so we look at this trma uh basically a lot of the applications that are built nowadays um they sort of like give two out of these three properties and we think that without a combination FHE ZK and uh MPC it's kind of hard to get all three of them. You might get confidentiality and verifiability but you sort of lose on aggregation. You might get confidentiality and aggregation but then you lose on verifiability and basically we can see how confidentiality can be given by FHE. NPC gives us collaboration and CKP gives us the verification. Um so we built Enclave with the uh goal of solving this and basically we want everything um we want people to collaborate on compute uh on any sort of like use cases you might think that is possible and which not all of them might be possible this moment but as stuff improves we'll be able to get more and more complex programs.

um we want everything to be verifiable and we use CKP for that and that's really important for for our systems and we don't want any of the inputs to be revealed at any time just a sort of output from the FH computation um this kind of sums it up in a u graphic way there's a bunch of people bringing the plain text input that gets encrypted with a key from the uh network for the computation there's some sort of compute which is run confidentially on this data and then there is an output. This output is encrypted and then would be decrypted by a threshold network. Once we have the output then of course a lot of new things can happen. Uh but as you can see like we don't want the sort of input to ever be decrypted. Um okay let's look at a very simple example and one of the first thing we built at enclave on top of enclave is actually vining.

I think it's a very simple use case. Everyone understands it and um without FHE and PCNK is kind of hard to sort of get it right. Um so some of the properties we want are the having secret ballots. So just like traditional voting systems, you vote your vote should be kept private. Uh we want it verifiable which is something that traditional systems don't really give you.

uh we want to have receipt freess that is sort of to prevent um collusion and coercion and finally we want to distribute trust. We don't want um our secrets to be revealed. Um and for that we need some sort of distribution of um the trust which in this case is the key use for encryption and decryption. [snorts] Um some of the technologies um we decided to go with BF. Um so when Enclave started um they we decided to uh use PFE that gave us access to um some very efficient addition and for ving that's just all we need really.

Uh thinking of TFHE is a bit uh overkill for that. Uh we want ZK uh for proving that your cipher text is valid. proving that the talent is valid and that your vote is valid and fits within certain constraints as well as being able to sort of vote anonymously and then we use treasure cryptography um for the sort of trust. So there will be there is a network of um nodes which hold part of the key and that key uh can be reconstructed with a threshold. Um and the premises is that they would never decrypt the input and we do have some sort of like game theory and financial incentives to prevent that.

Um so yeah like just a simple thing. So take it as an example like um onchain governance you usually have votes that are like yes no maybe you abstain uh some might use it some might not but at a simple sort of um case we take just yes and no um the cool thing about u these BF schemes is that it works on polomials and let's just take a polomial of degree 10 and like flatten it out like let's get like a an array of 10 elements and we arbitrarily choose that the First five um the first five indexes are for yes and the first and the last five are for no. So we can efficiently encode a certain vote. Of course with a degree of 10 you're not able to get a large v in that but in reality for production use cases you'll have much larger polomials. In this case like we just take 10 um we take the first five.

So it's 0 * 1 1 * 2 and then uh a * sorry 4 * 2 we get a + 2 = 10 and zero for the no. Uh imagine it's like all the people come in they encode their cipher text encrypts it and it still has a flatten array um and then there's some sort of uh f computation done on that. So all of these indices are uh stamped and then let's imagine we get to this sort of tally. Then we take the same sort of formula. The first five are yes, the last five are no.

Clearly no is zero in this case. And then we just like reconstruct the part for yes and we get 18. Uh this is highly par parallelizable. So that's pretty good um to get done uh fairly quickly. But of course like this is super super simple.

Um in reality this sort of degree that we use in production can be up to like 8,192 which is like a large large polomial. [snorts] Um so how do we add receive freedness then? Then here we start combining uh ZK into it. Um, basically we want the circuit that people can use to either like um prove that you're a voter or prove that you're not a voter because you can't uh reconstruct you don't have basically access to the private key of the voter but you're doing some sort of masking operations. Um so when you encrypt like a cipher of zero uh due to like random noise and errors you always get like a different cipher text.

So to an externalize a cipher x of zero is not really um is different from I mean two cy zeros are different. uh what if you can actually take uh the previous vote of someone and just add zero to it and you get a completely new cipher text some sort of refreshing the cipher text basically and because everything is done through a z circuit uh this sort of like authentication logic is masked away and to an external eye you wouldn't know if you're actually voting for the first time if you're overrunning your vote or if you're actually just adding zero to it so with enough on parties you can actually get receive freess because you get plausible in the ability that um you voted in a certain way or that you haven't voted for instance. Um yeah just went through this um we something quite important there is that because we work this with encrypted data we want it to be uh we want to ensure that this is encrypted correctly. So every time a user sends an input to the system, we use um a tool called Greco developed by PSC uh which we ported to and adapted for certain other use cases. But basically like it takes a plain text, it takes a key, it takes a cipher text and you need to prove that this cipher text is the derivation of the plain text with this key.

Uh because there are sort of like economics involved in the system. If users were able to just send like random cipher text that will sort of break the system down and nodes will get slashed for not really the fault. Um but the issue with this is like it's quite uh computive intensive and that maybe sort of brings me to some other sort of rants about building with FHE is that we get like very large cipher texts at least with PF and proof for like validity can be quite expensive. Um just to finish the the flow of the voting uh each of the person will submit uh the vote the proof whether is a vote whether is a masking we don't know that um all the vaults are then summed up and we basically get the tally then the tally is decrypted by the traial network. Um this just a sort of representation of that.

We see um user come they put a private key uh sort of private key and a balance. We check okay do you have the right private key that result into a leaf within the tree. Cool. If you're that sort of authenticated users then your vote can be an encryption on anything as long as it's within your balance. But if you don't pass the authentication steps, then we need to check within the circuit that the actual cipher text you bring in is an encryption zero.

Um, and that adds a lot of constraint to the circuit. And then again, if you are uh just masking, so adding zero, we also need to prove that the operation you're doing and we need to prove that within the circuit is that just the sum of the previous cipher text with zero. Apologies for the resolution here. It's probably a bit hard to see. Uh, but I guess you got a gist of it.

Um and finally for the distributed trust uh there's no single node that can decrypt the data. Sure they could be colluding between themselves and decryptting the data but that sort of brings uh economics uh they can basically just get slashed and they of course don't want that unless uh the sort of reward for doing the early decryption or disclosing data is higher than the reward they get for behaving honestly. Um the thing is like for this to work we we sort of want a verifiability at all steps. So it's not just about the voting or the FH computation itself. It's like how do we um ensure that the key is used by the network is actually um correct.

Um we use a publicly verifiable secret sharing and a distributed key generation ceremony. So for each sort of computation there's like a uh fo key. So like the nodes after the computation is done they can just forget about a key and there's more security added to it. But the issue is like they need to perform some sort of MPC. In this case we do it uh in an interactive way with a low bandwidth.

Uh but basically you need to like generate a keeper. You need to like share it and [snorts] you need to re um you need to encrypt it as well. Send it to others. they can decrypt it and then start forming this sort of um key that uses and that's quite intensive. Um we tried going through some uh implementations our cryptographer would know better but um there was implementation about publicly fable secret sharing they wanted they were suggesting to use PVW encryption.

Uh we spent a few months on that and the cipher text ended up being like huge. uh the engineers working on the nodes were like um right this is going to be a bit tough we're sending like a huge amount of data in the network uh this is just not going to work so what we decided to do instead is just reusing BF uh and why we use like non we use threshold BFV for the actual um FH computations we can just use normal uh BF uh for encrypting the share and that was kind of sweet for us because we had all of this stuff already um built in and at the same time we having the circuit for verifying um the cipher the encryption we can sort of adapt this um circuit for verifying that um the encryption of the share the aggregation and then eventually the decryption of the tally of the output is done correctly. Um so yeah there's a lot of trade-offs in here like if we want to achieve a higher level of security which is like at a minimum 128 bit to get postquantum security then we need a very large parameter set. I talked before about the polomials being 10 degree for that example but uh to some of the parameters which I'm working with we ended up having a polomials of degree 8,192 which is massive and verifying all of these it's very intensive like uh as of now for a user to verify the cipher text with this level of security uh bear in mind that we're also ensuring that the network is uh enough distributed so we also raise the number of part is they hold the key and yeah this basically brings up to like a huge number of constraints which um because the user need to do this on the browser they come and they encrypt the data and they prove client side we might you know we get into some troubles we're like sure formula constraint is not really going to work on a browser now so we're working towards some optimizations or at least for the time being for demo purposes working with smaller parameters some other of course uh options would be just using proof delegation Um but we haven't really explored that for now. Another cool thing that about PF and sort of like the voting use case is that it's sort of lightweight.

You just basically summing up cipher text. And what we found is that because we we talk a lot about verifiability across the stack. Uh we want the sort of um computation to be verifiable as well. And basically we just run the uh addition inside the risk um zero VM. you could choose other other ZKVMs.

Um, and this just gets us aggressive proof and they can be verified on chain pretty succinctly and cheaply. Uh, there's some other use cases which we explored. Um, we played a bit with sunscreen uh SPF that's pretty cool. We could build some uh demo for like uh auctions. It's just like build building this thing into the system will require a lot of changes uh just because we focus on BF for now.

also integrating all the new DKG uh and the keys and perhaps bootstrapping as well would be like a lot of work. Uh and then finally because you want verifiability uh sort of a questions to you guys and people working on this is like could this computation actually be verifiable and run within let's say um uh ZKVM. Some of the lessons learned is that this is a very exciting space. I joined like three months ago. I've been working on ZK in the past a lot but not on um FHE and yeah it just sort of like blows my brain seeing the sort of cool stuff that everyone's here is building and that we are building as well.

Um it's clear that not you know there's different uh schemes some of them will be useful for certain use case some for others. So it's it's very cool to see sort of scheme switching uh being implemented and we're very excited to try out libraries like pool pie um for that but the goal is like we don't want developers to actually worry about this uh even users like they come we want to run this computation cool this is the best scheme for that this is a program for it it'll just work right out the buff and we're not there yet of course um yeah so verifiability again that's a that's very resource intensive. Um and we want to see improvement on that. We're working very hard to improve um to optimize the circuits we're working on. It's just like having chosen to work with no and polomials is it can can be a little bit tough.

Um but eventually we'll get there. And even more like if you're adding extra sort of like logic into the circuit that that ends up blowing up and for user to run that in their own browsers it's it's not great. Um another issues we face is like because of such large polomials and some of them needed to be public inputs to the to the verifier then we end up sending a huge call data uh on chain. So basically we need to work with uh commitment schemes to just send a commitment to the data but that sort of blows up the circuit even more because we need to do a lot of hashing in it. So there's all sort of like drawbacks in all places.

But what we think we the ecosystem needs is like uh scheme libraries for multis scheme support. Um we want to see more and more libraries uh being improved and maintained. Uh verifiability seems like a very hot topic and it'd be great if the ecosystem continues to work on that and trying to work out on optimizing um circuits and primitives for very proving your cipherex encryption. Um yeah, I mean that's the end of it really like if you're interested in enclave um please just check this out and um yeah that's it. [snorts] [applause] If you got any questions, I think we got a minute and a half.

[snorts]

Uh next we have a panel and it will require a little bit of physical exercise by the speakers because we have no uh chairs here. So, all the speakers, please come up. Uh, if you're very far in the back, you can just take one of the chairs here in the front. This what

six. three or

are you going to be asking questions to public or are you going to be talking just by yourself?

Uh, I think no public. No public.

Okay. And this one check Thank you.

Um, wow. Do we need like introduction or we can just skip it because we only have like 20 minutes. So maybe I'll get like straight to the point like uh over the years we have seen like you know very uh many many teams develop uh ping fg uh but then like I think we are kind of like you know different in opinions in like how how how we how we develop this thing uh in terms of like also schemes and tooling and also you know like what kind of use case that we we're looking for and you know like but in the end of the day uh the the goal of panel is just to to to let everyone you know like uh have a chance to you know like share all these like difficulties, bottlenecks, experience and then you know finally hopefully like we can agree on like some general thing to to work on the next year even if it is just like in the form of some hints. Good enough. Okay.

So I think like uh we can start with uh you know a brief introduction of like everyone here. We have like you know researchers uh from academic, we have like developers. We also have like you know some some like product people here which I think is like quite representative for like the uh FG build builder system uh ecosystem I guess. So uh maybe like each of you can like share your um you know when you are developing uh or develop FG what are the uh difficulties uh that you encounter when you're building and also like with what you are building what are the uh bottlenecks and uh if you are looking um into like some potential uh thing yeah we can go from like around

okay okay u hi um I I'm John Majimal from R&D organization called Phantom to Zone. Um for short we call it PZ. Uh what is the first prompt? First prompt is uh

um yeah so in general like sharing like the difficulties when you build FG

right? Uh well I I work at a lower stack which means that I design FG algorithms and write the so not I don't write circus in general. I just write the algorithms. um uh the the difficulties that we face um well it's very hard to interoperate with hardware people uh as as someone working on algorithms um it just uh there's no there's no codem for interfacing with people doing hardware acceleration for FG hopefully that improves in the future um in terms of uh if I were a developer I would today there does not exist um standard library like the way it exists for for uh ZK there's no there's no way to reason about like for example in ZK we have custom circuits we have you know plonish circuits and so we have air arithmetic um you know that doesn't exist in FG space um it's just very hard to navigate the space um if you do not have that

uh yeah hey I'm working in enclave And um I work on a higher level uh than Jamaya. Is that right? Yeah. Sorry. And um yeah, I mean some of the difficulties it's I mean personal level is just like getting into the space.

The FH is like there's just so much to look at. Um some of it can be not properly explained. a sort of like education as well is very important like having like more accessible blog post um like papers sort of deciphered more examples that would be really useful for like um people just joining the space and um in terms of like when building with it u for sure like the lack of like general libraries and sort of an abstraction layer uh I feel like that will make our life much much easier and especially like um I mentioned in the talk is the TK K part of it like we need ZK for FHE like it's it's mandatory but the sort of like it's a bottleneck at least in my opinion of um getting your computation verifiable and anything around the stack.

Hi um my name is Eugene. I'm from Fisarium. Um some problems um the most problem I faced throughout this week was um educating people. So people now uh they have heard about FH but they don't even know what FH means. So I like spend a lot of time to educate people about like what it is and how what problem we can solve kind of things.

So that's one thing. Another is uh yeah as they mentioned like I also feel like the needs for standard of like more like how we what would be the best way to um like make a standard and then share that so that we like the application layers or some consumers like they don't get confused when they want to use FHA on Ethereum and also um there are other technology that try to achieve the private Y um and so there are many different technologies. So um how do we work together to uh make it more clearer for like people? So like explaining in more layman's language would be very important and yeah that that's my opinion.

Hi my name is Gorgen. from fair mass team and when we talk about challenges I think we need to separate or consider general two main groups customers of the technology and developers if you talk about customers I think it's general problem about privacy we need to provide some real use case scalable uh not just private transfers private tokens but show that we really need privacy because we have some hype on privacy we talk about privacy a lot but when you started to talk with crypto banks, with some DeFi companies, all of them wants to privacy, but right now they have a lot of customers and uh they can make money without privacy at this stage and all of them say yeah yeah we need but probably a little bit later when we talk about developers uh the problem we started with was uh we started to build application layer for developers because building applications for developers is very hard right now because It's now looks like like you are building uh applications as a developer on assembler language with very limited operations. This is the one thing we we are trying in our team simplify. Another thing again I talk about a lot. We need to find the way how to combine different technologies together.

How with Fe to organize joint computations. This is the biggest problem from my point of view because it needs us to use ZK to use MPC. It does much harder all stack with a lot of bottlenecks with a lot of hardness and degree security.

Um hello, I'm Tom from Phoenix. Um the main challenges that we see are essentially three. We have we want to make privacy and encryption seamless for developers. Uh we want to make privacy and encryption seamless for users and I think both of them uh we we in in to some level we achieve with the co-processor uh uh architecture. This is definitely something that we can uh you know further improve improve on.

It's still not perfect and I don't know if the co-processor model will be like the endgame for this. This is I think something that we that is like very suitable right now with the tools that we have now. I don't know if this is the end game but this is like definitely two angles that we uh really want to like focus and improve on. And the third and last one maybe the most important is performance. Um and here again like this is the the on one end the performance of the computations themselves on the other end is the per the performance of decryptions.

Something that people often forget about is that any data that is encrypted and computed over encrypted in an encrypted state needs to be decrypted eventually because people open their wallets and they see the balances of all their tokens. Um and this is something that we need to improve performance on as well because as we get adoption as we get like thousands of users, we get like you know a lot of decryption requests. Um and since FG cers towards mainly private shared state uh versus single users uh or sorry yeah private shared state versus single user privacy. This is something really important. Um yeah

um hi I'm Kiw I'm in I'm from PSSE and I'm more of a cryptographer I'm on the academic side of FHE I did my PhD in FHE and spent two years as a postto and has recently joined PSSE as a researcher um one difficulty well I saw people facing was like the because of this FHE has very um unintuitive cost model like like when I was like PhD student like a lot of like for example like from people from biology or like control theory like um reached out to our lab to collaborate on several projects but they were like why can't we do this in FHE like for example like RAM RAM RAM model like the if statements or the while statements and they they just had difficulties understanding what's um efficient under FHE something is not. So they sometimes bring us some um they built they built some FH circuit but like no no no that's not the way you can do it like that's going to be like too inefficient and yeah this kind of um um weird cost model kind of um hinders the adoption and makes the difficulty for the developers and user ends I think. Um so I'm CL I'm working for for Zama for few years now and I'm working mainly on the blockchain part and I feel like we we have two kind of challenges like we have the more crypto primitive so someone mentioned the proving execution which is really important and still something where we are doing research also but I feel like something uh which came up when you have a more mature technology is to actually build a product and um I think this is like a big challenge to uh realize that what would work for developers because we all know that privacy is not the most important thing for many people and if it's too hard to implement like people will just drop the feature. So you need to be better than any other features because it's not something people uh consider a lot. I think like it's good like we have a uh like a privacy season so like many people like take care of that right now.

So this is great but um we need to go beyond that. So it's it has been already mentioned by by Tom but I totally agree that we need to to push further about that. The composer approach is clearly a good one to drive adoption because people can just write code but is it the end goal? Can we do better? Can we do like more to to drive the adoption for that developer?

Uh I think we need to to continue on on this road on tooling and everything.

Yeah. So thanks everyone. So I'll try my best to make a summary like out of these like seven opinions. So we face first of all so let's say that we we agree that FG is a technology but it is not a solution and we need to work harder to make it a solution right and then we engage like different kind of difficulties when we try to use this technology in privacy solution let's say that first um you know like there is a lack of introductory material for new new beginners that you know try to get into this FG uh for privacy and then Second uh there is a gap between the traditional programming model and programming in FG right and third actually like uh approaching from the uh perspective of a privacy solution uh let's say product builder uh they have a hard time to understand what can they do with with FG if we don't have like a comp like uh let's say a good tooling or a good stack using FG for them. So like all these uh yeah of course we we also have like problem with trying to like increase uh the performance of FXG which is like the core of the the whole thing.

So like but these are like uh you know like the parallel fronts that we can we can work on and I believe like each of you here are already like engaged in one or more aspect of this and trying to improve this thing. Okay. So um I'll tell you like uh you know ahead that after the next question there will be a voting okay but then you like you can have like try to think about like whether you vote for it or not uh you know like when you are answering the next question um verifiable FG and FG okay practicality whether you believe or not in three years we have practical FG and verifiable FG. Oh no no no no hold on hold hold on you have time to think slow down slow down uh but then yeah that is like you don't you don't have to explain just just vote okay we we just like want to

yeah yeah right [laughter] uh but the next question is like what do you think about the current key management of uh FG uh based solution we can go like this

uh what in particular about key management solutions

oh yeah like uh in uh almost like all uh current uh privacy solution using FXG we have this uh centralized key and uh how do we manage this know the decryption key

it's it's not centralized it's threshold right

oh yeah yeah yeah okay

right but I mean like one key for everyone

oh right right right

almost centralized

yeah yeah yeah if you do not yeah almost centralized yes

so what is the what what is the opinion of our oh I see like you we are using this but you know like is it okay what are the uh awkward feeling when you kind of like uh send your privacy around this key

okay I I'll go first okay um I I think that u it depends on the context like in what use case are you deploying the FG system for uh if you're saying that you know there's a blockchain um and it's like as trustless as I don't know Astrike or as trustless as um Ethereum with FH threshold decryption. That's false. Um that's that's not uh that's not true because you can leak the secret and someone will bribe you on leak the secret and uh that's not attributable that you cannot design economic incentives unless something is attributable. But if you are able to design a spin up a system where you have legal contracts with the other party and you have threshold systems where have legal contracts with everyone then everything is fine because you have legal contracts there is a particular thing that enforces the entire system to not be bable and that's fine in my opinion. Oh,

I have one.

Um, essentially most of the use cases for um for the decryption committee or like the MPC protocol for threshold decryption is for us to have uh private share state again in comparison to a single user privacy. And so you can build protocols like rail gun like privacy pools that um you know using we can build those with FHE as well and have like single user privacy or like you know sort of more self-s sovereign you can decrypt only your own only you can decrypt your own data you're in full control and everything. The problem with is that well unless proven otherwise these systems always require some uh measurements in reality um to also deal with bad actors like hackers um uh uh and you know uh well mainly act actors, state actors and malicious activity and using uh well to to actually tackle that. We use like uh you know mechanisms like proof of innocence and and and protocols for disassociation and stuff like that. People need to wait for a day for example before entering the private pool in order to um to prove their innocence or honesty and but like what happens if a day is not enough?

Like we saw use cases where you know there were hacks and exploits where the all of the addresses associated with this act is uh revealed only like a few weeks or a month or a month after what happens then. So these technologies are not perfect for that. Um so this is for example why a committee based special decryption is much more powerful to tackle that and we like I think that uh true adoption also needs to tackle these kind of questions of like okay what happens you know when regulators and and and and states require the protocols to actually very again like uh very specifically in a very specific use case uh or or an instance to reveal some sort of information without like a you know um a dis like um a disclosure. Uh so what I'm trying to say is that all models are powerful in their own way. We currently seems like the com like the MPC protocols are a bit more pragmatic and tackle the the future with a bit more like a realistic approach.

Um so they're power powerful on their own. I I think also something on the MPC side uh which is uh something we we need to work on is the verifiability of decryption to be able to prove that decryption is actually done correctly by all parties and um and this is like it's not like perfect you don't solve everything and I totally agree that uh for like having like legal contract with all parties is still the the best solution for now but uh yeah this is like like a road map like for the NPC to have verifiability

u just just one point just just I'm I'm speaking again so I just want to make sure I'm not over speaking uh okay cool uh uh just just one point on just one thing on one top mentioned um I think uh the the the benefit of things the the the downside of having you know an MPC committee that becomes the you know this king that could decrypt um arbitrarily at any regulation or state actor request it's uh then it's not a blockchain because I'm not given uh my you know I I lose like if you're able to control the state for me then it's not it's not like I don't write over it it's not like my state right um then it's something else probably that's a better system as with the regulation but it's no more a blockchain Um

right. So I think um like basically [clears throat] what we just discussed here is that uh you know like unfortunately we have this uh key that is like the the problem of like you know privacy uh solution based on FXG right now and then uh let's say that we have different models uh in terms of like how do we custody this this privacy sometimes you can you know just rely on a committee maybe a rotating one on a TE uh but And there may be also like u the model where you can like engage with uh real world actors to uh you know have some post hawk uh resolution about this whole situation if uh your privacy is like at stake or you know some someone violate your privacy in some way. Yeah. And then like obviously we we also like need to work on um you know like how do we uh authorize access to to our encrypted data on Ethereum. that is like another another difficult uh difficult problem that we we need to to to add to to our road map.

Okay. Just small comments is the problem only when you talk about private shared state I mean about the key if you don't talk if you don't need private shared state it's not a problem at all.

Yes I think we are talking about private share state. Yes. Um yeah so like time for voting uh practical FG in three years.

Okay

in two

um practical VFG in five years.

Oh practical verifiable FG in five years. Uh

five

five

uh probably probably I think so.

Anyone? Yeah.

Oh, [laughter] that's a spirit. [snorts] Okay. So um I think like we have like already like surface the difficulties uh problems in building with FG and we also have like uh let's say the aim size on like what we should expect in terms of you know development of like TPS and also uh hopefully tooling uh in the so if you have to choose like two to three problems okay maybe one to two problems that you have to work on in the next year what will be it Uh

yeah, we're going to do a round you know it's not like yeah

maybe

um no I feel like a verifi verifiable FH is uh clearly on pure research uh run a really important and also verifiable MPC um having like the way to yeah to have more trust uh in the process is really important if we you want to to build a true decentraliz system. So yeah, I would say on research this is the two main and uh overall like uh performance is also obviously important uh even like uh we did like a huge progress but uh if you want to on board like uh basically the world blockchain let's uh be but I think it will happen at some point I'm convinced we need to improve that

so to increase this uh privacy guarantee when we have the central kite basically key management next year. Great.

Yeah. Uh Kiw

going live, right?

Yeah, we are going to do a round.

Um I think verifiable FH is a bit far away, but I think verifiable decryption we can work on more like like Phoenix did recent like published recent paper and like but it's like it's not like publicly auditable. it is like maliciously secure but we can also work on like publicly auditable um verifiable decryption. I think that's one thing that we can work on.

Okay. Proof of decryption publicly verifiable.

Yeah. Um I would say uh two things right. So uh performance definitely and um I think one thing that is often neglected is developer tools and user experience tools um to kind of bridge the gap. It feels like currently FHE based systems are more for like power users or advanced users and it's really not the point like we want to actually you know uh uh uh for it to be approachable for everyday users. Um so yeah

great thanks. So that is on uh developer experience

developer experience user experience and performance. [snorts]

That's three.

Yeah please. For me a couple of directions. The first of them is find a way to build new FH schemes fully new way because all scheme that we have right now they follows the same idea idea based on the gentri work with bootstrapping all of the schemes practical and secure scheme follows the same idea more or less. uh another thing joint computation if we talk about uh decryption threshold decryption protocol we don't know the way how we can eliminate this part at least right now but uh [clears throat] if we consider the way to use threshold decryption protocol we need to find the way how we can build scalable threshold decryption to be able to have thousands of node in the decryption protocol and there are two parts in threshold decryption protocols one of them is decryption let's say part where you decrypt another part is when you generate the key it's probably two different parts but all of them responsible for scalability and the developer experience also are one of the important part um I want to talk a little like more real world use cases so uh personally AI changed my life a lot this year and I see the the advancement is really speed up and you know AI they like develop like by consuming our humans data and then we don't get any benefit out of it and now Google is building word model and then it will be only accelerating and I always think about um like how can I um protect my priv privacy and then how can I get benefit out of the AI consuming my data data and learning from it so that they will eventually replace humans. um then and including myself then like maybe uh we can use FHA uh for protecting our data and then get some incentive uh out of for their using our data and the incentive schemes and the protecting and then usage all these um usage can be done uh by using Ethereum as a settlement layer and also using the privacy preserving this FAC tech so um I am very passionate about in this like real world use cases.

Uh currently we only have the FAC as a tag but uh we want to build some find a way to build this use cases how to use our attack. Um for me I would say uh focusing on the DK part of FHE. the verifiability I feel cutting the cost of proving down and optimizing that will be what we focus on and uh that would be really useful for the ecosystem but in one year is probably not enough but we need to get started and on the other end of the spectrum is the developer experience like there's so many cool uh stuff we can build with it just like who's building it like there's not enough developers building it just because it's you know there's no documentation there's like if libraries are a bit cranky like just just everything is fragmentated is not properly explained and trying to get everything in a place where it becomes easier for people just you know go to hackathon and build stuff and you know like take it from there really

right uh three right

three or one to two one to two I see I see uh uh just just just before that one point on new schemes. I think there are a lot of good people working on codebased FG systems and there's a new paper from Rabbital uh technologies about graphine. Um I think uh there needs to be more uh you know speaking about new schemes and FG conference you're laughed at but I would say that there needs to be more engagement about building new new FG based systems um that do not rely on lises because we do not want to be putting everything into a single bucket. Um okay now now now the first first thing that I would I would want to work on uh or I would want other priorities as well is uh we it's inevitable that we would see deployment in in in blockchain context in decentralized settings in a pre um in a co-processor model I would say we should try to minimize the surface area of attack there has not been much discussion about um you know all of us are essentially trusting these these MPC committees uh we should try to design systems and the way they interface with the actual smart contract in a way that the user is not drugged for privacy or like even for state by a state actor in certain settings uh or not even like state actor probably you know there could be someone else bribing someone sitting in I don't know Serbia bribing people and sort of like that stuff uh and legal contracts are a good way to do it um the second thing that I would say is uh work on probably we need to we need to see more applications that are not related to to private shared state I mean there's one really good application that I would personally pay for oblivious measure retrieval um that one should work on we should be try to solve P uh and make it concretely faster P has this issue which you know which all of us know it's really time but they need Fe sort of like is really good in settings where a person holds their secret key and it is it is sort of like offloading a heavy compute to beefy server and there are a lot of use cases for in this blockchain space probably not you know deploying private share state private share is one probably commercially viable use case probably there are other use cases where we can use it for um yeah

wow so yeah I think like uh I'm glad that we uh you know like uh kind of like join together today here share opinions and you know also like share what will be like prioritized to to work on next here and hopefully that you know like after this we can like kind of make an open rearch forum where we can you know like if you're working on like uh verifiable uh decryption or you know like a model to to do key management or working on like improving the user experience developer experience then you need access to like hardware uh you know like builder then yeah I think this is like maybe a good chance to to know like Joy Fox and uh do something and move the the [clears throat] whole FG forward. Not just you know something exists only on design but then we actually have like applications in three to five years. So thanks everyone. [applause] Quick plug uh after the lunch break at around a little bit before 2 p.m.

uh we will have obfuscation day here. Um like if you haven't uh registered for that there might may still be space here. If you're interested in that just pop up if it's not full you can come. So yeah it will be interesting. [applause] [music]

[music]

The past few months was very crazy.

[music]

Just I system. [music]

[music]

It's difficult to fight.

[music]

This is one of the private tracks.

[music]

Okay. Hi everyone. Thanks a lot for joining the opuscation day at Defconnect. Um we have a small technical gathering here and the goal was to just bring uh together some people that are interested in building in this space and just want to learn more. Uh the event here is hosted by the PSE team from the Ethereum Foundation.

Um and um we will have three talks each half an hour and afterwards one panel. Um, yeah. And then afterwards will be the closing cere ceremonies at Defconnect I think at 5:00 p.m. So we will end here at 4.

You will make it well in time to the closing ceremon ceremonies. Um, if you hear something interesting, find a speaker later. Uh, if you're looking for collaborators, it's a place great place to say so. Here you can also catch me in the back if you have opinions or thoughts on what the Ethereum Foundation or PSE should do in the space. Um yeah, thanks again for being here.

And so let's get started with the first speaker which is Sora.

Say again.

Okay. Can we start from now?

Yep. Can start now.

Okay. Hi world. Yeah, thank you. So thank you for joining this obiscation day. So I'm Sora from Magna IO a project uh within Foundation PSC.

So today we like to challenge two common beliefs about IOR. One is IO would be nice to have but it isn't strictly necessary for most applications. And second one is IO is technology that's still 10 years away and we don't know any path toward practical IO. So how many people believe these two arguments? [laughter] Thank you.

Cool. So in the first part in the first part we show that IO is essential for enabling confidential smart contract in a scalable way for easily and in the latter part we'll present our load map toward practical implementation of IO and actually we only have three technical components that we don't know how to implement practically and if we can implement them uh we believe we can extend them to our practical IO construction as long as the assumptions for our IO construction remain secure. Okay. So uh before going to the first part uh let's review the history of how E3 have improved scalability for public smart contract. Oh I think design seems to be slightly broken but like a that's a big not big problem.

So the baner is ran without any programmable cryptography without snack or was not scalable because bitors need to perform all the m computition to verify m transactions per second and this problem was temporarily solved by side chains. So transactions have transactions are processed by cytochain committee which is different from the Ethereum validators and only the some commitments of cychain blocks has been recorded onto the EUM layover. However, this next introduced security issue because that side chain committee is less decentralized and less secure and finally zil appeared. It requests a trustless permissionless prover to generate a proof of the M transactions and the committee only need to perform constant communication to verify this proof and this solves the security and efficient scalability issues at the same time by delegating such heavy linear part computation to our permissionless parties and then keeping the keeping the val computational cost constant. Then howbert scalability for confidential smart contracts.

So man definitely does not support confidential smart contracts and even with ZKP we cannot support contracts that involve multiple users ply inputs and this problem is so addressed by one solution for this problem is FG plus MPC for decryption. So it introduces a MPC committee or to perform decryption to decrypt cipher text of output from confidential smart contracts and this can be compatible with the this does not require any new tasks on the Ethereum validators since every work is done by this committee. So this also implies it introduces the security issue since users need to trust this MPC committee which is also less decentralized than the EM parasites. We can place IO as a solution that solves the security and scalability issue at the same time but for confidential smart contracts. Some people might think it's still possible to modify ision protocol to have validities support this MPC decryption for FG but we don't think this approach works because this this introduces a significant trade-off between the security and scalability.

So let's consider the case where the number of the transactions per second for confidential smart contracts increase in double and since the computational cost and communication cost for each committed party increases in the same order the committee party need to increase their computational and communication throughput of their hardware in the same way. But this worsens the decentraliz decentralization of the committee parties because only rich people who can operate high performance computers will be able to join this committee and also this worsens the ge geographic decentralization since they might be able to operate operator with enough network throughput uh only in regions with high network bandwidth. In this way, we believe IO is a necessary solution to solve this tradeoff between security and scalability. And uh to give up on practical IO today is equivalent to having given up on practical snack in the past. Okay.

So then let's go to more deep part of the construction. So I have not explained what IO is actually. So IO can be seen as a program compiler. If you have some program or which which makes some output on some inputs, you can make a obscated version of the circuit by using IO. And while this makes the same output uh while this makes the same output as the original circuit for any inputs, this obiscated circuit intuitively ensures that you cannot uh get some secret within this obiscated circuit.

And in practice we can consider one or skater who makes some socket or with some secrets and then makes the ariskated circuit and distribute it uh to the like a publicly and then any evaluator can evalate this any user can download this ariskated circuit and evalate it on any inputs without interacting with this obscator. And you might think uh in blockchain use cases we cannot assume such single trusted obiscator. So in practice we can also consider IO obscription with decentralized parties and in this case and and also in the blockchain use cases we don't need to hide all of the functionalities. Uh rather than that we only need to hide some hardcoded secrets. So we can in this obscated decentralized obscution uh like participants will provide their own secret key and by doing some NPC they can make a obscated circuit such that as long as at least one party is honest no one no single party can know the hard final hardcoded secret within this obscated circuit and uh have you ever received the our position paper.

Yeah, like a weird distributing real paper and uh more concrete technique to make this obscription decentralized and make this process verifiable are proc are explained in this paper. Okay. So, and uh formally there are two security definitions of IO. So, one is indistinguishation. I think this is more famous and uh but actually this only guarantees that or this this does not guarantee that any secret within the obiscated circuits remains secret remains private but it can be constructed without any huristic assumptions at least theoretically.

The other assumption is ideal obsiscation. This ensures that this ensures that the obiscated circuit cannot does not reveal any non-trivial information beyond its input output behaviors. However, it is known that we cannot make such ideal obscations for any programs without any huristics. But in other words, if we introduce a huristic model called s random oracle model, we can actually construct this for most of the natural programs and if we have indistinguishation uh we can easily extend this to idealation by combining hash function. So in the following uh when I when we use IO or as like a tool blackbox I we will explain the security based on the based on the security definition of this idealation while when we talk about how to construct IO uh this this IO means indistinguishation.

Okay. So then how can we completely make confidential smart contracts based on uh this IO and actually instead of we make such contracts and using only IO we also combine FEG and this allow us to make only this allow us to use only single implementation of IO or for any application and we call this single implementation root IO. So before explaining this root IO, I'll explain the previous idea to construct confidential smart contracts based on FEG uh which is basically inspired by the Zamar's FG BM protocol. So there are three components. The first one is our smart contract on blockchains and there are two types of the smart contracts.

One is our application contract which defines what kind of program should be homologically evalated by FEG and this also defines a decryption policy of the cipher text and the second one is a gateway contract which orchestrates users and the other components I'll explain next and next component is a FG co-processor. So this process f evolation of the requested programs and the requested input cipher text uh which is specified by each application and this is actually operated by permissionless and trustless evalators and the remaining one is last one is decryption co-processor. So this is like a one of the biggest uh like most insecure part in this architecture. Because while this performs FG decryption, if the application contracts confirms that this like a given suffer text can be decrypted based on their decryption process, uh this decryption is instantiated by the T out of an MPC committee. In other words, new trusted parties different from the Ethereum validators.

So today when we use this FPV plus MPC for decryption construction we still need to trust this uh this committee to perform or decip to perform MPC for decryption. So our idea is we use IO just for replacing this decryption co-processor and then in particular this obiscation for this socket function is sufficient to replace to replace decryption core processor in this FG BM architecture. So you can see that like most of the parts seems to be agnostic to the any of the application logic. But you might you also might think or well like while decryption policy uh can be different for each application. We need to fix some single verification logic uh to verify this given proof inside this obiscated circuit.

Then how can we uh def how can we design such a uniform verification logic? We achieve this by using gateway contract. This absolves the difference between application specific decryption conditions. So for example if there are two applications using FUG based confidential smart contract each of them will like check if uh the given cipher text or satisfies their own or decryption policy application specific decryption policy and if this checks if this confirms it satisfies their policies this cipher text is provided for the gateway contract which is a single contract for all applications. And this gateway contract will just just check that the given cipher text is like a legit for the sorry the caller smart contract application contract is legit for the provided cipher text by seeing some access control list.

And uh if this is true, this gateway contract will output a message like this cipher text can be ready for decryption. And if we lie on this gateway contract, we only need to the obiscated circuit only need to verify that this gateway contract approves decryption for the given cipher text on the isan. So we only need to make a snack proof such that uh there is a like a event such that this gateway contract outputs the given cipher text uh for decryption or as a decryptable cipher text. And this is why we only need single implementation of the obsiscated circuit for all applications. So let's summarize the idea of this or FG plus root IO.

So from the perspective of trust assumptions process can be decentralized among n out of n committee and this is only for one time setup and uh you you might think this is this still depends on some committee for MPC but this assumption is significantly weaker than our previous ones because if you only need this committee only for setup phase you can easily set the threshold to the highest one which is which is n number of the committee because if someone like uh goes offline and uh some MPC for setup fails we can just restart the same MPC since there's no kind of uh state and uh there's no effect to the users since this is a like a process only in the setup and uh once this setup is done uh no additional ongoing trust assumption is necessary beyond ELM validators. So in this sense we believe this FG plus root IO is the best solution to make our ELM are really scalable and privacy preserving without sacrificing the security and from the perspective of onchain cost. So we in the paper we show that our so we can verify our outputs from the obsiscated circuit just by checking some signature. So onchain contracts only need to perform snack plus signature verification plus some uh tiny public operations like access control checklist. So we can say onchain cost for conf combination smart contract in your approach can be almost as cheap as a uh cost for public public smart contracts.

Okay. So yeah we so in the in this like part uh I assumed we already have some uh super practical available IO construction and I use it as a blackbox but uh as you know the biggest problem is can we make like a practical IO and this is a benchmark of our IO latis based IO implementation and uh this input size means input the size of the program being obiscated. So you can see that even for four input bit it's already obiscation already takes around uh five hours and the evolution takes 18 minutes and uh this like time seems to increase more than linearly. Yeah. So like uh well we can always make some good cryptographic protocol or yeah we in practice like we always also have some like a bottleneck or for practical IO construction.

So and we have not directly improved uh this benchmark uh after we first implemented that implementation in last May because after we make this we focused on more fundamental part which is keyhorn encoding and actually this keyh encoding is a central like a part central component to improve the latisbased IO construction. So uh I next go to the second part which is about our road map to make audio practical. So this is our road map. So this like a allo with red question mark means we don't uh we don't know how to implement this transformation practically and uh well the allo with check mark means we know how to implement this transformation or if we already have the implement practical implementation uh at the tail of each arrow. So you can see that the only missing components are homoic PLF over encodings, snack verifications over encodings and the verifiable FG.

So, so like a our so you can find that our practical IO is not like a kind of like a something we don't know something that we don't know even that past but like it's just a complete collection of technical challenges and in the following I'll explain what this keyhorific encoding and what's the exact definition of this missing link components. So yeah, I I I'll add more like a mass bird, but the point is you don't need to like understand all of these details. I just want to say like this key config encoding is actually very simple and uh uh straightforward. So like uh I just want to uh it's enough if you can feel like uh this is like just a linear jibler and uh you can like uh try to solve this problem. So sorry I think notation like uh notation position seems to be broken but like uh we can define some encoding for integers uh and some secret and the public key and this encoding is technically defined in this way where uh this G is some fixed matrix and uh this this one is like a tensor product and uh this time actually also contains some LW errors.

So you can see that this is very somehow close to GSW GSW FG certext and uh but it's different from our GSW FG because it allows holopic property not only for this encoding but also for public keys. So specifically we can first define algorithms such that given the some given some cipher or given some circuit and the public keys for inputs you can deliver public key corresponding to the circuit outputs without knowing any inputs to the encoding and similarly you can homologically evalate circuit over given encodings without knowing secrets. And but point is this algorithms also takes as input encoded integers and I'll elaborate this like why this x is necessary later and uh this algorithms output or encoding corresponding to the psychic output and these two outputs satisfy this equation. So you can see that the second term contains a circuit output but this is masked by the first time. So intuitively if you can like when like evalator some permissionless evalator computes this encoding over provided homologically compute circuit over provided encodings.

If evalator also have access to the this like first stamp they can obtain the socket output. More concretely uh in most most applications in most cryptographic constructions using this BZ press encodings. Trusted party somehow provides encodings for the inputs and also this first term and then like trustless evalator can compute the circuit over the encoding which makes uh encoding for the circuit outputs and if the this first time is also provided these two things allow evulator to learn the circuit output. But the important point is if the evaluator computes any not allowed circuit like a C prime or this output encoding will be like a different from this time. So that this S times SC part will be different from the uh one data provided by the trusted party.

So this implies that this mask part provided by trust trusted party allows the evaluator to run socket output but only for some specific socket. So someone might think or this seems to be like a more useful than FUG because while FG secret key allows decryption for all suffer text this allows decryption uh for only for some uh permitted sockets. But actually this is not correct because as I said our trusted party also need to send the encoded integers because homophic multiplication requires the knowledge of the uh input integers. So that our common approach to to overcome this limitation is combining FG over BC plus encodings. So intuitively uh we encode f cipher text of the private inputs and encode not the private input itself but the f cipher text then we evalate we simulate the f evolation algorithms over this business process encodings.

So more concretely trusted party will provide the encoding of their FJ encryption and uh uh the circuit evalated over encoding is defined as a homophic evalation of some specific socket and uh by using some technique we can also perform FG decryption without revealing FG secret key so that our evalator can obtain the encoding of the decrypted result only for some specific permited circuits then uh I think it's ready for explaining what these especially these two components means. So the first component homorphic PLF over encoding is a problem to compute or FG plation this aal means FG evalation. So like uh we want to evalate a circuit that simulates horic evolation of the PLF soland function over Bit encoding. And this second component snack verification over encodings means we want to evalate snack verification algorithms over the our BCC plus encoding as a socket and uh if we can make these components practical and uh also we if we have verifiable FG uh with practical performance uh we believe we can make practical IO or as long as some assumptions non-standard assumptions remain secure and uh we explained more details in our paper. Okay, let's summarize this talk.

So yeah, I want to tell you two messages. So one is IO is not just nice to have. This is essential for making it a really scalable and scalable private world computer. And the second the practical implementation of IOR is not a kind of distant idea or discovered from reality or not the idea from like a not in not the idea only in some s but the complete collection of technical challenges and as I said these challenges concretely means uh verify and the BZ plus encoding evolution for holophic PLF and snack verification and uh I hope like uh we can uh kind of yeah we can challenge these uh three components. Thank you for listening.

[applause] So do you have any questions? Uh

as far as

so your question is like why we I don't consider TE as a social

for specific uh I think just because like uh we need to trust uh like we don't want to add new trust assumption uh for introducing TE

get what

I get. I don't see why.

Ah, I see. So, okay, thank you for your question. So, we actually, yeah, we actually don't need to evalate proof for verify feature uh within the obiscated circuit, but this is verified by the either application contract or uh verif gateway contract. So in more detail uh when FG co-processor computes some horic circuit uh they will also provide proof of the holopic evolution and this is verified by any of the smart contract and if this proof is verified onchain or I expect this gateway contract will approve decryption of that output cipher text

right so you can have the platform sign the cipher text hash So what why why do you implement this?

Check whether the correct.

Yeah.

And then it

what? Oh, so so the conditional decryptor only says that you know I will only decrypt the cipher text as long as gateway smart contract sign it. Oh I see your point. Ah I see

like I think we need

so so there needs to be some sort of proof then then why do you need the gateway contract again?

Yeah so this is for making the implementation of IO agnostic to applications. So, so for example, uh if it's okay to

what does the gateway contract do though? So gateway contract will technically like uh after doing some horrific evolation uh this application. Okay. So the role of gateway contract is check if uh this output cipher text is ready for decryption or not. And in more detail uh this get by contract itself will check that uh the given cipher text is like a kind of okay let me explain the from basis like so first this gateway contract will manage some access control list such that uh for each cipher text or collect owner of the cipher text is defined uh by the application contract address and uh if the some contract request decryption for some cipher text.

It checks that this like a caller of this decryption API is a rigid owner of the given cipher text and if this is true uh it allows decryption or for this cipher text.

How does the gateway contract communicate to the conditional decryptor that is it is allowed to decrypt it?

So like uh it does not check. So basically it's just like a trust application contract because like uh okay so my point is like uh assuming that users only kind of delegate like a ownership of the cipher text to to some trusted application contract.

This tr trusted application contract will some uh good decryption policy for each application context. So like if this uh trusted application uh application contract trusted by uh owner of the cipher text uh says uh this cipher text satisfies some like application specific decryption policy uh this gateway contract can just like a trust this claim as long as this caller smart contract is uh collect owner of the given cipher text.

Okay.

Does it make sense? I I think we can keep discussion later.

Yeah, we can we can take it offline.

Thank you for a question.

Maybe [clears throat] about the setup ceremony. Uh is it n of n? Does it mean that no honest I mean everyone has to be honest in the setup.

So in n of NPC uh if at least one party is honest uh no one can no single party can uh get the hardcoded secrets.

Hello. Oh hey thanks for your talk. Uh just following up on that. So are you basically saying that for these app contracts, it's sort of like the access control list for the cipher text and then once those are approved, then the gateway contract can essentially evaluate it without the quote unquote decrypting. Okay.

Uh yeah, sorry. Uh my other question was um for the encodings that you were talking about earlier, is is that primarily for um like to to evaluate um the actual like I guess FHE cipher text cuz my understanding traditionally for something like uh uh for like the FHEVM I think you were you you showed earlier uh usually like those uh zero knowledge pro proofs uh require the um plain text input I think in what you I want to say you said integers or um the integer value actually for the cipher text. So is the encoding essentially a way to do the uh homorphic evaluations and verify that these were done uh but you do them through the encodings instead of having to have the specific plain text be known.

I see. So so the point of using this encoding is that like we want to allow decryption but only for some specific circuit output but also in your no interactive way. So this means for example if we assume this obscator is uh online and the evalator can always interact with this obscator or simpler solution is that uh user just performs f evalation and then makes a proof of the horrific evolation and uh that evaluator sends uh returns that circuit output uh encrypted output and the proof to the obiscator and the offiscator if obiscator confirms S uh this cipher text is for specific circuit output. They just returns a decrypted result. But this idea does not work since we assume this obiscator uh goes offline after publishing offiscation.

So we need to make some special secret key decryption key such that uh without any interaction this key allows decryption for some specific circuit output. But this cannot be useful for any other circuit outputs. And this is a yeah actually uh enabled by this s times se term and uh to make such term we we need to ensure that some corresponding public key or is like unique to the circuit unique to the definition of the circuit and also this is independent of the input since obuscator cannot know evalator's inputs beforehand in the setup. Uh in this example is the trusted party here the obusiscator.

Yeah like uh uh informally yes like formally like we have more complicated process to generate this s times AC and actually this time is generated during the part of the evolation but intuitively yes this proced and they makes some enough data to allow evalator to compute this s times AC.

Okay. Yes. So I just had one last question about the uh trust assumptions of the initial ceremony. So sorry if this is off base but my understanding it's something like uh functional encryption for example the the master secret key uh is that what is being distributed and is that so before that uh I guess the distributed key ceremony that the actual uh offiscated circuit itself needs to be encrypted via that specific secret key and then there's a distribution or can the dist can that encryption uh of the can that can the uh can can that process happen like while the keys are distributed? Uh, sorry, maybe I missed the last part of your question.

Uh, sorry. Basically, I'm just asking like um, and again, this could be off because I'm kind of basing this off of my understanding of functional encryption, but if you're if you're encrypting the the ciph the the the uh the offiscated circuit essentially with the master secret key, this is the thing that's gets distributed um between the parties of the like you said the end event. Um so does that happen like can can you distribute the keys and then encrypt the program or do you have to encrypt the program and then distribute the keys?

Uh okay thank you for your question. So technically like so in in the construction for decentral decentralized obscution we propose in the paper uh we first dist we first makes distributed secret keys for FG using standard some kind of MPC and uh but after that each party makes obiscation using their own secret key shares in independently individually instead of doing NPC for obuscation. And uh this like obscated circuit will output partial decryption uh for decryting given cipher text instead of outputting or print text itself. So like if you have like a n amount of the like n number of the obiscated circuit each of which outputs uh decryption series evalator just repeats the this like evalation of each obiscated circuit for the same cipher text and they obtain the enough amount of the partial decryptions but in a non-interactive way and by recovering using these shares they can recover the plain text and uh since each party need to obscate circuit which only uses their own uh secret key share. Uh they don't need to perform like a MPC for for obiscating socket.

They only need this for making some secret shares of the FG key.

Okay, cool. Thank you. Sorry. Appreciate it.

Yeah. Thank you for your questions and everything. [applause] Hello. Uh, I am Nicholas. I am with Phantom Zone and we have been working on local mixing.

You guys might have heard about local mixing throughout the talks so this week and essentially we are working on obuscation. Sora just talked about how IO is very how IO is very useful and of course there are still a lot of work that needs to be done in order to reach practicality but this is a theoretically a alternative approach to IO. So what is local mixing? And first it might be useful to talk about what IO is and this is just a quote that I liked from Hoy Jalin and the notion of indistinguishability was first conceived by Bareric in 2001 and it guarantees that the offiscation of two circuits which are computationally indistinguishable as long as they are both equivalent circuits. So this just means that if we have C1 and C2 which on the same inputs yield the same outputs these two offiscated circuits would then be indistinguishable to each other.

Now local mixing actually does provide something a little stronger than this but I will not go through too much in detail but if we have the stronger notion then of course we will have IO and there are already constructions of IO but they have their own problems. The numerous tools that they have used in the past are evasive LWE, multi-linear maps and learn in parody with noise. And of course, these have a good bit of structure. And these are also they have a high overhead. They might be inefficient as Sor just showed and they are quite complex in structure.

So one question that we had was what can we achieve if we try to do IO try to do IO with only first principles much simpler objects. This is where local mixing comes in. So let's suppose we just have a circuit. We just want to make a single perturbation. Just take a small subcircuit.

We will talk about how we take these subcircuits and just change it in some way. Maybe we increase the subcircuit in the number size of gates, number of wires, we decrease it. Just make a small perturbation. Do it again. Do it again.

Do it again. Do it again. And the hope would then be if we do it enough, the entire circuit while maintaining functionality is now obiscated. So very simple small probrations that maintain functionality. So how do we actually know that this is secure?

Well, our hope is that after all of these perturbations that it will look secure. And we have, I guess, two ways of actually analyzing this, but I'll talk about that later. But how effective are our randomized substitutions? Some questions that we need to answer and think about as we are making our substitutions is whether we need to expand our subcircuits, compress the subcircuits, maybe we just swap them of equal lengths. Does the overall obiscated circuit need to grow?

If it does, we think it does. How much does it need to grow? And is our injected randomness detectable? And if we do small perturbations like we just did, it will be detectable. So how do we actually hide this?

and how much do we need to hide it? These are all questions that we're thinking about as we are doing local mixing. So, first is how do we select our random subcircuits? And there are kind of two natural ways to do this. Just have two circuits here.

And the easy way is just to take contiguous subcircuits. Just randomly select random positions in our circuit and try to make a replacement in any way we can. The other way is to well not do this. we take circuits throughout the um subcircuits throughout the circuit. We of course will make this because if we try to replace these blocks at the bottom here without choosing them carefully, then we actually change the functionality of the circuit.

So in a bit I'll explain how we actually do this. But what type of circuits are we actually looking at? For us, we are trying to maintain simplicity. A lot of the previous tools very complex, but if we have very simple tools and hopefully we can get closer to practicality and so we're going to look at reversible circuits and to foligates and you might be concerned because well reversible circuits aren't just general purpose circuits but we can actually represent any circuit as a reversible circuit. So this turns out not to be a huge problem.

We look at the foli gates and in particular we look at gates R57 which just means that on our active wire we flip it if and only if the first control gate is true and the second control pin is false. And this actually allows us to get every gate that we would ever want. So in order to maintain simplicity again we look at just the single gate and then this is just for notation. So how can we see how well our perturbations are? Well, we can make replacements, many different types of replacements, but some of our replacements will look more random than others.

So how do we actually get this notation or notion of what is random and what isn't. Well, we want to have some sort of idea of a circuit isomeorphism. And so we are going to define that two gates collide if an active pin shares a wire with any other pin. So here we see that the first gate the active wire only collides with that third gate. But the second gate's active wire collides with the first gate and then the third gate's active wire collides with the second gate.

So we have some collisions here. We can't just swap these around. But if they don't collide, we can swap the gates around and we maintain functionality. So this allows us to kind of define a skeleton graph. First we just create a node for each of our gates and then we simply have a directed wire for each collision.

And I missed one but so this actually allows us to look at the skeleton graph representation of our circuits when we're trying to select our subcircuits. So instead of choosing simply contiguous subcircuits. We can look at convex subcircuits. And of course, because we're looking at convexity and in topological levels of each um level in our convex subgraph, our gates are guaranteed to not be colliding. Each of these pieces we can actually swap around in order to create a version of our circuit that is well that will have all of these sub circuits that we selected to be contiguous.

Then we can make the replacement and ensure that we have not lost functionality in any way. So overview of our steps in a simple way. We pick a random subcircuit. We select a random subcircuit with functionality and of course we have now two ways of sampling our random subcircuit and then we replace the circuit. Sounds simple enough.

So what methods do we actually have? Well, first let's just talk about rainbow tables because that third point of replacing the subcircuit is harder than it may sound. So how can we actually sample such circuits? An easy way is to do brute force and This seems to be the one way, but I I don't know another way. Maybe you guys do.

And what information do we store about a circuit? Well, we have its functionality. So, of course, they permute the bits that they compute on the number of wires and the number of gates. But if we were to store every single circuit with every single functionality, every single number of um gates and wires, there are a lot on just um n wires and m gates. We can actually compute how many there are in total.

And on five wires and five gates, we are already above 700 million circuits. And this actually doesn't seem that well this actually seems quite scary because our smallest possible circuit would be on three wires and one gate. So only on five wires and five gates we are already have an explosion in number of circuits. So we want some other notion of a circuit isomeorphism and that's where canonicalization comes from. We want to define a canonical ordering of our circuits.

Our choice of conicalization is might not be the right one but it's just a form of conicalization. So for circuits we can just simply keep permuting the non-oliding gates until we get an ordering by lexographic ordering that is the smallest and that will be our cononicalized circuit. Each circuit will have a permutation and for each permutation we can do the same thing. We can find a lexographic ordering of the permutations up to bit shuffling as well. We don't need to store inverses of our permutations just because if we have an an inverse already stored, we can merely reverse the circuit.

So this allows us to store less circuits. We only need to store our cononical circuits up to some permutation. And on five wires and five gates, we now only need to save about 3 million. Still a lot, but nowhere near as many as 55. Of course, this does didn't actually help much as we go more wires, more gates.

Our limit seems to be around five gates, six wires, seven gates, four, five wires, or sorry, seven wires, four five gates. So, we still reach an upper limit, but we can do much better than just storing every single possible circuit. So let's get into the first thing that we tried and this is the first method that was proposed in the paper if you guys have seen it. Um in two-phase mixing we have two stages. The first part we have an inflationary phase where we just take our circuit find random convex subcircuits and then try to make equivalent replacements with a larger number of gates.

So we are trying to inflate our circuit in order to give it me and so we have actual room in order to mix it. And then our second phase is the kneading phase. We just make replacements again using convex random convex subcircuits but now we make it so that the length of our replacements are equal. So we're not trying to grow it anymore. You can think of this as you're making bread where you first take your dough and you add more dough to make more bread and then you knead it.

You put the circuit on top of itself again and again and again. Hopefully maybe thousands, millions of times and hopefully the functionality will get randomized in the middle. So how do we actually analyze how we do Well, one way is to look at the heat map. The heat map, we're just looking at the Hamming distance at each circuit's position along the gates. So, let's say we have C1, C2 with 10 gates each.

We just look at C1 at gate one at gate two at gate three in relation to C2 at gate one, gate two, and gate three. And we can get a heat map of all these hamming distances. We also don't want to care about gate ordering because two circuits can be equivalent but non-oliding gates are swapped around. But we know that we can just compute the conicalization. An adversary can compute the conicalizations.

So we don't want to care about how gate ordering affects our heat maps. So this is an example of one of our early early tests where we took a 250 gate circuit and inflated up to around 20,000 and did maybe a thousand steps of kneading. And as you can see hopefully you can see along the y= x the circuit has not changed at all. So this was very bad. This is a very scary result because this meant that this inflationary needing thing wasn't even doing anything.

And it seems that our replacements aren't actually meaningful replacements. And in this in our early test, we weren't actually using our rainbow table in order to do replacements. We were just sampling completely random circuits. But as we know that many circuits don't look that random from each other because they may differ only by gate ordering. They may only differ by a bit shuffle.

So it seems important that we actually use meaningful replacements. Here we see that we actually have I believe this is like a million maybe two million um steps of kneading and it actually does look more blurry. So the heat map does look more random. And so hopefully if we did it more and more we would get a heat map that looked completely random. And so we we released the bounty and as you may know the bounty got this like they solved it and essentially what happened was they we released the bounty by starting with a 64 wire circuit with 1,14 gates.

We inflated it up to 12,000 gates about did many many rounds of kneading and then released the bounty with a $10,000 reward and somebody we managed to find the original functionality with even less gates. They even managed to compress our original circuit down to 987 gates. And the way they did this was by using the same thing that we were doing by inflating. We just sampled random subcircuits, made larger replacements. And no one will stop an adversary from doing the exact same thing, but instead of making replacements with larger circuits, they just make a replacement with a smaller circuit.

So this is the idea of compression. And you can make a rainbow table as well. And the attacker did use a rainbow table. One thing to note is that because we're only using a gate R57, two adjacent gates that are equal will just be the identity. So there are two ways to compress a circuit.

One, you can just scan through the entire circuit very quickly, see if any two gates adjacent to each other are equal and immediately remove them. Two, we can then look at our rainbow table, sample subcircuits, and then make replacements smaller like that. So we need to have an idea of how effective compression is and it turns out compression on identities can be quite easy because how can we make an identity? Well in a really easy way is to take a circuit reverse it concatenate it and you have an identity. But this is very easy to compress because as we said adjacent gates of equal functionality will immediately get compressed and so these can compress instantly.

On completely random circuits, it is actually very hard to compress them much. Maybe they compress one or two gates, but in general, it's very hard to do. So, so if we can get hard incompressible identities, maybe this can help us. But for now, let's just look at method two, which we call asymmetric butterfly. So, let's start with just a circuit.

And then in between each circuit, we insert a random identity, but it's a very stupid identity. We just take a gate, reverse it, and boom, we have an identity. And then we put them in different blocks so that each of these blocks look random and then just focus compression on these individual blocks. Then we combine them. We combine them.

We combine them. And now we have our opuscated circuit. And then we do this for many many rounds. And the hope here is that we can use compression instead of doing inflating kneading. We do inflation.

We compress. We inflate again. We compress. We repeat this again and again. And since each of these blocks are completely random, they won't compress that much, which it wasn't clear whether this would hurt us or whether this would help us.

But if we can make some form of compression and stop the blocks from just staying as they are, then when we combine everything at the very end, these stupid identities wouldn't completely compress it anymore and we would have something that is hopefully incompressible. So here's a circuit that we started with. Um the y-axis is flipped, but ignore that. And so we have an identity on 455 wires. We were working on sampling large identities as well, but I'm not going to go too much into detail.

So we have a 450 wire or sorry four on five wires we have 455 circuit gates um identity and this was incompressible at the time and we wanted to run offiscation on it. The reason we chose identities is because then we could have two different identities. Run offiscation on both and then compare how the offiscated identities looked. And with two rounds of this, it looks kind of blurry, right? But we can still kind of see the structure that we had before.

So we have these four X's and you can still kind of see them in this heat map. And this is after two rounds. And if you notice, we went from 455 gates all the way up to above 300,000. So this actually impases a lot because in the inflationary needing stage, we could do millions of rounds and get really nice heat maps. But now we can't do that many rounds.

So that's where symmetric butterfly comes in. It's a small variant of the asymmetric butterfly where we have the same steps essentially but instead of injecting random identities in each different random identities in between each gate we do the same identity and this is now we're purposefully making each of these blocks much more structured which would then allow us to compress it more. So it's the same idea. We want to compress these blocks so that when we combine them, they don't look they don't just immediately get killed because identities are super identities are easy to kill. And then later on it would be harder to compress them in the offiscated version and we have some examples and it looks questionable.

We can still see the identities that we're injecting all around and we still see a ver a line on y equals x. So there are some questions still but it did compress a lot more than it did prior. Another thing to note is how large are the identities that we inject here the identities are about 20 gates and red means that there's not much change. So we did essentially nothing here. And as we can see on this plot, most of the wires aren't doing anything.

And most of the gates because our identity started with five wires are still dominated along those five wires. So we need more. We need larger wings on our identities. So what if we increase it to about 50? Okay, we can still see the X looks a bit better.

increase it to 150. A lot better. And increase it to 300. Maybe not as good or not as much of an improvement, but we don't really see the X anymore. But if you notice, our circuit now has blown up to a million gates.

So, when it comes to practicality, this is not ideal. We want to be able to do more rounds. And here we only did two rounds. And this is an example of 10 rounds on really small wings. This is also on random shooting.

So here we have canonicalized all of our circuits before computing the heat map. And I just mentioned that we don't want the heat maps to reveal anything. But there's actually another layer to this. What if we just randomly shot gates around? When we canonicalize, this wouldn't do anything.

But if we look at the heat map, it doesn't get rid of the line, but it does blur things. And this idea of blurring can be very useful to us because what if we randomly shoot gates around and then in order so that you can't just reverse our shooting, you can't just canonicalize. What if we combine this with our previous methods of the butterfly so that when we insert identities that have colliding gates, you can no longer undo my random reordering of the gates. So I can fix this blurring with the butterfly method. And that's kind of what we've reached.

So we have multiple ways of doing this blurring. One way is looking at method one where we make replacements but instead of making just random replacements, we make much more structured replacements where we take pairs of our gates and then make the replacement that way. And that might not seem very useful because we're of course we're growing. We're going to do this butterfly thing. We're going to expand it anyway.

So maybe we don't need to expand this much. But what we actually do when we replace a pair of gates, maybe a maybe three gates, is that you eliminate the seam in between the original two gates. Let's say I replace G1 G2. The seam in between G1 and G2 is now gone. It's going to be somewhere in this random replacement that we've made.

Of course, the functionality is the same. But if we do this overall, we do actually see that we managed to blur the circuit. Maybe not that much, but we managed to blur it. And as you saw in the kneading that we did earlier, it does blur in the heat map. That one was incompressible.

But if we combine this with the butterfly method, we do manage to become incompressible. If we compress a ton, then of course it doesn't become incompressible. But in between the rounds, as long as we don't let it kill all of our butterfly wings, eventually we become incompressible. So we have two ways of blurring. We can make it incompressible.

So heat map attacks won't work because everything looks blurry. Compression attacks won't work because our butterfly method stops compression. And to me, those are the only two attacks. So there may be other methods in order to do this mixing. We chose these methods out of their simplicity.

Um it's very quick to compute all these things. But of course when you try and compute these heat maps on a million gates that's where it gets kind of tricky. Another thing we can ask is how can we sample random incompressible circuits? Um in the butterfly method we insert these stupid identities. But if we can insert incompressible identities in between everything then everything already looks random.

But this question of sampling random incompressible identities is actually quite hard. We have ideas for how to do so. But they don't seem to always work out. Maybe they're still compressible a bit. They don't look that random.

As you saw that 455 gate identity had four of these X's. So we want getting actually achieving something completely random is quite nuanced and we don't quite know an effective way to get small random identities. But maybe we have an idea for large random identities. But of course if we do something too large then our butterfly method explodes like crazy. And one question we could still have is what other attacks can an adversary attempt?

I don't know when, but we plan to look at this butterfly, look at these blurring methods, and hopefully in the coming months, we're going to release another bounty. And if someone manages to break it, we'll hopefully we have a new way of studying our circuits. If someone doesn't, then we have a much better idea of how to approach local mixing. Now, local mixing won't actually achieve practical IO, but it's another route for us to achieve IO. And then hopefully because everything is so simple, we can then later on reach practicality.

And that's it. And then if you want to see the paper that IO was originally or local mixing was originally based on, there it is. Um, everything is open source. I didn't have a link here, but if you're curious, you can come ask me. [applause] Yes sir.

[snorts]

Thank you for your interesting talk. So my question is like uh uh when you analyze the security of the local mixing uh did you find uh the security of the this security is essentially uh connected to the like other a year of the cryptography or like uh you think uh do you think this security is completely like a different from the like a security of the like other kind of cryptographic approaches? So the security of this actually is very comparable to some security notions in physics. That's where the idea of this came from. Um it's not fully understood how secure this is.

So our notions of security currently are mostly built on the heat maps, mostly built on the compression ideas. And one of the concerns about local mixing is indeed this lack of knowledge on how secure this would actually be in the future. Which is why we do require more attempts at attacks more adversaries. And so our hope is that as we build um a repertoire of different attacks, we can get a better idea of how to establish security of this.

I see. Uh yeah technically I just one thing I found is like I feel your second method I think butterfly method seems to be somehow similar to the uh like I think it name is uh kion randomization used for multilinear map based IO construction. So this also like a insert some random matrix and its inverse matrix between two matrices. And uh if you multiply these matrices this like a random path is canceled out because random matrix and its inverse matrix is multiplied. But if you only see kind of single matrix or if you multiply pair of like a bunch of the matrices in your increct order this randomization is not canceled out.

So that uh this like uh makes some privacy protection but like uh as far as I know I think the security provided by this randomization technique is also uh limited. So like uh maybe yeah such idea can be useful to analyze this like security of these like butterfly techniques.

Yeah. Okay. So, we're still analyzing security of everything, but yeah, as you're saying, there does seem to be hope as we are unable to actually compress everything down, unable to undo this randomization. Um, so there is hope, but of course, we don't fully understand it yet.

Thank you. [applause] Hello everyone. I think they got me into open the Overton window so that uh the exotic assumptions don't seem so exotic. Um pause. Okay.

I only have one joke which I always tell in these situations and no one ever laughs but I again I'm waiting for the slide so I'll tell it again. I went to go um see my plastic surgeon recently. His name is Phillip. One laugh. There we go.

Um yeah. So maybe I'll I'll one thing I wanted to say before the talk was that I was excited to come and speak to you guys today. partly because I love speaking about this stuff, but also because I think that um even though on the surface what I've been thinking about is very far removed uh from what you guys are doing. Well, one similarity is the functionality and I'll get to that in a second, but the other is the like style of thinking where um I find myself having to reason through a lot of assumptions, security assumptions, me and many other people through security assumptions that we need to validate. uh and there are like different strategies and approaches and I guess that's something that um this group also has to do um especially people working with um very novel assumptions um still waiting for the slides okay anyway so I'll I'll get get you guys going on the context so how did I end up working on this my name is Quintis I'm a researcher at flashbots uh and my background is actually in like algorithmic game theory and protocol design um so you won't be seeing too many polomials today.

But um about 18 months ago uh it became quite clear that TEES would be very very popular uh and increasingly so uh for the next for the foreseeable future. Uh and I guess maybe you guys can prove me wrong. Um but even I think if we do get very practical IO tomorrow, we'll still see TE usage relatively widespread and I can I'll talk about that later in the talk. Um, but I started looking into what we can do uh about uh the fact that TEES have basically a horrible uh trust model. Um, and I'll describe why it's horrible in a second.

But what started off as just like initial research trying to see if it's feasible to make improvements turned into a realization that we can make improvements and that there's appetite from sufficiently many parties with different specialties. um to make this change to to basically improve the the silicon security um or the world of silicon security and and that's kind of what I've been working on. Um so yep that this is me. Um and uh I will say that the things I talk about in this presentation will be very foreign to this group and many of the assumptions are not validated as well as you know the security of AES or something like that. Um, but at the same time, many of these are deployed today and seem to be working reasonably well.

And I'll I'll talk about that as I as I get through it. So, the main points I'm going to get through today is that secure hardware, especially TEES, is useful. Uh, I won't spend too much time on that. Um, and really the point that I'm trying to make today is that secure hardware can be made more secure. uh and we can do this in a way that's familiar to this like sort of broader cryptographic community that's used to reasoning uh about security in a certain way.

Uh and the implication of of those two facts should be that uh it's worth paying attention to. So very briefly what are TEES? Um the idea is that we can build a chip in a secure manner and embed a cryptographic key in the chip. uh the chip can then will then sign the software that is deployed on it uh in such a way that the user can be given a certificate. This certificate then convinces the user with some you know under some trust assumptions that they can securely interact with this program which has been issued a private key uh that is sort of confined uh to the use of this program and it's not available to anyone outside of it.

Uh because of this a user can interact securely with the program uh and is is you know assured of some properties uh even in the presence of an adversary and the the properties and the adversary um are sort of vary uh across different devices but broadly there are two properties that we care about. Uh one is integrity meaning that the uh program returns a corre correct result. We can't obviously force uh the chip to return a result can always be like disconnected from the internet or destroyed or something like that. Um and confidentiality and confidentiality um is underdefined. Uh I'll give my explain to you guys what I think we can achieve.

Uh some some sort of manufacturers advertise complete confidentiality that the program is completely uh hidden and the data that's sent to it. Um but um that's I think not reasonable. It's reason it's not not that hard to reverse engineer at least some of the the logic that's being executed. Uh in terms of adversaries a high level separation is software adversaries which is actually where where a lot of attention goes. I think these are sort of orthogonal to the things we really need to talk about.

Software adversaries are a problem largely because people are trying to deal with these very large code bases and are trying to you know uh protect against potential software supply chain bugs or it's in the cloud setting where the cloud vendors like uh allocating multiple tenants to the same physical machines. Uh, and so it's not actually a problem that we need to worry about or in many cases not a problem we need to worry about if we're willing to make the tradeoffs and have like only the program we're trying to protect running on a chip. The more complex uh adversary that I'll be speaking about today is a physical adversary. Um, and you know there are there are distinctions between physical adversaries, how long they have access to the device and these kinds of things and I I'll get through it. Um, but the way that the the hardware research community broadly thinks about this is that the adversary is sort of parameterized by how much time they have with a device, the budget they have, the equipment they have available.

Uh, and really I think we can just think about sort of the budget they have available as like a standin for all of those. Um, there is also some supply chain stuff which I'll mention in a second. So why the one of the graphics is a little bit weird but why pay attention to tees at all? like you know uh we have some other forms of cryptography that we can we can look at uh one one reason is performance right that's one of the main reasons people use T's right now that they just get get you attractive properties um at a fraction of the overhead of what FHE or whatever else you want to use uh the trust assumptions um certainly are very different from uh like what you get in NPC for example and so in particular uh collusion and undetect undetectable decryption attacks and these kind of things are typically mitigated with TEES. If you speak to people who have these like live MPC deployments, usually just like threshold signing.

They they usually require the parties to run TEES. And the third one and the one that I think that is like sort of a little bit outside of the scope of what IO can help to address is governance over physical objects, right? like a camera that signs its images um so that you know it's not a deep fake generated image or a surveillance camera that's attesting to you that it's not sending the the feed to the NSA. Um this just happened this morning. I learned about it this morning.

Open AAI is building uh a TE privacy team. Uh and this is like you know the latest in a series of many announcements. uh basically the world is becoming teified. Uh and I think this is a very important problem for us to address even if it's like uh ugly uh from in the cryptographic mathematical sense. Um if we don't address it, we're going to end up with a world where people are relying on this very flimsy form of security.

Um yeah, and that that sort of motivates motivates me. So briefly, what is the state of secure hardware? I'm sorry I'm going to fly through many of these slides just because I have a lot to say and I would love to have questions at the end as well. So what is the state of secure hardware? Um this is a simplification but you can kind of separate it into like different points in the trade-off curve that people have tried to occupy.

Um I'm also reducing many dimensions here but on the one you have sort of these cloud TES you've heard of Intel SGX, TDX, AMD ACV, these kind of things. uh these guys are just juicing out performance and doing the minimal to be able to claim um you know do the GDPR tech tickbox basically um the these typically don't offer any real physical security on the other extreme we have very small very limited devices like secure elements the chips in your credit cards uh your hardware wallets these kinds of things uh and these guys uh can't do much these chips can't do much but they have much stronger security than the cloud tees I should mention that basically all of the hardware ecosystem is completely closed. Uh and so there are just trust assumptions implicit in that. Uh but at least from a physical security perspective, you have this kind of separation. Um, and one reason that I'm excited about what we're doing is or what this like ecosystems new demand is representing is it's basically just asking the hardware hardware industry or at least I am and I think we are implicitly with the where the dollars are going um for more security.

Um, and part of the reason that that part of the this like space is is not doesn't have a box in it is because there hasn't really been that economic demand for it. In fact, what we've seen over the last 10 years is that people have removed security features from uh especially the cloud TEES to juice performance because the the use cases just weren't there for for better security. Um there's also some other stuff on here uh like gaming consoles or mobile phones that it's kind of hard to place them because they haven't been studied that well. Again, the whole ecosystem is very closed. Um but the reason I put those boxes there is just to sort of communicate that there is a very wide array of devices that have some security features in them.

Uh and they they managed they managed to achieve some some level of protection. Um yeah so because of these like security trade-offs there bunch of like basic preventable attacks that have been published recently. Um these are not actually interesting research problems aside from their consideration for performance. Right? So some of these things we know how to defend against them.

The question is with what overhead? Um, and specifically these attacks, uh, actually I'll come back to that. I won't describe it too much. It's it was just an absence of encryption of the the way data was stored. Um, so a story I wanted to include in here to give you an idea of what's going on is the Raspberry Pi.

Uh so Raspberry Pi at Defcon 2024 decided to do a public bug bounty on their the security features of their new chip. Um the one which is very uncommon. People don't do this in the hardware space. Good on them. Uh one of the submissions to the bug bounty was like very interesting.

You can see sort of a screenshot from that report over here. uh and basically what happened was that uh the key storage mechanism which had been believed to be secure for a very long time uh was broken quite easily and it demonstrated an easy methodology to to take it apart. Um, and this sent waves through the industry because it is a mechanism that had been used in many chips. And if you read the report, they say, well, we spent 90% of our time reverse engineering actually what this mechanism looks like. And then it was easy to break it.

And that's a pattern you see across a lot of secure hardware research. And the other thing they said is, oh, we were waiting for a legal window in which we can actually attack this chip. we kind of thought that this o this IP we kind of thought that this mechanism was broken but if we published it on another chip uh they probably would have sued us and we wanted to avoid that and so there's basically just a lot of lack of opportunity to to uh examine these things properly another example is ukle this is on this is on UB keys it was actually a software based attack but it would required physical access to look at the power channels and the reason I mentioned that is because that was a very highly certified chip very certifies to be secure and the hardware industry, not the academics but the industry really likes certification which is uh not very good. Um on the supply chain side of things uh there are some ways of checking that devices are not obviously backdoored. There are ways of checking it very thoroughly which are not very widely implemented.

Um there are many historical examples that show that uh um the standard throughout the industry is not very good. Um and even for the for the supply chains where the manufacturer is checking or whoever's at the end of the supply chain is checking a bit more thoroughly that isn't exposed to the end user and so you can't really verify if if the supply chain if there's like a back door basically in the chip or in the low-level software um yeah so to summarize uh people have occupied the extremes of uh the kind of physical security curve I wouldn't say actually the extreme of the security curve but it because there's a third dimension of cost. Uh but basically very small low performance and like pushing for security on the other extreme for performance. Uh closed source makes it hard to validate assumptions. The supply chain verification is an issue.

Uh and that you know I've spoken to a couple of people who are very enthusiastic about the idea of like unconditional security like we just have this security assumption and no one has ever break broken it. No one ever will uh or like the set of security assumptions that comprise the chip. Uh but for [clears throat] all intents and purposes, we assume just that there's a cost of attack and we're trying to make this very high. Um um and then you can build protocols on top of that to amplify this kind of security. Okay, so that was all just kind of context.

Very gloomy, very sad. Um but I think there's something we can do about this, which is why I'm talking to you today. And so let's structure an approach to to dealing with this. So firstly, just like what what are we talking about? Well, the main functionality we want to uh um enable here is remote attestation.

Meaning that the remote user can be convinced uh that a program is running with confidential confidentiality and integrity on the device they expect. And so we we imagine the adversary uh builds a device uh they can choose whatever structure it should occupy. this oops okay this um device gets sent to some uh certificate authority inspection kind of mechanism and we can choose how we implement that and that's sent back to the adversary uh the certificate authority should then like generate a certificate basically uh and send this to the user uh and then the user will interact remotely with the chip if they if they want to um this is sort of just like very abstractly how I think the flow should go uh but today uh the certificate authority is basically just the same as the manufacturer uh and so there isn't any like actual separation but the separation of roles is important going forward. Uh also if you have guys have any uh no actually let's save questions for the end. Sorry.

So okay so uh in the right the title of the slide is incorrect. It should just say defense strategy physical defense strategy. So there's um one thing we want to achieve and that uh that should basically be that the adversary uh should not be able to physically alter the structure of the chip beyond a certain point without uh irreoverably destroying uh the secrets that they that they're trying to attack. Once we have that assumption then we can build defenses uh based on the physical structure of the chip. And the physical structure implies like some level of noise.

it implies some level of imprecision for fault injection uh because there is basically just like layers of physical matter between the adversary and the secrets they're going after. So tackling the first problem uh first uh how do we prevent the adversary from making very profound uh physical changes to the structure of the of the device? Well, puffs physical and clonable functions are an interesting primitive here. I could have done the whole talk about puffs. They're very interesting.

They're a relatively wellstudied phenomenon. There's a object there's a abstract mathematical definition and then there's like the actual practical thing that people use in silicon. Uh and puffs are interesting because they say um let us derive a secret based on the physical structure of the chip. Uh so in the manufacturing process despite the best efforts of this trillion dollar industry every chip looks different just because of the physical the difficulty of getting precision at a phys in physics. Um, and if you I'll show you guys an example in a second.

If you structure your circuits correctly, you can harness this this natural variation uh to give every chip a unique identity. Uh and now the game is can you set can you design uh the puff so that um the identity changes irreversibly if someone makes a hole in the chip basically uh and so that the secret is there's sufficient entropy between the devices so you can actually use this as a as a private key uh and the the use of puffs as private keys is like very common or not relatively common it's done in industry that's not a that hard of a problem uh it's also used as an invasive attack countermeasure uh but that is one of the like less tested assumptions in in public. Uh and of everything I talk about today, I think this is the most uncertain problem. Uh not that we don't have a good direction, but that basically we haven't done the physical evaluations and that um yeah uh most of the academic evaluations are done in in simulation or only for the entropy side of things, not the invasive attacks. So what's an example of this?

Basically, imagine that your logical design says we have these wires and they're equally long. Uh and uh the the output of the system should depend on which wire uh which wires signal terminates first. Uh the logical description doesn't tell you which wire that should be, but the physical variations between the chips does. Uh and it turns out that you can use this kind of an approach to uh yeah realize puffs. Um I won't talk more about puffs because I'm running low on time.

Uh okay, non-invasive attacks and this is actually something that'll be very interesting to this community uh because most of the counter measures are based on things like leakage resilient cryptography uh or like as a subset of leakage resilient cryptography. Uh it started a little bit before this but basically the seminal papers by Yuval Shai or this ISW basically uh with a question can you guarantee secrecy if an adversary can eaves drop on your brain. Um and yeah there's a there's a lot to say here. It's a very mature uh field of research. Um and uh what's very promising about it is that there's a mature sort of pipeline going from uh very abstract theory connecting this kind of uh research with um the rest of cryptography all the way down to practical physical chips.

Um before I say more about what the kind of countermeasures look like, this is the electromagnetic radiation coming off an ARM processor doing division on different values. This is okay. This is the average of several runs. But you can tell that the electromagnetic electromagnetic radiation gives off a lot of information. A lot of it's easy to ease drop that way.

Um and so what do what do these counter measures look like? Just like with the rest of cryptography, you exploit a uh asymmetric uh relationship between the attacker and the defender where the defender pays some polomial penalty uh to you know put a exponential penalty on the adversary. uh and in the case of these kind of like physical side channels, the uh defender is paying in terms of latency of the computation or in the surface area cons like the number of gates basically in the circuit and the adversary uh pays or like is punished in terms of bits per second and if we can make the bits per second small enough then it requires like a infeasible amount of time to extract a secret. Um so the like high level approach that's most uh promising here is basically like running MPC on the same chip. So there's it's one party but there's multiple circuits that are executing over different shares representing the data.

Um and it turns out that you can you do all these reductions to like relate the amount of noise that the adversary is experiencing versus the number of shares in your computation. I won't actually go through the history of this field. I wanted to point out that it's gone through several iterations where the theoretical models have been adjusted to be more realistic back and forth. And then eventually uh in 2020 there was this notion of arbitrary composability. And what used to be a very um arduous thing to implement now became something that you could do automatically basically with like a a compiler taking an insecured circuit to a secured one.

Uh and so in 2021 the first like automated generation of secure circuits was done. Um and now the tools are getting much better. Basically the blue you can see is the is the automated uh generation of these secure circuits. Uh and the colorful ones are the sort of bespoke handmade ones. Um and this is very important because it turns out chips are very complicated.

the circuits are very large and if you have to pay a bunch of PhDs to make the thing secure, you'll be bankrupt and probably it won't be secure because it's there's human error involved and you'll only have the chip in a couple of decades. So the automated stuff is very promising. Um so where does this leave us? If I basically a similar trajectory has has gone down for fault injection. it's a couple of years behind.

Um but through the use of electromagnetic pulses or alterations of voltage, the adversary can also inject faults in the circuits. Uh and through using redundancy and just clever encoding schemes, in particular pol polomial um secret sharing or masking. Um you can uh protect against these kinds of faults uh relatively effectively, but the cost is still a bit bit high. Anyway, okay. Uh leaving that aside, assuming we've fixed fault injection and we've implemented masking in a sufficiently performant way, where does that leave us?

The adversary shouldn't be able then to distinguish between the different data being fed to an operation like the different uh values a division operation is operating over. But the adversary can distinguish uh different instructions from each other and it can obviously monitor information leaving the chip. In particular, it can monitor the communication with offchip RAM. Um, you can encrypt the data, but you still have to tell the RAM controller which locations you're accessing. Um, oh, okay, we went through that.

Um, and this uh this leads us to this property called memory trace obliviousness. Uh, which may you may know from uh interactive NPC. Um and the basic idea here is if a program satisfies memory trace obliviousness if the adversary can monitor all the instructions know the sequence of instructions and know this the sequence of uh memory addresses that were accessed um but cannot distinguish uh the secret data um and we can design the processor to make this make it much easier to realize this like for example if at every clock cycle you execute every instruction um yeah this this becomes much simpler and so that would be more than just implementing masking. Uh so I won't go into that too much. Um Oblivious Labs has done some really cool stuff in doing efficient implementations of OAM which helped to realize memory trace obliviousness.

Um it's gotten practical recently. So Oblivious Labs is like Ela she basically and her PhD students. Um if you guys are from the NPC world I guess you'd know her. Um yeah uh you hear about um Spectre meltdown all these sort of like uh out of order execution speculative execution kind of attacks. Um we could just not speculate on data uh and not have to worry about those but that gives you a performance penalty.

Fortunately there's a bunch of research that allows you to like have the best of both worlds. Uh I don't want to go get into that but I'm just uh mentioning it. Um I should talk about the supply chain. That's one of the things that crypto people really care about. Um, basically the imaging technologies are pretty good, but they're destructive and expensive.

And so the question is how can we when I say imaging I mean like physically uh um visually well through microscopes inspecting a chip uh and comparing it to a design. Uh that technology is reasonably good but expensive and slow. So, we're trying to do that in a way that's like more scalable and non-destructive. Uh, and this is some interesting work in that direction. I'm running out of time, so I won't talk about it too much.

Um, and there's actually a bunch of different techniques you can combine together to make these kind of uh inspections more thorough. Like for example, you can design a chip to be more easily tested. You can monitor the power power uh consumption properties and these kinds of things uh to detect if there are alterations in the logic. uh this is also a developing field. Um but I think it's maybe yeah it's probably also the least pressing of our concerns.

I think there's just a lot of other more more important problems. So if the chip which we're working on doesn't perfectly 100% guard us against uh Trojans that's probably okay because also really hard to probably really hard really expensive to insert at least um at least the most advanced ones. Um so okay so now this is kind of the main question that I get maybe it's strange that that I address it at the end of the presentation then but basically the question is okay so I give you a physical chip and I give you some mechanism through which to compare the physical chip with an advertised design we assume that works 100% uh with 100% guarantees um what then the we assume the user is remote so this physical inspection process means nothing to Well, basically you then have to bootstrap some protocol where you have a decentralized set of of uh uh inspectors um and the logistical aspects here become the the bottleneck. But imagine some you know hypothetical world where we could send the chip to end verifiers who could non-destructively image this chip. uh then the end user only needs to trust one of those verifiers or the signature from one of those verifiers in order to sort of uh buy into the mapping between the physical structure and the underlying uh cryptography.

Yeah, thank you. Uh I'm nearly done. Um open source is really important and we need to validate security assumptions. Uh like I said, it's currently really hard to look at commercial chips because they have NDAs and all these different kinds of things and and um that makes it hard to do. I won't actually talk about this too much.

The only the main point I want to make here is that there's levels to open sourcing silicon. So there's some IP which which belongs to like the chip design team and they can open that up. But then these then these there are these things that like uh are analogous to software libraries basically uh and they can't open source those um those IP blocks uh without getting permission from the uh the vendors of those and then there's the stuff that sort of def depends on the fab on the on the factory that makes these things and that's the the hardest kind of a thing to open source but people are working on this including Vitalik's new um uh vena initiative which you guys may have heard of. So, closing thoughts. Uh TE's are very important.

Uh if you guys succeed, maybe less important, but I still think important at least for the physical world. If you guys don't succeed for for the collusive world of collusive aspect of NPC and if the FH people don't do a good job, then also just for performance. Um we uh need to bring cryptographic thinking and verifiability into this field. The researchers do have this kind of uh when I say cryptographic thinking I mean uh deriving proof of security from minimal assumptions. Uh people have done this especially for the non-invasive attacks physical side channels and fault injection.

Uh but for the like invasive attacks like puffs and and and for the supply chain uh that has been less the case and that's something I'm trying to work on. Uh one thing that's just very hard here is that we have long cycles and high costs. So you want to try something it takes like many months if not years to actually bring it into a physical form and then to validate that is expensive and if it's broken you have to go through the cycle again. It's much it's it's not as easy as like doing a you know uh basically a software test to see if there's any correlations. Um many assumptions uh need to be made.

You can't do it off like just a single assumption. Um but at the same time despite all these challenges there are very many lowhanging fruits. Like I said the cloud TES right now which everyone's relying on are like just built purely for performance with a little bit of security basically only against software adversaries. Uh and so it's not that hard to get them to be much more secure. Um and I think not crazy hard to make them much more secure without ridiculous overhead.

Um, this is a new meme I'm trying to spread throughout the world. Sink it into your eyeballs for a second. Sovereign silicon. Very exciting. Um, and yeah, basically most of my time is now going into what uh is called the trustee initiative.

At the moment, we are working to produce an open-source physically secure TE uh asteris asterisk in the next three years. But we're also supporting some secure hardware R&D around puffs and side channels and these kinds of things. And I have left very little time for Q&A. Uh but yes, thank you very much for indulging these exotic assumptions. [applause]

That sounds great. Are you putting your hand up for a question or oh there's a

yeah thank you for your interesting talk. So uh I have two questions. So first point is about uh parf puf.

So as far as I understand I think weak prick puf is just a constant function which returns some secret unique to each device. Yes. So can we restrict that like uh or this like a PUF output can be available only for some cryptographic population without that that is how it works right so the the puff is like a physical uh object you stimulate it outcomes some value u which you can interpret as a secret key with a few extra steps uh but obviously if you then just read like if you make it possible to just read out that secret key with a function call then obviously it's not secure so basically you have wrap that with some like signing logic or or encryption logic or whatever you're doing.

I understand. Thank you. So my second question is like uh about the idea of running MPC in the same hardware.

Yeah. So I don't understand the like why it kind of makes sense from the cost performance perspective because let's say like uh we need uh x amount of cost for attacking like one chip which has one threshold one secret share and uh even if we have like a t uh n like a chips and like a socket of chips each of which contains different secret shares we just need to repeat the same attack or n times so that attack cost is just n times like x but we need to increase the area size of the hardware also n times so like uh

what's the

yeah so so the question is why would I run npc on the same chip when I could run NPC between multiple chips when doing it between multiple would have a higher attack cost

yeah so like what's the

biggest motivation to increase

yeah it's it's performance right if like I say running MPC on the chip that's basic you can do that in in a circuit in like a few clock cycles and a few like nanconds but like you you couldn't even get a packet to another chip in a couple of nanconds right so from a performance perspective

uh so sorry I think we can discuss later yeah

okay okay

yeah thank you

thanks for listening and the questions

thank you we have a panel Oh,

this is

Thank you. Uh so hi guys um my name is Rico and I work with Sora on IO in the Machin IO team and uh yes so basically now we have this panel and all the speakers are here and uh we're going to discuss more. So I think uh the first question that I want to ask uh the panelists is more about their personal path into IO or actually let's say first uh because we have like Jay and Sora here are working on IO from more like mathematical let's say cryptographic based approach for the security of the offiscation while Quintus is more working on a hardware approach. So I think during this panel we can just say offuscation as a way to hide as a let's say this kind of abstract compiler that allows you to hide the inner working of a program and give you this offuscated program but we we're not going to specify or maybe when we specify we're going to uh explicitly mention it how we're going to do this offuscation either by mathematics or with uh hardware. So the first question that I want to ask the the speakers and the panelists is how they got into IO or how they got into fuscation and what was the original motivation for you to join this kind of very hard challenge.

So we start with Quintis maybe.

Uh thank you. Yeah I I consider I don't ever say this but I consider myself to be working on IO just very exotic assumptions. Not that I exactly know the mathematical definition but anyway um the reason I'm working on this is because I was doing mechanism design basically and saw the power of tees uh in the crypto space and beyond uh and like I said it became clear that they're going to be deployed everywhere uh and used for many things uh but if we don't address them and address the the address the shortcomings and tees. I think we basically build a world in which we rely on the extension of the good favor of large organizations Intel, Nvidia, the cloud providers, which is I think uh you know a marginal improvement over what we have today but a significant uh shortfall over what we would like to achieve one day.

Sorry.

Yeah. So basically modification is almost same as what I talked in in the first part of the talk but like uh more intuitively I think. Yeah, this is because uh I want to let smart contracts have some secrets that like a no human can know but but like everyone can use or in some restricted way or in more like a stronger like a fundamentals trust models and uh yeah my motivation I think I originally started is because I thought uh we can make some strong program uh we can makes programs as strong as like a physical laws like in similar to no one can modify like stop physical laws like we can make our programs on E3 such that no one can alter the program no one can stop that no one can be ruled out or even for deployers and uh but like a later I found its functionality is limited because it's completely public and it can only modify some state on public on Ethereum itself but but like by using cryptography uh we can extend this functionality and uh especially if we can make practical IO without introducing any additional trust assumptions uh like we can naturally extends this like power of smart contracts and uh yeah we can make more kind of strong and elegant smart contracts and uh yeah this is yeah so this is what the conclusion is like Yeah, we can be more smart contract can be more close to physical loss.

Thanks J. Uh well I so this the reason that I working on so I started working on I would say offcation or offcation based on more exotic assumptions um is because I so so initially I was working on encryption and so on and so forth and other cryptographic primitives. There could be multiple reasons we could figure it out. But what I really want to build at the end of the day is to is to have a like we think of Ethereum as like you know there's this the world computer. That's one way of looking at it.

What I want to have is like a way to have certain parts of this world computer encrypted hidden from anyone else. uh and be it uh hidden be it with a with with with cryptographic guarantee like um it's I think it's very hard for us to imagine that um one would be willing to use this computer if I have to trust an MPC committee for it. Uh the only way we can do that is we have trustless cryptographic primitives or even like trustless t in future to be able to sort of like um claim that you know you can use this thing as as a user of blockchain systems.

I would say that I think your trustlessness is stronger than my trustlessness because you for me you always have the supply chain issue

right I see.

Yeah. Unless you inspect it yourself, but that's

so I think you you both alluded to that also Quintto a bit, but I think in the previous representation we never touched on the actual application of this ofcation. So what I'm what I wanted to ask you is like u u yeah this sounds very cool in in theory and sounds a very challenging uh task that we all want to solve but like what you think is going to be the moment or the application that is going to drive uh demand for that and therefore also drive researcher and more resources to to try to solve this task. So maybe an analogy would be we know that ZK got this big boost because of uh ZK rollups that you know they made money flow into the market into the business and into research. What do you think would be the the analogous uh case for for for IO this time we start with with you Sora? I yeah so I think in short term shortterm application can be like a trustless bitcoin breach because as far as I know this has been a kind of longstanding program and there are various like services for breaching bitcoin to eum but uh I think all of them write on either trusted hardware or some trusted committee uh different from bitcoin miners and ean barers So like uh and also from technical perspective uh if we can make witness encryption practical it's like somehow we can make our trusted bitcoin bridge by using non techniques.

So yeah, I think this can be a kind of one milestone application for both from like a demand perspective and a technical perspective and in more longer time the application which seems to be like important and interesting can be yeah you're running the AI inference process entire AI inference process within the obsiscated circuit and this is especially important When people start putting their private data, not only some text data but also like a video like photos, sounds uh they like uh in their like a you like a usual daily life and also like a when or one single AI model AI agent or stats like using not only one person's private data but also like matchable users data or when like a country like a city start using some AI services for public services. So that uh single AI model or not single but like some AI models need to like uh make some outputs based on like uh a lot of number lot of number of peoples private data of a lot of number of peoples and in such cases we need some like our kind of private world computer and uh or if we can implement if we can like uh run obiscation in your data center to make every output of the kind of air services like chachi pity. I think this can be a super great milestone and what is the trustless bitcoin bridge and why why this is important?

Uh so your first question is what is the trust? Yeah. Yeah. So basically this is just a bridge between Bitcoin blockchain and ERAM. So you can if you deposit your bitcoin into some like a specific bitcoin address you can issue a wrapped version of the bitcoin or easily and if you ban this wrapped bitcoin uh you can withdraw bitcoin on the bitcoin blockchain and we say this is trustless uh especially when we don't need to rely on like uh any trusted hardware or any like uh committee like uh beyond the bitcoin and eum miners Russia partors

which is the case today.

Yeah, except for initial trusted setup.

Yeah,

what's your take?

Uh well h use cases. Uh no [snorts] I I think um okay it it is nice that you guys touched upon trustless bitcoin bridge because uh if you if I'm not sure whether whether whether someone is familiar with the numbers but the amount of bitcoin that is logged on MPC bc based committee bridges from bitcoin to ethereum is like just less than one person total supply of BTC. So that showcases that people understand that these systems are these MPC based systems are fragile. No one's willing to trust the money on them unless you're a DJ speculating stuff. Um and this sort of like uh you know goes uh this sort of is a good bridge to my next point which is that you know we would be able to have private smart contracts or have you know this this encrypted private world computer using MPC committee probably you know have MPC stuff or probably TE's as well.

But the amount of value that these committees can unlock like the amount of value that you can lock or like keep private or like you know put inside these systems is would not be greater than the amount of value that you that the amount of value that is required to break them. Um which is obviously not you know trillions of dollars. It's like I don't know what is for TE's I don't know

I think a couple thousand I think a couple I think it depends on the TE but I think honestly No, actually less if you have physical access to one of these cloud TE's like 50 bucks maybe.

Yeah, but probably you can figure out that the that they would not want to list their shares in the in the NASDAQ.

Yeah. If if it's in a data center then it's economic argument.

Yeah. But I would say that it's not I don't know more than the market cap of these companies. But if you sort of like look at the trajectory of Ethereum and Bitcoin, they're going going to lock I don't know trillions and billions of dollars. If you want to have privacy in those systems, you would want some cryptographic guarantees. Uh you would want to trust into math.

You cannot trust on uh you know hardware or I don't know I don't know how the trajectory of hardware progresses. Probably we are able to do that with hardware as well. uh but I don't I I don't think we can rely on MPC systems at least

and uh yeah I also for quintus I also want to extend the question to your experience with application because I know you work with flashbots so they use tea in production right so maybe the question is like also what's application today and what will be the the moment in the future

right right so um coming from a game theory mechanism design background Most of the most of the like um issues that people think about in mechanism design are about information. Can you get in agents to reveal truthfully their information? How do you deal with this information? What information do you expose to agents? You know, it's all about information.

And so having means to technically uh control the flow of information is very important for this like uh mechanism design where you can't rely on a trusted party. uh in like concrete terms, um in the blockchain space right now, basically there's all of these like uh uh problems that sit between the user and the blockchain. Sometimes it's just getting a transaction on the blockchain. Um threshold encryption is a solution that could work here again with some trust assumptions, but uh from an incentive perspective, people don't do it because for a variety of reasons, you want to do computation on the transactions before you put them on chain. Um do you also want to do like counterparty discovery?

So one here's a very concrete example. I am a user. I want to do a trade. Uh someone else has some like a trade routing algorithm uh that can help me execute my trade effectively. That trade routing algorithm is proprietary.

It's how they make money. My trade is sensitive data because if if they learn what my trade is going to be, they can frontr run me and make money off me at my expense. Um ideally we get these parties together. Right now we're doing it by putting the the algorithm in a TE and having the user send the data to the algorithm uh and basically delaying any information leaving the TE by let's say a day a parameterizable amount uh and except for data flowing back to the user. So the user gets their like uh their like routed trait for example.

But this but think we just think about the internet right uh social media apps search um those are probably some of the biggest areas that we haven't gone into data uh ad auctions uh more than search uh and I think the reason the crypto industry hasn't even tried to go that direction is performance and because we don't have anything for privacy and those are all databased uh applications

right so uh I think to conclude I want to ask you a more speculative question I These were already speculative but this is even more speculative. So um offuscation is is often deemed as this kind of uh endgame of cryptography this holy grail of of cryptography that basically it seems that like once we get there there's like nothing else to to work on. So it's game over and we're just going to have holiday. I don't know. So I'm wondering in your opinion assuming that we get IO assuming that we get it in a practical way what's going to be the next thing the new challenge to to solve after that and uh I need to ask Jay first just for I see you you wanted to speak Sor

so [laughter] my answer is uh quantum cryptography so like a crytography using quantum features properties of the quantum bits. So for example,

so explain why this is different from uh postquantum cryptography.

Ah yeah right. So postquantum cryptography is still using classical only using classical computers but like their construction is secure even against adversely who can use quantum computers. In contrast, quantum cryptography uh uses uh quantum bits uh by some some like even by some trusted uh honest parties and uh this also uses leages uh properties provided by contemps. So for example, yeah one good example is like a oneshot signature. So if you have sign uh if you have signing key basically you can just re reuse the signing key many times and this is why we need blockchain to prevent double spend attack but like uh you can just sign sign two different conflicting transaction using the same secret key.

But if we can if we can use quantum based oneshot signature uh this signing key can be uh protected by cont as a contam or super position and even if you have this contam bit or you cannot reuse the same secret key same secret content bit uh for signing uh two different messages. So in other words or if you can verify that you have signature by uh by generated by this signing key in this oneshot quantum secret key uh you can already you can already confir convinced that like uh the same key will not be used by for any other message. [snorts]

Right? So the difference between uh classical cryptography and quantum cryptography is that uh um basically data have this property of just uh decaying after being used right. So you cannot just copy the bits

but they just uh

as soon as you consume them they just uh disappear or you cannot

you cannot clone the private content.

Jay what's your take on this?

Right. Uh well it's it's a very fascinating question and to be very honest I'm I'm a bit shortsighted on this. I think if in case we get off skation then I would say it will at least take a decade or like half a decade to to build the tools so that the world can use it and I think my my focus would be that

okay so that's then uh prompts me with another question like how [snorts] would people in five 10 years use offuscation and how would they what's going to be this offuscation like how does it how is it going to look like

okay uh right uh it's is you know at the moment I just only have tools with the my mind can only work with things that we know right um and um seems like if and I'm going I'm going to be again a bit shortsighted and be like you know I'm going to talk about the things that I know you know I don't know a lot of other methods of doing offication let's just say local mixing for instance uh I I I would say that uh if local mixing works out and you know hopefully I I it's a very speculative idea u I I I can clearly see a path of building a virtual machine out of it. So the the cost on the developer side would not be much. The the majority of the time would be spent on trying to figure out how can we build a VM and make and endo this particular thing a circuit with a state. Um I'm not sure whether the same path would be followed by you know the the encoding method that sort of was describing about but I I see a general pattern where you take a cryptographic method that initially works with circuit but turns out that once you sort of like once you can once you can sort of like build a universal circuit using this cryptographic method everything is solved on the developer end.

Um does it make sense?

Yes. Yes. Yes. Absolutely. Hello Quintus, you have any opinion on this?

Yeah, I I want to design the mechanisms, but so please can we get the tools? Then there's a lot of mechanism design stuff to do. I you guys can do the rest.

Yeah. Yeah. Yeah.

Yeah. I I don't I don't I don't I I think what one uh limitation from my my you know untrained understanding is that you guys don't get statefulness from from IO. I don't know do do you

can you can you implement oneshot signatures with that?

I mean I think if we also assume uh uh Ethereum trust in Ethereum we can actually do oneshot signatures

if you have broadcast if you have a public broadcast that everyone can trust like a DA

then you have statefulness. So one one question uh yeah yeah

you cannot do

oh yeah yeah that's true

if you want to use signatures to build a blockchain

yeah yeah yeah

go back

yeah yeah

isn't doesn't uh honey badger is a consensus protocol that's built where every node is a consensus protocol. Okay, that's completely besides the point. But but uh yeah,

all I'm trying to say is that there's a difference between what

right yeah yes so we have real one one shot signature with quantum cryptography right

with the lack of I mean to our best understanding today.

Yes. Yes. Yes.

If my understanding is correctly maybe I think are like if my understanding is correctly the original construction of the oneshot signature was attacked later right? Yeah. Yeah. So this is why you said we don't know whether this is secure or not. new assumptions.

Ah, okay.

I see. I see.

So they come up with a new science weird new assumption.

Yeah.

Maybe they are safe.

Yeah. Yeah. Nice.

So one last question just for you Quintus like I think in the paper that we shared read our paper the paper we shared um we proposed this construction we actually we try to minimize what's inside this offiscated program to the minimum and we kind of outsource stuff to external more efficient stuff which in our case is FHE rather than offiscation. I'm I'm trying to understand and actually we we claim that we only need this program to be offuscated to then have offuscation for any program. Is it also something that you sort of like a design pattern that you follow with TE or it's going to be like I don't know uh millions of TE for each application?

Yeah. So this is a very practical concern that people think about even for today's today TE's today call like TCP minimization like trusted compute base the more lines of code or more like pieces of logic you trust the larger the chance that there's some uh mistake in security either software attack is possible or some of these power you know power based attack or something like that um and so yeah that's definitely something I've been thinking about Um there's some interesting like uh there's this paper there's a field of a line of research that was started by I think a paper from Dan Bernet called slalom um which basically says like what if we only trust some like nonp parallel like slower uh computer um but still want to do LLM neural net computations with a parallel accelerator uh so we do like all the nonlinear um operations in the slow CPU basically basically and outsource all the heavy computations, the matrix moles to the GPU. Um, and that kind of thinking is is very interesting. You can there's also some yeah okay there's there's a bunch of people looking into this from a software perspective as relevant people have like you know non-cryptographic solutions for today's stuff and for tomorrow I think we need to come up with more secure schemes. Definitely the ideal constructions involve multiple of the acronyms TE MPC, you know, you pick your favorite, put in a pitch deck and um

raise money.

Sorry.

And raise money.

Yeah. Yeah. Yeah. Yeah.

Okay. Uh yeah. So I think um the offiscation day is over. For the last one that remain, we also have a t-shirt of Machina. So yeah, just come and pick up your t-shirt.

Thank you guys. Thank you.