Proxy Contracts on Ethereum

Conor Svensson: Okay, let's get this session going. For those people who join later, they can catch up and we'll also put it out on podcast. Anyway, okay, so just to kick things off, Andrii, if you can start by telling us a little bit about who you are and what you do.

Andrii: Yeah. Thank you, Conor. So my name is Andrii. I am a blockchain developer. For the last four or five years, I have been working in the blockchain field. It was an interesting experience. Before it I was working with Java but right now I'm working with different multiple languages.

Conor Svensson: And so what is it that you're working on right now?

Andrii: So right now I'm working on the block explorer project, it's called Chainlens. We are working on building a system to make it possible for ordinary people who are not involved too deeply in blockchain science and technologies to understand what's going on inside the blockchain. We try to simplify the processes, the information, that goes on inside the blockchain and try to show it in a simple way for people.

Conor Svensson: And so one of the things that you've been working on recently, and this is going to be the subject of the session now, is proxy contracts. And so let's start by talking about what a proxy contract is and why you need them. And they're probably best to start from a non technical perspective and we can build from there on this topic.

Andrii: Yeah, sure. So the recent feature that we were working on was recognising of proxy contracts. We will talk about some details a bit later. So during this implementation, we got to deeply understand a lot of differences, and small details of different contract types, how it's working, how it's recognised. And it turned out that everything is not as simple as it seems, at first glance. So we can start by talking about what is a smart contract. What is a proxy contract? So proxy contract is a smart contract written in Solidity language for EVM family networks. And this contract delegates all or most of all function calls to another contract. This other contract, calls, contract implementation, or contract logic. So the proxy itself contains a minimal logic. This logic is mostly related just to delegate and proxy calls to the contract implementation. So what is a proxy contract? I would say that a proxy contract right now, is widely used almost everywhere because it gives a lot of advantages for contract developers. So let's talk a bit about the advantages that a proxy contract can give. So the first one is upgradability. Once a smart contract is deployed, on the Ethereum network, this code is immutable and cannot be changed, that's why developers invent a way to upgrade contracts. And the solution was a proxy contract.

Conor Svensson: So from the point of view of end users, if they need to, if they don't have an upgradeable contract, this means that the address of a contract needs to change each time they upgrade it, which is bad for users.

Andrii: Yeah, the issues, we all know that it often happens that there are some bugs, or issues that need to be fixed in the contract. If you add some new features you need to redeploy or update a contract, and basic solidity functionality doesn't support such things. That's why if you want to support your contract or update your contract or be able to change a contract in some way, you should use a proxy contract, a kind of contract intermediate between actual contract logic and the end user. So the proxy contract solves this problem of immutability of data inside the EVM field.

Conor Svensson: Okay, cool. And so then you mentioned that that's one of the advantages. What are some of the other ones?

Andrii: Yeah, just to add a few things. So when you use a proxy contract, you can update your contract without losing your state. So it required some additional effort because you should separate state from the contract state and contract logic. But using a proxy contract it's possible to make it possible to replace only logic. But you will use the same state of the contract. So that’s the first important advantage, why people use proxy contracts. So the second one is gas efficiency. We all know that to deploy anything or to make any action in the mainnet is usually quite expensive. That's why you always should think about how much data you want to deploy. And that's why proxy also can help in this case. And in this case, developers can split a contract implementation into separate parts, or pieces. For example, some of the contract doesn't need changes, for example, it's a contract state that we talked about before. Some of the contract, you suppose that required some change. And that's why you can gradually update your smart contract, depending on your needs, without deploying the same data and same bytecode, several times. So in this case, you save gas, money, on the contract deploying process.

Conor Svensson: Okay, so there's actual savings there as well. And so in terms of Ethereum, there's a number of different proxy approaches to proxy contracts, too. Are you able just to talk about some of the different ones and what the differences are between them?

Andrii: Yeah, we can discuss it a bit later. I can finish talking about the general advantages of a proxy contract. So if you don't have questions about gas efficiency, you can go to the next point. So the next advantage is better security. So we know that from time to time, we hear about some contracts' vulnerability. And there is a chance that when you develop your contract and use some third party dependencies or third party libraries, this library will have some vulnerability in the future. And that's why you should have an option or ability, to replace your implementation, and it's another reason why you need to keep an ability to replace or update your contract, because you'll never know if any libraries will have a vulnerability in the future that you use. Unfortunately, recently there have been more and more cases of fraud that are based on using a proxy contract. So the fraud is that the attacker has the ability to replace the implementation of the contract with another one, with some vulnerability, for example. So that's why in some areas, using proxy contracts is considered a red flag, unfortunately. And the last advantage is modularity. so we have talked a bit about it in previous points. But let's summarize everything. So if you use some of the proxy contracts that allow you to use not only one contract, you can use a different number of contracts and you can combine your business logic with different pieces and different smart contracts. For example, provide ERC-2535. It called daemon standard. It's quite new solution of proxy contracts. I haven't seen too many implementations of this standard. This standard allows developers to work or to mention a different number of smart contracts and make some relationship between all of these contracts. So that’s all I want to tell you about the advantages of using proxy contracts and reasons.

Conor Svensson: So we have a number of different benefits associated with them. So I think you mentioned upgradeability, you mentioned gas cost reductions as well. You've mentioned security and then also modularity. And so then if we talk about the different types of proxy contracts, from what I understand is that there's like three or four different proxy contract standards in Ethereum. If you could give a quick summary of each of those and maybe talk about some of the benefits of why you might choose to go with certain ones over the others, that would be awesome.

Andrii: Yeah, of course. So there are five different standards of proxy contracts that are widely used. I would say that during the last two years, there has been a kind of  evolution of proxy contracts. So the first proxy contract was 1167, it's a minimal proxy contract, with minimal functionality. It provides a way to create minimal proxy contracts, which are highly gas efficient and delegate. And this proxy just delegates all logic to the master implementation contract. And the next standard is ERC 1822, named universal upgradable proxy standard. It has a bit more functionality, this additional functionality mostly related to the way of upgrading a proxy implementation contract. It provides more flexibility, but at the same time you should more carefully manage such contracts because at the same time it can be vulnerable. The next generation of smart contracts is the ERC 1967 Ethereum proxy standard. This contract, this standard upgrade, improves the security of using proxy contracts. They add a standard storage slot for saving proxy implementation and admin address. Because in some previous versions it was vulnerable to replace a proxy contract admin and proxy contract implementation. So this solution fixed this possibility and is safer than previous standards. And the last one is ERC 9565, diamond standard. We talked a bit about the standard of this contract. So it's kind of a new generation of proxy contracts that provide tools to work with multiple contract implementations and build relationships between these contracts, contract implementations. So if I summarize all different types, I would say that there are two kinds of two smart contracts. It's erc 1967, that it was highly improved since first proxy implementations and have flexible ways of managing proxy implementations, and second one is daemon standardization. I would say it's kind of a new generation and a new way of working with proxy contracts when you have multiple proxy contracts. In these cases I would use logic for a different business logic. I would say that if you need, if you have a simple contract without complex logic, and you have for example one solidity contract with logic and you plan to upgrade or update only one contract. So ERC 9067 is definitely a good choice. But if you have something more difficult, with a lot of logic and functionality and a lot of smart contracts, I think it definitely makes sense to try to use a new smart contract, diamond standard, ERC 9565.

Conor Svensson: Okay, cool. So just to recap that of the different proxy standards that are out there, the ethereum proxy standard for ERC 1967 is the most simple one to get going. If you have a relatively straightforward use case and there's not lots of modularity with the contract or business logic or, you know, the different logic around different contracts, and then if you have something that's a bit more advanced or maybe you're more seasoned developer who has more complex set of contracts that they're working with, then ERC 2535, the diamond standard is the way to go there because it's been designed for much more, modular contracts in that regard.

Andrii: Yes.

Conor Svensson: Okay, awesome. And so then within Chainlens Blockchain Explorer, we've obviously been doing some work as well with proxy contracts. how is it that chainlens then supports proxy contracts and makes it easier for users to see exactly how they're being used in different applications.

Andrii: So the biggest challenge for us was to recognise smart contracts of not a verified contract because as you know if a contract is not verified you don't have any information about this contract except contract bytecode. So we don't know the contract type. We don't know almost anything. And that's why to recognise what type of the proxy contract it is. We were working with a contract bytecode. and the most interesting part was to recognise the type of contract. And to do it we learn a proxy contract standard details because each proxy contract standard is unique. So it has its own code, its own implementation and it is almost fully different from another one. And that's why to define smart contracts we should know some details about this standard. So we found a way that some of the contracts use for example, a static storage slot, for storing contact implementation and admin address. So that's why we try to find this information inside the contract bytecode. and if we find this if we find this address, it means that this contract has this type and other contracts use some unique pattern of EVM commands. And now that we try to find some parts of this byte pattern inside bytecode. It was a way how we implement recognising of different smart contracts. And so now we have different implementations for each of the proxy contracts that can recognise a particular smart contract bytecode.

Conor Svensson: So from the perspective of users and Chainlens what it means is that they can for unverified contracts, that is contracts which have not been verified with a service like Sourcify. Then if they're using a proxy contract we can still pick up information that it is a proxy contract and expose this to the user so that the users can then see which proxy contract standards the specific contracts implement and that they are labeled as proxies.

Andrii: Yeah, even more we provide more information. So the end user will know not only a type of contract, but we will also provide the standard functionality of this contract that makes it possible to interact with this smart contract, and even know that this contract is not verified. Our user will have the ability to communicate and to call some functionality of this smart contract. We also provide additional information about contract implementation. We have implemented a functionality to get this information from the not verified smart contract and provide it to the user.

Conor Svensson: So this is awesome to sort of get into those details on that, Andrii. We're at time now for the session, but if people want to learn more about proxy contracts, what's the best way in which they can do that?

Andrii: So I would recommend starting from the official solidity documentations, to read about ERC contracts, ERC standards of these proxy contracts. There are about five contracts that are widely used right now. And people can read a standard about each of them.

Conor Svensson: Awesome. All right. Well yeah, thank you, Andrii. It's been super helpful to do this deep dive on proxy contracts and hopefully people have lots of takeaways from it. But yeah, we'll wrap up there and thanks again for your time on this.

Andrii: Yeah, thank you.