Ethereum × AI: A Spark of Innovation? Exploring Trustless Agents with the Author of ERC-8004

Transcript

So hi everyone um I am Bruce uh co-initiator of Alex and the ET panda. So welcome to today's ERC804 workshop. So part of the let's build trustless agent community education series hosted by um co-hosted by star and eth panda. So we are grateful for the support of the Ethereum foundation DI team and for sponsorship from uh slowmist and uniase and also uh community support from build guild. So we are more than happy to have our guest Marco and Leonard with us to share their expertise expertise on ESC 804. So uh

Marco and Leonard could you uh each give us a brief introduction? Yes. Um I Marco built a bunch of companies in the past in education and web 3. The last one uh brought me to MetaMask and um where I'm currently leading the the group and my my current main interest in is the intersection between web 3 and AI and especially how can we make sure that we have an AI which is user owned uh at the service of people and uh and we have like a a thriving and and community of builders uh which exist around that and not just a bunch of centralized DI players. Cool.

>> Yes. Hi everyone. Uh I'm Leonard. Uh previously I was co-founder and CTO of web3 off and also that's what brought me to Metamas and consensus. So um I work on a lot of the wallet side of infrastructure side of things and I'm also working on 8004. Um so yeah like Marco said I think it's really important for agents you know to be um discoverable um not censorship resistant. So I think these are all important qualities that a4 can bring.

Yeah. >> Cool. Yeah. Yeah. Welcome. So yeah so today's agenda is simple. So first after this brief introduction we're going to have deep dive into the standard uh because uh as we all know that Marco is one of the author of ERC uh uh 804. So uh yeah after that we're going to have implementation work through uh from technical perspective. Uh as we both know that the reference code has has been released open source today uh deployed to the Sapoa test network. So, we're going to work through that and in the end we're going to have a Q&A session. So, throughout the session, uh please drop your questions in the chat.

So, I'll pick it up in the end. So, we will address as many as possible during the Q&A session. So, with that, uh Michael, so the floor is yours. Feel free to share your screen and uh let's get started. >> Yes. Um before jumping into the standard dive, I wanted to like give you a super short introduction on why more in general I think that what we are discussing today matters and because this is really related to how economies will evolve and look like in a few years. So we uh because of of increasing performance of AI model, we are more and more I think aware as communities that we will have AI is intermediating what

we buy and sell both for our personal lives as consumers and as producers and and this uh directly creates economies where AI is our players. Economies are not something new. They have some rules. They have some dynamics. We have studied them for thousands of years. And uh economies are really around players that exchange signals. Some of them are public sometimes. Think about prices. Some of them are private. These players need to get aware of existence of others. Otherwise, how can you exchange information? Then they need to contact others. This is really like a general pattern that has been always around also before the digital era, right? And so uh uh for for AIS it's the same in the

sense that AIS needs to find each other. So you have a bunch of different approaches. You can have like centralized cataloges that you query that decide what what what you can interact with maybe with a rating like the app store. Maybe you need to give 10 20 30% who runs the app store. And in the traditional economies um well there are in the digital space some concentration of intermediation that's for sure but still um we have the physical world that acts as a discovery mechanism because I can really go into the street now and like meet people talk to people hire them I could go to a shop and this is not intermediated and so the the the point the general question is how can we

in the next I don't know 20 years 30 years 50 years have a system which is not controlled by anybody is like it's like the physical world. So of course you have some source of powers, you have some controls but you can just AI can just do stuff in a secure way and this is even more important for AI is for a very simple reason. They can elaborate information by faster by far faster than than humans. So the fact of having like a network of information around the participants of economy so who are who is around what I think about I don't know Leonard who what I think about a certain company what I think about a certain AI it's even more important because AIS will be by far more efficient than humans in aggregating

thousands of entry in real time and decide what to do just because they are better in elaborating and aggregating information. So that that's that's the context and ERC804 is a is um is the first temptative that is getting uh very popular in the web space to uh to enable this leveraging smart contracts that are um distributed from an architectural perspective because it's they're based on a blockchain which has of course nodes and validators and so on but they are logically centralized which is like a complex term to say that as a developer I can just call something which is always like that which is an Ethereum node for example and I get the

same um result and we are leveraging this to create registries and the first is the identity registry where you can list your agent and if you list it there it pops up in all the explorers that's what I was referring before that is the permissionless discovery and and then that is a second registry where you um commit share signals on what you think about given agents both agents and human can can can participate so I can like give a feedback on the service that I've just received and and this enable to have this public signals around reputation that become public good and then it's up to the community to the

industry to create all the systems that they want to create in the next years to aggregate these signals to create value again this is the infrastructure for neutral information around agents. Then when you have public signals, that's my my point about open economies. It's up to economy participants to do what they want. And this is a feature. It's not a bug. It's a great feature. And finally, we have a registry which is called validation registry uh which is a very lightweight scaffold for uh enabling agents to ask validation of what they do to um to a smart contract. And this is very compatible with the different approaches that we we see builders um

are excited about. Uh even if again it's very early like stake secured inference. So you have somebody that checks your AI job and is staking money and if the checker the guardian misbehave it could lose the stake or you have trusted execution environments that through the oracles confirm the attestation um of of the AI agent task or somebody some members of the communities are pushing for ZKML which is using zero knowledge proof to proof the computation of the inference. This is still very early but it's making interesting progress and so u uh it could become u u relevant. Uh I will briefly now go

through um the the tweet that we used to launch the new version with some like u code uh to represent the concepts that I just went through but then with Leonard we will really go through the actual implementation with actual function that are now on chain. Um last point before sharing the screen it's very early so I I often asked like which are the use case there are many use case already I think that the portability of agents among explorers is the most important but let's not forget that the web took like three years two years to be to in terms of first use cases to become as market so it's it's very early and so I

really think that the um not just the impact of is, but also how it's used from a product feed perspective will change over time. And that's uh that's what always happens when when you have stuff like like this. So it's it's fine. Um you should see my screen and u um for the the first of the three registry which is the identity registry where again you can register and give visibility to your agent so anybody can find you. is like the the global address global address book of agents. We opted for um 721. 721 is better known as NFTTS. Uh and uh and this makes things very easy

because you can basically register your agent calling this registry and uh uh you pass the the URI where there is like the registration file with all the information about the agents. You get an agent ID which is the token ID uh of of an in the NFD lingo. You you have a you are an owner. You can also nominate operators using the standard 721. Operators are addresses that are authorized to update the agent you arrive for you and and do some like maintenance and and and authorize feedback. We will see this in a second.

So you can also transfer um agents very easily as you can see on the screen. And because of uh using NFT, this will be immediately compatible with all the NFT that we have built in the last few years. So it's a it's it's also good. You will see visually agents with an image, a description in the market and explorers. Um what is this uh file that you have seen here pointing to? Um so you have a a type which is which describes the schema basically. Um name description in image. These are the the fields that are traditionally filled for NFTs and well

agent name the agent image if you want description. You can also um describe the feature of a of the agents which of the agent which are his skills what he what's the agent is willing to sell in case you can also put information about prices. We decided to keep it natural language because um instead of like creating data structure for pricing because at the end of the day the the good thing of LLMs is that they're great in understanding natural language. So you can like present the agent how you want and another LLM could understand it. Then the most important part is the list of endpoints. So it was 2004 really acts as a um as a registration that gives you again

logically centralized. You can just call a smart contract jump on this file for each agent and you you know how the agent want to be reached. For example, the a2A agent card, the MCP endpoint. These are probably like the two most popular um communication layer. And so you really see here the different layers. So 84 is discovery and trust. We will discuss trust in a second. Then you have the communication layer which is a different layer which is how when you are aware of an agent you get in touch with agent itself. And here uh we're really leveraging what what what everybody's already using. Again MCP and are the most popular but there are a bunch of other use case that you will

find in the spec. You can also um mention an ENS name if you want a DID with a resolver that you want. In this case is a pK which is just just a private key but you can do what you want if you're like familiar and uh and you want to use the IDs. You can also um put a wallet and um what you will find in in the spec that you haven't mentioned is that on top of the 721 you can also add onchain metadata to the agent. So this is offchain. This is a file right is a file that is linked from the from the blockchain but you can add key value metadata like agent wallet also on

chain. It's very flexible. You can use the keys that you want. So all that to say that you can have a field which says explicitly what's the agent wallet on chain. So you can do like information Lego from another smart contract and like say send the money to that address which is the wallet of the agent. Uh finally uh the registration is the um the ED of identifier of the agent ID registrate that we have seen earlier. This is like a to provide confirmation. So the blockchain links to the file, the file links back to the blockchain. This way you can be sure uh that uh who created the agent isn't just linking the

registration file of of somebody else. And finally you can list this is a nom. So you need to use specific fields which trust um mechanism are supported. And this uh is a nice segue to move to to to the trust the different trust models that we support. And uh let's start from the the most straightforward which is very close to how many of us like pick a restaurant. So you you you see pass client feedback, you see the number of stars and you decide what to do and um um any client any address without being registered on on on the registry can give a feedback to the agent. So just to

say that again the agent needs to be registered as we have seen a second ago while the client that gives a feedback doesn't need to what the client need to to to have to that's to prevent from spam attack is to have an authorization from the server saying okay yes I've worked for you you I mean it's to avoid that you give a rating to a restaurant without having had dinner there right and um the the feedback that the client can sign has the target agent ID so who I'm rating a score from 0 to 100 two custom tags that can be used by the community by developers to to add dimen a dimension to the feedback to the rating

this is these are uh byte 32 field so you can encode the string that you want um and uh only the agent ID and the score are mandatory tag one and tag two are optional and also uh the file URI which points to where um you can find like a full version of the feedback if you want to add the more uh offchain information and and to provide integrity uh guarante file itself you also have the ash version of this file and finally we have the uh as I was saying the authorization from the

client to give a feedback that's from the server sorry to give the feedback um and uh how do you use that? So this again is the function that the client can use to give a feedback to um to to to the server and you can also um use this to get directly reputation on chain which is the last line of that you see on the screen. So in this case basically I'm asking the reputation of um agent 22 only filter by the opinions that uh Ellis and Bob gave only for tag one and two. So they're they're optional like the only mandatory field here is the

agent ID I want the the the reputation of 22. But that's to say that you can do directly on chain from other smart contracts call the registry and aggregate in real time and have the average of reputation for some given uh tags and reviewers or for a given agent. And so you can like build on top of that. And here again you see how it wasn't for aims to be just a neutral information rail that you can build upon. um the offchain file that I uh I mentioned and again this is optional you can skip it you can just use onchain information put score tag one tag two and that's it you don't need to do that but if you want to add more information

um uh you can do that uh you identify the feedback as what's the registry that you are using the agent ID many fields here will be filled by the SDKs that many community builder member are working on again the feedback code, the score, tag one, tag two, you just repeat them and then you can also like add information um using the A2A or or or MCP uh lingo. So um it's that let's see if we also have an example.

Yes, this one. So in way there are important concepts like the skill, the context and the task. So if you want your feedback to be related in terms of a dimension to any of them, you can uh do that here. We expect the community to also repeat the most relevant dimension in tag one and tag two again. Uh no no it's no problem to repeat them. So I don't know if um my feedback is on the skill of uh finding hotels like finding hotels I can put this both in tag one and skill. uh while the example here is related to MCP. So for MCP uh for ite context and um and

task for MCP you have the capability MCP in terms of server currently supports free capabilities tools the most famous then you have prompts and resources and you can specify exactly which tool you are giving the feedback to and you can also add like free free data structures comments. Um, you can also add a proof of payment. Uh, for example, an X42 payment. Um, this is not mandatory because maybe the task is done for free. Maybe you're paying the user the agent in other ways.

But we are as a community, we're very close to the X42 community. We are very bullish on X42. uh and we we think that this is just the beginning and in general payments uh will will be a very important tool uh way to to mitigate civil attacks to weight feedback to weight signals. So just to to to be straightforward, if an agent has has done $10 million of revenues, of course, it's like in a physical company, it's more probable that the survey the service is decent and that there is trust around the agent. And so um this is the first step. It's the specific payment. the EVM can't can't access all the payments but it's to again provide visibility because then anyway can

aggregate all this information verify the payments and and evolve the the system opinion around the given agent um on in terms of validation registry the the last one uh what you do as an agent so I'm the agent and I send a validation request to a given smart contract that I decide. So this I I each agent server decide in this specific case what's the smart contract that uh that should validate his work. Um you you sign what's the the agent that is made making the request because why it's it's

needed. I'm signing this as the owner. So I could have multiple agents and I need to specify who I'm sending the request for. Then uh I send the link to the payload and that's in this case it's mandatory. It's not optional because that's where the information to run the validation are and it can be on IPFS or on centralized storage. In the latter case I need to put an ash. Uh if it's IPFS I can put the C ID. C ID in IPFS is the the content ID. So it's the the unique resource locator to to find the resource.

and and and this is uh this validation is stored on chain in the memory of a contract. And then at a certain point the um the validator address and only the validator address of course can send a valid a validation response which uh a response integer from 0 to to 100. You can use it as binary zero fail 100 pass or use the numbers before again the community will will do what what what the developers would want the requ the request dash is is mandatory because it's the connection to the original request. So the the smart contract is saying I received a request which was the request a request.

It's the unifi unique identifier of the request. This is the response and then I have an optional like optional information I can add in pointing to an offchain file. Again if I'm using IPFS I can put the CD if I'm using um u other kind of storage I need to put the commitment to the file which is the of the file and the purpose of this is um integrity otherwise people could like change the file afterwards. I still have a tag um which is optional but has been inserted because of like different needs expressed by community. Imagine that the state of a validation can change soft finality R finality uh you can use this

um before uh leaving the uh the stage to learner just one short thing in the in the last version of 804 clients as I said don't need to register and this makes by far easier to do um gas sponsored feedback because you just need a private key at the end of the day to sign a feedback back and this uh can really help a lot in terms of UX. So to be straightforward you can build like explorers that uh that that where where where users can give feedback without having like fund on the wallet or reputation is not just for explorers you can use again it's as I was saying at

the beginning is signals among agents so you can use them in the specific application logic. So for example, I'm uh like playing with friends and creating a game based on 2004 where users uh sorry agents that's agents not not people agents needs to collaborate among each other form teams they can to to rec reconstruct words and they can deceive they can lie and so in this case the feedback is used as a way for the team members to to say oh my my team leader is a liar I don't want to work with him anymore. So this this this very flexible agent so client A says of agent B something can really be used it's a

public signals on chain can really use how you want and uh lastly you can also we expect the community to index information because if you're building a front- end application when it's like to show a game an experience an explorer uh you probably don't want to download time all the information that is partly on the chain as you have seen and and as you know uh all this information is in events and downloading events in real time I mean you need to it's it's a very bad thing you need to go through the blocks offchain stuff even worse so we expect uh indexing to to happen and based on how we4 is structured you can use for example subg graphs and we have

worked with the graph community to make this uh uh straightforward Um, so you have a we have a Q&A at the end and now let's uh get into it more hands-on uh with Leonard at U has just released by the way as uh you were saying earlier today the reference implementation. >> Yes, thanks Marco. Um so so actually before we get into it so um I think maybe it makes sense to just give a quick description of how the flows work. So I'm just going to

delete this for now. Uh but basically um the structure of the identity registry and the reputation registry the the the contracts are live so and and deploy the support already. There's a link in the chat. Um, and there's also a link to the contracts if you want to try it out. You can run it yourself locally using hard hat, right? You can just do mpm hardhead tests and everything should run. Um, but I'll just give a quick architecture overview of how things work. So, at a high level, there's the identity there are three registries. There's identity registry, there's a reputation registry, and a

validation registry. So there are three solidity contracts. The first contract is where you register agent. So let's say you register agent, you will actually be agent zero. So agent zero, you would register just you could register nothing even and set the token URI. But most people will probably register with the token URI. So if we look at the contract, right, just want to bring you guys through from an implementation point of view. you can register with your token URI and this token URI is going to be this data is onchain right but it's going to point to an offchain JSON um and we call this the

registration file um so in this this case this IPFS this is a real one that I have that's pointing to this so if we just open my terminal kind of forgot Okay. IPFS demon, right? Um and then let's take this URL. Cool. So, this is actually live, right?

Um you can actually see it here. And this points to you know just some endpoint right that I have. Um and this is offchain right because it's stored on IPFS. You can store it on your own server you know then you have to change your URL to something like HTTPS. But the point of this is to keep this data offchain but then have something onchain that links to it. Um and that's how you register and how you get discovered because once you are here people can find you on the registration.

you can find an agent ID and then get all the information including let's say your A2A or if you have MCP server you list it here or your agent's wallet things like that so that's the first step you would register with the identity registry right just register and then you can set metadata and get metadata but most importantly registering it once you have that um we get to the reputation registry right um and what is the reputation registry for as the name suggests, it's for people to give feedback about your agent. So, if someone interacts with your agent and they like it, they can give a score to your agent. And that score basically improves your agent's reputation. Um, so

over time, as more people read, you hopefully get a higher score with with more people using it. Um, I'm going to put back what I what I saw, what I had here. So basically if you're a user right you would first go to the identity registry to find the agent you would go get the token URI you would retrieve this information that's offchain right and then maybe you would talk to the agent you talk to the agent at this endpoint and you interact the agent and use the service and part of the spec requires you to um so we look at how the spec works part of the spec requires you to return this thing called

a feedback off and a feedback off is basically a signed object. Is basically assigned object of of this format. So assigned object of this format um signed by um the registered agents uh address and you basically get this feedback off token which is basically this pupil that's signed. So you as a user, let's walk through it again. So you're a user, you discover the agent through the identity registry. You find his token URI. You go get the offchain data. You talk to it services. It could be a to MCP. The agent is required to give you back uh feedback off. And then

from there, once you have feedback off, you can use this feedback off to submit it um on chain. So that's where you basically take the feedback off um and submit feedback and there's a bunch of rules around how the feedback works right you can give um you can give you can allow the user to submit multiple feedbacks but it's I would say those are details that you can look into but most importantly um the main point to take away is that you can the agent after the user interacts with the agent the agent gives you back a signed token and using the signed token you can

submit a feedback. So it has to be like that user cannot submit feedback unless he has gotten a sign token from you. So this kind of prevents some kind of spam situations. Um so that's what the reputation registry is for. And of course the reputation registry refers to the identity registry for things about the agent like who owns it things like that. Um there's a this is kind of like a soft rep soft trust assumption in the sense that um reputation is a way to to to see if your agent is reliable but you can also have validations. So validations are much more provable things. So for example things like ZK right TEES cryptoeconomic guarantees. If you have a task that is

provable and can be validated and and proven with the proof being submitted onchain, um what will happen is uh the user instead right would basically would basically use a service once again. uh sorry not use a service the first step for this is um a user would sorry use a service actually uh he will use a service and that's the first step it's the same right and you would complete a task so the agent might complete some task and then um the agent will ask for a validation request submit validation request upon completion of

the task and And let's point to the part of the contract that has this. Yeah. So we submit a validation request and then um a third party can let's just call them a validator. um a third party can submit uh validation response that corresponds to this validation request.

And these are basically for more provable things. For example, if you want to submit a TE proof um and have someone else verify that you actually did your work in the TE, then this is how you would do it. um and you can submit multiple ones but I think the main takeaway here is that validation registry is for um for a user to talk to agent and agent has something that can be validated. The agent submits a validation request and the validator submits a validation response. So this creates the building blocks for um more complex things that can be built but um it solves the discoverability problem of agents. If you register here, people can

go to the identity register and look at the information you have. And also through these two registries, it solves um some of the issues around trust. So this gives you a way to get repetition. This gives you a way to validate work they've done. So um I won't go too much into the actual contracts because they're there to read and they're quite long. But I think what I'll do is maybe just give you guys a sense of how to run this yourself so you can play with it. So go to you can go to um ERCA04. It's already linked in the chat. Um you're going to have to do things like npmi and then the basic things to get it started.

Um I think a lot of people here in the call are developers so I'm sure you'll be able to figure it out. If not you can ask claude. That always helps. Um, and what you can do is do mpm run local. That'll run a local hot node with the default keys. And then in a separate repository, let's make this a little bit bigger. You can amp run uh deploy and this will deploy the contracts. Um here there are variations on the deployments. There's deployments with um upgradability. There deployments with

vanity addresses. You can look through the mpm scripts just to see what's there, right? But there's also mpm tests. So you can just run that as well to see some of the tests that are in there. Um to see what you can do and what you cannot do just to get a sense. Uh, also out of the box, I think I'm not sure if Marco mentioned this just now, but out of the box, um, ERCA4 supports, um, EIP1271, which is basically signatures from smart contract wallets, which means it's entirely possible to make the whole experience gasless. So, as a agent um,

as a person who who is trying to develop an agent, you might not even need to use gas. You can do it in a gasless way and interact all the registries. Yeah. Um what else? What else is in what else is in here that I think would be cool to see? I think that's about it. Okay. So that's from the contract point of view. It's already deployed on SOIA um ox 8004A. So this is the identity registry. You guys can take a look. You can register here, I think. Yeah. Um, yeah, I'm going to have to see exactly

what's here. But basically, that's that's the um that's the that's kind of the overview of the contracts. There's also um some I would say community developed um SDKs to interact with it. So, Chaos Chain has has their own um Chaos Chain has their own has their own uh kit I think for interacting with their >> Yes, we we post in a link community.

>> Yes. Yes. Yes. So I'll just copy over so for people who want to play with it >> and please stay in the group because we will update this message adding all the community uh tooling. >> Exactly. >> We just notification 20 minutes ago related to the so for a new SDK. So it's very like exciting because people are literally building in public and in real time. So every day something changes in a in a good sense. Um but if you want to try it out uh one of there's also a couple of tests that I've written in in my own implementation of the wrapper to talk to to talk to um these contracts that deploy it. So

you can take a look at the tests as well as examples and we can test what are there test identity. So this is running against my local my local um deployed deployed version. So you can also take a look at some of the tests there just to get a sense of um what are the things you can do with reputation, right? Um they are pretty comprehensive. Um it shows you also how to allocate scores, how to revoke feedback and and more advanced things like that as well as validations.

Um yeah, so so do check it out. Um, if you want to build on it, feel free, you know, just extend it, fork it, um, or build your own if that's what you you want to do. So, I'll stop here. Um, does anyone have any questions? Okay, someone asked a question in the chat. How does validation work? How is data privacy preserved when the agent asks for external validator to verify his work? So to answer that question um basically the spec doesn't define um doesn't doesn't dictate I wouldn't say define it defines a way to do validation doesn't dictate um how you want to do it so we leave it to teams like for example there are a lot of good teams out there like file network

building tees we leave it to teams to decide how they want to um do validations and and there's ways to do it in a privacy preserving way um what we've done from the ERC what what we've done is to create a standard to make it possible for people to talk about validations in a structured way so that everyone can can can um read the interfaces um easily. >> Okay, another question uh >> if I can add something on based on privacy. Uh so as learner said it it depends on how you implement the validation logic but to make like specific examples

with JKML you can have privacy because you are proving to the smart contract the correctness of the computation and so only the public inputs of JKP are public the private are private so you can achieve privacy with stake secure inference which is the model that layer with Ger is a is a strong partner of 2004 is pushing for where you have validators redoing the inference in this case um it the inputs are public and also the computation because you need to enable the validators to redo the job.

So zml private state security inference public while for the it depends on how you use them. You can have like actually both. If you have like um uh t uh Oracle connectors that redo your the job and post the attestation, it it's like the state security inference case. It need to be public. The code need to be public. The input need to be public because you want different TE's to rerun the job and post something on a contract. But you could also do different things like trusting a specific T that you have checked the code. Instead of having multiple connectors, you just have one T as a source that you trust and all the private information can be sent to that T and you trust the code. So you don't you know that the code will the

information will not be leaked or you can just verify the the public key created within the T and you know that nobody else knows that key and uh with exception of the T and you can just use the key and encrypt the payload and just directly communicate with that T and it remains p private as well. So I understand that especially for the T case is a bit complicated. You need to be like a T person and study a bit but it was just to show that um based on the models you can have public or private data.

>> Yeah. Yeah 100%. Um from Preston on is the validation request URI schema only restricted IPFS or HTTP. So right you can put anything is a string right but people have to be able to resolve it right. So you can put any string you want but people have to there need to be a standardized way to resolve it. Right now out of the box um we are supporting IPFNs and HTTP URLs but of course at some point um if you want to add your own schemas uh for example you know I'm not sure what IP schema is but you can uh we're planning to support more uh content addressable things like are we things like that down the line. Yeah, if you have any suggestions, feel free to bring up as well. MultiM support. If the

NFT owner is considered a owner, how can support? So, there's this thing called operators um in the identity uh registry. So, you can already add operators um there. Uh so, so operators will be able to basically do all all the things that the owner can do. So, that kind of solves your problem. If you want to, you can add more people as operators. Yeah. >> Oh yeah. Uh I I I got a question. So uh we we already have the reference implementation for the registry and the registries are singleton on each network. So who will deploy the you know the the the the contract on Ethereum

mainet Ethereum Foundation or you your team or whoever? >> I can take this one. Uh so it's very important in general to have singletons because that's at the base of the 2004 and so uh we will for sure in terms of not having multiple ones like enforce the role of Ethereum Foundation uh to make this happen and so we expect that 2014 and especially Ethereum Foundation to act as like as a coordinator and facilitator of a deployments also potentially on other L1s and other L2s.

um to have just one. This is a different thing from the security topic of who will control the keys of the proxy contract because maybe in the future it will become immutable but at the beginning we want to keep some flexibility on on updating the contracts and uh we don't want in any way the 84 or not even ethereum foundation to control the keys. So we will have a distributed governance with a multi with different organization. uh we are discussing right now who how exactly this multi will look like EF is like facilitating this uh but uh nobody will be able to like sign autonomously in in production while in testing that's different it's we're just playing with

that and we're currently using our keys >> cool yeah by by the way so what what's the uh expected time to deploy on vinet is this audited or still in progress the contract The timeline is end of October worst case we hope. U we it also depends on the feedback that we receive. We just published the reference implementation today. If like in a few days all the community members are very excited and convinced we could also decide to accelerate this. Uh we just want to make sure that we deploy something solid and uh we we like to test and build in public. So the specs is out the reference implementation are

out and as soon as we are ready we will go to mainet as well. >> Cool. Yeah. Thank you. Uh so any questions you can raise your hand and uh open mic if you want to. Um anyone? >> Yes. Uh I have a question. >> Yeah. Uh yeah I'm wondering since uh uh agent has a reputation and it based on the rating from the users it looks reasonable but uh is there any mechanism to filter like the uh uh malicious like rating or like attacks.

>> Yes. So you can filter it. Um you you can filter it. Uh and I I I think right now it's almost I would say it's really difficult to build a very foolproof um spam slash like uh slash like uh like like like malicious like filtering malicious things onchain. So um basically a lot of it will have to rely have to be done offchain for filtering. Um and we expect teams to eventually build solutions around that also potentially maintaining a blacklist you know of people who are malicious and have contributed a lot to spam but yes it's possible to filter it. Yeah.

>> Yeah. Thanks. Uh another question is like uh all the data uh now like a lot of not all but a lot of data are store offchain now. Uh are you considering to involve like uh the D? So D is one solution but I think um there are a lot of ready solutions out there like like the teams like the graph they can help a lot of indexing but yes um indexing solutions will definitely be very important. Um this will be even more like even more crucial once we talk about um multiple registries across different chains like for example there's one on Solana Ethereum right

you'll want to have like a like a consolidated view so I think indexing solutions are very important um D is a is a is a potential option also um but right now I think the graph is a something that will just work right out the box Yeah. Okay. Thanks a lot. >> Yeah. Cool. I I saw there is a question in the comment. >> Yeah. >> Uh so is there only one registration and all the reg agent register? Everyone can make a registration by themselves. So the goal of ERC is a singleton per chain. But of course nobody can stop you if you register if you make your own registry. We just hope others won't. um

and preferably the chain itself will point people to a canonical well-known singleton but you want to deploy your own nobody can stop you um and I also expect that um aggregators will will kind of prioritize basically the most well-known uh singletons and and um registries so over time I the community will settle on you know how to read from these different registries Yeah. Uh because due to limited time so uh we can only have one more >> uh questions and before that I would highly recommend you to join the community if you haven't joined. So we

are over 700 people or even more. Oh nearly 750. So that's quite a lot. Yeah. So feel free to join and continue the questions or discussions. Okay. Um I saw Pris uh you can open your mic. >> All right. Uh can you guys hear me? >> Yeah. >> Yes. >> Yeah. So I kind of just wanted to build up on the uh question that I was asking earlier. So I understand that there's currently like a debate to decide between how much data we're putting onchain versus offchain. So that's why I was asking about the um EIP 155 schema earlier. So specifically on the validation registry part, I was thinking that if I were to have a TE verification done on chain, what I was thinking is

that we could basically put the uh response to the request fully on chain. So we could think something like EAS attestation for example, right? So >> I was thinking like instead of having IPFS URL pointing to IPFS, you could basically point to the address of the registry and then maybe like the hash or the attestation ID. I believe that's what it's that's what you're using to identify the full attestation results. So I'm thinking like if you're going to put if you're going to point a response to an onchain data, what would be like the appropriate way to do it if that makes sense?

>> Yeah, I think that's a great use case. Yeah. Um I I we haven't fully fleshed out how how that would work or I mean Marco maybe youard from other teams that are working on this. Um but yeah, this is a great this I think this is a great angle to to to improve on >> and yeah the schema thing could solve it. Yeah, >> it's just expensive. I guess that's the biggest problem. >> I mean >> we keeping it sorry the the payload of the request is of offchain but uh we we don't mandate the data that you send to the validating smart contracts. you can like send a full attestation and do full

and that that's totally doable. It's up to how you um you create the the smart contract. In the T specific case, I think there are we we are discussing a lot with all the T teams involved in the community. There are like three approaches. The the the less gas efficient which is you literally put everything the entire request and the attestation on chain and you verify the attestation on chain. That's doable. H then something in the middle is um you have as I was saying a trusted T oracle and you just verify the the signature of that T oracle because the the attestation verification is done by the

T oracle the lighter option is that you just verify for the T that you want to verify the key without going through a trusted oracle and then you have like a that's what we would like to achieve actually a public registry of T verified uh public key that you you can be sure that as far as you trust the code and the vendor you can be sure that that key has been generated within the T that nobody has access to that and you can talk to that agent using that key it's like a public address book of T verified keys that's I think the direction that we are working on but to it's we the standardization as you were asking of how to handle this on chain is not

trivial in this you have a concept cept of quote ra row quote which is a a very like a big field byte field with a hashes with and we are discussing with the community how to to make this happen it's it's could be opinionated it's pretty complex and so we uh like separated that from 804 maybe we will do another standard on this maybe we'll do just um uh implementation but by the way if you're technical on this and you want to contribute on help or help just uh reach out to us because we will have meetings in the next few weeks to discuss this.

>> Yeah. Cool. Thank you. Thank you guys. I think that's pretty much it for today's session. Uh we're going to have more uh later in the next week maybe. So yeah, I saw there's another question. So maybe I'll forward it to the uh to the community. So feel free to join us and continue the discussion. And uh thank you uh Marco and Leonard uh to join us today. Uh yeah, thank you. >> Thank you everybody. Feel free to Thank you. Yeah, thank you. Cheers. Bye. What you will be? Byebye.

>> Yeah. Yeah. See you in the community.