Навстречу большей ончейн-масштабируемости с Unitrie

Published on: 19 марта, 2019

RSK была создана в 2015 году как Эфириум-совместимая биткойн сайдчейн. Еще в 2016 году, когда сайдчейн RSK был все еще на стадии разработки, мы решили улучшить и упростить его конструкцию путем замены одного из ключевых компонентов Эфириума: счета синтаксического дерева, называемого также деревом «общего состояния» согласно Желтой книге Эфириума. Дерево общего состояния является основной базой данных в блок-цепочках, подобных Эфириуму, и его вспомогательная структура данных называется «Безопасное модифицированное дерево Патриция». Мы разработали замену структуры данных состояния, которая превратилась в то, что мы сейчас называем «Юнитри» (Unitrie).

Серхио Лернер (RSK Labs) представляет Unitrie на выставке laBitConf (2016г.)

Вот некоторые из основных свойств (оригинального) устройства Unitrie:

Базисное дерево radix-16 заменяется на базисное дерево radix-2 (двоичное).
Произвольные значения длины могут храниться в ячейках памяти.
Все деревья объединяются, происходит сливание ячеек хранения договоров с ячейками счетов в единую большую структуру данных, которую мы назвали Unitrie.
Ссылки дополняются метками времени последнего обновления (поле «lastUpdateTimestamp»), в результате чего Unitrie поддерживает аренду хранилища и автоматический спящий режим узлов.
Префиксы хранятся в родительском узле для каждого из его дочерних узлов. Это позволяет удалять конечные узлы в спящем режиме для максимизации удаление данных. Кроме того, это предотвращает побочный эффект перекрещивания узлов при обработке параллельных транзакций.
Ключи «защищены префиксом» с помощью 10-байтового (80-битного) префикса хеша, чтобы предотвратить разбалансированность дерева, но все же содержат полный ключ (оригинал хеша) после префикса хеширования.
Узлы сохраняют размер своей полезной информации.
Узлы сохраняют информацию, сколько байтов используется его поддеревом.
Если узел слишком мал, чтобы заслуживать независимого хранения в базе данных, он встраивается в родительский узел. Это экономит 32-байтовое хэш-профиль, используемый для ссылки на узел.

Некоторые преимущества Unitrie очевидны, однако некоторые едва уловимы. Вот список основных улучшений:

Упрощение общей конструкции.
Снижение сложности реализаций и, следовательно, снижение риска консенсусных ошибок.
Упрощение конструкции Легковесных клиентов.
Сокращение времени на синхронизацию состояний (например, fast-sync/warp-sync), делая его более распараллеливаемым и устойчивым к вредоносным поставщикам состояний.
Включение более простых способов защиты от мошенничества для клиентов SPV и мостов SPV.
Включение упрощенного состояния очистки памяти от ненужных данных.
Включение договора аренды для каждой ячейки памяти.
Включение режимов ожидания и пробуждения для каждой ячейки памяти.
Включение параллельного выполнения с распознаванием конфликтов для каждой ячейки памяти.
Включение быстрых запросов EXTCODESIZE без необходимости извлечения данных кода.

Проект Unitrie был предложен компанией «RSK Labs» для блокчейна RSK и кратко представлен на конференции laBitConf, 4-5 ноября 2016 года. Тем не менее, нашим главным приоритетом в то время, когда основная сеть RSK еще не была запущена, было обеспечение большей совместимости с инструментальными программными средствами Эфириума, поэтому мы решили отложить внедрение Unitrie и выполнили только два критических изменения в структуре данных дерева: поменяли radix-16 на radix-2 и внедрили хранение произвольных значений длины. Использование radix-2 позволило бы в будущем перейти на Unitrie, выполнив динамическое преобразование дерева вместо полной миграции базы данных. Это оказалось мудрым решением, так как сейчас мы в динамическом режиме тестируем быструю миграцию всей древовидной структуры, сохраняя большинство структурных частей.

К концу 2017 года мы были удивлены, увидев, что «Виталик» (Vitalik) предложил аналогичное изменение в технологиях Эфириума на форумах Эфириума. Он также подчеркнул преимущества комбинированного дерева состояний. Это подтвердило наш первоначальный тезис о том, что объединение дерева было в целом лучшим решением.

Предложение Vitalik по объединенному дереву состояний (2017 г.)

Время пришло

В январе 2019 года у блокчейна RSK был первый день рождения, который ознаменовался годом 100% безотказной работы, поэтому мы решили возобновить наши усилия, нацеленных на внедрение структуры данных Unitrie при следующем обновлении сети. Мы отредактировали и отшлифовали старые IP RSK, создали новые IP и эталонные реализации. Эта статья является частью нашей разъяснительной работы о том, каким образом сообщество RSK сможет извлечь выгоду от этого предлагаемого изменения. Мы обновили RSKIP16 и добавили RSKIP107, RSKIP108 и RSKIP109. RSKIP107 описывает, как узлы дерева сжимаются при сохранении. RSKIP108 описывает, как адреса учетных записей и адреса ячеек памяти сопоставляются с ключами дерева. RSKIP109 пересчитывает затраты на запись в ячейку памяти, чтобы стимулировать использование более коротких адресов хранилища. Мы реализовали и протестировали все вместе, и мы увидели заметные улучшения в производительности узла и потреблении памяти от обновлений состояния до синхронизации. Однако во время тестов не все прошло гладко. Например, мы решили исключить из предложения идею перемещения префиксов узлов в родительские узлы. Причина была в том, что это изменение усложняет быстрое преобразование между новыми и старыми деревьями, полагаясь на сходство древовидных структур.

Мы считаем, что для снижения риска, связанного с хард-форками (обновление программного обеспечения, с которым вводится в действие новое правило работы сети, несовместимое со старым программным обеспечением), лучше всего разбить изменения на два последовательных обновления сети. Первый, во втором квартале 2019 года, будет включать в себя Unitrie, ключи с префиксной защитой, кэш с размером полезной нагрузки, кэш с размерами дерева и сжатие узлов на диске. Второй, в четвертом квартале 2019 года, будет включать отметки времени последнего обновления аренды хранилища. Мы откладываем внедрение функций, связанных с арендой хранилища, потому что IP аренды хранилища, принадлежащие RSK еще не является окончательным, и потому что изменения при втором обновлении сети влияют только на новые созданные узлы дерева (это не требует переноса дерева), тогда как первое обновление сети требует полного переноса дерева.

Уникальное обновление сети

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

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

Unitrie («Юнитри»)

Unitrie объединяет информацию об учетной записи с ячейками памяти всех контрактов. Он хранит ячейки памяти контракта в виде листьев поддерева с корнем в узле, соответствующем адресу хранения контракта. Он также разбивает информацию о контракте на несколько отдельных подузлов дерева. На следующей упрощенной диаграмме показана одна учетная запись (управляемая ECDSA — алгоритмом электронной цифровой подписи, основанной на эллиптических кривых), у которой нет дочерних элементов, и контракт, в котором есть один дочерний узел, в котором хранится код контракта, и дочернее поддерево, которое содержит фактические ячейки памяти.

Образец Unitrie для состояния блокчейна

Комбинация счетов и хранение контрактов — не единственная разница, также меняется и расположение ключей. Давайте вспомним, как работает дерево учетной записи Эфириума: дерево «защищено» с использованием хеш-профиля адреса учетной записи в качестве ключа для получения значения. Узлы в дереве сортируются не по адресам учетных записей, а по их хэш-профилям. Это преобразование ключа выполняется, чтобы предотвратить попытки взломщиков заспамить структуры данных значениями, которые разделяют растущие ключевые префиксы, которые превратили бы дерево в длинную цепочку. Такая атака может привести к тому, что полный узел будет выполнять определенные поиски гораздо медленнее, или увеличить размер некоторых доказательств внедрения дерева. В Unitrie ключи строятся из 80-битного префикса хеш-профиля, за которым следует полный простой адрес учетной записи. Только 80 бит используются для распределения ключей по дереву и поддержания его в вероятностном балансе. Учитывая, что воздействие атаки на вырождение дерево минимально, 80 бит более чем достаточно, чтобы противодействовать им. Такая атака потребует разработки специального аппаратного обеспечения с префиксом хеш-кода на основе ASIC, очень похожего на майнер с доказательством выполнения работы, и производства миллионов таких «майнинговых» блоков. Если представить, что ультрасовременные биткойн-машины могут выполнять произвольный поиск по прообразу с префиксом в 80 бит, то взломщику потребуется около 6 миллионов долларов США только на электричество, чтобы найти коллизии в 80 различных 80-битных позициях чтобы немного разбалансировать дерево. Тем не менее, влияние на время обработки блока будет незначительным (из-за кэшей), а доказательство включения для несбалансированного аккаунта увеличится всего на 2 Кбайт.

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

Преобразование адресов учетных записей и хранилищ в ключ дерева

Чтобы представить полную картину, мы покажем, как каждый тип данных отображается в Unitrie:

Ключ	Значение	Описание
0x00 SHA3(account_addr)(адрес учетной записи)[0:9] account_addr(адрес учетной записи)	Rlp (случайный код, количество, флаги)	состояние учетной записи
0x00 SHA3(account_addr)(адрес учетной записи)[0:9] account_addr(адрес учетной записи) 0x80	массив байтов	шифр учетной записи
0x00 SHA3(account_addr)(адрес учетной записи)[0:9] account_addr(адрес учетной записи) 0x00	0x00	заполнитель для изоляции дерева хранения
0x00 SHA3(account_addr)(адрес учетной записи)[0:9] account_addr(адрес учетной записи) 0x00 SHA3(storage_address)(адрес хранения)[0..9] trimmed_storage_address (усеченный адрес хранения)	массив байтов	значение в ячейке памяти

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

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

Существует много различий между RSKIP16 Unitrie и предложением Vitalik. Одно из отличий состоит в том, что Unitrie не хранит случайный код и сумму в разных узлах, а сохраняет их вместе. На это есть несколько причин:

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

Перспектива Unitrie RSKIP

Unitrie определяется 9 RSKIP (Предложения по усовершенствованию RSK). Каждый RSKIP описывает конкретный компонент Unitrie: структуру, хранилище, отображение ключей, аренду хранилища, гибернацию, затраты на газ. Это разделение показано на следующей диаграмме:

RSKIP, связанные с Unitrie

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

То, что не вошло в Unitrie

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

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

Теперь обсудим все преимущества RSK Unitrie более подробно.

Более короткие доказательства членства

При использовании двоичного дерева вместо дерева с основанием-16 доказательства членства для учетных записей в дереве RSK максимально короткие, а время, необходимое для проверки доказательств членства, приближено к оптимальному. Это позволяет децентрализованным легковесным узлам, работающим на мобильных телефонах, потреблять меньшую пропускную способность соединения и меньше энергии. В следующем примере, представленном на схеме, для дерева radix-16 требуется 30 указателей (колец) и 3 узла (кружки), чтобы доказать существование целевого узла (синий кружок). Дереву radix-2 необходимо только 8 указателей и 8 узлов. Так как переданные узлы не требуют передачи родительских ссылок, ввиду того, что их ссылки могут быть вычислены динамически, и, следовательно, для двоичного доказательства требуется 26% пространства дерева radix-16.

Сравнение между доказательством членства оснований radix-16 и radix-2.

Уменьшение размера состояния путем сжатия узлов учетных записей

Учетным записям в Unitrie не требуется хранить профиль корневого хеша «хранилище» или профиль хэш-кода, это означает, что почти 60% данных учетной записи удаляется из состояния. Например, учетная запись, в которой хранится 1 RBTC, потребляет около 38 байтов вместо 104 байтов, используемых в Эфириуме. Следующая схема демонстрирует приблизительную экономию пространства при удалении ненужных полей.

Сжатие учетных узлов путем удаления ненужных полей

Уменьшение размера состояния за счет внедрения небольших узлов

Для дочерних узлов, размер которых меньше ~ 44 байт (точное значение будет уточнено позднее), Unitrie предоставляет возможность встраивать их непосредственно в родительские узлы. Эта функция описана вRSKIP107. Большинство учетных записей имеют узлы размером от 31 до 41 байта, следовательно, большинство учетных записей будут встроены в родительские узлы. Это уменьшит накладные расходы учетной записи на 62%. Уменьшение размера для учетных записей, посредством встраивания узлов в сочетании с более короткими записями учетных записей, достигает 81%, что не только уменьшает время, требующееся на синхронизацию и снижает требования к ресурсам полного узла, но также понижает риск DoS-атаки, которая размещает спам с помощью созданий учетных записей. В примере, представленном на следующей схеме показано, как узел, имеющий два дочерних узла в дереве Эфириум, преобразуется в один узел с дочерним узлом, встроенным в Unitrie.

Встраивание двух маленьких узлов в родительский

Уменьшение размера состояния и снижение затрат на газ за счет сжатия ключей ячейки памяти

Наш RSKIP108 описывает, как могут быть сжаты ячейки памяти, когда ключи хранилища имеют длинные нулевые префиксы. Ячейки, которые имеют однобайтовые адреса и хранят отдельные байты, могут быть сжаты до 10% от предыдущего несжатого размера, потому что их небольшой размер также позволяет встраивать узлы. Чтобы стимулировать пользователей использовать сжатое хранилище, RSKIP109 обновляет стоимость операций записи в хранилище. Например, для хранения 0x01 по адресу 0x00 потребуется всего 5460 единиц, а не 20K, как в Эфириуме. На следующей схеме изображены различные ключи, используемые в Эфириуме и в Unitrie, для адреса ячейки памяти 0x01.

Пример сжатия ключей хранилища

Лучшая масштабируемость в сочетании с параллельной обработкой транзакций

Наш RSKIP04 предлагает параллельную обработку транзакций, чтобы сократить время обработки блоков. Сокращая время обработки блоков, мы можем быстрее наращивать блоки и улучшать консенсус. Это также означает, что мы можем помещать больше транзакций в блоки без задержки наращивания блоков. В целом, более длительная задержка наращивания блоков выгодна большим майнинговым пулам по сравнению с меньшими, поэтому понимание, что при масштабировании не снижается децентрализация, станет обнадеживающим фактом. Однако блокчейн может получить выгоду от параллельной обработки транзакций только в том случае, если транзакции могут быть разбиты на непересекающиеся наборы с точки зрения доступа к состоянию контракта. Если все транзакции вызывают один токен-контракт, этот контракт вызывает сериализацию транзакций и становится «узким местом» в системе. Одно из решений, указанных в RSKIP59, заключается в проектировании контрактов так, чтобы ячейки хранения контрактов перемещались в субконтракты, создавая отношения типа «исходный-порожденный». Затем балансы токенов для разных пользователей сохраняются в разных договорах. Тем не менее, это решение требует пересмотра и реализации контрактов, заставляющих использовать определенные шаблоны проектирования для обеспечения масштабируемости. Тем не менее, предложение Unitrie способно решить эту проблему, не создавая препятствий для использования новых шаблонов. Unitrie позволяет упростить обнаружение одновременных обращений к ячейкам памяти, а не только одновременные обращения к полным контрактам. Это означает, что если только две транзакции не записывают одни и те же ячейки памяти (или одна читает ячейку, которую записала другая), обе могут выполняться одновременно. Например, контракты ERC20 обычно меняют только ячейки, связанные с исходной и целевой учетными записями, поэтому эти контракты получат возможность немедленного распараллеливания с обнаружением на уровне ячейки. Несмотря на то, что то же самое может быть достигнуто и без Unitrie, Unitrie значительно упрощает алгоритм обнаружения конфликтов записи. В качестве примера на следующей схеме представлено два потока, обрабатывающих транзакции. Поток 1 изменяет ячейку контракта C (на которую указывает фиолетовая стрелка), на которую не влияет Поток 2. Поток 2, в свою очередь, изменяет две другие ячейки из того же контракта, которые не влияют на ячейку, измененную Потоком 1.

Два потока выполнения, изменяющие одно и то же хранилище контрактов

Устранение дискриминации при аренде хранилища

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

Аренда хранилища сглаживает обе проблемы. Наиболее обсуждаемая и принятая форма аренды хранилища требует, чтобы пользователи, взаимодействующие в рамках контракта, платили комиссию, пропорциональную времени, в течение которого контракт был неактивным, и пропорционально объему памяти, занимаемому контрактом во время бездействия. RSKIP61 предлагает использовать договоры аренды для предотвращения ряда нежелательных последствий использования оригинальной конструкции EVM, которая влияет на справедливость платформы. Хотя это предполагает некую вероятностную справедливость, все же такая система является шероховатой и неэффективной в пограничных случаях. Коллективный контракт, в котором хранятся но редко используется миллионы пар «ключ/значение», приведет к чрезмерной нагрузке на аренду хранилища для первого пользователя, который использует его после длительного периода бездействия. Unitrie упрощает задачу отслеживания времени последнего доступа для отдельных ячеек хранилища, так что аренда хранилища может быть поделена, что позволяет оплачивать аренду только за ячейки, участвующие в выполнении контракта. Это упрощение, описанное в RSKIP113, является результатом того, что все узлы обрабатываются одинаково, поэтому учетная запись, код и ячейки памяти могут списывать арендную плату при обращении к ним.

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

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

Более быстрая и простая синхронизация состояний

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

Однако, что наиболее важно, Untrie обеспечивает быструю и параллельную загрузку информации о состоянии для выполнения команд синхронизации «Fast Sync» или «Warp Sync.» Узлы могут получать информацию о состоянии быстрее и проще, если вся информация хранится в одном дереве. Поскольку Unitrie хранит количество байтов, потребляемых поддеревом, укорененным в каждом узле, структура данных Unitrie поддерживает запросы диапазона этих размеров. Это может использоваться одноранговыми узлами для запроса «пакетов» определенного размера, начиная с любого байтового смещения. Следовательно, запросы могут быть эффективно распараллелены. Например, узел может собирать информацию о состоянии от 10 узлов и запрашивать диапазон байтов от 0K до 100K до первого, от 100K до 200K до второго и так далее. Это позволяет создать режим синхронизации, который сочетает в себе преимущества быстрой синхронизации (немедленная проверка возвращаемых данных) с преимуществами Warp-синхронизации (одновременное получение больших фрагментов данных из нескольких источников). На следующей схеме представлен пример Unitrie, отображающий размеры поддерева узла. Дерево можно разделить на три блока, каждый из которых содержит почти одинаковое количество данных и должен быть запрошен для другого партнера. Даже если запрашивающая сторона не знает содержимого и пределов каждого фрагмента, размеры фрагментов известны ей заранее. Каждый блок может быть эффективно и независимо проверен при получении. Некоторые внутренние узлы включены в несколько блоков для обеспечения их проверки.

Состояние Unitrie разделено на три проверяемых независимо друг от друга блока

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

Меньший блокчейн с помощью автоматической дедупликации кода

Объединяя ячейки хранения и код в единую базу данных с адресным содержимым, узлы, содержащие один и тот же ключ/значение, сохраняются в базе данных только один раз. Это обеспечивает автоматическую дедупликацию данных, которая в случае кода контракта может уменьшить размер блокчейна, не требуя отдельного механизма дедупликации или использования методов сжатия данных. Узлы кода в дереве всегда будут содержать один и тот же префикс (0x80); следовательно, один и тот же код подразумевает одинаковый хеш-узел и одинаковое хранилище.

Ускоренное выполнение EXTCODESIZE

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

Данные метода обновления

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

Для успешного обновления сети должно произойти несколько событий. Новая версия программного обеспечения полного узла будет выпущена во время R. Новая версиябудет содержать периодические контрольные точки из первичного блока в конкретный блок во время C. Время C наступает раньше времени R. Затем будет интервал, в котором узлы будут обновляться перед хард-форком во время H. На следующей схеме представлена временная шкала:

Сроки обновления сети для Unitrie

Когда новая версия (которую мы назовем 0.7.0) установлена, полный узел должен будет перестроить свою базу данных состояний в соответствии с новыми правилами. Он может либо перенести текущее состояние, либо пересчитать состояние путем повторной обработки всех блоков от первоначального до конца цепи. Для обновления RSK мы выбрали повторную обработку. Это обеспечивает полную синхронизацию баз данных всех узлов, даже если предыдущая база данных ранее была каким-либо образом повреждена.

Событие C выбрано так, чтобы оно произошло примерно за две недели до хард-форка. Пользователи должны будут обновить свое программное обеспечение для полных узлов после даты выпуска R, но до даты хард-форка H. В течение периода C-H узлы будут вычислять как старые, так и новые корни состояния. Старый каталог состояния будет динамически вычисляться из нового состояния. Легковесные узлы (например, узлы SPV) могут принять решение не проверять каталоги состояний в течение этого короткого интервала для снижения нагрузки на процессор. Это связано с тем, что легковесные узлы в любом случае последуют за хэшрейтом (вычислительной мощностью). Кроме того, узлы могут уменьшить накладные расходы в течение этого периода, например, проверяя 1 из каждых 10 подтверждений каталогов состояний в течение интервала C-H. Однако первый блок после хард-форка больше не будет вычислять или проверять старые каталоги состояний. В случае одобрения сообществом, мы ожидаем что хард-форк пройдет успешно.

Заключение

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

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