All Core Devs - Execution #91

Transcript

[Music] [Music] [Music]

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

[Music] [Music]

[Music] [Music] [Music]

[Music]

Hudson Jameson: hello everyone and welcome to meeting number 91 of the etherium core devs call today we're gonna have James Hancock running the meeting so he'll be the host so I'm gonna just be recording today and I with that I will pass it over to James

James Hancock: Thank You Hudson welcome everybody we have a few little bit of VIP discussions that we're going to have in the beginning and then the majority the lion's share of the meeting we'll be talking about will be continuing last week's discussion on network health and I would encourage anyone to go and listen to that as its I

feel an important meaning for the network

the first is this is is VIP 1559 updates I mean it's Yuting I can give a quick update there was another implementers call so people can go watch that if they want to for details but in short we're working on getting you a test net between Jeff and bass you notes running 1559 there's been some good progress on that right now I think we have a basic part set up and we're starting to add the get nodes and we should be able to have it be more public in the coming days or a week yourself in parallel to that we've been starting to reach out to

people to help do a formal design of the mechanism and basically do kind of a analysis of does 59 actually reach its intended goals I know that's something that a lot of people in the community wanted to see given that it it's a pretty significant change so yeah I think those are the two major updates and we'll have other implementers calls in the next couple weeks great and most of the discussion for people following along it's happening in the rd they eat our indie discord in the 1559 channel we'd like to get involved that's the place to go for that

James Hancock: next item on the agenda is account abstraction updates is will

here know will couldn't make it unfortunately out be filling in fun okay so yeah hi everyone ants can hear from us from the quilting um little yeah basically earlier this week we did publish what we call the a ton of station playground we just briefly wanted to announce that and that's based on our MVP account obstruction implementation and get and the dependents that implementation together with vocal solidity and some example contracts and tutorials anyone who's interested can play around a little bit with a constriction that was the idea get a feeling of what contract intake should look like and all of that

I'll either link through that in the agenda for this call and just briefly while I'm on here I just wanted to clarify because I think there were some concerns around that obviously an obstruction has been around for quite a while and they have been a valid concerns in the past around performance and network stability we do think that the simplified proposal from earlier this year by bit early on a constriction might address these questions but we are still in the process of performance testing and collecting metrics this playground is not supposed to answer these questions it's just a byproduct of our work there once we have the results we like have it dedicated right up and then that might hopefully be the basis of like further discussion on that and

of course like we are well aware of the even if we are convinced at the end of feasibility and if we were to convince most of you here it might still not be worth the effort to bring it a minute I think someone raised it in the beauty as well that's that's a very valid point we just think it's worth looking into points more quotas like coming from is to execution research context and the past I was usually face to but now it looks like there might be an intermediary phase one situation where we would have a VM running on one or multiple it's two shots and so we're just interested to see and is there is it feasible to bring some of these features that were discussed in these two contexts like the current abstraction is there is it feasible would it be feasible to bring them to

the each one IBM that's all we basically we might be a mindful of the current state of the network we don't want to be disruptive we just to see how to help explore these questions and if you have any like feedback or criticism or something you can also find us on the ether Rd discard we have a kind of section channel there as well and yeah that's that's that's all for my site great in working me where can people find the you say was a github that had yes and these things so yeah I think that's worth mentioning again so I'll put a link in the so there's a link in there in the discord but I also put a link on the call notes

on github for for this call perfect thank you next we have Matt with her light client with the VIP to send one a further Fox and the ap2 seven one one introduction thanks James

yeah just to reintroduce 27:18 real quick it's the VIP four type transaction envelope and essentially this is going to make it easier to introduce new transaction variances and that work the way that we're proposing that this happen is we're gonna create

an RLP tuple where the first element is an integer that Doe notes the transaction type and then the second element is raw bytes that will be decoded based on what the transaction type is we talked about a little bit last week I don't know if in the two-week period between then if anyone has had any more thoughts or feedback regarding that EIP

Piper Merriam: we have a little bit of discussion yesterday in the channel that sort of uncovered a couple of things basically looking at that it does need a fork block because it's gonna change things like the header field and how the transaction route is going to be

computed and then I think that there's some complexity for us to dig into about supporting essentially the historical dev p2p protocol versions because when we release this first transaction type it'll still be possible for clients to continue supporting essentially once the nutrients action type is in place all of the dev p2p messages will need a new the deal with transactions have to be updated and that'll be fine because it means that the clients can still support old versions by essentially reversing the you can convert a type-0 one of the legacy transaction types you can sort of

blindly convert it back and forth between the two formats which means that initially we'll be able to still support the old dev PTP like eath protocol versions because new transactions can be downgraded to the old format but as soon as we introduce a new transaction type beyond the initial one that's supporting the legacy formats it'll officially deprecated all of the old eath protocol versions because it won't be possible to broadcast transactions or blocks in the old versions and that's something that I just realized this morning and that we need to think about I don't see it as a blocker at all but it's just something that wasn't initially clear to me

okay yeah so I guess like my question I don't

really I'm not as familiar with does p2p but my understanding was a it's thought of blocks and transactions just kind of like opaque data structures that's defined by the protocol and so if at a fourth block we decide to leave that using the transaction the legacy transaction this is this new one would not allow old the p2p protocol to continue operating by just serializing whatever the the protocol is specifying as the transaction

Piper Merriam: it would mean the only way do it would be for for legacy clients to actually change what those old protocol versions mean and so you would have to essentially make like a backwards

incompatible change to an existing protocol version and I think that would cause a lot of chaos on the network

I don't think this is necessarily

Piper Merriam: a blocking issue but I do know that there are you know a lot of 863 clients out there still on the network I'm not sure about clients that are using versions before 863 but basically once we introduce another new transaction type that isn't compatible everybody that's on an eighth critical version before it you know it might be 66 or 67 I'm not sure would would no longer be able to receive new blocks or or transaction

pool information

Martin Holst Swende: I don't really understand that way it would be so Piper because I also think I mean if the protocol defines the response to this message message should be a list of transactions and we then modify the potential for how a transaction might be serialized I don't see what we need to change the encompassing protocol

well

Piper Merriam: so I guess my my intuition there was that the dev p2p specs for like 863 have a definition of what a transaction

looks like they actually defined things like the fields and stuff that go into like the transactions message and so we would be making that one version says okay transaction encoding looks different so this is propagated backwards through all of the deaf PDP messages and historical deaf p2p versions the other version says those versions already exist and so we can't change the transaction format we need a new eath protocol version that has this new transaction format I'm not saying one if these is right and the other is wrong I was leaning towards the latter because it felt like the you

know respecting backwards and compatibility but I'm very open to discussing either of those

approaches so it's

correct to say that the dead PAP protocols are tied to a specific transaction type you it sounds like because if they are then that makes sense that we would potentially be needing to do a breaking change to past versions but if they aren't tied to a transaction type that would like lead me to believe that that upgrading the transaction type would just be propagated to all the ones without problem

Piper Merriam: I think that's the question that we need to answer and we

don't have to do it here on this call I think just the fact that like by getting this in front of people is really what I wanted to do so I think that we can continue figuring out what we want to do in

in you know discussions on forums or oh god R&D for them mm-hmm yep thanks for bringing it up effort any other - no no good yes sir I was just this is there

any other comments or feedback on 2718

you okay

27:11 so this is going to be 27 11 is a new general transaction type that's

going to add a lot of functionality that people is kind of proposed EAP is done or questioned in the past and this is going to be built on the framework that 27:18 is providing and so there's three main features that we're looking to add into this transaction type the first one that spawned all of these ideas was introducing something like sponsored transactions which allows for a transaction to be paid for by a user other than the actual user who will be represent as the caller of the transaction and this is going to allow something that's really not possible in the protocol right now it's going to give us a lot better meta transactions more at the protocol layer rather than

needing to do some sort of easy recover syringe from our contract execution the second thing that it's going to provide is

can provide batch transactions

and so this is going to let us have the stronger guarantees about having sequential transactions maybe you want to do a proven transfer flow and so this is going to provide strong guarantees or the sequence of those transactions being included at the same time we also think that this is going to help improve the or reintroduce the ability to make guarded calls sub calls and this is something that came up in the each one X call a couple weeks ago regarding the

proposals of possibly removing the other server bills observability of gas and with the batch transaction is kind of kind of provide that again and there's another AIP that's still being formulated the IP 27:33 which would give a return data to pass between these transactions and so that way you can kind of build a batch of transactions that depend on some output from a previous transaction and this is kind of similar how sub calls work today but this new batch version would work even if gaps not observable during EDM execution the third main thing is expiring

transactions and this is just going to allow transactions to become invalid after some time stamp s has been passed and we're just using the time stamp that's provided in block headers so as soon as that passes the transaction probably should be dropped from your own pool these are the three main things about AIP 2711 that's going to be introduced there's I put at each research post a few weeks ago just comparing some of the different approaches to protocol betta transactions which kind of addresses the first feature of this transaction so people could take a look at that if they want to see what else is out there I want to take up too much time but if

anyone has any quick comments or feedback definitely I appreciate that

Jason Carver: there might be interested in doing a block number and so

times version of expired at but we talked about it inside channel yeah definitely the just quickly the reason that isn't a rationale that the author has decided to use time stamp is that a block number is that time stamp is easier easier ly accessible offline you you oh yeah what we can talk about it yeah

sure

any other comments or things agree

on thank you for introducing these in movies yeah thanks for let me introduce the stuff yes

James Hancock: yeah it's been great having you work around well maybe IP stuff as well so thank you very much

for that thank you you but if there is no other comments on those then I'll give a last chance for someone to raise their hand if they'd like to

James Hancock: the next on the agenda is the network health and it's a continuation of the conversation from last week on

combination of how we move features forward and some of the weight that is on the client teams and perhaps what are things we can do about it I'd like to start by I believe Alexia is here then I knew new space to kind of Alexi brought this up on last on the last awkward that's captain channel I think and so I wanted to give you a chance to introduce and to reflect since the last two weeks if anything has come up and then Piper has written a great post that has had a lot of great discussion on it and so I'd say to move to him after that

Alexey Akhunov: yeah thank you yeah I don't actually have a lot to say to be honest so I just wanted to before the so we kind of looked back and I think I agree with Piper that we probably talked a lot about potential solutions without spend spending enough time on actually detecting the problem so I probably just gonna pass the microphone to him to kind of to contribute what he wasn't well he wasn't unfortunately on law school but he wanted to join this one so I would just let him to speak what he wants to say

Piper Merriam: already without further ado so let's see yeah sorry for not being unless last week's call but I did listen

to it in its entirety and and I really appreciated all the discussion that happened I spent some time trying to kind of like think through this because one of the guys who's been doing technical writing for us Griffin posted this wonderful thing from Harry Potter and the methods of rationality quoting about groups getting too quick to focusing on solutions before digging into the real problem and when I listen to last week's call that's sort of what it felt like to me you know there I think the discussion was great I just felt like it got some of the directions that it went it didn't like lead towards

what I thought were like actionable things that we could fix so like there was talk about you know get having like a head start on everybody and sort of like can we can we supports you know minority clients better and help them catch up and and that that you know had a high-level seems seems like you know okay well maybe we could do that and we could get you know other clients on the network but when I really look at that we've had a lot of of minority tiny clients in the periphery for a long time and and they're not poorly supported so some of them might be but it's not like they're like that far off from what the gift

team is doing on their own and I don't know as a as a like I think that the Basu Pegasus team is maybe two or three or four times bigger than the Geth team maybe so like I'm not sure that that support is the problem for minority client teams so I I felt like this has a lot of tie in with some of the stateless aetherium stuff that's going on and I kind of wrote I wrote a research forum post and a and a blog post targeted more at the general public in the chat for that thank you

it sort of tries to trace a line and it is a fuzzy line and I'm not saying that these are the only problems or that this is the only place that you could get to but my my conclusion that I draw for like why why don't we have more clients and thus why is it so stressful to be a client dev is that it's too hard to build any theory em client and so we need to make that easier I guess that's my like thesis which is which I'd be very curious to hear other people's thoughts and comments on

you

Martin Holst Swende: yeah that sounds reasonable to me

Piper Merriam: yeah I guess that's kind of just like a generic blanket statement um maybe we can get even a little more specific and I don't know if we want to actually get into like what it is specifically that we need to fix

but my mic I think

Alexey Akhunov: I think this is actually exactly what we want to do we want to eventually get to the things that we might be able to fix because I do believe that we have all the people here that could do things because it's not like okay we so it's not like we what I don't want you want

us to walk away with is to essentially admit our input input and say oh there we can't do anything that would be the worst outcome ever

Piper Merriam: all right so I think I can take a stab at this and then we can see if there's a direction that's worth it's worth like digging into more deeply in the discussion I think that we already are doing one big thing that's going to help stateless etherium it's us it should put us closer to a it's not so much that it makes the state more manageable but it makes it easier to ignore the state and I think that that is at least a starting point what we still don't have a solid solution for you know placing economic bounds on

state growth or anything like that so we can kind of tackle some of the state what like we're already we're already approaching the state problem from one direction one of the other big problems they see is the the networking protocol itself being a monolith in order to implement a client you have to implement a lot of stuff because the network protocol bundles everything together where realistically let's say that you're a miner who already has all of the state you the only things that you actually need out of the networking protocol or gossip but right now you can't be a active participant of network if you only respond to the gossip messages that are sent over the network

because you'll get kicked by other clients who are asking you for data so you won't necessarily be able to maintain healthy our connections and some of that is that you know the client the networking protocol requires clients to have access to all of the historical state and all of the historical blocks and chain data and everything like that so know that illustrate though I sorry not all the historical state all of the current states all of the historical chain and block data and and that alone is a pretty big requirement to put on on clients so it'd be really nice if we loose in that either by loosening it or

even lifting it entirely by separating the protocol out i'm alexi presented a sort of loose diagram of the network divided up into three pieces and I think that there's sort of a natural dividing line to divide the network into three pieces one being gossip which is essentially just transaction information for the current transaction pool and new block information propagating around the other is essentially the historical chain data so all of the old blocks and receipts and everything like that and then the third is state sync so a network that's

specially designed for efficiently syncing the state for clients they need to pull the whole state so I think so I think this is you know were we to have a network that was in these three different pieces and each of those three pieces was healthy I think it enables building more special-purpose clients or clients that just aren't required to build out all of the functionality you could build a client that just follows along with the with the head of the chain by only following the gossip part of the network ignoring

you know all of the other stuff it's not there's a bunch of problems that come up if we just naively divide the network into three pieces and that's something that it's probably more suitable for a discussion in a forum post or something like that but yeah so stateless aetherium attempting to kind of tackle the like problem of clients having to manage the state dividing the network into three Pete are dividing the networking protocol up into chip into two less monolithic pieces into more special-purpose functionality to allow clients to kind of select which networks

they they want to be a part of or things like that and now I'm hitting the end of my ramble I feel like I had a third thing but I always feel like there's three things [Music] does anybody have thoughts on those specific topics or is or-or-or a different thing that that you think needs to be attacked in order for us to simplify what it takes to build out any theory on client

Alexey Akhunov: I would like to kind of go onto something that you mentioned that saying

that the let's say that you gave an example of of what is it called Bisou yeah these do basically having more resources at the moment it is it looks like it's got more people then go aetherium and yet you know I would like to hear the do what is the perceived reason why you know Bisou is not just simply growing

in terms of the you shirt is it yeah yeah so

Tim Beiko: I think there's like a bit of a misconception there so when we first built the client base you I think I don't know I'd call it roughly 20 people mostly focus on building each one archive node and I was the first

version of base you and over time a lot of Pegasus's focus has been from fun stuff that's not main it so for example we do a lot of like EA private network stuff and a significant portion of our engineers are focused on that and now we also have any two client called take who which took from the same pool of engineers than we originally had working on base you so I'd say right now on main that there's probably I don't know four to six people who are working on this full-time and that includes stateless aetherium and then we also have requests for

supplying stuff that's more private that's work-related um so I guess the short answer is just like we have probably a bigger team but having a main net client is like one of the things we're focused on I'll live I'd say three or four and so that obviously it's the resources

that way okay so

Alexey Akhunov: I would like to ask the same kind of question two other people were Nicole I'd say that so much maybe can you tell us about never mind how much resources you've got like are you know comparable to go then I will tell you about our team so I have a sense of whether this the Pipers essentially kind of teases about the

main problem is the complexity of a protocol I would like to question this because I my personal intuition is that it the the protocol could actually be structured in such a way that you could code I mean it takes a lot of effort but he could actually organize your code in such a way that the protocol is is structural it's not like it's completely monolithic and if you have enough people and if you have enough dedication to actually do that you will be able to come up with the kind of the code which is very sort of team friendly rather than like it requires a superhero to support it so but I would like to kind of to hear from

other people what

about what it is very there is for situation yeah I mean if I think about resources obviously it always feels like this would help I mean we have two senior engineers working calm like we including me working on interim 1 and private networks and a few other things and this is also a tear in two ones and some of the commercial projects that we have but we have also two junior engineers working there one person enjoying this testing and known more

like developing cast so it's integrations testing json-rpc improvements and one person is working mostly on the projects that are not related directly to if one so if they say this is a team on the development side okay what about open theorem can our tomb tell us about your team can you tell us about your team

Artem Vorotnikov: right so we have three people right now we are growing but hiring rust engineers is generally it's always a problem not so many in the market but we have a team of three

people currently so we are currently working mostly on bug fixes on the 3.0 release because there was some nasty bugs in there but hopefully they will be fixed soon and we are looking at how to simplify things in the code base I have my own thoughts but as for the resource situation just three people and we aren't looking to expand

Alexey Akhunov: thank you so I'm gonna give you our situation and anybody who else I forgot might be somebody on the call who running the East one team so interpret yes we are very close to release I mean we're just getting a few a few remaining things done and hopefully we'll be kind of

announcing that it's usable but essentially what we have currently is let me just say I need to remember how me 23 I think we got about six people pretty much full time and I think this stuff started to pay off recently because I think in the beginning just there's a lot of life you know learning going on but I think it started to pay off to have a bigger team as you probably all know it takes time and I think it does actually matter the the size of the team doesn't matter in the beginning but it starts matter more and more if you kind of manage to get them to stick around so and I think I will have a seventh person who we just

started its junior developer but I think it will start making a big making a difference anybody else I forgot to well Piper can you tell us about your situation

Piper Merriam: yeah it's fluctuated some right now we've got three people full-time on eath one with that's not counting me because I'm not doing as much direct contribution anymore historically we've had between three and five working on it and we've been at it for almost three years working on the ourselves up against the trying to build

a III em client in Python which has had its own just difficulties but some of it like I don't think that we could have gotten further with more resources

okay and sorry Martin Martin can

Alexey Akhunov: you actually just tell us because I think we just started to look at can you remind us what is the biggest team situation at the moment

Martin Holst Swende: sure we are currently I think five people working on coding and of those oh maybe six and two are kind of new

hires something like that

okay so it takes I mean yeah

Alexey Akhunov: with the new hires it always takes time to kind of bring them into the

I counted 10 yeah don't count adamantly key right right okay cool thank you

Alexey Akhunov: anybody else I forgot to call out anybody else's word because I'm gonna go to step to the next question so that I would like everybody to answer if people if it's okay good okay so if everybody had if I haven't forgotten

anybody so the next question I would like to answer it goes to my kind of questioning of this assumption that Ethier in protocol is inherently monolithic and therefore very hard to implement which is partially true but I think it's also true because we haven't had the time and dedication to properly structure it and to decouple things from each other so it it's happened that the first major implementations had the certainties things kind of monolithic because this is how it it naturally occurs you know when you want to implement something you just basically keep implementing it and then you've got this monolithic product and then it takes you quite a lot of time to to

actually kind of split it up and figure out where the proper obstruction lines are and so forth and and so this is what I start you know we've been developing to beget for it like for I mean I started just a two and a half years ago and only very recently actually I started to see how the how to properly structure the protocol and how did the couple things and it becomes kind of quite amazing thing is that I all my previous sort of assumptions that it's really hard and monolithic started to for kind of fall away so that's why I wanted to hear your perspectives about what do you think about the possibility that we simply did not spend enough time

on structuring the protocol and finding correct obstructions and just making this modular

Piper Merriam: I'm not sure what the difference is between between those two yes that it sounds like just different words for the the same thing that I at least think I was trying to say which was yeah whether or not you divided up into three networks or whether or not you make the one network modular they feel like two anyways

oh and there is that

Jason Carver: is the spec inherently difficult to separate into into modular pieces or doing me to spend

more resources on designing the architecture so that we model the spec well in a and modular way

yeah correct

Alexey Akhunov: basically the the question that kind of behind this is that do we need basically like a superhero developers to to support this by superhero developer I mean that somebody who knows absolutely the entire thing like with a very very detailed knowledge like everybody who knows at the same time how to do databases how to do networking how to do this and this and understands the marquetry and cryptography do we need this kind of people or can we split it up into pieces where you can actually have a developer working on reasonably sort of small defined piece where they

can comfortably comfortably make changes without like knowing that they're gonna break everything else so that's what I'm going to come in into can we actually structure it so that we can basically like run it almost like an industrial operation and rather than this kind of superhero

based sort of thing

Martin Holst Swende: I think one of the problems of trying to organize it without this wasn't that you call it super super programmer it's that it's inherently very difficult to to work on I don't know transaction handling if you don't if you're not also very aware about denial

of service issues and what can cause I mean what causes disk thrashing what causes how can we avoid protocol the protocol being used with denial service and things like that and and what things are cheap and what things are expensive and I think there's a difficulty in that which requires you to have more than just knowledge about one component but a bit more

Tim Beiko: I think we've seen that too at Pegasus like it's not impossible to get you know call it non-superhero developer but it

does take time to build this intuition of like this is how the system works in the wild these are the things you need to be mindful of and these are all kind of the various parts and I think another thing that maybe it takes a while to build up is just like understanding where to find information on the area which is like different problems but um yeah I'd say to answer your question it's like probably not impossible but it is difficult and there is like a pretty a pretty significant ramp up area for some one thing that to get an intuition of all those things and then when they do they're much much more productive

Piper Merriam: I've seen the same thing on our team engineers can be very productive on the client before they gain the broad understanding of the protocol however I don't feel like this that what well they can be effective at implementing things on the client what they can't do is contribute back towards protocol development and research they can only you know work with what's there

and yeah

Alexey Akhunov: any other comments from other people from other teams

Rai Sur: yeah Aleksei you were

mentioning that like to what extent were you saying that you know you don't need to be a superhuman like were you just talking about the protocol as in you know it appear or were you imagining this superhuman person has to understand that plus the Merkel Plus feel like he said

Alexey Akhunov: well essentially I'm trying to reflect please you know the the kind of the sentiment that I got from Twitter and from other places where essentially if you to be honest people praising certain individuals like pizza for example for being such a super hero for looking out for the network when in response to when he basically says that

I'm waking up at 4 a.m. and trying to do stuff right the in response basically they respond with the praise oh how good you are right you were really great and in New York we all kind of owe you this stuff and so I kind of see this as the not a very healthy situation I'm ok you know with people praising people but it's like do we need to rely on the superheroes - there's nothing against Peter but I think it's kind of everybody would feel a bit kind of yeah so and what I want to dig into that what makes a person such a such a sort of superhero who can who can run this you know who

can know everything about what you need to do to afraid the client the client team and secondly is night is it possible to sort of avoid that to the certain extent made it not completely but so just answering the previous comments from Piper and others is that now I want to refine my question is that how much effort do you think needs to be spent in each team on maintaining and optimizing the client where you can have it but developers are essentially responsible for certain modules versus the the development that is is needed to go to to change the protocol because I think both

so we're needed and what are the proportions you cannot assume that everybody every single person on the team has to do some protocol improvements I think a lot of them actually have to do stuff to improve the actual implementation

Piper Merriam: I mean I think that's the problem right now though is that all of the clients are operating on the far upper edge of like efficiency and optimizations that we've been able to figure out and so we as the client developers end up having to spend time doing protocol development in order to make our clients work and so we're we're like we're at the point where you it's not that you can't build a client on the

protocol as exists today that's obviously not true but to do so is very difficult and requires a lot of careful optimization and so I think that's where some of the requirements for you know excellency come from is that in order to build a client that you know sinks and works in a reasonable amount of time and is fast enough to keep up with chain and everything you you you have to like attack things from a pretty advanced complex perspective

Greg Colvin: why is this a problem

Alexey Akhunov: sorry what is the

problem

wait

Greg Colvin: why is it a problem that in a very advanced protocol requires very advanced programmers to maintain and to research and advance it

Rai Sur: I mean there was the idea of like the problem that Alexey brought up I think he was saying that whatever the difficulty is it could be made easier with structure in order to kind of lower that

you know oh yes

Greg Colvin: the various skills need to be reflected in the structure of the software so the teams can work on it with team members having their own expertise to write one

alone is difficult to write a very high quality one although you can steal one that exists and copy it in whatever environment and languages is necessary

yeah this is this is where exactly Greg

Alexey Akhunov: this is exactly where I'm trying to get into I'm trying to get to the question can we do that can we add the extra structure add extra guidance to make sure

net we's yeah of course we can that it's engineering everybody doesn't cool yeah so let's

Alexey Akhunov: let's talk about this how can

we do that

sorry just before we go into that I had another suggestion to make like do we okay I understand the rationale for like you know having several clients but does every clients need to reemployment every single piece of the code I mean you you have for example the Python Python I mean it's interpreted there's not there's not going around this maybe Python could be an even nether mind or anything could reuse bits that are from gath from open a serum from whatever that could be reused I do why do we have to reemployment everything every time one

Tim Beiko: I guess for us the reason was licensing and and I think something that

was considered at first Pegasus and you know can we build off something else but just the licensing of the client with an issue

okay that's so if you're going commercial I can see why this is a problem

but um for

Piper Merriam: for the Python client some of it is design choice so some of it is you know corners that we painted our own selves into we did look at one point at using a VM C or something like that but in in if we were only focused on building a client that would have been a an option but we also focus on

exposing an EVM library itself and in order to do that if we were to use e BMC we would have lost a lot of functionality and features that were valuable to us so some of it was just design decisions I would love to have a database application that just managed the etherium State that we could interface with as a black box that would be wonderful I'd love to have turbo deaths flat database just as a as a piece of software that that we could use so I think that is a great direction for us to focus on simplification is reusable client components but to get there I think we also have to make

clients more modular so that you aren't required to implement all of the things

yeah that's actually quite good yeah so also for so

Artem Vorotnikov: for what it's worth there's also and FPTP implementation and trust the new deputy implementation that is currently being written as a library so it will be pluggable and hopefully it can be used not only in open aetherium who has the new one but also in other clients

- and then except you had a comment

wondering if my mic is not working because sometimes it isn't yeah

Alex Beregszaszi: just a comment on the ABMC and just wanted to share the I had the same impression hmm what Piper said especially with DVM see I think one reason a lot of these clients choose to only have everything in the same language and because if debugging is much easier that way and also delivery of the client is very easier if it's just a single a single language because then it's packaged nicely and I think that was the D blocker against for example EVM C and EVM one to be used in Goethe RIA more in

other cases and probably the same applies to you too many other components and there was a proposal some time ago by Pavel from Aleph to maybe separate add some components and make them interoperate through an RPC protocol I believe he he separated the networking layer into its own it into its own part and I think there were some discussions about this but it never really got any anywhere

yeah guess once everything in go argument the thing is you know some clients are having a hard time catching

up so why not externalize the development of some problematic components

Piper Merriam: well I think the problem is that the most problematic components are subject to the highest churn like if like think about management right like the the best answer that we have for state management is the flat database layout right now I think that there's two independent implementations of that with turbo graphx having one and Jeff I believe having the other and like I'm struggling to figure out how to say

what I'm trying to say but basically like depending on one of these things essentially subjects you to the development cycle of another team because these aren't mature stable pieces of software they're pieces of software that are changing at high velocity and thus that's why I think it's maybe not feasible right now to have reusable components at least in the most problematic pieces of the protocol the reusable pieces are probably only viable in the most boring parts of the protocol json-rpc is one of those like like exposing the json-rpc api is boring and it's something that every client

does and it's a pretty generic thing but it's reimplemented across every single client

well

Alexey Akhunov: what I would say is that we did actually coming back to attack succeed for example and young we did look into implement integrating EVM one and in DMC and we did actually put it in master because we could and so the hope was to essentially attain a higher performance but what we we hit into we hit into these interfaces between languages so in go for example you get high overhead of interfacing we see which is not noticeable when you basically do the core once in a while but if you're

operating it like if you're running the evm see-through like blocks at a speed of let's say 100 bucks per second then the the overhead becomes noticeable and so that they're there for at the moment it's not the performance is still lower than the performance of the native kind of go go serum like idiom but we are not stopping there we actually started developing the the kind of the bigger component which wraps around EB MC and then connects to the to this to our database which is currently LM DB which is a C interface so that component is in C++ and it would actually connect the the sort of the

high speed because basically what the problem is that when you start making modular software you have to watch out that these interfacing points are not the ones that are introducing too much friction so and we realize that the interfacing with the EVM in the my EVM C introduces quite a lot of friction unless you have very efficient into language interface and so we want to reduce that friction because we know like something like def p2p or RPC doesn't actually introduce that much friction and you can it pretty easily separate them out as the is a modules so we actually gave in this direction but I would like to sort of get the sense of how everybody wants so if we decide this

is gonna be one of our strategies I wanted to everybody to be started being aware of it and actually move in there rather than kind of moving in random directions

Piper Merriam: to me this direction doesn't feel actionable like and if I understand correctly the direction you're talking about is is generic reusable components that can be used by multiple clients is that correct

well well it is kind of the high goal yes I don't see

Alexey Akhunov: I agree with you that it's not immediately actionable but it's one of these things I call the Northern Star like a high goes whenever you're you're you're making your architectural decisions or your kind of strategic

decisions you need to have those things in front of you to say okay out of these two options which one would contribute to the kind of the the future where we have residual use usable components and perhaps that would kind of nod you into this direction I completely understand we can't simply sort of say oh yeah let's all do everything modular yeah that's probably not not actionable right now

Martin Holst Swende: yeah I would I would say that there's actually so there is a disincentive towards going towards the modular approach and that when you do this monolithic and when the bill is monolithic thing there are a great many

opportunities to optimize everything and we're at this stage in the game now where basically we have to optimize everything in order to handle the massive actual state that we have so it's not enough to have a fast EBM in order to actually process both quickly you need to maybe do some cheats like you maybe need to have a precursor which checks like what like what accounts are likely to be used and how do we you know can we precast them in the state cash so that it once it executes there's speed-up and if we try to just

disentangle all these components from each other then a lot of optimizations go out the window so I think it's very difficult to untangle everything because then you won't get a fast client

well actually

Alexey Akhunov: I had the opposite experience

can you let Thomas raise his hand so I'd like him to go next their mics muted dumbest yeah sorry I had trouble too president Mian button the master twerking yeah okay so

Tomasz Stańczak: a few things so first of all if we start

talking about reusable components I think we were looking everywhere possible when there was something to reuse we looked at EDM see I agree with Alexei the interface at EPMC was simply not possible to integrator in a mine stay now it might have been performant underneath for the interface was not like designed for integration with other clients that well like up to the point where it was not possible to integrate it with with our virtual machine that was doing like the iterative approach instead of recursive one that was one one example like so it was just a bit too low the interfacing was too low so

when Alex C says that he writes a wrapper it makes more sense because the interfaces of the ADM are very simple you just need to access state and almost end transaction and a very small context of the block environment so at this level it could be possible to wrap it up then when we talk about having multiple clients and we talk about correctness coming out of the multiple implementation that when they start using the common component for the virtual machine that actually we kind of try to achieve that goal of diversification by introducing the single component all reliance or why not having a single client then okay you can have multiple components and different team specializing in all of them but

then if every single of those components is implemented only once and we didn't really get anything from the diversification as what Martine said same in our case most of our optimizations come from the fact that on the understanding of the whole architecture and all the possible level salary to dizzy across module optimizations when you I think that over time our code looks less and less nice the way Alexei describes is exactly it's nice architecture nice module framework it started like this and all the time all the optimizations are slowly breaking two structures of course we put a lot of effort to keep the architecture clean but sometimes the optimizations will

actually cause it to look worse some of the things that terrible when I explain it to the new joiners for example like Carol or a piece of realization you know every new joiner would say oh we should we write our own fee to make it look nicer so it for its generically but no it works like this at the beginning but then it was split into smaller and smaller pieces to the non allocating very specific each type is separately defined on how it serialize instead of doing that in one form again most of the complexity lies in our case in the synchronization and network my thing that we are locking the proper comprehensive test cases for a potential

network attack network synchronization nodes and so on you have very solid consensus testing and so if um even being very difficult to implement it's reasonably simple comparing to synchronization and state management say I would say if you want to have something for all the clients to to be better we can save a lot of time in implementation by just adding more and more networking test network this case is different their attack scenarios being used in those test cases and so on because we have to write it ourselves now just to give you an example what if you did a king or a standard synchronization and we have to experiment with all the possible

malicious peers scenario when they send us beta test not really following the rules that it tried to send the data that is actually breaking our synchronization modes this takes a lot of time

it's testing we can possibly build something similar to consensus tests on the network layer

James Hancock: we have about 25 minutes left

anyone else wants you to jump into the comments and

James Hancock: you have to click the raise hand button down tell us to have it go away unless you have another

phone because

Alexey Akhunov: if nobody wants to talk right

now

yeah well if you if you're like

Piper Merriam: if you've got sort of a conclusion I'm happy to hear that but I'm still not I'm not sure what exactly you're like I did this this this topic seems to have have wandered and I'm not sure objectively what what's being sort of suggested here

and so I'm a Michael

Alexey Akhunov: so far what I gathered from our conversation is that first of all it seems like so I see some agreement to the thesis that some level of structure structuring might help to sort of to

improve the life of the developer in in one of these teams so even though there's still kind of opinion that you do need like really knowledgeable sort of super developer at least one or two whatever okay but there still might be some as Greg mentioned it is very kind of common practice to structure the software to make sure that it is designed it is optimized for the team rather than for one person and but on the other side I can hear the arguments that you know the optimizations are necessarily cutting across the modularity which actually something that I mean I'm not ready to debate it right

now but I think this could be this proven false because actually I saw exactly opposite effect in our latest reacted texture which actually gave us the boat of the most performance boost simply splitting things out actually was most beneficial but it's I also another thing I heard from Thomas which I wanted to fix is that they and Guillaume so essentially the idea of having reusable components in some way cuts cuts against the idea of having diverse implementation and I currently would say that yeah these are two sort of slightly

disjoint but not completely joint approaches to improve in our situations maybe instead of having multiple teams working on completely different implementation you can have like some sort of hybrid situation where there would be teams working on components then there will be another team working on kind of assembly and you know those components and so forth

well Gregg Inman Artem

Greg Colvin: I spent years working in the kernel of a very high-performance system and the team members were specialists in in the particular areas they needed to be to get the highest performance out of

you know they had to be experts in a very narrow deep way but they had to be able to communicate with each other enough to deal with any cross-cutting concerns but one of us could be responsible for just two or three files in the system spending most of our time that specialized and then a larger set of files that we all had to understand and it got pretty damn hairy but the specification was clear and the major module structure stayed stayed clear and aligned with the specialties that you

need for that kind of high performance software it's just what you do but getting getting the specification clear so that somebody can write such a thing not the highest performance but you know a clear silent implementation you know that needs to be done yeah then you can bomb it as much as you need to but there's not an initial clear spec you're you're not going to make it

that's not artim Piper and right

Artem Vorotnikov: so I agree with the thesis that that there needs to be

some kind of ability for team members to species to specialize in a theory core development for the simple reason that if theorem cooperates are basically they are not born they come from all walks of life so unless we are ready to train every I mean we have we are having this experience right now because many of us working on openly theory we were hired starting in January basically so many of us are just learning the ropes still and co-developers they come from all walks of life so some come from with networking background some with just generic back-end engineering background

some from security and cryptography background and it's unreasonable to expect every single newcomer in the core developer in the core development to to completely understand all of the yellow paper right off the bat because that's that's unreasonable people specialize in their usual day jobs that are not related in the theory of core development so it makes sense to to not pile on them basically and another thing that I wanted to just mention is that if we solid this is slightly different but

also to the topic of simplification is that if I were building a new client today there are two things that I wouldn't want to face first of all this is the elaborate mechanism in thinking in networking where I have to match request to responses this is basically there's something at each six to six is designed to solve as far as I know and another thing is that I wouldn't want to do aetherium archaeology and ring implement all five years of changes in the yellow paper so this is definitely something that I wouldn't want to tackle and there should be a way for the new clients to just

start with with the rules in the network that exists today not that existed a millennia ago

so this is that Piper Thomas and then you still have your hand up Greg Piper did you want to go yes as I talking to my muted phone it

Piper Merriam: that sounded a lot like Regenesis maybe that was a reference to that which

Alexei proposed recently and I think that that's something that we should look into very seriously because being able to ditch the old ABM rules is like that would be great I think that would be a major simplification for for new client developers you know a barrier lowering right for clients because yes like it it's a lot easier for those of us who have gotten to implement them as they come but to try to go back and figure out what the rules were three or four or five Forks ago or something like that is is not an utterly trivial task to do I still am very skeptical about reusable components I think that they

are a great idea but I don't think it's something that we can that we can like it it doesn't feel like one of those things that you can actually push like it's something that that will happen at some point and I think it's good to encourage people to focus and work on that but if we say that's our solution then I think that the result is that we are all going to end up having to just sit around and wait for one of those to show up and that's kind of already the case right now so I don't like like I agree that we could gain some ground there but it doesn't feel like anything that we can actively make happen

and it's that's different than the like the

specialization or the modularization of the codebase so it's easier for the developers um they're

Piper Merriam: similar I mean that one is just on an individual client implementation like level of how do you structure your code and can you achieve you know good modular code we have people like people have been able to work on the Trinity code base for a long time don't fully understand all the protocol stuff because of you know architecture and modularity there so I think that we're already doing that as as teams and so I really want to move our effort into into some of these harder things that I think are going to

have just way more significant long-term impacts hence the carving up of the network into maybe three maybe up to three different pieces we've already got great momentum going with stateless aetherium and and and working towards having a network with witnesses and so I'd like to see like the the area here that I see that we have agency to make real improvements are on our focusing you know getting more people looking at some of these other areas that aren't stateless etherium because we already have a good number of people working there on things like how can we improve sync and state network which I

am lately more of the opinion of like piling onto what guests already been doing with snap and us really looking at what we can do either with the existing protocol or if there are things that we can even do to to iterate on it and make it better so that we can get sync completely out of the ether otic all and into its own specialized sync protocol and and I'm working right now to get a meeting scheduled to work on the other corner of that problem which is historical chain data and figuring out how we can build a network that does a good job hosting all of that historical chain data so that we can take the

responsibility off of full nodes I'm talking about solutions now but this is where like this is a problem that I have been thinking about for a while and I and and and I think that this is the area that we have the agency to actually make a change

Martin Martin Tim and then right um sorry to blow at my hand all right so then marching Tim Ryan Thomas all right yeah first I'm gonna add to what Artem said I think that's a really good point so this 66

Martin Holst Swende: will make things easier we haven't actively pursued it yet

because we I mean it's really nice we're still gonna have to support the old protocols for a while so we don't see it does something that will make our lives easier in the short term but for anyone I mean for other clients to do so I think that would be great also about not having to to make all the historic rules I think that totally makes sense and I think it's totally legit to release a client which will not be able to do a full sync from zero but instead has some hard-coded hash that it syncs only to some block after I don't know seven million Jeff uses canonical

hash tables to basically hard code the known check points that we know that which if someone tries to sink us to block 500 we should not do it we will go to the latest scan on clash table entry and sing from there and then they that team would have to solve how do we actually get this state a I mean they could bundle it it would be a very large binary but they could also have somehow their own custom gossip network which spreads the sink on which they start or something and I think that would be totally cool thing to do for new client regarding what Piper said about

separating out state management into some other protocol or network as currently constructed the snap protocol works it's not on top of each it's in its own namespace it does not so in the latest design it does not even rely on get no data from the protocol but instead replicates it inside it's not protocol I think and the we're still iterating on the protocol mainly Peter is but I think it's at a pretty stable point right now where it is sufficiently

evolved but it's no longer proof of concept but it actually can be used in a more production like setting where you actually sink for multiple peers

and not just one pair with another Peter and yeah that's some of what I have to say Jim yeah I'm

Tim Beiko: I'm wondering is if we're like conflating two things is one is making it easier for a new client to be written from scratch you know a client thing that doesn't exist today and two is like how do you make it easier for the minority clients

that exists today to actually you know improve their share of the networks or make it easier to keep up and it seems like we're kind of going back and forth between stuff that would help one or the other yeah and I'm not sure what's the best way to like delineate between them because I feel like for example what was mentioned earlier around say you know having modular components for some of the common stuff it's like that would help a lot if you're creating a client from scratch but like obviously base you open your theory another mind Trinity they all have json-rpc right so there wouldn't be any gain from having like a JSON RPC module that exists and yeah I guess I'm just wondering like in terms of solutions like how different

the two are for both new clients and minority

kinds of a

Piper Merriam: there's one thing about json-rpc that I'd love to address which is essentially it yes we all have json-rpc implementations we intentionally have not implemented any of the logging api's and Trinity because it's my opinion that those should actually go away and that those should be like secondary tooling that's built on top of clients so I think that one thing that I think that there are areas where reusable components could maybe not in the

shortest term but in at least in the medium term could reduce development overhead for existing clients as well as new clients

Thomasson and Alexi a Finnish court reason see the dopey no new clients for interim 1 in the foreseeable future interests if you

Tomasz Stańczak: can change the architecture so much to enable the new clients to be quickly built this will be interesting but I think this requires research effort maybe maybe in that direction Alexei is looking at that's for the existing clients to to improve the things Nick we we feel that we spend a

lot of time on the on the tooling things that some users are used to so it means that we still can work with the users that do not require everything but we cannot work with all the users and this will always reflect on they um they like a share in the pie on how many common users are running then I mind comparing together will work with some users and clients and it will be really really satisfied and don't they can't because they may actually not be using some one or five percent of the functionality for easier delivery of the clients liked that provide everything that is available in a tea room now my thing and I keep repeating that tests available

for the clients are the most useful tools and we cannot really over invest in testing of various components the one thing one thing that I'm looking at recently is this like JSON RPC confirmation of all the clients behaving the same as is something in our users had a bit of a problem for a long time because there's no place which will tell us how exactly JSON RPC should behave in corner cases how it should behave when the errors happen the time notes and so on all of these things are causing the minor differences that the users later report and they take quite funny lis big

amount of time to just fix something very small to be compliant with what gas Authority did in the past and I think with proper testing tools we can really save a lot of time here for not only the new clients that will appear but also to the teams like Trinity bazoo in the mind and even like partying gets to actually arrive at the exactly same behavior in some cases and if these cases are just to give you examples like what happens if you invoke it eh call like a coal contract we found specifying gas limit without specifying gas price without specifying sender because they spiked up json-rpc it does describe the API but it

doesn't describe the exact behavior here and the users do have problems with this and they then come to us and we spend some time to make it the same as gas and it it's not necessarily following any spec on not following expect because the spec is there and we do follow it but there are some things that are not described and they cannot be really valid or not valid they're just implemented in some way in a majority client and you have to do that the same way because other users are used to have it so more testing more tools for testing Network json-rpc consensus all of these components and then it's 2 times faster to deliver those on the market

alexey our demand and tim did you have your hand up again oh just forgot through ok so then yeah so basically what I want to say I'm just forgot it okay yes so

Alexey Akhunov: to the question about would be nice to forget about all the archaeology of the EVP and behavior yeah that's actually one of the the side effects I didn't realize that would come out of something like Regenesis but even before that is what something with Martin mentioned that is that if you could simply download the sort of the snapshots from somewhere and then then download all the blocks and that's not short which is actually what

are the things that I'm planning to do with trooper yet I actually decided we're not going to try to implement any of the snapshots in protocols in the near future and for the reason that instead we want to try to do something much more simple we will produce the snapshots of the state in whatever format we we kind of figure out and we're basically gonna be distributing them and on the let's say a BitTorrent that would be snapshot every let's say million blocks and we're also going to be distributing the slices of the block looks and had three blocks and headers and whatever receipts so they will be some kind of hard hard coded content

addresses and we'll see how it goes because if you can if it's okay for I mean trooper guess is particularly efficient in executing like in syncing from Genesis but if it can it can sync from the latest whatever blocks and million or eleven million I think that would be simple still a reasonable performance and the complexity so the simplicity of this solution will probably mean that we would want even one needs to have some kind of super complex or not even super complex synchronization and that is something that we can do without yeah as you know without any hard work so anything like

this so if you think that this could be done across the multiple implementations we could figure that out as well

that's what I was going to say artim and then rye and we're island we have two minutes left so I wanted

Artem Vorotnikov: to talk about JSON RPC so it was mentioned so that's basically each flight has its own implementation but for me personally coming from micro-services background partially I was quite surprised I don't know if this applies to all clients but that at least some clients do not automatically generate Jason RPC server

from a schema this is something that also could definitely be looked into by everyone and could definitely reduce code complexity in in their clients

in right

Rai Sur: I just wanted to like put something out there after the discussion about how there seems to be a difference between you know the level skill required to implement the protocol versus to suggest improvements to it I'm a year into working on a theorem and I definitely feel like I don't have enough of the holistic picture to actually think of you know improvements to the protocol whereas I feel a much more

confident in implementing into implementing it as it is and working on our client so I was wondering if there would be any willingness to do something like in aetherium open OpenOffice or like open hours or something where you know a few the people who have actually had track records of suggest the improvements to a protocol we can all get into like a zoom call and just asked like unstructured questions stuff like that things that aren't implementation specific yeah I think they'll be really useful to me and maybe some other junior developers on other teams

yeah

James Hancock: I like that I do I'll be happy to help organize something like

that we're at time I want to give a space for perhaps a final thought from someone if there is something I this is seems to be an ongoing conversation that we should continue

and my

Hudson Jameson: final thought I think if we have one more of these if we have one more of these that aren't you know about e IPS but about this type of conversation around and I guess what we talked about today I can't even sum it all up in one good word that we should focus on actionable next steps maybe or like

goals or this is what we're doing in response to this so that the end of the story can be we did X in response to Y and I think that would be really cool I don't really have any idea what that would be personally but if anyone wants to take up on that and has ideas you can throw them into the Chordettes chat the agenda or the public discourse in general

yeah I agree with that

Alexey Akhunov: okay so that was pretty good so I would just want to summarize it for one minute so what I've learned and I think what we collectively learned together or sort of something that we need to look into more

in more details so I think there was a good discussion about you know is there a different either is it possible to essentially structure the teams in such a way that there are some people who have a more holistic understanding and they're the these people are kind of have a necessary experience to propose protocol changes however they might be the case that the majority of people do not need this majority of people to be able to be productive in such a team do not need this sort of holistic experience and they could be super productive in simply optimizing the the current implementation that's that's one observations that I had another

observation is that we there is still some potential for for structuring and that's what Gregg's calls the a good specification structuring the protocol and what is required in such a way that people could specialize so that's the second point I think we touched upon and we talked about the kind of the reusable components which i think is sort of slightly a saga no or even maybe disjoint to the to the client diversity so I think these are the three things that I took from from from today

James Hancock: something that would be good for next

time is strategies on adoption of client diversity so I don't think we talked about that today but it came up on the last one so next steps for that I think that is time so thank you all for coming today

thank you experience yep bye everyone thank in you thanks everyone thank you thanks again James yeah of course [Music]

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

[Applause] [Music]

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