So thank you. Thank you for joining me. Uh welcome. My name is Nick. I am a devil at Flare network and uh in this workshop I'll going to talk about Flare smart accounts and Flare confidential compute.
Um, before we get started, I have a quick question. How many of you have already know what a TE or a trusted execution environment is? Just a show of hands. Okay, so about half. That's good.
That's good. And another question, this is more of a joke one. How many of you have uh at least once in your life deployed a smart contract and verified it on chain? Just a show of hands. Okay, this is I I I've had a workshop at E if Oxford and in a room of 50 plus people seven raised their hands when I pose these questions.
So this is a refreshing change. Um so I'm glad to be here. Um so in this workshop we are first going to look at what flare smart accounts are. I'm not going to spend a lot of time speaking about this because we have a lot of video and written materials about this already. I'm more going to focus on the Flare confidential compute.
Um I'll just very briefly introduce what this is, show a couple of diagrams, uh but then I'm really going to spend most of my time showing uh a couple of examples of the Flare smart accounts and Flare confidential compute. Um, so first of all, uh, since I'm so limited with how much time I've got, uh, I'm going to point you towards, uh, useful resources that you can look at yourself, uh, yourselves. So first of all the Flare Foundation GitHub um specifically the FCE that's Flare uh compute extension um sign this is an example of a P extension on Flare. Uh the second one is the FCE weather API. Um, this is an example of how you can put a an API key into a TE uh and then have it retrieve uh weather data that is locked behind an API.
Um, then there is the Flare smart accounts Vim uh GitHub repo. Uh this um this repository contains multiple examples of how you can use the Flare smart accounts. Um and um lastly the um the Flare Network's YouTube channel uh and specifically the live section. Um this is where our uh so-called Flare Builder online workshops are recorded to. Um so if you prefer uh video guides, this is what you should look at.
and specifically the um session 17. This is the one dealing with uh Flare smart accounts, a more in-depth guide into that. But now let's return to the presentation. Um oh yeah, I'll also try to aim uh for a 20 minute presentation. So there's going to be a 10 minute uh time window for questions um at the end.
So first of all, the Flare smart account. Uh Flare smart accounts are an account abstraction schema that allows XRPL users to perform actions on Flare without having any Flare token. So for each XRPL user, for each address on XRPPPL, a personal account smart contract is created on the Flare blockchain which is controlled completely by payment transactions on the XRPL. So how the whole workflow looks like is uh an XRPL user sends encoded instructions to a specifically predesign predetermined address on XRPPL and then the machinery of the Flare smart accounts bridges that instruction onto the Flare blockchain, delivers it to their personal account and then their personal account performs the action in the name of the user and the the personal account is logged. So it is set up so that only the instructions from the user on XRPL to which the personal account uh belongs to uh only those instructions are actually executed by that personal account.
Um I won't go into more detail about the whole process although I really like to talk about it uh because the the two things that are important here are uh or the one thing that's uh really important here uh if you are actually uh developing with flare smart accounts is um you need to you need to be able to uh define or encode the instructions and for a a set of predetermined instructions such as minting FXRP which is uh XRP wrapped on the Flare blockchain minting that transferring to it to to an account depositing it into a vault. All of those account uh all of those actions can very easily be encoded with a special flare library. um which we also mention in different guides. Um but the more interesting one is the custom instruction which requires a little bit more work. It still can be encoded with the library but you need to be able to extract the function call.
So the function handle uh and the AI encoding of its parameters. Um yeah that's that's the difficult part. Um, but anyways, the trusted execution environments. So, for those of you that haven't heard of this, what trusted execution environments are are isolated secure pieces of hardware or pieces of CPU. um you are able to deploy code into the uh into a TE into a trusted execution environment but afterwards you cannot modify that code.
Uh no one can read the state. It is uh um the the data within the TE is encrypted. So it's only available to the TE itself. not even the owner of the TE can access it. Um, and the TE can also prove that the code that it is running is the same code that was deployed that it claims it is running and that it hasn't been tempered with.
So what these do is they take the security of a blockchain um and extend it to be able to handle secure or private data and computationally heavy tasks um because this is the main benefit of the blockchain. You get the smart contract and you know that given certain inputs there is just one result that you're going to get and it's same with ease. you know what code it is running so you know ahead of time what the end result is going to be. Now this is the workflow or the big picture of uh how the player confidential compute looks like how the data flows through player confidential compute. Um I'll again skip over most of the diagram because the two important parts are the user that interacts or that wants to um make use of the TE.
they have to interact with a contract that that the developer has prepared and the contract then sends instructions um through the chain of uh um command let's call it um to the T itself and then the T can interact with the outside world can produce results and then expose uh those results to the world the outside world by either writing them onchain or just writing them to a a special end point. Um this is the diagram expanded. So yeah, um it's the very same diagram. Why I'm showing it to you is because um the only two pieces of this workflow that the developer needs to modify is first of all the smart contract that it that can send the instructions to the TE um and then the TE extension. So the TE extension is the actual code that you want to run.
So that's I don't know an AI agent or something whatever you desire. um it can interact with the external world. It can interact with the flare blockchain. Uh it can also write the results to the external API. So that's slash action slash result API of the TE proxy.
Um but the whole point of the TE is that uh the outside world can only interact with the TE proxy. So that's a special server that it runs. um and more specifically with with its external API and then what the TE does is the TE monitors the internal API um and that's the only place it can get instructions from. So there's a firewall between the TE uh and the outside world. So the thing is happening securely.
That's a very very brief description of what's going on here. Um let's jump to examples. So oh that was not the right one. So and let's also close those two. Yeah, I should have done that beforehand.
Anyways, this is the FC sign um repository and I also probably need to enlarge the whole thing. Um yeah, that's probably better. So, um, I encourage you that you read through the readme of the FC sign repo if you're going to go the TE route. Um, this is a repository that comes with all the support scripts for deploying the extension, registering, all that uh kind of stuff that I've skipped over in that diagram. Um so what I'm going to show you is the two pieces of code that you do in fact need to modify.
Um so that's the instruction sender and then so the DE can uh theoretically be written in any language um but the language has to be powerful enough to perform certain stuff. Um we have here a go and a python implementation uh just as a starting point. You can also write your own implementations but I I think that at least Python should suffice. But anyways the instruction sender smart contract um this is the thing that the use the end user will actually interact with. Um and then what the end user is going to do is they will u call the update key function which will uh store a private key into the TE and this is secure because no one else but the TE can look inside of the TE.
Um and then the user will call the sign function and all this does is the T will sign a transaction for them on Flare. Um so yeah the all that this smart contract does is it prepares the T instruction parameters. Um and the three parameters that are important are the op type, the op command and the message. So uh the op type and the op command. They can be anything you want to except a certain u set of of keywords that are reserved by flare, but you probably won't run into those unless you're very unlucky.
Um so they can be basically any string. uh it gets converted to bytes. All that matters is that you have the same string in the actual t um it so in this case we have the op type e which is the same uh for both function calls and the update and sign op commands. This is just so that he can case match uh the data that it is being given. Um, as you'll see in a second, this is all that happens in the background.
The T just literally case matches op command and uh goes from there. And then the message itself in this case it is already um it is already uh encoded as bytes. Um, in the case of a private key, the private key needs to be encrypted with the T uh T's public key before being sent uh uh over the blockchain. Otherwise, you've just exposed your private key. Um, but yeah, um, this is very briefly about this contract here.
I'll open up the Go example. Um because this one um has better case magic. That's all. Um so uh so Oh yeah, here it is. So the T um the functions for the T are in go internal app handlers.
So these are the handlers for different cases. Uh so we have handle uh key update. This is what triggers in the case of the update key. And then uh handle key sign. This is in the case of a user calling the sign function.
There's a bunch of uh like error checking, but what this resolves to is just setting the private key as the thing that it received. Um and yeah, so we register different handles for the op type uh and op commands. Uh the op type and op commands are set are defined in the config. So this here is where you need to set your own opt commands and uh um yeah op types and op commands. Um so that's all very briefly now we're kind of out of time so I won't run the thing here.
Um there's a couple of steps that you need to perform oral describe in the readme. Um but it basically resolves to having an angro uh or a cloudflare u tunneling setup so the data providers the validators from the flare network can access the this local version. Oh yeah, I forgot to mention uh we've prepared a tool set so that you don't need to actually deploy the things to a te just a local deployment on your or a local host uh service is all that you need to run for for this hackathon. Um um and yeah, you need to connect to a database. there's a username and password that uh you need to get from the Flare team at the booth.
Um but otherwise you can just follow the read me and it should be fine. Last thing to mention, the uh the example repositories come with AI skills that help with uh creating a custom extension and we also have other uh skills available for other pieces of layer tech um just because the time is limited. So um for VIP coding purposes, this is it. Uh but yeah, this is it for the uh workshop. Now it's we have 10 minutes for questions, right?
We probably have time for one question. Um and then anyone else can ask you at the booth.
Perfect. Any questions or any one question?
Is it ord? Is it Intel TGX or SGX?
Um, I'm not sure. I think that you need to ask Philip at the
Okay, no worries.
Thank you.
Maybe one more.
One more question. Um
so I was I just wanted to ask a question about the interaction uh with the the data providers and the validators. Is there a proxy for that just dedicated for the hackathon or are we going to use the real uh uh data providers?
So the data providers are going to be real. um you're just going to set up a fake proxy basically like the whole machine here will be mocked on your PC. Um what we've uh there's a piece missing from this diagram which is an uh a a C chain indexer for flare which is needed for um just to to to uh to recognize if the uh signatures that were delivered represent more than 50% of uh um of the consensus. So, um that thing is going to be mocked by giving you access to a database with uh with our own indexer entries. So, we made this as lightweight as possible.
No, cheers. So, uh thank you for coming to this workshop. If you have further questions, do stop at our booth.
Automatic transcript — names and jargon may be misspelled.