Raft Block Signature

[dbryan0516]

This Pull Request implements block signing for the raft consensus protocol. Currently, any node could cheat by rewriting a block and re-build the chain from that block onward, in its local copy of the chain, and there's no telling that cheating has occurred and which node has the original copy. By implementing block signing, no follower nodes would be able to rewrite the content because they don't have the leader's nodeKey

This is implemented similarly to clique, where a 32-byte vanity and a seal is added to the extraData header field. During block creation, the raft ID of the leader is combined with the leader's signature of the block in a struct, which is then rlp encoded for storage into the extraData field after the vanity.

For the signing to work, the nodeKey needs to be passed further along to the minter. This is possible by adding a nodeKey field to the raftService and changing the backend type of the minter to the more specific raftService struct, similar to clique and IBFT.

[jpmsam]

Thanks @dbryan0516! This was a todo for us, can you please complete the CLA and email it to [email protected].

[dbryan0516]

Hey @jpmsam, I just sent it in!

[fixanoid]

@jpmsam CLA received

[joelburget]

Hi @dbryan0516, thanks for submitting this! The biggest question I have is why does the signature use the raft ID? I'd expect it to use the enode id.

[jimthematrix]

@joelburget thanks for the review, the reason we chose to encode the Raft ID into the extraData structure instead of the enode ID is that it felt redundant to include the enode ID because you can already recover the proposer's address from the signature itself, which is functionally equivalent to the enode ID. On the other hand, the proposer's Raft ID is otherwise non-existent on the chain itself, so doing this provides a strong binding b/w the node and the Raft cluster. This could be useful in situations like forensic investigation to trace activities from the Raft cluster logs to the blockchain, and vice versa.

[joelburget]

Hi @jimthematrix -- thanks for the explanation. I'll think about it and get back to you in a day or two.

[dbryan0516]

Is there something blocking/preventing this from being merged?

[fixanoid]

@dbryan0516 hey, were still reviewing this pull and will decide on the best path forward for raft signing after next release which is coming shortly.

[trung]

Just a nitpick

Also, please do gofmt and optimize the imports

[dbryan0516]

Made those requested changes for optimizing imports and changing the pointer logic

[jpmsam]

Thanks @dbryan0516 and @jimthematrix for your work and contribution!