All Core Devs - Execution #44

Transcript

[Music] [Music]

[Music] [Music]

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

[Music] [Music] you

[Music] good morning everyone or afternoon or evening I always forget that it's not just morning for everybody here we're gonna go ahead and start i think the audio is working yep the audio is working first item on the agenda is testing and I don't think Dimitri was able to make it but he did have an update so I'll just kind of read the high level stuff he listed two links to the ext code hash test list and the create two tests list I'm gonna add

those to the Constantinople progress issue and the PM repo and he suggests that you add your ideas as comments to the list and also he wants us to confirm the implementation of e IP 1014 which is the skinny create - which I believe we've already decided on someone correct me if I'm wrong but I believe last call we decided on that because we didn't find any issues implementing it so far he also did an update or actually does anyone have a like correction on that yes so regarding this guinea crate - we haven't finally Club the actual formula

for with the address create address so there were two options in the eat and then in the last weeks there have been some more discussions mainly well one thing is if we want to include the init code or the hash of any code doing the calculation and the argument argument for doing sorry only the hash of the in the code is that it's easier well in many situations is easier to include the hash then we have a fixed size of the preimage and it's easier to calculate on chain it's might be simpler to calculate

for Hardware wallet and stuff like that and the second thing that there's been some discussion on is if we can use some Rd schema or just prepended with oxf yeah well basically the problem with option 1 is written in the APIs that may collide preimage may collide with our classical equation whereas either we can pretend with oh it's FF or we could use some alternative or PCI which this argument I'm a learner suggested so it's not really decided got it ok cool then I'll need to put in the Constantinople

tracker that this is not finalized at all and that any implementations may need to change in that case oh yeah if we have enough people who can make that decision I didn't know if that was something that the EIP author would have to make a decision on earth it could be something we could just decide but it sounds like we can just decide it so in that case we'll be getting to that item so which number is that that's 10 14 I'll just add it to the agenda in a second so we'll discuss 10 14 we put that down okay thanks Martin next on

Dimitri's update he has an update on retest ëthe it now supports client configurations so you can set the configs and bash script so it'll use and manage the RPC socket you can also set or you could set the TCP socket to an external IP address so if you look on the comment that I'm about to post in the chat and and the Alcor devs chat that's just kind of an update on everything he's talking about he also suggests that we drop blockhouse refactoring because we already have a lot of changes going into the hard fork well so we have that on the agenda to discuss as well the let's see is there

any other comments on testing such fuzz testing or things like that yeah we're getting ready to do cross testing but there's not really any point to start with the fast testing before the PRS are implemented and it's are equally implemented in gas and parity at least they're both Abe is possible it needs to be possible to configure Constantinople then we can start doing the processing as for highway recently integrated Alif which the new name for CPP ethereum so it's running on a speech that's it ok great thanks for the update now we'll

just go through client updates let's see let's start with parity hello hey last week we have implemented 1087 we have that's 10 14 but there's some active discussion regarding all clashes with I think 87 86 and yeah the sir remaining question is like we said in last call that we were going to give a 1087 with shots we did we found some issues it

sort of prevents some optimizations that we're doing and we will talk more on this later of like yeah we have a proposal for our replacements yeah he can talk more about the trade-offs there but basically I mean we're we're at a stage where we could easily compatibility with pretty short amount of time like how many weeks is that again i couldnt hear like a number like say one or two weeks oh cool nice that's pretty good thanks for the update guess do we have someone here Martin or someone

I might be the only one and I wasn't really prepared for that I don't think we're done on him Anna made changes recently Peter is still working on pruning which is pretty complex yeah so no real updates for now okay thanks let's see let's do a left next so that was formerly cpp aetherium yes we were working mostly on Constantinople changes three of them that are more or less specified or implemented the left one is net net cost storage for a store and and

yeah we are releasing version 1.4 so there is release candidate if anyone is interested binary is available on the github and if no issue found reported during their next week we will just release the final version okay great thank you next we have let's do a theory MJ or harmony we have started to work in Constanta novel I can say that 1087 is pretty straightforward to implement in

the theorem G but after yesterday's discussion I decided to wait the decision between those two year VIPs like 1087 m 1283 so that's it when I would just started and yep okay thank you do we have anyone here from Trinity no do we have anyone here from aetherium je s okay what about Nimbus yeah I can

take a few notes on Nimbus so basically we've been busy implementing enough ground support in name for all the different primitives and aetherium primitives and we've reached the stage where we pass all the VM tests we are working on downloading blocks and things like this and at this point we're also splitting up our development resources into two parts one will focus on the core chain here in one query chain whereas the other part will focus on on the charting chain and getting a beacon chain going as soon as as soon as we build those primitives so that's what's

going on on the Nimbus side we've also open up a getter channel status I am / Nimbus for those day one if you want to get in touch with us over getter it's being bridged to our right channel which existed before and I'll just make a plug here for the ECDC videos that are out link was posted in the in all coordinates channel angular and another one was posted on on the EP 8 status Twitter account so check that out if you want to see what we did in Berlin last

month so thanks thank you for the update do we have anyone here from mana or nether mind all right what about Pegasus hey everyone matt from Pegasus here so still working on our main at sync last time I said we were able to sync to valk 2.8 million now we're end is able to sink to 4.46 million we're still implementing those ek snart's pre-compile but I guess they haven't been executed on the main shade to date so our sink continues besides that we're working on stabilizing our networking

code and json-rpc support and all that good stuff nothing on Constantinople okay thanks so much do we have anyone from Eve awesome hey Hudson looks like looks like it's me and Pavel public did you want to say anything otherwise I can jump in and just do a really quick update yeah go ahead cool yeah not a ton to report on our side still working on some tooling around rust and assembly scripted in particular which which is pretty exciting so we hope to have more to share on that stuff soon including implementing some of the pre compiles in

like in rust for example primarily focused on test net getting kind of a public test that up and running and kind of DevOps e fooling stuff around that the other thing I would say is we've been thinking a lot about the design kind of this EEI aetherium environment interface design and in particular kind of versioning around it and modeling this a little bit after kind of the EIP process but again kind of with the nice nice addition of like versions so we're kind of like sealing off the current version of what that spec will look like and beginning to put it in place the next core the roadmap kind of going forward what are some of the new kind of interface methods and things that we're going to introduce and sort of break in

a little bit away from pure EVM compatibility which we had been doing up to now that's it thank you I just reminded and alex has compiled rust EVM to help assembly and yeah maybe we'll try to use it at some point yeah thank you also he also pulled the what was it the Waze M interpreter out of parity and compiled that to was him or something so there's been some fun going around going on here as well great all right do we have anyone from the

research team to talk about sharding or charting areas plus Casper I don't think anyone's here from the research team oh absolutely sorry Lexi I didn't see you there okay well sorry either him didn't say hi so I would have done so far is it I got the I mean a few weeks ago I got this following the tip of the chain working so it's been so the latest instance has been following chain for about a week now it didn't fail yet it's to me pretty pretty stable way so and then currently

I'm testing and fixing the RPC RPC API and basically after this is done it's gonna be pretty much functional and I'm planning to basically tested in in within and fewer first just because they these guys have a big they'd probably be one of the people who are benefit most from front row baguette because of the smaller disk supply size requirement and actually that I'm going to do the the benchmark of RPC requests against two guests to see if there's any advantage and I think that would be some advantage so yeah that's my update yeah cool thank you and yeah there's no one from

research here so we'll just skip that and move on to the next agenda item we're back to talking about the difficulty bomb and the reduction or increase and block reward does anyone have any new insights or opinions on what to do about the block reward specifically everyone agreed on doing the difficulty bomb delay but what we're stuck on is what to do about the block reward due to it being a very I guess I would describe it as an economics problem or a Tripta economics problem that a lot of people didn't comment on last time okay we may have to table that one again then

cuz I don't think there's really been any changes to it another AIP was created to disable the bomb and I didn't put that on the agenda because we decided last time too disabling the bomb was off the off the off the table so let's see we might just jump into Constantinople then unless anyone had any other stuff on the block reward reduction or increase so I guess the question is how do we resolve this and decide what to do yeah that's a good question part of what I was thinking is getting people who really care about it and getting them on the call and seeing

what their opinions are or coordinating with some of the researchers like Danny who have looked into this and written up reports to see what their thoughts are because if we have anybody with a strong opinion it might just go through because no one has an opinion right now that's very public but the people who will really care about it are the miners right yeah they're definitely gonna have a say in this as well I've been meaning to reach out to some of them and get their opinion I know that some of them have commented on github I don't know if they've revealed that they're miners or not but I know some comments on some of the IPS have been from miners so the all the all the resources that are free

linked to were proponents of block reward reduction right I hadn't had time to look at them so I'm not sure doesn't make sense to try to reach out to miners to go get them on this call and hear them out or is like I know at least one I can reach out to great I'll hook up with you after this call then and we'll figure it out but yes they shouldn't be on this call giving their opinion on it I know a couple of miners from some of the pools and so I can reach out to them as well so maybe next meeting will be really like that'll be the biggest topic of discussion as far as implementation

of this it's very trivial am i right so this is one of those things that doesn't need to be decided about like and the next week or anything to be put into Constantinople well I remember that in case she was the case he was saying that the changes which included to include the formula of difficulties they they have some problematic bits about testing him and he was was it him he's saying that the basically is like sometimes you have to pray that this is going to work because it's very difficult to test in a test net but but I may be mistaken yes I think the problem is not I said we in

order to test the difficulty calculation formula we can draw on the regular block test because we need like millions of box so for last fork we implemented a new kind of tests and it's in there is standard test case repository but it's not it doesn't resemble the existing you know state test box interest etc so it required all the plaintiff Dementors to implement some new test harnesses to run them natively on their own frameworks so it was not something which we could run black box like we do with the high octane tests

yes that's problem this time around it should be easier since hopefully all trying to implement this already have that have implemented those test cases so it should be just a matter of adding new of the same kind I see okay um so does that mean that it is easier than it was last time is that that's kind of what I'm reading yes okay good so we'll definitely have a lot of people on next time to talk about this does anyone else have comments on this or any ideas on the way we should resolve this side I love suggestions too for that yeah just a thought we touched upon this

briefly on the last call but I think this is a very interesting example of a question which is less technical and more again I'm using this term philosophical economic for the reason is described like it's not technically it shouldn't be at least super challenging and as Martin said hopefully this sort of test harnesses are already in place and so I don't know given that we have Greg and Jamie and and sort of Boris here from fellowship with the theory magicians I mean I guess sort of Fe M is also a mostly technical initiative but I'm just I'm just raising this open question and I don't have an answer right what is the right channel for having these conversations is it fellowship of ethereal magicians is it the all core devs call is a TI p0 is their particular forum where this conversation should happen yeah

does anyone have from the fellowship of theory and magicians who are here have any opinions on that right now if not if you have one later you can always bring it up um no I don't have anything to add okay sounds good I would just add one more thing so it's not that people don't have opinions about this clearly there are sort of you know we now have sort of four or five competing EIP is so I think Hudson we should definitely bring this up on the next call and I think we should make an effort to get those champions like if possible sort of roughly one from each of those VIP is to make the case I don't know if we have any of those people on this call that's a good point we should bring the

champions from the IPS there cuz yeah there are and I guess when I said earlier there weren't opinions on this I meant purely from the core developers who from last call in this call but um yeah obviously we need to get more voices in here to kind of shape shape how people are thinking about this issue and make sure everyone's heard so yeah great comments there and we'll definitely try to do that let's see did anyone else have anything else to say on that I would like to add maybe it's a problem in ioan but I think the way to solve that is if within a if we delay

let's say six months the difficulty in some way we should try to keep that they're synthetic total supply that the difficulty bomb gives constant so we should we should produce little bit the block reward in order to keep you know the total supply at the moment that the difficulty ball clock starts happening I don't having exactly the same that having exactly the same total supply I think for me it's a good criteria to decide how much the block should be reduced yeah Jory I I I think that's one very interesting and reasonable approach here

I'm trying to remember which do you know offhand which AIP suggests that I think a freezie IP is the one that suggests doing exactly as you're describing yeah I don't remember either I think it might have been off fries and to be clear that's another argument in favor of that approach is that I believe it's what was done last time Oh interesting or just an FYI did he have we actually put a bunch of useful links in the agenda for this call if anyone yep I just posted the link to it so I'll try

to read through some of those and get a better idea of each each a ip's position yeah just know the thoughts I think the problem may not be that people aren't aware of the discussions and read it might be just problem of actually making the decision so something to ponder about this there should be some kind of voting on the old quarter or something I don't know Greg did you have something I saw you on me for a second so I wasn't

sure okay cool any other comments on this I I was just gonna say that I think the word voting is a trigger word yeah absolutely so so it was like the worst case scenario that you guys were to change the rewards too low then you alienate all your minors then they would like not mine the network or something like that and go to other networks in line yeah just trying to understand it yeah that's one of the primary concerns is my understanding we would just be pissing miners off that's the main one right right okay thanks yeah I was just saying

if we've got multiple IPS and authors inviting them to hash it out The Magicians forum or some other forum yeah might reduce the number of VIPs if if they can hash it out together yeah I'll put that as a welcome thing to do for me to get in touch with them but I think even more so again from a champions perspective scheduling a call dedicated to just that because I don't know that right writing more lines of text is going to help right it's getting the various champions together and they

may decide they're they don't really need all of those different e ip's they can come to some consensus themself hi I mean I don't understand how they could possibly come to consensus when like they also totally opposing views one don't want to with reduction at all and as everyone else wants about reduction if they can't they can't but if they can then we don't have to fight it out yeah it's worth putting up it's basically like yeah the likelihood of it

is incredibly low but at least we can say we tried so maybe a whole call that's just like a battle royale between the EIP authors would be really would be fun I'd set that up I do think that debate format could be interesting like like adopting some slightly more formal you know debate format where you have you know X minutes 5 minutes 8 minutes to make your case and then the other person has you know three minutes to model or something it could be interesting totally it could be horrible why would it be horrible we don't need it to fate we need the technical discussion

technical debate discussion or just discussion not not a debate debates just polarize people hmm that's a good point well maybe a public discussion on a call that's less less has less of a format and more of a moderator that doesn't try to make it sound like a debate would be better okay so let's go ahead and get into Constantinople on the agenda there is if you click on Constantinople or the link

that says Constantinople progress you'll get a chart of where people are implementation wise and I totally forgot to edit its gonna create two and I'll say under discussion all right so I just updated it so it's we're aware that's gonna create two is not finalized at all but it looks like there were some issues with skinning create two the implementation of it I know parity had an issue and then Martin you said within the EIP itself there was discussion based on that issue I think so can anyone kind of give an

overview Martin gave a good one earlier but anyone else maybe from parity kind of given overview of what the issue was or was it exactly what Martin said way do you wanna cover this one sure so so I think right now the usual real face is just that the skinny quick first specification it's not compatible with the IP 86 we also support EAP 86 in our land right now so that creates um some issues but it's minor issues and and actually those problems are ready to

like the the stuck stuck odor is different or the yeah and the RLP for my creation or dress format is different that's to usually have under create rule of code it's different it was different up code compare is yeah th6 so so it just if we could modify the skin equate to yet he or the Gita sticks to make those two yeah I ki compatible with each other that would save a lot of effort for for party yeah I think that's the

easy way of facing okay and pardon my question just be as I don't understand the technical innards of this but um was that the same thing Martin was saying earlier or Martin was that a different issue there producer kind of their incoming a little bit okay so let's go ahead and try to figure out today some of this as Martin suggested earlier so I'm going to the EIP now and seeing what can be done so it looks like Dimitri's up for option number two which I don't

know what he's referring to exactly Oh basically making it on Sergio Damien learner's comment there's like option to yeah yeah oh no go ahead forget them I learned yes so there are also an option to on the actual learners I see I didn't know which one he was referring to okay I think you're right that he's for option two on the eath on the IBAMA or myself okay so what needs to be decided first for Martin's issue and maybe that'll kind of waterfall into the

sheep here I was having yeah so I would suggest that the first decide should we show to read include the inner code or sha of the inner coat and for context old e86 uses the show of the init code so I would and that's also what Sergio thinks is a good idea and it has a nice property that the inputs to the final shop function has a fixed link which is nice I think so I would propose that views to show how shall be in it code okay what does everyone who's involved in this discussion think about

that way would it would it help your stuff at all or is it yours things too different I mean I mean our problem is just that the yeah it sticks doesn't come is no complex compatible with the skin equate to so so I mean for us it's probably ok to this for any solution will be ok on this and we would just want to make two tools back compatible so yeah I think what Martin proposes is slightly less work but it's it's not really like the work amount it's not

really relevant ok I don't know if anyone else has is involved in the discussion on the CIP is actually in this call right now does anyone else from the who's been discussing the EIP in this call who can have an opinion Aleksey might have an opinion Alexei I don't want to speak for you obviously but you were definitely part of that conversation oh well maybe at some point yes I was just when I was involved in this conversation I was trying to get the idea whether the this IP was ok for the people would be state channels who is actually is designed for but I didn't

get any reply and I just kind of dropped it at that point because it basically I just wanted to make sure that the people who really wanted this IP are are actually happy with that because otherwise it could be I mean oh you can just assume that if they weren't happy that would have told us that was my opinion apart apart from that it's I could I could see the the you know to be honest I don't really see a big difference in these things I definitely agree that pretending they 0xff is a good idea and there's an option to in the IP in terms of hashing of in it code I think it's yeah I don't actually I mean I don't go didn't go deep enough to

understand why it's better but agree could be okay but in terms of what way is saying it looks to me like they have already a lot of code which was trying to implement different AP and you try you basically have a conundrum whether to keep that code or just throw it away and then write everything from scratch right so that's why it's so that's why it's a bit confusing but this is I think what they trying to do so yeah I'm apart from that I don't have anything to say about this Aleksey when you talk about state channels I assume you're referring to kind of factual yes correct because when I met them in Toronto ed corn they were saying to me please you know can you you

know if you join in the the cold please can you ask them to do this create schema create or whatever they were calling it at that time so they really wanted that change to be in that's a really good point they they're definitely champions of this idea I'll make an effort to reach out to them as well maybe before the next call and you know either just find out that they're comfortable with it or if not maybe ask one of them to join the call and share why yeah that would be great idea yes thank you yeah that'd be great Lane so yeah so the second part is if you do an RFP list or a message center piece of valois or just repent o xff and I would suggest that we prepared I would set up

a costs if you want to do this calculation on chain it's big hassle to do or LP encoding on chain unless you do it potentially erroneously so is that part of the list the second comment from the bottom Sergio's comment when he analyzes all cases for create two addresses so you're referring to number two yes okay number two it's the one that I would propose as being the one we accept yeah justjust just curious on this I don't have really strong any of which should

we use but but what what are the problems that will out the encoding in green because our existing the so the current wave equation or grad stream as scheme already used the arrow key encoding and yeah so just curious what what are the problem like if we use a continue to use arrow key encoding so currently if you want to implement the current address scheme and do it on chain you need to take the nonce into account so you need to dynamically you need to know I mean if the nonce is larger than I don't know o X 80 then you need to or LP store that in figured

differently so you can't just naively I mean yeah it's it yeah you do it on time and actually I would add as well that the reason why it is kind of important to be able to do it on chain well that might be wrong but I think because this my main goal of this grade 2 is the counterfactual kind of association so that in most cases this will never actually be in most cases when the the state channels were created then the Creator will never actually go and change but in the case of arbitration they will have to be able to compute the

addresses of the contracts unchanged so that's why it's kind of more person in a real case yeah though it might be that in this particular case there are no such dynamic things if this is the message sender in the salt and the shell 3 and we know the size of them maybe the RFP encoding is trivial after all yeah okay so either I guess I didn't catch the end of that very well but it sounds like we're either still unsure of

it or we want to go with Sergio's option too Sergio's option 2 seems easier right Martin okay I don't think anyone cares particularly how its implemented as long as someone makes a decision is kind of what I'm hearing you know you know Hudson I think we could mark it as the tentatively decided but I would still like to hear the opinion of the the potential users maybe for them it does matter like for example would the whole point of the Krejci is to make the counterfactual instantiation more efficient so they could already do it with the current opcodes but it's much more efficient for them to do it with a

Krejci so if we now introduce the way which is make them less efficient again then I'd rather not do it I'd rather make sure that we do exactly what gives the maximum efficiency I agree okay that sounds good and Lane you can reach out to them are you only reaching out to l4 or there are other people doing counterfactual I thought maybe spank chain was yes Bank chain is Bo and there's some other people and you think there might be more lots of them actually these days I will reach out to spank chain and l4 I'm not aware of others but maybe we can kind of just get the word out or tweet about it or something or maybe they can point us at other people as well yeah that'd be cool and if they can comment on the EIP

Martin can you just do a comment on they're just saying as discussed in the meeting Lane's gonna reach out to a few people doing counter actual instantiation however we're leaning toward option 2 from Sergio's list yeah thank you and then back to the problem that parody was having which is different that's something else that needs to be decided but that's not something that we need to talk to is that something we can all we also can talk to the counterfactual people about way I mean I mean is it's more like I think I think if we if we decided the best way to do the skinny

created and the thing for us is that we probably want to get yet he 86 to be compatible so it maybe if no one cares about yeah he 886 right now them probably we can modify that to to to be the same Isis in equal to that would save save ask some problem or getting the to just KK toes - yeah it's fake and skinny way to implementation to gradual what I would say about EAP 86 because I was trying to revive it at some point and I found it was pretty difficult to

do so I would just completely ignore the EIP 86 for now because even if it does come back it will have to come back when have completely different revised form so I would just suggest that we kind of don't mix it in right no 86 was a cat abstraction right yes correct admit that was actually including the they create a skinny crate to an hour later on this crease Kinney Krejci was kind of extracted out of it to be salvaged so that like the whole 86 was bit too big for to be implemented and then they one of the useful parts were skinny crate - I don't know how the process here works

really so it's more of a question but like does it make sense to close this down and say that you know in some definitive way say this won't be implement and then create a new EIP with whatever the other parts are in the future when you're talking about that are you talking about from 86 to its many parts or are you talking about specifically 1014 to spread it out 86 to its many parts that is kind of what's happening with skinny create - as my understanding it was broken out from 86 exactly so shouldn't we just like March 86 yes we don't have a process right now for putting rejected or withdrawn we

really need one because that's actually any IP one and that's also something the fellowship of ethereal magicians discussed I believe so they might touch on that later potentially but um yes that's a good idea let me put that to withdraw 86 since we're now kind of busting out pieces of it that that would be a good idea okay thank you all right so do we have any other issues with what we just discussed is is a way after hearing a Lexi's argument do you have any rebuttal as far as not using 86 not using 86 when you're implementing 1014 I think that work for us so we just

removed so yet here it's six code I think that work for us yeah okay great is there anything else that I missed it hasn't been figured out about this of course pending all the counterfactual people chiming in on which I guess would be an which one to use out of Sergio's list for the encoding or the other cases for create two addresses there anything else I'm missing great I think we figured this one out for the most part and we can move on so what is the next one so the next one is

a successor to 210 simple block hash for factoring and we've keep going back and forth on this and I kind of wanted to decide today if we're just gonna kill it or if there's any reason to keep it alive for Constantinople and at this point we were looking last time for a reason to implement this and anybody that will champion it and I don't know if we even have that still so is there anyone here who has opinions on e IP 1218 simpler block hash refactoring and any reason we should put it into Constantinople it was the author of that one you know what the end that was Vitalik Vitalik I

think was both 2 10 and 12 18 but I remember last call he he had a reason for it let me look at his the IP and see I believe the main reason for that is the light wine support and I think in order to decide whether we still want to keep it or not we have to ask the people who implement light clients that would be the best option I see ok who at parity implements light clients Fred I forgot who it was it was someone sorry I had to move my cierra problem sorry

what was the question sure so who implements light clients support at parity it's a mix of people Pierre is officially the owner Ovitz but yeah we have we have like probably four or five people working on ok can we can you ask them basically what their opinion is of VIP 12-18 which is a successor to EIP 210 because according to Alexi light client implementers may have some opinions on it because it would help them implement like clients better or something and then is it who implements light clients and get older that's right

and he hasn't been on a call in a while so let's reach out to him and see let me see reach out to salt I have that as a note now has been Nimbus team started joining these calls yeah yeah Nimbus is on here today actually did you yeah does any other clients have opinions on this Nimbus or anybody I will take a look ok great so the chances of this getting into Constantinople are rapidly decreasing as time goes on because we don't want to be adding anything too late and this is already pretty much too late but it's still good

to get opinions and see about throwing this in the biggest reason to not have this is because the testing team which is pretty much Dmitri right now said we shouldn't include it so obviously we don't want to kill it if there's a major reason to put it in but right now I think that we haven't heard enough people speak up about it but we want to reach out to the like line of letters to see their opinions anybody else have an opinion on this or a comment or disagree with what I just said okay so for now we're gonna get some more feedback from people the next

one is net gas metering for s store operations I know parity team was having some issues implementing this and so basically for the if you look at the chart the people who have implemented this are trinity aetherium j s sorry i'm looking at the wrong one where is that no one's fully implemented it yet but I can tell but I know guest was not having problems with it and aetherium J you said you weren't having problems with it either right yes right so if that's the case in parities having issues what they've done is they've developed a IP 1283 or not

developed I should say I don't know whether did that were their implementation isn't that but they've written 1283 as an alternative so I think Weig wrote that do you want to kind of go over the reasoning behind that e IP and what's going on with it yes sure so that's the way we had some issue is with the IP 87 so let's just because some some some augmentation we enabled after the Yeti six to six five eight and the conflicts with with some of the requirements for twenty seven so so the issue is that we can't get the 30 the 30 might efficiently and it either

needs to cause more memory or or we need to to make I mean we need to do a food if of the station's try which is expensive and it makes the transaction that executed later on the block slower so we just yeah so just kind of a performance issue for us and I know we had different opinions on how much performance impact is but this is indeed a concern and I think in the future if other clans also implement this optimization this kind of also be a optimization blockers so we can kind of

want to - yeah so so so we got another draft the IP VIP 1283 there are two version provided here basically what it does is it twists the tuple of starch original value current value and the new value as a state machine and you you don't need any dirty maps or anything you just use this as a state machine and issue test use forecast refund and in this case

Alexei found found out that its cover sold cases for yet he 87 so yes so right now talking about the version two after yet he 1287 and 80 83 so so it covers all the nearly all the use cases for the 1887 and we think it may be a good replacement it definitely needs some more reviews and if you Clent have no problem implementing thirty-sevens and you will also have no problem implementing the 1283 version two and [Music]

yes oh uh well so yeah so I and and I guess that's that's basically the sum sum or about 1283 so what yes so basically because we had yeah yeah so guys I have to drop off in a couple of minutes but I just want to say something very quickly about this before I go so yeah I really looked at these differences between the this - IPS which we'll discuss couple of weeks and we believe now I mean at least I believe that they might actually be equivalent in terms of like how the the the gas the gas consumption in the end the only difference would be

that the the gas usage at any given point might be slightly different so it means that the IP 1283 sometimes might require to post more gas upfront than the gas than the AIP 1 0 68 86 this is for 87 but what I think we should do is that we should I try to try to do that we if we formally prove that they actually equivalent then I would just say that the issue will become much more trivial because we won't need to be the question won't be about which one is better because they would be they're doing it's pretty much the same thing so I and I think in if that is the case then we should you choose the 1283 because it's a it is a

less performant impact so that's what I want to say um can you one speak up as a counterpoint to what was just said by way and Alexei especially if they understand Nick's argument because I was reading through I was reading through the Alcorn devs chat and I could not understand next counter-argument we don't have to go into that but I think it's not reasonable to I would like we can try to make a guess and another PR and see if it's it's equally simple and if this seems to be the better of the

two since it's less processing okay and so I would suggest that we serve it next week yeah I agree yeah we'll try to I mean when I you know if I have time and I will coordinate with with the way I think I might we might try to find out some kind of way of proving it but um it might be for me I wanted to give it's like go and see if it works and by the way I'm just talking from the call thank you very much guys bye thanks lexy bye guys kid I had a few words to this conversation about it - yeah bees I'll go right ahead if you had any

comments yeah even though in theory oMG both here is looks pretty straightforward to be implemented I would go with 1283 incase if in terms of gas meter in base both yeah he addresses the same problem my point is that 1283 is more elegant in technical point of view than 1087 I I think we should ask Nick if 1283 addresses the same issue that he has addressed in 1087 and if

it's if he confirmed that that's they are address address the same issue then I would I would go with 1283 so that's it ok so it sounds like we have way and Alexei looking to compare the two which would be very helpful so that'll work out just keep us updated in the awkward Debs chat way especially with updates to the e IP and we can discuss it on the next coordinate call hopefully Nickleby there to discuss it as well and I might try to reach out to him between now and then to let him know kind of what

discussion went on in the core dev call yeah yeah great anybody else have comments on that okay great and Martin you mentioned that get would try to implement it hopefully yes sir and I do want to say that for Part II we have we also have a key are implementing the 1283 that was done a few days ago so it's still version one but we are going to approve that version version two of the AIP 1283 okay great next up or did anyone have any other

comments on that okay next up we have AIP 1109 remove call cost for pre-compiled contracts Jordie do you want to give a quick summary of what that is and kind of your reasoning behind supporting that EIP yeah well mainly it's a very easy IP mainly what it is is just to remove the gas cost of the calls to the precompiled smart contracts the big problem is for example sha-256 compared to smart contracts it costs only sixty units but the same cow just for calling it because 700 so it

makes absolutely no sense at all and because when you are coming as precompiled smart contract you have to load anything because it's in the same code in the client code I think it makes no sense to charge with these gas costs so the proposal is just removed the 700 presently 700 for the call for the cost of the smart contracts mainly is name is that do everybody with a comment on that yeah I promise removing it completely it's too much I think in the first

instance we should be a bit more careful that's about it otherwise I'm for reducing it Matt yeah so I left a comment on that PR right before this call I guess an alternative approach I don't know if you considered it as to leave the call semantics the same but add a pre-compile opcode to the EVM that then just does the the price of the the pre-compile it's been called it seems like it might be a little easier on the the call logic and not have to you know you don't have to set up all that scope and stuff depending on your implementation for I think it's it's fine also itself exactly

the it's ably good so for me I think it would be good also to have a different knob code and the thing is that although all the pro combines my contracts they already have a cost depending on does my contract so yeah we can set up maybe a minimum but then it should be added to the gas cost of the specific smart preoccupied smart contract yeah absolutely maybe something along the lines of your first you put one item on the stack and that's going to be you know the the pre-compiled address you ought to call and if it's there then it uses the existing pre-compile gas calculation mechanisms and if it's too

large then it has an exceptional halts otherwise it it executes stit and then if this precompiled contract is not there then maybe there's zero gas cost and it just executes as if there was a no op or something okay okay go ahead Jordi it makes sense just to define now yeah yeah our for if you call us my pre complex mark contract that's not that that's not define it so specify every kind of yeah gas cost it could be 700 the saying that normal so this will require a hard fork and an according to

math suggestion it would also require doing a pre compile am i right I think it would require adding an EVM opcode and in there it just checks for the pre-compiled I think it would be slightly easier to add an opcode than to modify the semantics of the call to do that okay we estimation yeah what other people think as far as implementation cost here and like how difficult it would be it sounds like it'd be really hard on testing at this point to put it in to Constantinople but the maître is not here to speak on that so from the VM perspective it's it

breaks the abstraction because currently VM doesn't need to know anything which which contractor actually precompose because it goes just cause that and get some result so like in some sense probably most of the implementations the VM doesn't know that and that would be also different depending on the chain configuration so that's complicated so so I I liked what I heard I liked the version with additional adding new opcode for that it seems quite quite

better and something alternative I just figure out would be to allow pre compiles to to refund some of the gas because the refound counter it's it's mostly handled by it handled paid per transaction so it's it's on the on the boundary between EVM and the client so that it's something that it's not strictly know that's EVM is not strictly responsible for and from the implementation perspective it might be

easier to actually add some grass to the refound counter in the pre-compiled implementation or something like that and and get it back at the end of transactions oh yeah but actually as the heap is written it it doesn't care what were these pre compiles it's valid for everything calling anything below 250 yeah and I haven't read it so so so sorry for a furrow for dumb comments anyway because that was like something I swear of that doing call right now I think you raise a good point that I mean your abstractions in your code base are different than ours so it's yeah it's

debatable what's easier for you yeah I want to add that on these yeah it depends on the smartphone depends on the precompiled smart content has already a different cost so IBM should know that because it's calling a difference mark on track of it they know it right now and about the removing you know the adding and then removing part the problem well maybe the problem on that is that there are some intensive firm for example let's say checking a miracle proof or a long miracle proof in the chain this is a very intensive sha-256 call that case and this you will have to add like a lot of upfront gas that part

can be returned to that I think I don't know if it's good idea on that I think it's better just to charge what it's supposed to be the same way for example this is a j-3 the difference - sha-3 Sony it's very in dust and you know at the tools - sha-256 is 760 if you if you are a dog together okay do we have other comments on us okay I hear my cat breaking things lanes gonna take over for a second hey guys Hudson warned me this might happen so

all in me all in the plan cool if there are no more questions or comments on this topic then according to the agenda I think the last item here is the Fellowship of ethereal magicians update okay good I guess we can begin um like just let me say one thing and welcome just to put in the notes I will update the IP 1109 for touring this coat this new overcoat excellent thank you very much dirty and then yeah Jaime feel free please take it away sure yeah actually I think Greg might be a good person to introduce the vision of

the group a Greg do you want to get it started and then Boris and I can talk about Berlin yeah I don't have a lot to say because for personal reasons I haven't contributed all that much since the first meeting in Paris so mostly I've just been gratified that it's rolled on without me and just the desire to get a forum going where people can meet in person and work together plus organize their work in between meetings and I seem to get the feedback the people are really enjoying doing

that enjoying the opportunity to meet in person enjoying having slightly more structured forums to work in and there seem to be working out the ideas not necessarily the way I would do it but that's just fine and take it away okay great well that's a good overview um so yeah I guess I'll talk about the basic mission and principles of the organization basically the idea is the we want to nurture community consensus and the technical direction of aetherium and we do that through ultimately producing high-quality EIP

he's and of course I'll core devs have been doing that the whole community has been doing that but there's a lots and lots about VIPs so especially ERC's and so we want to facilitate the work there and allow working groups to form which we call rings and and and to proceed from there and some of our principles two of the key ones is an open process and of course how to make decisions on things which is rough consensus and running code and some of the key things that we do the practices we like to focus on in-person meetings and that's why we had the Council of Paris and the

council of Berlin which Boris will will discuss and keep places that we maintain we have our wiki where we keep our information and we have the forum which is etherium - magicians org and in there are a lot of discussions about all the different e IPS and other issues in the community and it's a threaded forum and it it forms a better place to to discuss things then then the github issues have been it's okay there but and when you have a multi-threaded forum its issues

get hashed out a lot better where you give users a lot more ability to to to guide the conversation and and add content things so that's that's the big overview on it on the magicians and I guess I'll turn it over to Boris now to discuss I met some of you and and participated in the the wallet unconference that's that happened outside of Eid Khan and got really pleased with what everyone was working on I said I stuck my hand up and said sure I'll help ballin year to to organize things in in Berlin and and ended up taking that on and getting sucked into really the great

community that's forming around etherium if it went well um you know Berlin we had about 70 people over two days at sea bass lots of things got hashed out including really that people had a desire to do more work into volunteer I think what was interesting is that a lot of non-technical people showed up as well I think we're still struggling even just on this call with with what non-technical means but essentially there's lots of people that want to get involved and want to help and ideally we can do that my point of view and I think you know the theory of magicians is a forum it's a domain Greg has been really

good about indicating that no one's in charge everybody's welcome and it's just people that do work and there's a Greg share the other day about the rainbow gatherings and the rainbow family and they talk about that is the largest non or organization of non-members in the world so I'm a proud non member of the magician's and that's kind of what the the style that we're going to do because it's important to the way we're trying to stick to the principles of decentralization but some of that can help with even just organization so we have a github repo where a wiki that got formed at in Berlin we have some rings which are working groups we see those working groups really much like Hudson

already drives the calls and asks for consensus for people working on particular eeap's it can potentially pay scale technical improvements by having the people who are interested in certain areas having ways to gather together and come to consensus around that and when it comes up and impact score devs and and core clients then we have a set of experts who have hashed through it already we just announced Prague we're gonna do the same thing in Prague ahead of Devcon if will not be like DEFCON content in that we actually do work and then and and to make progress on eats and and and ERC's so welcome everyone to get involved and hope we can

help support basically scaling and improving some of the technical discussion and decision making whether we really includes anyone who wants to get involved cool thanks you guys that that's really exciting I have just a couple of questions before we end this out we only have a little less than 10 minutes so real quick I know the all core devs call was discussed a bit at the meeting in Berlin was there any really good ideas or suggestions or things that people might have somewhat come to consensus about about how either the all core devs call interacts with the rest of the ecosystem or changes that can happen that make it a little bit better because

we really want to be kept in the loop on that we being the kind of the core devs and myself so that we know kind of our role in the whole thing or what people think our role should be so we can kind of adapt I'll take a crack at this and Greg and Jamie can can chime in so I think one of the things that came up there I think this spreads to even things like III search where it was clear that questions like who owns the roadmap how does the roadmap get decided how do core devs make decisions how do you eat evolve eeap's theoretically are

the things that need core protocol changes in the ERC's are the things that are more rough standards at different layers and I think mainly it was more like this would be helpful if it was written down somewhere because right now people don't know the answers to these things so I think there were more questions than answers and an offer to help figure some of those things out and that even just things like eat process and rejected and so on that needs to be tightened down and clarified because I think yeah yeah I completely agree I think that's a good that's good feedback do other

people have any comments on this either from Fe M or not um I'll say this much there was one session in particular it was I think I'll just call it Cori IPS versus implementation and it that I think it was at that session and there was a discussion about how working groups would would would come what come to consensus and how that would be recognized by client implementers and and the core devs and that there's that that the work performed inside of these

different rings and and if there's a particular working group that's just focused on the IP and there's people coming together on that issue that their decisions would be recognized and implemented possibly in clients and possibly elsewhere are recognized as and then of the right word is or authoritative but that that body that's forming around that issue would be recognized as having some kind of authority or some kind of record you know wide recognition that they're what they come to consensus to is is the community consensus so long as the process is open so you have a ring let's

say there's the wallet ring and they they come to consensus on something and there might be all the what you know the majority of the wallet implementers are involved and there's open process and then if they reach you know if they have their their flow that might be very similar to the way the core devs or the EIP editors have their flow for reaching final on an EIP that that that would be widely recognized and implemented so you know that process needs to you know solidify and I think that the all core deficit have done a really good job too either way as have of course the EIP

editors and so the more education there is like that's big component of of magicians it's educating people on these processes and then a lot you know facilitating these rings so they can start to govern their domains so that's that's my perspective I don't see what so what you guys think yeah that sounds great anybody else have comments before we go yeah just a quick one something that would be interesting to hear from Jamie Greg and Nour Boris on is for those for the Chordettes right how can the Cortes

contribute or get involved um I think one way I mean I was saying this recently is the Chordettes is like a ring really that that I think it's the first ring before magicians or anything else existed that makes decisions about the the protocol as defined in the IP one and I think as such you know it's established many of the conventions that we're all following so I think the more that the Chordettes can describe its process through articles or more more

documentation the and yeah I think that would be very helpful for the wider community that the wider community could see what what makes the Chordettes work why is it why is this working so well why and yappi editors have done better with this in particular because they have obviously IP one and all all of what's going on in the issues so I think the more that can be done in that regard like just documenting and and participate you know just showing up really to the open process that the magicians and contributing to that and and changing that in a way because I think the experience here is so great you know

bringing that out and helping everyone see why it's working and then spreading that to all these other efforts these rings I think that's that would be my recommendation so in the spirit of decentralization and it's crucial I mean the SE C's recent decision was in large part based on this is decentralized there is no organization controlling it we we can't really call it money or anything like that and so the openness and decentralization really counts and you know to a large stand core developers simply by as developers

participating in the rings of you're relevant to the IPS that are relevant to them just means that by the times things get to the core devs a lot of stuff has been hashed out and it's just much easier the core devs aren't aren't facing controversial choices as often and this is what happened with the IB editors we got you know some very controversial proposals slammed into us and we had to clean up our process such that we could handle those and to some extent The Magicians you know took on handling that sort of controversy and to some extent we tried

to draw lines and say we're only handling tactical controversies you can take your political arguments elsewhere and I don't know where elsewhere is but it's not here that's that all right well cool well we're out of time thanks so much for chiming in fellowship of a theory magicians folks and thanks everyone else for participating I have a long to-do list to reach out to minors to reach out to a few other people from the light client team talk to Nick and so hopefully we all get this stuff done and we'll see you all in two weeks bye everybody thank you thank you [Music]

[Music] [Music]

[Music]