A blockchain is a specific set of choices suitable for a narrow set of use-cases
<i>As original link is not available, posting the content from Google Cache for future reference</i><p>Thread by @clemensv: &quot;I&#x27;ve talked to a lot of distributed systems engineers (who build cloud-scale stuff) from across the industry about blockchain. While most pl […]&quot;<p>I&#x27;ve talked to a lot of distributed systems engineers (who build cloud-scale stuff) from across the industry about blockchain. While most platform folks I talked to are perfectly happy to help with frameworks that help selling product or services, ...<p>... and some even rode the crypto wave to make some hay, I have a hard time finding people in the distributed systems platform community who believe that blockchain is even remotely as significant as the hype wants to make us believe.<p>Engineers at the center of the industry understand the qualities of append-only logs, understand signatures and non-repudiation, and understand consensus protocols. They understand that those are a few building blocks from a large toolbox and that there are choices for each.<p>A &quot;blockchain&quot; is a specific composition of specific choices for these building blocks that&#x27;s suitable for a fairly narrow set of use-cases. The blockchain-specific consensus models are tailored to (a) all-around lack of trust and (b) convergence to a singular global log.<p>Convergence to a singular global log with many candidate writers and many replicas makes it hard to reach consensus and for that consensus to be propagated; PoW or PoW+PoS (cleverly) solve that by being intentionally slow.<p>The PoW lottery is probabilistically set up so that a singular mining winner can emerge and its winning block can be propagated throughout the network before another miner finds a competing solution (there can be many valid ones). The enabler for that is a time window.<p>The tradeoff the &quot;nobody is trusted&quot; blockchain model makes, is that it literally trades trust for time. It&#x27;s slow by design. Giving consensus forming ample time is foundational. (I&#x27;ll be happy to hear arguments that prove the contrary).<p>Once parties trust eachother to faithfully collaborate, the existing consensus models that we all use to build hyper-scale cloud systems become applicable and those can resolve even complex and contested consensus problems in a few milliseconds, largely gated by network latency.<p>Even if there&#x27;s no all-around trust, there&#x27;s often a neutral party that can supervise a transaction of two parties that don&#x27;t trust eachother, but who each trust that party. &quot;Sidechains&quot; and &quot;Private permissioned blockchains&quot; are playing that trick.<p>However, once there&#x27;s a trusted neutral party, that trusted neutral party can already establish non-repudiation by forcing authentication&#x2F;authorization along with a content signature and only ever allowing appends. With any regular old database that the neutral party maintains.<p>The world&#x27;s economy today is built on the very principle that accounting records are both safe from deletion and immutable in digital accounting systems. There&#x27;s a clear sense of order. They are written to audit logs for non-repudiation proof.<p>The cryptographic chaining of records is a good idea to strengthen the immutability of the ledger as a whole, but it&#x27;s not really superior to holding a ongoing full copy of the ledger in safe escrow. A signature chain can be done on any existing database.<p>The single global log requirement and therefore the global consensus problem completely falls apart in all cases where the problem is partitionable (FWIW &quot;sidechains&quot; are partitions). Turns out, that&#x27;s true for most problems, otherwise nothing would ever scale.<p>Once you can use partitions, the consensus scope shrinks to the scope of the partition. When you transfer money from your bank account, the intial scope is just your bank, with the initial transaction to a clearing account. (FWIW, a &quot;sidechain&quot; is a clearing account). Easy.<p>For those familiar with (shall I say &quot;classic&quot;?) distributed systems architecture, it&#x27;s amusing to see things like &quot;sidechains&quot; with local trust relationships emerge, because they are nothing but a reaffirmation of the partitioning principles foundational for a functional economy<p>Yes. The combination of decentralized operation, variable trust, and non-repudiation is very attractive. The world already works like that. There are easily 15,000+ banks globally and countless more businesses that maintain various ledgers. That&#x27;s hardly &quot;centralized&quot;.<p>&quot;Centralization&quot; is not when 15000 organizations are federated such that you can transfer funds between them. Yes, you need a banking license and audit in the local jurisdiction to be a bank. Because, as we see, some people are happy to separate other people from their funds.<p>The specific combination of well-understood architectural building blocks that make up &quot;blockchain&quot; is very well applicable, but nearly exclusively applicable to all-around trustless global ledger accounting problem (e.g. &quot;coins&quot;).<p>Any other set of requirements is likely better addressed using a different combination of elements from the broad toolset that exists across the distributed systems platform landscape today. &#x2F;fin<p>PS: I&#x27;m not an ideolog on this matter. If you&#x27;re convinced that you need a blockchain, I&#x27;ll surely help with the communication path if asked. I have the finest shovels.<p>Clemens Vasters 🇪🇺 (@clemensv)