Stresstesting for thundermint

Сейчас неясно, какая пропускная способность у Thundermint, насколько хорошо он работает в большой сети, насколько хорошо работает сеть при сбоях отдельных узлов и связей между ними.

Поэтому необходимо разработать инструментарий для нагрузочного тестирования Thundermint.

Он должен позволять:

* Запускать сеть узлов Thundemint произвольного, указанного в конфиге размера на произвольных машинах;
* Задавать длительность работы сети в количестве достигнутых блоков;
* Случайным образом "убивать" узлы и связи между ними, перезапускать узлы спустя некоторое случайное время;
* Выдавать простейшие метрики:
* количество реального времени от начала и до генерации последнего блока;
* TODO

В частности, создав "идеальную" сеть (без сбоев) и запустив в ней одно из тестовых приложений на базе Thundermint, можно понять, какая его реальная скорость в транзакциях/секунду. Ещё предполагается, что если же запустить такую сбойную сеть и дать ей очень долго поработать (дни/недели), то вскроется масса мелких маловероятных багов, практически не обнаруживаемых при локальном тестировании.

----

Для замера скорости введём два экспримента:

* **эксперимент 1**. Нужно проверить скорость Thundermint в "идеальной" сети, без сбоев, в сети с хорошей связью. Для этого можно запустить сеть Thundermint на некоторую высоту (напр., `--max-h 1000`, после чего посмотреть время работы узлов и количество обработанных транзакций. Тем самым будет получена скорость в идеальной сети. Надо получить скорость в идеальной сети для нескольких размеров: 4, 5, 6, 7, 8, 9, 10, 16, 32, 64 узла.
* **эксперимент 2**. Нужно проверить скорость работы Thundermint в "реальной сети", когда часть нод "убивается", сеть нестабильная и т.д.

Замечание про транзакции и размер блока. Консенсус проходит несколько фаз:

* выбор узла-пропозера,
* предложение блока (блок создаётся из транзакций, рассылается по сети),
* предварительное голосование,
* окончательное голосование,
* сохранение блока в БЧ.

Вся последовательность образует один раунд (round); раунд может не заканчиваться, а по таймауту или другим причинам начинаться заново

Переход между фазами осуществляется по таймауту, поэтому 100% загрузки CPU получить не удатся. С другой стороны, увеличивая размер блока, увеличивается время его передачи по сети, и алгоритм может не "сходится", т.е. узлы не будут синхронизированы полностью: например, часть узлов уже получили блок и могут начать голосование, а другие только скачивают его. Кроме того, если блок большой, то его проверка тоже может затягиваться.

Поэтому в экспериментах надо подобрать такой размер блока, чтобы, с одной стороны, тратилось много времени на его создание и проверку, но с другой сторны, алгоритм оставался синхронным. По видимому, придётся подбирать размер блока экспериментально --- начать с маленького, и увеличивать его до тех пор, пока алгоритм не начнёт расходиться (это будет видно по увеличению Round в логах -- попыток снова прогнать всю последовательность "выбор -- предложение блока -- предголосование -- голосование -- коммит")

----

Такое решение уже начинали делать, однако дело не завершилось. Оно основано на том, что есть тестовое приложение thundermint-coin-node, которое запускается на кластере Terraform.

Ещё для локального запуска используется скрипт `start-coin-node-cluster-locally.sh`, который запускает четыре узла и дожидается завершения (см. параметр `--max-h` в скрипте).

Поэтому первым делом надо:

* [ ] разобраться с тестовым приложением `thundermint-coin-node`: как оно запускается, что делает, какие параметры у него есть. Необходимо также понять, каким образом представляются тестовые транзакции в том приложении, какой размер блока, сколько транзакций в блоке. Это потребуется потом, чтобы понять, какая пропускная способность у сети.
* [ ] добиться работы `start-coin-node-cluster-locally.sh` локально.
* [ ] подготовка к эксперименту 1: проверить скорость работы такого кластера локально, подобрав размер блока так, как описано выше (чтобы дальше нельзя было увеличивать без "расхождения" алгоритма).

После этого переходить к Terraform-решению:

* [ ] разобраться с теми скриптами Terraform, которые уже есть.
* [ ] добиться их работы: запуска 10 узлов локально.

Затем можно осуществить первый эксперимент по проверке скорости Thundermint:

* [ ] проверить, что Terraform-скрипты работают не только локально, но и в Интернет: добиться работы Terraform-кластера из 4-х машин в сети. Для этого привлечь Рому в помощь.
* [ ] собственно "эксперимент 1": запустить в "идеальной сети", померять скорость на разных размерах сети (от 4-х узлов до 64-х узлов).

---------

Подготовка к нестабильной сети.

Нужно сделать так, чтобы можно было разворачивать кластер в сети и эмулировать эту нестабильность: "убивать" случайным образом отдельные узлы сети, "убивать" или "тормозить" связи между ними.

Для начала поискать готовые решения, возможно, такие системы для нагрузочного тестирования (stress testing) уже есть. Тогда надо приспособить для наших целей.

Если найти не удалось, то написать самостоятельно. Наверное, для этого можно использовать Haskell-пакет turtle, чтобы писать скрипто-подобные программы. Необходимо сделать решение, которое случайным образом "портит" сеть.

Уточню это позже, как дойдёшь до этого этапа.