This Friday December 29th 2017, I had an epiphany about decentralizing crypto-currency transactions: a network of repudiable centralized operations with ultimate decentralized arbitration, can implement a cryptographic ledger with both high-throughput and high-trustworthiness. I posted my idea around and asked friends who are more up-to-date than I am about what market competitors are currently doing at this date. From the feedback I got, it seems that most of the elements in my design are well-known and are being currently implemented in some project or some other; and yet there seems to be some clarity in how I frame my design and some originality and simplicity in the overall result, that others hadn't realized yet. I would encourage further friends and experts to give me more informed and detailed opinions as to what follows, what about it is original, already well-known, or well-debunked, before I start trying to convince an existing system to adopt it, or to build a new one that does.
The first part of this essay tries to deconstruct the high-level design of a crypto-currency in terms of software design principles within the applicable constraints: what Bitcoin and its descendants are trying to achieve, how and why. From this deconstruction emerges a natural way to decentralize and federate the operations of a cryptographic ledger. The second part summarizes the design.
The essential innovation brought by Bitcoin was a way to achieve a Distributed Consensus that is robust against tampering by bad actors. This innovation is remarkable, and is something that in particular is not possible using centralized management, since the central manager can itself be a bad actor, become one, be captured by one, manipulated by one, and even if it is currently trustworthy, it will attract bad actors and bad acting in its midst in an evolution toward corruption both irresistible and irreversible.
Unhappily, the Distributed Consensus invented by Satoshi Nakamoto, while possible, is not only technically very hard to achieve but also economically very expensive; and for all that trouble, it remains slow and has low throughput. By contrast, centralized systems are much cheaper to operate, much faster, much more reliable, etc.; but ultimately they are fragile to failure or abuse by the operator: overcharging or outright censorship of transactions, double spending on their own transactions, inflation, confiscation, outages, gross negligence, etc. A big question today is how much the advantages of distributed consensus can be combined with those of centralized management without also combining their disadvantages.
One limitation of the Distributed Consensus invented by Satoshi Nakamoto is that it is a scarce resource that only scales so much, yet is potentially desired by billions of participants: Bitcoin can process a bit over 2000 transactions every ten minutes before it chokes, whereas credit cards currently process around 2000 transaction per second and could easily process hundred times more as the world economies grows. That's a factor of hundreds to tens of thousands that the Bitcoin network or its competitors would have to scale in throughput (not to mention its latency) to fulfill its destiny as the world's payment system of choice.
Consequently, many people have been working on various ways to increase the throughput of Bitcoin and its many variants without jeopardizing the robustness of the Consensus: the Bitcoin Lightning Network, Ethereum 2, Blockstream Liquid, OmniLedger, etc. The general idea is usually one of federating smaller subsets of the ledger that each can handle parts of the transactions more efficiently.
Now, trying to make sense of some of the existing proposals, I had the general impression that they consisted in adding ad hoc gadgets upon ad hoc gadgets to plug in hole after hole, resulting in as many Rube Goldberg Contraptions. At the root of the issue, the authors were tinkering with no clear design principles, because their underlying theory of crypto-currency was an accumulation of epicycles upon epicycles rather than a simple universal theory that could enable science and engineering.
However, trying to make sense of the essential problem at stake, I was reminded of three ideas that seemed to be wholly missing in many of the designs I saw, and at best present but not explicitly articulated in other designs: (1) Accountability, (2) Voice and Exit, and (3) Court Systems.
The first general idea, Accountability, consists in recognizing idea that parties to an activity can be incentivized to behave well and not to cheat by having skin in the game that they will lose should their cheating be revealed. While not a very insightful notion in human social organization, the idea was first explicitly applied to cryptocurrencies by Vitalik Buterin as part of a proposed Proof-of-Stake protocol called Slasher, where use of a same signature to endorse multiple contradictory views of the ledger can be denounced by other parties as a double-spending attempt, at which point the cheater is punished by losing a bond that he posted, whereas the author of the denunciation is rewarded with a fraction of the bond lost. I first heard about Slasher-style denunciations in the Tezos White Paper, but Vitalik Buterin is also making good use of it in Ethereum 2.
Voice and Exit are the idea, as introduced by Albert Hirschman but also notably studied by Public Choice economists, that (a) the ability to "Voice" complaints and maybe cast a tiny insignificant vote in picking who the next collective manager will be for everyone is essential to confront and combine the concerns of many honest people, but is wholly ineffective at keeping infrastructure managers honest and efficient; instead what is effective is (b) everyone's ability to individually "Exit" the set of customers of one's current service provider, or even of all existing service providers, thus becoming one's own provider and possibly that of others (an extreme case, also called "Enter", without which the providers still form an oligopoly if not a monopoly). In the context of crypto-currencies, that means that most of the elaborate "Voice" mechanisms that a lot protocol designers put in the "sub-chains" they federate, often mimicking the consensus protocol they try to extend, are mostly useless junk that make the protocol slower, more complex, more fragile, and more likely to be broken, while ultimately contributing little value to anyone. Instead, the one decentralized mechanism that will keep sub-chain managers honest is an "Exit" mechanism whereby asset holders can at any time freely repudiate a manager and pick another one.
The third idea, Court Systems, views the Distributed Consensus as a mechanism to render Justice: It creates consensus and clarity a posteriori, where there was the uncertainty of a dispute a priori; it provides Accountability by punishing bad actors and rewarding good actors. Certainly there is some degree of arbitrariness in how it resolves the uncertainty, but even if less than perfectly fair, as long as it is not corrupt, its adjudications are essential to disincentivize bad behavior. Courts can help preserve the right to Exit and Enter in various markets, — thereby punishing those who might be tempted to abuse a dominant position and rejecting de jure monopolies. But the concept of Exit and Enter also applies to Courts and their officers themselves: if there is no freedom not only to merely Exit from the jurisdiction of a court to live in another one's, but also to Enter the market of Justice and compete with existing courts, then soon enough, Courts will behave like a monopoly or an oligopoly, and provide services both expensive and bad. And that's what makes any centralized Court System ultimately a problem: it can and will be captured by bad actors. As applies to crypto-currencies, Decentralized Consensus provides, within its limited domain, the automated electronic equivalent of a Court System: arbitrating the many claims in the case of a dispute (double-spend), punishing bad behavior, and doing so without being a monopoly, without relying on a monopoly, and without otherwise condoning any monopoly.
In a crypto-currency, public key cryptography is used so that funds in a public ledger are assigned each to an entry protected by a publicly recognizable lock. Only the actor who knows the matching secret key (typically called Alice) can sign the checks that spend funds protected by a given lock (in some more advanced cases, it can be a set of actors each with many keys, interacting through a "smart contract"); but everyone who sees the signature can easily assess whether it indeed matches the lock. There is no way within the system to cheat by spending funds controlled by someone else: you may of course always crack their computers or torture them to extract their keys; but supposing that their software, hardware and wetware are secure, remote participants in the protocol cannot rob these funds; the theft has to occur outside of the protocol itself, which is secure. Inflation and confiscation, two risks commonly associated with phanero-currencies (currencies that are not crypto-currencies), can also be written out of the protocol at the time it is designed, before it is adopted; or they can be made to follow predictable patterns that users may accept before they adopt the currency, or reject and the currency with it.
The main risks that remain in a cryptographic ledger are: (C) censorship of transactions, which includes gouging of transaction fees under threat, and locking or destruction of funds that thereupon cannot be spent anymore, or even partitioning the network into parts that cannot see each other's messages; and (D) double-spending of funds by a malicious actor, who promises to deliver the very same funds simultaneously to multiple recipients and run away with benefits received in exchange before the deceived victims hear the news.
Without consensus, censorship is more of a technical problem that anything, and the Internet, being verily designed to be resistant to censorship of any kind, is as good a medium as any to address it, with all the well-known Internet techniques (which means you should have a networking expert in your team if you develop a crypto-currency, but this is not where you should expect your product to be positively differentiated, only negatively differentiated if you bungle it and fail to hire a competent expert).
Double-spending, however, is especially problematic, because the only action that can be taken in absence of consensus is to freeze all funds ever involved in a double-spend and mark them as "toxic" forever, everyone refusing to further use them. And what makes it problematic is that a malicious actor who possesses, buys or steals keys used in previously established transactions can retroactively sign and/or reveal double-spending messages long after the fact, at which point accounts once believed to be safe are under jeopardy and the malicious actor can blackmail their owner without recourse, and poison large parts of the ledger that you can never be sure you're not in.
Of course, no one would accept funds as being worth anything when the sender or any previous "owner" could at any time blackmail the recipient out of any marginal value the funds still possess. In other words, no title chain is ever safe, no title insurance is ever possible, and the entire system is worthless as a "currency": you may only trade tokens with people you fully trust never to cheat and never to be hacked, and must never accept funds that have at any point been held by anyone you don't thus trust; all that is left is at best a disconnected network of centralized debt exchange ledgers, with nothing to offer that phanero-currencies (those that aren't crypto-) don't already offer, better.
You don't need a Consensus to freeze disputed assets, but you do need a Consensus to unfreeze them (or to prevent the freezing).
A robust Distributed Consensus allows to declare a specific version of the ledger as canonical. Based on the consensual history of transactions, everyone can therefore agree on the same consensual priority between rival claims, so that there is always a clear (though sometimes slow) answer to the question of who does or doesn't rightfully control any given resource at any given moment.
Certainly, a bad actor can sign or reveal double spending messages about long spent funds. But if the double spending was made part of the consensus during the confirmation period, then the bad actor will be punished and their funds confiscated, whereas if the double spending wasn't made part of the consensus, there will be a clear owner: the one who has the prior claim within the consensus. Thus, a bad actor cannot wreak havoc by posting old double spends, only create suspicion about the keys he now owns without jeopardizing any confirmed title. Everyone is secure in his confirmed property, and all titles are so perfectly clear at all times that title insurance is not needed (you may still need insurance against theft outside the protocol).
In terms of epistemic logic, consensus transforms shared knowledge into common knowledge. Shared knowledge is something that everyone knows (yet may have no way to be sure that others agree on it). Common knowledge is something that everyone agrees on: everyone knows that everyone knows that everyone knows it, etc.
The Distributed Consensus is slow: it can take at least one hour for a Bitcoin transaction to be considered confirmed, even more hours considering the time between which it is posted and the time it starts being included in the consensus. Some Bitcoin rivals are faster. In any case, transactions are both much slower than credit card transactions (a few seconds) and much faster than inter-bank transfers (a few business days).
As for Censorship, it is a problem with Distributed Consensus, but only slightly so: a very large entity, such as a large government, could try to censor communications, partition the network, and threaten the Proof-of-Work "miners" (in the case of e.g. Bitcoin) or the Proof-of-Stake "bakers" (in the case of e.g. Tezos) who would refuse to enforce their publishing restrictions. But if a single miner or baker disagrees and wins the block, the transaction is still posted and evades censorship. And even if a government successfully imposes its rules permanently, that only results in a fork of the crypto-currency network, with most of the value migrating to the "rebel" consensus, since it's the one that keeps delivering the promise of a crypto-currency; and the miners forced to stay on the government-sanctioned fork see the value of their investment eroding. In other words, a government can of course destroy the riches of those it has under its control — this has and will always be the one and only power at the root of all governments. But it cannot stop the Distributed Consensus, only temporarily fork it and stall it.
Now, notice that the bad events that the Consensus deals with require a bad actor, or at least a sufficiently incompetent one (and here as always, any sufficiently advanced incompetence is indistinguishable from malice). The mechanism to deal with bad actors after the fact, in the real world, is a Court System, a Justice System. And that's exactly what the Consensus is in a crypto-currency: a Court System with which to adjudicate contradictory claims.
By analogy with offline Court Systems, is an online Court System that is decentralized: not only does it know no central manager, no "government", but it actively protects against the abuses of a would-be central manager or "government". Within the limited scope of the cryptographic ledger it implements, it settles property right disputes at the speed of the Internet.
In centralized systems, the manager can protect against small bad actors (though he isn't the one to suffer if he does a poor job at it), but nothing protects users against the manager eventually and necessarily becoming the bad actor. Putting a central government, a Leviathan, or some other ultimate judge above the managers would only move the problem back one level without solving it, as said Leviathan itself behaves badly, either immediately or after a quick capture. In a Distributed Consensus, there is no manager, no Leviathan, and all bad actors are punished, even if they are big. There is no "too big to jail".
The Distributed Consensus of course does not and cannot protect people against predatory behavior outside its protocol. You can still be robbed, murdered, abducted, raped, tortured and racketeered, your computers cracked, your passwords and your money extracted from you. Be sure to pay your pizzo, whether your local mafia's assassins wear blue uniforms or black suits, or whatever costume. What the Distributed Consensus can do, though, is make sure is not the weakest link in the defense of property rights.
From this epiphany of Consensus as Court System, it becomes obvious what are meaningful or absurd designs in building decentralized crypto-currencies: will be meaningful those design that use the Consensus as the Court System it is, and absurd those that fail to use Consensus to settle claims where conflicts there might be, and try to use it or mimick it where conflicts are irrelevant or cannot be avoided anyway. The lessons of Political Economy apply, including those of Public Choice Theory.
Distributed Consensus is hard and expensive. But it's only needed in case of a dispute. Using the Distributed Consensus to publish each and every transaction is like going to Court every time you want to pay for coffee: a totally inefficient abuse of the system. No wonder Bitcoin and its copycats won't scale in their current state. The obvious solution is to use Distributed Consensus only where it's needed: to preclude and resolve disputes. In other words, do not publish individual transactions, only publish ledger registrations and dispute resolutions.
Not-publishing is infinitely faster than publishing, and can easily be scaled a millionfold: "My consensus can not-publish ℵ₄₂ transactions quintillions of times faster than your consensus can publish a single transaction."
When Alice sends money directly to Bob through the Consensus, Bob has to trust Alice not to be double-spending, and thus, wait for the transaction to have been confirmed by the Consensus. This is slow. Now, if Alice sends money through Trent who guarantees it, who trusts Alice and whom Bob trusts, then Bob only has to trust Trent, at which point he only has to wait for Trent's confirmation, which can be just as fast as a Credit Card transaction. But how can this trust be established without relinquishing decentralization?
Trust can be established in this and many other cases through Accountability: those who try to cheat can be denounced by anyone who exhibit cryptographic signatures of double spending, at which point the user who cheated loses all the funds at stake and the user who did the denouncing (typically the miner who won the Consensus confirmation) receives a fraction of the funds at stake while the rest of the funds are returned to general pool of assets to mine. The fraction cannot be the totality, or else miners could try to cheat then immediately denounce themselves to recoup the double-spent funds; see in a chapter below an arithmetic justification for one quarter as a reasonable reward.
Therefore, Trent can trust that Alice is not double-spending, because Alice has registered Trent as her current Payment Processor and cannot be spending the same assets through a different channel. If Alice tried to double-spend anyway, Trent could see it and denounce Alice instead of becoming her accomplice; or Trent could assume a mistake by Alice and refuse to relay double-spending messages that could get Alice denounced and her corresponding assets seized; also warn her that she is using buggy software that could cost her money. (Unless Trent is also the miner who will make the next Consensus, or has a contract with him, he is unlikely to get a reward from denouncing Alice; he will be better rewarded by providing helpful service).
That Trent is Alice's current Payment Processor can be easily verified by Trent and Bob by consulting a recent enough version of the Consensus. Alice can change her Payment Processor, but the change will take enough time to be confirmed and become effective that Trent and Bob could see if that were the case. Trent being Alice's Payment Processor, knows what assets Alice possessed at the latest Consensus, and what she spent, which happened through him; he can therefore safely undersign any transfer of Alice's assets, and for a small fee will batch it with thousands or millions of other transactions that he will register with in a further Consensus.
But how does Bob know that he can trust Trent? Because Trent is accountable: Trent posted a bond with the Consensus, that he cannot recover for a duration that leaves more than enough time for Trent to be found fraudulent and successfully sued.
Note that in some cases, Trent might also be a known institution, such as a bank or credit card issuer, that Bob can sue in real-life; phanero-institutions can therefore directly offer services that integrate well with the Distributed Consensus and compete for Trust, Speed or Price with other cryptographic intermediaries that hide their TRUE NAMES behind anonymizing network layers. Some people might consider them more trustworthy because of their higher accountability; other people might consider them less trustworthy because they collaborate with oppressive governments or may be forced to (Of course, nothing can guarantee an anonymous payment processor won't; and users can use proxies, onion networks and other such anonymizing techniques to connect to their payment processor).
In the case that Trent is also Bob's Payment Processor, Bob can start spending those funds immediately; otherwise, Trent would be prudent to wait for Consensus confirmation before he undersigns the use of funds that haven't been secured yet. This is akin to transfering funds within a bank versus between banks.
All in all, having designated payment processors rather than letting any miner notarize any transaction enables faster transactions in many common cases where Trust can be reasonably assumed thanks to Accountability. It also offers a mechanism to increase said Trust by providing stable third parties that users can choose to trust or not to trust based on whichever relevant criteria apply to the transactions at hand.
Why would Bob trust Trent and Alice not to be pseudonyms for the malicious Mallory, or for Mallory and her accomplice Chuck, trying to extract value from him through double-spending?
Because of the bond posted and the speed of the Consensus, Mallory (disguised as Trent) only has limited time to double-spend: it all has to happen before the news gets out. And if Bob broadcasts the messages that Trent sent him to chat networks that exchanges such messages, the fraud can become shared knowledge world-wide in a fraction of a second, long before it is common knowledge, which might take many seconds, minutes or even hours. Therefore, it may take some time for the Consensus to catch and punish Trent by seizing his bond and proscribing his key; but Bob will be warned very quickly that something is amiss with Trent. If every merchant software does that as requirement for being part of the protocol (under pain of being banned from the network, on the ground of behaving in an uncivil way that incentivizes fraud), then Mallory can only defraud one merchant, which if Bob follows the proper protocol will be worth less than she will lose by being denounced as double spender.
Thus Bob can reasonably trust Trent, using simple verifications completed within a second, as long as the list of unconfirmed payments undersigned by Trent total less than a fraction of Trent's posted bond. Bob may pay a small fee (probably through his payment processor) to be part of this chat network (the fee makes it possible to punish spammers and censors), but it allows him to be sure that Trent/Mallory cannot win this way. If Mallory didn't have to post a bond, she would be able to repeatedly create fake identities and try to fool lots of Bobs by somehow cutting them from the chat network. The bond payment, together competently written payment software used by Bob, hopefully makes that a losing strategy by raising the fixed costs of Mallory while decreasing her potential benefits.
There is still the case of Wanda the vandal, who may try to simultaneously cause one or several enemies to irreversibly waste their resources in a very short time interval at the combined cost of losing Alice's payment and Trent's bond, which will both be lost. Wanda might be ready to pay money just to see her enemy lose as much. Vandals or very fast thieves might even manipulate an incompetent Trent and stealing his identity and decide to be nuisances to Bob whom they hate, since they can't escape with the funds. Bob has to decide whether any of these scenarios is likely, depending on what he's selling in exchange for these crypto-currency assets. He should wait for the Consensus to confirm the transactions for which he suspects this risk matters.
An online business shipping physical goods can definitely afford to wait for Consensus. A brick-and-morter store selling physical goods, or an online business selling revokable online goods, will probably be satisfied with Trent's bond and an all-clear on the chat network: Mallory will is unlikely to run away with the goods, in addition to losing the bond and more. If Bob is an online cash exchange business, he'll definitely want to wait for several confirmations by the Consensus. If Bob is a physical cash exchange, he may trust just one confirmation for small amounts.
Crypto-currency Payment Processors do not solve all trust issues for everyone; but they can probably compete with Credit Card processors in terms of trustworthiness, speed and price. And in cases they can't make transactions fast, they can still make things transactions cheap by batching their verification and registration.
What is a reasonable fraction of the bond posted by Trent under which
Bob may trust Trent's word as a fast confirmation for Alice's funds?
That fraction shall be strictly less than what Mallory could expect to win
by impersonating all the other parties to a con:
Alice the double-spender, Trent the trusted underwriter, Chuck the other recipient,
Mina the miner who will confirm the transaction, and even
Manny the next miner who will confirm the denunciation right afterward.
Assuming Bob and every other honest recipient
verifies against double-spend on the broadcast chat network
before accepting the unconfirmed transaction,
Mallory will only be able to defraud one person, Bob, in this double-spend attempt.
Assuming the amount double-spent by Alice was A and the bond posted by Trent was B,
then Mallory spends A as Alice, but likely gets it back as Chuck, and captures value A from Bob;
Mallory then loses B as Trent from the lost bond, maybe but earns back the reward R B as Manny,
where R is the reward factor.
With some skill, Mallory could expect to defraud marks who fails to properly verify transactions,
or somehow manage not to get caught, and so we should multiply Mallory's expected profits
by a skill factor S that represents the number victims that Mallory can con
before she is found out.
For removing Mallory's incentive to cheat, we thus want S A + R B < B;
put as a ratio, this is equivalent to A/B < (1-R)/S.
To disincentivize an enemy with a skill factor S,
we need trust ratio T = (1-R)/S.
Let us assume a skill factor S = 4 because someone who pulls that off is not an amateur.
Let us set R = .2, a 20% reward for who denounces a double-spend.
Then, T=(1-R)/S=(80/100)/4=1/5, i.e.
Bob shall trust Trent only up to the point that Trent has underwritten
transactions for more than 20% of the bond that Trent posted.
If Trent posted five million dollars worth of currency units,
then Trent can reasonably be trusted up until he underwrote
one million dollars worth of currency unit in so far unconfirmed transactions.
Beyond that, Bob and other merchants would be prudent to wait for Consensus,
or ask Alice to pay using an account with another payment processor
who hasn't maxed out his bond-based trust yet.
Note that Bob is individually free to choose his trust ratio T based on his estimate for S;
on the other hand, the reward ratio R is baked into the network protocol,
and therefore protocol designers should be low enough to accommodate
for a range of estimates by Bob, yet high enough to incentivize miners to care.
For instance, a 10% reward with R=.1 instead of a 20% reward could lead to a 22.5% trust ratio
T=.225 for an expected opponent same skill factor S=4,
a 30% trust ratio for a skill factor S=3, or a 18% trust ratio for a skill factor S=5,
which means Trent should post 5.56 times what he intends to underwrite to satisfy Bob.
Obviously, Bob should never make an estimate for S that is less than 1,
and should never trust Trent if he believes other users somehow fail to verify.
Note that when double spending happens, there is no proof of collusion, or even crime.
There is a slight chance that there was a weird bug in Alice's software,
and another in Trent's software.
It is nevertheless just to punish Alice and Trent for their negligence,
where Alice loses her funds and Trent his bond.
In the case the double-spending succeeds in being confirmed in Chuck's favor before it is denounced,
it is possible that Alice and Chuck were honest, that someone stole Alice's key after the fact,
and that Bob is in fact a fraud complaining;
still, if Trent did underwrite both spending messages,
he is at best negligent and should be punished,
though there is no proof, only suspicion, for Alice and Chuck.
If Mina confirms the transaction, she is strongly suspect of being in collusion with Mallory,
especially if the broadcast chat network posted a contradictory transaction that Mina ignored;
but Mina could be the innocent victim of a network split, and only Trent is surely wrong.
Similarly, whenever Manny posts a denunciation and gets a reward,
Manny can be suspected of being in bed with Mallory-Alice-Trent who timed their double-spend
just when Manny would win. But that is no proof, especially if R is low and S is high.
In case of transaction before denunciation, Chuck, Mina and Manny are strongly suspect, but especially since not just Bob but several other merchants (unverifying and/or victims of network split) have to be victims for the double-spend to be effective, this suspicion is no proof. And even in the case of Alice, double-spending happening after transaction could be just part of a smear campaign. Of course, if there is a pattern, and the same online identities, or identities related by fund transfers, are repeatedly used for fraud, then there is a good case for proscribing those identities in a fork, or in a layer of fraud tracking on top of the ledger itself: merchants could consider any payment from a suspect identity frozen until cleared by the police, for instance.
On the other hand, if Mallory is able of such highly complex technical attacks, she's probably able to create lots of false online identities cheaply using zombie botnets, like Sybil, and otherwise muddy her tracks so it's hard to trace the money back to her. And while they may be suspect, it would be unwise for the protocol to deny pseudonymous newcomers a presumption of innocence just because they are new or small; otherwise not only will you punish a lot of innocent people, you will also institute a de facto oligopoly for the big old payment processors who can then capture the value of the network and raise their fees. At some point, the protocol must not try to address things it cannot fix, and actions outside the protocol must be taken to catch the criminals who are probably negligent in some way or some other.
Note Bob must also watch signs of health in the broadcast chat network.
If the network isn't healthy, then Mallory could potentially be managing to defraud
more than one person, at which point the skill factor S could be arbitrarily high,
and Bob should just stop trusting Trent's word and just wait for confirmation by the Consensus,
or at least wait for the network to be healthy again.
Alice might be unsatisfied with Trent because of the price, speed or trust issues: Trent might demand too high fees to undersign and register transactions, or Trent might be plainly refusing to process some transactions, or might be technically failing to be responsive and complete the notarization. Trent might not register transactions to the Consensus often enough by Alice's tastes (for instance, to save on Consensus fees, Trent might only register transactions at ever other block of the Consensus blockchain). Trent might have been caught double-spending, or might have acquired a bad reputation with respect to its operational security practices, etc. Alice might have learned that Trent's real-life CEO voted for a candidate she hates, or collaborates with a national government she despises. Or Alice might like Ted for whatever opposite reasons.
Whatever her reasons, Alice can alter her Payment Processor at any time, by having Ted post a notice on the Consensus. The change will only be effective after Trent has had time to register any pending transactions to the consensus. and after the change notice has been confirmed enough times by the Consensus. But the change will be seen long before it's effective as common knowledge by the Consensus, by consulting the chat network for shared knowledge. Thus, Alice, Bob, Trent and Ted all have plenty of heads up.
Alice may even Enter the market for payment processors by posting a bond with the Consensus, by advertising how much she charges for posting transactions and how often she intends to register her transaction updates, by becoming a peer on the shared knowledge chat network and a common knowledge Consensus mining pool, etc. Being her own payment processor isn't cheap: the cost of posting data in the Consensus is presumably much higher than the fees required by payment processors. Being her own payment processor isn't simple, as there may be a lot of technical overhead to partaking in the Consensus. But it's possible; and if Alice is good at it, she can do it for others too and get paid for it, or she can at least share costs with friends.
On the other hand, changing her Payment Processor would leave Alice unable to make new transactions for a short while, until the confirmation window for this change is over, unless Trent confirms the change rather than lets Alice's subscription timeout. There are therefore two ways to change payment processor: the cooperative way, wherein Alice pays both Trent and Ted to coordinate a graceful handover, and the preemptive way, wherein Alice only pays Ted and severs ties with Trent, whether Trent likes it or not, but Alice has to wait longer for the handover to happen. Trent can also be nice and make exit confirmation messages free, signalling to his actual and potential customers that he is not afraid of competition and they have nothing to lose to pick him as Payment Processor. No one can force Trent to be nice, though. And Trent could start nice one day and later change or fail, be sold to less nice guys or overtaken by bad actors. But even if Trent is later unwilling or incapable of letting Alice go gracefully, Alice can repudiate him with a preemptive change of Payment Processor. However, the inconvenience of switching as well as associated transaction fees and delays should motivate Alice not to spam the system with spurious changes.
All in all, the ability for Alice to change Payment Processor at anytime, and even become her own Payment Processor if she wants, ensures that there is a free market for payment processors; this in turn ensures competitive service price and quality, and preventing any de jure monopoly or oligopoly in Notarization. Even in a degenerate case, where a single payment processor would possess a de facto monopoly on processing transactions, being the registered Payment Processor for all or most of the active users, as long as it keeps registering its transactions with a Consensus that allows to repudiate it and as users keep broadcasting their transactions to a chat network that validates them, the users can be safe in their possessions even should the payment processor later fail. The payment processor is kept honest, cheap and efficient by the potential competition that would inevitably declare itself and undercut it should its service eventually prove less than satisfying.
There are cases where Trent may wholly fail: caught double-spending, too slow, having software or hardware issues, falling into the hands of criminals or government agents (but I repeat myself), bitrotting, or otherwise ceasing business without having registered all the transactions that it agreed to register. In those cases, after Trent misses his deadline to register transaction updates, Alice (and all other user that had Trent as their Payment Processor) can choose Ted as her payment processor and have him register those pending transactions. If Alice refuses to do it, Bob in turn (each person that Alice sent money to) may have his own Payment Processor go to court and register the transactions that Alice signed and Trent undersigned that were published on the shared knowledge chat network. To give something to Alice without waiting for Consensus confirmation, Bob may require Alice to leave long enough timeouts on the checks she signs that he may thus ensure that they are confirmed even if Trent fails. The fees that Alice pays for her transactions will go to whoever registers them: Trent, if he does it before his promised timeout, Alice's new Payment Processor Ted or Bob's Payment Processor if they pick up the slack after Trent fails to deliver; if they consider those fees insufficient they may charge Alice or Bob extra for the act. It is alright if multiple Payment Processors redundantly register the same pending transactions of a failed Payment Processor. If they register conflicting transactions, then the miner can denounce the corresponding double-spends and Alice loses the corresponding funds and the Payment Processors lose the associated fees.
If Alice is honest and not colluding with Trent, Bob may thus still get his payment despite Trent's failure. If Alice tries to double spend while her pending transaction hasn't been confirmed, Bob may not be able to get any funds as he may have to race with the other person to whom Alice tries to double spend and with the validating miners who will no doubt denounce Alice and get half her funds. However, Alice cannot benefit and can only lose from trying to double spend after Trent's failure. Once again, if Bob has enemies ready to spend money for Bob to lose money the same, then Bob better wait for Consensus confirmation before to provide goods and services to anyone. Otherwise he's still pretty safe even if Trent fails (though he may have to pay extra fees in this case, a small punishment for his bad judgement).
When a Payment Processor fails, there may therefore be extra delays before accounts are settled with the Consensus for all who used said Payment Processor. Once again, these delays and fees will be punishment enough for Alice who chose an unreliable Payment Processor, and for Bob who accepted an unconfirmed transaction from an unreliable Payment Processor; and the threat of them will be incentive for Alice and Bob to be more discriminating. But they won't otherwise prevent the completion of bona fide transactions between honest people, and they won't allow dishonest actors from profiteering from making victims.
In any case, Bob should use suitably advanced payment processing software or a competent online service before he starts accepting fast transactions from unknown payment processors; but assuming he follows industry best practices, he should be reasonably safe — no less so than by using a Credit Card processor.
The known Distributed Consensus variants developed since their invention by Satoshi Nakamoto are quite resistant to manipulation by bad actors. Yet Proof-of-Stake and to a much lesser degree Proof-of-Work are both susceptible to capture by a large bad actor such as a government. Such a bad actor could then censor transactions by its enemies; it could refrain from denouncing and punishing double-spending attempts, instead confirming between multiple spends it makes those that benefit it; it could even retroactively undo what was thought to be the confirmed consensus.
Happily, such capture can be detected as shared knowledge by the broadcast chat network: that "network" is a loose decentralized, censorship-resistant, uncontrollable network, that every participant can at any time supplement or supplant with rivals who evade the control of whichever large bad actor tries to censor them. That fast network can clearly see that some transactions are censored, some double-spends not denounced, some confirmations reversed. What the chat network cannot do, however, is provide a clear consensus resolution to this problem; yet it can leverage other sources of consensus to topple the existing one that was recognized as having been captured. This threat alone might be enough to convince powers-that-be that it is pointless to spend resources capturing the consensus for nefarious purposes.
Indeed, as users understand that the consensus has been captured and as victims of censorship or double-spending raise awareness of the issue, the ultimate solution is to fork the system. But cheaper counter-measures are available before going that route. Let's assume a meta-decentralized crypto-currency called MetaDecentCoin or MDC, that relies its own cheap Consensus that has say a one minute latency to reasonable confirmation. Let's assume that, whether MetaDecentCoin uses Proof-of-Work or Proof-of-Stake, its Consensus has been hijacked by bad actors who double-spend and censor denunciations, who censor the transactions of enemies or raise transaction fees through the roof and prevent new entrants from registering as competitors. This activity is detected on the broadcast network, and concerned users can then use a higher consensus as an escape valve: assuming that say Bitcoin, or BTC, offers a much more trustworthy, censorship-resistant and capture-resistant Consensus than MetaDecentCoin, then MetaDecentCoin could define a way to encode transactions and denunciations so they may somehow be published on the Bitcoin blockchain with well-defined meaning and priority. Then the MetaDecentCoin protocol could mandate that any transaction or denunciation published on the higher consensus should be included by the regular MDC Consensus within a given window; otherwise, that is reason enough to denounce all the miners who published MDC confirmations during that window, who would lose all their assets including all posted bonds. Eventually, either the bad actors who captured the Consensus learn their lesson and stop acting badly after losing significant funds in bonds, or they lose their influence as their ability to post bonds wanes. Either way, as long as the bad actors don't capture both the MDC and BTC consensus, then MDC can be saved by anyone capable of posting transactions on the higher consensus. Bad actors who are nevertheless not ready to lose too many funds may capture the lower consensus and avoid double-spending, but still censor the transactions they dislike though only until someone pays the price of publishing them on the higher consensus; this timid bad capture will then raise somewhat the price of using the MetaDecentCoin, but only until users migrate to new payment processors who don't play that game that negatively affects the usability and value of the ledger.
Adding one or several "higher consensus" safe-guard adds significant complexity to the code base, what more in a way that is intended seldom or, hopefully, never, to be used in production. Yet for security reasons, this code has to be tested extensively, and often, on test networks. Strict privilege separation should be used to isolate the foreign codebase of the "higher" consensus from the regular codebase. One reason to add several such codebases is that which of the Consensus is actually higher than the MetaDecentCoin consensus can change with time. Any timeouts associated with repudiating an unconfirmed transaction, or removing funds posted as a Payment Processor, should be large enough to allow for use of such a "higher consensus".
If and when the Consensus is so hopelessly captured that the bad actors run loose, and yet there is no other "higher consensus" that hasn't been captured that can be used as a safe-guard, or when other essential issues in the Consensus won't be fixed, then it's time for a Fork of the ledger.
At that point, users who desire a fork have to publish their updated code, setup their rival servers, and start an alternate Consensus history. Then, the mechanism against double-spending ensures that a given Payment Processor (and also regular users?) should only ever support one fork, least it could be denounced in the other one, or in both. Assets that have been mined before the fork may be spent simultaneously on both forks at once, or only on a single one, depending on the details of the fork. Forkers may also declare a proscription on all the payment processors that were known to partake in the capture, on all the addresses known to be associated to them, on all the accounts that have accepted funds from them unless they first destroy said funds (by sending them to a specially recognized unusable address) — the exception being in case the bad actors wanted to otherwise taint the accounts of people they dislike with toxic funds.
Forks are hard, expensive and painful, but the finite cost of a transition to a fork puts a cap on how much a ledger can suck. By definition, when forks happen, the formal Consensus as embodied in the code, has failed. To determine which Fork to use, users may have to rely on some Social Consensus beyond any formal Consensus. Yet in the end, forks are how the real and higher Consensus emerges. It is the possibility of divergence that incentivizes convergence: Forks are Exit for blockchains, they are what ultimately keeps the Consensus honest, making its capture in the view of acting badly a fool's errand. The True Consensus is always what emerges a posteriori, which in case of dispute always beats what was decided a priori.
It is important to realize that the Consensus exists on top of the broadcast chat network, and not independently from it. How will the blocks of data from the Consensus be exchanged? Via the chat network. That is why it is not necessary for Consensus "blocks" to contain all the data sufficient to reconstitute ledger history, only cryptographic digests of content that can be found in through the chat network.
What happens if the apparently highest weight block in the Consensus is badly formed, or refers to content that is unavailable? (e.g. a Payment Processor signs a digest of the transactions it is registering, but the actual list of transactions with said digest is nowhere to be found, preventing users from actually confirming who has which funds?).
One rule is for members of the chat network to refuse to relay data that they cannot completely validate, or at least to flag it as unvalidated and refuse to use it as the basis for confirming the validity of transactions. This may give an advantage to miners who can start working on the best block early when others are waiting for validation. Or this can be detrimental to these miners, as other miners decide to mine alternate blocks that they know are valid.
In the end, this can give some big miners a way to amplify their advantage at winning the block-mining competition. But it won't allow them to act badly without getting caught with censorship or double-spending. In the end, if they act badly or even simply make it harder and slower for users to verify their transactions, then it will only be giving users a big incentive to fork the ledger and leave them behind. They can keep doing 51% attacks in the original blockchain, but that won't help them much if everyone abandons it for the fork and they end up having 100% of a currency worth nothing.
In the end, the payment processors and miners who make the Consensus are interested in only working with data readily available in the chat network, which increases the usability and therefore value of the currency they are invested in.
To use the protocol at all, Software must be able to talk to the broadcast chat network, to extract from it the consensus, payment processor information, transaction and denunciation history, with many intricate rules of priority and awareness of any change in the protocol history. To safely use the protocol to receive payment, it must also be able to watch double spend alerts, have good heuristics to decide when to trust or not trust a payment processor, be able to ensure confirmation if a payment processor fails, and watch the account and launch alerts if anything is amiss. To make payment, it needs all the above, plus managing public and private keys, maintain account state and transaction state, somehow hold a lock with timeout between multiple devices so users won't double spend or wonder about appearing or disappearing funds if they use their wallet from more than one device, etc. To be a node in the broadcast chat network, a node needs the above plus good heuristics for when to accept or reject connections, validate messages, drop or relay data, maybe join secondary networks for messages in a "higher consensus", etc. And in all the details of all these things, multiple layers of software security matter.
Ultimately, though, such is the cost of reconciling the advantages of centralized and decentralized: the codebase must contain both the centralized and decentralized systems, plus some code to reconcile the two, plus plenty of safeguards. Keeping the code secure despite the complexity is a great challenge.
Meta-Decentralized Crypto-Currencies, where routine operations are centralized, but arbitration is decentralized, combine the high-throughput and low-cost of centralized systems with the robustness and capture-resistance of decentralized systems. Meta-Decentralized Crypto-Currencies are a natural evolution and reconciliation of both current crypto-currencies and phanero-currencies, based on understanding the essential principles of what makes either valuable: the slower decentralized arbitration keeps the faster operation honest and efficient.
Some existing crypto-currency project could adopt this protocol. For instance, Tezos's delegate mechanism could be transformed into a payment processor mechanism, and the transformation could be sold as an amendment to the coin holders. If no existing crypto-currency adopts this protocol, a new cryptocurrency could be created, or an existing one could be forked. For instance, if Tezos owners won't adopt the proposed amendment, a fork of Tezos where they do. that might have great arguments to beat its competitors in speed, price and trustworthiness.