On blockchain decentralization: Defining a new path

“Sounds great, but is it decentralized enough?”

This question became the very definition for a blockchain project’s entire legitimacy over the past few years. If a new design is not decentralized enough, it is often referred to as a “centralized piece of crap” from mainstream critics, while a “proper” aim for decentralization that involves multiple new techniques gets praised for “pushing the industry forward”. On the other hand, relatively new platforms like EOS — which prioritizes processing performance over decentralization by design — receive massive support from people and developers who prefer mass adoption than a vague ideology, while also facing fierce condemnation from its opponents, mostly from the Ethereum community.

This conflict over the direction of blockchain platforms has been ongoing ever since Ethereum started to show major limitations in terms of performance. Some believe the whole point of a blockchain is decentralization — mostly related with gaining back control of the World Wide Web from large, greedy & privacy invading corporations and governments — while others prefer faster mass adoption of the technology by improving its performance, even if they become more centralized compared to previous attempts with blockchain application platforms.

While I cannot say for certain on the exact direction of how this seemingly endless fight between the two giants would conclude (as everyone else would), my personal belief for the future of this industry is vastly different from the typical assumptions involved within this decentralization versus adoption debate; perhaps neither of them have got it right, and maybe this whole debate might not have been as important as we initially thought. Here’s why.

1. The definition

Let’s start with a simple question: what is a blockchain?

Everyone would agree that it is basically a cryptographically chained data structure of transactions, forming a ledger, which is then shared across multiple nodes without allowing intermediary manipulation. What I have noticed, though, was the difference in specific detail with this definition: when people were personally asked with this question, not a single pair have given the exact same answer. While some might believe the impacts of those individual differences in definition are small, they actually may be the root cause for this fight — because they do not share the exact same assumptions and definitions on the very topic that they are debating over.

With Satoshi’s original Bitcoin whitepaper, the “block chain” was simply defined as a “chain of timestamped digital signatures that are bind and verified using a method similar to Adam Back’s Hashcash algorithm”. This was the very beginning of a Proof-of-Work chain that still powers many major blockchains, now known under the name Nakamoto Consensus. This definition have stayed roughly the same with most other Proof-of-Work chains before Ethereum, mostly because the vast majority of them were a fork of Bitcoin’s codebase.

Ethereum, on the other hand, changed this definition of a “blockchain” in significant ways. The most significant change that Ethereum introduced was state-based transactions, which was completely different from the UTXO model that Bitcoin and its cousins all have shared.

Why is this such a big deal? This is huge because it changed the very definition and assumptions of a “block chain” from those of Bitcoin’s. To see this in detail, let’s take a look at the definition of “digital coins” and “transactions” from the Bitcoin whitepaper:

We define an electronic coin as a chain of digital signatures. Each owner transfers the coin to the next by digitally signing a hash of the previous transaction and the public key of the next owner and adding these to the end of the coin. A payee can verify the signatures to verify the chain of ownership. (…) We need a way for the payee to know that the previous owners did not sign any earlier transactions. For our purposes, the earliest transaction is the one that counts, so we don’t care about later attempts to double-spend. The only way to confirm the absence of a transaction is to be aware of all transactions. In the mint based model, the mint was aware of all transactions and decided which arrived first. To accomplish this without a trusted party, transactions must be publicly announced [1], and we need a system for participants to agree on a single history of the order in which they were received. The payee needs proof that at the time of each transaction, the majority of nodes agreed it was the first received.

Here, an “electronic coin” is defined as a “chain of digital signatures”. This digital signature, of course, is a transaction, which is also defined with the next sentence — digitally signing a hash of the previous transaction and the public key of the next owner and adding these to the end of the coin. This is known as a UTXO (Unspent Transaction Output) model, which quite literally defines a coin as a group of transactions and spends the “unspent transaction outputs” of each coin (the latest transactions of a coin that is not spent yet) when its owner sends them to another wallet.

Compare this with the definitions of the exact same concept from Ethereum’s whitepaper…

In Ethereum, the state is made up of objects called “accounts”, with each account having a 20-byte address and state transitions being direct transfers of value and information between accounts. An Ethereum account contains four fields:

- The nonce, a counter used to make sure each transaction can only be processed once

- The account’s current ether balance

- The account’s contract code, if present

- The account’s storage (empty by default)

“Ether” is the main internal crypto-fuel of Ethereum, and is used to pay transaction fees. In general, there are two types of accounts: externally owned accounts, controlled by private keys, and contract accounts, controlled by their contract code. An externally owned account has no code, and one can send messages from an externally owned account by creating and signing a transaction; in a contract account, every time the contract account receives a message its code activates, allowing it to read and write to internal storage and send other messages or create contracts in turn.

And using this new definition of accounts and state transitions (which is also explained in detail with this paper), Ethereum proposes an entirely new definition of transactions:

The term “transaction” is used in Ethereum to refer to the signed data package that stores a message to be sent from an externally owned account. Transactions contain:

- The recipient of the message

- A signature identifying the sender

- The amount of ether to transfer from the sender to the recipient

- An optional data field

- A STARTGAS value, representing the maximum number of computational steps the transaction execution is allowed to take

- A GASPRICE value, representing the fee the sender pays per computational step

The first three are standard fields expected in any cryptocurrency. The data field has no function by default, but the virtual machine has an opcode which a contract can use to access the data; as an example use case, if a contract is functioning as an on-blockchain domain registration service, then it may wish to interpret the data being passed to it as containing two “fields”, the first field being a domain to register and the second field being the IP address to register it to. The contract would read these values from the message data and appropriately place them in storage.

See the difference? Ethereum’s definition of those same concepts within the blockchain are very different from those of Bitcoin’s, because Ethereum is a generalized ledger designed for general-purpose computation tasks while Bitcoin is solely focused on processing value transfers. Rather than defining a “transaction” as a single-purpose signature that makes up coins, Ethereum treats them as a state transition — yes, that state that CS students all love from a compiler construction lecture — that is simply “executed” on the platform, just like when you open Google Chrome on your local computer.

This state transition is made out of accounts, which hold and control the actual Ether balance. These accounts may also hold contract code, which is executed when a transaction is made to the account that holds them, and may also write to its storage in the process. The actual balance number that is recorded within those accounts is Ether, which is the very definition of “coins” with the Ethereum blockchain (instead of a group of transactions, as of with Bitcoin). Ether is also defined as a “fuel” for running these state transitions on the Ethereum blockchain, which is also different from Bitcoin’s definition of its coins that are simply… “digital coins” that represent value in itself. This is why Ethereum is often known to follow an “account-based” model, rather than “UTXO-based”.

The point I am trying to make here is that even though the definition of a “blockchain” may be similar at the concept level, the actual details may differ significantly based on what they actually want to achieve with the concept. As explained above, the goals of Bitcoin and Ethereum were completely different, and thus they started with very different definitions of the same concept. This is why they resulted in two distinct blockchain designs that are not compatible with one another.

It’s the same thing with EOS, and basically any other blockchain project you may be able to think of. If they have different definitions of the problems they want to solve, they will eventually have different definitions of their concepts, which will inevitably lead to different design choices and an entirely different end product. What’s the use of attacking one another based on their design philosophy when they had different definitions of a “blockchain” in the first place?

The same also applies to another very important concept here, and that is…

2. Decentralization

Same question here: what exactly is decentralization?

With this one, I have received even more varying answers than the blockchain question. No one could give a consistent and clear answer — they all had their own, different vision on how blockchain can completely change the future of the Web, but when they were asked about the specifics… no one was really sure about what the future of this industry could possibly look like. All of their answers were vague without a clear direction, and had extremely varying opinions on the ultimate “level” of decentralization that a blockchain project should set as a goal, including myself.

That is the most significant problem that I am seeing here: no one is really sure about what “decentralization”, a core value of a blockchain, even is. If there is no clear consensus on this concept, reaching an agreement on the “decentralization level” that blockchain projects should pursue will be impossible.

To get a glimpse of just how complicated this idea is, let’s first turn to the Holy Bible of the blockchain world — the Bitcoin whitepaper. Looking at the Introduction of this holy whitepaper:

Commerce on the Internet has come to rely almost exclusively on financial institutions serving as trusted third parties to process electronic payments. While the system works well enough for most transactions, it still suffers from the inherent weaknesses of the trust based model. Completely non-reversible transactions are not really possible, since financial institutions cannot avoid mediating disputes. The cost of mediation increases transaction costs, limiting the minimum practical transaction size and cutting off the possibility for small casual transactions, and there is a broader cost in the loss of ability to make non-reversible payments for non- reversible services. With the possibility of reversal, the need for trust spreads. Merchants must be wary of their customers, hassling them for more information than they would otherwise need. A certain percentage of fraud is accepted as unavoidable. These costs and payment uncertainties can be avoided in person by using physical currency, but no mechanism exists to make payments over a communications channel without a trusted party.

The important point to note here is that the whitepaper only discusses the issue with centralization with financial institutions, and wholly focuses on processing electronic payments without those intermediaries. This concept was very appealing back in 2008 because of the subprime mortgage crisis, which crashed many financial institutions and greatly hurt the entire global economy as a result. Trust on traditional financial institutions were sharply falling those days, and that definitely played an important role with the idea of Bitcoin growing very popular between enthusiasts and early adopters.

Those concepts were later expanded with other Bitcoin forks that attempted to bring “decentralization” to other areas, such as Namecoin, and then exploded in popularity when Ethereum was first announced. The idea behind Ethereum was, of course, to bring this idea of decentralization and trustless environments enabled by the concept of a blockchain to much more generalized use cases, such as an automatically executing contract.

But as seen from the Bitcoin whitepaper, where all of those concepts and ideas first originated, there is no mention of a “generalized” form of decentralization — it only mentions decentralization in a financial context. This is very much expected because as explained previously, the definitions and assumptions for a “blockchain” with Bitcoin is solely focused on exchanging value. This means that a “single source of trust” for the concept of decentralization does not exist, and that people are defining their own concepts to justify the directions they are taking for their own project.

And that is completely normal. Remember what happened to the communist movement: Marxism is without doubt one of the most well-designed economic utopias on paper, but when the movement started to overthrow existing governments and form a communist one, it started to turn into a nightmare. People all had their own, different definitions of what an ideal communist society should look like, because the ideology that they were following did not give them detailed instructions on operating governments, and that eventually led to extreme conflicts and a complete dictatorship. Yet some nations have started to apply those ideologies on top of existing capitalist systems in the form of welfare, and some people still study Marxism today as a serious discussion point on the future of our society as a whole — only because the direction and ideology that it suggests is definitely worth considering, even nearly after 150 years since Das Kapital was originally published.

Same with blockchain. Whitepapers and the idea of “decentralization” are just ideologies that only exist on paper. They definitely suggest a clear direction for a better future, but that does not mean we have to take it word for word. It is only natural that different people have different definitions and specific strategies in achieving that ideology, whether that strategy towards that ideology is drastic or gradual.

3. It’s time to define our own path

What does all of this mean for the industry as a whole? Simple: don’t waste time fighting with other projects with different goals. Just focus on building your own product.

There is no such thing as a single, fixed definition of a blockchain or “decentralization”. Each of us can, and should, build upon this ideology to create something that fits our own goals, not somebody else’s.

Even I do not personally prefer DPoS-based chains, they are definitely much faster than anything else that are currently out there on the market. This simply mean they have a goal of bringing powerful “decentralized” applications to the masses. They are not a “traitor” to this ideology, it’s just that we have different ideas and definitions on how things should work on the blockchain.

I would rather spend my time building on my own stuff that fits my own “decentralization” ideology, rather than condemning and attacking other DPoS chains for their “crappy centralized block producers”. Because you know what? You do not choose who the winner is. The market does.

So, let’s see who wins. We firmly believe that solutions focusing more on keeping permission-less and more equally distributed conseusus mechanisms will eventually be the champion. That is why we still work on all of these sophisticated tech that might seem useless to centralized people, because that is our definition of a “blockchain” and “decentralization”.

Back to work, guys. For a brighter future.