New Ethereum talks, every Monday. The week's conference uploads by event, in your inbox.

Loading player…

Bringing Fully Homomorphic Encryption to the L2 Space | Kyle Koshiyama - Fhenix

Ethereum DenverWed, Oct 9, 2024, 12:00 AM

Fhenix is the first L2 to allow developers to execute operations over an encrypted field. This allows for on-chain composable state management. APPLICATIONS FOR ETHDenver 2024: #YearOfTheSpork ARE OPEN APPLY NOW https://ethdenver.com/apply

Transcript

[Music] hello uh my name is uh Kyle I'm the devell at uh Phoenix um and our goal is to build uh onchain composable private contracts uh using solidity um oops so uh what is Phoenix Phoenix is basically uh an L2 project um that again is trying to leverage composable onchain encryption um so obviously privacy in the smart contract space is very popular um primarily most of the attention is being given to uh proofs using zero knowledge projects using zero knowledge proofs um in some ways there's kind of some limitations um in the sense where like maybe ZK isn't the endgame specifically for composable onchain privacy um specifically in the sense where FH allows you to run um operations over Cipher text um which kind of allows you to create an onchain state so you can have more complex logic versus just point of at testation privacy um which scales a little bit differently um so if you want to get started um with the private order flow um example here's a QR code to sample repo um we also will have um a lot of other um uh aspects of um the presentation to add to um but here's a quick um contract import example so one of the benefits of uh building on Phoenix is that you don't have to go and learn another language um you know we kind of we're trying to prioritize the um developer experience in the sense where uh it should be as simple as you know considering that an integer um would be an encrypted integer uh so here we have kind of an example um where the FHA is just imported on the top of the contract uh here are some examples of how you could pass in Cipher text and a cipher text uh for those of you UNF familiar it's essentially sort of like think of it like a hash value that kind of represents uh the the knowledge of the plane text as well as noise uh FHA is using kind of a noisy encryption here um and as you can see on line 11 we uh will move towards a type of a decrypt um which will kind of uh that's essentially what is exposing the value to the rest of the network um so here's an example of a local setup uh if anybody also would like to um use a traditional um like a hard hat repo um so this can be run locally um through the plugin um there's other opportunities to U build your contract out this way you know using um a different testing that's possible um so feel free to Fork it and uh give it a shot um we also have a remix plugin that will help you generate and format the cipher texts um to so you can actually pass them as input prams for your um contract as well as handle permissions in the sense of uh basically who can view what data um we'll get a little bit more to that later but uh if you have any questions about uh any of the slides um we do have the uh link to the documentation for each corresponding um part of the presentation um so here's an example of how you put an input uh into a function uh traditionally uh you would probably just pass this in as an integer or a uint I guess of size eight for example um however it uh different formatting um is necessary in order to pass in the cipher text and we do try to set up tools to make it uh as easy as possible for developers to pass this in but essentially you can think of this is just a level of aisc um on chain so instead of having to offchain turn aggregation uh or security when it comes to M or basically anything um you you can use FHA in this sense and so uh if if you see here there's actually two different ways um to save to this encrypted integer a of uh of 8 bit length um so uh it could either be arbitrary bite code for example if you want to develop using um you know for example if he needs to be get passed in from a the call from another function uh or if you just directly want to call it um in terms of the cipher text here um okay so conditional logic also does apply a little bit differently when you're um trying to advance the State over um an encrypted field because it's not as deterministic as like natural uh blockchain execution because what could what what the state could Branch to is dependent on a value that isn't known um so this does have some issues when it comes to like gas estimation but um again this is uh filled through um in terms of like just kind of estimating as an arbitrary sort of block of bite code if that makes sense um as so as you can see here the first example was kind of something that would be more natural um to you know any of us that have really r like kind of simple if then logic um however uh having to apply this logic um like like the conditional case um vers over something that's encrypted again has uh kind of the issues I was talking about earlier um so the bottom is is basically kind of using a selector method U which is kind of like a multiplexer in the sense where it takes in a Boolean value of is higher here and then we'll we'll we'll slot uh either the value or the existing bid um and set that to the corresponding wherever it needs to be um in this case it's a specific mapping um and we'll get kind of get to why this mapping is important later but um you know it's good to keep in mind of you know specifically if you want to check if a value is less than and then apply conditional logic you would use some sort of a selector here um and then Branch based off the encrypted integer could be a Boolean could be an encrypted Boolean um required statements so required statements are also different in the sense that sometimes you don't want the contract to execute if a certain threshold is or isn't met TR release is a relatively uh simpler thing to calculate and often times you can do it before the contract even needs to be run um however obviously with FHA especially when it comes to multiparty a lot of this information isn't going to be known um so required statements also need to be a little bit different um so another thing to to be cognizant of is what information does leak because at the end of the day if you're trying to build a really secure encrypted application one of the things that uh one of the core design principles um is is information leakage uh because that can take down entire systems but the FHA require here um is is sort of like an example um of what of a condition of what's not going to make this contract work um so if you have a Boolean condition for example and you can look at you know how the contract executed you would be able to tell um uh you know if the contract got reverted or not without necessarily seeing the contents um so to go on a little bit more about conversion leakage so from a high level I I like to think of it in the sense where like uh if it happened at some point there is a trail of it right because General engineering principles right everything's sort of deterministic that's how you can build forward and expand on top of things um someone say stand on the shoulder of giants I suppose um but when it comes to information leakage by ever exposing an unencrypted integer here so a standard un 256 to try to convert that to something like a un32 um or un UN 2 256 for that matter um that conversion is going to have some issues because the uh the plain text value that had ever existed will have leaked so the safest way of uh encrypting your data this way is to make sure that it's formatted as a cipher text and like I said we we believe that this is kind of an extension of sort of uh an application use of zero knowledge technology zero knowledge proof technology um like under the hood um part of our operating system we actually do use uh zero knowledge proofs of PL techn knowledge to verify that the um developer or that the participant knows um that the cipher text was constructed correctly and that the contents uh the plain text contents uh are known so that logic can be applied and and a certain level of construction um trust can be built in towards the application moving forward um okay so what is fhos so we have heard um I've kind of gone about how to build with uh Phoenix but from a high level um what Phoenix is working on is we are building um an encrypted L2 but also we are working on the general ecosystem around um you know what's going on in the FH space for example we have a we have use of the threshold uh Network which is kind of like the if you think about in terms of multiparty compute uh and the threshold encryption this is kind of what the uh what some of the the fhe oracles that eventually are going to be read um for the necessary decryption um but basically the fhos uh Library specifically is kind of a wrapper around Z's tfhe RS Library um which is a rust Library that's again maintained by Z and uh uses a specific FHA encryption scheme to handle certain operations um and from there we try to keep our stack as modular as possible um even in the sense where um you know like there's a lot there's a lot of trendy stuff about you know like Atomic execution fragmented liquidity Etc so one of the aspects of keeping this modular is that you we could attach it to um you know different wasm execution environments you know in this case like we're using uh the the test environment is using the arbitrum uh for prover the Nitro U for the integration for stylist so that we can actually run uh the tfhe RS functions uh uh I guess you could say the solidity endpoints import them as like stateful pre- compiles um and so again this could be applied to different Stacks as it's getting more and more popular um right now we can convert to uh you know networks using the goe client um but from a high level this is kind of what we're doing like I said under the hood um if you dig into the tfhs library it is using uh zkp uh for the construction of the plane text and knowledge of the plane text um and the threshold service network um you know will apply um a lot of the security that can be used between um you know different networks that eventually get added to so um it's kind of interesting because it kind of comes down to like how do you how do you give encryption as a service I suppose there's some trains of thought you know like some people U might advocate for using some sort of bridging but then you're bridging a cipher teex Cipher teex value is still relatively large you know they could be as large as like 8 kilobytes trying to send that through um some sort of uh Bridge obviously is going to have its own issues you could try to segregate it uh the the message um however you know there I think also as an argument for just applying the stateful pre- compiles directly to the client itself um and then they can connect to each other using the threshold service network um which is um sort of kind of like the shared state of uh you know kind of like leveraging the network um Network effects for um encryption and just general security um so what is Phoenix JS Phoenix JS is is a library that you can import into the client and it'll help you kind of earlier where I was going over Cipher text formation and when it comes to permission viewing basically who has access to this data um this is a way to integrate it into uh you know JavaScript whatever however developers want to build out on the front end um and uh basically it just kind of helps you integrate with the ABI a little bit easier um just in the case of formatting so again hopefully the developer exper we're trying to make the developer experience uh as seamless hopefully as you know building with anything else um in the web 3 space um so what are permissions I've been talking about permissions so uh it's kind of a long witted way of saying that uh like who can see the encrypted data right like maybe I want another contract to be able to read a certain value Maybe I want to lease out my information to some sort of like I don't know machine learning model or something that's doing training over an encrypted data set and monetize it that way um but essentially in practice um this is kind of you can kind of think of it as like a modifier uh which you know we'll check to see that you know the Senter is uh actually the one that's reviewing this so if I want to check my own permission I'm the only one that I want to be able to view what my current balance is for some sort of application basically this permission object gets passed in um as as a as a a parameter in the function like an AR U pass into the function as an argument and what it's doing under the hood is that it's kind of checking to see if this permission key if the key matches the same um if it's the same public key as the one that's uh corresponds to the message. sender basically kind of making sure that the person that's actually sending this message is the person that has access to the correct key um and so uh this is another one of the uh aspects of the Phoenix stack that we try to simplify um by using different plugins U such as the remix plugin which is I think kind of a good way for people that are more visual Learners um to sort of kind of go through the process and get onboarded that way U but also it can be more complex in the sense if you need multiple contracts to talk to each other um but yeah so here again is kind of an example of a permission basically sort of like you know if you wanted to um have an erc20 balance you know where the address would mapped to a certain integer value I guess an encrypted integer value um of of what a specific user would have um but again you only want to make sure that that's revealed um in in the the right context and so the implications of like basically a lot of these Technologies could be interesting in the form of like solving generalized sequencer issues U whether that pertains to like bundler user option and like something like account abstraction versus it has to do with like meev front running other issues with meev when it comes to the more financial space and I think generally speaking like sequencing is is sort of one of the major uh issues that we're facing but um again here's like a a version of a sample um contract as you can see it's pretty similar to the last one in the sense where you just really have to import um the contract is basically one line of code and then most of the other stuff is basically kind of think of as like um importing a different like integer type versus you know for sometimes there's libraries that will let you import a float that you can use this kind of instead of a flow you kind of think of it as like it's an import of uh of an encrypted integer and so this can kind of be used as like sort of like um you know similar um as like you would with like a potentially like a database Association to to build like Cascade like more complex logic um with with your application on your contract and so what are kind of the downsides of this you know we've been going over or what or like what are the things to keep in mind in terms of constraint right because basically it seems sort of like the next logical step of uh using ZK for privacy in terms of it just being more um composable which opens up a lot of uh options and the ability to actually have the state um be encrypted and not having to decrypt for example if you wanted to do something similar um to like I what I kind of said like the database Association system for like I don't know some sort of game or a complex application or some sort of like social media anything right like you basically need to be able to run a query on encrypted uh space or else like how what are you doing with these numbers um it's always kind of um so like for example in a lot of um standard is kind of like it would have to be decrypted and then the logic would have to be applied that way obviously that leaks so the solution is maybe we bring that off chain what is the cost of that what's the cost of security um some could make the argument that the kind of goes against the ethos of like blockchain technology supposed to stand for um but FHA is still pretty new and in the sense where like the hardware acceleration we're still in the pre AIC days and like there are there is a lot of funding that is going into Hardware acceleration specifically I mean for me personally I know I've run into issues where U we were trying to work on like a decentralized DEX for example um you know not being able to use um anything larger than like a 16bit encryption does have it trade-offs for example you try to have a fee on a DEX and you can only use 8 bit how can you you can't really get a fee if you're trying to divide by a thousand because 8bit only goes up to like 26 right so these are kind of the design constraints that have to be kept in mind but for example even a few months ago like a division over two cyer like a Cy even if you kept the numerator um in Cipher text but the denominator itself even had to be in um plain text and even though those type of Divisions you could maybe pack like one in a transaction now I think um you know even in the short period of months like there has been improvements uh to figuring out the best way to do these like arithmetic Expressions especially because for now division actually is possible you can have multiple divisions um in one specific uh transaction but if you want more details and like uh going over each specific oper operation um what and how that corresponds to each specific data type the gas use how to fit that in a block um to prevent overflow um you know here's a the documentation um anyway that's the end of the slides um again if you want to check out uh the blind auction um which is I think is a pretty good example of using um you know the FHA technology to kind of build something out that could be used and it's kind of something that we're sort of familiar with um other than that uh also you know there there's there's caveats to the design um that need to be uh you know considered like I said we we only support uh up to EU and 32 values right now so for example if you wanted to encrypt an address which was like 25 characters right you could turn that uh each a bit into a representation of a bite and then use that uh sort of to represent a string so I mean because essentially if you can create bits you can create bites but these are just like the caveat development caveats that uh sort of need to be considered especially when it comes to like the runtime execution um like General tips of performance but but yeah that that's thank you for listening

Automatic transcript — names and jargon may be misspelled.