All Core Devs - Execution #33

Transcript

[Music] [Music] [Music]

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

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

[Music] [Music] [Music]

[Music] [Music] [Music]

[Music] [Music] [Music]

[Music] [Music] ok everyone I think we're going to go ahead and get started today is the format video 33 and we look at the agenda first universe dynamic is testing updates so let's fill ahead achieve on that update specifically because he has an update about test everybody can hear me

yeah yes alright so this is so the C++ Jim had so many of the suppress regime at a meeting this Monday and so basically we split up repositories because the cppm

yes it's a giant the many of CBeebies ramen developers are interested in making it giant that can take on the world of the third world major Ryan but GPB grant is CPM repository contained also the code for generating the consensus tests these developments with emerald like projects in terms of the testing requirement so if we windows repositories compliant and

for the consensus test generation team there was new suggestion that the test generation should run using any client not just shitty precedent for that dimitri started working RPG based test generation so currently is station code is written in C++ and 88 recalled CPP clients functions but the next plan is to separate this disinterred different executables talking over an RPC so that test

generation can burn any client that suppose did this Takeshi methods Dimitri is figuring this out and meanwhile I maintaining Dimitri and I maintaining this tested upholstery so that new tests can be still generated have you already defined the RPC methods that will be required for this no it's still stage so the suggestion was made on Monday the Dmitry experiments the

direct like on Monday and today again so it's still very yo-yo I in the same vein we should talk and take a look at how we're running the consensus tests over JSON RPC for pi EVM so we have a full test suite that actually runs the JSON test Suites over over an RPC connection so it loads all the data with some special custom RPC endpoints and then test them using standard RPC endpoints actually that sounds great soul who is Dimitri because yes I mean different people proposing

similarly the king or methods is you know it's it's so we want like a small number of methods that can say doctor DG by the way we also had a quick chat in Berlin on Wednesday that it will be nice to have a have a discussion with a few people specifically about somehow standardizing these methods among clients so that we we can do something that's meaningful for all the clients I think on Tuesday that scheduled for Tuesday anyone wants to introduce um this one so for this one the set of methods is already defined so basically the method that's used by certain tests the

testings with possibility I mean so this is really the compiler being compiled a beam by the code must be tested in some client and currently it's just among stability and CPP serial but if other clients support the same method so tests can run on these variants as well and this works as a test of possibility as well as a client so it should be a wing meeting and four distinct set of methods unmounted is kind of already settled cool there any other comments

okay Martin you just posted about the hive test IP changing was there any other info on that other than the fact that I just changed no I mean earlier we are the URL has good map but at one points the dead link right now so in case people are wondering why we are not running high just anymore we are just of that IP for now that's it okay thanks are there any other testing updates that anyone wants to address okay

the next topic is a IP 867 so the IP 867 is a an EIP that proposes that we have a standardized etherium recovery proposal system or ERP so the recovery of certain classes of lost funds can be submitted so I'm gonna just go ahead and have Dan who's joining us he's five for D on github and the one of the people who proposed this so he can go ahead if you Dan if you could give an outline of what this is and then kind of an overview of where the conversations gone the past week so then we can kind of go from there sure so the that major outline of the proposal sort of came together as I

was talking to people in the recovery Channel so I'm with news economy we were affected by the parody multi-sig issue but I know that there's CIP 1:56 that was out there and there was a different set of cases that would potentially could be addressed through that there was some conversation on that issue about trying to include other cases but it seemed like maybe it didn't all fit together so as there was discussion going on in the ether recovery Channel I think in the context of the original solution that was put forward by parody that had suggested so maybe some ppm modification so I think the big difficulty with that was that it would

affect contracts that were already out there they had some ways to maybe mitigate that but it really looked like there was a lot of potential for unintended consequences with those EVM changes and so the conversation in the ether recovery channel is sort of started to focus on irregular state change in that it's something that can be well defined it happens in a single block the chances for unintended consequences because of that particular state change are smaller and there may be also some other things that we can do to help with some additional verification so what the we ultimately

came up with was that okay first of all we make the assumption that there are these cases that people would like to see salt and if that's the case you know what cases could be solved by an irregular state change and even what cases should be considered and then if we were to say okay yes maybe there are some cases these certain types of cases that could be considered what should that process look like rather than having everybody say submits a change to each client that's you know is it is going to be coded and it's going to be another if block somewhere in the in the code and it's going to be technical debt so is there a way that we

can handle this to minimize the amount of effort that's associated with each one of these recovery proposals and at the same time make sure that the verification process is is very clear so what we wanted was a transparent process that would allow some of these cases to be addressed and what I tried to do in the in the proposal was be very clear about the types of cases that could be addressed and specifically where you know there's no there's no one contesting the ownership of funds let's say I certainly would exclude any sort of case where someone says hey this guy I sent him some ether and he didn't do what he said he's going to do and now

I'm either back and so there's a clear disagreement between the two directly affected parties and so I try to say okay well what about cases where there aren't any there's no disagreement about directly affected parties it's really just that there's some I'm stuck ether and if there's everybody would agree that everybody who's at least directly affected would agree that it would be better if XYZ happened is there some way to take those cases a very narrow set of cases and say well maybe we can address those and I think I in my the way I was thinking about this the there's a number of cases that have been talked about there's the EMP 156 cases there's the save splitter cases there's the parody

multi-sig there's another one with a client library that left off some padding or included some extra padding I don't remember exactly the details where I can't say for sure if you know all of those could be handled by this process but if there were a way for them to essentially present their case present their evidence that hey it's obvious what the right thing is to do here who the true owner of it is here's the set of actions here's how I decided what addresses would be affected so there's this verification script that's included so if we were to you know narrow it down to this very small set of cases is there some way that we could handle this so the conversation and the P was started

off just about you know whether there was maybe some conflict with see if they are in philosophy on whether or not this should be done and and I think we've hardly moved past that although I think there's still certainly some questions but we may be moving past the point where we'll have the proposal as a draft that hasn't happened yet but I think we're making progress in that direction I think there's a lot of concern about a slippery slope the other types of concerns are about cost and you know whether or not it's it's maintainable or whether or not it's going to be too difficult to try and handle all these

Europe you requests and I think any concerns that have to do with the resources I think are pretty right forward to address especially given the amount of funds that are locked up I mean even just in the parity multi-sig alone somewhere around half a billion dollars at the moment so I think if funding is an issue or resources is an issue that's that's an easy problem to solve and then the other thing that's brought up is maybe just risk and so that's a lot of the process that was included in the ERP proposal was about how can we reduce risk one of the things that we can put in place so one of the conversations that came up was about some language in there that had some peer review type of process and I think

that was initially looked at as maybe selecting a special set of people though only they could do the validation and I I really put it in there because I thought well we're this is a these types of proposals should be scrutinized very carefully and so we may want to have some extra bar that people need to get over in order for them to even be considered for inclusion that guarantees that the claims that they're making or helps to verify the claims that they're making if there's a better way to do that I'm certainly open to that but that was the intent of including it and I guess the other place where things maybe were not so clear was I think I misunderstood the directions of

causality in this process and and that the IPS would be proposed and unapproved and then there's sort of disagreement that once an EIP has approved that the clients will go and implement it and I understand that that's not the way it happens and it's more the other way around that when clients agree and they may have their own approval process pulling the community however they do it then that's when something gets marked as accepted so I've updated the language in there and reflect that and make sure that I'm not attempting to give any additional you know bureaucratic power to whoever the VIP editors or are the people who are doing the verification that wasn't my okay good so and just to be clear what you're pushing for right

now is only for this to be merged as a draft to then have further discussion included with it if that's the yeah if that's the process that was my understanding is that that was the process and so when it didn't get merged I was concerned that that if it wasn't getting merged that it was sort of influencing the discussion that would happen because people would see how this thing is blocked from even being merging it's maybe it's bad idea or I'll wait until it gets merged in order to give my opinion I don't know but if that's the standard procedure that it should be unmerged until it's effectively accepted that that's what I didn't understand as I thought it would

get merged unless there was some major issue and then people could have a discussion it would be draft and so yeah I think if that's the logical next step then great I be happy to have that happen but if you tell me that's not the way it works then yeah so here I'll do I'll just give my opinion first and then we can go around to the other editors and people in the room who have some comments but basically the biggest issue right now is the fact that there needs to be some updates to EIP 1 there needs to be clarity on just what gets merged how it gets merged because the EIP process was initially left vague and pretty much a copy of the VIPs Bitcoin and pretty mint proposal process so

after that there has been a few times that it's been updated to more address aetherium sneed such as adding ERC's as a subtype of VIPs to be approved there's also a path that any IP takes from draft to acceptance but as far as when it gets merged to the repository that I have not seen that written anywhere as far as like after time X or thing X happens it gets merged it's more at the discretion of the editors and so it's been very mixed what gets merged so for instance er C 20 I think it was mentioned in the thread I don't think that got merged

four years after it was being widely used not because of anyone trying to Brigade it or stop it from happening or anything like that it just was the editors just not merging it yet and everybody using it anyway so there isn't that clear of a process right now for when things get merged however there's going to be soon a more clear process so my recommendation would be to not merge it until that clear process is decided on over the next few weeks or month I definitely don't want to drag this out because that could have unintended consequences on VIPs such as this one that might you know the time might be a factor in and I mean obviously in cases of lost or stuck ether times not a

factor and that the ether stays there but times a factor and that as time goes on the you know decisions of the community might be swayed one way or the other as community members come and go so it's now in my opinion a priority for people to or for the EIP editors to change the process somewhat make it more clear and until then I personally don't think it should be merged but I definitely want other opinions of the room but Dan if you want to respond first and then we'll get other opinions yeah I think that's I think that's fine if the if the process isn't clear right now I mean certainly it helps if I'm still making at it's still getting

feedback to not have emerged I think the biggest drawback is just the it's hard for people to go and read it they you know they know where to click in github that's fine drew from people who aren't familiar with that maybe it might be difficult to go in there and figure out okay how do I actually read the thing I saw some comments on reddit that said well there's nothing there and I think the issue is that they were just looking at comments and they couldn't see the actual content yes that's something we're kind of somewhat addressing by a plan to have a cool front end like a really neat awesome thing where you can go to a website and it lists all of the e IPs in a way that's more human readable and doesn't require knowledge of github or going through the all the PRS and issues

and searching for your thing is the plan but that's going to take a lot longer so in the meantime what we can do to facilitate people like cases of yours that are unclear about the process is to update and improve the process mm-hmm so um yeah whoo I think someone probably had a comment was that you Peter no so I just wanted to say that even now you can actually link to the even inside the PR you can link to the file with that we are so you can in theory share it but yes it's a bit hard to share something that can be updated constantly sure so hi I have a couple of comments

firstly like I just as a just in terms of this idea or like making it wait until the process is clarified I think you know as long as it's not the case that the process so somehow this is important that the the proptosis or determining what the process is isn't biased by say for example the editors feelings about the particular proposal that we have that we had to deal with right like somehow the the the thing I'm concerned with is that like the process will be specifically derived not just to deal with this case but to deal with this case with like you know and bias the outcome so somehow you know

I'm not sure if it as a general thing it makes sense to like you know pause and work out the process in response to a controversial eep however I think that might be okay I'm not I'm not saying it's not okay I this is potentially if there's lack of clarity and it's been for a while - yeah the plans for a while has been to update the process so this isn't spurned by the controversial EIP I will admit however it's definitely put more pressure on it to go faster so I mean there's always gonna be a chance of biases creeping in with anything and the best thing we can do is just stay open and transparent

about this yeah yeah I think that's I think that's super important and I think let me say one more thing quickly I think is especially important for something like this where it really does play deeply into this kind of important questions about like what is the nature of the blocking what is the relationship between the blockchain in the community and how do we kind of like like it does affect this question of like you know what is the philosophy of aetherium and and so like in this these proposals especially proposals that like do kind of you know set important precedents that like impact the relationship between the community and the platform I think need to be subject to a tremendous amount of public debate that I'm not actually sure the each process is

designed to really handle and as an example let me just say that I don't I mean in my recollection was at the die hard fork entirely happened outside of the each process I'm not sure if that's something we think was a good idea but I think that was something that happened because the east process wasn't set up to deal with that kind of the kind of existential deep like philosophical kind of like important fundamental questions about the relationship between the community and the Oracle now I think during the doubt the most the biggest problem was the time pressure so that's that's kind of true but like you know we did have like well over a month there was certainly enough to do go through

the east process if that was what we were gonna do but but we didn't right I'm not sure what does it do people think that the east process it would have been appropriate venue for the down hard floor I don't think it would have been I think the the the Apes process is good and we do have Apes for the irregular state transition that happened I believe I could be wrong so yeah I'm not sure if we do yeah what to look into that more but I definitely want yuuichi to be able to give some comments here so go ahead yuuichi I can last week I merged one EEP and the author of the EEP to me he was still modifying deep so I

have to continue the my you just think because I don't want to be you know particularly against particularly but then so this time this time was my first time reviewing the process method concerning the consensus process and okay well and this is this was my first time looking at this theorem philosophy mentioned in it number one so if number one says anybody that can deny indeed status for reasons including not in keeping with

philosophy earlier this week I thought this theorem in philosophy refers to a document written by during that period I refused to merge this EEP because that document was against having trusted operators up here but I mean at most like 3040 people deciding balance transfer seemed like at least at odds with this that document that philosophy document but well later this week I noticed that this SEM philosophy

mentioned in deep number one was originally just copied and pasted from the Bitcoin document be 0 0 1 and there it was like not in keeping with the people in philosophy and then it was modified in the same philosophy so now I'm not sure if this theorem philosophy mentioned in it number 1 refers to a particular document or not and I wouldn't use this theorem philosophy Clause unless I'm sure that most of the same community believes that the SEM

philosophy and I I don't have that kind of confidence anymore so I don't use this SEM philosophy thing anymore so they for me the same as the usual EEP so after some spirited King Hitler format and if it's very fish fighting not fun or something I just not as addressed yeah and I think that's I think that's a good policy and I mean we'll talk about what the final process should be but I mean I think we should be getting in a habit of merging them personally we need to talk with the other editors and you know get some feedback but merging them as soon as the author wants them merged

and it's formatted correctly sounds like a fair way to do it so I don't think [Music] something special about it so far I mean they were like we've won eBay dies okay they can match it and I don't know but so far it was operated like that so I'm speaking so that was I thought before I heard Hudson in this meeting here in Hudson saying he wants to finish up the

procedure first okay well I mean of the is fine by me I would wait yeah I think if if this is something that's not uncommon I haven't followed too much the the IPS that that have come out before in the process that's behind it and my major concern was just if this is something your regular that's happened and it's acting as a signal to the community and knots may be influencing the debate if that's not the case then it doesn't concern me so much if there's a good reason to to leave it unmerged I mean certainly as I mentioned continuing

to edit it will be much easier if it's if it's not merged and then once it is merged I guess the conversation would move to an issue so that's how it used to be now it would just be that the once it's merged the hmm see that's the thing we got it we got to discuss how the best way to do that is because we don't know at this point oh yeah let's let's leave it unmerged we can actually yuuichi or any if you maybe just want to comment on it just say you know this we're gonna leave this on merge for now the discussion to continue while we're figuring out how the flow should really be I think

merging might be carries a little weight and if there isn't a particular IP that's still very controversial or still being being built I don't think it should merge I think that the fact that the year c22 so long were it wasn't that much we eat really was formatted and I don't mean that only for the request for for recovery to recovery but even things like the next token there are multiple token elimination hood are being floated and I think all of them are at birch I would say that the best way to merge something is after it has been tested in

the wild there are many implementations and there are people using it and because that also helps set the correct standard so I would say that in order things to be to be merge they should be uncontroversial and they should start to be a to be a bottom-up standard do you think I understand that for a year see 20 that sort of thing but in cases where relies on client modification how could they be in this particular proposal how could it be out in the wild ahead of time well yeah that's true way I would say that that's that's four things that can come can 10 B button up when it requires a

hard work and requires a when they they act to issue being accepted requires a hard work and compliant invitations and I would say that it's fair to say but still it should be on Reverso at least I would say or not very controversial in my understanding the EEP repositories like Twitter everybody can say whatever they want and I much everything that's my understanding country so it's very different so I I have some some thoughts here on just that overall meta process it seems like initially merging draft things is fine basically when something is like you know met whatever the minimum old

standards are it seems like merging something as draft is fine and then at that point you can continue a conversation in a separate poll request at which point it's a lot easier to pick out the things that have changed from the original draft it's a lot smaller set of changes it might actually facilitate that sort of tweaking discussion that that has to happen for for those like minor rule changes small changes to the so merging things prior to them being accepted you know for implementation it seems fine and I feel like we still have a pretty good forum for continuing discussion just through a secondary pull request that that

modifies the EEP even if that initial per request is literally just changing the status to accepted at which point the the discussion can continue there yeah to to draft is that right or yes so like initially things get merged as draft once they're sort of gonna be author feels like it's a good starting point and all of the you know various sort of minimum requirements have been met after which a second pull request gets open changing the status from draft to accepted at which point that's where the sort of deeper discussion can happen on all the little tweaks that maybe need to

happen I see that sort of thing also there's a state called the rejected so after product is merged as a draft can continue and after everything is said and if it's founded to be a better idea the status might change to reject it and I think it's the record about decision in that repository yeah there's also superseded so that's another good one so for instance if there's a new token standard there's gonna be some discussion on whether it's superseded zrc 20 or if it's just an alternate standard that then gets accepted to then

be used by whoever wants to use it so that's a whole nother discussion for another day but so there's there's a lot of statuses we can use to make things clear once a once a PR has been merged any other comments on this topic yeah so basically I'm curious as a discussion point for this meeting what meaning to discuss its merging or not merging or just it was primarily to discuss the process itself and then any comments for the actual eve itself would probably be remain in the in the PR as my as my like thought yeah

and then once it gets a little bit more mature probably you know it's only been around for a week and once it gets a bit more community support bringing it up in another coordinate meeting I think would be very appropriate so I think then and also once we figure out the merging thing and just things kind of move along a little bit we can bring it back up at a core dev meeting okay it's just one exit here so one small thing I would like to you know if somebody hears this or somebody wants to make a like a public debate about it I think that would be good regardless of what the process is because I understand what we're discussing here's just a kind of

formality which I don't know really important in this case so yes let's have a public debate about it and just to to figure out whether it's a good thing to do yep I agree and I think that the best formats for that are gonna be the github PR reddit twitter and the ether recovery get her channel if I didn't already say that I might have repeated that something else people feel is appropriate yeah I would actually suggest not going even beyond it I think it's such an important topic it should be debated like in a sort of live video or something but you know I know it's not it's just beyond this meat beyond the purview of this meeting but I'm just

kind of the suggestion that's that's a good idea are there any other comments I'm sorry I actually think that's a terrible idea relegating that debate to a live video basically puts people on the spot and makes this a politician based thing rather than a like let's have a careful discussion about it so I think keeping it in text-based asynchronous formats is a much fairer way to do a contentious debate otherwise it's a popularity contest it will become that whether you want it or not so that's what you just

do it right now yeah well I mean we can't do it today just because that wasn't part of the dwell I haven't listed as an agenda topic as far as the EEP itself but this is more to resolve the process no not today what I meant is that we I have a feeling that will have to happen anyway so I say confiscate from there okay well that remains to be seen so either way I think a video chat would be fun but I see Piper's point as well so just when it comes to that time we'll figure it out and I mean we wouldn't be able to stop anyone from doing that kind of live video chat thing anyway so yeah anyways any other comments on that EIP all right

cool thanks a lot Dan for coming on and explaining it and us working through this yeah sure thanks for putting on the engine okay so such our item three fork release management and Constantinople so Martin and the core dev channel posted some AIPS that under his with his under standing may be included in Constantinople I wanted to go over those one by one and in addition I wanted to talk about if there's any other AIPS that would need to go into Constantinople so let's start if and I updated this right before the meeting so you might have to refresh the page to see them but um II IP 145 bitwise shifting instructions for the EVM that

one's pretty uncontroversial does anyone have any comments on that we've pretty much said before that it can go in but does anyone have any other comments on that and I believe there were recently test cases written for that and C++ client I might be wrong but there are the test case is defined in the actually and we have implemented it as a pull request yeah the test cases checkout [Music]

sure whoops I did the wrong it Oh yep it's actually no problem any other comments on 145 okay and for any of these that we decide on that are like approved for going in the constantinople previously and then confirmed in this meeting we can update the chart on the ii ip's repos readme page the second one is the IP 210 I have a question regarding the test cases so you have the test cases in the the IP itself but do

we have a process defining who's writing the actual like state tests into the test repo or how does that part work I don't think we have one anybody know so Opie's and Jim what was happening was so people find the test cases and toward Demetri or me and Demetri had a Google spreadsheet of test cases and we were turning the Google spreadsheet green why are we implementing the tests spreadsheet sounds like a good idea right but for the spreadsheet that was

more for coming up and writing down complex scenarios of the types of tests that should be needed for something like the shifting operations I think it's perfectly fine with just using the once in the eat Plus maybe a few few more if there are n a particularly interesting educators which I don't know what they would be that's that's yeah execute did that answer your question or was your question more based on who is assigned to it yeah I guess I mean we have those test cases defined it just needs to be translated into an actual state test I think in the test repo so every client

can test against it oh and I think there was a second part to this briefly mentioned last time and that in the test repo and there needs to be a new heart fork added called concerned in opal I suppose and it needs to be generated etc I'm gonna finish the process there so I'm not sure if it's not what it should be never get done it contained a big swath between 15 I think but execute your question would I mean it's meaty annuity would probably be the

ones to make actual test cases right Richie yes and it also sounds like I'll go ahead Peter now I just wanted to say that if a while back we are discussing that it's it's really really hard to make new test cases meaning that for example if while I am implementing an EIP and I find some really weird corner case for the golden foundation to do it it would be really awesome if I could just somehow create the test case that can be run against the other ones and back then we were discussing that it would be nice if we could somehow figure out a more streamlined approach so maybe we could also discuss this when discussing the

RPC transgenerational to see whether we could somehow make it easy for anyone to make this little script that can generate test yeah sure I mean so for instance I mean take a block can take transaction and if you commit the test case to be great I mean currently writing a testing under special developer knows how to interact with the change so I mean if you can like automatically create a test case out of an existing in a private network so then it will be much easier yeah but that's

exactly my point that of course I have every one of us can make tests but if it's going to take half an hour that I'm simply not going to do it because it's it's just painful and gets in the way so if we could streamline it so that you could do it in maybe three minutes then that would really help I see okay three minutes is a good number to aim at - yes I agree and just just emphasize I'm not saying that you you guys should be the ones to figure it out or make this work I think in general in the ecosystem we should somehow figure this out of course of course although of course we I mean we are famous we'll be happier

with the beta process so I'm looking for ah c'est vous salue so another comment in in general I suppose we don't really have a proper timeline yet for for the heart fork or any of these changes but what should be so if practically right now it's it's really hard for anyone not familiar with the test way to create new test cases what should we expect what kind of time frame should we expect for like the bit by shifting test to appear [Music]

so overnight and dispensing it's more like getting attention and bringing this up here I think there was already

documentation on how to make test cases right yes but after the recent organizational change I mean this documentation is now will soon be obsolete okay sounds good so this just needs to be updates there AXA did you have other comments or did that answer your question I guess it's a dance for some parts but not really yeah the timeline I guess is undecided for now is what it sounds like I maybe this is not a topic for the

whatever meeting but since testes moved out of City Pass area maybe it deserves its own resources but I mean that's maybe an ashram foundation internal organization stuff yeah I think mostly the foundation handles the tests we right now or at least they employ everybody handling it so that is the discussion for that it's just as a side note probably it would be really nice if we could have the test cases headed by next court of call because then it seems

we have like two implementations of I think I should keep adding the Byzantium test cases right now because it's one minute already and this affects the security of the main network so this one has a priority oh we don't even have or magenta okay yeah yeah we team we didn't have all the test cases done so yeah we're gonna be working on those so yeah it's an undecided timeline unfortunately x'q well that's these stunts were some hippie cool thanks cool any other comments on

EIP 145 okay the IP 210 block hash refactoring that's another one that Martin and I agree with him kind of implied was not very controversial so I'm let me go to block hash refactoring that is a State that's a system contract I believe that reduces protocol complexity it says to process the block hash opcode so one perspective I've heard on this is that it is a good stepping stone for pieces of Casper since this would be the first this would be the first system blockchain system contract and Casper

itself as a blockchain system contract is that does anyone know if that's accurate or have comments on the CIP if there's a name discussion needed yeah unfortunately the Tallis person to ask but oh go ahead oh I was just gonna ask for a high-level overview if somebody was able to give it I can't anyway so of this obsess is that the certain port number there will suddenly appear a contract at address and no f0 and that

add another contract and it also specifies the code that will go in there although that may change and what this contract so and then afterwards in each block this contract is called before any other transactions a call is made from some system address the calls made to this contract and the call data contains the previous block cache and once 256 blocks I think as number has passed since the fork invocation of the opcode loCash will instead be a call to

this contract and what this contact does is that it saves blockages state requiring the clients explicitly maintain this the cash of the last 256 and I think but I'm not sure that this contract contains older block caches but only the 256 most recent ones but I must say I'm not yeah I would actually look at that I don't remember the contract Macau that's that's plenty I was just looking for kind of exactly what you you said a high level implementation cool sorry quick question on this one as well is it

also if anyone knows like the Casper system contract that sort of there'd be no gas for calls to this contract as well so that would be an interesting first case as well so there will be gas if you call it if it when it's cooled by the system contractor for any transactions then there will be no gas but so if you call block cache of code it will it will increase it will so the suggestion is to increase it from cost 20 gas into costing 800 and we don't

know where exactly what the I mean if you actually execute the opcodes one by one something else so I would guess that if you call it by the blockage of code you get a fixed price of say 800 and if you call it explicitly by address I would guess that you get the actual gas Monsieur I can give some clarifications at least what I understand there is it should be able to cover more than 20 56-bit 2056 hashes but there were different implementations storing and them in a different way and

as a result if calling the block up code that would still be limited to 256 items and it would have a fixed cost the 800 you have mentioned but a contract would be able to directly call the contract and retrieve more information if it supports storing more than 256 hashes and that would have just a regular cost of calling and but the actual cost of the contract was well the extra cost of the contract would be it's a normal EVM contract so it's just regularly calculated but I think maybe lanes question was more like what

happens to the first transaction in every block does it have a gas cost or is it free but I don't think there was an answer to this should be free otherwise the system contract will go just to pronounce 0 and after that this brush will not be hyphenated yeah I mean I guess it's free I think we can have that discussion on the eve but in general it doesn't sound like there's any controversy over over this should be use this was that controversy oh yeah so

actually that brings me to a comment that Powell made ten days ago it's at the very bottom of the poll request for this eeep and it says that the code still has a bug and that he wants to write unit tests for the contract and that he'd like to implement it in Julia to estimate the lower boundary of the gas consumption am I saying that right Julia okay perfect so it sounds like the bytecode would be generated from Julia at this point but that's not a definite that's just what he's proposing so he has actually made unit tests but

there were different I think after he made them there was a different proposed contract code and I also implemented them in and Julie especially but I don't think it's up to date because there were so many different proposed versions of the code okay so that just needs to be figured out in the EEP and it sounds like there isn't that many like there's not really that much controversy over this so I don't see why this wouldn't go in anybody else have comments or any reason why this wouldn't go into Constantinople okay next we have e IP 168 and 169 for

killing dust accounts that's one that gap came up with I don't know if there's an updated to eat besides that and I know that there were some discussion and the core dev chat about just how much this would help as far as what was it where was that Hudson if you want I can just quickly it's Alexi so basically we asked we want an assessment of how much saving in disk space or whatever this change will bring and I think Andre from the C C++ team

has already did some analysis but this analysis only covers only covers the number of accounts which could be deleted at a certain threshold of the that what's considered to be dust and it's actually attached to the year to DAAP so what I'm planning to do in the next couple of days is that I have a code which could analyze how many nodes in the actual state tree would be removed if the different thresholds and I will post that Graff so for everybody to see so that we can make more informed decision whether this AIP brings enough improvement to justify the implementation that's it for

me okay cool so there just needs to be more analysis than it sounds like so this isn't anything that's definitely going in yes so we also had a discussion about this internally and this yet is bit interesting and this problematic because so the original proposal that Gavin made I think he said that he proposed that any account that has less than 420 Saboo should be deleted and I'm not sure it's where I saw the exact number somebody says that that would amount to by about 45 cents currently and I think this this really highlights the issue the core

issue with the CIP in that how do you define a threshold which is a good-enough threshold in the future too because for example if you would propose now that we delete everybody's accounted as less than 45 cents then the entire ecosystem would blow up that body mean because all of a sudden something that was one and a half year ago and a significant sum now became what I wouldn't call foreign accent significant but still it's not insignificant anymore well and it's 45 and back then for each feature was about ten dollars and 420

example was less than a cent and right now it is 400 it's for each offense so that's exactly the problem in the proposal that it doesn't so it it may or may not scale into the future yeah that's a good point so that sounds like to summarize there needs to be more analysis of the actual benefits of the of the clearing and also whether or not this is for future price movements etc that would potentially make that amount of zaba more or less valuable yeah and for example Felix had so way back yeah I

know it this this is off the table currency but just to mention it there was some proposal that whether or not if um should or should not for example collect rent from contracts or from accounts and it's an interesting concept that if if um were to go down the rent approach and all of a sudden you don't need to clean up best accounts anymore because all these accounts will eventually run out of front and get deleted anyway now this is obviously a completely different discussion I just brought it up that there might be different solutions to that haven't been yet considered I also noticed that because its contract so it might encourage people to either create

wallets that they didn't necessarily need to hold small amount of money or to use wrapped F as a token which in the end might even use more disk space and not necessarily bring rain so it might encourage behaviors that they might make people use even more disk space but those that this space is in contracts not in accounts okay so at this point we can definitely say that this will not be going into Constantinople at this time without some refactoring and obviously yeah I wouldn't say that it shouldn't go into

Constantinople for example because it's a simple enough solution for a problem just it's important to know that it's not a future-proof solution and it should be discussed what the future will hold for the CIP good good point Thanks I think it's interesting to note from opposed to the graph that Alexei posted that there are 10 million accounts with balanced cero so I'm guessing they're not count as I'm Turkish have nonzero norms right so I

mean if we changed emptiness I mean we could basically set the threshold at zero instead of 420 shabbat we wanted to oh okay right anyway there's an interesting problem with contracts so what happens if for example I have a contract I suicided move all so sorry I have a contract I move all the funds out suicide it and then redeploy two different code oh yeah of course it needs yes I'm sorry

but yeah if if account obstruction comes into play then we have funky I mean only one of you comes so this e which the next one under-16 line discusses how to deal with that that's they can't breathe they protection it's also by gaven and it has three different variants to how we gave with a replay protection problem yes oh

yeah anyway yeah I guess it was down to how account obstruction would work indeed that actually happens to be the next thing haha so any other comments on that before we move on to account abstraction cool so Ebates 59 was created by vitalik as an update to one of his previous eeap's about account abstraction that eep was a culmination of ideas or my understanding is that it is updated based on feedback he got from an eighth Research Forum so right now account abstraction is still up in the

air there's people who are very in favor of account abstraction just because they don't see the point of having a whole hard fork for minimal changes and that that something this important should go in what's everyone's opinion on account abstraction and I can start collecting these in the notes so that we can don't have to repeat this conversation over and over again as for me I would say that I think we need more people to read up the details about this and think about what consequences it would have because it's I think the implementation of this looks kind of complex that the contract

creation is a two-step thing where this is created and then it's called and there are two different kinds of data in the transaction there's in a code which is what you would get and join you for execution if you medical data coffee and then there is a data which is what you get in the second part if you do call it a copy and yeah yeah it's it's I mean I think it's complex cover every aspect of this in one sitting so I really would like to see some more discussion about this in general among the core developers is this is this ERP prerequisite for any of the future

changes in their own like Casper sharding I think it's Alec I mean we when we discussed this we alternate Alec on the line yeah if I remember correctly from the last call he said it wasn't required but it would make I think he said it would make something easier I forgot which which one I think in more in general the entire community and ecosystem would prefer this abstraction because all of a sudden then you can do a lot of stuff that are currently not necessarily impossible but really really

hard for example to have a contract pay for its own fees currently you can only do that if you have some specialist set up to the mining pool etc and this would actually make that possible which immediately would make a lot of applications possible I agree I think there's widespread community support for this because I've seen it referenced when people reference the road map and reference things coming up in the future and then there a lot of the nap developers I should say are pretty excited about it for my for my experience the reason I was asking this question is not the skepticism but it's whether we could say that the tracks of working on this AIP and the tracks of Casper development can

go in parallel so that there is no impression that we have to do this first before we can go to Casper so we can actually do both in parallel and then whatever comes first will come first oh I see what you're saying just as a from a client developer perspective I would probably be happier if we would select a few VIPs that we would like to ship next and focus on those rather than trying to do concurrent stuff it sounds like we picked at least two of them today okay but those so that those who are fairly easy but retirement currently is that

account obstructionist officer is a lot of work probably and a lot of things to test and the same goes for for the scaling solutions so I think it would be nice to figure out whether we want the next hard work to focus on scaling or to focus on account distraction and stick to it so mine doesn't matter the thing is though that there's no e IP right now so basically there's no scaling solution that's an e IP right now until sharding which would be beyond the constantinople hard fork so I guess I'm not sure what you're referring to when you say focus on either scaling or this for the next hard fork well so okay I meant more like for example Casper and my suggestion

would be that if you want we should either focus on for example getting the account abstraction done for the next hard fork and do something with it or if we decide that we want to push Casper then maybe you should put focus on that front and half and ship it as fast as possible instead of getting lost between both changes I see okay that's a good point what is the implementation state of a construction when we almost finished and then in the end postpone it because the consequences for the infrastructure will not clear so yes and now because now we're talking about different types are count abstraction the one you're talking about it's 886 and that was even more complex

because it and I'd allowed stuff like paying for your transaction with the RC 20 tokens or whatever's this is a different variant and that's also good to be aware of it I mean if the community wants account abstraction it should be aware that this proposal does not include paying with their random things you need to pay with the ether but essentially the previous proposal was binned and one of the reasons it was bent was that you could do a reorg attack where someone created its own multi-sig of them malicious miner did the reorg and suddenly someone else owned that accept contract and I think this proposal does not suffer from that

and because a cost structure yeah you can read my comment on the on the eat but there are complexities that we should read out my opinion is I think that the the italics proposing is important and I think a lot of a lot of developers are waiting for some kind of distraction but my opinion is that the way it is described it's very technical when it's very and it makes it hard for outsiders to contribute so maybe if someone could try to try to do a write up on it and try to get more require

more feedback from just like normal developers not just core client developers and developers it might help bring more attention and discussion to that to the hmm I'm a bit unsure about that at the current point I mean it's always nice to together community feedback but I think that was one of the biggest issues with the originally acted is say that everybody wanted it everybody liked it just nobody from the client developer teams actually put the effort in to implement it and then after it was everyone thing was said and done and we figured that yeah we should definitely implement it it turned out that it's it's really really messy so my suggestion would be that first let's try

to pick something that is technically feasible and then work on the little details it wouldn't be a waste of time to fully flush out the EIP even if it does not end up being implemented in this Constantinople cool any other comments on that yeah suffice to say that one is at this point not officially going into Constantinople and means a lot more discussion all right the last agenda topic is client and research updates so let me go ahead and go to the list of clients so the first one will go with death have any updates or things

you want to announce well so basically since this year we've mostly been working on under the try to write this kind of stuff those have all been all ended already on master currently we are just polishing and finalizing my master we do know of a few bugs that need still to squash which are currently preventing us from releasing but I would really like to release hopefully beginning of next week although we may have to I don't know so let's we're targeting a new release for next week and we really hope that it will also fix all the like client issues

which I'm hoping people will be happy about [Music] okay thank you CPP aetherium actually he would speak on that Christian maybe I guess he would she knows more I think most of the people are all but I can do is trying to corral the office this fits Andre so wait for few minutes okay sounds great

I guess removal of test eath is one of the updates already totally yeah and I'll go on to the next clients until we can get Andre on here next parody I think offeree not much updates from parodies right now we have security audit incoming we just published a blog post this morning yeah we started to improve the light client it's really overdue and last but at least might be worse to mention that our next release

will come without any wallet interface and user interface yeah we need to we are starting to split off soon user interface in a standalone electron wallet might be interesting for someone following the wallet development yeah working on Casper so the world later code is almost written and we are trying to test and debug all it is done so far but the problem is that we can't connect with

the payee tab so trying to solve the problems with PI as its that's it for Casper and working on performance improvements still working on that and I can say that we have a stable version which is just a reminder that we have a problem with the too long database flash and we now have a table working where database flash a hundred times faster than in the version which we have in the master branch so

the only one problem left here is a large memory footprint it's about four gigabytes we'd like to reduce it to two gigabytes or something about that and then we'd like to make a release so I hope it will be soon or yeah that's it thank you we are quickly approaching our first public release it'll be able to run a sort of minimalistic like client and sharding implementation continues to

forward cool as anyone from aetherium jeaious available yeah yeah oh yes exit great and yes so basically the most of the development happen in the in the VM implementation and there was a major release made last week which was the the only release made since the Byzantium heart fork and this one fixes a lot of different things some of the changes started out as performance increase changes but they ended up being they ended up cleaning up the code

significantly it should be much easier to understand what's going on it did fix a lot of potential consensus bugs on certain edge cases mm-hmm and it fixed a couple of other issues which have been experienced by truffle so contract testing should be under certain circumstances should be much easier and they're better with this release and after the release there was some work on running code coverage test code coverage reports are while running the state tests and doing that we have found I think a list of like ten different items

where we believed that the tests weren't covering certain edge cases but then it turned out that the state tests used by the VM were still from I think around October hmm so we did an update to the latest version of the state test repo which was hard to figure out what what is the actual latest version of it and what is the latest stable version of it and it seemed like the information we got from uhé and Dimitri is whatever version used by cpp terrarium is the latest version

of the state tests so we have updated to that version and the VM isn't isn't successfully passing all of them so work is being done and fixing those issues now and after those are fixed hopefully we gonna get a better a more accurate coverage report okay thank you turbo gasps yes so I'm currently dealing with fixing all the tests that exist in the tree so before probably many charts some more and also I'm running the tests on how

does it behave on hard drive I think at the moment it's pretty promising it's actually no difference to the speed with SSD but I still have to test it through this pound box which is gonna be very interesting and yeah so I don't know when the this whole thing is gonna be stable enough but yes it's the work is going on okay is there any updates from research metallics not here lane you talked with the research team sometimes do you have anything that you're able to definitively say what can I say I met with Xiao Wei today and we sort of had a chat about sharding and it's

continuing a pace there was a little bit of concern about kind of a discussion we had on the last meeting about the phases and the stages I think there's a little bit of a little bit of confusion here about some of the terminology and and there been a little bit misrepresentation and the part of some some media or something about it being a bit further along then than it actually is and so I think just that we're still kind of it's still kind of quite early but but things are going well that's yes I that's all I have on the research side silent as tonight I was talking and I

was on mute I'm saying I was saying yeah there was some confusion from a coin desk article but there are some some people trying to clear that up and some of the reddit threads so I think that's that's passed but in the future we can try to be more definitive with some media outlets about what what stage were at with that so yeah thanks yes okay thanks that's it so I one other thing came to mind it may be worth mentioning as well that I I also understand that there's a little bit of trouble as was discussed last time getting some of the Casper tests and stuff working on piyah theorem and Piper you may be able to speak to this a bit better than I can

but if any point it would be possible to move that stuff over 2pi EVM I know we're kind of not there yet we may not be anywhere near that point yet but I guess that may be a possibility to relieve some of the p2p issues that's something that we're like basically validating and part of the basically we're working on validating that we can sustain a healthy network using the Trinity networking code and if that turns out to be the case and we can validate that base assumption that I think that the Kasper research is going to migrate over but we want to validate that initial assumption first to make sure that we don't do the migration work and then have the same problems okay

sounds good thanks everybody for the updates are there any comments or anything any other topics we didn't reach can I actually ask I have two questions one is aimed at Piper so you said that you 20 would be releasing soon public alpha with a light client are you using which light client broke who are using I think Ilyas - okay no no just asking that if you are using a yes - well for one thing Elias one will probably

we did release soon so the front don't use that one as for Elias to if you have actually a client running or the usable I would really appreciate if we if you could sum us and usage issues or anything that you see to happen absolutely I will I will be in communication if anything comes up that causes issues sweet and my other question was directed toward Alexi you said that I was looking at the turbo gas charts and the numbers are kind of impressive but as far as I know you kind of store everything in memory which

currently leads to a 65 gigabyte memory usage yes so at the moment it's the numbers are kind of unrealistic so because they do require you to have a huge amount of memory however I do I'm doing some testing with the realistic mods memory and there I'll publish them later because yeah so I agree this is this is unrealistic thing although I mean we'll see we'll see how it goes I think it won't be too too far ahead so far off from the current numbers but I will publish when I have them mm-hmm now I'm gonna curious about that one because I've had a lot of the optimization on

the idea that you had two really nice just is this memory footprint really scared me because I didn't see it as scalable but if you are actually working on on pulling those numbers down then I'm really curious yes I will definitely let you know when I have a new set of numbers and one can have a chat about okay sounds good any other comments okay thanks everybody we'll see you in two weeks - bye-bye thank you very much [Music]

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