Ardor и Конкуренты, ч. 8: Ethereum (Раздувание блокчейна)

Перевод статьи с английского, источник https://www.nxter.org/ardor-vs-competition-pt-8-ethereum-blockchain-bloat/

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

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

Главным в этом сравнении является понимание того, как организован блокчейн Ethereum.

Структура Ethereum

Как и Nxt, Ethereum отслеживает текущее состояние всех аккаунтов с появлением каждого нового блока. И как Биткойн, Ethereum хранит информацию в каждом блоке древовидной структуры Merkle (а именно, три из них) и сохраняет свой корневой хеш в заголовке блока.

Как именно это работает? Диаграммы в этой статье помогают наглядно рассмотреть это.

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

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

Простое объединение всех листьев нод вместе и хеширование их всех одновременно приведет к аналогичному результату, но древовидная структура имеет второе хорошее свойство, которое заключается в том, что можно доказать, что один лист находится в дереве, не видя всего дерева. Например, на этой диаграмме можно доказать, что зеленая транзакция была включена при её осуществлении одноранговому элементу, в желтый, родительский, в серый и в другие одноранговые и родительские элементы по пути назад к корню. Другой пользователь может вычислить соответствующие хеши на каждом уровне дерева, а затем сравнить полученный корень Merkle с тем, который хранится на блокчейне. Эти «доказательства Merkle» являются основой для упрощенной Bitcoin проверки платежей клиентов (SPV), а также для некоторых предложений по масштабированию Ethereum.

Ethereum использует три отдельных структуры дерева Merkle для записи данных в каждом блоке: одна для осуществления блочной транзакций; вторая - для набора «квитанций поступлений» для этих транзакций, которые отражают эффективность каждой транзакции; и третья для записи текущего состояния всех учетных записей, включая их балансы и связанные данные. Хранение всего состояния системы каждого блока звучит совсем нерационально, но поскольку каждый блок изменяет только очень небольшое подмножество листовых нод, большинство ответвлений дерева состояний не меняются от блока к блоку, и каждое новое дерево состояний может ссылаться на целые ветви предыдущего с минимальным потреблением ресурсов. В использовании этого подхода есть несколько технических сложностей, и по этой причине Ethereum фактически использует немного другую структуру данных, называемую деревом Merkle-Patricia, но концепция та же.

Fast-Sync ноды платформы Ethereum

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

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

Этот подход показывает именно то, как работает fast-sync функция кошелька Go Ethereum (geth). Чтобы выполнить быструю синхронизацию, новая нода сначала загружает и проверяет все заголовки блоков, начиная с блока генезиса (на самом деле нужно проверить только каждый 100-й заголовок блока, подробнее см. ссылку GitHub). Поскольку заголовки содержат доказательство выполнения работы (PoW), этого шага достаточно, чтобы показать, что сеть достигла консенсуса относительно корней Merkle в каждом заголовке на тот момент, когда майнинг блока.

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

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

Сокращение дочерней цепи на Ardor

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

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

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

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

Надеемся, что сравнение с опцией быстрой синхронизации geth является понятным на этом этапе: в обоих случаях узлам не нужно хранить подавляющее большинство данных транзакций, чтобы иметь возможность проверить, что сеть одобрила эти транзакции в тот момент, когда они были созданы. На платформе Ethereum достаточно проверить доказательство выполнения действий (PoW) в заголовках блоков и точность любого заданного корня Merkle, чтобы иметь возможность доверять соответствующему дереву состояний. На платформе Ardor немного сложнее, потому что она использует консенсус доказательство владения долей (PoS), но сохраняя полную запись ARDR транзакций вместе с ChildChainBlock транзакциями она гарантирует, что узлы могут проверять, начиная с генезис блока, что каждый блок форжировался определённым форжером.

Сравнение двух платформ

В данном случае, надеюсь, вы согласны со мной в том, что мы можем провести следующие параллели между Ethereum и Ardor:

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

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

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

В этой заметке мне кажется, что деревья Merkle на платформе Ethereum, естественно, могут вместить такой дизайн, где «полный узел Golem» будет искать полный блокчейн для всех транзакций, включающих GNT, всегда хранить Merkle доказательства для этих транзакций и переходов состояний и отсеять оставшиеся данные. Я признаю, что я даже не думал о последствиях этой идеи, поэтому я не буду более говорить об этом.

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

Говоря о шардинге...

Шардинг

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

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

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

Если разработчики смогут воплотить эту идею, то платформа Ardor будет очень похожа на «базовый дизайн блокчейна шардинга», описанного в документе команды Ethereum. Этот раздел статьи описывает набор «collator» (bundler) нод, наполненных собирающими (связанными) транзакциями из одного шарда (дочерняя цепочка), проверяющих их и записывающих их хеш в «collation заголовок» (транзакция ChildChainBlock) на основном (родительском) блокчейне. «Переполненные ноды» (текущие ноды родительской цепочки) будут обрабатывать все транзакции из всех шардов; «Ноды верхнего уровня» (будущие ноды родительской цепочки) будут обрабатывать только основные блокчейны, но не полное содержимое всех подборок; и «ноды с одним шардом» (будущие ноды дочерней сети) будут обрабатывать все транзакции в основной цепочке и один шард.

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

Заключение

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

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

С другой стороны, основным недостатком существующего проекта Ethereum является то, что где-то в сети всё еще должны быть полные ноды, и эти ноды должны хранить все 300+ ГБ информации Ethereum блокчейна. По мере того, как он продолжает расти, и стоимость работы с полной нодой растет вместе с ним, можно было бы ожидать, что доля полных нод относительно быстро синхронизирующих и мало весящих нод естественно уменьшится. Как следствие, каждая полная нода, вероятно, будет обрабатывать возрастающий объем запросов от других нод, что еще больше увеличивает стоимость (с точки зрения пропускной способности и вычислительной мощности) работы полного узла.

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

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

Перевод статьи с английского, источник https://www.nxter.org/ardor-vs-competition-pt-8-ethereum-blockchain-bloat/