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

50 2.8. Классификация блокчейн-проектов валидаторов). В текущем подмножестве валидаторов существует предопределенный порядок, поэтому каждому блоку назначается производитель (т. е. валидатор, который, как ожидается, сгенерирует этот блок); ротация этих назначенных производителей осуществляется по круговой схеме.
Таким образом, блок сначала подписывается только валидатором. Затем, когда генерируется следующий блок, и его производитель предпочитает ссылаться на этот блок, а не на одного из его предшественников (в противном случае его блок будет находиться в более короткой цепочке, которая может проиграть конкуренцию
«самому длинному форку» в будущем), подпись следующего блока, по сути, также является дополнительной подписью предыдущего блока. Таким образом, новый блок постепенно собирает подписи большего количества валидаторов - скажем, двадцать подписей за время, необходимое для генерации следующих двадцати блоков. Полная нода должна будет либо дождаться этих двадцати подписей, либо подтвердить блок самостоятельно, начиная с достаточно валидного блока (скажем, двадцать блоков назад), что может быть не так просто.
Очевидным недостатком алгоритма DPOS по сравнению с алгоритмами BFT является то, что новый блок (и транзакции, зафиксированные в нем) достигает того же уровня доверия («рекурсивная надежность», как описано в п. 2.6.28) только после добычи следующих двадцати дополнительных блоков, которые сразу же обладают таким же уровнем доверия (скажем, двадцать подписей). Другой недостаток заключается в том, что DPOS использует подход «побеждает самый длинный форк» для переключения на другие форки; это делает форки весьма вероятными, если некоторые производители не смогут сгенерировать последующие блоки после того блока, который нас интересует (или мы не сможем наблюдать эти блоки из-за нарушения связности сети или хакерских атак).
Мы полагаем, что хотя подход BFT и является более сложным для реализации и требует более длительных интервалов времени между блоками, чем DPOS, BFT лучше приспособлен к «сильно-связанным» (см. 2.8.14) мультичейн-системам, потому что другие блокчейны могут начать работу почти сразу после фиксации транзакции
(например, генерировать сообщение, предназначенное для них) в новом блоке, не дожидаясь двадцати подтверждений валидности (т. е. следующих двадцати блоков) или следующих шести блоков, чтобы убедиться в отсутствии форков и проверить новый блок самостоятельно (проверка блоков других блокчейнов может стать недопустимой в масштабируемой мультичейн-системе).
Таким образом, обеспечивается масштабируемость системы с одновременным сохранением высокой надежности и доступности (см. 2.8.12).
С другой стороны, DPOS может быть хорошим выбором для «слабо-связанной» мультичейн-системы, где быстрое взаимодействие между блокчейнами не требуется - например, если каждый блокчейн («воркчейн») представляет собой отдельную распределенную систему обменов, а взаимодействие между блокчейнами ограничивается редкими передачами токенов из одного воркчейна в другой (или, скорее, обменом одного альткойна, находящегося в одном воркчейне, на другой со скоростью, приближающейся к 1: 1).
Именно это и реализуется в проекте BitShares, который довольно успешно использует подход DPOS.
Подводя итог, хотя DPOS может генерировать новые блоки и включать транзакции в них быстрее (с меньшими интервалами между блоками), эти транзакции достигают уровня доверия, необходимого для их использования в других блокчейнах и офф-чейн приложениях как «включенных» и «неизменяемых» гораздо медленнее, чем в системах BFT - скажем, за тридцать
26
секунд вместо пяти.
25
Некоторые пользователи даже заявляют, что время генерации блока DPOS составляет полсекунды, что не кажется реалистичным, если валидаторы разбросаны по нескольким континентам

51 2.8. Классификация блокчейн-проектов
Более быстрое включение транзакции не означает более быстрое выполнение транзакции. Это может стать огромной проблемой, если требуется быстрое взаимодействие между блокчейнами. В этом случае следует отказаться от DPOS и вместо этого выбрать BFT PoS..

52 2.8. Классификация блокчейн-проектов для выполнения кода смарт-контрактов, одну и ту же криптовалюту и так далее), и это сходство явно используется, но с разными данными в каждом блокчейне. В этом случае мы говорим, что система гомогенная. В ином случае разные блокчейны
(которые в этом случае обычно называются воркчейнами) могут иметь разные
«правила». Тогда мы говорим, что система гетерогенная.
2.8.9. Смешанные гетерогенные-гомогенные системы. Система может быть смешанной – в ней существует несколько наборов типов или правил для блокчейнов, но присутствует множество блокчейнов с одинаковыми правилами, и этот факт явно используется. Тогда это смешанная гетерогенная-гомогенная система. Насколько нам известно, блокчейн TON является единственным примером такой системы.
2.8.10. Гетерогенные системы с несколькими воркчейнами с одинаковыми
правилами, или конфедерации. В некоторых случаях несколько блокчейнов
(воркчейнов) с одинаковыми правилами могут присутствовать в гетерогенной системе, но взаимодействие между ними такое же, как и между блокчейнами с разными правилами (то есть их сходство не используется явно). Даже если они используют "одну и ту же" криптовалюту, на самом деле они используют разные "альткоины" (независимые воплощения криптовалюты). Иногда можно даже иметь определенные механизмы для конвертации этих альткоинов со скоростью, близкой к
1 : 1. Однако, на наш взгляд, это не делает систему гомогенной; она остается гетерогенной. Мы называем такую гетерогенную коллекцию воркчейнов с одинаковыми правилами конфедерацией.
Хотя создание гетерогенной системы, позволяющей создавать несколько воркчейнов с одинаковыми правилами (например, конфедерацию), может показаться дешевым способом построения масштабируемой системы, этот подход также имеет множество недостатков. По сути, если кто-то размещает большой проект в нескольких воркчейнах с одинаковыми правилами, он получает не большой проект, а множество небольших экземпляров этого проекта. Это похоже на приложение для общения (или игру), в котором может быть не более 50 участников в любой комнате чата (или игры), но которое при необходимости «масштабируется» путем создания новых комнат для общения большего количества пользователей. В результате многие пользователи могут участвовать в чатах или в игре, но можно ли сказать, что такая система действительно является масштабируемой?
2.8.11. Наличие мастерчейна, внешнего или внутреннего. Иногда в мультичейн- проекте есть выделенный «мастерчейн» («управляющий блокчейн»), который используется, например, для хранения общей конфигурации системы (набора всех активных блокчейнов, или, скорее, воркчейнов), текущего набора валидаторов (для системы Proof-of-Stake) и так далее. Иногда другие блокчейны «привязаны» к мастерчейну, например, путем включения в него хэшей своих последних блоков (это то, что делает блокчейн TON).
В некоторых случаях мастерчейн является внешним, что означает, что он не является частью проекта, а является каким-то другим существующим блокчейном, изначально совершенно не связанным с новым проектом и не зависящим от него. Например, можно попробовать использовать блокчейн Эфириум в качестве мастерчейна для внешнего проекта и для этой цели опубликовать специальные смарт-контракты в блокчейне Эфириум (например, для выбора и наказания валидаторов).
2.8.12. Поддержка шардинга. Некоторые проекты (или системы) на блокчейне имеют встроенную поддержку шардинга, что означает, что несколько (обязательно гомогенных; см. 2.8.8) блокчейнов рассматриваются как шарды единого (если смотреть сверху) виртуального блокчейна. Например, можно создать 256 шардчейнов

53 2.8. Классификация блокчейн-проектов с одними и теми же правилами и сохранить состояние учетной записи точно в одном выбранном шарде в зависимости от первого байта его идентификатора account_id.
Шардинг — это естественный подход к масштабированию блокчейн-систем, потому что, если он правильно реализован, пользователям и смарт-контрактам в системе вообще не нужно знать о существовании шардинга. На самом деле, когда нагрузка становится слишком высокой, часто имеет смысл добавить шардинг к существующему синглчейн-проекту (например, Эфириум).
Альтернативный подход к масштабированию мог бы заключаться в использовании "конфедерации" гетерогенных воркчейнов, позволяющей каждому пользователю держать свой аккаунт в одном или нескольких воркчейнах по своему выбору и при необходимости переводить средства со своего аккаунта в одном воркчейне в другой воркчейн, по сути выполняя обмен альткоинов 1 : 1. Недостатки этого подхода уже обсуждались в п. 2.8.10.
Однако шардинг не так просто реализовать быстрым и надежным способом, поскольку он подразумевает пересылку множества сообщений между различными шардчейнами. Например, если учетные записи равномерно распределены между N шардами, а единственными транзакциями являются простые переводы средств с одной учетной записи на другую, то только небольшая часть (1/N) всех транзакций будет выполняться в одном блокчейне. Почти все транзакции (1–1/N) будут включать в себя два блокчейна, что потребует взаимодействия между блокчейнами. Если мы хотим, чтобы эти транзакции были быстрыми, нам нужна быстрая система для передачи сообщений между шардчейнами. Другими словами, блокчейн-проект должен быть «сильно-связанным» в смысле, описанном в п. 2.8.14
2.8.13. Динамический и статический шардинг. Шардинг может быть динамическим
(если при необходимости автоматически создаются дополнительные шарды) или статическим (когда есть предопределенное количество шардов, которое можно изменить только с помощью хард-форка в лучшем случае). В большинстве проектов предлагается статичный шардинг; в блокчейне TON используется динамический шардинг (см. 2.7).
2.8.14. Взаимодействие между блокчейнами: слабо-связанные и тесно-связанные
системы. Мультиблокчейн-проекты можно классифицировать в соответствии с поддерживаемым уровнем взаимодействия между составляющими их блокчейнами.
Наименьший уровень поддержки — это отсутствие какого-либо взаимодействия между различными блокчейнами вообще. Эти блокчейны являются не частями одной блокчейн-системы, а просто отдельными примерами одного и того же протокола блокчейна.
Следующий уровень — это отсутствие какой-либо конкретной поддержки обмена сообщениями между блокчейнами, что делает взаимодействие в принципе возможным, но неудобным. Мы называем такие системы "слабо-связанными"; в них нужно отправлять сообщения и переводить ценности между блокчейнами, как если бы они были блокчейнами, принадлежащими к полностью отдельным блокчейн- проектам (например, Биткоин и Эфириум; представьте, что две стороны хотят обменять биткоины, хранящиеся в блокчейне Биткоин, на эфиры, хранящиеся в блокчейне Эфириум). Другими словами, необходимо включить исходящее сообщение
(или его генерирующую транзакцию) в блок исходного блокчейна. Затем нужно дождаться достаточного количества подтверждений (например, заданного количества последующих блоков), чтобы считать исходящую транзакцию «включённой» и
«неизменной», чтобы иметь возможность выполнять внешние действия на основе ее существования. Только после этого может быть включена транзакция, передающая сообщение в целевой блокчейн (возможно, вместе с референсом и доказательством
Меркла для существования исходящей транзакции).