Ethereum Foundation DevCon 6 - Developer Infrastructure Track, 13 Oct 2022

Previous Meeting Next Meeting

⏯

youtube image

►

From YouTube: Unlimited Size Contracts Using Solidity by Igor Yalovoy | Devcon Bogotá

Description

Visit the https://archive.devcon.org/ to gain access to the entire library of Devcon talks with the ease of filtering, playlists, personalized suggestions, decentralized access on Swarm, IPFS and more.
https://archive.devcon.org/archive/watch/6/unlimited-size-contracts-using-solidity/

Ethereum currently have a limit of 24KB for a contract size which cause a major pain for many Solidity devs. I would present all available options to address this issue using Solidity language during the workshop and provide cons and pros of them.
* External libs
* Transparent and uups proxies
* EIP-2535
* Static precompiled router proxy
* Dynamic router
I will also provide gas optimization tricks for above methods and a novel method to reduce a gas cost for unlimited size contracts.

Speaker(s): Igor Yalovoy
Track: Developer Infrastructure
Keywords: Solidigy,dev tools,smart contracts

Follow us: https://twitter.com/efdevcon, https://twitter.com/ethereum
Learn more about devcon: https://www.devcon.org/
Learn more about ethereum: https://ethereum.org/

Devcon is the Ethereum conference for developers, researchers, thinkers, and makers.
Devcon 6 was held in Bogotá, Colombia on Oct 11 - 14, 2022.
Devcon is organized and presented by the Ethereum Foundation, with the support of our sponsors. To find out more, please visit https://ethereum.foundation/

A

A

Everyone, my name, is igorio boy, I'm, a strategic developer, a CEO founder and previously I worked at open, Zeppelin and co-founded. A D5 startup called Baby on finance. Today, I'm excited to present you a workshop titled unlimited size contracts.

A

Before we jump in the action you might want to download a GitHub repo for this Workshop either use the QR code or just Google GitHub. While we Dash IO workshop and you'll get it. We also will need a Foundry for this Workshop. If you have it great, if you don't have it just install it using the link in this slide and then run two commands Foundry up and Forge build.

A

uh I know. Internet is pretty bad here and so for some reason you can't download it and install it. Don't worry, uh the repository will stay up and you have access to it and I'll pause. The slides tomorrow and I'll be doing some live demos, so you can just watch and get the idea what's going on, let's jump right into it all right who has ever deployed here and written a smart contract. Please raise your hand, yes, I needed the developers.

A

Okay, who has ever run into the issue of a contract size limit here, please raise your hands wow. It's way more problem than effort, so yeah this picture. It illustrates my personal pain and why I work in baby on finance. We pretty quickly ran at the issue of a contract size limit and it's not easy issue to address and it causes us a lot of pain and one file developer. I know in a series space code with limitation.

A

I quote bane of my existence, so this is how big this problem is, and we are going to talk about today. So there is a few solutions for this. Well, you can reduce byte code size using various techniques, and essentially it's like alternative sport to guess, golfing I called it byte code. Golfing I certainly do not recommend it, because it's like a diminishing return. Sport with each optimization.

A

You have like less and less space left for each new function and it even May compromise the security of your project, so I would be wary of using this technique and I suggest to try to design the architecture from Day Zero in the way it supports your contracts to be unlimited size. Other Solutions are external libraries, static, pre-compiled, router and a dynamic rotor. We will cover them in this workshop and hopefully have some time for questions and discussions all right. We're gonna use a simple contract as a baseline contract for this Workshop.

A

It's called a counter. It has a few functions, a set function which sets a invariable to a new value, a get functions which reduce this variable and finally, a const functions which just adjusts the constant. These are good functions for a baseline contract because they essentially utilize one as load, operation, One, S, store operation and returning the constant value, and these examples are quite um well spread in real smart contracts.

A

All right, um let's jump into the code uh here, we have um our counter contract again, I'm, not going to spend any time on this. It's a pretty basic. What is important about it? It's rather small! So if we look at it byte code size, you can see it's under one kilobyte, which is great, and we have a lot of space left.

A

But let's say a product team says: oh actually, we need to implement this new core feature called quote function. The core function is a function which returns just like big string, which takes all the space and then, if you look at this big modeler, it like takes almost all the space in the contract with a few left and if we try to implement it in very new way, using solution inheritance. So we just okay for our counter.

A

The big modeler like done job done, and then we discovered that no the counters over the size of the limit we can't deploy it, which nothing can be done. It can be optimized so how we can solve it. The first solution is external libraries.

A

External libraries is a is a feature of a solidity, so how it works is that in your contract, in your methods, you just call a library instead of implementing it in the contract. In this case, we have a two libraries. One is called storage lib, which contains our original counter methods such as set get const.

A

And finally, we have a quote Loop, which contains the only quote method which contains this big string, and if you look at the implementation details, the catch here is that you need to pass this parameter, which is canonically called self and has a storage type, and this like a special syntax in solidity, allows you to modify storage in external contract and essentially external libraries.

A

Stability is just abstraction layer over delegate code and that's basically it there is not much to this, and if we go back to our presentation, uh we can quickly sum up all the ups and downs, this approach, so the good part about it. It comes with some security guarantees by solidity. The main important one is the library can't call self-destruct. So a library can't destroy your smart contract, which is important because it's not the case if you use diligate code directly, essentially proxies where, if a proxy contract calls so distract your contract is done.

A

It's somewhat easy to add one more leap. You can always introduce one molip and it's gas efficient to a degree, but a bit later on this and the main down downside. So this is it it's not truly infinite, because if we Define to add one more function, you need like external wrapper function, which stack up quite quickly and eventually you run out of space in your surface contract and it doesn't matter how many ellipse you can write.

A

More will be just normal space and the final downside, maybe for some projects external libraries can be used, can support upgradable contracts. So once you deploy your external libraries, it's like set in stone and you can't change it. Okay. The next approach is a static, pre-compiled rotor.

A

This work was pioneered by Alejandro Santander from synthetics. He also previously worked at open Zeppelin and he is known as if you're not on Twitter, and if you look at like, if you want to take a look at production, ready like stable code, I suggest you check out hard hat router package at the synthetics repo and what they are going to take a look at the simplified example.

A

So so the idea um for the static router is pretty simple: uh it's a smart contract which has no fun no external functions, and it only has a fallback and receive functions and what it does. It goes. A forward function inside both of them and the forward function consists of two parts: the lookup part for the implementation address and the assembly part for delete.

A

Jade call I'm not going to spend time on this I'm just going to say this is like a canonic implementation of a proxy, a jade call in assembly which is used by all the proxies and what it does.

A

It basically sends your function code to whatever the implementation contract is and then returns its results, and the interesting part is here so uh in solidity, each function has a signature and, as you can see here, we have a switch for a signature method and based on the signature of code function, we pick up an implementation address which is later used for dedicate call and, as you can see here, we have a four functions registered for a counter modular, which is a get set.

A

Const and one function registered for a quote modular, because it's like so big and based on a function signature. We do pick up a right implementation address and then use it for delegate call and again, if you go to our contract sizes, why it works, because these are three separate contracts. We have a big modular which is within the limits.

A

Then we have um counter modulator, which is also wind limits and finally static. Router itself is pretty small because it just with one function, though the more functions you have, the more it's bite-sized grows, because you have to add each function here as a new line, though it grows way less than external libraries example.

A

And if we go back to slides, we can see what are the benefits of using it. It's extremely gas efficient. Why? Because it's all pre-compiled in byte code, so you don't need to waste any expensive operations as load on the router itself. Your function call goes to the router and then immediately calls delegate calls. So you must guess: overhead comes from Julie Jade call, which is about 2600 gas. It's almost infinite.

A

It will take really a lot of functions before you run out of space in this router in terms of adding with a constant signatures and contract sizes. It doesn't require external functions. Well, the downsides um pretty expected, because it's essentially a proxy you can't use a Constructors. You have to use initialize methods and cross modular calls can be tricky and you have to use explicit storage slots. So you don't. um Your different model is going to write to the same storage and then finally develop and maintain.

A

So your head can be tricky because you need to pre-compute always signatures and addresses up front, and you don't want to do it by hand which is I, recommend check out again have hot router. They built a plugin which does that for you. Well this, like a second approach, how you can achieve infinite size and compare to libraries, it's like better in the way which gives you like more control, using like assembly and low level language features.

A

The next idea is a duration on a static router. It's not necessarily better. It is a different approach. It depends on your project, I call it Dynamic router.

A

If you're interested in a product level better tested implementation of this idea, I highly recommend you to check out EAP 2535 by Nick, March vcp is covers far more things than just unlimited contract size, but one thing it certainly does achieve is unlimited contract size through a dynamic, router I've written a simplified example of this Dynamic router. So, let's get to it, so we can see how it works.

A

um It's quite similar to a static router. In the same way, it has a fallback receive functions which just forward every function Call to um to our forward function, but the difference comes in this line. If, in a static user function, we have a switch case which just goes or have this for VC, which I have this address in the dynamic router, we are using a smart contract storage mapping which is called modulus and using his as you can see here.

A

We pick up an implementation address using a message, signature and then the rest of limitations functioning the same. We just provide with implementation to the legit call and essentially it works in the same way. The essential difference between static growth and dynamic is the static. Router has all these signatures and all the implementations and races hardcoded in its byte code, where Dynamic router use uh mapping on the storage of a smart contract to track them, and that adds pluses and minuses to this approach.

A

So the pluses is once you deploy your Dynamic router, you can add more modulus, even it's already deployed, or you can like fix bugs by updating it here. Have this function, update, modulus and it's also pretty uh straightforward. As you can see, we just iterate and add selectors to implementations.

A

The downside of this approach is you have to manage access rights? You you can't allow anyone to update functions of your router. That would be disasters, a critical issue in security terms, and there are different ways to use it.

A

You can use open, Zeppelin access roles or some like other techniques, but that's like out of the scope of this Workshop, but you just have to keep this in mind and if we go back to presentation, Dynamic router is the first router which is truly infinite, because all the mappings between uh function, signatures and implementations are inside the storage, which is, as we all know, very big in solidity. Then you can literally add infinite amount of functions to this router.

A

So it's very good for a complex system which would require upgrades and have like long expected lifetime. Then another option, another plus I just mentioned it can be updated anytime.

A

Well, I mean it can be a minus if you're getting hacked, but generally it's a plus has no external functions, so the main downside or with is it I guess expensive, with function is essentially here is a regular storage which is extra s load, which is about 2000 gas and the set part you have to pay it for every contract call and then another downside is you have to manage access rights who can update this router?

A

If you want to build a truly Unstoppable contract, maybe you don't want to have any upgrades and them can be many solutions like governments and multi-seek, but you eventually have to figure it out for yourself.

A

These are the three main approaches uh which you can use to tackle uh infinite size contracts and then, what's like important: what's the difference between infinite size contracts and normal contact using this approach, it comes down to a gas overheads.

A

Essentially, here in this table, we are campaigning our base contract with with three approaches in terms of gas, and why I guess it's important uh like a short story?

A

When was like a bull run and gas prices were high, we were seeing the the function, calls for the users in the price ranges of 100 dollars, twenty two hundred dollars and even 300 for some projects and a lot of these gas costs were coming from using proxies because proxies has a gas overhead at each function call and if you really have a complex, defy system where protocols call each other and they all have.

A

There are all proxies with amount of overhead Stacks pretty heavily even within your own protocol, and it's like important to keep an eye on this gas overhead course. So, let's dig down a bit in these numbers. The first base contract are the numbers for our base course. So it's like no delete code involved and then, if you look at that, the base call for a constant call. It just returns a number.

A

It's a very small and the first number in red is just what's the overhead and guess, and the second number in red is in percentage and you can see for like a simple return call of a constant value. The overhead is actually around two thousand percent, which is like insane, and you may say: oh, it's not practical. You know to return the constant value, but you'll be far from the truth, because the famous uc20 token has a member a function called decimals, which returns how many they came.

A

Also talking has- and you have to call this function if you define developer because in order to handle ec20 token, you have to know how many decimals this token have and one of the most common uh uc20 tokens like usdc their approxy contracts. So every time you call decimals you overpain, roughly two thousand percent or probably more but anyway, let's take a high level. Look at this approaches so, as you can see indeed, static. Router is the most gas efficient approach.

A

So if you have to build a gas efficient, infinite contract- and you are- and you know what kind of functions you're going to have and don't plan to upgrade- then it's like a great solution and then Dynamic router is make more expensive even more expensive than external Library.

A

um The reason I wouldn't recommend external Library. As you can see, it has unusually high overhead, for quote more than double than it should and I think it has something to do with how solidity pass with like big amounts of data, but I haven't dipped the byte code yet, but just be wary. If using external libraries and you pass or return big amounts of data, then your gas expenses may surprise you and to take a look at this. uh What would be the high level uh conclusions of this overview?

A

Is that uh your gas overhead obviously is more significant for uh low functions which are low in gas. Essentially, if your function has only a single s load, then you would pay a lot of gas.

A

So what it means in Practical terms, which I also encountered is that if you need to build a function, you should learn some like data around your protocol, smart contract, you may want to park them all this data in one function call so you don't need to call five functions in a row because you would pay a gas overheard on each call. Essentially, batching view functions might be a good idea.

A

Then again, the bigger the Baseline gas cost for your function, the less you care about it. So let's say you have a function which is quite expensive, let's say 300K, then suddenly, five, five key overhead doesn't look that bad um though there is a catch to this in many protocols, not all functions are equal.

A

Essentially, if you look at like typical vote functions such as deposit or withdrawal, which are mostly called by the user, so you won't achieve uh the maximum gas efficiency on these functions and some like admin functions which are rarely called you may want. You know to skip optimizing yes for them and um because the guess is so important. I spent some time thinking and trying to figure out a trick. How we can improve this and I came up with solution which we use successfully in production to reduce the gas cost of our contracts.

A

We never found anyone using it um somewhere on the Internet or on GitHub, which is why um I had to coin the term for this approach, so I'm going I'm, calling it like loaded router, and so the approach is pretty simple because like if you go back to a static, router, so static router. In our case um it doesn't take much space and even it grows. There's still a lot of space left and what you can do essentially is again using solution inheritance.

A

You can inherit some functions of your contract to a static router uh which allows them to be as guest efficient as the contract itself, because it's essentially a contract itself. So, in the other ways, every some space in terms of byte code size left in your static router.

A

You can put the functions there, which either people use the most in your system or the functions which has the highest gas overhead like calling decimals, and this allows you to save quite a bit of gas because um just to give better explanation of this, uh if you combine static router with a counter modular, we don't get to this forward function because static router.

A

Now is counter modular and that results in a quite significant gas savings and the same approach can be applied to Dynamic router I'm, just gonna show you the call, but it's a pretty uh straightforward. You again can hit counter model, but here this is the cache with a dynamic router, because in Dynamic router we can update implementations of a function. If you place a function like get a set on the router itself, you will never be able to update it.

A

So that is why it's like rather risky- and you should be very mindful- which functions you put on Dynamic router, because you don't want to be in a situation where a critical bug is found in the function and you can't update it and it's just like a terrible situation to be in and with this approach we can crunch some guess numbers so now here we're using routers themselves as a Baseline and then the loaded version, essentially as Improvement and as you would expect, because we move a constant function from sitting behind the delegate call back on the router.

A

It results either to 95 Improvement or 97 Improvement for a constant function. It results around 54 or 68 Improvement for a get function, which is a single s load. A singular slow function is not that uncommon, as you might think, because, for example, you see, 20 balance of function is just a single s load and again this function is called a lot and I. Don't really expect it to be changed and then, finally, for a single s store operations, uh the savings amount is about 11 or 18.

A

So it's like not that much, but like still um sizeable and what you could you like looking at these numbers, my suggestion would be is to move a logous function on the router if they use a lot. So this is the most best saving or just the functions you expect uh user Fade to be user facing so the in the functions. People will use the most again as a transfer function, the deposit of withdrawal or claim reward, and then finally the pure functions.

A

You just adjust the constant Health the biggest impact on this uh and just gives you some practical meaning. Let's look take a look at the two. Most common uh contracts is essentially C20 token and lc721, which is an nft foreign.

A

We can see surprisingly many functions of pc20 function, 20 token, the station's name and symbol in decimals. In most implementations they really return. A constant you know, just like name is like my great tokens involved with like three letters, and they came out with like 18 number right and in most projects really with functions, will never change and virtually.

A

If you write in UC 20 token, which has decimal functions which will return different values, I might have a problem with you, please let me know, and um even going back even on later so total Supply many AC 20 tokens has a fixed, total Supply right. So with again, no reason for this function to be upgradable or to ECB sitting behind the daily rate call, um and then things get tricky, so I can see how transfer allowance or proof can be changed in the future. Maybe standards change, but it's like up to every developer.

A

You have to make call on yourself whenever your project uh View encounter these issues in the future or not and um the same logic more or less applies to ec721, but these are just two common contracts.

A

I really want you to show on them kind of logic: I would fall if I would do a complex system where I would just sit down and look at my contracts and look at which methods are uh not going to change for sure and visual X save to put on the router itself to save the gas and which makes the most sense because, for example, with baby on finance, we had this like admin model which had like a lot of admin functions, but it's pretty much only us or governance we're calling them.

A

So we really didn't care about the gas gas cost of it. So I was a confident just like putting them behind the digit call and being upgradable, and let's, let's uh jump back to the code. So here you would see once we put these functions on our routers, they do grow in size. So a loaded, static, router is slightly bigger than just a static router.

A

That's because we merged all these functions on this contract, and eventually you hit the size of how many functions you can put on your router, which we did, and that is why you also should be like mindful that you have to put the functions on the router which, like your absolute top priority in terms of gas. So if it's like questionable, don't do it and the same applies to Dynamic router, so it's higher, but to repeat uh secure my security. You can see on concern once again.

A

um Dynamic router is different from static router. In that sense that, if you put a function on router itself, then it can be upgraded later and you should be like super careful doing this. The code, uh the repo is already public, and it has all these examples, as well as the test which I just made, which actually makes sure that all we discussed is worked. So here you can see that creating static. Routers is simple because it has everything encoded in it while to create a dynamic router.

A

We need to build all these modules, so we need to dynamically fetch all the selectors for the methods and then we create a model definition, which is an array of selectors, bind it to a certain implementation. And, finally, we can use with modulus to initialize our Dynamic router with update modulus, and this is the same way you can update existing functions or add new.

A

Even after the deployment, and here we have tests to make sure that all these functions work and if you will be checking out with Reaper later, you can run the following command test guest report to see all the guest numbers we just looked and speaking of these guess numbers, um these numbers are produced on 0.8 solidity, compiler with optimization set on and about 200 optimizations run on, let's get back to our presentation, and that will be it. Thank you for your time.

A

I hope you find it useful I hope you build unlimited contracts successfully and never experience the pain. I did please follow my Twitter I do Post development stuff. There.