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

45 2.7. Разделение и объединение шардчейнов
Обратите внимание, что любой активный шард (w, s) будет либо наследником некоторого однозначно определенного исходного шарда (w, s'), то есть, s' является префиксом s, либо он будет корнем поддерева исходных шардов (w, s'), где s будет префиксом каждого s'. В первом случае просто берется и удваивается группа задач исходного шарда (w, s'), в результате чего получается группа задач нового шарда (w, s). Во втором случае группа задач нового шарда (w, s) будет объединением групп задач всех исходных шардов (w, s '), которые являются наследниками (w, s) в дереве шардов.
Таким образом, для каждого активного шарда (w, s) назначается четко определенное подмножество валидаторов (группа задач). При разделении оба результирующих шарда наследуют всю группу задач от исходного шарда. При объединении двух шардчейнов соответствующие группы задач также объединяются.
Любой, кто отслеживает состояние мастерчейна, может вычислить группы задач валидаторов для каждого из активных шардов.
2.7.5. Ограничение операций разделения/объединения в период ответственности
исходных групп задач. В конечном итоге будет учтена новая конфигурация шарда, и для каждого шарда будут автоматически назначены новые выделенные подмножества
(группы задач) валидаторов. Прежде чем это произойдет, необходимо наложить определенный лимит на операции разделения/слияния; в противном случае исходная группа задач может закончить проверку 2
k шардчейнов для большого k одновременно, если исходный шард быстро разделится на 2
k новых шардчейнов.
Это достигается путем наложения ограничений на то, насколько активная конфигурация шарда может быть удалена от исходной конфигурации шарда (той, которая используется для выбора групп задач валидаторов, отвечающих за проверку блоков в настоящее время). Например, может быть задано требование, чтобы расстояние в дереве шардов от активного шарда (w, s) до исходного шарда (w, s') не превышало 3, если s' является предшественником s (т. е. S' является префиксом двоичной строки s), и не должно превышать 2, если s' является преемником s (т. е. s является префиксом s'). В противном случае операция разделения или слияния не будет разрешена.
Грубо говоря, в данном случае вводится ограничение на количество процессов разделения (например, три) или объединения (например, два) шарда в течение периода ответственности данного набора валидаторов. Кроме того, после создания шарда в результате слияния или разделения его нельзя перенастроить в течение некоторого периода времени (некоторого количества блоков).

46 2.7. Разделение и объединение шардчейнов шард только что был разделен). Следующий блок мастерчейна будет содержать хэши блоков B’
0
и B'
1
новых шардчейнов; в блоке не может содержаться хэш нового блока шардчейна B' (w, s), потому что событие «выполнить разделение» уже было зафиксировано в предыдущем блоке мастерчейна.
Обратите внимание, что оба новых шардчейна будут проверяться той же группой задач валидаторов, что и исходный шардчейн, поэтому они автоматически получат копию своего состояния. Сама операция разделения состояний довольно проста с точки зрения парадигмы бесконечного шардинга (см. 2.5.2)
2.7.8. Определение необходимости операций слияния. Необходимость операций слияния шардчейнов также определяется некоторыми формальными условиями
(например, если в 64 последовательных блоках сумма размеров двух блоков родственных шардчейнов не превышает 60% от максимального размера блока).
Формальные условия также должны учитывать общий объем газа, израсходованный этими блоками, и сравнивать его с текущим лимитом газа на блок, в противном случае блоки могут оказаться небольшими из-за наличия некоторых транзакций, требующих большого объема вычислений, которые препятствуют включению большего количества транзакций.
Эти условия отслеживаются группами задач валидаторов обоих родственных шардов
(w, s.0) и (w, s.1). Обратите внимание, что родственные шардчейны обязательно являются соседями с точки зрения маршрутизации в гиперкубе (см. 2.4.19), поэтому валидаторы из группы задач любого шарда в любом случае будут в какой-то степени контролировать родственный шард.
Если эти условия выполнены, одна из подгрупп валидаторов может предложить другой объединиться, отправив специальное сообщение. Затем они объединяются во временную «объединенную группу задач» с объединенным членством, способную запускать согласованные алгоритмы BFT и при необходимости распространять обновления блоков и блоков-кандидатов.
Если валидаторы достигают консенсуса относительно необходимости и готовности слияния, флаги «подготовки к слиянию» фиксируются в заголовках некоторых блоков каждом шардчейне вместе с подписями не менее двух третей валидаторов группы задач родственного шардчейна (и распространяются на следующие блоки мастерчейна, чтобы все могли подготовиться к неминуемой реконфигурации). Однако они продолжают создавать отдельные блоки шардчейна для некоторого заранее определенного количества блоков.
2.7.9. Выполнение операций слияния. Когда валидаторы из двух объединенных исходных групп задач готовы стать валидаторами объединенного шардчейна (это может включать в себя передачу состояния из родственного шардчейна и операцию слияния), они фиксируют флаг «выполнить слияние» в заголовках блоков соответствующего шардчейна (это событие распространяется на следующие блоки мастерчейна) и прекращают создание новых блоков в отдельных шардчейнах (после появления флага «выполнить слияние» создание блоков в отдельных шардчейнах запрещено). Вместо этого создается объединенный блок шардчейна (путем объединения двух исходных групп задач) со ссылкой на оба его «предыдущих блока» в «заголовке». Это отражается в следующем блоке мастерчейна, который будет содержать хэш вновь созданного блока объединенного шардчейна. После этого объединенная группа задач продолжает создавать блоки в объединенном шардчейне.
2.8. Классификация блокчейн-проектов
Мы завершим наше краткое обсуждение блокчейна TON сравнением его с существующими и предлагаемыми блокчейн-проектами. Однако перед этим

47 2.8. Классификация блокчейн-проектов необходимо представить обобщенную классификацию блокчейн-проектов.
Сравнение конкретных блокчейн-проектов на основе этой классификации будет приведено в п. 2.9.
2.8.1. Классификация блокчейн-проектов. В качестве первого шага мы предлагаем некоторые критерии классификации блокчейнов (т. е. блокчейн-проектов). Любая такая классификация является в некоторой степени неполной и поверхностной, поскольку она игнорирует некоторые из наиболее специфических и уникальных особенностей рассматриваемых проектов. Однако мы считаем, что это необходимый первый шаг для предоставления хотя бы очень приблизительной схемы блокчейн- проектов.
Список критериев, которые мы будем рассматривать:
• Сингл-блокчейн vs. мульти-блокчейн архитектура (см. 2.8.2)
• Алгоритм консенсуса: Proof-of-Stake vs. Proof-of-Work (см. 2.8.3)
• Для систем Proof-of-Stake: конкретное поколение блокчейна, валидация и алгоритм консенсуса (двумя основными опциями являются DPOS vs. BFT; см.
2.8.4)
• Поддержка «произвольных» (Тьюринг-полных) смарт-контрактов (см. 2.8.6)
Мульти-блокчейн системы имеют дополнительные критерии классификации (см.
2.8.7):
• Типы и правила для блокчейнов: гомогенные, гетерогенные (см. 2.8.8), смешанные (см. 2.8.9). Конфедерации (см. 2.8.10).
• Отсутствие или наличие мастерчейна, внутреннего или внешнего (см. 2.8.11)
• Нативная поддержка шардинга (см. 2.8.12), статический или динамический шардинг (см. 2.8.13).
• Взаимодействие между блокчейнами: слабо-связанные и тесно-связанные системы (см. 2.8.14)
2.8.2. Сингл-блокчейн vs. мульти-блокчейн проекты. Первым критерием классификации является количество блокчейнов в системе. Старейшие и простейшие проекты состоят из одного блокчейна («синглчейн-проекты» для краткости); в более сложных проектах используется (или, скорее, планируется использование) несколько блокчейнов («мультичейн-проекты»).
Сингл-блокчейн проекты обычно проще и лучше тестируются; они выдержали испытание временем. Их главный недостаток в низкой производительности, или по крайней мере пропускной способности для транзакций, которая находится на уровне от десяти (Биткоин) до менее чем сотни
24
(Эфириум) транзакций в секунду для многоцелевых систем. Некоторые специализированные системы (такие как Bitshares) способны обрабатывать десятки тысяч специализированных транзакций в секунду, взамен требуя хранить состояние блокчейна в памяти, и ограничивая обработку до предопределенного специального набора транзакций, которые затем выполняются высокооптимизированным кодом на языках вроде C++ (никаких виртуальных машин).
Мультичейн-проекты могут поддерживать большее общее число состояний и больше транзакций в секунду, взамен делая проект и его имплементацию намного более сложными. В результате, есть всего несколько уже работающих мультичейн- проектов, но большинство предлагаемых проектов являются мультичейн-проектами.
Мы верим, что будущее именно за мультичейн-проектами.
24
Скорее, на данный момент это значение составляет 15. Тем не менее, планируются некоторые обновления, чтобы увеличить пропускную способность транзакций Ethereum в несколько раз

48 2.8. Классификация блокчейн-проектов
2.8.3. Создание и валидация блоков: Proof-of-Work vs. Proof-of-Stake. Другое важное отличие – это алгоритм и протокол, которые используются для создания и распространения новых блоков, проверки их валидности и выбора одного из нескольких ответвлений, если таковые появляются.
Две наиболее распространенные парадигмы - это Proof-of-Work (PoW) и Proof-of-
Stake (PoS). Подход Proof-of-Work обычно позволяет любой ноде создавать
(«майнить») новые блоки (и получать некоторую награду, связанную с майнингом блока), если ей повезёт решить в ином случае бесполезную вычислительную задачу
(обычно включающую вычисление большого количества хэшей) раньше, чем это успеют сделать конкуренты. В случае форков (например, если две ноды публикуют два валидных, но разных блока, следующих за предыдущим) побеждает самый длинный форк. Таким образом, гарантия неизменности блокчейна основана на объеме работы (вычислительных ресурсов), затрачиваемых на создание блокчейна: любому, кто хотел бы создать форк этого блокчейна, необходимо было бы повторно выполнить эту работу, чтобы создать альтернативные версии уже включенных блоков. Для этого нужно контролировать более 50% общей вычислительной мощности, затрачиваемой на создание новых блоков, в противном случае у альтернативного форка будут экспоненциально низкие шансы стать самым длинным.
Подход Proof-of-Stake основан на больших стейках (в криптовалюте), сделанных некоторыми специальными нодами (валидаторами), чтобы подтвердить, что они проверили (валидировали) некоторые блоки и нашли их правильными. Валидаторы подписывают блоки и получают за это небольшие награды; однако, если валидатор когда-либо был пойман на подписании неправильного блока, и было представлено доказательство этого, часть стейка или весь его стейк аннулируется. Таким образом, гарантия валидности и неизменности блокчейна обеспечивается общим объемом стейков, поставленных валидаторами на валидность блокчейна.
Подход Proof-of-Stake более естественен в том смысле, что он стимулирует валидаторов (которые заменяют майнеров PoW) выполнять полезные вычисления
(необходимые для проверки или создания новых блоков, в частности, путем выполнения всех транзакций, перечисленных в блоке) вместо вычисления бесполезных хэшей. Таким образом, валидаторы будут приобретать оборудование, которое лучше приспособлено для обработки пользовательских транзакций, чтобы получать вознаграждения, связанные с этими транзакциями, что кажется весьма полезным вложением с точки зрения системы в целом.
Однако системы Proof-of-Stake несколько сложнее реализовать, поскольку необходимо предусмотреть множество редких, но возможных условий. Например, некоторые злонамеренные валидаторы могут вступить в сговор, чтобы нарушить работу системы и извлечь прибыль (например, путем изменения своих собственных балансов криптовалюты). Это приводит к необходимости решать некоторые нетривиальные задачи теории игр.
В целом, более естественен и более перспективен, особенно для мультичейн-проектов
(потому что Proof-of-Work потребует непомерно больших вычислительных ресурсов, если блокчейнов много), но его необходимо более тщательно продумать и реализовать. Большинство работающих в настоящее время блокчейн-проектов, особенно самых старых (таких как Биткоин и как минимум оригинальный Эфириум), используют Proof-of-Work.
2.8.4. Варианты Proof-of-Stake. DPOS vs. BFT. Хотя алгоритмы Proof-of-Work очень похожи друг на друга и различаются в основном хэш-функциями, которые необходимо вычислять для добычи новых блоков, для алгоритмов Proof-of-Stake существует больше возможностей и они заслуживают отдельной подклассификации.
По сути, нужно ответить на следующие вопросы об алгоритме Proof-of-Stake:

49 2.8. Классификация блокчейн-проектов
• Кто может произвести («добыть») новый блок - любая полная нода или только член (относительно) небольшого подмножества валидаторов? (Большинство систем PoS требуют, чтобы новые блоки создавались и подписывались одним из нескольких назначенных валидаторов.)
• Гарантируют ли валидаторы валидность блоков своими подписями или все полные ноды должны проверять все блоки самостоятельно? (Масштабируемые системы PoS должны полагаться на подписи валидаторов вместо того, чтобы требовать, чтобы все ноды проверяли все блоки всех блокчейнов.)
• Есть ли назначенный и заранее известный создатель следующего блока блокчейна, вместо которого никто не сможет произвести этот блок?
• Является ли вновь созданный блок изначально подписанным только одним валидатором (его создателем), или он должен собирать большинство подписей валидаторов с самого начала?
Может показаться, что в зависимости от ответов на эти вопросы алгоритмы PoS можно разделить на 2 4
возможных класса, на практике различие сводится к двум основным подходам к PoS. Фактически, для большинства современных алгоритмов
PoS, разработанных для использования в масштабируемых мультичейн-системах, ответы на первые два вопроса являются одинаковыми: только валидаторы могут создавать новые блоки, и именно они гарантируют валидность блока (при этом не требуется, чтобы все полные ноды проверяли валидность всех блоков по отдельности).
Что касается двух последних вопросов, ответы на них сильно зависят от свойств конкретной системы, оставляя по существу только два основных варианта:
• Delegated Proof-of-Stake (DPOS): для каждого блока есть общеизвестный назначенный производитель; никто другой не может произвести этот блок; новый блок изначально подписывается только производящим его валидатором.
• Byzantine Fault Tolerant (BFT) алгоритмы PoS: существует известное подмножество валидаторов, любой из которых может предложить новый блок; выбор следующего блока среди нескольких предложенных кандидатов, который должен быть проверен и подписан большинством валидаторов перед передачей другим нодам, достигается версией протокола консенсуса Byzantine
Fault Tolerant.
2.8.5. Сравнение DPOS и BFT PoS. Подход BFT обладает тем преимуществом, что вновь созданный блок с самого начала имеет подписи большинства валидаторов, подтверждающие его валидность. Еще одно преимущество заключается в том, что, если большинство валидаторов правильно выполняет протокол консенсуса BFT, форки системы невозможны. С другой стороны, алгоритмы BFT обычно довольно запутанны и при их использовании необходимо больше времени для того, чтобы подмножество валидаторов достигло консенсуса. Следовательно, блоки нельзя генерировать слишком часто. Вот почему мы ожидаем, что блокчейн TON (который является проектом BFT с точки зрения этой классификации) будет создавать блок не более одного раза в пять секунд. На практике этот интервал может быть уменьшен до
2-3 секунд (хотя мы этого не обещаем), но не больше, так как валидаторы разбросаны по всему миру.
Преимущество алгоритма DPOS состоит в том, что он довольно прост и понятен. Он может генерировать новые блоки довольно часто - скажем, раз в две секунды или даже раз в секунду
25
- благодаря тому, что он полагается на заранее известных производителей блоков.
Однако DPOS требует, чтобы все ноды – или как минимум все валидаторы - проверяли все полученные блоки, потому что валидатор, создающий и подписывающий новый блок, подтверждает не только относительную валидность этого блока, но также валидность предыдущего блока, на который он ссылается, а также все блоки назад в цепочке (возможно, до начала периода ответственности текущего подмножества