海蓝 发表于 2016-12-2 06:03:22
您需要 登录 才可以下载或查看，没有帐号？立即注册
How Developers Are Responding to Ethereum's Unexpected Fork
An unintentional split of the network was the latest event to shake ethereum.
By now, you might have heard the back-and-forth about so-called hard forks, a particularly contentious way to update a public blockchain. Some view it as a sometimes necessary means to update the network, while others see it as less than desirable path because it breaks consensus and everyone on the network needs to update to a new blockchain in order to participate.
Ethereum has hard forked three times over the past few months to fix technical issues. But the latest fork was different, because it wasn’t executed on purpose.
At issue is that ethereum has different implementations of the protocol to process transactions on the network in sync. The two most popular, Geth and Parity, implemented the code for the last technical hard fork slightly differently, leading to a Thanksgiving fork .
One consequence is that the ether price dipped to the lowest point it’s been at since April, or before The DAO crisis, according to ethereum’s event timeline. Petar Zivkovski, director of operations for leveraged bitcoin trading platform Whaleclub, went as far as tocall these recent challenges a "crisis of identity."
From the mid-summer unravelling of The DAO to an unknown hacker spamming the network to the point where users couldn’t complete smart contracts, it’s been a rough few months for the smart contract platform.
Yet ethereum developers have struck an optimistic tone, seemingly viewing the Thanksgiving fork as another learning experience and a chance to make the network better.
Those involved with the project say that the team is looking to take steps in order to prevent future occurrences.
"This time, the fork was detected within 6 minutes, which was a bit lucky," Ethereum Foundation security lead Martin Holst Swende told CoinDesk.
Because developers might not always accidentally spot the problem in such a short time frame, they want to make sure that they're able to react quickly in a similar situation.
"We're working on improving our capabilities for detection, analysis, communication/coordination between teams,” Swende said.
He added that they’re working on a "Post Mortem" report, outlining lessons learned from various ethereum bugs, which they aim to open up to the public soon.
One step being taken will involve making time for added testing of "non-critical" forks, or those that don’t need to be executed immediately.
Ethereum Foundation media relations lead Hudson Jameson noted that developers also plan to overhaul the Ethereum Improvement Proposal (EIP), a process by which developers propose new ecosystem standards or changes to the ethereum protocol.
"There is also plans to eventually create an alternative web interface for listing EIPs so it will be easier for the average user to view EIPs without having to navigate a GitHub repo, which can be confusing at times," he explained.
Fixing the fork and beyond
There have been three other forks recently.
The last technical fork, Spurious Dragon, fixed a few different ethereum issues, including the deletion of the empty accounts that the attacker used to spam the blockchain.
Over the past week, developers have been using this newly granted power to delete all of these empty accounts, thus "debloating" the blockchain (a process that was officially completed on Wednesday). In the middle of this process, at block 2686351, a developer tried to delete an empty account, but didn’t use enough gas.
That’s where Geth and Parity had a minor disagreement— with big consequences. Geth went forward with deleting the accounts, whereas Parity didn’t. So, the network temporarily split into two.
The latest version of Geth, released the day of the fork, fixed the problem.
"If you do not update, please be aware you will be on an invalid chain that is not supported," ethereum creator Vitalik Buterin wrote in response. (This comment got some flak , since Buterin was declaring which chain was correct.)
Further, Buterin described it as an issue with Geth, but other developers have argued otherwise.
Geth developer Péter Szilágyi remarked at the time that, "We're trying to introduce the Parity bug into Geth so that we don't have to rewind the chain..."
Still, despite the minor infighting, the ethereum community views it as an opportunity to do better next time.
Yet there are some who think it's a problem that will continue to impact the ambitious smart contract blockchain. To some, the problems described above vindicate a position offered by bitcoin's pseudonymous creator during a debate from six years ago.
"I don't believe a second, compatible implementation of Bitcoin will ever be a good idea. So much of the design depends on all nodes getting exactly identical results in lockstep that a second implementation would be a menace to the network,” Satoshi Nakamoto said in a discussion with Gavin Andresen, former lead maintainer of Bitcoin Core.
One potential "menace" is that every client on the network needs to function nearly the same, even while written in different programming languages. If there’s a slip up (in ethereum’s case, small disagreements of how to delete the empty accounts), the network could split.
ChromaWay co-founder and CTO Alex Mizrahi argued recently that while multiple implementations might be considered a good thing in other instances, the risk of monetary loss showcases why it might not be appropriate for cryptocurrencies.
So, some argue that a fork was an inevitable result, but since bitcoin and ethereum networks are perceived as competitors, it’s hard to determine the honesty behind this analysis.
Since ethereum doesn’t a wide user base, it might not have impacted that many people. In this case, those miners that accidentally continued to mine on the "wrong" chain probably lost money. Anyone who made a transaction on the wrong chain might be surprised to see that it didn't go through.
In the end, a similar event would perhaps be more worrying on a more widely used platform.
上一篇：GraphQL Starter Kit /w Node.js, Babel, Flow and PostgreSQL
下一篇：Async / Await Warm Up