Currently consensus uses a simple random number generstor
It should use common coin \(a random number jointly generated by all nodes\)

Ask Natasha Kolenova for full logs and reproducibility \(and see attached logs\)

\(hint: sktest\_performance on 4 nodes many times\)

Note: node1 stopped at ~14 transactions while others proceeded up to 21k.

1. Fix memory leaks
2. Run in Valgrind to fix memory corruptions.
3. Remove all unsafe memory accessesl
4. Fix all major compiler warnings

The reduce chain should perform key-value reduce operation similar to Hadoop/Spark

https://www.safaribooksonline.com/library/view/learning-spark/9781449359034/ch04.html

Key-value reduce is needed to perform aggregation of payments or other operations performed in different Map chains in Map-Reduce atchitecture. Normally key is the payee and value is the amound paid

The result of map reduce performed for a particular reduce block shall be available as input to Map smart contracts for the next block

Example:

Each user maintains a payee account with a key on each Map subchain, and a payor account with the same key on a particular subchain.

Payee accounts are used to acumulate accepted payments, and payor accounts are used to pay.

After the Map phase a smart contract on each subchain produces a set of payee - amount key/value pairs that it wants to aggregated. The pairs are passed to the reduce phase and aggregated by key. This means that payments made to the same user on different subchains are aggregated. After that the aggregated payment message is send to the subchain where the corresponding user payor account is maintained, and the payor account is credited.

In this way payments can be scaled to millions of users.

To implement this we need key/value aggregation \(adding up values by key\) performed during the reduce phase and then
message send operation that sends aggregated value to the subchain where the corresponding payor account is stored.

This uses threshold signatures

It is not possible to create several instances of ConsensusEngine because all of them use the same global variables. It makes difficulties for testing and is the cause of ConsensusTests unit test suite does not work.
We want to make it possible to run several instances to test their communication in scope of one process.

Move repo to skalenetwork and erase all the commit history.

Start skaled with bad ip or port numbers\(may be ports occupied by other apps\) and handle bind errors correctly.

Just checked this server that D1 spun up just 12 hrs ago, and noticed that it crashed. see comments for log files. Note this new error:

\[2019-02-04 04:54:57.595\] \[config\] \[info\] Char\*, ErrorHandler&&\) \[with Char = char; ErrorHandler = fmt::v5::internal::id*adapter<fmt::v5::format*handler<fmt::v5::arg*formatter<fmt::v5::back*insert*range<fmt::v5::internal::basic*buffer<char> > >, char,
                fmt::v5::basic*format*context<std::back*insert*iterator<fmt::v5::internal::basic\_buffer<char> >, char> >&, char>&\]

Sergej found this

test/unittests/mapreduce\_consensus

Each schain needs to get performance/resources proportional to staked tokens

One contract should be able to send a message to another contract across chains

After block commit, do additional verification of correctness of transactions \(nonces etc\) in transaction queue. Do not use separate queue in consensus.

Sergej found this