[pfraze]

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.

[hagreet]

So essentially you need a trusted third party and if that party stops being trustworthy you have to start from scratch?

[pfraze]

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.

[EGreg]

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?

[pfraze]

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."

[wyldfire]

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.

[bmcusick]

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.

[dreit1]

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.

[rocqua]

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.