EIP Editing Office Hour #65 (EIP + ERC)

Transcript

Please [Music] move around. [Music] Heat. Heat.

[Music] Heat. [Music] Hey Heat.

[Music] [Music] moving on.

[Music] Hold on. [Music] Oh yeah. Hey Hey. Hey. Hey. [Music] Hey hey hey.

[Music] [Music]

Heat. Heat. Heat. Heat. N. [Music] Hey, [Music] hey hey.

Heat. Heat. N. [Music] Hey hey hey.

[Music] in progress.

>> Welcome to EIP editing office hour meeting 65. This is EIP plus ERC GitHub repositories open poll request. We are joined by editor Sam Wilson. This is issue number 1620 on Ethereum/PM GitHub repository. We do have a few um proposals which are moving statuses and then followed by other additional reviews. So Sam maybe we can start with the final proposal which is listed here first. >> Can do. Let's see what we're changing here.

code join and all right actually I guess we want to do Guess that's fine. Uh you get a funible UC 20 token contract and a nonfungeible 721 token contract keeps long actions to be performed on one contract to be reflected on the other. This proposal defines the relationship between the two contracts can be quered also configure

721 minutes and transfers should be skipped during ERC 20 to ERC 21 synchronization. All right. uh the ERC 20 fungeable and 721 nonf fungeible token flexibility for co-join dual nature token pair um applications such as USC 721 fractionization right okay that's reasonable and a dual nation to bear comprises of C20 contract and C721 contract for recommen.

Okay. Okay. Yeah, it seems fine.

All right. >> So, we have got one more proposal move to final status here. There are three more for last call. Let's see where they are. >> Yeah, let's take a look. So All right.

So, we are on the 15th. So, the 29th is now the last call deadline. And let's give this a read through. Authentication for three. Establish sessions by all these people review. Okay, good. So the script accounts authenticate with offchain services by send. Yep. Okay,

good. Yeah, I don't think anything else has changed significantly. So, we will approve. >> It's good to see this one moving into last call. >> Very very happy. I have been following with the third regularly and I'm very very happy to see this moving. Thank you Sam. Okay.

Okay. So, I can add that. It's easy enough. Just let go in. Such status runtime Security checks and smart

contracts. The CI pro interface bring security and smart contracts middleware enabling runtime validation function calls before and after execution independent of the protected contract logic. Okay. Current smart contract security practices often rely on monolithic validation within the contract itself. This can lead to tightly coupled code make it difficult to isolate and address security concerns but our structure architecture is needed approach. Okay.

Yeah, that seems fine. >> 6. >> What is the normal time to get it merged? Because I see that 4361 is still not merged. It says some checks were not successful. Is that the reason? >> Uh, no. It's just waiting for the HTML proofer to finish. >> Okay. >> It takes about 10 minutes. >> Okay. >> Yeah. >> Okay.

Okay. Uh the author could not join the meeting because of time zone but he has requested for reviews of two proposals. One is this one another one is also upcoming. Yeah. Okay. Cool. Okay. CIP defines a state interface for smart contracts in Ethereum by the bite code hash disable trustless discovery verification of contract code facilitating use cases like break code signing white listing decentralized distribution mechanisms. Okay.

Existing and addresses which are nondeterministic can be obvious through proxies indexing by cut hash. Okay. All right.

So, fix for the broken group. Yeah. Okay. >> I have added these smaller PRs before the bigger draft one so we can review more proposals here. I could not quite get Gajender's comment. I know he added.

>> Yeah. So Sam, I'm I'm just uh in general having this thought like if we become very strict about not accepting any typo for withdrawn or stagnant proposal perhaps our open poll request could be lesser. actually does not add a value except for it is increasing the number

of open PRs like we have received so many open PRs for this. >> Yeah. So, so typo fixes and I guess broken links like Okay. So, this PR is technically changing the meaning of the the pull request >> and it makes sense because it is for a withdrawn proposal like proposal is already withdrawn. If anyone wants to move forward with this proposal, they should ideally come and create a new PR, new EIP. >> Yeah. No, I think I think that's that's fair. Um, typo fixes I'm a little bit more okay with and stagnant and withdrawn because um I feel like they are they increase the quality of the the

project as a whole. Like if we have typos in our stagnant and withdrawn like it kind of looks bad on us. Um, but this one's uh kind of changing the meaning as well. So >> yeah. >> Yeah. I mean like uh if we really want to add value uh by increasing the you know quality of it I think it will be more meaningful if they invest their time doing it to the proposal which are in active discussion not going back filtering out the proposal which are in withdrawn and stagnant unless there is an intent of bringing it back to the active conversation and I believe if we start becoming vocal

about it we will we will receive number of PRs for these kind of type of access. >> This is 7291. All right. Yeah that's So, why didn't this one merge for no reason? All right.

Close >> out of date base branch. >> Uh, that should be okay. >> Okay. >> It's just um it's that the required checks didn't run. >> Um sometimes GitHub actions just breaks for no apparent reason. Okay. Yeah. >> Yeah. >> Yeah. Here it is adding value because the proposal is in like what last call. So it does make sense. >> Okay. So this is just a regular review

then. >> That's right. Yeah. So you have already reviewed it before and they have made changes and that's why they are added. >> All right. Permission creative factory. Permission for the question development of a universal creative factory. Um And the CC defensive permissionless and

deterministic deployment mechanism across all EVM compatible chains uses the deep 7702 set code for EOA transaction type to deploy create to factory contract to a fixed address with known bite code. The factory can then create a new contract to deterministic address using the he 1014 create. Yep. Secret keys for chain specific infrastructure. Cool. Okay,

I think it's one for stone. Nope. All right. We carefully got a secret key and use it

to send transactions to create two factory contracts resulting contract deterministic address and join all change where the first transaction can be verified post deployment to your test does have the same gas sensitivity downsides as mix method as propens transaction guest transaction. Yeah. Okay.

This see permission. Okay. Private key. Okay.

Sign 7702 authorization using the deploy private key delegating to the bootstrap contract. Execute in 7702 type 04 transaction with the authorization. Step two, the transaction must cause deploy and address. Okay.

Okay. So that is the permissionless create to factory. So now 6220 fix returns names and comments. Is this on a firewall proposal or is this on a Yeah, you are fine. All right. What are we changing here? Yep, that's totally fine by me.

Okay. Instinctbased automatic transactions. All right. 7757 instinct based automated transactions. datadriven transactions with onchain instincts, temptation values and environment variables for target autonomy.

Okay, the CC introduces a compact onchain program that lets autonomous agents coordinate through instincts small objects by scientists and safely and once a trigger condition is met the contract secession transaction the agent managing a private key alongside instincts agent shares some onchain environment variables can Okay. Okay.

All right. Yes. Okay. No, this didn't get didn't get merged. Why?

Ah, that's why Right.

Okay, do that. Okay. Yeah. So, I guess I can just delete

these. I do that all at once. No, I can't. Can't edit it. Um yeah. All right. He has these tokens. Okay.

stream address privacy own verification signatures without exposing addresses. Standards separate ownership from transaction initiation allowing third parties to pay gas fees without controlling tokens suitable for batch transactions or gas sponsorships. Key functions transfer, mint, destroy are defined with robust signature verification and not check text checks. Avoid message tampering. Replay attacks by relays. Traditional EIP Okay. Let's

try this instead. Yeah, I'll just tell them to do it. I'm feeling lazy today. Okay. Reference implementations. It's

fine. Cool. Nonfunderable account tokens. Is this not a thing already? I vaguely remember this.

No, guess not. All right. Smart cancel trib. Cool. a nonpunchable account token sent to owners as smart contract wall transfer the NFT transfers full control of that wallet validated making smart contract visible and tradable existing NFT infrastructure >> yeah I think they have added on top of your last reviews right in implementing all your comments from that because I don't know for some reason I see your GitHub handle in one of these 1101 we are looking at right? Yeah.

>> Yeah. >> I haven't looked at this one yet. [Music] >> I just assigned it the um the number. >> Uh yeah because it's is that like what I'm looking at it it is commit number. Okay. Let me uh copy link and >> like you talk about this one here. Yes. >> Yeah. Just to send the number. >> Okay. >> Okay.

>> I still see they have put 4337 in required. I don't know how long they are running here. Okay. All right.

1101 1103. Have to look at Word and fix some typos. Yep, that's fine by me.

07 functionality. Yeah. Okay.

I suppose by removing these links also this proposal can be made as a standard right? I mean only >> probably. Yeah. >> Okay. Hello.

All right, that's 997 774. Four. Okay. dependent for schema safe upwards of extendable structable storage spaces.

Great. So, I'm not going to start this one. I'm not going to have time to finish it. Um, yeah. So, I guess thanks everybody for coming out. I will uh see you all maybe next week and maybe the week after that. >> Thank you so much, Sam. And for people who are watching this, tomorrow we are going to have the EIPAP meeting. So if you have any questions or comments related to the process uh of EAPs, please join us. We hope to have some presentations as well with the tooling that community may have created. So yeah, thank you all. See you around.

[Music] Oh, hold on.

[Music] Heat. Heat. [Music] [Music]

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

Hold [Music] on. Hold on. Heat. Heat. [Music]