Ethereum is getting ready for next hardfork. In today's Ethereum Core Developer's meeting, other than regular update on testing and clients, they discussed on deferred EIP's to be included in Constantinople.

Ethereum Core Devs Meeting #32 [01/26/18]
- Video
- Agenda
- Important updates
  - New EIP will be written by Vitalik on PayGas to replace EIP 86
  - EIP 96 needs a little more collaboration to get more formal EIP till next core dev meeting.
  - EIP 145 is almost final and will be going in the hardfork.
  - EIP 169 / 170 will be discussed more in the next meeting

Testing

Yoichi - EWASM chain was using the same framework as consensus. Problem regarding user experience has been reported. Tim said that Yoichi can reach him for any help on user experience.
Swende - Regarding Hive testing, some restructuring done. Hoping to relaunch as soon as possible.
Dimitry - On one test optimization, he suggested that a few tests have been repeatedly tested fork after fork and that is wasting time so it's better that it should be removed to optimize testing time. Clients might not need to implement any changes as it will just remove some post dates from the tests. He plans to create a test on all these forks that specifies the spec section, so that when someone creates a test, it will specify on which fork this test will be executed.

Fork release managementAbout next hardfork Constantinople, what EIPs will be considered?

EIP 86 (Account Abstraction - Sharding)(Vitalik) - There will be a new opcode called PayGas. It will have two function:
(i) Paying for gas. It will have a buit in functionality to refund any unused gas at the end.
(ii) If a transaction is froze before the PayGas functionality has been called off at any point, then the transaction will be invalid. But if the transaction execution is froze after the PayGas opcode has been called, then the transaction is valid. The purpose of this is to find out if any execution before the PayGas opcode should be considered as part of basic verification. So, it would include things like nonces; in some cases it might include more things. If anything that comes after the PayGas opcode, is part of the full execution. The way it has that miner will generally work is every miner will have some threshold of gas, possibly 100,000 gas or something. At any time, they would keep a transaction; they would run the transaction execution for up to that amount of gas. If the PayGas opcode has been called, then the transaction will not be included but if it hasn't then it will be the end of the transaction. So, this is basically the substitution of pre-verification and false transaction execution.There is another discussion about having in-protocol nonces. In the context of sharding discussion, team is leaning towards not doing that but in another context, it will have much higher transition cost because it will move transaction to appear more than one time in the blockchain. So, in the main blockchain, it might make sense, but that could have a separate protocol verification mechanism.Benefits :
(a) Signature abstraction - You can use whatever signature scheme you want.
(b) Replay protection abstraction
(c) It makes pre-verification much more complex.The possible use case could be ICOs. Say, there is an ICO where 100,000 people wants to participate but there is cap that after first 20, 000 no one else can join. The status close will be all 100,000 transaction will go in but the last 80, 000 that basically turned into no ops will not have to pay up for gas fees.

Conclusion:New EIP will be written by Vitalik on PayGas to replace EIP 86.

EIP 96 - Initially, Vitalik doesn't have any strong opinion about including this in the Constantinople. He thought, it is of less importance for Casper as of now. Whereas Pawel shared his thought that it is more aligned with removing some features from internal EVM to external contract like some kind of pre-complied contract. It will make it lot more easier transfer contract. Vitalik then agreed it to be included in the upcoming hard fork. EWASM team also feels the same way, added Axic.

Piper - We are getting ready for apply transaction concepts in PyEVM. It is moving along quickly from sharding branch into the main branch.Conclusion:EIP 96 will need a little more collaboration to get more formal EIP till next core dev meeting.

EIP 145 (Bitwise Shifting instruction in the EVM) - Pawel informed that the EIP is ready for peer reviews. It also has gone CPP implementation ready except they need some way to configure the client to include this feature. So, it can either go in some fake Constantinople fork or can be some separate configuration. This is the only thing on list before start testing. Some more client implementation will be welcome. There is also support in Solidity for it , added Axic.

Karalabe requested to have expanded test cases for EIPs to cover generic usecases so that an implementor can check if it seems to work.Conclusion:EIP 145 is almost final and will be going in the hardfork.

EIP 169 / 170 (Account clean up) - Vitalik explained, one of them says that if the account balance drops below 21,000 times transaction gas price, then the account disappears. Other one says, when you create a new account, the initial nonce have to be something other than zero.

Conclusion:EIP 169 / 170 will be discussed more in the next meeting.Hudson - EIP timing is important to decide, implement and test; that will help on how much more time is left.

Client update

Geth - Karalabe - One of the current problem with Geth is that once you sync, you do a fast sync that consumes some disk space but afterwards, it acts as a full node. From that point onwards, you kind of act as an archive node and eventually your machine slows down. They are currently working to do an in-memory state pruning, so that they try to keep as much of junk in memory only and clean it out in-memory and only flush the disk periodically or if reaching critical memory disk or something like that. They have started benchmark on main net and it has reduced disks growth by about 80%.
Geth v1.8.0 will not GoEthereum speed up but it will actually prevent it from slowing down. With this user don't need to re-sync just so often, just 1/5th of the time. They also have separate pull request or POC experimentation for implement full garbage collection. In follow up work 190, he hopes to have full garbage collection implementation.
Team will wait for the full release.
Parity - Afri - Parity 1.9 is released. It is the fastest clients so far. Focus for next week is on light client development. They would also want to start implementing Casper testnet reports.
Harmony - Mkalinin - We have implemented our purest version of Casper Ware node. The node is able to sync with other clients in the hybrid consensus network.
Cpp Ethereum - Pawel - We have EWASM integrated, so it can run EWASM for VM smart contract.
Ethereum JS - Casey - No major updates on Ethereum JS, keeping up with maintenance.
PyEVM - Piper - Re-branded and calling the PyEthereum client as 'Trinity' going forward. Started with formula implementation on command line interface and working as fast as they can. Works on sharding and other merging going on.
TurboGeth - Alexey - Working on last optimization after that it is hopefully stable. Sync is faster, and they are trying to see if it could work as a client.

Research updateCasper and Sharding - Vitalik - Casper FFG - Aplha Casper FFG has been running for a few weeks. It hasn't been working too well as it keeps reconnecting and is not good enough to keep maintaining all by itself for another node. So it ended up requiring active maintenance in some firewall. They are ready to help other clients in the Casper testnet.

Sharding - A lot work has started. We are going to do sharding implementation on top of PyEVM. We are working on getting some changes for thigs like account access, account abstraction written into PyEVM. Spent a lot of time developing a new binary tree. The next thing actually be getting stateless client logic. Trying to get full node functionality working on test networks.

Yellow PaperYellow Paper has been placed under the Creative Commons Free Culture License CC-BY-SA. It is currently maintained by Nick Savers and with contributions from many people around the world.

Follow us at Twitter, Facebook, Google+, Steemit and Medium for more interesting stories. To receive weekly newsletter, subscribe here. Publish Press Release and list ICO at our website.

Topics