EIP Editing Office Hour #26

Transcript

welcome to EIP editing office hour meeting number 26 uh this is issue number 277 on ethereum caters EIP IP get of repository I shared the link here in the chat for uh for reference uh thank you Sam for joining us and we are also joined by a few authors so the first item for like a review here I can see that is a EIP 7682 okay uh bofu if you would be U maybe share the pr number directly that will be very well in the meantime Sam maybe if

you were to start with the final eips you can take a look try to grab the pr number for it yeah thank you so I think that is uh this one here 7682 okay yeah I think um yeah so there's no reason that we can't work on this it just has to be moved to um the other repository before we can do anything with it I think this would be a good time for

any other authors following this call Sam if you would like to let them know about the changes and whoever have not made their PR move oh sure that's a good idea so um after you know several years of discussion uh We've split erc's and eips so if you have have an ERC it is now in the ethereum erc's repository and if you have anything that isn't an ERC it's all going to be in the ethereum eips repository um this is kind of like a a branch from our trying to organize things better um initiative and uh it should make things easier for us to

review and hopefully make things less noisy on the GitHub for core developers who don't really care that much about erc's or or at least they don't care to receive notifications about them so uh if you had a port request open on ethereum eips and it was for an ERC type proposal um you'll have to move it over to the ethereum erc's repository I went through and left a comment on everybody's po request uh there's a link in that comment on um how to do it if you wen't that familiar with Git um yeah it'll look like something like this here and uh the guide is right here uh just follow that and you should be able to

open your PO request on the new repository and we'll be able to work on it sorry for all the inconvenience there yeah um yeah thanks for the explanation I yeah I didn't notice that you provide a comment for for me so yes I will follow the instruction and send a new pull request awesome thank you anyone else on the call if you have any poll request like the new poll request in the ERC repository and you would like that to be discussed today please feel free to share it in the chat and we will take it uh as we receive so all right so starting off

with 7066 here correct I think that is in the final yes that's right yeah all right so we are having some difficulty with internal links uh between like eips and erc's and stuff so if the bot's complaining about something like that just ignore it and we'll take care of it at some point right interface for enabling locking of RC 721 using locker and approved this is going to final so this needs to go into a last

call First unless there already was one let's go take a look look at an old repository [Music] 7066 h yeah I guess they just wanted to

go to final yeah the last status even on the eaps rep I mean like the website it says review so they need to go with last call yeah okay Sam I wonder if it is possible to

maybe increase the font size of your screen because that generally does not turn out good when we are sharing recording yes that is better a little better yes but can it go a little bit more control+ plus yeah it can let me just put you back on this mode yes thank you okay h

okay maybe want to add the count as well like the um end yeah's forget the order comes right after status all right there two weeks from today 14th yes so we'll do I maybe the

20th give them a little bit of extra time there there so an extension of VC 721 this standard incorporates locking features into nfts allowing for various uses while preventing Sal Tok owner can unlock it setting loer address power unlock the token owner can also provide approval for token ID that should be for token ID enableing ability to

lock asset while address holds the token approval tokens can also be locked by approved assigning a locker to itself upon token transfer these rights get purged all right motivation so h721 has sparked unprecedent and unprecedented search and demand for nfts however despite this tremendous success nft economy it should be the nft economy suffers from secondary liquidity where it remains liquid liquid in the owner's wallet should that shouldn't be capitalized wet there are projects such as that of T5 par

space and Paras space uh which aim to address the liquidity challenge but they entail below mentioned entail the below mentioned inconveniences and risks for owners as they necessitate transferring the participating entities to the Project's contracts all right so Sam I actually have a question on this one yeah um when we were writing 4626 there were um complaints about pointing to specific production products because specific implementations are not

necessarily going to be immutable like the standard is meant to be so they wanted us to use abstract terminology like lending protocol or whatever instead of saying compound um is that sort of an EIP editor flavor like it depends on who's editing or is that um yeah so like technically Like rules is written mentioning a project is like an external link and should be prohibited um I'm a little loose on it in as long as it's not like a like a reference implementation or in the specification section um but no that is a good point and uh we can remove those

I tend to like the spirit of that rule myself but I understand also it's like it is easier to point to specific implementation so it's kind of unclear whether that belongs in like a medium article or you know a substack or whatever um anyway yeah yeah no it's a good point there we go cuz you know if if down the road they don't entail the same risks that are listed here then it won't make any sense so it's yeah absolutely a good point loss of utility so the utility value of nfts diminishes when they are transferred to an escro account no longer remaining under the direct custody of the owners all right lack of

composability the market could benefit from increased liquidity en owners had access to multiple Financial tools such as leveraging loans renting out their assets for maximum returns composability Services the missing piece and creating a more efficient market smart contract vulnerabilities energy are susceptible to loss or theft due to potential bugs or vulnerabilities present in the smart contracts they rely on yep so the aforementioned issues contribute to a poor user experience and we propose enhancing the 721 standard by implementing native locking mechanism rather than being transferred to a Smart contract an nft remains securely stored in self- custody but is locked during the lock period the nd's transfer is restricted while its other properties

remain unchanged do use or distribute its utilities so there should be a period there okay nfts have numerous use cases where the nft must remain within the owner's wallet even when it serves as collateral for alone whether it's authorized access to a Discord server I can't comment on that so that one's going to sneak through or utilizing nft within a play to earn game owner should have freedom to do so the lending period just as real estate owner can continue living in their mortgage house take personal loan or keep tenants to generate P keep tenants to generate passive income these functionalities

should be available to nft owners to bring more investors in nft economy sure do I have edit rights on this I do so I could just make these changes we'll see loable ADT enable the following use cases N cized Loan utilize n okay said lock join okay noway

okay different from other proposals this implementation provides minimal impation of lock and unlock and beles other condition like time bound great ideas but can be achieved without creating specific impation locking unlocking can be based on any conditions therefore time bound okay this implementation proposes a separation of RS between locker and approver token can be locked with approval and approved can unlock and withdraw tokens bnpl um okay so you did mention that somewhere

else now pay later yeah for

Str lock okay the secure convenient mans prevent np5 use cases such as taking Ling and renting anticipate that this propos projects okay HC 721 comply contracts May implement the CIP to provide standard methods of locking and unlocking the token at its current owner address token May lock token owner May lock the token is unlock to the same address using lock this must said locker toore locker

token owner or approved May lock the token using lock function this this must set Locker to message. Sender token may be unlocked by Locker using unlock function unlock function must delete Locker mapping and default to address Z the token is locked the locker function must return an address that is locker and can unlock the token for tokens that are not lock must return zero lock function must revert if the token is not already locked lock function must revert if token is not already locked that that seems wrong can someone double check that I'm

reading this correctly lock function must revert if token is not already locked maybe the goal here is to save some gas so that you don't execute it un necessarily a second time but wouldn't this mean that an unlocked token can never be locked I think it say the lock must uh revert if is if it's already locked so

it means I cannot lock it twice but it says lock function must revert if token is not already locked yeah I think that's a typo a logic typo ah oh yeah I I completely igned the not sorry no worries I'm just like I don't want to incorrectly comment on this person's thing unlock function must revert if token is not locked that makes sense here c721 approved function must revert

if token is locked erc721 transfer function must revert if token is locked r721 uncore transfer function UHC 721 doesn't have a transfer fun underscore transfer function here see 721 so oh you're also write transfer not transfer

that's um for there's also a somewhat pedantic Point

here but it's saying that transfer must revert if the token's locked and then it's saying it must pass if it's locked but the caller is the locker so that can be simplified it must revert unless the caller is both approved and the locker because otherwise it's saying like two incompatible things those two sentences and it's also saying that even if you don't own the token it must succeed so that's kind of a problem too feel free to leave a comment to that effect like I don't I don't have to be the only one uh reviewing today um you see 721 true uh

functions that transfer ownership of a token must and we are two zoomed in7 that is not what I wanted to do uh UC 721 transfer function must pass

token is locked message sender is approved and lock about after ERC 72 transfer okay okay to may be transferred and locked and optional setup approval to Locker using transfer and lock function this recommended for these cases for token transfer and subsequent verification is required okay

okay optional set up okay okay it's the actual interface lock extension for 721 committed one token lock token is unlocked okay Lo the token ID if message Senter owner or approved transfer unlock okay lock bring up space this assertion contract to verifi a token is locked

okay this Pro exposed to transfer and lock which can be used to transfer token and lock the receiver's address this additionally accept set approve which is true which on true assign approval to Locker hence neing lock of the token okay okay good security considerations yeah so the rest seems fine good all right so I think that's good for this one and we will move on to the next one so ERC

3643 so this is moving to last call okay T-Rex token for regulated exchanges an Institutional grade let's expand all these first uh institutional grade security token contract that provides interfaces for manage management and compliant transfer of security tokens when are we going with this is last

call can I God just give me edit permissions makes this so much easier um okay so let's see if there are any

discussions still active yeah it doesn't look like it cool so the 2x token is an Institutional grade security token standard this standard provides a library of interfaces for the management and compli transfer security tokens using an automated onchain validator system leveraging onchain identities for eligibility checks the standard defines several interfaces that are described here under neat the Advent of blockchain technology has

brought about a new year of efficiency accessibility and liquidity in the world of asset transfer this is particularly evident in the realm of cryptocurrencies where users can transform token ownership peer-to-peer without intermediaries transfer rather however when it comes to token secur through security tokens the situation is more complex to than need for compliance with Securities laws these tokens cannot be permissionless like utility tokens it must be okay neat is motivated by this need it a a comprehensive framework designed to work in conjunction with non identity system allowing for the validation of identities credential investors through signed attestations all

right system must be used to apply any rule compliance that is required by regulator or token is sure okay agent R interface the standard defines an agent role which is crucial

for managing aent various functions of smart contracts the interface for the agent role is as follows all right so let's pull their discussion thread back up and comment on it for

okay so do you have in the ration now a reason why activ management um implementing this

interface um it's a good word for those different IND depending example see doesn't

standard okay some I don't know

regulatory contract okay back over here

actually okay back up to here the cas responsibility okay to be able to transfer on T-Rex you need to fulfill several conditions sender yeah receiver yep yep yep on this point Sam do you think there's actually utility in standardizing functions that admins could call because then you can make interfaces that uh work for for multiple contracts sort of more in a more opinionated way out of the box versus having to implement

everyone's um you know custom function names or is that is it enough to coordinate without any IP for that um so I think there is a separate EIP for the mint and burn functions and I think that might be the the right approach for some of these things cuz like yeah ERC tokens are definitely popular enough that a standard mint burn interface would be nice but this you know I don't know if it needs to standardize it right off the bat I don't know if like the less you can standardize you know the the more flexibility you have and then you can come up with something good down the road I don't know it's kind of a tight rope walk I just want them to put a reason why they're standardizing it in here sure yeah yeah that makes sense

okay force transfer all right the burn function do I actually specify a burn function C they do okay they do have standardized Min and burn uh what's the

Vault EIP yeah that one yeah 46

26 [Music] proposal 466 fault want to comply with this proposal but okay it's

broken cool on ch9 they could possibly I mean they could just change the naming and then in terms of accounting for how to tokens you know 4626 for example um that would just be like forced delution by the Admin um and the admin could be responsible for keeping the accounting straight by burning from somewhere else um or the admin could have the rights to just delude everybody there's nothing intrinsically wrong with minting other than the clash of the parameter the function names so call admin Mint or something yeah well that's kind of what I'm saying right like deposit would be

the normal way to Mint tokens in a vault right yeah so you could still also have a mint function oh is really 4626 defines mint yeah it's the direction so deposit goes from assets to shares and mint goes from Shar step it's denominated in shares so there is already a mint function there but even still it's okay for an admin to have minting rights on a 4626 that just changes the the access control trust assumption and delution for token holders oh yeah it's not that it's bad that they could it's that they have to right yeah oh the the standard is explicit that that's the only way that

you can mint the other one I'm not sure probably not um okay the mint takes shares you 256 yeah so it is it is exactly the same okay so that's probably a bad example then POS yeah okay yeah that is a bad example thank you for that yeah sure okay

de okay good these are all actually rationale so that's good backwards compatibility

sure yeah so I mean that's pretty decent and then we'll go leave that comment over here okay for

cool Ed office hour so we got another to last call these ones are always the longest uh so Sam I think poo in the meantime has a um created a PR on the ERC repo and the number is 8 if we can maybe quickly take a look yeah of course there we go all right is there any policy for ordering

the editing based on who is like which authors are actually on the call or they kind of just go from the top to the bottom so it should it's authors that are actually here get priority and then perfect whatever whoever else asked yeah cool yeah the idea here is like uh we want to make sure that this call is more utilized for answering questions rather than just reviewing because reviewing are also being done async and by any and many other editors so uh authors who have questions generally join this call and try to get their proposals reviewed and uh shared their question with editor great we we want to avoid the

situation where this is a back door to get your EIP reviewed faster even though it is that a lot of the time okay preserve the digital owner intent and respect Creator rights all right CP for sustained approach to declaring mining preferences the metadata okay comp blockchains Med it's like okay okay follow yeah

okay onto media Providence registration defined in yeah so you can't so even though this doesn't specifically depend on those eips I would say that it's hard to understand this EIP without um without them 7

53 I'm also seriously hoping I didn't tell you earlier to remove those because that also sounds like something I might do and then 21 73 okay okay

oh 1155 okay as digital assets become increasingly utilized in yeah machine learning work isal but the rights and preferences of creators and are respected yeah so simil to dete websites content owners and creators are looking for more Dr control over how their creativities are used this proposal declaring these preferences adding data Min preference

in the content metadata allows creators to include information about how they want to work in the content metadata allows creators to include information about how they want their work maybe part the may be used as part of data mining or AML AIML trading workflow this ensures the original intent of the content maintain I think that's better

this proposal standardizes a method of declaring these preferences adding data minor preference in the content metadata allows creators to include the information about whether the asset may be used as part of a data mining yeah that's for AI focused applications this information serves as a guideline facilitating the ethical and efficient use of content while respecting the Creator's rights and building sustainable data yeah okay the introduction of the data minor prefence property in digital asset metadata covers the considerations including I should probably have colon rather including accessibility a clear and easily accessible method with human

readability and machine readability for digital asset creators and license owners to express their preferences for how their assets are used in Data Mining and AIML tra workflows the AI ml tra creators could check and collect data systemtic systematically rather adoption as Coalition for Content Providence and authenticity c2p already outlines guidelines for indicating whether an asset may be used in data mining or AIML training it's crucial that onchain metadata aligns with these standards this ensures compatibility between inmedia metadata and onchain Records okay so I think I think that's a reasonable call out for another standards body um and it's in the motivation section so

that that's fine uh this EIP introduces a new property dating moding preference to the med standards which signify the choices made by the asset creators license owners regarding the suitability of their assets for inclusion in data mining or AIML trading workflows object include one or more specific conditions okay that's all good each category is defined as a set of permissions that can take one of these values okay good schema defined as follows proper is true great preference example for only

allowing fors great okay and then embedding it into an ERC [Music] 21 proper nft defined and exactly using the data mining preference property in nft this it's a little ambiguous so this and the example using Okay property in yeah we'll change this to here here

here is an example yeah so I'm just changing that because um the way it's originally worded here it sounds like the property is defined in erc721 but it's not so just trying to make that a little bit more clear we can put the data mining preference field in the Mt metadata below the license field is an example for specifing to use a constrained condition NFD has its way to describe its license okay so this license mentioned here in

row uh line number 140 146 is that only specific to this nft and should it be allowed as a standard yeah exactly that's that's what I'm uh yeah we'll put that up here

okay for okay example using the DAT preference property in on media Province okay 7053 assuming the decentralized content identifier is after foll up the

CID got the commit data sentence fragment there so so assume the decentralized and okay okay

7053 7053 75 okay uh same sorry just double check with you so the suggestion is that uh in the example so maybe I will write a

comment like uh this portion uh this session is the original like ant 721 and this session is an newly added by this proposal just add some comments in the example yeah it's it's more like here the the 721 I'm a little bit more familiar with so I'll do that one um so did they not even have an example in here it's annoying so it will be uh name description

image okay there we go so let's go for

yeah properties and description image perfect and then few too many so does that kind of clear up what I

mean with these type of comments like I want to see the there still too many new lines on there but I want to see um what it what the the final out like the final combined metadata would look like that way somebody can like yeah I think yeah very CLE thank you I think just provide a 100% is PR example so that the reader will not be confused exactly yeah close enough it doesn't matter that much

okay good R now good good security considerations yeah that looks great okay yeah and feel free to like give me a ping on on Discord or or whatever uh or Twitter where wherever I am and I can take another look at it when you're ready um yeah awesome um thank you so much no no problem thanks for thanks for coming out uh I've got a jet for another

meeting so I will talk to you all later uh Happy Halloween everyone Sam before you leave could you please let us know about the next meeting time so if it is going to be500 UTC for people in United States the meeting will be an hour earlier like today it started at 11:00 a.m. it will be starting at 10:00 a.m. do we want to keep that or we want to move it uh I don't really care either way okay then let's keep it 1500 UTC it's like not changing for many many of the people in other part of the world sounds good perfect thank you so much for your time and thank you everyone for joining us today thanks