eth_multicall Meeting, Jun 17, 2024

Transcript

right [Music] so I can give my updates um so yeah this week we were looking into the tests with Kari like um how to first get them working the hive test and then because we had more details um in the block results then uh we could kind of investigate some things which s um basically gu was not properly assigning a default chain ID which was causing the transaction hases to mismatch sometimes

uh so I fixed that and I think there there was another bug that I also fixed that we found through the test was the EA sending or sending transactions that's true yeah so in in validation mode and contracts can now also send uh like do simulation and I think that's it yeah that's basically what I have been doing as well except I have been working with uh with those same bucks as well with the nether mind we are not getting the

same transaction has with the get yet but will look into that but I can imagine it can be something that that it's not assumed or I know when you're sending a transact with call then what transaction is generally assumed since it depends on the input you are setting on on which transaction format you should be using so I can imagine that kind of that can cause bugs or differences between the clients and I don't know if we need to make do more specking on that like how the transaction be formed on what kind of parameters but that feels somewhat complex to do if you just sending transact to somewhere it can basically be any

transaction format except the blob transaction well we default to 1559 no unless gas price is explicitly provided at least that's yeah I don't know if net might works like that yeah yeah but there's no one from NM around so this something maybe could discuss if at some point the other thing that was what you were bringing was that what was the that there would be second evm and that would also affect multicol but

that's not valid or it's not in yet but I guess it would be affecting multic call and then uh what was the change e yeah the E thing but is it so that that's going to be approv that's going to be the next hard or I I it's quite a lot of work yeah that seemed to be the consensus uh from last alcore devs that is going going in the next hard work MH or really no so that would be probably this year maybe still in this year um I would

guess end of this year early next year yeah but yeah I mean we have to in investigate and see if it effect mode is simulate I'm not sure like I haven't done a deep dive in UF yet to to really be able to say yeah I don't I don't think it will I don't think there's any changes that would affect simulate um mainly because we just are using the standard evm for almost everything right but maybe you want more overwrites or something else or some new transaction format or that kind of stuff yeah those are the type of things

that I was also uh thinking of I hope we can do it so that if it reest changes that the old method would still work but maybe it would have some limitation on the new environment and then we would make a second version and the second version which put the new evm yeah yeah but yeah I'm not really fine enough that we will have two EVMS sounds very complex but what what are you going to do about it go on all and play I've tried that it doesn't go

anywhere have you seen awarded against it but you lost or you just um actually people from get are also hesitant was were hesitant about you so uh we were kind of pushing back but um seems like everybody else is on board so it's going through hello lukash hello is or

not uh I didn't get that sorry are you Pro or against EF uh I'm to be honest I'm not 100% convinced but I I don't I don't think I have anything major against itart a bit complicating the code base that's basically everybody's argument against it yeah like I haven't met anybody that says e is a bad idea if we were building a new blockchain but on the other hand like a lot of people are telling me it's a good thing and they have some arguments that

it's hard to me to judge so and some of them are seems quite smart so it might be a good idea so it's so complex that it's a good idea I think it is as the change introduced in eof do make for a better evm if I was building a blockchain today I would use everything that they suggested because they are smart people doing smart things and they're all good ideas the problem I have is that as clar mentioned before you were here in chat somewhere it require you you can't get rid of the old evm the evm has to live forever and so it's not like we're getting rid of some tech debt or anything like that it's just you're adding more complexity to everything and having a better evm by itself while still

having to maintain the old one is not obviously worth it to me I know this is how things kind of work when you're doing CPUs you add new instructions you add new complexity but x86 doesn't really remove the old things so yes but presumably the new ones give you new functionality I don't think there's anything in EF that gives new functionality like there are things that would be really useful in terms of like uh code analysis and whatnot that I think are only really useful if all of the code in the evm follows it if you only have like half the code on ethereum following it then you can't leverage the

benefits but you can opt out from the old code right you can write only new code and COD only new new type contracts and then you everything uses this I guess maybe maybe gas costs go down like the new evm is a little more efficient perhaps maybe that's an argument in terms of what what's the benefit to users ah what's the benefit to us so I don't think this is user facing uh Improvement it is developer facing Improvement right is it smart developer fing yeah like Okay so let's say the smart contract developers are the user in this case what is the benefit to them uh I think better tooling uh

definitely uh cheaper gas is a byproduct right it's maybe not not the main idea but it is there uh better security potenti because of better analysis um don't know okay those are good argum I'm not I'm not a developer so it's hard to me I don't develop on train right so much so I I'm not the best person to ask I mean the number one problem with developing on ethereum right now is it's way too easy to shoot yourself in the foot and introduce security vulnerabilities so if if the eof contracts actually do have better static analysis capability

that is a good thing it feels to me like you could not change the evm and just have solidity changes though and achieve the same result but maybe I'm wrong I don't know I'm not a solid compil developer what was the question we had for nethermind earlier the transaction type so when you are defining a transaction then what the transaction type is set depending on the what are the the arguments for the call like if you just set two fields for example then is it assumed to be type two transaction or type one or or what uh can you can you ask the question

again I'm listen like if you're do if you do an E call and you only provide the two field what is the type of that transaction is it a type two transaction or a type one or a type Legacy ah the two okay you don't provide transaction type to call okay that's what what it defaults to it defaults to two you said no no no no I'm I'm I don't know okay that's the question like what's what's the default and is there like some heuristic you use to try to guess like let's say access list is included do you do type one or do you do type two or let's say the max speed for gas is it type two or type three there something what potentially

could be different between get a letter I think it defaults to Legacy currently yeah then that would explain some of the has differences that we are having how hard is it NE mind to change it for E simulate to default to type two or just change it for both e call and E simulate to default very easy I think in general I think type two is the best default transaction blob doesn't make sense for anything that's not a blob transaction um type one was basically temporary we don't really need it's it has no benefit over type two and Legacy I think is just strictly

worse except for you could do multichain but in this case doesn't matter would it be easy for Cena to fetch the rules on how the type is defined and then share share them and then maybe nether mind could have the same rules if those are good yeah maybe I don't know I yeah I think it's basically I mean we have a logic that tries to detect the type based on the fields so if there are blobs then it's a blob transaction if um if there is the max Vier gas and so

on it's a type two if there's gas price is type one but def just it defaults to to tattooes sense not available or like blobs are not available makes sense uh I'm looking into the code for each simulate I think it defaults to type two there but I'm not entirely sure uh oh okay Al is not here today he's sick yeah I can continue the discussion with with when he gets to start developing that

part okay uh yeah I will keep that in mind we'll ping him to about it anything else well we're discussing about that EF and how that will affect the each simulate but Cena didn't know yet does it have impact or not but that's something that we probably to start discussing at some point but we get well much it's just DVM change very ter though yeah hopefully it's like that it's like adding new new bite code new up codes is there no new transaction type

or no no it's all about the B code right changes I was reviewing that like I don't know a year ago or something I don't remember when uh so yeah uh yeah it was very very deeply in the stack in DVM like not sure even if anything above changed so how do you deploy a um an EF contract is it just that it starts with the Zer there's a there's a new up code for that I think but like so you cannot deploy it with a normal transaction that's missing the

two Fields I don't know at the moment like I said I haven't looked in that for a year or something I will be doing a revisit soon but uh when Iman uh updates our PRS for but I I don't remember I don't think it's no I I don't know I don't know I'm pretty sure it just depends on the first two bites of the contract so it's just the same way deploying that you just remove the two field and then it read the same bite code I guess and in the I guess then change some transactions some

transaction will behave differently if you have those two bites set differently do anything else uh have you read uh if we talking about e the some somebody from the ref team posted why eof is good you have benefits uh I can check it I send it to the chat but yeah I think many people agree it's

a good idea but not not all agree that's a good idea to have both at the same time that sounds difficult not really it's like adding some new up codes right it's just adding bunch of them so it's not like it doesn't break anything that that was before right it's just uh like like adding I don't know 10 10 new OP codes that are somewhat heavy right in the logic but it it doesn't really break anything that's there already well main Bo yeah if I understand correctly there are certain

contracts that would be valid as preeo and are not valid as eof and so if those first two bites are set the evm rules are different like how jumps work and stuff like that yes yes yes yes so so it's not just adding op codes it's changing the behavior of some op codes making some yeah yeah sure I mean I mean from the node developer okay sorry uh didn't didn't specify from a person who developed virtual machine or or ethereum node right okay from how it is executed yeah it's different yeah that that's that's true that's true uh but that's kind of uh on the compiler side mostly

right it's not it's not something that would be visible to users explicitly most of the time yeah I think the people who are affected by this are slity developers and whoever is building the VM for each of the clients so I don't know who on nethermind team build yes the VM but they'll have to deal with this heavily but I think you're right my guess is is that if you're just building the client itself not the evm portion then it's probably almost no well we are building the our own evm all right so I'm saying like you got I don't know who on your team works on the evm or if you guys all do uh it's all it's always team effort right so I don't want to put anyone and uh I think a lot

of people are adding for example up codes for different the so we have it fairly a lot of people are working let's say but we have some Specialists so probably Iman and Ben are uh the most specialized at the moment Ben maybe from more from the performance perspective uh Iman actually if anyone's interested is building something that we call I evm it's uh I is a net Intermediate Language so net bite code you can say so we are trying to also compile uh the uh evm to to net code uh like evm contracts evm bite code

and we will be able to do it on the Fly for example so if we like find out that some uh something is becoming heavily used we could potentially even on the Fly compile it so isn't the problem with or the challenge with that um gas accounting no not really how how do you do gas accounting because if you if you're compiling yeah but so like a a big part of what the evm does is gas accounting like when each op code you execute you have to account for its gas whereas if you convert the code to ilil and then run it inside the CLR for example CLR

doesn't keep track of which operations actually yeah yeah we will have to emit code that does g of counting right and in there yeah yeah would you just maybe do like uh I guess add tracers or something like that and then just track the tra the CLR tracers or something it's always been like I've thought about this in the past like why why why build your a new evm every time I think about it it's all and it's like why not just use the jvm or the CLR or something which already exists seems much better and the problem problem is always gas accounting like that's always the thing that makes you say oh this is why we don't just use ex I would say

I don't think so it's just easier to build something right there's a lot of right now experimentation with compiling bite code and it's a good way of having additional uh layer and of abstraction and a lot of evm op codes like completely are not easily transferable to single or even multiple instructions easily so yeah it's I would say it's more of a ruction problem like the gas accounting is just adding integers to each other so it's not a big deal you're more optimistic than I am I'm curious to see how it goes though if

you can pull it out that yeah we already have everything I think every up code compiling but uh uh we had have now a bit of setback because Iman who was implementing this is also now switching to back to UF because he was the one working on E most so it will be probably delayed a bit due to that because we need to make e uh stable first before we go back to that and we probably will need to add eof to ilm that will take even more time so yeah okay well I'm very curious you guys succeed at it that' be awesome um well I think we will succeed the question mark is what it will bring and

how much optimizations it will bring how much the CLR has many many more people working on optimizing its performance than nether mine does so as great as you guys are I suspect they will be better at it well I think the main thing is the branching right we could because basically when you interpret uh evm by code you have a big loop that interprets it up code by up code and if you just emit them one by one uh uh and then potentially you can have a great optimizations right on the prefecture side Etc uh you eliminate a

lot of jumps right from your code which can be the main boost yeah working on working on the most of Coach already so that have you been doing testing on the performance of uh so yeah that's why I was asking for that but no we haven't been uh the I think the the part that's uh currently being finalized is also interrupting between the two versions because uh we don't really want to uh do compile everything right it doesn't make sense to compile everything why not is it it will take yeah it's

quite expensive it will take a lot of time it will take a lot of code so in terms of bite code right we have like what few gigabytes of code deployed on the Chain so if you compile that and try to load it into memory right it's like you would have to unload it load it unload it Etc right you could you could just say save both the so on chain currently you have the in in storage on disk you have the evm B code you could have a copy of it that was the pre-compiled one so anytime someone deploys code you just immediately uh jit it down into CLR I and then you load that off disk

instead of loading the evm by C off this like I said to be honest it's still a bit early to to how it will evolve uh but a lot of people are experimenting with this so we'll see okay I'll follow along also ref is experimenting with this maybe not even ref but rvm uh who else is experimenting uh a lot of other like P l2s are experimenting with with uh compilation and Native Native code execution so we'll see how it goes I think it's it's pretty doable

right it's just fairly complicated there just doing Vector that if you compile everything always then someone just make some just deploy huge amount of contracts and and Ne mind would be just compiling everything so you would probably wouldn't want to compile everything yeah also there's latency right if someone uh deploys a new contract we don't want to compile it right away because latency of compiling will be huge we want to if we will be ever compiling uh and we will probably be even live compiling based on some horis we will still want to do it in the background threads in the background right not maybe even not even doing actual block execution but between

blocks uh yeah they're doing it smart way yeah I think the best way SS that you always run the EV and bite code as it is and then you have some low priority thre that is compiling them all the time and then if it's available that combined version then used it yes exactly something like that because we always want the lowest l and see on the evm mhm yeah yeah there's a lot of a lot of details uh it will took us a you know more time to to get there but uh a lot of interesting things are coming I'm also experimenting with parallel

execution uh we give you an updating in in for evm yes yes for evm I have it in my model so we recently are introduced or are introducing because the final version is not out yet uh that we run transactions in parallel uh and what we use it we don't we discard the execution results at all but we use it to populate a big cach uh of state and then when the main thread runs in uh uh the trans actions most of the state is already populated so we we have all almost well most of the state

populated right that's how we achieve our newest performance increases how do you can pre populate state if you haven't run the transaction yet well we run it in parallel in the background threats and you assume that those transactions are not affecting each other or well we we not assume they are not affecting other we run them on um like a copy of the state right or similar like you do with eth call right you run it on a readon copy of the state which actually loads from the main state right but then if that one transaction is affecting the other transaction then you canot run those transaction parall

yeah yeah yeah yeah so it's a yes yes so like I said we discard the effects or the results of the execution right we just uh populate big cash that then is being used on the main thread which uh again invokes those transactions in in order in single threet like like it was before Oh so so you just get everything in the cash that you need to calculation you don't yeah we try to yeah we try to load as much of the state we need in the parallel and just uh run it in the single frit with as much State populated and we are getting on a very fast

machines around 700 megag per second sustained because Peaks are like we had a peak of two gag I think uh but sustained is around 700 meas on on a very fast machine but I guess you can have transaction that refer the next trans or previous transactions and then the gas that they bringing is kind of completely wrong because the yeah yeah yeah yeah exact so it's a you know it's a heris sck right you can see it's not a guarantee just you're just trying to warm your cash yes exactly you're trying to spend you know 30 threads at the same time all warming the cash rather than one thread that's warming the cash and executing at the same time exactly at

the moment but we will be trying to uh now evaluate if we can use the results of this execution and instead of executing it again just uh just committing to that state right so we will be now trying to add intelligent transaction Collision logic and see if what we you should be able to so if you keep track of keep track of the state you loaded in each transaction and then when you get to that transaction in the main thread you check to see if the state that it loaded is has been touched by a previous transaction if not then you're guaranteed that it will execute the same right uh yeah yes but we want to make it

a bit more complex so we will be trying to evaluate if the transaction needs to be re-executed uh earlier and re-executed in parallel again right oh I see okay way before the main thread catches up so so as as you're going so you execute all of them save the starting state for each and then in order you iterate through them and say okay this one runs it touches these states therefore we keep the next one we keep the next one and you can save them all and then figure out which ones you need to rerun and only rerun those yeah yeah but like even those rerunning can also be done in parallel right uh if we

figure it out potentially yeah it's a complicated it's not that complicated but it's from the code perspective it's not that simple a lot ofl code Etc how do you basically need a ram disc for this thing for your disc to keep up no no no fast is fine because it's not about uh throughput it's about latency right so uh you can have a lot of uh lot of parallel uh nvme Drive access it's not a big deal it's just this access will take x amount of milliseconds or nanc right so uh if you're doing one one

access or 10 10 times or 100 times the access it's like the cost is almost the same so it's actually beneficial of doing this on nvme drives and probably generally ssds is this just because nvmes are so fast because like we're talking about they they are they are kind of they support like parallel fetching in some ways right let's see so you're leaning on Modern drives having the ability to do hyper ization yes exactly this is something that would be nice to have in each symol as well that you could make multiple parallel blocks so that you can simulate a lot parallel stuffs and those wouldn't affect each

other well parall blocks or parallel transactions in blocks I'm not entirely sure what do you mean so that you have creating multiple parents for the first block so that you could simulate multiple stuff that kind of would be conflicting each other but you could simulate it parall so it wouldn't affect each other but that's basically same as sending multiple multical reest I feel I feel that the not would optimize that better if if you are sending S no not really it's way easier to just send multiple uh requests so right now we are not bringing this uh this and I doubt I doubt we will ever

bring uh this multi threading into uh RPC calls unless you will explicitly maybe enable it and it's your private RPC that you want the fastest execution because if at any point you have multiple users you don't want probably one user to uh consuming too much resources oh yeah so in in like if you have any kind of like public RPC you don't want to spin all threats for one user it's wasteful uh you want to have you know load balance users yeah uh yeah so this is mostly for Block

processing and potentially block production and nothing else is anyone working on the state rent I feel that we are all the time making eum bigger and bigger and and this is also making that the resources and then no not at the moment but I think uh I will be looking into some ideas of reducing State I don't remember the state rent I I remember State expiry is it the same sim kind of similar like I think for example good idea because the blobs are expiring and they disappear but then that's only for the blobs yeah state state X was the Su successor to State rent State rent was

deemed too challenging because because we didn't start with it and so we can't get rid of any of the Old State where State xur lets us get rid of the Old State which is really nice ah okay okay the problem State XPR was address space extension we need bigger addresses 32 bytes ideally and U and we also need to address this extension for other reasons like just the hash Collision on 20 bytes is going to get dangerous soon and so uh but address add dress space extension opens massive can of worms in the evm um because addresses are used internally and they're assumed to be 20 bytes and solidity does some optimizations on how they do that and so you can sometimes sometimes end up with garbage in the

first 10 it's not always zeros or sorry in the first 12 it's always zeros and so uh address space extension was ultimately what blocked that last I checked okay I wish someone could solve it like the state X conceptually I think is a great idea like everything is great about it we just needed to make the addresses bigger so and that was where we got stuck we couldn't make the well I don't agree that everything is great about State expiry but it might be the best thing we have I to be honest I don't like it but it's like I don't have any better solution at the moment why don't you like it no well it provides pretty crappy user experience right because your state

is not there it deletes your account sort of it makes it so your the average RPC node that is or light node whatever you want to call it um may not have the old data but any the if you do have an account with the old or an RPC with the old data then everything will work fine your gas cost will be a little higher the first time you when you're restoring old data it costs quite a bit and so there is like from from an end perspective my hope is is that most end users will be communicating I guess my hope is is that that we can build something in so that

if a node doesn't have some old data they can ask a peer-to-peer Network for it like ewm or just some other gossip Network or something that you can be into unless portal Network solves the state oh yeah portal can do it then I'm then I'm happy to to go with it more right but the last time I I talked with portal Network guys they said they might be able to launch the state Network on Portal by the end of the year and I don't know how realistic that is uh I I would expect next year maybe for the state Network I think this year my I'm hoping they get history this year well

the history is supposedly already working but oh sure but not not in production like I'm hoping by the end of the year I'm hoping it's stable and working well in production yes yes yes for example so we'll see uh we are trying to build something but we are trying to build too many things at the moment we'll see how it goes is the so that you have to poke the addresses or the data and then it stays available for like six months or something like that yeah six how whatever the the Epic size is but yes the any data that's not touched in a certain amount of time will expire out and then you can bring it back with a proof can you POG it multiple times to

to the extent of time or you just need to do it periodically yeah you can just so you just every time you touch if I remember correctly every time you touch the data it moves it back to the front of the line basically so do it do it right periodically if you want your stuff to survive yeah okay yeah I'm like yeah we need we need a good backups right it's I don't I don't like waving H some node will have it right me will but you know what if no nodes have it or what if you don't have access to any node that have it or something right it's like this is pro by waving

hands so I I kind of agree with that um there's two reasons that I'm okay with it in this case one reason is is because this is a single honest backer upper requirement like as as long as one person in the world backs actually has all the data like keeps an archive node running then the data does exist out there and you can figure out how to get it so in theory um it's a very low bar right and ethereum already has you know many people running full archive nodes Which is far exceeds what you would need for this and so I'm not too worried about everyone losing the data and then the other aspect is is that the problem that we have right now is no one can run a note at all and if this makes so so people can run nodes then I'd say that's

a win just in terms of trading one bad thing for a less bad thing well Micah uh while I agree some in some way I think you're too fatalistic in some of your statements or too absolute like I know a lot of people that run notes so are any of them not core developers uh yes really like all the noncore developers I know no longer run nodes they used to and they don't anymore I no longer know any anyone that's not a cordev that runs a node anymore I was the last one and I quit okay reason I quit is because my server server provider screwed me and blah blah but it was the last one of in my Social Circle okay but it is possible uh yeah

so maybe if you're kind of if your uh wallet would automatically backup your data makes sense I mean if I was building a new blockchain right now it would be a ZK blockchain and storage would actually be each user stores their own data and so on chain an account just has a hash of the data and all you have to do is prove that any mutations that like when you update that hash of your user data you all you you do is you provide a proof that says I updated the data that results in this hash according to the rules of the blockchain you don't

have to even tell anybody what you change all you do is you say oh my my user data changed and here's the new new hash of my user data and the change was for the rules and so in that case this is literally users store their own data and you can store it wherever you want presumably your wallet has some mechanism for backing it up and you know encrypting it and putting on Google Drive or whatever it is but the idea is is the blockchain doesn't store any user data it just stores a hash of user data and then you can do things like make it so um contracts can have per user storage so tokens for example would associate your balance with user accounts instead of having in a global shared space as an example and so I'm a big fan of users storing their own data

and like you said for stex free I think you could do something similar with enough effort and design yeah that would be kind of think okay uh yeah we'll take a look at it but I don't know when yeah maybe some some sometime late this year I thought nethermind had like 400 people in in the company is that no longer the case yes but 30080 are slacking see okay sounds sounds normal for a company I'm joking a bit but uh car development is not not you know it's

maybe 20 people okay and you know not not all of them are seniors or anything so uh yeah oh that's right you guys hired like 200 uh entry level people interns yeah we we we do we do allow a lot of interns uh actually I think it's a very good uh way of uh of the growing the company and and the everything so I I I'm actually all for it if you can afford it I think it's a good idea it helps people helps the new people and when they do they often stay stay in the company and then you have someone that you can sometimes get for cheaper

long term but you need to have a good Runway to do that okay okay let's we to off topic sorry yeah cool Good Start I guess don't have anything else yeah see you guys see you bye uh can you can you write a summary also for like on the chat for the transaction type I I already pinked him about it but maybe you want to maybe I miss something yeah I can can say some coach somewhere with you're making okay this

is also recorded so we can okay so he can just watch it okay cool yeah but I would also like to understand what are those rules I would guess it's they are not that complex but maybe there's something it should be simple if there's something about blob it's a blob transaction otherwise if there's something about otherwise it's probably uh EAP 1559 transaction that's probably pretty much it by Def gas price if gas price is defined and Max is not okay then it's a legacy otherwise it's a 1559 mhm yeah okay we'll get that in chat for like

yeah okay see you see you guys later