There’s no design published on the public Internet for a blockchain, DAG, or other variant of a distributed ledger which has all three qualities: scalable, decentralized, and secure. Also we’d like real-time, sub-second transaction confirmations. Bitcoin certainly can’t scale-out decentralized. Bitcoin was designed to be a surreptitious winner-take-all paradigm. Lightning Networks also won’t scale-out decentralized.
Here’s my compendium of research and analysis of the various extant, published attempts to design a secure, decentralized, and scalable ledger consensus system. I’ll reveal some of my formerly secret designs, insights, and exemplify the depth of my expertise. But I will withhold some of my best gems for just a little while longer.
I’ve been needing to write this blog for some time now given that I was researching this topic since 2013 with the intent to design a solution to this challenging problem. I’ve been slowed down considerably by a chronic health ailment (c.f. also).
This blog was instigated by a recent discussion with @tenpoundsterling, which was followed by a myopic, incorrect Medium blog extolling QuarkChain as a worthy design.
The essence of the security of the QuarkChain ledger consensus system is presented in §3.4 Consensus Algorithm on pg. 19 of the whitepaper.
In 2015, I had contemplated this (c.f. also) exact design of a root (master) layer proof-of-work blockchain controlling numerous proof-of-work blockchain shards. I quickly discarded the design idea because it’s so egregiously insecure.
And sub-seconds confirmations aren’t possible in proof-of-work because the block period must be orders-of-magnitude greater than the network latency (and network latency isn’t scaling by Moore’s law). Otherwise the orphan rate becomes too high (c.f. the derivation) such that the chain might not even converge on a longest.
The QuarkChain whitepaper claims that the percentage of hashrate needed to double-spend drops from just over 50% in Bitcoin’s Nakamoto proof-of-work to (at worst1) just over 25%, which is already a horrible reduction in security (and selfish mining would be 17%). But the actual security is even worse.
There are numerous game theory security vulnerabilities related to incentives compatibility, transaction fees, and the ability of the miners to move their hashrate around at-will between root chain and any of the shards. Which include vulnerabilities similar to those that Byzcoin attempts but fails to fix about Nakamoto proof-of-work, as well as the failure modes of Byzcoin which I cited in my analysis of OmniLedger. Additionally I describe another vulnerability as follows.
Unlike with Nakamoto proof-of-work where all miners have a vested interest in not defecting and they all thus validate the blocks of each other, QuarkChain destroys that Nash Equilibrium because with control just over 50% of the hashrate of a shard, the attacker can censor shard transactions and/or extort high transaction fees. With 10 shards splitting 50% of the system hashrate that remains from the 50% for the root chain, the attacker would only need 5% of the system hashrate to wreck such havoc. With 50 shards, the attacker only needs 1% of the system hashrate. Rented hashrate attacks on proof-of-work altcoins are quite plausible. Verge is a recent example that such attacks aren’t just theoretical.
To prevent DoS attacks which destroy the scalability of the sharding wherein an attacker simultaneously issues a transaction to spend on every shard (note for scalability that shards don’t validate other shards and root chain miners don’t validate any shards), the hostage UTXO must only be spent on another shard after recording in the root chain a lock commitment. The committed shard can then validate the hostage UTXO lineage before accepting the transaction. Yet the attacker’s hashrate could move to the targeted shard to sustain the censorship/extortion indefinitely.
The double-spending protection claimed by the QuarkChain whitepaper is impotent against the above attack, because it only records the shard’s block hashes in the root chain. Only the shard’s miners validate and determine the contents of the blocks in the shard.
Merkle tree based fraud proofs issued by honest observers can’t prove anything about censorship of transactions.
Presumably as a coordination mechanism to override the above attack, QuarkChain proposes the mechanism of super-nodes in §5.1 Horizontal Anti-Centralization Scalability Expansion on pg. 24 with the union of super-nodes providing validation for the root and all shards. What the QuarkChain designers apparently don’t realize (or don’t want us to realize) is that these super-nodes must collectively possess just over 50% of the system hashrate for their decisions on validation to be adhered to. So in essence QuarkChain must be run by an oligarchy of whales who coordinate their validation of the entire system. Centralizing a ledger is a way of obtaining scalability, yet a distributed and centralized database isn’t accomplishing anything for trustlessness and permissionlessness. The antifragility vulnerabilities of centralized cartel control are:
a single-point of weakness that can be attacked, e.g. by the government regulators.
the cartel wants to maximize the extraction of rents from the system.
such maximization may turn against the best interest and desired features the users of the system want and need.
OmniLedger which I analyze below resolves this problem by creating shards which have a PBFT consensus algorithm instead of proof-of-work (which has a higher security threshold of 67%) and the set of validators is randomized2 so that the attacker can’t target a specific shard so as to weaken the security below that of the root chain’s 50% proof-of-work security threshold. One disadvantage of the OmniLedger design is that the liveness drops to 33% which is one of the weakness of any deterministic Byzantine agreement protocol such as PBFT.
As shocked as I am that (Ethereum's Casper design team lead by) Vitalik expended 3+ years to produce a totally flawed slashing proof-of-stake design (c.f. also), I am perhaps even more shocked at the blatantly obvious insecurity of the Quark[Quack]Chain design considering the number of PhDs listed in the §9 Development Team on pg. 35 and §Advisors on pg. 37. But really this should be expected from an opportunity cost economics analysis in the current gold-rush FOMO (fear-of-missing-out) race to extract a slice of the greater fool, agape n00bs speculative bubble. Even dozens of celebrities are pimped in the gold-rush.
Seriously, QuarkChain is more or less as useful as any of the series of shitcoin parodies such as the 100% Useless Token and those [ANN]ounced by the outrageously hilarious Gleb Gamow, which include the Bitcoin Pussy “The Wife of Dick” and YuTü.Co.in “Catering to YouTube 📷 Creators”.
As I proceed below responding to the QuarkChain whitepaper’s summary analysis of competing attempts to design a scalable, decentralized, secure ledger consensus system, I’ll explain the tradeoffs in the extant, published designs for other projects such as Bitcoin (Nakamoto proof-of-work), Lightning Networks, Ethereum, EOS (DPoS including STEEM) , OmniLedger, and other proof-of-stake derivatives such as NEM, Nxt, NEO, Qtum, etc.. And hybrids such as Dash and PIVX.
In a subsequent section I’ll cover the DAGs such as Byteball, Hashgraph’s Swirlds, Iota, and SPECTRE. And finally hopefully I will add a section on reputation-based designs such as Radix (formerly named Emunie) and Stellar’s SCIP consensus systems.
1 The 25% presumes a large number of reasonably equivalently hashrate weighted shards that divides the other 50% into a very small percentage. Thus the 25% rises to for example ~30% if there are only 10 shards. That is in the presumptions of their (incomplete and inadequate) conceptual security model.
2 Note it wouldn’t be secure to randomize the validator sets for the proof-of-work shards of QuarkChain because unlike deterministic Byzantine agreement protocols, proof-of-work isn’t one vote per cryptographic identity (i.e. per validator). There’s no way to limit or know the hashrate of each such identity and that’s why it’s useless to even assign identity to miner validators in proof-of-work.
Quoting from §2.2 Decentralization issue on pg. 12:
The mining pool encourages centralization and becomes a risk for decentralized POW blockchains.
Incorrect. POW mining pools (such as for Bitcoin) are not winner-take-all nor are they a sustained 51% attack risk, because individual miners can change pools. There’s even the getblocktemplate pool protocol which can enable the individual miners to choose which transactions go into the block they mine. Also there’s P2Pool but it can in theory be DDoS delayed and would have non-optimal performance if attacked. Yet none of these decentralization protocols are significantly used because they’re unnecessary per my first sentence and the more straightforward protocols work best.
Rather as I explained why recently for 
The thing is, you can't centralize something that is inherently distributed
Nonsense. Understand the distinction between the meaning of the terms ‘decentralized’ and ‘distributed’. Decentralization refers to the concept of who controls what. Distributed refers to the topology of the nodes of the network. If 51% those nodes are surreptitiously controlled by the same entity, then the blockchain is entirely centralized. With selfish mining that threshold drops to 33%.
Also I debunked the POW as space heaters argument in an excerpt from a late 2016 rough draft of the CRED project’s forthcoming whitepaper. I also explained the aforementioned power vacuum economics as an abstract macro-economics concept.
This combined with other factors such as:
Satoshi’s intentional meticulous design of ASICBOOST (c.f. a more direct link).
Satoshi meticulously designed hashed public-key addresses to protect private keys against quantum computing thus surely knowing Nakamoto proof-of-work is vulnerable to a long-range attack by future quantum computers but never mentioned it. This is summarized (archived) in a bitcointalk.org response to @tromp.
Satoshi insinuated he could raise the 1MB block size to squelch/suppress the rising apprehension/inquisition but then he didn’t actually raise it.
Are why I have concluded that “Satoshi Nakamoto” was a pseudonym obscuring a secret task force of the “Satan’s global elite” and Bitcoin was mostly likely designed by the global elite in order to surreptitiously foist a world central bank by way of creative destruction of their own nation-state central banks. Note the natural law’s (i.e. collective human nature and physics of the universe) “Satan” wants to own your soul with the coming 666 system and thus Satan’s global elite always must give you your free will and allow you to choose to enslave yourself. Thus Satoshi never outright lied, but rather employed double-speak and deceptive truths. He was perfectly accurate with exquisite, meticulous attention to detail.
Click all my links if you want to more deeply grok the summary I have written here.
Quoting from §2.3.1 Multiple blockchains on pg. 13:
Having multiple blockchains also limits cross-chain transactions to [centralized] cryptocurrency exchanges which charge trading fees, have long processing times, and are notoriously
unsecure[insecure].
Not entirely correct. Secure and decentralized cross-chain transactions can be achieved:
A cut-and-choose protocol can be employed to enable decentralized verification that there’s no fractional reserves and centralized exchanges actually control the tokens which they claim they do. But that doesn’t prevent the centralized exchange from being hacked (by itself lol). The insecurity of cryptocurrency held (for any appreciable length of time) by centralized cryptocurrency exchanges can be fixed with an innovation I contemplated but have not yet implemented. A Hashed Time Locked Contract (HTLC) can be employed which only allows the committed tokens to be spent to the exchange and no other third party. Essentially this is analogous to a dedicated Lightning Networks (LN) connection between the exchange user and the exchange. The user can then trade these tokens instantly on the exchange by issuing a signed transaction to the exchange. Due to the HTLC commitment, the exchange knows the funds can’t be double-spent to another party before that transaction is confirmed in the blockchain which thus enables instantaneous confirmation upon receipt of the signed transaction from the user.
However, in that simplistic design the exchange has possession of the tokens for brief time until it issues a corresponding HTLC payout of the traded tokens to both (all) parties of the trade. More ideally would be cross-chain implementation of the LN protocol which would remove ownership control from the exchange and merely have it acting as a liquidity provider hub to facilitate the HTLC channel trade transactions between the end users. This however will introduce a different form of risk in that the security becomes vulnerable to either of the blockchains in the transaction becoming compromised by an attacker. Yet that risk is probably small when trading between secure pairs. And this security risk doesn’t metastasize as a domino insecurity effect through all trades ever completed as is the case for side-chains that share the same (i.e. fungible) token. Deploying LN for his use case seems to be beneficial unlike the problems with the general deployment of LN discussed in this blog. ZigZag is an example implementation purportedly employing the LN protocol for the exchange so that the traded tokens instantly change hands on both sides of the trade without the exchange ever having ownership control. Regulated exchanges may not be able to adopt the current LN protocol because of lack of KYC/AML compliance, although this LN protocol design perhaps could be altered to carry KYC information.
The aforementioned LN solution for exchanges has the advantage of fast, highly liquid trades, but it has the disadvantage of relying on a centralized hub to serve as the liquidity provider which means it will take fees and it could enforce KYC, break anonymity, and otherwise be regulated by authorities, even though it would be secure.
I had explained in early 2016 that @TierNolan’s proposed decentralized, atomic, cross-chain transaction protocol could be indefinitely jammable because a race condition existed wherein there was no way to prevent the attacker from repeatedly refusing to release the signed transaction and re-entering every transaction the honest party offers. I rebuked the proposed solutions:
Forfeiting a deposit risks the honest party’s deposit because there’s no 100% reliable/objective way to differentiate between a network outage and an attacker that refuses to send. Moreover, the jamming problem arises also on the commitment of the deposit to the specific trade, so it solves nothing.
Requiring all parties to have reputation (and Coin Days Destroyed) equates a newbie with an attacker and prevents them achieving a reputation. Also reputation is centralizing too-big-to-fail and domino-effect antifragile as I explained to @tenpoundsterling in the context of rebuking the Hashgraph concept.
If the jamming problem of the commitment of the deposit could be solved (but I highly doubt that), then a proposed solution could be that newbies risk deposits (to presumably rare network outages) in order to obtain reputations, after which time they wouldn’t need to deposit. But reputation breaks anonymity, which is important for even for businesses who don’t want the competition tracking all their trades and potentially for achieving their privacy policy. It might be possible to achieve homomorphic encryption of reputation analogous to how Zcash works for transaction data, but even if this vaporware is possible it would not a protocol which every blockchain would support now and the overhead of such technology is currently onerous.
In early 2017, I devised a simplified protocol for truly trustless, decentralized cross-chain trades which removes the jammable race condition. I publish it widely now for the first time (had originally published it to a Pastebin which I think not very many people were aware of). The HTLC escrow requires OP_CHECKLOCKTIMEVERIFY (OP_CLTV) (which was introduced into Bitcoin by SegWit) on every blockchain for the token of the bidders. This protocol can’t be achieved with nLockTime. The ask side of the trade must be on a blockchain (or any form of decentralized ledger) which implements the following protocol. The asker issues an ask offer open to all bidders and this is confirmed by the ledger. The ledger is then able to automate the release of tokens being offered by the asker if a bidder’s transaction is confirmed. Thus the bidder has no risk of the asker jamming the trade by refusing to release the signed transaction.
Multiple bidders may commit to a HTLC on the blockchain for the token they’re offering. Bidders which are not chosen to complete the trade are refunded automatically by the HTLC. The ledger for the ask side selects and commits to one of the bidders. The chosen bidder must release the signed transaction before the ledger for the ask will release the tokens. The bidder can trust the ledger because by definition a decentralized ledger is trustless and always fulfills the protocol.
The bidder could fail to release (and obtain a refund via the HTLC) but this is not the race condition of @TierNolan’s protocol, because there’s already a list of alternative bids confirmed on the bidders’ blockchain which the ledger for the ask side can opt to next. The attacker would have to get to the back of the line to re-enter the same attack. Thus if even one of the bidders is honest, then presuming the time lock duration is sufficient to try all the bidders, then the trade will succeed (after some delay) and not be indefinitely jammed.
Also my proposal requires only very little delay to wait on the bidder to release the HTLC solution, thus can cycle through the bids much faster. Also the bidder's funds are locked up for some time before they are refunded so this isn't cost free (time opportunity cost) for the attacker. Also bids in the same block could be prioritized by the ones with the longest refund time, so that time opportunity cost can be ramped up as needed to squelch attacks. This is a clever solution to @TierNolan’s ingenuous but flawed concept.
The aforementioned LN solution for exchanges also has the disadvantage compared to centralized exchanges that many traders want to employ leveraged margin and/or to sell short. So the greatest liquidity will be on exchanges that offer margin and short-selling, but DEX isn’t compatible with these features for the analogous reason that pegs aren’t stable.
Must have another token to borrow to go long, and to sell to (or at least a price feed for settlement) for long and short margin trading respectively. A blockchain could have two tokens, but that would really be the same as different assets. Bitshares' tried to solve this problem by pegging external assets but all pegs are unstable and eventually fail.
Settlement ordering of trades (and also w.r.t. to who is providing price feeds if using those as documented as problematic in Steem’s whitepaper) can be gamed by the witness, miners, or whom ever is ordering the transactions in blocks. Because settlement order moves prices, etc..
Too much leverage in the system can cause margins to be exceeded and those who loaned tokens can lose some tokens. This is analogous to debt defaults due to excess extension of leverage in the fiat world.
The idea of pegged assets (e.g. BitBTC, BitLTC, BitUSD) trading on the same blockchain as a form of DEX is flawed because no peg since antiquity has ever remained stable long-term because pegs increase the profits of those who arbitrage externalities against the peg because stable pricing is not normal so there’s profit to be made in betting against stability. The peg can be attacked by for example taking a leveraged short or long position and then overwhelming the liquidity that maintains the peg. For example, when speculators were expecting a collapse in the price of STEEM, there was an exodus into STEEM DOLLARS (SBD) causing the peg to break. StableCoins proposes to instead allow a band of volatility in the peg in order to reduce the liquidity required to maintain the peg. That has a potential of maintaining the peg longer, but eventually there will be an arbitrage opportunity which overwhelms any meaningful parameters chosen.
Thus Tether (USDT) is corrupt. One can surmise that the likely way they got exchanges to use it, is by sharing the fractional reserve pie with the exchanges. When USDT fails that could cause another cryptowinter.
Without short-selling, the OTC (i.e. DEX) markets can go no bid. While OTC markets function well during normal times, their lack of transparency can cause a vicious circle to develop during times of financial stress, as was the case during the 2007-08 global credit crisis. Mortgage-backed securities and other derivatives such as CDOs and CMOs, which were traded solely in the OTC markets, could not be priced reliably as liquidity totally dried up in the absence of buyers. This resulted in an increasing number of dealers withdrawing from their market-making functions, exacerbating the liquidity problem and causing a worldwide credit crunch.
OTC markets will have huge spreads at times.
People only use OTC markets when they have no other choice, such as to avoid regulations or the only place where certain assets are traded. Because OTC markets have inferior liquidity, spreads, and pricing information (transparency). Thus OTC markets will only be popular when normal exchanges are too painful. If ever exchanges become too regulated to the point where a large number of people want OTC markets, then a DEX will be viable. But not until then.
Leveraged trading is impossible in DEX (will always fail eventually). Thus it is interesting to note that OTC is plausible only in a scenario where centralized exchanges are no longer viable, i.e. seems to correlate well with the slow death of fungible money over the coming decades. So perhaps DEX will become important in coming years. Banning short selling is the fungible money fiat system in its death throes.
Bitsquare is not trustless and requires reputation and security deposits— all of which can fail as already explained.
Quoting from §2.3.2 Lightning Network on pg. 13:
The basic idea is to defer frequent transactions among a fixed group of parties until all parties are finalized with the transactions.
Actually LN can’t function that impractical way where any fixed group (i.e. subset of users of the blockchain) all coordinate to open LN channels (which are variants of the aforementioned HLTC) on the blockchain, such that they’re all reachable to each other within their respective liquidity balances. Payment systems function because anyone can pay to anyone at-will. Instead the only viable way LN can function is (as I @iamnotback explained to the creator of Bitbay David Zimbeck) with the centralization of “Mt.Box” hubs (a term that was coined by the LN’s progenitor) that will allow for existence of fractional reserves analogous to centralized exchanges such as Coinbase. Also the LN routing algorithms are undecidable (or at least impractical) in any purely decentralized formulation. And LN can plausibly steal your funds (c.f. also) even without a 51% attack.
I wrote:
You’re missing the point that LN will not function correctly with many small overlapping circles providing the chain of connectivity from end-to-end for any user-to-any-user. The routing algorithms are implausible in that configuration. And there’s a bottleneck in liquidity because the distribution of fungible resources is not uniform nor even a bell curve in nature, but rather power-law distributed. So these chains of illiquid circles can’t handle the require liquidity surges. Also in order to significantly reduce the load on the blockchain, then there needs to be huge centralizing “Mt.Box” hubs […] that will allow for existence of fractional reserves analogous to centralized exchanges such as Coinbase […] For these and many other reasons, LN is a centralizing, fractional reserve system that can significantly accelerate the inevitable “winner-take-all” centralization of Bitcoin.
In an excerpt from a late 2016 rough draft of the CRED project’s forthcoming whitepaper, I cited explanations of these points which provide more detail and also the fact that settlement to the blockchain also requires coordination otherwise chaos could result such as random spike transaction loads which are higher than without LN.
Additionally as I had pointed out in one of my 2016 blogs, the SegWit “anyone can spend” addresses incentivize the formation of mining cartels because the 51% attack is amplified from formerly being only able to censor transactions3 to stealing the SegWit transactions. This potential theft of LN transactions is distinct from the risk which I already mentioned (before the quote above). Possibly LN can be designed not to employ SegWit but even so there’s nonzero risk in such a complex design of some inherent game theory or protocol design flaw could amplify the 51% attack to theft capability is another way as exemplified when I discovered that @TierNolan’s cut-and-choose protocol so elevated the 51% attack to theft capability.
3 Don’t equate a 51% attack which attempts to change the protocol with one which steals, because the former is an objectively visible fork which users can choose to not follow and the latter is not objectively discernible (← links to an excerpt from a late 2016 rough draft of the CRED project’s forthcoming whitepaper). With enough users complaining that their funds were stolen or with evidence of a very long-range chain rollback, the community might presume an attack has occurred but it can’t be unarguably and objectively proven that the users are not lying. The attacker’s fork may present many other users and alternative community archives of chain history which show they’re being stolen from if the orphaned chain were to be followed. The only objective truth is the longest chain.
Then one of the parties would just post the final result without incurring multiple historical transactions on chain.
LN really doesn’t propose the perfection of only one on chain settlement transaction per grouping. Rather it proposes that the number of on chain settlement transactions will be much lower on average than would have been required otherwise. Note my aforementioned issue with spike loads potentially being higher, especially if highly centralized “Mt.Box” hubs aren’t coordinating their on chain settlements.
However, the Lightning Network is only suitable for frequent transactions among a fixed group of parties, while it is inefficient if a user’s transaction target is random and happens sporadically.
That’s correct, except centralized “Mt.Box” hubs can make it suitably efficient but at the detriment of the loss of antifragility via centralization, fractional reserves, and thus eventually loss of funds via bank runs, theft, or government confiscation/regulation of hubs.
This prompts the question whether it is necessary to build another centralized payment method when there are already many out there.
Of course it’s necessary because it’s the competition over whom is going to winner-take-all the Bitcoin blockchain which is perhaps the future international reserve currency (or one of the currencies/commodities that will be in the an IMF weighted basket). Understand the actual game ongoing. The Bitcoin blockchain has international scale and wrecks jurisdictional arbitrage havoc with the regulations of nation-states.
Quoting from §2.3.3 Sharding on pg. 14:
Ethereum has adopted sharding technology to scale out, and its phase one development is near completion.
In addition to sharding, Ethereum is[was?] also planning to adopt a variant of proof-of-stake originally name Casper which has a slashing design that proposes to confirm concurrent blocks presumably to lower the confirmation time and increase throughput. However, yesterday I wrote five shocking comments (1, 2, 3, 4, 5) on Vitalik’s Medium blogs about this technology. My aforementioned linked comments explain in sufficient detail that Ethereum’s proposed slashing and concurrent blocks confirmation algorithm is fundamentally and irreparably insecure and would also diverge into innumerable forks.
So unless I am mistake in my analyses, before Ethereum can even attempt to institute sharding, they must completely redesign their proof-of-stake consensus algorithm which has already consumed more than 2 years in research. Or adopt some extant scalable consensus algorithm such as DPoS which powers Bitshares, Steem, and EOS. Or OmniLedger. Yet those extant consensus algorithms are also flawed with limitations such as on how low the confirmation latency can realistically be, and flaws of lacking security, antifragility, permissionlessness/trustlessness, decentralization, and/or viable political economics.
However to adopt sharding on an existing blockchain is complicated, and it is estimate to have 3 to 5 more years to go before Ethereum can fully support other fundamental sharding features, such as cross-shard transactions. The main challenges for sharding include cross-shard transactions, security issues like single shard take-over, and further scalability issues.
As I have explained in greater detail within my aforementioned linked Medium comments, in my numerous comments (under my various usernames including @eca.sh, @TPTB_need_war, @iamnotback, @Hyperme.sh, and @CRED.me) in the Ethereum Paradox and DECENTRALIZED crypto currency threads at bitcointalk.com, in a Medium post about Blockstack, and in two threads (#46 and #47) I had started at the Cosmos project’s Github, sharding is inherently insecure against double-spends if there’s one deterministically validated total order (i.e. one consensus) for all the shards. Or stated in another way which will be important for understanding what is different about the consensus algorithm I designed, all shards must be validated by all of the validators from all the shards that participate in the same total ordering (of shards)— which is a requirement that one would think always defeats the entire scalability of sharding. And all the said validators must have sufficient economic, game theoretic incentive not to defect from correct consensus.
I explained in one of my Medium comments that security deposits aren’t a robust security solution because they don’t resolve the nothing-at-stake problem of proof-of-stake. Thus the security of proof-of-stake depends on trusting the whales who control it, i.e. proof-of-stake (including DPoS) are centralized (and distinguish decentralized from distributed) and not trustless, nor permissionless systems.
Sharding exacerbates this weakness because it attains scaling by not requiring every full node to validate every transaction from every shard. Thus sharding introduces the need for full nodes to trust each other. Since security deposits don’t provide a trustless solution when combined with cross-shard (or even cross-side-chain) fraud proofs, we are no longer trusting one oligarchy of whales controlling one shard, but instead trusting potentially different competing or upstart oligarchies who control the full nodes for each shard. Thus sharding is prone to shards forking off the main ledger and chaotic results. Imagine the block size scaling forking wars from 2017 but ongoing and amplified by a factor of 10 or 100 forks. Simpletons would presume that malfeasance can be revealed with fraud proofs, the miscreants punished, and the chain restored to pristine condition. But it’s not that simple. For example, fraud proofs may arrive too late and then there’s downstream and/or conflicting transactions involving innocent parties which depend on not reverting the fraud. The range of potential security and consensus divergence issues are too detailed and numerous to summarize here. My Medium comment elaborates on some divergence scenarios.
These technological problems really are not solvable in any of the designs currently contemplated. Even OmniLedger’s white paper admits it lacks formal vetting on game theory incentives. So sharding is a lie hyped to agape n00b speculators— which experts such as myself know really won’t work unless all the shards are controlled by a centralized cartel. The form of scaling that we’re more likely to get if something like my design doesn’t pan out, is the DPoS-variant in which we trust an oligarchy of whales to duplicate Facebook’s centralized infrastructure and pretend we have decentralization when all we really have is a distributed ledger under centralized cartel control. The antifragility vulnerabilities of centralized cartel control are:
a single-point of weakness that can be attacked, e.g. by the government regulators.
the cartel wants to maximize the extraction of rents from the system.
such maximization may turn against the best interest and desired features the users of the system want and need.
There are also different proposals such as OmniLedger which claims to reach about 100,000 TPS by introducing intricate consensus protocols.
OmniLedger is essentially the same design which I conceived of in early 2016 but which I discarded for a superior design I formulated for the CRED project I’m working on. The summary of my detailed analysis of OmniLedger explains the insecurity and other flaws lurking in the design of OmniLedger. The Byteball Flaws section in Part 2 of this blog elaborates on OmniLedger and DPoS.
In some other cases, a user account is partitioned by introducing sharding; as a result, users may end up having multiple accounts in order to make transactions with others.
Any secure variant of this design such as Elastico (c.f. also) will prevent cross-shard transactions, so it is essentially the same as having tokens on different blockchains.
Any attempt at cross-shard transactions (employing deterministic validation) such side-chain tokens will either be centralized, not be fungible in exchange value between side-chains due to not enforcing a total order, or not secure against losses due to double-spends if there’s one total order (i.e. one consensus) for all the shards!
For example, Raiblocks which Bitcoin Core developer Gregory Maxwell, @monsterer, and myself had debunked in 2015 as being a silly insecure and unsound design.
The masternode scam, non-antifragility, and insecurity.
I won’t waste more ink on that “what’s the most egregious fraud/scam/shitcoin design can we get neophyte greater fools to think is the greatest thing since baloney on sliced bread?” Or IOW, “how much lipstick makes a pig[Dash soda vending machine] fly?”
For anyone with a functioning technological brainstem, it’s cringe worthy amazement that grown men can still be sold snake oil. And what’s more amazing is when they shamelessly defend and promote their unsubstantiated idealism analogous to over enthusiastic, fanatical, evangelizing born again Christians that just rediscovered God.
This blog isn’t about the “To Da Moon” FOMO pump-n-dump speculation value of shitcoins. Masternode deposits tend to lock up much of the token supply thus causing FOMO demand to outstrip token supply on the exchanges, leading to rising prices.
I was sent a draft research paper for this proposed new consensus ledger system. The technobabble in the paper about particles and partial orders may effectively fool agape n00bs, but the key admission that the design must be entirely centralized is in §4. Total ordering of particles on pg. 11:
An important fact to note here is that we are working now on top of the protocol of validating transactions that was built in the previous section, which deals with any fork and double-spending attacks. The only concern of the following algorithm is the exact timings of transactions, not their validity. The algorithm does not require an exchange of any additional information among nodes, the total ordering is computed locally by each node by using only combinatorial properties of posets.
Then by definition different nodes can have different perspectives and thus different versions of the total ordering as is always the case in an asynchronous model which the paper admits in a prior section as follows:
In a non-synchronized network, several consensus participants can create a block at nearly the same time due latency and network topology. Subsets of the network receive and propagate their version of the “valid” block to peers which then leads to a fork […] On the other hand, since Aleph is leaderless, then no single consensus participant will be responsible for establishing the total order. Instead, a committee will agree upon the total ordering according to the rules of the protocol […] This allows particles to validate other particles which are high below them which allows us to validate transactions contained in each particle […] However, some applications require a total order on the particles; hence, we introduce the notion of timing particles that allows us to define a total order. The Aleph Ledger builds on the Aleph protocol by choosing a committee consisting of entrusted users responsible for maintaining constant information exchange, i.e. keeping the stream of particles flowing. Committee composition is updated based on all the users’ votes
So because of the inviolable nothing-at-stake issue that will plague all of (archived) these non-proof-of-work consensus systems, Aleph Ledger is centralized with user voting analogous to the non-antifragile centralization of DPoS consensus system that corrupts Steem, EOS, Lisk, and Bitshares. Readers may read my blog archive if they still do not understand that voting is centralization.
If elections, voting and democracy actually worked, then why are our Western nations so incredibly fucked with corruption, war mongering, debt-to-GDP ratios exceeding 100–300%, tax cuts for the poor, and imminent global economic collapse.
STEEM, Bitshares, LiskIn addition to what I wrote about the DPoS consensus system in the last two paragraphs of the prior Aleph Ledger section, the voting paradigm in DPoS favors the adversaries and oligarchies. The inventor of DPOS Dan Larimer years ago purportedly admitted that he doesn’t believe in the possibility of decentralization.
The “free” transaction fee design of the DPoS consensus system that powers these projects such as EOS and STEEM, is actually not free, is a centralization feature, and is an incorrect design which I characterize as a bug.
Also I wrote on Medium:
The minimum latency for OmniLedger will be several seconds for acceptable error rates at the current network presumptions in the decentralized case.
I'm working on an improved design (which doesn't employ proof-of-work and isn't purely proof-of-stake) that obtains instantaneous sub-second latency (~0.05 seconds) for achieving the sort of interactivity we normally experience when interacting with a centralized database such as Facebook. Whereas, the DPoS-variant in EOS also barely obtains 0.5 second latency which requires forsaking antifragility and decentralization (and note that distributed isn’t the same as decentralized).
The Byteball Flaws section in Part 2 of this blog elaborates on OmniLedger and DPoS. All proof-of-stake systems are so inherently flawed (c.f. also) that they must exist only as oligarchy run systems that extract maximum value (rents) out of the system.
I participated in some debates about EOS at bitcointalk.org before I was perma-banned. For example, c.f. a reply to 
STEEM. C.f. also a reply to @scaryvirus.
My Medium post.
Click Here to continue reading Part 2 this blog.
The linked webpages and whitepapers cited in this blog have been archived at archive.is and/or archive.org.