# Open Community Discussion Devcon5

- Channel: [Devcon](https://streameth.org/devcon)
- Date: 2020-10-09
- Duration: 59:33
- Topics: blockchain, smart contracts, distributed ledger, ethereum
- Watch: https://streameth.org/watch/yt-CZWkpOwEb6o
- YouTube: https://www.youtube.com/watch?v=CZWkpOwEb6o

## Description

Visit the https://archive.devcon.org/ to gain access to the entire library of Devcon talks with the ease of filtering, playlists, personalized suggestions, decentralized access on IPFS and more.
https://archive.devcon.org/archive/watch/5/open-community-discussion

An open community discussion featuring many voices from the Ethereum ecosystem & developers.

Speaker(s): Various
Skill level: Intermediate
Track: Society and Systems
Keywords: ecosystem, feedback, floor, technical

Follow us: https://twitter.com/efdevcon, https://twitter.com/ethereum
Learn more about devcon: https://www.devcon.org/
Learn more about ethereum: https://ethereum.org/ 

Devcon is the Ethereum conference for developers, researchers, thinkers, and makers. 
Devcon 5 was held in Osaka, Japan on Oct 8 - 11, 2019.
Devcon is organized and presented by the Ethereum Foundation, with the support of our sponsors. To find out more, please visit https://ethereum.foundation/

## Transcript

what this is is a community discussion and we have people who are core devs we have cat herders here we have all kinds of people or from different organizations to bring different skills to this and what we're going to talk about is theorem 1x and so this is an open format this is a fishbowl format and so what that means is people from the audience can join us in the week we have these - this chair right here in this chair right there we're gonna try to keep open so if you come to the front there's someone there you can kick them out if you would like to to join but I expect this to fill in more as more and more people want to participate if you want to keep participating you can move into one of these chairs and just stay maybe you won't get kicked out but I think anyone could be kicked out so sorry but yeah just keep in mind you're you're free to participate so we're gonna have I guess we'll try to keep a mic mic over here if anyone wants to come and we'll put a mic right here and so I guess we'll get started the key the key to this is where we're gonna start with what what does the community want to talk about what - developers want to talk about what core developers want to talk about and then I'll I can just pass the microphone on to you all and then maybe you guys can get started with the conversation sounds great should we do intros with some of the people up here who are core devs and stuff just so people are familiar well everyone in the circle gets an intro so perfect yes if you're gonna sit in a circle then introduce yourself yes okay so let's kick it off I'm Jamie Pitts I've worked with magicians I'm also work at the etherium foundation that's a net back there once you introduce yourself hi guys I'm in it and I'm working with it here magicians and I'm helping out with operations and organizing events and making sure that all those people and all those the important discussions will happen cool so we'll leave to you Hudson you wanna introduce so my name is Alexia Hoonah I'm I've been working on your biggest client which is derivative of Kosir IAM and also the last this year i've also been involved into research in development of into state rent and stateless clients so which I'm all these things I'm still doing hey I'm Hudson Jamison I work with the etherium Foundation and with the etherium cat herders I also am one of the organizers of the bi-weekly core developer meetings along with a few other people who we all help out I'm not accord EV but I try to keep up with the text so that I can facilitate the meetings accurately I've been doing that for the past three years roughly so I know a lot about the process he's the hard fork decisions things like that so that's how I feel like I will contribute today I also have a talk tomorrow on the main stage right after Vitalik I think it's a ten on eighth one X so if you want to see a more formal presentation that I have slides for and stuff feel free to come to that tomorrow that's the end of my showing hey I'm Tim bake Oh I work with the Pegasus team on the hyper that year hyper ledger basement client I'm a product manager not a core dev but I do attend the calls to try wrap my head around the process and the eeap's and I'm also part of the cat herders I'm Rai also at Pegasus working on hydrology Basu yeah hi I'm Martin swanda and I work for the ethereum foundation with security issues aetherium infrastructure may not and also I'm one of the coders on go with areum hey so I'm Peter and I'm currently the lead deaf of Goethe reom that's about it I'm Vitalik I advised a couple ICO projects it before never hello technically I'm not the part of the core team but I've since I'm sitting here I'm doing the notes and the clients with the nation-state cryptography for the Russian central bank I guess my name is Cody born I'm a developer on the adjure blockchain team at Microsoft hi I'm Lucas I'm just a random software developer who worked on depths and I'm the humbled sitting at his magic round here okay so what do you guys want to talk about what do you all want to talk about if if there's anybody who has a topic that relates to theory m1x please come forward with it is do we have something okay come on down come on down I also have a topic okay so you first I'm worried about the scalability of a theorem one so and we can't even reprise up codes without breaking anything I mean we had this discussion with the 1283 I think it was the problem and now we have the same problem again with 1884 so as a developer I would be really interested in seeing some invariants that I can work with so that my code that I write and deploy Andre Ethier maenette doesn't break in the future and I mean in the case of the 1283 the developers weren't following best practices but now in this 1884 case yeah people wrote code they followed every guideline that was there and now the code breaks so yeah I can kind of give a quick intro to this before we have some comment from some of the other developers but we had an EIP and basically in order to make it the blockchain a bit safer to prevent from and please correct me because I'm gonna butcher this from like DDoS attacks we repriced an opcode and in repricing that opcode if you have a smart contract that relies on that opcode being a certain price that contract may break there was a bunch of contracts that have upgradability I believe Aragon was one of them and those are gonna be able to be upgraded but it's a little bit annoying there's other contracts that may have the effect of having funds locked in them that's a little bit scary of a term so what we did is in order to prevent this from being another scenario where it's like we can't get our funds out things like that what we determined was if people come to us after we implement the CIP and they say something like hey this is you know messing my contract up we're going to research and come up with a solution to work around so that they can have their contracts work again and those limited amount of cases do I get that I'm almost right okay yeah Martin can also comment a little bit more on yeah and you brought up two cases 1283 and 1884 and they're kind of different because 1283 was made to improve the life of deaf developers making it cheaper whereas 1884 has been added as basically a security precaution because to rebalance the opcodes and the former one we skip that so it's not to break stuff it's being implemented now again in the form of e 2200 but with a minor modification so that it won't start introducing new vulnerabilities into contract and in general the idea that has been floating around a lot is that if we do changes to the EVM we will also do versioning so that these new features will be opted in however it really makes really kind of makes no sense to have opt-in features for security features where we want to protect the base layer so thus we're all out 1884 and the thing is this will affect a lot of contracts but in the large majority of cases it will only mind affect them a little bit like most use cases that are affected can be solved by adding a bit more gas at the beginning and I think that would cover like 95% of all the cases where it's going to be affected but then there are some particular use particular flows where it's already encoded that it's an automated transfer into something else and that flow between two contracts can thus be broken in a way that is not fixable and I mean not fixable by the initiator of the of the transfer or the operation and so that much has been you know we know that this might break things the question is how hard will it break and and how much pain will it bring because I think that in many cases contracts are actually upgradeable and if you have a set of contracts which suffer from this you can actually redeploy it and fix it that way which further brings down the number of actual broken flows and if there if it can be evidenced later on that hey we have actually these particular instances which are broken cannot be upgraded and cannot be salvaged in any way then we can look at okay so what fixes are needed to solve these instances and there are a couple of ways that may help in most of them I think in for example if we lower the cost of a location that will solve a lot of the issues but it remains to be seen exactly what kind of patches will be needed for the yeah to get the maximum coverage or the rescuing or what you want to call so maybe just a step back I thought it might be useful to just offer an introduction as to like the specific and if gas cost increase in some of the security background around it so it's a kind of general fact in a theory so in aetherium we have different kinds of op codes we have op codes that do computation add divide subtract elliptic curve pairing and so forth we have and we have data and we have op codes that do disk i/o so basically op codes that read from read from contract balances read from contract state so read things that require basically accessing the disk and it's been a general fact of etherium pretty much since the beginning that the gas costs that we set for those out codes are for multiple reasons far lower than they should be so one of those reasons is that the operative to there gas cost the op codes actually take a fairly long time to process because accessing disk is pretty expensive and takes a long time and so for example there was this recent paper that suggest suggested that like on their own hardware a worst-case dos block would take like up to 80 seconds to process and making a worst-case tosspot is hard because you have to outbid like whatever all the other users but there's like it's security is still lower than we would want it to be especially given the people's people's desire for more scalability in the medium term and so from a security point of view it's like pretty much required to increase the gas costs of checking contract balances reading contract code you agreed in contract storage and my own personal opinion is that the IP is that we have don't go nearly far enough but the problem is that the like this requires increasing some gas costs and this basically breaks some contracts that relied I'd only assumption that there is a fixed amount of gas within which they could do some things so I think I've written this opinion somewhere but from my point of view the the reason why the creases of the gas ghost breaking things is because the gas is used in two different functions so first function of the gas is what metallic was talking about is to basically measure the the impact on the system the performance impact and charge people for the same transaction to compensate for that and discourage the abuse of the system but there's a second function which also gas gas plays which is the restriction of the things like recursion and Kobach's and that that second function has been on the rise since 2016 when the especially especially after the re-entrance e3 instance ii problems have been kind of brought into light and people were trying to use the second function the gas much more to so they would allocate a very limited amount of gas for a lot of operations to make sure that the recursion doesn't go deep or the callbacks can't do things but we now see that these two functions are becoming at odds with each other while you know improving one we actually hurt in the other and from my point of view the it is becoming worrying because that that tells me that in the future we need to do more of those things in just in the gas Coast and we have to assume that we should be doing it all the time anyway because the hardware changes everything changes we have to do the way out of it is to split those two functions and then decouple them from each other and that does bring complexity because we essentially will have two gases now to gas counters one for the one first function one for the second function and then you need to decide what is the gas limit and is it the gas limit for the first one or is it the gas limit for the second one but I think it's solvable and more importantly if you decouple this then you are kind of a bit more future-proof so coming back to your original question which was a like invariances an app developer like obviously we need to change the gas cost sometimes because security and a whole bunch of reasons and some of which we don't know today so I I guess it's a question for people up here are there like actual invariants that you can give the DAP developers building and aetherium or is the sort of hard answer you know things will change they will break and we'll try our best you know to make that the least inconvenient as possible but it's kind of unrealistic if you're building an app to assume you know there's any invariants I think the truth is like somewhere in between but I'm curious what people think about that yeah I I think that the app developers should have the mindset that things may change there are no way variants and they should build their systems or deployments in ways that they can be upgraded because it's still developing the EVM is still developing that's my point of view just after that I think of for example now the important thing that that developers should always keep if in front of them is that every time you you find a neat little trick that hey I can store this data in a in a more optimal way or sorry in a way that kind of is a bit cheaper than storing it the other way around our goal as maintenance of a theorem is to make sure that everything is priced correctly which kind of means that storing data should cost the actual resource so if you figure out a cheaper way to store it then there is a high chance that if it picks up steam then it will get patched simply because it's out of its not balanced correctly so our goal is always to balance there is the of course of the resources actually being used and yes sometimes that means making it them cheaper and sometimes it means making them more expensive but all the loopholes will eventually be filled so I think that's a good invariant can I ask a question unrelated can we warm from great hi I'm Mary Emma from maker and I'd like to discuss programmatic proof-of-work because because I feel I I feel like there's a big device core devs and community in general and like I've seen a lot of prominent members of different projects and apps that feel strongly against it and many quarters apps that feel strongly for it then they were way around and I don't think we've ever been closer to a potential heart Fork since 2016 so I would like to see what you think about it I think prog POW is really important as an issue that we need to decide not important in itself necessarily I am NOT taking a position but I'll say that because of the politics around it it makes it really challenging because on one side you have you know the people like ASIC manufacturers and users and some investors and stuff like that who say we don't need it the threat isn't big enough or you know the people who made it are unknown and that's scary and things like that and then on the other side you have the GPU miners and the mining pool saying we need this otherwise we're gonna go under and you're going against the promise that you made in the white paper according to them that that there would not be a sakra xizt insanity reom so and then there's many many other arguments I'm actually post Devcon going to make a large blog post reddit post etc with everybody's arguments and counter-arguments so the community can get a better idea of where everybody stands on that from each side that's on my to-do list and it's nearing the front of it so that'll happen hopefully before November and other than that I do want to kind of hear the perspective of some of the core devs because there you're right there are core devs who are supporting prog pal from their perspective whether its technical political or both and that's another divide that's very that's very naturally occurring is you have this technical perspective where we had two audits done a hardware and a software audit that basically cleared prog Pao is something that wasn't super fishy and then you have and then you so you have the technical perspective of it's good we've implemented it it'll take two to four weeks for the other clients to implement it we're good to go and then the political one where it's like you know I hate Christie Christie's bad Christie lied all this other stuff with coarse scientific and the people who are anonymously developing it so a long story short a lot of politics involved there's technical versus non technical arguments and there is a division that needs to be figured out in a rough consensus style way yeah I am personally I kind of cooled down quite a lot on this particular issue or last few months I did see a lot of you know discussions a lot of people getting I hope they're getting more informed about this so and I really welcome the audits that happened I read through the audit report yeah I mean I I sort of had my opinions I put them out there and I'm happy that you know people were listening and there was a discussion going on and at the mall at this moment I'm you know I'll be okay if it gets implemented rolled out and I'm gonna be okay if it doesn't so I'm not really going to worry about this so if I'm basically something that I've said before if I turned out to be wrong that that's fine you know yeah just kind of moved on so I think it's made a good progress recently yes I'm one of the core developers or pro rock pal and I've written down my reasons why I believe rock pop is the right way forward the way I see it I think there's very loud what I perceive is a very loud minority who is extremely loud and spreading a lot of fear and I started in doubt about it and in my view there has been signaling taken from the community there has been coined about there's been mining votes and etc etc so I feel it has been kind of there has been shown a great support in the community and I don't think this situation has changed from six months ago except that at this point in time there has been a lot more yeah a lot more churn from the political side and then the fun side yeah and I from the political side I would say that one area that myself that I fault myself on and others is there wasn't enough communication people like to be heard and this kind of got sprung on people some people because you know who's gonna read a transcript of the most boring core dev meetings every other week I mean it's not boring to everybody but like there's a lot of you know just very deep technical topics and the average person isn't gonna you know realize that so got sprung on a lot of people and that was a communication error and so because of that now people are upset because they felt like they're not being heard now they weren't being heard then when they felt like they didn't like Prague town they thought it was dead because it wasn't getting implemented as quickly cuz this has been on the radar for how many since last don't know before last DEFCON so since March of 2018 Prague POW has been starting to be implemented talk about etcetera so it's been a long time so I think if we can have people be heard that's going to heal a lot of the wounds and start to get us more toward a rough consensus and I welcome people from the audience if you have an opinion on this you can go sit in this chair and like you know give your opinion or whatnot and otherwise anyone else we can go to another topic one thing that I'd like to point out is um intro my name is Dan affarin I'm picking my son up from school one of things that have noticed within the past six to eight months with this is there's been a notable drop in civility in the arguments relating to prog pal and the problem with this drop in civility is people start closing their ears and there are principled people with real solid objections to it who get lumped together with some of these people spouting these crazy things and that's doing a disservice to the dialogue to be uncivil and to be rude and to be crude to everyone and to send all sorts of weird veiled threats to people that's just not cool yeah I agree yeah I think I want to want to echo Dinos statement I'm Adrian Sutton work on Basu I think one of the things that's very dangerous in this for the whole etherion community is that if we set a precedent where you can shoot down something by attacking someone proposing it personally then we're gonna see a lot more of that in the future so I'm really keen to hear technical concerns and that that includes some politics of do we actually want to be a Sikh friendly is that that direction we want to go those arguments I'm all for I really want to hear but when we start diving into this person was associated with that or they're corrupt or their and not actually being able to point to this is what they're trying to do so if you've got a problem with Proctor and you think it's all great scam then great let's hear exactly what the scam is not just a vague thing where we're we're slandering personalities because that leads to more and more attacking people which makes it incredibly difficult for people to stand up and make proposals and be involved in the community we've lost people in the community who would diluent great work because they've been attacked personally in the past we don't want to see that happening in the future just to add my two cents this whole proper vs. Edie Hodge discussion I think one of the so currently my feeling is that the whole discussion boils around a sick whether we want to be a secure distant or not and I think this is something that kind of just is tearing the whole community apart and I from my personal perspective I don't really see what's the whole point of office so currently we have a few big mining pools now if we have an ASIC friendly mining algorithm then probably we will have some manufacturers that make a killing out of it and some mining pools now if we have an ASIC resistant mining algorithm probably there will be some different mining pools and different hardware vendors making a killing out of it but essentially from my perspective currently we're just trying to decide who we want to give our money to for mining or for creating that hardware now if on the other hand we can actually technically say that one of them is dangerous or one of them or we can somehow prove that yes et hash is a security issue and we can prove that publicly then all of a sudden probably the entire community would shift towards the other one so if as long so if there's a threat to the network I think then the whole discussion is decided and if there's no threat to the network then it's it's kind of just a heated political thing of who gets to make more money out of it and that's not going too far too fast I do we have a next topic or somebody wants to discuss something yeah come on up you can come on up before we're done talking about the next topic by the way and just grab a mic so we know the next one's ready all right hey I'm Fernando what's the deal what state rent where are we at with that it's council no actually it's more the question is the answer is more complicated than that so our current effort is to prototype and specify so that's my main effort effort in my little team team so to prototype and specify the the first viable version of the state status clients what's this oh yeah and so so you might be the the the good thing to put out there is a date of data from the status client prototype if that would be their proposed to Leah did that one that's probably the like the closest one you could if you scroll down to the there it describes a slightly the idea of it go down a little bit it's very old post but it's still relevant and it describes what we kind of want to do and the yeah further down to the graph to the next one breakdown yeah a further one further it further okay that one so yeah so the this is the I've done some more analysis on this but basically there are what we're trying to do is that we kind of try to circumvent rent a bit because as I said in April in our meeting in Berlin after research in researching rent for a bit for a few months I've realized that it is possible to do it technically but it would be very expensive project to roll out practically and the reason why it would be very expensive to roll out right now is the is the cost of ecosystem research which had to be done because the the state rent wherever however you implemented it will change the programming paradigm in the way that at least in a way I thought about it because other proposals where you have a kind of attenuated cost of the storage which I don't call story Brent it's a state rent because it doesn't actually remove things from the storage so so any any proposals in any shape or form which will start removing things from the state at a certain after the state rent is not paid will inevitably change the program in paradigm and some of the things will become quite a connect unexpected for example give you example now I have a smart contract and solidity and it has a variable fill variable net and you initialize it in constructor and that variable essentially like let's say pointer to another contract you initialize it in contract and it's an on now it's reference to another contract and you can happily use it within the contract anytime and you assume that it will never go - it will never disappear so you don't have to check in every function of the contract that that pointer is still valid that the contract that you point you know is still there because you're assumed that okay I've initialized in constructor it will not go away it's like in kind of Const constant variable in C++ right it will be there it's once you've initialized it it never changes but then with the state rent you might see that this thing can just go under you know it will go under the pointer so the this contract will disappear and then your pointer will will point to something that doesn't exist anymore so that sort of lots of these things have to be changed in terms of the paradigm so and obviously there would be some contracts that would be suspected susceptible to some Griffin attacks that need to be needed to be researched as well and obviously the number amount of resources that I thought would be required for that so if we really wanted to roll it out would be you know something that I cannot afford or maybe I'm not sure if if they are foundation would be able to afford that or something like that so that's why we started to do more emphasis on status clients which might actually if implemented correctly and if if my sort of intuition is correct it might actually give us enough runway before we and then I've got another proposal but which I haven't published yet that actually introduces state rent after the stateless clients but in a slightly different in more surprising way but I don't think I have time to explain it so there basically it's postponed at the moment until we do the stateless clients okay so stateless clients are the way to go until a few point oh that's what's gonna hold so hopefully because I don't know because the obviously the future is hard to predict this is our current this Alec wants to say something yeah so I know like another reason why it's good to go this way is because the like the ease by far the easiest way it's our kind of merge ease one into it the REM 2.0 is to basically turn it into a stingless client by default because that's just the way that state is inside of each key works so what actually kind of makes the the roadmap stoic fit together very smoothly so the downside of the state is Cline related to the state rent is that there will have to be no the network that still hold the entire state but the this requirement will not will not be for every basically phone out so they will be still somebody has to have all the entire state but we hope that this is you know as long as not everybody needs to do that it will be better so one kind of hard thing about stateless clients that I think it's important to be very transparent and clear about is that meet the making stateless clients work well ultimately will require the basically the same kinds of kind of gas cost sacrifices that we talk that we but in the first question but probably to an to an even greater scale right so for example the witness size so the size of like extra Merkel data that you would needs to pass for to verify a worst case block right now is about three hundred and thirty megabytes and that's basically because you have contracts calling that seven hundred gasps twenty four thousand gasps for a contract and then add four thousand bytes for a witness twenty eight thousand x fourteen hundred and like you've got you've got your hundreds of megabytes right there so and then there's kind of smaller versions of this attack with things like the balance off code SSO load and all of those things so I think we will ultimately need to have changes that say like one the gasps cost for these storage accessing of course opcodes go a lot more to is that the gas cost for accessing contracts that have a large storage like what needs to go up even further right so for example charge one gasp provide of provide of code that you read and if we want to make this nicer one thing we could do for example is we could waive the extra fee if the contract was accessed say within the last ten thousand blocks and that would reflect the kind of the actual load of kind of quote almost stateless clients that keep stayed around for a little bit of time so like those kinds of like that kind of rebalancing would need to be thought thought about as well so basically kind of for multiple reasons like developers should expect that kind of IO is likely to storage reading account reading cross contract calling is likely to get more expensive relative to other things just to pause this topic for a second I wanted to introduce somebody just got here Felix Felix take the mic and just give a quick introduction he works on some of the networking stack yeah I'm Felix I work on guest on on the networking uh I just got here from another a I missed the beginning so I don't really know what you guys talking about what I hear it's mostly been about stateless fans which is actually which add also huge challenges on the on the networking side so I feel like the status lines is basically just this unsolved is like any other problem there has been progress but it's not really something that we can honestly say like it's easy to pull off like yeah I would I would use the same analogy as for quantum computers I've heard like to as I've heard about two years ago that in terms of quantum computers all the all the fundamental challenges have been solved now it's the matter of engineering to get to build one I mean it's it's so there is no real kind of super complex stuff in stateless Minds that the idea is super simple you can yes there would be more you know shuffling that data around the network there would be some issues with that but I don't see them as being fundamental can I interrupt so I I think there are really fundamental issues there so the problem is that the moment so currently transactions are really tiny the moment you start entering into territories of megabytes and we're not talking about hundreds of megabytes as megabytes the whole networking layer needs to be gutted out and retrofitted so you cannot own you can chunk up messages into smaller pieces that's a lot of engineering effort research effort let me just finish however even if that is soft and the network data shuffling is soft then if you so all of a sudden you also need to store these witnesses beside the transaction so you implode or explode sorry the the data usage of the immutable side of the chain and we can say that yeah but that's cheap to store we can put it on an HDD sure but we're already at 100 gigabytes 150 gigs of tiny transactions now imagine that all of a sudden every transaction will be twice or not twice ten times the size and maybe instead of one hundred fifty gigs would we would have two terabytes of immutable chain basically is the information to give us they was playing for syncing data yes I'm saying like that basic like an archive no it basically is the note the the the no type that has like all of the data was the ability to produce it on demand for any transaction yeah but my essentially without an archive node you would not so you either need the archive code or you need the chain of witnesses so one thing we can agree on with status clients is that basically it it changes the user experience a lot where previously handing the state was kind of if areum's problem with stateless clients it's a user problem no no that's not true because I think you might be confusing it with what I call status contracts so they they're so stateless contracts is the the idea it's actually the it's a design pattern where we're by your start instead of storing your data inside the contract storage you store some sort of miracle route and then you start passing the they like you pretend that they're the data somewhere of change well you don't pretend that there is of chain but whenever your do something with the data you start providing the miracle proofs and these proofs are actually inside the transaction and that it increases the size of transaction and so on the status client actually remove it's not like that it moves the the burden into the actual layer in the protocol layer it's it's not the the job of the smart contract developer will not change and the user will have the exactly the same experience apart from paying more for the state access so as Vitalik mentioned the call up codes will be more expensive because you have to load the code the S store as loads and s stores will be more expensive balanced the reading will be more expensive anything that touches the state will be more expensive to pay for the witnesses transaction format will not change essentially in there will be more that data shuffling around network but not as transactions as the as the basically part of witnesses and of course the witnesses we will chop them up in part so you don't have to like to ensure the the better propagation so that is also a kind of pretty solvable problem but yeah it's not okay also in that case that that's like it's like halfway solution basically like you do still want to have state it's not like status and you know like a theorem itself doesn't have any state it's more about so I would say this is the the stateless client is basically approach of of instead of asking every all the app developers to follow design certain design pattern you just basically solve it for them in a generic way so if you have a status client instead of telling everybody poom to put merkel root in the contract you just tell them just do whatever you did before and we're just gonna take care of that you're just gonna pay for it a bit more but the whole technicalities will be taken care of so we have we have the working group session scheduled for later this afternoon and about like 15 minutes left for this session so maybe it makes sense to just like have a stateless client discussion this afternoon because I know there's a whole bunch of new people sitting there what time is it 3:30 to the end of the day I don't know what that is they have this room here to just discuss working groups jason carver also join give a quick intro with Felix's mic hi Jason Carver working on the Trinity clients that's an all Python client I came here to talk about stateless clients so I guess I'll save that for him I mean we keep talking about stateless clients but yeah yeah does anyone have anything else they owe hello hello could you talk about VIP one five five nine which is the idea of having the gas priced at the protocol level and it's burned instead of given two - yeah sure so the basic kind of description of the proposal rate is that we basically add a kind of negative components to the block reward so that basically says that we have some in protocol fear and incident you within the context of any particular block you can think of it as a constant but the constant adjusts up and down over time and it's basically the minor of a block has to pay some amounts or alternatively the block reward is reduced by that amount which is equal to that fee multiplied by the number of gwei of gas used and this obviously if this kind of like whatever this burn feels like it'll push up the minimum wave or the minimum gas price that the miner is willing to accept by roughly the same amount right so like if the fee goes up to ten quid then the miners not gonna accept transactions that are less than 10 way because they're not even going to be not profitable anymore and the idea would be that we would say increase the gas limit limit of a block from say 10 million to maybe 20 million or more but then we would have this fee be adjusted according to an automatic algorithm that basically in targets the use average usage of gas and a block to be to be at the ten million level so if a block sometimes blocks will be bigger sometimes walk is always smaller whenever blocks are bigger the fee goes up whenever blocks were smaller the fee goes down and so at equilibrium like there's some kind of mandatory fee that gets that kind of gets burns and miners are going to accept below it but the end like blocks are an on average gonna be a half full or one-third fo instead of being completely fall the reason why we wants to do this and there's actually a few different reasons one of them is that but the most fundamental one is that currently fee markets work really horribly so one example of this is that like on average people tends to overpay by a factor of somewhere between three and three and five or higher than five for our transactions and like you see people talking about a trade-off of like you either pay five times more and you get included right now or you pay like two took the minimum and you wait maybe a minute and maybe ten minutes but like in reality that waiting is like completely socially unproductive right because it's the same load to the chain well no matter if it happens now or if it happens ten minutes from now and and also just it adds a lot of wallet complexity that people have to like think about oh is this gonna be a solo transaction is this gonna be a fast transaction so EAP one five five nine fixes it by making the calculations you will minor much some much simpler the calculation basically as if there is a transaction that pays the burn like whatever the burn fee is plus whatever amount and it overcomes the extra risk that my block will be an uncle and that value has been estimated to be about one guei that'll accept it and so clients would just like pay like calculate the fee that they pay based on a simple formula and it'll reliably get into the chain and so users will be able to get like pretty reliable next block inclusion of any of their transactions even if there are odd short-term spikes and there's like suddenly two times more usage in this minute and electrodes I was watching usage the next minute so it's intended as a kind of fee market simplification and a user experience increase because like users just won't happen won't have to wait anymore what does that do for users who are willing to let a transaction happen sometime over the next day they're very price-sensitive saying yeah so users will be able to still like basically say I want to pay a transaction I'm gonna pay a gas price which is lower than the let's say for example I as a transaction sender see that the current fee that's being burned is like pushed all the way up to 23 way because like I know fair one is doing stupid stuff and I as a user know that fair ones doing stupid stuff is exceptional and four hours from now chances are fair one will stop doing stupid stuff so I as a user totally can send a transaction with a gas price of say nine gwei instead of twenty three and whenever fair wind stops doing stupid stuff to get the burns gas price we collaborate down to below nine image production will get included so that's like totally fine an intended behavior that you can do so I want to comment in this that we a lot of times we're thinking about like the one user sending one transaction which is okay you know you can wait or you can do it within like you pay a bit more but the real problem is that for the people or for organization who actually depend on sending tons of transactions all the time and for those people it's crucial that the things work well because they can't just say what we're gonna close our exchange for four days until this whole things blow over right or we stop sometime under topics ten minutes any topics yeah Bri I wants to bring up this idea that in order to reduce storage requirements on nodes we like actually make more progress on implementing a mechanism where we only require nodes to store say the last year of history and for anything older than one year we figure out some way we're note where each individual node only needs to store part of that so that we basically instead of node storage being 200 gigabytes that can just be like state plus 10 attended 20 when you when you say splitting it you don't mean like go to Peter sounds like sharding kinda is it sharding or cheney yeah so I guess this kind of was one of my proposals from way back in I think last year or this year journey or last year January so the idea was that currently a lot of the ether ohms chain data about one another 50 gigs give or take is just immutable past chain for example past transactions past blocks past receipts and many people don't really need this I mean yes it's nice that you can dig up your transaction that you did five years ago but do you realistically want to do it now if you don't want to do it and okay that's that might be an interesting thing for you to want to dig up your transaction from five years ago I definitely don't want to pick up your transaction for five years ago so essentially it's just we're wasting a lot of space for a lot of people that and it doesn't really give a anything back and then the the idea was that can we somehow say that okay we're going to maintain the last some time frame maybe a year and maintain everything on all who knows but everything that's older than one year let's try to put it stash it somewhere else and make it available and generally I think most of this is doable so it it is not even a hard problem to solve the tricky parts come start to appear with for example logs because they are so contracts for contracts use logs as a cheap data storage and then they just the Deb filters for the logs and the issue is that logs weren't really designed for this but it wasn't really explicitly said nor limited that this is not intended use case the Internet use case of logs was to raise events so your smart contract does something it raises a few events and then you react to those events and yes it's nice that you don't have to react immediately you can react a day later a week later a month later and that's perfectly fine the problem is that for example there are Deb's kind of like the Akasha social network which uses logs to store the post themselves which means that when you want to list the post that you've written or your feed they will actually scan the in a blockchain for data and these are the use cases that that gets really really broken because all of a sudden you have a node that wants to access all the time the history going back to the past five years and this is their really the challenge that that needs to be solved on the upside however the nice thing about this chain Pass chain data is that it's immutable which does mean that I mean immutable in theory is not immutable but in practice do the proof of work you won't have a real that's a million block deep and this kind of means that you can move this data on to an HDD so you can actually make store it relatively cheaply however I do I still say that if we want to enter these stateless clients territory then well if the blocks all of a sudden becomes a hundred times larger than we need to solve this because even on an HDD you don't want to put 100 times more data so it's an interesting problem definitely so something interacting with the next section of topics how does the finality gadget figure in with a chain data do we need to keep historical data being on the horizon of the agreed-upon finality and how far you know how important is that finality gadget you mean like that used to finality I should get one and for consensus purposes you definitely don't need to keep any history older than about eight months but and like one year was the period that I had suggested we make kind of mandatory doubled so sorry so so the one proposal and that ia that I have for solving this receipt issue is that it's actually a very nice problem to just solve with a group to economic light quite market right like I want to keep a list of all risks of all the transactions that satisfy some particular bloom filter I asked you you give me a complete list and you sign that list and if it's or if someone else disagrees they can make a miracle proof and they can like so and they can slash your deposit so like basic turning like making something like that the other benefit of that approach is that instead of requiring like you to scan a bunch of headers walk away it's basically a few rounds of network messaging so could be also interesting to look into prototyping in the medium term so maybe one thing we could do because there's so many people in the room we're just like us like a lot of you guys are deaf developers like who here needs access to logs from beyond like you know last three months or something like who's Depp's actually use this stuff you can just maybe raise your hand if you need access to all the historical stuff I see about 15 hands yeah so what about transactions who snaps use transactions could we also get some information on why those locks I don't know maybe because it's cheaper yeah but that would actually be a really interesting question like to a lot of client developers like which taps are like heavy on like actually accessing transactions like transaction by hashed transaction by book and index who uses those that's really dumb developer is there and wants to talk about it please come over instead this circle because this those mics has a cable so we just come free so just for the record I saw two hands for the transactions three okay well cool okay so not a lot of people you actually use a facility that like access past transactions is what I mean getting so from this room from this room it is not me like not representative just to expand the reason why Felix was asked actually asking this question so we've been sitting on a new feature for example in gas that so currently all fool knows all the theorem who knows maintain an index the transaction index that's simply saying that this transaction hash is located in that block so essentially just the hash to block number mapping and it seems like a stupid cheap thing except when we count that they are five hundred million transactions it turns out that that's 200 gigabytes of the sorry 20 gigabytes of data so essentially every fu-- know this is storing 20 gigabytes of data just to be able to say in which blocks and transaction is and if full of don't need it then we can immediately wipe out 20 gigs of data that can be reconstructed at any point in time and that's the reason Felix's question was really really good because we always wondered is anyone actually using it or can we wipe it should it be the default or should it not be default so it's actually really reassuring to see that people don't need it yeah come to the mic right there yeah so I work at synthetics and so we obviously have what's like a Dex a bit like your new Swami introduce yourself oh hello my name is Justin Moses and I'm the CTO at synthetics for a defy app and we do indeed need to know the transactions our users of ahead of time and adapts however we have been using something like the graph and that's actually being successful so we're happy to use decentralized services like that that can track all our transactions instead of having to do like yeah point go back and look at individual one so I guess what I'm hearing is that actually all the people who might actually want access to transactions will totally be fine - like externalizing that to some service provider because it is it's not really something anyone like a lot of people expect from the node to like do for them to like get the transaction I think a cost you would have like rewrite their stuff but I mean know that's what I thought they were log heavy crypto economic light client implemented then they could just like replace one two to one the two lines of code and it would just work as is and it would probably work even faster than today but I was just Paulo question for you on the deef i thing we look up transactions don't is that ancient transactions or is the transactions for the last week month will have all of them so over time so we're gonna go back to look at even you know years worth interesting I want to throw this out there real quick we're about out of time right what's it worth three minutes yes yeah so I personally think eath 1x eath 1.0 is getting stronger there was a period of kind of you know eath 2.0 is the the new stuff and it's sexier and stuff like that but uh now it's like the theorem foundation has dedicated at least eight million dollars to eath 1.0 and 1x research development etc and that is being spun up they did that back in May to do it for the next year and there are teams being spun up as we speak coordinators being spun up as we speak so there's a lot of good stuff happening as some of it's happening in the background a lot of it you're gonna see in the forefront real soon you've won forever yeah wait but is it really gonna be forever that's actually the next topic eath one-day into transition just one last one last bit about that I mean oh he's gone but the guy was just standing there had like some pretty but just like in general I think like that developers if you have like these peculiar use cases trying I don't know like on eat magicians or somewhere like that they try and like explain like answer those questions and like oh are DAP is like kind of weird because it uses logs in this way and and we'd like the note to do that or not do that like if they were like eath magician supposed you know kind of either complaining you're requesting features I think that would be pretty useful I mean like one five of nine right was like one I was very interested in already right and it's imagine a lot of DOC development care a lot about that because gasses you know lifeblood and having the form to be able to talk about that because don't really want to jump in on AI pay unless I have something yeah you know meaningful to say I think so I feel like youth magicians it's kind of more general less formal forum where you can just kind of write a post and people will see it yeah