tcrain / cons Goto Github PK

When local random member selection is used, security relies on only the local node knowing the members.

Currently when an external node asks for recovery (i.e. in case of a lost message), the reply will, when loaded from disk contain the full state of the consensus instance which will reveal the members. Instead this should only contain the message sent by the local node.

Another issue is when using reliable broadcast, a set of Byzantine nodes can get the system to enter a sate when the Broadcast has started but not terminated, but the Byzantine nodes may allow it to
terminate later. This gives the attacker infinite time to identify and corrupt the member selection of nodes. A possible fix would be to allow a node to change members even for within the same reliable broadcast instance after a timeout, though this would need some careful design to ensure other properties are not broken.

The local random member selection type should be set using custom threshold instead of the usual
1/3 or 2/3. The reason is that the number of faults tolerated will be different given the randomization

Various discussions on things to add/improve in the project are found in TOADD.md,
eventually they should be added as issues.

Various issues are written in tofix, eventually they should be created as issues here.

Should add channels for transmitting metadata in a reliable way.
This could include things like

• updates of the addresses of the participants
• propagating transactions for the state machine
• ...

Allocation of buffers should be handled better.
Currently a message buffer may be copied multiple times after it is loaded from the network,
including when storing to disk.
After a message is read from the network there should be minimal copies.
It should also keep track of if a buffer is read only, so we know when it should be copied.
Also it would be nice to use a pool for message byte buffers to lessen impact of garbage collection.

There are points where crypto hashing is done even when not necessary, or done multiple times.
This especially is the case when not using signed messages.
Additionally, the hashes are sometimes used as keys in maps, where a shorter identifier should be used.