Мы завершим наше краткое обсуждение блокчейна TON сравнением его с существующими и предлагаемыми блокчейн-проектами. Однако перед этим необходимо представить обобщенную классификацию блокчейн-проектов. Сравнение конкретных блокчейн-проектов на основе этой классификации.Классификация блокчейн-проектов
В качестве первого шага мы предлагаем некоторые критерии классификации блокчейнов (т. е. блокчейн-проектов). Любая такая классификация является в некоторой степени неполной и поверхностной, поскольку она игнорирует некоторые из наиболее специфических и уникальных особенностей рассматриваемых проектов. Однако мы считаем, что это необходимый первый шаг для предоставления хотя бы очень приблизительной схемы блокчейн-проектов.
Список критериев, которые мы будем рассматривать:
• Сингл-блокчейн vs. мульти-блокчейн архитектура
• Алгоритм консенсуса: Proof-of-Stake vs. Proof-of-Work
• Для систем Proof-of-Stake: конкретное поколение блокчейна, валидация и алгоритм консенсуса (двумя основными опциями являются DPOS vs. BFT)
• Поддержка «произвольных» (Тьюринг-полных) смарт-контрактов
Мульти-блокчейн системы имеют дополнительные критерии классификации:
• Типы и правила для блокчейнов: гомогенные, гетерогенные, смешанные. Конфедерации.
• Отсутствие или наличие мастерчейна, внутреннего или внешнего
• Нативная поддержка шардинга, статический или динамический шардинг.
• Взаимодействие между блокчейнами: слабо-связанные и тесно-связанные системы
Сингл-блокчейн vs. мульти-блокчейн проекты
Первым критерием классификации является количество блокчейнов в системе. Старейшие и простейшие проекты состоят из одного блокчейна («синглчейн-проекты» для краткости); в более сложных проектах используется (или, скорее, планируется использование) несколько блокчейнов («мультичейн-проекты»).
Сингл-блокчейн проекты обычно проще и лучше тестируются; они выдержали испытание временем. Их главный недостаток в низкой производительности, или по крайней мере пропускной способности для транзакций, которая находится на уровне от десяти (Биткоин) до менее чем сотни(Эфириум) транзакций в секунду для многоцелевых систем. Некоторые специализированные системы (такие как Bitshares) способны обрабатывать десятки тысяч специализированных транзакций в секунду, взамен требуя хранить состояние блокчейна в памяти, и ограничивая обработку до предопределенного специального набора транзакций, которые затем выполняются высокооптимизированным кодом на языках вроде C++ (никаких виртуальных машин).
Мультичейн-проекты могут поддерживать большее общее число состояний и больше транзакций в секунду, взамен делая проект и его имплементацию намного более сложными. В результате, есть всего несколько уже работающих мультичейн-проектов, но большинство предлагаемых проектов являются мультичейн-проектами. Мы верим, что будущее именно за мультичейн-проектами.
Скорее, на данный момент это значение составляет 15. Тем не менее, планируются некоторые обновления, чтобы увеличить пропускную способность транзакций Ethereum в несколько раз
Создание и валидация блоков: 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.
Варианты Proof-of-Stake
DPOS vs. BFT. Хотя алгоритмы Proof-of-Work очень похожи друг на друга и различаются в основном хэш-функциями, которые необходимо вычислять для добычи новых блоков, для алгоритмов Proof-of-Stake существует больше возможностей и они заслуживают отдельной подклассификации.
По сути, нужно ответить на следующие вопросы об алгоритме Proof-of-Stake:
• Кто может произвести («добыть») новый блок — любая полная нода или только член (относительно) небольшого подмножества валидаторов? (Большинство систем PoS требуют, чтобы новые блоки создавались и подписывались одним из нескольких назначенных валидаторов.)
• Гарантируют ли валидаторы валидность блоков своими подписями или все полные ноды должны проверять все блоки самостоятельно? (Масштабируемые системы PoS должны полагаться на подписи валидаторов вместо того, чтобы требовать, чтобы все ноды проверяли все блоки всех блокчейнов.)
• Есть ли назначенный и заранее известный создатель следующего блока блокчейна, вместо которого никто не сможет произвести этот блок?
• Является ли вновь созданный блок изначально подписанным только одним валидатором (его создателем), или он должен собирать большинство подписей валидаторов с самого начала?
Может показаться, что в зависимости от ответов на эти вопросы алгоритмы PoS можно разделить на 24 возможных класса, на практике различие сводится к двум основным подходам к PoS. Фактически, для большинства современных алгоритмов PoS, разработанных для использования в масштабируемых мультичейн-системах, ответы на первые два вопроса являются одинаковыми: только валидаторы могут создавать новые блоки, и именно они гарантируют валидность блока (при этом не требуется, чтобы все полные ноды проверяли валидность всех блоков по отдельности).
Что касается двух последних вопросов, ответы на них сильно зависят от свойств конкретной системы, оставляя по существу только два основных варианта:
• Delegated Proof-of-Stake (DPOS): для каждого блока есть общеизвестный назначенный производитель; никто другой не может произвести этот блок; новый блок изначально подписывается только производящим его валидатором.
• Byzantine Fault Tolerant (BFT) алгоритмы PoS: существует известное подмножество валидаторов, любой из которых может предложить новый блок; выбор следующего блока среди нескольких предложенных кандидатов, который должен быть проверен и подписан большинством валидаторов перед передачей другим нодам, достигается версией протокола консенсуса Byzantine Fault Tolerant.
Сравнение DPOS и BFT PoS
Подход BFT обладает тем преимуществом, что вновь созданный блок с самого начала имеет подписи большинства валидаторов, подтверждающие его валидность. Еще одно преимущество заключается в том, что, если большинство валидаторов правильно выполняет протокол консенсуса BFT, форки системы невозможны. С другой стороны, алгоритмы BFT обычно довольно запутанны и при их использовании необходимо больше времени для того, чтобы подмножество валидаторов достигло консенсуса. Следовательно, блоки нельзя генерировать слишком часто. Вот почему мы ожидаем, что блокчейн TON (который является проектом BFT с точки зрения этой классификации) будет создавать блок не более одного раза в пять секунд. На практике этот интервал может быть уменьшен до 2-3 секунд (хотя мы этого не обещаем), но не больше, так как валидаторы разбросаны по всему миру.
Преимущество алгоритма DPOS состоит в том, что он довольно прост и понятен. Он может генерировать новые блоки довольно часто — скажем, раз в две секунды или даже раз в секунду — благодаря тому, что он полагается на заранее известных производителей блоков.
Однако DPOS требует, чтобы все ноды – или как минимум все валидаторы — проверяли все полученные блоки, потому что валидатор, создающий и подписывающий новый блок, подтверждает не только относительную валидность этого блока, но также валидность предыдущего блока, на который он ссылается, а также все блоки назад в цепочке (возможно, до начала периода ответственности текущего подмножества валидаторов). В текущем подмножестве валидаторов существует предопределенный порядок, поэтому каждому блоку назначается производитель (т. е. валидатор, который, как ожидается, сгенерирует этот блок); ротация этих назначенных производителей осуществляется по круговой схеме.
Таким образом, блок сначала подписывается только валидатором. Затем, когда генерируется следующий блок, и его производитель предпочитает ссылаться на этот блок, а не на одного из его предшественников (в противном случае его блок будет находиться в более короткой цепочке, которая может проиграть конкуренцию «самому длинному форку» в будущем), подпись следующего блока, по сути, также является дополнительной подписью предыдущего блока. Таким образом, новый блок постепенно собирает подписи большего количества валидаторов — скажем, двадцать подписей за время, необходимое для генерации следующих двадцати блоков. Полная нода должна будет либо дождаться этих двадцати подписей, либо подтвердить блок самостоятельно, начиная с достаточно валидного блока (скажем, двадцать блоков назад), что может быть не так просто.
Очевидным недостатком алгоритма DPOS по сравнению с алгоритмами BFT является то, что новый блок (и транзакции, зафиксированные в нем) достигает того же уровня доверия («рекурсивная надежность») только после добычи следующих двадцати дополнительных блоков, которые сразу же обладают таким же уровнем доверия (скажем, двадцать подписей). Другой недостаток заключается в том, что DPOS использует подход «побеждает самый длинный форк» для переключения на другие форки; это делает форки весьма вероятными, если некоторые производители не смогут сгенерировать последующие блоки после того блока, который нас интересует (или мы не сможем наблюдать эти блоки из-за нарушения связности сети или хакерских атак).
Мы полагаем, что хотя подход BFT и является более сложным для реализации и требует более длительных интервалов времени между блоками, чем DPOS, BFT лучше приспособлен к «сильно-связанным» мультичейн-системам, потому что другие блокчейны могут начать работу почти сразу после фиксации транзакции (например, генерировать сообщение, предназначенное для них) в новом блоке, не дожидаясь двадцати подтверждений валидности (т. е. следующих двадцати блоков) или следующих шести блоков, чтобы убедиться в отсутствии форков и проверить новый блок самостоятельно (проверка блоков других блокчейнов может стать недопустимой в масштабируемой мультичейн-системе). Таким образом, обеспечивается масштабируемость системы с одновременным сохранением высокой надежности и доступности.
С другой стороны, DPOS может быть хорошим выбором для «слабо-связанной» мультичейн-системы, где быстрое взаимодействие между блокчейнами не требуется — например, если каждый блокчейн («воркчейн») представляет собой отдельную распределенную систему обменов, а взаимодействие между блокчейнами ограничивается редкими передачами токенов из одного воркчейна в другой (или, скорее, обменом одного альткойна, находящегося в одном воркчейне, на другой со скоростью, приближающейся к 1: 1). Именно это и реализуется в проекте BitShares, который довольно успешно использует подход DPOS.
Подводя итог, хотя DPOS может генерировать новые блоки и включать транзакции в них быстрее (с меньшими интервалами между блоками), эти транзакции достигают уровня доверия, необходимого для их использования в других блокчейнах и офф-чейн приложениях как «включенных» и «неизменяемых» гораздо медленнее, чем в системах BFT — скажем, за тридцать26 секунд вместо пяти. 25 Некоторые пользователи даже заявляют, что время генерации блока DPOS составляет полсекунды, что не кажется реалистичным, если валидаторы разбросаны по нескольким континентам.
Более быстрое включение транзакции не означает более быстрое выполнение транзакции. Это может стать огромной проблемой, если требуется быстрое взаимодействие между блокчейнами. В этом случае следует отказаться от DPOS и вместо этого выбрать BFT PoS.
Поддержка Тьюринг-полного кода в транзакциях, то есть, произвольных смарт-контрактов
Проекты блокчейнов обычно собирают некоторые транзакции в своих блоках, которые изменяют состояние блокчейна необходимым образом (например, переводят некоторое количество криптовалюты с одной учетной записи на другую). Некоторые блокчейн-проекты могут разрешать только заранее определенные типы транзакций (например, транзакции стоимости из одной учетной записи в другую при условии наличия правильных подписей). Другие могут поддерживать определенную ограниченную форму написания сценариев в транзакциях. Наконец, некоторые блокчейны поддерживают выполнение произвольно сложного кода в транзакциях, позволяя системе (по крайней мере, в принципе) поддерживать произвольные приложения, если позволяет производительность системы. Обычно это связано с «Тьюринг-полными виртуальными машинами и языками сценариев» (это означает, что любая программа, которая может быть написана на любом другом языке программирования вычислений, может быть переписана для выполнения внутри блокчейна) и «смарт-контрактами» (которые представляют собой программы, находящиеся в блокчейне).
Поддержка произвольных смарт-контрактов делает систему по-настоящему гибкой. С другой стороны, такая гибкость обходится дорого: код этих смарт-контрактов должен выполняться на какой-то виртуальной машине, и это нужно делать каждый раз для каждой транзакции в блоке, когда кто-то хочет создать или валидировать блок. Это снижает производительность системы по сравнению со случаем предопределенного и неизменяемого набора типов простых транзакций, которые можно оптимизировать, реализовав их обработку на языке вроде C++ (вместо какой-либо виртуальной машины).
В конечном счете поддержка Тьюринг-полных смарт-контрактов представляется желательной в любом универсальном блокчейн-проекте; в противном случае разработчики блокчейн-проекта должны заранее решить, для каких приложений будет использоваться их блокчейн. Фактически, отсутствие поддержки смарт-контрактов в блокчейне Bitcoin было основной причиной создания нового блокчейн-проекта Ethereum.
В (гетерогенной) мультичейн-системе можно получить «все самое лучшее», используя Тьюринг-полные смарт-контракты в некоторых блокчейнах (воркчейнах) и небольшой предопределенный набор высокоэффективных оптимизированные транзакций в других блокчейнах.
Классификация мультичейн-систем
До сих пор классификация действовала как для синглчейн, так и для мультичейн-систем. Однако мультичейн-системы допускают еще несколько критериев классификации, отражающих взаимосвязь между различными блокчейнами в системе. Давайте обсудим эти критерии.
Типы блокчейнов: гомогенные и гетерогенные системы
В мультичейн-системе все блокчейны могут быть одного типа и иметь одинаковые правила (то есть использовать один и тот же формат транзакций, одну и ту же виртуальную машину. Например, EOS, один из лучших проектов на основе DPOS, предложенных на сегодняшний день, обещает 45-секундное подтверждение и задержку взаимодействия между блокчейнами (см. разделы «Подтверждение транзакции и задержка взаимодействия внутри сети»).
Для выполнения кода смарт-контрактов, одну и ту же криптовалюту и так далее), и это сходство явно используется, но с разными данными в каждом блокчейне. В этом случае мы говорим, что система гомогенная. В ином случае разные блокчейны (которые в этом случае обычно называются воркчейнами) могут иметь разные «правила». Тогда мы говорим, что система гетерогенная.
Смешанные гетерогенные-гомогенные системы
Система может быть смешанной – в ней существует несколько наборов типов или правил для блокчейнов, но присутствует множество блокчейнов с одинаковыми правилами, и этот факт явно используется. Тогда это смешанная гетерогенная-гомогенная система. Насколько нам известно, блокчейн TON является единственным примером такой системы.
Гетерогенные системы с несколькими воркчейнами с одинаковыми правилами, или конфедерации
В некоторых случаях несколько блокчейнов (воркчейнов) с одинаковыми правилами могут присутствовать в гетерогенной системе, но взаимодействие между ними такое же, как и между блокчейнами с разными правилами (то есть их сходство не используется явно). Даже если они используют «одну и ту же» криптовалюту, на самом деле они используют разные «альткоины» (независимые воплощения криптовалюты). Иногда можно даже иметь определенные механизмы для конвертации этих альткоинов со скоростью, близкой к 1 : 1. Однако, на наш взгляд, это не делает систему гомогенной; она остается гетерогенной. Мы называем такую гетерогенную коллекцию воркчейнов с одинаковыми правилами конфедерацией.
Хотя создание гетерогенной системы, позволяющей создавать несколько воркчейнов с одинаковыми правилами (например, конфедерацию), может показаться дешевым способом построения масштабируемой системы, этот подход также имеет множество недостатков. По сути, если кто-то размещает большой проект в нескольких воркчейнах с одинаковыми правилами, он получает не большой проект, а множество небольших экземпляров этого проекта. Это похоже на приложение для общения (или игру), в котором может быть не более 50 участников в любой комнате чата (или игры), но которое при необходимости «масштабируется» путем создания новых комнат для общения большего количества пользователей. В результате многие пользователи могут участвовать в чатах или в игре, но можно ли сказать, что такая система действительно является масштабируемой?
Наличие мастерчейна, внешнего или внутреннего
Иногда в мультичейн-проекте есть выделенный «мастерчейн» («управляющий блокчейн»), который используется, например, для хранения общей конфигурации системы (набора всех активных блокчейнов, или, скорее, воркчейнов), текущего набора валидаторов (для системы Proof-of-Stake) и так далее. Иногда другие блокчейны «привязаны» к мастерчейну, например, путем включения в него хэшей своих последних блоков (это то, что делает блокчейн TON).
В некоторых случаях мастерчейн является внешним, что означает, что он не является частью проекта, а является каким-то другим существующим блокчейном, изначально совершенно не связанным с новым проектом и не зависящим от него. Например, можно попробовать использовать блокчейн Эфириум в качестве мастерчейна для внешнего проекта и для этой цели опубликовать специальные смарт-контракты в блокчейне Эфириум (например, для выбора и наказания валидаторов).
Поддержка шардинга
Некоторые проекты (или системы) на блокчейне имеют встроенную поддержку шардинга, что означает, что несколько (обязательно гомогенных) блокчейнов рассматриваются как шарды единого (если смотреть сверху) виртуального блокчейна. Например, можно создать 256 шардчейнов с одними и теми же правилами и сохранить состояние учетной записи точно в одном выбранном шарде в зависимости от первого байта его идентификатора account_id.
Шардинг — это естественный подход к масштабированию блокчейн-систем, потому что, если он правильно реализован, пользователям и смарт-контрактам в системе вообще не нужно знать о существовании шардинга. На самом деле, когда нагрузка становится слишком высокой, часто имеет смысл добавить шардинг к существующему синглчейн-проекту (например, Эфириум).
Альтернативный подход к масштабированию мог бы заключаться в использовании «конфедерации» гетерогенных воркчейнов, позволяющей каждому пользователю держать свой аккаунт в одном или нескольких воркчейнах по своему выбору и при необходимости переводить средства со своего аккаунта в одном воркчейне в другой воркчейн, по сути выполняя обмен альткоинов 1 : 1.
Однако шардинг не так просто реализовать быстрым и надежным способом, поскольку он подразумевает пересылку множества сообщений между различными шардчейнами. Например, если учетные записи равномерно распределены между N шардами, а единственными транзакциями являются простые переводы средств с одной учетной записи на другую, то только небольшая часть (1/N) всех транзакций будет выполняться в одном блокчейне. Почти все транзакции (1–1/N) будут включать в себя два блокчейна, что потребует взаимодействия между блокчейнами. Если мы хотим, чтобы эти транзакции были быстрыми, нам нужна быстрая система для передачи сообщений между шардчейнами. Другими словами, блокчейн-проект должен быть «сильно-связанным» в смысле.
Динамический и статический шардинг
Шардинг может быть динамическим (если при необходимости автоматически создаются дополнительные шарды) или статическим (когда есть предопределенное количество шардов, которое можно изменить только с помощью хард-форка в лучшем случае). В большинстве проектов предлагается статичный шардинг; в блокчейне TON используется динамический шардинг.
Взаимодействие между блокчейнами: слабо-связанные и тесно-связанные системы
Мультиблокчейн-проекты можно классифицировать в соответствии с поддерживаемым уровнем взаимодействия между составляющими их блокчейнами.
Наименьший уровень поддержки — это отсутствие какого-либо взаимодействия между различными блокчейнами вообще. Эти блокчейны являются не частями одной блокчейн-системы, а просто отдельными примерами одного и того же протокола блокчейна.
Следующий уровень — это отсутствие какой-либо конкретной поддержки обмена сообщениями между блокчейнами, что делает взаимодействие в принципе возможным, но неудобным. Мы называем такие системы «слабо-связанными»; в них нужно отправлять сообщения и переводить ценности между блокчейнами, как если бы они были блокчейнами, принадлежащими к полностью отдельным блокчейн-проектам (например, Биткоин и Эфириум; представьте, что две стороны хотят обменять биткоины, хранящиеся в блокчейне Биткоин, на эфиры, хранящиеся в блокчейне Эфириум). Другими словами, необходимо включить исходящее сообщение (или его генерирующую транзакцию) в блок исходного блокчейна. Затем нужно дождаться достаточного количества подтверждений (например, заданного количества последующих блоков), чтобы считать исходящую транзакцию «включённой» и «неизменной», чтобы иметь возможность выполнять внешние действия на основе ее существования. Только после этого может быть включена транзакция, передающая сообщение в целевой блокчейн (возможно, вместе с референсом и доказательством Меркла для существования исходящей транзакции).
Если не ждать достаточно долго, прежде чем передать сообщение, или если форк все равно произойдет по какой-либо другой причине, объединенное состояние двух блокчейнов окажется противоречивым: во второй блокчейн будет доставлено сообщение, которое никогда не было сгенерировано в (окончательно выбранном форке) первом блокчейне.
Иногда добавляется частичная поддержка обмена сообщениями путем стандартизации формата сообщений и расположения очередей входных и выходных сообщений в блоках всех воркчейнов (это особенно полезно в гетерогенных системах). Хотя это в определенной степени облегчает обмен сообщениями, концептуально он не слишком отличается от предыдущего случая, поэтому такие системы все еще являются «слабо-связанными».
Напротив, «тесно-связанные» системы включают специальные механизмы для обеспечения быстрого обмена сообщениями между всеми блокчейнами. Желаемое поведение — иметь возможность доставить сообщение в другой воркчейн сразу после того, как оно было сгенерировано в блоке исходного блокчейна. Также ожидается, что «тесно-связанные» системы будут в целом оставаться непротиворечивыми в случае форков. Хотя на первый взгляд эти два требования кажутся противоречащими друг другу, мы полагаем, что механизмы, использующиеся в блокчейне TON (включение хэшей блоков шардчейна в блоки мастерчейна; использование «вертикальных» блокчейнов для исправления невалидных блоков; маршрутизация в гиперкубе; мгновенная маршрутизация в гиперкубе) делают ее «тесно-связанной» системой (возможно, пока единственной в своем роде).
Конечно, построить «слабо-связанную» систему намного проще; однако быстрый и эффективный шардинг требует, чтобы система была «тесно-связанной».
Упрощенная классификация
Поколения блокчейн-проектов. Предложенная нами классификация разбивает все блокчейн-проекты на большое количество классов. Однако на практике критерии классификации, которые мы используем, довольно сильно коррелируют между собой. Это позволяет нам предложить упрощенный «поколенческий» подход к классификации блокчейн-проектов как очень грубое приближение к реальности с некоторыми примерами. Проекты, которые еще не реализованы и не развернуты, выделены курсивом; жирным выделены наиболее важные характеристики поколения.
• Первое поколение: Сингл-чейн, PoW, нет поддержки смарт-контрактов. Примеры: Bitcoin (2009) и множество других не интересующих нас подражателей (Litecoin, Monero, …).
• Второе поколение: Сингл-чейн, PoW, поддержка смарт-контрактов. Пример: Ethereum (2013; развернут в 2015), по крайней мере в его оригинальной форме.
• Третье поколение: Сингл-чейн, PoS, поддержка смарт-контрактов. Пример: будущий Ethereum (2018 или позднее).
• Альтернативное третье (3′) поколение: Мульти-чейн, PoS, нет поддержки смарт-контрактов, слабо-связан. Пример: Bitshares (2013–2014; использует DPOS).
• Четвертое поколение: Мульти-чейн, PoS, поддержка смарт-контрактов, слабо-связан. Примеры: EOS (2017; использует DPOS), PolkaDot (2016; использует BFT).
• Пятое поколение: Мульти-чейн, PoS и BFT, поддержка смарт-контрактов, тесно-связан, с шардингом. Примеры: TON (2017).
Хотя не все блокчейн-проекты попадают в одну из этих категорий, большинство из них относится к одной из этих категорий.
2.8.16. Сложности изменения «генома» блокчейн-проекта. Приведенная выше классификация определяет «геном» блокчейн-проекта.
Этот геном достаточно «жесткий»: его практически невозможно изменить, как только проект развернут и используется большим количеством людей. Потребуется серия хард-форков (что потребует одобрения большинства сообщества), и даже в этом случае изменения должны быть очень консервативными, чтобы сохранить обратную совместимость (например, изменение семантики виртуальной машины может сломать существующие смарт-контракты). Альтернативой было бы создание новых «сайдчейнов» с разными правилами и их привязка каким-либо образом к блокчейну (или блокчейнам) исходного проекта. Можно использовать блокчейн существующего синглчейн-проекта в качестве внешнего мастерчейна для принципиально нового и отдельного проекта.
Мы пришли к выводу, что геном проекта очень сложно изменить после его развертывания. Даже начать с PoW и планировать его замену на PoS в будущем – это довольно сложная задача. Добавление шардов в проект, изначально созданный без их поддержки, кажется практически невозможным29. Фактически, добавление поддержки смарт-контрактов в проект (а именно, Биткоин), изначально разработанный без поддержки таких функций, было сочтено невозможным (или, по крайней мере, нежелательным для большей части сообщества Биткоин) и в конечном итоге привело к созданию нового блокчейн-проекта — Эфириума.
Геном блокчейна TON
Следовательно, если кто-то хочет создать масштабируемую блокчейн-систему, нужно тщательно выбирать ее геном с самого начала. Если система предназначена для поддержки некоторых дополнительных конкретных функций в будущем, неизвестных на момент ее развертывания, она должна изначально поддерживать «гетерогенные» воркчейны (с потенциально разными правилами). Чтобы система была действительно масштабируемой, она должна поддерживать шардинг с самого начала; шардинг имеет смысл только в том случае, если система «тесно-связана», а это, в свою очередь, подразумевает наличие мастерчейна, быстрой системы обмена сообщениями между блокчейнами, использование BFT PoS и так далее.
Если принять всё это во внимание, большинство дизайнерских решений, сделанных для блокчейн-проекта TON, кажутся естественными и почти единственно возможными.
Например, в проекте Plasma планируется использование блокчейна Ethereum в качестве (внешнего) мастерчейна; в противном случае он мало взаимодействует с Ethereum, и он мог быть предложен и реализован командой, не связанной с проектом Ethereum.
28 По состоянию на 2017 год Ethereum все еще пытается перейти от PoW к комбинированной системе PoW+PoS; мы надеемся, что когда-нибудь Ethereum станет настоящей системой PoS.
Предложения по шардингу в Ethereum появились еще в 2015 году; неясно, как их можно реализовать и развернуть, не нарушая работы Ethereum и не создавая по существу независимого параллельного проекта.
