EIP Editing Office Hour #68 (EIP + ERC)

Transcript

[Music] Move on. [Music] Heat. Heat.

I feel [Music] down. [Music] Recording in progress.

>> Welcome to EIP editing office hour meeting number 68. This is August 5th and the issue number is 1660 on Ethereum/PM repo. It was originally planned to be an EIP only but uh thanks for Sam Wilson joining us and we have made it for EIP plus ERC. Um the first uh PR that we would like to discuss here today is PR number 1149 on ERC repository and we are joined by the author.

>> Thank you Sar9 right? >> Yeah. >> Okay. >> 49. There we go. All right, let's go see what's going on here. Okay, so we'll have to start by assigning an EIP number. Um, Okay. So,

Now, hang on a second. I am logged out of literally everything. All right. So, that isn't working. Let

me just uh kill my screen share for a bit. I'll be right back. >> Yeah, no problem. I mean, I'll still be here. My screen share will be right back. Um, there we go. Okay. Okay, there we are back. So,

oh, we broke into the 8 thou the 8,000s. That's uh >> Yeah, that's recent. Yeah. Okay. So, let's give this a nice review.

Secure intents for agent coordination. Cryptographic coordination of autonomous agents who verify intent structures without trust. Okay, that's a reasonable description. Um, I think if you want to improve this a little bit, you'd want to give a little bit more information about not just what it is, but what it's trying to accomplish. As somebody who's not super familiar with autonomous agents or verifiable intent structures, this kind of just like looks like word soup to me. Um, that's not to say it's bad. It's just for somebody who's not intimately familiar, it might not be the best description.

Um, all right. So, the CSC proposes a cryptographic framework that enables autonomous agents to coordinate interactive without relying on trusted intermediaries for verification. The fabric addresses the fundamental trust problem and autonomous agent interactions by providing cryptographic guarantees for authenticity, integrity, confidentiality. Okay. opposition to these just verify their intentions that form security properties protocol specifications and implementation guidelines. Um okay so this is um Um,

Okay. The proliferation of autonomous agents into central systems create a fundamental coordition problem that existing solutions fail to address adequately. Current approaches to autonomous agent coordination rely heavily on centralized verification authorities trusted execution environments or assume agents operate within trusted network boundaries. These limitations create significant barriers to scalability interability and decentralization and autonomous system architectures. Consider a typical autonomous agent interaction scenario. Agent A generates a trading decision based on market analysis and communicates this intent to execution system B. Okay. Under conventional architecture, system B must establish trust across multiple dimensions. First, that the decision actually originated from agent 8 and has not been forwarded. Second, that the decision payload is up and tampered with or modified. Third, that

the decision reflects current mark conditions rather than stale or replayed information. And fourth, that sensit strategy information contained within the remains confidential from authorized servers. Okay. Deploy authentication service. Okay. Scale across media systems. creates points of failure when a state coordinate across organizational boundaries different blockchain networks various execution environments manage relationship grows exponentially each new integration requires establishing okay Okay. So

Okay. Secure intent is the fundamental unit of agent coordination. Secure intent security intent to cryptographic construct instruction encoding. I is the length of C invite back again.

Okay. It's required.

Okay. And the following JSON schema 712 integration in terms of my support 712 following type definitions. Okay.

Okay. Okay. So, this looks like for 10 values

for high frequency coordination. Okay. So for 10.1 E the 20 the security. Yeah. Okay.

Operations using T. Okay. Yeah, that's fine. Economic security mechanisms implementations may implement. Okay. Okay.

Okay. Okay, test cases. Just going to assume these are correct. Securityation.

These all certainly seem like security considerations. All right. Um, that's looking pretty good. What was the broken part in? Oh, guess it's fine now. Cool. Um, done. >> Awesome. So, we have just got another EIP added. Well, we can next go on to the last call proposals. Uh final and last call proposals, then by review and draft.

Yeah, >> I'm excited. This is 4361 sign in with Ethereum. Yeah. Okay. Um I doubt that this is going to be a problem. Um, if that's the only change, let's go here. ERC's 4361 3 weeks ago. Yeah, this hasn't changed

since the last time. So, this is good to go. Oh, let's actually double check the discussions thread first. Yeah, that's totally fine. Let's >> I'm also following with one of the co-authors and I think he also made approval. Yeah, he approved this one as well. >> Cool. Well, they're signed an Ethereum finally across the finish line. That's exciting. >> I'm happy. I wish we can bring 4337 there as well. One day.

>> One day. One day. 7656 6551 nonfungeible token bound accounts. Okay. Okay. Is 6551 in here? No. Okay.

Is there a PR for 6551? There's not. So, um, okay, that's an easy one

7 858. What's going on here? So nonfundable and sub tokens with expiration supporting time limited use cases. All right. So introduce an extension for your C721 nonfgeable tokens and sobound tokens.

Then it's an expiration mechanism on tokens to become valid after predefined period. This additional layer functionality ensures that expiration mechanisms should not interfere with existing NFTs or SPTs preserving transferability and compatibility with current deps such as NFT marketplace. Expiration can be defined using either block height or time spent operating. Yeah cool. Cool. There's an interface.

Must return on tokens even if expired. Must transferring tokens even if they're expired. Expiry type must return the type of expiry used by the contract which can either be block or time. Is token expired is used for retrieving the status of the given token ID function. Okay.

Okay. So then Okay. Any other bold optional Yeah.

Okay, [Music] these are all good rational. Okay. Defend expiration. Cool. So that seems good. I should have changed the uh last call that at the same time. Oh well.

So when is two weeks from today the 19th Cool. I'm happy with this.

Into last call you go. >> Good. Then we have now proposals moving towards review. There are four of them I guess. I think uh should be three only. This is good. I'm going to remove the fourth one because it still seems to be in draft. >> Okay. All right. So, I guess let's go and fix

these links. Okay. Wait. What was it complaining about before? Who knows?

Okay. So X because I'm assuming Okay. No, you're actually listing them as separate. They're not inter. Okay. Generic key value store one generic execute function X.

It's got Okay.

165 functions below. Okay.

Execute batch. 725. Okay.

Okay. Quite a bit of things need to be changed here. All right. Okay.

So, 75 [Music] 72 [Music]

Okay. Transferred. Okay.

Okay. So that is 725. 7829. What has changed since the last time I looked at this? Nothing. Okay. Yeah. So, there's no changes to this one. 7828776.

>> Thanks. Yes. All right. This is going to review transparent financial statements open transparent financial data set. Okay. Abstract proposed API that enables the blockchain based companies that are so called protocols to publish their financial information specific balance sheets on chain in a transparent manner.

I think I left a comment about 10 Q filings before. I guess not. It's not super important. So Cool.

Good to go for a draft or review rather. 7776. So, fractional reserve token 6444. Cool. Are you still approved or do I

need to reapprove you? I need to reapprove you >> or should we just close and open because it seems like all reviewers have approved it already. I mean >> uh yeah, there was a an incorrect link so it wouldn't merge. Okay. Okay. So, why didn't you work?

Close. Reopen. Cool. So hopefully this will just merge

on its own. 7754 PR is from project board. All right. >> So the project boards are generally like you already have reviewed it before. Yeah. >> Yeah. Okay. Give me attributes for missing control.

Gave away attributes for cancellation. Time out retro dependencies and delivery control and crosschain messaging. for your C778

six cross messenger. Okay, that's good. sends battery system for crashing message after standardization to follow specifications. Is crashing applications maturation. [Music] Okay, that is a reasonable description. Uh The word delivery delivery message then

Yeah, I think this looks pretty Good. We can approve this one. Zero trust security framework implement capability access control with policy enforcement and local first architecture support.

I have no idea what any of that means but that's okay. Uh the CRC proposes a comprehensive capability based security framework for smart contracts that implements zero trust security principles through unforgeable capability tokens policy and enforcement points and cryptographic proof systems. The framework enforces the principle of least privilege single use tokens issued by recognized authorities for policy constraint enforcement mechanisms. The system supports local first architectures. [Music]

Cool. Well, that's uh another hour of office hours. So, thanks everybody for coming out. Um, see you all on the next call. >> Thank you, Sam. Thanks everyone. >> Cheers. [Music] Hold on.

[Music] Heat. Heat. [Music] Oh, [Music] hey.

[Music]