Random Participation for new nodes

[andrecronje]

Allow new nodes to join the network randomly (and leave) while maintaining the participants table.

[andrecronje]

• Update the core consensus methods to use a dynamic list of participants.
• Define the interface between consensus and Application that enables dynamic changes to the peers list.
• Create a special type of transaction for Entry/Exit requests that gets intercepted by consensus and handled in a special way. This is a non-standard type of transaction because consensus does not read and interpret normal transactions.
• Extend the proxy interface with a method to interrogate the application if an JoinRequest should be accepted.
• Monitor the transaction until it reaches consensus and approval by +1/3 of participants and update the participant list accordingly.

[Maxime2]

This is related to issue #8

[Maxime2]

At this point lachesis node does not look into transactions inside transactions block body. If we add special type of transactions for dynamic node addition/removal we would need to filter every transaction on the chain to find these special ones related to node addition/removal. This will directly impact performance of the chain in terms of tps, our primary goal in development at the moment.

Thus I see two approaches to implement dynamic addition/removal for nodes:

1. Add 1-byte prefix for every transaction entering the block chain, say byte 0x00 would indicate application layer transactions and bytes 0x01-0xFF would indicate special/internal lachesis transactions. That approach would allow us to fast filter special transactions out of application layer ones for the price of 1 byte per every transaction in the blockchain plus operations implementing transactions filtering (please note, lachesis nodes currently operate with transactions blocks as the minimal chunk of data passing between nodes).

2. Add separate poset store for internal transactions. That approach would require allocation of additional memory and hard drive storage for this store (as basically two lachesises would be run on every node), and thus would lead to increased hardware requirements to the nodes.

I welcome input from other developers on this dilemma and views on this issue from other perspectives.

[andrecronje]

Separate poset store for internal transactions. I have a semi implementation almost ready, will share tomorrow.

[devintegral]

outdated