译者注：谢谢 殷允峤，kyle.c开噢，Toya，深鱼，游啊游，少平，吕国宁，兆亿的空间 等对文章翻译的一些建议和讨论。
1) 三个月以前，在一次对Morgen Peck采访中，我做过这样的声明，如下所述：
“我一般赞同每一个出现的分裂企图，”他说，“如果未来在Ethereum中有一种争吵，我一定会很高兴看到Ethereum A朝一个方向发展，而Ethereum B朝另外一个方向发展。”
如果真的存在一种共识机制是最好的，为什么我们不应该合并所有这些不同的项目，形成一个最好的去中心化计算机作为基础推动密码学的发展，在统一的系统下共同进步？在某些方面，这听起来有些高尚；“分裂”肯定有不好的一些属性，通常认为“团结一致”是更好的。然而事实是，更多的合作确实有用，但是这篇文章稍后会描述为什么以及如何，追求极度的团结或者赢者全赢是一个更大程度上的完全错误 – 并不是所有的分裂都是坏的，而且它也是不可避免的，可以说在这一方面适度的繁荣是有利的。
2) 但是这些只是我的信仰和中立的价值观。我们怎么确认“百花奇放”的观点是真正正确的呢？事实上在当前情况下，我们可以发现很多事实。首先，尽管我们看到ETH + ETC在过去的2.5天里有一个相当稳定的价格在$14.3附近，尽管两个部分都有很大的波动性。这依然是在早期阶段，所以依然提醒两个加密货币的价格事实上并不是完全符合超线性函数。
3) 我同样想表达对硬分叉的我的个人观点。我不认为使用硬分叉作为主要手段来解决偷盗和不道德的应用，是一种长期可行的方案。这一次，我们比较幸运的是，被盗的DAO ETH锁定在一个已知地址里35天。下一次，资金可能在开发者知道以前就被卖到交易所里了，唯一的解决办法可能是回滚 - Casper会使回滚不可行，因为在任何情况下的经济终结机制。
在短期到中期的未来，我期望会有更多的小的应用，而不是一个大的应用，那样的话不会因为一个失败而影响到整个生态系统；如果应用求助于硬分叉变成一种常态，它对我打击很大（注意到某些人不同意；Vlad会比较乐于硬分叉因为更多原因，尽管如此我允许他捍卫他自己的观点 :) )
i) 一种分叉，一种非常不可能的情况是Solidity 编译器证明有一个非常严重bug，导致500-1000万ETH在危险状态。
ii) 中等数额的ether被发送到一个不能花费的地址，因为用户使用了有bug的ethereum-js库，没有正确地从public key创建地址。我可以接受为此做些改变，比如作为metropolis，增加一种新的交易类型，有效地使多数普通类型的不能花费的地址可以花费，通过密码学上证明他们是正确的拥有者（但是我只是表示可以接受在广泛共识的情况下，而且它也会取决于技术可行性和代码复杂度）。
A Grab Bag of Thoughts on ETC and Forks
1) Three months ago I made a statement in an interview with Morgen Peck as follows:
I generally support just about every secession attempt that comes along,” he says. “If in the future there is that kind of a dispute in Ethereum, I’d definitely be quite happy to see Ethereum A go in one direction and Ethereum B go the other.
I do have principles, and this is a principle that I have so far held consistently. It would of course be grossly hypocritical for me to (correctly) decry bitcoin maximalism back in 2014, and then start shouting "one chain to rule them all! network effects!" the moment it becomes suitable to me. Rather, I believe, just as I had stated in my 2014 post on silos, that:
If there truly is one consensus mechanism that is best, why should we not have a large merger between the various projects, come up with the best kind of decentralized computer to push forward as a basis for the crypto-economy, and move forward together under one unified system? In some respects, this seems noble; “fragmentation” certainly has undesirable properties, and it is natural to see “working together” as a good thing. In reality, however, while more cooperation is certainly useful, and this blog post will later describe how and why, desires for extreme consolidation or winner-take-all are to a large degree exactly wrong – not only is fragmentation not all that bad, but rather it’s inevitable, and arguably the only way that this space can reasonably prosper.
I personally admittedly find ETC's social contract, community and raison d'être less exciting and satisfying and would not personally feel the same passion for it that I do for ETH, but this is simply my judgement, and the judgement of the very many members of the community that have voted or otherwise expressed assent to the fork. Anyone who feels sufficiently strongly in the other direction is welcome to focus on the ETC chain, and we will see if it remains viable.
2) But those were just my beliefs and intermediate values. How do we know that this "let a hundred flowers bloom" position is actually correct? We can actually discover a lot of facts from the current situation. First of all, though we can see that the price of ETH + ETC has been remarkably stable around $14.3 for the past 2.5 days, despite great volatility in each component. This is still early-stage, but suggests that the value of at least the cryptocurrency component of the ecosystem actually isn't a superlinear function that favors monopoly.
Second, we can see from several sources (including exchange order books, but also public pronouncements from Barry Silbert et al) that incoming interest into ETC is actually coming from the bitcoin side even more than it is from the ethereum side. And this is a core tenet of blockchain pluralism: by leaving open an option to join an alternate system if an individual so chooses, you can satisfy the varying needs of larger groups of people.
3) I may as well offer my own views on hard forking. I do not believe that using hard forks as a primary paradigm to resolve thefts or to deal with unethical applications is a long-term viable strategy. This time, we got very lucky that the stolen DAO ETH were conveniently stuck in a known address for 35 days. Next time around, the funds will likely be being sold on exchanges before the developers even know it, and the only solution will be a rollback - and Casper will make rollbacks infeasible due to its economic finality mechanism in any case.
3b) "Evil dapps" can constantly move their contracts around in ways that evade a necessarily slow-moving hard fork, so while we can annoy them, "softer" means of mitigating the harm of such applications must necessarily still be sought out.
3c) The blockchain itself is very far from the eventual vision of a hyper-scalable, efficient and secure world computer and will see several more iterations to move closer to that goal; if you wish you may view Casper as a completely independent blockchain that happens to have a 100% state-copying premine from ETH, and in fact this may even be the cleanest way to implement it in code. I personally was okay with a fork in light of this context, together with a philosophical belief that a principle does not need to have literally infinite weight in order to have value.
In the near to mid-term future, I expect that there will be many small applications rather than one big application, and so no single failure will be enough to greatly impact the ecosystem; hence it strikes me as quite unlikely that application rescue hard forks will become a regular thing (note that some disagree; Vlad would love to have hard forks for many more things, though I'll let him defend his own views :) )
At this point, I am hypothetically open to two kinds of application rescue hard forks:
i) A fork in the very unlikely case that the Solidity compiler proves to have a serious bug that puts 5-10 million ETH in danger.
ii) There has been a medium amount of ether that has been sent to unspendable addresses because users were using buggy ethereum-js libraries that created the address from the public key incorrectly. I would be OK with a change, for example as part of metropolis, that adds a new transaction type that effectively makes the most common categories of such unspendable addresses spendable by their cryptographically provable rightful owners (but I would only be ok with this with broad consensus and even still it's dependent on technical feasibility and tradeoffs in code complexity).
In the future, I suspect that both possibilities will recede over time.
3d) In the short and medium term, we are still under conditions of high technical uncertainty. For example, Vlad and I continue to argue about whether or not a fixed currency supply can offer sufficient incentives through transaction fees alone to secure the network. If we had agreed, for example, to a "100 million ETH and never a single bit more" principle on day one, we would have dug ourselves into a rather deep hole if the research ends up showing that low inflation (or something more complex, like expected low deflation but the possibility of low inflation under conditions of low Casper participation) is the only safe way forward. Similarly, "it is possible to create a contract that lasts forever" is also something that is economically dangerous to commit to. Hence, principles on these kinds of matters may need to be settled only later.
4) Concerns about moral hazard are, in this case, IMO overblown; on the contrary, despite the fork, I have been extremely impressed by the sheer number of formal verification and other secure contract programming projects that have recently emerged in academia. Writing this from inside the middle of an Ethereum research workshop in Cornell, I am very optimistic that the number of bugs in code will decrease greatly over the next year.
4b) This does however mean that there is now a much larger burden on high-level language developers, and I personally do not have the time or ability to maintain Serpent at a level that I personally find satisfactory. I am personally continuing to use it as a language for experimenting with Casper simulations, but I welcome proposals from the community for how and if it can find a niche in other contexts.