|
|
|
|
|
by pfraze
3145 days ago
|
|
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. |
|
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?