Consensus
https://eprint.iacr.org/2016/199.pdf
HoneyBadger is responsible for decrypting the shares and generate a valid message (transaction receipts) that will be accepted by all. Honey Badger gets the txes as input, encrypt it and send it to Common Subset. Common Subset generates more encrypted shares (one share for each validator) and returns them to Honey Badger. These encrypted shares are decrypted by Honey Badger. Note that the encrypted share came from tx receipt so it could be different for other validators. So for each encrypted share Honey Badger needs the decryption from other validators as well. So if the number of validators is N then N decryption for each encryted share and combining them (*interpolation) we get the full decrypted share for the corresponding encrypted share. Note that No one delivers their encrypted share, it is like a private key. And a node has its own encrypted share only, to get more encrypted shares (one for each validator) it depends on Common Subset to get them correctly.
This protocol generates an encrypted share for each validator and sends to HoneyBadger. To get that we need to communicate with other validators. Remember validator will not simply send their encrypted share. The reason could be trust issue or this share are meant to keep private. This protocol establishes a proper communication among validators with two sub-protocols: Reliable Broadcast and Binary Agreement
There are N instance of Reliable Broadcast (one for each validator). The purpose of this protocol is to process the shares from valdiators. An instance (let say instance 'i') will receive and process the messages related to the share of validator 'i'. If the current node is validator 'x', then the instance 'x' will receive the encrypted share from Common Subset and other instances will receive nothing from Common Subset.
The messaging is done in several steps: ValMessage, EchoMessage, ReadyMessage.
How ValMessage is created? Pieces of codewords are created for each validator from the encrypted share via ErasureCoding. The codewords are used as leaves to build Merkle Tree and ValMessages for validators. ValMessage sent to a validator consists of Merkle Root, codeword for that validator and Merkle Proof by which one can verify that the codeword is used as a leaf and the Merkle Root is valid. So ValMessage sent to valdiators are different, only Merkle Root is same.
EchoMessage is simply confirmation of ValMessage. When an instance 'i' receives a ValMessage from validator 'i', it constructs EchoMessage, copying the values of ValMessage, and delivers to everyone. Note that after receiving all EchoMessage, one can combine them and restore the whole Merkle Tree and all the codewords. So if every one is honest, then the process of sending ValMessage and EchoMessage is equivalent to sending the whole Merkle Tree and all codewords to everyone else. But we have to assume there could be dishonest validators, so instead of sending the whole thing, we are distributing the data to everyone else and they are confirming via EchoMessage.
So after enough EchoMessage is received, an instance 'i' can decode via ErasureCoding combining received EchoMessage and sends ReadyMessage which confirms that 'I just got all necessary info for validator i and decoded them properly'. It consists of only the Merkle Root. After receiving enough ReadyMessage, encrypted share is generated from EchoMessage and ReadyMessage and returned to Common Subset. The same process is happening in all instances.
