О стресс-тестах в сетях TON и Everscale

В последние пару дней многие заметили сложности в работе testnet TON и mainnet Everscale. Сейчас, когда обе сети работают в обычном режиме и постепенно обрабатывают последствия стресс-теста, можно поговорить и о причинах, вызвавших такое поведение сетей.

Как развивалось?

Эта история, как и многие из таких историй, началась с умелых рук и любознательной головы. 25 апреля один разработчик решил запустить «форк-бомбу» в виде контракта, который при получении сообщения посылает два сообщения себе же, порождая геометрическую прогрессию сообщений. Такие «бомбы» запускались уже не раз. Они работают пока хватает баланса. В рассматриваемом случае при тестировании был использован довольно большой баланс.

Начав с testnet TON и маленькой суммы (~50 тест-коинов) и убедившись, что все работает, разрабочик решил провести такой же тест и в mainnet Everscale, но уже с большей суммой. Обнаружив проблемы с производительностью —происходило значительное замедление генерации блоков в бейзчейне — он повторил атаку с большей суммой и в testnet TON.

В процессе присоединились и другие разработчики, добавив на контракт стресс-теста тысячи тестовых монет.

В testnet TON атака привела к следующему: атакованный контракт, который все же стабильно работал около двух часов, «провалился» в свой собственный шард, после чего также начала проявляться деградация производительности. Остальные шарды бейзчейна (т.е. ~94% сети) продолжили работать также, как и раньше.

Напротив атакованный шард 0:a8000... начал хандрить: блоки продолжали генерироваться, но очень медленно, раз в 10-20 минут, а иногда и с гораздо большими перерывами — до 40 минут. 26 апреля работа шарда чуть стабилизировалась: блоки по-прежнему генерировались редко, но уже без длительных перерывов. Наконец, 27 апреля блоки шарда начали генерироваться с нормальной скоростью:  до контракта дошли дополнительные монеты для атаки (удлиняя ее во времени), при этом производительность шарда стала ниже ожидаемой ~30 ТПС (https://testnet.dton.io/). В таком режиме сеть работает последние сутки, «разгребая» последствия атаки.

Сеть Everscale также начала восстанавливать работу утром 28 апреля.

Что произошло?

Проблема «форк-бомб» заключается в том, что, по мере своей работы, они бесконечно (пока хватает денег) наращивают очередь сообщений. Соответственно, чем дольше работает «бомба» и чем крупнее на ней баланс, тем длиннее очередь. И, если работа с очередью не до конца оптимизирована, то обработка транзакций и генерация новых блоков может замедляться.

Это и произошло с testnet TON, когда оказалось, что часть проверок при коллации (создании новых блоков) и валидации (их проверки) работала не только с той частью очереди сообщений которая непосредственно затрагивается в транзакциях блоков, а и со всей очередью. 

Несмотря на многочисленные ограничители и заложенную Николаем Дуровым архитектуру TON, в которой уделено специальное внимание оптимизациям подобных операций, через 2 часа экспоненциального наращивания очереди, проблемы производительности «догнали» валидаторов. 

Решение

В ходе устранения проблем, разработчики TON предложили два нововведения:

• дополнительное ограничение при коллации — нода перестает читать новые сообщения из очереди, если это дольше определенного времени;
• упрощение избыточных проверок при валидации. 

Таким образом были убраны операции работающие на всей очереди сообщений, и размер очереди перестал влиять на валидацию и коллацию. 

После раскатывания обновленного кода на ноды testnet — сеть восстановила нормальную работу.

По-видимому, разработчики Everscale тоже оптимизировали работу сети другим образом.

*****

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