Confidential Computing in Web3: TEEs on Flare

Transcript

Mhm. >> [snorts]

[snorts] [snorts] >> So, I start?

Yeah, I guess I start. Thank you for setting up everything. Uh thank you for joining here and also those who are watching online later. And today I want to explain about confidential computing in web3, especially how we do uh that at Flare. And uh yeah, like blockchains essentially are excellent and very good in transparency and making it everything verifiable, but sometimes you don't want to be public.

Let's say, for instance, some couple of examples would be user data, business logic, some kind of specialized strategies, compliance checks or cross-chain interaction, or some kind of sensitive off-chain data. You want to keep it private. You don't want to expose it. And then there is question how can we keep this sensitive computation private? You can come in closer, otherwise you won't see the code later.

Uh so, how can we keep this sensitive computation private? Like how we execute something, but still have proofs and trust and verification on chain. And this is where Flare confidential compute or TEEs in short uh, in and I will, uh, give you short presentation and then we will, uh, actually see the code how it works behind the scenes. And before I go, uh, deeper into, uh, Flare Confidential Compute, uh, let's take, uh, quickly look what is Flare.

So, Flare is EVM Layer 1 and it's designed around data. And, uh, core idea is that, uh, contracts can access data, uh, from, uh, other chains, let's say prices, events, proofs, messages and also Web 2 data. And, uh, we can clearly say that, uh, Flare is blockchain for data if you need to process, uh, that kind of, uh information. And, uh, Flare Confidential Compute especially extends this idea with data because we can bring data on chain, not only read but also write. And, uh, do it in sensible, uh, private manner and have proofs back, uh, on the

on chain. So, basically results are relayed back on chain. And, uh, quickly about, uh, Flare Confidential Compute. So, that, uh, like I explained, adds, uh, this confidential, uh, execution layer, uh, to Web 3. So, uh, basically sensitive work uh, happens off chain uh, when you don't want to expose like private keys, API keys or something or, uh, maybe some, uh, you have AI models, what what are you, uh, running there, you don't want to expose and also you have much more power than it is on chain. So, you can access, uh, you know, better machines for your,

uh, for your tasks. And then everything is anchored back, uh, to chain. So, uh, there is integrity, identity verification. So, that comes back on chains. And developers can build applications where private stays private, but uh like computation still is in isolated environment, so that is the TE. And blockchains just receive sign actions, instructions what are sent to the chain, and then relay it back. And I think this is quite powerful because we still get

qualities of blockchain, and we can extend it and do it in actually very safe and trustless manner. And I want to explain that I mean stress that Flare confidential compute is still in latest development stage. It's on testnets. Uh Uh yes, so today I will give sneak peek. It might change maybe slightly, but we are close to mainnet as well. So, right now we are getting like feedback. We had first hackathon, so yeah. I I hope it will spark some

uh some feedback today as well in the or tomorrow in this conference. And how it's kind of tied together, there is everything is dockerized. There is uh TE node, TE TE TE proxy where which is relayed information from blockchain to T TEs. Uh but the main thing what developers need to worry about or need to develop essentially are Flare compute extensions. So, we can say that these are small applications in TE environment what

runs inside these TE machines in a secure enclosure. And thing is that these extensions they don't have access to outer world, let's say. They have access only inside, so they pretty much get instructions in asynchronous manner. Then they process these actions and then they post results. So, they don't have access to the blockchain itself, so that's behind the proxy which signs all the transactions.

And yeah, we can have like small small comparison. So, basically smart contracts are deterministic and public, but Flare confidential compute extensions extend these smart contracts into workflows into confidential private off-chain execution. So, that's I think it's very very powerful. And yeah, the mental model I think is public settlement but private execution. So, public settlement option.

And thing is that all of this is with saved with the consensus and basically all the instructions to these are related with 50% signature weight from data providers. So, that you will get same proof. I mean, same security as system Flare system itself, the network. >> [snorts] >> And yeah.

So, that So, we can think about these extensions that those are like notary that you can prove that some that notary kind of signs like document but they they not always expose what's in the document. So for instance you want to know that if person can you know buy alcohol let's say very stupid example but that's the most simplest one and you need to know only if that person is about some kind of threshold age. You don't need to know their name, you don't need to know their exact age. You just need to know that that's

like above this threshold. A notary signs, notary says yes you can sell to this person alcohol and that's how these extensions work. So the proofs are still relayed back to the chain. And today I want to explain I mean I want to show demo. So we look into more and this demo is weather insurance. So basically you came to this conference hopefully today won't rain but actually yesterday and day before it was raining and you buy insurance. So if it rains you get

money for taxi to come to this conference so you don't need to come here you know soaking wet. So yeah so that's the application I will be showing. So let me So this is the front end application I will be showing.

We will go into details how it works behind the scenes. Uh and a couple of things to set it up as it is insurance application is we need to have some kind of pool. In this case, that pool multiple people is just pool and it uses mocked ERC20 token for simplicity reason because that's not the main point of this demo. But here is the you know the real meat of this demo is that we want to buy a policy and uh here I have two options which is private

and public and we will look into today only in private. And uh how it makes everything private is that uh the signing mechanism is using ECIES mechanism. So basically TE has private key and it exposes public key. So this is the very important how you can encode information and send to TE and that TE has only this key and then it can encrypt it. So that is very very important. So it exposes public key. You can get this public key with a get request uh through the TE proxy for this

specific TE extension. And then encrypt information and then you know that no one else can encrypt this information because only the key is in TE. And important is that this key is in TE. So basically no one else can alter that. Otherwise the hash of this TE is not correct. And all of these hashes are in TE registry on Flare blockchain. So, you know that you are interacting. So, basically when you send interaction, we will check how it's from the code.

This interaction won't be relayed to the TE. So, the kind of integrity checks are not in place if but the thing is that TE, as it is trusted execution environment, is in secure enclave and no one can you know change it. So, once you deploy it, it's there. And yeah, of course there is problem that what happens with the TE goes down. So, pretty much there is no state. There can be some workarounds, but I will not go into details in this demo. So, we are actually currently exploring these mechanisms.

Redundancy that is you know problem as well. Uh Oops. And yeah, so then we can buy the policy. I will go into details. And then I created where the first demo feature which is getting live weather. So, this application where it gets weather, it it gets from OpenWeatherMap API.

We can argue if that is you know legit or something, but that's one of the best out there. And this is how we can so the mental model how to get weather is from this OpenWeatherMap API. Let's say we want to get weather for for Berlin right now. So, what it does is that it constructs I will jump in the code quickly. It constructs the request that it will be sent to T. And as I explained, T works in asynchronous model. So, as you saw, there was small delay. So, instruction is sent to T.

Basically, you say to T, "Hey, please check weather." That's That's what you essentially say. And then T does its work. In this case, it was a couple of seconds, but if you are working with like AI models or such kind of things, then of course it can take more more time. So, you need to see when this instruction has been processed. And we can see that currently it's almost 18° and scattered clouds. So, hopefully it will won't rain today.

So, let's go into code. So, here I will not show everything, but some some parts and code of course we have on our GitHub. I will show the post the link in my X as well. So, everything is open right now. You can, you know, download and check it out later. But this is the smart contract how when you call get weather interacts with this specific function. So, what it does, I will make it a bit bigger.

What it does is that it gets the T from registry. And in this case, we are getting just one T machine. So, we are not using multiple, but for redundancy actually it could be more than one as well. The important one is that we are using extension ID. So, each of these, you know, small applications have their own ID, but there can be multiple machines who are running this uh extension.

Uh we have cosigners feature as well, but in this demo I'm not using cosigners. So, that's another layer of security. And then we are constructing the T instruction parameters. So, essentially that is a struct which says what is the operation type. In this case, that's weather and what's the command. And then we are encoding message. So, message is arbitrary data what T will encrypt.

Uh I mean, decode. And then we send that instruction to T registry. So, we have all the necessary information what's the T ID, what's the extension, what's the message, and then we send to registry. And then the Flare network like validators, they see, okay, that's like valid instruction. All the hashes match and then they can send I mean, the T proxy can pick it up and see and I mean, relay to the T itself.

Come closer then you can see code there. >> [sighs] >> Uh and let's go to the extension itself. In this case, extension is written in Go, but pretty much that's like web service and you can use TypeScript, you can use Python, whatever language you like. And Here we have a bunch of uh Here is the config file where we are configuring these types which is operation type weather, and then multiple commands. And this case we just executed fetch,

but then there we will look into how we buy policy as well. And then the extension itself. So, what what it does essentially is that T proxy sends requests, and then it processes the actions. And in this case we have just one action, which is weather. And then uh here we have function, which is processing the weather, and then multiple commands. And here what's important is that in this case weather fetching.

So, we can scroll a bit down, and what happens here there a bunch of checks if we check if there is open weather API, if message is fine, but the most important here is that we are actually fetching the weather, and that leaves in this utilities uh utilities file. And what it does it's actually not so interesting. It goes to open weather map API, and it fetches weather. Those who are in back you can come in front,

otherwise you won't see anything. Uh and once that is done then we have the report of the weather, and then we are constructing result. And the T proxy signs this like result, so then we can see what if that is that came from this tea. But, uh uh I think that's like very simple, but let's try and buy policy with this application and then go into more interesting flow.

So, let's say we will buy for instance for Sunday. In this demo, of course, we can buy from backwards, but of course in real application it wouldn't be the case. And here what it does it's it approves this test tokens to buy the policy. That's not so interesting, but here all of this cryptic thing is that it's it tries to buy policy in private manner. And we will go into code step-by-step.

So, let's hope everything works. So, that that executed, but now we need to relay back to chain the result. And I will go into step-by-step in code what is it is behind the scenes. So, don't worry. And here we have Berlin. We we haven't settled that policy, but let's go into code how it works behind the scenes. And uh two So, here we have smart contract and let's go to uh

to this function which is buying policy in private private approach. So, basically how it works behind the scenes is that once uh uh we specify the minimum rainfall. So, basically, if it rains more than 1 mm, we will get the payout. But, we don't want uh that everyone would see this minimum rainfall of uh millimeters. We want to encode it. And as we see in this uh list, that is uh hidden. Like the mini this millimeters uh is hidden.

How it works behind the scenes is that we uh know the uh extension. We We that specific extension, we get the uh public key, and then we encrypt this information. So, only the TEE can encrypt it. And that is what we call here. So, uh this is this is encrypted uh policy. And again, uh like I explained before, we get the uh TEE uh from registry. So, in this this case, we have just one, uh but we can have multiple machines running the same uh extension. We're not using uh cosigners.

And we're executing uh operation type weather and command buy. And we're sending this encrypted uh policy. And then we're sending to uh registry, so the validators can validate that everything is fine. The TEE hash uh is uh still intact. It's uh valid, and then it's relayed to the uh TEE uh confidential uh compute. And uh then we need to go to uh ex- uh extension. And uh here, uh let's uh jump to the uh buying uh uh buying uh policy uh privately.

So, what What it gets here, uh it gets here the uh private buy parameters. So, remember we encoded with private key. So, basically that decodes that information. So, now the because the T only can decode because it has this private private key. And then it gets all the parameters like date, premium, payout what we had here in this in this front end. So, it gets all this these parameters.

And it creates commitment. So, commitment in this case it is hashed information that we can relay back to blockchain. So, then blockchain can reference what's in the T memory. So, T is not exposing the this millimeter threshold. So, it has the a hash of this policy snapshot. So, that is what is relayed back to chain. So, then once it's done, it tells that hey, I have the result. Go and you know, we can see that that result is published. It's again in asynchronous manner because it can here it it's very

very fast, but it can take more time. For instance, if you are working with a model predicting weather or something, then of course it takes time. And then the secondly, you saw another transaction. So, that is finalizing private buy. So, pretty much anyone can execute that and let's go into code what happens there. So, that when we relaying back the private buy, we have the uh data from the T instruction uh result. We have the action ID. We have all the necessary information. And we have the signature of uh this TE as well. And then what it

does is that it uh uh reconstructs uh this result. So, we have the result data. Remember that was uh hashed information. Uh then we have a submission uh tag. And then uh it's uh very important because it checks that uh from which TE this instruction came. So if uh you are trying to feed some malicious uh information, then the signatures are not uh you know, like working. So, the signatures are wrong. So, basically, that information could be signed with uh not correct

uh key. And then we are uh saving this information uh on chain. Like all these parameters, what's the payout, rain threshold, uh all that stuff. And then we are creating uh policies. Then we get the policy uh ID. And we are not uh exposing the uh in this list the uh what's the rain uh what we are you know, buying the policy. So, no one else can uh see it or they can, you know, see what what I'm uh working on. So, we have only the proof uh on chain.

And now uh we can uh go and settle this uh policy. So, basically, we want to get uh the payout. We we know that it was, you know, uh raining. And again, I will show from the UI and then uh go into into the code. So, what it does, it requests the uh settlement for this specific policy. And then we get back the I mean it's it's related to the T. And what T in this case will do, it will go and to OpenWeatherMap API and check if there was rain. And we can clearly

see that there was 3.44 mm rain measured in Berlin this Saturday. Then we get back 10 tokens for our policy. So we bought for one and we got back 10. So this very simple how insurance works behind the scenes. But let's go into code where we have, you know, all the all the interesting stuff. And here I'm in within smart contract. So first we start calling this function request settlement with policy ID.

Then it gets the policy from the policy registry array. Checks that there is this policy. It's not settled. We can settle after specific unlock. In this application I said that you can settle policies which are for previous day or after 6:00 p.m. today. Otherwise there is no data for today yet measured, you know, rain. And then we are getting the T like we did before.

And constructing the message. And in this message we have policy ID. We have address who is settling this policy. Then we have date, latitude, and commitment. And remember that commitment is hashed information of this uh milli- uh millimeters of rain. So, we are still not exposing uh to publicly what what it is because maybe someone can intercept it in in between before our policy has been uh settled.

And then we send this instruction to uh TEE. And I want to stress again that TEEs work in a synchronous manner. So, you send instructions, they process it, and return uh result. And then we using uh proxy, you can see that okay, this uh instruction has been uh processed. And then we send to the TEE registry. Again, uh all the network validators validate that this is uh correct. It belongs to the uh correct TEE. Uh the code that I mean the hash hasn't changed. There is uh uh TEE machine running. All that is uh uh what network like validators do.

And let's go to extension. Uh again, I explained that this is in code in Go, but it can be in uh different uh language as well. So, we need to find uh uh that is process weather settle. Yeah. So, we have uh this function. So, basically that uh gets the uh processing the settlement. So, basically starting the uh settlement. Then we have a bunch of uh checks if we have API keys.

And then we are uh decoding the uh settlement message. So, then we we get the latitude, longitude, basically location, uh date, uh all that stuff which we are saving here. Uh and uh we need to untangle the private terms. So, now we have the hash, we have the terms commitment, we have the inside in T memory that no one else can see uh this this millimeters. So, we take the hash and we get the correct millimeters what we need to you know see if that insurance we need to pay out. So, still is not visible to

to to anyone. And then what what it does is that it fetches day summary using open weather map API to get the measure precipitation I mean millimeters in rain in short uh uh from the API. And that happens here. Uh and it's uh I would say nothing interesting is just API get call with specific parameters and API key which is not exposed as well. So, this API key is only it's private in this T machine.

So, no one else can see it, no one else can you know read it. So, that's for you. And I think yeah, it's very powerful. And I will talk a bit later other use cases where it could be even more powerful than this application. And once that is done, we have the revealed threshold of millimeters and then we are creating the settlement result uh what was you know what we get back from the open weather API.

And then once that instruction is I mean this process has finished it tells hey, I have finished this this this action and then we can get from TE proxy. Okay, this is finished but we need to relay back that to chain and that's why you saw two transactions. And in this second transaction is being called settle function. So, we have the result data what comes from TE. We have action ID.

And and then important is signature because signature what happen what is comes from the TE. And then if all the signatures match so basically we derive the signer from the from this data. If that matches so basically this message is from correct TE. Then we can write this information on chain. And in this case we are decoding the information from the from the result data, the policy ID, what's the millimeters, what's the date and what is the revealed

threshold. So, basically what we how we bought the policy at first place. In this example I made that after the policy is settled we can see what was in this policy what the user specified but of course that could be actually private information as well. It's just for the demo that we can all see it. And we are updating the storage so basically everything is on chain so what you see in this front end application it it comes from from the chain.

And Yeah, here is the check if it's private commitment then we are revealing if everything is you know fine and yeah we then we update the array on blockchain and emit settled. settled event So this is how it works the from the code and uh Yeah so we in this application which is open source on our GitHub I will post the link on my X or you can find on Flare Network GitHub and we can follow along everything how we for instance

bought this policy. So we can see that we bought for one token. And of course we can see that uh it's settled and we get back 10 tokens. So it was raining we came came to the this conference we're so wet but at least we get money. So for those who joined later this application what I'm showing is that if we come to this conference it was raining we bought policy before and when we are you know wet there is rain we get money for taxi. So that's how it is and the T

extension machine checks from the OpenWeatherMap API data it it sees that okay there was actually rain and you get the payout. So that's short I mean maybe not so short from from code perspective. I have couple of slides but then I will open open for questions or recommendations. I hope it makes made sense. I'm not going over everything and we have worked uh for this like for for a while and everything is dockerized. So, there is like what I mentioned T proxies, T

extensions, all that is dockerized and we have guides how you can start writing these T extensions. So, you you do actually don't need to worry about everything. And later on, we are working with Google secure cloud. So, this is the first partner we are partnering with where you you could deploy the T extensions, T applications. And we have multiple guides, multiple information how to you know, deploy applications. And everything is still in development. It's on testnet, so it's fresh and I'm happy that it it worked today.

So, let's go back to the uh Uh, so here's the link for for the demo, but I will post that in on my X later as well. So, you can find under Flare Foundation GitHub as well. And the time what I have left, I I want quickly explain what could be even more developer use cases because this uh relatively simple application what I showed just goes and reads the information from API and you are encoding this API key which is not visible. But there could be even more

use cases like for instance private DeFi applications. Like you have some kind of re-scoring which is only you don't want to expose it. It's your tactic. Some kind of specific logics like private routings or confidential public checks you are you need to, uh, go and check, uh, to some kind of API. Or, uh, real-world applications, though that's actually very important as well. So, you so you have some kind of maybe land registry or like state, uh, systems where you can verify that this information is actually, uh, true. So, uh, how we verified if, uh, whether what was the weather information.

Uh, like regulated, uh, applications. For instance, like I explained, there is like, uh, compliance checks and you don't want to expose, uh, a sensitive information. For instance, people's age, people, uh, names, whatever it is. You just need to check if they are, for instance, uh, citizens or, you know, they, uh, own a property. So, that's can be, uh, possible here as well. Otherwise, it could be open and, uh, yeah, not that we want, uh, to expose this information. Like data marketplaces or and, uh, very important what we are working also, why we actually created this and we are, uh, giving to anyone I is cross-chain, uh, automation or cross-chain communication.

So, we're working right now on, uh, cross-chain, uh, wallet specifically with, uh, Bitcoin. So, this is how you could control from Flare network which which is EVM chain, uh, Bitcoin, uh, wallet. So, you have the, uh, private key of the wallet of Bitcoin wallet and then you can initiate trades, you can read information, all that, uh, stuff. And the key is not exposed to anyone. Only the code and proves that you did, uh, something. And we call it protocol managed wallets. So, basically, uh, system protocol manages wallets outside, uh, chain and I think it's very powerful which could open even, uh, you you more eyes, uh, in in my opinion. And

the thing is that uh, all of this technology that I am showing right now, we are dog fooding ourselves. So, basically we're building uh products with this information, same APIs, same technology, and we are giving to anyone outside as well to build applications. And yeah, and I think uh there could be some uh security trade-offs, so which I need to mention. For instance, uh like the key, you need to handle like failure.

Basically, the T machine could go down, it can rotate. There could be you know, you need to think about recovery mechanism, maybe some multi-signature approach, how you store this this key. Of course, the T machine itself, no one can change it. Otherwise, uh the hash is different. So, basically you you see that machine has changed. But how you handle like keys, what's stored there like to wallets for instance, that of course is still up to you. It That's not the technology what solves this specific problem.

Yeah and another use case is you know, attestations of some information, external data like for instance, we attested that weather was measured at that specific you know, millimeters, and then we got a payout with this application. And that's it. We have We are before time, so if you have any questions, I know that you know, lunch is coming up as well.

But if you have feedback, you can come and ask now, later uh I will be available throughout this week in this conference today and tomorrow as well. And still this is very new technology. And we think that it will open many doors because there is privacy manner privacy approach in blockchain. So you that's how you we can extend our smart contracts blockchain applications and it opens many doors. Either communicating with other blockchains, getting information from other APIs, writing to other APIs, I know banking, weather, whatever APIs and

everything is everything could be their private and you relay back only the validity proofs. So you don't expose private information. And importantly, you can get more powerful machine than it is blockchain because blockchain is very limited. It's limited by gas, what kind of computation you can you have there. So let's imagine you can run like AI model in this trusted execution environment machine, which is in private only for you. You do the computation with this model and then only the have the proofs I mean the results back to the chain. So I think in this AI world that's very important as well.

I will be working on this idea later this summer. So you can follow my on my X as well. I will post what what we have because we have multiple ideas uh how we can jump in this AI field and in trusted way. For instance, especially what happened in in last week with anthropic thing that now we don't have have in Europe this nice model uh uh person we we all know who said that you cannot export that. And I think that shouldn't be the case. We can do better that everything is kind of in just couple of uh people's hands that you can make

decision in 10 minutes. And uh yeah, I think it will open those doors as well, especially in AI. And in real-world applications like like I explained, uh I think this is the missing piece what was in blockchain. We have been talking about that for years, but here you saw a working demo already. So, thank you. If you have any questions, then uh uh ask right away. Don't be shy or feedback as well. Thank you. >> Can you go to the process again I would like to know more exactly

uh who executes the ghost script. So, and also like how do I run the whole setup from start to end? Do I have to fork your repository, create spin up a server, and put everything to run there? >> Yeah, can you repeat for recording? >> Sure. Is it working? >> Yeah, I think so. >> I don't >> Test something.

>> Testing, testing. >> Ah, okay. Now it's working, I think. >> Okay. So, uh my question was I don't know for sure if I'm here. >> It is working. >> Fine. So, my question is uh if you can go through the process of how the ghost script is executed. And also the end-to-end scenario. So, I fork your repository, spin up a server, and put everything there. Uh so, that's sort of confusing for me. >> Yeah, yeah, yeah. Yeah, I I I I get the point. Uh right now is that you uh run it locally in dockerized containers.

So, I have a docker containers here. So, this is the it's very small, but this is the weather insurance. It has the the database and the proxy and extension running. So, those are different services. So, I will uh jump I will explain only about the flow. So, basically from uh from front end, you start buying the policy. Let's Let's go step by step. Uh and how you run it right now we have a repository which you can, you know, clone and then you can set it up. There are guide guides on our DevHub also how to set it up. Uh and I will be actually publishing about this specific uh

use case most likely next week. So, about this weather insurance as well. So, there will be guide how to run it. Uh and how it works is that uh So, you have a T extension running locally, but later later this year we have guides how you can deploy to Google secure cloud. So, there you can will be running this extension. No one can touch that one. Right now it's in testing phase as I explained. And how it works is that we specify here the policy parameters. Then we call the smart contract. And smart contract has there is T registry on blockchain where all the T's have been registered and

their hashes. I'm pretty much that is Here we have system explorer as well where all the T machines are uh are set up. So, I'm working with this specific T uh And then, as TE, it uh processes these actions in a synchronous manner. So, basically, it sits and waits waits and then see, "Oh, one action came in. I will process that one." Then I I processing that I'm doing some you know, magic. In this case, let's say I'm fetching the weather information. I have that one. Maybe it takes 1 minute, maybe 10 minutes, maybe 20 minutes. And

then, it relays the result back to the proxy. And then, you need to actually fetch from the proxy that specific instruction has been finished because you have the ID when you send to the registry. And then, when you have the result, then you relay this information to the chain. This was the I explained that you see that this signatures match. Otherwise, if signatures don't match, someone can sign this information from different TE, different machine, whatever. So, you need to see that this information match and this is correct how it is in TE registry. Because when you set up everything, you actually registering your TE in TE registry. We have network level registry of all the

machines and all the hashes. So, that's the validity, you know, you know, integrity check how it is. It's not like sending out in the void. And then, you once you process that information, there is actually no specific need to send to the blockchain. It's just how the blockchain applications work. You have the proofs on on chain. So, this was the what I explained with how we store information. We don't expose this weather millimeters, but we have the hash of this policy. And that's the kind of the privacy aspect. So, you it's up to you how you store this information on chain, right?

So, uh yeah, so that that's uh essentially it is that you through registry you send this instruction, then it's being uh picked up by uh T in asynchronous manner, and then it's uh the result is relayed back uh and then you fetch from the proxy. So, yeah. I don't know. Maybe this is I hope that's working. So, I hope I explained uh and all the guides are there. We have very simple uh sign uh extension guide on our dev hub. Uh it's updated. It's up to date. Uh basically, how you can sign information, and pretty much you can I know uh commit to GitHub or something. Uh you you have

GitHub key in this uh T. So, that guide is up there. I will be adding this guide uh la- later uh next week. So, yeah, I hope I answered that question. Of course, this technology it's per se it's not easy, but we are hiding away because we're making it uh containerized uh dockerized everything, and you can spin up uh docker. So, you don't need to mess around. Actually, developers you can read more what's behind scenes, but you need to be working on extension code itself, and everything else is uh dockers. Of course, it's not simply uh simple, but uh it's uh relatively straightforward how it works. Uh uh But, of course, we I would like to get

feedback if that guide is, you know, understandable uh because we I want to improve that uh as well, the all the flow. Yeah, good question. Thank you. >> Thank you. >> Any other questions? Uh comments? Was it kind of clear clear? Uh I I Maybe I want I want to ask audience, are you exploring uh trusted execution environments or private execution uh yourself? Uh What what's the, you know, uh theme of there? I know. Maybe show of hands who are like exploring trusted execution or private execution outside blockchain. Anyone?

Okay, I see. Some hand. Maybe you can give a >> [snorts] >> Yes, so we we run a we have our own solver infrastructure. So, we're trying to like create an environment where we can do private solves and stuff because we see a lot of value there. So, yeah, I mean, a solver like touches so many infrastructure points from relays to sub environments. So, we want to see like could be a hybrid environment where we use TEEs for certain aspects and like ZK stuff for different

aspects. So, yeah. Yeah. We see value for TEEs for certain aspects of a a model, but like kind of like Yeah. ZK kind of execution stuff for privacy elements for different stuff. Yeah. >> Yeah, I would say this yeah, it's maybe different than ZK because this is private compute. So, you get actually compute and that's the essential. So, we need to think about these machines because here was just simple example, but you can have maybe running some some code for I know half an hour, you know, AI model or maybe even more. So, it can be such and you cannot get that on blockchain.

You cannot get even, you know, couple seconds pretty much execution. And this is how what opens doors in my opinion as well this case because we shouldn't limit ourselves just couple of minutes. Of course, you pay for compute time. That's like obvious. For a machine you need to pay, but you get the proofs and you get the security aspect of blockchain because all the network is still validators are proving that these instructions are, you know, valid. So, yeah, I definitely would like to see more use case how you would use this. Thank you.

Anyone else or we're ready for lunch? I guess that's it. Thank you for coming and if you have feedback then catch me later. And have a great Devcon. Thank you. >> Thank you. >> [applause] >> Mhm.

>> Mhm. >> Mhm.

>> Mhm. >> Mhm.

>> Mhm.