<p>I think you're mistaking PoW for a mechanism that guarantees the chain's correctness, rather than just a means for finding consensus.</p>

<p>A blockchain (without PoW) is just an ordered list of batched updates to a database.</p>

<p>PoW is one mechanism to guarantee that everyone eventually ends up on the same chain, but it doesn't guarantee that this chain is valid. Validity is enforced because non-miner full nodes actually validate all the operations in the chain to determine correctness.</p>

<p>If you remove PoW, you need another mechanism to obtain consensus. One way of doing that is having the block by signed by a trusted set of nodes. This means you're trusting those nodes to not sign multiple conflicting chains. However, it does not necessarily mean you trust them to assert validity of that chain. You can still have full nodes that verify that the chain being created is valid. In order to do that, your set of updates must be identifiable. A hash chain is one way of doing that.</p>

<p>If you're going to fully trust whatever your trusted parties sign without any validation, just use a replicated database instead. What a blockchain adds is simply a mechanism for identifying and auditing updates.</p>

<p>To be clear, I don't think there are all that many uses for permissioned blockchain technology, and a lot of the claimed advantages are hype. However, some of them will likely turn out to be a modern instantiation of BFT systems with auditability, and be boring but quite useful.</p>

CC BY-SA 3.0
2018-03-21T09:19:16.197Z
Thanks for clarifying that **consensus about the longest chain** and **validity** are two different things! 

However, I’m not sure I understood your sentence *„In order to do that, your set of updates must be identifiable. A hash chain is one way of doing that.“* correctly. - Do you mean that e.g. each new block has to be signed by the miner and this signature verified, so that no alien miner could fake blocks? - But why would one need a hash **chain** for that? Or in other words, why would you need to store a record of the validation into the blockchain?
Andrusch
CC BY-SA 3.0
2018-03-21T17:02:10.517Z
In order to verify that a batch of updates ("a block") is valid, you need to know what state it builds on. A very reasonable way to do so is to include the hash of the previous update that led to that state. Otherwise you could for example miss one update due to being offline, download the latest block, and find it invalid due to e.g. spending a coin that doesn't exist in your eyes (because it was created in a block that you missed).
Pieter Wuille
CC BY-SA 3.0
2018-03-20T22:12:47.197Z
2018-03-20T22:12:47.197Z
Pieter Wuille
<p>I think this question does not have a good answer, because there is no strict, general definition of what a 'permissioned blockchain' is. </p>

<p>In general, if only certain participants are allowed to extend the chain's history, then trust must be placed in those participants to not alter the record. Less participants means more trust must be placed in each individual participant.</p>

<p>What a participant (or a colluding majority of participants) can alter will depend on the rules of the specific system in question. A cryptography-enforced block ordering may or may not be alterable, it depends on the protocol. </p>

<blockquote>
  <p>So why would you need to add a hash of the preceding block to a new block in a permissioned blockchain since there's no proof of work and thus linking the blocks in this manner does not provide any help to solve the double spending problem?</p>
</blockquote>

<p>Doing so establishes an ordered history for transactions, but in a permissioned system you're still going to need to trust that the permissioned participants are not acting maliciously. So the use of a 'blockchain'-type architecture does not bring about the benefits normally seen with an actual blockchain system (like bitcoin), at least not for users (since the user needs to trust the permissioned actors). Perhaps an argument could be made that a blockchain architecture could allow the permissioned participants to interact in a less trusted way, but again that does not quite capture the user-facing benefits that a blockchain network normally provides. </p>

CC BY-SA 3.0
2018-03-20T21:55:06.430Z
2018-03-20T21:55:06.430Z
chytrik
<p><strong>My question:</strong> Do the blocks in a blockchain without proof-of-work (i.e. a permissioned blockchain) have to be linked together via a cryptographic hash?</p>

<p><strong>Longer version of my question</strong>:</p>

<p><em>(Please correct me if some of my remarks contain mistakes)</em></p>

<p>The blocks of a blockchain are linked to each other so that after <em>proof-of-work</em> their content cannot be easily faked, right? If several new blocks were created on top of a block which contains my transaction, I can be pretty sure that I'm on the longest blockchain and my transaction can't be faked (i.e. the <em>double spending problem</em> is solved).</p>

<p>However, <em>in a permissioned blockchain there's no proof of work</em>. As far as I know, in permissioned blockchains agreement on the longest chain (i.e. <em>consensus</em>) is reached by having a majority of blockchain participants agree on the longest chain. But since there's no proof-of-work, <em>51% attacks</em> (pretending to be the longest blockchain while containing blocks with tampered transactions) are much easier to achieve, or am I wrong?</p>

<p>So why would you need to add a hash of the preceding block to a new block in a permissioned blockchain since there's no proof of work and thus linking the blocks in this manner does not provide any help to solve the double spending problem?</p>

<doublespend><proof-of-work><private-blockchains><hyperledger>
Why are blocks in a permissioned blockchain linked together?
Andrusch
# Why are blocks in a permissioned blockchain linked together?

(Asked by: username_0 on 2018-03-20)

**My question:** Do the blocks in a blockchain without proof-of-work (i.e. a permissioned blockchain) have to be linked together via a cryptographic hash?

**Longer version of my question**:

*(Please correct me if some of my remarks contain mistakes)*

The blocks of a blockchain are linked to each other so that after *proof-of-work* their content cannot be easily faked, right? If several new blocks were created on top of a block which contains my transaction, I can be pretty sure that I'm on the longest blockchain and my transaction can't be faked (i.e. the *double spending problem* is solved).

However, *in a permissioned blockchain there's no proof of work*. As far as I know, in permissioned blockchains agreement on the longest chain (i.e. *consensus*) is reached by having a majority of blockchain participants agree on the longest chain. But since there's no proof-of-work, *51% attacks* (pretending to be the longest blockchain while containing blocks with tampered transactions) are much easier to achieve, or am I wrong?

So why would you need to add a hash of the preceding block to a new block in a permissioned blockchain since there's no proof of work and thus linking the blocks in this manner does not provide any help to solve the double spending problem?

**Tags:** doublespend, proof-of-work, private-blockchains, hyperledger


---

## 2 answers

### Answer by username_1 on 2018-03-20. Score: 2

I think you're mistaking PoW for a mechanism that guarantees the chain's correctness, rather than just a means for finding consensus.

A blockchain (without PoW) is just an ordered list of batched updates to a database.

PoW is one mechanism to guarantee that everyone eventually ends up on the same chain, but it doesn't guarantee that this chain is valid. Validity is enforced because non-miner full nodes actually validate all the operations in the chain to determine correctness.

If you remove PoW, you need another mechanism to obtain consensus. One way of doing that is having the block by signed by a trusted set of nodes. This means you're trusting those nodes to not sign multiple conflicting chains. However, it does not necessarily mean you trust them to assert validity of that chain. You can still have full nodes that verify that the chain being created is valid. In order to do that, your set of updates must be identifiable. A hash chain is one way of doing that.

If you're going to fully trust whatever your trusted parties sign without any validation, just use a replicated database instead. What a blockchain adds is simply a mechanism for identifying and auditing updates.

To be clear, I don't think there are all that many uses for permissioned blockchain technology, and a lot of the claimed advantages are hype. However, some of them will likely turn out to be a modern instantiation of BFT systems with auditability, and be boring but quite useful.

> **Comments:**
> **username_0**: Thanks for clarifying that **consensus about the longest chain** and **validity** are two different things!   However, I’m not sure I understood your sentence *„In order to do that, your set of updates must be identifiable. A hash chain is one way of doing that.“* correctly. - Do you mean that e.g. each new block has to be signed by the miner and this signature verified, so that no alien miner could fake blocks? - But why would one need a hash **chain** for that? Or in other words, why would you need to store a record of the validation into the blockchain?  
> **username_1**: In order to verify that a batch of updates ("a block") is valid, you need to know what state it builds on. A very reasonable way to do so is to include the hash of the previous update that led to that state. Otherwise you could for example miss one update due to being offline, download the latest block, and find it invalid due to e.g. spending a coin that doesn't exist in your eyes (because it was created in a block that you missed).  

---

### Answer by username_2 on 2018-03-20. Score: 0

I think this question does not have a good answer, because there is no strict, general definition of what a 'permissioned blockchain' is.

In general, if only certain participants are allowed to extend the chain's history, then trust must be placed in those participants to not alter the record. Less participants means more trust must be placed in each individual participant.

What a participant (or a colluding majority of participants) can alter will depend on the rules of the specific system in question. A cryptography-enforced block ordering may or may not be alterable, it depends on the protocol.

> So why would you need to add a hash of the preceding block to a new block in a permissioned blockchain since there's no proof of work and thus linking the blocks in this manner does not provide any help to solve the double spending problem?

Doing so establishes an ordered history for transactions, but in a permissioned system you're still going to need to trust that the permissioned participants are not acting maliciously. So the use of a 'blockchain'-type architecture does not bring about the benefits normally seen with an actual blockchain system (like bitcoin), at least not for users (since the user needs to trust the permissioned actors). Perhaps an argument could be made that a blockchain architecture could allow the permissioned participants to interact in a less trusted way, but again that does not quite capture the user-facing benefits that a blockchain network normally provides.


---

