Ethereum is second best leading blockchains today with a value of about $ 82 per Ether and a market cap of more than $ 7.3 B. One of the key factors behind the success of Ethereum is its core development team.
Henry Ford once said,
“Coming together is a beginning; keeping together is progress; working together is success.”
Ethereum community is continuously putting efforts to make Ethereum platform stronger, safer and simpler to work with. To keep the entire team and world together on same page, they have Ethereum core developers meeting twice a month. Last 'All Core Devs: Meeting 14 ' took place on April 21, 2017. The meeting included discussion on various Ethereum Improvement Proposals (EIP) and Metropolis updates. The video and transcript of the meeting are available at GitHub.
Highlights of the meeting are
EIP 186: Reduce ETH issuance before proof-of-stake
The reward (issuance of Ether) is going to come down once Ethereum community will start the PoS switch. The difference between cutting it down to even to take the bottom end 2.5 and just pushing it all the way back up to 5 and in terms of Metropolis, it’s going to be something like 2-3 million Ether.
EIP86 (a.k.a EIP-208), there is a difference between the EIP pull-request and the implementations. Which should be fixed?
There are two ways to create contract, one of them is external and other one is with create opcode. So, part of the EIP accounts the scheme for addresses that get created externally gets changed. But as far as the create opcode, there can be two main reasons to change that -
• One of them is consistencies.
• Other is that the scheme works even if contracts are creating other contracts and not just the mechanism from the outside.
These implementations, these pull requests change the create instructions and they add a new create instructions.
After Metropolis, there will be three ways an address for new contract is generated.
- Create transactions: generates an address from the code hash
- Create opcode generated by ROP concatenating sender and nonce
- A new create instructions to generate it from.
EIP 98: removing medstate from receipts - go & cpp implemented option 2, Parity seems to have went with option 1
-
EIP 98 is the one which removes the intermediate state.
-
There are two options in EIP specifications
-
Removing the root hash altogether from their RLP structure
-
Replacement with zero hash Looking at the code, it was noticed that parity seems to modify RLP structure and go just replace it with zero hash.
- Team decided to remove it completely because it seems more cleaner and ready to deploy it.
EIP 96 is about blockchain and state root change, In this, the contract is inserted into the state when the transition happens and it changes the state root. Reasoning for making them separate is because these addresses for EIP 96 is not actually a real precompile; it’s just a prenode regular contract with a piece of prenode regular code that happens to have a privilege status in the protocol.
Metropolis testing and client implementation updates
-
For testing of EIPs for Metropolis - A file on Google Docs is available that is updated with test cases that are already implemented and are marked in green. To do list and status of other tasks are also available there.
-
Metropolis Clients implementations - Looking at the PR it looks like it’s almost done.
-
Parity - Mostly done, just one EIP that needs to be implemented on the return data.
-
Pythereum – Metropolis features implementation is started. The revert opcode is passing all the tests, there is implementation of EIP 86 although it is old so it may not be fully compliant with all the related stuff that team agreed on but that will be very easy to change once the test is there. EIP 96 and EIP 98 are theoretically implemented back when Vitalik was doing some experimentations for Casper, but it may be reparametrized a little bit. There are still couple of EIP those aren't done, so static calls are not done on them either.
-
Update on C++ - Progress are half the way through, three EIPs are still not started, three are implemented and merged.
-
Ethereum JS - It is a work in progress; team hasn't done any Metropolis related stuff so far except for one.
-
Block time - If Ethereum community gets out the fork by June 25, 2017 and hash power stays as it is now then block time will not go above 19s.
-
Timeline for Metropolis - There is still too much uncertainty to get on a hard date right now. Thats why development team decided to make no commitments and just to get stuff running and passing tests with medium – high priority. Once it gets clearer and get all closer towards it then they may agree to a date.
EIP 599: 'Valid until block' field for transactions
-
Nick suggested to add an optional field which specifies that the transaction must be mined before they stay in block. And any transaction whose block number is before the current block number is discarded as it may not be relied and any transactions whose include before block number is too far in the future should be treated as hostile and generally not relied.
-
The idea is in addition to make DAO attack harder also allows people to publish transaction they now believe be executed quickly or not at all good for operations.
-
The existing transactions will still be fine with this proposal. Nodes must accept the blocks that contains transactions with fa future time stamps or with block numbers and with no block numbers, they would generally try to avoid relying them.
-
Update the proposal according to EIP 232 for the next meeting.
Next meet is scheduled at Friday 5/5/17 at 14:00 UTC.
For more updates, technical blogs and general discussion on Blockchain Technology, Subscribe for weekly newsletter and follow us at Twitter, Facebook, Google+ and Medium. You can also reach us at contact@etherworld.co.
