All Core Devs - Execution #81

Transcript

[Music] [Music] [Music]

[Music] so [Music] [Music] hello

Hudson Jameson: and welcome to ethereum core developer meeting number 81.

this is um hudson let's see real quick okay i just muted someone who was typing um let's go ahead and start with the agenda this is going to be a super packed agenda today so let's try to be cognizant of uh getting through your topics really quickly and with um yeah with like minimal interruption and uh not too much off topic discussion when it comes to the technical aspects if it can be talked about in getter or the magicians just make sure to keep that in mind thank you all very much

and now we are going to start with actually we're going to start with efi but is anyone here for open rpc because i remember from last meeting we said that we would start with that is anyone here for that okay we can skip that for now let's start with the efi stuff um and i'll just let's um tag team this with james is that okay with you james

James Hancock: yeah i would actually discuss um any of the efi or eips that are looking to be in berlin and then have a general the general efi

discussion happen after

Hudson Jameson: okay do you wanna just take it away

James Hancock: um yeah i can do that

Hudson Jameson: thanks

where

James Hancock: let me grab the agenda so i have the list of the number of vips clicking around so for berlin coming up the there's been a couple eips that are almost ready to get in and then there's recently been in um

the eth2 deposit contract is looking to use a pre-compile so they can validate um the bls curves within the contract itself which they can't do in solidity so that gives us a schedule to schedule around and so the eips that are close to being ready and then that eip should be a scheduling window the ones i have seen as at that stage would be greg's eip greg colbin three two three one five um 1962

or the bls one that uh the eth2 team has created and it has created a proposal for a simplified version that only has the curves that they need so we can talk about that at the at the time that happens we should do we can do that at the as the last eip and that list then there's danos eip which is about scheduling um doing schedules for the um scheduling but with block time for the forks and just making it so it's easier so we can predict when those happen then there's the the difficulty bomb eip that i wrote for updating the difficulty bomb changes the algorithm and that one is

two um two five one five so let's first go into greg are you here

colbin he's on mute okay

Greg Colvin: yeah i'm here

James Hancock: so we could talk about that one first as possibly for inclusion for berlin and then after this discussion i had the first scheduling starting to talk about scheduling and then we also can talk about

uh praguepal which is on the agenda today as well

Martin Holst Swende: sorry if i may i just i think it's wrong to say talk about inclusion for berlin i think we should talk about eligible for inclusion period and then once the test cases exist and implementations work we can see if it's uh well kind of what upgrade window it goes into but i don't think we should do like we've done previously and say this goes for berlin and then kind of halt everything due to something that doesn't make it

into that

slope yeah

Greg Colvin: i agree we need to get the implementations much closer to ready and then say let's go

okay

Martin Holst Swende: i do agree that we we could make call today like and say yes we're all for this e or some other um go for it

that i think we should and can do yeah then

James Hancock: that was more of what i was intending and the as far as the scheduling goes the only one to really figure out when it when it could happen is the is the signature for the eth2 contract

and then whatever ends up is ready by that time can also be it just would be helpful for me to get an idea of who wants to kind of hit that timeline and if and then as a group are uh getting the general okay for that not saying it will or will not

could

Greg Colvin: uh could you remind us what the timeline is

um craig

James Hancock: the other greg are you here from the e2 team so the eth2 deposit contract was supposed to be july i believe july

29th

Tim Beiko: i thought maybe i'm wrong here but i thought

that uh the e2 deposit contract would happen uh sorry the e2 beacon chain launch was to happen around july which means the deposit contract would probably be you know weeks to month ish before that yes so i think like june is probably

oh in the system i realized i logged in from the cather's accounts my bad yeah i should mention that 1962 elsa has a complete implementation so it's it's not that showstopper

James Hancock: yes so the the bigger conversation is by june which of those could be ready so

that the deposit contract could be made and then which of the eips could would would be would we accept as like efi for that kind of before for that so that the authors of the ips can either get ready and be and make it for this window or make it in the next window when as the next fork happens is that kind of does that feel all right martin the way i said that

Martin Holst Swende: uh yeah

okay

James Hancock: so then for greg's vip is there any uh any updates

and is there do we have the sentiment that if if it was ready at that time that it would be able to go in

well

Greg Colvin: it's fine by me but i'm not i'm not currently implementing a client um so i think martin um who else dano here

Hudson Jameson: yeah dana's here um i would say greg can you give like a two sentence overview of what your um eip is again just as a reminder i see there's a lot of new people here today

Greg Colvin: okay um the proposals out there essentially essentially it adds three op codes at this point possibly

two um there's just to begin sub up code to mark the beginning of a routine martin and i have been discussing that maybe just a jump test would do um but you have to have some something to go to and then two two op codes one of them is just jump sub go to a subroutine and the other one is return sub come back um for most for most implementations you would simply have a a return stack so when you jump to a subroutine you push the current pc uh onto the stack and when you return from the subroutine you pop the stack and uh

resume execution where you jumped from and so it's it's really just that simple it's a two-stack design just like fourth so it's uh basically getting the evm up to uh 1970 standards

uh yes i just want to add something to greg's comments basically uh i think that's basically what other machines are doing so like with some subroutine jumps and uh return address stack uh yes so that's pretty standard so um uh and also uh the the lvn compiler could support that uh with a few uh modifications so uh

yes i think this is a good uh eip that we should put it in thanks so one thing that

Péter Szilágyi: we've been discussing with martin about the cip is that uh on the surface it looks uh really nice and we are wondering how much time would it be to hack solidity so that it actually can use this so that we might somehow try and run some benchmarks against existing contracts because it would be really nice to be able to see the actual number of what what this would mean

from uh yes but it's up to the solidity compiler to do the uh change and it has nothing to do with any uh uh solidity language level uh

modifications basically it's just a compiler change and the real change yeah

Péter Szilágyi: i know but the question my question is that uh it seems so the whole point of the of this subroutine is of the subroutines are to make the generated code faster but it would be nice to actually confirm that it does indeed make it faster before shipping it

Greg Colvin: is anyone here from solidity

doesn't sound doesn't sound like anyone's here but i think like like from the perspective of the compiler i think our

lvn based compiler could support it very easily so the

Felix Lange: the request was not to um like you know have all the compiler changes ready just before the hard fork including this eip but the idea was that since it is unclear if you know it provides an actual like benefit to the performance of let's say solidity smart contracts i think it would be very good to validate this eep before deploying it in a hard fork by basically just trying out the changes i mean the the the evm changes are implemented at this time so it is

possible to actually spin up a a a small uh laptop uh network and then you know use a modified compiler and then just run some benchmarks and this is basically what we we were thinking on the guest side would be the next step for this eip because um it is such a low level change and you know just i think it deserves to be evaluated before inclusion

Greg Colvin: okay it's unfortunate the solidity people haven't come

James Hancock: um i can help connect you you with them as far as like assuming that we have this the solidity benchmarks is there any opposition to

having this in

our strong feelings no we we discussed this a bit in the gut

Martin Holst Swende: team and i think yeah as a whole we're supportive of this uh proof of it to be eligible for inclusion and there was one thing though um so one thing greg already mentioned that's another stack a parallel stack so that's a kind of big change to dbm but it's it's not a show stopper in our opinion another thing worth pointing out is that if we do have the begin data sorry begin sub op code it means that when doing the jump test

analysis we also need to mark out begin subs and forget this is easy we do a one pass and mark code sections and data sections but other implementations which specifically look for the jump desktop code they would have to either convert to our style or they would have to do one more jump test analysis basically begin

sub-analysis yeah just an implementation detail at the

Greg Colvin: at the end of the eip there's an example laying out how subroutines

are going to show up in the assembly code so i think it's pretty clear there the the difference in gas count um actual measured performance i think would have to be better but that would have to be measured but certainly it's going to save on gas substantially

yeah so we are expecting the same thing it would just be nice to actually confirm the numbers before we ship this eip

Greg Colvin: of course

so we can have

James Hancock: let's add that as the next step for the eip and consider that good

Hudson Jameson: sounds good to me

so um i have a quick

question though so i think so there's a awesome implementation attached to the eip against the gas code base yeah

Greg Colvin: there's a pr

the ip mentions three up codes whereas uh the implantation does too

Greg Colvin: yeah the implementation is uh earlier

yeah okay okay

Péter Szilágyi: that's fine i was just wondering which one is the canonical version then but yeah okay then the

ip cool thanks yeah

Greg Colvin: i did the pr earlier just to be sure the things would actually work going into geth

okay great um dano

James Hancock: do you have any updates on your eip

i'm not remembering the number right now

two four five six two four so one thing i was thinking of the possible change uh one of the i don't think um jason carver's on call out not close to my zoom spring his concern was going back a thousand blocks to check might be uh too much load for lighter clients that don't store as many blocks so one thing that crossed my mind is instead of going back a thousand blocks to check the trigger we could go back to ten blocks to check the trigger and uh with those ten blocks back that's going to be far enough so that the armors will have the armor limit of six so we won't have straight armors for when we trigger the upgrade so if 10 before a thousand is after the times another thousand we

would do the upgrade so that is one change i'm considering i posted on eight magicians and i haven't gotten any feedback on on that particular suggestion so you know mostly i think we're just um haggling over how far the look back is um and whether it's going to be you know zero or ten or a thousand for this and uh probably a discussion that's better to have on the e positions than on the call but i'm willing to have another call if people want to

James Hancock: assuming that number gets worked out and and you have that conversation with jason dano is there any strong feelings about

having this be included or not included after that point from the group that's more of what i would like to get out of this conversation

is um i think we would need some testing the current uh testing structure for these activations i don't think quite would support the look back so it needs some updates to the reference test files and i'd also like to see some live transitions before we go to a test net so there's there's more of a testing burden on this and it looks like the uh most of the work on this is in the test code so that's mostly where i think the big work for this is yeah

Martin Holst Swende: maybe in particular because in testing scenario

we're going to run into problems with we have to use synthetic

times right yeah multiple objects like but

James Hancock: i think he means that you have to do fake times in order to test that the time is actually happening right

Martin Holst Swende: yes

no i'm thinking like a purpose test let's see the purpose test net where we would have people come on and get a few miners you know kind of an hour before forks do the fork and then dispose of it just like we've done with some of the other testaments before a transient testing not a persistent test net

Martin Holst Swende: yeah i was thinking more about actual test cases um high test but maybe that's not a problem because it can just ignore the system talk and use old timestamps for all blocks so that's not a problem

yeah the time step is into actual block centering that's the type stamp we would use so we can totally set up a stream of fake data to validate as well

James Hancock: so for testing in the live transition things is that something you see as could be done in the next month and a half or that you'd be wanting to pursue for hitting a june window

that's not going to have to happen i

think we should come back to this for two weeks and make sure my schedule will support that okay so just a question for me i i can't really make it or tells did we decide anything regarding ep 2315 because as far as i know only the guest team gave a thumbs up and i'm not sure if that's sufficient i would assume not well yeah so i think dana said good um i have

Hudson Jameson: a question for way and anyone who was on the parity team like parity ethereum client team what is your involvement um right now in the open ethereum initiative and is that something that is we should consider you guys having

like an up-down opinion on this because what i heard was that parity technologies won't be supporting parity ethereum slash open ethereum after q2

uh we will um i mean

Wei Tang: we will still provide support for opening serum for at least the next artwork and there are a lot of other teams for example the geniuses they are uh taking a lot of the development job over so yeah so i think we should be should be finally should uh open ethereum should continue to be considered a usable client implementation

great yeah and

Hudson Jameson: the question wasn't as much that because i knew it was going to continue is more can i turn to like you or someone else from the team who should i do you know who i should ask for an up or down on certain questions like if eip 2315 is okay for the client i think you're the only one from parity here so you might be the one to give an up down if you're comfortable with that

Wei Tang: yeah you mean the the the eip for the

uh structured uh which one is it the simple subroutines the one greg had oh yeah yeah so uh i i think that should be fine for us it requires an actual stack but so i don't see any problem of that

Hudson Jameson: awesome and then i don't know if nethermine's here today that would be the only other really active client except c plus plus who doesn't always come to these meetings am i right james or who am i missing

no that's

James Hancock: that's right trinity

Hudson Jameson: oh that's right sorry trinity that that's another good one they've been focusing so much on beam sync and 1x i uh forget when they come to the calls who who's from trinity here most of the time they're good with stuff so if they're not here i think we have enough teams saying that it's okay to move up move with greg's ahead as an efi

i agree well

Martin Holst Swende: sorry for interrupting james you can continue

James Hancock: oh that's perfect so um greg's eip which is the number of two three one five moving to efi dano's eip did we move it to efi or we did we i believe we we had like a general thumbs up but you wanted to talk to jason did we move it at that time or did we say we were going to move it after that time

Martin Holst Swende: i'm not sure if we officially thumbed it up did we

Hudson Jameson: i thought we did last time i thought we officially said it's an efi meaning we've given a thumbs up for it being a good idea but i don't know

you know what actually you're you're right i don't know if we did or not dana do you remember

why did you take my sample oh say that one more time it cut out i didn't think we gave any you don't think we gave it an efi

Hudson Jameson: okay sounds good we can continue to not have it in that status um as as long as you haven't talked to jason

yeah i think moving the time from 0 to 10 to 1000 is

Danno Ferrin: such a fundamental enough change that it shouldn't be considered

um state on october past where it's at

James Hancock: so then let's wait for that conversation to happen and then we can revisit this as

efi

exactly come back in two weeks i'll try and get all the games in the next two weeks

James Hancock: okay so that is it for that um the next one i i've i wrote a proposal for this one is two two five one five which is an eip to address the difficulty bomb or update it and i wrote the proposal last week and sent it out and had a lot of good feedback from from the core devs and people on twitter and the general idea is to have a have a block activation number where the

difficulty freezes and then after that point increase the difficulty at a consistent rate and so we uh so there's there's an eventual uh that leads off until eventually the network can't uh support the block times become too big for the network and i'm not exactly sure how to run any how to run a conversation on an eip i'm doing so maybe that should be you hudson

sure so looking at this um eip let me just pull it up real quick so it's eip21 um was it two one two five one five i believe it's only in

um is it even in draft right now it looks like it's just written it's in a yeah it's in a and it's it's in a pr it hasn't been merged

Hudson Jameson: perfect okay that sounds good i was just making sure i was on the right page um all right there's a few things so since my assumption is you're not a client dev so you wouldn't be able to put this in but i think that um as far as implementation and testing goes but let's just talk about and just a paragraph or two the general idea of how this is laid out and then we'll get some opinion and then after that we'll see if there's you know a lot of support some support no support that kind of thing

James Hancock: so the the general layout is that the difficulty bomb has gone off a few times sometimes due to um moving a chain having to delay a fork and so it goes off for a while and then most recently it went off because um i had missed the miscalculated it and then it and it wasn't double checked so we we weren't sure when it happens and that's primarily right it's primarily because the difficulty bomb adjusts is affected by the network uh there's the adjustment factor that happens within the the out within the block like trying to make sure

the is between 10 and 20 seconds and if the when the difficulty bomb is unsurmountable by that adjustment period it depends on the current difficulty on the network and because we don't know what the difficulty will be in the future we can estimate it and there was a great um calculator from

um from oh ether mine

Hudson Jameson: or well it's they have like three names bitfly ether mine etherchain

yeah

James Hancock: they made a great calculator for predicting that the difficulty bomb as it is now it still relies on assuming what the difficulty will be at a certain time and

over time that will get more accurate and i think it would just be a lot easier if we removed if the if we split those two abstractions and kept the difficulty bomb because i've as i've heard from the community there's a lot of people who have strong feelings about keeping it we can at least make it more usable for knowing when it will happen and how and its effect and so it's easy we can address it easier as core devs

Hudson Jameson: so any questions on that anybody have um comments

um so i'm asking

Martin Holst Swende: as i understood it first

we would freeze the difficulty but you were talking about some linear increase

James Hancock: yes the original proposal was to freeze the difficulty and leave it at that but after feedback from the community it made sense to have it freeze and then linearly increase at that point so at block 10 million and 500 000 the parent difficulty equals the block difficulty the block difficulty equals apparent difficulty plus 10 or plus one percent and that will just continue to increase

Martin Holst Swende: is that reflected in the actual specification on there magicians or anywhere else

James Hancock: it's in

the pr i haven't i haven't i just need to read it's in the pr yes i need to write that it the pr has been updated on updated on these magicians this is also after talking with tj for a long time at eve denver who is one of the big critics of my approach

Martin Holst Swende: yeah as for my part i think yeah this is kind of a good trade-off between removing it entirely and having it in its current form which obviously isn't that great so i'm tentatively positive but i'd love

to hear other people's take on it

it

Hudson Jameson: might be a situation where people need a little more time to read it and if that's the case um i'd say it's a good idea james to just shop it around to the different teams in the uh awkward devs getter or just people you talk to individually and then once it's in draft stat if it's in draft status by next meeting that would be um good to um yeah um that'd be good to do

Tim Beiko: i have a question maybe this is a dumb question but um wouldn't like freezing the difficulty and then linearly

increasing it make it it kind of goes against the whole difficulty adjustment so i'm i'm not sure i haven't read the whole ep but maybe just trying to clarify how those two mechanisms would like interact so what's like the trade-off of of not having the difficulty adjustment um yeah and the security potential security implications

so after the so the

James Hancock: the difficulty adjustment would be removed after the point of act of block activation

Tim Beiko: yeah so that's what i mean but right so say you know this kind of a a toy scenario but say

you freeze the difficulty and then 2x the amount of miners start mining on ethereum um you know are we gonna have seven second blocks instead of 15 second blocks because our difficulty is kind of frozen and i understand over time it'll grow but if the amount of hash power kind of grows quicker than the rate at which the difficulty bomb slows the network um we have like a quicker network

so i and and i'm just not sure like no yeah yeah you're

James Hancock: you're totally right and and the so once it's frozen there is an incentive for miners to jump on assuming that that the main chain is the one we're talking about right now yeah for miners to jump

to jump on and increase the hash rate and because the difficulty is now adjusting up slowly that it would like block times would increase quite a bit for a short amount of time and it would they would accelerate their pace into the into the linear increase and the the risk there is that if block times are too fast the uncle rate could be high enough to result in sort of a fracturings of the network or but um uh or just block times becoming very very quickly for a short time until eventually there isn't enough miners

on the planet to yeah

Tim Beiko: i think the mining reward would also play into that right like how profitable is it for them and whatnot

but i think to me that's like one one thing where i'd like to see someone who understands it much better than me like the various incentives and and kind of talk through the possible cases like what happens if you know there's like 50 more miners there's like half the amount of miners you know um because we kind of lose this like dynamically adjusting parameter

and i wrote a little bit

James Hancock: i wrote a little bit about that on the on the in the eip as well

cool

James Hancock: is there any other thoughts on that before and we can just we can decide more on it next week

next two weeks

yes

Martin Holst Swende: i'm curious as to why freeze at all and not just the linear increase from a certain point in time

that is that is what it what i guess the

James Hancock: freeze to me is removing the difficulty adjustment piece and then it will just linearly increase and that's it right is that what you mean

Martin Holst Swende: no not quite i meant why not instead keep the difficulty keep the adjustment but also add not an exploding bomb but a linear increase bomb which has less chaotic kind of

effects so that we for example once once we hit this new soft bomb it starts to target 15 second block time and then 16 second block time and then 18 second time but doing so in not as yeah large

hops the

James Hancock: the reason and that i think that would have the same problem is not really being able to predict effectively when that first increase would happen because as long as the difficulty adjustment piece is in there and the increase is some static function that inc that can can

adapt to it then there is this requirement to guess or to predict what the difficulty of the network is in order to be able to predict the effect of the bomb

so

Martin Holst Swende: i think what i'm proposing would be to instead just change the desired block time remove the bomb and modify the desired block time

so there isn't

James Hancock: because of how the the the adjustment algorithm only adjusts up and down depending on if

it's between a 10 and 20 second block window so we we don't really have a capacity to target a block time as far as my understanding we have an equilibrium equilibrium that happens because of how the mechanism if it's below 10 seconds then it then it um increases the difficulty if it's above 20 seconds then it decreases the difficulty for every amount of 20 seconds it's above for every 10 seconds it's above that [Music]

so i don't know how we could we can move that window the the other concern i would have with that approach is the the people that are most affected by this going off or for us for it not going for it going off is the miners in there and that isn't that never was really the intention of the difficulty bomb was to make it so miners are are less able to pay for their electricity that month so as like while it is less impactful for us we are also not this really impacted by having block times increase in the same way as other stakeholders on the network and so making it so it is more

real to us what the consequences are as in visceral for us in in this room then we who are the ones who can address it will also be more likely to address it in a timely manner

Hudson Jameson: any other comments okay we can probably just go to the next one and just um shop it around some more i guess james

that sounds like a good idea to me

yep

James Hancock: i can do that if there's a way to target like that martin i would definitely be open to how to make the adjust the mechanism to be targeted around that i just wanted to figure out how that works how that would work

so

James Hancock: then the next eip is alex vlasov you're here correct

uh yeah yeah uh so just following the discussion which was on the last call people wanted to get uh someone outside of this like

call and implementation of the eip every time so i have invited few people zack and kobia here unfortunately joseph from eui couldn't join due to personal reasons i got an email from him an hour ago else unfortunately this week it wasn't the best one to also get more people because now it's standard blockchain conference and it's 6 a.m in here yep a little bit inconvenient uh but still i think people who were actually interested in getting something new in terms of uh elliptical cryptography and serum here so uh in principle if you want to ask them about the difficulty of the pre-compile or something else you can talk with them uh i also chatted uh

on telegram police uh people who implemented cryptography like shambo and definitely for example it's not a problem uh the difficulty of such pre-compile and its age cases documentation elsa didn't rise any questions for them um so and in general in total what was also like adjusted over the last two weeks between the calls a gas price is very calculated to increase the constant of gas per second now it's 30 even while it's way above what my laptop has for uh bn pre-compile i mean current implementation was being pre-compiled

oh oh josef sent his colleagues that's great um yeah um so uh lc gas formulas were adjusted a little but it's it's not a large difference otherwise all implementations are ready and what we do now is just sayed who is most likely listening to the skull but never joins uh another of going implementation he boards a gas metering routine to go which is the most real part of the of the quick compile so in principle all implementations are ready in rust c plus blossom so i think zach or kobe can say

something um yeah i'm happy to have a couple of thoughts um uh if now's a good time um so yeah i just i just kind of wanted to give like a bit of an external viewpoint on kind of um the value of this eip um so it's quite quite a few companies working in this space um like the current pre-compile situation uh means that it's difficult to deploy kind of um state of the art for cutting-edge cryptography to ethereum um especially given the amount like there's been a lot of new developments that have come out in the past year that we can't currently leverage because of the limited pre-compost support and i guess yeah this erp is kind of um i see it as a way of future proofing

ethereum so that it can become a test fed for a lot of the advanced cryptographic techniques and that in turn should provide a lot of value to the community to the to the wider ecosystem particularly in the form of roll-ups in the form of you know using starks and snarks for proof of data availability and for scaling um and um sorry hang on so just lost my place there a minute oh yes and basically um there's also been some research lately um spared by kirby actually which highlights the fact that um if you want 128 bits of security for snarks roll up scaling solutions that kind of thing um the bls 12 381 curve isn't really sufficient um

so whilst it would be it would be a big improvement for for ethereum to support to have the bls 12 pre-compiles the ability to use more secure curves um which eip cip supports would be extremely valuable um when it comes to implementation um i'm about to add a few thoughts uh otherwise i just echo alex says it is a complicated erp and there is there is a lot of um like a lot of potential attacks that need to be closed off uh but like fundamentally it's not new cryptography that's being deployed or new techniques um and also the teams that would be using these precompiles um as part of

the tech stack they all have quite significant ones that i know for quite significant in-house cryptographic expertise so they would also be you know providing auditing validating this code themselves they wouldn't be treating it like a black box yes so the we

James Hancock: i can see the value of it i think all of us here agree the value of it the concern is how do we do it in a way that is secure given previous experience with alt bien and other and others so um if your organizations or others could could um i mean not if not audit ends in the formal way but look at the implementation and look at the specification and just say yes both of these things are lining up as a

vote of confidence for those things that would be very helpful for us

yeah we'd be happy to do that

Martin Holst Swende: i would like to voice some opposition here i'm i've done it before i'm i'm opposed to this eep because it's so broad and so sorry that's maybe the wrong wording that is very huge and it's a generic pre-compile it's basically a virtual machine for a modern crypto which i don't think suitable for ethereum i think we should add pre-compiles for well-defined use cases

um and if we need some particular pre-compile for some well-defined use case such as c cache interoperability or ease 2.0 then we can add a precompiled with that but i think it's two largest step to take to add this big generic recompile and it's there there are several concerns one is the actual crypto correctness uh and there i can only you know trust that cryptographers know what they're doing the other large concern is that these are extremely large code bases so even if the crypto is right there may still be mistakes in the implementation and like i i briefly looked at the code

the goal line code base and solar that like 12 days ago there was a commit which fixed a simple mistake that set copied a value into the wrong destination in one edge case and it's like these things happen but if they slip into production there we have then we would have a consensus issue on our hands and when you have 10 20 000 lines of code there's quite a high chance that these kinds of bugs exist in the code

basis well i think i should hear a little bit

explain uh uh about why supreme compile is what like was made universal at the first place it was actually to eliminate ever a discussion about like how many people want this feature how many people want this curve and who is to decide uh like whether we will increase it or not seconds for code based size and similar things this is the reason why we run the classic testing to find such mistakes and if you look at the implementation of for example if you would ever want to add bl b ls 12 curve uh three 81 bits is the base field and if you ever

after this would want to add bls 12 curve 377 it's different one let's give you like huge other set of capabilities which people would potentially want they will have an intersection in the code base of around 90 percent just because the most of it will take failed arithmetics and current matrix which is the same on every curve same goes and in this pre-compile this common part between the curves which is much easier to solve and which actually has no zero edge cases uh actually is this well not eighty percent as in my previous example but most likely 75 um

so if i can a little bit explain how it works uh for go implementation we originally said that for now it's uh it's only for what they're 64-bit processors like performance one especially done uh by uh handcrafted assembly which was later cross-checked and i mean still independent orientation and it's not didn't hit the uh like we we didn't hit the inclusion we didn't hit the hardware so we can fix the mistakes that at least the gas price inform was very calculated on the lisa last week so this small correction is not a big deal uh i also included a set of like what can be called the downgrades or

like a white listing feature which people have discussed before unfortunately when i started to collect the list of the curves which are of the like kind of known of the good use in the mod for a lot of various applications uh by modern crypto and i mean for existing projects already when i got into the list of these curves i collected a quite huge one it's also listed in the uh document and my main readme uh file this insta repository uh it says so at the end this precompiled wants to eliminate any form of uh like centralized decision to like which curse goes in which curse that's

not going if you want to implement it in a set of specialized pre-compiles but this is the state of some modern uh cryptography and specifications that now so with recent discoveries there are more choices which give you a lot of different features another one talking about whether you use narcissistics it just kind of separates discussion uh so it's why it's universal is why you call it a virtual machine i call it a calculator which is actually much simpler if you ever implemented it at least once um so i'll go ahead yeah i want to sorry i just want to react on top of

this um you you see i mean understand the logic of implementing one and for all crypto and be done with it at the same time uh you can ignore that it's a attack vector and i'm just going to go back to one specific mistake that happened with windows we had a very thrilled crypto team uh that happened like a stream just one month ago so my concern at this point concerning cip is like having it's not encrypted itself because the crypto the math works and we can write we can verify the map it's it's okay the right is probably in the implementation level and what concerns me here is that we i mean i mean we don't have like i know

you told me that there is another team but they i haven't come up to to present i am and also we don't have like sort of um other known figure and copy or being one of them or it's like being one of them actually doing the implementation and saying that this current spec is enough for anyone to implement according to the spec how would you address this concern uh i mean we cannot ask someone uh like specifically if he doesn't want to implement or do the duplicate work because as far as they know zak usually writes in c plus plus and c plus plus implementation exists if he wants to find unit but change it a fork it

uh just for his own interest he's free to do this uh but if no one volunteers to make an alternative implementation according to suspect uh because a set of languages in which it's already implemented is kind of wide enough and what are most usable we cannot force anyone to do this according to the windows hack which you mentioned as far as they know the problem was not even the cryptography itself it was in parsing format and this is equivalent to the api part of this pre-compile which is likely much simpler than uh their encoding format in usual certificates uh but i mean attack surfaces chapter is also covered in the documentation so

there were only three main parts and i spent a few pages to explain by say are not like how they addressed and uh like why this way of addressing attack services is enough i mean uh recompile documentation and readme document was updated quite a lot over the past weeks and i mean i cannot force people to actually look at it and pay attention because it's quite a large document i mean for these questions there is a formula well no well um i think that's

Martin Holst Swende: a bit of a strong argument i mean i have read the attack service description uh i just don't agree with the conclusions there actually

uh yeah what can i say there's there's one little paragraph about it being consensus breaking where you somehow you say that it cannot be consensus breaking because of conventions um yeah i don't agree sorry

so

Felix Lange: um i would like to also expand on that so uh yeah i think with this eep uh our main concern is really that is is really like with the complexity of this of this particular precompile and um this definitely would definitely also be my concern um it is definitely possible to to

create a large programs which behave correctly uh and are in consensus across multiple implementations as the ethereum implementation shows but um especially with this pre-compile i think it it might be stretching the limit a little bit as to how big a precompile can be and i do understand that basically it is quite important for applications today to have access to uh these kinds of cryptographic features but i do disagree with the notion that um the process of adding pre-compiles is like too complicated right now to uh make that happen

so i think um as client implementers i don't think there's any problem with adding any particular pre-compile as long as it is reasonably simple and there is a use case for it and these things are like with this particular eip there is definitely use case for it but it is not simple and i think as such is it doesn't really meet the criteria for like um a good pre-compile

so

Hudson Jameson: i don't want to spend like too much time on this alex go ahead and

do a rebuttal and then i'll no no i i mean i wanted to answer these questions this kind of uh like a stock border like for

difficulty you may ask like there is a list of cures which would be potentially end of interest to use uh unfortunately this is quite large so it would at the end of the day will result in making uh let's say eight different uh heaps each of those will take something like three to six uh pre-compile addresses and i can easily and i mean i can definitely split this breaking pile by just doing calculations for uh some coded set of parameters and even by using the same code base as a reference to like say well let's include these eight curves but the problem and all of those curves

are usable and people want to use them for some or one or another particular application what would be the chance to actually get this included in a time frame of a few months and i mean it's eight pre-compiles with huge set of addresses but they all have this vanishing uh vanishingly smaller difficulty in this case i just want to uh i mean because this is what i wanted to avoid with this pre-compiler avoid this specific decision for every time what would be second three chances for this case is it okay if i give my view as well i know that you want to move on but yeah sure thing yeah yeah right

um i just want to comment on some things that happened so i won't go again into saying the value of the of the i think we all understand it's valuable and we have a bunch of use cases that we want to use it for so i won't go into that um i will say to the to alex's credit or like to metrolabs credit this is has explicit explicit formulas how to implement the specific crypto features that are needed which is quite unusual usually people implement from papers and the papers are scattered and all around and people

go to different websites and implement different ways to add or multiply points so having these explicit formulas is super helpful to make independent implementation so this is a very good positive point about the cip um one thing that for example i don't completely understand yet or i i can't internalize yet is the guys schedule calculations which kind of like i understand the ideas but it's hard for me to internalize it and i think this is somewhat related to

[Music] how people can perceive the complexity of this ap because it feels like it's a big very big unit that you must take as a whole all over nothing and that is kind of scary and that is kind of um problematic like like or not maybe not problematic but this makes you look at this 20 000 or whatever lines code base and say this is very big and i can say i disagree with it and it's it's

i think it might come down and maybe we could discuss that at some point um of how to [Music] to make this at least lighter so like alex mentioned yeah you could divide this so you won't have like five compiles you would have 60 recompiled for all the different curves that we want and maybe even eap eap1962 would be the underlying implementation and then you could have specific gas formulas for each curve and so on but that would also mean that you would require a hard fork every time you want

to care which to be honest i'm not totally aggressed dude you would

Felix Lange: still need a hot fork every time you add a curve even with this particular

erp it's not an opening i mean not with this one no not yeah that's kind of like saying oh it's such a pain to push to push a new eep through the process so we'll kind of clump this all together and so actually one actually i was building up to a point so maybe i'll finish that um so yeah so you could divide this into

60 ap 60 compiles and do that but then it would require a hard fork every time which is maybe fine um and i think something that we could discuss um is to if for example we do go through the process of adding for example six eight pre-compiles per curve and even if the underlying implementation is 1962 does this improve the complexity worries or for example even including one curve is already scary and even that should be really evaluated

further and these are things we could discuss as to how we can actually move something like this forward because i totally understand the worries and the complexity of what it introduces um and i think it's mostly about the discussion of how can we modularize it so it is not received as complex

Péter Szilágyi: so just uh to [Music] add something to it so our biggest concern with the code with regard to complexity is that uh i'm almost certain that there are bugs in it

because i don't believe that three times 20 000 lines of code is bugless so from my perspective there will be a consensus issue that's for sure and the question is that uh parity is currently maintained by i don't know two people and in the progress of being switched over to open ethereum with uh god knows what governance model and who will be actually maintaining it uh geth is again maintained by a handful of people and if hits the fan who is going to fix it

Hudson Jameson: that's what i'm saying actually so just real quick peter i was wanting to get like buy-in from some of the cryptographers in the community including people on this call who either

built or support this eip to be in a getter or telegram or you know something bridge channel so that if hits the fan we can call on you all to jump in and within a very reasonable amount of time fix things uh and when i say fix things more identify the problem that kind of thing so so peter what about that idea

Péter Szilágyi: to jump in with a reasonable amount of time i would like to mention the time when doing the shanghai attack you called me at 4 am in the morning to get up and solve some issues so is anybody is a group of cryptographers willing to be able to be called at 4am in the morning and fix it at 4am because if not then that's a huge

problem because we cannot fix it

Hudson Jameson: i think the time zones probably is what i'd be guessing but i want to hear from them what do you think alex

kobe uh et cetera yeah i mean yeah zac i mean this the cip if it went through i mean aztec would definitely use it and we would be great and we'd be very happy to fix it if circle hits the fan 100 so we if we can collect who those people are willing to be i mean uh i saw this as a world responsibility i would i mean i didn't know that it existed but i thought it's by default so i can count it as yes from my side

um i cannot answer for saeed who is an astro go implementation but he's must i can i will ask him to write on the guitar for this he usually listens to the quote but never joins and i'd

Hudson Jameson: take responsibility for keeping this channel up to date as far as people on it and then alex if you continue to run this type of fuzz testing or someone runs this fuzz testing i think that'll also be something that'll help regardless of i mean it's not going to fix the concerns that the guth team has for sure but anything if this goes through anything that we can have in addition to just putting it in and everybody leaving like having this supported until well after each two

becomes a thing i i think is going to help um like some concerns not all concerns uh peter you can continue because i interrupted you earlier

so

Péter Szilágyi: i'm not sure where i want to get at but uh where now i want to something make something particularly clear is that in if this eip goes in the gas team will take absolutely zero responsibility for it i mean we don't have the knowledge to do this

and

Hudson Jameson: what you're saying is when you say not taking responsibility that's not by choice as much as you don't have the knowledge right

Péter Szilágyi: yeah yeah so i mean i would gladly fix something and obviously if hits the fan i would be super pissed and i would i would be staying there but um but if it's something that i cannot that i don't understand then so i think it's it's also really important to see to consider what are the consequences on on the network of the whole thing so yes everybody everyone wants everything to go really smoothly and uh yeah of course but what happens if um let's suppose the implantation is huge so you can have two two types of issues one of them is you can have a consensus issue um which for example currently if there's a bug in let's suppose in the go

implantation and eighty percent of the network goes off in a different direction and let's suppose or whatever let's suppose 80 of the miners go in in the direction which has the bug then the only way to solve it is to roll back the chain which is like this horrible situation or pause the chain like iota style so do are we willing to do that probably not then if um even if the whole implantation is implantations are in consensus and there is a bug in the cryptography itself i cannot verify it i can say that the five

of the different implantations do the same thing but whether that makes sense or not is beyond me but if something like that happens then great game it's a catastrophic failure for ethereum and these are the risks that we are talking about and the reason why martin is kind of against this and was suggesting that the individual eips that introduce curves one by one can help is because it's much easier to to say that yes bn256 or whatever is bls signatures is uh even adding that one curve can be really dangerous but i mean it's a tiny surface compared to enabling a touring complete cryptography machine

uh well it kind of gets us back to the

ideas that for like we can roll it out gradually but not by making individual curves as individual pre-compiles and addresses and all other things so people don't really know what's under the hood we can just white list the curves by still i mean as copy mentioned well even we set it as a set of independent pre-compiles for different cures and still use the same machinery underneath uh then it's not that different from just making a white list which is in this case it's just a prefix uh matching for whatever user wants to call to speak compilers can their proposal for this could we imagine providing the cip has

um sort of a bitter testing like that testing mode like where we offer a bounty for like no one can use it except to to to to sure to display an attack on this vip like things

Felix Lange: because then they would wait for uh for it to go

a minute no no like it's true but like at least research like people from universities who find fun like hacking and breaking you know cryptography which can you know could try to break something that will have money on it later on yeah so crowdsource audits which is nice yeah because as as martin said like there is

100 percent like 99 standards there is probably a bug there and if someone that is individual implementation we would have a consensus issue and at least having a hash like challenge for this cryptography library probably could help uh sort of uh limit a limited the sort of attack vector in the first in the first first phase and maybe like letting it run for like six months or whatever until until it gets uh it gets like sort of a bit trusty enough so

Tim Beiko: maybe this is like a separate conversation um but i feel like with this eip and what you're mentioning lewis uh and and just like having this longer testing it kind of reminds me of what we were talking about with eip 1559

on a previous call where it's like we we maybe want something more than you know activate it on a test net for six weeks and then fork the main net um i'm not sure how we do this i don't think the 17 minutes we have left is enough to discuss like a a proper plan to it but maybe it's worth thinking about like what's a what's a better way to test these like complex eeps because there's more coming down the pipeline um so that we're we're kind of you know confident with them and i know we wanted to talk about progpal today as well that's another one of those i feel the unjustine will have the same exact conversation uh so what's like the how do we test hard that's a good question and i just need

to oh i

James Hancock: i want to kind of time box this a little bit

because we have we don't have much time to do the rest of it can i bring just one more element you can just bring one in i want just to ask who among the cryptographer of the community will be in eve paris because i think an in-phase discussion will probably help a lot in in solving sort of a of the core concern here uh i'll be there or i don't know could you just name it because i'm on the phone right now zach i'll be there too uh i'd like to be there great so let's maybe coordinate something in if paris on the killer and and get you know

start discussing there

Hudson Jameson: yeah i think that's a great idea also uh just before we end this just uh just a like as quick as you can dano and way and um we we know geth's position but i haven't heard from bae su or from parity um and there's particular concern over parody not being kept up with so i just want y'all's perspectives we can go

dano first i'm in a car dropped off my kid so i'm not in a good position to discuss it say that one more time i'm driving my kid to school i'm

Danno Ferrin: in a bad position to discuss it

oh no problem we'll do we'll save that for next time uh way i believe this is 1962 so uh i mean it's uh the the there's an implementation in us so that's good for us but we also think uh the the this pre-compile is uh is quite complicated and uh uh yeah so that means we are slightly against it for implementing okay

Hudson Jameson: this is something that is why we have this type of governance system and i think having in-person meetings at ecc where it could be longer form discussion and

individual discussion uh is going to help clear some things up but in no way can we confirm this eip is going in because at this point there are clients who would not want to implement it right now or what i should say have serious concerns implementing it so as unfortunate as that is for people who are wanting to use these curves this is just how the process goes but i do thank everybody for coming uh here to discuss this especially the people who took their time on the west coast during stanford blockchain week to discuss this particular eip um and the cryptographers who were

offering to um lend support uh given if this goes in uh peter do you have one last thing

i saw you pop up yes so just um you mentioned that so i don't think that

Péter Szilágyi: so i don't want to say that the guest theme opposes uh the features itself so i we have absolutely nothing against adding whatever cryptography is deemed useful and necessary we just want to make sure that it's added in a way where you can more or less guarantee that things don't go horribly wrong

Hudson Jameson: is that something you can guarantee with anything though i guess you're saying minimize it

right

yeah yeah minimizes i think what he was going for it's like kind of like ethereum it as it said you know ethereum has a

Felix Lange: large amount of complexity already and uh we have been pretty good at slowly um expanding the complexity and not adding like a whole bunch of complexity all at once and i think this is something that you know over time as ethereum 1 evolves there will be more and more and more and more complexity in the execution because this is where all of the interesting features are and there are many many things that could be done to improve what you can do in a smart contract but this also kind of

i think there are certain things where like we really have to like slow down and then really check okay so like what is the thing we really need right now that will like add the most value and then maybe we go for the next thing and then for the next thing and i think doing it this way will it basically allow us to vet each feature more or less completely like i mean the last few times we added cryptographic pre-compiles there was a lot of exhaustive testing done and i see there has been a lot of exhaustive testing on this particular eip with all the fuzzing that's been going on on this you know like 32 core server that is mentioned in the rig me i'm i believe 100 that you know like everything that could be done has been

done to verify that you know the implementation is secure and everything and you know it's will will behave under consensus however you know just adding this large chunk of complexity all at once is just a really scary thing and uh maybe we're all going to be able to absorb that scare and you know know like in a couple weeks or whatever we're all going to say you know why did it what what were we even thinking about this is the best idea ever but i think at this time it just feels like this is too much all at once

yeah okay and let's move on yeah let's move on yeah uh if if i may have like a 10 second closing word first of all 20 lines the 20k

lines of code isn't most likely not the right estimate because more than half of this are testing uh second one if j if martin has a a counter example for why there will be no consensus breaking uh if implementation is done correctly i would see this contract i would like to see this counter example uh because otherwise i believe it's my kind of semi-formal analysis it was correct okay but it's all that's all from my side um so going there there is a pre-compile that we want to look into individually to getting in and i and i can see that this is something that will take longer a longer amount of time for everyone to be comfortable with and i don't want to continue the conversation on that

i think also we don't have two people here today that i can see so that's why i've been i've been talking with with them and i've been meeting with him so i'm representing them okay i think alex who was one doing his pls felt like proposal he's also here in stanford most likely it's just purely before stanford and and i talk i'm i'm here at stanford as well i'm just i'm representing them at this moment because it's very early for them but alex has an eip written i put it in the chat for the bls signature and then having a target for june so that it can be used in the eth2 deposit contract as far as hard fork

scheduling that i think is important to target okay um so yeah i agree that we need to figure that out would there be an appetite for meeting in one week and fleshing out specifically this eip after discussion on getter and magicians um who would be able to come to that yeah i actually have a conflict too this might have to wait for two weeks and given the text stuff and that's unfortunate because of the timing of um

you know that that might put off some of the other discussions but i guess this is the process now if it doesn't get in at berlin it doesn't get in at berlin we can only do so much with the time we have um james if it's okay with you i was wanting to get the open rpc discussion going if that person is still here because we promised last time that they'd be able to have a little bit of time and we're at the end of the meeting again with like eight minutes left so i think that's exactly is that okay with you james uh yeah i think we should do that and then we should also discuss proc pal i know things might go over but i think it's important to talk about as far as in in conjunction with berlin going in for

each e for eth2 stuff anyway continues we'll do light discussion on progpal that won't be anything binding if people have to leave so uh yeah let's start with uh zach though go right ahead cool yeah thanks for having me uh yeah sorry i turned up a little bit late today uh but yeah glad to be here um so i just wanted to quickly maybe start by saying a little bit about what openrpc is so um yeah openrpc is what is called a service description uh specification so a way of describing a service uh there's other ones that exist open api is probably the most well definitely the

most popular one and that's the one that i've used a lot in the past and i found that there was some particular challenges when using open api with json or pc services because open api is you know structured as this individual route it's based on http um it also has a lot of features that are specific to rest based apis um and so that's why we made open our pc which we started out as a fork of open api and worked with the guys that maintained that to figure out basically how to set this

thing up and so yeah like started out by deleting all the stuff that only pertained to rest and the beauty of json rpc is really its simplicity um and you can really tell that by like how much stuff we are able to we are able to remove from open api and we also worked a lot on tooling around it as well so the motivation behind all this is really we wanted the same sort of tooling that you get from open api um but specific to json or pc um and because and there's a couple other things that we

added in there as well like uh the the concept of uh service discovery maps really well on to json or pc whereas for the open api stuff they have they have ways of doing it um but it's a little bit different and it's uh so like for example we have a rpc.discover which is a method that you can add to your jsonrpc service rpc dot being a reserved prefix for json rpc and the idea there is that that method would return the service description for itself um and so you can sort of ask a service hey what

what methods do you have you know what parameters they take what do they return so you know fundamentally we built this stuff for json rpc not for any particular one technology just json rpc in general um then um you know of course it has specific applications within blockchain because most crypto you know most blockchain clients use json or pc um but also there's a lot of say like within ethereum ethereum classic whichever there's multiple client implementations all trying to uh you know hopefully adhere to some common base set of methods uh and

interface right and maybe some clients add certain functionality and whatnot um but moreover having a way to communicate these differences is really important um and so yeah that's pretty much the gist um we've put together one like a specification for ethereum as like like the base level set of methods for ethereum um haven't had too many eyes on it really but uh we're we're using it uh inside of multi-guest so like multi-gath is supporting those methods and it's return and it's implementing the service discovery as well um but yeah there's there's also like a lot of interest outside of blockchain as

well so yeah happy to answer any questions that you have and also we're really happy to help out um you know hopefully make this tooling stuff work for you guys or yeah talk about it and just to make sure i understand is the ask to implement this at the client level and um for those who might not be familiar this is not a consensus breaking change right this is just like something at the like client level yeah totally yeah it's yeah definitely it's at the client level um it also like uh i guess the there's

i have a couple examples i don't have the links handy right now but um one example of a way that it could be used is when proposing an ec or an eip uh if if the eip includes a new json rpc method or a change to the existing json rpc method or something like that uh it can be you know specified as a in like a structured format that's you know like you can just include the open rpc definition of the method right um so that's quite nice but um aside from that like yeah each client it's on it's up to them to implement this stuff or not

like you said it's not consensus breaking or anything like that it's just something that uh for example with uh multi-geth whenever whenever the you know specification changes we just rerun the generator and we get new clients for javascript and rust right now working towards go and python and the near future but like these are generic right so like of course you can generate clients for any json rpc api uh same with uh documentation so yeah the idea is to just save time and not really um like force it on to anyone i guess is

a good way to put it uh so like there's no need for anyone to implement anything if you don't want to it's just a tool cool uh anyone have questions or peter i have a small reaction so generally the problem with these generated apis is so before ethereum i i used quite a lot and hacked quite a lot on the on google apis and google is famous for they have these api descriptors they are super complex and you have api generators for pretty much everything and uh essentially i was using the go apis and the problem is that yes you do get these apis generated

but they are more or less useless on themselves because uh after the api reaches certain complexity the generated code is just you just essentially map function calls to or api calls to you just translate them to your language but most often the user doesn't really want to call do the low level calls individually and assemble and pass in all the configurations so at the end at the end of the day you will need to write a proper client and that that was my experience i mean uh agreed there are some cases where um the complexity is too great for for a generated client to really fit the bill

but um like uh similar to in open api world um there's many rest sort of pattern or there's many patterns that people use that don't necessarily fit rest or open api and in that case uh you either accommodate with by adding like plug-in interfaces to the generators or like you like as you said you just you're stuck with having to write your own um and if that is the case that is the case right so um but certainly there's a lot of cases where you know what you want is just a very light wrapped uh interface to your methods

that includes uh static uh typing and uh and and like um like uh say like if it's the j if it's a js or javascript generated client then you want like js doc annotated functions uh so that you know in your editor when you're calling like if.call or whatever you you don't have to go look up the docs for how to use it right it's just your editor will tell you how to use it so if this is already in multi-geth would that mean it works for geth already uh yeah certainly so it should be the base level set of methods there so the thing is i think we are happy to add uh the server side for this uh i doubt

that we will change in in mainline guest uh we won't necessarily change the client uh based on this because i think we are still uh on that part that basically like we do have a handwritten client which i think is basically includes the functionality that you would need to interact with the chain and it's kind of we do add to it from time to time but it's not uh in general we're more trying to provide a stable sort of go api instead of providing uh like even if the if the underlying mechanism changes that is used by this particular go api and we do strive for the stable api on the client side also and so i i don't we'll be using the

generator but we're super happy to just add the like rpc.discover endpoint and return whatever stuff needs to be returned there like that's not that big of a deal yeah cool i mean uh the the intent is for you know this stuff i guess to highlight differences between clients really so you know if you're ah so it would kind of mean though that we basically have to because since since the the server that we use i actually don't know if multicat uses a different rpc server i think would be kind of silly but usually yeah so what do you mean the gold one like the just the one that everyone uses

like the you know put up same one as gaff anyway oh yeah okay so uh the thing is that uh in within that server implementation uh it's kind of like we basically need to have a way to like auto generate this like schema from the provided methods and that's not something we are not doing right now right so um it's a very good point that you brought up uh so i'll first start by saying that we have uh a fella on our team named isaac who is working on this stuff exactly um and what he's trying to do is uh yeah like infer from the code what the

what the scheme like what the document like the service description document ought to look like um and so that's uh like sort of in the realm of like document introspection uh which is definitely one avenue uh another one being like starting from the document and then updating the the typed interfaces in your code which you know breaks compilation you go and fix it and now everything's happy okay you've implemented the change to the interface right um so they're sort of two different schools of thought i suppose uh i so there's a big benefit to this so

the big benefit if we'd go down the path where basically we would define the official sort of like ethereum rpc interface as you have done as a schema like that then loading it into the server we'd also be able to provide canonical parameter names which is something that we cannot do right now so at this time all of the methods are you know by position and that can actually be a bit of a hurdle because you actually have to remember which thing goes into which place and some of the methods work around it by just taking an object as a parameter but that's kind of a hack so i do feel that like this is something that could provide like a big benefit to you know users of the rpc interface because they'd be able

to use name parameters finally people have been requesting that feature for a long time yep yeah definitely yeah you you nailed it there um i want to time box this a bit absolutely but uh zach if you could just tell us how to get in touch with you or are you on the all core devs getter um just basically how to get in touch with you or your team if people are interested in this uh that is a good question uh github is definitely the best place to chat about this stuff um if it's a related to the specification uh there's the spec there's the open rpc slash spec repo happy to chat there entertain any questions

um otherwise uh i'm on you know telegram discord twitter all that stuff uh getters mostly used for these type of things are you on there yeah yeah so actually we've been talking about this uh sort of having the need to maybe start a getter for these exact reasons so uh maybe i'll get to that uh this week or today and get back to you perhaps yeah feel free to come back and give any announcements of better communication methods um if you'd like even if it's not talking about the whole thing y'all are always welcome here oh well well thank you very much for your time and uh it was nice to meet some of you in east denver last weekend oh yeah

thanks again all right thanks zach all right uh on to praguepow

Hudson Jameson: uh thanks for staying over everybody um james did you ha or actually i should put it this way we could have james go ahead with it or martin you put it on the agenda so maybe it's better to hear what you wanted to do with it today and then go to james

uh yes sorry um so

Martin Holst Swende: my idea was basically i think we should have another discussion of this proposal and see what the next step is i would for example propose that we launch a new testnet with the updated 093 implementation and

uh yeah i don't i don't really know where we're at in the discussion uh or in the decision-making process i seem to recall we have decided it for implementation

but i don't know so andrea um or

Hudson Jameson: andrea i'm really sorry if i'm not pronouncing your name correctly where do you see uh where we are in the process if you have an opinion at all i'll just kind of put you on the spot there we can't hear you if you're talking you might be muted on your end no we can't hear you

oh okay while you fix your mic i think james had something to say

yeah so they have a

James Hancock: they have an 093 test net or there are there's a mining oh i think i can hear you know you're better now you're just very quiet yeah if you can up your mic volume yeah we still get here just go ahead james yeah so they're the readiness of their like they have some testing of some test nets or they're they're

mining on the 093 spec and it's in my opinion the closest eip to being ready to launch so as far as status of implementation they're very they're pretty much ready to go if um unless andrea has an opposing opinion to that my i do have a proposal for a a hard fork scheduling proposal for this which is the bls pre-compile getting in sometime for june having a fork scheduled for that as the as the whether it's with the 18 um one white listed or if it's in the

specific as if it's a specific pre-compiled there the eth2 team is working on that right now and and it's important that we get that done before the deposit contract so things can be validated on chain then for progpal and its inclusion i would suggest that it is a contentious upgrade but i've as i have done research and around that there isn't uh the likelihood of a network split is very very low because i haven't actually seen someone willing to be on the other side of that but i do agree that it is a contentious upgrade so my proposal is that we have a fork for the bls precompile and then three

the next third wednesday after that we have a fork that includes only proctol and and that's the the suggestion and there are there's a lot to go in on why i don't think we have a lot of um any more time to really go over that

Hudson Jameson: my main question is uh when you say three weeks is that we're testing them at the same time but we're just including them in forks at different times in order to make sure people have the opportunity to fork off if they want to

is that correct okay

James Hancock: yes so berlin would happen in when the bls precompile is ready and

then a prague pal would happen the next third wednesday after that

Hudson Jameson: any other anybody have comments concerns etc

i'm

Tim Beiko: concerned it's not much too close i think from a community perspective uh and enough people opposing prog pal i i feel like putting e2 and e2 like pre-compiles at brockpow a month apart is kind of conceptually weird for some reason um i you know if you told me like three months or two months between the

two sure i'm also unsure if like i know we've had a lot of discussions around like if people want frog pow and and or not and what um and given how contentious it is i'm personally a bit uneasy about about including it i think kind of deciding through a network split is is far from ideal um so yeah i i yeah i'm i'm a bit uh i'm a bit uneasy about program general but i'm especially uneasy about having it very close to uh an e2 related upgrade just because of the the potential confusion

that's so the both the

James Hancock: as far as the releases go we could have the release for berlin as soon as that's ready and we could release the progpal one shortly afterwards and um it's more of giving if we wait another three months then progpal eats up six months of our development cycle where really proctol is actually the most ready to go out of any pay right now but the reason we aren't scheduling it is because of the we don't want to just do the only proc pal one first so how and as far as timing goes getting the the bls uh signature the precompile in is is more important than having proctol come in first

and the so having multiple releases before and then having people to like upgrade to the one that they want um and them is i like that that has already worked and so it isn't like a okay once berlin is done then we'll release the version for frogpal it's more of we'll release everything for berlin as soon as it's ready and then we can release a procter one shortly after and have people also upgrade that as that's the next one but as far as act fork activation happens it would happen at that amount of time

yeah and i mean three

Martin Holst Swende: weeks it's not like we're just

trying to slip in prog pile the day after nope nobody noticed i mean i don't really think

uh i think three weeks is sensible

Hudson Jameson: what about giving exchanges and other network service providers time to upgrade their clients twice it's three weeks enough

well i mean we could

Martin Holst Swende: we they don't actually have to do that we could bundle code wise it could all be implemented and activatable or deactivatable via switches so if we just code it right you don't actually wouldn't actually have to update the software twice

Hudson Jameson: so what i remember from the dow is that there was a lot of um pushback on a switch because that that

implies a default to the switch uh whereas running an entire client where the default is one or the other is a much more explicit switch than having a software enabled switch that you have to like manually go in and do

Martin Holst Swende: i mean yeah so so the default obviously would be pro prog power because that's what we kind of decided right

Hudson Jameson: yeah

yeah and but then yeah

James Hancock: if the exchanges and things seem they have they like to upgrade the moment before and there already have been shown to be

capable with that in a much shorter and crazier timeline which was mere glacier um and if we did a release of berlin and then a release of broad pal then that is people could just go to the release that they they choose and we would be supporting going to the proc power release

Tim Beiko: i think one thing that's also worth considering is the exchange have the biggest incentive to support two coins right like if ethereum splits the best you know it's bad for everybody except exchange fees um and it's worth being mindful this is basically how etc came into exit existence um so this is just you know i can i can absolutely see the first

exchange the once the first exchange is like we'll let users decide we'll run both etc or sorry ethrogpow and eta etch then it's almost like a you know every other exchange has to do it because they end up competing for the fees and we've kind of split the network um so again this is kind of why

i'm personally uneasy on this yeah yeah and i and i i understand that and as as i've read

James Hancock: from the community there are people who are who oppose praguepow but their stance is that we would all go to the prague pal state we would all go to the non-prog pouching and if that is actually the case then there is no network split they're just we go on with the one without product

power or we go on the one without and i have not seen any evidence that there is there is an ideological or people willing to step up to actually have a network split and if if i'm wrong about that i'll resign as hardcore coordinator

Hudson Jameson: yeah that probably wouldn't be necessary but what i'd say is i've seen very little the only person i can just call it out i'll just say amin's the only one who said they'd step up and i'm not sure if they still have that position today and even if they did uh just kind of seem like i i don't know i'm i'm skeptical of that happening but again i don't want to like i don't want to be proven wrong but if i am then that's just how things go

so i think

yeah and i mean

James Hancock: i am serious that if i'm wrong about this i would i would quit my job

Hudson Jameson: please don't please i would really like you to stay

out okay go ahead tim what are you saying yeah i was gonna say another another uh sort of broadcast critic i found is like

Tim Beiko: the gnosis team um and martin specifically and and you know i think it might be worth uh getting their thoughts on it on a cordes call especially because they're gonna be maintainers of open ethereum um i personally would feel much more comfortable with this plan if you know gnosis as maintainers of parity ethereum or open ethereum um say they're kind of okay with this you know like i i know for a fact they

don't actually martin is not gnosis

no no he is

James Hancock: he's talking about the right one and and all right so i have i have gone back and forth with him a lot on this yeah and his views that prague would collapse would would be nothing and we'd all be on the other side so so those are those are the two big objectives and neither of them are saying yes i will i will move forward with a network split

yeah so i think yeah again i would

Tim Beiko: be much more comfortable if gnosis uh martin k from gracis you know agrees that like open ethereum will implement that and kind of be okay with it even though say you know he's personally somewhat opposed to it um because i think that's the other kind of credible

like the two people yeah

Martin Holst Swende: i don't know i mean we've had discussions back from everything that's going to be said that has already been said uh i think we kind of just need to go forward uh that's my view

yeah and i think

Hudson Jameson: i agree with that view however tim if you want to ask them uh and make sure they're aware of it uh or at least stefan um uh from gnosis um uh yeah yeah just feel free to ping them and like let make sure that they know this is happening because the last thing the the the thing that got me last time was people saying this is being snuck in so i'm gonna make a effort to make sure

that's not the case this time um as i'm sure james and others will do as well and there'll be plenty of time for open descent that won't really change the decision necessarily because we've already gone back and forth and approved it twice but at least they'll be aware so if people want to do that they can it's that's what that's why um forking off is the ultimate consensus mechanism

yeah just a quick question is there a better way to advertise this than through your twitter account like a more official venue

Hudson Jameson: good call um i'd say i can't think of one what about you

uh the ethereum blog i mean if you were

really serious about this hmm there's a

Hudson Jameson: there are trade-offs to doing that and when i say that what i mean is it looks like it's an endorsement by the ef which it really isn't because geth acts autonomously from the ef although it is funded by the ef um with as far as their decisions as in no one outside the geth team influences any or has ever influenced any decision for what goes into a network upgrade um within the ef so like aya or any of that stuff don't just they don't go in and be like you have to put this in and so that would be one misconception the other one would be

giving it more it would be kind of fanning the flames of something that like is not really needed to be fanned but i'm open to other suggestions if enough people want that to happen i'm perfectly comfortable bringing that up to the other blog editors

no that's that's true good perspective

James Hancock: um mine would be if you have grievances come to me i am taking responsibility for this uh um to an extent yeah yeah as much as i as i can in my role and i'm i am i i do listen and i have had many of these conversations and i look forward to having more of them and i am sure essentially putting my reputation on the line for

this decision

announcement of like the decision uh the like you know this would this basically you know awkward is deciding that like

Felix Lange: the way forward is to include profile is kind of something that i feel like is newsworthy and it's definitely something that can be announced on the ethereum block even without seeing it as an endorsement because it's basically just documenting the fact that um yeah all quartus has you know collectively decided that you know pro crowd is the way to go and if the community doesn't accept power and we turn we all turn around and we're like okay um you know maybe it wasn't such a good

idea and then we just go with the other chain that's fine as well but at least having like an explanatory write-up that on the blog that actually explains why proper was adopted and you know like that it is being adopted because of the decision in all cortex i think these things can just be included in the block and it's not an endorsement

yeah

Hudson Jameson: there's a happy medium we can definitely approach once things get closer um especially if we very early um if we very early put a blog out there rather than like two weeks before like i've been prone to doing

Tim Beiko: uh i think we should probably do it now i don't know if now is the right time or like after the next

cordev's call but that seems like yeah

we should have it we should have the uh yeah next next shortcut

Hudson Jameson: i think we should do it after whatever bls eip is going in has decided so we can make both announcements so i'm not doing it eip by eip

yeah

Felix Lange: it's not that it's not about the heart frognance it's more about it's more about the like you know the decision that you know the official decision is now will happen and that doesn't really mean that's not a heartfelt announcement that's just informational post

yeah and

James Hancock: and when it will happen will be after this the third i like we can if we don't say when it happens i don't think it will happen so having it be the third wednesday after the bls pre-compile

is a way of saying this is it it is happening when it will happen

Hudson Jameson: okay we'll discuss this more next meeting because it's not going to happen before next meeting and i can definitely draft something up just so that we don't keep everyone here all day

uh and

Hudson Jameson: artem makes a good point um that we should definitely invite stefan and amin if they want to come on and give their perspective of like why they would like that they're splitting just so people are aware but i'm going to talk to amin and just see if what his position is now uh he knows i think he knows any way that he can just come on and say that if he wants to but that's kind of i don't want to create drama for the sake of drama so i'm avoiding that as much as possible

while still giving people while still making sure people are aware of what's going on and giving them voice so that's a hard thing to balance and i think james is doing a good job of that and i'm going to try to also do a good job

of that

Hudson Jameson: any other final comments before we close out the meeting and what we'll do is for the next meeting let's look at what we missed this meeting and try to prioritize that um along with the bls curve stuff obviously but it sounds like eth paris is going to be a big place where that's discussed but if we can have an eth2 person on next time james i know you were representing them so actually that might be sufficient

but um yeah next time we'll we'll have someone and the actual eap will be written and

finished oh great okay

Hudson Jameson: that'll help a lot so yeah let's re-prioritize the ips next time so we're not leaving stuff out and other than that any other final comments

Felix Lange: i have a quick request yeah so um i know that you know so it's been quite a while since we've had the uh eep 778 and 868 merged so uh this is something that uh to refresh you guys this is ethereum node records and the node discovery v4 enr extension um these things have been live for quite a long time and there is implementation in trinity geth and um and an alif but we are not really seeing many other

implementations on that so it would be very useful to have these things because we we have just rolled out another critical piece of infrastructure that will deprecate the bootstrap nodes in the long term and that is the dns based discovery and i would really watch for people especially like client implementers to go ahead and just um add these features to the discovery implementations they do not take a lot of time but it would be very helpful for the network

um okay okay

Artem Vorotnikov: uh if i may i have just finished working on it 64 implementation for open ethereum so it's just hit the master and and now uh

i will also be working on ethereum node records and integrating it into the

uh open ethereum's networks text oh that's very nice

Felix Lange: that is very very nice so uh do note that basically the um just contact me if you have any questions um regarding that and i'm very happy that this is finally happening and i can really recommend that you look into the uh rustly p2p ripple because they have already implemented all that stuff as part of the discovery version five uh draft work so you can just use the implementation from there you don't have to implement in or again

Artem Vorotnikov: uh in fact i have been in contact with sigma prime and they have yes and they have split their uh implementation of enr into a separate

crate so will reuse it and uh yeah very very helpful okay yeah so

Hudson Jameson: felix if you could get on the all core devs getter uh put your specification and ways to contact you and then tag nethermind and baysu that sounds like those are the ones that uh we are not accounted for for if they've implemented this or not uh just if you could do that today or monday maybe monday might be better so people are like not ending their day um that

that would be helpful

so with these heaps is basically the

Felix Lange: the situation is a bit unclear anyway because uh we have approved them on all quarters a long time ago but that but the status in the eep was never updated so they're all still in draft but actually you know like we have discussed these two or three times on all quarters even more than a year ago and by now because uh the enr was it was proposed in november 2017 right so that is like more than two years ago yeah and i think it's kind of like it's been it's been around all this time and i kind of feel like moving these things to final would be great but also i don't really know like we still don't know what the process is for for those networking things

because it's kind of like you know

is it move to final when everyone has it or is it move to final when we've discussed it enough or like yeah there's a there's

Hudson Jameson: a process being changed in the eips right now to make that more clear there's eipip meetings which are eip improvement process meetings so um yeah and you're welcome to come to those there every other wednesday but basically uh right now the next step as the current system stands would be to put it in final call or last call

which is a pr to do that yeah yeah i made a pr for that already james already yeah yeah so

Felix Lange: we're currently in the waiting for merge

state oh perfect okay yeah

Hudson Jameson: just uh ping me i can merge it okay thanks all all right any other final stuff

all right we went over exactly half an hour not bad all right thanks everybody uh thank you artem for your update artem just for the record you're on you're on open ethereum are you with i just totally forgot are you with uh uh parity technologies

or are you with uh different i'm from gnosis actually so i am employee i'm i'm employing diagnosis

Artem Vorotnikov: to work on open ethereum so i'm the first of the hires and we are currently expanding so yeah we're looking for more people welcome work on this

yeah welcome to the calls um i think you've been on before a little bit maybe but um yeah yeah i was just a mute so okay cool all right see y'all in two weeks bye everybody

thank you so much thanks bye [Music] bye [Music] [Music]

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

[Music] so

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

[Music] [Music] [Music] you

Speaker names adapted from ethereum/pm, CC BY-SA 3.0.