Towards Support of Ethereum Equivalence on Different L1/L2 Blockchain Ecosystems

Transcript

thank you okay okay for the microphone hello hello okay okay um i guess that will be um about the time to get started okay um great lunch everybody free lunch fancy hot weather i hope you are not melting um so i am neo i am the head of tech advocacy at cayton so you might be having questions why are we here today as a as a standalone layer one or maybe even later

to you that you can see that um but today we're here mostly on to talk about ethereum equivalents how from a clayton perspective also from a standalone layer one perspective so we would go through uh this topic uh with the support of ethereum equivalence and evm request uh the equivalents that what we mean on different layer one layer two blockchain ecosystem and this is our outline for today uh when you look at it so we give it a bit background on what catan is because this is most of the questions that i have all the time what is clayton and obviously we talk about the rise our compatibility about evm as a standard and also talk about the support of the ethereum equivalents from the clayton

perspective and last but not least is to cover the implementations implications which is everybody maybe care about what is happening with the clayton in terms of the ethereum prevalence so clayton in a nutshell um last i mean the very short time you put it right here is like we have our own user experience that we would like to empower every organization with a robust blockchain ecosystem and what does it mean which i'll cover in a second but when you look at we just lay another blockchain layer one obviously but one of the major in the market at the moment when you look at the ecosystem these are all the use cases and ecosystem partners that we have and the whole thing is actually initiated you know from korea

you know developed by cacao in the first place and then you have all this company ground is crisis actually supported but what is what are the major offerings right here for clayton as a layer one as a standalone layer one then you think about the user experience that we're looking to have is the speed and reliability you look at you look there's a 4 000 transaction per seconds that we have on the main map and you think about the one second you know block generation time which is more like finality like the immediate finality that we keep talking about right here you think about we have the layer two we also have our own layer two servicing etc etc you know like these um deterministic price structures

and then we're trying to actually benchmark ourselves with other lay ones or layer 2 in the market when you look at clayton right here when i just mentioned that is the block generation one second and you talk about it's a bit oh the data right here but then when you look at is about in the top 50 then you further look at the transaction legacy i just want to go quickly on the background about clayton but when you look at it um that's actually some kind of um you know a user test right that we we have which you can get to the github link by the repository what you see is the transaction latency what we kind of define is how much time for a transaction being packaged in a blog but

at the same time obviously people care about the tps and all these kind of things about the scalability but really is the performance plus the transaction latency is what a you know a standalone layer one should be looking at so our latency is around 2.1 seconds at the moment for that specific you know test cases that you will see but then how are these actually being made possible uh for all these kind of things that we claim that one second block time four thousand tbs blah blah blah when you look at it let's like creating is actually based on a blockchain infrastructure is more like a surface centric you look at we have oh we have the main net right here which is you've got different consensus now

proxy node that is actually for the surface chain as well you've got proxy now so you think about is the standard three node structures that we have and also we have the service train right here for different use cases that you might be having and but when you look closer really is we have the three node structures endpoint proxy corner endpoint you think about is more like rpc you know api for people actually running the apis right there and you know connect with your you know rpc uh api modules but generally you know um what you will be taking from here will be the consensus algorithm for clayton's actually with the ibft and this kind of thing that i just covered already but what is really different from

ethereum or other layer one is you think about we have a very specific account model it's with the multi-key pairs could be linking with a single account and the transaction model is um you think about on the on chain multisect that how we can make it happen is the transaction model is actually with the multi-signatures on the transaction fields in the object and also with the deterministic in a transaction course because we're basing on the fixed gas price and this is just a design pattern that we have at the moment but when you look closer um you know just go back to 2018 we actually we actually a fork of ethereum back then and this is not a reason why we are here

but it's part of reason but um but we still you know keep keep contributing for the same foundations that we have with ethereum but when you look at the on the on your right hand side obviously you've got different layers of the architectures and then when you look at the orange and in purple color all this kind of thing is what we have been making changes actively since the half full that we have from ethereum um but then why do we why do we do that in the first place like all we care was you know if you want to have a dynamics in the blockchain industry obviously you will be having given layer one but different layer one why they're building layer one not just because of fixing

some kind of paint points that ethereum committee is having at the moment but we would like to have our own ux our own user experience right here that i mentioned all things differently how are you going to make the one second block time in a possible oh is it based on the the gas limit that you set oh we don't have the concept of the gas limit so how do we do that so we have something we call the computation calls and multisig account control and all this kind of thing is the our own ux not just to say how you can make it 4000 tps or one second block time per se but really if we yes we have four we make changes then what happened it happens your account model is different

your transaction model is different and then you have you know different data structures of everything that we put together right here for example you might be using the same ethereum apis you know fire ethos.js but then really this is most important you may be running with some errors because you have different json requests and and return format you know in your transaction body that will be coming back and then it turns out the transaction fields will be a bit different and then we have a problem right here and then that's that's why people keep talking about a rise of uh evm compatibility not just from a creatine perspective but most of the layer one or standalone layer two obviously i saw

polygon right here we're actually you know thinking about the same directions and and what that is like yes we are the gift for from it from ethereum but then we all believe um a theme at the evm is the de facto you know runtime for us obviously people will argue it uh we'll have a debate right here i mean outside the room whether you know web assembly will be the one ago uh going forward with the major one but then we're all here for ethereum um you know committee conferences right i believe we would like to look at how individual layer 1 or layer 2 can actually harness the network event from ethereum communities and and so that we can have thousands of different use cases actually built on the ethereum ecosystem at the same time

we would like to see more thousands of development tools right that has been deeply integrated into the evm and so us as a standalone year one or layer two we would love to have some way that we can attract our users you know builders so that on on the different levels that we would like to integrate with it and support them like how for example the core protocol level can we supporting ethereum transaction type types on you know for the first time so that you can still sign your transaction uh the ethereum's format transactions into creating it will still be working so that you don't have to think about to make any specific changes that to your

use cases or any any stuff that you're building on different you know ecosystem that we'll be having and and but i think we all agree on the point that if we bring ethereum or maybe ethereum they don't have to to the long layer to lay i mean layer one or layer two do they say that you have a evm compatibility i think it will take time i think batter will be for this layer one and layer two standalone to think about how you can do more in terms of the even compatibility to to make it happen um and going forward is they people think about evm compatible is not enough because what what it means is the modify is the

modifications and the complete uh reinventations like that for the low level call the implementations actually takes time and drives more difficulties and the complexity on working out one solutions only for that case so that's why people would like to think about compatible it's not enough what we need might be the evm equivalents and but then what does it mean for the evm equivalent so when you look at our roadmap obviously case in 1.0 pre-2021 we thought about we would like to be one of the ethereum compatible blockchain but when we know that we need to emphasiz we need to keep emphasizing our

own features and data structures at the same time and than the ethereum compatibility but it turns out we didn't we did not keep up with any single or any changes that we have from the latest evm versions and then things becomes that really complicated that result in we're putting many or much effort just to integrate a specific ethereum that use or use cases that have been building on ethereum to create it if that would be a way right there and what we believe after this experiment that we have been doing in the past years and you know pre-2021 we believe what we need is really to have 100 you know compatible

which is these equivalents that we talked about to keep the original functions at the same time we can support the ethereum functions and most importantly the ethereum format transactions and that's what we would like to say is is if you're trying to think about evm equivalence is the complete compliance uh you know just like the ethereum yellow paper you put all the op code right here you have different guests that meaning all the things that how does it work interweb we want exactly the same happen on ethereum but at least you have the mode or environment to support the ethernet equivalents and so that you will have more standalone in the layer one layer to you to think about how to integrate with the

existing ethereum stack and most importantly this is something that we would like to see really the evm network evaps we would like to see and every eip that will be merged you know during the time we would like to see that exact same features or changes that will be happening on our evm environment uh on cayton going forward that's why we would like to support the evm equivalents but before that we talk about the clayton case about the evm equipment what are others or what have been you know doing from in the wider industry normally we see if people would like to jump from evm to uh you know web assembly obviously they

write all the right uh like they they compile all the bicol they rewrite everything to make sure that we'll be running on another runtime but at the same time is you see it's a lot of complexity that is being introduced and the layer one for example for layer serial like you know polka dots or cosmo what they do is they have different method if you look at nia they are going with the evm like the evm involvement uh but mostly on the layer serial you think about they are building more sub chains like power chain like like the one like the moon beam on pokedoll they're exactly doing the evm compatible way of it but you know when you look at it most of the solutions that you see

or maybe the operational pattern that you see today is really going with quite similar to the f 2.0 think about the new consensus or what a new consensus plus the data availability or this kind of starting pattern that you have to be more scalable going forward and then finally we are here about the evm equivalents about the clayton case right here so evm equivalence is has has always been the major pillar that we have for the clayton 2.0 initiative so if you want to learn more about casein 2.0 you can check out our lights paper right here as a reference but what does it mean it means we finally would like to do more than

evm equivalents we would like to support of ethereum equivalents meaning that every single evm features that will be available on the clayton core protocol and ethereum development tools for example when you think about ethers.js and all these kind of the ethers api libraries they will be happening and being you know totally applicable for the use within the clayton ecosystem and that's why you start seeing something if namespace api that we support that will support the full ethereum transaction format into the category ecosystem but then if you can support clayton format and ethereum cater sorry ethereum

format and clayton format transactions then you need to think about how you support it at the same time but you can also distinguish it from each other when this transaction going to transaction pool and further being packaged to a broke and we're not just talking seriously the whole thing is being released on the first one 1.8 that we have for clayton's actually back in a few months back just before april we actually release it and things has been working well and working all fine but we go deeper what do you mean by if your name space but you look at the test stack that we have for clayton right here is yeah people you know build their adapt solutions

and they can also have their developer environments per ecosystem obviously ethereum got tons of those and we would like to see more on clayton that can work out in integratable versions or you know just think about how it could be interoperable between different chains but really this is the main part is on our json or pc on our endpoint node i mentioned previously you can start seeing more ethereum api and this ethereum api with the ethereum namespace that they can support all the ethereum transactions all the ethereum formatted transactions that will be going obviously being processed by our avm plus which what we have been branding as a kl vm creating via patent vm

but then there's so many implications right here is um about the pre-compiled contract what does it mean like there's so many things that it's not just you plug in the ethereum namespace then the whole problem will be solved and you don't have any problem you can you can process ethereum format transaction it's not like this is actually we did have a lot of implementations implications if we're trying to do this obviously we are not trying to kill ourselves but we would like to harness the network effect into the ethereum ecosystem at the same time to bring more users to extend their use cases maybe they have the developer tools maybe they have different use cases built on ethereum already we would

like to see that happening that building on creighton so when you look back about when we talk about the ethereum equivalence as a as a as a major requirement that we would like to have and obviously there's some more requirement that i mentioned already you need to you know have every evm features that will be in support right there on your vm level or clayton vm and you then you need to um actually i don't have to walk i can just do this pointer so um so you can support all the ethereum development tools that you think about that will be usable on clayton what i mentioned you support the api format with the if namespace that will be available on endpoint node so you can kind of

access these kind of ethereum apis that as you go but then when you look at these four major which i have only mentioned that already you would look at actually some implications like for example when you look at this okay so it's easy that you say you can support event features then what about the transaction types that eva like the evm you start having like these you know like the dynamic fee that's starting from eip 1550 like how you're going to do that because you don't have you don't have the the gas limit concept you don't have the the dynamic gas fee concept how you're going to do that and and also the transaction feel like i mean not every transaction food is actually having on both blockchain ecosystems so how you're going to deal with it if you're

going to you know having the evm equivalent support right here and as it's really a lot like this pre-compiled contract the references will be different um so if you think about for these as well some transaction field may not even be used even though after that after the integration with the evm you know equivalence that we're having because we're not using proof of work like why do we even have like feels like difficulty and all this kind of stuff like the gas limit so um when you combine together everything we have feel more but then some like generalized um you know pain points i don't think it's a pain point but then you think about it's more like

the implications that we see is okay so you can okay neil you told me that you can support ethereum equivalence or evm equipments per se then what about the pre-compile because now um you know ethereum they got pre-compiled contract as well as specific address then obviously you will be having some kind of caching using the same address so obviously for these situations we do the update so as not to have the overlap because when you look at this case exactly the vm load when you look at ox 09 that we were using but that will be clashed with the breakthrough you have which is more like the generations of the harsh functions that we have support

in the ethereum ecosystem and then also for the free payer validate sanders that we have and obviously for these we make the changes for the addresses as well we don't want to have these references we'll be clashing with what we have and and also it really depends on the dip down people using on the maybe proxy contract or maybe any contract that they have they have their own pre-compiled contract they may be using call method delegates call method right here it could mean differently um because when you know if if a call is happening from an eoa account meaning that you don't have the access to the chain data when you actually make

the call from it uh also mean that it will it will have different different behavior because if you look at this if you're using that k core they always you know um you know kind of refer to the latest um pre-compiled maps right here all the time so what you actually had before uh will actually be different from you know after the hard fought that we have to support the like the evm equivalents and so to speak um for the transaction types there are a lot of transaction types that not really a lot but only two that we see that is major stuff that we like to support but then really when you look at it that there are different implications that you can see from the different

transaction types that we need to start supporting you know after this kind of hard fork um to support of the ethernet confidence and also yes you can you can support both uh format of the transactions but you have no control because it's a decentralized network if your transaction center would would like to send the clayton format transactions and being processed to a smart contract that is running with these ethereum you know apis then obviously is at your discretion as a user but obviously we can do much better on the error handling to tell you exactly you know the model that you sign is actually a mismatch of the one that's being processed on your smart contract so on this kind of things that obviously uh we

will have these kind of implications combined together but if you want to go deep always refer to this recording of the presentations and and also you know get to the um maybe you can get the slides somehow and you can just have a look and keep asking questions to our you know community out here really to conclude i think we've still got some time to conclude five more minutes we believe evm equivalence is an industry standard so we don't think in a way that we are a standalone layer one or layer two then we must be competitors of ethereum not like this if we believe evm equivalence is an industry standard and you think about there's so many evm

compatible chain you're essentially building a bigger cake and we treat we treat ethereum as a layer zero and we build you know on the layer one and we based on the evm we make it evm equivalent and and obviously it creates an enormous opportunity to experiment infections without touching the ethereum map so we don't we don't make any you know influence to the ether and make that you can always have the innovations on the layer one or even on our test net to make something happen because we believe ethereum is now too big when you look at the merge it takes time it's now too big to be flexible to changes not to mention changes to support your layer one so

things must be coming from layer one or layer two i mean standalone to contribute to the ethereum ecosystem to drive this forward and when you think about klvm is evm equivalent and we actually enable support of ethereum equivalence by saying that we can support the 100 the same of ethereum formatted transactions and you know in these three areas the development teams evm api and core development contributions that we could have so that when you actually contribute to eip you contribute to kip as well so you know one one or the other you're you're still contributing to to the ethereum ecosystem

finally finally going forward this is just my thought is if you believe evm is a standard going forward and obviously there will be there have been so many evm compatible changes i mean not this one this is equivalent these guys then you think about it's actually a an ecosystem and evm ecosystem that people are trying to build and then you start looking at a lot of opportunities between evm evm cross train the bridge that we talked about and also it might be it might be time to go back to a discussions about evm to evm or what vitalik has been saying the evm in evm opportunities that we may be having given that we have more evm compatible chains

or maybe change or layer one or layer two that with the evm compatible support right here then we can have more opportunities going forward so this is the invitations for everybody right here of your developers feel free to scan the curve if you want to join we would love to have you to build on our ecosystem your abilities to contribute we have a lot to contribute to all to our own ecosystem and also to the clayton ecosystem and we have a lot happening obviously you know hackathon is the best way we give the price we have your incentives you come to join you get your prize contribute to your ecosystem to build more tools towards the bright future of evm equivalents at clayton and also for the evm ecosystem growth

that would be me a bit long but if you would like to get more information about clayton just to scan the code right here you will get the link tree you have all these kind of channels that go through um do we have any questions on the floor if that will be money we can take it outside the door i would just stand there and just to mingle and answer all the questions that we have right here i don't do do i have to yeah okay yeah any questions don't ask me what is clayton because i don't want to do that again yeah go on yeah oh sorry yes uh suck neil for the very good presentation i'm from verilog solution i'm a

co-founder there and i'm also a professor from ubc actually then we submit the proposal to clayton and it's kind of the uh yeah so my my question basically is that do you have any plan and for for example because the solidity code has the deficiency and a lot of those uh the uv evm equivalence uh chance they would like to build their own languages so i want to know that clayton has this plan and the other question is about the zero-number proof we also have some change and try to develop some privacy protection mechanism in the chain so also i would like to know more about this uh you cannot think in later um if we're trying to build under languages

that you need to think about the equivalence of it afterwards so what's the best strategies to do right now is that keep using what we have this like with with the solidity we keep building we're not going to create new languages called something kind of fancy name clay blah blah but the short answer for you will be we keep using solidity for what we have been using maybe you know maybe we support more languages we don't create but we support more languages that go into the creatine ecosystem you know cairo and fipro obviously all this kind of thing we want to keep supporting fiber maybe a bit going down but then you look at cairo or you solidity will be the main languages that we cover and also i think for serial knowledge proof that you mentioned it depends on the applications right i

think very quickly but you think about we do have plans think about these layer 2 layer 2 plan that will be running on clayton or ethereum ecosystem that is running with these you know ck roll up that we might be having this model but this application will be what we've been thinking about the serial knowledge proof but i guess that would be everything that i have [Applause]