<div dir="ltr">Dear Fransisco,<div><br></div><div>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: </div><div><br><div>Back to basics: <div>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. </div><div><div><br></div><div>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. <br></div><div><br></div><div>(sorry for very brief, informal, personal definitions).<br></div><div><br></div><div>Some brainstorming:</div><div>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.</div><div>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.<br></div></div><div>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). </div><div>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. </div><div><br></div><div>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. </div><div><br></div><div>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?</div></div></div><div><br></div><div>Cheers,</div><div><br></div><div>Ersin</div></div><div class="gmail_extra"><br><div class="gmail_quote">2018-01-08 20:21 GMT+03:00 Francisco Hernández Parga <span dir="ltr"><<a href="mailto:f.hernandez.parga@gmail.com" target="_blank">f.hernandez.parga@gmail.com</a>></span>:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Which aspects of the Blockchain or DLT (Distributed Ledger Technology) can be centralized, decentralized or distributed?<br>
______________________________<wbr>_________________<br>
The cryptography mailing list<br>
<a href="mailto:cryptography@metzdowd.com">cryptography@metzdowd.com</a><br>
<a href="http://www.metzdowd.com/mailman/listinfo/cryptography" rel="noreferrer" target="_blank">http://www.metzdowd.com/<wbr>mailman/listinfo/cryptography</a></blockquote></div><br></div>