Файл: Аннотация Цель данной работы предоставить первое описание блокчейнплатформы ton (The Open Network) и связанных с ней технологий одноранговых сетей, распределенного хранилища и хостинга..pdf
Добавлен: 25.10.2023
Просмотров: 231
Скачиваний: 3
ВНИМАНИЕ! Если данный файл нарушает Ваши авторские права, то обязательно сообщите нам.
2.6.4. Фишермен: получение денег за указание на чужие ошибки. Другой способ получить награду без необходимости становиться валидатором это возможность стать фишерменом. По сути, любая нода может стать фишерменом, сделав небольшой депозит в мастерчейн. После этого она может через специальные транзакции в мастерчейне публиковать доказательства (Меркла) невалидности каких-либо блоков
(обычно в шардчейнах), ранее подписанных и опубликованных валидаторами. Если другие валидаторы соглашаются с доказательством невалидности, обвиняемые валидаторы наказываются (потерей части их стейка), и фишермен получает награду
(часть монет, конфискованных у обвиняемых валидаторов). После чего невалидный блок (шардчейна) должен быть исправлен, как описано в 2.1.17. Исправление невалидных блоков мастерчейна может вовлекать создание "вертикальных" блоков поверх ранее включенных блоков мастерчейна (см. 2.1.17); необходимость создавать форк мастерчейна отсутствует.
Обычно фишермену может потребоваться стать полной нодой для хотя бы некоторых шардчейнов и тратить вычислительные ресурсы на выполнение кода хотя бы некоторых смарт-контрактов. Хотя фишермену не нужно иметь столько же вычислительной мощности как валидатору, мы считаем обычной кандидатурой в фишермены тех, кто мог бы быть валидатором, но не был выбран в качестве валидатора (например, из-за невозможности внесения достаточно большого стейка).
2.6.5. Коллаторы: получение денег за предложение новых блоков валидаторам.
Еще один способ получать награду без становления валидатором - это становление коллатором. Это нода, которая готовит и предлагает валидаторам кандидаты в блоки шардчейна, дополненные (collated) данными, взятыми из состояния этого шардчейна и из других (обычно соседних) шардчейнов, вместе с приемлемыми доказательствами
Меркла. (Это необходимо, например, когда некоторые сообщения нужно переслать из соседних шардчейнов.) Затем валидатор может легко проверить предложенный блок- кандидат на валидность без необходимости скачивать всё состояние этого или других шардчейнов.
Поскольку валидатору нужно отправлять новые (collated) кандидаты в блоки для получения награды, есть смысл платить часть награды коллатору, желающему предоставить подходящих блоков-кандидатов. Таким образом, валидатор может освободить себя от необходимости следить за состоянием соседних шардчейнов, отдавая это на аутсорс коллатору.
36 2.6. Создание и проверка новых блоков
Тем не менее, мы ожидаем, что в фазе изначального развертывания системы в ней не будет отдельно назначенных коллаторов, поскольку все валидаторы будут иметь возможность являться коллаторами для самих себя.
2.6.6. Коллататоры или валидаторы: получение денег за включение
пользовательских транзакций. Пользователи могут открывать каналы микроплатежей для некоторых коллекторов или валидаторов и платить небольшие суммы монет в обмен на включение своих транзакций в шардчейн.
2.6.7. Отбор «глобального» набора валидаторов. «Глобальный» набор валидаторов выбирается один раз в месяц (фактически, каждые 2 19
блоков мастерчейна). Этот набор определяется и становится общеизвестным за месяц вперед.
Чтобы стать валидатором, узел должен передать несколько монет TON в мастерчейн, а затем отправить их на специальный смарт-контракт в качестве предлагаемого стейка. Другой параметр, отправляемый вместе со стейком, - это l
≥
1, максимальная проверочная нагрузка, которую этот узел готов принять, относительно минимально возможной. Также существует глобальная верхняя граница (еще один настраиваемый параметр) L для l, равная, скажем, 10.
Затем этот смарт-контракт выбирает глобальный набор валидаторов, просто выбирая до T кандидатов с максимальными предлагаемыми ставками и публикуя их описание.
Изначально общее количество валидаторов T = 100; мы ожидаем, что оно вырастет до
1000 по мере увеличения нагрузки. Этот параметр является настраиваемым (см.
2.1.21),
Фактический стейк каждого валидатора рассчитывается следующим образом: если верхние значения T предложенных стейков составляют s
1
≥
s
2
≥
• • •
≥
s
T
, то фактический стейк i-го валидатора устанавливается на s’
i
: = min (s i
, l i
• s
T
). Таким образом, s’
i
/s’
T
≤
l i
, поэтому i-й валидатор не получает больше чем l i
≤
L раз больше нагрузки самого слабого валидатора (поскольку нагрузка в конечном итоге пропорциональна стейку).
Затем избранные валидаторы могут отозвать неиспользованную часть своего стейка, s
i
— s’
i
. Кандидаты, которые не стали валидаторами, могут отозвать всю свою предложенную долю.
Каждый валидатор публикует свой открытый ключ подписи, не обязательно равный открытому ключу учетной записи, из которой был получен стейк
20
Ставки валидаторов замораживаются до окончания срока, на который они были избраны, а также еще на один месяц на случай возникновения новых споров (т.е. обнаружения невалидного блока, подписанного одним из этих валидаторов). После этого стейк возвращается вместе с долей валидатора в монетах и комиссиями от транзакций, обработанных за это время.
2.6.8. Выбор «групп задач» валидаторов. Весь глобальный набор валидаторов (где каждый валидатор считается присутствующим с множественностью, равной его стейку - в противном случае у валидатора может возникнуть соблазн использовать несколько идентификаторов и разделить свой стейк между ними) используется только для проверки новых блоков мастерчейна. Блоки шардчейна проверяются только специально выбранными подмножествами валидаторов из глобального набора валидаторов, выбранных в соответствии с п. 2.6.7.
20
Имеет смысл генерировать и использовать новую пару ключей при каждом подборе валидаторов
37 2.6. Создание и проверка новых блоков
Эти «подмножества» или «группы задач» валидаторов, определенные для каждого шарда, меняются каждый час (фактически, каждые 2 10
блоков мастерчейна), причем они становятся известны за час вперед, так что каждый валидатор знает, какие шарды ему необходимо будет проверить, и может подготовиться к этому (например, загрузив недостающие данные шардчейна).
Для выбора групп задач валидаторов для каждого шарда (w, s) применяется детерминированный псевдослучайный алгоритм.
Он использует псевдослучайные числа, встроенные валидаторами в каждый блок мастерчейна (сгенерированные путем получения консенсуса с использованием пороговых сигнатур) для создания случайного начального числа, а затем вычисляет, например, Hash(code(w): code(s):validator_id:rand_seed) для каждого валидатора.
Затем валидаторы сортируются по значению этого хэша, и выбираются первые несколько валидаторов, имеющих не менее 20/T от общих стеков валидаторов (группа состоит как минимум из 5 валидаторов).
Этот выбор может быть сделан с помощью специального смарт-контракта. В этом случае алгоритм выбора можно было бы легко обновить без хард-форков с помощью механизма голосования, упомянутого в 2.1.21. Все другие упомянутые до сих пор
«константы» (такие как 2 19
, 2 10
, T, 20 и 5) также являются настраиваемыми параметрами.
2.6.9. Смена приоритета в каждой группе задач. Для членов группы задач шарда вводится определенный «приоритетный» порядок, зависящий от хэша предыдущего блока мастерчейна и порядкового номера блока (шардчейна). Этот порядок определяется путем генерации и сортировки хэшей, как описано выше.
Когда необходимо сгенерировать новый блок шардчейна, валидатор группы задач шарда, выбранный для создания этого блока, обычно является первым в отношении этого чередующегося «приоритетного» порядка. Если создать блок не удается, это может сделать второй или третий валидатор. По сути, все они могут предлагать своих блоки-кандидаты, однако кандидат, предложенный валидатором с наивысшим приоритетом, должен победить в результате применения протокола консенсуса
(задача византийских генералов, BFT).
2.6.10. Распространение блоков-кандидатов шардчейна. Поскольку членство в группе задач шардчейна известно за час вперед, их участники могут использовать это время для создания выделенной «многоадресной оверлейной сети для валидаторов шардчейна», используя общие механизмы сети TON (см. 3.3). Когда необходимо сгенерировать новый блок шардчейна - обычно через одну или две секунды после создания самого последнего блок мастерчейна – все валидаторы знают, у кого наивысший приоритет для генерации следующего блока (см. 2.6.9). Этот валидатор создает новый блок-кандидат либо сам, либо с помощью коллатора (см. 2.6.5).
Валидатор должен проверить (подтвердить) этот блок-кандидат (особенно, если он был подготовлен коллатором) и подписать его своим закрытым ключом (валидатора).
Затем блок-кандидат распространяется на оставшуюся часть группы задач с использованием заранее организованной оверлейной сети многоадресной рассылки
(группа задач создает свою собственную частную оверлейную сеть, как описано в п.
3.3, а затем использует версию протокола многоадресной потоковой передачи, описанную в п. 3.3.15, для распространения блоков-кандидатов).
Наиболее правильный метод – это использование BFT протокола многоадресной рассылки, такого, который используется в Honey Badger BFT [11]: закодировать блока-кандидата с помощью кода стирания (N, 2N/3), отправить 1/N полученных данных непосредственно каждому члену группы и ожидать, что они будут передавать свою часть данных в рамках многоадресной рассылки напрямую всем другим членам группы.
38 2.6. Создание и проверка новых блоков
Однако более быстрый и простой способ сделать это (см. также 3.3.15) заключается в том, чтобы разбить блок-кандидат на последовательность подписанных однокилобайтных блоков («фрагментов»), дополнить их последовательность с помощью кода Рида-Соломона или исходного кода (такой как RaptorQ [9] [14]) и начать передачу фрагментов соседним узлам в «сетке многоадресной рассылки» (т. е. оверлейной сети), ожидая, что они будут распространять эти фрагменты дальше.
Как только валидатор получает достаточно фрагментов для восстановления на их основе блока-кандидата, он подписывает валидацию и распространяет ее по всем соседям в своей группе. Затем соседи валидатора перестают посылать ему новые фрагменты, но могут продолжать отправлять (исходные) подписи этих фрагментов, полагая, что этот узел может генерировать последующие фрагменты, применяя код
Рида-Соломона или фонтанный код (имея все необходимые данные), объединить их с подписями и передать их соседним узлам, которые еще не закончили процесс валидации.
Если «многоадресная сетка» (оверлейная сеть) остается подключенной после удаления всех «плохих» узлов (напомним, что до одной трети узлов могут вести себя злонамеренно), этот алгоритм распространяет блок-кандидат как можно быстрее.
Не только назначенный создатель высокоприоритетного блока может выполнять многоадресную рассылку своего блока-кандидата на всю группу. Валидаторы со вторым и третьим приоритетом могут начать многоадресную рассылку своих блоков- кандидатов либо сразу, либо после того, как не получили блок-кандидат от валидатора с наивысшим приоритетом. Однако обычно только блок-кандидат с максимальным приоритетом будет подписан всеми валидаторами (фактически как минимум двумя третями группы задач) и зафиксирован как новый блок шардчейна.
2.6.11. Проверка блоков-кандидатов. Сразу после получения блока-кандидата валидатором и проверки его исходной подписи принимающий валидатор проверяет валидность этого блока-кандидата, выполняя все транзакции и контролируя, чтобы их результат совпадал с заявленным результатом. Все сообщения, импортированные из других блокчейнов, должны поддерживаться подходящими доказательствами Меркла в сопоставленных данных, в противном случае блок-кандидат считается невалидным
(и, если соответствующее доказательство было передано в мастерчейн, уже подписавшие этот блок-кандидат валидаторы могут быть наказаны). С другой стороны, если блок-кандидат признан валидным, принимающий валидатор подписывает его и распространяет свою подпись другим валидаторам в группе либо через «ячеистую многоадресную сеть», либо посредством прямых сетевых сообщений.
Следует подчеркнуть, что валидатору не нужен доступ к состояниям текущего или соседних шардчейнов для проверки валидности (сопоставленного) блока-кандидата
21
Это позволяет проводить валидацию очень быстро (без доступа к диску) и снижает вычислительную нагрузку и нагрузку на хранилище для валидаторов (особенно если они готовы принять услуги внешних коллаторов для создания блоков-кандидатов).
2.6.12. Отбор следующего блока кандидата. Как только блок-кандидат собирает не менее двух третей (по стейкам) подписей валидаторов в группе задач, он может быть зафиксирован в качестве следующего блока шардчейна.
21
Возможным исключением является состояние выходных очередей соседних шардчейнов, необходимое для обеспечения требований к порядку сообщений, описанных в 2.4.21, поскольку в этом случае размер доказательств Меркла может стать непомерно высоким.
39 2.6. Создание и проверка новых блоков
Протокол BFT используется для достижения консенсуса по выбранному блоку- кандидату (может быть предложено несколько блоков), при этом все «хорошие» валидаторы предпочитают блок-кандидат с наивысшим приоритетом для этого раунда. В результате использования этого протокола блок дополняется подписями не менее двух третей валидаторов (по стекам).
Эти подписи свидетельствуют не только о валидности рассматриваемого блока, но и о его отборе в соответствии с протоколом BFT. После этого блок (без сопоставленных данных) объединяется с этими подписями, сериализуется детерминированным способом и передается по сети всем заинтересованным сторонам.
2.6.13. Валидаторы должны сохранять подписанные ими блоки. Ожидается, что во время своего членства в группе задач и в течение как минимум одного часа (или, скорее, 2 10
блоков) после этого валидаторы будут сохранять блоки, которые они подписали и зафиксировали. Непредставление подписанного блока другим валидаторам может повлечь за собой штрафные санкции.
2.6.14. Передача заголовков и подписей новых блоков шардчейна всем
валидаторам. Валидаторы передают заголовки и подписи вновь созданных блоков шардчейна глобальному набору валидаторов, используя многоадресную ячеистую сеть, аналогичную той, которая создается для каждой группы задач.
2.6.15. Генерация новых блоков мастерчейна. После того, как все (или почти все) новые блоков шардчейна были сгенерированы, может быть сгенерирован новый блоков мастерчейна. Процедура, по существу, такая же, как и для блоков шардчейна
(см. 2.6.12), с той лишь разницей, что все валидаторы (или как минимум две трети из них) должны участвовать в этом процессе. Поскольку заголовки и подписи новых блоков шардчейна передаются всем валидаторам, хэши самых новых блоков в каждом шардчейне могут и должны быть включены в новый блок мастерчейна. После того, как эти хэши будут зафиксированы в блоке мастерчейна, внешние наблюдатели и другие шардчейны могут считать новые блоки шардчейна зафиксированными и неизменными (см. 2.1.13).
2.6.16. Валидаторы должны сохранять состояние мастерчейна. Заслуживающая внимания разница между мастерчейном и шардчейном заключается в том, что все валидаторы должны отслеживать состояние мастерчейна, не полагаясь на сопоставленные данные. Это важно, потому что информация, получаемая группой задач валидаторов, основана на состоянии мастерчейна.
2.6.17. Блоки шардчейна генерируются и распространяются параллельно.
Обычно каждый валидатор является членом нескольких групп задач шардчейна; их количество (и, следовательно, нагрузка на валидатора) примерно пропорционально стейку валидатора. Это означает, что валидатор параллельно запускает несколько экземпляров нового протокола генерации блоков шардчейна.
2.6.18. Предупреждение атак с удержанием блоков. Поскольку полный набор валидаторов вставляет хэш нового блока шардчейна в мастерчейн после просмотра только его заголовка и подписей, существует небольшая вероятность того, что валидаторы, которые сгенерировали этот блок, вступят в сговор и попытаются избежать публикации нового блока целиком. Это приведет к неспособности валидаторов соседних шардчейнов создавать новые блоки, потому что они должны
(обычно в шардчейнах), ранее подписанных и опубликованных валидаторами. Если другие валидаторы соглашаются с доказательством невалидности, обвиняемые валидаторы наказываются (потерей части их стейка), и фишермен получает награду
(часть монет, конфискованных у обвиняемых валидаторов). После чего невалидный блок (шардчейна) должен быть исправлен, как описано в 2.1.17. Исправление невалидных блоков мастерчейна может вовлекать создание "вертикальных" блоков поверх ранее включенных блоков мастерчейна (см. 2.1.17); необходимость создавать форк мастерчейна отсутствует.
Обычно фишермену может потребоваться стать полной нодой для хотя бы некоторых шардчейнов и тратить вычислительные ресурсы на выполнение кода хотя бы некоторых смарт-контрактов. Хотя фишермену не нужно иметь столько же вычислительной мощности как валидатору, мы считаем обычной кандидатурой в фишермены тех, кто мог бы быть валидатором, но не был выбран в качестве валидатора (например, из-за невозможности внесения достаточно большого стейка).
2.6.5. Коллаторы: получение денег за предложение новых блоков валидаторам.
Еще один способ получать награду без становления валидатором - это становление коллатором. Это нода, которая готовит и предлагает валидаторам кандидаты в блоки шардчейна, дополненные (collated) данными, взятыми из состояния этого шардчейна и из других (обычно соседних) шардчейнов, вместе с приемлемыми доказательствами
Меркла. (Это необходимо, например, когда некоторые сообщения нужно переслать из соседних шардчейнов.) Затем валидатор может легко проверить предложенный блок- кандидат на валидность без необходимости скачивать всё состояние этого или других шардчейнов.
Поскольку валидатору нужно отправлять новые (collated) кандидаты в блоки для получения награды, есть смысл платить часть награды коллатору, желающему предоставить подходящих блоков-кандидатов. Таким образом, валидатор может освободить себя от необходимости следить за состоянием соседних шардчейнов, отдавая это на аутсорс коллатору.
36 2.6. Создание и проверка новых блоков
Тем не менее, мы ожидаем, что в фазе изначального развертывания системы в ней не будет отдельно назначенных коллаторов, поскольку все валидаторы будут иметь возможность являться коллаторами для самих себя.
2.6.6. Коллататоры или валидаторы: получение денег за включение
пользовательских транзакций. Пользователи могут открывать каналы микроплатежей для некоторых коллекторов или валидаторов и платить небольшие суммы монет в обмен на включение своих транзакций в шардчейн.
2.6.7. Отбор «глобального» набора валидаторов. «Глобальный» набор валидаторов выбирается один раз в месяц (фактически, каждые 2 19
блоков мастерчейна). Этот набор определяется и становится общеизвестным за месяц вперед.
Чтобы стать валидатором, узел должен передать несколько монет TON в мастерчейн, а затем отправить их на специальный смарт-контракт в качестве предлагаемого стейка. Другой параметр, отправляемый вместе со стейком, - это l
≥
1, максимальная проверочная нагрузка, которую этот узел готов принять, относительно минимально возможной. Также существует глобальная верхняя граница (еще один настраиваемый параметр) L для l, равная, скажем, 10.
Затем этот смарт-контракт выбирает глобальный набор валидаторов, просто выбирая до T кандидатов с максимальными предлагаемыми ставками и публикуя их описание.
Изначально общее количество валидаторов T = 100; мы ожидаем, что оно вырастет до
1000 по мере увеличения нагрузки. Этот параметр является настраиваемым (см.
2.1.21),
Фактический стейк каждого валидатора рассчитывается следующим образом: если верхние значения T предложенных стейков составляют s
1
≥
s
2
≥
• • •
≥
s
T
, то фактический стейк i-го валидатора устанавливается на s’
i
: = min (s i
, l i
• s
T
). Таким образом, s’
i
/s’
T
≤
l i
, поэтому i-й валидатор не получает больше чем l i
≤
L раз больше нагрузки самого слабого валидатора (поскольку нагрузка в конечном итоге пропорциональна стейку).
Затем избранные валидаторы могут отозвать неиспользованную часть своего стейка, s
i
— s’
i
. Кандидаты, которые не стали валидаторами, могут отозвать всю свою предложенную долю.
Каждый валидатор публикует свой открытый ключ подписи, не обязательно равный открытому ключу учетной записи, из которой был получен стейк
20
Ставки валидаторов замораживаются до окончания срока, на который они были избраны, а также еще на один месяц на случай возникновения новых споров (т.е. обнаружения невалидного блока, подписанного одним из этих валидаторов). После этого стейк возвращается вместе с долей валидатора в монетах и комиссиями от транзакций, обработанных за это время.
2.6.8. Выбор «групп задач» валидаторов. Весь глобальный набор валидаторов (где каждый валидатор считается присутствующим с множественностью, равной его стейку - в противном случае у валидатора может возникнуть соблазн использовать несколько идентификаторов и разделить свой стейк между ними) используется только для проверки новых блоков мастерчейна. Блоки шардчейна проверяются только специально выбранными подмножествами валидаторов из глобального набора валидаторов, выбранных в соответствии с п. 2.6.7.
20
Имеет смысл генерировать и использовать новую пару ключей при каждом подборе валидаторов
37 2.6. Создание и проверка новых блоков
Эти «подмножества» или «группы задач» валидаторов, определенные для каждого шарда, меняются каждый час (фактически, каждые 2 10
блоков мастерчейна), причем они становятся известны за час вперед, так что каждый валидатор знает, какие шарды ему необходимо будет проверить, и может подготовиться к этому (например, загрузив недостающие данные шардчейна).
Для выбора групп задач валидаторов для каждого шарда (w, s) применяется детерминированный псевдослучайный алгоритм.
Он использует псевдослучайные числа, встроенные валидаторами в каждый блок мастерчейна (сгенерированные путем получения консенсуса с использованием пороговых сигнатур) для создания случайного начального числа, а затем вычисляет, например, Hash(code(w): code(s):validator_id:rand_seed) для каждого валидатора.
Затем валидаторы сортируются по значению этого хэша, и выбираются первые несколько валидаторов, имеющих не менее 20/T от общих стеков валидаторов (группа состоит как минимум из 5 валидаторов).
Этот выбор может быть сделан с помощью специального смарт-контракта. В этом случае алгоритм выбора можно было бы легко обновить без хард-форков с помощью механизма голосования, упомянутого в 2.1.21. Все другие упомянутые до сих пор
«константы» (такие как 2 19
, 2 10
, T, 20 и 5) также являются настраиваемыми параметрами.
2.6.9. Смена приоритета в каждой группе задач. Для членов группы задач шарда вводится определенный «приоритетный» порядок, зависящий от хэша предыдущего блока мастерчейна и порядкового номера блока (шардчейна). Этот порядок определяется путем генерации и сортировки хэшей, как описано выше.
Когда необходимо сгенерировать новый блок шардчейна, валидатор группы задач шарда, выбранный для создания этого блока, обычно является первым в отношении этого чередующегося «приоритетного» порядка. Если создать блок не удается, это может сделать второй или третий валидатор. По сути, все они могут предлагать своих блоки-кандидаты, однако кандидат, предложенный валидатором с наивысшим приоритетом, должен победить в результате применения протокола консенсуса
(задача византийских генералов, BFT).
2.6.10. Распространение блоков-кандидатов шардчейна. Поскольку членство в группе задач шардчейна известно за час вперед, их участники могут использовать это время для создания выделенной «многоадресной оверлейной сети для валидаторов шардчейна», используя общие механизмы сети TON (см. 3.3). Когда необходимо сгенерировать новый блок шардчейна - обычно через одну или две секунды после создания самого последнего блок мастерчейна – все валидаторы знают, у кого наивысший приоритет для генерации следующего блока (см. 2.6.9). Этот валидатор создает новый блок-кандидат либо сам, либо с помощью коллатора (см. 2.6.5).
Валидатор должен проверить (подтвердить) этот блок-кандидат (особенно, если он был подготовлен коллатором) и подписать его своим закрытым ключом (валидатора).
Затем блок-кандидат распространяется на оставшуюся часть группы задач с использованием заранее организованной оверлейной сети многоадресной рассылки
(группа задач создает свою собственную частную оверлейную сеть, как описано в п.
3.3, а затем использует версию протокола многоадресной потоковой передачи, описанную в п. 3.3.15, для распространения блоков-кандидатов).
Наиболее правильный метод – это использование BFT протокола многоадресной рассылки, такого, который используется в Honey Badger BFT [11]: закодировать блока-кандидата с помощью кода стирания (N, 2N/3), отправить 1/N полученных данных непосредственно каждому члену группы и ожидать, что они будут передавать свою часть данных в рамках многоадресной рассылки напрямую всем другим членам группы.
38 2.6. Создание и проверка новых блоков
Однако более быстрый и простой способ сделать это (см. также 3.3.15) заключается в том, чтобы разбить блок-кандидат на последовательность подписанных однокилобайтных блоков («фрагментов»), дополнить их последовательность с помощью кода Рида-Соломона или исходного кода (такой как RaptorQ [9] [14]) и начать передачу фрагментов соседним узлам в «сетке многоадресной рассылки» (т. е. оверлейной сети), ожидая, что они будут распространять эти фрагменты дальше.
Как только валидатор получает достаточно фрагментов для восстановления на их основе блока-кандидата, он подписывает валидацию и распространяет ее по всем соседям в своей группе. Затем соседи валидатора перестают посылать ему новые фрагменты, но могут продолжать отправлять (исходные) подписи этих фрагментов, полагая, что этот узел может генерировать последующие фрагменты, применяя код
Рида-Соломона или фонтанный код (имея все необходимые данные), объединить их с подписями и передать их соседним узлам, которые еще не закончили процесс валидации.
Если «многоадресная сетка» (оверлейная сеть) остается подключенной после удаления всех «плохих» узлов (напомним, что до одной трети узлов могут вести себя злонамеренно), этот алгоритм распространяет блок-кандидат как можно быстрее.
Не только назначенный создатель высокоприоритетного блока может выполнять многоадресную рассылку своего блока-кандидата на всю группу. Валидаторы со вторым и третьим приоритетом могут начать многоадресную рассылку своих блоков- кандидатов либо сразу, либо после того, как не получили блок-кандидат от валидатора с наивысшим приоритетом. Однако обычно только блок-кандидат с максимальным приоритетом будет подписан всеми валидаторами (фактически как минимум двумя третями группы задач) и зафиксирован как новый блок шардчейна.
2.6.11. Проверка блоков-кандидатов. Сразу после получения блока-кандидата валидатором и проверки его исходной подписи принимающий валидатор проверяет валидность этого блока-кандидата, выполняя все транзакции и контролируя, чтобы их результат совпадал с заявленным результатом. Все сообщения, импортированные из других блокчейнов, должны поддерживаться подходящими доказательствами Меркла в сопоставленных данных, в противном случае блок-кандидат считается невалидным
(и, если соответствующее доказательство было передано в мастерчейн, уже подписавшие этот блок-кандидат валидаторы могут быть наказаны). С другой стороны, если блок-кандидат признан валидным, принимающий валидатор подписывает его и распространяет свою подпись другим валидаторам в группе либо через «ячеистую многоадресную сеть», либо посредством прямых сетевых сообщений.
Следует подчеркнуть, что валидатору не нужен доступ к состояниям текущего или соседних шардчейнов для проверки валидности (сопоставленного) блока-кандидата
21
Это позволяет проводить валидацию очень быстро (без доступа к диску) и снижает вычислительную нагрузку и нагрузку на хранилище для валидаторов (особенно если они готовы принять услуги внешних коллаторов для создания блоков-кандидатов).
2.6.12. Отбор следующего блока кандидата. Как только блок-кандидат собирает не менее двух третей (по стейкам) подписей валидаторов в группе задач, он может быть зафиксирован в качестве следующего блока шардчейна.
21
Возможным исключением является состояние выходных очередей соседних шардчейнов, необходимое для обеспечения требований к порядку сообщений, описанных в 2.4.21, поскольку в этом случае размер доказательств Меркла может стать непомерно высоким.
39 2.6. Создание и проверка новых блоков
Протокол BFT используется для достижения консенсуса по выбранному блоку- кандидату (может быть предложено несколько блоков), при этом все «хорошие» валидаторы предпочитают блок-кандидат с наивысшим приоритетом для этого раунда. В результате использования этого протокола блок дополняется подписями не менее двух третей валидаторов (по стекам).
Эти подписи свидетельствуют не только о валидности рассматриваемого блока, но и о его отборе в соответствии с протоколом BFT. После этого блок (без сопоставленных данных) объединяется с этими подписями, сериализуется детерминированным способом и передается по сети всем заинтересованным сторонам.
2.6.13. Валидаторы должны сохранять подписанные ими блоки. Ожидается, что во время своего членства в группе задач и в течение как минимум одного часа (или, скорее, 2 10
блоков) после этого валидаторы будут сохранять блоки, которые они подписали и зафиксировали. Непредставление подписанного блока другим валидаторам может повлечь за собой штрафные санкции.
2.6.14. Передача заголовков и подписей новых блоков шардчейна всем
валидаторам. Валидаторы передают заголовки и подписи вновь созданных блоков шардчейна глобальному набору валидаторов, используя многоадресную ячеистую сеть, аналогичную той, которая создается для каждой группы задач.
2.6.15. Генерация новых блоков мастерчейна. После того, как все (или почти все) новые блоков шардчейна были сгенерированы, может быть сгенерирован новый блоков мастерчейна. Процедура, по существу, такая же, как и для блоков шардчейна
(см. 2.6.12), с той лишь разницей, что все валидаторы (или как минимум две трети из них) должны участвовать в этом процессе. Поскольку заголовки и подписи новых блоков шардчейна передаются всем валидаторам, хэши самых новых блоков в каждом шардчейне могут и должны быть включены в новый блок мастерчейна. После того, как эти хэши будут зафиксированы в блоке мастерчейна, внешние наблюдатели и другие шардчейны могут считать новые блоки шардчейна зафиксированными и неизменными (см. 2.1.13).
2.6.16. Валидаторы должны сохранять состояние мастерчейна. Заслуживающая внимания разница между мастерчейном и шардчейном заключается в том, что все валидаторы должны отслеживать состояние мастерчейна, не полагаясь на сопоставленные данные. Это важно, потому что информация, получаемая группой задач валидаторов, основана на состоянии мастерчейна.
2.6.17. Блоки шардчейна генерируются и распространяются параллельно.
Обычно каждый валидатор является членом нескольких групп задач шардчейна; их количество (и, следовательно, нагрузка на валидатора) примерно пропорционально стейку валидатора. Это означает, что валидатор параллельно запускает несколько экземпляров нового протокола генерации блоков шардчейна.
2.6.18. Предупреждение атак с удержанием блоков. Поскольку полный набор валидаторов вставляет хэш нового блока шардчейна в мастерчейн после просмотра только его заголовка и подписей, существует небольшая вероятность того, что валидаторы, которые сгенерировали этот блок, вступят в сговор и попытаются избежать публикации нового блока целиком. Это приведет к неспособности валидаторов соседних шардчейнов создавать новые блоки, потому что они должны