It turns out soft forks are indistinguishable from censorship. In that case, we had better make sure control over them is adequately distributed among the stake holders of the network, lest we be subject to soft-fork attacks.
AttacksThere are four broad categories of attacks in blockchain land:
1) safety violation a fork in the blockchain; the source of double spends
2) liveness violation no new blocks are added; the chain halts
3) censorship certain valid transactions are not included in blocks
4) invalid execution certain invalid transactions or data are included in a block
I first heard this stated by Vlad Zamfir , and I believe it is correct. One might wish to add additional categories of attack, such as privacy invasion (for instance de-anonymizing transactions) and manipulation of fees/capacity (for instance by sending lots of transactions with high fees), but these are more probably consequences of design than explicit failure scenarios Bitcoin was never really designed to be that anonymous and higher fees is just the healthy fee market kicking in.
The first two attacks, safety and liveness violation, are properties of the underlying protocol, and are the focus of traditional research on distributed consensus. Any viable algorithm must prove to satisfy safety and liveness. The latter two, of avoiding censorship and invalid state transitions, are more economic and political in nature, and are emphasized much more by the blockchain community, where censorship resistance and code-as-law are cherished ideals.
Ironically, and seemingly less well known, the latter two attacks, of censorship and invalid execution, correspond exactly to what are called “soft forks” and “hard forks”, respectively.
Forks: Soft and HardA soft fork is typically described as an update to the protocol that is backwards compatible peers that do not upgrade can still get along just fine. Sometimes soft forks are said to correspond to a “narrowing” of the rules transactions which used to be perfectly acceptable may no longer be accepted if they do not account for the new rules. This is blatant censorship. That is, a soft fork is indistinguishable from censorship.
A hard fork is typically described as an update to the protocol that is not backwards compatible peers that do not upgrade will fork off onto their own chain, as the new rules appear invalid. Sometimes hard forks are said to correspond to a “widening” of the rules transactions which used to be invalid may now be valid under the new rules. That is, a hard fork is indistinguishable from invalid execution.
It is humourous for proponents of Bitcoin to champion its censorship resistence when it fact the very thing that has enabled Bitcoin to improve its feature set is blatant censorship. The difference is, censorship in the form of a soft fork is explicitly voted for before it activates, and has some guise of community support, though this need not be the case.
StakeIn Bitcoin, at least, voting for a soft fork is strictly the domain of miners, and as we saw in July 2015 with BIP66, they can even screw it up . But the distribution of bitcoin users is much different than bitcoin miners, and the users have no say in a soft fork (which is, remember, indistinguishable from censorship). Of course there is a meta-protocol argument that miners will only implement soft forks (censorship) that are good for everyone, like Pay-2-Script-Hash and Segregated Witness , lest they sacrifice the utility of the system and value of their seniorage. But so long as they appease the majority, there is little to prevent them from performing what might be called “soft fork attacks” as they please. Remember: implementing segregated witness as a soft fork amounts to burdening the bitcoin ecosystem with a substantial amount of additional techincal debt.
Proof of stake attempts to mitigate this issue by distributing soft-fork/censorship voting power in proportion to a user’s “stake” in the system. How to measure such an abstract quantity as “stake” is of course extremely difficult, given the various axes of participation or stake one might have in a network for instance how do you compare someone with high net worth but low transaction volume against someone with low net worth but high transaction volume? What about the offering of additional services which complement the network, like exchanges, embedded currencies, and payment channels?
While it might be difficult to quantify “stake”, presumably PoS does a better job than mining power, especially in today’s age of hyper specialized hardware. However, a naiive PoS suffers from the nothing-at-stake problem, and so far our only solution to that is security deposits or “validator bonds”.
BondsSecurity deposits were introduced to proof of stake by Vitalik to ensure that validators who attempt to double spend can be punished by “slashing” the deposit when evidence is published that the validator double-signed. The first implementation of such approach came in the form of Tendermint , which used a classic Byzantine Fault Tolerant consensus algorithm to order transactions in blocks, where the voting power of a validator in the consensus is proportional to the security deposit. Of course, since validators must eventually be able to unbond and get their money back, introducing the so-called long-range-nothing-at-stake-attack , nodes joining the network for the first time must authenticate the state via extra-protocol means (for instance by asking friends or checking social media), and must keep up with changes to the validator set, lest they fall subject to attack by unbonded validators who have created an alternative chain from way back when they were still bonded.
The problem with this solution is that not everyone can be, or even wants to be, a validator at the same time, as there are practical considerations which limit the number of users in a conensus algorithm at once and being a validator requires significant expertise in maintaining a secure server on a live adversarial network. Thus, the distribution of soft-fork/censorship voting power follows that of the bonds, not of the actual stake in the currency, bringing us back to the situation in proof-of-work where validators are easily able to soft fork attack the network.
That this is a problem with security deposit based PoS was recently pointed out by Zack Hess in the design documentation for his Flying Fox blockchain . Flying Fox is a security deposit based PoS chain with an emphasis on state channels , where most computation happens off chain between the relevent participants and honest behaviour can be enforced by resorting to the blockchain when necessary. Flying Fox’s solution to the soft-fork attack issue is to introduce a different metric for stake, a different “bond”, based on how much money you had locked in state channels, rather than on security deposit. Thus there are effectively two bonds: the small bond, a deposit used for economic security such that it can be slashed if the validator misbehaves, and the big bond, which amounts to the deposit held in payment channels, and which serves as a measure of a user’s actual stake in the system (having a lot bonded in a payment channel and being online to service it is a major committment to the value of the network). The big bond can not be slashed (it does not protect against double spends), but is instead used to select validators, and once selected, the small bond, which can be slashed, is placed by a validator and used to ensure they do not double sign.
DelegationAnother approach to the problem of adequately representing stake holders in the consensus process (ie. in soft-forks/censorship) is to use delegation: non-validators can delegate their coins to validators, thereby contributing to the security deposit. This is the approach taken by Atom , a scalable multi-asset proof of stake blockchain based on Tendermint. Delegation allows one to receive a portion of the transaction fees paid to the validator, but also puts the funds at risk if the validator double-signs. Validators will thus partake in some kind of “delegate campaign”, where they attempt to convince stakeholders to delegate to them by advertising the reasons why they are the best protector of a private key or the ideal representative of a stakeholder’s values.
Of course, as we know quite well, representational governance doesn’t always work very well, and more or less degrades into “who can run the best campaign”. That said, since this is cryptoland, we can introduce additional constraints which limit the ability of a validator to vote for a soft-fork without the approval of her constituents. Alternatively, reputational markets and the ability to “switch delegates” may be sufficient incentive for delegates to behave honestly or as their constituents would like.
ConclusionOne trouble with miners is their capacity for censorship. Since they determine what goes in the blockchain, they can co-ordinate to prevent certain kinds of transactions. Such behaviour is also known as a soft fork . People often think of a soft-fork as “any update that is backwards compatible”. But it is more illuminating to think of it as explicit censorship of transactions which do not account for the new rules found in the update.
Proof of stake attempts to solve this issue by distributing the voting power across all stake holders, but secure proof of stake, with security deposits, re-introduces the problem once again. The solution the second time around is to use investment in a useful service (like payment channels) as a direct measure of stake, or to allow delegation, such that a representational governance system with low switching costs ensues.
Addendum How Ethereum Could have Soft-Forked TheDAOOne of the initial proposals for dealing with The DAO fiasco was a softfork which would censor all transactions to The DAO contracts. Of course the issue with this is that it is not known if a transaction will call a particular contract until run time, and if such transactions are rejected, and hence gas is not collected, they open a denial-of-service attack against miners who may have to do considerable computation only to find out the transaction should be censored. However, as discovered by Zack Hess, it is indeed possible to implement this censorship without the DoS vulnerability, at the cost of significant additional complexity. To wit: an additional state tree and transaction log is added to the Ethereum blockchain. Any transaction which ought to be censored will be included in the new transaction log, and have appropriate gas deducted in the new state tree. Thus the current state will result from the combination of state trees. Anyone who has not upgraded will not be aware of this new state tree, and so will perceive incorrect balances. This will appear to them indistinguishable from censorship. Of course, this would make quite the mess of the protocol, but it is an interesting intellectual exercise. A more refined taxonomy of forks is certainly needed coming soon!
