A hotly anticipated change aimed at ridding ethereum of its bitcoin-inspired mining process is moving forward in testing, with the platform’s popular software clients now participating in review.
Following on an April software release that saw the idea formalized in code, the upgrade looks to transition the world’s second largest blockchain into a new way to keep those running its software in sync. However, the current iteration of the idea (called Casper FFG) finds ethereum’s developers proceeding with a plan that would enable both its new and old consensus algorithms to work together to protect the network from unexpected attack vectors that may arise during the transition.
Under the proposal, smart contracts will link miners that secure the network with a new set of participants called “validators.”
The code provides a way for mining to continue undisturbed by layering a smart contract on top of ethereum that allows users to bet on transaction histories in exchange for rewards. The smart contract also contains a “difficulty bomb,” which would (upon being enacted) propel an upgrade by making mining this iteration of the code more prohibitive over time.
According to the current block times, the difficulty bomb is expected to activate in about two years, at which time the new consensus method, proof-of-stake, is expected to launch – and ethereum will relinquish its mining layer entirely.
But while much of that has been in the project’s official roadmap, what’s new is that the smart contract in question is getting tested by Parity, the second largest ethereum software client. Plus, Geth, the largest ethereum software client by users, is getting closer to launching its implementation of the code on testnet.
“All of the major clients are working on implementation,” author of the Casper specification, Danny Ryan, said.
The forward momentum will come as a relief to many in the ethereum community who are upset by the recent release of specialized crypto mining hardware that some believe will disturb the platform’s distributed network of users.
And with the work going toward testing the smart contract – less than a year from when the Casper white paper was released – it seems clients are equally as interested in pushing proof-of-stake from concept to code.
Ryan told CoinDesk:
“Proof of stake has been on the roadmap since day zero. Our community is very excited to take the first step with this hybrid model and to follow it up with a full [proof-of-stake] implementation soon after.”
Critiquing the contract
And there’s reason for those backing the software to feel confident in their current approach.
For one, proponents argue releasing the code as a smart contract first reduces the complexity of the full proof-of-stake transition and creates a software-agnostic template for ethereum’s various software iterations, or clients, to build upon.
“The contract acts as a black box for much of the functionality and thus greatly reduces the complexity of the code that has to be replicated across clients,” Ryan said.
As client developers implement the spec, Ryan said, they’re likely to identify issues that can feed back into the initial code as well. Already an issue has been identified – a piece of code that could enable spam transactions.
Wei Tang, the developer leading Parity’s integration, told CoinDesk:
“The Casper research team is really open to those critiques.”
Tang added that his team has been proactively addressing problems as they come up, and said, “I think Casper research team, Geth, Parity and other implementations still need to work together to agree on and improve the specifications.”
As such, it’s a collaborative moment between Casper researchers and client developers, each working together to finalize the code.
Ryan echoed this, telling CoinDesk, “Formalizing the spec in EIP 1011 really opened contributions and development up to the entire community.”
According to Wei, Parity is using the testnet specification to test out network functionality, such as how voting happens and blocks are formed, in an effort to make sure the smart contract code behaves in conditions that mirror those of ethereum itself. Not only that, but Wei said, the testing is also about making sure the smart contract doesn’t conflict with the way ethereum clients are written.
And in these tests, Wei said, both the Parity and Geth teams have made good progress.
“I’m excited about Parity’s testnet,” Ryan told CoinDesk, “I believe they are the first client to get EIP 1011 implemented. As more clients implement, we will either have them join Parity’s net or we will coordinate a new testnet.”
Parity’s current testnet won’t be the only one, though.
“The current Parity Casper testnet is certainly not the last one,” Wei said, noting that the specification will have to be tested many times before it’s finally released to all users.
“Casper is a relatively big change to the consensus protocol, so we need to be careful, and there are also many parameters in specifications that need to be finalized.”
Ryan said similar things about not rushing the implementation, during an ethereum core developer call on June 1.
According to Ryan, the smart contract is unlikely to be launched alongside ethereum’s upcoming hard fork, Constantinople. Rather, Ryan continued, it’s important to have all ethereum clients testing the code in a shared testing environment before such decisions can be made.
“Parity’s done some great work and there’s some ongoing work with the side team with Geth, kind of putting all the pieces together and hopefully getting a testnet with more than just Parity up in the next few weeks,” he concluded.