Setting a precedent

It’s time for the Ethereum community to make a difficult decision. As Vlad Zamfir recently explained, a lack of consensus on a hard fork could be problematic, regardless of whether or not a hard fork occurs.

This post doesn’t argue for or against a hard fork. There are strong arguments on both sides and neither is a perfect solution. But there is one argument against forking seems broadly misunderstood.

The legal doctrine of precedent has been built up over centuries, across different legal systems. The basic concept is that similar cases should be decided in the same way, in the interests of fairness, predictability and stability. When applying the doctrine, most of the arguments are around whether the facts of the current case fall within the principle established by the precedent case. That is to say, it’s more nuanced than ‘we have to do it this way because that’s what we did last time.’

Of course, we use informal applications of precedent for other decision-making purposes too, in systems as diverse as sports, execution of business plans, and family and parenting decisions.

But a hard fork of the Ethereum blockchain to address The DAO attack wouldn’t necessarily set a ‘precedent’ (legal or otherwise) that every future smart contract failure deserves a hard fork to ‘correct’ it.

In this case, a fork could be done on the basis that The DAO attack (1) occurred early enough in Ethereum’s development and (2) was of a significant enough scale, to warrant protocol-level intervention. By defining this decision clearly and narrowly, we could limit almost all future scenarios from falling within this ‘precedent’. Measures such as limiting the value held in any given smart contract (at least in the short term) will also assist.

In any event, it’s not clear whether a strict doctrine of precedent would be a valuable governance tool for protocol-level decisions. As Vlad points out:

It is paramount that the social governance process, rules, or principles that govern hard forks do not become institutionalized. The community must not be bound by precedents (or lack thereof), it must not be bound by miner voting, it must not be bound by coin voting (although these may be useful for signaling), it must not be bound by the will of its leaders, and it must not be bound to any other kind of majority rule.

Of course, precedent is very important in legal systems. It protects against arbitrary and inconsistent decision making. But it might not work as well in systems where rapid development is a requirement, because strict adherence to precedent could also impede rational decision making in the future.

The evolution of governance for open-source protocols is critical, challenging and exciting— so let’s think carefully before committing to existing rules designed for other systems.

Nothing in this article is legal advice. These opinions are my own, and don’t necessarily represent the views of Coinbase or any other organization.