По сути, блокчейн TON состоит из блоков шардчейна и мастерчейна. Чтобы обеспечить бесперебойную и правильную работу системы, эти блоки должны создаваться, проверяться и распространяться по сети всем заинтересованным сторонам.
Валидаторы. Новые блоки создаются и проверяются специальными назначенными узлами, называемыми валидаторами. В сущности, любая желающая нода может стать валидатором, при условии внесения достаточно большого стейка (в монетах TON, см. Приложение A) в мастерчейн. Валидаторы получают «вознаграждения» за хорошую работу, а именно, комиссии за транзакции, хранение и газ со всех транзакций (сообщений), включенных в только что созданные блоки, и некоторое количество только что «отчеканенных» монет, что отражает «благодарность» всего сообщества валидаторам за поддержание работы блокчейна TON. Этот доход распределяется среди всех участвующих валидаторов пропорционально их стейкам.
Однако быть валидатором — это большая ответственность. Если валидатор подписывает невалидный блок, он может быть наказан потерей части или всего своего стейка, и временным или постоянным исключением из набора валидаторов. Если валидатор не участвует в создании блока, он не получает свою долю награды за этот блок. Если валидатор воздерживается от создания новых блоков длительное время, он может потерять часть стейка и быть временно или навсегда исключен из набора валидаторов.
Всё это значит, что валидатор не получает свои деньги «ни за что». Действительно, валидатор должен следить за состояниями всех или некоторых шардчейнов (каждый валидатор отвечает за валидацию и создание новых блоков в конкретном наборе шардчейнов), выполнять все вычисления для смарт-контрактов в этих шардчейнах, получать обновления о других шардчейнах и так далее. Эта деятельность требует значительного дискового пространства, вычислительной мощности и ширины интернет-канала.
Валидаторы вместо майнеров
Напомним, что блокчейн TON использует подход Proof-of-Stake, вместо подхода Proof-of-Work, используемого Биткоином, текущей версией Эфириума, и большинством других криптовалют. Это значит, что нельзя «майнить» новые блоки, предоставляя некое доказательство проделанной работы (вычисления большого количества в ином случае бесполезных хэшей) и получать в результате новые монеты. Вместо этого, нужно стать валидатором и тратить вычислительные мощности на хранение и обработку реквестов и данных блокчейна TON. Коротко говоря, нужно быть валидатором, чтобы «майнить» новые монеты. В этом смысле, валидаторы являются новыми майнерами.
Тем не менее, есть другие способы заработать монеты помимо становления валидатором.
Номинаторы и «майнинг-пулы»
Чтобы стать валидатором, обычно требуется приобретать и устанавливать несколько высокопроизводительных серверов и обеспечивать хорошее интернет-соединение для них. Это не так дорого как оборудование ASIC, на данный момент требуемое для майнинга Биткоинов.
Однако, майнить новые монеты TON определенно не получится на домашнем компьютере, не говоря о смартфоне.
В майнинг-сообществах Биткоина, Эфириума и других Proof-of-Work криптовалютах есть определение «майнинг-пулов» с большим количеством нод, которые сами по себе не имеют достаточно мощности для майнинга новых блоков, но объединяют усилия и впоследствии разделяют награду.
Соответствующим определением в мире Proof-of-Stake является номинатор. По сути, номинатор — это нода, одалживающая свои деньги, чтобы помочь валидатору увеличить его стейк. Впоследствии валидатор отдает соответствующую часть своей награды (или ранее согласованную её долю, скажем, 50%) номинатору.
В этом смысле номинатор также может принять участие в «майнинге» и получить часть награды пропорционально количеству денег, которую он желает одолжить для этой цели. Он получает только часть доли от награды валидатора, поскольку он предоставляет только «капитал», но не имеет нужды приобретать вычислительную мощность, дисковое пространство и интернет-канал.
Однако если валидатор теряет свой стейк из-за невалидного поведения, номинатор также теряет свою долю стейка. В этом понимании номинатор разделяет риск. Он должен выбирать номинированного валидатора мудро, иначе он может потерять деньги. В этом смысле номинаторы принимают взвешенное решение и «голосуют» за конкретных валидаторов своими деньгами.
С другой стороны, эта система номинирования или одалживания позволяет стать валидатором без изначального инвестирования большого количества денег в монеты TON. Другими словами, это не позволяет обладателям большого количества монет TON стать монополистом в среде валидаторов.
Фишермен: получение денег за указание на чужие ошибки
Другой способ получить награду без необходимости становиться валидатором это возможность стать фишерменом. По сути, любая нода может стать фишерменом, сделав небольшой депозит в мастерчейн. После этого она может через специальные транзакции в мастерчейне публиковать доказательства (Меркла) невалидности каких-либо блоков (обычно в шардчейнах), ранее подписанных и опубликованных валидаторами. Если другие валидаторы соглашаются с доказательством невалидности, обвиняемые валидаторы наказываются (потерей части их стейка), и фишермен получает награду (часть монет, конфискованных у обвиняемых валидаторов). После чего невалидный блок (шардчейна) должен быть исправлен. Исправление невалидных блоков мастерчейна может вовлекать создание «вертикальных» блоков поверх ранее включенных блоков мастерчейна; необходимость создавать форк мастерчейна отсутствует.
Обычно фишермену может потребоваться стать полной нодой для хотя бы некоторых шардчейнов и тратить вычислительные ресурсы на выполнение кода хотя бы некоторых смарт-контрактов. Хотя фишермену не нужно иметь столько же вычислительной мощности как валидатору, мы считаем обычной кандидатурой в фишермены тех, кто мог бы быть валидатором, но не был выбран в качестве валидатора (например, из-за невозможности внесения достаточно большого стейка).
Коллаторы: получение денег за предложение новых блоков валидаторам
Еще один способ получать награду без становления валидатором — это становление коллатором. Это нода, которая готовит и предлагает валидаторам кандидаты в блоки шардчейна, дополненные (collated) данными, взятыми из состояния этого шардчейна и из других (обычно соседних) шардчейнов, вместе с приемлемыми доказательствами Меркла. (Это необходимо, например, когда некоторые сообщения нужно переслать из соседних шардчейнов.) Затем валидатор может легко проверить предложенный блок-кандидат на валидность без необходимости скачивать всё состояние этого или других шардчейнов.
Поскольку валидатору нужно отправлять новые (collated) кандидаты в блоки для получения награды, есть смысл платить часть награды коллатору, желающему предоставить подходящих блоков-кандидатов. Таким образом, валидатор может освободить себя от необходимости следить за состоянием соседних шардчейнов, отдавая это на аутсорс коллатору.
Тем не менее, мы ожидаем, что в фазе изначального развертывания системы в ней не будет отдельно назначенных коллаторов, поскольку все валидаторы будут иметь возможность являться коллаторами для самих себя.
Коллататоры или валидаторы: получение денег за включение пользовательских транзакций
Пользователи могут открывать каналы микроплатежей для некоторых коллекторов или валидаторов и платить небольшие суммы монет в обмен на включение своих транзакций в шардчейн.
Отбор «глобального» набора валидаторов
«Глобальный» набор валидаторов выбирается один раз в месяц (фактически, каждые 219 блоков мастерчейна). Этот набор определяется и становится общеизвестным за месяц вперед.
Чтобы стать валидатором, узел должен передать несколько монет TON в мастерчейн, а затем отправить их на специальный смарт-контракт в качестве предлагаемого стейка. Другой параметр, отправляемый вместе со стейком, — это l ≥ 1, максимальная проверочная нагрузка, которую этот узел готов принять, относительно минимально возможной. Также существует глобальная верхняя граница (еще один настраиваемый параметр) L для l, равная, скажем, 10.
Затем этот смарт-контракт выбирает глобальный набор валидаторов, просто выбирая до T кандидатов с максимальными предлагаемыми ставками и публикуя их описание. Изначально общее количество валидаторов T = 100; мы ожидаем, что оно вырастет до 1000 по мере увеличения нагрузки. Этот параметр является настраиваемым.
Фактический стейк каждого валидатора рассчитывается следующим образом: если верхние значения T предложенных стейков составляют s1 ≥ s2 ≥ • • • ≥ sT, то фактический стейк i-го валидатора устанавливается на s’i: = min (si, li • sT). Таким образом, s’i/s’T ≤li, поэтому i-й валидатор не получает больше чем li ≤ L раз больше нагрузки самого слабого валидатора (поскольку нагрузка в конечном итоге пропорциональна стейку).
Затем избранные валидаторы могут отозвать неиспользованную часть своего стейка, si — s’i. Кандидаты, которые не стали валидаторами, могут отозвать всю свою предложенную долю.
Каждый валидатор публикует свой открытый ключ подписи, не обязательно равный открытому ключу учетной записи, из которой был получен стейк. Ставки валидаторов замораживаются до окончания срока, на который они были избраны, а также еще на один месяц на случай возникновения новых споров (т.е. обнаружения невалидного блока, подписанного одним из этих валидаторов). После этого стейк возвращается вместе с долей валидатора в монетах и комиссиями от транзакций, обработанных за это время.
Выбор «групп задач» валидаторов
Весь глобальный набор валидаторов (где каждый валидатор считается присутствующим с множественностью, равной его стейку — в противном случае у валидатора может возникнуть соблазн использовать несколько идентификаторов и разделить свой стейк между ними) используется только для проверки новых блоков мастерчейна. Блоки шардчейна проверяются только специально выбранными подмножествами валидаторов из глобального набора валидаторов.
Имеет смысл генерировать и использовать новую пару ключей при каждом подборе валидаторов. Эти «подмножества» или «группы задач» валидаторов, определенные для каждого шарда, меняются каждый час (фактически, каждые 210 блоков мастерчейна), причем они становятся известны за час вперед, так что каждый валидатор знает, какие шарды ему необходимо будет проверить, и может подготовиться к этому (например, загрузив недостающие данные шардчейна).
Для выбора групп задач валидаторов для каждого шарда (w, s) применяется детерминированный псевдослучайный алгоритм. Он использует псевдослучайные числа, встроенные валидаторами в каждый блок мастерчейна (сгенерированные путем получения консенсуса с использованием пороговых сигнатур) для создания случайного начального числа, а затем вычисляет, например, Hash(code(w): code(s):validator_id:rand_seed) для каждого валидатора. Затем валидаторы сортируются по значению этого хэша, и выбираются первые несколько валидаторов, имеющих не менее 20/T от общих стеков валидаторов (группа состоит как минимум из 5 валидаторов).
Этот выбор может быть сделан с помощью специального смарт-контракта. В этом случае алгоритм выбора можно было бы легко обновить без хард-форков с помощью механизма голосования. Все другие упомянутые до сих пор «константы» (такие как 219, 210, T, 20 и 5) также являются настраиваемыми параметрами.
Смена приоритета в каждой группе задач
Для членов группы задач шарда вводится определенный «приоритетный» порядок, зависящий от хэша предыдущего блока мастерчейна и порядкового номера блока (шардчейна). Этот порядок определяется путем генерации и сортировки хэшей, как описано выше.
Когда необходимо сгенерировать новый блок шардчейна, валидатор группы задач шарда, выбранный для создания этого блока, обычно является первым в отношении этого чередующегося «приоритетного» порядка. Если создать блок не удается, это может сделать второй или третий валидатор. По сути, все они могут предлагать своих блоки-кандидаты, однако кандидат, предложенный валидатором с наивысшим приоритетом, должен победить в результате применения протокола консенсуса (задача византийских генералов, BFT).
Распространение блоков-кандидатов шардчейна
Поскольку членство в группе задач шардчейна известно за час вперед, их участники могут использовать это время для создания выделенной «многоадресной оверлейной сети для валидаторов шардчейна», используя общие механизмы сети TON. Когда необходимо сгенерировать новый блок шардчейна — обычно через одну или две секунды после создания самого последнего блок мастерчейна – все валидаторы знают, у кого наивысший приоритет для генерации следующего блока. Этот валидатор создает новый блок-кандидат либо сам, либо с помощью коллатора). Валидатор должен проверить (подтвердить) этот блок-кандидат (особенно, если он был подготовлен коллатором) и подписать его своим закрытым ключом (валидатора). Затем блок-кандидат распространяется на оставшуюся часть группы задач с использованием заранее организованной оверлейной сети многоадресной рассылки (группа задач создает свою собственную частную оверлейную сеть, а затем использует версию протокола многоадресной потоковой передачи, для распространения блоков-кандидатов).
Наиболее правильный метод – это использование BFT протокола многоадресной рассылки, такого, который используется в Honey Badger BFT [11]: закодировать блока-кандидата с помощью кода стирания (N, 2N/3), отправить 1/N полученных данных непосредственно каждому члену группы и ожидать, что они будут передавать свою часть данных в рамках многоадресной рассылки напрямую всем другим членам группы.
Однако более быстрый и простой способ сделать это заключается в том, чтобы разбить блок-кандидат на последовательность подписанных однокилобайтных блоков («фрагментов»), дополнить их последовательность с помощью кода Рида-Соломона или исходного кода (такой как RaptorQ) и начать передачу фрагментов соседним узлам в «сетке многоадресной рассылки» (т. е. оверлейной сети), ожидая, что они будут распространять эти фрагменты дальше. Как только валидатор получает достаточно фрагментов для восстановления на их основе блока-кандидата, он подписывает валидацию и распространяет ее по всем соседям в своей группе. Затем соседи валидатора перестают посылать ему новые фрагменты, но могут продолжать отправлять (исходные) подписи этих фрагментов, полагая, что этот узел может генерировать последующие фрагменты, применяя код Рида-Соломона или фонтанный код (имея все необходимые данные), объединить их с подписями и передать их соседним узлам, которые еще не закончили процесс валидации.
Если «многоадресная сетка» (оверлейная сеть) остается подключенной после удаления всех «плохих» узлов (напомним, что до одной трети узлов могут вести себя злонамеренно), этот алгоритм распространяет блок-кандидат как можно быстрее.
Не только назначенный создатель высокоприоритетного блока может выполнять многоадресную рассылку своего блока-кандидата на всю группу. Валидаторы со вторым и третьим приоритетом могут начать многоадресную рассылку своих блоков-кандидатов либо сразу, либо после того, как не получили блок-кандидат от валидатора с наивысшим приоритетом. Однако обычно только блок-кандидат с максимальным приоритетом будет подписан всеми валидаторами (фактически как минимум двумя третями группы задач) и зафиксирован как новый блок шардчейна.
Проверка блоков-кандидато
Сразу после получения блока-кандидата валидатором и проверки его исходной подписи принимающий валидатор проверяет валидность этого блока-кандидата, выполняя все транзакции и контролируя, чтобы их результат совпадал с заявленным результатом. Все сообщения, импортированные из других блокчейнов, должны поддерживаться подходящими доказательствами Меркла в сопоставленных данных, в противном случае блок-кандидат считается невалидным (и, если соответствующее доказательство было передано в мастерчейн, уже подписавшие этот блок-кандидат валидаторы могут быть наказаны). С другой стороны, если блок-кандидат признан валидным, принимающий валидатор подписывает его и распространяет свою подпись другим валидаторам в группе либо через «ячеистую многоадресную сеть», либо посредством прямых сетевых сообщений.
Следует подчеркнуть, что валидатору не нужен доступ к состояниям текущего или соседних шардчейнов для проверки валидности (сопоставленного) блока-кандидата. Это позволяет проводить валидацию очень быстро (без доступа к диску) и снижает вычислительную нагрузку и нагрузку на хранилище для валидаторов (особенно если они готовы принять услуги внешних коллаторов для создания блоков-кандидатов).
Отбор следующего блока кандидата
Как только блок-кандидат собирает не менее двух третей (по стейкам) подписей валидаторов в группе задач, он может быть зафиксирован в качестве следующего блока шардчейна. 21 Возможным исключением является состояние выходных очередей соседних шардчейнов, необходимое для обеспечения требований к порядку сообщений, описанных в 2.4.21, поскольку в этом случае размер доказательств Меркла может стать непомерно высоким.
Протокол BFT используется для достижения консенсуса по выбранному блоку-кандидату (может быть предложено несколько блоков), при этом все «хорошие» валидаторы предпочитают блок-кандидат с наивысшим приоритетом для этого раунда. В результате использования этого протокола блок дополняется подписями не менее двух третей валидаторов (по стекам). Эти подписи свидетельствуют не только о валидности рассматриваемого блока, но и о его отборе в соответствии с протоколом BFT. После этого блок (без сопоставленных данных) объединяется с этими подписями, сериализуется детерминированным способом и передается по сети всем заинтересованным сторонам.
Валидаторы должны сохранять подписанные ими блоки
Ожидается, что во время своего членства в группе задач и в течение как минимум одного часа (или, скорее, 210 блоков) после этого валидаторы будут сохранять блоки, которые они подписали и зафиксировали. Непредставление подписанного блока другим валидаторам может повлечь за собой штрафные санкции.
Передача заголовков и подписей новых блоков шардчейна всем валидаторам. Валидаторы передают заголовки и подписи вновь созданных блоков шардчейна глобальному набору валидаторов, используя многоадресную ячеистую сеть, аналогичную той, которая создается для каждой группы задач.
Генерация новых блоков мастерчейна
После того, как все (или почти все) новые блоков шардчейна были сгенерированы, может быть сгенерирован новый блоков мастерчейна. Процедура, по существу, такая же, как и для блоков шардчейна, с той лишь разницей, что все валидаторы (или как минимум две трети из них) должны участвовать в этом процессе. Поскольку заголовки и подписи новых блоков шардчейна передаются всем валидаторам, хэши самых новых блоков в каждом шардчейне могут и должны быть включены в новый блок мастерчейна. После того, как эти хэши будут зафиксированы в блоке мастерчейна, внешние наблюдатели и другие шардчейны могут считать новые блоки шардчейна зафиксированными и неизменными.
Валидаторы должны сохранять состояние мастерчейна. Заслуживающая внимания разница между мастерчейном и шардчейном заключается в том, что все валидаторы должны отслеживать состояние мастерчейна, не полагаясь на сопоставленные данные. Это важно, потому что информация, получаемая группой задач валидаторов, основана на состоянии мастерчейна.
Блоки шардчейна генерируются и распространяются параллельно. Обычно каждый валидатор является членом нескольких групп задач шардчейна; их количество (и, следовательно, нагрузка на валидатора) примерно пропорционально стейку валидатора. Это означает, что валидатор параллельно запускает несколько экземпляров нового протокола генерации блоков шардчейна.
Предупреждение атак с удержанием блоков
Поскольку полный набор валидаторов вставляет хэш нового блока шардчейна в мастерчейн после просмотра только его заголовка и подписей, существует небольшая вероятность того, что валидаторы, которые сгенерировали этот блок, вступят в сговор и попытаются избежать публикации нового блока целиком. Это приведет к неспособности валидаторов соседних шардчейнов создавать новые блоки, потому что они должны знать как минимум очередь выходных сообщений нового блока после того, как его хэш будет зафиксирован в мастерчейне.
Чтобы предупредить эту проблему, новый блок должен собирать подписи от некоторых других валидаторов (например, двух третей объединения групп задач соседних шардчейнов), свидетельствующих о том, что эти валидаторы действительно имеют копии этого блока и готовы отправить их любым другим валидаторам при необходимости. Только после предоставления этих подписей хэш нового блока может быть включен в мастерчейн.
Блоки мастерчейна генерируются позже, чем блоки шардчейна
Блоки мастерчейна генерируются примерно раз в пять секунд, как и блоки шардчейна. Однако в то время как генерация новых блоков во всех шардчейнах выполняется по существу одновременно (обычно этот процесс запускается после выпуска нового блока мастерчейна), генерация новых блоков мастерчейна намеренно задерживается, чтобы обеспечить включение хэшей вновь сгенерированных блоков шардчейна в мастерчейне.
Более медленные валидаторы могут получать меньшее вознаграждение. Если валидатор работает «медленно», он может не успевать проверить новые блоки-кандидаты, и две трети подписей, необходимых для фиксации нового блока, могут быть собраны без его участия. В этом случае он получит меньшую долю вознаграждения, связанного с этим блоком.
Это дает валидаторам стимул оптимизировать свое оборудование, программное обеспечение и сетевое соединение, чтобы обрабатывать транзакции пользователей как можно быстрее.
Однако если валидатору не удается подписать блок до его фиксации, его подпись может быть включена в один из следующих блоков, а затем часть вознаграждения (экспоненциально уменьшается в зависимости от того, сколько блоков было сгенерировано с тех пор — например, 0.9k, если валидатор опаздывает на k блоков) будет по-прежнему передана этому валидатору.
«Глубина» подписей валидатора
Обычно, когда валидатор подписывает блок, подпись свидетельствует только об относительной валидности блока: этот блок действителен при условии, что действительны все предыдущие блоки в этом и других сегментах. Валидатор не может быть наказан за то, что принял недействительные данные, переданные в предыдущие блоки.
Однако подпись валидатора блока имеет целочисленный параметр, называемый «глубиной». Если он не равен нулю, это означает, что валидатор также подтверждает (относительную) валидность указанного количества предыдущих блоков. Этот способ позволяет «медленным» или «временно отключенным» валидаторам догнать процесс и подписать некоторые из блоков, которые были зафиксированы без их подписей. Тогда валидаторам все равно будет передана некоторая часть награды за блок.
Валидаторы несут ответственность за относительную валидность подписанных блоков шардчейна
После этого следует абсолютная валидность. Мы хотели бы еще раз подчеркнуть, что подпись валидатора на блоке шардчейна B свидетельствует только об относительной валидности этого блока (или также d предыдущих блоков, если подпись имеет «глубину» d; но это не сильно влияет на последующее обсуждение). Другими словами, валидатор утверждает, что следующее состояние s’ шардчейна выводится из предыдущего состояния s путем применения функции оценки блока ev_block.
Таким образом, валидатор, подписавший блок B, не может быть наказан, если исходное состояние s оказывается «некорректным» (например, из-за невалидности одного из предыдущих блоков). Фишермен может указать на ошибку, только если он находит относительно невалидный блок. Система PoS в целом стремится сделать каждый блок относительно валидным, а не рекурсивно (или абсолютно) валидным. Однако следует обратить внимание, что если все блоки в блокчейне являются относительно валидными, то все они и блокчейн в целом являются абсолютно валидными; это утверждение легко проиллюстрировать с
помощью математической индукции по длине блокчейна. Таким образом, легко проверяемые утверждения об относительной валидности блоков вместе демонстрируют гораздо большую абсолютную валидность всего блокчейна.
Обратите внимание: подписывая блок B, валидатор утверждает, что блок является валидным в исходном состоянии s (т. е. результат не является значением ?, указывающим, что следующее состояние не может быть вычислено). Таким образом, валидатор должен выполнять минимальные формальные проверки ячеек исходного состояния, к которым осуществляется доступ во время оценки.
Например, представим, что ячейка, которая, как ожидается, будет содержать исходный баланс учетной записи, к которой осуществляется доступ из зафиксированной в блоке транзакции, имеет нулевые необработанные байты вместо ожидаемых 8 или 16 байтов. Тогда исходный баланс просто не может быть получен из ячейки, и при попытке обработать блок происходит «необработанное исключение». В этом случае валидатор не должен подписывать такой блок под угрозой наказания.
Подписание блоков мастерчейна
Ситуация с блоками мастерчейна несколько иная: подписывая блок мастерчейна, валидатор подтверждает не только его относительную валидность, но и относительную валидность всех предшествующих блоков до самого первого блока, с которого этот валидатор начал проверять блоки (но не дальше).
Общее количество валидаторов
Верхний лимит T для общего числа валидаторов, которых можно выбрать, не может быть в описанной системе больше чем, скажем, несколько сотен или тысяча, потому что все валидаторы должны принимать участие в протоколе консенсуса BFT для создания каждого нового блока мастерчейна, и неясно, могут ли такие протоколы масштабироваться до тысяч участников. Ещё более важно, что блоки мастерчейна должны собирать подписи как минимум двух третей валидаторов (по стейку), и эти подписи должны быть включены в новый блок (иначе все другие ноды в системе не будут иметь причины доверять новому блоку до собственноручной его валидации). Если, скажем, одна тысяча подписей валидаторов будет включаться в каждый блок мастерчейна, это будет подразумевать больше информации в каждом блоке мастерчейна, которую нужно хранить всем полным нодам и распространять через сеть, и больше вычислительной мощности будет тратиться на проверку этих подписей (в PoS-системе полные ноды не должны валидировать блоки сами по себе, но должны проверять подписи валидаторов вместо этого).
Хотя ограничение T до тысячи валидаторов выглядит более эффективным для первой фазы развертывания блокчейна TON, должен быть запас для будущего роста, когда общее число шардчейнов станет настолько большим, что нескольких сотен валидаторов не будет достаточно для обработки их всех. С этой целью мы представляем дополнительный конфигурируемый параметр T′ ≤ T (изначально равный T), и только верхние T′ выбранных валидаторов (по стейку) будут создавать и подписывать новые блоки мастерчейна.
Децентрализация системы
Можно заподозрить, что Proof-of-Stake система, такая как блокчейн TON, полагающаяся на T≈1000 валидаторов для создания всех блоков шардчейнов и мастерчейна, обязательно станет «слишком централизованной», в противовес общепринятым Proof-of-Work блокчейнам, таким как Биткоин или Эфириум, где все (в принципе) могут майнить новые блоки, без явно выраженного верхнего лимита на число майнеров.
Однако популярные Proof-of-Work блокчейны, такие как Биткоин и Эфириум, на текущий момент требуют огромного количества вычислительной мощности (высокие «хэш-рейты») для майнинга новых блоков с приемлемой вероятностью успеха. Таким образом, майнинг новых блоков имеет тенденцию концентрироваться в руках нескольких крупных игроков: одни инвестируют большие деньги в датацентры и специальное программное обеспечение, оптимизированное для майнинга, другие же концентрируют и координируют усилия больших групп людей, неспособных самостоятельно предоставить достаточный «хэш-рейт», тем самым образуя крупные майнинг-пулы.
Таким образом, по состоянию на 2017 год больше чем 75% новых блоков Эфириума и Биткоина создаются менее чем десятью майнерами. Фактически, два крупнейших майнинг-пула Эфириума производят вместе больше половины всех новых блоков! Очевидно, такая система намного более централизована чем та, которая полагается на T≈1000 нод для производства новых блоков.
Также следует отметить, что вложения, необходимые для того, чтобы стать валидатором блокчейна TON — то есть, для приобретения оборудования (скажем, несколько высокопроизводительных серверов) и стейка (который при необходимости может быть легко собран через пул номинаторов) — намного меньше, чем требуемые для успешного самостоятельного майнинга Биткоина или Эфириума. По сути, параметр L будет заставлять номинаторов не присоединяться к крупнейшему «майнинг-пулу» (то есть, к валидатору, который собрал крупнейший стейк), но, скорее, искать меньших валидаторов, на данный момент собирающих средства от номинаторов, или даже создавать новых валидаторов, потому что это обеспечит более высокую пропорцию s′i/si стейка валидатора — и как следствие номинатора, откуда следует более высокая награда за майнинг. Таким образом, Proof-of-Stake система TON на самом деле поощряет децентрализацию (создание и использование большего числа валидаторов) и наказывает централизацию.
Относительная надежность блока
(Относительная) надежность блока — это просто сумма стейков всех валидаторов, подписавших данный блок. Другими словами, это сумма денег, которую некоторые акторы потеряют, если этот блок окажется невалидным. Если передаваемая транзакциями стоимость ниже уровня надежности блока, их можно считать достаточно безопасными. В этом смысле относительная надежность — это мера доверия внешнего наблюдателя по отношению к определенному блоку.
Обратите внимание, что показатель относительной надежности блока является гарантией валидности блока, при условии, что предыдущий блок и все упомянутые блоки других шардчейнов являются валидными.
Относительная надежность блока может возрастать после его фиксации — например, при добавлении подписей «медленных» валидаторов. С другой стороны, если один из этих валидаторов теряет часть или весь свой стейк из-за его некорректности, связанной с некоторыми другими блоками, относительная надежность блока может снизиться.
«Усиление» блокчейна
Важно создать стимулы для валидаторов, чтобы максимально повысить относительную надежность блоков. Один из способов сделать — это выделить небольшое вознаграждение валидаторам за добавление подписей к блокам других шардчейнов. Даже «потенциальные» валидаторы, которые внесли сумму, недостаточную для того, чтобы попасть в ТОП T валидаторов по размеру стейка и быть включенными в глобальный набор валидаторов , могут участвовать в этой деятельности (если они согласны оставить свой стейк вместо того, чтобы снимать его после неудачных результатов отбора). Такие потенциальные валидаторы могут выступать в роли фишерменов: если им все равно нужно проверять валидность определенных блоков, они могут также сообщать о невалидных блоках и получать связанные с ними вознаграждения.
Рекурсивная надежность блока
Рекурсивную надежность блока можно определить как минимум его относительной надежности и рекурсивной надежности всех блоков, на которые он ссылается (т. е. блок мастерчейна, предыдущего блока шардчейна и некоторых блоков соседних шардчейнов).
Другими словами, если блок окажется невалидным сам по себе, либо потому, что недействителен один из блоков, от которых он зависит, то кем-то будет потеряна как минимум эта сумма денег. Если пользователь действительно не уверен, следует ли доверять конкретной транзакции в блоке, следует вычислить рекурсивную надежность этого блока, а не только относительную.
Нет смысла возвращаться слишком далеко назад при вычислении рекурсивной надежности – в этом случае мы увидим блоки, подписанные валидаторами, чьи ставки уже были разморожены и сняты. Как бы то ни было, мы не позволяем валидаторам автоматически пересматривать слишком старые блоки (т. е. блоки, созданные более двух месяцев назад, если используются текущие значения настраиваемых параметров) и создавать на их основании форки, либо исправлять их с помощью «вертикальных блокчейнов», даже если они окажутся невалидными. Мы предполагаем, что два месяца – это достаточный период для того, чтобы обнаружить невалидные блоки и сообщить о них, поэтому, если валидность блока не будет оспариваться в течение этого периода, она вряд ли будет оспариваться когда-либо.
Последствия подхода Proof-of-Stake для неполных нод
Важным следствием подхода Proof-of-Stake, используемого в блокчейне TON, является то, что неполной ноде (запускающей «облегченное» клиентское программное обеспечение) блокчейна TON не нужно загружать «заголовки» всех шардчейнов или даже блоков мастерчейна, чтобы иметь возможность самостоятельно проверить достоверность доказательств Меркла, предоставленных неполной ноде полными нодами в качестве ответов на ее запросы.
В самом деле, поскольку самые последние хэши блоков шардчейна включены в блоки мастерчейна, полная нода может легко предоставить доказательство Меркла, что данный блок шардчейна является валидным, начиная с известного хэша блока мастерчейна. Кроме того, неполная нода должна «знать» только самый первый блок мастерчейна (где объявляется самый первый набор валидаторов), который (или, по крайней мере, хэш которого) может быть встроен в клиентское программное обеспечение, и только один блок мастерчейна примерно каждый месяц после этого, когда объявляются новые наборы валидаторов, потому что этот блок будет подписан предыдущим набором валидаторов. Начиная с этого момента, нода может получить несколько самых последних блоков мастерчейна, либо как минимум их заголовки и подписи валидаторов, и использовать их в качестве основы для проверки доказательств Меркла, предоставленных полными нодами.
