Best use of Fhenix Stack - ETHGlobal San Francisco 2024

hey my name is Kyle I'm the deell at Phoenix and I'm just going to go over a quick overview of Phoenix kind of one1 uh building private applications would be just pure solidity uh so real quickly if you want to join the Discord this is probably the best place to do it uh I'll just leave this up here cheat sheet this is probably the easiest way to get started um again we're standard evm op codes plus some FHA pre- compiles um I'll go into more of the details but basically if you can deploy your contracts on a standard evm uh you should be able to uh deploy to us uh and again we're fhl2 so evm compatible um but again what is this fhe nonsense FH is basically a really fancy name for kind of doing uh think about like operations over Cipher text um so General homomorphic encryption is basically the ability to do something to one field and it affects another field uh in this case the plain text affects the Cypher text and fully homomorphic encryption BAS basically is the ability to run um an infinite amount uh of these um operations so real quickly FHA is kind of the new ZK I'm sure a lot of you are familiar with the concept of using zkps for privacy um some would say that's a meme I don't know if I'd go that far but uh there's a lot of nuance I suppose with it um so a quick overview of FHA and again I'm kind of saying FHA obviously FHA and ZK are very different Technologies uh I I see FHA as more like operate like encrypted private operations versus ZK is more of like a constant time verification or just verification in general obviously it's not always constant time but many ways I digress um here's kind of like a timeline of last 40 years uh you know privacy homomorphisms have existed for decades however in 2009 um you know Craig Gentry changed the game with his ability with this introduction of something called like bootstrapping and then um which is kind of a way to make the um noise because FH uses noisy um noisy encryption so basically bootstrapping allows you to reset I'm not going to go too much into the details here but um yeah if you have any specific questions uh please reach out again so like FH and ZK both uh provide some level of privacy um ZK is like the more scalable technology as of now however things are you know changing very quickly um in terms of composability FHA allows you to have uh multiple private input and run an operation on top of um you know on top of these uh encrypted inputs uh just encrypted fields in general and again this is all done on chain doesn't have to be offchain and then just verified so you kind of get um in the sense where maybe you wouldn't really know what the Prov is doing in this case you would uh be able to verify each operation itself um again so the the main issue with ZK for privacy is that it just doesn't address the issue of being able to um run an operation over Cipher text which means at some point you're going to have to decrypt to run these operations um again not always necessarily true I mean there are certain situations where you could use some sort of like secret sharing uh or just a bunch of different other methods but from a high level it's U uh you know there's kind of issues with it when it comes to the concurrency but anyways I digress um so real quickly building with Phoenix for this hackathon it's a relatively straightforward uh it could be done with a single input again if you know solidity you should be able to pick this up relatively quick uh for those of you that would prefer to use uh hard hat this is kind of what we have going on right now so uh you just have to set it up locally there's instructions on the docks uh similar thing with the remix plugin for some of you that might I don't know visual Learners prefer remix I don't know but that's also an option um in the future we are going to be adding Foundry support there's a few reasons why it's a little bit it's been a little bit difficult for us to add it uh to our Network right now you know some of the just the way the pre- compiles are handled but um these fhe pre- compiles will be added to Foundry down the road U currently working on it so inputs so basically you can think of FHA Phoenix what we're doing here uh is that when you would normally normally have an unsigned integer that's queriable from everyone um now you have an un now you basically have an encrypted unsigned integer uh which is in in this case you can see is basically passed in as bite code um this bite code can be formatted into something specifically called what we call an NE and8 which is basically an encrypted unsigned integer of bit length eight which means you can represent up to 256 uh different numbers basically and then we go up to the sizes up into 256 um however not all operations are supported after you get past 32 uh bit length but anyways um so it's a good thing to try to recondition yourself here again like with fhe similar to some other things things maybe like some dsls you might be familiar with but like we have constant time code which means or I'm sorry it acts like constant time code um in the sense where you um have to have a single code path which means you need you can't really Branch right branching isn't something that's feasible here um so most of you might be familiar with the methodology on the left the syntax of like the F FL syntax and kind of having the cases that way um and I like to think of it is like um however if you look at what's on the right this is how we do it we have like a selector function which is essentially like a multiplexor operation which allows you to pass an encrypted Boolean um and then assign the value uh based on like whatever the encrypted Boolean is so I like to think about it that like fhe doesn't have conditional write but it is conditional um assignment and so it just it's probably one of the trickiest ways to have to recondition yourself into uh the specific type of engineering but uh generally speaking most things are relatively the same to General solidity development um requir statements are also slightly different um the sense where you have to use fhe requir and but it's basically kind of what what it sounds like in the sense where if you have an encrypted integer uh and let's say you want to revert if the encrypted integer is not equal to something or if it's less than something this is basically how you'd go about doing it very similar to a normal required statement and solidity uh conversion leakage is basically I just like to think about it that if there was a plain text history of a somewhere right that means that at some point if the number existed in plain text that means it leaked to state that leaked memory to State at some point so uh in this case as you can see if you pass in a plain text and then go through the uh process of actually encrypting it um you're basically going to be leaking what the value of the cipher text is so generally speaking it's uh it's ideal to make sure that the whole process is encrypted um so what is fos over at Phoenix like I said we're building in L2 one of the other products that we're producing is a threshold service network um you know it's something different from like other fhe especially things that are marketed such as like fhbm is that you know they're they're basically from my understanding is for the most parts are using uh synchronous uh asynchronous decryption or moving towards asynchronous decryption we're also moving towards asynchronous decryption however um from a devx perspective it's going to look uh similar as it does now in terms of the decrypt um versus having to go through the process of making essentially what is like cross-chain Oracle request and waiting for the response via callback function um but the threshold service network you can kind of think of it as the MPC KMS that essentially handles um the decrypt conditions of the cipher text right because you don't necessarily want that to be just completely involved in your network for a few reasons um you know part security partly scaling Etc but again um I digress because that's not super pertinent to this haathon um Phoenix JS is basically the JavaScript library that's going to allow you to interact with um uh with Phoenix essentially um so I won't get too caught up with the fact that it's like a new JavaScript Li Library relatively it's somewhat straightforward it's it's actually in my opinion it's very similar to like standard stuff that you've worked with right this is basically just impacting your ABI interactions in the S where we're going to handle with permissions and I'll get to that in a second but as you saw before in the encrypted inputs right uh you can't just pass in the number five right let's say you have to encrypt the number five to be EU in for example an encrypted integer um and so basically the Phoenix JS here is kind of handling that for you it's subtracting away a lot of the uh a lot of the stuff and it can really be done in like as you can see that one line of code right there where you're basically just encrypting five um so what are permissions I talked about permissions but basically uh it's the encrypted Fields who has access to view these encryption encrypted Fields so like I said there's encrypted integers and let's say part of your application you need you know a certain party to be able to view uh a value for whatever reason or maybe you want to check your own value so what you can do right here is you can basically uh you know import uh the permissions library and from the permissions Library you can create this thing called the permission object and the permission object uh allows you to create um it's sort of like a modifier if you would on this specific function um and it's basically checking to see that the person that the message do sender actually is the correct uh person who has access to view this so what what's happening under the hood is it's basically kind of like a re like we're decrypting and then we're re-encrypting with the uh specific users Pub Key here and so it's making sure it's checking to see that the pub key uh the user is actually trying to view this the message not sender if you would actually has the correct Pub key access so uh again we can go in a lot more detail about the Nuance of this but uh this is just kind of a high L overview um here's an example permission and again conditions can be added so for example if you're part of a certain array then you're allowed to decrypt a certain field text uh but you know we there there's a lot of ways that that can branch and and that's one of the beautiful things about Phoenix is that allows you to have very conditional de uh re-encrypts or or sealed outputs if you would um so here's a sample smart contract we have more in our docs um we're hosting a 5k hackathon so if you're if you're interested we're looking for full stack applications if you have any questions feel feel free to reach out to me uh General runtime tips are that um you know if you don't want your operations to overflow your uh to overflow essentially there are certain uh limits to each block you can find that in the docs but the important caveat to remember here is that basically there's two distinct things that are going to impact your gas calculations and it's going to be what operation you're running for example division is going to be more expensive than addition um and uh what size bit length you're using right so like Divi adding two eight bits is going to be cheaper than adding to like 16 or 32 bits right that's just sort of basic engineering um and so here's a pro tip from developers is that like if you get stuck you know GPT is actually pretty solid for coming up with some stuff um you know it's it's probably worth a try and yeah I just wanted to say thank you uh if you have any specific questions feel free to reach out to me uh my telegram is at corsula 26 I like the Pokemon so uh yeah thanks for your time and uh look forward to hopefully working with you all right take care