Что такое Блокчейн TON где купить

Создание и проверка новых блоков
Блокчейн TON в конечном счете состоит из блоков shardchain и masterchain.
Эти блоки должны быть созданы, проверены и распространены по
сети всем заинтересованным сторонам, чтобы система функционировала
бесперебойно и правильно. Блокчейн TON где купить
2.6.1. Валидаторы. Новые блоки создаются и проверяются специальными назначенными узлами, называемыми валидаторами. По сути, любой узел, желающий стать
валидатором, может им стать, при условии, что он может внести достаточно большую долю
(в тонных монетах, т.е. тонных монетах; см. Приложение А) в мастер-цепочку. Валидаторы получают некоторые награды за хорошую работу, а именно плату за транзакции, хранение
и газ со всех транзакций (сообщений), совершенных во вновь сгенерированных блоках, и некоторые недавно отчеканенные монеты, отражающие благодарность
всего сообщества валидаторам за поддержание работы блокчейна TON. Купить на EXMO
Этот доход распределяется между всеми участвующими валидаторами пропорционально
их ставкам.
Однако быть валидатором - это большая ответственность. Если валидатор подписывает
недействительный блок, он может быть наказан потерей части или всей своей доли, а также
временным или постоянным исключением из набора валидаторов. Если
валидатор не участвует в создании блока, он не получает свою
долю вознаграждения, связанного с этим блоком. Если валидатор воздерживается от
создания новых блоков в течение длительного времени, он может потерять часть своей доли и быть
приостановлен или навсегда исключен из набора валидаторов.
Все это означает , что валидатор не получает свои деньги даром .
Действительно, он должен отслеживать состояния всех или некоторых цепочек осколков (каждая
валидатор отвечает за проверку и создание новых блоков в определенном
подмножестве цепочек сегментов), выполняет все вычисления, запрошенные smart con44
2.6. Создание и проверка новых
участков блоков в этих цепочках сегментов, получение обновлений о других цепочках сегментов и так
далее. Эта деятельность требует значительного дискового пространства, вычислительной мощности и
пропускной способности сети.
2.6.2. Валидаторы вместо майнеров. Напомним, что блокчейн TON использует подход
, основанный на доказательстве ставки, вместо подхода, основанного на доказательстве работы, принятого
Биткоином, текущей версией Ethereum и большинством других криптовалют.
Это означает, что нельзя добыть новый блок, представив некоторые доказательства работы (вычисляя множество бесполезных в противном случае хэшей) и
в результате получить несколько новых монет. Вместо этого нужно стать валидатором и тратить свои вычислительные
ресурсы на хранение и обработку запросов и данных блокчейна TON. Короче
говоря, чтобы добывать новые монеты, нужно быть валидатором. В этом отношении валидаторы являются
новыми майнерами.


Однако есть и другие способы заработать монеты, помимо того, чтобы быть
валидатором.
2.6.3. Номинанты и майнинг-пулы. Чтобы стать валидатором, один
обычно требуется купить и установить несколько высокопроизводительных серверов и
обеспечить для них хорошее подключение к Интернету. Это не так дорого, как оборудование
ASIC, необходимое в настоящее время для майнинга биткоинов. Однако никто определенно не
может добывать монеты новой ТОННЫ на домашнем компьютере, не говоря уже о смартфоне.
В сообществах майнинга биткойнов, Эфириумов и других проверенных на работоспособность криптовалют
существует понятие майнинговых пулов, где множество узлов, обладающих
достаточной вычислительной мощностью для самостоятельного майнинга новых блоков, объединяют
свои усилия и впоследствии делятся вознаграждением.
Соответствующее понятие в мире доказательств ставки - это понятие номинанта.
По сути, это узел, предоставляющий свои деньги, чтобы помочь валидатору увеличить свою
долю; затем валидатор распределяет соответствующую долю своего вознаграждения
(или некоторую ранее согласованную часть, скажем, 50%) номинатору.
Таким образом, номинатор также может принять участие в майнинге и получить
некоторое вознаграждение, пропорциональное сумме денег, которую он готов внести для
этой цели. Он получает лишь часть соответствующей доли
вознаграждение валидатора, потому что оно обеспечивает только капитал, но не требует
покупки вычислительной мощности, хранилища и пропускной способности сети.
Однако, если валидатор теряет свою долю из-за недопустимого поведения,
номинатор также теряет свою долю доли. В этом смысле номинатор
разделяет риск. Он должен разумно выбирать назначенного валидатора, иначе он
может потерять деньги. В этом смысле кандидаты принимают взвешенное решение и
голосуют за определенных валидаторов своими средствами.
45
2.6. Создание и проверка новых блоков
С другой стороны, эта система номинирования или кредитования позволяет
стать валидатором, не вкладывая сначала большую сумму денег в
монеты TON. Другими словами, это мешает тем, кто хранит большое количество тонных
монет, монополизировать поставку валидаторов.
2.6.4. Рыбаки: получение денег, указывая на ошибки других. Еще один способ получить некоторые награды, не будучи валидатором, - это
стать шерманом. По сути, любой узел может стать шерманом,
внесение небольшого депозита в мастер-цепочку. Затем он может использовать специальные транзакции мастер-цепочки для публикации (Merkle) доказательств недействительности некоторых (обычно цепочек
сегментов) блоков, ранее подписанных и опубликованных валидаторами. Если другие
валидаторы согласны с этим доказательством недействительности, валидаторы с окончанием o наказываются (теряя часть своей ставки), а шерман получает некоторое вознаграждение
(часть монет, полученных от валидаторов с окончанием o). Впоследствии,
недопустимый блок (цепочка сегментов) должен быть исправлен, как описано в 2.1.17. Исправление недопустимых блоков мастер-цепочки может включать создание вертикальных блоков
поверх ранее зафиксированных блоков мастер-цепочки (см. 2.1.17); нет необходимости
создавать вилку мастер-цепочки.
Обычно шерману нужно было бы стать полноценным узлом, по крайней мере, для некоторых цепочек
сегментов, и потратить некоторые вычислительные ресурсы, запустив код,
по крайней мере, некоторых смарт-контрактов. Хотя шерману не нужно обладать такой
вычислительной мощностью, как валидатор, мы считаем, что естественный кандидат
стать шерманом - это потенциальный валидатор, который готов обрабатывать новые
блоки, но еще не был избран в качестве валидатора (например, из-за неспособности
внести достаточно большую долю).
2.6.5. Коллекторы: получение денег путем предложения новых блоков валидаторам. Еще один способ получить некоторые награды, не будучи валидатором, -
это стать коллектором. Это узел, который готовит и предлагает
проверяющему новые кандидаты на блок цепочки сегментов, дополненные (сопоставленные) с
данные, взятые из состояния этой цепочки осколков и из других (обычно соседних) цепочек осколков, вместе с подходящими доказательствами Меркла. (Это необходимо,
например, когда необходимо перенаправить некоторые сообщения из соседних цепочек
сегментов.) Затем валидатор может легко проверить предложенного кандидата на блок на действительность, без необходимости загружать полное состояние этой или
других цепочек осколков.
Поскольку валидатору необходимо представить новых (сопоставленных) кандидатов на блок
для получения некоторых (майнинговых) вознаграждений, имеет смысл заплатить некоторую часть
вознаграждение сборщику, готовому предоставить подходящих кандидатов на блок. Таким образом

Создание и проверка новых блоков
валидатор может освободить себя от необходимости следить за состоянием
соседних цепочек сегментов, передав их на аутсорсинг сборщику.
Однако мы ожидаем, что на начальном этапе развертывания системы
не будет отдельных назначенных коллаторов, поскольку все валидаторы
смогут выступать в качестве коллаторов для самих себя.
2.6.6. Сборщики или валидаторы: получение денег за включение
транзакций пользователя. Пользователи могут открывать каналы микроплатежей некоторым коллекторам или
валидаторам и платить небольшие суммы монет в обмен на включение
их транзакции в цепочке осколков.
2.6.7. Выборы глобального валидатора. Глобальный набор валидаторов
избирается один раз в месяц (фактически каждые 2
19 блоков мастерчейна). Этот набор
определяется и общеизвестен за месяц вперед.


Чтобы стать валидатором, узел должен перевести несколько монет TON
в мастер-цепочку, а затем отправить их в специальный смарт-контракт в качестве
предлагаемой ставки. Другим параметром, отправляемым вместе со ставкой, является l ≥ 1,
максимальная допустимая нагрузка, которую этот узел готов принять относительно
минимально возможное. Существует также глобальная верхняя граница (еще один настраиваемый
параметр) L на l, равное, скажем, 10.
Затем глобальный набор валидаторов выбирается этим смарт-контрактом, просто
выбирая до T кандидатов с максимальными предлагаемыми ставками и публикуя
их личности. Первоначально общее число валидаторов равно T = 100; мы
ожидаем, что оно вырастет до 1000 по мере увеличения нагрузки. Это контролируемый параметр
(см. 2.1.21).
Фактическая ставка каждого валидатора рассчитывается следующим образом: Если верхние T
предлагаемых ставок составляют s1 ≥ s2 ≥ · · · ≥ sT , фактическая ставка i-го валидатора равна
установите значение s
0
i
:= мин(si
, li
· sT ). Таким образом, s
0
i
/s0
T ≤ li
, поэтому i-й валидатор
не получает больше, чем li ≤ L, умноженное на нагрузку самого слабого валидатора (потому что
нагрузка в конечном счете пропорциональна ставке).
Затем избранные валидаторы могут отозвать неиспользованную часть своей доли,
si−s
0
i
. Неудачные кандидаты в валидаторы могут отозвать всю предложенную ими
долю.
Каждый валидатор публикует свой открытый ключ подписи, не обязательно равный
открытому ключу учетной записи, с которой была сделана ставка.20
Ставки валидаторов заморожены до конца периода для
которые они были избраны, и еще один месяц, в случае новых споров
20 Имеет смысл генерировать и использовать новую пару ключей для каждого выбора валидатора.
47
2.6. Возникают создание и проверка новых блоков
(т.е. обнаруживается недопустимый блок, подписанный одним из этих валидаторов). После
этого ставка возвращается вместе с долей валидатора в отчеканенных монетах
и сборами за транзакции, обработанные в течение этого времени.
2.6.8. Выборы рабочих групп валидаторов. Весь глобальный набор валидаторов (где каждый валидатор считается присутствующим с кратностью, равной
его доля в противном случае у валидатора может возникнуть соблазн присвоить себе несколько удостоверений личности и разделить свою долю между ними) используется только для проверки новых
блоков мастерчейна. Блоки цепочки сегментов проверяются только специально выбранными подмножествами валидаторов, взятыми из глобального набора валидаторов, выбранных, как описано
в 2.6.7.
Эти подмножества валидаторов или группы задач, определенные для каждого сегмента,
меняются каждый час (фактически каждые 2
10 блоков мастер-цепи), и они
известны за час до этого, так что каждый валидатор знает, какие его осколки
потребуется подтвердить, и вы можете подготовиться к этому (например, загрузив недостающие
данные цепочки сегментов).
Алгоритм, используемый для выбора групп задач валидатора для каждого сегмента (w, s),
является детерминированным псевдослучайным. Он использует псевдослучайные числа, встроенные
валидаторами в каждый блок мастер-цепочки (генерируемые консенсусом с использованием
пороговых подписей), для создания случайного начального значения, а затем вычисляет, например, хэш (код (w). код (ы).validator_id.rand_seed) для каждого валидатора.
Затем валидаторы сортируются по значению этого хэша, и первые несколько
выбирается таким образом, чтобы иметь не менее 20/Т от общего количества ставок валидатора и состоять не
менее чем из 5 валидаторов.
Этот выбор может быть сделан с помощью специального смарт-контракта. В этом случае алгоритм
выбора можно было бы легко обновить без жестких форков с помощью механизма
голосования, упомянутого в 2.1.21. Все остальные константы, упомянутые до сих
пор (например, 2
19
, 2
10
, T, 20 и 5) также являются контролируемыми параметрами.
2.6.9. Чередование приоритетов в каждой целевой группе. Существует определенный порядок
приоритетов, налагаемый на членов целевой группы по сегментам, в зависимости от
хэш предыдущего блока мастер-цепочки и порядковый номер блока (цепочки фрагментов)
. Этот порядок определяется путем генерации и сортировки некоторых хэшей, как
описано выше.
Когда необходимо сгенерировать новый блок цепочки сегментов
, валидатор группы задач сегментов, выбранный для создания этого блока, обычно является первым в
этом порядке чередования приоритетов. Если ему не удастся создать блок,
это может сделать второй или третий валидатор. По сути, все они могут предлагать своих кандидатов на блокировку
, но кандидат, предложенный валидатором, имеет наивысший
48
2.6. Приоритет создания и проверки новых блоков
должен быть получен в результате применения протокола консенсуса Византийской отказоустойчивости (BFT)
.
2.6.10. Распространение кандидатов в блоки цепочки осколков. Поскольку членство в целевой группе цепочки сегментов известно за час до этого, их участники
могут использовать это время для создания выделенной сети многоадресной наложения валидаторов сегментов, используя общие механизмы сети TON (см. 3.3). Когда
новый блок цепочки сегментов должен быть сгенерирован обычно через одну или две секунды
после распространения последнего блока мастер-цепочки, все
знает, у кого наивысший приоритет для создания следующего блока (см. 2.6.9).
Этот валидатор создаст нового кандидата на сопоставленный блок, либо самостоятельно, либо
с помощью средства сортировки (см. 2.6.5). Валидатор должен проверить (подтвердить) этого кандидата
на блок (особенно, если он был подготовлен каким-либо проверяющим) и подписать
его своим (валидатором) закрытым ключом. Затем кандидат на блок распространяется
на оставшуюся часть целевой группы, используя заранее подготовленную многоадресную оверлейную
сеть (целевая группа создает свою собственную частную оверлейную сеть, как объяснено
в 3.3, а затем использует версию протокола многоадресной потоковой передачи, описанную
в 3.3.15, для распространения кандидатов на блокировку).
Действительно БФТ способ сделать это было бы использование византийских многоадресной рассылки
протокол, такой как используется в медоед БФТ [11]: кодировать блок
кандидата (П, 2П/3)-стирание кодов, отправьте 1/Н полученных данных
непосредственно каждому члену группы, и ожидать от них многоадресной напрямую
их часть данных, чтобы все остальные члены группы.
Однако более быстрый и простой способ сделать это (см. также
3.3.15) разделить кандидата от Блока в последовательность подписан на один килобайт
блоки ( chunks ), дополнить их последовательности Рида-Соломона или фонтан
код (например, код RaptorQ [9] [14]), и начать передачу блоков с
соседи в многоадресной сетки (т. е. оверлейная сеть), ожидая от них
для дальнейшего распространения этих фрагментов. Как только валидатор получает достаточное количество блоков,
чтобы восстановить из них кандидата на блок, он подписывает квитанцию подтверждения
и распространяет ее через своих соседей по всей группе. Затем
его соседи перестают отправлять ему новые фрагменты, но могут продолжать отправлять
(исходные) подписи этих фрагментов, полагая, что этот узел может генерировать
последующие фрагменты, применяя код Рида Соломона или фонтана самостоятельно
(имея все необходимые данные), объединять их с подписями и распространять среди
своих соседей, которые еще не готовы

Подписание блоков мастерчейна. Ситуация с
блоками мастер-цепочки несколько иная: подписывая блок мастер-цепочки, валидатор подтверждает не только его относительную действительность, но и относительную действительность всех
предыдущих блоков вплоть до самого первого блока, когда этот валидатор взял на себя
ответственность (но не далее).
2.6.24. Общее количество валидаторов. Верхний предел T для общего
числа валидаторов, подлежащих избранию (см. 2.6.7), не может быть
больше, чем, скажем, несколько сотен или тысяч, в описанной до сих пор системе, потому что все
ожидается, что валидаторы будут участвовать в консенсусном протоколе BFT для создания каждого нового блока мастер-цепочки, и неясно, могут ли такие протоколы
масштабироваться до тысяч участников. Что еще более важно,
блоки masterchain должны собирать подписи не менее двух третей всех валидаторов
(по ставке), и эти подписи должны быть включены в новый блок (в противном случае у всех остальных узлов в системе не было бы оснований доверять новому
блоку, не проверив его самостоятельно). Если больше, скажем, одной тысячи
подписи проверяющего должны быть включены в каждый блок masterchain,
это будет означать больше данных в каждый masterchain блока, должны быть сохранены все
полные узлы и распространяются через сеть, и больше вычислительной мощности
провел на проверку этих подписей (в системе POS, полные узлы не нужно
проверка блоки сами по себе, но они нуждаются для проверки вместо подписей валидаторов).
Хотя ограничение T до тысячи валидаторов кажется более чем достаточным для
первого этапа развертывания блокчейна TON, необходимо предусмотреть
быть сделано для будущего роста, когда общее количество цепочек осколков станет
настолько большим, что несколько сотен валидаторов не смогут обработать
их все. С этой целью мы вводим дополнительный настраиваемый параметр T
0 ≤ T
(первоначально равно T), и только верхняя T
Ожидается, что 0
избранных валидаторов (по ставкам) создадут
и подпишут новые блоки мастерчейна.
2.6.25. Децентрализация системы. Можно заподозрить, что система проверки ставок, такая как блокчейн TON, полагающаяся на валидаторы T ≈ 1000
для создания всех блоков цепочки сегментов и мастер-цепочки, неизбежно станет слишком
централизованные, в отличие от обычных блокчейнов, подтверждающих работоспособность, таких как Биткойн или Эфириум, где каждый (в принципе) может добыть новый блок,
54
2.6. Создание и проверка новых блоков
без явного верхнего ограничения на общее количество майнеров.
Однако популярные блокчейны, подтверждающие работоспособность, такие как Биткоин и Эфириум, в настоящее время требуют огромных вычислительных мощностей (высоких скоростей хэширования)
для добычи новых блоков с немалой вероятностью успеха. Таким образом,
добыча новых блоков, как правило, сосредоточена в руках нескольких крупных
игроки, которые вкладывают огромные суммы денег в центры обработки данных, оснащенные специально разработанным оборудованием, оптимизированным для майнинга; и в руках нескольких крупных пулов
майнинга, которые концентрируют и координируют усилия больших групп
людей, которые не в состоянии самостоятельно обеспечить достаточную скорость хэширования.
Таким образом, по состоянию на 2017 год более 75% новых блоков Ethereum или биткойнов
производятся менее чем десятью майнерами. Фактически, два крупнейших
майнинговых пула Ethereum производят вместе более половины всех новых блоков! Очевидно, что
такая система гораздо более централизована, чем система, основанная на T ≈ 1000 узлах
для производства новых блоков.
Можно также отметить, что инвестиции, необходимые для того, чтобы стать ТОННОЙ
Блокчейн-валидатор, т.е. для покупки оборудования (скажем, нескольких высокопроизводительных
серверов) и ставки (которую при необходимости можно легко собрать через пул номинантов; см. 2.6.3) намного ниже, чем требуется, чтобы стать
успешным автономным майнером биткойнов или Эфириума. Фактически, параметр L в 2.6.7 заставит номинантов не присоединяться к крупнейшему пулу майнинга
(т.е. к валидатору, накопившему наибольшую долю), а скорее искать
для небольших валидаторов, которые в настоящее время принимают средства от номинантов, или даже для
создания новых валидаторов, потому что это позволило бы использовать более высокую долю s
0
i
/si от доли
валидатора и, следовательно, также от доли номинанта,
что привело бы к увеличению прибыли от майнинга. Таким образом, система TON Proof-Of-Stake фактически поощряет децентрализацию (создание и использование большего количества
валидаторов) и наказывает централизацию.
2.6.26. Относительная надежность блока. (Относительная) надежность блока -
это просто общая доля всех валидаторов, подписавших этот блок. В других
другими словами, это сумма денег, которую некоторые участники потеряют, если этот блок
окажется недействительным. Если речь идет о транзакциях, стоимость которых ниже, чем надежность блока, можно считать их достаточно безопасными.

В этом смысле относительная надежность является мерой доверия, которое внешний
наблюдатель может иметь к определенному блоку.
Обратите внимание, что мы говорим об относительной надежности блока, потому что это
гарантия того, что блок действителен при условии, что предыдущий блок и все другие
упомянутые блоки цепочек сегментов действительны (см. 2.6.22).55

2.6. Создание и проверка новых блоков
Относительная надежность блока может возрасти после его фиксации,
например, при добавлении подписей запоздалых валидаторов (см. 2.6.21). С
другой стороны, если один из этих валидаторов потеряет часть или всю свою долю из-
за неправильного поведения, связанного с некоторыми другими блоками, относительная надежность
блока может снизиться.
2.6.27. Укрепление блокчейна. Важно обеспечить стимулы для валидаторов, чтобы повысить относительную надежность блоков настолько, насколько
возможный. Один из способов сделать это - выделить небольшое вознаграждение валидаторам
за добавление подписей в блоки других цепочек сегментов. Даже потенциальные валидаторы, которые внесли ставку, достаточную для того, чтобы попасть в топ-Т валидаторов
по ставке и быть включенными в глобальный набор валидаторов (см. 2.6.7), могут
участвовать в этой деятельности (если они согласятся сохранить свою ставку замороженной, а не
отозвать ее после проигрыша на выборах). Такие потенциальные валидаторы
могут выполнять роль рыбаков (см. 2.6.4): если им нужно проверить действительность
в любом случае, некоторые блоки могут с таким же успехом сообщать о недействительных блоках и
получать соответствующие вознаграждения.
2.6.28. Рекурсивная надежность блока. Можно также определить рекурсивную
надежность блока как минимум его относительной надежности и
рекурсивной надежности всех блоков, на которые он ссылается (т.е.
блока основной цепочки, предыдущего блока цепочки сегментов и некоторых блоков соседних цепочек сегментов).
Другими словами, если блок окажется недействительным, либо потому, что он недействителен сам по
себе, либо потому, что один из блоков, от которых он зависит, недействителен, то, по крайней мере, это
сумма денег была бы кем-то потеряна. Если вы действительно не уверены, следует ли
доверять определенной транзакции в блоке, следует вычислить рекурсивную
надежность этого блока, а не только относительную.
Не имеет смысла заходить слишком далеко назад при вычислении рекурсивной
надежности, потому что, если мы заглянем слишком далеко назад, мы увидим блоки, подписанные
валидаторами, ставки которых уже были разморожены и сняты. В любом
случае, мы не разрешаем валидаторам автоматически пересматривать старые блоки
(т.е. созданные более двух месяцев назад, если текущие значения
используются настраиваемые параметры), и создавать вилки, отталкиваясь от них, или
исправлять их с помощью вертикальных цепочек блоков (см. 2.1.17), даже если они
окажутся недействительными. Мы предполагаем, что двухмесячный период предоставляет
широкие возможности для обнаружения и сообщения о любых недействительных блоках, так что,
если блок не будет оспорен в течение этого периода, он вряд ли будет оспорен
вообще.

Signing masterchain blocks. The situation with the masterchain
blocks is somewhat dierent: by signing a masterchain block, the validator asserts not only its relative validity, but also the relative validity of all
preceding blocks up to the very rst block when this validator assumed its
responsibility (but not further back).
2.6.24. The total number of validators. The upper limit T for the total
number of validators to be elected (cf. 2.6.7) cannot become, in the system
described so far, more than, say, several hundred or a thousand, because all
validators are expected to participate in a BFT consensus protocol to create each new masterchain block, and it is not clear whether such protocols
can scale to thousands of participants. Even more importantly, masterchain
blocks must collect the signatures of at least two-thirds of all the validators
(by stake), and these signatures must be included in the new block (otherwise all other nodes in the system would have no reason to trust the new
block without validating it by themselves). If more than, say, one thousand
validator signatures would have to be included in each masterchain block,
this would imply more data in each masterchain block, to be stored by all
full nodes and propagated through the network, and more processing power
spent to check these signatures (in a PoS system, full nodes do not need to
validate blocks by themselves, but they need to check the validators' signatures instead).
While limiting T to a thousand validators seems more than sucient for
the rst phase of the deployment of the TON Blockchain, a provision must
be made for future growth, when the total number of shardchains becomes
so large that several hundred validators will not suce to process all of
them. To this end, we introduce an additional congurable parameter T
0 ≤ T
(originally equal to T), and only the top T
0
elected validators (by stake) are
expected to create and sign new masterchain blocks.
2.6.25. Decentralization of the system. One might suspect that a Proofof-Stake system such as the TON Blockchain, relying on T ≈ 1000 validators
to create all shardchain and masterchain blocks, is bound to become ?too
centralized?, as opposed to conventional Proof-of-Work blockchains like Bitcoin or Ethereum, where everybody (in principle) might mine a new block,
54
2.6. Creating and Validating New Blocks
without an explicit upper limit on the total number of miners.
However, popular Proof-of-Work blockchains, such as Bitcoin and Ethereum, currently require vast amounts of computing power (high ?hash rates?)
to mine new blocks with non-negligible probability of success. Thus, the
mining of new blocks tends to be concentrated in the hands of several large
players, who invest huge amounts money into datacenters lled with customdesigned hardware optimized for mining; and in the hands of several large
mining pools, which concentrate and coordinate the eorts of larger groups
of people who are not able to provide a sucient ?hash rate? by themselves.
Therefore, as of 2017, more than 75% of new Ethereum or Bitcoin blocks
are produced by less than ten miners. In fact, the two largest Ethereum
mining pools produce together more than half of all new blocks! Clearly,
such a system is much more centralized than one relying on T ≈ 1000 nodes
to produce new blocks.
One might also note that the investment required to become a TON
Blockchain validator?i.e., to buy the hardware (say, several high-performance
servers) and the stake (which can be easily collected through a pool of nominators if necessary; cf. 2.6.3)?is much lower than that required to become
a successful stand-alone Bitcoin or Ethereum miner. In fact, the parameter L of 2.6.7 will force nominators not to join the largest ?mining pool?
(i.e., the validator that has amassed the largest stake), but rather to look
for smaller validators currently accepting funds from nominators, or even to
create new validators, because this would allow a higher proportion s
0
i
/si of
the validator's?and by extension also the nominator's?stake to be used,
hence yielding larger rewards from mining. In this way, the TON Proof-ofStake system actually encourages decentralization (creating and using more
validators) and punishes centralization.
2.6.26. Relative reliability of a block. The (relative) reliability of a block
is simply the total stake of all validators that have signed this block. In other
words, this is the amount of money certain actors would lose if this block
turns out to be invalid. If one is concerned with transactions transferring
value lower than the reliability of the block, one can consider them to be safe
enough. In this sense, the relative reliability is a measure of trust an outside
observer can have in a particular block.
Note that we speak of the relative reliability of a block, because it is a
guarantee that the block is valid provided the previous block and all other
shardchains' blocks referred to are valid (cf. 2.6.22).
55
2.6. Creating and Validating New Blocks
The relative reliability of a block can grow after it is committed?for
example, when belated validators' signatures are added (cf. 2.6.21). On the
other hand, if one of these validators loses part or all of its stake because
of its misbehavior related to some other blocks, the relative reliability of a
block may decrease.
2.6.27. ?Strengthening? the blockchain. It is important to provide incentives for validators to increase the relative reliability of blocks as much as
possible. One way of doing this is by allocating a small reward to validators
for adding signatures to blocks of other shardchains. Even ?would-be? validators, who have deposited a stake insucient to get into the top T validators
by stake and to be included in the global set of validators (cf. 2.6.7), might
participate in this activity (if they agree to keep their stake frozen instead
of withdrawing it after having lost the election). Such would-be validators
might double as shermen (cf. 2.6.4): if they have to check the validity of
certain blocks anyway, they might as well opt to report invalid blocks and
collect the associated rewards.
2.6.28. Recursive reliability of a block. One can also dene the recursive
reliability of a block to be the minimum of its relative reliability and the
recursive reliabilities of all blocks it refers to (i.e., the masterchain block, the
previous shardchain block, and some blocks of neighboring shardchains). In
other words, if the block turns out to be invalid, either because it is invalid by
itself or because one of the blocks it depends on is invalid, then at least this
amount of money would be lost by someone. If one is truly unsure whether
to trust a specic transaction in a block, one should compute the recursive
reliability of this block, not just the relative one.
It does not make sense to go too far back when computing recursive
reliability, because, if we look too far back, we will see blocks signed by
validators whose stakes have already been unfrozen and withdrawn. In any
case, we do not allow the validators to automatically reconsider blocks that
are that old (i.e., created more than two months ago, if current values of
congurable parameters are used), and create forks starting from them or
correct them with the aid of ?vertical blockchains? (cf. 2.1.17), even if they
turn out to be invalid. We assume that a period of two months provides
ample opportunities for detecting and reporting any invalid blocks, so that
if a block is not challenged during this period, it is unlikely to be challenged
at all.