Файл: Аннотация Цель данной работы предоставить первое описание блокчейнплатформы ton (The Open Network) и связанных с ней технологий одноранговых сетей, распределенного хранилища и хостинга..pdf

40 2.6. Создание и проверка новых блоков знать как минимум очередь выходных сообщений нового блока после того, как его хэш будет зафиксирован в мастерчейне.
Чтобы предупредить эту проблему, новый блок должен собирать подписи от некоторых других валидаторов (например, двух третей объединения групп задач соседних шардчейнов), свидетельствующих о том, что эти валидаторы действительно имеют копии этого блока и готовы отправить их любым другим валидаторам при необходимости. Только после предоставления этих подписей хэш нового блока может быть включен в мастерчейн.
2.6.19. Блоки мастерчейна генерируются позже, чем блоки шардчейна. Блоки мастерчейна генерируются примерно раз в пять секунд, как и блоки шардчейна.
Однако в то время как генерация новых блоков во всех шардчейнах выполняется по существу одновременно (обычно этот процесс запускается после выпуска нового блока мастерчейна), генерация новых блоков мастерчейна намеренно задерживается, чтобы обеспечить включение хэшей вновь сгенерированных блоков шардчейна в мастерчейне.
2.6.20. Более медленные валидаторы могут получать меньшее вознаграждение.
Если валидатор работает «медленно», он может не успевать проверить новые блоки- кандидаты, и две трети подписей, необходимых для фиксации нового блока, могут быть собраны без его участия. В этом случае он получит меньшую долю вознаграждения, связанного с этим блоком.
Это дает валидаторам стимул оптимизировать свое оборудование, программное обеспечение и сетевое соединение, чтобы обрабатывать транзакции пользователей как можно быстрее.
Однако если валидатору не удается подписать блок до его фиксации, его подпись может быть включена в один из следующих блоков, а затем часть вознаграждения
(экспоненциально уменьшается в зависимости от того, сколько блоков было сгенерировано с тех пор - например, 0.9
k
, если валидатор опаздывает на k блоков) будет по-прежнему передана этому валидатору.

41 2.6. Создание и проверка новых блоков
Таким образом, валидатор, подписавший блок B, не может быть наказан, если исходное состояние s оказывается «некорректным» (например, из-за невалидности одного из предыдущих блоков). Фишермен (см. 2.6.4) может указать на ошибку, только если он находит относительно невалидный блок. Система PoS в целом стремится сделать каждый блок относительно валидным, а не рекурсивно (или абсолютно) валидным. Однако следует обратить внимание, что если все блоки в блокчейне являются относительно валидными, то все они и блокчейн в целом являются абсолютно валидными; это утверждение легко проиллюстрировать с помощью математической индукции по длине блокчейна. Таким образом, легко проверяемые утверждения об относительной валидности блоков вместе демонстрируют гораздо большую абсолютную валидность всего блокчейна.
Обратите внимание: подписывая блок B, валидатор утверждает, что блок является валидным в исходном состоянии s (т. е. результат (24) не является значением ?, указывающим, что следующее состояние не может быть вычислено). Таким образом, валидатор должен выполнять минимальные формальные проверки ячеек исходного состояния, к которым осуществляется доступ во время оценки (24).
Например, представим, что ячейка, которая, как ожидается, будет содержать исходный баланс учетной записи, к которой осуществляется доступ из зафиксированной в блоке транзакции, имеет нулевые необработанные байты вместо ожидаемых 8 или 16 байтов. Тогда исходный баланс просто не может быть получен из ячейки, и при попытке обработать блок происходит «необработанное исключение».
В этом случае валидатор не должен подписывать такой блок под угрозой наказания.
2.6.23. Подписание блоков мастерчейна. Ситуация с блоками мастерчейна несколько иная: подписывая блок мастерчейна, валидатор подтверждает не только его относительную валидность, но и относительную валидность всех предшествующих блоков до самого первого блока, с которого этот валидатор начал проверять блоки (но не дальше).
2.6.24. Общее количество валидаторов. Верхний лимит T для общего числа валидаторов, которых можно выбрать (см. 2.6.7), не может быть в описанной системе больше чем, скажем, несколько сотен или тысяча, потому что все валидаторы должны принимать участие в протоколе консенсуса BFT для создания каждого нового блока мастерчейна, и неясно, могут ли такие протоколы масштабироваться до тысяч участников. Ещё более важно, что блоки мастерчейна должны собирать подписи как минимум двух третей валидаторов (по стейку), и эти подписи должны быть включены в новый блок (иначе все другие ноды в системе не будут иметь причины доверять новому блоку до собственноручной его валидации). Если, скажем, одна тысяча подписей валидаторов будет включаться в каждый блок мастерчейна, это будет подразумевать больше информации в каждом блоке мастерчейна, которую нужно хранить всем полным нодам и распространять через сеть, и больше вычислительной мощности будет тратиться на проверку этих подписей (в PoS-системе полные ноды не должны валидировать блоки сами по себе, но должны проверять подписи валидаторов вместо этого).
Хотя ограничение T до тысячи валидаторов выглядит более эффективным для первой фазы развертывания блокчейна TON, должен быть запас для будущего роста, когда общее число шардчейнов станет настолько большим, что нескольких сотен валидаторов не будет достаточно для обработки их всех. С этой целью мы представляем дополнительный конфигурируемый параметр T′ ≤ T (изначально равный T), и только верхние T′ выбранных валидаторов (по стейку) будут создавать и подписывать новые блоки мастерчейна.

42 2.6. Создание и проверка новых блоков
2.6.25. Децентрализация системы. Можно заподозрить, что Proof-of-Stake система, такая как блокчейн TON, полагающаяся на T≈1000 валидаторов для создания всех блоков шардчейнов и мастерчейна, обязательно станет «слишком централизованной», в противовес общепринятым Proof-of-Work блокчейнам, таким как Биткоин или
Эфириум, где все (в принципе) могут майнить новые блоки, без явно выраженного верхнего лимита на число майнеров.
Однако популярные Proof-of-Work блокчейны, такие как Биткоин и Эфириум, на текущий момент требуют огромного количества вычислительной мощности (высокие
«хэш-рейты») для майнинга новых блоков с приемлемой вероятностью успеха. Таким образом, майнинг новых блоков имеет тенденцию концентрироваться в руках нескольких крупных игроков: одни инвестируют большие деньги в датацентры и специальное программное обеспечение, оптимизированное для майнинга, другие же концентрируют и координируют усилия больших групп людей, неспособных самостоятельно предоставить достаточный «хэш-рейт», тем самым образуя крупные майнинг-пулы.
Таким образом, по состоянию на 2017 год больше чем 75% новых блоков Эфириума и Биткоина создаются менее чем десятью майнерами. Фактически, два крупнейших майнинг-пула Эфириума производят вместе больше половины всех новых блоков!
Очевидно, такая система намного более централизована чем та, которая полагается на
T≈1000 нод для производства новых блоков.
Также следует отметить, что вложения, необходимые для того, чтобы стать валидатором блокчейна TON - то есть, для приобретения оборудования (скажем, несколько высокопроизводительных серверов) и стейка (который при необходимости может быть легко собран через пул номинаторов; см. 2.6.3) - намного меньше, чем требуемые для успешного самостоятельного майнинга Биткоина или Эфириума. По сути, параметр L будет заставлять номинаторов не присоединяться к крупнейшему "майнинг-пулу" (то есть, к валидатору, который собрал крупнейший стейк), но, скорее, искать меньших валидаторов, на данный момент собирающих средства от номинаторов, или даже создавать новых валидаторов, потому что это обеспечит более высокую пропорцию s′
i
/s i
стейка валидатора — и как следствие номинатора, откуда следует более высокая награда за майнинг. Таким образом, Proof-of-Stake система
TON на самом деле поощряет децентрализацию (создание и использование большего числа валидаторов) и наказывает централизацию.
2.6.26. Относительная надежность блока. (Относительная) надежность блока - это просто сумма стейков всех валидаторов, подписавших данный блок. Другими словами, это сумма денег, которую некоторые акторы потеряют, если этот блок окажется невалидным. Если передаваемая транзакциями стоимость ниже уровня надежности блока, их можно считать достаточно безопасными. В этом смысле относительная надежность - это мера доверия внешнего наблюдателя по отношению к определенному блоку.
Обратите внимание, что показатель относительной надежности блока является гарантией валидности блока, при условии, что предыдущий блок и все упомянутые блоки других шардчейнов являются валидными (см. 2.6.22).
Относительная надежность блока может возрастать после его фиксации — например, при добавлении подписей «медленных» валидаторов (см. 2.6.21). С другой стороны, если один из этих валидаторов теряет часть или весь свой стейк из-за его некорректности, связанной с некоторыми другими блоками, относительная надежность блока может снизиться.
2.6.27. «Усиление» блокчейна. Важно создать стимулы для валидаторов, чтобы максимально повысить относительную надежность блоков. Один из способов сделать
- это выделить небольшое вознаграждение валидаторам за добавление подписей к

43 2.6. Создание и проверка новых блоков блокам других шардчейнов. Даже «потенциальные» валидаторы, которые внесли сумму, недостаточную для того, чтобы попасть в ТОП T валидаторов по размеру стейка и быть включенными в глобальный набор валидаторов (см. 2.6.7), могут участвовать в этой деятельности (если они согласны оставить свой стейк вместо того, чтобы снимать его после неудачных результатов отбора). Такие потенциальные валидаторы могут выступать в роли фишерменов (см. 2.6.4): если им все равно нужно проверять валидность определенных блоков, они могут также сообщать о невалидных блоках и получать связанные с ними вознаграждения.
2.6.28. Рекурсивная надежность блока. Рекурсивную надежность блока можно определить как минимум его относительной надежности и рекурсивной надежности всех блоков, на которые он ссылается (т. е. блок мастерчейна, предыдущего блока шардчейна и некоторых блоков соседних шардчейнов). Другими словами, если блок окажется невалидным сам по себе, либо потому, что недействителен один из блоков, от которых он зависит, то кем-то будет потеряна как минимум эта сумма денег. Если пользователь действительно не уверен, следует ли доверять конкретной транзакции в блоке, следует вычислить рекурсивную надежность этого блока, а не только относительную.
Нет смысла возвращаться слишком далеко назад при вычислении рекурсивной надежности – в этом случае мы увидим блоки, подписанные валидаторами, чьи ставки уже были разморожены и сняты. Как бы то ни было, мы не позволяем валидаторам автоматически пересматривать слишком старые блоки (т. е. блоки, созданные более двух месяцев назад, если используются текущие значения настраиваемых параметров) и создавать на их основании форки, либо исправлять их с помощью «вертикальных блокчейнов» (см. 2.1.17), даже если они окажутся невалидными. Мы предполагаем, что два месяца – это достаточный период для того, чтобы обнаружить невалидные блоки и сообщить о них, поэтому, если валидность блока не будет оспариваться в течение этого периода, она вряд ли будет оспариваться когда-либо.
2.6.29. Последствия подхода Proof-of-Stake для неполных нод. Важным следствием подхода Proof-of-Stake, используемого в блокчейне TON, является то, что неполной ноде (запускающей «облегченное» клиентское программное обеспечение) блокчейна
TON не нужно загружать «заголовки» всех шардчейнов или даже блоков мастерчейна, чтобы иметь возможность самостоятельно проверить достоверность доказательств
Меркла, предоставленных неполной ноде полными нодами в качестве ответов на ее запросы.
В самом деле, поскольку самые последние хэши блоков шардчейна включены в блоки мастерчейна, полная нода может легко предоставить доказательство Меркла, что данный блок шардчейна является валидным, начиная с известного хэша блока мастерчейна. Кроме того, неполная нода должна «знать» только самый первый блок мастерчейна (где объявляется самый первый набор валидаторов), который (или, по крайней мере, хэш которого) может быть встроен в клиентское программное обеспечение, и только один блок мастерчейна примерно каждый месяц после этого, когда объявляются новые наборы валидаторов, потому что этот блок будет подписан предыдущим набором валидаторов. Начиная с этого момента, нода может получить несколько самых последних блоков мастерчейна, либо как минимум их заголовки и подписи валидаторов, и использовать их в качестве основы для проверки доказательств Меркла, предоставленных полными нодами.
2.7. Разделение и объединение шардчейнов
Одной из наиболее характерных и уникальных особенностей блокчейна TON является его способность автоматически разделять шардчейн на две части, когда нагрузка становится слишком высокой, и объединять их обратно, если нагрузка снижается (см.

44 2.7. Разделение и объединение шардчейнов
2.1.10). Эту особенность следует обсудить более подробно из-за ее уникальности и важности для масштабируемости всего проекта.
2.7.1. Конфигурация шарда. Напомним, что в любой момент времени каждый воркчейн w разбивается на один или несколько шардчейнов (w, s) (см. 2.1.8). Эти шардчейны могут быть представлены листьями двоичного дерева, корнем (w, 0) и каждым не-листовым узлом (w, s), имеющим дочерние элементы (w, s.0) и (w, s.1).
Таким образом, каждая учетная запись в воркчейне w назначается ровно одному шарду, и все, кто знают текущую конфигурацию шардчейна, могут определить сегмент (w, s), содержащий учетную запись account_id: это единственный сегмент с двоичной строкой s, являющейся префиксом account_id.
Конфигурация шарда - то есть это двоичное дерево шарда или совокупность всех активных (w, s) для данного w (соответствующего листьям двоичного дерева шарда)
- является частью состояния мастерчейна и доступна всем, кто отслеживает мастерчейн
22
2.7.2. Самая последняя конфигурация и состояние шарда. Напомним, что хэши самых последних блоков шардчейна включены в каждый блоков мастерчейна. Эти хэши организованы в двоичное дерево шардов (на самом деле это набор деревьев, по одному на каждый воркчейн). Таким образом, каждый блок мастерчейна содержит самую последнюю конфигурацию шарда.
2.7.3. Объявление и внесение изменений в конфигурацию шарда. Конфигурацию шарда можно изменить двумя способами: шард (w, s) можно разделить на два шарда
(w, s.0) и (w, s.1), либо два «родственных» шарда (w, s .0) и (w, s.1) можно объединить в один шард (w, s).
Эти операции разделения/слияния объявляются несколькими блоками заранее
(например, 2 6
- это настраиваемый параметр), сначала в «заголовках» соответствующих блоков шардчейна, а затем в блоке мастерчейна, который относится к этим блокам шардчейна. Такое заблаговременное объявление позволяет всем заинтересованным сторонам подготовиться к запланированному изменению
(например, создать оверлейную многоадресную сеть для распределения новых блоков вновь созданных шардчейнов, как описано в 3.3). Затем изменение фиксируется сначала в блоке (или заголовке) шардчейна (в случае разделения; при слиянии блоки обоих шардчейнов должны зафиксировать изменение), а затем передается на блоки мастерчейна. Таким образом, блок мастерчейна определяет не только самую последнюю конфигурацию шарда перед его созданием, но также и следующую конфигурацию шарда.
2.7.4. Группы задач валидаторов для новых шардчейнов. Напомним, что для каждого шардчейна обычно назначается подмножество валидаторов (группа задач валидаторов), предназначенных для создания и проверки новых блоков в соответствующем шардчейне (см. 2.6.8). Эти группы задач избираются на некоторый период времени (приблизительно один час), являются известными заранее (также приблизительно за час) и остаются неизменными в течение этого периода времени
23
Однако фактическая конфигурация шардчейнов может измениться в течение этого периода времени из-за операций разделения/слияния. Необходимо назначить группы задач для вновь созданных шардов. Это делается следующим образом:
22
На самом деле конфигурация шарда полностью определяется последним блоком мастерчейна; это упрощает получение доступа к конфигурации шарда.
23
Если некоторые валидаторы будут временно или навсегда забанены из-за подписания невалидных блоков, то они автоматически исключаются из всех групп задач.