ERC-8152: Content-Addressable Logic Modules - eliminating Initcode Variance - Radek Swarz

Transcript

Thank you. It's nice it shows go. So now I can go. Um and okay so the ERC and content addressable logic modules that's a quite technical talk for today. um where we set up a standard that enable us uh some different way of of working for the developers, deployers and builders, auditors as well. So it might have some interesting side effects on uh several segments of the industry I

would say. Um for those who are not patient enough, here's the QR code to go to the ERC so you can quickly go through it and and then raise the questions. uh based on the content. Um we were three people actually working on this ERC. Uh now it's in the review state. So uh it's it's close to be finalized. Uh uh I was working there. Then Nick Moo much Nick is the author of the diamond proxy pattern. So the upgradeable quite like robust strong upgradeable pattern. and uh and Bill uh is also quite known persona in the in the Ethereum and Ethereum magician space. Um

so what why some new standard to to deploy and develop things? The reason is that currently we have fragmented logic uh or I would say redeployed logic for many many times uh across even let's say one EVM chain or across the whole EVM space meaning like in the multi-chain manner. What does it mean? It means that most of the people that want to build I don't know for an example a funible token like C20 they go to the open zeppelin website or they use the hardhead or or or foundry to use the framework of the open zeppelin and just start creating the the contracts and then they deploy those contracts again

again. So basically the same code with the same logic uh just with a different token ticker is basically redeployed uh many many times on on on chain. Um so that's the duplication of the logic that actually somehow populates the chain quite a lot and uh it's uh it's like broadening the the whole space. So what what we are bringing here is that since many of those tokens needs to be upgradable or with using the proxy button that um there we are proposing some what we call a column architecture and that is that we would have a contracts that will be reusable. Uh

basically their identity is your uh is your address of the contract and um uh you do not need to redeploy them on the same on the same chain. you basically reuse them, you know, if they have the same functionality or capability like what you what you need to have. Um the if you go a little bit deep down why it happens uh this let's say identity of the of the deployed contracts is that the the typical EVM deployment uh where you have the create or create of codes or mechanisms they relies on several aspects on how to drive the resulting address of the deployed smart contract

code. uh if for instance here is mentioned create two where you have the initial code. So basically your runtime bite code plus whatever there is in the constructor um and then also uh also the the salt and um in many cases is also depending on who actually deploys that. So those are all those like parameters or variables that that that impact the uh the outgoing address or outcoming address of the deployed code uh which actually results in the fact that it's being deployed on different chains towards the different addresses and that creates a headach for the devops or for for operations. Um

so what we are proposing is that that runtime byte code itself is basically the identity u meaning that we avoid the init code uh we would apply some constants which are like generally known constants and the only variable will be the runtime bite code. So based on that the any logic that we need to deploy on the on on on the EVM chain will result into the same address like like for instance when you have IPFS and you have a content uh content deployed there it's it's already ex it's always existing on the same uh let's say URL right on the on

the same H ID. So this is very similar logic but applied towards the smart contracts and uh and I know and I see some some friends from Solana space. Uh Solana also has it a little bit in a quite similar space but what we are propos proposing is that it would be highly decentralized and highly like permissionless. So we do not propose like centralized entity uh but rather that anyone can deploy and have the identity derived from from the runtime bite code. Um if we think about what what are the impacts or how how we need to work with that it means that we have to avoid any

initial like constructor code. Uh the impact un for some people unfortunately is that there will not be able to be any immutables uh because immutables are actually being done or created within the constructor within the int code. Um and we also we also concluded that uh we these coms these these logic models they need to avoid self-destruct right because when you have the proxy architecture the self-destruct in the in the logical code would actually destroy the the proxy. So something that keeps the let's say the business information the data the storage about the uh of the users. So those are the key limits that are there and if we if we comply to these limits

then we have a pure crypto cryptographic determinism of the of the result resulting module. So what we say is that the the runtime bite code becomes the identity. Um how we achieve it? Uh we bypass the init code that we have some specifically factory um and that actually serves as that constant uh for being the deployer. Uh that factory can be again permissionlessly redistributed across chains even those that are not yet existing and uh that factory brings that micro constructor. So it replaces that in code. It replaces the the constructor with a fixed constant micro constructor

and we also fix the salt towards the zero. Uh so the only variable as is mentioned here is the runtime bite code. Uh where it is possible to use it it's the on the diamond facets as a way behind a diamond proxy. Uh also there is a new uh ERC contract for the proxy design and that's for the um that's for the mod smart contract. So some similar as the diamond is but more like generic and more aligned towards the computer science I would say and and the generic terminology um for the dispatch proxies. Um what is also a loss is that those coms u or

actually we we say that those coms it's themselves that they are stateless right they they they execute the logic for the proxy so the business logic is there but the state that they impact is the state of that proxy itself uh and one thing that we ask the users is that um they need to prevent the collision of the storage right because that's one of the reasons of the of of the hacks that the the storage collision. So that needs to be described. Yes. Uh you either use the diamond storage or use the uh use the namespace storage like the open plan does.

Uh it has interesting side effects and that that is that we can skip the we can skip the proxy uh sorry the the dispatcher that is being implemented by default by the solidity. Meaning if you have like the uh the proxy over here uh and there is only like one function actually being implemented by the column then you don't need to have that secondary dispatcher there because that proxy does the dispatching just itself right so the that proxy can call a different columns but if the column is highly atomic that it executes only one capability one function then you don't need to deploy their additional dispatcher

which is currently being uh done by the solidity. So uh that's a possible way to skip it as the right side as automic logic or as is current situation you can have like a multi multi method column with the internal dispatcher um uh it just works uh as well. Um we also discussed some metadata dilemma because there is the impact on the verification on the indexers uh when you apply the uh when you apply the the the source code and and resulting hash into into the runtime bite code. Um so that's open the user to to decide we have the examples in the ERC are

described the examples where you have the logic only identity meaning there is no metadata hash it's purely based on the functionality right on the runtime bite code uh so you strip the metadata or which can be perfectly fit for very easy uh to decompile or very easy to understand runtime by bite code like like for instance the call towards the decimals you you know uh or uh the full source identity asset is common right now it has also some impact but perfectly in in both cases it's permanently replicable coms it's perfectly fitting uh there within the ERC there is a discussion on under which cases it's suitable to use what so you can look it up there then we also

created some tooling related uh when you consider to deploy these logical modules uh the hashcarf it's it's open source tooling that actually enables that that deployment onto the different chains um on the same address right that's basically the factory deployer uh with some features that are related towards the verification of those coms so here's the QR code by the way uh for that um and regarding deploying um one needs to decide whether they want to deploy those columns or whether they want to deploy uh something that keeps the storage right that gives a state uh typically that proxy so u based on that if it's

stateless logic perfectly the coms are the perfect things because they can be reused among the projects you know I am creating the some project like the stable con which is mentioned here and I will need to prepare and deploy some some uh important business logic there and your project can basically reuse that you know or part of it so the stateless logic the the business logic itself would be deployed by the hashcraft deployer. Uh anyone can permissionlessly to reuse it or redeploy it onto the different chains which will result in the same address but someone else. And regarding the particle storage for the for the business itself that's uh within the proxy and that needs to be deployed in a different way like create

x for instance that's another deployer. Um so here you can see the comparison on that uh the address identity there's a there's a key one is uh that the content addressable is for the columns whatever the proxy it's typically the salt addressable or or actually the deployer addressable uh that's the key differentiation I would say um and and the impact on the users is the very bottom line here and it is the security model uh for the coms also since they can be permanently redeployed. that's basically immune to hijack because one one of the issues which we are solving with the national stable coin was that when we want to deploy it on different

chains even those that are not known yet uh how do we avoid the like uh hijacking that that address you know where where the where the contract will be uh by some by some bad actors party because that's one of the unfortunate you know conclusions when you use or when the user uses the metam mask and and somehow it's different address on different chains then um you know it's much harder to spot some some fishing some fishing token right so with the coms that's basically immune to hygiene because that's content addressable it's based on the content so it always results into the same uh while on the proxy itself that requires basically the control

um what it has is the impact is the as we discussed there needs it needs to be care one needs to be careful regarding the storage. So not to collide when you know when you see the column and you will see you will see soon that there will be like popping up the libraries or the pieces of the code that that will be existing on the on the chain but you will need to think like is this impacting this kind of the storage or that kind of the storage you know can I have there the collision yes or no so this is something that need to be basically stated uh and cross-cheed um and that's why we also elaborated some signaling uh of the compatib ability and impact. So we call it compatibility and impact manifest that that should be

there within the uh within the source code of the com um and uh that describes whatever it relies on because just to give you the example EVM is not only in the public blockchain but it's also used in the in let's say uh some uh institutional blockchains like the hyper lessu and so on but the compatibility is highly different right the the forks are very different so what needs to to be sure whether those pieces of codes that are being deployed somewhere that they can literally be reusable somewhere else because of that uh dependency on on the capabilities of the chain itself. So that's why we said the developers intent need to be declared there.

Um what it also enables is that if there are already existing codes like like some tooling like the multicol for instance um or some factories or let's say uh governanceless registries that they can be recarved into the like canonical identity. Uh so we brought that this this function into that that hashcarf uh mechanism that will say okay from the source code from this source address just redeploy it into the canonical identity and then it can be reused among the chains. So that already exists. Uh we also develop the uh some cross-checking function. So that

basically says okay just verify that this is really the uh the column that that has been deployed. um and not something else and as the consequence is it's enables to build like universal library of the logic that exist among the EDM space I would say not only the the mainet but overall space so really trustless global library of the EM logic and univers addressable by the hash of the spy code and the chip that it has is that currently when you create those contracts you basically you create like monolithic contract cont right you at the very best you you have like a proxy like UPS proxy the upgradeable proxy and

then behind that you have like one logical contract that's common pattern uh this enables further to to use those either diamond you know modularization or or uh the that that model dispatch proxies to have those logical modules there and it will naturally lead towards a registry less registry you know that there will there will be those coms being deployed and the what we believe is that the community um will just lead towards those those codes that are uh highly reused among the projects. So basically just imagine that that you would be one project the first project to deploy like

20 20 automic contracts and all those 20 will be already audited right by your project and there will be a secondary project that says like 6 months later and and it it knows that it needs to reuse like 12 of those contracts because that's the same capability that needs to be reused like ERC20 transfer for instance you know so you will just create a blueprint and state okay I want to use that code that's it's already audited huh and you might also audit your your project as well but then those 12 will be audited twice so it naturally emerges to that code that is highly reviewed highly reodited and highly reused

um and this is one of the consequence also here that it will have the positive impact on the users because currently when you have like a massive amount of the different ERC20 or or or or NFT uh codes. Uh it's basically duplicated logic. So there is a cold access penalty. Uh some of you might know that that if you are accessing or if you're like executing the transaction within the block, there is like hot and cold access, right? Uh so once you have those let's say automic coms that are very frequently used like that calling the decimal for instance uh then they will be basically cached so they will be

already warm for your transaction for your contract for your like overall solution by someone else. So this is the just the convergence of of that. Um and basically it's it's it acts as a synergy for this EIP 7863 because it's a shared logic right um it has the impact on the developers experience uh because sudden and somehow you will change your thought from like writing the code more into like declaring the the blueprints declaring on what features I want to have and most of the features are there already

deployed on on EVM chain. So uh that will be it will be more like construct it will be more like architecting what you want than writing those codes that are already existing. Um of course you will write your specific like specific functions that are extra. Um but there will be a huge possibility to reuse the code. Uh what it also enables is that you do this assembly your and okay and uh you move it towards the you you deploy it towards the test net you test it on the test net and then you will just use uh what we have a carbon copy you will just basically redeploy it

easily to whereas the towards a production network uh so that's another uh conclusion the uh another one is the uh as is the impact on the agentic experience And it is that there are two use cases which we discuss here with the people. One is that they will become the builder's agents. So the build builder's agents will know what what what you want or you will discuss with them what you want and they will actually do that architecture and and and blueprint declaration what they need to uh assemble together that is already existing on on chain. And then there will be execution agents. That's the another use case and it is that that that agent seeks some or sees some opportunity and uh just in time in in

the time of that opportunity just redeploy uh redeploys the already existing code that is somewhere else might be also already audited but uh it will just put it into its emm chain that needs to be there just in time. Uh we also created or this is the work in progress the command line for the carbon copying it from from like source source chains towards the target chains. Um this is the idea that there could be like a web UI for that and in general it improves the developer experience the autonomous operations of the agents and improves the node performance of the EVM itself. So that's uh just the impact of using this ERC8152

and regarding the status where we are. So we have the standard in the review phase. We have the deployer that's already it's already done. So I have a final call for the features because that impacts the address. Uh carbon copy CLI is work in progress. U let's discuss whether there would be a need for the web UI. uh we think that there should be a standard for that manifest of the compatibility and and the strong thing is a call for participation on the decentralized discovery layer for the developers and for the agents and these are the calls. So please uh talk to me regarding uh whatever we would need or what what you would need as the carving canal logic for the deployer mechanism.

That's one thing and the other thing that's a strong topic we need to create the discovery marketplace of those coms but we need to do it in the different way than the ether scan it uh is done right we didn't want to like create like a centralized one piece that everyone would depend on we want to rather do it in the let's say sourcify way it means the decentralized permissionless way that uh anyone could like publish the the corner and anyone else can actually discover uh discover particle uh and compatible com code. So thank you. I would say be calm reuse already deployed and audited code and yes let's discuss and see you on the next B5 meet up

questions.