blockchain data structure should be able to prove its own validity

[corecode]

Currently there are no signatures attached to a block on the ledger. To validate (a prefix of) the blockchain, f+1 (out of 2f+1) correct peers will have to agree on the hash of the top block.

If that number of correct peers does not exist anymore, the whole blockchain cannot be trusted anymore.

Causes of this could be:

• enough peers are destroyed in a fire/meteorite/godzilla strike
• rogue chaincode or attackers take over peers and compromise data
• more than f peers collude (byzantine) and claim alternate history
• companies go out of business or move to a different software solution

Adding signatures to blocks could be one way of addressing this issue.

[ghaskins]

I didn't realize we weren't doing this already. I think this is critically important.

[adecaro]

I agree with @corecode, signatures are required. Not sure if they are sufficient in all the cases listed but definitely they should be there. :+1:

[vukolic]

An easy fix - have PBFT commit msgs signed by the validating peers, making sure that they also sign the hash of the batch. Log the commit certificate (this time w. 2f+1 signatures - that you need to make sure verify correctly before logging them). NB: Blocks should be hashchained together for easier integrity verification.

@adecaro This was intended long time ago - but dropped because of very poor sign/verify performance of ECC384. Where do we stand now with crypto, is digital signature algo configurable?

[corecode]

@vukolic You mean instead of sending a list of transactions, send a complete block instead? That would work.

[zmanian]

Adding signatures to the block is an important step towards enabling light client applications and portability of state across blockchains.

In the light client version, presenting a signed block hash and merkle proof of the current state can all a light client to trust that ledger state has been updated correctly. Examples of this are the Bitcoin SPV model, the Ethereum Light client protocol and Tendermint light client protocol.

In the blockchain portabability land, another distributed ledger verifies a proof from a foreign consensus algorithm to update it's own state. An example of this pattern is the original sidechains paper or the BTCRelay smart contract on Ethereum.

[ghost]

I would note that in post-quantum you'd have to update your signing algorithm, but other than that...