Twilight: A Differentially Private Payment Channel Network with Saar Tochner | a16z crypto research

Transcript

so hi everyone um this talk is going to present a paper that just was got accepted to use Nick's security like we presented two weeks ago there I think um I really like this paper because it spans through many different topic topics so like in every groups that I presented to has different kind of questions so just feel free to talk and to interact with any questions because this is I really want you to understand it deeply um so the paper is called Twilight the differentially private payment Channel network and this is a joint work with my adotaniosar we all from the Hebrew

universities okay so a bit about myself and PhD student finishing my PhD at the Ava University of Jerusalem I have a lot of different papers in the area of cryptocurrencies um Twilight is the paper that I'm going to present now but we have also a blockchain stretching and squeezing which is a paper that discuss how to change the rate of block creations in blockchains and using that to we were able to create an Arbitrage between different D5 platforms uh we have this paper about how to add new channels into payment Channel network and then hijack traffic

and create maybe an hour of service and another completely theoretical paper about how to avoid um isolation attacks or Eclipse attacks in general peer-to-peer Networks but this paper this talk is about Twilight so let me first try to introduce uh the basics the preliminaries of the stock um the first thing that I want to make sure that everyone in this room knows is payment Channel Networks um so PCN PCN is a network in every Network we have the relays which are the participants in the network uh we have channels channels are the

edges between the relays and in a channel there is there are locked coins and when I said locked coins let's assume that we have Alice and Bob each one of them locked five coins in this locked amount of coins they can just now create transactions or create small payments for example Alice can transfer two coins to Bob when they do this transfer they just decide on a new division of the locked coins so the same amount of coins is here but they know that coins are devised between the parties differently they can now do how many payments that they want and an important thing to note

here is that giving this new state after all it after Bob paid one coin to Alice um in this state Alice will not be able to transfer five coins back the world right because we don't have enough liquidity in her side of the channel perfect then we have routes routes are just list of channels from a specific source to a specific Target and then we have a payment payment is just shifting coins across this long route so for example we have Alice Bob and Charlie um Alice can transfer two coins to Charlie across this route and as we can

see um the liquidities the divisions of the funds will be updated throughout the route again an important thing to notice here is that Alice should not be able to transfer another two coins to Charlie because even though she had enough liquidity in the channel That is direct to her somewhere later in the route there isn't enough liquidity perfect um this is a payment Channel network and this is not something that I just invented um there is the lighting Network which is a big Penman Channel network that has a capacity of over 100 million dollars

uh this 100 million dollar are just the locked funds which means that transactions that goes on it may be much much higher and this 100 million dollar is after the great uh cut in Bitcoin um in bit in Bitcoin prices in the last two months so people use that um and why do people use that the main motivation is blockchain um I will just give put it here that's okay if you will not understand it the idea is that we use only two transactions in order to summarize or to squish a lot of different payments or different coin transfers that happened

so we do a single transaction that locks the coin that creates a channel this thing happens inside the blockchain and then outside of the blockchain we will do many payments which are different divisions of the same locked funds and then we when we decide that okay this is the less division that we want to do we will just commit it back to the blockchain so we were able to create a lot of different coin transfers with just two transactions in the blockchain and this is awesome because it creates a great scale we got fast payments and I actually didn't tell you how to do that

but we can also get the trustless property um which is well this is great this is what we need to have um and there is a butt and interesting but in this kind of Networks is the probing attack probing attack is an attack that was uh presented first in a paper in 2017. um so probing is to inquiring closely into something and in this attack we base our were based on the idea that took probe to understand uh something about the network is very cheap or and in here this is actually

free the idea is that an attacker can execute a transaction or can ask the network hey can I move a specific amount of coins from me to someone else and then after receiving a response from the network the attacker can just cancel the transaction and not pay anything so the attacker was able to achieve observation from the network without paying anything um and the idea here is pretty simple the idea is that we can just the attacker can just repeatedly query channels over and over again until he will see changes which is pretty cool for example we can

look on the right which is marked in blue here and the attacker just query hey can I send 100 coin and for example the network now tells him yes you can transfer this 100 coins cool thank you I will cancel the transaction a second later he will just query that again and a second later he will just create that again each time he gets a yes because okay there is this but then in the fourth time that requires the network he will he maybe get this answer that the no so an attacker that observes these changes in the network can just react to these changes and for example ask hey

can I send 50 coins the idea here is a simple idea that both that leaks a lot of different kind of informations about the network it leaks the current liquidity of the channel because we know how much money both side locks but we don't know how how the money transfers between the two parties uh it licks the existence of the transaction that a transaction just happened uh it leaks the size how many coins moved from one side to another um if the attacker will do that to many channels in the network because it can this is free then it also leaks the identities whom send money to whom

and this is silent to Alison Bob Alice and Bob will not know that someone is currently trying to understand whether they just paid to one another this is a great but um and Twilight is a system is a payment Channel network that tries to solve this problem that tries to solve probing the text um I think that this will hint you what the how do we how do we do that um but the basic idea is that we're using noise in order to provide differential privacy guarantees

we then use trusted execution environments in order to enforce um our enforce the relays to use our protocol um and this is a systems paper so we both have analysis and simulations to all the three properties of the cost privacy and security and we have a full prototype implementation this slide is our agenda for the rest of the stock we will first talk about how do we achieve this differential privacy guarantee um a very interesting construction I think that the people that love um privacy will enjoy that then we have

the trusted execution environments which is how to define protocols correctly between trusted and untrusted parts and how to engineer it uh and then in the last we will talk about a real implementation and what are the performance of this network so let me start with um explain you a bit about differential privacy uh does anyone know what this differential currency us awesome so just go fast on it in this in our case specifically we wanted the attacker will not be able to distinguish between two events the first event is that Alice paid Bob and the

second one is that Alice didn't paid Bob the formal definition uses Epsilon and Delta the Epsilon is here as Epsilon goes to zero uh the observation the probability to see a specific observation of the attacker on the network should not be correlated with whether Alice paid Bob or Alice didn't pay Bob so as Epsilon goes to zero we bound uh what is the probability to see this observation in two different events whether else table or others didn't pay well and we want to be able to make sure that uh in most of the cases the attacker will

get this thing so that that's okay the attacker will get more information in some of the observations but we want to make sure that the the leaking observations will be as few as possible and this is Delta um in our case we use Delta 10 at -5 so like in in a very small chance the attacker will get more information than that Epsilon is here uh in our case we use we had uh we all our analysis will be on Epsilon which is 0.15 usually this is a valid uh Epsilon Delta for differential prices

yeah wait to see the numbers uh great what is noise in our case noise in our case is some random number are and this random number the channel will generate a point of query upon someone asks them hey can you transfer m coins for me and then instead of instead of checking hey do I have enough liquidity he will check if he has enough liquidity minus this random number um in the next four slides we will discuss more about how to generate this number but I want to highlight here that this is set right

me as an uh Channel owner I will say no to much more transactions because I have lower liquidity and that's that's a bummer um I hope that later in this talk I will I will convince you that this is not that bad or I will give you some economical argument about what does it really gives us you're generating random transactions here and is it all like Revenue neutral so nobody you're only hurting liquidity people aren't that's an important question

um so we don't Generate random transactions we just Generate random number that reduce luckily from the liquidity this is not a real transaction this is not a real money that goes in the network just every channel by itself when you try to answer whether he can transfer coins yes or no he will just reduce locally just for this specific query so someone wants to transfer 100 coins like in your example and your sample R is like 50. you'll only do the transfer if you have more than one yeah I will still transfer only the 100 that the attacker asked I will not

transfer more this R is only used to answer the question can I transfer yes or no because this is the only observation that the attacker sees so we just want to somehow noise it um awesome um how do we generate this random number R first of all I want to make sure that we all understand that the naive solution doesn't work here and the native solution is pretty simple let's just assume that the channel owner just every time query a random number independently um so it will not work because the attack is really cheap is is actually

free so the attacker can just do it over and over and over again and just see how how many observations does he really get of yes and no's and to reconstruct everything the the noise formula is known everything is known so we can just rewrite everything on a paper solve it and understand what is the real liquidity um and it doesn't matter how many yes or no he gets he just can always rebuild the histogram so we can't use something that is that naive we will actually use something that is more complex which was presented in 2011 and the idea is that you want to achieve differential privacy under

continual observation um and the basic idea here is that we want to drop the independency property we want somehow that the queries that the attacker query us uh the the noise will be dependent uh and in one in what sense dependent we want to that over time there will be dependency so I'm now going to present you a construction on how to build the noise we will later just give you the intuition on why it works so here is the construction on how to build the noise first divide the time into slots and

build a tree where the leaves will be the time clocks the time spends um then we want to track payments in the subtree in the route to the root so for example we had a coin transfer here then all we can see here the changes that we know okay a payment happened in this subject now we derive noise from the minimal covering set for example if the attacker queries at T equals 7 then the noise will be the ribbon from the time span between zero and six the minimal covering span the minimum covering set of this time span is the

nodes that are currently marked in blue okay we sample noise just once for every three node and then we can just answer the question can we transfer mcoin so please note that we added here a time which gives us the the dependent between different queries and then the answer will be just the capacity minus the actual parent payments which gives us liquidity and then we add our R our total noise um this is the construction uh so the the basic the the important

things that we need to notice here is the minimal covering set and the idea that we sample noise once for every tree node does the construction make sense no Fair um let me let me present you why it makes sense um and here is the idea that is pretty simple the idea is that we want to limit the number of different of different noise that happens on the same coin transfer and let me give you an example let's assume that we have a coin transfer at T equals one

and then the attacker queries on the red slot in t equals 2. then the minimal covering set will be the node that is currently marked in blue so the attacker will now see a specific sampling of noise that hides this coin transfer okay he gets one observation now the attacker queries again at T equals three the minimal covering set are the nodes that are currently marked in blue but note that we did not generate a new noise here which means that the same noise that hide this coin transfer that we use it the same noise again for

the attacker so the attacker now did didn't get a new observation of noising the same coin transfer this is the intuition and only next when the attacker requires on time T equals 4 we will query the random number generator and get a new noise so in total the number of different noising samples that the attacker get for every coin transfer is limited is limited in the number in the height of the trip so if you will compare it to the naive approach where the attacker just get a fresh new noising over the same coin

transfer here it doesn't get too much fresh noises we limit the number of fresh or fresh noises that the attacker gets for every coin transfer so if we assume if we said before on the naive approach that the attacker just get different noising a lot of different noising of the same thing now we just limit the number of different noising he just get a fewer number of samples and the next slides gives us the analysis of okay so what so we get five samples instead of 5 million how good is that the idea is that you

can't just um we need to somehow construct a noise that will all the time will look the same so we want that the as I said before we in order to generate the noise we will sum the noise of all the three nodes of all the trainers in this in the minimal covering set um if you will just create a noise for every node while you go like if if I'm creating now in time T equals 5 then I will generate five and if I'm querying on T equals six then I'm generating six so the noises keep getting bigger so it

sounds it's just impractical you want somehow that you will limit the number of noises of different noises that you add on your noise in your noising mechanism so you need to balance between the different sum the the number of some summation that you do of noises on the one end and on the other end to give enough privacy so this is the thing that the tree tried to balance between how how can you just add a fixed or a limited number of noises while still preserving some kind of some kind of privacy does make sense

perfect I I maybe later in this talk it will make more sense um let me present you just the basic of the analysis the basic of our analysis is first of all based on how many different samples of the noise on the same coin transfer does the attacker gets so if the attacker gets more uh samples of this noising mechanism over the same payment we lose privacy right so for longer routes or the attacker can just query each Channel independently there there will be more samples leaked so longer channels longer routes means

less privacy this is l then we have r r is if there are two routes that are that Alice could use in order to pay Bob this somehow helps the Privacy right because the attacker don't know which route to query or here we'll see two different query two different observations but you will not know which one he really need to use and this is where where I um went which is a real theorem that tried to use this L and this R and this T which is the number of noise and log T which is the height of the tree and we

try to build something that will give us real numbers on what is our privacy guarantee and I know that this theorem or this numbers don't give your real intuition in tumor slides I will just plot it so we can all see exactly the numbers the differential privacy guarantee is it for like the next 60 years or is it occur some transfer that's a great question so we assume our worst case that the attacker can just query all the time even in the future

so the same guarantee is holds on a transaction that happens now even in six years in the future we also assume that the attacker can query all the channel in the network we have a super strong attacker um in the expression what is T is that like the amount of taxes yeah yeah so log T is like the height of the tree this is the the maximum number of different samples that the attacker will get on a specific uh coin transfer perfect um so there is a trade-off here an interesting trade-off right ending noise means that we will fail

more uh so this is what you meant I think um we will just say no to more transactions um and the the relays can just compensate it by locking more coins and this is possible but this extra long locked coins which means that he will pay more money and and how much more money will he need to pay this is a very interesting question and I will give here some kind of um economical argument that um let's assume that the attacker don't need to pay for all this extra locked coins why because you can maybe just take a loan from the bank of this extra locked

coins and then when the channel will be distracted he will get all these locked coins back he will repay the loan which means that he only need to pay for the interest of this time so when we ask how extra money does it cost to create our channels it depends on time and the equations that I will give will be depend on time as I promised numbers um 9560 times the number of the minimal query for example if you want to hide queries

of size 1 you need that the channel will hold 9500 coins this is a lot okay perfect uh and this is the Epsilon this is the semitron from the uh differential privacy guarantee on the other hand we have this thing of okay so maybe we can just look much less money with the same Epsilon but we will pay for it with a very bad we will just say no to everyone yeah for example if we will if the

channel will just say no to everyone he can lock zero money X extra zero money and the Epsilon will be uh there right um so we need to somehow balance between the privacy and how much fails do we get and this is I think the most interesting uh economical argument that we can give here um let's assume a yearly interest rate of three percent uh if you want to get a Delta the efficiency of 10 in minus 5 and we want to get an Epsilon of 0.15 and here comes uh the time that I talked

before if the channel will handle 77 payments a day then taking one percent is enough to cover all the extra costs everything um so yeah I agree that this 9 500 cents a lot but one percent of 77 payments a day well this is reasonable I can give you for example Visa takes two and a half percent uh American Express take four percent we're taking one okay make sense yeah uh yeah um how does the maximum size of the

payment come to play it all like if I have a gaming channel that can do a maximum of ten thousand I want to send ten thousand yeah presumably that will be easier for someone to detect that now all of a sudden yeah so this 9500 is um is comparing to the maximum number of coins that you wish to hide so if if your channel is wish to hide a payments of one then you need to look that if you want to hide payments of 10 you need to lock 10 times that but your channel will be able to transfer uh 10 if you locked only that

but then you will provide worst um privacy guarantees let's follow up on the next question which is the payments on the bottom of the slide and I feel like there has to be some relationship between the typical size and those 77 payments yes so this is 77 payments a day of the maximum amount that you watch that you wish to hide if you wish to hide a single coin which means that you need to lock 9500 then you need 77 payments of one this is the maximum side that you want to hide that's why you use it we a channel one a channel will not say that you try to hide thousand uh dollar

payments because then it will cost him a lot in additional locked funds so it's like it's a balance I guess time graphs if you want Epsilon equal to 0.15 for all of time then like you'll have to pay a lot more and additional watch points is T fixed to something here yeah this is really important Epsilon effects so there are two different times in here the time the T that Epsilon is using uh is is a lot of time it's like 64 bits of time uh so uh we assume this 64 bits of time that the attacker can just query every time

spent across this 64 bits of time uh this time is a different time this time is a time of how how much time do we want this channel let me phrase it like that we're taking loan from the bank in order to create this Channel and then the channel will be distracted and then we will repay our loan what is this time period so this is not necessarily the same time periods right the channel can live less than 60 years in the future the channel can lives for a day a week a year that's fine this is the time here so different times

how uh how did the parameters change like I say you want to go from 60 years to like 120 years yeah but I don't understand fairly is how does the Privacy versus efficiency change because there's like a log key here and I'm trying to figure out if that's like bad when he grows or good when he grows because it's on linear linear um when tea grows it means that if you will use the same tree structure and everything when tea grows it means that you will have more height which means that the attacker will see more different observations which means that you can just keep everything the same you can keep the same 9500 extra coins but then you will pay

with Epsilon so there is a there is a delicate relation that is in in these equations that gives you what is the balance that you're trying to achieve if you're trying to achieve the same Epsilon for longer it is then you will need to lock more money or to fail more you're not okay so the way to look at this is It's the bigger key is yeah that makes sense that's a balance everything you hear is a balance and that that that's what that's why I said that this equation is pretty hard to

digest I would say because it has a lot of different um um parameters inside perfect and this ends are theoretical differential privacy part let's talk about protocols um Protocols are called and here are protocol challenge is the following relays don't want to use Twilight realize that use Twilight will say no to more transactions they can just say hey sure I'm used

Twilight yeah I'm adding the noise and oh the noise was small I'm so lucky we need to somehow force them to use Twilight and this is an interesting challenge um really don't want to use us we want to make sure that they do use us um we can try to solve it from many different uh places um forcing is is the world that wears a computer science don't love to use um we tried to think a lot about incentives they in in one sentence this is pretty hard because you cannot make sure that that

they uh created the noise as you wished they might create noise differently and we want to make sure that they use the noise as they wish so we just decided to force them um yeah that that's a good uh reaction to just think about it yeah and when I say Force this is not that force and not that for us but this is that Force trusted execution environments um so let's talk about that perfect what is trust execution environment trust execution environments is just an isolated Hardware that gives us two

properties the first one is integrity it means that when it starts to execute the program it tells me hey this is the program that I'm running and it can not change the program in the middle it cannot change up codes in the middle it it just has to run it uh back to front just in a single execution the second interesting property is that confidentially while this isolated harder Hardware execute a program we cannot see what is its memory we cannot see um which execution flow it tooks we just

cannot see anything you we can just think about trusted execution environments as a black box that can tell me hey I'm running this executable this is the response and I can fully trust it uh an important thing to say here is that uh there are different way to implement it in practice there is the sgx of Intel uh uh Nitro of AWS different approach to to achieve this trust execution environments um I want to use it here as a primitive let's assume that we have these two another important thing to say here is

remote attestation this is this is the process in the beginning when the tease initialized they just attestate with everyone or with a third party to say hey this is the code that I'm running this is a a trusted part a trusted phase that you need to make sure that works awesome this is a great primitive let's see how we can use it we want that every relay we will run a t we want that the teeth will be completely stateless why because if they will not be stateless then there will be

a lot of communication with the blockchains that need to happen there is a consensus that you need to implement inside a t and we just don't want to get into it so we decided to get a stateless team this decision creates a lot of different challenges the new challenges are okay so this is stateless I as a I'm as a relay that has this thing you can just rerun the tea over and over and over again until he will respond me with the good noise that I want to see right I can just re-execute everything because this is stateless then it means that we need to somehow hide everything hide everything means that we need to

create um like the thing that we promise to handle is now encrypted which means a new smart contract in the blockchain in order to handle everything it means a lot of things the next thing is that um a relay can cheat the tea with what is my real liquidity right they Relay can tell the tea hey I don't have 100 coins locked in my channel I have a million coin lock coins locks in my channel okay so that they always say sure you can transfer these coins uh we solved it in the paper with simply inversing everything instead of the T

checking whether I can send the coin the T only check whether I can receive the coins so by changing that the relay has no incentive to cheat the team if the relay will say that he has more coins in the incoming Channel then the T might accept to transfer to give money to someone although I cannot receive this amount of money so the relay has no incentive to cheat to bigger numbers there really is no incentive to cheat on smaller numbers because then um the team will just say no the transaction that we I would have accept

so I don't have incentive to cheat lower so my incentive is to just say the writing which is amazing the third channel is about um colluding relays um we need to if we need to relays can just create many many really a single Relay can create many nodes in the network so he can just look whether the node before him said no I don't have enough liquidity and then he can just tell him and we don't want that it will happen because the the t is stateless so we need to somehow make

sure that all the payment looks the same whether it was accepted or not only after the payment will be finalized only then we will know whether the money was transferred yes or no um cool I will just skip that and let's talk about the implementation the implementation of this thing is is huge we have three parts we have the new smart contract that need to handle this encrypted um it's not htlc now right because everything is encrypted we don't know how much money we we promised to give so everything is encrypted so we need to

create a new type of smart contract uh so we wrote it in solidity and tested with ganache The Enclave itself was written in C plus plus because we wanted to write it on a real sgx and we used pistachio in order to communicate with the relay and the relay themselves uh was was written in Python using fast API in order to communicate between one another and fight group The Dom in order to execute uh cryptographic operations in sea level in fast way um we implemented it all on Azure confidential Computing in order to have dozens of machines with an sgx Hardware we used Azure SDK in order to create

big topologies with different connections we wanted to use real real-time Network delays so we want to create our machines in different places across the world and we had to somehow monitor everything so we used um elasticsearch in order to send all the metrics from all the distributed system into one place so we can just monitor everything from it and it creates a very cool I would say uh open source that is now available to everyone which called Twilight which has I would say a lot of different languages uh very very uh

uh sparse implementation that that was awesome um which gives us pretty good performance and when I separate a good performance I'll say here that we achieved a throughput of 850 payments per second while currently the lightning Network handles 350. almost three times higher um uh I would say here that we have the T which is the bottleneck let me later explain you why it happens we have a very fast latency for a single payment to be accepted assuming that

there are four intermediate relays between us it's less than one second latency just think about the latency of using Visa one second is pretty fast for private payment channels for private payments system and this is an important thing the idea of me putting an encrypted data inside the blockchain so when I'm trying to put an encrypted data inside the blockchain it means a lot of things it means that I need to pay on this stored data I need to pay on the gas of

decrypting it and validating it and all this thing so it creates us a very interesting trade-off between what we want to happen inside the smart contract and what happens in the team because the T encrypts things and validate things and sign on things that happens on one side but on the other side we have the smart contract that also need to decrypt um and here the cost is high I don't know if you uh you probably tried it how much does it cost to store a single bit in the blockchain this is crazy expensive half of the price here is storing so we wanted to

make sure that everything everything is super tight which created us an interesting trade-off between this number and this number we decided to one second we decided to move all the hard cryptography building from the smart contract to the team yeah so you said the smart contract against the decrypt how is the key on the smart contract Secret that's an important thing uh so I didn't got too deep on how the trustless property of payment Channel network works but the idea is that there is a secret that the recipient of the payment

released once he wants to get the money so we want to make sure that his secret the secrets of Bob the recipient of the transaction will somehow be the key to this um to this encrypted value is it okay for that kid to be public because I could imagine someone could intercept that my question if your computer network and then who knows what they could do if they know the key yeah so um once Bob uh um revealed his secret it is completely public so we need to somehow make sure that everything works as as it should and I think that a really cool thing to say

here is that note that we encrypt this uh value that should be decryptable although it should be decryptable by two different Keys it should be decryptable by the key of Pub but it also should be decryptable by the next T so you need to do some very delicate cryptographic here in cryptographic operations here um this is something that I can take offline and explain more yeah so I don't know if I missed I missed something but I I thought you were pitching something like that on top of that's the only thing that

you didn't miss anything I think the the 350 payments that I mentioned is something theoretical that papers showed that it is possible to do on currently lighting Network um because they just didn't try to make it more uh to make it more efficient the idea is because the currently lighting Network can handle 350 payments in real life there are less than 350 payments per second that's why our system will just handle it as well you're right we're doing more work than the lightning Network so uh conceptually they will beat us somewhere but currently it just

not important because the true food that they trying to handle uh we can handle just I guess maybe I was trying to ask like what are what are you like what about this could possibly increase the Republic what you were presenting was just strictly more work yeah and that's somehow there's more creative yeah so again the more throughput is because they didn't try to make their code more efficient we absolutely do more work um our main bottleneck is the tea which is you can think on it because this is hardware uh we our relays have a lot of cores and one core to the T so it's like we have a very strong CPU bottleneck

let me just conclude in the last five minutes so we're able to achieve differential privacy under continual observation this is the tree that we built in the beginning of the stock uh then we talked about the extra cost the additional coins that the relays need to pay in order to achieve privacy um realize that are selfish they don't want to use uh Twilight that's why we enforce them using teas and we have a full prototype implementation that works so you can use it tomorrow if you wish to do private payments um

that's it thank you [Applause] questions yeah so I hear conflicting things but your thoughts personally and just also the feedback you've gotten from the security Community around that uh that's a good question you're right there is a huge debate about it I like to present this work and I work more with this in different

papers as a new primitive that we as the academy Community can just use as new primitive to achieve new goals that we always wanted to achieve and this idea of forcing a specific protocol that you cannot verify differently or you can but it will be costing um this idea just gives us a whole new world of new problems that we can solve um if we will look on how the industry really tried to create trusted execution environments there are two different approach the thing the first approach is

like a separated Hardware this is what intels does and it just keeps breaks right every every week a new researcher find a new way to just side Channel secrets out of the sdx and there is another in another approach the approach of AWS Nitro where they just say yeah this is an isolated Hardware we don't promise you that this Hardware is strong we just keep this Hardware in a different place we are the API between your machine and the other machine and we just make sure that you cannot do anything there so the industry tried to create to to make

this Primitives feasible they not there yet but I do think that creating research over this New Primitives is is the way to to get very crazy things done awesome thank you so much I think that we're