writes 
Do we want our governance structure to be a decentralized one or not?
DPoS is decentralized.
ECAF isn’t.
Sounds good. But sadly the pithy message relies on several misunderstandings.
The issue here is twofold. Firstly, in understanding what decentralisation delivers to you. It is not about the counting of the numbers. Understanding when and 'how much' to decentralise is actually a design choice that comes out of a process known as security risk analysis. First step is about understanding how the design responds to threats. And then, because of that focus, it is about deciding which threats to prioritise because there are always too many threats. And only then do we decide whether to use decentralisation to deal with that threat or not.
Secondly, all systems are to some extent centralised and to some extent decentralised. In practice, when people say their favourite system is decentralised, what it means is the one element they most like is decentralised.
By way of historical example, consider messaging of the old form: telegram or post. Messages were sent by mechanisms far flung and wide, but the infrastructure was always centrally controlled. Hence the original name: Royal Mail, which handled both technologies. And then in about 1901 Marconi sent his famous first message using Morse code over radio, and a new decentralised messaging era was born.
Except, the radio waves eventually became 'congested'. Powerful radio companies appealed to government and thus frequency band licensing was born. (As an aside, there was an international treaty that said that listening is allowed and sending is not allowed without a licence. Both of these were broken in the 1980s, by for example anti-radar detector legislation and by the 2.4GHz ISM - anyone can send on ISM and similar bands without a licence. Except limited to low power because again a powerful radio supplier lobbied to reduce the power to tiny local numbers.)
Similarly with blockchain - it decentralises the double spend protection. Yet to do that it creates a very brittle protocol scenario and thus centralises the code base. Look at Bitcoin and look at EOS and count the stacks. One in both cases. Look at TCP/IP and count the code bases - hundreds - and look at the definition, being only one in IETF RFC 793. Why the difference?
The concept of decentralisation is just that, a concept. It's not a universal, nor fixed nor essential. In practice, it tends to follow what we call a "shifting of the burden" pattern, which is to say we fix this problem X and it just shifts the trouble over to place Y.
Let's look at the problem of DPOS. On paper, BPs are 'decentralised'. We can even measure it at 21. And the community will praise and punish via voting.
Except, that's not what is happening. The community are NOT praising and punishing BPs. What is happening is that a small group of cooperating whales are pushing the BPs up and down according to some internal agenda that they are not revealing. Ah, I knew I'd seen it somewhere. Here:
DPOS under EOS has been centralised, already. And there isn't a thing the community can do about it, seemingly.
Then, in comparison, let's look at ECAF. Each case goes into ECAF, which is a centralised clearing house for handling cases. More about that later.
Then, the case is handed to an arbitrator. Who that arbitrator will be is outside the direct control of the parties. There are several popular methods:
Each of these have pros and cons. Which is better depends on the circumstances. For now ECAF is going with the second.
The point here is that no party has total control over which arbitrator you get in your dispute. So in effect, the forum is decentralised. If measurement by numbers is important to you (it shouldn't be) then it's the number of arbitrators. Today that number is 6 - based on volunteer resources. In the future that number could be 100. If numbers matter, then this is a much larger number than DPOS's 21.
But as mentioned above, ECAF is a central clearing house of cases. Surely this is the point of centralisation? Surely this is the failure point for the whole organisation?
Well, maybe. In comparison, look at the DPOS code. It comes from one place, block.one. If you think that ECAF is decentralised because there is only one ECAF, why wouldn't you think that EOS is decentralised becauses there is only one code base and one code team?
In practice, the answer is it depends. On many factors. For example, the sole supplier of code is a single company that has the resources to maintain a large team, and in time there will be better capability to modify the mainnet's code base without resort to that supplier. By BPs, presumably, and in the first instance until someone points out that is too centralised. Either way, we're a long way from decentralisation of EOSIO.
In contrast, the Arbitrators are the bosses of ECAF.
2 EOS Core Arbitration Forum
By reference herein, the EOS Core Arbitration Forum (ECAF) (“the Forum”) is created to serve the Community by administering the Rules and providing customary support to the Arbitrator and to the administration of cases.The Forum is managed by the active Arbitrators. ...
And the Arbitrators are decentralised because they are 6 independent persons, and more coming.
Hence, although discussions about quantity of decentralisation aren't grounded on any accepted or useful theory, it's not clearly valid to say that ECAF is centralised. Just as it is not clearly valid to say that EOS' DPOS is decentralised.
Depending on which facts or claims we include, we can even make the case that ECAF will be more decentralised that EOS DPOS can ever be. But as I suggest above, saying something is more decentralised than something else suffers from a weak theoretical view as to what decentralisation actually is.
It's also bypassing the real discussion, which is security risk analysis. The real question is, which is more secure, and against what threats? And the really real question is, which approach delivers more benefit to the user?
