Avalanche consensus family. Snowlfake. BFT.
В статье про Slush мы упоминали, что у него нет BFT — византийской отказоустойчивости. То есть, нет гарантий, что принятая транзакция не является мошеннической. Или не направлена на даблспенд (когда злоумышленник делает две оплаты на разные кошельки из одной транзакции). Узлы могут посчитать мошенническую транзакцию (например, синий цвет) предпочтительной для голосования большинства, поскольку сам по себе gossip-протокол не делает различий между правильными и неправильными транзакциями. Эту проблему частично решает следующий уровень — Snowflake.
Snowflake добавляет к Slush такую базовую функцию, как счетчик (назовем его cnt). Если вы помните, Slush использует память по-минимуму, поскольку не сохраняет информацию о раундах и обмене состояниями между узлами. Этот счетчик хранит количество последовательных выборок из сети, которые дают одинаковый результат, будь то красный или синий цвет. При каждом изменении цвета счетчик перезапускается с нуля.
В приведенном ниже примере есть узел, называемый IN (Initial Node — так мы будем называть его далее). IN получает транзакцию, красный цвет. Затем он окрашивается в красный цвет, его счетчик обнуляется (cnt = 0) и формируется выборка из других нод.
Если вы помните по предыдущей статье, в gossip-протоколе узлы, не имеющие транзакций (цвета) окрашиваются в цвет (соглашаются с транзакцией) узла-лидера выборки (IN); ноды, уже имеющие цвета — просто передают информацию об этом IN. Если цвета большинства узлов в выборке совпадают со цветом IN, то он не меняет его. Если цвет большинства отличается от IN, то тогда он уже меняет цвет.
В 1ом раунде IN после запроса у своей выборки получает 4 ответа красным и один синим, большинство — красный, счетчик устанавливается в позицию cnt=1.
Во 2ом раунде то же самое — 4 красных и один синий, в итоге снова красный цвет, счетчик уже cnt=2.
А в 3ем раунде узел IN со счетчиком cnt=2 становится синим, так как 4 ноды из 5— синие. Здесь счетчик сбрасывается до cnt=0, и IN берет цвет большинства.
После такого сброса цвета с красного на синий и счетчика на 0 во время 3го раунда, для раунда 4 возможны два случая:
1) Большинство опять за синий цвет, соответственно, IN сохраняет синий и увеличивается счетчик для этого цвета (cnt=1).
2) Если же больше голосов за красный, то IN меняет цвет на красный, и счетчик снова обнуляется (cnt=0).
После определенного количества последовательных выборок узел гарантированно принимает окончательный цвет. Количество раундов задается отдельным параметром для обозначения порога византийских нод и безопасности. Это позволяет правильным узлам взаимодействовать между собой и двигаться к консенсусу. В вайтпепере финализация называется “точка невозврата”, после нее решение уже неизбежно.
Другими словами, узел примет какой-либо цвет/одобрит транзакцию только когда его счетчик, в котором хранится количество последовательных записей по одному цвету, превысит заданный параметр безопасности β (пример ниже).
В итоге можно сказать, что Snowflake имеет следующие преимущества:
- Ноды имеют эфемерную память, в которой хранятся их текущие цвета и счетчики.
- Обмен данными между узлами не записывается, что делает Snowball очень легким протоколом
- Протокол имеет BFT
Тем не менее, имеется еще более усовершенствованная версия — Snowball, в котором реализована более надежная защита от сбоев с помощью счетчика доверия - истории для каждого цвета вместо постоянно обнуляющихся cnt у Snowflake. Также этот механизм позволяет еще более гарантированно склонить сеть к одному результату. Впрочем, это уже тема следующей статьи. Не переключайтесь!
- Telegram RU: https://t.me/AVA_Russia
- Medium RU: https://medium.com/ava-russia
- Twitter RU: https://twitter.com/Ava_Russia
- Announcement channel: https://t.me/AVA_announcements
- YouTube: https://www.youtube.com/
- Сайт проекта: https://www.avalabs.org/
