EIP Editing Office Hour #73 (EIP + ERC)

Transcript

Heat. [Music] Welcome everyone to EIP editing office

hour meeting number 73. This will include both EIP and ERC's PRs for review. Thank you Sam Wilson for joining us here today. On agenda, we have a few final last call review and a bunch of proposals that may require force merge and a few draft proposals to look into. So, let's begin with the final proposal. >> Sure thing. >> Um, just warning you all know this will be a bit of a short call for me. Um, probably going to end at 12:30.

All right. So what's going on here? Signature verifiers interface for the verification of signatures by addressless key by addressless keys. Okay, last call deadline has passed. Let's go take a look at this discussions too link. Nothing recent. So good enough for me. All right. So externally owned accounts EOA can send messages with their associated private keys. Additionally, RC21 verification by smart accounts such as multisync. Both caser is an Ethereum address standard to extend this concept

of signer description sign verification. Two keys that do not have an Ethereum identity of their own. Okay. Okay, that makes sense. With the development of account abstraction, there's increasing need for nonthereum signage verification. Cryptographic evidence such as natively supported page 56 K1 are being used for controlling. Yep. R1 say keys. Just deploy 12 compatible contracts for each key individually. This would be cumbersome and expensive as a cover to separate the account address from the

key that controls them giving said using a small number of verifier contracts that can process signatures in a certain way and having the accounts remind these verifiers with the correct approach. The advantage that once the verifier deploy any key can be represented using a verified key pair without setup cost can be given to control the smart account perform. I swear I just read that.

where signers are identified by their address to your new model where signers may not have an address and identified by a bytes object. This definition is backwards compata and 71 contracts. In that case, we use the address of the identity contract as the verifier and the key is empty. Okay. Okay. Keys are represented using bytes objects of arbitrary length. For example, if P 256 are public key, keys must not be empty.

Verifiers are smart contracts in charge verification for given type of key. They have an Ethereum address. Okay. Verifiers must implement the following interface. Blah. should return or revert. Okay. Verify statements. Rational verifiers could be used to avoid deploying 121 identity contract one per key which would be expensive using this model keys could be used for deployment cost 1271 already covers the keys for a key issue.

The verifier contract should not support or be expected to support empty keys. Centers that are 20 bytes long empty key should be handled using SC21 consistent with existing systems require message by 32 hash usually produce following 911 or cryptographic systems use different hash method should see this hash as message and possibly rehashing using 51. Okay. All right, that's reasonable. Just uh this comment here. All right, moving on to

RC6909. No, no, no. I guess it doesn't tell me the

request. Oh well. 699 And then we look at Sorry, I'm just looking at the history

of this here. Yeah. Okay. Um Okay. And the phone says multi token

contract is simple alternative to the ERC 1155 multi token stated in contrast to EFC 1155. Callbacks and batching have been removed from the interface. The permission system is a hybrid operator approval scheme for granular and scalable permissions. Okay. Single permission scheme limited allowance over a token ID to the contract compatibility is deliberately removed only when necessary. Additional features such as batch calls increase and decrease allowance of deliberately. Okay.

According to US 115, callback required reach transfer and batch transfer to contract accounts potentially and calls to the recipient when the recipient is a contract accountless behavior desirable opt behavior. In addition to runtime performance of the contract token itself also impacts the runtime performance and codes as recipient contract account require multiple callback functions to return values to receive the tokens. batching transfers were useful from the standard to allow for opinionated batch transfer operations of different implementations. For example, a different AI encoding may provide different benefits in different environments. Just call data says yeah.

Okay, that all that's all good. Uh EC 69 compliant contract must implement the 165 isn't required. It is color. Yep. Spender operating Okay, that looks fine.

All right. Two months call 7857. AI agents. Nice. So good. AI agents with private metadata. That's all good. The standard interface for enterprise agents with their metadata represents agent capabilities requires privacy protection and traditional standards that focus on set of metadata. The standard mechanisms for verifiable data ownership and secure transfer by defining unified interface for verification methods to zero proofs.

Okay. The increasing intelligence of AI models agents have become powerful tools for automating meaningful daily tasks. The integration of agents with blockchain technology has been recognized as a major narrative in the crypto industry with many projects enabling agent creation of their users. However, crucial missing piece is the centralized management of agent ownership. AI agents possess inherent non-punchable properties that make them national natural candidates for NFT representation. Agents embody clear ownership rights. This looks like a correctly formatted

proposal. I'm really not sure how useful a proposal like this is going to be, but

we'll see. It's not really my place as an editor to determine that, but uh yeah, 7656. Move the proposal to last call. All right. Federalize contract link services define a factory for generic services linked contract type including smart accounts and NFTs. All right. So first thing we need to bump that up by two weeks. So that'll be October 7th.

Uh, this defines a factory capable of deploying generic services linked to specific contracts such as ES437 accounts or 721 tokens. services extend the functionality of the target contract operating under the ownership of the contracts or NFT's owner without requiring modifications to the original contract's code as a secondary effect house fighting Existing projects determine bound

accounts specific successfully bind smart accounts to NFTs allowing registries to deploy accounts by specific token ids. However, these stages are two key limitations. often require deployed contracts to implement specific interfaces for handling assisted executing transactions effectively mandating the deployed contract must function as an account or they are restricted to NFTTS or many other contract types particularly 437 accounts benefit from similar linking mechanism strict functionalities CRC approach more versatile factory specification that enables development of proxies pointing to any contract that enhances the associated contract's capabilities whether it's an NFT or account contract Nice social recovery mechanism linked to an

existing 437 wall that can restore access. Okay. Okay. To find a slow >> All right. Sam, I know you have less

time today. Um I would request you to maybe kindly go to the force merge section. Maybe we can pick up couple of um PRs from there because review might take longer. >> Sure. And uh we are joined by Franio. Um this PR is from him in case you have any Okay. So what are we doing here?

>> I can give some context if you if it's useful. >> Yeah, sure. Um the the issue that I was having is that in an EIP I wasn't able to link to an ERC that was added postsplit and that is because the one of these checks I think the the validator runs without first merging the ERC's repo back into into this repo and so it doesn't find the file That's interesting.

>> But it does for the publish, right? Yeah. >> Yeah. Looking at this, I found that it is merging for other steps. So, I just pulled that out into a shared action and um which is what you see there on screen and then added the missing merge into the check. >> Yeah, I think this makes sense. Um, I will just go over this a little bit in more detail after uh I hop off this call, but yeah, I think this makes sense.

>> Cool. Yeah, thanks so much. >> No worries. Yeah, I'll hop off hop off then. >> Cool. Appreciate it. Um, yeah, thanks everybody. I'm going to take care of this poll request offline. So, thanks for coming out and uh see you the next time I'm hosting one of these. >> Thank you so much. Thank you everyone for joining. Have a great rest of the day. Bye-bye. >> Right. Thank you. Heat. Heat.

[Applause] What's up?

Heat up here. Thank you.