ERC-7936: Versioned Proxy Contract Interface

Transcript

The way people handle dependency and smart contracts is very primitive and there is something that we can learn from web 2. >> We want to bring the best of web 2 version into web 3. >> The ERC 7936 is not like the traditional proxy which forces the use of the latest version and we want to enable selected version delegate calls. a problem that uh today when you depend on a contract and the contract is upgraded all clients are are forced to update to depend on the new behavior.

>> This proposal we maintain a registry of implementations >> and we want to improve backward compatibility and upgrade flexibility. >> So the users can choose to upgrade or they can also choose to stick with a verified version. This proposal completely solves the problem of breaking updates. Welcome back to PE and a podcast where we talk about Ethereum improvement proposal and Ethereum standards.

This is episode 158 brought to you by ECH Institute and I'm your host Puja Randan. Today we are going to talk about an ERC. It is a standard track proposal which envisions to versioned proxy contract interface. This proposal is documented in April 2025 and currently is in the review status. We are joined by co-authors of the proposal Rafina, Monica and Martin. Welcome you all to Panip.

>> Thank you. >> Thank you. >> Thank you. >> Well, I know Martin. Martin is a professor at KT Royal Institute of Technology at Sweden. I connected with him back in 2022 when he reached out to me for a project which was based on client diversity to increase resilience. at ECH I remember we also did um survey which was based on client diversity and it was published in the same year so definitely there were exchange of conversation and that was the time when people were preparing for merge so I believe Martin and his team ended up helping testing the merch with some or the other area after 3 years hearing back from Martin was uh exciting for me

because I know they stick around they wanted to make more contribution into the ecosystem and thus we see this proposal and I would love to hear more about you and the team a little bit of background what motivated and how you entered into the Ethereum ecosystem and what brings you to the proposal documentation. >> Yeah. Yeah. We've done a lot in three years. We've done more client diversity. We had grant from the academical to to do advanced client diversity. That's a project we'd be very happy to talk in one in a good outlet either web or or podcast. But yeah, so we had a very good project on diversity another one verifiable university funded by a

foundation together with Rafina and Monica. We we had also another project funded in the ecosystem development part on software on dependency analysis. So releases ERC is one of the outcome a very concrete outcome of an ecosystem development grant where we make sense of how people reuse code on chain. There is a massive amount of reuse on chain which is good for the ecosystem but people don't know how it's done and so we worked extensively on doing onchain analysis with academic papers on writing the CRC to improve the maturity of the ecosystem and also on building automated security tooling for smart contracts and this is part of a of an effort to commercialize our our academic results

in a product which should be useful for the community so that this is a maybe.xy XYZ product that we are working on. We also work extensively with Bureau students and master students. So we send them to Ethereum conferences. So we have a grant for that. And so we send our best students two conferences. So they were for instance one best student and one master and one Phon in Argentina and they were all super inspired by the field. So yeah to sum up we have a number of different activities some very oriented towards community you know building community bringing new students some very heavy heavy duty research where you know we publish scientific papers to push the state of the art of of web 3 and also we have a

commercial arm where we send three security solutions um to to the ecosystem that's what we're trying to do to cover basically >> so there is a complete package to build a robust ecosystem, heavy duty research, a specific papers and selective participants joining different event backed by commercial product. Thank you so much for contribution in the Ethereum ecosystem. >> Thank you. >> Well, Rafina, if you would like to go next. Yeah, sure. So uh I've been working with Martin for two years and uh I started doing research like the blockchain related research from contributing to opensource ERM related projects and also then I do software

supply chain security research and then I move to the smart contract research. I kind of feel like all these fields are collected like for example all the software dependency analyze I have researched is actually also very important for our web3 ecosystem because that's where like the front end is where the users interacted with the contract or like the blockchain. So I feel like after collecting all this I got to know more about the Easter room and I know more about the community. So I also like the like how people contribute to the

whole ecosystem by contributing to like all the doing all the security research or like uh have very good uh place to discuss freely of all the ideas. So that's also why I want to contribute by writing this uh Y with Monica and Martin. So yeah, >> that's awesome. Thank you so much. >> Thank you >> for your contribution because we understand that we can help each other by making a standard so newcomers can just adopt those standards, come up with amazing projects.

>> Thank you. >> Very happy to contribute. >> All right, we can go with Monica next. >> Sure. So yeah, I'm Monica. I've been working with Hafin and Martin for almost two years too. I actually started my research on blockchain on the infrastructure part. So the node, the consensus protocols and then I was reading a lot of news on blockchain attacks and and I realized a lot of the attacks were happening on the smart contract side and I was thinking how can I actually prevent that or make something uh a nice contribution to the ecosystem that has a bigger impact on the final users because at the end of the day if you're using some smart

contract protocol if it gets attacked you also lose that money that you invested there, right? I started working with Martin and Hafina on this web free software supply chain challenges that we could improve and contribute to the ecosystem so we can mature and we take a lot of this is amazing. I'm thankful for your contribution on the application side of Ethereum by building this standard. But since you have interest in nodes and other things on the Ethereum protocol side as well, perhaps you can take a look at other interface or networking standards and maybe one day we can have some suggestions coming up from your end as well. I really

appreciate you all working in the ecosystem and uh helping new contributors in and I look forward to hear more about this proposal. So without further ado, let's peep in. >> It's a pleasure to talk about this work and to disseminate this work. So Rafina, Monica and myself have been working for quite some time on the problem of dependencies on chain. So how people uh reuse existing contracts or depend on other contracts. And after after many many months of work and doing onchain analysis, lots of onchain analysis, we realized that uh the way people handle dependency on smart contracts is very primitive and there is something that we can learn from web two and um and this

ERC is the result of this of this work where we bring a fundamental concept of web two which is a concept of version dependencies to onchain and smart contracts. So the next slide gives a bit of background. So it's you know we all know that in blockchain everything is immutable. Yes it is. So when is zipper z forever yet in ethereum we have a fundamental way to handle mutability. It's through proxies and and upgrades and this is essential for doing proper soft engineering uh because this is how we can fix bugs. is in how we can add features and this is uh something which has been pretty much researched by the

community. So there is you know the early EIP1 1967 on proxy storage slots to avoid storage collision the well-known uh universal upgradable proxy standards and the very sophisticated standard on diamonds which to be to to do a lot of of very advanced use cases yet all those EIPs suffer from the same problem is that you know if I depend on a contract and this contract is upgraded did then I will directly depend on all new problems. So we will suffer on new bugs and we also suffer from security problem. If a malicious sector is able

to upgrade a contract they would be able to impact all clients of that contract. So it's a it's a major problem and there has been real world exploits about about that. So that's the problem which we solve with with this EIP. So we solve the problem that uh today when you depend on a contract and the contract is upgraded all clients are are forced to update to depend on the new behavior. It's a real problem when you have a software company. Usually you want to support like gradual rollout you know you want your clients to depend on v2 when they're ready to depend on v2. You don't want to force all your clients on the same day to depend on v2. So that's the problem we are solving with.

Um same thing today more or less when you depend on a contract to be upgraded you fully trust the proxy admin the proxy owner that they will not get their keys compromised but as we all know all keys end up being compromised. So our ERC reduce the first assumption on on on the proxy admin. So we solve the security risk of having a malicious new implementations, malicious upgrades. And also from a pure software engineering perspective, we also solve the problem of breaking changes. Um if it turns out that a new good update is breaking for me, well I I could still perhaps depend on the previous version. So that's the problem we are solving with this ERC. So

basically MR said there are problems with the current proxy pattern and the ERC 7936 is not like the traditional proxy which forces the use of the latest version. This proposal we maintain a registry of implementations. So the users can u choose to upgrade or they can also choose to stick with a verified version. So basically we maintain a registry of the implementation versions and we map the version identifier to the implementation address and then the

caller can specify which version they want to call. So if we say the picture here and let's say the cat is a user and through the proxy they can dedicate call to the food they want like the implementation contract which is a dry cut food but one day the owner want to change to the wet cat food. So basically the dry cat food is not uh option for the cat anymore. But with our yi and although there are new option of the wet cat food the cat can still choose the dry cat food because he choose to and he's happy about it.

So uh let's say an example which is the main push new implementation and it contains a back bug. So basically all the users using the proxy fallback are routed to the bug implementations they would lost funds but with this because the old versions still there and they are still default and registered. So the users or the integrations can keep calling the old audited version while the function executed version at the old version. So the result is that only the callers who explicitly

choose to call the new version are affected and most the user remains safe. So the core function of this ERC is register version. For this one, you can add a new versions and you can also say set the default version which is a fallback version and also execute at the version is uh basically you call a specific version also you can get implementation and get versions and Monica do you want to continue?

>> Yeah sure. So Kafina introduced basically the core of our interface our northstar the goal that we want to achieve with DCRC. So this is the interface that we propose in our formal PR. So it formalizes what are the core functions that have been already told us about and now we wanted to talk about a bit how we get to this goal. So a bit of the implementation. So first of all we have to identify the biggest challenge here because we are sharing a bunch of implementations and we're allowing the user to choose it but at the end of the day all of these implementations share the same state

which is the proxy right so the question here the hard question here is actually how can we prevent buggy implementations from leaving the share state in an inconsistent condition for other implementations any buggy implementation ation could be just a bug introduced by a developer for example or even a malicious actor introducing some back door to the new implementation. Right? So this could potentially lead to a very inconsistent inconsistent state that other implementations while being benign could run on a very bad state and could suffer from it. So the approach that we decided on is actually to scope each contract function

to a well- definfined storage region. So we can have the storage isolation to limit the impact of the bugs. So we can ensure that the state corruption is contained and does not compromise the unrelated logic. So we can thereby maintain the partial system functionality even if we have failure scenarios. So for example, we can't scope that the function f1 is working and only modifies the storage slot one.

So even if a malicious implementation tries to make any change to other storage, we can restrict that and invalidate that transaction. So the F2 code can keep working even if we have already except some malicious implementations or buggy implementations because the storage slot is different. So we create a frameworks for anyone who wants to try to implement this concept to follow. And what we suggest currently is to for each external function of your contract try to identify which variables can be modified and the ones that must

remain unchanged. So for each function that you allow any user to call in your proxy and your implementation, you try to define the invariance of each function and then you try to have a snapshot of these initable variables. So the ones that they should not touch during the execution of this function. So having this snapshot, we want it in memory. This is crucial because when you are delegate calling between contracts, you actually share the storage but you don't share the memory. So the malicious implementation or the buggy implementation does not have access to the memory in your proxy for example. So after this you allow the uh delegate

call to execute and once it finish you will get a new snapshot of the variables that you defined in step one. At the end of this, you want to compare these two snapshots. If they match, great. It means that this scoping remains the same. But if they don't match, you want to revert this transaction because it might lead to some inconsistency that you don't want. So this is the overall framework that we uh recommend anyone who tries to implement this ERC to follow. And of course, this framework comes with a tradeoff. By following this ERC, we're telling developers and users to actually put more computation on each contract. We will have to create a

snapshot and we have to compare these snapshots. So this will have to consume more gas for each code to our implementation. So for our future work, we actually want to explore and evaluate different implementations of our proposed framework and later on we want to conduct gas consumption benchmarks and finally we want to identify and implement gas efficiency optimization. So at the end of this review process, we want to have a report so everyone who wants to adopt this ERC has an informed decision whether they want to adopt it or not. What are the tradeoffs? What are the good things and the bad things that

the community can be aware of? So this concludes our presentation and our introduction of our ERC. We want to bring the best of web two versioning to web 3 and we want to enable selected versioned delegate calls and we want to improve backward compatibility and upgrade flexibility. Thanks so much for having giving us this opportunity to talk more and discuss about the CRC. >> Thank you so much for this presentation. It is really an interesting proposal. I know this EIP talks about a lot of thing. It talks about addressing multiple problems, providing flexible selections options to users and also

enhance backward compatibility. We would be talking about the improvement that it might bring to future users. I have a handful of questions and I would like to get into it one by one in order to understand this even better. In the beginning of the conversation you mentioned about different proposal UUPS upgrade uh standard which is already existing proxy storage and diamond standard just trying to understand from the point of view of this proposal you don't find them anywhere in the required sections you are just trying to address the problem that were identified in these of standards and help provide a solution is that a correct understanding

>> so it is not a require environment. So if you don't use any of those ERC's, you can still adopt this one. And if you're also already using that ERC, you can still try to adopt our ERC. So it can be compatible with them according to each developer's needs, but it is not a hard requirement. If you don't have that type of upgradability, it doesn't mean that you cannot use this new type of upgradability. >> That makes a lot of sense. We talked about for post adoption like when there is any upgrade uh and everybody is forced to implement obviously this proposal provides us that flexibility whether we want to go ahead with that or

not with buggy updates you mentioned about state correction stored and storage slot but I'm a little curious to understand here how would one know that this is a buggy implementation if we know obviously we would not choose that but without implementation how someone will get to know that we should not go for the new updated one, we should continue going ahead with the previous one. So here it's a very known problem in web two as well that you know you depend on on let's say react 3.5 and and then somebody says you should use the latest version and what is done in web two is that you should wait a little bit you should wait for some other users to to use the new version before switching

yourself and if you are super careful you know a big enterprise you might wait a bit longer to have really guarantees that it's working reasonably well and so here it's a bit the same so you You know early adopters the gen users might directly go to the new new versions but more careful users might wait for having you know couple of days a couple of blocks a couple of transactions uh and they would decide how much you know how many how many days how many transactions they want to like but if they you know they wait for thousand other users to do transactions to the to migrate to the new version and everything is fine then they wouldn't migrate what's for sure is that the developers themselves the new implementation everybody makes mistake and they might push a big game in the

relation. This happens regularly, >> right? So not only you just have to be a smart contract developer, you also have to be a smart uh implementer. Wait for some time, make sure it is all good and then go ahead and implement that. I guess it was in the presentation someone comes up with more implementation of these proposal. I wish someone one day comes up with this kind of implementation where there is a test scenario available before it goes into implementation. So this proposal provides option which is very good. It helps with some kind of protection against bad updates for security consideration. Are there anything new or any tradeoff that any team or project may have to do if they

want to adopt this standard? >> So this is a very good point and what Malik has presented was really to to the point. So this proposal completely solves the problem of breaking updates but it solves partially the security aspects depending on what you are able to protect. So this was the last side of the presentation that if you are able to completely specify the state which must be protected for a given implementation then then this proposal gives you security guarantee. If we you know some many smart contracts they might use you know very lots of mappings where we don't really know which part of the memory will be impacted and then it might become harder to to protect again a very malicious user who knows exactly what they want to change and the and the

part of the state they to corrupt. So it doesn't completely solve the fundamental problem of delegate codes. dedicate codes is something it's known in the in the industry that you know this is something very powerful but also very dangerous and it's much better than the previous proxy patterns the previous ERC's but uh but yeah there are there are some very advanced attacks that can still go through >> yeah we we like to think that this proposal is narrowing down the attack surface of delegate calls but it comes with a trade-off with all of these invariant checks that we're doing. We do consume more gas. That's why we want to work in multiple different

implementations to properly benchmark what are the gas consumptions so we can publish this to the public and they can make an informed decision on whether they want to have a secure contract, a more secure contract or whether they want to risk it and use less gas. So I think it is still under the wish list that uh we need to come up with benchmarking about gas consumption and gas efficiency. It is not there yet. Is that a correct understanding?

>> Yes, for different implementations we have a couple of naive implementations but of course the scope of each smart contract currently is so big and we can only start with ERC20 for example. some contracts that are popular and start benchmarking those. But there are so many diverse smart contracts at the moment that we want to be thorough and include all of this diversity in our benchmark too. >> All right. From my experience of looking into ERC's that comes into the process of standardization. I'm just sharing this. I may be completely wrong and editors may find it very different. But in the security consideration section, I do not see any mention of this

benchmarking. As you mentioned that every contract may have different implementation, different parameters and you cannot go for benchmarking for all but from my perspective it would be a good idea to give them a hint of like this is something that people should consider would be nice addition but my worry is if you mention that then the editor might want to have the benchmarking done before they move the proposal to the finalized status. So it's a call for authors. How do you guys want to proceed in this uh proposal? But I feel it is a good piece of information that every implementer might use before choosing to implement this EIP in the project. Well, moving ahead, you did

mention that there are small implementation and maybe for those small implementation you could have the benchmarking done. So I'm curious is there a proof of concept or reference implementation already ready that people can refer to maybe we can add the link in fellowship of Ethereum magician or somewhere. >> So yes we have a proof of concept implementation well tested it which is in our repo we are happy to share the link and we are happy to take contributions external contributions on this proof of concept implementation. Yeah, I think that would be helpful because this is one of the requirements that has been added recently though it has not been formalized yet but we want that if a proposal is in the repository to become a standard there has to be

some implementation. So even if it is reference implementation or PC ready it's a good idea to share let's see if it is a viable proposal it is a viable standard. >> Fully agree we love proof of concepts and reference implementations. Yeah, very well. Looking ahead, how do you see this standard influencing enterprise adoption of a Ethereum smart contract? I'm asking this because I understand this provides a lot of flexibility and all the standards that you mentioned in the beginning of this conversation are very well uh received by the community.

>> So I would say this ERC is very enterprise. You know, versioning is very enterprise. This ERC is very enterprise. So to some extent this CRC really contribute to making uh yeah onchain development more mature with you know with the sound software engineering principles and we actually expect uh you know the first users and implementers to be more on the enterprise side matur established web three protocols. We expect them to be the first users more than the gent going for new new fancy contracts directly. The core of the CRC is an enterprise mindset of stability and security.

>> Yeah. And also like uh large scale adoption or enterprise adoption. They care about the compliance or like the uh security part. Actually this can provide more transparent and more aggregated information for all the enterprise who want to do the complence and uh for example they can easily build like dashboard for like which version we are using or like uh what is this uh GitHub source codes can be reproduced from the contract itself. So we would say that it's very helpful for all the like

enterprise adoptions. >> I mean I can definitely see some operational benefits of this proposal which will help bigger projects to keep working uninterrupted in case of any maybe Malaysia's upgrade had upgrade or by mistake upgrade it it can still continue working in that direction. I'm assuming that you are not aware of any project already implementing this proposal. That's perfectly all right. But uh this is also very much recommended to all ERC authors that get in touch with people to get this proposal implemented. I really loved your idea that you would want it to be adopted by enterprise rather than getting into a simple project because

that would like have more visibility of uh this uh proposal. We would love that but we would encourage authors to like talk more about it. We'll come up with different platforms where we can share about this proposal and perhaps that would help you. Well, I see this proposal is in early stage of standardization. It is still in the review status. How comfortable are you guys with this packs? How long would you want it to wait before we can move it to next step which is called last call and eventually to the final status? I think we we are not far away from going to last call. Uh so we are polishing the last security aspect. We will add the link to the reference implementation. We waited for some bit to get feedback on

ether magicians. So yeah we are confident the compos is good. We received lots of very good feedback from from the committee when we talk about that it's really novel. It really contributes to some something new which is important. So yeah, we are now polishing the the last parts before going to last call and then final status. >> That is very good to know and please feel free to reach out to editors in office hour in case of any help and support needed to move this proposal forward. Well, thank you so much. This was really interesting. So I think we are coming towards the end of this conversation.

Any message, any call to action that you would like to share with the community? I think one call to action would be if anyone has suggestions, if anyone has an idea of an implementation, just send us an email or send us a message and we'll review it. We love software diversity. We want to have as many different implementations as possible because this is what makes software reliable too >> and this is the world of open-source. So, we would love to have any kind of contribution. Thank you so much for the message. Perhaps people can reach out to you on fellowship of Ethereum magician and leave a comment with their ideas or thoughts and they can be connected.

>> Thank you very much. We we're very happy to be here today. Thank you very much for hosting us. >> Thank you everyone for joining us on Penney. We hope to see this proposal moving forward to last call and eventually to the final status. All the very best from our side. Please reach out to us for any support during the transition of these statuses. We do organize EIP editing office hour that is there on Tuesdays at 1600 UTC. We would be more than happy to help you around. Dear listeners, thank you for tuning in.

If you like the episode, please share with like-minded people. Check out our description section to get more information and related resources. How do you like Penney series? Let us know via comment below or you can also email it to us at team eatcat herurders.com. We would love to hear from you and if you have got any suggestions around which EIP we should bring it to the podcast again. We would love to hear any kind of feedback from your end. This is the last episode for year 2025. So happy holidays and we will see you around in 2026. Cheers everyone.