EIP-7784: GETCONTRACT opcode | Tim Pechersky, Peeramid Labs | ETHTaipei 2025

[Music] Hello everyone. Uh nice to be here and um today I'm going to talk about smart contract indexing on chain. uh with this EIP um the proposal is like to um create uh root of trust for immutable byte code which in my opinion when I joined the blockchain wipes was like the big offering of the blockchain that the bite code is a rule and it's immutable you cannot really work around that and then I figured out that there are proxies and not really that easy so um how did I get here and uh What was the road that brought us to proposing the CIP is that uh we wanted to build apps onchain for smart contracts. We didn't really want to build another yet another blockchain and um we faced many challenges there and uh one of these challenges was lack of standardized factories. So today a lot of projects like Aragon, ENS, uh safe wallets, um a lot of D5 protocols will design their own factories to deploy the code and um often times what you'll need is not just deploy the code but ensure that you actually have some kind of registry which says you that hey this code actually was deployed from a trusted factory.

Therefore, you can have some kind of level of interperability between the apps or between the deployed bite codes because you are quite determined that it is performing according to the factory uh rules. Now, um the problem though is that all of that is super custom. So every project will have separate implementation and we were standing basically on this road of choosing do we also want to write yet another custom implementation of something that can be actually generalized. Um and the generalization is basically that yes you have this like tree of different instantiations of any kind of contracts which kind of like still have some base layer the root of the this trusted environment. So we actually proposed C7744 as beginning of that which is basically the same as 7784 but is ERC basically smart contract um and it has some challenges.

So so what what is it about actually? So, TLDDR uh basically we want to have this get contract op code which we can feed in the hash of the bite code and get the address where that functional piece exists on the blockchain without having to think what is an address because the addresses on chain today they have account information. They store information about the stoages, the accounts uh and with that also the bite code. But we don't need the stoages of the accounts. We actually want to have that library.

We want to have this beautiful immutable library of the source code we can refer to. And if we have it, it creates us basically this kind of intent mechanism that I can say when deploying my code that I want to process, you know, these calls as if I'm your C20 token without thinking about they have to write all of the C20 implementation and deploy it. And uh it has some nice features. It makes it globally portable even across chains, immutable and quite secure. Um so why why did we need that uh for building apps uh and why apps will love it?

So few reasons uh first of all it's uh it will make deployments cheaper um because you will reuse more code from already existing deployments and the whole Ethereum with that becomes a huge library of uh interoperable smart contracts where you can refer to others code and reuse it not just by uh compiling in hard hat or foundry and deploying yet another same implementation but just referring it on chain and um it it it opens up actually ability yesterday was nice idea so I added it to the slides to actually have a pre-ompiled for everyone uh so if you actually have index for the bite code you can actually as well check how much is being used how much is gas being spent on that bite code and then protocol level um developers well they can optimize for that and they can like uh pre-ompiles for that and optimize retroactively just seeing on the usage of that particular functional code piece. Um and then it adds like really nice features for app developers such a feature flags. So say I want to have compound compound markets on some chain where it's not deployed yet. uh and if I have uh ERC AIP 774 what I can do is I can say if there is a distribution of uh this exact bite code which represents compound market as it is today say on Ethereum and I know the hash of that then I automatically whitelist to do some functions on my chain on my contracts even without it being deployed yet or if I'm um security auditor I can attest that some code will be secure cure on chain even before that code is being published somewhere which is um nice feature as well and the the biggest offering of course is that uh it is uh it it enables this trust because it's immutable you can really proxy around the bite code references um and there is a lot of use cases for that so here I wrote some I hope you can see that actually I'm not sure if you can Um uh this is like uh how it could be used for 7702 with the delegations. So instead of delegating to an address, you could write a simple proxy contract which uses uh 7784 or it could be baked into 7702 as well.

But anyway, um which would say that you just whitelist the hashes of the functional bite code that is allowed to operate from your EOA. It makes it very easy because you can whitelist these hashes even if the code is non available or if you don't know the address of that code but you know exactly functionality. Let's say you compiled it or uh you just have a general trust registry or security oracles that whitelist that and um and you don't have to think about the accounts today as they are since uh you don't have to think of all the storage I think uh which are account related not the bite code. So good news everyone it's a part of Ethereum distribution system which uh I was crazy enough to start writing uh as is this generic solution of the factories and registries and uh with having such immutable thing which um you can safely refer to it enables actually to um have this unified interface for smart contract distribution and um and save time on repeating factory registry designs and since it's immutable well you can make a packages and not just make packages but other developers can trust that this package you distribute it is going to perform same way as it does today tomorrow and day after and year after and even if you are on a different chain you still can assume that there is this package existing on another chain and I can whitelist and I can package it and I can port it and everyone can really easily attest and verify that indeed this package is secure by just checking the bite code hashes without any account information which is today on Ethereum. So check it out.

It's a public repo EDS on our GitHub. Um and it's really cool. Um it's a little bit uh hectic to get uh big projects using that because again like a lot of investments are done in these custom factories. But if you are writing some project in that direction then EDS can actually help you out to save your time. And um the structure of EDS is quite uh big but in the essence what we are doing is we're basically setting up few layers of assumptions about uh entities who do the deployments.

We have permissionless domain where basically you would think of this here as uh ERC EIP7784 which acts as a trustless registry for the functional pieces and then developers could develop the code and it automatically gets indexed. Um the current implementation of EDS actually uses ERC7744 which requires developers to manually index that and um yeah AP7784 would really help out by automatically reindexing this. There are a few projects we wrote uh the solutions.py.xyz is a safeguards plugin which uh answers uh challenges for recent bybit attack and it uses CDS on the background.

So check it out the GitHub all of this is public um for I just quickly go through why it's um good actually for the execution clients because one of the problem with EIP774484 is that it requires uh execution clients to store data in very specific way. So you have to think of that you have bite code and you have accounts and that's a different things and that was not an assumption before. However, um like rough estimates are that it's going to to add some like 4 GB to the index, but uh contracts today actually if you think of them, that's a big like thing. They all reproduce like if you deploy the RC20 token today, it will be the same code deployed to different addresses added with like small metadata behind which makes like the hash different. Hopefully EF changes that.

But with uh this you just have a pointer. So you have one contract which once figured out how to do that and then if you want to deploy another one you just make a reference that's it. It's very easy and simple. Um and then it actually provisions solutions for one of the long-term problems with uh Ethereum is that bite code cannot be pruned. You can prune the stoages uh or event data but uh bite code is not really prunable at the moment.

But if you have an index, you can actually get the metrics of how often this code is being used for anything. And well, at some point you might want to put in an archive or figure out uh some pruning solution to that as well. Yeah, I think that's pretty much it. Thank you. There are my email and my Twitter.

And uh I think we have time to some questions. Yeah, we can have some Q&A. So, does anyone has any questions? Oh, here. Wait, wait.

There's like a microphone. Okay. Uh, I'm seeing this proposal. Very good. Wonderful.

I love it. I'm just wondering is there any drawback or uh disadvantage that might introduced because of this approach? The the only challenge I see is that execution clients have to store data differently that they assumed previously. I cannot see any particular disadvantage for anyone. the the there is one uh security assertion you have to keep in mind with ERC7744 and this one as well is that the first time the contract gets indexed it does some particular actor does it.

So they might have their own storage logic there and you cannot really refer to the security of that as a dot like doing calls to that contract but you you can you can it's your responsibility to attest to like check the security of that you actually want to use that code beside that I think it's all fine got it thank you okay so maybe one more anyone. Okay, then let's not let's give Tim a round of applause. Thank you. [Music]