On blockchains and why secure ledgers don't require proof-of-work
pfrazee.github.io
On blockchains and why secure ledgers don't require proof-of-work
1–10 of 61 posts
Re: On blockchains and why secure ledgers don't require proof-of-work
#2So 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.
Re: On blockchains and why secure ledgers don't require proof-of-work
#3So 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.
Re: On blockchains and why secure ledgers don't require proof-of-work
#4So 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…
So essentially you need a trusted third party and if that party stops being trustworthy you have to start from scratch?
Re: On blockchains and why secure ledgers don't require proof-of-work
#5The catch is at the end: "There are some downsides to losing decentralized consensus. A ledger-backed service could manipulate the order in which it handles requests, or reject some requests altogether, and clients would have a hard time proving it." Calling that a "secure ledger" is kind of a stretch.
Re: On blockchains and why secure ledgers don't require proof-of-work
#6Earlier quoted context omitted.
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…
So essentially you need a trusted third party and if that party stops being trustworthy you have to start from scratch?
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.
Re: On blockchains and why secure ledgers don't require proof-of-work
#7Geee, what a dangerous fool...
What good is the ability to tell whether something is shit or fake or completely out of service when I can’t update or restore or correct it?
That is totally vulnerable in terms of DoS, state actor confiscation, and censorship. Awful!!!
Re: On blockchains and why secure ledgers don't require proof-of-work
#8The catch is at the end: "There are some downsides to losing decentralized consensus. A ledger-backed service could manipulate the order in which it handles requests, or reject some requests altogether, and clients would have a hard time proving it." Calling that a "secure ledger" is kind of a stretch.
There's aaalways a catch.
See my response to hagreet. Neither of those problems are unfixable.
Re: On blockchains and why secure ledgers don't require proof-of-work
#9Straw man. Blockchain consensus algorithms don't only use proof of work. We have proof of stake, delegated proof of stake like LISK, proof of Correctness like Ripple (my personal favorite), and so on.
No need for a wasteful arms race just to elect a leader who can be DDOSed.
Re: On blockchains and why secure ledgers don't require proof-of-work
#10Security can be extremely simple and efficient when you just have to trust a third party. The author is describing Linked Timestamping [1], which has been detailed since the early 90's.
Removing the need for trust is what takes all the energy.