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

В этом посте мы углубляемся в детали проблемы доступности данных и влияние этого на масштабирование на Ethereum.

Что такое проблема доступности данных?

Проблема доступности данных (DA): Как участники сети блокчейн могут быть уверены, что все данные в только что предложенном блоке действительно доступны? Если данные недоступны, блок может содержать злонамеренные транзакции, которые скрываются производителем блока. Даже если блок содержит не злонамеренные транзакции, их скрытие может подорвать безопасность системы.

Для примера, предположим, что Алиса является оператором ZK-Rollup (ZKR)Она представляет доказательство ZK на Ethereum, которое проверяется. Если она не представляет все транзакционные данные на Ethereum, хотя ее доказательство доказывает, что все состояния, произведенные в rollup, являются действительными, пользователи rollup могут остаться в неведении относительно своих текущих балансов счетов. Представленное доказательство не проливает свет на текущие состояния из-за его нулевой прозрачности.

Существует аналогичный пример в Оптимистичный Роллап (OPR)настройка, в которой Алиса отправляет утверждение на Ethereum, но ни один из участников OPR не может оспорить его, потому что транзакционные данные недоступны, и, следовательно, они не могут пересчитать или оспорить утверждение.

Для противодействия вышеупомянутым сценариям как дизайн OPR, так и ZKR обязывают операторов предоставлять все детали транзакций на Ethereumкак «calldata». Хотя это позволяет им избежать проблемы DA в краткосрочной перспективе, с увеличением числа транзакций внутри роллапов также будет расти объем данных, который необходимо представить, что ограничит возможности масштабирования, которые могут предложить эти роллапы.

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

Как это сказывается на блокчейне сегодня?

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

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

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

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

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

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

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

Давайте немного поглубже вникнем в проблему с помощью примера. Предположим, что производитель блока Алиса строит блок В с транзакциями tx1, tx2, …, txn. Предположим, что tx1 - злонамеренная транзакция. Если tx1 транслируется, любой полный узел может проверить, что она злонамеренная, и отправить это легкому клиенту в виде доказательства мошенничества, который сразу узнает, что блок не приемлем. Однако, если Алиса хочет скрыть tx1, она раскрывает заголовок и все транзакционные данные, кроме tx1. Полные узлы не могут проверить правильность tx1.

Кто-то может подумать, что простое решение заключается в том, чтобы все легкие клиенты просто выбирали транзакции случайным образом, и если они обнаруживают, что их выборки доступны, они могут быть уверены, что блок доступен. Пусть легкие узлы запрашивают любую одну транзакцию, равномерно случайным образом. Вероятность того, что легкий клиент запросит tx1, равна 1/n. Таким образом, с огромной вероятностью Алисе удается обмануть легких клиентов, заставив их принять вредоносную транзакцию. Другими словами, большинство легких клиентов будут обмануты. Из-за неатрибутивного характера полные узлы не могут каким-либо образом доказать, что tx1 недоступен. К сожалению, увеличение количества образцов не делает ситуацию намного лучше.

Итак, что нам делать с этим?

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

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

Если мы заставим производителя блоков кодировать стирание транзакций tx1, tx2, …, txn, то, чтобы скрыть одну транзакцию, ему потребуется скрыть n+1 блок данных, так как любые n достаточно для восстановления всего набора транзакций. В этом случае постоянное количество запросов дает легкому клиенту очень высокую уверенность в том, что базовые данные действительно доступны.

Вау, так вот это?

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

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

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

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

Итак, как работают эти решения?

Недавно много внимания в блокчейн-сфере привлекли коммитменты полиномов. Эти коммитменты полиномов, особенно постоянного размера обязательства KZG/Kate к полиномам, можно использовать для разработки аккуратной схемы DA без необходимости доказательств мошенничества. Другими словами, обязательства KZG позволяют нам обязать полином с использованием одного элемента группы эллиптической кривой. Более того, схема позволяет нам доказать, что в некоторой точке i полином φ вычисляется как φ(i) с использованием постоянного по размеру свидетеля. Схема обязательства вычислительно обязывающая и также гомоморфная, что позволяет нам изящно избежать доказательств мошенничества.

Мы заставляем производителя блока взять исходные транзакционные данные и упорядочить их в 2D-матрицу размером n x m. Он использует полиномиальную интерполяцию для расширения каждого столбца размером n в столбцы размером 2n. Каждая строка этой расширенной матрицы генерирует полиномиальную привязку и отправляет эти привязки в виде части заголовка блока. Ниже приведено схематическое представление блока.

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

Схематическое изображение блока

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

Какие есть другие альтернативы и что дальше?

Код стирания более высокой размерности и обязательства по KZG не являются единственными способами решения проблемы ПДР. Есть и другие способы, которые мы здесь пропустили, например, Закодированные деревья Меркля, Закодированное переплетающееся дерево, ПТ, и подходы на основе STARK, но у каждого свои достоинства и недостатки.

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

Отказ от ответственности:

1. Эта статья перепечатана из [Команда Avail]. Все авторские права принадлежат оригинальному автору [Команда Avail]. Если у вас есть возражения к этому перепечатыванию, пожалуйста, свяжитесь с [GateGate Учитькоманды, и они оперативно разберутся с этим.

2. Ответственность за отказ: Взгляды и мнения, выраженные в этой статье, являются исключительно мнением автора и не являются инвестиционным советом.

3. Переводы статьи на другие языки выполняются командой Gate Learn. Если не указано иное, копирование, распространение или плагиат переведенных статей запрещены.