All Core Devs - Execution #38

Transcript

[Music] [Music]

you [Music] [Music]

[Music] you

[Music] [Music] [Music]

[Music] [Music]

you [Music] [Music]

[Music] [Music]

all right Lena we get on the live pier we're good all right awesome thanks everybody for joining let's go ahead we got a lot on the agenda today so let's jump into that Dimitri I think you're on here let's start with testing and you also had an EIP for a common Genesis format across all client implementations or Genesis JSON so basically something that everyone can agree on yeah that's right I was thinking about this for a long time now when I started doing this RPC testing tool I see that each individual client has its own

Genesis configure field and field names and parameters but some of them are basically means the same and we should come to agreement how should we name it at least the format should be general for all of the clients that would be much easier for everybody do you have I can write about that and but actually I think there are two problems one of is the structure of the Genesis file which differs between the clients and another is the kind of semantic meaning where some clients have like four o'clock number for each for

hopes that a 4 o'clock number for it is not where as priority for example has number they haven't divided it up by forks necessarily but by features and that may vary between clients so that they have feature X at block X instead of certain hard work maybe we could come to a standard in this question yeah I think we could and so from Paraty site this is a actually discussion we had recently because we're moving around some parameters to make it easier possible to have POA chains that don't they're these sort of theorems

specifically IPS and hard quarks and a part a part of the problem here is also when you change the spec file like how do you migrate from one to the other so probably useful to have like a migration framework discussion here as well like what happens when it changes and if there's breaking changes how do we deal with them yeah I think it would be great if you could put together some a group to work on this because every time something changes I noticed it when hive goes down or EBM lab stops functioning and I really like to to get some buy-in from parity and guess and testing yeah

that's why I introduced I fielder and called the version in that genesis proposal he could implement scheme for the format and call it version 1 and then at least we agree on this scheme and everybody implemented it and it should work so Martin since you have rights and get her to make new channels could you maybe make one just a quick channel to throw some people from different clients and to discuss this I can figure out the other stakeholders if you'd like absolutely great Dmitry does that sound good to have a getter chat and start kind of flushing this out more

yeah absolute something okay great and otherwise guys comment on the EIP it's linked in the agenda for any other feedback okay and Genesis is basically a description of the first block and the state and some optional parameters so I just trying to figure out what I needed and how should we name it okay sounds good let's move on to the next topic client updates and then a research updates after that I decided to move them from the end of the meeting to the beginning so we're not having to rush at the very end of the meeting through this

and we can just if we run out of time we can just table some of the other items till afterwards that's a series of changes that are going to be happening to this meeting so if we go to client updates we can start with parody Fredrik all right yeah we I'd say the biggest update is the one 11.1 release we have a bunch of performance improvements and general improvements here but two main ones are we've introduced sea life or whisper and we've have a complete refactoring of the transaction cue so verification is happening in parallel

previously fetching items from the queue was order one but now and inserting was order n-squared now it's much more performance for inserting and we've kind of split out the transaction pool to have like a scoring and readiness thing separately which makes it a lot easier for my nurse to like view the pool and a more coherent way and be able to do a lot more with it so I think that's a pretty big change on our and put otherwise this just general improvement okay Thanks guess I guess Peter you know so not much

we're mostly working on performance improvements we've seen that in the last couple of weeks transactions on main ads especially spam transactions kind of went up so we're trying to track down some issues that we're seeing especially around memory usage and I'm not really sure we have a few hunches hopefully those will be fixed I mean hopefully those will fix the issue but your card benchmarking them on testing apart from that the problem we just had a meet-up in Stockholm small team Nita and we tried to figure out which direction to take they go into one of the one of direction that we would like to work the

words is basically some form of accounting resource accounting for the light client which should be able to help a lot with with the centralizing running full notes so basically we'd like to create some form of from basically separate the light kind the resource counting which kinds uses how much resources and probably the monetary layer so that anyone can basically monetize their note however they like with whatever mechanism and then gas would just count it and make sure that you adhere to your own quarters and yeah I think that's mostly it we've also I've done not quite

a few little bit of hacking on on a new synchronization but I don't really have any numbers yet but I'm hoping that by next week sorry bye next chord F meeting in two weeks I could give you guys some hard numbers on whether it's worth it or not if it seems to be worth it I'll probably post some some document next week so that everybody would have time to look through it that's it cool thank you CPP etherium Paul hi from from my from our side important news I sent binaries for a CPP atrium it goes if client and

test if to to get half releases it's it's now in form of development snapshot but will make stable release soon and we have some RPC improvements and fixes and and also all the tools within CPP atrium accepts dynamic loaded EVM C implementations and you can load for example he was in back-end as a shirt library so you don't have to rebuild all the source codes in trying in case you

would like use some external VM yeah that's that's all I have from from the from the interface point of view okay thank you very much harmony Dimitri we have finished everything we want in this release it is release candidate now and we started to test innate it's mainly a performance release we have improved processing time up to five ten times before it was difficult for us sometimes to stay on the top of the chain some blocks arrived

early and we processed previous so we have solved this issue now it's a fast we are still behind get but it's a big improvement for us also we have fixed it a lot of issues with stolen of synchronization with memory usage and we are going to test with this and release in one to week that's all I think okay thank you anyone from Pegasus okay anyone from Trinity we've been knocking out

low-hanging performance issues for the last like two or three weeks and gotten things down to a point where we at least probably have a viable alpha right around the corner we have main net full and fast sync functional same with functional white clients working on getting some of the RPC endpoints up and running against those and basically knocking off a pretty short checklist right now towards public okay great I'd like to introduce Jeff he's with the X theorem team it's a new client written

in elixir Jeff if you wanted to kind of just do a quick intro of the project and updates hey guys thanks for having me here yeah you know we started X theorem about you know it's pretty new client probably about six months ago and the focus has been to help you know diversify the community plus a lot of people have been using elixir for the backend servers and we figured having a lot of these libraries in place would be beneficial for people building services on top of this area for us you know there's just been a lot of work on getting to a v1 client so a lot of the libraries we've been focusing on are for interacting with back-end services plus you might have heard of the work that

POA network is doing they have a mana for a for called mana and the goal of that project is to you know push to having a full synced first-class client so you know just glad to be here and help out any way I can awesome thanks Jeff is anyone from Nimbus here ok am i missing any clients not research teams but clients Turbo goth put their update and the notes and the agenda if anyone's interested in that there's some really cool really cool improvements and

there's also a link to the video Alexi did a TED Kawas really good I was able to catch that ok before research let's start with Casper Danny I think you can take that yeah we've been honing in on the VIP spec as we've been talking with clients and kind of figuring out all the little details there's the updated spec is live and associated change long and the discussions to issue there's some concerns about the parallelization of both transactions and how clients will actually handle this and initially these

conversations are leading us to think that we might put all of the the data that boats do modify and a separate track that's guaranteed to not be modified by anything else but those boats so would be really easy for clients just copy the state route hash like that contract round anyway we're working on that we're also working on some decentralized pool implementations just kind of some proof of concept stuff right now this is also something that recently made it onto the grant wish list if anyone out there listening is interested in getting involved other than that just keeping trucking along I know that a lot of the clients are

implementing their exciting getting there great to hear and then let's see drops of Diamond James yes yes yeah project so yeah we just are being working on blob serialization so it's been finished and yeah I'm just looking into developing and feeding feeding network who is live p2p or Russell EPA so yeah that's that's a lot to say okay II was um any number of people can take that Lane or KC lady

if you want it yeah sure our focus for Azam has been on EBM to blossom and you know that that trans files EVM bytecode to Waze invite code and it would allow for a client that only has a Waze and VM to be able to run on the maintenance acute EVM contracts but but the main reason we're we've been focused on that and testing it with on CPP etherium and uh is is to get greater wasum greater test coverage over the over the that you

as an interface the I because with the with IBM to us and we can transpile all the IBM you know you know state tests the the multi client test suite and then and check a lot of edge cases uh and discovers or discovering fixing bugs in an era and then EVM EBM G Watson okay Thank You Phil is that is that Phil dying or a different Phil hello Phil are you able to hear us I'm not sure if Phil

has a mic or anything but if you if you are able to talk to us later Phil just jump on I wanted to see if there were any updates from your end on the jello paper or anything else like that so now that we've gone through all of the updates the next item on the agenda is reward clients first first sustainable network when each transaction is validated give a reward to clients for developing the client and I think there's an ethereal magicians thread that's linked in the agenda as well as the EIP itself and that's James James if you want to just kind of briefly explain that and ask for feedback okay so the AIP is pretty long but this

specification is itself is pretty short so it it's just saying that you have an arbitrary byte array addition added to each block which is just the previous block verifications and a new transaction you could add a hash of the previous block verifications with access whether the address of the client has verified the transaction and in order to make sure that the client is legitimate they could be included in an access list

and you could check that the address this provider is in the access list in order to check that it's legitimate so that's essentially it however there are complications with implementing the access list in order to do it in a trust las' way so there's a number of proposals to do that however they all have difficulties with them so I mean they could be done but they might not be ideal so yeah I also initially had a proposal included to reward for

modes but I decided to remove that because Casper is going to the incentivizing of validation Kasper FSG so when that concert we won't really need to advise our full notes for verification however there would still be any incentives for relaying with bandwidth or downloading as well as storing stay in data so that would still need to be incentivized in proposals have been made elsewhere on that which is dick thousand eight so yeah if anyone has any questions yeah feel free to ask that yeah there's there's more details

than eight yeah does anyone have any questions or comments right now or yeah I have one question so I haven't dug into this so maybe what I'm going to ask is really stupid so if you are including any metadata in the blocks which aren't part of consensus aren't verified then let's suppose that parrot we have a block which has a metadata that for example parity verified it or whatever whichever parity notes verified it and then I'm going to be an and release a new version of death which simply strips these out

before forwarding to the network now of course what happens in this case ah sorry yeah I I'm not sure if this LAN sauce but let me know but it says when a client verifies that a previous block is valid and that's according to the valid valid DT definition in the yellow paper then so that not yellow paper is a specification for all common clients so that will determine whether a block is valid acquainted census rules so if if guess released a new release that had some it would need to make sure it you know complies with communist what I'm doing I would so what I'm saying is that

if you are tracking the accounting of which client verified which blocks then all other clients in the network so there's no incentive for other clients actually forward this metadata discounting info so everyone has sent out this info and forward the block themselves only sure sure yes so I mean obviously you want multiple clients not just one client to be verifying book and I believe guess the previous block verification is an arbitrary array any client could include that they verified it so it's it's you know any any node is verifying it and it would insert the address of the client of that node that is verified it I'm a

Trinity node I'm the first person that a newly mind block form ago etherium node was broadcast to an i-strip out their verification info and then forward the block on to other people and will that still be a valid block no no I say so because you're just inserting that you and verified block I to that a pre this block so it's just like linkie putting the ball cash to say that you verified it and this is in a future block you say the part of the block cash so when you verify a block you're

inserting that that you have verified in a few in the future block you would insert the the book hash of block the either verified well okay my Danny that basically depends on minors goodwill to insert these stuff into the blocks so let's suppose that if Trinity verifies all the blocks then why should I go in through either even mention that Trinity verified it is trying to break it here now yeah I understand so Peter mentioned earlier that there will be an invitation

to run full notes once you can monetize on less clients but that's not neither here nor there regarding the EEP itself I still think it's a little thin on actual technical data but but it's I mean it's mostly a lot of discussion and yeah discussion about I think and it's very brief briefly about the actual technical implication what what is hashed and who does what kind of so I still think it's bit early to actually discuss this with a pin a quart of cold okay just another minor addition to it so so plastic for

example we have to go to incentivize running full nodes we have basically two problems one of them are live clients which are obviously Qing the network those joint is working on a few monetization schemes I won't go into that and the other is running basically just running a full load without serving life clients that's also still handsome because you are wasting your bandwidth to have the network and for example what it's really really hard to solve this problem because it's really hard to fake that you verify the block or that you indeed uploaded one gigabyte of traffic to whoever wanted to join the network but maybe maybe swarm is actually the direction where we want to take this so

if the reason of being of swarm would be to share data and to be able to run a tit for tat for the call essentially as long as you upload approximately the same amount of data if you don't care and if you down more then you need to somehow make amends so what I was saying is that maybe that would be actually a nice approach to solve this problem altogether without having to come up with yet without basically without having to reinvent swarm on a top of if you're in protocol right yeah you could also have trouve it to use interactive verification as well but that's more suitable for blocks transactions that

have gas limit yeah okay great so it sounds like we'll flush this out more in the theory Magicians thread and try to get some more technical details in there to kind of spruce it up a little bit but yeah thanks for bringing this topic James and is that pretty much is that good for now yeah you know that's that's fine yeah okay perfect so next we have VIP 10:57 prague pal programmatic proof-of-work its Britain by radix PI and then if def else if def else are three people who are

working on it and they've actually joined us in the call so a few three want to just at least one of you mainly talk about what this is a little bit about how it works and the goal of this pick is not to decide exactly like if this is going in or not but this is a really good way to kind of either replace the current proof-of-work scheme or have as a backup if we ever need to replace the current proof-of-work scheme so at the very end of the topic I'm gonna kind of just query the core devs and see if anyone has changed their mind with regard to having a strong opinion on implementing this now or waiting till Caspar gets implemented and not changing

the proof-of-work algorithm so to start if you all could just introduce what this is and what you guys are doing sure can you guys hear me okay first and foremost yes we can okay so no pressure so proof of work is a new proof of work algorithm that's designed to close the efficiency gap available to specialized Asics so in the current implementation of etherium and ASIC it can get a potential for two times speed-up and this is because a large portion of the actual programmable hardware in this case a GPU card is not used so what type

proof of work does is it starts utilizing more of the GPU part it utilizes specifically engages more of the core and in doing so it means that specialized hardware is not able to gain its large efficiency speed off so we have taken great lengths to ensure that implementation of this is as easy as possible we've already got the minor implementation up and running on our github it's public and ready for review we've also started with the first client see yes Alex someone shouldn't link it

to you we've already started with the C++ client it's already committed as well and our goal is to ensure that all of the clients see more ethereum are already done with sites with the work implemented so that the ethereum developers do not have to spend any development time or effort on the implementation just the testing I want to introduce deaf and else these two are hardware engineers that have been worked by mining projects in the past specifically else I'd like you to go through a brief technical description of proof of work and how it works for the end-user and how we close that efficiency again so if you could

talk about five tunable parameters yeah so basically the current patch isn't so much a proof-of-work as it's a proof of devan bandwidth that all the algorithm really requires is a large amount of D vamp a store the Dagon and then high bandwidth access to that dag so a specialized ASIC can be made for that by basically removing the majority of the ASIC and only having the frame buffer interface the algorithm that we developed takes the e patch as the base but then adds using the register file

high high throughput math and caches so that any ASIC that implements this also needs to implement those and once you've implemented all of those you've basically implemented a full GPU so any implementation is going to be almost through the level of a GPU okay so my main queries right now at the developers meeting would be what barriers do you see for adoption of proof of work and I will tell you what has been referenced to me on my side the major arguments

have been that we're not seeing enough adoption by both stakeholders and developers and this I believe is an educational issue that we are working on so we need to educate the public more on why this is so important for the gentle transition of Casper FFG into the hybrid model and also the other statement we've been given is that it would basically add too much work for the developers which were doing our best to help out with by making sure all the implementation is already done so yeah does anybody have any comments on basically what was just presented any

questions yes I have a question with regard to well actually two two issues that you may or may not have thought about so that means that for example as far as I know ET hash on CPP theorem only is an only little-endian implementation and we actually had to ream from and the whole thing in go for to be able to run ET hash on top of big andean system side mix and whatnot this do not affect you probably not just saying that it's probably something you need to take care of or take care with the other interesting issue is that I'm not sure how your algorithm will scale

to mobile use because currently surrounds ET hash if you want to mind a tag you if you want to mind a block I mean you generate a 1 gigabyte + or - the byte right I don't know the exact number how large dag but in order to verify it you know you can do that only using a 40 megabyte verification cache now the issue is that this verification cache is insanely expensive already on mobile phones so it takes a fairly modern mobile phone a few minutes to generate it and the question is that if you introduce a new proof of work mechanism that on top of the memory thing also adds a city overhead then how does that impact verification performance especially on low power

devices sure so let me just address your first question we are working on the go implementation next we're hoping that this should be rolled out this week so again we are taking on the implementation work ourselves and ensuring that there's nothing the developers of the etherion community you need to do I will turn to death on how it sorry mr. Ellis on how it scales through mobiles so mr. Ellis take it from them so for the verification side calculating some of the cash the bag entries that need to be used that's extremely expensive it's a couple thousand instructions so adding

to every loop we're only adding about thirty instructions the randomized instructions that's going to basically be in the noise compared to generating the dag data that you need like now the parameters end up generating twice as much dag data we could tune that so that it the same amount of dag data needs to be generated so the verification times will be approximately the same sure think so I'm I'm more as brought this up so that you are aware that ETH is already problematic on mobile so it's just the thing let's try not to make it

lot worse okay yeah we can definitely turn it so that it's approximately the same yeah yeah so I have a comment on mobile to but maybe Paul was about to say the same thing so it's not the same but I started fixing Indian s in cpp implementation and also I wanted to optimize like loading so in in the end it ended to be a separate project and it has endianness correct correct and and also like for for Peters information the the de cash generation the small cash

generation takes around half a second I haven't benchmark on mobile as but if that's something like it's something performance critical we can compare numbers and half a second on a mobile phone no it's not on mobile oh yeah that's so basically generating the cash ongoing theorem takes it's really really fast but a mobile phone it takes three minutes okay okay yeah I can I can start playing panting that mobile as well if not something does this critical yeah I just wanted to do ya do inform that there's like the site implementation of

you fresh if that helps and we want to actually use it in I think in theory andreas to switch from from the old library okay Alex do you have something yeah I did I apologize that I couldn't actually find my notes on this but I do really I like the proof of work proposal although I I really am not sure if it carries the same properties due to the FMV function so it says validity is outside of my expertise however I noticed when when we when we initially

adopted it and I'm curious if this was noticed by mister miss if mister elf's and anyways so you might look into I believe that the like client dag generation is actually somewhat redundant in that basically the this the property of this protocol is maxing out the sort of the like you said the DRAM on the GPU and I recognize that and when when we were looking at like that the

hardware performance because we we noticed there was also like difference between nvidia and AMD and stuff like that so the point is is that I think that the fewer fewer cycles are required or the white client dag and the effect is the same so you know in other words like the the the protocol I think can be tuned to where the light client has like 128 less sha-3 cycles or something like that per one of the cycles I can't remember but I would encourage looking

into that because that might actually if if you reduce that that might compensate for the addition of the math operations so I wanted to point that out and then also ask if the protocol has the same security properties as far as it being a cyclic and and quickly verifiable on the on the light client I think that that's assumed but I'm curious if there's any information on research or research on how the random mathematic operations for each dag or whatever if that reduces the security properties of the graph so the

the basic structure is the same as etherium the existing eve hash and there's an array of basically register file elements that are calculated one of them acts exactly like the existing eath has implemented that it loads of and m value from the dag updates its value and then goes on to load the next value there just happens to be a bunch more happening in parallel so even if you somehow have a security weakness due to the random math that's happening in parallel the main load is going to give

you the same security guarantees as you have with today's ETF got it and and did you by chance run into the a quick note by the way on the redundant DAG generation cycles what actually happened at the time is that everything had everything was ready to go and we'd already launched Olympic and we were kind of ready to launch the main that so it like like nobody wanted to go and and refactor that out so I'd be curious if you post on github somewhere if if if you look into that it would be great if that small bit of redundancy was was

optimized even you know even if it's not adopted by aetherium or something I think it's a really useful portal culture for general use cases yeah I haven't looked into the back history on that but we can definitely look into how they're like type implementation is cool are there other comments or questions yeah I had a comment another aspect about these proof-of-work proposals that I don't see often mentioned as verifying them in contracts so with eat hash we have some efficient ways to verify eath had you know POC

headers in contracts and that enables cross chain atomic you know transactions or you know cross chain relays or bridges or however you call them and you know where as you know in contrast to like dogecoin like coins s script hash function there's no efficient way to do that in a contracts or requires you know really fancy things like true 'but in order to do a you know an ether to postpone relay and so if you know if a different proof

of work algorithm was adopted on the main net well for one it would it would break all existing contracts that do that do relays and and I guess I would suggest you know a solidity implementation as well of verifying you know headers that would use you know this alternative proof of work no algorithm and that's it cool so any any other feedback or comments especially

based on Casey's comment we were not aware that proof of work would break the relay contracts so definitely we can work on a solidity implementation can Rob to fix this if you're looking at an example of a an ethereal base chain to aetherium base chain real a look at Lulu's piece relay its aetherium classic to aetherium and i don't even think it's in use right now I think it was a proof of concept but that's an example of verifying etherium style headers and a different ethereum blockchain if I recall correctly and then another one would be the Doge ether relay that uses

true--but I'm not sure if that actually uses headers or not I haven't looked at it closely enough but I can send you the link to that and that that can that might help you some sure so we'll definitely take a look at that um I just wanted to address that the the key message for why we are pushing this and why why we are so motivated for this is that while Kasper FFG will provide finality and secure security during the hybrid period there are still proof of work owner abilities specifically censorship attacks where from that can be accomplished by a six which we've already identified our running and

this can all be mitigated by a proof-of-work so later today we will have more of a complete statement on this attack a detailed basically explanation of the attack and this is our main motivation for proof of work we want to ensure that proof of stake has its best chance for adoption by giving up this transition period giving the transition period a fighting chance ok great explanation thank you anybody else have comments I just want to in a general sense this the attack is a proof-of-work general weakness that relates to what happens when the block

rewards are reduced and you basically reduce the security of proof-of-work it's not specific to Asics anyone who owns basically more hash rate would be able to perform this in attack okay sounds good that separates it that separates it from some of the ongoing discussion about ASIC resistance for sure Danny did you have a comment oh I think I don't know that that attack ends up being a lot more limited by the finality I know you might be maybe detailing something later today that has to do with censoring these actually the transactions but I will say I'm I am

kind of from from this is not the entire caspere team I'm not sure what everyone's opinions are but I do think that you know if there is a easy switch to make it make this thing potentially more ASIC resistant if that's this new algorithm or just tuning the eath hash parameters for the time being I'm generally in favor of it because I think that it does give us just more runway to make the switch in a were conservative fashion but it's my two cents well thanks Danny anybody else yeah we hear that we are definitely as this if said working on

trying to make this as painless as possible and furthermore we agree that it doesn't change the finality behavior and finality is a good thing and this is totally independent of the the there's there's no weaknesses to the proof of stake side of Casper of course we all look forward to seeing that to be adopted as quickly as possible just to be a little bit careful about what happens to reward reductions to the security of this proof-of-work part and in terms of the proof-of-work part as a general attack censoring means also that

you can hold the network hostage with a 51% where you don't allow any other transactions through accept the attackers Brax okay thank you for that anybody else have anything okay if def else or def else--if or whatever order I'm supposed to say it in thank y'all so much for stopping by and explaining prog Pao it sounds like a really technically interesting project there so the next agenda topic is gonna be let me see here EW 210 block hash refactoring Martin put

a note up it says see this summary document and the agenda if you refresh the page on item 6 and that kind of gives an overview of it but Martin can also go through and explain it again a little bit so Martin go right ahead Martin kid we can't hear you can you hear us you're unmuted on zoom are you muted on their local microphone oh he hears us okay he's fixing it see ya while that's happening if y'all want to

open the summary document that would be nice because it gives a really good overview I looked it over right before this happened okay we can move on to a I P 1051 number seven and then go back to six afterwards once Martin gets this stuff fixed Nick are you on still yes I am wonderful I think this is your topic right yes so

this is really raised before there are some technical details to work out and some interesting points being raised on the magicians forum about whether this should be prep you know like a flag and and track operation or a flag that's cleared or you know what the best implementation is but the reason I wants to add it to the agenda was to get a general gist for what kinds of pointers think of overflow checking in general my view is that the vast majority of math operations want to be overflow protected or differently use cases for overflow in math in the EVM but most people are working with the assumption of the won't

be others and presently you have to code around that explicitly it significant additional runtime cost so I think it would be useful to add a backwards compatible way to support overflow checking in the EVM that lowers the costs to clients and makes it more practical and more secure to do so so I'm curious what behind teams thinking I can't speak for everyone on the team but personally I believe that this is a good change in something that will help developers and prevent them from shooting themselves in the foot which is

always good so Nick would this negate the need for safe math like stuff fishing assuming that solidity implemented support for the new write operations then yes it would okay I mean to be they are solid as he could implement support for overflow predicted mass right now but it would be doing effectively the same thing went safe math does it would still be a significant performance impact right and Piper does have it and if they we had native opcodes I'm sure they'd move to the more efficient implementation anybody else had comments basically like

solidity or Viper to take advantage of this it's gonna add like some level of constant overhead to each use of the like ads it depends on how your implementation is doing to 36 but at the moment some implementations will be able to detect overflown trivially because it's already available to them and they just throw it away others will have to do extra work I guess maybe even a more specific question is basically that in order to do a check on an operation the at least like previous check has to have happened to make sure that the flag has been reset is that am I reading that

correctly yeah so you would have to each written as an alternative to all the plagues register with the flags for that operation and another kind of naive question would we be able to get rid of that overhead by changing the add subtract and multiply out codes to reset the flag on entrance so personally so if you use a trap mechanism then you can simply if you have an overflow you jump to a trabber drinks and you don't need the flag but if you're using a Flags mechanism then resetting the flag on entrance and seems to it wouldn't be any more efficient and it seems to me that it would kind of void some of the

purpose of having a flag because the idea is that you can do a whole basic block with operations and then afterwards check whether any overflows occurred which means you only really want a block that's because I was missing thank you Paul did you have a question or comment yes also from the implementation of arbitrary-precision integers and I think it's it's quite quite easy with its small penalty after detecting unassigned andhra flows but i don't rub out the signed overflows actually and how would you like to distinguish them in in EVM

where it's not so obvious which operation is is meant to be for signed addition or when which one is meant to be for unsigned one so the idea is that the the EVM instruction is set the signed overflow flag if there was an overflow assuming the values assigned and then the code that's running in the users with yeah but does it mean you you have you would like to have two flags for assigned overflow in for unsigned overflow yes I'm not sure actually if you do like regular arbitrary-precision

implementation you mostly do it using unsigned numbers and then you try to incorporate sign later on so sorry I'm not so sure it's so easy to actually get the signed overflow information doing it this way maybe there's like the way to actually transform the results after it but yeah it's like it's not obvious to me at this moment how to do it if your number is represented in two's complement then there are very simple rules for checking the sign that the input operands and the output to determine whether an overflow occurred

okay okay thank you just wondering with you is USM I know it counts for metering I think the change is some pro quo it's great but I'm just wondering it's like he wasn't has built-in metering right so does that kind of negate the need for having these kind of changes to gas costs for optimization or at least with these kind of changes still be helpful with rehab he was in production I I think he was on beautif to ask me he wasn't aim if yeah I will I wouldn't add

instructions to he was and specifically for that doesn't already have it and if it already has it then we could use those right yeah I mean I was thinking more in general like general ID not just like Overflow checking but more just general changes to gas costs if they would be necessary if we have a loss them that can do media inc to to determine the gas cost space on the metering yeah okay anybody else have comments on this okay so yeah I I guess I'm curious just for is here there's

anyone from the gift team here Martin it was just curious okay I'm just curious what you think of implementing it in gates given the current operations it would be or do you think it will impose a significant additional burden I would have to investigate that and get back to you okay I know that there are some slight challenges for example with with division I know that or exponentiation I

think yeah an exponentiation it has some it's based on some special algorithm that kind of assumes that if you can randomly cut off anything above 200 256 so yeah I can't answer this question up hey would you take over and all that over and chat I just sketched out the change to the C++ multiply operator I repeated a line at the stop start of the second part but basically I'd have I would have to cast one of the operands up to 512 so I could get a 512 bit

product that I have to check whether the product is bigger than the overflow value and trap if I'm not going to trap that I have to cast the product back down to 256 bits so it seems a significant amount of extra work and that extra code will have to be added to every arithmetic operation there also like double or triple the cost relatively to the others so they leave a precision math library are using it has

256 bit lemons and no support for employed in yeah you can't get at any overflow flag but it doesn't have are you have to get the limbs how bigger the what the individual woods in the arbitrary position may be as big as you want so that's that's why I can use a 512 bit word Tober flow into dan shak whether it got too big why does it need to be 512 bits most most bignum libraries have smaller limbs than they and they would just add one an extra one stroll in for another flood this is a multiplication so it can it can flow

bigger than that oh sorry this is this is just for multiplication yeah addition you only need you know need you a little bit more but okay how you currently multiplying with 36 bit output I'd have to look inside I believe the library just sort of up automatically masks off the over blow okay so but the library masks it out but there's no way to you've no way to get a bit shorter modifying the library is that right well I just tailed library to use a wider word denizens is already doing that multiplication work yeah okay okay so it

sounds like there might need to be a little more investigation into the cost of this between the clients well we have a lot of clients using a lot of different libraries and the libraries vary and in what they expose yeah so what's the best way to accomplish this I wonder casting yeah for me was him he from you know with me during if that would help from if I would render these kind of changes like not necessary sounds like it could be complicated

different clients yeah I'm just speculating you're not sure I follow we're metering comes into it I mean if this kind of change is irrelevant to he was in many ways because we'll be yep using their up codes not ours so I'm not sure can you elaborate on my nature in his relevant so as I understand it um metering he can use two meter how much computation is done for its convocation not storage memory loads and stores and hymns and loads but yeah I understand he's great he was long but I have read the spec and I just thought

that the hats with metering you would know you'd be able to measure how much computation is done so that you can then see you don't need to play around with the gas costs in India so much sorry you think humans Asian I think you're thinking that we later in the agenda about changing crystals so your store we're talking about the for supporting overflows okay yeah I understand that yeah so Peter did you have a comment or Piper can just be done rather than having to deal with much higher scale

numbers essentially doing an inverse check that think now the division is very expensive - yeah all right either way this seems like a positive thing and while we might have some concerns about the overhead it adds to a you know some commonly used op codes seems like something that might be worth implementing especially since languages are kind of already pushing the stuff in in the first place and adding overhead to their contract code I don't know I'm I'm I thought about this a lot so that's kind of just a gut reaction so can like

Greg mentioned testing is probably the best way to do this can that be accomplished for some of the main clients is anyone interested in doing that I think I think maybe the best thing this initial state would be to ask for somebody from each client in the nixel coordinates to say whether it did to have a quick look in say whether they think it's necessary whether they think it will be an undue burden to implement in terms of efficiency or developer time because as Greg pointed out here there's a lot of different implementations out there for the big no myth I'm I started working on

custom implementation of betrayal' precision for C++ I know also the Martinus has similar idea for forego so I can take a look there and see if how intros if it would be to actually extract this information out of it okay so okay that sounds good so we have a next step that we're going to be doing with that is that good Nick will go on to the next agenda sounds good cool let's go back to six-block hash refactoring martin is your mic fixed up or did he leave again yeah he's not on

here anymore okay well table six until Martin either gets back or until another time the next one is e IP 1052 xcode hash opcode that is Nick yes so this one's even a straightforward there's an increasing number of use cases where on chain a contract wants to know what the code what the whether the code of another contract matches known template in order to to do various things such as trusted uncertain implementations and so on

presently they have to fetch the entire code into memory and inertia and in throw it away which is a ways to guess and we already have this information in the EVM so I'm just proposing a very simple opcode that pushes the write the data hash of another contracts to the stack on the surface this seems good it seems like this would encourage languages like solidity that include and the extra like I think they include a swarm hash of some information in the contract by code which would sort of well it I guess it

already makes this problematic if you're checking into the full code it seems like it would discourage that practice even more but in general it seems positive I I would I would agree with that I it would be great if somebody could do some asking around as to why this wasn't in there to begin with but it would be really great to have this it it uses a ton of gas and it seems like a really useful operator for welfare for some of the projects that

I've I've seen people working on recently so for what wasn't included originally and I think it was just an oversight any insight yeah from from the VM perspective it's also very useful information and it's one of some of the informations I care about it it's used to actually have unique and identifiers for executive code so for example in EVM see this information is already available to VMs so it wouldn't be very problematic to expose that to contracts as well yeah and it's also like really fresh it it it's already loaded in

storage if you've already hit that the code so there's it's it's almost no cost to actually implement that and probably probably only a couple lines of code and most of the clients that was my guess as well and I think we should probably price it the same is the base cost of extra copy because if you haven't touched a contract it will require loading it but they would still be a big improvement over the current solution for getting there she yeah I'm not sure it would be this is s code cuts code copy based purely on the bite size returned or is there an initial gas cost on that I

believe it has a base cost and an additional cost per bite but I'm just looking it up right now it should be like the same cost is like checking the balance yes much to Xcode 5 which is actually seven hundred thousand words exactly yeah so I think we should just make it Oh Xcode sighs like Pavel said which is seven hundred right which is so so with me in the white paper Expo copiers described as the cost of an Xcode plus

the cost of a copy times the number of words and X was the other one Xcode is the cost of its code so what do you think our next steps on this one Nick I I think it's reasonably well specified right now and reasonably straightforward so really just to see whether I mean whether we can move to accepted and this would be something that could be implemented without a hard fork because it's at the VM level right no would have to be add four because it introduces a new opcode the next okay you know what there would be good to do

together with the way I eat with the IP 210 I don't know maybe I don't know what the status of things are but if if 210 goes through because that also ABS that that adds an opcode yeah we're actually Marcus back now so he's can talk about German Oh yep we could hear you nice yeah so actually here Peter 10 does not happen of course however so I don't know if you guys sorry it sort of changes the right course in the EVM yeah yeah virtually changes it have it have the hack and B note up so a couple of problems with how

it's written right now I divided it into two so the intent and it would have been good if victaulic was on the call so I don't know if we can solve this now or maybe we'll have to talk about it next time the intent was to not change the semantics of the OP code block cache so the OP code block cache would still return only the last 256 hashes that's what he wanted however as it is specified and as it is written in the contract the contract doesn't care if you ask about the only the most recent where if you ask about older stuff so as it's written it would be the same thing basically if I do

block hash on a very old book or if I actually call the contract way back so one alternative is to do it as vitalik wanted from the beginning to modify it to make it clear that when you call it when you do the block hash up code you only get the latest 256 and in that version it doesn't change anything on the block hash opcode semantics so the clients would actually not need to do any changes for that or code the only thing that would be required would be to increase the Gaskell's for it however that would mean that in order

to get more useful information people would have to call it and it would maybe be nice to add for an ABI encoding or decoding to it so that you could just yeah call it nicely the second alternative is to have the e as written that would change the baka semantics because you could reach further back yeah I don't know that makes it kind of why would I ever ever call it if the block hash exists like that and then the second issue it's not really an issue

it's a question should we add support to get obtained at the Genesis hash from this contractor absolutely a nice thing nice thing and yeah it complicates a little bit because we need to show it in there during contact creation but it's probably a nice thing to have in the future Paul you added another point point D on this that there's an one bug with it is that if you invoke it at block one sorry if you do right then you're going to understood

that's basically the problem so what that affects mainly test cases that execute it I see okay and power what was the other issue about sign-in to yours I didn't really oh yes oh so the current the current contract is implemented the serpent and serpent only has signed signed integers I believe it's hard to I mean I had to guess that but it looks like from from the behavior I get from from writing unit tests so so there was some some comparison in inside the code

that does it actually accounted for it and so you can you can overflow this comparison and you get some unspecified results I mean they are specified but it's not what you want it intentionally so this another check needed in the serpent because to check if there if the argument from the call it's not- hmm so there's a break where that fixes these two issues I can to continue working on writing unit tests it's not clear it's the unit tests

should go to the AI piece repository or or it has to be on the side somewhere but it's I think it's it's minor issue to figure out and okay it's so I wanted to actually add more unit tests to make sure it works as specified and and then I would think about like optimizing the the contract with something using maybe solidity assembly or something like that it's not it's not mandatory to do that but having unit tests it's quite easy to test if the result of the same mm and

the costs are lower so that's that's one thing and commenting of commenting on Martin's propositions I would go with their with their first first alternative version when we don't modify block hash-table code that's one thing and I don't want to give a lot of arguments for it it seems just safer and second thing is about the Genesis block and block hash so actually this this back with with with at block one means he wanted to

insert the hash of their Genesis actually and I believe there is a generic solution for it which I would try quickly explain but it's not so so so easy to to do on the call and so so mostly instead of replacing some some stored value you can actually move them like to different storage location in this in this way you will keep all the information all the time about some

specific blocks so we never override some important information and the block the block number zero it's it's like meet solder or this all these requirements being division by by some some multiplication of two five six so in case so we can I believe you can you can change a bit the logic of how how you store information in this in this way so if you would run this contract from from the block block zero from the block one you will you will have this information about about block zero all the time like this is like abstract solution for that and how and and the second part of

the solution would be to actually also insert the mythic information and deploy time so we can actually have all this required information also on the main eight so that would somehow solve that determines this hash problem but I think it's it's quite complex comparing where what we have right now in the contract I mean I haven't finished the prototype of the implementation it seems it requires recursive because of functions or something like that maybe can be flattened down later on and it's really

good at auguries so I cannot do it very quickly but that that would be one of the solutions to to this block hash and also it might be a bit problematic to actually insert all this block hashes on the on the time of the hard work but I love her good property of that solution is in the smart contracts you can you can assume the information about historic blocks are already there according to the specification you don't have to account also the hard work number - - in your contracts to actually to actually

compensate this this lack of information because this change was introduced in the middle of the of the may not not in the beginning ok let's summarize that in two parts of the EIP discussion and I think that the PR that you opened I think it was ten fifty seven no way what was it ten ninety four is appropriate to include fixes for VIP 210 but we might also take those comments to EIP 210 itself so that it's kind of kept up with by everybody or at least linked to the PR great so does that kind of cover most of your e

IP 210 stuff Martin yeah I'm fine with going with the original intent I would like nicer ABI and I would also like the Genesis lookup and I think it could be done pretty easily if we don't go with some more generic approach and add a lot of my own law caches on the way of Genesis okay sounds good it looks like we are pretty much out of time so Nick and Greg I'm gonna have to move your items to the next core dev meeting the EIP 1087 and the concern for using native browser vm's while running ewaz

them so I will move those to the next meeting sorry we couldn't get to them today and otherwise we'll see everybody in two weeks I'll also kind of if you go to the etherium slash p.m. repo I've wrote up what the Cornett meetings are about the purpose who can join how to add agenda items stuff like that and then I'm also gonna elaborate further in either a blog post or a reddit post or something about some of the changes that are going to be happening to the core dev meetings particularly specifying how they're gonna be more technical in nature and have less philosophical discussion and things like that to kind of help save time and not have it be the core devs

deciding everything in the ecosystem because that's not really what we're after here it's more to figure out core core development low-level protocol issues rather than high-level issues and contentious community debate so yeah we'll talk about that more next time thanks everybody for showing up and we'll see you in two weeks goodbye thank you very much [Music] [Music]