[Cryptography] Decentralized Vs Distributed Blockchain

[Ersin Taskin]

Dear Fransisco,

I am working on a paper proposing a new protocol to Bitcoin. That answers
your question in more detail. I will share with you a draft. In the
meantime, I am tired of coding non-stop for a long time and I wanted to
give a break writing below:

Back to basics:
The basic logical components of a distributed ledger system are the initial
conditions, the log, the state, the transactions, the nodes and the agents
(client/processor) (key pairs/addresses, IDs, hash-pointers, IP addresses,
etc.). A transaction is what changes the state of the system.  The log
(ledger) is an ordered list of transactions. The state is the minimum
information that describes the system at a given time (snapshot) fully so
that we can deterministically compute the next version through a valid
transaction. The state beautifully describes our context. It is the model
of the system instance providing the snapshot.  As a result, given the
initial conditions and the ordered log of transactions you get the system
state at any given time.

In Bitcoin (as the most famous example) the genesis block is the initial
conditions, the block-chain is the ledger of the system and this makes it
the log. The UTXO Database is the state (who owns what), Bitcoin
transactions are the transactions, Bitcoin private and public keys and the
addresses formatted from public keys are the key pairs/addresses. Then we
have the IP addresses of the nodes etc.

(sorry for very brief, informal, personal definitions).

Some brainstorming:
1. Key pair creation can be a decentralized process thanks to the practical
impossibility of collision (we randomly select very high numbers from an
unfathomably large value space). Key-pair usage can also be decentralized.
We can have sort of centralization/organization/hierarchy for
efficiency/implementation purposes though.
2. The log and the state must be replicated across some of the nodes.
Otherwise, the system is not distributed. Not all of the nodes for the sake
of efficiency.
3. Transactions: We need a verification algorithm to decide if a
transaction is valid and can be committed. (a) Is the syntax good?  (b) Is
the signature valid? (c) Is the money, to be spent, present in UTXO? etc.
Some of these questions like (a) and (b) can be answered in a decentralized
manner. The validity of the syntax or the private key does not require
contacting a central authority. However, the question (c) is tricky. We
have to touch the state of the system. Here the question becomes "is this a
double spend" in a cryptocurrency context? This is what made Bitcoin novel.
Solving the double spend problem in a "decentralized!?" manner. I feel bad
about using words like "decentralized" whose meaning is not settled and
defined to the satisfaction of the scientific literature. The Bitcoin
solution based on POW was sort of decentralized at the beginning when
individuals could do mining on their PC's and even laptops at home. But
Bitcoin mining is very centralized today. The majority of the mining
algorithm instances run on machines that do not even hold (and thus check)
the blockchain for a double spend attempt. These miners have outsourced the
task of holding and checking the ledger or deciding what transactions from
the mempool to process to their pool managers. Today a few pool manager
guys literally hold the majority power of POW to prevent double spending
(and also transaction selection).
Let us consider a scenario to check the decentralization of Bitcoin. The
state is the UTXO DB and it is the component that runs on memory, and the
ledger is on disk. For performance concerns, these pool managers' systems
don't continuously check the ledger but the UTXO DB while working on the
next block. Instead, they try to keep the UTXO DB secure once it is formed
from the ledger. If a hacker is able to modify the UTXO DB he can arrange
new checksums to pass integrity checks. He can insert a single UTXO record
to the UTXO DB of a few mining pool managers which run the same system and
form 51% of hash power, then spending that UTXO in a swap transaction set
which may involve sidechains. The transaction will make it to the next
block and cause fraudulent acquisition of assets of innocent people until
the hard fork becomes too obvious and requires the intervention of the
Bitcoin core development team signing the valid checkpoint block against
the longest chain if the mining pools insist on the chain not to lose money
and blaming security issues of the bitcoin development team. Funnily, the
attacker would have the other part of the swap transaction mined on the
other blockchain which makes it completely valid. Indeed, Bitcoin core team
endorses checkpoint blocks periodically as proposed by Nakamoto himself
much later. The ratio of full nodes that check the ledger validity
continuously has dropped tremendously and this is a problem. Can we talk
about the power of POW based decentralization for security here? We have
two central authorities in this scenario: The mining pool managers and the
Bitcoin core development team. You can think of other scenarios
illustrating centralization in Bitcoin. We will have the same power
consolidation process in exchanges when evolution towards centralization
will be obvious there too. Exchanges are sooo important and soo powerful.

This is the heart of the decentralization and trustlessness issue in the
cryptocurrency context. Can we obtain a decentralized/trustless way to
prevent double spend? If we can achieve a unique ordering of valid
transactions we can reject the second attempt of spending the same token.
This is the distributed consensus problem. How do we achieve consistency in
the state of the system? We are limited to the CAP Theorem. We can relax
Consistency and have eventual consistency. This is what Bitcoin does. At
any given point in time different clients can see different block-chain
versions, however, if we wait enough (long in Bitcoin), we hope that all
these forks will unite. However, no matter how eventual, consistency
requires determinism which requires authority. Authoritative components of
algorithms at runtime. Let me repeat: We need authoritative algorithms to
get determinism. Authoritative algorithms don't materialize and run
themselves. We need authority resources to run these algorithms. This
dictates that a degree of centralization/authority/trust-resource is
inevitable. I use the term "anchor" in my paper. Anchors may involve secret
keys. And for the sake of robustness, the system will evolve to more
hierarchical. Remember that Internet itself started as Peer-to-Peer and it
got sooo hierarchical. Same happened to e-mail. Today e-mail routing,
storing and using all happens in the cloud on a deep hierarchy of
organizations/servers, etc. Today we can't help deep surveillance by a
handful of companies.

The above was brainstorming introduction to relaxing the
decentralization/trustlessness myth. I think this is what is needed to
start designing a robust DL or Blockchain system. I think this is why the
most famous BC implementation is not robust. I think the heart of the
problem is the distributed consensus algorithm. This is where we see a lot
of paper/patent activity recently. I started using eyeglasses last month
because of them:) Why in the world do they print those papers like that?

Cheers,

Ersin

2018-01-08 20:21 GMT+03:00 Francisco Hernández Parga <
f.hernandez.parga at gmail.com>:

> Which aspects of the Blockchain or DLT (Distributed Ledger Technology) can
> be centralized, decentralized or distributed?
> _______________________________________________
> The cryptography mailing list
> cryptography at metzdowd.com
> http://www.metzdowd.com/mailman/listinfo/cryptography
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.metzdowd.com/pipermail/cryptography/attachments/20180110/a761ff80/attachment.html>