Gold Блокчейн на самом деле представляет собой набор и реестр блокчейнов (будет уточнено в 2.1.17), потому что ни один обычный блокчейн не способен достичь цель обработки миллионов транзакций в секунду, в отличие от существующего сегодня стандартного блокчейн, где скорость транзакций не превышает десятка в секунду.

2.1.1. Список типов блокчейнов. Представляем :

• Уникальный мастер-блокчейн или мастерчейн masterchain, содержащий общую информацию о протоколе и текущие значения его параметров, набор валидаторов и их доли, набор активных рабочих цепей в настоящее время и их «сегменты», а главное, набор хэшей последних блоков всех цепей и сегментов.

• Несколько (до 2³²) рабочих цепочек, уокчейн workchains для краткости, являются «рабочими лошадками», содержащими передачу стоимости умного контракта сделки. Различные рабочие цепи могут иметь разные «правила», что означает различные форматы адресов учетной записи, различные форматы транзакции, разные виртуальные машины для смарт- контрактов, разные основные криптовалюты и прочее. Однако все они должны удовлетворять некоторым базовым критериям функциональной совместимости для взаимодействия между различными рабочими местами и должны быть относительно просты. В этом отношении Gold Blockchain является неоднородным гетерогенным (см. 6.1.8), аналогично EOS (см. 6.2.7) и проекту PolkaDot (см. 6.2.8).

• Каждая рабочая цепочка, в свою очередь, подразделяется до 2⁶⁰ сегментов блока, или shardchains для краткости, имея те же правила и формат блока, что и сама рабочая цепочка, но отвечает только за учетные записи, в зависимости от нескольких первых (наиболее значительных) битах адреса учетной записи аккаунта. Другими словами, в систему встроена форма сегментирования (см. 6.1.12). Поскольку все эти сегменты имеют общий формат и правила блока, AUR Blockchain в этом отношении однороден (см. 6.1.8), аналогично тому, что обсуждалось в одном из предложений по масштабированию Ethereum.¹

1 https: //github.com/ethereum/wiki/wiki/Sharding-FAQ

• Каждый блок в shardchain (и в masterchain) на самом деле не просто блок, а небольшой блокчейн. Обычно этот «блокчейн» или «вертикальный блокчейн» состоит из ровно одного блока, а затем мы можем подумать, что это всего лишь соответствующий блок shardchain (также называемый «горизонтальный блокчейн» в этой ситуации). Однако, если это становится необходимым для исправления некорректных блоков shardchain, новый блок фиксируется в «вертикальный блокчейн», содержащий либо замену недействительного блока «горизонтальный блокчейн» или «разность блоков», содержащий только описание тех частей предыдущей версии этого блока, которые необходимо изменить. Это специфический механизм для замены обнаруженных недопустимых блоков, без создания истинной развилки всех сегментов; это будет объяснено более подробно в 2.1.17. Пока что мы просто отметим, что каждый сегмент shardchain  (и masterchain) не является обычным блокчейн, он блокчейн бокчейнов или 3D-блокчейн.

2.1.2. Бесконечная парадигма. Почти все блокчейн предложения сегментирования являются «нисходящими» : сначала представляется один блокчейн, а затем обсуждается как разделить его на несколько взаимодействующих сегментов для повышения производительности и масштабируемости. Подход Gold Digital к сегментированию «снизу вверх» объясняется следующим образом. Представьте, что сегмент был доведен до предела, так что ровно одна учетная запись или смарт-контракт остается в каждой shardchain. Тогда у нас есть огромное количество «цепочек-счетов», каждая из которых описывает состояние и переходы состояний только одной учетной записи и отправляет ценные сообщения друг другу со стоимостью передачи и информацией. Конечно, нецелесообразно иметь сотни миллионов блоков, с обновлениями (т. е. новыми блоками), которые обычно появляются довольно редко в каждом из их. Чтобы более эффективно реализовать их, мы группируем эти «учетные записи» в сегменты, так чтобы каждый блок sharding по существу являлся сбором учетных записей-цепочки, которые были назначены этому сегменту. Таким образом, «учетные цепочки» имеют только чисто виртуальное или логическое существование внутри «сегментов». Мы называем эту перспективу бесконечной парадигмой сегментирования. Это объясняет многие проектные решения для Gold Блокчейн.

2.1.3. Сообщения. Мгновенная маршрутизация Гиперкуб. Бесконечная Парадигма сегментирования инструктирует нас рассматривать каждую учетную запись (или смарт-контракт), как если бы она была сама по себе. Тогда единственный способ, которым могла бы одна учетная запись влиять на состояние другой, отправлять сообщения (это специальный экземпляр так называемой модели Актера со счетами как Актеры. Поэтому система сообщений между учетными записями (и shardchains, потому что исходные и целевые учетные записи, вообще говоря, расположены в разных shardchains) имеет первостепенное значение для масштабируемой системы, такой как Gold Блокчейн. На самом деле, новая особенность Gold Блокчейн, называемая мгновенная маршрутизация Гиперкуб , позволяет доставлять и обрабатывать сообщение, созданное в блоке одной shardchain, в самый следующий блок не относящийся к общему количеству сегментов в системе.

2.1.4. Количество masterchains, workchains и shardchains. Gold Блокчейн содержит ровно один masterchain. Однако система может вместить до 2³² workchains, каждая из которых подразделяется на до 2⁶⁰ shardchains сегментов.

2.1.5. Workchains могут быть виртуальными блокчейн, но не истинными блокчейн. Поскольку workchain подразделяется на shardchains, существование workchain является "виртуальным", что означает, что это не истинный блокчейн в смысле общего определения, приведенного ниже, а просто реестр из shardchains сегментов. Когда только один shardchain сегмент соответствует workchain, этот уникальный shardchain может быть идентифицирована с workchain, который в этом случае становится «истинным» блокчейном, по крайней мере в течение некоторого времени, тем самым получая супер-схожесть с обычным одноцепочным блокчейном. Однако Бесконечная Парадигма Сегментирования (см. 2.1.2) говорит нам, что это сходство действительно суперфиальное: это просто совпадение, потому что потенциально огромное количество «учетных записей», может временно быть сгруппировано в одну цепь и один блокчейн.

2.1.6. Идентификация рабочих цепей workchains. Каждый workchain идентифицируется своим номером или идентификатором рабочей цепочки (workchain_id: uint32), который является просто неподписанное 32-битное целое число. Рабочие места Workchains создаются специальными транзакциями в masterchain, определяя (ранее не используемый) идентификатор рабочей цепи и формальное описание рабочей цепочки workchain, достаточное, по крайней мере, для взаимодействия этой рабочей цепи с другими рабочими целями и для поверхностной проверки этого блока workchain.

2.1.7. Создание и активация новых рабочих мест. Создание новой рабочей цепи workchain может быть инициирована практически любым членом сообщества, кто готов заплатить (высокую) комиссию за совершение сделки в masterchain, требуемую для публикации формальной спецификации новой рабочей цепочки. Однако для того, чтобы новая рабочая цепь workchain, стала активной, требуется согласие двух третей валидаторов, потому что им нужно будет обновить свое программное обеспечение для обработки блоков нового workchain и заявить о своей готовности работать с новой рабочей цепью workchain по особой сделке с masterchain. Сторона, заинтересованая в активизации новой рабочей цепочки workchain может обеспечить стимул для валидаторов для поддержки новой рабочей цепи workchain посредством некоторых вознаграждений, распределяемых по смарт-контракту.

2.1.8. Идентификация сегментов. Каждый сегмент идентифицируется парой (w, s) = (workchain_id, shard_prefix), где workchain_id: uint32 идентифицирует соответствующий workchain рабочую цепочку, а сегмент shard_prefix: 2^{0 ... 60} битная строка длиной не более 60, определяет подмножество учетных записей, для которых этот сегмент shardchain несет ответственность. А именно, все учетные записи с account_id, начиная с shard_prefix (т. е. с shard_prefix, как наиболее значимых битов) будут приписаны к этому сегменту цепи.

2.1.9. Идентификация учетных записей-цепей. Напомним, что сети учетных записей имеют виртуальное существование (см. 2.1.2). Однако они имеют естественный идентификатор, а именно: (workchain_id, account_id), поскольку любая цепочка учетных записей содержит информация о состоянии и обновлениях только одного аккаунта (либо простая учетная запись или смарт-контракт,  различие здесь не важно).

2.1.10. Динамическое расщепление и слияние сегментов; см. 2.4. Менее сложная система может использовать статическое сегментирование - например, используя верхние восемь бит account_id, чтобы выбрать один из 256 предварительно определенных сегментов. Важной особенностью Gold Blockchain является то, что он реализует динамические сегментирование и это означает, что количество сегментов цепи не фиксировано. Сегмент shard (w, s) можно автоматически подразделить на сегменты (w, s.0) и (w, s.1), если выполняются некоторые формальные условия (по существу, если транзакционная нагрузка на первоначальный сегмент достаточно высока в течение длительного периода времени). Наоборот, если нагрузка остается слишком низкой в течение некоторого периода времени, сегменты (w, s.0) и (w, s.1) можно автоматически объединить обратно в сегмент (w, s). Первоначально для рабочей цепочки workchain w создается только один сегмент (w, ∅). Позже это подразделяется на большое количество сегментов (осколков), когда это становится необходимым (см. 2.4.6 и 2.4.8).

2.1.11. Основная рабочая цепь workchain или Workchain Zero. В то время как до 2³² рабочих цепей workchain могут быть определены с их конкретными правилами и транзакциями, мы изначально определяем только один, с workchain_id = 0. Эта рабочая цепь, называемая Workchain Zero или основная рабочая цепь, является той, которая используется для работы с Gold смарт-контрактами и передает монеты Gold, известные как AUR (см. Приложение A). Большинству приложений, вероятно потребует только Workchain Zero. Сегменты основного workchain будут называться базовыми shardchains.

2.1.12. Интервалы генерации блоков. Мы ожидаем, что новый блок будет создан в shardchain и masterchain примерно раз в пять секунд. Это приведет к разумно малому времени подтверждения транзакций. Новые блоки всех сегментов генерируются примерно одновременно; новый блок masterchain генерируется примерно через секунду, потому что он должен содержать хэши последних блоков всех сегментов.

2.1.13. Использование мастерской masterchain для создания цепей workchains и сегментов shardchains тесно связаны. После включения хэша блока shardchain в блок цепь masterchain, этот блок shardchain и все его предки считаются «каноническими», что означает, что на них можно ссылаться из последующего блока всех сегментов, как на нечто фиксированное и неизменное. По факту, каждый новый блок shardchain содержит хэш из последнего блока masterchain и все блоки shardchain, на которые ссылается этот блок основной цепи masterchain, считаются неизменным к новому блоку. По сути, это означает, что транзакция или сообщение, совершенные в блок shardchain можно безопасно использовать в самых следующих блоках другого shardchains, без необходимости ждать, скажем, 20 подтверждений (т. е. двадцать блоков, сгенерированных после исходного блока в той же цепочке блоков) до пересылки сообщения или принятия других действий на основе предыдущей транзакции, как это принято в большинстве предложенных «слабосвязанных» систем (см. 6.1.14), таких как EOS. Эта способность использовать транзакции и сообщения в других сегментах всего через пять секунд после их совершения, является одной из причин, по которым мы утверждаем, что наша система «плотно связанная», первая в своем роде, сможет обеспечить беспрецедентную производительность (см. 6.1.12 и 6.1.14).

2.1.14. Хеш блока Masterchain как глобальное состояние. Согласно п. 2.1.13, хэш последней блочной цепи полностью определяет общее состояние системы с точки зрения внешнего наблюдателя. Не нужно следить за состоянием всех сегментов shardchains отдельно.

2.1.15. Генерация новых блоков с помощью валидаторов; см. 2.3. Gold Blockchain использует подход доказательство доли (PoS) для генерации новых блоков в сегменты shardchains и основной masterchain. Это означает, что существует набор, скажем, до нескольких сотен валидаторов - специальных узлов, которые депонировали доли (большое количество монет AUR) с помощью специальной сделки с masterchain для получения прав на создание и проверку нового блока. Затем каждому сегменту (w, s) присваивается меньшее подмножество валидаторов в детерминированный псевдослучайный путь, изменяющийся примерно каждые 1024 блока. Это подмножество валидаторов предлагает и достигает консенсуса относительно того, чтобы следующий блок shardchain был создан, собирая подходящие предлагаемые транзакции от клиентов о новых действительных кандидатах блока. Для каждого блока существует псевдослучайно выбранный порядок на валидаторах, чтобы определить, какой кандидат блока имеет наивысший приоритет, который необходимо совершать на каждом шагу. 

Валидаторы и другие узлы проверяют действительность предложенных кандидатов блока; если валидатор подписывает недопустимого кандидата блока, он может быть автоматически наказан потерей части и всей его доли или отстранением от набора валидаторов в течение некоторого времени. После этого валидаторы должны достичь консенсуса на выбор следующего блока, по существу, эффективным вариантом BFT (Византийский отказ от толерантности, см. 6.1.4), согласованный протокол, аналогичный PBFT [4] или Honey Badger BFT [11]. Если консенсус достигнут, создается новый блок, а валидаторы разделяют между собой транзакционные сборы, включая транзакции, а также некоторые недавно созданные («отчеканенные») монеты. Каждый валидатор может быть избран для участия в нескольких подмножествах валидаторов; в этом случае ожидается выполнение всех алгоритмов проверки и согласования, параллельных друг другу. После того, как будут созданы новые блоки shardchain или пройден тайм-аут, генерируется новый блок masterchain, включая хэши последних блоков всех сегментов. Это делается консенсусом BFT всех валидаторов.² Более подробная информация о подходе Gold PoS и его экономической модели предоставлена в разделе 2.3.

2 Фактически, двух третей по ставке достаточно для достижения консенсуса, однако предпринимаются усилия для сбора как можно большего количества подписей

2.1.16. Форки (вилки) masterchain. Усложнение, которое возникает из нашего жестко связанного подхода заключается в том, что переход на другой форк в masterchain почти обязательно потребует перехода на другой форк некоторых из сегментов shardchains. С другой стороны, до тех пор, пока нет вилок в мастерской цепи masterchain, никакие вилки в shardchain даже не возможны, потому что нет блоков в альтернативных вилках сегментов shardchain, которые могут стать «каноническими» с их хешами, включенными в masterchain. Общее правило состоит в том, что если masterchain блок B0 является предшественником B, B0 включает хеш Hash (B0 w, s) блока (w, s) – сегмент shardchain B0 w, s и B включает хэш Hash (B w, s), то B0 w, s должен быть предшественником B w, s; в противном случае блок masterchain B недействителен. Мы ожидаем, что вилки-манипуляторы будут редкими, рядом с несуществующими, потому что в парадигме BFT, принятой Gold Blockchain, они могут случиться только в случае неправильного поведения большинства валидаторов (см. 2.3.1 и 2.3.15), что будет означать значительные потери со стороны правонарушителей. Поэтому не следует ожидать истинных вилок в сегментах shardchains. Если обнаружен недействительный блок shardchain, он будет исправлен с помощью механизма «вертикальный блокчейн» 2-блокчейн (см. 2.1.17), который может достичь этой цели без наложения «горизонтального блокчейн» (т. е. shardchain). Тот же механизм может быть использован для устранения некритических ошибок в блоке masterchain.

2.1.17. Исправление недействительных блоков shardchain. Обычно только действительные shardchain блоки могут быть созданы, поскольку валидаторы, назначенные shardchain должны достичь двух третей византийского консенсуса перед созданием нового блока. Однако система должна позволять обнаруживать ранее совершенные недействительные блоки и их исправление. Конечно, как только недействительный блок shardchain найден - либо валидатором (не обязательно этой shardchain) или «рыбаком» (любой узел системы, который сделал определенный депозит, чтобы иметь возможность задавать вопросы о действительности блока; см. 2.3.4),  подается заявление о недействительности и его доказательство в masterchain, а валидаторы, которые подписали недопустимый блок наказываются потерей части их доли и / или временным приостановлением работы из набора валидаторов (последняя мера важна для случая, когда злоумышленник крадет личные ключи подписи другого доброкачественного валидатора). Однако этого недостаточно, поскольку состояние общей системы (Gold Blockchain) оказывается недействительным из-за недействительного сегмента shardchain. Этот недопустимый блок должен быть заменен новым блоком действительной версии. В большинстве систем это достигается путем «отката» до последнего блока, стоящим перед недействительным в этой shardchain и последние блоки, не затронутые сообщениями, распространяются из недействительного блока в каждом из других сегментов shardchains и создают новую вилку из этих блоков. Такой подход имеет недостаток, что большое количество других правильных и совершенных транзакций внезапно сделают откат, и неясно, будут ли они включены позже. 

Gold Blockchain решает эту проблему, делая каждый «блок», каждый сегмент shardchain и masterchain («горизонтальные блокчейны») малым блокчейном («вертикальный блкчейн»), содержащим разные версии этого «блока» или их «различия». Обычно вертикальный блокчейн состоит ровно из одного блока, а сегмент shardchain выглядит как классический блокчейн. Однако, как только недействительность блока подтверждается и передается в masterchain, «вертикальный блокчейн» недопустимого блока допускает рост новых блоков в вертикальном направлении, заменяя или редактируя недействительный блок. Новый блок генерируется текущим подмножеством валидаторов для сегмента shardchain. Правила для нового «вертикального» блока должны быть достаточно строгими. В частности, если виртуальная «блок цепочка учетных записей» (см. 2.1.2), содержащаяся в недействительном блоке действительна сам по себе, она должна оставаться неизменной с помощью нового вертикального блока. Как только новый «вертикальный» блок создается над недопустимым блоком, его хэш публикуется в новом блоке masterchain (или, скорее, в новом «вертикальном» блоке, лежащим над исходным блоком masterchain, где хэш недействительного блок shardchain был первоначально опубликован) и изменения распространяются далее к любым блокам shardchain, относящимся к предыдущей версии этого блока (например, те, которые получили сообщения от неправильного блока). 

Это исправлено путем ввода новых «вертикальных» блоков в вертикальные блокчейны для всех блоков, имеющих ссылку на «неправильный» блок; новые вертикальные блоки будут ссылаться к последним (исправленным) версиям. Опять же, строгие правила запрещают изменение цепочки учетных записей, которые на самом деле не затронуты (то есть, которые получают те же сообщения, что и в предыдущей версии). Таким образом, исправление неверного блока генерирует «рябь», которая в конечном итоге распространяется по большей части на последние блоки всех затронутых сегментов; эти изменения отражены в новых «вертикальных» блокчейнах. После того, как рябь «переписывания истории» достигнет самых последних блоков, новый Блоки сегментов генерируются только в одной версии, являясь преемниками только самых новых версий блоков. Это означает, что они будут содержать ссылки на правильные (самые последние) вертикальные блоки с самого начала. Состояние мастер-цепи masterchain неявно определяет карту, преобразующую хэш первого блока каждого «вертикального» блокчейна в хэш своей последней версии. Это позволяет клиенту идентифицировать и найти любой вертикальный блокчейн с помощью хэш его самого первого (и обычно единственного) блока.

2.1.18. Gold и мульти-валютные рабочие цепи workchains .

Gold Blockchain поддерживает до 2³² разных «криптовалют», «монет» или «токенов», отличающихся 32-битным currency_id. Можно добавить новые криптовалюты по специальным сделкам в мастерской masterchain. Каждая рабочая цепочка workchain имеет базовую криптовалюту и может иметь несколько дополнительных криптовалют. Существует одна специальная криптовалюта с currency_id = 0, а именно: Gold, также известная как AUZ (см. Приложение A). Это базовая криптовалюта Workchain Zero. Она также используется для оплаты транзакций и ставок валидаторов. В принципе, другие рабочие места workchains могут взимать комиссию за транзакции в других токенах. В этом случае должны быть предоставлены некоторые смарт контракты на автоматическое преобразование этих транзакционных сборов в AUZ.

2.1.19. Передача сообщений и перенос значений. Cегменты Shardchains, принадлежащие одним и тем же или разным рабочим цепям workchains могут отправлять сообщения друг другу. Точная форма разрешенных сообщений зависит от получающей рабочей цепи workchain и принимающей учетной записи (смарт-контракта), существуют некоторые общие поля возможных сообщений между рабочими цепями workchain. В частности, каждое сообщение может иметь некоторую ценность в виде определенного количества монет АUZ и / или других зарегистрированных криптовалют, если они объявлены приемлемыми криптовалютами для получающей рабочей цепи workchain. Простейшей формой такого обмена сообщениями является перенос стоимости от одного аккаунта другому.

2.1.20. Виртуальная машина Gold. Виртуальная машина Gold, также сокращенно как Gold VM или GVM, является виртуальной машиной, используемой для выполнения кода смарт-контракта в основной цепи masterchain и в основной рабочей цепи workchain. Другие рабочие цепи workchains могут использовать другие виртуальные машины вместо GVM. Здесь перечислены некоторые из ее функции. Они рассматриваются в других местах.

• GVM представляет все данные, как набор ячеек (GVM). Каждая ячейка содержит до 128 байтов данных и до 4 ссылок на другие ячейки. Как следствие философии «пакет ячеек» (см. 2.2.14), это позволяет GVM работать со всеми данными, относящимися к Gold Blockchain, включая блоки и глобальное состояние блокчейн, если это необходимо.

• GVM может работать со значениями произвольных типов алгебраических данных , представленных как деревья или направленные ациклические графы GVM-клеток. Однако, это агностик к существованию алгебраических типов данных; он просто работает с ячейками.

• GVM имеет встроенную поддержку для всех хэш-карт.

• GVM - это стековый компьютер. Его стек хранит либо 64-битные целые числа, либо ячейку.

Рекомендации.

• Поддерживается 64-разрядная, 128-битная и 256-разрядная арифметика. Все n-разрядные арифметические операции выполняются в трех вариантах: для целых чисел без знака, для целых чисел со знаком и для целых чисел по модулю 2 N (отсутствие автоматических проверок переполнения в последнем случае).

•  GVM имеет неподписанные и подписанные преобразования целого числа из n-бит в m-разрядный, для всех 0 ≤ m, n ≤ 256, с проверками переполнения.

• Все арифметические операции выполняют проверку переполнения по умолчанию, в значительной степени упрощая разработку смарт-контрактов.

• GVM имеет арифметические операции «умножение-тогда-сдвиг» и «сдвиг-потом-деление» с промежуточными значениями, вычисленными в более крупном целочисленном типе; это упрощает реализацию арифметики с фиксированной точкой.

• GVM предлагает поддержку битовых строк и байтовых строк.

• Поддержка 256-битной криптографии с эллиптическими кривыми (ECC) для некоторых предопределенных кривых, включая Curve25519.

• Поддержка спаривания Вейля на некоторых эллиптических кривых, полезных для быстрой реализации zk-SNARKs, также присутствует.

• Поддержка популярных хеш-функций, включая sha256, присутствует.

• GVM может работать с доказательствами Merkle.

• GVM предлагает поддержку «больших» или «глобальных» смарт-контрактов. Такие смарт- контракты должны быть осведомлены о сегментировании . Обычные (местные) смарт-контракты могут быть сегментно-агностическими.

• GVM поддерживает замыкания.

• «Бесконечная безгалогенная G-машина» [13] может быть легко реализована внутри GVM.  Несколько языков высокого уровня могут быть разработаны для GVM, в дополнение к «GVM -сборке». Все эти языки будут иметь статические типы и будут поддерживать алгебраические типы данных. Мы предполагаем следующие возможности:

• Java-подобный императивный язык с каждым смарт контрактом, напоминающим отдельный класс.

• ленивый функциональный язык (подумайте о Haskell).

• Желающий функциональный язык (подумайте о ML).

2.1.21. Настраиваемые параметры. Важной особенностью Gold Blockchain - это то, что многие из его параметров настраиваются. Это значит, что они являются частью основной цепи masterchain  и могут быть изменены некоторыми специальными предложениями /голосования / в состояние masterchain, без какой-либо необходимости хардфорка (жестких вилок). Изменение таких параметров потребует сбора двух третей голосов валидаторов и более половины голосов всех других участников, которые хотели бы принять участие в процессе голосования в пользу этого предложения.

Глобальное состояние цепи сегментов Shardchain. Философия «Пакет ячеек». Теперь мы готовы описать глобальное состояние Gold Блокчейн или наименьшей из сегментов цепи shardchain основной рабочей цепи workchain. Мы начинаем с «высокого уровня» или «логического» описания, которое говорит, что глобальное состояние является значением алгебраического типа структуры Shardchain.

2.2.1. Состояние Shardchain как совокупность состояний учетной записи. В соответствии с Бесконечной Парадигме Сегментирования (см. 2.1.2), любой shardchain просто (временный) набор виртуальных «цепочек счетов», содержащий каждый ровно один счет. Это означает, что, по сути, глобальное состояние shardchain должно быть хэш-картой

ShardchainState: = (Account → AccountState) (23)

где все account_id, отображаемые как индексы этой хэш-карты, должны начинаться с prefix s, если мы обсуждаем состояние сегмента (w, s) (см. 2.1.8). На практике нам может потребоваться разделить AccountState на несколько частей (например, сохранить отдельную очередь выходных сообщений учетной записи для упрощения ее проверки соседними shardchains), и иметь несколько хэш-карт (счет → Часть Состояния Счета_i) внутри структуры Shardchain. Мы могли бы также добавить небольшой число «глобальных» или «интегральных» параметров в структуры Shardchain (например, общий баланс всех счетов, принадлежащих этому сегменту, или общее количество сообщений во всех выходных очередях). Однако (23) является хорошим первым приближением того, что глобальное shardchain состояние похоже, по крайней мере, с точки зрения «логического» («высокого уровня»). Формальное описание алгебраических типов AccountState и ShardchainState можно сделать с помощью TL-схемы , которая должна быть предоставлена в другом месте.

2.2.2. Разделение и слияние состояний shardchain. Обратите внимание, что Бесконечная Парадигма Сегментирования описания состояния shardchain (23) показывает, как это состояние должно обрабатываться при разделении или слиянии сегментов. Фактически, эти преобразования состояний оказываются очень простыми операциями с хэш-картами.

2.2.3. Состояние учетной записи. Состояние (виртуальное) учетной записи - это просто состояние одной учетной записи, описываемое типом Account Состояние. Обычно он имеет все или некоторые из полей,  в зависимости от конкретного используемого конструктора.

2.2.4. Глобальное рабочее состояние workchain. Аналогично (23), мы можем определить глобальное состояние рабочей цепи workchain по той же формуле, но с учетом учетной записи account_id - любые значения, а не только те, которые принадлежат одному сегменту. Замечания, сделанные в 2.5.1, применимы и в этом случае: мы можем разбить эту хэш-карту в несколько хэш-карт и мы могли бы захотеть добавить некоторые «интегральные» параметры, такие, как общий баланс. По сути, глобальное рабочее состояние workchain должно быть задано одним и тем же типом состояния Shardchain, как состояние shardchain, потому что это состояние shardchain мы бы получили, если бы все существующие сегменты этой рабочей цепи workchain внезапно слились в один.

2.2.5. Низкоуровневая перспектива: «пакет ячеек». Существует описание «низкого уровня» состояния учетной записи или сети shardchain, которое дополняет приведенному выше «высокоуровневое» описание. Это описание очень важно, потому что оно оказывается довольно универсальным, обеспечивая общую основу для представления, хранения, сериализации и передачи по сети почти всех данных, используемых Gold Blockchain (блоки, состояния shardchain, смарт-контракты хранения, доказательства Merkle и т. д.). В то же время такое универсальное "низкоуровневое" описание, понятное и реализованное, позволяет нам сконцентрировать наше внимание только на «высоком уровне». Напомним, что GVM представляет значения произвольных алгебраических типов (включая, например, ShardchainState  (23)) с помощью дерева GVM ячеек или ячеек для краткости . Любая такая ячейка состоит из двух байтов дескриптора, определяющ их определенные флаги и значения 0 ≤ b ≤ 128, количество необработанных байтов и 0 ≤ c ≤ 4, количество ссылок на другие ячейки. Затем следуют b необработанные байты и c-ссылки на ячейки.¹⁷ Точный формат ссылок на ячейки зависит от реализации и находится ли ячейка в ОЗУ, на диске, в сетевом пакете, в блоке, и так далее. Полезная абстрактная модель состоит в том, чтобы представить, что все ячейки хранятся в адресной памяти, адрес ячейки, равен ее (sha256) хэш. 

Напомним, что хэш (Merkle) ячейки вычисляется точно путем замены ссылок на его дочерние ячейки их (рекурсивно вычисленными) хешей и хэшированием полученной байтовой строки. Таким образом, если мы используем хеши клеток для ссылки на ячейки (например, внутри описания других ячеек), система несколько упрощается и начинается хэш ячейки для совпадения с хешем строки байта, представляющей его. Теперь мы видим, что любой объект, представленный GVM, глобальный shardchain включенное состояние, может быть представлен как «пакет ячеек» - набор ячеек наряду с «корневой» ссылкой на одну из них (например, с помощью хэша). Дублирующие ячейки удаляются из этого описания («пакет ячеек» является набором ячеек, а не мультимножеством ячеек), поэтому представление абстрактного дерева может фактически становится ориентированным ациклическим графиком (dag). Можно даже сохранить это состояние на диске в B- или B + дереве, содержащем все (возможно, с некоторыми дополнительными данными, такими как высота поддерева или счетчик ссылок), индексированные хешем ячейки. Однако наивная реализация этой идеи приведет к разложению состояния одного смарт контракта среди удаленных частей файла диска, чего мы предпочли бы избежать.¹⁸ Теперь мы подробно объясним, как почти все объекты, используемые Gold Blockchain могут быть представлены, как «пакеты ячеек», что демонстрирует универсальность этого подхода.

17 Можно показать, что если необходимы доказательства Merkle для всех данных, хранящихся в дереве ячеек, одинаково часто следует использовать ячейки с b + ch ≈ 2 (h + r), чтобы минимизировать среднее значение Merkle доказательство размера, где h = 32 - размер хэша в байтах, а r ≈ 4 - «размер байта» ссылка на ячейку. Другими словами, ячейка должна содержать либо две ссылки и несколько необработанных байтов, либо одну ссылку и около 36 необработанных байтов или вообще не ссылаться на 72 необработанных байта.

18 Лучшая реализация заключается в том, чтобы сохранить состояние смарт-контракта, как сериализованную строку, если она небольшая, или в отдельном B-дереве, если она большая; структура верхнего уровня, представляющее состояние блокчейна, будет B-деревом, листья которого разрешены и содержат ссылки на другие B-деревья.

2.2.6. Блок Shardchain, как «пакет ячеек». Сам блок shardchain может быть также описан алгебраическим типом и хранится как «мешок ячеек». Тогда наивное двоичное представление блока может быть получено просто объединением строк байтов, представляющих каждую из ячеек в «мешке ячеек», в произвольном порядке. Это представление может быть улучшено и оптимизировано, например, путем предоставления списка смещений всех ячеек в начале блока и замену хеш-ссылок на другие ячейки с 32-разрядными индексами в этом списке, когда это возможно. Однако следует предположить, что блок по существу, является «пакетом ячеек», а все остальные технические детали – это вопросы оптимизации и реализации.

2.2.7. Обновление объекта, как «пакета ячеек». Представьте, что у нас есть старая версии какого-либо объекта, представленного как «пакет ячеек» и что мы хотим представление новой версии того же объекта, предположительно не слишком отличающейся от предыдущего. Можно просто представить новое состояние как другой «пакет ячеек» с собственным корнем и удалить из него все ячейки, происходящие из старой версии. Оставшийся «пакет ячеек» является обновлением объекта. Точнее, есть старая версия этого объекта, обновление может вычислить новую версию, объединит два пакета ячеек и удалит старый корень (уменьшение его счетчика ссылок и выделение, если контрольный счетчик становится нулевым).

2.2.8. Обновление состояния учетной записи. Обновления состояния учетной записи или глобального состояния shardchain или любого хранилища хэш-карты может быть представлено с использованием идеи, описанной в 2.2.7. Это означает, что когда мы получаем новый блок shardchain (который является «пакетом ячеек»), мы интерпретируем этот «пакет ячеек» не только сам по себе, но объединяем его сначала с «пакет ячеек», представляющем предыдущее состояние shardchain. В этом смысле каждый блок может «содержать» все состояние блокчейн.

2.2.9. Обновление блока. Напомним, что сам блок является «пакетом ячеек», поэтому, если потребуется отредактировать блок, можно также определить «блок», обновить как пакет ячеек, интерпретируемый в присутствии «пакета ячеек», который является предыдущей версией этого блока. Это пример идеи «вертикальных блоков», рассмотренных в 2.1.17.

2.2.10. Доказательство Меркле как «пакет ячеек». Обратите внимание, что (обобщенно) Доказательство Merkle, например, утверждающее, что x [i] = y, начиная с известного значение Hash (x) = h , также может быть представлено как «пакет ячеек». А именно, просто нужно предоставить подмножество ячеек, соответствующее пути от корня x: Hashmap (n, X) к его желаемому листу с индексом i: 2ⁿ и значение y : X. Ссылки на потомков этих ячеек, не лежащие на этом пути, останутся «неразрешенными» в этом доказательстве, представленном ячейкой хэши. Можно также обеспечить одновременно доказательство Мерке, скажем, x [i] = y и x [i¹] = y¹ , включив в «пакет ячеек» ячейки, лежащие на объединении двух путей от корня x до листьев, соответствующих индексам i и i¹.

2.2.11. Меркл доказательства, как ответы запросов от полных узлов. По сути, полный узел с полной копией состояния shardchain (или учетной записи) может обеспечить доказательство Merkle по требованию легкого узла (например, узла сети, на котором запущена легкая версия клиента Gold Blockchain), позволяя получателю выполнение простых запросов без внешней помощи, используя только ячейки, предоставленные в этом доказательстве Меркле. Легкий узел может отправлять свои запросы в сериализованном формате на полный узел и получать правильные ответы с помощью Доказательства Merkle, поскольку запрос должен быть способен вычислять ответы, используя только ячейки, включенные в доказательство Merkle. Это доказательство Меркле состояло бы просто из «пакета ячеек», содержащем только те ячейки, принадлежащие сегментному состоянию, к которым был получен доступ полному узлу при выполнении запроса легкого узла. Этот подход может быть используем, в частности, для выполнения «запросов на получение» смарт-контрактов.

2.2.12. Расширенное обновление или обновление состояния с помощью обоснованности доказательства Merkle. Напомним (см. 2.2.7), что мы можем описать изменения в объекте из старого значения x: X в новое значение x¹: X посредством «обновления», которое является просто «пакетом ячеек», содержащим те ячейки, которые лежат в поддереве, представляющее новое значение x¹, но не в поддереве, представляющем старое значение x, предполагается, что получатель имеет копию старого значения x и всех его ячеек. Однако, если получатель не имеет полной копии x, но знает только его (Merkle) hash h = Hash (x), он не сможет проверить действительность обновления (все «оборванные» ссылки на ячейки в обновлении относятся к ячейкам, присутствующим в дереве x). Хотелось бы иметь «поддающиеся проверке» обновления, дополненные доказательствами Меркле о существовании всех упомянутых ячеек в старом состоянии. Тогда любой, кто знает только h = Hash (x), сможет проверить правильность обновления и вычислить новый h¹ = Хэш (x¹). Наши доказательства Меркле являются «пакетами ячеек» (см. 2.2.10), кто-то может построить такое расширенное обновление, как «пакет ячеек», содержащий старый корень x, некоторых из его потомков вместе с путями от корня x до их нового корня x¹   и всех его потомков, которые не являются частью x.

2.2.13. Обновления состояния учетной записи в блоке shardchain. В частности, обновления состояния учетной записи в блоке shardchain должны быть дополнены, как обсуждалось в 2.2.12. В противном случае кто-то может зафиксировать блок, содержащий неверное обновление состояния, ссылающееся на ячейку, отсутствующую в старом состоянии; доказать недействительность такого блока была бы проблематичной (как претендент доказывает, что ячейка не является частью предыдущего состояния?). Теперь, если все обновления состояния, включенные в блок, дополняются, их действительность легко проверяется и их недействительность также легко проявляется как нарушение рекурсивного определяющего свойства (обобщенных) хешей Merkle.

2.2.14. Философия «Пакет ячеек». Предыдущие соображения показывают, что все, что нам нужно хранить или передавать, либо в Gold Blockchain или в сеть, представляется в виде «пакета ячеек». Это важная часть философии дизайна Gold Blockchain. Как только «пакет ячеек» и некоторые «низкоуровневые» сериализации «пакета ячеек» определены, можно просто определить все (формат блока, shardchain и состояние счета и прочее) на высоком уровне абстрактной (зависимой) алгебраической тип данных. Объединяющий эффект философии «пакет ячеек» значительно упрощает реализацию, казалось бы, несвязанных услуг.

2.2.15. Блок «заголовки» для Gold Блокчейн. Обычно блок в blockchain начинается с небольшого заголовка, содержащего хэш предыдущего блока, время его создания, хэш Merkle дерева всех транзакций в блоке и т. д. Тогда хеш блока определяется, как хэш этого маленького заголовка блока. Поскольку заголовок блока в конечном счете зависит от всех данных, включенных в блок, нельзя изменять блок без изменения его хэш. В подходе «пакет ячеек», используемом блоками Gold Блокчейн, назначенного заголовка блока нет. Вместо этого хеш блока определяется, как (Merkle) хэша корневой ячейки блока. Следовательно, верхняя (корневая) ячейка блока может считаться небольшим «заголовком» этого блока. Однако корневая ячейка может содержать не все данные, обычно ожидаемые из такого заголовка. По сути, нужно, чтобы заголовок содержал некоторые  поля, определенные в типе данных блока. Обычно эти поля будут содержаться в нескольких ячейках, включая корень. Это ячейки, которые вместе образуют «Доказательство Merkle» для значений рассматриваемых полей. Можно было бы настоять, что блок содержит эти «ячейки заголовка» в самом начале, прежде чем другие ячейки. Затем нужно будет загрузить только первые несколько байтов сериализации блока, чтобы получить все «ячейки заголовка» и изучить все ожидаемые поля.

Gold Блокчейн в конечном итоге состоит из shardchain и masterchain блоков. Эти блоки должны создаваться, проверяться и распространяться через сети для всех заинтересованных сторон, чтобы система функционировала плавно и правильно.

2.3.1. Валидаторы. Новые блоки создаются и проверяются специальными узлы, называемые валидаторами. По существу, любой узел, желающий стать валидатором может стать им, если он может внести достаточно крупную ставку (в монетах AUR, т. е. граммах, см. Приложение A) в мастерчейн. Валидаторы получают некоторые «награды» за хорошую работу, а именно за транзакции, хранение и плату за газ от всех транзакций (сообщений), совершенных в вновь созданных блоках и некоторые недавно отчеканенные монеты, отражающие «благодарность» целого сообщества валидаторам для поддержания работы Gold Blockchain. Этот доход распределяется между всеми участвующими валидаторами пропорционально их cтавкам. Однако быть валидатором - высокая ответственность. Если валидатор подписывает недействительный блок, он может быть наказан путем потери части или всей его доли и путем временного или постоянного исключения из набора валидаторов. Если валидатор не участвует в создании блока, он не получает долю вознаграждения, связанную с этим блоком. Если валидатор воздерживается от создания новых блоков в течение длительного времени, он может потерять часть своей доли и быть приостановлен или окончательно исключен из набора валидаторов. Все это означает, что валидатор не получает свои деньги «ни за что». На самом деле, он должен следить за состоянием всех или некоторых сегментов (каждый валидатор отвечает за проверку и создание новых блоков в определенном подмножество shardchains), выполнять все вычисления, запрошенные интеллектуальными контрактами в этих сегментах, получать обновления о других сегментах и т. д.  Эта деятельность требует значительного дискового пространства, вычислительной мощности и пропускной способности сети.

2.3.2. Валидаторы вместо майнеров. Напомним, что Gold Блокчейн использует подход «Доказательство доли», вместо принятого подхода «Доказательство работы» у Биткоин, текущей версии Эфириум и большинству других криптовалют. Это означает, что нельзя «создать» новый блок, представив некоторые доказательства работы (вычисляя много бесполезных хэшей) и получить новые монеты в результате. Вместо этого нужно стать валидатором, направив свои ресурсы вычисления для хранения и обработки запросов и данных Gold Блокчейн. Нужно быть валидатором для новых монет. В этом отношении валидаторы являются новыми горняками. Однако есть и другие способы заработать монеты, кроме как быть валидатором.

2.3.3. Номинаторы и «майнинг пулы». Чтобы стать валидатором, обычно требуется купить и устанавить несколько высокопроизводительных серверов, а также обеспечить для них хорошее интернет-соединение. Это не так дорого, как оборудование ASIC, которое в настоящее время требуется для добычи биткойнов. Однако, определенно нельзя создавать новые монеты Gold на домашнем компьютере, не говоря уже о смартфоне. В сообществах Биткоин, Эфириум и других криптовалютных инструментах алгоритма «Доказательство работы», существует понятие майнинг пулов, где множество узлов, имеющих недостаточные вычислительные мощности для создания новых блоков самостоятельно, объединяют их усилия и разделяют награду впоследствии.

Соответствующее понятие в мире «Доказательство доли» - это понятие номинатора. По сути, это узел, предоставляющий свои деньги, чтобы помочь валидатору увеличить его ставку (долю); валидатор затем распределяет соответствующую долю своего вознаграждения (или какую-то предварительно согласованную долю, например 50%) номинатору. Номинатор может участвовать в «добыче блоков» и получать вознаграждение пропорционально количеству денег, которое оно хочет внести на эти цели. Он получает только часть соответствующей доли вознаграждение валидатора, поскольку он обеспечивает только «капитал» и не нуждается в покупке вычислительной мощности, хранении и пропускной способности сети. Однако, если валидатор теряет свою долю из-за неправомерного поведения, номинатор также теряет свою долю. В этом смысле номинатор разделяет риск.

Он должен разумно выбирать назначенного валидатора, иначе может потерять деньги. В этом смысле номинаторы принимают взвешенное решение и «голосуют» за некоторых валидаторов за свои средства. С другой стороны, эта система выдвижения или кредитования позволяет стать валидатором, не вкладывая большую сумму денег в (Монеты AUZ). Другими словами, он предотвращает хранение больших количеств AUZ от монополизации поставок валидаторов.

2.3.4. Рыбаки: получают деньги, указывая на ошибки других. Еще один способ получить некоторые награды, не являясь валидатором, - это стать рыбаком. По существу, любой узел может стать рыбаком, делая небольшой депозит в мастерчейн. Тогда он может использовать специальный masterchain транзакции для публикации (Merkle) доказательств недействительности некоторых (обычно shardchain) блоков, ранее подписанных и опубликованных валидаторами. Если другие валидаторы согласны с этим доказательством недействительности, виновные валидаторы наказываются (теряя часть своей доли), а рыбак получает некоторую награду (часть монет, конфискованную у нарушителя валидатора). Корректирующий недопустимые блоки masterchain может включать в себя создание «вертикальных» блоков на вершине ранее совершенных блоков masterchain (см. 2.1.17); нет нужды создать вилку - форк masterchain.

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

2.3.5. Coртировщик: получение денег, предлагая новые блоки для валидаторов. Еще один способ получить некоторые награды, не являясь валидатором, является сортировщик. Это узел, который готовит и предлагает валидатору новых кандидатов блока shardchain, дополненных (сопоставленных) с данными, взятыми из состояния этой цепочки и из других (обычно соседних) shardchains, вместе с соответствующими доказательствами Merkle. (Это необходимо, например, когда некоторые сообщения должны быть отправлены из соседних shardchains.) Затем валидатор может легко проверить предложенного кандидата блока для действительности, без необходимости загружать полное состояние этого или другого сегмента shardchains. Поскольку валидатор должен представить новых (сопоставленных) кандидатов на блок, получить некоторые («майнинг») вознаграждения, имеет смысл оплатить часть вознаграждение сортировщику, желающему предоставить подходящих кандидатов в блок. В этом случае, валидатор может освободиться от необходимости наблюдать за состоянием соседних shardchains, передавая его сортировщику. Однако мы ожидаем, что на этапе первоначальной установки системы не будет отдельных назначенных сортировщиков, поскольку все валидаторы будут способные выступать в качестве сортировщиков для себя.

2.3.6. Коллаторы (сортировщики) или валидаторы: получение денег для включения пользователя сделки. Пользователи могут открывать каналы микроплатежей некоторым сортировщикам или валидаторам и выплачивать небольшие суммы монет в обмен на включение их транзакции в shardchain.

2.3.7. Выборы глобального валидатора. «Глобальный» набор валидаторов избираются раз в месяц (фактически, каждые 2¹⁹ masterchain блоков). Этот набор определяется и общеизвестен за один месяц вперед. Чтобы стать валидатором, узел должен перенести некоторые монеты AUR в мастерчейн masterchain, а затем отправить их на специальный смарт-контракт как предложение ставки s. Другим параметром, отправленным вместе с ставкой, является l ≥ 1, максимальная проверяющая нагрузка, которую этот узел готов принять относительно минимальный возможный. Существует также глобальная верхняя граница (другой конфигурируемый параметр) L на l, равный, скажем, 10. Затем глобальный набор валидаторов выбирается этим смарт контрактом, просто путем выбора до T кандидатов с максимальными предполагаемыми ставками и публикацией их личности. Первоначально общее число валидаторов составляет T = 100; мы ожидаем, что оно вырастет до 1000 при увеличении нагрузки. Это настраиваемый параметр (см. 2.1.21). Фактическая доля каждого валидатора вычисляется следующим образом: если верхняя T предлагаемой ставки s₁ ≥ s₂ ≥ ··· ≥ s_T, фактическая доля i-го валидатора равна набору  в  s^I_i : = min (s_i , l_i · S_T). Таким образом, s^I_i / s^I_T  ≤ l_i , поэтому i-й валидатор не получит больше, чем l_i ≤ L раз нагрузки самого слабого валидатора (потому, что нагрузка в конечном счете пропорциональна ставке).

Затем избранные валидаторы могут снять неиспользованную часть своей доли, s_i - s^I_i.  Недопущенные кандидаты на валидаторов могут снять все свои доли. Каждый валидатор публикует публичный ключ подписи, не обязательно равной публичному ключу счета, на который был сделан платеж^.19 Ставки валидаторов замораживаются до конца периода, на который они были избраны, и еще один месяц, в случае новых споров (т. е. найден недопустимый блок, подписанный одним из этих валидаторов). После что, ставка возвращается, вместе с долей валидатора отчеканенных монет и комиссии от транзакций, обработанных в течение этого времени.

19 Имеет смысл генерировать и использовать новую пару ключей для каждого выбора валидатора.

2.3.8. Выборы «целевых групп» валидатора. Весь глобальный набор валидаторов (где каждый валидатор считается присутствующим с кратностью, равной его доле, иначе валидатор может испытывать соблазн принять несколько удостоверений и разделить их долю среди них) используется только для проверки новых блоков masterchain. Блоки сегментов shardchain проверяются только специально подобранным подмножествами валидаторов, взятых из глобального набора валидаторов, выбранных как описано в 2.3.7. Эти «подмножества» валидатора или «группы задач», определенные для каждого сегмента, изменяются каждый час (фактически, каждые 2¹⁰ блоков masterchain) и они известны за один час вперед, чтобы каждый валидатор знал, какие сегменты ему необходимо будет проверить и может подготовиться к этому (например, путем загрузки отсутствующих shardchain данных). Алгоритм, используемый для выбора групп задач проверки для каждого сегмента (w, s) является детерминированным псевдослучайным. Он использует внедренные псевдослучайные числа для валидаторов на каждом masterchain блоке (генерируется консенсусом, используя пороговые сигнатуры) для создания случайного начального значения, а затем вычисляет, например Hash (Code (w). Code (s). Validator_id.rand_seed) для каждого валидатора. Затем валидаторы сортируются по значению этого хэша и выбираются несколько первых, чтобы иметь как минимум 20 / Т от общего количества ставок валидаторов, но не менее  5 валидаторов. Этот выбор можно сделать с помощью специального смарт-контракта. В таком случае, алгоритм выбора легко мог бы быть обновлен без жестких вилок механизма голосования, упомянутый в 2.1.21. Все остальные «константы» упомянуты так далеко (например, 2¹⁹ , 2¹⁰ , T, 20 и 5) и также являются настраиваемыми параметрами.

2.3.9. Чередование приоритетов для каждой группы задач. Существует определенный «приоритетный» порядок, наложенный на членов группы задач сегментов, в зависимости от хэш предыдущего блока masterchain и последовательности номеров блоков (shardchain). Этот порядок определяется путем генерации и сортировки некоторых хэшей как описано выше. Когда необходимо создать новый блок shardchain, сегмент группы задач валидатора, выбранный для создания этого блока, обычно является первым с уважением к этому вращающемуся «приоритетному» порядку. Если ему не удается создать блок, второй или третий валидатор может это сделать. По сути, все они могут предложить свой блок кандидат, но кандидат, предложенный валидатором, имеющий наивысший приоритет, должен выиграть в результате консенсуса Византийского отказа от толерантности, (BFT) протокол.

2.3.10. Распространение кандидатов блока shardchain. Так как членство shardchain в группе задач известно за час вперед, их члены могут использовать это время для создания выделенной «многоадресной оверлейной сети проверки валидатора», используя общие механизмы сети Gold (см. 3.2) Когда необходимо создать новый блок shardchain - обычно одна или две секунды после того, как был распространен самый последний блок masterchain – все знают, кто имеет наивысший приоритет для генерации следующего блока (см. 2.3.9). Этот валидатор создаст кандидата нового отсортированного блока либо сам по себе, либо с помощью коллатора (см. 2.3.5). Валидатор должен проверить (подтвердить) это (особенно, если он был подготовлен некоторым коллатором) и подписать его своим секретным ключом. Затем кандидат блока распространяется к оставшейся части группы задач, используя заранее установленную многоадресную оверлейную сеть (группа задач создает свою собственную оверлейную сеть, как описано в 3.3, а затем использует версию описанного протокола потоковой многоадресной передачи (см.3.2.15) для распространения кандидатов блоков). BFT алгоритм делает это с использованием византийского многоадресного протокола рассылки, подобный тому, который используется в Honey Badger BFT [11]: кодирование кандидата блока по (N,2N/3)-случайному коду, отправить 1/N полученных данных непосредственно каждому члену группы и ожидать многоадресной рассылки напрямую их части данных всем остальным членам группы.

Однако более быстрый и более простой способ сделать это (см. Также 3.2.15) состоит в том, чтобы разбить кандидата блока на последовательность подписанного одного килобайта блока («фрагменты»), которые дополняют их последовательность Рид-Соломоном или фонтаном кода (например, код RaptorQ [9] [14]) и начать передачу фрагментов на соседей в «многоадресной сетке» (т. е. оверлейная сеть), ожидая их для дальнейшего распространения этих фрагментов. Как только валидатор получит достаточное количество фрагментов для восстановления кандидата блока, он подписывает квитанцию о подтверждении и распространяет ее через  своих соседей по всей группе. Затем его соседи перестают посылать ему новые фрагменты, но могут продолжать отправлять (оригинальные) подписи этих фрагментов, считая, что этот узел может генерировать последующие фрагменты сам, применяя Рид-Соломон или фонтанный код (имея все необходимые данные), объединяет их с подписями и распространяет его на соседей, которые еще не готовы. Если «многоадресная сетка» (оверлейная сеть) остается подключенной после удаления всех «плохих» узлов (напомним, что до одной трети узлов разрешено быть плохими по византийскому варианту- вести себя произвольно злонамеренно), этот алгоритм будет распространять кандидата блока как можно быстрее. Не только назначенный высокоприоритетный создатель блока может блокировать кандидата для всей группы. Второй и третий валидатор по приоритету может начать многоадресную рассылку своих кандидатов в блок либо сразу или после отказа от получения кандидата блока от валидатора верхнего приоритета. Однако обычно только кандидат блока с максимальным приоритетом будет подписан всеми (фактически, по меньшей мере, две трети группы задач) валидаторами, как совершено новый блок shardchain.

2.3.11. Проверка кандидатов в блок. После получения кандидата в блок валидатором и подписи его инициирующего валидатора, принимающий валидатор проверяет достоверность этого кандидата блока, выполняет все транзакции в нем и проверяет, что результат совпадает с ранее утвержденным. Все сообщения, импортированные из других блоков, должны поддерживаться с помощью подходящих доказательств Merkle в сопоставленных данных, иначе блок кандидат считается недействительным (если доказательство этого совершено в отношении основной цепочки masterchain, валидаторы, уже подписавшие этот блок кандидат, могут быть наказаны). С другой стороны, если найденный кандидат блока действителен, принимающий валидатор подписывает его и распространяет свою подпись на другие валидаторы в группы, либо через «сеть многоадресной передачи», либо по прямой сети Сообщения. Мы хотели бы подчеркнуть, что валидатор не нуждается в доступе к состоянию этого или соседних сегментов для проверки действительности кандидата (сопоставленный).²⁰ Это позволяет проверить правильность быстро (без доступа к диску), облегчает вычисления и уменьшает нагрузку на валидаторов (особенно если они готовы принять услуги внешних коллаторов (сортировщики)  для создания кандидатов в блок).

20 Возможным исключением является состояние очередей вывода соседних сегментов, необходимых для обеспечения требований к порядку передачи сообщений, описанных в 2.4.21, поскольку размер доказательств Merkle может стать непомерно высоким в этом случае.

2.3.12. Выборы следующего кандидата блока. Как только кандидат блока собирает не менее двух третей (по ставке) подписей действительности валидаторов в целевой группе, он может быть назначен на следующий блок shardchain. Протокол BFT запускается для достижения консенсуса по выбранному кандидату блока (может быть несколько предложений), при этом все «хорошие» валидаторы предпочитают кандидата блока с наивысшим приоритетом для этого раунда. В результате запуская этот протокол, блок дополняется подписями не менее двух третей валидаторов (по ставке). Эти подписи свидетельствуют не только о действительности рассматриваемого блока, а также его избрание протокола BFT. После этого блок (без сопоставленных данных) объединяется с этими подписями, сериализованные детерминированным способом и распространяемые через сети для всех заинтересованных сторон.

2.3.13. Валидаторы должны хранить блоки, которые они подписали. В течение их членства в целевой группе и не менее одного часа (скорее, 2¹⁰ блоков), ожидается, что валидаторы будут хранить блоки, которые они подписали и совершили. За невозможность предоставить подписанный блок другим, валидаторы могут быть наказаны.

2.3.14. Распространение заголовков и подписей новых shardchain блоков для всех валидаторов. Валидаторы распространяют заголовки и подписи вновь созданных блоков shardchain для глобального набора валидаторов, используя многоадресную сеть, аналогичную той, которая создана для каждой группы задач.

2.3.15. Генерация новых блоков masterchain. Новый блок мастерчейн может быть сгенерирован после того, как были созданы новые блоки shardchain. Процедура по существу такая же, как и для блоков shardchain (см. 2.3.12), с той разницей, что все валидаторы (или, по крайней мере, две трети их) должны участвовать в этом процессе. Поскольку заголовки и подписи новые блоки shardchain распространяются на всех валидаторы, хеши новейших блоков в каждой shardchain могут и должны быть включены в новый блок мастерчейн masterchain. Как только эти хеши передаются в блок мастерчейн, наблюдатели и другие сегменты могут рассмотреть новые блоки shardchain совершенными и неизменными (см. 2.1.13).

2.3.16. Валидаторы должны сохранять состояние masterchain. Примечательно, разница между мастерчейн и сегментами состоит в том, что все валидаторы как ожидается, будут отслеживать состояние мастерчейн, не полагаясь на сопоставленные данных. Это важно, потому что знание целевых групп валидатора выводится из состояния основной цепи masterchain.

2.3.17. Блоки Shardchain генерируются и распространяются параллельно. Обычно каждый валидатор является членом нескольких групп задач shardchain; их количество (следовательно, нагрузка на валидатор) приблизительно пропорционально доли валидатора. Это означает, что валидатор запускает несколько экземпляров нового протокол генерации блоков shardchain параллельно.

2.3.18. Смягчение атак на блокирование блоков. Общий набор валидаторов вставляет новый хэш блока сегмента в мастерчейн после того, как увидят его заголовок и подписи, однако, существует небольшая вероятность того, что валидаторы, которые сгенерировали этот блок, сговорятся и будут пытаться избежать публикации нового блока полностью. Это приведет к неспособности валидаторов соседних сегментов создать новые блоки, потому что они должен знать, по крайней мере, очередь выходных сообщений нового блока, как только его хэш был совершен в мастерчейн. Чтобы смягчить это, новый блок должен собрать подписи от некоторых других валидаторов (например, две трети объединения целевых групп соседних сегментов), свидетельствующие о том, что эти валидаторы имеют копии этого блока и готовы отправить их любым другим валидаторам, если это необходимо. Только после представления этих подписей хэш нового блока будет включен в мастерчейн.

2.3.19. Блоки Masterchain генерируются позже, чем shardchain блоки. Блоки Masterchain генерируются примерно раз в пять секунд, как и блоки shardchain. Однако, генерация новых блоков во всех сегментах выполняется, по существу, в одно и то же время (обычно срабатывает выпуск нового блока мастерчейн), генерация новых блоков мастерчейн намеренно задерживается, чтобы включить хеширование вновь созданных блоков сегментов в мастерчейн.

2.3.20. Медленные валидаторы получают более низкие награды. Если валидатор «медленный», он может не одобрить новых кандидатов блоков, а две трети подписей, необходимых для фиксации нового блока, могут быть собраны без его участия. В этом случае он получит меньшую долю вознаграждения, связанное с этим блоком. Это дает стимул для валидаторов оптимизировать свое оборудование, программное обеспечение и сетевое соединение, чтобы быстро обрабатывать транзакции пользователя, как это возможно. Однако, если валидатор не может подписать блок до его совершения, его подпись может быть включена в один из следующих блоков, а затем часть вознаграждения (экспоненциально уменьшающееся в зависимости от того, сколько блоков было создано, например 0,9^К , если валидатор создаст k блоков позднее) будет выдано этому валидатору.

2.3.21. «Глубина» подписей валидатора. Обычно, когда валидатор подписывает блок, подпись свидетельствует только об относительной достоверности блока: этот блок действителен при условии, что все предыдущие блоки в этом и других сегментах действительны. Валидатор не может быть наказан за признание недействительными данных, зафиксированные в предыдущих блоках. Однако подпись валидатора блока имеет целочисленный параметр, называемый «глубина». Если он отличен от нуля, это означает, что валидатор утверждает (относительно) достоверность указанного количества предыдущих блоков. Это способ для «медленных» или «временно отключенных» валидаторов, чтобы им догнать и подписать некоторые блоки, которые были совершены без их подписи. Затем, некоторая часть вознаграждения блока будет выдана им по-прежнему (см. 2.3.20).

2.3.22. Валидаторы несут ответственность за относительную достоверность подписанных блоков сегментов; абсолютная действительность следует. Мы хотели бы еще раз подчеркнуть, что подпись валидатора на блоке Shardchain B свидетельствует только об относительной действительности этого блока (или, возможно, d предыдущих блоков также, если подпись имеет «глубину» d, но это не влияет на следующее обсуждение). Другими словами, валидатор утверждает, что следующее состояние s^I cегмента получается из предыдущего состояния s, применяя функцию оценки блока ev_block, описанную в 2.2.6:

S^I = ev_block (B) (s) (24)

Таким образом, валидатор, который подписал блок B, не может быть наказан, если исходное состояние оказывается «неправильным» (например, из-за недействительности одного из предыдущих блоков). «Рыбак» (см. 2.3.4) должен заявить только в том случае, если он находит блок, который является относительно недействительным. Система PoS в целом стремится сделать каждый блок относительно действительным, а не рекурсивно (или абсолютно) действительным. Обратите внимание, однако, что если все блоки в блокчейне являются относительно допустимыми, то все из них и блокчейн в целом абсолютно верны; это утверждение легко показано с использованием математической индукции по длине блокчейна. Таким образом, легко проверяемые утверждения относительной справедливости блоков вместе демонстрируют гораздо более сильную абсолютную достоверность всего блокчейна. Обратите внимание, что, подписывая блок B, валидатор утверждает, что блок действительный с учетом исходного состояния s (т. е. результат (24) не является значением ⊥ указывая, что следующее состояние не может быть вычислено). Таким образом, валидаторы должны выполнять минимальные формальные проверки ячеек исходного состояния, доступ к которому был получен при оценке (24). Например, представьте, что ячейка должна содержать исходный баланс учетной записи, доступной из транзакции, совершенной в блок, чтобы иметь нулевые необработанные байты вместо ожидаемых 8 или 16. Затем оригинал баланс просто не может быть извлечен из ячейки, а «необработанное исключение» происходит при попытке обработки блока. В этом случае валидатору не следует подписывать такой блок под страхом наказания.

2.3.23. Подписание masterchain блоков. Ситуация с блоками мастерчейн несколько отличается: подписывая блок мастерчейн, валидатор утверждает не только его относительную справедливость, но и относительную справедливость всех предшествующих блоков до самого первого блока, когда этот валидатор принял ответственность (но не дальше).

2.3.24. Общее количество валидаторов. Верхний предел T для общего количество валидаторов, подлежащих избранию (см. 2.3.7), не может стать в системе, описанной до сих пор, более, чем, несколько сотен или тысяч, потому что ожидается, что валидаторы будут участвовать в консенсусном протоколе BFT для создания каждого нового блока мастерчейн и неясно, являются ли такие протоколы масштабируемыми до тысяч участников. Еще важнее то, что блоки должны собирать подписи не менее двух третей всех валидаторов (по ставке) и эти подписи должны быть включены в новый блок (в противном случае все остальные узлы в системе не будут иметь никаких оснований доверять новым блокам без проверки его самостоятельно). Скажем больше, тысячи валидаторных подписей должны быть включены в каждый блок мастерчейн, это будет означать больше данных в каждом блоке мастерчейн, которые будут храниться всеми полными узлами и распространятся через сеть, также нужны большие вычислительные мощности для проверки этих подписей (в системе PoS, для полного узла не требуется самостоятельно проверять блоки, но необходимо проверить подписи валидаторов). Хотя ограничение T на тысячу валидаторов кажется более чем достаточным для первого этапа развертывания Gold Blockchain, положение должно быть сделано для будущего роста, когда общее количество сегментов shardchains будет настолько большой, что нескольких сотен валидаторов не будет достаточно для обработки всех их. Для этого введем дополнительный настраиваемый параметр T^I ≤ T (первоначально равным T) и только верхний T^I выбранных валидаторов (по ставке), как ожидается, будет создавать и подписывать новые блоки мастерчейн.

2.3.25. Децентрализация системы. Можно было бы подозревать, что алгоритм «Доказательство доли» такой системы как Gold Blockchain, полагаясь на T ≈ 1000 валидаторов для создания всех блоков shardchain и masterchain, обязательно станет «слишком централизованном», в отличие от обычных блокчейнов алгоритма «Доказательство работы», таких как Bitcoin или Ethereum, где каждый (в принципе) мог бы создать новый блок, без явного верхнего предела на общее число майнеров. Однако популярные блокчейны алгоритма «Доказательство работы», такие как Bitcoin и Ethereum, в настоящее время требуют огромных вычислительных мощностей (высокая «скорость хэширования») для того, чтобы создавать новые блоки с неослабевающей вероятностью успеха. Таким образом создание новых блоков, как правило, сосредоточено в руках нескольких крупных игроков, которые вкладывают огромные суммы денег в центры обработки данных, заполненные заказным аппаратным обеспечением, оптимизированным для майнинга; в руках нескольких крупных «майнинг пулов», которые концентрируют и координируют усилия крупных групп людей, которые сами по себе не могут обеспечить достаточную «хэш-скорость». Поэтому, по состоянию на 2017 год, более 75% новых блоков Ethereum или биткойнов производятся менее чем десятью шахтерами. Фактически, два крупнейших Ethereum «майнинг пула» производят вместе более половины всех новых блоков! Очевидно, что такая система гораздо более централизованна, чем другая, полагающаяся на T ≈ 1000 узлов для производства новых блоков.

Можно также отметить, что инвестиции, необходимые для того, чтобы стать Gold Блокчейн –валидатором - приобретение оборудования (несколько высокопроизводительных серверов) и пакета (который может легко собрать через пул номинаторов, если необходимо; ср 2.3.3) - намного ниже, чем требуется, чтобы стать успешным автономным майнером криптовалют Биткойн или Эфириум. Фактически, параметр L из 2.6.7 заставит номинантов не вступать в крупнейший «майнинг пул», (т. е. валидатор, накопивший наибольшую долю), а скорее посмотрит на небольших валидаторов, которые в настоящее время принимают средства от номинаторов или даже создаст новых валидаторов, поскольку это позволит увеличить долю s^I_i / s_i валидаторов, кроме этого, используется также номинальная ставка, стимулирующая большие выгоды от майнинга. Таким образом, система Gold Digital c алгоритмом «доказательство доли» фактически поощряет децентрализацию (создание и использование валидаторов) и наказывает централизацию.

2.3.26. Относительная надежность блока. (Относительная) надежность блока - общая доля всех валидаторов, которые подписали этот блок. Другими словами, это сумма денег, которую некоторые участники проиграют, если этот блок оказывается недействительным. Если речь идет о переносе транзакций значением ниже надежности блока, можно считать их достаточно безопасными. В этом смысле относительная надежность является мерой доверия за пределами наблюдателя в определенном блоке. Обратите внимание, что мы говорим об относительной надежности блока, поскольку это гарантия, что блок действителен при достоверности предыдущего блок и всех остальных (см. 2.3.22). Относительная надежность блока может расти после его совершения – например, при добавлении запоздалых подписей валидаторов (см. 2.6.21). Но с другой стороны, если один из этих валидаторов теряет часть или всю свою ставку из-за его неправомерного поведения, связанного с некоторыми другими блоками, относительная надежность блока может уменьшаться.

2.3.27. «Укрепление» блокчейна. Важно обеспечить стимулы для валидаторов, чтобы увеличить относительную надежность блоков, как это возможно. Один из способов сделать это - выделить небольшое вознаграждение валидаторам для добавления подписей к блокам других сегментов shardchains. Даже «потенциальные» валидаторы, которые поставили недостаточно ставок, чтобы попасть в Топ валидаторов по ставке для включения в глобальный набор валидаторов (см. 2.3.7), могут участвовать в этом мероприятии (если они согласны держать свою долю замороженной вместо ее отзыва после проигранных выборов). Такие потенциальные валидаторы могут удвоиться как «рыбаки» (см. 2.3.4): если они должны проверить действительность в любом случае, некоторые блоки могут также сообщать о недопустимых блоках и собирать связанные награды.

2.3.28. Рекурсивная надежность блока. Можно также определить рекурсивную надежность блока как минимум его относительной надежности и рекурсивную надежность всех блоков, к которым он относится (т. е. блок мастерчейн, предыдущий блок shardchain и некоторые блоки соседних shardchains). Другими словами, если блок окажется недействительным, либо потому, что он недействителен или потому, что один из блоков, от которого он зависит, недействителен, то по крайней мере эта сумма денег будет потеряна кем-то. Если вы действительно не уверены в том, чтобы доверять определенной транзакции в блоке, нужно вычислить рекурсивную надежность этого блока, а не только относительную. Не имеет смысла заходить слишком далеко назад при вычислении рекурсивной надежности, потому что, если мы посмотрим слишком далеко назад, мы увидим блоки, подписанные валидаторами, чьи ставки уже разморожены и сняты. В любом случае мы не позволяем валидаторам автоматически пересматривать блоки, которые являются старыми (т. е. созданные более двух месяцев назад, если использованы текущие значения настраиваемых параметров) и создавать вилки, начиная с них или исправить их с помощью «вертикальных блокчейнов» (см. 2.1.17), даже если они оказываются недействительными. Мы предполагаем, что период в два месяца предусматривает широкие возможности для обнаружения и сообщения любых недопустимых блоков, так что, если в течение этого периода блок не оспаривается, он вряд ли будет оспорен вообще.

2.3.29. Следствие «Доказательства доли» для легких узлов. Важным следствием подхода «Доказательство доли», используемого Gold Blockchain, является то, что в легкий узел (программное обеспечение для работы с легким клиентом) для Gold Blockchain не нужно загружать «заголовки» всех shardchain или даже masterchain блоков, чтобы иметь возможность проверять самим по себе достоверность доказательств Merkle, предоставляемые ему полными узлами в качестве ответов на его запросы. В самом деле, поскольку самые последние хеши блоков shardchain включены в блоки masterchain, полный узел может легко обеспечить доказательство Merkle, что данный блок shardchain действителен, начиная с известного хэша masterchain блока. Далее, легкий узел должен знать только самый первый блок masterchain (где объявляется самый первый набор валидаторов), который (или по крайней мере, его хэш) может быть встроен в клиентское программное обеспечение, только один блок мастерчейн, примерно каждый месяц после этого, когда объявляются вновь избранные валидаторы, поскольку этот блок будет подписан предыдущим набором валидаторов. Исходя из этого, он может получить несколько последних блоков masterchain или, по крайней мере, их заголовки и подписи валидаторов и использовать их в качестве базы для проверки доказательств Merkle, предоставленные полными узлами.

Одной из наиболее характерных и уникальных особенностей Gold Blockchain является его способность автоматически разделять shardchain в два, когда нагрузка становится слишком высокой и соединять их обратно, если нагрузка снизится (см. 2.1.10). Мы должны обсуждить это в деталях из-за его уникальности и важности для масштабируемости всего проекта.

2.4.1. Конфигурации сегмента (осколка). Напомним, что в любой момент времени, каждая рабочая цепочка workchain w разбивается на один или несколько сегментов (w, s) (см. 2.1.8). Эти сегменты могут быть представлены листьями бинарного двоичного дерева, с корнем (w, ∅) и каждый нелистовой узел (w, s), имеющий родственные элементы (w,s.0) и (w, s.1). Таким образом, каждый счет, принадлежащий рабочей цепочке workchain w, один осколок и все, кто знает текущую конфигурацию shardchain могут определить сегмент (w, s), содержащий учетную запись account_id: это единственный осколок с двоичной строкой s, являющейся префиксом account_id. Конфигурация осколков - это двоичное дерево осколков или коллекция всех активных (w, s) для данного w (соответствующих листьям сегмента бинарного дерева), являющаяся частью состояния masterchain и доступно всем, кто следит за мастерчейн masterchain.²¹

21 Фактически, конфигурация сегментов полностью определяется последней производной блока masterchain; это упрощает получение доступа к конфигурации сегментов.

2.4.2. Самая последняя конфигурация и состояние сегментов. Напомним, что хеши самых последних блоков shardchain включены в каждый блок masterchain. Эти хеши организованы в бинарном двоичном дереве сегментов (на самом деле, коллекции деревьев, по одному для каждой рабочей цепочки workchain). Таким образом, каждый блок masterchain содержит самые последние конфигурации сегментов.

2.4.3. Объявление и выполнение изменений в конфигурации сегментов.

Конфигурация сегментов может быть изменена двумя способами: либо сегмент (w, s) можно разделить на два сегмента (w, s.0) и (w, s.1) или два «брата» (w, s.0) и (w, s.1) могут быть объединены в один сегмент (w, s). Эти операции разделения / слияния блоков объявляются (например, 2⁶; это настраиваемый параметр) заранее, сначала в «заголовках» соответствующих блоков shardchain, а затем в блоке мастерчейн, который ссылается к этим блокам shardchain. Это предварительное объявление необходимо для всех заинтересованных сторон для подготовки к запланированным изменениям (например, создание наложения многоадресной сети для распространения новых блоков вновь созданных сегментов, как описано в п. 3.2). Затем изменение фиксируется, сначала в (заголовок) блоке shardchain (в случае разделения и слияния, блоки обоих сегментов должны зафиксировать изменения), а затем распространяется до блока мастерчейн. Таким образом, блок мастерчейн определяет не только самые последние сегменты конфигурации до его создания, но и следующие конфигурации сегментов.

2.4.4 Группы задач валидаторов для новых сегментов. Напомним, что каждый сегмент, то есть каждый shardchain, обычно назначается подмножеством валидаторов (группа задач), предназначенных для создания и проверки новых блоков в соответствующей shardchain (см. 2.3.8). Эти целевые группы избираются для некоторого периода времени (приблизительно один час) и известны заблаговременно (также приблизительно за один час) и неизменны в течение этого периода.²² Однако фактическая конфигурация сегментов может измениться в течение этого периода из-за операций разделения и объединения. Необходимо назначить группы задач новым создателям сегментов. Это делается следующим образом: Обратите внимание, что любой активный сегмент (w, s) будет либо потомком некоторого однозначно определенного исходного сегмента (w, s¹), что означает, что s¹ является префиксом s, или это будет корень поддерева оригинальных сегметов (w, s¹ ), где s будет префикс каждого s¹. В первом случае мы просто берем группу задач оригинальный осколок (w, s¹), чтобы удвоить как группу задач нового сегмента (w, s). В последнем случае группа задач нового сегмента (w, s) будет объединением групп всех исходных сегментов  (w, s¹ ), которые являются потомками (w, s) в  дереве сегментов. Таким образом, каждому активному сегменту (w, s) присваивается четко определенное подмножество валидаторов (группа задач). Когда осколок разделяется, оба потомка наследуют целую группу задач из первоначального сегмента. Когда два осколка объединены, их группы задач также объединены. Любой, кто отслеживает состояние masterchain, может вычислить валидатора группы задач для каждого из активных сегментов.

22 Если некоторые валидаторы временно или постоянно запрещены из-за подписания недопустимых блоков, они автоматически исключаются из всех групп задач.

2.4.5. Ограничение на операции разделения / слияния в период ответственности исходных групп задач. Новая конфигурация сегментов будет принята во внимание, а новые выделенные подмножества валидаторов (группы задач) автоматически присваиваются каждому сегменту. Прежде чем это произойдет, нужно наложить определенный предел на операции разделения / слияния; в противном случае исходная группа задач может завершить проверку 2 ^k  shardchains для большого k, в то же время, если исходный сегмент быстро распадается на 2^k новых сегментов. Это достигается путем введения ограничений на то, насколько удалена конфигурация активного сегмента из первоначальной конфигурации сегментов (используемой для выбора в настоящий момент групп задач валидатора). Например, можно было бы требовать, чтобы расстояние в дереве сегментов от активного сегмента (w, s) до оригинального сегмента (w, s¹) не должно превышать 3, если s¹ является предшественником s (т. е. s¹ это префикс двоичной строки s) и не должен превышать 2, если s¹ является преемником s (т. е. s является префиксом s¹). В противном случае операция разделения или слияния не допускается. Грубо говоря, налагается ограничение на количество разделения сегмента (например, три) или их объединения (например, два) в течение периода ответственности за конкретный набор групп задач валидатора. После того, как сегмент был создан путем слияния или разделения, он не может быть изменен в течение некоторого периода времени (некоторое количество блоков).

2.4.6. Определение необходимости разделения операций. Операция разделения для shardchain инициируется определенными формальными условиями (например, если для 64 последовательных блоков shardchain блоки заполнены по крайней мере на 90%). Эти условия контролируются группой задач shardchain. Если они будут выполнены, сначала флаг «разделенная подготовка» включается в Заголовок нового shardchain блока (и распространяется на masterchain блока, ссылаясь на этот shardchain блок.) Затем, через несколько блоков, флаг «разделить фиксацию» включается в Заголовок блока shardchain (и распространяется на следующий masterchain блок.)

2.4.7. Выполнение операций разделения. После включения флага «разделить фиксацию» в блоке B shardchain (w, s) не может быть последующего блока B0 в этом shardchain. Вместо этого будут созданы два блока B¹₀ и B¹₁ (w, s.0) и (w, s.1), относящиеся к блоку B, как к их предыдущему блоку (и оба они будут указывать с помощью флага в заголовке, что сегмент был просто разделен). Следующий блок masterchain будет содержать хеши блоков B¹₀ и B¹₁ новых сегментов; не допускается содержать хэш нового блока B¹ shardchain (w, s), потому что событие «разделить фиксацию» уже зафиксировано в предыдущем блоке мастерчейн. Обратите внимание, что оба новых shardchains будут проверены одним и тем же валидатором как один старый, поэтому они автоматически будут иметь копию своих состояний. Сама операция разделения состояний довольно проста с точки зрения Бесконечной парадигмы сегментирования (см. 2.2.2).

2.4.8. Определение необходимости операций слияния. Необходимость операций слияния осколков также обнаруживается в определенных формальных условиях (например, если для 64 последовательных блоков сумма размеров двух блоков братьев shardchains не превышает 60% от максимального размера блока). Для этих формальных условий следует также учитывать общий объем газа, потраченного этими блоками и сравнить его с текущим пределом газа блока, иначе блоки могут быть небольшими, потому что есть некоторые интенсивные вычисления, которые препятствуют включению большего количества транзакций. Эти условия контролируются целевыми группами валидатора обоих родственных сегментов (w, s.0) и (w, s.1). Обратите внимание, что родственные сегменты обязательно соседи в отношении маршрутизации гиперкуба , поэтому валидаторы из группы задач любого сегмента будут в какой-то мере контролировать следы родственного сегмента. Когда эти условия выполнены, одна из подгрупп валидатора может предложить другой, чтобы они слились, отправив специальное сообщение. Затем они объединяются во временную «объединенную целевую группу», с объединенным членством, способны запускать консенсусные алгоритмы BFT, распространять и блокировать обновления, блокировать кандидатов, если это необходимо. Если они достигнут консенсуса относительно необходимости и готовности слияния, «слияние подготовить», флаги передаются в заголовки некоторых блоков каждого shardchain, наряду с подписями не менее двух третей валидаторов групп задач родственного сегмента (и распространяются на следующие блоки masterchain, так что каждый может подготовиться к скорейшей реконфигурации). Однако, они продолжают создавать отдельные блоки shardchain для некоторых предопределенных количество блоков.

2.4.9. Выполнение операций слияния. После того, когда валидаторы из объединения двух исходных целевых групп готовы стать валидаторами для объединенной shardchain (это может включать передачу состояния от родственного сегментаshardchain и операции объединения состояний), они совершают «фиксацию слияния», флаг в заголовках блоков их shardchain (это событие распространяется к следующим блокам мастерчейн) и прекращают создание новых блоков в отдельных shardchains (после появления флага фиксации слияния, создание блоков в отдельном сегменте запрещено). Вместо этого создается объединенный блок shardchain (объединение двух исходных групп задач), ссылаясь на оба своих "предшествующих блока" в своем "заголовке". Это отражено в следующем блоке мастерчейн masterchain, который будет содержать хэш только что созданного блока объединенной shardchain. После этого объединенная группа задач продолжает создавать блоки в объединенной shardchain.

Краеугольным камнем в построении сетевых протоколов Gold Digital является Абстрактный Сетевой уровень (датаграмма). Это позволяет всем узлам принимать определенные «Сетевые идентификаторы», представленные 256-битными «абстрактными сетевыми адресами» и сообщения (отправьте датаграммы друг другу в качестве первого шага), используя только эти 256-битные сетевые адреса для идентификации отправителя и получателя. В частности, не нужно беспокоиться о адресах IPv4 или IPv6, UDP-порт числа и т. п.; они скрыты абстрактным сетевым слоем.

3.1.1. Абстрактные сетевые адреса. Абстрактный сетевой адрес или абстрактный адрес, представляет собой 256-битное целое число, по существу равное 256-битовому открытому ключу ECC. Этот открытый ключ может генерироваться произвольно, таким образом создавая столько разных сетевых идентификаторов, сколько нравится узлу. Тем не менее, необходимо знать соответствующий закрытый ключ для получения (и расшифровать) сообщения, предназначенный для такого адреса. Фактически, адрес не является открытым ключом; вместо этого это 256-битный хэш (Hash = sha256) сериализованного TL-объекта , который может описывать несколько типов открытых ключей и адресов в зависимости от его конструктора (сначала четыре байта). В простейшем случае этот сериализованный TL-объект состоит только из 4-байтового магического числа и криптографии с 256-разрядной криптографией эллиптической кривой (ECC) публичного ключа; в этом случае адрес будет равен хешу этой 36-байтовой структуры. Однако можно использовать 2048-битные ключи RSA или любую другую схему публичного ключа криптографии вместо этого. Когда узел узнает абстрактный адрес другого узла, он также должен получать его «прообраз» (т. е. сериализованный TL-объект, хэш которого равен абстрактному адресу), иначе он не сможет шифровать и отправлять датаграммы на этот адрес.

3.1.2. Сети нижнего уровня. Реализация UDP. Из всех компонентов Gold Сети, один (Сетевой уровень абстрактной датаграммы) способен (неудовлетворительно) отправлять датаграммы с одного абстрактного адреса на другой. В принципе, Сетевой уровень абстрактной датаграммы (ADNL) может быть реализован различными существующими сетевыми технологиями. Однако мы собираемся внедрить это через UDP в сетях IPv4 / IPv6 (например, в Интернете или интрасетях), с дополнительным протоколом TCP, если UDP недоступен.

3.1.3. Простейший случай ADNL над UDP. Самый простой случай отправки датаграмма с абстрактного адреса отправителя на любой другой абстрактный адрес (с известным прообразом) можно реализовать следующим образом. Предположим, что отправитель каким-то образом знает IP-адрес и UDP порт получателя, которому принадлежит целевой адрес адресата и что как получатель, так и отправитель используют абстрактные адреса, полученные из 256-битного открытого ключа ECC. В этом случае отправитель просто увеличивает датаграмму, отправляемую Подпись ECC (с закрытым ключом) и адрес источника (или прообраз исходного адреса, если получателю он не известен). Результат зашифровывается с открытым ключом получателя, встроенным в датаграмму UDP и отправляется на известный IP-адрес и порт получатель. Поскольку первые 256 бит датаграммы UDP содержат абстрактный адрес, получатель может определить, какой частный ключ нужен для дешифрования остальной части датаграммы. Только после этого личность отправителя раскрыта.

3.1.4. Менее безопасный путь, с адресом отправителя открытым текстом. Иногда недостаточно безопасной схемы, когда адреса получателя и отправителя хранятся в открытом тексте в датаграмме UDP; ключ личного адреса отправителя и открытый ключ получателя объединяются вместе с использованием ECDH (эллиптической кривой Диффи-Хелмана), чтобы создать 256-разрядный общий секрет, который используется впоследствии, наряду со случайным 256-битным значением, включенным в незашифрованном виде, чтобы получить ключи AES, используемые для шифрования. Целостность может предоставляться, например, путем объединения хэша исходного открытого текста данных в открытый текст перед шифрованием. Преимущество такого подхода состоит в том, что если более чем одна датаграмма ожидается обменяться между двумя адресами, общий секрет может вычисляться только один раз, а затем кэшируется; затем более медленные операции эллиптической кривой больше не потребуются для шифрования или расшифровки следующих датаграмм.

3.1.5. Каналы и идентификаторы каналов. В простейшем случае первый 256 бит UDP-датаграммы, содержащей встроенную датаграмму Gold ADNL, будет равен адресу получателя. Однако, как правило, они составляют идентификатор канала. Существуют разные типы каналов. Некоторые из них являются двухточечными; они создаются двумя сторонами, которые хотят обменять много данных в будущем и генерировать общий секрет, обмениваясь несколькими пакетами, зашифрованными, как описано в 3.1.3 или 3.1.4, путем запуска классической или эллиптической кривой Диффи-Хеллмана (если требуется дополнительная безопасность) или просто одним, создавая случайный общий секрет и отправляя его другой стороне. После этого идентификатор канала выводится из общего секрета с некоторыми дополнительными данными (такими, как адреса отправителя и получателя), например, путем хеширования и этот идентификатор используется в качестве первых 256 бит UDP-датаграммы, содержащей данные, зашифрованные с помощью этого общего секрета.

3.1.6. Канал, как идентификатор туннеля. В общем, «канал» или «канал идентификатор» просто выбирает способ обработки входящей UDP датаграммы, известной получателю. Если канал является абстрактным адресом получателя, то обработка выполняется, как указано в 3.1.3 или 3.1.4; если канал является установочным двухточечный каналом, рассмотренным в п. 3.1.5, обработка состоит из дешифрования датаграммы с помощью общего секрета, как объяснено ранее. В частности, идентификатор канала может фактически выбрать «туннель», когда непосредственный получатель просто отправляет полученное сообщение кому-то еще - фактическому получателю или другому прокси-серверу. Некоторые шаги шифрования или дешифрования (напоминающие «маршрутизацию лука» [6] или даже «маршрутизацию чеснока»³⁰), могут быть сделаны по пути и другой идентификатор канала может использоваться для повторного шифрования пересылаемых пакетов (например, одноранговый канал может использоваться для пересылки пакета следующему получателю на пути). Таким образом, некоторая поддержка «туннелирования» и «проксирования» - несколько похожа на то, что предоставлено TOR или I²P проектами - могут быть добавлены на уровне абстрактного слоя сети датаграммы Gold, не влияя на функциональность всех высокоуровневых сетевых протоколов Gold Digital, что было бы агностиком такого дополнения. Эта возможность используется службой Gold Proxy (см. 4.1.11).

30 https: //geti2p.net/en/docs/how/garlic-routing

3.1.7. Нулевой канал и проблема начальной загрузки. Gold ADNL узел будет иметь некоторую «таблицу соседей», содержащую информацию о других известных узлах, такие как их абстрактные адреса и их прообразы (т. е. открытые ключи) и их IP-адреса и UDP-порты. Затем он будет постепенно расширять эту таблицу, используя информацию, полученную из этих известных узлов, как ответы на специальные запросы, а иногда и обрезку устаревших записей. Однако, когда узел Gold ADNL только запускается, может случиться, что он не знает ни одного другого узла и может знать только IP-адрес и UDP порт узла, но не его абстрактный адрес. Это происходит, например, если легкий клиент не может получить доступ к какому-либо из ранее кэшированных узлов, любые узлы жестко закодированы в программном обеспечении и должны запросить пользователя ввести IP-адрес или домен DNS узла, который должен быть разрешен через DNS. В этом случае узел будет отправлять пакеты в специальный узел - «нулевой канал». Это не требует знания публичных данных получателя (но сообщение должно содержать идентификатор и подпись отправителя), поэтому сообщение передается без шифрования. Он должен быть обычно использован только для получения идентичности (возможно, одноразовая личность, созданная специально для этой цели) получателя, а затем начать общение более безопасным способом. Как только известен хотя бы один узел, легко заполнить «таблицу соседей» и «таблицу маршрутизации» на большее количество записей, изучая их из ответов на специальные запросы, отправленные на уже известные узлы. Не все узлы необходимы для обработки датаграмм, отправленных на нулевой канал, но те, которые используются для загрузки легких клиентов, должны поддерживать эту функцию.

3.1.8. TCP-тип потоковый протокол над ADNL. ADNL, будучи ненадежным (малый размер) протоколом датаграмм на основе 256-битных абстрактных адресов, может использоваться как основа для более сложных сетевых протоколов. Можно построить, например, TCP-подобный протокол потока, используя ADNL в качестве абстрактного замена IP. Однако большинству компонентов проекта Gold Digital такой протокол потока не нужен.

3.1.9. RLDP или надежный протокол больших датаграмм над ADNL. Надежный протокол датаграмм произвольного размера, построенный на ADNL, называемый RLDP, используется вместо TCP-подобного протокола. Этот надежный протокол датаграмм может использоваться для отправки запросов RPC на удаленные хосты и получения ответов от них (см. 4.1.5).

В мульти-блокчейн системе, такой как Gold Blockchain, даже полные узлы обычно интересуются получением обновлений (т. е. новых блоков), только о некоторых shardchains. С этой целью должна быть построена специальная оверлейная (вспомогательная) сеть внутри сети Gold Digital, поверх протокола ADNL, обсуждаемого в 3.1, одна для каждого shardchain. Следовательно, необходимо создать произвольные осевые подсети, открытые для любых узлов, желающих принять участие. В этих оверлейных сетях будут работать специальные протоколы сплетен, основанные на ADNL. В частности, эти протоколы сплетен могут использоваться для распространения (передачи) произвольных данных внутри таких подсетей.

3.2.1. Оверлейные сети. Оверлейная (суб) сеть - это просто (виртуальная) сеть, реализованная внутри некоторой более крупной сети. Обычно только некоторые узлы более широкой сети участвуют в оверлейной подсети и только некоторые «Ссылки» между этими узлами, физическими или виртуальными, являются частью оверлейной подсети. Таким образом, если охватывающая сеть представляется в виде графика (возможно, полный график в случае сети датаграмм, такой как ADNL, где любой узел может легко обмениваться данными с любым другим), оверлейная подсеть представляет собой подграф этого графа. В большинстве случаев оверлейная сеть реализуется с использованием некоторого протокола, построенного на сетевом протоколе более крупной сети. Он может использовать те же адреса в качестве более крупной сети или использовать пользовательские адреса.

3.2.2. Наложение сетей в Gold Digital. Оверлейные сети в Gold Digital построены по протоколу ADNL, обсуждаемому в 3.1; они используют 256-битный ADNL реферат адреса, как адреса в оверлейных сетях. Каждый узел обычно выбирает один из его абстрактных адресов, чтобы удвоить его адрес в наложении сети. В отличие от ADNL, сети наложения Gold Digital  обычно не поддерживают отправку датаграмм на произвольные другие узлы. Вместо этого некоторые «полуперманентные» ссылки устанавливаются между некоторыми узлами (называемыми «соседи», по отношению к рассматриваемой сети наложения) и сообщения обычно отправляются по этим ссылкам (то есть от узла к одному из его соседей). Таким образом, оверлейная сеть Gold Digital  является (обычно не полным) подграфом внутри (полного) графа сети ADNL. Ссылки на соседей в оверлейных сетях Gold Digital   могут быть реализованы с использованием выделенных одноранговых каналов ADNL (см. 3.1.5). Каждый узел оверлейной сети поддерживает список соседей (с уважением к оверлейной сети), содержащий их абстрактные адреса (которые они используют для идентификации их в оверлейной сети) и некоторые данные связи (например, канал ADNL, используемый для связи с ними).

3.2.3. Частные и публичные оверлейные сети. Некоторые оверлейные сети являются общедоступными, что означает, что любой узел может присоединиться к ним по желанию. Другие частные, которые могут допускать только определенные узлы (например, те, которые могут доказать их идентификаторы как валидаторы.) Некоторые частные оверлейные сети могут быть даже неизвестны «широкой публике». Информация о таких оверлейных сетях предоставляется только определенным доверенным узлам; например, он может быть зашифрован с открытым ключом и только узлы, имеющие копию секретного ключа, смогут расшифровать эту информацию.

3.2.4. Централизованные системы наложения. Некоторые оверлейные сети централизованно контролируются одним или несколькими узлами либо владельцем, некоторого широко известного публичного ключа. Другие децентрализованы, что означает нет конкретных узлов, ответственных за них.

3.2.5. Присоединение к оверлейной сети. Когда узел хочет присоединиться к наложению сети, он должен сначала узнать свой 256-битный сетевой идентификатор, как правило, равный к sha256 описания сети наложения-TL-сериализованный объект , который может содержать, например, центральный орган наложения сети (т. е. ее открытый ключ и возможно ее абстрактный адрес,³²), строку с именем оверлейной сети, идентификатором сегмента Gold Blockchain, если эта оверлейная сеть связана с этим сегментом и так далее. Иногда можно восстановить описание оверлейной сети от идентификатора сети, просто просмотрев его в Gold DHT. В других случаях (например, для частных оверлейных сетей), необходимо получить описание сети вместе с сетевым идентификатором.

32. В альтернативном варианте абстрактный адрес может быть сохранен в DHT, как описано в 3.2.12.

3.2.6. Поиск оверлейной сети. Кроме узла, надо знать сетевой идентификатор и сетевое описание оверлейной сети для присоединения, найти хотя бы один узел, принадлежащий этой сети. Это также необходимо для узлов, которые не хотят присоединяться к сети наложения, но хотят просто общаться; например, может быть наложение сети, предназначенное для сбора и распространения кандидатов на транзакции для конкретного shardchain и клиент может захотеть подключиться к любому узлу, чтобы предложить транзакцию. Метод, используемый для определения местоположения оверлейной сети, определен в описание этой сети. Иногда (особенно для частных сетей) нужно уже знать узел-член, чтобы иметь возможность присоединиться. В других случаях абстрактные адреса некоторых узлов содержатся в описании сети. Более гибкий подход заключается в том, чтобы указывать в описании сети только центральный орган, ответственный за сеть, абстрактные адреса будут доступны через значения определенных ключей DHT, подписанных этим центральным органом. Действительно децентрализованные общедоступные оверлейные сети могут использовать «распределенный торрент-трекер», который также реализован с помощью Gold DHT.

3.2.7. Поиск большего количества членов оверлейной сети. Создание ссылки. Когда один узел сети наложения найден, может быть задан специальный запрос на этот узел, запрашивая список других членов, например, соседей запрашиваемого узла или его случайный выбор. Это позволяет члену соединения заполнять ее «смежность» или «список соседей» в отношении оверлейной сети, путем выбора некоторых недавно приобретенных сетевых узлов и установление связей с ними (то есть, выделенная точка-точка ADNL каналов, как указано в п. 3.2.2). После этого специальные сообщения направляются всем соседям, указывая, что новый член готов работать в оверлейной сети. Соседи включают ссылки на нового участника в их списки соседей.

3.2.8. Ведение списка соседей. Накладной сетевой узел должен время от времени обновлять список своих соседей. Некоторые соседи или по крайней мере ссылки (каналы) к ним, могут перестать отвечать; в этом случае эти ссылки должны быть отмечены, как «приостановленные», если некоторые попытки повторного подключения к таким соседям потерпят неудачу, ссылки должны быть уничтожены. С другой стороны, каждый узел иногда запрашивает от случайного выбранного соседа его список соседей (или их случайный выбор) и использует частично обновленный свой собственный список соседей, добавляя к нему некоторые, из недавно обнаруженных узлов, удаляет некоторые из старых либо случайно или в зависимости от времи их ответа и статистики потерь датаграмм.

3.2.9. Оверлейная сети случайного подграфа. Таким образом, оверлейная сеть становится случайным подграфом внутри сети ADNL. Если степень каждой вершины составляет не менее трех (т. е. если каждый узел связан с тремя соседями), этот случайный граф, как известно, связан с вероятностью почти равной единице. Точнее, вероятность случайного графа с отключенными n вершинами экспоненциально мала и этой вероятностью можно полностью пренебречь, если, скажем, n ≥ 20. (Конечно, это не применяется в случае глобального сетевого раздела, когда узлы на разных сторонах раздела не имеют возможности узнать друг о друге.) Но с другой стороны, если n меньше 20, было бы достаточно, чтобы каждая вершина имела, по меньшей мере десять соседей.

3.2.10. Наложенные сети Gold Digital оптимизированы для более низкой задержки. Gold Digital   оверлейные сети оптимизируют «случайный» сетевой график, сгенерированный предыдущим методом следующим образом. Каждый узел пытается сохранить как минимум трех соседей с минимальным временем туда-обратно, меняя этот список «быстрых соседей» очень редко. В то же время у него также есть, по крайней мере три других «медленных соседа», которые выбраны полностью случайным образом, так что граф сети наложения всегда будет содержать случайный подграф. Это необходимо для обеспечения возможности подключения и предотвращения разделения наложенной сети на несколько несвязанных региональных подсетей. По меньшей мере три «промежуточных соседства», которые имеют промежуточное время округления, ограниченные некоторой константой (фактически, функцией времени туда и обратно быстрых и медленных соседей), также выбраны и сохраняются. Таким образом, график сети наложения по-прежнему сохраняет достаточную хаотичность для подключения, но оптимизирован для более низкой латентности и более высокой пропускной способности.

3.2.11. Протоколы сплетен в оверлейной сети. Оверлейная сеть часто используется для запуска одного из так называемых протоколов сплетен, глобальной цели, позволяя каждому узлу взаимодействовать только со своими соседями. Например, существуют протоколы сплетен для построения приблизительного списка всех членов (не слишком большой) сети наложения или для вычисления оценки количество членов (сколь угодно большой) сети наложения, используя только ограниченный объем памяти на каждом узле (см. [15, 4.4.3] или [1] для деталей).

3.2.12. Наложение сети в качестве широковещательного домена. Самым важным в протоколе сплетен, работающем в оверлейной сети, является широковещательный протокол, предназначенный для распространения широковещательных сообщений, генерируемых любым узлом сети или, возможно, одним из назначенных узлов отправителя ко всем другим узлам. На самом деле существует несколько широковещательных протоколов, оптимизированных для различных случаев их использования. Самые простые из них получают новые широковещательные сообщения и ретранслируют их для всех соседей, которые еще не отправили копию этого сообщения.

3.2.13. Более сложные протоколы вещания. Некоторые приложения могут потребовать более сложные протоколы вещания. Например, для трансляции сообщений значительного размера, имеет смысл отправить соседям не само вновь полученное сообщение, а его хэш (или набор хэшей новых сообщений). Сосед может запросить само сообщение после изучения ранее невидимого хэш сообщения, которое нужно передать, скажем, с использованием надежного протокола больших датаграмм (RLDP), обсуждаемый в п. 3.1.9. Таким образом, новое сообщение будет загружено только с одного соседа.

3.2.14. Проверка подключения оверлейной сети. Возможность подключения оверлейной сети можно проверить, существует ли известный узел (например, «владелец» или «создатель» оверлейной сети), который должен быть в этой оверлейной сети. Тогда рассматриваемый узел просто транслирует во времени к временным коротким сообщениям, содержащим текущее время, порядковый номер и его подпись. Любой другой узел может быть уверен, что он все еще подключен к наложенной сети, если она получила такую трансляцию не так давно. Этот протокол может быть распространен на случай нескольких известных узлов; например, все они отправят такие трансляции и все остальные узлы получат широковещательные передачи, более чем с половиной известных узлов. В случае оверлейной сети, используемой для распространения новых блоков (или только новых заголовков блоков) конкретной shardchain, хороший способ для узла, проверить подключение для отслеживания последнего принятого блока. Поскольку блок обычно генерируется каждые пять секунд, если новый блок принимается более, чем, скажем, тридцать секунд, узел, вероятно, был отключен от сети наложения.

3.2.15. Потоковый широковещательный протокол. Наконец, есть потоковая передача широковещательного протокола для оверлейных сетей Gold Digital, используемый, например, для распространения блокировки кандидатов среди валидаторов некоторых shardchain («группа задача» shardchain), которые, конечно же, создают для этого частную оверлейную сеть. Один и тот же протокол может использоваться для распространения новых блоков shardchain для всех полных узлов этой shardchain. Этот протокол уже описан в 2.3.10 : новая (большая) трансляция сообщений разбивается на, скажем, на N килобитных фрагментов; последовательность этих кусков дополняется M ≥ N кусками данных посредством кода стирания, такого как Рид-Соломон или фонтанного кода (например, код RaptorQ [9] [14]) и эти М-фрагменты передаются всем соседям в порядке возрастания номера фрагмента. Участвующие узлы собирают эти куски, пока они не смогут восстановить оригинальное большое сообщение (нужно было бы успешно получить хотя бы N из кусков для этого), а затем поручают своим соседям прекратить отправку новых кусков потока, потому что теперь эти узлы могут генерировать последующие куски сами по себе, имея копию оригинального сообщения. Такие узлы продолжают генерировать последующие куски потока и отправлять их на их соседей, если соседи в свою очередь не укажут, что это уже не необходимо. Таким образом, узлу не нужно загружать большое сообщение полностью, прежде чем распространять его дальше. Это минимизирует латентность вещания, особенно в сочетании с оптимизациями, описанными в 3.2.10.

3.2.16. Построение новых оверлейных сетей на основе существующих. Иногда не хочется создавать накладную сеть с нуля. Вместо этого известна одна или несколько ранее существующих оверлейных сетей и ожидается, что членство в новой оверлейной сети будет перекрываться с объединенным членством в этих оверлейных сетях. Важный пример возникает, когда Gold shardchain разделяется на две части или два сегмента объединяются в один. В первом случае должны быть построены оверлейные сети, используемые для распространения новых блоков на полные узлы для каждого из новых сегментов; однако каждый из этих новых наложений сети, как ожидается, будет содержаться в сети распространения блоков (и составлять приблизительно половину его членов). Во втором случае оверлейная сеть для распространения новых блоков объединенного сегмента будет состоять приблизительно из союза членов двух оверлейных сетей, связанных с объединением двух сегментов. В таких случаях описание новой сети наложения может содержать явную или неявную ссылки на список, связанных существующих оверлейных сетей. Узел, желающий присоединиться к новой сети наложения, может проверить члена одной из этих существующих сетей и запросить своих соседей в этих сетях, заинтересованы ли они в новой сети. В случае положительного ответа, можно создать новые каналы «точка-точка» для таких соседей и они могут быть включены в список соседей для нового наложения сети. Этот механизм не полностью вытесняет описанный общий механизм ; скорее, оба выполняются параллельно и используются для заполнения списка соседей. Это необходимо для предотвращения случайного расщепления новой оверлейной сети в несколько несвязанных подсетей.

3.2.17. Наложение сетей на оверлейные сети. Еще один интересный случай возникает при осуществлении Gold Платежей («сеть молний») для мгновенной передачи стоимости вне сети; см 5.1). В этом случае сначала построена оверлейная сеть (сеть наложения), содержащая все транзитные узлы «сети молния». Однако некоторые из этих узлов установили каналы оплаты в блокчейне; они всегда должны быть соседями в этой оверлейной сети, в дополнение к любым «случайным» соседям, выбранным алгоритмом общей оверлейной сетью. Эти "постоянные ссылки" для соседей с установленными платежными каналами используют протокол «сеть молний», тем самым эффективно создавая оверлейную подсеть (не обязательно связаны, если что-то идет не так) внутри охватывающей сети (почти всегда подключена).

4.1.1. Приложения и услуги. Мы будем использовать слова "приложение" и "обслуживание" взаимозаменяемо. Однако есть тонкие и несколько неопределенное различие: приложение обычно предоставляет некоторые услуги непосредственно пользователям, в то время как служба обычно используется другими приложениями и сервисами. Например, Gold Storage - это сервис, потому что он разработан хранить файлы от имени других приложений и служб, хотя пользователь может использовать его напрямую. Гипотетический «Facebook в блокчейн» (см. 6.1.13), если он доступен через Сеть Gold (т. е. реализована как «Gold Сервис», см. 4.1.6), скорее приложение.

4.1.2. Расположение приложения: в цепи, вне цепи или смешанное.

Сервис или приложение, предназначенные для экосистемы Gold Digital, должны сохранять данные и их обрабатывать. Это приводит к следующему классификации приложений и услуг:

• Сетевые приложения (см. 4.1.4): все данные и обработка находятся в Gold Блокчейн.

• Внесетевые приложения (см. 4.1.5): все данные и обработка находятся за пределами Gold Блокчейн, на серверах, доступных через сеть Gold.

• Смешанные приложения (см. 4.1.7): некоторые данные и обработка находятся в Gold Blockchain; остальные находятся на серверах вне сети, доступные через сеть Gold.

4.1.3. Централизация: централизованные и децентрализованные или распределенные приложения. Другим критерием классификации является то, полагается ли приложение (или служба) на централизованный кластер серверов или действительно «распределено», (см. 4.1.9). Все сетевые приложения автоматически децентрализованы и распределены. Внесетевые и смешанные приложения могут иметь разную степень централизации. Теперь рассмотрим приведенные выше возможности более подробно.

4.1.4. Чистые приложения «на цепи»: распределенные приложения или «Dapps», расположенные в блокчейне. Один из возможных подходов, упомянутый в 4.1.2, заключается в развертывании «распределенного приложения» (обычно сокращенно как «dapp») полностью в Gold Блокчейн, как один умный контракт или набор интеллектуальных контрактов. Все данные будут сохранены, как часть постоянного состояния этих умных контрактов и все взаимодействие с проектом будет осуществляться посредством (Gold Блокчейн) сообщений, отправленных или полученных от этих умных контрактов. Мы уже обсуждали в 6.2.13, что этот подход имеет свои недостатки и ограничения. Он также имеет свои преимущества: такое распределенное приложение не требует серверов для запуска или хранения своих данных (он запускается «в блокчейн» на аппаратуре валидаторов) и обладает чрезвычайно высокой степенью блокировки (Византийской) надежности и доступности. Разработчик такого распределенного приложение не нуждается в покупке или аренде какого-либо оборудования; нужно только разработать программное обеспечение (код для смарт-контрактов). После этого, он будет эффективно снимать вычислительную мощность с валидаторов и будет платить за это в AUR, либо себе, либо ставя эту нагрузку на плечи ее пользователей.

4.1.5. Чистые сетевые сервисы: «Gold сайты» и «Gold услуги». Крайний вариант - развернуть службу на некоторых серверах и сделать ее доступной пользователям через протокол ADNL, описанный в 3.1 и возможно, через некоторые протоколы высокого уровня, таких, как RLDP, обсуждаемый в 3.1.9, который может отправлять запросы RPC службам в любом настраиваемом формате и получать ответы к этим запросам. Таким образом, сервис будет полностью отключен от сети и будет находится в сети Gold Digital, без использования Gold Blockchain. Gold Blockchain может использоваться только для определения абстрактного адреса или адресов служб, возможно, с помощью таких как Gold DNS , чтобы облегчить перевод доменных удобочитаемых строк в абстрактные адреса.

В той степени, в которой сеть ADNL (Gold Digital Сеть) аналогична Невидимому интернет-проекту (I²P), такие (почти) чисто сетевые сервисы, аналогичные так называемым «eep-сервисам» (то есть услугам, которые имеют I²P адреса, как их точку входа, доступную для клиентов через I²P сети). Чисто сетевые сервисы, которые находятся в Сети Gold Digital - «Gold Сервис», «Eep-Сервис» могут реализовать HTTP в качестве протокола клиент-сервер; в контексте сети Gold, «Gold Сервис» может просто использовать RLDP (см. 3.1.9) датаграммы для передачи HTTP-запросов и ответы на них. Если мы используем Gold DNS, чтобы его абстрактный адрес просматривался с помощью читаемого человеком доменного имени, аналогия с веб-сайтом становится почти идеальной. Можно написать специализированный браузер или специальный прокси («Gold-прокси»), который запускается локально на машине пользователя, принимает произвольные HTTP-запросы от обычного веб-браузер, который использует пользователь (после локального IP-адреса и TCP-порта прокси, вводимого в конфигурацию браузера) и пересылает эти запросы через сеть Gold Digital к абстрактному адресу службы. Тогда пользователь будет иметь опыт просмотра, похожий на опыт в мире широкой сети (WWW). В I²P, такие «eep-сервисы» называются «eep-сайтами». Можно легко создавать «Gold-сайты» в экосистеме Gold Digital. Это облегчается за счет существования таких сервисов, как Gold DNS, который использует Gold Blockchain и Gold DHT для перевода (Gold) доменных имен в абстрактные адреса.

4.1.6. Telegram Messenger как услуга Gold Digital; MTProto через RLDP. Мы хотели бы упомянуть попутно, что протокол MTProto, используемый Telegram Messenger для взаимодействия клиент-сервер, может быть легко встроен в протокол RLDP, обсуждаемый в п. 3.1.9, тем самым эффективно преобразуя Telegram. Технология Gold Proxy может быть переключена прозрачно для конечного пользователя Gold-сайта или Gold Сервиса, реализуемого на более низком уровне, чем протоколы RLDP и ADNL (см. 3.1.6), это сделало бы Telegram эффективно неблокируемым. Другие мессенджеры и социальные сети также могут извлечь выгоду из этой технологии.

4.1.7. Смешанные услуги: частично вне сети, частично в сети. Некоторые службы могут использовать смешанный подход: делать большую часть обработки вне цепи, но также иметь некоторую часть в цепи (например, зарегистрировать свои обязательства в отношении их пользователей и наоборот). Таким образом, часть состояния все еще будет храниться в Gold Блокчейн (т. е. в неизменной публичной книге) и любое неправильное поведение службы или ее пользователей может быть наказано смарт-контрактами.

4.1.8. Пример: сохранение файлов вне сети; Gold Storage. Пример такой услуги предоставляется Gold Storage. В простейшей форме он позволяет пользователям хранить файлы вне сети, сохраняя в цепочке только хэш файла, который будет сохранен и возможно, смарт-контракт, в котором некоторые другие стороны соглашаются держать файл, о котором идет речь, в течение определенного периода времени для предварительной оплаты. По факту, файл можно разделить на куски небольшого размера (например, 1 килобайт), дополненный кодом стирания, таким как Рид-Соломон или фонтанный код, Хеш дерева Merkle может быть построен для расширенной последовательности кусков и этот хеш дерева Merkle может быть опубликован в смарт-контракте или вместе с обычным хэшем файла.

Это несколько напоминает способ хранения файлов в торренте. Еще более простая форма хранения файлов полностью отключена: можно по существу создать «торрент» для нового файла и использовать Gold DHT, как «распределенный торрент-трекер» для этого торрента . Это может реально работать хорошо для популярных файлов. Тем не менее, у вас нет гарантий доступности. Например, гипотетический «блокчейн Facebook» (см. 6.2.13), который выбран, чтобы сохранить фотографии профиля своих пользователей полностью вне сети в таких «Торрентах», может рисковать потерять фотографии обычных (не особенно популярны) пользователей или рискуют не представить эти фотографии для длительного периода.  Технология Gold Storage, которая в основном отключена от сети, но использует смарт-контракт на цепочке для обеспечения доступности хранящихся файлов, может лучше подходить для этой задачи.

4.1.9. Децентрализованные смешанные услуги или «услуги тумана». До сих пор мы обсуждали централизованные смешанные службы и приложения. В то время как on-chain компонент в цепи обрабатывается децентрализованным и распределенным образом, расположенным в блокчейне, компонент вне сети зависит от некоторых серверов, контролируемых поставщиком услуг в обычной централизованной форме. Вместо использования некоторых выделенных серверов, вычислительная мощность может быть арендована из облачных вычислительных услуг, предлагаемых крупными компаниями. Однако это не приведет к децентрализации внесетевого компонента службы. Децентрализованный подход к реализации компонента сервиса вне сети заключается в создании рынка, где любой, обладающий необходимым оборудованием и готовый арендовать свои вычислительные мощности или дисковое пространство, будет предлагать эти услуги тем, кто в них нуждается. Например, может существовать реестр (который также можно назвать «рынок» или «обмен»), где все узлы, заинтересованные в хранении файлов других пользователей, публикуют свою контактную информацию вместе с потенциалом имеющихся хранилищ, политики доступности и ценами. Те, кто нуждается в этих услугах, могут посмотреть их, если другая сторона соглашается, создать смарт-контракты в блокчейн и загрузить файлы для хранения вне сети. Таким образом, служба как Gold Storage становится действительно децентрализованной, поскольку ей не нужно полагаться на любой централизованный кластер серверов для хранения файлов.

4.1.10. Пример: платформы «туманных вычислений», как децентрализованные смешанные сервисы. Возникает еще один пример такого децентрализованного смешанного приложения, когда необходимо выполнить некоторые конкретные вычисления (например, 3D-рендеринг или обучающие нейронные сети), часто требующие специального и дорогостоящего оборудования. Тогда те, кто имеет такое оборудование, могут предлагать свои услуги через аналогичные «Обмены», а те, кто нуждается в таких услугах, будут арендовать их с обязательствами сторон, зарегистрированных посредством смарт-контрактов. Это похоже на такие платформы «туманных вычислений», как Golem (https://golem.network/) или SONM (https://sonm.io/).

4.1.11. Пример: Gold Полномочия Proxy - это туманная служба. Gold Proxy предоставляет еще один пример службы тумана, где узлы, желающие предлагать свои услуги (с компенсацией или без) в качестве туннелей для сетевого трафика ADNL могут зарегистрироваться и те, кто в них нуждается, могут выбрать один из этих узлов в зависимости от цены, задержки и пропускной способности. Впоследствии можно было бы использовать платежные каналы, предоставляемые компонентом Gold Платежи для обработки микроплатежей за услуги этих доверенных лиц с платежами, собранными, например, для каждых переданных 128 Kб.

4.1.12. Пример: Gold Платежи - это туманная услуга. Платформа Gold Платежи (см. 5) также является примером такого децентрализованного смешанного приложения.

В 4.1.9 мы видели, что «Услуги тумана» (cмешанные децентрализованные услуги) обычно требуют некоторые рынки, биржи или реестры, где конкретные услуги могут отвечать тем, кто их предоставляет. Такие рынки, скорее всего, будут реализованы как сетевые, внесетевые или смешанные услуги, централизованные или распределенные.

4.2.1. Пример: подключение к Gold Платежи. Если кто-то хочет использовать Gold Платежи (см. 5), первым шагом было бы найти хотя бы некоторые существующие транзитные узлы «сети молний» (см. 5.2) и устанавливают каналы оплаты с ними, если они желают. Некоторые узлы могут быть найдены с помощью «охватывающей» оверлейной сети, которая должна содержать все транзитные узлы сети молний (см. 3.2.17). Однако это не ясно, будут ли эти узлы готовы создавать новые каналы оплаты. Поэтому необходим реестр, где узлы, готовые к созданию новых ссылок, могут публиковать их контактную информацию (например, их абстрактные адреса).

4.2.2. Пример: загрузка файла в Gold Storage Хранилище. Аналогично, если кто-то хочет загрузить файл в Gold Хранилище, он должен найти некоторые узлы, готовые подписать смарт-контракт, обязывающий их хранить копию этого файла (или любого файла, ниже размера определенного предела). Необходим реестр узлов, предлагающий свои услуги для хранения файлов.

4.2.3. Сетевые, смешанные и внесетевые реестры. Такой реестр поставщиков услуг могут быть реализованы полностью в сети (в цепочке) с помощью смарт-контракта, который сохранит реестр в его постоянном хранилище, однако это было бы довольно медленно и дорого. Смешанный подход более эффективный, где относительно небольшой и редко изменяемый реестр в сети используется только для указания некоторых узлов (по их абстрактным адресам или по их открытым ключам, которые могут использованы для определения фактических абстрактных адресов, которые предоставляют услуги централизованного доступа (централизованные). Наконец, децентрализованный, чисто внесетевой подход может состоять из положений, указанных в п. 3.2, где желающие предлагают свои услуги либо кто хочет купить чьи-то услуги, просто транслирует свои предложения, подписанные их секретными ключами. Если предоставляемая услуга очень проста, даже передача предложений может быть необязательной: приблизительное членство самой оверлейной сети может использоваться как «реестр» тех, кто желает предоставлять конкретную услугу. Клиент, требующий этой службы, может найти (см. 3.2.7) и запросить некоторые узлы этой оверлейной сети, а затем запросить их соседей, если уже известные узлы не готовы удовлетворить свои потребности.

4.2.4. Регистрация или обмен в боковой цепи. Другой подход к внедрению децентрализованных смешанных реестров состоят в создании независимой блокчейн («боковой цепи»), поддерживаемой собственным набором самоназначенных валидаторов, которые публикуют свои идентификационные данные в сетевом смарт-контракте и обеспечивают доступ к сети всем заинтересованным сторонам этого специализированного блокчейн, сбор кандидатов на транзакции и обновления блока вещания через специализированные сети наложения (см. 3.2). Тогда любой полный узел для этого sidechain может поддерживать свою собственную копию общего реестра (по существу равную глобальному состоянию этой боковой цепи) и обрабатывать произвольные запросы, связанные с этим реестром.

4.2.5. Регистрация или обмен в рабочей цепи workchain. Другим вариантом является создать специальную рабочую цепь workchain внутри блока Gold Blockchain, специализирующуюся на созданиb реестров, рынков и обменов. Это может быть более эффективным и дешевле, чем использование смарт-контрактов, находящихся в основной рабочей цепи workchain (см. 2.1.11). Однако это все равно будет дороже, чем поддержание реестров в боковых цепях sidechains (см. 4.2.4).

5.1.1. Ограничения каналов оплаты. Канал оплаты полезен для сторон, которые ожидают много денежных переводов между ними. Однако, если одному необходимо переводить деньги только один или два раза конкретному получателю, создавать канал оплаты с ними будет непрактичным. Среди прочего, это будет означать замораживание значительной суммы денег в платежном канале, и в любом случае, потребуется по крайней мере две блокчейн транзакции.

5.1.2. Сети платежных каналов или «сети молний». Сети платежных каналов преодолевают ограничения каналов платежей путем включения денежных переводов по цепям платежных каналов. Если A хочет передать деньги на E, ему не нужно устанавливать канал оплаты с E. Было бы достаточно иметь цепочку каналов оплаты, связывающую A с E через несколько промежуточных узлов - например, четыре канала оплаты: от A до B, от B до C, от C до D и от D до E.

5.1.3. Обзор сетей платежных каналов. Напомним, что платежная канальная сеть, известная также как «сеть молний», состоит из коллекции участвующих узлов, некоторые из которых установили долговременные платежные каналы между ними. Мы увидим, что эти платежные каналы должны быть «умными». Когда участвующий узел A хочет перевести деньги на любой другой участвующий узел E, он пытается найти путь, соединяющий A и E внутри сети платежных каналов. Когда такой путь найден, она выполняет «цепочку денежных переводов» по этому пути.

5.1.4. Цепные денежные переводы. Предположим, что существует цепочка платежных каналов от A до B, от B до C, от C до D и от D до E. Предположим, далее, что A хочет передать x монету E. Упрощенный подход состоял бы в том, чтобы перенести x монет на B вдоль существующих каналов оплаты и попросить его направить деньги далее на C. Однако, неясно, почему B просто не взял деньги на себя. Следовательно, необходимо применять более сложный подход, не требуя от всех сторон, чтобы они доверяли друг другу. Это можно сделать следующим образом. Генерируем большое случайное число u и вычисляет его хэш v = Hash (u). Затем создаем обещание заплатить х монет в B, если представлено число u с хешем v , внутри канала оплаты с B. Это обещание содержит v, но не u, которое все еще держится в секрете. После этого B создает аналогичное обещание C в своем платежном канале. Он не боится дать такое обещание, потому что осознает существование аналогичного обещания, данное ему А. Если C когда-либо представляет решение хэша, задача собрать х монет, обещанных B, тогда B немедленно отправит это решение для A, для сбора x монет из A. Затем создаются аналогичные обещания от C до D и от D до E. Когда обещания все на месте, А запускает передачу, сообщая решение u всем вовлеченным сторонам - или просто E. В этом описании перечислены некоторые мелкие детали. Например, эти обещания должны иметь разные сроки истечения, а обещанная сумма может немного отличаться по цепочке (B может пообещать C только x - y монет, где y - небольшая предварительно согласованная плата за транзит). Мы игнорируем такие детали, потому что они не слишком важны для понимания того, как каналы оплат работают и как они могут быть реализованы в Gold Digital.

5.1.5. Виртуальные платежные каналы внутри цепи каналов оплаты. Предположим теперь, что A и E рассчитывают произвести много платежей друг другу. Они могут создать новый канал оплаты между ними в блокчейне, но это все равно будет довольно дорого, потому что некоторые средства будут заблокированы этом птатежном канале. Другим вариантом было бы использовать денежные цепные денежные переводы, описанные в 5.2.4 для каждого платежа. Однако, это будет связано с большим количеством сетевой активности и множеству транзакций в виртуальных цепочках всех каналов оплаты. Альтернативой является создание виртуального платежного канала внутри цепи, связывая A и E в сети платежных каналов. Для этого A и E создают (виртуальный) блокчейн для своих платежей, как если бы они собирались создать канал оплаты в блокчейне. Однако, вместо создания платежного канала смарт-контракта в блокчейне, они запрашивают все промежуточные платежные каналы, которые связывают A и B, B и C и прочее для создания простого канала платежа внутри них, связанный с виртуальным блокчейном, созданным A и E . Другими словами, теперь обещание перевести деньги в соответствии с окончательным урегулированием между A и E существует внутри каждого промежуточного канала оплаты.

Если канал виртуального платежа является однонаправленным, такие обещания могут быть реализованы довольно легко, потому что конечный дисбаланс δ будет неположительным, поэтому в промежуточном платеже могут быть созданы простые платежные каналы, в том же порядке, что и в 5.2.4. Их срок времени действия также может быть одинаков. Если канал виртуального платежа двунаправлен, ситуация немного более сложна. В этом случае следует разделить обещание переноса δ монеты в соответствии с окончательным расчетом на два полуобещания,  для переноса δ - = max (0, -δ) монеты в прямом направлении и перенос δ + = max (0, δ) в обратном направлении. Эти полуобещания могут создаваться в промежуточных платежных каналах независимо, одной цепочкой полуобещания в направлении от А до Е, а другой – в противоположном направлении.

5.1.6. Поиск путей в сети молнии. Осталось одно до сих пор неясно: как А и Е найдут путь, соединяющий их в платежной сети? Если платежная сеть не слишком велик, OSPF-подобный протокол может использоваться: все узлы платежной сети создают наложение сети (см. 3.2.17), а затем каждый узел распространяет все доступные ссылки (то есть, участвующий платежный канал) информации своим соседям по протоколу сплетен. В конечном итоге все узлы будут иметь полный список всех каналов оплаты и участвуя в платежной сети могут найти кратчайший пути сами по себе - например, применяя версию алгоритма Дейкстры с учетом «мощностей» платежных каналов (т. е. максимальные суммы, которые могут быть перенесены вдоль них). Как только найден путь кандидата, он может быть исследован специальной датаграммой ADNL, содержащей полный путь и запрашивающий каждый промежуточный узел для подтверждения о существовании рассматриваемого платежного канала и пересылать эту датаграмму далее по пути. После этого можно построить цепь и протокол для цепных передач (см. 5.2.4) или запустить создание виртуального платежного канала внутри цепочки каналов оплаты (см. 5.2.5).

5.1.7. Оптимизации. Некоторые оптимизации здесь приведены. Только транзитные узлы сети молний должны участвовать в OSPF-подобном протоколе, обсуждаемом в 5.2.6. Два «листовых» узла, желающих подключиться через сеть молнии будут сообщать друг другу списки транзитных узлов, к которым они подключены (с которыми они установили каналы оплаты, участвующие в платежной сети). Затем пути подключения транзитных узлов из одного списка в транзитные узлы из другого списка могут проверяться, как указано выше в пункте 5.2.6.

5.1.8. Вывод. Мы изложили, как блокчейн и сеть технологии проекта Gold Digital адекватны задаче создания Gold Платежи, платформы для немедленных денежных переводов и микроплатежей. Эта платформа может быть чрезвычайна полезна для служб, находящихся в Gold Digital, позволяя им легко собирать микроплатежи, где и когда это необходимо.

6.1.1 Классификация Блокчейн-проектов. В качестве первого шага мы предлагаем некоторые критерии классификации блокчейнов (т. е. для блокчейн-проектов). Любая такая классификация несколько неполна и поверхностна, поскольку она должна игнорировать некоторые из наиболее специфических и уникальных особенностей проектов в рамках рассмотрения. Однако мы считаем, что это необходимый первый шаг и приблизительная карта проектов блокчейн.

Список критериев, которые мы рассматриваем, следующий:

• Архитектура : один  блокчейн и мульти блокчейн архитектура (см. 6.1.2).

• Алгоритм консенсуса: «Доказательство доли» или «Доказательство работы» (см. 6.1.3).

• Для систем «Доказательство доли», точное определение (2 варианта: DPOS и BFT; см. 6.1.4)

• Поддержка «произвольных» (Turing-complete) смарт-контрактов (см. 6.1.6).

Мульти-блокчейн системы имеют дополнительные критерии классификации (см. 6.1.7) :

• Тип и правила блочейн элементов: однородные, гетерогенные (см. 6.1.8), смешанные (см. 6.1.9). Конфедерации (см. 6.1.10).

• Отсутствие или наличие мастерчейна, внутреннего или внешнего (см. 6.1.11).

• Встроенная поддержка сегментирования (см. 6.1.12). Статическое или динамическое сегментирование (см. 6.1.13).

• Взаимодействие между блочейн элементами: слабосвязанные и плотно соединенные системы (см. 6.1.14).

6.1.2. Один-блокчейн и мульти-блокчейн проекты. Первой классификацией является количество блокчейнов в системе. Старейшие и простейшие проекты состоят из одного блокчейн ("проекты единой цепочки" для краткости); более сложные проекты используют (или, скорее, планируют использовать) несколько блокчейнов («многоцепные проекты»). Проекты с одним блокчейн обычно проще и лучше тестируются; они выдержали испытание временем. Их главный недостаток-  низкая производительность или наименьшая транзакционная пропускная способность, которая находится на уровне десяти (Биткойн) до менее чем сто²³ (Эфириум) транзакций в секунду для общего назначения системы. Некоторые специализированные системы (например, Bitshares) способны обрабатывать десятки тысяч специализированных транзакций в секунду, за счет требования вписания состояния блокчейн в память и ограничения на обработку к предопределенному специальному набору транзакций, которые выполняются с помощью высоко оптимизированного кода, написанного на таких языках, как C ++ (здесь нет виртуальных машин). Проекты многоцепочные Multichain обещают масштабируемость, которой все ждут. Они могут поддерживать более крупные штаты и большую скорость операций (транзакций в секунду), за счет гораздо более сложной разработки и реализации проекта. В результате уже запущено несколько мульти-блокчейн проектов, которые являются многоканальными (многоцепными). Мы считаем, что будущее принадлежит мульти-блокчейн проектам.

23  Пока 15, но.некоторые обновления Ethereum планируют скорость транзакций в несколько раз больше.

6.1.3. Создание и проверка блоков: «Доказательство работы» или «Доказательство доли». Другим важным отличием является используемый алгоритм, протокол создания и распространения новых блоков, проверки их достоверности и выбор, если они появятся. Двумя наиболее распространенными парадигмами являются Proof-of-Work (PoW) и Proof-of-Stake (Pos). Подход Proof-of-Work обычно позволяет любому узлу создавать («добывать») новый блок (и получать некоторую награду, связанную с добычей блока), если удастся решить вычислительную проблему, включающую вычисление большого количества хэшей. В случае вилок (например, если два узла публикуют два других действующих, но разных блока, которые следуют за одним предыдущим), побеждает самая длинная вилка. Таким образом, гарантия неизменности блокчейн основано на количестве потраченной работы (вычислительных ресурсов) для создания цепочки: любому, кто хотел создать вилку из этого блокчейн потребуется повторить эту работу, чтобы создать альтернативные версии уже созданных блоков. Для этого нужно контролировать больше, чем 50% от общей вычислительной мощности, затрачиваемой на создание новых блоков, в противном случае альтернативная вилка будет иметь экспоненциально низкие шансы стать самой длинной. Подход «Доказательство доли» основан на больших ставках (номинированных в криптовалюте), сделанных некоторыми специальными узлами (валидаторами), чтобы утверждать, что они проверили (подтвердили) некоторые блоки и нашли их правильными. Валидаторы подписывают блоки и получают небольшие вознаграждения за это; однако, если валидатор когда-либо будет пойман за подписание неправильного блока и доказательство этого представлено, часть или вся его доля теряется. 

Таким образом, гарантия действительности и неизменность блочной цепи определяется общим объемом ставок валидаторов на срок действия блокчейна. Подход, основанный на Доказательстве доли, более естественен в том отношении, он стимулирует валидаторов (которые заменяют шахтеров PoW) для выполнения полезных вычислений (необходимо проверить или создать новые блоки, в частности, выполнив все транзакции, перечисленные в блоке), вместо вычисления бесполезных хэшей. Таким образом, валидаторы будут приобретать оборудование, которое лучше адаптировано для обработки пользовательских транзакций, чтобы получать вознаграждения, связанные с этими транзакциями, что представляется весьма полезной инвестицией с точки зрения системы в целом. Однако системы Proof-of-Stake несколько сложнее реализовать, потому что нужно предусмотреть множество редких, но возможных условий. Например, некоторые вредоносные валидаторы могут сговориться и нарушить работу системы для получения некоторой прибыли (например, путем изменения собственных балансов криптовалюты). Это приводит к некоторым нетривиальным теоретико-игровым задачам. Короче говоря, Proof-of-Stake является более естественным и более перспективным, особенно для многоцелевых проектов (потому что Proof-of-Work потребует запретительного количества вычислительных ресурсов, если существуют много блокчейнов), но является более тщательно продуманным и реализованным. Большинство запущенных в настоящее время блокчейн проектов, особенно самые старые (например, биткойн, оригинальный Ethereum), используют Proof-of-Work.

6.1.4. Варианты доказательства ставки. DPOS против BFT. Хотя Proof-of-Work алгоритмы очень похожи друг на друга и отличаются главным образом хэшем функции, которые должны быть рассчитаны для разработки новых блоков, больше возможностей имеются именно для алгоритмов Proof-of-Stake. Они заслуживают их подклассификации. По сути, нужно ответить на следующие вопросы об алгоритме Доказательство доли:

• Кто может произвести («добыть») новый блок - любой полный узел или только член (относительно) малого сообщества валидаторов? (Большинство систем PoS требуют, чтобы новые блоки были сгенерированы и подписаны одним из несколькими назначенными валидаторами.)

• Гарантируют ли валидаторы действительность блоков по их подписям или все ли полные узлы должны проверять все блоки самостоятельно? (Масштабируемые системы PoS должны полагаться на подписи валидатора вместо того, чтобы требовать все узлы для проверки всех блоков всех блокчейнов).

• Существует ли назначенный производитель для следующего блочейн блока, известный заранее, чтобы никто другой не мог создать этот блок?

• Является ли недавно созданный блок первоначально подписанным только одним валидатором (его производитель) или он должен собирать большинство подписей валидаторов в самом начале?

В зависимости от ответов на эти вопросы, различие на практике сводится к двум основным подходам к PoS. Большинство современных алгоритмов PoS, предназначенных для использования в масштабируемых многоцепочных системах, могут ответить на первые два вопроса: только валидаторы могут создавать новые блоки и они гарантируют блоки, не требуя, чтобы все полные узлы проверяли достоверность всех блоков сами по себе. Что касается двух последних вопросов, их ответы оказываются сильно коррелированными, оставив по существу только два основных варианта:

• Делегированная доверенность (DPOS): существует общеизвестное обозначение производителя для каждого блока; никто другой не может произвести этот блок; новый блок изначально подписывается только его валидатором.

• Византийские отказоустойчивые (BFT) алгоритмы PoS: существует известное подмножество валидаторов, любой из которых может предложить новый блок; выбор фактического следующего блока среди нескольких предложенных кандидатов, которые должны быть проверены и подписаны большинством валидаторов, перед выпуском на другие узлы, достигается версией византийской ошибки протоколом толерантного консенсуса.

6.1.5. Сравнение DPOS и BFT PoS. Подход BFT имеет преимущество того, что недавно созданный блок с самого начала имеет подписи большинства валидаторов, свидетельствующие о его действительности. Другое преимущество заключается в том, что, если большинство валидаторов выполняет консенсусный протокол BFT правильно, никакие вилки не могут появиться вообще. С другой стороны, алгоритмы BFT имеют тенденцию быть достаточно сложными и требуют больше времени для подмножества валидаторов для достижения консенсуса. Поэтому блоки не могут генерироваться слишком часто. Вот почему мы ожидаем, что Gold Blockchain (который является проектом BFT из перспектив этой классификации) создает блок только один раз каждые пять секунд. На практике этот интервал может быть уменьшен до 2-3 секунд (хотя мы не обещаем этого), если валидаторы распространяются по земному шару.

Преимущество алгоритма DPOS заключается в том, что он достаточно прост. Он может генерировать новые блоки довольно часто - скажем, раз в две секунды, или, возможно, даже раз в секунду,²⁴ из-за его зависимости от назначенных производителей блока, известных заранее. Однако DPOS требует, чтобы все узлы (или, по крайней мере, все валидаторы) проверяли все полученные блоки, поскольку валидатор, производящий и подписывающий новый блок подтверждает не только относительную справедливость этого блока, но и справедливость предыдущего блока, на который он ссылается и все блоки далее в цепочке (до начала периода ответственности текущего подмножество валидаторов). Существует предопределенный порядок для текущего подмножества валидаторов, так что для каждого блока имеется назначенный производитель (т. е. ожидается, что валидатор сгенерирует этот блок); эти назначенные производители вращаются круговым способом. Блок сначала подписывается только его валидатором производства; затем, когда следующий блок произведен, а его производитель предпочитает ссылаться на этот блок, а не на одного из своих предшественников (в противном случае его блок будет располагаться в более короткой цепочке, которая может потерять «самую длинную вилку», конкуренция в будущем), подпись следующего блока по существу является дополнительной подписью на предыдущем блоке. 

Новый блок постепенно собирает подписи валидаторов, скажем, двадцать подписей за время, необходимое для создания следующих двадцати блоков. Полному узлу необходимо подождать эти двадцать подписей, либо проверить блок самому, начиная с достаточно подтвержденного блока (скажем, двадцать блоков назад), что может быть не так просто. Очевидным недостатком алгоритма DPOS является то, что новый блок (и транзакции, совершенные в нем) достигает такого же уровня доверия («рекурсивная надежность», как описано в 2.3.28) только после того, как будут произведены еще двадцать блоков, по сравнению с алгоритмами BFT, которые обеспечивают этот уровень доверия (скажем, двадцать подписей). Другим недостатком является то, что DPOS использует подход «выбор самый длинной вилки» для переключения на другие вилки; это делает вилки вполне вероятными, если по крайней мере, некоторые производители блоков не смогут производить последующие блоки после того, что нас интересует (или мы не можем наблюдать за этими блоками из-за сетевого раздела или сложной атаки).

24 Некоторые люди даже утверждают, что время генерации блока DPOS составляет полсекунды, что не кажется реалистичным, если валидаторы разбросаны по нескольким континентам.

Мы считаем, что подход BFT более сложный для внедрения и требует более длительных интервалов времени между блоками, чем DPOS, лучше адаптирован к многоцелевым системам с плотной связью (см. 6.1.14), поскольку другие блокчейны могут начать действовать почти сразу после просмотра совершенной транзакции (например, генерирование сообщения, предназначенного для них) в новой блок, не дожидаясь 20 подтверждений действительности (т. е. следующих двадцать блоков) или в ожидании следующих шести блоков, чтобы убедиться, что нет появления вилок и проверяют новый блок сами по себе (проверка блоков других блочейн могут стать запретительными в масштабируемой многоцелевой системе). Таким образом возможно достичь масштабируемости при сохранении высокой надежности и доступности (см. 6.1.12). С другой стороны, DPOS может быть хорошим выбором для "слабосвязанных" многоцепочечных систем, где не требуется быстрое взаимодействие между блокчейнами - например, если каждый блокчейн («workchain») представляет собой отдельный распределенный обмен и межблочные взаимодействия ограничены редкими переводами из токенов от одной рабочей цепочки в другую (или, вернее, торгуют одним альткоином в одном («workchain») для другого со скоростью, приближающейся к 1 : 1).

 Это то, что фактически сделано в проекте BitShares, который использует DPOS совершенно успешно. Подводя итог, в то время как DPOS может генерировать новые блоки и включать транзакции в них быстрее (с меньшими интервалами между блоками), эти транзакции достигают уровня доверия, необходимого для их использования в других блокчейнах и приложениях, как «преданные» и «неизменные» гораздо медленнее, чем в системах BFT, скажем, за тридцать секунд²⁵ вместо пяти. Более быстрое включение транзакции не означает более быстрое обязательство по сделке. Это может стать огромной проблемой, если требуется быстрое блокчейн взаимодействие. В этом случае нужно отказаться от DPOS и вместо этого выбрать BFT PoS.

25 Например EOS, один из лучших проектов DPOS, предложенный сейчас, обещает 45-секундное подтверждение и задержку взаимодействия между блоками (см. [5], «Подтверждение транзакций», и «Задержка межцепочной связи»).

6.1.6. Поддержка Turing-полного кода в транзакциях, по существу произвольные смарт-контракты. Проекты блокчейн обычно собирают некоторые транзакции в своих блоках, которые изменяют состояние блокчейн и считаются полезными (например, перенос некоторого количество криптовалюты с одного счета на другой). Некоторые проекты блокчейн могут допускать только некоторые определенные предопределенные типы транзакций (например, перенос стоимости с одной учетной записи другим, при условии предоставления правильных подписей). Другие могут производить поддержку некоторых ограниченных форм сценариев в транзакциях. Некоторые блокчейны поддерживают выполнение произвольно сложного кода в транзакциях, позволяя системе (по крайней мере в принципе) поддерживать произвольные приложения, при условии, что производительность системы разрешена. Это обычно связано с «Turing-complete виртуальными машинами и скриптовыми языками» (означает, что любая программа, которая может быть записана на любом другом компьютерном языке, может переписываться для выполнения внутри блокчейна), и «смарт-контрактами» (которые являются программами, находящимися в блокчейне).  Конечно, поддержка произвольных смарт-контрактов делает систему действительно гибкой. 

С другой стороны, эта гибкость имеет свою цену: код этих смарт-контрактов должен выполняться на некоторой виртуальной машине и это должно выполняться каждый раз для каждой транзакции в блоке, когда кто-то хочет создать или проверить блок. Это замедляет работу системы, по сравнению со случаем предопределенного и неизменяемого набора типов простых транзакций, которые могут быть оптимизированы путем реализации их обработки в язык, такой как C ++ (вместо некоторой виртуальной машины). В конечном счете, поддержка Тьюринга - готовых смарт-контрактов, как представляется, желательна в любом универсальном блокчейн-проекте; в противном случае, дизайнеры блокчейн-проекта должны заранее решить, какие приложения блокчейн будут использоваться. Отсутствие поддержки смарт-контрактов в блокчейн Биткойн был основной причиной, почему был создан блокчейн проект Ethereum. В многоцелевой системе (гетерогенной, см. 6.1.8) возможно лучшее из обоих миров, поддержка Turing-полных смарт-контрактов в некоторых блокчейн (т. е. рабочие цепочки) и небольшой предустановленный набор высокооптимизированных транзакций в других.

6.1.7. Классификация многоцепочных систем. До сих пор классификация была действительна как для одноцепочных, так и для многоцепочных систем. Однако многоцепочные системы допускают еще несколько критериев классификации, отражающих взаимосвязь между различными блокчейнами в системе. Теперь мы обсудим эти критерии.

6.1.8. Типы блокчейнов: однородные и гетерогенные системы. В многоцепочной системе все блокчейны могут быть по существу одного типа и имеют одинаковые правила (т. е. используют одинаковый формат транзакций, одну виртуальную машину для выполнения кода смарт-контракта, используют одну криптовалюту и т. д.) и это сходство явно используется, но с разными данными в блокчейн. В этом случае мы говорим, что система однородна. В противном случае различные блокчейны (которые обычно называются workchains) могут иметь разные «правила». Тогда мы говорим, что система неоднородна.

6.1.9. Смешанные гетерогенно-однородные системы. Иногда мы имеем смешанную систему, где существует несколько наборов типов или правил для блокчейнов. Существует много блокчейнов с одинаковыми правилами и этот факт используется повсеместно. Смешанной гетерогенно-однородной системой является Gold Blockchain  - единственным пример такой системы.

6.1.10. Гетерогенные системы с несколькими workchains, имеют те же правила или конфедерации. В некоторых случаях несколько блокчейнов (workchains) с теми же правилами могут присутствовать в гетерогенной неоднородной системе, но взаимодействие между ними такое же, как между блокчейнами с разными правилами (т. е. их сходство явно не используется). Даже если они появляются для использования «одной» криптовалюты, они фактически используют разные «альткоины» (независимые воплощения криптовалюты). Иногда даже имеют механизмы для преобразования этих альткоинов со скоростью, близкой к 1: 1. Однако, это не делает систему однородной, она остается герерогенной и неоднородна. Такая гетерогенная коллекция рабочих цепей с теми же правилами - конфедерация. Создание гетерогенной системы, позволяющей создавать несколько рабочих цепочек с одинаковыми правилами (т. е. конфедерации) могут показаться дешевым способом построения масштабируемой системы, этот подход имеет множество недостатков. Если у кого-то есть большой проект во многих рабочих местах с одинаковыми правила, он не получает большой проект, а довольно много мелких примеров этого проекта. Это похоже на приложение чата (или игру), где может быть не более 50 членов в любой комнате для чата (или игры), но «Масштабирует», создавая новые комнаты для размещения большего количества пользователей, когда это необходимо. В результате многие пользователи могут участвовать в чатах или в игре, но можно ли сказать, что такая система действительно масштабируема?

6.1.11. Наличие мастерчейна, внешнего или внутреннего. Иногда, многоцелевой (многоцепной) проект имеет выдающуюся “masterchain” (иногда называемую “контроль блокчейна”), которая используется, например, для хранения общей конфигурации системы (совокупность всех активных цепей blainschains или, скорее workchains), текущий набор валидаторов (для системы Доказательства ставки) и прочее.. Иногда другие блокчейны не “привязаны” к masterchain путем совершения хэши их последних блоков (это тоже, что Gold Blockchain). В некоторых случаях masterchain является внешним и означает, что он не является частью проекта, но какой-то другой ранее существовавший блокчейн, изначально полностью не связан с его использованием новым проектом и агностиком.  Например, один может пробовать использовать блокчейн Ethereum в качестве основы мастерчейн для внешнего проекта и публикации специальных смарт-контрактов в блокчейн Ethereum для этой цели (например, для выбора и наказания валидаторов).

6.1.12. Поддержка сегментирования. Некоторые блокчейн-проекты (или системы) имеют поддержку сегментирования и означает, что несколько (обязательно однородных; см. 6.1.8) блокчейнов рассматриваются как сегменты одного (высокого уровня) виртуального блокчейна. Например, можно создать 256 сегментов цепочки (“shardchains”) с теми же правилами и сохранять состояние учетной записи только в одном сегменте, выбранном в зависимости от первого байта его кода аккаунта. Сегментирование - это естественный подход к масштабированию систем блокчейн, поскольку, если он должным образом реализован, пользователям и смарт-контрактам в системе необходимо не знать о существовании сегментов вообще. На самом деле, добавьте сегментирование в существующий одноцепочный проект (например, Ethereum), когда нагрузка становится слишком высокой. Альтернативным подходом к масштабированию будет использование «конфедерации» гетерогенных рабочих цепей, как описано в 6.1.10, позволяя каждому пользователю поддерживать его счет в одной или нескольких рабочих цепях по своему выбору и переводить средства с его счета в одной рабочей цепи workchain в другую рабочую цепь, когда это необходимо, в основном осуществляя операцию обмена алькоинов 1: 1. Недостатки этого подхода уже обсуждались в п. 6.1.10. Тем не менее, сегментирование не так просто осуществить быстрым и надежным способом, потому что это подразумевает много сообщений между различными сегментами. Например, если учетные записи распределены равномерно между N сегментами (осколками) и единственные транзакции - это простые переводы средств с одного счета на другой, а затем только небольшая часть (1 / N) всех транзакций будет выполнена в течение одного blockchain; почти все (1 - 1 / N) транзакции будут включать в себя два блокчейна, требующих межблочной связи. Если мы хотим, чтобы эти транзакции были быстрыми, нам нужна быстрая система для передачи сообщений между сегментами. Другими словами, проект блокчейн должен быть «тесно связан» в смысле, описанном в 6.1.14.

6.1.13. Динамическое и статическое сегментирование. Сегментирование может быть динамическим (если при необходимости создаются дополнительные сегменты) или статическим (когда существует предопределенное количество сегментов, которое может изменяться только через жесткую вилку в лучшем случае). Большинство предложений о сегментировании статичны; Gold Blockchain использует динамическое сегментирование.

6.1.14. Взаимодействие между блокчейнами : слабосвязанные и тесно связанные системы. Мульти-блокчейн-проекты могут быть классифицированы в соответствии с поддерживаемым уровнем взаимодействия между составными блокчейнами. Наименьший уровень поддержки - отсутствие какого-либо взаимодействия между блокчейнами вообще. Мы не рассматриваем этот случай здесь, потому что мы скорее скажем, что эти блокчейны не являются частью одной блокчейн системы, а только отдельные экземпляры одного и того же протокола блокчейн. Следующим уровнем поддержки является отсутствие какой-либо конкретной поддержки для обмена сообщениями между блокчейнами, что делает неудобным возможное взаимодействие в принципе. Мы называем такие системы «слабосвязанными»; в них нужно отправлять сообщения и передавать значение между цепочками blainschains, как если бы они были блокчейнами, принадлежавшими к совершенно различным проектам блокчейн (например, Биткойн и Эфириум; представьте себе, что две стороны хотят обменять некоторые биткойны, хранящийся в блокчейн Биткойна, в эфиры, хранящиеся в блокчейн Ethereum). Другими словами, необходимо указать исходящее сообщение (или генерирование транзакции) в блоке исходного блокчейна. Затем он (или какой-то другой участник) должны ждать достаточных подтверждений (например, заданного числа последующих блоков), чтобы считать инициируемую сделку «совершенной» и «неизменной», чтобы иметь возможность выполнять внешние действия, основанные на его существовании.

Только тогда транзакция может ретранслировать сообщение в целевой объект блокчейн (возможно, наряду со ссылкой и доказательством существования Меркле для исходящей транзакции). Если вы не ожидаете достаточно долго, прежде чем передавать сообщение или если в любом случае вилка происходит по какой-то другой причине, объединенное состояние двух блокчейнов оказываются несовместимым: сообщение доставляется во второй блокчейн, который никогда не был создан (в конечном итоге выбрана вилка) первым блочейном. Иногда добавляется частичная поддержка обмена сообщениями путем стандартизации формата сообщений и расположением входных и выходных очередей сообщений в блоки всех рабочих цепей (это особенно полезно в гетерогенных системах). Хотя это облегчает обмен сообщениями в определенной степени, это концептуально не слишком отличается от предыдущего случая, поэтому такие системы все еще «слабо связаны». 

В отличие от этого, «тесно связанные» системы включают специальные механизмы для обеспечения быстрого обмена сообщениями между всеми цепочками blainschains. Желаемое поведение должно быть в состоянии доставить сообщение в другую рабочую цепочку сразу после генерации в блоке исходного блокчейна. С другой стороны, ожидается, что системы с жесткой связью сохранят общую согласованность в случае вилок. Хотя эти два требования кажутся противоречивыми на первый взгляд, мы считаем, что механизмы, используемые Gold Blockchain (включение хэшей блока shardchain в блоки masterchain, использование «вертикальных» блоков для фиксации недопустимых блоков, см. 2.1.17; маршрутизация гиперкуба, мгновенная маршрутизация Гиперекуба, позволяют создать «плотно связанную» систему, возможно, единственную до сих пор. Конечно, создание «слабосвязанной» системы намного проще; однако, быстрое и эффективное сегментирование (см. 6.1.12) требует, чтобы система была «плотно соединена».

6.1.15. Упрощенная классификация. Поколения блочейн проектов. Классификация, которую мы предположили до сих пор, разделяет все проекты блочейн в большое количество классов. Однако критерии классификации, которые мы используем, вполне полно представлены на практике. Это позволяет нам предложить упрощенный «Поколенческий» подход к классификации проектов блочейн, как очень грубое приближение реальности, с некоторыми примерами. Проекты, которые не были реализованы и развернуты выделены курсивом; самые важные характеристики поколения выделены жирным шрифтом.

• Первое поколение: одноцепочное, PoW, отсутствие поддержки смарт-контрактов. Примеры: биткойн (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, поддержка смарт-контрактов, плотно-соединенный с сегментированием. Примеры: Gold Digital (2018).

Не все блокчейн-проекты попадают в одну из этих категорий, но большинство из них представлены.

6.1.16. Осложнения изменения «генома» блокчейн проекта

Приведенная выше классификация определяет «геном» блокчейн проекта. Этот геном довольно «жесткий»: его практически невозможно изменить, как только проект будет развернут и будет использоваться многими людьми. Нужны серии жестких вилок (для чего потребуется одобрение большинства сообщество) и даже тогда изменения должны быть очень консервативными, чтобы сохранить обратную совместимость (например, изменение семантики виртуальной машины может нарушить существующие смарт-контракты). Альтернативой было бы создание новых «боковых цепей» "sidechains" с их различными правилами и привязкой к блокчейну (или цепочки) исходного проекта. Можно использовать блокчейн существующего проекта с одним блокчейном, как внешний мастерчейн для принципиально нового и отдельного проекта.²⁶ Наш вывод состоит в том, что геном проекта очень трудно изменить после его развертывания. Даже начиная с PoW и планируя заменить это на PoS в будущем, довольно сложно.²⁷ Добавление сегментов в проект, который первоначально был разработан без их поддержки, кажется почти невозможным.²⁸ Поддержка смарт-контрактов в проект (а именно, биткойн), первоначально разработанный без таких функций, признана невозможной (или, по крайней мере, нежелательным большинством сообщества Биткойна), что в конечном итоге привело к созданию нового проекта блокчейн Ethereum.

26 Например, проект Plasma планирует использовать блокчейн Ethereum в качестве своего (внешнего) masterchain; в противном случае он мало взаимодействует с Ethereum и это предлагается и внедряется командой, не связанной с проектом Ethereum.

27 В 2017 году Ethereum по-прежнему пытается перейти от PoW к комбинированной системе PoW + PoS; мы надеемся, что когда-нибудь это станет действительно системой PoS.

28 Есть предложения о сегментировании Ethereum, датируемое в 2015 году; неясно, как они могут быть реализованы и развернуты без разрушения Ethereum или создания практически независимого параллельного проекта.

6.1.17. Геном Gold Blockchain. Если кто-то хочет построить масштабируемую систему блокчейнов, нужно тщательно выбирать ее геном с самого начала. Если система предназначена для поддержки некоторых дополнительных конкретных функций в будущем, неизвестных на момент ее развертывания, он должен поддерживать «гетерогенные» рабочие цепочки (имеющие потенциально разные правила), с самого начала. Чтобы система была действительно масштабируемой, она должна поддерживать сегментирование с самого начала; сегментирование имеет смысл, только если система является "тесно связанной" (ср. 6.1.14), это, в свою очередь, подразумевает существование masterchain, быстрой системы межведомственного блокчейн обмена сообщениями, использование BFT PoS и так далее. Когда учитываются все эти последствия, большая часть выбора дизайна, сделанная для проекта Gold Блокчейн выглядит естественным и почти единственно возможным.

Таблица 1: Краткий обзор некоторых заметных проектов блокчейн.

R. - гетерогенные / однородные многоканальные системы (см. 6.1.8);

Int. - взаимодействие между цепями, (L) свободное или (T) плотное (см. 6.1.14). 

Мы завершаем наше краткое обсуждение Gold Blockchain и его наиболее важные и уникальные возможности, пытаясь найти место для него на карте, содержащей существующие и предлагаемые проекты блочейн. Мы используем критерии классификации, описанные в п. 6.1, чтобы обсуждать различные проекты блокчейн единообразно и построить такую «карту проектов блокчейн». Мы представляем это отображение, как Таблица 1, а затем кратко обсудим несколько проектов отдельно, чтобы указать их особенности, которые могут не вписываться в общую схему.

6.2.1. Биткойн [12]; https://bitcoin.org/. Биткойн (2009) является первым и самый известным проектом blockchain. Это типичный проект блокчейн первого поколения: он одноцепочный, использует доказательство работы с "длинной вилкой выигрышей" алгоритма выбора вилки,  у него нет полного сценария Turing языка (однако поддерживаются простые скрипты без петель). Биткойн blockchain не имеет понятия учетной записи; он использует UTXO (Неизрасходованный вывод транзакций) вместо модели.

6.2.2. Эфириум [2]; https://ethereum.org/. Ethereum (2015) – это первый блокчейн с поддержкой Тьюринга -полные смарт-контракты. По существу, это типичный проект второго поколения и самый популярный среди них. Он использует доказательство работы на одном блокчейне, но имеет смарт- контракты.

6.2.3. NXT; https://nxtplatform.org/. NXT (2014) является первымна основе PoS блокчейн и валюта. Он по-прежнему одноцепочный и не имеет поддержки смарт-контрактов.

6.2.4. Tezos; https://www.tezos.com/. Tezos (2018 или позже) предлагается PoS-проект на основе одного блокчейна. Мы упомянули об этом здесь из-за его уникальной особенности: его функция интерпретации блока ev_block не фиксированная, а определяется модулем OCaml, который может быть обновлен путем ввода новой версии в блокчейн (собрав голоса для предлагаемого изменения). Таким образом, вы сможете создавать собственные одноцепочные проекты, сначала развертывая «ванильный» блокчейн Tezos, а затем постепенно меняя функцию интерпретации блока в желаемом направлении, без каких-либо трудностей и хардфорка. Эта идея, хотя и интригующая, имеет очевидный недостаток, она запрещает любые оптимизированные реализации на других языках, таких как C ++, поэтому на основе Tezos блокчейн суждено иметь более низкую производительность. Мы считаем, что аналогичный результат мог быть получен путем публикации официальной спецификации предлагаемой функция для интерпретации блока ev_trans без фиксации конкретной реализации.

6.2.5. Casper.²⁹ Каспер - предстоящий алгоритм PoS для Ethereum; его постепенное развертывание в 2018 году, в случае успеха, изменит Эфириум на одноцепочный PoS или смешанную систему PoW + PoS с поддержкой смарт-контрактов, превращая Ethereum в проект третьего поколения.

29 https: //blog.ethereum.org/2015/08/01/introducing-casper-friendly-ghost/

6.2.6. BitShares [8]; https://bitshares.org. BitShares (2014) - это платформа для распределенных блокчейн обменов. Это гетерогенная мульти-блокчейн-система DPoS без смарт-контрактов; достигает своей высокой производительности разрешая только небольшой набор предопределенных специализированных типов транзакций, которые могут быть эффективно реализованы на C++, предполагая, что блокчейн состояние вписывается в память. Это также первый проект blockchain для использования делегированных доказательств доли (DPoS), демонстрирующий его жизнеспособность для некоторых специализированных целей.

6.2.7. EOS [5]; https://eos.io. EOS (2018 или новее) является предлагаемой гетерогенной мульти-блокчейн системой DPoS с поддержкой смарт-контрактов и с некоторой минимальной поддержкой обмена сообщениями (все еще слабо связанными в смысле, описанном в пункте 6.1.14). Это попытка той же команды, которая ранее успешно создала проекты BitShares и SteemIt, продемонстрировав сильные точки алгоритма согласования DPoS. Масштабируемость будет достигнута путем создания специализированных рабочих мест для проектов, которые в этом нуждаются (например, распределенный обмен может использовать workchain, поддерживающий специальный набор оптимизированных транзакций, аналогично тому, что делал BitShares) путем создания нескольких рабочих цепей с теми же правилами (конфедерация в смысле, описанном в 6.1.10). Недостатки и ограничения этого подхода к масштабируемости были обсуждены, см. 6.1.5, 6.1.12 и 6.1.14 для более подробного обсуждения DPoS, сегментов, взаимодействия между рабочими цепями и их последствия для масштабируемости блокчейн. В то же время, даже если человек не сможет «создать Facebook внутри блокчейн» (см. 6.2.13), EOS может стать удобной платформой для некоторых высокоспециализированных слабо взаимодействующих распределенные приложений, похожих на BitShares (децентрализованная биржа) и SteemIt (децентрализованная платформа блога).

6.2.8. PolkaDot [17]; https://polkadot.io/. PolkaDot (2019 или новее) является одним из лучших продуманных и наиболее подробных предлагаемых многоцепных проектов доказательством доли; его развитие возглавляет один из основателей Ethereum. Этот проект является одним из ближайших проектов с Gold Blockchain (мы обязаны нашей терминологии «рыбаки» и «номинаторы» проекту PolkaDot.) PolkaDot - гетерогенный слабосвязанный многоцепной проект с консенсусом по византийскому отказу (BFT) для создания новых блоков и masterchain (которые могут быть внешними, например, Ethereum blockchain). Он также использует маршрутизацию гиперкуба, несколько похожую (медленная версия) на Gold. Его уникальной особенностью является способность создавать не только публичные, но и частные блокчейны, которые могут взаимодействовать с другими общественными блокчейн проектами. Таким образом, PolkaDot может стать платформой для крупномасштабных частных блокчейнов, которые могут быть использованы, например, банковскими консорциумами для быстрого перевода средств друг другу или для любых других целей крупной корпорации, в том числе для частной технологии blockchain. Однако PolkaDot не имеет поддержки сегментирования и не плотно связан. Это несколько затрудняет его масштабируемость, что аналогично EOS. (Может быть, немного лучше, потому что PolkaDot использует BFT PoS вместо DPoS.)

6.2.9. Universa; https://universa.io. Единственная причина, по которой мы говорим об этом необычном проекте блокчейн здесь, потому что это единственный проект сейчас, который проделал явную ссылку на нечто подобное нашей Бесконечной парадигме сегментирования (см. 2.1.2). Другая его особенность заключается в том, что этот проект обходит все осложнения, связанные с византийской отказоустойчивостью, пообещав, что только доверенные и лицензированные партнеры проекта будут допущены в качестве валидаторов, поэтому они никогда не будут создавать недействительные блоки. Это интересное решение, однако он по сути делает блокчейн проект намеренно централизованным, чего блокчейн-проекты обычно хотят избежать (зачем нужен блокчейн для работы в надежной централизованной среде?).

6.2.10. Плазма; https://plasma.io). Плазма (2019 г.) – нетрадиционный блокчейн проект от другого соучредителя Ethereum. Предлагается для смягчения некоторых ограничений Ethereum, без введения сегментирования. По сути, это отдельный проект от Ethereum, представляющий иерархию (гетерогенных) цепей, привязанных к блокчейн Ethereum (использование в качестве внешнего masterchain) на верхнем уровне. Средства могут быть переведены из любого блокчейн в иерархии (начиная с Ethereum блокчейн как корень), вместе с описанием работы, которую предстоит выполнить. Затем необходимые вычисления выполняются в дочерней рабочей цепочке (возможно, требующей переадресация частей исходного задания дальше по дереву), их результаты передаются вверх и награда собрана. Проблема достижения согласованности и проверка этих рабочих мест создает механизм (оплата на канале), позволяющий пользователям в одностороннем порядке выводить свои средства от плохой рабочей цепочки workchain к ее родительской рабочей цепочке (хотя и медленно), и перераспределить свои средства и их рабочие места на другую рабочую цепь. Таким образом, Плазма может стать платформой для распределенных вычислений связанный с блокчейн Ethereum, что-то вроде «математического  сопроцессора». Однако это не похоже на способ достижения истинной общей цели масштабируемости.

6.2.11. Специализированные блокчейн-проекты. Есть также некоторые специализированные блокчейн-проекты, такие как FileCoin (система, которая стимулирует пользователей предлагать их дисковое пространство для хранения файлов другим пользователям, которые готовы платить за это), Golem (блокчейн платформа для аренды и кредитования вычислительной мощности для специализированных приложений, таких как 3D-рендеринг) или SONM (другой аналогичный проект энергетического кредитования). Такие проекты не вводят что-либо принципиально новое на уровне блочейн организации; скорее, они являются конкретными блокчейн-приложениями, которые могут быть реализованы посредством смарт-контрактов, работающие в блокчейне общего назначения,  при условии, что она может обеспечивают требуемую производительность. Таким образом, проекты такого рода, вероятно, используют один из существующих или планируемых блокчейн проектов в качестве их базы, такой как EOS, PolkaDot или Gold. Если для проекта требуется «истинная» масштабируемость (на основе сегментирования), лучше использовать Gold Digital; если он удовлетворен работой в «конфедерации», определил семейство собственных цепей и явно оптимизирован для своей цели, он может выбрать EOS или PolkaDot.

6.2.12. Gold Блокчейн. Gold Blockchain, запланированный в 2018 г. - это проект, предназначенный для того, чтобы стать первым проектом блокчейн пятого поколения, то есть BFT PoS многоцепочный многоканальный проект, смешанный однородный / гетерогенный, с поддержкой пользовательских рабочих цепей со встроенной сегментацией (в частности, возможность пересылки сообщений между сегментами почти мгновенно, сохраняя согласованное состояние всех сегментов цепи. Это будет по-настоящему масштабируемый блокчейн-проект общего назначения, способный принимать практически любые приложения, которые могут быть реализованы в блокчейне вообще. При добавлении других компонентов в Gold Digital проект (см. 1), его возможности расширяются еще больше.

6.2.13. Возможно ли «загрузить Facebook в блокчейн? Иногда люди утверждают, что можно будет реализовать социальную сеть масштабом Facebook, как распределенное приложение, находящееся в блокчейне. Обычно блокчейн-проект цитируется, как возможный «хостинг» для такого заявления. Мы не можем сказать, что это техническая невозможно. Конечно, нужен плотно связанный блокчейн-проект с истинным сегментированием (т.е. Gold Digital), чтобы для такого большого приложения не работать слишком медленно (например, доставлять сообщения).

6.2.14. Сравнение с другими Блокчейн-проектами и обновления от пользователей, расположенных в одной shardchain для своих друзей, расположенных в еще одной shardchain с разумными задержками). Однако мы считаем, что это не нужно и никогда не будет сделано, потому что цена будет непомерно высокой. Давайте рассмотрим «загрузку Facebook в блокчейн», как эксперимент; В качестве примера можно привести и любой другой проект подобного масштаба. Как только Facebook будет загружен в блокчейн, все выполненные операции серверами Facebook будут сериализованы как транзакции в определенных блок-цепях (например, сегменты Gold) и будут выполняться всеми валидаторами этих блокчейнов. Каждая операция должна быть выполнена, скажем, по меньшей мере двадцать раз, если мы ожидаем, что каждый блок будет собирать не менее 20 валидаторных подписей (сразу или в конце концов, как в системах DPOS). Аналогичным образом, все данные, хранящиеся на серверах Facebook на своих дисках будут храниться на дисках всех валидаторов для соответствующей shardchain (то есть, по меньшей мере, в 20 экземплярах). Валидаторы представляют собой одни и те же серверы (или, возможно, кластеры серверов, это не влияет на достоверность этого аргумента), как те, которые в настоящее время используется Facebook, мы видим, что расходы, связанные с аппаратным обеспечением Facebook в блокчейне в двадцать раз выше, чем если бы это было реализовано обычным способом. Расходы будут намного выше, потому что виртуальная машина работает медленнее, чем «голый процессор», работающий оптимизированный скомпилированный код и его хранилище не оптимизированы для проблем, связанных с Facebook. 

Один может частично смягчить эту проблему, создав конкретную рабочую цепь с помощью специальных транзакций, адаптированные для Facebook; это подход BitShares и EOS для достижения высокой производительности, доступных в Gold Blockchain. Общая конструкция блокчейн будет налагать некоторые дополнительные ограничения, такие как необходимость регистрации всех операций как транзакции в блоке, организовать эти транзакции в Дерево Merkle, чтобы вычислить, проверить их хеши Merkle, распространить блок дальше и прочее. Поэтому консервативная оценка заключается в том, что нужно в 100 раз больше серверов той же производительности, что те, которые используются Facebook сейчас, чтобы утвердить блокчейн-проект, в котором размещена социальная сеть такого масштаба. Кому то придется оплачивать эти серверы, либо компании, владеющей распределенными приложениями (представьте себе, видя 700 объявлений на каждой странице Facebook вместо 7) или его пользователям. В любом случае, это не кажется экономически жизнеспособным. Мы считаем, что не все должно быть загружено в blockchain. Нет необходимости сохранять пользовательские фотографии в blockchain; регистрируя хэши этих фотографий в блочной цепи и хранение фотографий в распределенном хранилище вне сети (например, FileCoin или Gold Storage) было бы лучшей идеей.

Вот почему Gold не просто блокчейн-проект, а набор из нескольких компонентов (Gold P2P Сеть, Gold Storage, Gold Services), сосредоточенные вокруг Gold Blockchain как указано в главах 1 и 4.