Whitepaper проекта Elrond

Аннотация

Появление безопасных общедоступных блокчейнов, таких как Bitcoin и Ethereum, вызвало значительный интерес и приток капитала, создающих предпосылки для волны глобальных инноваций.

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

В данном материале речь пойдет о проекте Elrond.

Это оригинальная архитектура, которая выходит за рамки существующих решений, благодаря представленной схеме разделения состояний (стейт-шардинга) для практической масштабируемости, устранения потерь энергии и вычислительных ресурсов, при распределенном обеспечении прозрачности посредством консенсуса Secure Proof of Stake (SPoS)

Уделяя особое внимание безопасности, сеть Elrond построена так, чтобы гарантировать устойчивость против известных проблем безопасности, таких как атака Сибиллы (Sybil attack), атаки “Nothing at stake” и других.

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

Предварительное моделирование и результаты тестовой сети показали, что Elrond превышает среднюю пропускную способность Visa и достигает улучшений производительности на 3 порядка или в 1000 раз по сравнению с существующими решениями.

При этом снижаются затраты на загрузку и хранение данных, обеспечивая долгосрочное функционирование.

I — Вступление

1.1 — Общие аспекты

Криптовалюта и платформы смарт-контрактов, такие как Bitcoin и Ethereum, вызвали значительный интерес и стали перспективными решениями для электронных платежей, децентрализированных приложений и, в перспективе, цифровых средств сбережения.

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

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

Было предложено несколько решений, но немногие из них показали хорошие результаты.

Таким образом, чтобы решить проблему масштабируемости, требовалось полностью переосмыслить инфраструктуру блокчейна.

1.2 — Определение проблем

В процессе поиска решения для инновационного блокчейна, рассчитанного на масштабирование, необходимо решить несколько задач:

• Полная децентрализация — устранение необходимости в стороннем доверенном лице и исключение единой точки отказа;
• Надежная защита — обеспечение безопасных транзакций и предотвращение любых известных векторов атак;
• Высокая масштабируемость — обеспечение способности сети достигать результатов производительности, измеряющейся в транзакциях в секунду (TPS), не ниже, чем у централизованных аналогов;
• Эффективность — обеспечение функционирования всех сервисов при минимальных потерях энергии и вычислительных ресурсов;
• Упрощение синхронизации и хранения — обеспечение конкурентноспособной стоимости хранения, синхронизации и начальной загрузки данных;
• Кросс-чейн взаимодействие — реализованное на уровне дизайна неограниченное взаимодействие с внешними сервисами.

Исходя из вышеперечисленных задач, мы создали Elrond, как полное переосмысление инфраструктуры блокчейна, который был специально разработан, чтобы быть безопасным, эффективным, масштабируемым и совместимым.

Главный вклад Elrond основан на двух ключевых элементах:

1. Принцип настоящего сегментирования: эффективное разделение блокчейна и учётных записей на несколько сегментов (шардов), обрабатываемых параллельно различными участвующими валидаторами;
2. Механизм консенсуса Secure Proof of Stake (SPoS): улучшенный вариант консенсуса Proof of Stake (PoS), который обеспечивает устойчивую безопасность и достоверность, устраняя при этом потребность в энергоемких алгоритмах Proof of Work (PoW).

1.3 — Адаптивное сегментирование

Elrond предлагает динамический адаптивный механизм шардирования, обеспечивающий формирование сегментов и их реорганизацию в зависимости от необходимости и количества активных сетевых узлов.

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

По сравнению со статичной моделью у адаптивного сегментирования есть дополнительные проблемы.

Один из ключевых моментов заключается в том, чтобы предотвратить общие задержки, вызванные потребностями синхронизации во время смены сегментов при разделении и объединении шардов.

Задержки в данном случае — это вычисления и коммуникации, необходимые узлам, чтобы получить актуальное состояние, как только изменилось адресное пространство сегмента.

Решение этой проблемы в Elrond описано ниже, но сначала необходимо определить некоторые понятия: пользователи и узлы.

• Пользователи — это внешние субъекты и они могут быть распознаны по уникальному адресу учетной записи;
• Узлы — это компьютеры/устройства в сети Elrond, на которых работает наш протокол.

Такие понятия, как пользователи, узлы, адреса, будут более подробно описаны во 2-й главе, 1-м пункте (Субъекты).

Проблемы адаптивного сегментирования Elrond решает следующим образом:

1 — При разделение адресного пространства используется бинарное дерево, которое может быть построено с единственным требованием — знание точного количества сегментов в определённой эпохе.

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

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

Во-вторых, задержка уменьшается благодаря механизму резервирования состояния, поскольку слияние происходит путем синхронизации состояния в родственных узлах.

2 — Внедрение техники балансировки узлов в каждом сегменте для достижения общего архитектурного равновесия.

Этот механизм обеспечивает сбалансированную рабочую нагрузку и вознаграждение для каждого узла в сети.

3 — Разработка встроенного механизма автоматической маршрутизации транзакций в соответствующие сегменты значительно уменьшает задержку.

Алгоритм маршрутизации описан в 4-й главе, 4-м пункте (Подход к сегментированию Elrond).

4 — В Elrond реализуется механизм обрезки (сокращения) данных, чтобы значительно ускорить начальную загрузку и сократить затраты на хранение данных.

Это обеспечивает устойчивость архитектуры даже при производительности в десятки тысяч транзакций в секунду (TPS).

1.4 — Secure Proof of Stake (SPoS)

Мы представляем механизм консенсуса Secure Proof of Stake, который развивает идею Algorand о механизме случайного выбора и отличается в следующих аспектах:

1 — Elrond представляет улучшение, которое уменьшает задержку, позволяя любому узлу в сегменте становиться участником группы консенсуса (заявителем или валидатором блока) в начале каждого раунда.

Это возможно потому, что переменная рандомизации r хранится в каждом блоке и создается заявителем блока с помощью подписи BLS в предыдущем раунде.

2 — Заявитель блока — это валидатор в консенсусной группе, у которого хэш открытого ключа и фактор рандомизации является наименьшим.

В отличие от подхода Algorand, где выбор группы может занять до 12 секунд, в Elrond время, необходимое для случайного выбора консенсусной группы, значительно сокращено (по оценкам, менее 100 мс без учёта сетевой задержки).

В действительности для этого процесса не требуется связь, что позволяет Elrond иметь случайно выбранную группу, которой удается зафиксировать новый блок в каждом раунде.

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

Дальнейшим улучшением безопасности источника случайности может стать использование проверяемых функций задержки (VDF), чтобы своевременно предотвратить любую возможность фальсификации источника.

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

3 — В дополнение к фактору ставки, обычно используемому в архитектурах PoS в качестве единственного критерия для принятия решения, Elrond совершенствует свой механизм консенсуса, добавляя дополнительную переменную веса, которая называется рейтингом.

Вероятность того, что узел будет выбран группой консенсуса, учитывает ставку и рейтинг.

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

4 — Для подписания блоков группой консенсуса используется модифицированная схема мультиподписи (BLS) с двумя раундами связи.

5 — Elrond обеспечивает формальную проверку выполнения критических протоколов (например, механизма консенсуса SPoS) для того, чтобы подтвердить правильность работы алгоритмов.

II — Обзор архитектуры

2.1 — Субъекты

В Elrond есть 2 основных субъекта: пользователи и узлы.

• Пользователи, каждый из которых владеет (конечным) количеством пар открытых/закрытых (Pk/sk) ключей (например, в одном или нескольких приложениях кошельков), используют сеть Elrond для совершения транзакций передачи ценностей или для исполнения смарт-контрактов.

Они могут быть распознаны по одному из адресов их учетных записей (полученных из открытого ключа).

• Узлы представлены устройствами, которые формируют сеть Elrond, они могут быть пассивными или активно вовлеченными в задачи обработки транзакций.

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

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

Взаимодействие между субъектами в протоколе Elrond показаны на
рис. 1.

Кроме того, сеть делится на части, называемые сегменты (шарды).

Валидатор назначается определённому сегменту на основе алгоритма, обеспечивающего равномерное распределение узлов в зависимости от уровня дерева.

Каждый шард содержит случайно выбранную группу консенсуса.

Заявитель блока отвечает за формирование нового блока, объединяющего транзакции в своём сегменте.

Валидаторы могут отклонить или одобрить предложенный блок, тем самым подтверждая его и фиксируя его в блокчейне.

2.2 — Внутренний токен

Elrond предоставляет доступ к использованию своей сети посредством внутренних токенов, сокращенно называемых ERD.

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

Предполагается, что ссылки на взносы (ставки), платежи и балансы аккаунтов будут номинированы в ERD.

2.3 — Модель угрозы

Elrond предполагает византийскую модель достоверности, в которой по крайней мере 2/3n+1 узлов в сегменте являются добросовестными.

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

Пока 2/3n+1 валидаторов в сегменте являются достоверными, протокол может достичь консенсуса.

Протокол предполагает наличие злоумышленников, которые, однако, не смогут адаптироваться быстрее, чем время одного раунда.

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

Предполагается, что сеть честных узлов образует хорошо связный граф, а передача их сообщений осуществляется за ограниченное время ∆.

Предотвращение векторов атак

1. Атаки Sybil: смягчаются с помощью блокировки ставок при присоединении к сети. Таким образом, создание новых идентификаторов имеет стоимость, равную минимальной ставке;
2. Nothing at stake: устраняется благодаря необходимости наличия нескольких подписей, а не только от заявителя блока и блокировки ставки. Вознаграждение за блок по сравнению с заблокированной ставкой делает невыгодным такое поведение;
3. Long range attacks: смягчаются механизмом отсечения, использованием случайно выбранной группы консенсуса в каждом раунде и блокировкой ставки. Кроме того, наш алгоритм консенсуса pBFT гарантирует конечность;
4. DDoS-атаки: группа консенсуса выбирается случайным образом каждый раунд (несколько секунд); небольшой промежуток времени делает DDoS практически невозможным.

Другие виды атак, которые мы принимали во внимание, это: атака с захватом сегмента, усечение транзакций, двойные траты, атаки с подкупом и т. д.

2.4 — Хронология

В сети Elrond временная шкала разделена на эпохи и раунды.

• Эпохи имеют фиксированную продолжительность, установленную в один день (может быть изменена по мере развития архитектуры), в конце которой запускается реорганизация и обрезка сегментов.
• Эпохи далее делятся на раунды, длящиеся на протяжении фиксированного времени.

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

Новые валидаторы могут присоединиться к сети, заблокировав свою ставку, как представлено в 5-йглаве, 2-м пункте (Secure Proof of Stake).

Они добавляются в пул неназначенных узлов в текущей эпохе e и в список ожидания шарда в начале эпохи e + 1, но могут стать правомочными валидаторами для участия в консенсусе и получить вознаграждение только в следующую эпоху e + 2.

Аспекты временной шкалы более подробно описаны в 9-й главе, 1-м пункте.

III —Связанные работы

Elrond был разработан на основе и под влиянием идей из Ethereum, Omniledger, Zilliqa, Algorand и ChainSpace.

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

3.1 — Ethereum

Большая часть успеха Ethereum может быть приписана внедрению его децентрализованного уровня приложений с помощью EVM, Solidity и Web3j.

В то время, как Dapps были одной из основных особенностей Ethereum, масштабируемость оказалась серьезным ограничением.

Значительное количество исследований было проведено для решения этой проблемы, однако они не дали значительных результатов.

Тем не менее, было предложено несколько перспективных решений: Casper готовит обновление, которое позволит заменить текущий консенсус Proof of Work (PoW) на Proof of Stake (PoS), в тоже время как дополнительные цепочки и шардирование на основе Plasma, как ожидается, станут доступны в ближайшем будущем.

Это хотя бы частично решит проблему масштабируемости Ethereum.

По сравнению с Ethereum, Elrond устраняет потери как энергии, так и вычислительных ресурсов алгоритмов PoW путем реализации SPoS-консенсуса, используя параллелизм обработки транзакций.

3.2 — Omniledger

Omniledger предлагает новый, горизонтально масштабируемый, распределенный, инклюзивный реестр.

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

Атомарная фиксация транзакций между сегментами Omniledger представлена Atomix, эффективным протоколом межсегментной фиксации.

Его концепция представляет собой управляемый клиентом двухфазный протокол "блокировка/разблокировка", который гарантирует, что узлы могут либо полностью зафиксировать транзакцию между шардами, либо получить "доказательство отказа" для прерывания и разблокировки состояния, затронутого частично завершенными транзакциями.

Omniledger также оптимизирует производительность за счет параллельной внутрисегментной обработки транзакций, обрезки реестра с помощью коллективно подписанных блоков и проверки "доверяй, но проверяй" с малой задержкой для транзакций с низкой стоимостью.

Консенсус, используемый в Omniledger, представляет собой вариант BFT, названный ByzCoinX, который повышает производительность и устойчивость к DoS-атакам.

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

3.3 — Zilliqa

Zilliqa — это первая архитектура разделения транзакций, которая позволяет сети майнинга обрабатывать транзакции параллельно и достигать высокой пропускной способности за счет шардирования.

В частности ее конструкция позволяет увеличить скорость транзакций, присоединяя к сети все больше узлов.

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

Zilliqa использует pBFT для консенсуса и PoW для идентификации и предотвращения атаки Sybil.

По сравнению с Zilliqa, в Elrond реализуется не только сегментирование транзакций, но также и состояний.

Elrond полностью исключает механизм PoW и использует SPoS для консенсуса.

Обе архитектуры создают свой собственный механизм смарт-контрактов, но Elrond нацелен не только на соответствие с EVM, чтобы смарт-контракты, написанные для Ethereum, работали без проблем на нашей виртуальной машине, но также стремится достичь совместимости между блокчейнами.

3.4 — Algorand

Algorand предлагает открытый реестр, который сохраняет удобство и эффективность централизованных систем без недостатков текущих децентрализованных решений.

«Лидер» и набор верификаторов выбираются случайным образом, на основе их подписи, примененной к количественному значению последнего блока.

Выборы не подвержены манипуляциям и непредсказуемы до последнего момента. Консенсус опирается на новое византийское соглашение передачи сообщений, которое позволяет протоколу развиваться без хард-форков.

По сравнению с Algorand, Elrond не имеет единого блокчейна, вместо этого он увеличивает пропускную способность транзакций с помощью сегментирования.

Elrond также улучшает идею случайного выбора Algorand, сократив время выбора группы консенсуса с более чем 12 секунд до менее секунды и предполагает, что злоумышленик не cможет адаптироваться в рамках раунда.

3.5 — Chainspace

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

Для расширяемости она использует конфиденциальные и независимые от языка смарт-контракты.

Сегментированная архитектура позволяет линейно масштабировать пропускную способность с помощью S-BAC, нового распределенного протокола атомарной фиксации, который гарантирует согласованность и обеспечивает высокую контролируемость.

Функции конфиденциальности реализуются с помощью современных методов нулевого знания, а консенсус обеспечивается BFT.

По сравнению с Chainspace, где TPS уменьшается с каждым добавленным узла в сегмент, подход Elrond не зависит от количества узлов в сегменте, поскольку группа консенсуса имеет фиксированный размер.

Сильной стороной Chainspace является подход к смарт-контрактам, не зависящим от языка, в то время как Elrond фокусируется на создании слоя абстракции для совместимости с EVM.

Оба проекта используют различные подходы разделения состояний для повышения производительности.

Однако Elrond идет на шаг дальше, прогнозируя проблему размера блокчейна в архитектурах с высокой пропускной способностью и используя эффективный механизм обрезки.

Более того, Elrond демонстрирует более высокую устойчивость к внезапным изменениям в количестве узлов и злонамеренному захвату сегмента путем введения избыточности сегментов.

Это новые функции для шардированных блокчейнов.

IV — Масштабируемость за счёт адаптивного сегментирования состояний

4.1 — Зачем нужно сегментирование

Шардирование впервые было использовано в базах данных и представляет собой метод распределения данных между несколькими узлами.

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

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

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

4.2 — Типы сегментирования

Выделяются 3 основных типа сегментирования:

• Сетевое сегментирование
• Сегментирование транзакций
• Сегментирование состояний.

1 — Сетевое сегментирование определяет способ группировки узлов и может использоваться для оптимизации коммуникаций, поскольку распространение сообщений внутри сегмента может быть выполнено намного быстрее, чем распространение по всей сети.

Первая проблема в подходах к сегментированию заключается в механизмах сопоставления узлов. Он должен принимать во внимание возможность атаки со стороны злоумышленников, которые получают контроль над определенным сегментом.

2 — Разделение транзакций реализует способ распределения транзакций между сегментами для их обработки. Транзакции могут быть назначены на основе адреса отправителя.

3 — Сегментирование состояния является наиболее сложным подходом.

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

Транзакции, затрагивающие адреса, которые находятся в разных частях блокчейна, должны обмениваться сообщениями и синхронизировать состояния.

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

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

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

4.3 — Направления сегментирования

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

Тем не менее, в последнее время было сделано по крайней мере одно заявление об успешном выполнении как сегментирования транзакций, так и состояний, без ущерба для хранения или вычислительной мощности.

Однако сегментирование создает некоторые новые проблемы, такие как:

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

При условии, что вышеперечисленные проблемы будут решены, сегментирование состояний принесет значительные общие улучшения:

Пропускная способность значительно увеличивается благодаря параллельной обработке транзакций, а плата за транзакции будет значительно снижена.

Два основных критерия, которые широко рассматриваются как препятствия, станут преимуществом и стимулом для массового принятия технологии блокчейна.

4.4 — Сегментирование Elrond

Несмотря на сложности разделения сети, транзакций и состояний, Elrond был разработан с учетом следующих целей:

1. Масштабируемость без ущерба для доступности: увеличение или уменьшение количества шардов должно влиять на пренебрежимо малую часть узлов, не вызывая простоев или сводя их к минимуму при обновлении состояний;
2. Координация и мгновенная отслеживаемость: определение сегмента для обработки транзакции должно быть однозначным, легко вычисляемым, устраняющим необходимость согласований;
3. Эффективность и адаптивность: в любой момент времени сегменты должны быть максимально сбалансированными.

Описание метода

Для расчета оптимального количества сегментов Nsh в эпоху ei+1 (Nsh,i+1) мы определили один пороговый коэффициент количества транзакций в блоке, θTX.

• Переменная optN представляет собой оптимальное количество узлов в шарде;
• єsh — положительное число, на которое может изменяться размер сегмента.
• TotalNi — общее количество узлов (валидаторы, узлы в списках ожидания и вновь добавленные в пул узлы) во всех сегментах в эпоху ei.
• NTXB,i — среднее количество транзакций в блоке во всех сегментах в эпоху ei. Nsh,0 принимается равным 1.

Общее количество сегментов Nsh,i+1 будет изменено, если возникнет необходимость увеличения totalNi (количество узлов в сети) или, если от одной эпохи к другой количество узлов увеличивается выше порогового значения nSplit и среднее количество транзакций на блок больше порогового значения NTXB,i > θTX, или, если количество узлов становится ниже порогового значения nMerge как показано в функции ComputeShardsN.

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

Если этот аспект влияет на количество сегментов, можно рассчитать две маски m1 и m2, используемые при маршрутизации транзакций.

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

Координатор принимает во внимание адреса (addr) отправителя/получателя транзакции. Результатом является номер сегмента (shard), в который будет направлена транзакция.

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

Представленная древовидная структура является логическим представлением адресного пространства, используемого для предопределённого сопоставления.

Например, для распределения сегментов, вычисления родственных сегментов и т. д. Ветви двоичного дерева представляют шарды с их идентификационным номером.

Начиная с корня (узел 0), если существует только один сегмент/ветвь (a), все адреса сопоставляются с ним и все транзакции будут выполняться внутри этого сегмента. В дальнейшем, если формула для Nsh потребует двух сегментов (b), то адресное пространство будет разделено на равные части, в соответствии с последними битами в адресе.

Иногда дерево может стать несбалансированным (c), если Nsh не является степенью 2. Этот случай затрагивает только ветви на последнем уровне.

Структура снова станет сбалансированной, когда количество сегментов достигнет степени 2.

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

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

Если посмотреть на дерево, начиная с любого листа и двигаясь через ветви к корню, кодировка ветвей представляет собой последние n бит адресов, транзакции которых обрабатываются данным сегментом.

В обратном направлении, от корня к листьям, адресация связана с развитием структуры родственных сегментов и родительского сегмента, от которого они отделились.

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

Весь механизм сегментирования состояний выигрывает от этой структуры, всегда сохраняя адрес и связанное с ним состояние в одном и том же сегменте.

Зная Nsh, любой узел может наблюдать за процессом перераспределения без необходимости коммуникации. Распределение идентификаторов для новых шардов происходит по возрастанию и уменьшение количества сегментов подразумевает, что сегменты с более высоким номером будут удалены.

Например, при переходе от Nsh к Nsh-1 два сегмента будут объединены, а сегмент с самым высоким номером будет удален (shmerge=Nsh-1).

Поиск номера сегмента, с которым будет объединен shmerge, является тривиальным.

Согласно структуре дерева итоговый сегмент имеет номер родственного:

Для обеспечения избыточности отслеживания переходов состояний и быстрого масштабирования, важно определить родительский и родственные сегменты для исходного сегмента с номером p:

Избыточность сегментов

В ситуациях, когда работает недостаточное количество узлов или их распределение локализовано географически, повышается вероятность сбоев в работе сегментов.

В маловероятном случае, когда один сегмент выходит из строя (с ним нет связи и узлы находятся в автономном режиме, либо невозможно достичь консенсус, когда более 1/3 узлов не отвечают), есть высокий риск того, что вся архитектура будет полагается только на «супер- узлы», которые проверяют и хранят все блоки всех шардов.

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

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

Переключение контекста

Для обеспечения безопасности в шардированном блокчейне большое значение имеет переключение контекста.

Речь идет о периодическом перераспределении активных узлов между сегментами по некоторым случайным критериям. Такие перемещения узлов также усложняют поддержание согласованности состояний.

Это оказывает большое влияние на производительность, поскольку перемещение активных узлов требует повторной синхронизации с узлами в новом сегменте.

Чтобы избежать снижения производительности, в начале каждой эпохи между сегментами перераспределяются не более 1/3 узлов.

Такой механизм позволяет противостоять формированию вредоносных групп узлов.

4.5 — Заверяющая цепочка (metachain)

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

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

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

Эта информация будет агрегирована в блоки, по которым должен быть достигнут консенсус.

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

Более подробная информация о межсегментных транзакциях, коммуникации между шардами и метачейном будут представлены в главе 7 "Обработка межсегментных транзакций".

V — Консенсус Secure Proof of Stake

5.1 — Анализ консенсуса

Первый алгоритм консенсуса, основанный на Proof of Work (PoW), используется в Bitcoin, Ethereum и многих других блокчейнах.

В алгоритме Proof of Work от каждого узла требуется решить математическую задачу (трудно вычисляемую, но легко проверяемую). И первый узел, который найдёт решение, получит вознаграждение.

Механизмы Proof of Work успешно предотвращают двойные траты, DDoS и атаки Sybil ценой высокого потребления энергии.

• Proof of Stake (PoS) — это новый и более эффективный механизм консенсуса, предложенный в качестве альтернативы интенсивному использованию энергии и вычислений в механизме Proof of Work.

PoS можно найти во многих новых архитектурах, таких как Cardano и Algorand, он также может быть использован в следующей версии Ethereum.

В PoS узел, который предлагает следующий блок, выбирается комбинацией доли (богатства), случайности и/или возраста. Это смягчает проблему энергопотребления в PoW, но также вносит две важные проблемы: атака Nothing at stake и повышенный риск централизации.

• Proof of Meme, как это предусмотрено в Constellation, представляет собой алгоритм, основанный на историческом участии узла в сети.

Его историческое поведение определяет вес в матрице весов и со временем может изменяться. Кроме того, он позволяет новым узлам завоевывать доверие путем создания репутации.

Основной недостаток, связанный с атаками Sybil, устраняется с помощью алгоритма NetFlow.

• Delegated Proof of Stake (DPoS), используемый в Bitshares, Steemit и EOS, представляет собой гибрид между Proof of Authority и Proof of Stake, в котором несколько узлов, ответственных за развертывание новых блоков, избираются заинтересованными сторонами.

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

Кроме того, при недостаточном количестве «делегатов» система подвергается рискам DDoS-атак и централизации.

5.2 — Secure Proof of Stake (SPoS)

Подход Elrond к консенсусу заключается в случайном выборе валидаторов с учётом их ставки и рейтинга, в сочетании с оптимальным размером группы консенсуса.

Алгоритм описан в следующих шагах:

1) Каждый узел nᵢ определяется как кортеж из открытого ключа (Pk), рейтинга (по умолчанию 0) и заблокированной ставки.

Если nᵢ желает участвовать в консенсусе, он должен сначала зарегистрироваться через смарт-контракт, отправив транзакцию, которая содержит сумму, равную минимальной требуемой ставке, и дополнительную информацию (Pkₛ, открытый ключ, полученный из Pk и nodeid, который будет использоваться для процесса подписания, чтобы не использовать реальный адрес кошелька).

2) Узел nᵢ присоединяется к пулу узлов и ожидает назначения в сегмент в конце текущей эпохе е.

Механизм назначения сегментов создает новый набор узлов, содержащий все узлы, которые присоединились в эпоху e, и все узлы, которые должны быть перераспределены (не более 1/3 из каждого шарда).

Все узлы в этом наборе будут назначены в списки ожидания.

Wj представляет собой список ожидания сегмента j а Nsh — количество сегментов. Узел также имеет секретный ключ sk, который по своей природе не должен быть общедоступным.

3) В конце эпохи, в которую узел присоединился, он будет перемещен в список допустимых узлов (Ej) из сегмента j, где e — текущая эпоха.

4) Каждый узел из списка Ej может быть выбран как часть группы консенсуса с помощью предопределённой функции, основанной на источнике случайности, добавленном к предыдущему блоку, раунда r и набора вариативных параметров.

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

Это свойство делает его хорошим источником случайности и предотвращает высокоадаптивные злонамеренные атаки.

Функция выбора консенсусной группы принимает параметры: E, r и sigr-1 и возвращает список узлов Nchosen, первый из которых является заявителем блока

5) Новый блок создается заявителем, а валидаторы подпишут его на основе модифицированной “практической византийской отказоустойчивости» (pBFT).

6) Если по какой-либо причине заявитель блока не создал блок в отведённое время, в раунде r будет выбрана новая консенсусная группа с использованием источника случайности последнего блока.

Если ratingModifier < 0, происходит «отсечение» и узел ni теряет свою ставку.

Протокол консенсуса остается безопасным перед лицом DDoS атак, поскольку имеет большое количество возможных валидаторов из списка E (сотни узлов) и нет возможности предсказать новый список валидаторов до их выбора.

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

Такой блок формируется из:

• Ledger block: блок, который будет добавлен в реестр сегмента, содержащий все внутрисегментные и межсегментные транзакции, для которых было получено подтверждение;
• Несколько mini-blocks: каждый из них содержит межсегментные транзакции для разных сегментов;

Консенсус будет запущен только один раз на составном блоке, содержащем как внутри- так и межсегментные транзакции.

После достижения консенсуса заголовок блока из каждого шарда отправляется в metachain для заверения.

VI — Криптографический уровень

6.1 — Анализ подписей

Цифровые подписи — это криптографические примитивы, используемые для обеспечения защиты информации, посредством нескольких свойств, таких как аутентификация сообщений, целостность данных и неоспоримость.

Большинство схем, используемых в существующих платформах, основаны на дискретном логарифме (DL): функция одностороннего экспонирования y → αy mod p.

Научно доказано, что вычисление дискретного логарифма по основанию является сложной задачей.

Причина, по которой ECC обеспечивает аналогичный уровень безопасности для гораздо меньшей длины параметров, заключается в том, что существующие атаки на группы эллиптических кривых слабее, чем существующие целочисленные DL атаки, сложность таких алгоритмов требует в среднем √p шагов для решения.

Это означает, что эллиптическая кривая, использующая простое число p длиной 256 бит, обеспечивает в среднем безопасность на уровне 2128 шагов, необходимых для ее взлома.

Ethereum и Bitcoin используют криптографию с использованием эллиптической кривой и алгоритмом подписания ECDSA.

Безопасность алгоритма очень сильно зависит от генератора случайных чисел, потому что, если генератор не выдает разные числа при каждом запросе, возможна утечка закрытого ключа.

Другим, более эффективным вариантом цифровой подписи, является EdDSA, который построен на схеме Шнора, основанной на скрученных кривых Эдвардса.

В отличие от ECDSA, EdDSA — доказуемо устойчив. Это означает, что начиная с простой подписи, невозможно найти другой набор параметров, определяющий ту же точку на эллиптической кривой.

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

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

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

Эта подпись затем может быть проверена верификатором, который имеет доступ к сообщению и открытым ключам подписавших. Метод заключается в том, что каждый узел вычисляет свою собственную подпись, а затем объединяет все результаты в одну строку.

Однако такой подход неосуществим, поскольку размер генерируемой строки растет с увеличением числа подписывающих.

Практическим решением было бы объединить результаты в одну подпись фиксированного размера, не зависящую от количества участников. Имеется множество предложений таких схем, но большинство из них подвержены атакам с неавторизованными ключами.

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

Беллар и Невен (BN) предложили безопасную схему множественной подписи без доказательства владения в рамках модели простого публичного ключа с дискретным логарифмическим преобразованием.

Прежде всего, каждый участник представляет свою часть Ri в виде её хэша всем прочим подписантам, таким образом, последние не могут вычислить его функцию.

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

В этом случае проверка всей подписи требует открытых ключей всех подписавших.

Недавняя статья Грегори Максвелла и др. предлагает еще одну схему мультиподписи в модели простого открытого ключа с преобразованием еще одного дискретного логарифма (OMDL).

Этот подход улучшает предыдущую схему за счет сокращения раундов общения с 3 до 2, повторно вводя агрегацию ключей с более высоким уровнем сложности.

BLS — еще одна интересная схема подписи, опирающаяся на спаривание Вейля (Weil pairing), безопасность которого основывается на неразрешимости вычислительной задачи Диффи-Хеллмана и генерирует короткие подписи.

BLS имеет несколько полезных свойств, таких как пакетная проверка, агрегирование подписей, агрегирование открытых ключей. Это делает его хорошим кандидатом для схем с несколькими подписями.

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

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

Другое преимущество состоит в том, что для создания мультиподписи достаточно только двух раунда общения.

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

В этом контексте наш анализ позволяет сделать вывод о том, что наиболее подходящей схемой мультиподписи для подписания блоков в Elrond является мультиподпись BLS, которая в целом быстрее других вариантов за счет всего двух раундов комуникации.

6.2 — Подписание блоков в Elrond

Для подписания блоков в Elrond используется криптография кривых, базирующаяся на основе схемы мультиподписи BLS над билинейной группой bn256 группе, которая реализует оптимальное сопряжение Ate (Optimal Ate pairing) на 256-битной кривой Баррето-Наерига.

Билинейное сопряжение определяется как:

где g0, g1 и gt — эллиптические кривые простого порядка p, определенные bn256, а e — билинейная карта (т.е. функция сопряжения).

Пусть G0 и G1 — генераторы для g0 и g1. Также пусть H0 будет хэширующая функция, которая определяет точки на кривой g0:

где M — множество всех возможных двоичных сообщений любой длины. В

схеме подписи, используемой Elrond, применяется вторая функция хеширования, параметры которой известны всем подписывающим:

Каждый подписант i имеет свою собственную пару закрытых и открытых ключей (ski, Pki), где ski выбирается случайным образом из Zp.

Для каждой пары ключей выполняется операция Pki = ski * G1.

Пусть L = P k1, P k2, ..., P kn — это множество открытых ключей всех возможных подписантов во время определенного раунда, которые, в случае Elrond являются множеством открытых ключей всех узлов в консенсусной группе.

Ниже представлены 2 этапа процесса подписания блока:

• Подписание
• Проверка

Практическое подписание — Раунд 1

Лидер группы создает блок с транзакциями, подписывает и транслирует этот блок остальным членам группы консенсуса.

Практическое подписание — раунд 2

Каждый член консенсусной группы (включая лидера), получивший блок, должен проверить его и, если он признан действительным, подписывает его с помощью BLS, а затем отправляет подпись заявителю:

где Sigi — это точка на g0.

Практическое подписание - раунд 3

Заявитель ожидает получения подписей в течение определенного времени.

Если он не получает по крайней мере 2/3 - n + 1 подписей за этот промежуток времени, раунд консенсуса прерывается. Но при наличии 2/3 - n + 1 или более достоверных подписей, он использует их для создания агрегированной подписи:

где SigAgg — это точка на g0.

Затем заявитель добавляет агрегированную подпись в блок вместе с битовой картой выбранных подписантов B, где 1 указывает, что подпись соответствующего подписанта из списка L добавлена к агрегированной подписи SigAgg.

Практическая проверка

На основании списка открытых ключей L, битовой карты подписантов B, агрегированной подписи SigAgg и сообщении m (блок), верификатор вычисляет агрегированный открытый ключ:

Результат PkAgg является точкой на g1. Далее проводится окончательная проверка:

где e — функция сопряжения.

VII — Межсегментные операции

Как уже упоминалось в главе V – «Консенсус Secure Proof of Stake», структура блоков представляет собой заголовок блока, в котором содержится информация о блоке (уникальный номер блока, раунд, заявитель, временные метки валидаторов и т.д.) и список миниблоков от каждого шарда, внутри которых фактически содержатся транзакции.

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

В нашем случае для блока в сегменте 0, как правило, будет 3 миниблока:

• Миниблок 0: содержит внутрисегментные транзакции для сегмента 0
• Миниблок 1: содержит межсегментные транзакции с отправителем в сегменте 0 и получателем в сегменте 1
• Миниблок 2: содержащий межсегментные транзакции с отправителем в сегменте 1 и получателем в сегменте 0.

Эти транзакции уже были обработаны в сегменте отправителя 1 и будут завершены после обработки в текущем сегменте.

Количество миниблоков с одним и тем же отправителем и получателем в одном блоке не ограничено. Несколько миниблоков с одним и тем же отправителем и получателем могут появиться в одном блоке.

7.1 — Обработка

В настоящее время атомарной единицей обработки для межсегментных операций является миниблок.

Обрабатываются либо все его транзакции, либо ни одна, и выполнение миниблока будет повторено в следующем раунде.

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

Транзакции сначала маршрутизируются в сегменте отправителя, так как в нём может быть полностью подтверждена любая транзакция, инициированная с адреса в этом сегменте — в основном текущий баланс.

Затем, в сегменте получателей, узлам требуется только подтверждение выполнения, предлагаемое метачейном, проверка подписи и проверка на атаку «двойной траты», после чего к балансу получателя добавляется сумма из транзакции.

Сегмент 0 обрабатывает как внутрисегментные транзакции в миниблоке 0, так и набор межсегментных транзакций, которые имеют адреса получателей из сегмента 1, в миниблоке 1.

Заголовок блока и миниблоки отправляются в метачейн.

Метачейн заверяет блок из сегмента 0, создавая новый блок метачейна (метаблок), в котором сохраняется информация о каждом миниблоке (идентификатор сегмента отправителя, идентификатор сегмента получателя, хэш миниблока).

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

После заверения в метачейне набор перекрестных транзакций можно считать завершенным.

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

Раунды рассматриваются от первого включения в миниблок до момента, когда последний миниблок будет подписан.

VIII — Смарт-контракты

Выполнение смарт-контрактов является ключевым элементом всех будущих блокчейн-архитектур.

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

Это приводит к следующим двум сценариям:

1) Если у смарт-контрактов нет связанных транзакций, как показано на рис. 5, они могут исполняться в любой очередности и где угодно.

Это означает, что нет никаких дополнительных ограничений на время и место исполнения смарт-контракта.

2) Второй сценарий относится к параллелизму, вызванному транзакциями, в которых участвуют взаимосвязанные смарт-контракты.

Этот случай, отраженный на рис. 6, оказывает дополнительное влияние на производительность и значительно увеличивает сложность.

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

Протокол Elrond предлагает решение, которое определяет и перемещает смарт-контракты в тот же сегмент, где находятся их статические зависимости.

Таким образом, большинство, если не все SC вызовы будут иметь зависимости в одном и том же шарде, и не потребуется никаких межсегментных блокировок/разблокировок.

Elrond фокусируется на реализации виртуальной машины Elrond, совместимой с EVM.

Соответствие EVM чрезвычайно важно в связи с большим количеством смарт-контрактов, построенных на платформе Ethereum.

Реализация виртуальной машины Elrond позволяет скрыть базовую архитектуру, изолируя разработчиков смарт-контрактов от внутренних компонентов системы, обеспечивая надлежащий уровень абстракции, как показано на рис. 7.

В Elrond кросс-чейн совместимость может быть реализована с помощью механизма адаптера на уровне виртуальной машины, как это было предложено в Cosmos.

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

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

8.1 — Инфраструктура Виртуальной Машины (VM)

Elrond строит свою инфраструктуру VM поверх K-Framework, которая является исполняемой семантической структурой.

В ней могут определяться языки программирования, исчисления, а также системы типов или формальные инструменты анализа.

Самым большим преимуществом использования K-Framework является то, что с его помощью можно однозначно определять языки смарт-контрактов, исключая возможность неопределенного поведения и ошибок, которые трудно обнаружить.

K-Framework является исполняемым, в том смысле, что семантические спецификации языков могут быть непосредственно использованы в качестве рабочих интерпретаторов.

В частности, можно либо запускать программы на основе спецификаций, реализованных в ядре K-Framework, либо использовать интерпретаторы других языков.

Такие интерпретаторы также называются "бэкендами". Для обеспечения скорости выполнения и простоты взаимодействия Elrond использует свой собственный специально разработанный бэкенд K-Framework.

8.2 — Языки смарт-контрактов

Одним из главных преимуществ K-Framework является то, что можно сгенерировать интерпретатор для любого языка, определенного в K, без необходимости в дополнительном программировании.

Это означает, что интерпретаторы, созданные таким образом, являются "конструктивно правильными".

Существует несколько языков смарт-контрактов, уже определенных в K-Framework, или их спецификации находятся в стадии разработки.

Сеть Elrond будет поддерживать 3 низкоуровневых языка: IELE VM, KEVM и WASM.

• IELE VM — это язык среднего уровня, выполненный в стиле LLVM, но адаптированный для блокчейна.

Он был создан непосредственно в K, никакой другой спецификации или реализации его не существует за пределами K. Его цель состоит в том, чтобы быть читаемым для человека, производительным и преодолевающим некоторые ограничения EVM.

Elrond использует слегка измененную версию IELE, большинство изменений связано с управлением адресами.

Разработчики смарт-контрактов могут программировать в IELE напрямую, но большинство из них предпочтут написать код на Solidity, а затем использовать компилятор Solidity в IELE, как показано на рис. 8.

KEVM — это версия виртуальной машины Ethereum Virtual Machine (EVM), написанная на языке K.

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

• Веб-сборка (WASM) — это формат двоичных инструкций для стековой виртуальной машины, которая может быть использована для запуска смарт-контрактов.

Инфраструктура WASM позволяет разработчикам писать смарт-контракты на языках C/C++, Rust, C# и других.

Наличие спецификации языка и создание интерпретатора — это только часть задачи.

Другая часть — это интеграция сгенерированного интерпретатора с сетью Elrond.

Мы создали общий интерфейс VM, который позволяет подключить любую VM к узлу Elrond, как показано на рис. 9.

Каждая виртуальная машина имеет адаптер, реализующий этот интерфейс.

Каждый контракт сохраняется как байт-код виртуальной машины, для которой он был скомпилирован и выполняется на соответствующей виртуальной машине.

8.3 — Поддержка формального моделирования и верификации

Поскольку языки смарт-контрактов определены в K-Framework, можно выполнить формальную проверку контрактов, написанных на этих языках.

Для этого необходимо смоделировать их требования с помощью K Framework.

8.4 — Смарт-контракты в сегментированной архитектуре

Смарт-контракты в сегментированной архитектуре все еще находятся на ранних стадиях исследований и разработок и имеют серьезные проблемы.

Динамические зависимости смарт-контрактов не могут быть удовлетворены путем перемещения SC в один и тот же сегмент, так как во время развертывания не все зависимости могут быть вычислены.

Отправной точкой для таких SC являются реализации протоколов Atomix или S-BAC.

В настоящее время поиск решений идёт в следующих направлениях:

1. Механизм блокировки, позволяющий атомарное выполнение смарт-контракта в разных сегментах, гарантирует, что зависимые SC либо будут выполняться все одновременно, либо ни один не выполнится. Это требует многократного взаимодействия и синхронизации между разными сегментами.
2. Предложение по перемещению контрактов между сегментами для Ethereum 2.0 будет переносить код и данные смарт-контракта в вызывающий сегмент во время исполнения. В таком случае не требуется атомарное исполнение, но механизм блокировки также необходим для перемещенного SC, исполнение которого будет заблокировано для других транзакций. Такой механизм проще, но он требует передачи всего внутреннего состояния смарт-контракта.

Следуя модели Ethereum, Elrond имеет следующие типы транзакций:

1. Построение и развертывание SC: адрес получателя транзакций пуст, а поле данных содержит код смарт-контракта в виде байт-массива;
2. Вызов метода SC: транзакция имеет непустой адрес получателя и у этого адреса имеется ассоциированный код;
3. Платежные транзакции: транзакция имеет непустой адрес получателя и этот адрес не имеет кода.

Подход Elrond заключается в использовании асинхронной модели межсегментного исполнения смарт-контрактов. Пользователь создает транзакцию выполнения смарт-контракта.

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

Она добавляется в блок, в котором находятся записи сегмента отправителя и миниблок с записями сегмента получателя. Транзакция заверяется в метачейне, затем обрабатывается в сегменте назначения.

В сегменте назначения транзакция рассматривается как SC, поскольку адресом получателя является смарт-контракт, существующий в этом сегменте.

Для вызова смарт-контракта создается временный аккаунт, который дублирует аккаунт отправителя с балансом, эквивалентным стоимости транзакции и вызывается смарт-контракт.

После исполнения смарт-контракт может вернуть результаты, которые затрагивают адреса из разных сегментов.

Все результаты, влияющие на адреса внутри сегмента, применяются в одном раунде. Для остальных результатов будут созданы транзакции под названием «Результаты смарт-контракта» (Smart Contract Results – SCR), сохраняя данные выполнения смарт-контракта для всех затрагиваемых адресов.

Миниблоки SCR создаются для каждого целевого шарда. Эти миниблоки заверяются в метачейне, аналогично межсегментным транзакциям, а затем обрабатываются соответствующими сегментами.

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

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

IХ — Начальная загрузка и хранение

9.1 — Деление временной шкалы

Cистемы Proof of Stake, как правило, делят временную шкалу на эпохи, а каждую эпоху — на более мелкие раунды.

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

Эпохи

В протоколе Elrond каждая эпоха имеет фиксированную продолжительность, изначально — это 24 часа (значение может быть изменено после нескольких этапов проверки в тестовой сети).

В течение этого периода времени конфигурация сегментов остается неизменной. Система адаптируется к требованиям масштабируемости между эпохами путем изменения количества сегментов.

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

По этой причине в конце каждой эпохи не более чем 1/3 узлов распределяются случайно и равномерно в списки ожидания других сегментов.

Только перед началом новой эпохи распределение узлов по сегментам может быть произведено без дополнительной коммуникации, как показано на рис. 10.

Процесс перераспределения узлов состоит из нескольких этапов:

1. Новые узлы, зарегистрированные в текущую эпоху ei, помещаются в пуле неназначенных узлов до конца текущей эпохи;
2. До 1/3 узлов в каждом шарде выбираются случайным образом для перестановки и добавляются в пул назначенных узлов;
3. Новое количество сегментов Nsh,i+1 вычисляется на основе числа узлов в сети ki и загрузки сети;
4. Синхронизированные узлы, ранее находившиеся в списках ожидания сегментов, добавляются в списки допустимых валидаторов;
5. Вновь добавленные узлы из пула неназначенных узлов равномерно, случайным образом распределяются по всем спискам ожидания сегментов эпохи ei+1;
6. Узлы из пула назначенных узлов вносятся с повышенными коэффициентами в списки ожидания шардов, которые должны будут разделиться в следующую эпоху ei+2.

Каждый раунд имеет фиксированную продолжительность 5 секунд (значение может быть изменено после нескольких этапов проверки в тестовой сети).

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

От раунда к раунду набор валидаторов меняется с помощью списка допустимых узлов, как подробно описано в главе IV.

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

9.2 — Обрезка

Высокая пропускная способность приведет к быстрому увеличению размера блокчейна и увеличит затраты на начальную загрузку и синхронизацию (время + храннение), как указано в разделе XI.1..

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

Механизм обрезки аналогичен «стабильным контрольным точкам» в pBFT и сжимает все состояния блокчейна.

Протокол Elrond использует эффективный алгоритм обрезки, подробно описанный ниже. Будем считать, что e — это текущая эпоха, а a — текущий сегмент:

1. Узлы сегмента отслеживают остатки на счетах в эпоху e в дереве Меркла;
2. В конце каждой эпохи заявитель блока создает блок состояния sb(a, e), в котором хранится хэш корня дерева Меркла в заголовке блока и остальная часть в теле блока;
3. Валидаторы проверяют консенсус для sb(a, e);
4. Если консенсус достигнут, sb(a, e) сохраняется в реестре сегмента, превращая его в генезисный блок для эпохи e + 1;
5. В конце эпохи e + 1 узлы очистят тело блока sb(a, e) и удалят все предшествующие ему блоки.

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

На самом деле, они начинают с последнего проверенного блока состояния и вычисляют только следующие блоки вместо полной истории.

X — Оценка безопасности

10.1 — Источник случайности

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

Поскольку эти функции влияют на безопасность Elrond, важно использовать случайные числа, которые доказательно непредсказуемы.

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

где H — функция хэширования, которая хэширует точки на используемой кривой, а sk — закрытый ключ.

10.2 — Создание случайных чисел в Elrond

В каждом раунде создается одно случайное число, которое добавляется заявителем блока к каждому блоку в блокчейне.

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

Создание случайных чисел подробно описано ниже в рамках одного раунда консенсуса:

1. Новая группа консенсуса выбирается с использованием источника случайности в заголовке предыдущего блока. Она формируется из заявителя блока и валидаторов.
2. Заявитель блока подписывает предыдущий источник случайности с помощью BLS, добавляет подпись к заголовку блока в качестве нового источника случайности и транслирует этот блок группе консенсуса.
3. Каждый член консенсусной группы проверяет источник случайности как часть проверки блока и отправляет свою подпись заявителю блока.
4. Заявитель блока агрегирует подписи валидаторов и передает блок с агрегированной подписью и новым источником случайности всему сегменту.

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

10.3 — Схема завершенности блока "K"

Подписанный блок в раунде n является окончательным, если и только если блоки n + 1, n + 2, ..., n + k подписаны.

Более того, завершенный блок не может быть отменен. Метачейн заверяет только завершенные блоки, чтобы гарантировать, что разветвление в одном сегменте не повлияет на другие сегменты.

Сегменты принимают во внимание только финальные блоки метачейна, чтобы не пострадать в случае разветвлений метачейна. Окончательность и правильность блоков контролируется как при создании, так и при валидации блока. Выбранный параметр k равен 1, что обеспечивает «вилки» длиной не более 2 блоков.

Даже если 33% узлов в сегменте являются вредоносными, вероятность того, что злонамеренное супербольшинство (> 2/3 * n + 1) будет выбрано для того же раунда и в том же консенсусе, равна 10-9. В этом случае они могут предложить блок и подписать его, назовем его блок m, но он не будет заверен метачейном, т.к. в метачейне заверится блок m только в том случае, если после него будет построен блок m + 1.

Для того, чтобы создать блок m + 1, следующая консенсусная группа должна согласиться с блоком m. Только злонамеренная группа согласится с блоком m, поэтому следующая группа снова должна иметь злонамеренное супербольшинство.

Поскольку случайный выбор группы не может быть скомпроментирован, вероятность выбора еще одной злонамеренной группы супербольшинства равна 10-9 (5,38 - 10-10, если быть точным).

Вероятность подписания двух последовательных вредоносных блоков равна вероятности выбора двух подгрупп с не менее чем 2/3 * n+ 1 членов из вредоносной группы.

Вероятность этого составляет 10-18. Более того, такие группы должны быть в сговоре, иначе блоки не будут подписаны.

10.4 — Проблема рыбака

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

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

Другие узлы предоставят блок транзакций (предыдущее сокращенное дерево Меркла со всеми затронутыми адресами и состояниями смарт-контрактов), до применения оспариваемого блока, выявляя тем самым недействительную транзакцию/состояние.

Если недействительность блока не будет доказана в течение определённого периода времени, блок будет считаться действительным.

Стоимость каждого вредоносного запроса составляет всю ставку узла, в котором обнаружена проблема.

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

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

Однако, сделав обязательным для текущего консенсуса распространять созданный блок среди родственных сегментов и узлов-наблюдателей, данные больше не могут быть скрыты.

Расход ресурсов снижается за счет отправки только внутрисегментного миниблока. Кросс-сегментные миниблоки всегда отправляются всем заинтересованным узлам.

В итоге несоответствия могут быть выявлены несколькими честными узлами.

Еще один уровень безопасности обеспечивается созданием P2P соединений.

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

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

10.5 — Реорганизация сегментов

После каждой эпохи, с целью предотвращения сговора, до 1/3 - n узлов из каждого сегмента равномерно перераспределяются по другим сегментам.

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

Механизм обрезки уменьшит время начальной загрузки до приемлемого, как объясняется в разделе IX.2.

10.6 — Выбор группы консенсуса

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

В случае разсинхронизации сети из-за задержек в распространении сообщений, протокол имеет механизм восстановления и учитывает как раунд r, так и случайный номер из последнего зафиксированного блока для выбора новых групп консенсуса каждый раунд.

Это позволяет избежать разветвлений и обеспечивает синхронизацию по последнему блоку.

Небольшой промежуток времени (продолжительность раунда), в котором известна группа валидаторов, минимизирует большинство векторов атак.

10.7 — Рейтинг узлов

Помимо ставки, рейтинг валидатора, имеющего право голоса, влияет на шансы быть выбранным в группу консенсуса.

Если заявитель блока надёжен и его блок будет зафиксирован в блокчейне, его рейтинг увеличится, в противном случае его рейтинг будет снижен.

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

10.8 — Избыточность сегментов

Узлы, которые были распределены в соседние сегменты на самом нижнем уровне дерева (см. главу 4, пункт 4), отслеживают друг у друга данные блокчейна и состояние приложений.

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

Целевые узлы мгновенно инициируют процесс слияния сегментов.

XI — Понимание реальных проблем

11.1 — Централизованный и децентрализованный

Блокчейн изначально был создан как альтернатива централизованной финансовой системе.

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

Наиболее актуальной метрикой, измеряющей производительность, является количество транзакций в секунду (TPS), как показано в таблице 2.

Сравнение TPS традиционных централизованных систем с децентрализованными архитектурами, которые были признаны надежными и эффективными, в больших масштабах отражает объективную, но тревожную реальность.

Масштабируемость блокчейн-архитектур является критически важной, но до сих пор нерешенной проблемой.

Представим себе объём сохраняемых данных в нынешних блокчейнах, если бы внезапно они обрабатывали количество транзакций сравнимое с VISA.

При таких условиях объём многочисленных сопутствующих проблем становится очевидным (см. рис. 11).

XII — Парадигма производительности блокчейна

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

Таких как:

• Cложность
• Hазмер системы
• Cкорость транзакций

Сложность

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

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

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

Размер системы

Увеличение числа узлов в существующих архитектурах приводит к серьезному снижению производительности и повышению стоимости вычислений.

Сегментирование кажется хорошим подходом, но большую роль играет размер сегмента.

Меньшие сегменты более маневрены, но подвержены влиянию вредоносных групп, более крупные сегменты безопаснее, но их реконфигурация влияет на эффективность системы.

Производительность транзакции

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

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

• C1 пропускная способность транзакций — сколько транзакций система может обработать в единицу времени, известная как TPS;
• C2 время транзакции — как быстро обрабатывается одна конкретная транзакция в интервале между ее запуском и завершением - путь от начала до окончания.

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

В архитектуре с сегментированием, подобной нашей, пропускная способность транзакций зависит от количества сегментов, вычислительной возможности валидаторов/заявителей блоков и инфраструктуры обмена сообщениями.

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

C2. Время транзакции — ,олее тонкий аспект, который подчеркивает, что даже если пропускная способность системы может составлять 1000 TPS, обработка конкретной транзакции может занять продолжительное время.

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

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

В Elrond механизм координации (подробно описанный в разделе V) позволяет сократить время до завершения путем маршрутизации транзакций непосредственно в нужный сегмент, тем самым уменьшая общую задержку.

XIII — Заключение

13.1 — Производительность

Тесты и моделирование производительности, представленные на рис. 12, отражают эффективность решения как высокомасштабируемого распределенного реестра.

По мере присоединения к сети все большего количества узлов наш подход к сегментированию демонстрирует линейно возрастающую пропускную способность.

Выбранная модель консенсуса включает в себя несколько коммуникационных раундов, поэтому результат сильно зависит от качества сети (скорость, задержка, доступность).

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

13.2 — Нынешние и будущие исследования

Наша команда постоянно переосмысливает и улучшает дизайн Elrond в попытке сделать его одной из самых привлекательных архитектур; решает проблемы масштабируемости с помощью адаптивного разделения состояний, сохраняя при этом безопасность и высокую энергоэффективность, благодаря безопасному механизму консенсуса Proof of Stake.

Некоторые из наших дальнейших направлений развития включают:

1. Обучение с подкреплением: мы стремимся повысить эффективность процесса сегментирования путем распределения наиболее активных клиентов в один и тот же сегмент для общего уменьшения затрат;
2. ИИ-надзор: создание ИИ-надзора, который будет обнаруживать вредоносные модели поведения; пока нет ясности, как эта функция может быть интегрирована в протокол без нарушения децентрализации;
3. Надежность как фактор консенсуса: существующий протокол берёт в расчёт ставку и рейтинг валидаторов, но мы планируем добавить надежность в качестве метрики, вычисляя её на основании истории достижения консенсуса для недавно принятых блоков.
4. Кросс-чейн совместимость: реализация и поддержка стандартов, инициированных «Decentralized Identity Foundation» или «Blockchain Interoperability Alliance»;
5. Конфиденциальность транзакций: использование NIZK (доказательство с нулевым разглашением) для защиты личности участников, предоставления возможности аудита при сохранении конфиденциальности.

13.3 — Общие выводы

Elrond - первый высокомасштабируемый блокчейн, использующий недавно предложенный алгоритм Secure Proof of Stake в архитектуре с реальным разделением состояний для достижения уровня пропускной способности VISA и времени подтверждения в несколько секунд.

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

Благодаря использованию механизма обрезки существенно снижаются затраты на загрузку и хранение данных по сравнению с другими подходами.

Недавно представленный алгоритм консенсуса Secure Proof of Stake обеспечивает справедливое распределение и улучшает идею случайного выбора Algorand, сократив время создания группы консенсуса с 12 секунд до 100 мс.

Сочетание сегментирования состояний и эффективного алгоритма консенсуса Secure Proof of Stake показал многообещающие результаты, подтвержденные нашими последними тестами.

Оригинал документа на английском языке

АКАДЕМИЯ TOP TRADERS

• TT Аналитика
• ТТ Академия
• Инстаграм
• Фейсбук
• YouTube
• VC