So if there is no proof of work how do you avoid forks? The author says something about splits being detectable but that doesn't really help us decide on which side of the split is correct.
You don't use decentralized consensus in this model. It's a single node that's maintaining the blockchain state. Monitors actively watch the blockchain to make sure the node doesn't deviate from the code contract. If there is a fork in the blockchain, that'd be because the single node created that fork in an attempt to create two versions of the state-- that's a break in the contract and it would be viewed as a fatal corruption event.
Semi-trusted. You have total transparency into whether the node is following the rules of the code contract. The node could not, for instance, change values in the DB without doing so via the contract, and that would be logged for all to see. Very important for something like a key server.
There are two things you have to trust, which I mention in the post.
1. That the node is not denying writes. (What's sometimes in blockchains called censorship.) If the node just didn't run your request, you'd be locked out with no evidence. It's not unsolveable, though - you could combat this by using a 3rd party proxy which records the traffic, and thus can back up your claim that you're being censored.
2. That the node won't just shut down. To combat this, you'd need a procedure for moving to a new hosting node. Not impossible either, but you'd need to decide for your userbase what kind of process would make them most comfortable. The blockchain state is there to be cloned at any time.
Sure it can - it can just start reporting different things to different validators.
At this point the validators compare notes and gossip a proof that the node's been acting up. And then they need to elect another node, which requires... consensus!
Oh and the central node can also become unavailable and DDOSed, how are you going to add transactions to the ledger then?
Choosing another node won't involve consensus in the way that consensus is described in distributed networks. You'd handle that ideally by a prior agreement -- eg, "if this node corrupts, it's going to go into arbitration via a trusted third party, who will then decide who will resume operating the network."
IMO this new design is "fine w/me" in the way that ethereum is "fine w/me." If people want a not-so-decentralized cryptocoin that's not-so-trustless, then so be it.
If it handles transactions faster, better, cheaper, and with less emissions, then so be it.
Unfortunately bitcoin's popularity/ubiquity makes it superior (for the time being) and hard to unseat. Other (decentralized) altcoins make really great improvements over bitcoin but never became (and perhaps never will become) as popular as bitcoin.
If I can make a suggestion, you might want to look into the structure of the blockchain networks that use a network of known super-nodes to watch and verify each other.
If you have hundreds of known, diverse nodes distributed globally (run by very different institutions like Harvard, Bank of America, the Vatican, the Red Cross, the Gates Foundation, the House of Saud, etc. etc.) they can all watch each other, and the odds of them all going offline at the same time or cooperating to deny a specific user's transactions are very low.
This is called delegated byzantine fault tolerance, and what blockchains like NEO and ARK use this, or a variation of it to provide consensus. Token holders basically "elect" the super nodes, and if any begin to act untrustworthy they are "voted out." I'm a fan of this consensus styles because blockchains become semi centralized over time. Maybe not in the technical full validating node way, but certainly politically centralized.
Yes, if you can handle forks as long as you can detect them, centralized consensus is a decent solution with much lower costs that PoW.
This is essentially how CT-logs work, where we consider it sufficient to detect a falsely-issued certificate, even though we cannot prevent such issuance.
Forks are ok as long as they can be merged in the short term.
If something forks for a long time and stays forked, there is hardly any reason to establish a total order during the merge!
Think of an IRC netsplit for example. One that happens for a few seconds may attempt to merge back the chats in some fair order they were made, in diff forks.
But if the netsplit happens for a whole day, or month, no one really gives a crap about ordering messages across forks. The merge is too complex! In fact, the resulting conversation would be MORE nonsensical than if you correctly rendered the split conversations as a DAG in the client.
Similarly, if bitcoin forks into bitcoin cash or whatever, and enough validators accept it, I get to "double-spend" my new money now. Proof-of-work is no panacea. If we religiously want consensus then no transaction can ever be truly confirmed - there is always a chance some larger fork comes along and undoes all transactions on my fork going back a whole month. Interplanetary File System has to deal with this.
The problem is that we still haven't evolved our thinking about currencies as DAGs and keep worrying about the double spend problem and turn to global consensus to fix it.
In the specific case of currency, practical double spends are a real issue.
'Merging' the state after a double spend requires either forcing the double spender to pony-up, or taking back money from those who received it without being aware of any wrongdoing. That is, unless you are fine with people printing their own currency.
This is rather unique to the case of currency though. Specifically, the history of transactions determines which future transactions are possible. Instead a system that only records promises (but doesn't allow transfer of such promises) would work without centralization. If I promise something to 2 different people I remain on the hook for that promise. The fact that I am effectively 'in debt' on the system isn't an issue because the system gives no guarantees on people meeting their promises.
Everybody prints their own currency all the time. Currency is just promises made. Double spend is when you duplicate somebody else's promises that you are holding as an asset.
How are you going to merge if you have different spends on the forks you're trying to merge? It's not a matter of whether or not you care about ordering. It's a matter of one branch's spend being invalidated by the spend in the other branch.
If the answer is to stop caring about double spend, how do you anticipate that working?
Yes, stop caring about double spend as long as it happens in long term forks. After some point, two different forks become two different communities. Similarly when you restrict gene flow between species which are physically separated, they often can't interbreed anymore. It's called allopatric speciation. There is evidence it happens in nature.
What you should do is have each community have its own internal currency, and then have global payments be powered by a federated system. Like the internet works.
Well, if there is a period that your transaction might get reversed, then the seller can't send you the stuff. Or, maybe you need a reputation system for buyers and sellers and so on (what eBay does) along with chargeback systems figuring out whether to let the transaction be reversed.
Typically, that period is until the next consensus. In Ripple, the consensus eventually takes place but sometimes may take up to a minute. In Bitcoin it may take 30 minutes. You are never quite sure that everyone "phoned in", but presumably if the network participants announce themselves on the network then you can know when a supermajority has "phoned in". If they haven't - you've got a fork baby.
You can also get a fork if they phone in but start a second consensus somewhere else lol.