With Constantinople fork coming closer, listing all EIPs to be included is a priority for the Ethereum Core Developers. In latest Core Devs meeting, the discussion was more focused on streamlining the process of merging of EIPs and about the EIPs proposed to be included in the fork.Ethereum Core Devs Meeting #33 [02/09/18]
Important updates
Piper suggested to look at how team PyEVM runs the consensus tests over JSON RPC to which Yoichi replied that he will discuss with Dimitry about it.
EIP 867 provides a standardized format for Ethereum Recovery Proposals (ERPs), which relate to recovery of certain classes of lost funds. The discussion is around merging EIP 867.
Dan Phifer provided history of EIP 867- This is the result of conversation on Ether recovery channels on the economy affected by Parity Multisig issue. In the context of the original solution put forward by Parity that have suggested some EVM modification model, the big difficulty with that is, it would affect the contract that were already out there. There may be some ways to mitigate that but, it looked like there were lot of potential for unattended consequences with those EVM changes. So, the conversation on Ether Recovery channel focused on the irregular state change. In that, its something that can be well defined and happened in a single block. The chances of unattended consequences block because of that particular change, are smaller. There are some other things that could help with some additional verification.In the proposal to EIP 867, it is very clear what could be the types of cases that could be addressed; specifically, where there is no contesting the ownership of the fund. If we could narrow down the small set of cases like Parity Multisig, we could handle them. Proposal as in form of draft hasn't happened yet but we are making progress in that direction. There are certain concerns about costs, maintainability, handling ERP requests. He thinks funding and resourcing are easy problems to be solved considering the amount of funds stuck, nearly half billion dollars. Lot of proposals are introduced to discuss how to reduce risks. To scrutinize the types of proposals to be included for consideration, some set of extra bars are proposed. It has to be taken forward as EIP as per the process.On EIP merging process, Hudson said that EIP 1 needs to be updated to get clarity on what gets merged, how it gets merged. The EIP process was initially left vague and was pretty much the copy of BIP (Bitcoin Improvement Proposal). It has been updated according to Ethereum's need such as adding ERC's as a subtype to the EIP's to be approved. There is also a path that EIP takes from draft to acceptance. Getting merged to a repository happens more on the discretion of the editors, and there is no time line as such. There isn't set process now on how things get merged; however, there is going to be a more clear process soon.His recommendation on EIP 867 would be to not merge till the process is decided. The priority is to make the process clear. They are also working on listing EIPs at a place like website for the readers to understand without the knowledge of GitHub. There are a few EIPs which came up before EIP 867 and are still in process, alsoAlex suggested that, it is better that ERCs should be well tested and implemented before it is actually merged because it helps set correct standards and avoids controversy. Even ERC 20 took its time and was very well written before merging.In Piper's opinion, initially merging things as draft is fine when met with minimal standards, and continue with the conversation in a separate call request. It would make a lot easier to pick out the things that have changed from the original draft, as it's a lot smaller set of changes. It might also facilitate the tweeking discussion that has to happen for minor rule changes, small changes to the EIP. So, merging things prior to then being accepted for implementation seems fine and will still have pretty good form for continuing discussion just through a secondary pull request that modifies the EIP, even if the initial pull request is literally just changing the status to accepted. At which point, the discussion can continue there.
Yoichi added, if after discussion it is found as an abrupt idea, the status can be changed to rejected and recorded in the repository. Hudson further added that there is also status superseded. Example, if there is any token standard, there is discussion on whether it supersedes ERC 20 or it is just an alternate standard that then gets accepted to then used by whosoever wants to use it. There are lot of status to make things clear once a PR has been merged. It would be appropriate to discuss more when it gets more community support, may be in next core dev meeting, it can be discussed further.
Alexey suggested to have a public debate for merging of EIP 867. To which Hudson suggested, Ether Recovery Gitter channel, Reddit and Twitter would be better place to have debate. It could be debated on live video meeting, added Alexey and Hudson agreed. However, Piper seemed to think otherwise that live feed discussion can put people in spot and makes it more of a politician based things than just have a careful discussion about it. So keeping it in text based, asynchronous format is much fairer way to do a debate otherwise it will become a popularity contest.
Conclusion: EIP 867 will be left without being merged for now.
Discussion on some EIPs posted by Martin and the core dev channel with his understanding to be included and some other EIPs that could be included in the Constantinople.
a. EIP 145: Bitwise shifting instructions in EVM
Martin updated that there are test cases defined in the actual EIP and is implemented as Pull Request.For Byzantium, Yoichi and Dimitry maintained the spreadsheet of the testcases implemented. But after recent organizational changes, the documentation on how to make test cases is obsolete, informed Yoichi. Karalabe suggested to have more streamlined approach for test cases and also it could be discussed while discussing the RPC and make it easy for anyone to generate test cases. Yoichi agreed.The timeline for the hardfork and for Bitwise shifting test to appear in state test is not decided for now, said Hudson.
Conclusion: EIP 145 should be considered for Constantinople.
b. EIP 210: Blockhash refactoring
It is a system contract that reduces protocol complexity to process the BLOCKHASH opcode.
Martin explained the high level overview of EIP 210. This EIP says that at a certain port number, there will suddenly appears the contract and also specifies the code that will go in there, although that may change. Then afterwards, in each block this contract is called before enable transactions from some system address. The call data contains the previous blockhash. Once 256 block number has passed since the fork, invocation of the opcode blockhash will instead the call to this contract. This contract saves blockhashes in states instead of requiring the clients explicitly maintains this cache of last 256 blocks. There will be gas used if you call it, but when it is called by the system contract, then there will be no gas. The first transaction of every block should be free.
Hudson mentioned that on GitHub, chfast commented
This is not actual but just what chfast is proposing. The code version that needs to be used is still to be figured out. In general there is no controversy on this EIP, so this should be going in Constantinople.Conclusion: EIP 210 should be going in Constantinople.
c. EIP 168 & 169: Killing dust accounts
Gavin proposed EIP 168. Alexey summarized these EIPs. Basically they want an assessment of how much saving in disk space this change would bring. Team CPP has already did some analysis but it only covers the number of accounts which could be deleted or to a certain threshold of what considered to be dust and actually attach to the EIP. Alexy is working on the code that analyze how many nodes in the actual state tree would be removed at different threshold. He plans to post that graph for everybody to see that could help make more informed decision whether this EIP brings enough improvement to justify the implementation.
Karalabe informed that they had internal discussion about it and they believe that this EIP is interesting and problematic because the original proposal made by Gavin said that any account that has less than 420 Szabo (that would amount about 45 cents currently) should be deleted. This highlights the core issue in this EIP as how do you define a threshold which is a good enough threshold in future too? He thinks that the problem with this EIP is that it may or may not scale in future.Alex added that the original proposal made by Gavin was in Dec 2016 when ETH price was about $10 and 420 Szabo was less than a cent and right now it is 42 cents. Also, because it only uses accounts that never deletes contracts so it might encourage people to either create wallet that they didn't necessarily need to hold the small amount of money. It might even encourage behavior that people even use more disks space but those disks space is in contract and not in the account.
Hudson said that it may need some more analysis of the actual benefit of the clearing and also whether or not it is sustainable for future price movement etc that would potentially make that amount absorbent more or less valuable. At this point it is not going in Constantinople without analysis, concluded Hudson. However, Karalabe seems to think otherwise. In his opinion, it is a simple solution for a problem, its just it is important to know that it is not future proof solution and it should be discussed what the future will hold for this EIP.
Martin shared an interesting fact from the graph posted by Alexey that around 10 million accounts have zero balance. EIP 169 by Gavin discusses how to deals with account replay protection and has three different variances.
Conclusion: EIP 168 & 169 need further discussion.
d. EIP 859: Account abstraction for the main chain
It is created by Vitalik as an update about his previous EIP of Account abstraction. That EIP was based on the feedback he got from an ETH Research forum. Martin thinks that they need more people to read up the details about this, it is complex and would like to see some more discussion on this EIP.About implementation state of account abstraction, Martin explained that we are talking about different account abstraction. EIP 86 that allowed paying for stuff with token is even more complex.According to Alex, this EIP proposed by Vitalik is important but the way it is described is very technical and it makes it hard for outsiders (developers other than core devs) to contribute. So getting more feedback and a writeup on it might attract required attention and support from the community.Karalabe however doesn't agreed as he thinks that it was the main issue with original EIP 86 that many people wanted it, liked it but no one from client development team put the effort to actually develop it. So he suggested to try something that is technically feasible and then work on little bit else.Hudson said that it wouldn't be a complete waste of time to flush out this EIP even if this is not implemented in Constantinople.
Conclusion: EIP 859 needs lot more discussion.EIP repository will be updated based on the decision in the meeting about the EIPs to be considered for Constantinople.
This is originally published at EtherWorld.
For more updates, technical blogs and general discussion on Blockchain Technology, please Subscribe and follow us at Twitter, Facebook, Google+ and Medium.
