Projects
![]()
No projects found
Investors
New
DAO Treasuries
DATs
Lend / Borrow APRs
Chains
Categories
Spaces
ETH Slovenia - The Future of AI: Trustless, Private and Verifiable
Recorded: March 25, 2025 Duration: 1:01:16Space Recording
Short Summary
The discussion covers the convergence of AI, data, and blockchain as a significant trend, with Oasis launching a privacy-focused blockchain project. Innovations include decentralized AI developments and the introduction of Sapphire, an EVM-compatible confidential runtime. Upcoming launches in the DeFi space and collaborations with major players like Google Cloud highlight ongoing advancements and potential funding opportunities in the crypto industry.
Full Transcription
I'm going to be.
I'm going to be.
I'm going to
You know,
I'm going to
be able to
a lot of
a lot of
I'm going to
I'm going to do
you're
you're
you're
you know
you know
BOR.
Bhop
Bhop
Bhop
Bhop
Bhop
Bhop
I'm going to be
Oh my
I'm going to be.
I'm going to be.
I'm going to be.
I'm going to be.
I'm going to be
I'm going to be.
I'm going to
I'm going to be.
I'm going to be.
I'm going to do.
and...
be the
and...
...and
I'm going to
I'm going to
I'm going to
I'm going to
I'm going
I'm going to
I'm going to
the same
Here you're Slovenian team.
Welcome to our fifth meetup this season.
We're very glad that so many of you joined us today.
We have a very interesting topic, so convergence of AI, data and blockchain.
sounds very buzzwordish, but I'm sure that Philip and Matei will show you some very interesting business use cases.
And I'm sure you will enjoy it.
And of course, as usual, pizza and drinks are following that.
So for starters, I would like to invite Matei Anish from Oasis to start with his talk and then Philip will take it from him. Thank you.
Thank you, so I guess I'm the starters and Philip is the main course then, or how we're going to call it.
Yeah, so it's very, yeah, how should you say it, high P, you know, I even went further with the title,
The Future of AI, right? Trustless, private, verifiable.
And it might sound hyperbolic, right? But AI is evolving at an extraordinary pace, right?
And we are at the crossroad between, you know, having centralized or decentralized approach.
So today we're going to explore a little bit, you know, how we can build system that respect privacy,
ensure transparency, preserve human autonomy in the future. Before we dive into it, I'm Matei. I'm the head
of partnerships at Oasis. I've been with the team for about three years now. And yeah, I've been
in crypto since 2017. It's crazy to think now this is already eight years, but yeah, here we are and I think we're
We're just getting started for real.
Yeah, if we look at the current AI landscape, right?
AI has been around since the 90s, but in narrow applications and I think back then,
it was more called machine learning, right? Now machine learning is kind of one of the subsets
of what we call AI, but then
two years ago, I think it was, or even more than two years ago already,
you know, Chad GPT launched and AI really came to the forefront,
everybody started using it.
And we are kind of reaching that tipping point, right,
of widespread adoption.
Like even I'm here, you know, if I'm preaching,
I need to use it as well.
And you can see in the bottom right corner,
this presentation was made by a gamma as well.
No plug here.
I'm not being placed on that.
But I did use an AI presentation.
maker to enhance kind of the whole slide show.
And you can tell me if it's better or not,
or how it was.
But with all of the developments, right,
and all of these acceleration,
what we're getting is power concentration, right?
computer power capabilities, right, in the hands of a few.
And that we see, you know, as a little bit of a problem, we are in crypto because we want
decentralization, we're on trustlessness. And thankfully, right, in our ecosystem, new
alternatives, right, are popping up decentralized options or in development.
So if we touch on first on the centralized AI, as the word says it, it's centralized, right?
It's dominated by a few key players like Google, Open AI, Entropic, meta.
The Chinese are also, you know, getting better and better, Alibaba, deep seek.
And of course, they have many advantages, right?
Economism means of scale, access to data from
other applications, rapid development, access to talent, right?
They're also disadvantages.
And those disadvantages are mostly to the detriment of the user, right?
Data privacy concerns, monopoly over AI, risk of bias, right?
And how we can tackle that is
is through the decentralized AI approach, right?
So removing single points of failure,
adding transparency, users control their data.
So the advantages here are obviously,
control of data, enhance privacy, less potential for bias.
But we are finding challenges with the development in crypto
with lower performance, lower coordination, right,
and lack of standardization.
But user self-sovereignty is very important, right?
So data ownership, you know, where people have control over and consent, you know,
over their data and their individual choices, transparency.
So clear visibility into data use and AI decision making.
And of course, value recognition, right?
So personal data is valuable and users should be included in the AI economy.
So let's not copy what happened to Web 2 where our data...
was being monetized by the few, right,
but remuntonization to the end users as well.
So if we look at a quick comparison between centralized
decentralized AI, right?
So on the data control, we have data beaches
from this essentialized AI and user control sharing
on decentralized aspect.
On the privacy side, you have surveillance and profiling from the centralized side.
And here on the essential side, you have in hindsight protection.
And on the governance, you know, lack of transparency, it's basically black boxes that we don't know about, you know, how the decisions are being made, what's being done in there.
And with this decentralized AI, you have the distributed decision making and community governance.
And a lot of people here will say, well, I don't really care, right?
My data, they can have it.
I don't care how I get the end result.
So let's let's just leave it like that.
It's working fine.
But we need to think a few steps forward.
ASI, artificial super intelligence, right,
is arriving faster than expected.
And how are we going to be able to compete with that?
And then we need to come with human superintelligence
to be able to actually compete with ASI.
How is that?
Probably with some sort of BCI, so break computer interfaces.
You have neuralink, you have different less invasive possibilities, right?
But there will be a need for humans to enhance themselves to be able to compete, right?
And that comes then with enhanced learning, you know, AI-powered, school development, and decision-making.
But then, you know, with all that AI added to you, right,
it's a question of cognitive liberty, right?
How do you assure that the devices that you're using are not manipulating you, right?
So manipulation protection.
freedom of thought right who's putting because even we saw it right with social media how
influence people were able to to be through just social posts right um cambridge analytical was a
huge scandal right with facebook and and then think about if you have an a i let's say a personal
assistant you know that's that's giving you a bias view it's probably it probably can make you do
anything right or maybe not a bunch here right but let's say uh people they are not aware of this so
Why then go to the decentralized approach?
Because we can ensure that we have all of these three things covered.
So freedom of thought, personal AI assistance under our control,
not corporate oversight and manipulation protection.
And as we can see from the landscape, this was done a few months back,
So probably it's not completely valid anymore.
We have many more projects already active,
but we see a lot of different sectors popping up,
right, from decentralized compute,
confidential compute agents, monetization of data,
predictions, like, and as I said,
this was done November 2024,
so almost century ago for crypto and AI development.
And where we come in here is on the confidential compute side, right?
So what is the waste is?
Waits is privacy for Web3 and AI.
We are a public blockchain, right,
that have confidential runtimes powered by TEs.
And the additional interesting product that we're working on now
is what we call the Raffle framework,
which extends on-chain capabilities to off-chain compute.
And I'll dive in deeper in the next slide.
but maybe i go just through a quick origin story about oasis so we started back in 218 as in
layer 1 blockchain uh we already started back then with unique layered architecture with native
layer 2s so how how we see now how it theorem developed you know with compute going to layer
two's and it's and it's being more the consensus layer this is where
We started back in 218 and went main in 2020.
And smart privacy was always at the core of our, let's say, of our values.
We started with a rust-based paradigm, private runtime.
And then we switched to Sapphire in 2003.
So that's almost two years or even two years ago.
Yeah, two years, March 20, 23, so March 25, two years.
And Sapphire is meant to better serve the developers in the crypto ecosystem.
Why is that? Because Sapphire is still, I think, the first,
it was the first and still the only EVN-compatible confidential runtime in production.
So you're developing in EVM insolidity with the added confidentiality features that Sapphire brings.
And it's not all about native development on Sapphire.
We have cross-chain solution that we call the Oasis privacy layer,
which enables you to use Sapphire features on other chains as well.
And Raffle, which brings Sapphire's privacy features and verifiability to,
you see, I made a mistake here, and I didn't even see it.
It brings to, it brings Sapphire's capabilities to off-chain compute.
If we look at Raffle, so Raffle runtime off-chain logic,
it's intended Raffle as the acronym,
we want to have fun while we're in crypto.
But what it does it, it leverages TEs for security
paired with Sapphire with our Sapphire blockchain for on-chain verifiability.
it has flexible computation, right?
So enables the terministic applications APIs,
that blockchain scan handle.
So it extends your compute and it has the verifiable security,
right, because
what we saw right with right now T is being thrown left and right people just you know throw stuff in the T and and think it's done right but it actually is is important who has control over that T. Right. So how Raffle works I can show you this.
I'm not going to go into details of this, right?
But it's very simple, right?
We made it as simple as just run Oasis Raffle build
and then Oasis Raffle, build, verify,
to kind of extract away all this.
So for this crowd, if you summarize it,
maybe in a few bullet points,
what Raffle does, it does TEP provisioning,
right, OASID-NOSIS
provide provisioned Intel IGS and TDXDX these whole Raffle applications.
It does the on-chain registration of a Raffle app to establish identity,
and then the application interacts with smart contracts for verifiable execution.
And as, oh, sorry, yeah, see, I'm getting surprised by the slides as you are.
So if we look, if we go towards the most common application right now in AI, so AI agents, right?
there's a lot of industry momentum there in crypto and outside of crypto right so we had jensen
one from the video predicted that 2025 will be the year of agents right and i think that's great because
agents or maybe a solution, you know, that can help us bridge that UX gap that we have between Web 2 and Web 3, right?
Because if people are used to using agents in Web 2, you can actually just, you know, connect the Web 2 and Web 3 agents.
And then, you know, you don't have to teach people how to use wallets, how to use the apps. You can just
They just need to know how to use that agent that talks to the crypto agents, right?
So the start was very...
Yeah, very basic, right? You had simple chat bots, you know, on Twitter,
they were, they were funny, that were dunking on people. But we see how the space is evolving,
right? And with more handling more high-stakes roles like Defi, personal assistance, right?
You need that security, that verifiability. And then it becomes crucial. Who's running the agent? Is the agent autonomous?
And this is where
where the agent requirements come in right you want an agent that's private that's trustless
potentially autonomous as well depending on the application right but trust as agents you know
they need open reproducible bills with verified results autonomous agents you know require
verify self sovereignty control over the instance right and personal agents require private
interactions guaranteed confidentiality to improve data processing so you know that your data or
your interaction is not
getting out there for everyone to kind of see.
If we look at what's the deployment,
the Raffle and AI integration, right,
you have an AI agent that you deploy in a Raffle app,
you get privacy and verifiability through that and we also integrated a key management system within the raffle apps so you also have uh you have a completely integrated key management system for secure asset holding by the agent right so right now we saw i think it was uh so you had a i xbt being hacked i think a few days or a week back you had um
it wasn't a jail break here was actually a hack i think with a xvt but you also had i think was
through terminal uh the first kind of a i agent where it was actually managed by a guy in the back
and he had full control to the keys and shuffled around the tokens that were sent to the uh to the
trust uh through terminal uh agent right or more of a chatbot right but um
These are kind of the core components that you want to have for an agent to be sure that security is not compromised.
But of course, one is on the key side, but admin control is also very important, right?
As I mentioned before, you have now projects slapping T's to it, you know, just for the remote at the stations, but
It's important who has admin control, right?
Who can change the policies?
Of course, policy changes are visible on chain with us, right?
You can put in safeguards like time delays or anything similar, right, to protect against that.
But we have instances, you know, a project that just put stuff in the TE,
You know, there's no connection to any on-chain verifiability.
And that is basically no different than running something in Asia, right?
There's somebody else running this for you, right?
It's in a secure environment, but if they can change the policy, how can you verify anything, right?
Or they change the source code.
They deploy in there.
The attestation might still be true, but they change the source code, right?
So, I mean, the attestation is verified, right?
It's really running that code.
but it's a different different code.
And if you don't have somewhere to check
what was the attestation before and after,
then you don't have really anything.
So that's why governance here
it's also very important right and you have multiple options right you can have full autonomy
where you give you know transfer complete control to the agent that's also also risky right
uh you don't know how the agent will develop itself maybe fund funds get stuck so uh depending on
the application maybe that that is the right solution or not uh it's uh for everyone to decide for
themselves then you can have dial governance right
where you have votes that execute policy changes based on proposals.
You can have multi-stick control like with wallets, right?
Or you can have single wall control, but then maybe that's more for personal agents, right?
Because for personal agents,
there's less need for that trustlessness, right?
Because you're running it, right?
So you just want, you just need it to be secure.
You don't have to be, you don't have it,
you don't have to have it be fully autonomous or trustless, right?
You need that trust senses only towards the code.
That's kind of the counterparty here, right?
So, um,
Wrapping up here, I think, yeah, I'm going a little bit over time, but yeah, the focus, you know, for us, it's building, you know, an AI augmented future, you know, that shifts to towards this distributed AI system.
So shift to decentralization, a balance, you know, between ASI and HSI, you know, preserving cognitive liberty and, yeah.
use oasis and getting involved you know visit docs at oasis doxoacis dot oasis.io and start building
one less famous quote from ironman right so human torch is all about centralization because
it's better because it's faster right but ironman knows his stuff so potentialize is better because power to
the people anybody wanted to get in touch
We have a forum on the website.
You can reach me directly through email or telegram or X.
Or just grab me here after the chat and we can talk.
And that's about it.
Questions?
They're not mandatory, so I can go on a problem.
This is somebody, okay, Giga.
I'll give you the mind.
What do you think is the biggest hurdle for people being using blockchain?
Yeah, I think the comfort or discomfort is in the problem in the US, right?
So for instance, we made a chat bot with,
with, you know, a small model that you can deploy in a TDX,
you know, and when you ask you the question, you know,
you sign the transaction, you know, wait for the block to fall,
get the response.
So the UX obviously is a little bit slower.
It's a little bit more cumbersome, right?
It's always like that, right?
the big web to companies have that advantage of having really streamlined interactions.
People don't really think about it. It's just second nature at this point.
And crypto, you need to be a bit more intentional, right?
It's the same with, you know, cypherpunks in the past, you know, when you want to be private, you know,
using Duck, Go, you know, using Proton, being out of the Apple, Google bubbles, you know, using custom rooms on their phones.
It's a hassle, right? So I think it's until we, we bring it, you know, closer to the experience that they're used to, it's always going to be a problem.
I think we can. I think we can like Ruffle.
can actually alleviate quite a few things because it's off-chain compute.
So you can kind of have the verifiability be a little bit,
how should I say, you know, delayed.
So you can get, let's say, a response,
but then verification happens in the back.
But yeah, I think it's more about UX.
And obviously, exploits are not helping us as well.
So people thinking going to crypto, they're going to be losing money, you know,
memes didn't help as well, you know, pure gambling.
So it's all of that combined, it's like people still a little bit,
people are still a little bit deterrent towards crypto and then, yeah,
mixing with AI, maybe it's even worse.
I think if we're going to be building solutions,
and we are heavily now working on the agent side,
especially working on the frameworks for verified by AI agent
in the DFI space, we're going to be launching something fairly soon.
So a little bit of alpha for you guys, and you guys, but it's,
We see it as a very important sector, even though the kind of climate right now around agents deterred in the past, let's say, three, four months, I think they're going to have a comeback when they have more utility.
And this is where we're building right now.
Any else? If not, thank you very much. That's it from my side.
Oh, how was the presentation?
Good, bad. Okay. There was a little bit of, I saw the text. Yeah. You see, hey, it's not that capable yet.
Yeah. Ah, this is weird.
Yeah, hi, I'm Philip, head of Devere Latfler.
So, Claire is a NIVM layer one blockchain.
And apparently we're one of the guys that pretty much just
slapped the East on the blockchain and said this,
this should be enough to work.
Now, the thing is, we started in a bit of a different direction.
So we started as a NIVM chain.
nothing special wanted to focus on oracles, but slowly and slowly we saw that adding new things on blockchain, pretty much enabling blockchain to do something else and just being able to get you some tokens and being able to give you some security is a really important stuff. So it's pretty much, it's pretty much going to be a presentation, how we went from a
normal blockchain, a fork of avalanche,
and why adding this AI things is important,
how you can achieve a reasonable way of having a trust
in the AI model that's running somewhere,
what do you need to do, what are the nitty-gritty details,
and getting to the stage where we are now,
when we had a successful hackathon.
So maybe just going back, at least in my opinion, I'm a mathematician.
I would say I'm kind of new to this space.
I've been here for like three, four years.
And initially I was just laughing.
And the main thing for me, what you get from blockchains is the security.
That's the only thing.
So if you need a blockchain, you're pretty much paying a lot of stuff
for a very, very slow, very expensive database.
So that's the only thing.
And as soon as you're fine with that, it's okay.
The problem is that until you get to that point,
you pretty much think, okay, yeah, we got name coins,
we got tokens, we got this and that.
But at the end, you're paying for security,
either be the proof of work and then we decided,
okay, that's bad for environment, let's move to something else.
Then it's proof of stake.
But at the end, it's only this.
You're paying for security and security costs.
So whenever you want to deploy something on blockchain,
whenever you want to do something there,
there's always a trade-offs.
Should I do a lot of things off-chain?
and be happy with them and just a test of them on chain?
Or do they do them properly secure on chain,
do the whole computation off chain,
but then I can't do anything else.
So that's pretty much it.
It's always some sort of a balance between the security
provided by the change,
security provided by all the validators running the same computation,
being able to verify knowing that this has been done,
and just running some model on AWS and saying,
okay, fine, it's good.
So it's pretty much this.
It's striking a reasonable amount of balance.
What has this proven to be useful for?
Where tokens, ERC, you name it.
So small interactions between users,
distribution to users, let everybody have their own wallet.
Let's pretty much
use the fact that the banking system has been not has been undeveloped for the last 30 years in Europe and be able to send somebody in Southeast Asia
20 USDT and don't worry about it. So those small things. There's defy and the main problem with defy that blockchain had was that until we got AMM you couldn't really do anything useful with defy on blockchain. So you can't have a proper order book on blockchain up until now. So there's a bunch of projects now that are trying to
create the proper order book, but on a normal EVM chain on pretty much anything that has to be synchronized
across the whole world, you have to do something. You have to cheat a bit. So you need AMM for this. And the
Only other thing, when you can really use the data from some external thing, is this checkpointing.
So you can use blockchain to have some supply chain assurance, so the holy grail.
So use blockchain to store a very small amount, distribute this across this decentralized database, be sure about this, have this secure, and that's it.
but those are the only things that we can currently use.
So it's pretty much just having a settlement layer,
having something that everybody agrees on,
but those data pieces have to be small.
So this is the problem that we started on.
So again,
normal EVM layer chain, you could do all these things,
but it usually wasn't enough.
We needed something else,
but that's why we decided to just start slapping T's on top of it
and hope that this would magically solve the things.
But it took us a bit of time,
so we wanted to scale the computation.
So how do you scale the blockchain if you already have it?
So one way to do it is pretty much go the Solano way,
and some people are going to hate me for this.
But if you decrease the number of validators,
it's pretty easy to scale things.
So put them in the same data center.
I don't know, have three of them,
put them in Google BigQuery, and you're fine with it.
It's going to be fast, it's going to be efficient,
but this data center burns down and you're screwed.
And pretty much everybody here knows what happened to parties
because they forgot to add backups.
So that's one thing.
You can scale by removing this blockchain stuff.
You can scale differently.
You can use L2s, as you know,
and then you post checkpoints to something else.
So you leverage the ability to have data on some DA layers.
You leverage the ability to just put checkpoints of data.
But still, you have to do some computation somewhere else.
You have to trust it, or at least you have to verify it at the end.
So scaling both computation and memory, that was still a challenge.
So what do you do? And you can go either way,
and we still wanted to be reasonably decentralized.
And it comes at the end to the consensus.
So the same blessing and occurs you have at this point.
So if you want 1,000 or 100 or 50 validators to know the same thing,
if you want this to be accessible,
well, you need this communication among all this.
And even the Pacta upgrade pretty much talks about this.
So we're going to lower the amount of validators in Ethereum
by increasing the amount of ether they can stake from 32 to
between 32 and 2024.
And by doing this, we allow them to communicate a bit more among themselves.
So pretty much, I mean, it's a simple mathematical problem.
If you have n people communicating, you have a graph with n squared edges.
And that's the problem.
That's what it comes down to.
So at some point, if you want to scale, if you want to have this in a decentralized fashion,
if you want to have the data everywhere, and if you want
want to have everybody doing and verify the computation,
you run into a bunch of problems.
And then also you need data availability layers if you're just
checkpointing and you need to pay somebody to do it.
And you need, I don't know, if you're in the case of optimism,
you need proofs, you need proofs and all this.
And somebody has to be doing this and you have to pay themselves how.
And if you're a layer one, that's kind of simple.
You just print your own token and use it as a rewards.
And yeah, for sure, somebody's going to do it.
But this doesn't scale, A, and this doesn't pretty much take long to become problematic.
So what we did, the first thing we did was we had a bunch of oracles on the chain.
So this very specific Oracle was called FDC, the FLAR data connector,
which allowed you to get the thermistic data from other chains.
It was pretty much asking,
our own set of validators to the terministic question.
So has this Bitcoin transaction happened?
And I'm sensing it has.
This is the full output of a transaction.
I'm going to hash this output.
And then I presented this whole question to the set of validators and say,
okay, this is the input of the query you should execute.
This is the output I'm getting.
Please confirm this for me.
And the main idea behind this was that if you can achieve a consensus,
on which block is getting bind.
If you can achieve a consensus on what transactions are included into it,
you can also achieve a consensus on a deterministic query,
what's happening somewhere else.
And in our case, that started with Bitcoin.
So, okay, has this transaction happened?
And then we kind of evolved this.
We said, okay, has this triple transaction happen?
Can you index the repo?
um, XRP ledger beforehand.
And can you say, okay, was the block, I don't know,
2,000 blocks ago empty?
Can you say that no transaction such as this has happened?
And again, the thing we did was we say to all the validators,
please confirm this question for me.
So this was the initial idea on how do you scale this?
And along the road, we came to a problem that during the payments,
to one of the underlying agents, you have to say, okay,
please pay me to this specific address.
And this address was Bitcoin address.
And if you've ever tried to validate Bitcoin address,
Bitcoin public address in solidity, it's painful.
So there's this whole set of things you have to check.
And doing this insolidity is expensive, be very expensive.
And if you code it yourself, the auditors are just going to kill you.
So we decided to not do this computation.
on chain we decided to not add a pre-compile because messing with the node is also problematic
and we decided to extend this ability of what the fdc can do to add a new specific question
can you compute this small thing for me can you run this small python script that validates a
bitcoin address and out of this we saw that as long as you get validators to
be able to respond to the terministic queries,
you can increase this small Python code from a computation.
Can you run this code for me?
And then efficiently put just the result on chain
and have all the machinery around it.
You can increase this to ask validator, okay,
can you run this web to query for me?
and if you do it properly in a deterministic fashion,
okay, can you ask weather.com with those two parameters,
with this specific API key,
what was the weather in Ljubljana on 21st of March at 8pm?
And if they get the same response,
you've pretty much asked all of them to perform a computation,
similarly as if it was a pre-compile,
and you know that all of them got it.
And at this point, it was becoming quite clear that if we can extend this just a little bit more and decrease the amount of validators that need to run this, it's a nice way of keeping the network intact.
So using the existing tools, using the existing EVM, using all the existing solutions that you already have, and just add a similar to pre-compile-like thing.
to your chain by leveraging the same set of validators.
And importantly, every time you ask a question,
you're assured that the same thing is getting the same response,
A and B, that the security of the answer to your question is the same as the block building itself.
Because you're asking the same validators. If they screw it up,
it's the same as if they were to screw up the block building process.
Yeah, I should have done this.
OK, and that's pretty much it.
So when do you really trust a computation that's done by something else?
So you can have a chain.
You can have an add-on on chain that does this.
Or you can answer a validator said, OK, please compute this for me.
And if you have this reasonably prepared,
if you have some sort of queries that can do this,
you can create a really good parameterized way of asking
external work.
So you can go to Web2 APIs.
And as soon as you can go to Web to APIs and post-process them,
you can pretty much output a custom Python script
and let them compute it for you.
You have some parameters you can tweak, and then you go.
And what do you do? Well, the easiest thing to do this, the easiest thing to secure it is to pretty much use the stake.
So now we just split the stake from the validators to use some stake for the validator itself for block building.
And the second piece of stake is now also securing this additional querying the external world.
Okay, we'll get to why this is important very soon.
And now you know the specific point and say, okay, so now I have
100, 1,500 validators doing the same thing for me.
Can I make this a bit more efficient?
Can I make the computations a bit more efficient in such a way that not everybody is doing the same thing,
but I can still trust the result of the computation reasonably well?
And TE has turned out to be a really good solution for this.
So you could do a bunch of ML, you could do a bunch of things that are related to AI,
even with our first thing.
but you know that your computation has been done a hundred times,
which is kind of expensive. You're already on blockchain, so things are expensive.
If you're on blockchain and you want to use an AI model somewhere else,
you don't want to pay anything more than a normal invocation of an AI model,
maybe one order of magnitude more, but not two or three orders of magnitude.
So we need to find out what was the correct scale. And these were really good,
To do this because with them, if you create a system around them to allow people to easily attest to these,
so that the TE is running, the TE is running the correct code, and it has been changed,
you pretty much have a chain, the validators in between that can attest to those TEs,
and at the end, the result of the TE, so the whole chain of computations can be reasonably secured.
And yeah, doing this is this final non-frivial thing.
Oasis is doing.
So how do you make sure that you properly attest to what these are doing?
How do you make sure that the computation you are offloading to somebody else,
in our case, whatever you have to do with machine learning,
how do we make sure that this thing is really running?
So each of the major cloud providers is providing you their own abstraction on top of it.
So the main idea behind the TE is that
the hardware provider gets a certificate that this T is indeed correct,
that it can sign a bunch of stuff, and the T.E can also sign what's happening in between.
So in our case, what we did is we offloaded all this,
again to our very data set.
So setting up a TE, getting this initial thing is correct,
it's quite expensive.
So and by gathering the first few users that wanted to use this,
we arrived at a specific problem that the user spent most of their time setting up the TE.
So I've got the TE, I've got it running somewhere,
I'm pushing some Docker on it.
How do I now get the user,
the users of my debt to say, okay,
I really trust that this T is set up correctly.
You're not leaking your private key.
And how do I trust it that every time that code is changing,
I'm getting somehow notified that things are moving away?
Pretty much, how many of you have ever checked
verified smart contracts that you're interacting with?
Really? You've read all of them?
The whole block scouting, just the main one.
Yeah. So, and again,
In that case, we arrived at the same conclusion.
So you want to again leverage the validator set.
So and now instead of asking them, OK, execute this.
execute this web query for me, execute this Bitcoin check for me,
pretty much every time a new T-E set up,
the same set of validators is again used to attest to this thing.
So what this means is that we built an abstraction on top of
existing cloud providers, so currently we support Google Cloud,
because that was the easiest one to get to support,
and we already have a contract with them to use their hardware,
so it was kind of like a no-brainer to start.
And it was a,
And it was a nice layer of abstraction.
How do you bring users from a fact, okay,
I'm on blockchain, I can't do anything.
I'm on blockchain.
I can set up my own TE, just put everything there
and pretty much screw with people and say,
yeah, it's going to run there.
Please trust me, it's all right.
To a state when you have a blockchain,
a set of validators,
also attesting that this TE that's running somewhere
indeed conforms to the same reasonable state of security
that we have for blockchain,
and the users, the developers only being able to start with the TE,
get some instructions to it, run it,
and constantly verify that this is happening.
And by using the validator set,
you abstract this away from developers
so that anyone can at any time check,
okay, is this T.E is still responding to the same command as before?
As the Docker been changed.
So the code that you can deploy in T E's can be pretty much an arbitrary code.
There are a few cavits there,
but you want to make sure that your chain as such
is making sure that nothing nefarious is happening there.
Okay, so this is how the first iteration of this integration looked like.
So this is a picture from a smart wallet, but the generic TE is very simple.
I just couldn't find a nicer image.
So the thing is, the most important thing is that whenever you're sending the instructions to a T, you want to leverage the same thing you leverage on a blockchain.
So if your T.E, if the AI model you're running off-chain,
needs to listen to a blockchain to get some instructions,
or needs to listen to any other blockchain to get the instructions,
your first problem is that this thing you're running is going to get bloated.
You need a light client for a chain,
and pretty much none of the chains have a working light client,
which means that the thing you need to do is have an RPC in your T.E.
Or have your model connect directly to the RPC.
You need an RPC in our case for Flair.
You're connecting to Ethereum to execute some actions there.
You need another RPC, which is problematic from two things.
First one is, you need to include this.
You're paying a bit more for the T.E.
And secondly, all the instructions you get to your model are now conditionally secure
by the fact that there might be a bug in the RPC you're running locally.
So the thing we did, and this kind of proved useful for all the things that people were using after this,
was that we abstracted the way
the instruction part again to just be executed on behalf of the validators.
So again, you're not, you don't have to run an RPC inside between.
You pretty much are just working on behalf of the instructions contained into the smart contract directly on.
So pretty much again, the validator set, instead of just being the validator set,
is now also signing a bunch of other instructions, which are
very cheap, but in this way, you can make these things much, much smaller and allow people at that point to deploy just a model, which was the Holy Grail.
So what we wanted to do was to come to a stage when you are deploying just a single extension of a blockchain, and now you can really do
you can really do just AI as a single instruction in your smart contract.
This was the holy grill that we wanted to achieve.
So how do you make a smart contract that calls a model?
The model executes, you verify what the model is, and you're done with it.
And there's a bunch of problems you have to solve in the middle.
So how do you set this up?
How do you solve the key sharing?
One of the big problems is that these always come with their own private key,
which is amazing for AI agents, which is amazing for anything you want to interact with users.
But the thing is, if the TE shuts down, you're screwed.
If you have a wallet controlled by this, you're screwed.
If you have a Twitter account controlled by a TE, and the TE shuts down, you're again screwed.
So creating a nice abstraction over this allows you to,
allows the user, the developer again, to pretty much just put instructions to it,
and you are the one that's making sure that all this works.
in the end. And the third thing that was also important and gave us quite a bit of
problems specifically on the hackathons is this information leakage. So you have a TE, you have a
model that's running in it and very nice, the people are happy because you're getting a bunch of
IWAT information inside it, you're getting the model to run on a confidential information, you're getting the model to run on a
a bunch of healthcare information,
and at some point, these things can start to leak.
So how do you make sure that the TE is alive for only that specific time,
and how do you make sure that code inside is so simple
that it's easy to verify, not just for the person that's working on it,
but also for the person that's trusting it with data.
So this is also another thing, why you want to make those things as simple as possible.
As soon as you add in another node, another RPC, another
a restful API so people can easily connect with it.
You pretty much have 100 lines of code that is running your model and
200 to 2 gigabytes of additional code that just there for a blog.
And somewhere in there there's going to be a problem.
And yeah, so these those are all the steps that we had to take to come to a place when you can now have a blockchain.
with an off-chain compute where you can run anything else.
And obviously now we were able to finally start with the funny AI stuff that can really be useful.
So we just had a hackathon with Google.
Technically Google Cloud, they're being recorded.
So we just had a hackathon with Google Cloud. Find me afterwards.
And the main idea was what can you do
with a model that's running on a blockchain.
So you can trust that the output of a model is getting saved to somewhere safe.
And secondly, you know that the model cannot change in between.
So this opened the world for a bunch of stuff,
and specifically most of the people opted directly for AI agents.
Why? I'm going to have an AI agent that can run something on my Twitter account.
And the main thing that I don't want it to happen is for this agent to change its mind in between.
So the main thing that you want it to be is the fact that I'm always continuously attesting to the code.
And if anything goes wrong, the blockchain itself can shut down this other precompile.
So this was an important consideration.
How do you continuously attest this and how do you make sure that the users can pretty much forget about this?
So we've had a bunch of different projects and specifically most of them focused on those two things.
So you have a...
nice AI model that's running somewhere and you can trust it with your private keys because those are always encrypted.
And you also have an AI model that can access your banking or your past credit data because again, you know that the T is going to shut down after reaching vocation.
which allows us to have a simple models that calculate your credit score and shut down.
Why is that good? It's much better than a long-running model. It's much better than a long-running
machine that you attach to an existing system because all the verification can be done much simpler.
So all the other thing you need is much, much simpler because you pretty much have to know that this
one-shot thing is not going to leak any information. And as soon as you're done, your information is raised.
So this was also one of the
main considerations when thinking about adding AI availability to the chain is how do you make them one shot and how do you make them auto distract immediately?
And yeah, that's mostly it. So maybe just to recap, so starting with the blockchain, what can you do to extend the blockchain with this small pre-computs that can do things that blockchains usually cannot do, or you can only do them if you're running this in a cloud?
So how do you make a small burst of computations that can be efficiently encoded?
And how do you make this small burst still correctly private?
And yeah, that's it.
You have a lot of
that makes a big thing for something to create.
How, in one extent, is scalable.
So how much power single time
you have any tests for this already in order?
No, so the thing is, the thing is you don't scale the TEs.
What you scale is this communication.
So you scale TEs just to a level where you're fine that the TEs are reasonably live.
The thing where the validators come into play is this information passing to them.
So TEs are kind of like an extension.
So instead of having a blockchain with 1000 validators,
you have 10 TEs or 50 TEs to perform your computation.
You trust them that for that limited time,
they can't be exploited.
You trust them that for that limited time the attestation holds,
then you shut them down.
So you don't have each validator run their own TE,
because that is pretty much the same as if each validator was to run the same model.
That's kind of useless, and plus the greater the amount of those TEs,
the more problematic it becomes for a private data.
The more private you want to keep the data, the last T.E.
So for the things that are one shot, just compute something on my credit data, give me a score and then die.
You want just one TEs because you're fine with this computation not getting executed fully if something bad happens,
then with having these data across multiple TEs, if there's an exploit on one of them.
So that's the abstraction level you bring the users to.
So create a wallet for me.
I want multiple TEs.
I'm going to shut the key.
Create a one shot compute something on a legal data for me.
I'm just going to get one.
I'm going to compute something on it.
If something goes wrong, it's a raised anyway.
I'm not going to have this scaled across 10 TEs
because it's expensive and possibly problematic.
So he is on the side of the account.
No, these are provisioned by us and tested by us,
but the requests for them come from developer, yeah.
Pretty much app-specific.
There's no other questions, please is there.
Thank you.
Thank you, Philip. Thank you.
We have some drinks now, pizza.
For anyone that is not part of the step group, it's not part of the group,
it's not part of the computer for you.
So, you have to hear your enthusiasm.
You can also scan the QR code and it will direct it to our website.
Thanks.
