Posted on

Testing for Ethereum's Coming Consensus Change Is Moving Ahead

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 to a new way to keep those running its software in sync. However, the current iteration of the idea (called Casper FFG) actually 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 bing 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 proposal 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 upset 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 are working together.

Ryan echoed this, saying, “Formalizing the spec in EIP 1011 really opened contributions and development up to the entire community.”

More testnets

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.

He continued:

“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.

Welding image via Shutterstock

The leader in blockchain news, CoinDesk is a media outlet that strives for the highest journalistic standards and abides by a strict set of editorial policies. CoinDesk is an independent operating subsidiary of Digital Currency Group, which invests in cryptocurrencies and blockchain startups.

Posted on

Ethereum's Top Developers Think A Blockchain Split Might Be Inevitable

Ethereum may be on the brink of a blockchain split.

At least, that was the mood at a meeting of top ethereum developers late last week where a discussion around a code proposal called EIP-999 led some to speculate that the creation of two competing blockchains is now a possibility. Indeed, it’s now believed the proposal, which which seeks a technical fix that would return $264 million in funds lost due to the error of their owners, is so contentious, a minority of users may chose to defect.

Those in favor of the proposal point to frequently lost ether due to buggy code, arguing that the platform should ensure against such mistaken losses. But on the other side, many warn that editing code after deployment could damage not only the security but also the integrity of the platform.

“It’s clear no matter where you stand that the issue is contentious enough that if it goes forward and implements then it will generate a contentious hard fork,” developer of ethereum’s Mist browser Alex Van de Sande, said during the dev meeting on April 20.

“It’s unavoidable that it will create a split,” he continued.

Spearheading the code change is Parity Technologies, the ethereum software company behind the wallet that was impacted by the fund freeze. Founded by ethereum co-founder Dr. Gavin Wood in 2015, Parity is the second most popular ethereum software, used by almost one-third of the network.

Speaking at the meeting, two representatives from Parity, communications officer Afri Schoedon and co-founder and CEO of the company Jutta Steiner, urged client developers to move forward with EIP-999 implementations.

“For me, the most logical step to take is just implement EIP-999, and I don’t see what waiting another four weeks to conclude would benefit,” Schoedon said.

Steiner echoed this, emphasizing that implementing the code doesn’t necessitate a split.

But also at the meeting, Péter Szilágyi, the lead developer of Geth, the Ethereum Foundation-led ethereum software which serves the majority of users, disagreed, stating that if the code is available it will create a contentious split.

Szilágyi said:

“We’re talking about exactly the same networks and we’re basically starting a tribalism war. I don’t think we’ll reach a consensus.”

Geth versus Parity

And seeing developers of ethereum’s two biggest competing softwares go head-to-head displays the “main concern” many developers have.

Stepping back, though, it’s important to understand how Parity and Geth work together. Each communicates directly with the ethereum virtual machine – which takes smart contract language and translates it into more general code – but Parity and Geth do so in different computer programming languages.

By keeping up with each other’s development, both softwares remain in sync and on the same blockchain not only with each other but also with ethereum more broadly.

As such, it is critical that Geth and Parity contain the same code.

If, for instance, one team implements EIP-999 and the other does not, the blockchain will fracture into two divergent groups – two ethereums.

And just as the developers of the software implementations are split, so are ethereum users. An ether vote recently showed that a majority of people were opposed to the code change, but that voting method has come under much criticism. Other developers are looking to social media to help them gauge community consensus, but so far, it remains inconclusive.

As such, Parity’s Steiner said that the company “had not decided yet” whether to implement the change. But representatives from the company told CoinDesk that it would be publishing a statement in the coming days.

What is known, though, is that without Parity, ethereum would lose quite a bit.

Not only does the company provide a significant portion of the mining power on the network, but it also represents a large portion of ethereum’s developer community.

Speaking to this and Parity’s drive to hard fork so they retrieve user funds, Van de Sande told CoinDesk:

“Parity is a valuable team of developers, and they have a very large incentive to create a fork and support it.”

Dire disincentives

But even with an incentive to move forward with implementation, there are plenty of disincentives.

For one, if a split on ethereum occurs, it won’t merely impact transactions, but also the thousands of tokens and businesses built on top of the blockchain, Van de Sande said in a blog post.

Following a split, each ethereum contract will simultaneously exist on both chains, or as Van de Sande described, “If you own rare online cats, now every one of them will have an evil twin in a parallel universe.”

Speaking to CoinDesk, Van de Sande elaborated, saying, “The best case scenario for a split is one in which the minority fork is a very small community and most apps know which way to move forward, but it still might create an adversarial community.”

However, there is hope for disincentivizing Parity from going forward without full consensus, he said.

If a split occurs, it is likely that both ethereum blockchains will lose value as the community splits into two groups. This means that the money lost as a result of the Parity fund freeze will decrease in value.

“Since there is so much locked ether, that can amount to millions of dollars,” Van de Sande said. “Then they might not be so incentivized to fork it.”

Yet, that still doesn’t eliminate the issue that hundreds of millions of dollars of ether are locked up whereby users (including some high-profile ICO issuers) can use them.

As such, Van de Sande is working on a method to refund the Parity losses with the same amount of value as was lost in the fund freeze, although he wouldn’t go into much detail.

Instead, he told CoinDesk:

“The question is how to give value to those tokens, and that’s something I, and I hope others, will probably be writing more about.”

Warning of shock sign via Shutterstock

The leader in blockchain news, CoinDesk is a media outlet that strives for the highest journalistic standards and abides by a strict set of editorial policies. CoinDesk is an independent operating subsidiary of Digital Currency Group, which invests in cryptocurrencies and blockchain startups.

Posted on

Blockchain Bloat: How Ethereum Clients are Tackling Storage Issues

24,270 tokens. 27,358 pending transactions. 463,713 digital kittens.

Ethereum has hosted a lot of activity recently, and while many crypto enthusiasts see that as a positive sign, as the network’s usage soars, its history gets longer and its blockchain more unruly.

And although network congestion leading to transaction backlogs and rising fees has taken the spotlight, there’s another issue this scale causes – a growing database that puts significant storage costs on users wanting to run a full node.

That database, called the ethereum state, hold all the computations that need to be memorized by the computers supporting the platform and the ethereum blockchain itself. And with the costs (both in time and money) of storing the state increasing, fewer and fewer people are choosing to run full nodes, which many worry will centralize the network into the hands of only a few arbitrators.

And developers recognize the problem.

For one thing, ethereum developers are well underway engineering protocol-level changes such as sharding, aimed at minimizing the database.

But since these technologies are still in development, other stakeholders, namely those running ethereum clients – the software needed for users to communicate with the blockchain – have been under fresh pressure to cope with the growth of the state database.

“The fact that improving this stuff is critical has been known since late 2016, the ideas have been floating around for half a year to over a year. Where are the implementations?” said ethereum creator Vitalik Buterin on a developer channel recently.

The frustration is palpable with both Buterin and Afri Schoedon, who manages technical communications at ethereum software client provider Parity. Schoedon told CoinDesk:

“At the current growth rate it’s predictable that the state is going to grow very fast this year, to a point where it would be hardly manageable on small devices.”

In an effort to limit the effects of the unwieldy state, then, the two most popular ethereum clients – Geth and Parity – have recently released updates that attempt to improve the situation.

Turbocharged

The first update, released last week by Parity, reduced storage requirements by eliminating unnecessary, temporary files produced as the software memorizes ethereum’s history.

By vastly minimizing the storage requirements, users hooking up to run full nodes then experience faster synchronization times. And with that, the company said its ethereum software could now be run on a hard drive instead of a solid state drive (SSD), a particularly notable feat since long sync times have made ethereum unable to run on a hard drive since last summer.

The update even got an excited response from Buterin, who said on a developer channel,  “Wow. How did you guys accomplish that?”

As a result of the update, users have been reporting a vastly improved experience.

At the same time, independent developer Alexey Akhunov has been working on a rewrite of the geth client, called “turbo geth.” Described by Akhunov as an “obsession,” the project aims to remove a lot of unnecessary repetition in how ethereums’ clients process the overall state.

While it’s nowhere near ready, it has opened up some interesting avenues of “speculative optimization,” Akhunov said in a recent developer chat.

For example, Akhunov suggests “hard coding” certain information about the ethereum state into the clients themselves. Ultimately, the goal is to adapt the software to simply run using random access memory, or RAM, which could make the clients much faster – allowing them to potentially synchronize with the network instantly.

Developers at Geth itself are also working on optimizations, for one trying to correct a quirk in how information is stored when a client syncs with the network in what is called “fast” mode. Described by Geth core developer Péter Szilágyi as “really horrible,” the existing code is likely to be replaced along with a whole bunch of updates that make synchronization much faster and less storage-intensive.

The limits

There’s also research being done into a client type called “stateless clients,” which only store a compression of the overall state.

Even Buterin is interested in the idea, recently undertaking a study that describes a scenario where “miners and full nodes in general no longer need to store any state.” Plus, Buterin said later in a developer channel, stateless clients would also alleviate the need to clear up the state by other measures, such as pruning old, irrelevant data, for example, empty or long-inactive accounts.

“I’m now in favor of the stateless client approach,” Buterin wrote.

And there is even speculation that stateless clients might be possible without making protocol-level changes.

Touting such clients as a possible solution to the scaling hurdles faced by ethereum following the success of CryptoKitties, Akhunov wrote in a recent blog post: “I believe (stateless clients) can be implemented already now, without any hard fork, ‘simply’ by changing the ethereum clients … This means that nodes do not need to access storage from files and block validation times should drop significantly.”

However, client optimizations can’t be the only thing the network relies on to decrease state concerns.

According to Szilágyi, eventually, client optimizations will reach their limit. And then developers will have to turn their attention to in-progress technologies, such as sharding, which splits up the ethereum database into smaller pieces stored at different nodes, in an effort to alleviate the pressure of storing the full database on individual clients.

Perhaps in response to the recent strains on the network, sharding development has advanced in recent months, with an early stage specification sketched out on Github.

“We can optimize the database and make it ten times faster and more optimal, which gives us room to grow to ten times our current size,” Szilágyi said, adding:

“But eventually, we will get to the point where we won’t be able to do database optimizations anymore, and by that time we need to be able to shard our data.”

Hard drive image via Shutterstock

The leader in blockchain news, CoinDesk is an independent media outlet that strives for the highest journalistic standards and abides by a strict set of editorial policies. Interested in offering your expertise or insights to our reporting? Contact us at news@coindesk.com.

Posted on

Ethereum's Geth Client Finds Vulnerability Less Than Two Days Before Fork

The hard fork software on ethereum’s most popular client Geth has been retracted due to a denial-of-service (DoS) attack vulnerability.

Ethereum’s Byzantium hard fork is expected to happen in less than two days.

On finding the bug, ethereum developers pushed a new software release, but data from blockchain analytics site Ether Nodes shows a relatively low rate – only 1.9 percent of Geth nodes – of adoption.

With Geth responsible for about 75 percent of ethereum nodes, this could mean a large portion of the ethereum blockchain will be vulnerable to DoS attacks after the hard fork.

Explained by ethereum developer Casey Detrio on Reddit, the vulnerability stems from an oversight in one of the new Byzantium features. The risk is that this vulnerability could be exploited by a malicious agent fixed on taking down ethereum nodes – the kind of attack to which ethereum is well familiar.

Yesterday, ethereum’s second largest software client Parity issued a new release of its Byzantium hard fork software (the fourth iteration) that corrected a “consensus bug” – an error which could have caused the network to partition. Currently, less than 20 percent of Parity nodes have updated to the new release.

Both Parity and Geth faults are being discovered via some last minute “fuzz testing” – a thorough testing process that can reveal even the tiniest weaknesses in code.

Hard forks are hard

The surprises unearthed by the tests have been of unexpected severity, leading ethereum developers to question their approach to the hard fork release process.

Internal discussions are also underway about the possibility of postponing Byzantium, but this also causes issues. Doing that would require all nodes update their software with a later block time, and there’s no assuring this can happen with such little time before the fork.

In spite of these concerns, the Parity developer team tweeted that the fork should be delayed.

Speaking to CoinDesk, Detrio explained that “updating is not necessarily a quick and easy process for users with extensive infrastructure,” such as exchanges or mining pools, and requires ample time to be done correctly.

He added:

“The second concern is that there may be more undiscovered consensus bugs that could be found after the activation block, which would then result in needing to perform emergency client updates.”

Bug on leaf image via Shutterstock

The leader in blockchain news, CoinDesk is an independent media outlet that strives for the highest journalistic standards and abides by a strict set of editorial policies. Have breaking news or a story tip to send to our journalists? Contact us at news@coindesk.com.

Posted on

Ethereum's Geth Client Finds Vulnerability Less Than Two Days Before Fork

The hard fork software on ethereum’s most popular client Geth has been retracted due to a denial-of-service (DoS) attack vulnerability.

Ethereum’s Byzantium hard fork is expected to happen in less than two days.

On finding the bug, ethereum developers pushed a new software release, but data from blockchain analytics site Ether Nodes shows a relatively low rate – only 1.9 percent of Geth nodes – of adoption.

With Geth responsible for about 75 percent of ethereum nodes, this could mean a large portion of the ethereum blockchain will be vulnerable to DoS attacks after the hard fork.

Explained by ethereum developer Casey Detrio on Reddit, the vulnerability stems from an oversight in one of the new Byzantium features. The risk is that this vulnerability could be exploited by a malicious agent fixed on taking down ethereum nodes – the kind of attack to which ethereum is well familiar.

Yesterday, ethereum’s second largest software client Parity issued a new release of its Byzantium hard fork software (the fourth iteration) that corrected a “consensus bug” – an error which could have caused the network to partition. Currently, less than 20 percent of Parity nodes have updated to the new release.

Both Parity and Geth faults are being discovered via some last minute “fuzz testing” – a thorough testing process that can reveal even the tiniest weaknesses in code.

Hard forks are hard

The surprises unearthed by the tests have been of unexpected severity, leading ethereum developers to question their approach to the hard fork release process.

Internal discussions are also underway about the possibility of postponing Byzantium, but this also causes issues. Doing that would require all nodes update their software with a later block time, and there’s no assuring this can happen with such little time before the fork.

In spite of these concerns, the Parity developer team tweeted that the fork should be delayed.

Speaking to CoinDesk, Detrio explained that “updating is not necessarily a quick and easy process for users with extensive infrastructure,” such as exchanges or mining pools, and requires ample time to be done correctly.

He added:

“The second concern is that there may be more undiscovered consensus bugs that could be found after the activation block, which would then result in needing to perform emergency client updates.”

Bug on leaf image via Shutterstock

The leader in blockchain news, CoinDesk is an independent media outlet that strives for the highest journalistic standards and abides by a strict set of editorial policies. Have breaking news or a story tip to send to our journalists? Contact us at news@coindesk.com.

Posted on

Ethereum Client Update Sets Byzantium Hard Fork Date

Ethereum’s most popular client has upgraded its code to enforce the upcoming Byzantium upgrade set for later this month.

The code from Go Ethereum (Geth) officially enshrines the hard fork for block number 4,370,000, a time previously established by developers during an ethereum core team discussion on September 22. With the Geth release, the network moves closer to implementing the first of two parts in the wider Metropolis upgrade. The addition of the code to Geth is notable because it greatly increases the likelihood that the upgrade will happen at that time.

Geth, which is maintained by developers employed by the Ethereum Foundation (the Swiss nonprofit that manages development on ethereum more broadly), accounts for roughly 69 percent of all ethereum nodes, according to data from Ethernodes.org.

If the block time remains consistent between now and then, the hard fork – which will make previous versions incompatible with the wider ethereum network following the upgrade trigger – will officially occur on October 17.

Anyone running a ethereum node with Geth is requested to update their software to “ensure a smooth transition,” the code release states.

In a reddit post accompanying the release, ethereum developer Peter Szilágyi advised node operators to update their software at least a week prior to the mainnet launch. Other clients, such as Mist, will issue updates in the coming dates, Szilágyi predicted.

“Please give yourselves ample time to switch to the 1.7.x series (1.7.1 specifically for Byzantium) before the hard fork to avoid any surprises as the series does contain non-trivial database optimizations ([it] also gives us time to fix anything if something doesn’t work as it should),” he commented.

The code release comes in spit of the recent spam attacks on the Ropsten test network, though those interruptions were not enough to deter ethereum developers from the work on testing Byzantium.

As previously detailed by CoinDesk, the upcoming hardfork, which is the first part of a larger upgrade planned for the platform, will feature a variety of improvements including increased speed and ramified security. Certain changes may also eventually pave way to increase privacy on the ethereum blockchain.

Image via Shutterstock

The leader in blockchain news, CoinDesk is an independent media outlet that strives for the highest journalistic standards and abides by a strict set of editorial policies. Have breaking news or a story tip to send to our journalists? Contact us at [email protected].

Posted on

Geth Releases Software Update Ahead of Ethereum 'Byzantium' Hard Fork

A new version of ethereum’s Geth node software has been released, which includes support for the upcoming “Byzantium” upgrade as well as a series of performance enhancements.

Named Megara, the freshly-coded Geth release has been reformatted to include all improvements developed for Byzantium, which forms the first of two parts in the wider “Metropolis” update. Ethereum is currently on target to activate the Byzantium hard fork within the next month.

It notably includes a formal block number for the launch of Byzantium on Ropsten, the ethereum testnet. Previously set for September 18, the block number is now officially 1,700,000, which looks likely to be reached in roughly seven days.

On top of featuring compatibility with the Byzantium improvements, new performance enhancements have been introduced to the software. Among those are steps to cut the amount of data storage required by a node from 26.3GB to 14.9GB – making ethereum significantly lighter to run. Updated nodes will also be able to process contracts faster, with filtering times reduced from minutes to under a second.

Some updates are yet to be finalized, but promise to eventually reduce the bandwidth requirement of the underlying peer-to-peer protocol from 33.6GB to 13.5GB. Further, a memory-caching improvement should increase in speed by a “couple orders of magnitude,” the release states.

Megera also includes an improved transaction pool. In the earlier version of Geth, high-paying transactions were prioritized indiscriminately – but, in this new version, a Geth user’s own transaction will always receive priority, regardless of whether it contains fewer funds.

For enhanced security, new protective measures on the transaction disk enforce that a backup be created for local transactions in case of a node crashing. Further, Geth will now also support the Trezor line of hardware wallets.

Command line image via Shutterstock

The leader in blockchain news, CoinDesk is an independent media outlet that strives for the highest journalistic standards and abides by a strict set of editorial policies. Have breaking news or a story tip to send to our journalists? Contact us at [email protected].