Вариант решения проблем со сплитом + оптимизация быстродействия.
Всем добрый день, я с
@jason_forever предлагаю следующее решение вопроса, который решит в корне любой подобный вектор воздействия на сеть, когда создается нагрузка, которая, архитектурно, препятствует сплиту, и создает перегрузку.
Суть возникшей ситуации заключается в том, что сейчас, при перегрузке любой шарды, происходит разделение всех нагруженных на две.
В качестве делителя используется префикс адреса.
При определенных сценариях, например спаме на себя, это не позволит равномерно распределить нагрузку, в рамках архитектуры.
Так же это создает непропорциональную загрузку шард при любом их количестве, и никак не гарантирует оптимизацию работы цепочки смарт-контрактов (чтобы они, например, всегда были в одном шарде).
Наше решение предлагает изменить логику разделения и сделать следующим образом:
Вариант 1
Мы меняем мету и говорим, что у нас единое адресное пространство (все, что находится внутри воркчейна).
Каждое сообщение и транзакция маршрутизируются по round-robin на шард, если он один, либо на тот или иной шард (если их более 1). Те мы работаем только с хешем.
Преимущества:
1. Инкремент шард, минимально, всегда +1, без прогрессии.
2. Уменьшение нагрузок на сеть (нет лишних шард, без нагрузки)
3. От плавного до проактивного ответа на нагрузку (можно создать алгоритм, который приводит к выделению как одной шарды, при наступлении перегрузки, так и нескольких сразу)
4. Позволяет равномерно утилизировать все шарды, что есть.
Вариант 2
Мы пытаемся оптимизировать вариант 1, добавляя дополнительный атрибут цепочке интенсивно взаимодействующих друг с другом контрактов, пытаясь их совместить в 1 шарде.
При перегрузке (сбое в работе контракта, спаме, увеличении нагрузки), мы разделяем их по разным шардам.
Преимущества:
1. Уменьшение лишней активности между разными шардами при определенных сценариях.
2. Вероятно, уменьшение нагрузки, в том числе, сетевой.
Вариант 3
В дополнение. Мы вводим такое понятие как производительность шарды. Для этого необходимы объективные метрики каждой, чтобы RR алгоритм мог грузить их пропорционально, но:
- старался догружать те, которые работают объективно лучше.
- снимал нагрузку с тех, что обладают меньшей производительностью.