Warden Protocol & Statistical Proof of Execution (SPEX) for verifiable computing (ML/AI)

Transcript

Hello and welcome everyone. My name is Peter Robinson and this is the Ethereum Engineering Group meetup. Today we've got Antonio and Michelle here who are going to talk about the intersection of blockchain and AI and some interesting technology that they have um been working on. So before we dive into slides um I don't know Michelle do you want to go first? Um do do you want to explain you know give a bit of background quickly who are you why are you here and you know just and then flip it over to Antonio. Sure. Yeah. Yeah. So so yeah so who am I? Um my name is Nik and my background is computer science

worked uh uh in research a bit um around database technologies and uh yeah and then jumped into robotics ended up doing more and more data science machine learning and since more or less one year uh I'm working with warden labs on how to bring AI uh on chain and yeah that's me in a nutshell um Antonio to Hello everyone. Um, my name is Antonio and well, I'm a software engineer with a few years of experience. Keep it short.

I started my journey into in the blockchain industry by joining Tender Mint, the company behind Cosmos and the Cosmos SDK. And then I moved on to Warden to basically make our own blockchain. And as Mikuel said, we are trying to bring AI into this this world. Um yeah, I would keep it that way. Okay. Well, well, thank you both for joining today and um look, why don't you present your slides and you know um are you happy for how would you like to take questions?

Should we wait to the end of each section, dive in and whenever just put them in the chat or wait till the end? How how do you how would you like to handle it? So since uh we uh we we are a small group uh we can take the opportunity to to maximize interaction. Uh so yeah please uh uh let's uh uh stop the presentation at any point. Let's try to have it as a conversation uh as much as we can. So whenever there's something interesting to dive into, please uh stop us. Okay, sounds good. All right. Well, please both of you take it away.

Great. I'm going to share my slides. Sorry. What Antonio? No, no, no. Yeah. Share your screen if you can. Yeah, it should work. All right. You can see it, right? Yep. Perfect. Let me Okay, perfect. So again, thank you everyone for for joining and uh yeah, today we're going to talk about uh uh this

new technology. We we envisioned uh uh six plus months ago and recently also published a white paper on it and um we are now ready to talk about it. So statistical proof of execution and short specs uh and uh let's dive into it. So what is the main motivation behind this work? Well, in uh uh for both onchain and off-chain applications, uh uh you might want to request uh to a black box some kind of uh um output, right? Which could be an AI model and you want to get back some um predictions, right? So let's say that we want to to consume some

predictions from an AI model and me the submitter uh a request uh to to to another system the solver to produce those predictions for me as we see here in the diagram and then yeah uh again uh I might then consume these predictions onchain or offchain. Well, this is great, but uh uh I also want to trust these predictions, right? So, this is why um in this very simple uh scheme, we we we might also want to to introduce a third party the verifier that uh given some proof of the uh based on the

predictions produced, it can tell me if those predictions uh should be trusted or not. So this is uh at very high level the motivation behind this work. And uh um to give it a bit more uh breath um in terms of motivation uh motivations an increased uh automation in decision making general driven by MLA inference which really uh is often just a black box. We cannot really uh inspect much.

There's a lack of verification uh in using this technology with with an increasing potential errors, biases, manipulation. We just don't know. It's an opaque box. We don't control, we don't cannot inspect. Right? So, uh uh as we saw before, uh all kinds of questions come up. Does this rest API always returns the same value if I fit in the same inputs? um is the forecast consistent with the model specification? Can I verify somehow that the the outputs are correct uh that uh have been obtained or computed uh uh using the the intended model? Is this

result tax generated by the LLM I'm paying for and potentially not a cheaper one? So all these questions boil down to verify what was the uh computational process that generated the output. And uh yeah here we have the the supporting article which we will um extract some uh content for this presentation. But yeah for for questions or or deep dives this is really a good resource I invite everyone to look at. Uh we probably cover one uh of the white paper in this talk. So um yeah, so if you are interested in in more details

uh let's uh yeah invite you to have a look at it. So let's uh let's start some preliminary definitions and uh uh this is very important to to make sure we are on the same ground uh and we understand each other. So let's uh let's say that we have a certain task uh which can be any compute pipeline could be ETS data transformations uh or machine learning uh training workloads in LLM workloads any kind of rest APIs. So in general any task which provides some inputs we expect some outputs out and uh we have also a specification function f f is a

function that serves as a a reference implementation for the task which we also can use uh uh to verify the correctness of the outputs right so uh we can verify the outputs are correct making sure that uh if we do use the function f as implementation we would obtain the same result. So it serves as a correctness criterion and uh yeah then we have the solver s uh which is an executor for the tasks uh and might have an incentive to manipulate or or alter uh outputs. As we saw before, the solver is a party that uh uh com provides the outputs provided the

inputs and lastly the verifier is again an executor that verifies the correctness of the outputs of certain solar s accordingly to the specification function f and uh uh let's uh briefly talk about the the behaviors uh which we can have in the system. So we have a honest executors that uh yeah carry out the computation correctly and fully and uh maintaining accuracy integrity. So not manipulating outputs. We can trust honest executors. Then we have lazy executors uh that might skip or approximate some steps to reduce effort.

Uh they don't have any strategic intent to alter the results. they just want uh to skip or approximate uh some steps to reduce effort. We have then adversarial executors that might uh have a hidden intent uh to manipulate computations and uh potentially also incurring higher costs, right? Uh so uh to make sure that uh uh not to make sure but uh uh to try to to to manipulate the outputs uh uh try they might uh do the best uh even uh doing more work than acquired uh from an honest executor for

example and altogether lazy and adversarial executors uh are grouped into dishonest executors. So let's uh um I don't see the question. So if there are questions in the chat, please stop it. Uh let's now briefly um provide a for more formal definition of the problem we we want to work on uh introduce here. So verifiable computing given a task D uh that is executed repeatedly with potentially varying inputs. The as we saw before it's any computational uh pipeline the function produces as output uh R uh and along with a cryptographic proof P right

so the output is R plus a cryptographic proof B which then function B can use to verify the correctness of R of the output and function S returns uh runs on solver S while uh function V runs from verifier V. Now here we have a verifier V that is always honest right so uh while the solver S might be lazy or adversarial the objective here is to guarantee the correctness of the output R is a certain confidence level while minimizing the combined memory and computational cost for S and B. Okay. So

the solver does the the the the full computation and then the verifier uh verifies it and uh uh again verifier is always honest solver might be lazy or address. Let's uh let's now introduce uh Specs uh and uh Specs is a is a sampling based protocol uh which is quite flexible and and efficient as we will see in a second and uh uh there are few uh extensions uh which we might talk through uh in the QA time uh for handling nondeterministic workloads like for with GPU inference and embeddings and we also have a sorry

a reference open source implementation what specs which uh you can deep install or UV install and um experiment with now let's quickly uh overview different approaches for verifiable computing for machine learning in particular so TML let's start from the first one TML machine learning on trusted executed environments it's based on hardware encaps uh isolated environments providing data confidentiality and code integrity. What are the uh cost here?

Well, uh you you have a uh a time overhead 30% uh depend on the workload. Um and uh usually in ankles you have limited memory availability, right? So uh you you do have some constraints on what you can actually do inside inside hardware anchors inside uh and uh you must also trust the the the hardware manufacturer right to to keep uh for example root keys uh um confidential and secret. Uh this might always not be true. For example, we had this uh um big uh issue in 204 24 uh where Intel SDX uh root keys got

compromised for the Intel SDXD solution. So it is safe until it is not right. So you have to trust this uh uh third party uh to to keep the root keys uh private and safe. Then we have Zakl zero knowledge machine learning which is really uh fantastic technology. It ensures the correctness of the outputs without exposing exactly how the computation works or what what is the computation being carried out uh and uh uh keeping input output um encrypted all the time.

So they are never disclosed cons. It's extremely slower uh more than 10,000 times slower than uh just computing uh the the the the task uh without any any just computing the task. There's a also a long setup time. So uh compilation and quite complex. So you cannot just uh take something that uh you run uh regularly and expect it to run inside a special environment of some sort. You are really to to take the code adapted recompile it and it doesn't

generally support all machine learning I models out of the box. So u nice but uh uh it might not be always a great fit. Then we have optimistic machine learning uh which uh uh uses a challenger phase challenger time uh and uh uh and uh and partial reexecution of the task inside of a pro machine. Now here the the the time override uh which is basically the confidence you want uh in the outputs. the higher uh the confidence, the higher the the the computer

overhead and the compute overhead uh happens inside the virtual machine. So there's also uh the added cost of running the the task inside the virtual machine. uh cons well this challenge period prior to prior to finalization uh which adds up to the computer overhead and requires also recompilation and VM execution. Why? Because the the original task is not executed in the VM but in case uh the outputs get get challenged it gets executed inside a VM.

Uh so yeah and uh again no support for any general machine learning I model uh why because you always need this adaptation and the VM itself might not be capable enough to run uh any kind of model. Then we have specs our proposal which uh uh relies on cryptographic proofs uh for computation and sampled verification. Again uh sampling in this in in in uh in this regard is similar to optimistic machine learning. Right? So we do sample uh what part of the computation we want to execute and the confidence here is a

percentage of the comput overhead. uh cons um there's no confidentiality of inputs and outputs uh if we compare it to the KML also with OPML we don't have them and uh uh but we don't have the the we don't need to to run it inside a virtual machine so we have some uh benefits out of this and uh let's dive uh into uh how the specs protocol can protect against lazy solvers. In particular, for adversarial solvers, things are a bit different. They are uh discussed in the white paper and we can

also uh touch point on them in the Q time. Uh very briefly, a functions uh I guess everyone here um is familiar with with a functions but anyways so let's say I will quickly introduce them. So we have uh um some inputs m0 to m4 and uh each me message can be etched uh through a function hing function and these functions uh the their special purpose is to uh map data of arbitrary size to fixed size values for example uh integgers. Okay. So input can be text output uh is integers for

example. And uh uh uh how do we use a functions uh in specs? Well uh before answering that we need to also introduce bloom filters which are space efficient probabilistic data structures for a set membership. So again an example let's say that we have a set with XYZ u XYZ are inserted in the data structure by computing the hash which uh uh returns uh uh three integers and these integers are treated as offsets in a bit array uh which are set to to one and uh uh the others are uh defaulted to zero. And whenever we

need to check if uh uh a value is present in the set or not, we compute the ashing functions on on the value and check if uh the bits are the corresponding offsets are set to one. For example, here we have w uh which in two cases uh we see bits are set to one, third one it's not. So uh with three ashing functions uh two uh would match but three we see that there's actually a zero in there. So we can uh uh we can say that w is not part of the of the set right as you can as you can see the the more functions you consider the the stronger guarantees you

get from the blue filter. Uh now let's also introduce computational pipelines. So computational pipelines uh very broadly transform uh inputs S in outputs E right and the flow of computational pipelines can be sequential or parallel. Here we see uh two sequential um we see two parallel uh flows A1 A2 A3 and B1 to B3. And what is interesting here is that uh to to compute B3 we don't really need to compute uh uh A2 but we do need to compute B1 B2 right so there's a uh

dependency between states here uh and only a subset of the states preceding a certain state are required uh to reach it and uh uh how do they fit into mlai uh computational pip pipelines. Well, uh in terms of sequential processing, usually feature extraction or data preparation fit into sequential processing. Uh while for parallel processing, we have batch inference, simulations, anomal models, uh all kinds of uh uh subtasks that can be executed in parallel with any uh with no dependency between uh individual

subtasks. and uh uh and the intuition. So our the uh main idea behind specs is to use uh uh blue filters to um to to to ash the state of the computation and check if a certain state has been reached or not. So in machine learning AI pipelines states are then uh can be mapped to inputs model weights or intermediate results outputs. So any any state in the computation and blue filters can serve as a computation certificate. They can prove that we we indeed executed the process uh accordingly to specification and we can

answer them questions uh did we reach uh A3 uh in in the evaluation or not by by checking if a certain state is present in the bloomfield or not. Uh if we bring all things together and uh and look back at the diagram we saw before here we uh we can see how this all fits together. Right? So we have the submit which uh uh requests inference given a certain input x to the folder which returns back the the predictions Y and the poof P and the submitter can then uh prove uh that uh the solver did at least uh followed the specification

for for for for the task uh by providing the proof and the input X to set a verifier for verification. Here we see uh a quick example of it um for batch inference. So uh let's uh let's have a look here. We have a the input X is structured with uh with batch inference. You have multiple inputs uh grouped together, right? So X0 to X9, they are all independent. And uh uh when we ask for a prediction to the solver, the solver will produce Y0 to Y9 independently, right? So X0 to Y0, X5 to Y5 and so on independently.

But the solver will also h create a bloom filter inserting all the predictions inside the proof p. Okay. uh and uh at this point uh at verification time uh once we provide the proof P and the inputs X to to the verifier the verifier can sample uh any any subset uh of the inputs in X uh and check if the prediction is indeed in part of the proof or not. So in this way uh it can verify and validate uh the the the outputs of the of the solver. Uh now uh few few comments on uh

on what we just discussed. The verifier is speaking randomly is selecting randomly a subset of the inputs right uh which is uh why the overhead is proportional to how much confidence you want in the outputs. If you want 100 confidence in the outputs, you basically execute 100% of the computation uh and so on. So uh but what is interesting here is that there's not time overhead. The verification process can happen in parallel to the solver process. uh only when the the proof P is produced uh by by the by the solver uh the verifier can uh can then check if premputed items are present in there. So

this is just basically um one step at the end uh where where the the two are joined and the solver doesn't know which predictions the verifier is going to is going to check right so uh which uh which is important because in this way the solver cannot optimize cheating uh and as you can imagine it works best with parallel flows because the vifier can bypass prior dependent states with uh uh with sequential flows uh uh it it still works but uh but then you get uh uh to an overall uh higher overhead um considerations we don't have time to

to discuss now but uh there are few nice examples covering this in the white paper and uh I now handle it to Antonio thank you yes thanks Mikuel Um, do you want to share to share my screen or do you want to follow me to change slides for me? Before we dive into your section, could I could I ask question? Um, yeah. So, it you had parallel execution happening and then parallel outputs, you know, that then went into the um into the um what do you call it? the um

the um the filter at the end and uh how many how is there a limit to how many how much parallel uh work can be done you know would it make it that all the all the one bits are all the bits are one so you can't you know so you can't really differentiate what has been executed and what hasn't is is there some limit yeah so So this is a good question. So uh bloom filters. So uh bloom filters are additive. So you can compute uh um subsets of tasks independently uh and uh obtaining multiple bloom

filters and then you can also take the union of bloom filters to obtain the the result. Right? So that that is also an interesting property. uh and uh and uh uh a lazy solver might fit you with a proof that uh is full of ones, right? So that the verifier would always find everything. Uh this is why it is important to to to verify the ratio of uh uh false positives in your bloom filter. So when when we create the bloom filter we specify what is the uh expected rate of of false positives we have right. Uh and uh and in this way we can

uh we can uh zise accordingly the the bloom filter uh and at verification time uh we can also check uh we can also estimate that rate and verify that it is actually within uh reasonable bounds. Uh so if you feed a bloom filter filled with once we can then check that uh the estimated uh false rate uh rate of false positive is is wrong and we can detect a violation of the bloom filter.

Okay, that makes sense. All right. Well, thank you. U yeah so over to you Antonio. Sure. Thank you. So I I can I can enter the slides. So I let you just let me know when I have to switch slides. Sorry. Okay. Um so I'm going to talk a bit about the the concrete use case of why we build specs. So M at the beginning talk a bit about motivation behind it and I'm going to introduce our blockchain if you bear with me just for introducing like a real world use case that we have for it.

Um so Warland is a layer 1 blockchain and we have this concept of plugins which is some sort of an extend extensible oracle system. Um next slide please ma we build this blockchain with Cosmos SDK. It's a layer one. We have proof of stake, let's say classic proof of stake of Cosmos and we have like 30 validators in our network. We also are EVM compatible.

We are we have an EVM running thanks to the Cosmos EVM module and we have this concept of plugins which is something unique to our blockchain. uh they can be used by smart contracts developer using our pre-ompiled contracts and basically plugins are a way for any validators to plug in additional features to the network without requiring a full network upgrade. So each validator individually can decide which plugin to run. I'll dive deeper in a second. And specs is one strategy for building these sort of plugins that can be verified by other validators.

Next slide please. Uh you can see each plug-in as an oracle independent from the others. And as I said, each one of the validator can decide which plug-in to run. If you have at least one validator running a plug-in that will make the validator the executor the rest of the validators can be the verifiers for it. So for for each request that a user make requesting some something from a specific plug-in the blockchain itself deterministically choose one of the validator as a solver while the rest can be the verifiers that we talked about in for specs. I also wanted to mention that the runtime for this plug-in is fully

asynchronous. So the user will request something at a block H. The response will arrive at a later block and then the verifiers will include their basically boolean votes on on another yet another block. Uh next slide. And to keep it simple, we we developed this minimal very minimal interface for building a plug-in that contains only a couple methods. One is for executing something and as you can see here we talk only about a blob of bytes. So as an input and as an output and the second method is verify which is again it takes the input and the output

as blob of bytes and just returns uh a boolean you can say the main idea is to keep it simple for for keep it generic for different strategies to be applied. One of those strategies for verification is specs. And as of today in our chain, we have plugins as part of the main binary implementation. So they're basically written in Go and part of our you our main binary, but we are building a platform for running this plug-in as web assembly binaries. So they will be developed, compiled to web assembly, ship it to validators machines and this will like be more like a plug-in as you

can imagine. And next slide please. So I wanted to give uh the look and feeling of using one of those plug-in. One of those is called HTTP and it as the name suggests it lets you make HTTP requests for from your smart contract. This is a solidity function. We have these pre-ompile contracts for it. So you we developed this HTTP request type. You can set some fields for it like the URL and the HTT method. You can include for example a payload for your request and then you use our other

pre-ompile contract that is the async contract that lets you specify which one of the plug-in to call this name is a unique identifier for it and then depending on the plug-in you are invoking you need to provide the input as a blob of bytes in this case we take the HTTP request uh type we encode it using AI which is very convenient to do it in validity and we also pass a third parameter which is the callback address of the contract that will be invoked automatically when the result is ready.

As I said this our runtime is asynchronous. So we need a way to to pass the result back and callbacks are convenient instead of um periodically checking if your result is ready and this is all handled automatically by our blockchain. please. Uh yeah, this is the solidity function. The callback solidity function that will be invoked when the whenever the result is ready. Uh the first line fetches the a synchronous task by its ID that was returned in the in the previous slide. And here we can see that the task contains a result and an output.

Again, this is a blob of byes. we need to decode it into something and this is plug-in specific. So we decode it using AI again into this HTTP response structure so that we can read the status code for example for the HTTP request and the body of it. Um, we also provide, for example, a JSON pre-ompile that lets you extract the specific fields that you want from the JSON, which is convenient to use from from Solidity, of course. And yeah, this is mostly it for the HTTP plug-in. Next slide, please. Just a couple mention here. For example, whenever you request an HTTP

request, as I said, the blockchain will choose one of the validators that has the HTTP plug-in enabled, and that would be the solver. So, in a way, it's centralized. You don't get to choose which one of the validators and not all of them will run your HTTP request. You have to trust it, right? One way of using specs could be to batch requests of different users even and to take a sample of it. So to take a subset of these requests to verify them. This is this works under the assumption that

the HTTP requests we're making are uh deterministic. So in a way that whenever you make the same request you get the same output. Um so these are kind of the assumptions for making the HTTP plug-in verifiable. Uh next slide. We started from this HTTP plug-in as a sandbox as a way for trying out different strategies and also to sparkle creativity in smart contract development to see what what API you would use inside your smart contract. And we also came up with another plug-in. So once you are done with that part, you can

develop your own specific plug-in. In this case, for example, we built an HTTP server that uses a neural network under the hood for predicting the price of uh 100 plus tokens. And this is verifiable with specs in another way. So in uh let let me explain whenever you use this price spread plugin you specify a list of tokens that you want to predict and the date in the future. The what happens is that using specs the other validators that are running the same plug-in will be able to sample a subset of tokens. Instead of repredict all the tokens that you asked,

they will only predict a subset of it and they will use packs with the bloom filters that Mal explained to check if the subset of tokens was predicted correctly. And so the the validator that was chosen as a solver is not trying to uh to fake some data. And that was it. Uh next slide. I think it's the end. Thank you. Uh you don't thank us, we're we're thanking you. Um so that that was great.

And um I know I've um put a few questions in my own little notes, but um before I ask any um is there any Leki and others? Are there any questions from the from the audience? Okay. Um, all right. It's left to me to ask you the tricky questions. Um, so HTTP outwardbound requests from a blockchain validator node. What happened? You know how in the

internet um there are certain IP address ranges which are specifically um do very slow H um TCP IP specifically to try and catch spam bots and to really slow them down. So say someone say um someone put in a request to some malicious part of the you know internet address range where it was going to take a very long time for the HTTP request to come back and even the TCP IP you know to work. Um would that slow the validator node down or is that all handled asynchronously? How does that

work? So everything is handled asynchronously. Um if you want the technical details they basically run uh the entire blockchain is written in go and this is handled by using go routine. So they they are separate from the main blockchain execution flow. Um each validators can enable one of those plug-in one of them is HTTP and can configure it. So I expect to configure uh certain timeouts and if the request doesn't go through inside this timeout it just fails. And each validator I expect to be configuring their plug-in independently. So if you first of all

you you you can decide if you want to do it or not if you want to run the HTTP request or not. Second you can configure things such as timeouts to to handle this. In any case, the blockchain, the block production and the validator normal work is not uh impacted by it. Okay, that which is what I think everyone me myself and everyone else would have thought but you know good to check and um yeah it's a good question. Yeah. Um and um yeah, so say if you're if you were doing a HTTP request to an oracle, the whole idea of an oracle is that it will

change at some point because if it was just a constant, you know, you wouldn't need to be asking what the value is. But that sort of means that surely there will be times when the um you know the executor will go off get a value and says Ethereum's worth you know this amount and then the verifier will go off like sec a second or two later and get a different value simply because the value has changed. um it does that sort of result in an error and then all those requests need to be retrieded or how does that work? Yeah. So that depends on the use case. So if you if you are requesting

something from an API like that, it becomes very hard to to verify the response. And in this case, I think of HTTP requests as a way of, as I said, trying out ideas. So, let me let me take a step back. If the API allows it, it would be great to have some sort of timestamp parameter in the request such as to make it deterministic, right? and not requesting like now the now price which changes every maybe even milliseconds.

So it's impossible to receive the same response twice. Yeah. If you have if if you have no control over it, you can either build your own HTTP proxy. So you can build your own server running it and make the HTTP request to your proxy. But this centralize the the the source of truth, right? So you no longer have to trust coin gecko or whatever API you are calling. You have to trust your relayer which is not ideal.

Yeah. If you can leverage specific knowledge of the HTTP request that you're making, I would suggest to build your own plug-in so that you can plug in your verification logic as well. So you have to implement the verify method and that can be done in many different ways. For example, in the case of price oracles, what's typically done is to to for example to fetch prices from different sources and then to average down to minimize the the shifting between the prices and then to have some sort of acceptable threshold. So the requests are coming through in different

times like different seconds. You can have a margin of threshold that you would accept but that needs to be done in your plug-in building your own verification logic. And the HTTP plug-in that we provide today is more generic. It's more meant to be used for yeah for testing out ideas for sandboxing and see what you can build inside your smart contract. Oh, look it it's a great starting point I think for people. Um, another question. So it's statistical, you know, proofs. So I

guess you're going to try multiple bits to see, you know, so you're going to have multiple requests and then you're going to have the bloom filter. And I'm just trying to think how many how much is it um how many samples do you need to do to be certain, you know, like that say one in a million chance that everything's okay? Is it that is it just a binary two to the 20? So you do try out 20 things and if you um have done 20 samples then you feel you're right or um and maybe I'm thinking about this in the wrong way.

This is uh um this is actually correct way. So maybe I can take this one. Uh so um as a as a developer you you you have an expectation of what is the confidence uh uh in the outcome. uh you you get from the task right so it could be uh I want uh uh this task is super important I want 100% confidence I'm uh happy to to pay more for this so uh you are basically asking for a full recmp compute of the entire task for verification right then uh you might also be fine with just 20% recmp computation uh right so you might be

okay with 20% confidence in the output which if you can keep if you keep hitting the same service again and again and again uh this also compounds uh your confidence not in the specific answer but uh in the party that provides the answer. So so this is our reasoning um on how we address that. So it is actually a parameter when when you use specs you have to specify what is the confidence you would expect from out of uh for the outputs.

You're on mute. Yeah. Yeah. I'm on mute. That makes a lot of sense. Um and I I think the idea of repeated calls um gaining confidence and then I guess it's just a matter of um trying to think about the malicious aspect but as you say you've got information on that in your paper um which we should all get around to reading. Yeah definitely. But one comment on this let's say that uh uh you ask for 100 predictions. Okay. Uh and you identify uh or or you ask for 100 uh orders you should execute uh as a

recommendation and uh uh coin swaps for example h and you identify one you want to execute uh you might verify only that one right so you might reproduce uh selectively only uh parts of the outputs you're going to use. So um once you have the outputs uh as a as a as a submitter I can identify okay I actually want to use uh uh these predictions uh verifier can you please verify these ones for me because I'm extremely interested in those ones specifically and uh how you can do that you can specify your threshold of

confidence 100% fitting in just a subset of X uh and the same bloom filter and that's what the evidence the vifier needs uh to provide um 100% confidence in those outputs. Okay. Yeah. Yeah, that makes sense. That's good. It's it's Yeah. Look, it's interesting tech and I think I'm sure that um everyone who's in the audience today is going to be walking along the street having a coffee tomorrow and then go, "But what about this?"

It's a which is true for any new technology, isn't it? Um yeah. Um so you've got your own L1. Um have you got a test net and a main net or what what's it how does it where where are you up to with all of that? Uh yeah we're building our own layer one. We are at a test net stage. We actually had a few test net before and we are running now our latest one uh which is going to be integrated using hyperlane to the Ethereum mainet. Our also one of our goals is to make these sort of plugins available to the Ethereum mainet contract. So using these

um general message passing technologies that exist like hyperlink we would enable these to be used from from the Ethereum and other layer 2 networks as well. Uh we are still very much in the testing phase of it. We have the plug-in system working on our layer one on our test net and we're now integrating with these with the hyperlink. Yes. Yep, you can find more info in our website which is wordprotocol.org. Actually, if you go to docs.wordprotocol.org, there are also the information regarding our our test net.

Yeah, sounds good. Sounds good. Just trying to think of you know I know you're an L1 and I was thinking if you became an L2 on Ethereum would that help you be more integrated and hence would it yeah but then like say if you wanted to be OP stack they want you to use OP stack without changes but arbitrum are more flexible um and it's then a matter of you know is being an L2 on Ethereum with this experimental technology, would that make it easier for other people on Ethereum in the other L2s use your technology?

So, I'm not saying, you know, give up on being an L1. I'm just think, you know, thinking out aloud here. Would it make it easier for people to use and you might have more traction? Yeah. Yeah. Yeah. It might be. It might be. I cannot say no. At this time, we we thought about all the possibilities. We are starting on layer one and see how it goes. We also have some and there are reasons for that. We want to build certain features that are currently that that are nice to have if you are building a layer 1 for example.

I can give you an example. It's a concept of autonomous smart contracts. So smart contracts that can be invoked without user transactions with user interactions. So they are initiated by the chain code itself. You so you as a user you prepaid some gas fees in a gas tank. You can imagine and having your contracts being executed automatically every once in a while. The most simple way is as crown job for example. And inside your smart contract you can leverage these plugins to fetch data from external sources or AI models. And this was let you build your AI agent as a smart contract which is something that

we are not seeing today as at least I'm not aware of. We see AI agents that are Python scripts or running in centralized servers but that could let that would expand the possibilities I guess and these you can make if you have a layer one you can you can have control over the entire stack. you can have control over gas costs or network congestions and all these sort of things. But if eventually we see that it makes more sense to become a layer two or to build on another tax stack, I think that we will switch. We we want to to to choose the best technology for our use case as possible. Yeah. Where best is an everchanging um thing. Um yeah.

Yeah. All right. Look, it's been really interesting. Could you um there were some final slides. Did you get around to putting them into your slide deck? Yeah. So, please if we could quickly flick to them right at the end and I'll just go through that stuff for the audience. Um there is the merch store still. Every now and again we sell a t-shirt. Every now and again actually we sell about 10 t-shirts all in one go. But anyway, um next slide. Okay. Um so next week Ratan is going to talk about OP succinct um and so essentially how to use um their um succinct zk system with op stack so that you can get a um zk rollup and also an

optimistic zk. Um, I'm going to talk about I'm actually going to probably split that um July the 11th talk into two. And so one's going to be on web 3 game design and one's going to be on a very specific contract, a um claim contract which allows you to claim an NFT um onchain and it uses onchain random and how even with onchain random it's still actually secure um which is um something that I six months ago I didn't think I was going to be able to achieve. So yeah, and um EOFV 1.0 is still coming. And so anyway, um that's where we're up to talk-wise. Next slide, please. All right, great. Thank

you. And um so if you are watching this on YouTube, um go to the meetup and then you can ask tricky questions live. Um if you're here today, you can watch this on YouTube. There's a slack workspace where you can ask questions and as well um there's some example code that um we um some of the talks have and we'll go into that repo. Um so Michaela and um Antonio thank you very much for your time today and for putting together such a great talk. Um and so everyone please give them a round of applause.

Thank you very much for having us. That was great. Thank you. Thanks a lot. Lots of virtual claps there. Um, yeah. All right. So, look, I'm going to um if have you guys shared the slides into the Google Drive folder or I'm going to do it uh right after. Um, yeah. Yeah, please do. So, then what I'll do is I'll be able to share the the slides in the description of the YouTube video and that'll help people understand your technology just that bit better. Yeah. Okay. All right, brilliant. Thank you. Bye.

Bye. Thanks again. Bye. Bye. Bye.