All Core Devs - Execution #32

Transcript

[Music] [Music] [Music] [Music] [Music] [Music]

[Music] [Applause] [Music] [Applause] [Music] [Music]

[Music] [Music] okay I think we have enough people in here we can go ahead and get started so

let me see where's the agenda all right the agenda is pretty short today so we can if anyone wants to go and do a lot of detail about their stuff feel free the first item is going to be testing updates is anyone here who can speak to just updates on testing anything including fuzz testing or some stuff Dimitri usually does so Emerson team was using the same framework as the consensus test and the new users of test

test stood and they met they saw many problems regarding the user experience of the test Esther the reported problems and Dmitry has been fixing them thank you regarding Foss testing and the hype testing we've had to move all the

infrastructure from a short to AWS and getting it up again and Guido has now joined us on the DevOps side to help run the passers and maintain the new infrastructure so it kind of yeah hope we go kind of relaunch the kasnian purchase soon as possible great that sounds pretty cool and um Tim and you know Ichi do you already have a contact with each other if not we can just share that info on get her yeah Amy's email should uh sure yeah yeah

perfect cool any other updates for testing okay so the next item is gonna be fork release management like when we're gonna hard fork again and Constantinople so the very first I guess some point I probably should have put some points in here are what a IPS will be going in so unless someone wants to start out with a different topic I think we should kind of discuss what EIP should go into metropolis so then we can get a better idea or sorry into Constantinople so we can get a better

idea of when it will happen so I'm going to the EIP page right now let's start with the account abstraction the IP 86 right now I know Vitalik you had a III search message post about a month ago that you said was getting some replies about it do you want to go over what came of that conversation yeah let me get the link there we go I got a lot of replies so this was the concepts direction specifically in the context of sharding where there's less backwards compatibility requirements but like

basically the main proposal that people is so far seems to like the most because involved basically in all the one the pig ass off code so the idea here is that there's in that there would be a new approach called Pig ass which would have two functions one of them is paying actually like actually hand for guess and it would have like built-in functionality to be refund that any unused yes at the end and the second functionality that it has is that if a transaction arose before the pig a stop code has been caught at

any point then the transaction is totally invalid but if the top-level transaction execution throws after pig that he gets off would have been called then the transaction is that was and the purpose of this is basically that said of any execution before the pas opcode is like execution that should be considered as kind of part of a to clarification so we will include things like signatures that are liquid no nonsense in some cases might include more things and anything that comes after the pig ass off code is very kind of part of the full execution and the way that miners would generally work is that every miner would privately is

choose some threshold of gas like possibly 100,000 gas could be something else and anytime they receive a transaction they would have run the transaction execution for up to that amount of gas and if the P gets off code has been called then we know that the transactional pay for itself and over animal running folium though included but if it has not done albeit in the transaction and so this basically kind of substitutes the distinction between like prevarication and full full transaction execution but there was another part of discussion which has to do with nonsense or in protocol nonces versus not in protocol not having a protocol nonsense in the context of the

shorting discussion really omits the leading toward not doing that but in the context of outside the shorter discussion that would have a much higher transition costs because it would involve moving to trans transactions potentially appearing more than one time in the blockchain me and so make in the context of the main block G and it might be said so I do they do to pay gas proposal but then have like a have a separate in protocol non-tariff ocation mechanism so no question about the the public with the pay gap it's not possible to pay for gas with the earth when it tokens and stuff like that right correct it not and so what abstraction benefits what concrete

abstraction benefits are there okay so number one AB signature abstraction so you can use whatever TIG is your scheme you want number two like replay protection abstraction so like nan says you CXOs like one particular example is if you have something like let's say like a ring signature mixer contract then like a ring signature mixer contract is going now it already has its own replay protection because the linkable ring signature mechanism itself prevents you from using the same key to withdraw multiple times but if you try to force that kind of contract to have nonsense then I'm like you're going to have a problem because you're basically

if two peoples in this transaction around the same time then if one gets in the other we'll have to update the transaction it also lets you do other stuff like it lets you potentially make preview occasions much more much more complex so one motivating use case that I was thinking about was like ICO is where if you have an IC o---- where let's say there's a hundred thousand people that want to participate but there's a cap and so after the first twenty thousand no one else can join then but the status quo is basically that all hundred thousand transactions would go in but the last eighty thousand would just basically turn into no ops whereas with this scheme a five hundred thousand but if the verification in the ICO contracts

could be made to be compact enough which it probably could be given that like checking a number against the threshold is it more complicated than a signature then you could actually have a scheme where the 80,000 transactions that don't make it into the ICO in time actually we don't have to paper to see in those makeup gas-phase but yeah you're right is not it like this is not let you pay for gas with GRC 20s so 86 derivative and please consider the for Constantinople and is it still relevant so the Inc page with me this Deeb's

referred for Constantinople and if 86 86 is not considered anymore that should be replaced with something else and if people want me to make animation it for this abstraction but also I can probably make one yeah you probably should if you want it to go into Constantinople I'm not it does this need it I guess I guess the question is does this go into constants no um yeah I mean one click so one question for developers is like basically it how much development effort would this you know how much development

effort would this take and would this kind of possibly detract from other things you know so I seen you you've wrote about this proposal at the research right I put the link in the Skype hold on I don't know if ever evolve developers Revis I haven't read it last week professional memory but you might want to post it again so people can read about so crumbly the answer to my question

would be the cat6 might be replaced with something else because I mean at most one of those proposals in its research would be identical to 86 so might become something else yeah I would say at the point like I'm like fortunately I'm not super interested in the 8086 but I see yeah I think we mentioned that on some early record of : I can't remember which I think it was kind of generally talk said that the e36 is not won't would probably not be included and that we

talaq instead would write some other proposal or proposals which are presented on at research maybe we can kind of done grade eighty-sixing okay here um well I actually did not eat me I did not even be 8061 at all before but I guess the main difference between that in this proposal is that this proposal also has the mechanism where if a transaction exits for a guess then it's invalid it executes after it's valid and look under coupling with a key on abstraction so it does more things

so how long so it's actually invalid it's not just doesn't papers up yeah so if what in my proposal if each transaction exits execution before a pages opcode has been called and like you could even be called like tes with an argument of 0 if you don't want to actually pay then maybe if it gets if it gets executed before but before that happens then and the transaction fails then it's like that transaction is actually not allowed to be included on block all right s let's see here so I would also italic I would also add another restriction because I can see

like this could be used as the attack vector so I would add the restriction that before the pegas instruction is a code you are not allowed to access the state only the local information from the transaction that I that I basically because like there are a lot of the motivating cases that I think about actually require you to access the states before in order to do like various checks so one example would be checking the nonce another example as ICO is this ICO example another example is the racquetball thing is your case like all the interesting ones require you to access the state before they guess okay well look basically if a minor is concerns of L dog vectors and

ovation so the the simplest response would be to just decrease the amount of gas that it's willing to execute yeah it makes it makes it will become a bit more complex for nodes to validate that transaction is violent that no I agree with that oh yeah yes our own suggests that if we have let me have make it into neat but have the continued discussion almighty mmhmm yeah I agree I don't think I mean unless any client devs want to give any kind of estimate as to the amount of

work required for this I don't know if we can today without an e but if anyone has any other comments on that feel free mmm and just so that I make sure I understand is this the is this the type of EEP that would allow contracts to pay for themselves perfect okay so any other comments on specifically that one it looks like we're retiring 86 or removing it for at least from deferred and then metallics gonna write a new EP outlining the new pay gas plan potentially great any other comments or maybe it's a good moment to

clear up this deferred heap table so if nobody has a comment on 86 we can move on to there are two more like 96 it's the brokerage contract thing the third one is the bitwise ship shifting and yeah I want to ask if you know the people that still pushing these for actually thinking about something better yeah so the first one is a IP 96 block cash for factoring from Vitalik and that is on deferred that was gonna be we were thinking that be in Constantinople does anyone have an opinion on that or Vitalik cuz that's something you still

want to push for constantinople don't have to destroy abandon either way I don't want to speak on the that's a batterer and I personally think that at this point it's the lower value than either Casper or abstraction or just spending more time researching ways to make to make your client of limitations 5% faster anybody else have a different opinion yeah actually I would like to do see it being big shipped because it's

it's more aligned with with removing some interesting for EVM to external contract like some kind of precompiled contracts or that like removing features from from internal EVM to be available address on the smart contract which will it's easier than shipping that solid so now that I think about it I might have changed my opinion there the reason why is that I think it might be good practice for the much bigger round of kind of EVM code being a base protocol feature was that we're going to

introduce later which is the counselor contract yeah yeah that's that's what a good exact small example to test this approach yeah I agree with that we would like to include it in the he wasn't tested wouldn't be requires changes we add a secondary payer to contract where the person who signs the transaction is not necessarily the one who's paying for

it but there's there's a there's someone signing John with the transaction and someone else can just post a transaction on the blockchain and that person will pay the gas that allows more flexibility where I can sign a transaction send it to someone and that person basic s transactions but under my name I think my my my might change less things in the VM and on the on how we expect contracts work and it also is similar to help a lot of contracts are doing where they just sign a message and send somewhere off chain I can try to just write that down and sort

the discussion or IP maybe this is not the place for it yeah and you said that was the IP 61 right or 86 well Alex did you say that was a yet for e IP 6100 got it got it 186 okay cool yeah and after you when you do that comment just put the common in all core Deb's and I think that would be good let's see so that kind of went over 96 a little bit metallic you said you changed

your opinion to where it's a little bit more important and that's and the awesome team kind of feels the same way it sounds like okay so is there any comment on the level of difficulty for implementing that or is that is that and also I guess the better question is that a IP fleshed out at this point or is there some unanswered questions within the EIP for design and implementation questions if okati is not that high I saw requests for city pigeon and gates and it's not big it's kind of on a particular block we have to deploy at some code and after

that you have to run that on every block yeah I mean not that big and then the second question was oh yeah so and you just answer the question of the amount of difficulty mine was the this design issues remaining or not so a little bit more efficient version he was preparing a little bit more efficient version and so it's it's purely about this endian byte code that will be deployed and it's

a little bit more efficient storage usage but it's very little bit so when we were planning this for an immediate fork Vitalik once judged this tiny improvement tiny optimization is not worth it if not it's not that becoming this optimization can be considered as a I think okay and that's you said from based on pals comments based on well I

had some conversations with him and yes I saw his comments okay so I think there was like on the way there was like three versions of the contract like one was from the Thai coordinate and I did some change proposed some changes there and then was another one that was a bit more generalized and includes everything in some kind of tight loop so I don't remember exactly but I think we just have to review that code again at some point and yeah but it's just 1 1 1 notice from me is that like that

centralized efforts to have this bytecode ready so it doesn't like it's it's not included in the developers time for actually implemented in clients ok that makes sense so you're saying it would save developer time if we collaborate create the bike part of specification so like whatever code we'll agree on in the end it doesn't like affect the client's time spent only implementing that okay understood yeah I think that's good

ok and then lastly on this I mean there might be other comments but specifically from me this EW which one oh the IP 96 Piper I saw that there was unmerge in the last month where he refactored the vm vm state and blocked of new apply transaction did you actually and it referenced this AI p did you actually already partially implement the CIP this is gonna be me code reviewing one of the other dogs working on sharding is gonna be the one who actually did that work I'm scrambling real quick to pull up

what you're referencing I'll paste it in thank you yes so we are quickly working towards having a here apply transaction concept in PI ABM essentially getting ready for statements clients getting ready for being able to run it under that paradigm so that is moving along quickly and we've got a lot of that into the core library now we're kind of back porting these things from

the sharding branch into kind of our main branch as they seem appropriate okay thanks that answered my question perfect any other comments on 96 or 86 and because we'll move on to 145 after yeah my understanding on 96 is there needs to be more collaboration so if some of the people who discussed this Vitalik powell yo ichi others who've been involved in the conversation for e IP 96 if you all could start rehashing that a little bit and getting a more

formally IP that'll help us the next chord AB meaning okay EW 145 bitwise shifting instructions in the EVM that was Alex pairs Ozzie and pebble so if one of you guys could kind of comment on this kind of just bring up what it is again and if it should go into Constantinople about whoever's explaining it might be muted yes so so the the AAP it's it's ready and has been marked so it can get an

hour round of peer reviews and we house of have the CPP implementations ready except we need some some way of configured the client to actually include this feature in the VM so it can either go with the some kind of fake constantinople fork or can be some separate configuration that enables only this one that that's that's the only thing that hasn't been done yet and and we can start after that we can start making tests and so on so okay so it

sounds like you one more aligned implementation would that be correct to say you need one more client implementation to have like a little mini test net you can run with just this change I don't show it deserves a test net but we at least can have a classic JSON test for this case and yes so some some if implementation would be welcome if not some of us can actually jump on and implement that and in go probably so shouldn't be like big deal considering it's using only some additional functions from from big big number

libraries okay Alex did you have any comments there is also supporting solidity for it okay nice yep I see that it's listed under implementation in the EIP great and it would be fairly easy to support it in the JavaScript VM if if the number of client implementations is the limiting factor okay sounds good usually at least for a ip's getting

accepted there needs to be a few implementations but if it's on its way like there's implementations in progress that can be considered as well as it's kind of how we've been doing it as far as I can as far as I understand okay so any other comments on 145 yes could we please have the test cases expanded because it's really annoying when you have any IP that even though it's kind of trivial if you don't have any test cases it's just like shooting in a dark and hoping that it kind of works okay I don't think we have a proper rule yet on

the test cases because with some of the Byzantium oops and some people started to put a couple of test cases in the eeap's itself but then all the other useful test cases were written up we test it and none of those reported back to the ape so I'm not sure where test cases should be located I'm not saying that the test cases should cover all the all the color cases or two it should be two exhaustive but it would really have if there would be at least a handful of to three however many test cases that just kind of covers some generic use cases so that so that I as an implementer if I

implement my code I can actually check it that it kind of seems to work before even getting to the point looking it up and merging into into master it's just kind of nice feedback for for implantations yeah I understand yeah we'll do it okay I think that's the level we had in the revert EEP it only had like one or two test cases just a successful one and everything else was that tested by the big test suite if that's acceptable I mean for this case I think we can like have like like up to 20 it should be like big deal to also cover some negative cases I mean

it's it's I think it's it's general practice to for example having some hash hash functions example tests included in spec you think that in this case that should be should be fine to have them as a part of specification could you repeat the last part of that question Tim it's

hard to hear yeah sorry about that I was wondering if yeah there were a test case in the theory and test repository I had assumed there or not I think there are no tests for this one in the test repository the main blocker is actually there is only option to actually include them in some kind of new fork configuration or new network name and so on so like there is no way to actually have some separate

but I think there is no good way of enabling individual features separately we figure out how to actually upgrade this the test to be able to do it this way yeah it sounds like there aren't any in there right now but there definitely could be in the future I think the way it works if you figure even like a

fourth name tentatively like Constantinople then we could merge it in this IP client and test it could generate the test cases under the Constantinople for claim for therefore the bitwise shifting but it needs to have a name in order to generate the test yeah I think that's why we are talking about it here so that so that we can have a reasonable expectation but Constantinople would be and then we can start doing that so this e IP seems like a fairly trivial one so if we consider

adding it then we can consider adding it to the first upcoming hard work so unless anyone is anyone is actually opposing adding the the opcodes I think it's fine to add it to Constantinople yeah I've never heard anyone opposed so I'd say it's going in cool any other comments on 145 I guess the next steps are to work on some test cases for that and how people review the EIP again now that it's been edited a few times mate potentially since people last saw it is that accurate or has it been pretty

final for a while Alex or Pavel it's been final for two years at this point change like six months ago the operands were swapped and we discussed it probably five chord F meetings ago no changes since sounds like it's good to go then cool in that case yeah well just say it's going into Constantinople unless someone between now and the next coordinate meeting has any opposition sounds good and we know what we're working on there so that's it for the deferred AI peas

table so it looks like from that conversation we have 86 going to be replaced by something that metallic will come up with involving pay gas and potentially some other things 96 what do we decide on with 96 I forgot what into doing it yep that's what it was we're gonna yeah basically look at the EIP and add some more detail and then and then 145 that's gonna go in cool are there other AIPS that are not in the deferred table that

people are interested in including in Constantinople that they have handy if they don't we'll talk about this thing but yeah probably the ones that have to do with I can't clean up so I think it was deal 169 170 okay and I think I think something that we should do between now and next meeting is just talking the core dev meeting about the list of the state clearing ones and which one should go in and can you remind me again just in a nutshell once

what 169 170 I think is the ones you just said what they do so one of them is that if an account if it accounts balance drops below like twenty one thousand times that transaction gas price and then the account disappears and the other one says that if like when you create a new account the initial non has to be like be like it instead of being zero it's some different number and like that basically just does replay protection in the context of accounts being able to disappear sometimes replay okay so when you say some other number

like a random number I know it looks ugly a grenade encounter okay or something right yeah you know it's either the block number or it's just like a global counter that's like the maximum amount there's ever been okay yeah between now and next meeting let's get those together and we can discuss them more next meeting after some people have had a chance to read them unless anyone else has comments on those right now are there any other AIPS that should be considered for Constantinople that

people have thought about for today and then additionally do we want to start doing somewhat of a timeline or kind of even just like a rough quarter one quarter two quarter three or quarter four for Constantinople guessing not P 1 because that's we're in the middle of that right now but is this something that could probably be done by you know q3 maybe I need anybody have an estimate or do we need to kind of flush out the rest of the EIP s before deciding that yeah that sounds good

we can do that more so by next meeting and I still like the idea of timing it so where we have like a month to decide on a ip's multiple months to implement multiple months to test and then release and coming up with coming up with some hard timelines on the on those goals and those milestones so we should hopefully by next meeting come up with some Moree IPs and I think that that will help us start formulating how much time we have left okay any other comments on Constantinople VIPs that stuff

okay I want to go back to testing real quick because Dimitri is able to join us so Dimitri I know you left a comment on the agenda about test optimization do you want to go over that a little bit or describe it yeah hello we can hear you again so I was working on this test of optimization I saw that we have many tests that you just ran because of our previous optimization that every test case is being executed on every fork but now we have another fork and another four can we have like hundreds of tests being

executed and the most of them are just wasting our time because example static old tests have been executed on all Forks but we don't need to run static old tests on frontier homestead and as an as a hard Forks which do not introduce this opcode so I want to remove those tests and it will actually change that test format what clients might not need to implement any changes actually because it will just remove the post some post states from the test and let's eat it's mostly for diet Escalus so now I plan to create a test from a

test filler for only those networks that specifies only those networks means Forks networks and prongs I specified an expect section of the test filler so when you create the test you could specify on which Forks this test will be executed Demitri this is piper one thing that is good that we should try to make sure that we maintain is that the tests are still verifying that like the static call opcode doesn't work in frontier because I know that that was there this is another test case we could just we already have a test it

execute all of the opcodes on all of the forks that was done by by Jared yeah and it basically checks that every opcode it tries to execute every opcode on every fork and see what's what are the results great I just wanted to make sure that that protection state yes yes but this is only one test case you don't need to execute every possible situation it's a static call on frontier you could just try to run it and if it receive that it doesn't work and this is one test case slimming down the JSON test suite sounds wonderful it with we have you know like an hour and a half long CI run or something like that for largely due to

those well also we have a llamo support now implemented so you could develop test fearless in the amo format that's great news awesome any other testing updates from anybody mmm I think if you yes awesome upgrade is in research like oxic is working on awesome source code integration to test Villiers and test it could already compiled some of the code but it's not being passed by EVM just yet

okay let me see something real quick there's just a comment I'm checking on yep so yeah that is the correct decision actually axe Academy look at the comment on the agenda about the EIP 145 decision and yeah that that that is exactly what we came up with need to include a couple of test cases and start having clients implement if that works let me see what's the next item on the agenda oh so someone on the agenda asked if we'll see

short-term scaling improvements with death 1.8 by increasing the gas limits without having the uncle rate go massively up I don't know if they understand the correlation between gas limits uncle rate and the client updates but we'll probably just go into client updates right now so that we can get all the updates from gath including their 1.8 release so let's see if 1.8 so Peter yeah if you want to go first with Jeff yeah sure so I think the question kind of was referring to whether block processing will speed up enough so that

so that we we don't see a lot of phone calls out there so I think it's kind of important to know exactly what we aim to ship in one one eight zero and so one of the problems currently with death is that once you think you do a fast sync which consumes whatever amount of disk space the current the theorem state consumes but afterwards gets kind of acts as a full node which means that your state you kind of act as an archive node from that point onward and then the state kind of just blows on your machine and eventually your machine slows down and what we are actually working on currently is to do an in-memory

state pruning so that we to actually keep as much of the junk in memory only and clean it out in memory and only flush the disk periodically or if we're actually reaching critical memory usage or something and what basically we haven't done any two scientific measurements yet so we started on importing the entire food chain it's it shows it is promising we also started some benchmarks really preliminary brand benchmarks on the main net and as far as I can see it it reduces disk growth by about eighty percent so that's kind of really nice

but the answer the specific question posted on github whether this will have on correct or not so this will not speed go with theorem up but it will actually prevent it from slowing down or at least slowing down so too fast so this is a in my opinion it will be a very welcome change because then you don't need to resync so often maybe just five times oh sorry uh one fifth of the time and we're also we also have a separate or request or a proof of concept experimentation to actually implement full garbage collection too so that so currently what

we do is that we try to minimize the amount of junk we write to this but we still occasionally have to write to disk to flush out from memory and in a follow of work that's probably going to be one nine zero we will I really hope that we can actually get full garbage collection implemented so that even past the junk that we had to write out to disk can be cleaned up afterwards so that definitely won't come for the next release but I would really like to have the next release much much more stable one and much more usable one than the previous ones so that's mostly this the scalability fixes that we were working on otherwise there's a ton of work going in on various fronts like client

networking etc but you probably want to check out I don't think this is the appropriate channel for that yeah we'll just wait till the full release and we can go over all of the updates once that's happened but that's a good update and glad things are working out there next we're gonna have parody a free yes yeah we just released 1.9 today it's turned out to be one of our fastest clients so far I have gotten if we didn't expect that so we had a lot of

travel this broken walkthrough and database issues but they seem to be fixed or some resort so we are pretty satisfied with the current release yeah so for the future watering or snapshots it will be hard to maintain on this year Network you choose a growing state size and we are currently at the point where it takes longer for a client to generate a new snapshot then new blocks are mined in this window between two snapshots so the result is that there are not enough snapshots or not enough notes serving

snapshots under the network our focus for the next week's and want us to put water 422 light client development to and user experience yeah another thing we are doing is we're using you our user interface we are we want to reduce functionality and out correctly wallet already disabled notice it in her wallet and yeah we just want to we focus more on core technologies and last fundamental is to be also want to start

implementing customer support the customer customer support listen the next week great and a question are you still as parody still planning on doing their own custom database format I think it was like parody dB Oh a free I think you cut out can you hear us up I think we might have lost them okay we'll go to the next

client for now the next client let's go ahead and do harmony so Miguel yeah we have implemented our first version of Casper where node so the node is able to sync with other clients in their hybrid consensus network but by other point you need the Hyperion one or me I mean there's all the clients that already have a Casper implementation but we tried to test it in Casper a test

network we use the directions from alpha Casper to snap instructions post made by Carl but looks like that good nodes are not work in our something like that so I mean which is who who's the best contact or what is the best channel to ask about problems with that reach out to myself and I will both help and put you in touch with the other people yeah okay great thanks with Alec so yeah we definitely we'll try to test it offline

with the doctors which are also mentioned in that post but it would be nice to to test it in the live network also yeah that's are you have the day all updates hi okay thank you very much next we have let's see let's go with CPP aetherium so we have awasum vm integrated so it can run he was a mother yeah vm for smart contracts that's I

think the the only thing I would like to share in terms of CPP node I also released if minor if anyone is interested its version of the 0.14 and thanks for external all external contributors that make it happen with a very nice community der great etherium Jas no major updates on their MVS just keeping up with the maintenance pretty well great PI via cool so we are

rebranding and sorts so we're calling our client Trinity and so that's what we'll be referring to the actual Python client as sweet going forward we got started on the command-line interface like the formal implementation of that and are working as fast as we can towards I mean we're in an alpha release stage right now but the alphas are not really usable as a client and we're working as quickly as we can towards an alpha release that includes a kind of runnable node using that command line interface lots of works still going on with sharding and things getting merged

there like I said earlier we've got some stuff going in for being able to support running a stateless client that sort of thing and just lots of under the hood work going on to get towards a something that can be released as an early alpha okay good update thank you Aleksey with turbo goth or any of the other optimizations you've been working on yes hello so I'm still working pretty much full-time on this to forget thing which is just the moment is just an experiment but I'm

just doing out of my last kind of optimization and after that I will try to stabilize it and just run through all the tests so the updates I have been able to make think much faster and I have also noticed that the memory size does matter like I was trying to run through the spam blocks for example think with unconstrained memory like to keep everything all the state tree in the memory and it did actually go through that much faster than if you don't give it unlimited memory and it consumed about 676 gigabytes I think of a memory to get through that and then of course after the state clearing that the the the state

compresses again unfortunately I didn't get to run it very far because I need I still need to implement reworks so but that's what I'm working at the moment yeah so my plan is to just just try to stabilize it and see if it could be actually made work as a client that's it okay great let's see lastly for the list of client and research updates let's just go to research so Vitalik if you want to give kind of a overview of research updates specifically Casper and sharding I guess just so we're kind of up to date so on

the Casper side the Alpha Casper FFG test net has been running for a few weeks and don't eat the boy the chief says for that it has not been running q well mainly because we realized that like pi etherium networking is actually not good enough to like quick it's so key for connecting to the Tor network but it's not good enough for me getting a network all by itself without other nodes and so it's require and ended up requiring quite a bit of active maintenance and some firewalls and a couple other hacks they did to get around the fact that we're getting like 200 random Jeff and parity connections coming into each node um the NGO that

said the the Casper aspect of Casper where it's where if a blog is final like basically two conflicting watch should not be possible to get finalized seems to actually happen running in the network seems to actually kind of have agreed all along as to what the finalized chain is so that part is totally convinced totally successful so far is that kind of on the back on a bit of a back corner while we wait what what so we're trying to simultaneously optimize that and we're ready to kind of help other clients along and joining via the Casper test nest also on the sharding side quite a lot of work has

started and so there's quite a bit in the repo its mural nice Caribe oh here we are we're basically doing on the shardene implementation on top of Pi EVM the yeah there's a basic spec that is add over here at the this link over here which is and updated updated a lodge would and it's theoretically I think good enough as a kind of full spec of what meant of what kind of minimal stage one charting is going to look like and it's about and there's a like shell way I think has a something like a for phased roadmaps for

I get it forgetting it actually we deployed and it seems like kind of part one of these one is I get getting miss something like being already done at the end we expect like the next stage to be finished after a master a month in a bit so the main problem we've been working a lot on getting some of the auxilary changes so things like account access list account abstraction written into PI EVM and the weave of it and we've spent a lot of time on like on developing a new binary tree developing like what witness compression for the binary tree

right the next step will probably be actually getting like getting the Steelers clients logic was like thinking moving but syncing blocks and witnesses so we're working well and then from there we're going there and if try to turn it into AJ I was a working test what kind of test network in parallel with PI EB I'm getting both on or functionality working great that sounds good let's see do we have anything else on the agenda I don't think we do did I miss any clients or any other major

updates for people doing research oh I guess yellow paper recently there's been a lot of changes to the yellow paper yuuichi if you want to go for that so thanks to Kevin's license she was able to able to notch my product about the Byzantium changes into yellow paper master and there are enthusiastic contributors who we're fixing typos or adding internal hyperlinks in the document so it is they have started adding hyperlinks so that when you click

on an unknown symbol you can jump to the definition of that scene awesome any other client or research updates it's not a client update but we are approaching a stable v4 of web 3py which we've got some really nice new stuff in there Jason Carver the lead dev on that Roda a nice blog post covering a number of those but some of them are gas price API is that mirror some of the

functionality of the eath gas station which I think a lot of clients are either adopting and if they aren't they should look into adopting something along those lines because it is a solid algorithm for doing gas price projections cool yeah I saw that blog post I'll link that in the meeting notes after anybody else have any other updates clients or research does anyone have any other items that they want to bring up outside of the agenda items any other final comments otherwise we're

pretty much done okay well thanks everybody and we will talk to you in two weeks goodbye Cheers [Music] [Music]

[Music] [Music] [Music] you