Автор: Kernel Ventures Джерри Луо

Рецензенты: Kernel Ventures Мэнди, Kernel Ventures Джошуа

TLDR:

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

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

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

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

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

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

1. История

Будучи распределенным реестром, блокчейн должен хранить исторические данные на всех узлах, чтобы обеспечить безопасность и достаточную децентрализацию хранения данных. Поскольку правильность каждого изменения состояния связана с предыдущим состоянием (источником транзакции), для обеспечения правильности транзакций блокчейн должен в принципе хранить все исторические записи от первой транзакции до текущей транзакции. Если взять в качестве примера Ethereum, то даже если средний размер блока оценивается в 20 КБ, текущий общий размер блоков Ethereum достиг 370 ГБ. Помимо самого блока, полный узел также должен записывать статус и поступления транзакций. . С учетом этой части общая емкость хранилища одного узла превысила 1 ТБ, что концентрирует работу узла на нескольких людях.

Последняя высота блока Ethereum, источник изображения: Etherscan

Недавнее обновление Ethereum Cancun направлено на увеличение TPS Ethereum примерно до 1000. К тому времени годовой прирост хранилища Ethereum превысит сумму его текущей емкости хранилища. Среди различных высокопроизводительных публичных сетей, ставших популярными в последнее время, скорость транзакций десятков тысяч TPS может даже приносить в среднем сотни ГБ новых данных каждый день. Очевидно, что общий метод избыточности данных всего узла сети не может адаптироваться к такому давлению на хранилище. Уровень 1 должен найти подходящее решение, чтобы сбалансировать рост TPS и стоимость хранения узла.

2. Показатели эффективности DA

2.1 Безопасность

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

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

  • Проверка доступности данных: количество избыточностей гарантирует наличие достаточного количества записей данных в сети, но точность и полнота используемых данных должны быть проверены. Обычно используемым методом проверки в текущем блокчейне является алгоритм криптографического подтверждения, который сохраняет небольшое криптографическое обязательство для записи всей сетью. Это обязательство получается путем смешивания данных транзакций. Если вы хотите проверить подлинность определенного фрагмента исторических данных, вам необходимо восстановить криптографическое подтверждение с помощью данных и проверить, соответствует ли криптографическое подтверждение, полученное в результате этого восстановления, записям всей сети. , проверка пройдена. Обычно используемые алгоритмы проверки криптографии включают Merkle Root и Verkle Root. Алгоритм проверки доступности данных с высоким уровнем безопасности требует лишь небольшого объема проверочных данных и может быстро проверять исторические данные.

2.2 Затраты на хранение

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

2.3 Скорость чтения данных

После достижения снижения затрат следующим шагом является повышение эффективности, то есть возможность быстрого вызова данных с уровня DA, когда их необходимо использовать. Этот процесс включает в себя два этапа. Первый — поиск узлов, хранящих данные. Этот процесс предназначен в основном для общедоступных цепочек, в которых не достигнута согласованность данных во всей сети. можно игнорировать время, затрачиваемое на процесс. Во-вторых, в современных основных системах блокчейнов, включая Биткойн, Ethereum и Filecoin, методом хранения узлов является база данных Leveldb. В Leveldb данные хранятся тремя способами. Во-первых, данные, записанные немедленно, будут сохранены в файлах типа Memtable. Когда хранилище Memtable заполнится, тип файла будет изменен с Memtable на Immutable Memtable. Оба типа файлов хранятся в памяти, но файлы Immutable Memtable уже нельзя изменить, из них можно только читать данные. Горячее хранилище, используемое в сети IPFS, хранит данные в этой части. При вызове их можно быстро прочитать из памяти. Однако мобильная память обычного узла часто имеет уровень ГБ, и ее легко записывать медленно. и когда произойдет сбой узла или другая нештатная ситуация, данные в памяти будут безвозвратно потеряны. Если вы хотите, чтобы данные хранились постоянно, вам необходимо сохранить их в виде файла SST на твердотельном диске (SSD). Однако при чтении данных вам необходимо сначала прочитать данные в памяти. что значительно снижает скорость индексации данных. Наконец, для систем, использующих сегментированное хранилище, восстановление данных требует отправки запросов данных на несколько узлов и их восстановления. Этот процесс также снизит скорость чтения данных.

Метод хранения данных Leveldb, источник изображения: Leveldb-справочник

2.4 Универсальность уровня DA

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

3. Исследование технологий, связанных с DA

3.1 Шардинг

  • В традиционной распределенной системе файл не хранится в полной форме на определенном узле. Вместо этого исходные данные делятся на несколько блоков, и в каждом узле хранится один блок. И блоки часто не хранятся только на одном узле, а оставляют соответствующие резервные копии на других узлах. В существующих основных распределенных системах это количество резервных копий обычно установлено равным 2. Этот механизм шардинга может снизить нагрузку на хранилище одного узла, расширить общую емкость системы до суммы емкости хранилища каждого узла и в то же время обеспечить безопасность хранения за счет соответствующей избыточности данных. Схема шардинга, принятая в блокчейне, в целом аналогична, но конкретные детали будут другими. Прежде всего, поскольку каждый узел в блокчейне по умолчанию ненадежен, процесс реализации шардинга требует достаточно большого объема резервных копий данных для последующего определения подлинности данных, поэтому количество резервных копий для этого узла должно быть намного больше, чем 2. . В идеале в системе блокчейна, использующей эту схему хранения, если общее количество узлов проверки равно T, а количество шардов равно N, то количество резервных копий должно быть T/N. Второй — процесс хранения блоков. В традиционных распределенных системах узлов меньше, поэтому один узел часто адаптируется к нескольким блокам данных. Сначала данные сопоставляются с хэш-кольцом с помощью алгоритма согласованного хеширования, а затем каждый узел сохраняет данные. блоки пронумерованы в определенном диапазоне и могут принять, что узел не распределяет задачи хранения во время определенного хранения. В блокчейне присвоение каждому узлу блока больше не является случайным событием, а неизбежным событием. Каждый узел случайным образом выбирает блок для хранения. Этот процесс объединяет исходные данные с блоком и собственной информацией узла. хеширование данных завершается взятием модуля количества шардов. Если предположить, что каждый фрагмент данных разделен на N блоков, фактический размер хранилища каждого узла составляет всего 1/N от исходного. Правильно установив N, можно достичь баланса между ростом TPS и нагрузкой на хранилище узла.

Метод хранения данных после шардинга, источник изображения: Kernel Ventures

3.2 DAS (выборка доступности данных)

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

  • Код-ластик: Учитывая огромное количество узлов проверки в Эфириуме, вероятность того, что определенный Блок не будет сохранен ни на одном узле, практически равна 0, но теоретически вероятность возникновения такой экстремальной ситуации все же существует. Чтобы смягчить возможную угрозу потери памяти, в соответствии с этой схемой исходные данные часто не делятся напрямую на блоки для хранения. Вместо этого исходные данные сначала сопоставляются с коэффициентами полинома n-го порядка, а затем 2n. взяты из полиномиальных точек, и пусть узел случайным образом выбирает одну из них для хранения. Для этого полинома n-го порядка для его восстановления необходимо всего n+1 точек. Следовательно, по узлам нужно выбрать только половину блоков, и мы сможем восстановить исходные данные. Благодаря коду Eraser повышается безопасность хранения данных и возможности восстановления данных в сети.

  • Полиномиальное обязательство KZG: очень важной частью хранения данных является проверка их подлинности. В сети, которая не использует код Eraser, в процессе проверки могут использоваться различные методы. Однако, если вышеуказанный код Eraser введен для повышения безопасности данных, то более подходящим методом является использование полиномиального обязательства KZG. KZG Polynomial Commitment может напрямую проверять содержимое одного блока в форме полиномов, тем самым исключая процесс сведения полиномов к двоичным данным. Форма проверки в целом аналогична дереву Меркла, но не требует только конкретных данных узла пути. KZG Root. Его подлинность можно проверить с помощью данных блока.

3.3 Метод проверки данных уровня DA

Проверка данных гарантирует, что данные, вызванные с узла, не были подделаны и не потеряны. Чтобы минимизировать объем данных и затраты на вычисления, необходимые в процессе проверки, уровень DA в настоящее время использует древовидную структуру в качестве основного метода проверки. Самая простая форма — использовать для проверки дерево Меркла, которое записывается в виде полного двоичного дерева. Для проверки вам нужно только сохранить корень Меркла и хэш-значение поддерева на другой стороне пути узла. время проверки сложное. Степень соответствует уровню O(logN) (если logN не добавляет основание, по умолчанию используется значение log2(N)). Хотя процесс проверки был значительно упрощен, общий объем данных процесса проверки по-прежнему растет с увеличением количества данных. Для решения проблемы увеличения объёма верификации на данном этапе предлагается ещё один метод верификации — Дерево Веркла. Помимо хранения значения, каждый узел в дереве Verkle также имеет векторное обязательство. Благодаря значению исходного узла и этому доказательству обязательства подлинность данных можно быстро проверить, не вызывая значения других сестер. узлов, что делает каждый раз количество проверочных вычислений связано только с глубиной Дерева Веркле и является фиксированной константой, что значительно ускоряет скорость проверки. Однако вычисление Vector Commitment требует участия всех сестринских узлов одного уровня, что значительно увеличивает стоимость записи и изменения данных. Однако для таких данных, как исторические данные, которые хранятся постоянно и не могут быть изменены, и их нужно только читать, но не записывать, Verkle Tree чрезвычайно подходит. Кроме того, у деревьев Меркла и дерева Веркла есть варианты в K-арной форме. Их конкретные механизмы реализации аналогичны, за исключением того, что количество поддеревьев в каждом узле изменено. Сравнение их конкретной производительности можно увидеть в таблице ниже.

Сравнение временных характеристик методов проверки данных. Источник изображения: Verkle Trees.

3.4 Общее промежуточное программное обеспечение DA

Постоянное расширение экосистемы блокчейна привело к постоянному увеличению количества публичных цепей. Из-за преимуществ и незаменимости каждой публичной цепи в своих областях практически невозможно объединить публичные цепи уровня 1 за короткий период времени. Однако с развитием DeFi и различными проблемами с CEX требования пользователей к децентрализованным кросс-чейновым торговым активам также растут. Поэтому многоцепочному хранилищу данных на уровне DA, которое может устранить проблемы безопасности при межцепочном взаимодействии данных, уделяется все больше и больше внимания. Однако, чтобы принимать исторические данные из различных общедоступных цепочек, уровень DA должен предоставить децентрализованный протокол для стандартизированного хранения и проверки потоков данных. Например, kvye, промежуточное программное обеспечение для хранения данных на основе Arweave, активно извлекает данные из цепочки и может все это делать. Данные в цепочке хранятся в Arweave в стандартной форме, чтобы минимизировать различия в процессе передачи данных. Условно говоря, уровень 2, который специально обеспечивает хранилище данных уровня DA для определенной общедоступной цепочки, взаимодействует с данными через внутренние общие узлы. Хотя он снижает стоимость взаимодействия и повышает безопасность, он имеет относительно большие ограничения и может предоставлять данные только определенной публике. сети предоставляют услуги.

4. Решение для хранения данных уровня DA

4.1 Основная цепь DA

4.1.1 Класс DankSharding

У этого типа решения для хранения пока нет определенного названия, и наиболее ярким представителем является DankSharding на Ethereum, поэтому в этой статье для обозначения этого типа решения используется класс DankSharding. В этом типе решения в основном используются две упомянутые выше технологии хранения DA: шардинг и DAS. Сначала данные делятся на соответствующие общие ресурсы посредством шардинга, а затем каждый узел извлекает блок данных в виде DAS для хранения. Если во всей сети достаточно узлов, мы можем выбрать большее количество шардов N, чтобы нагрузка на хранилище каждого узла составляла всего 1/N от исходной, тем самым достигая расширения общего пространства хранения в N раз. При этом, чтобы не допустить экстремальной ситуации, когда определенный Блок не сохраняется ни в одном блоке, DankSharding кодирует данные с помощью Eraser Code, и полностью восстановить можно только половину данных. Последним шагом является процесс проверки данных, в котором для обеспечения быстрой проверки используется древовидная структура Веркла и полиномиальное обязательство.

4.1.2 Кратковременное хранение

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

4.2 Сторонний DA

4.2.1 DA, специфичный для основной цепочки: EthStorage

  • DA, специфичный для основной цепочки. Самым важным на уровне DA является безопасность передачи данных. На данный момент наиболее безопасным является DA основной цепочки. Однако хранилище основной цепочки имеет ограничения на пространство для хранения и конкуренцию за ресурсы. Поэтому, когда объем сетевых данных быстро растет, сторонний DA будет лучшим выбором, если необходимо обеспечить долгосрочное хранение данных. Если сторонний DA имеет более высокую совместимость с основной сетью, он может реализовать совместное использование узлов, а также будет иметь более высокую безопасность в процессе взаимодействия данных. Таким образом, если принять во внимание безопасность, DA, специфичный для основной цепи, будет иметь огромные преимущества. Если взять в качестве примера Ethereum, то основным требованием к DA, специфичным для основной цепочки, является совместимость с EVM и обеспечение взаимодействия с данными и контрактами Ethereum. Типичные проекты включают Topia, EthStorage и т. д. Среди них EthStorage в настоящее время является наиболее хорошо развитым с точки зрения совместимости, поскольку помимо совместимости на уровне EVM он также специально настроил соответствующие интерфейсы для подключения к инструментам разработки Ethereum, таким как Remix и Hardhat, для достижения совместимости на уровне Ethereum. Уровень инструмента разработки Ethereum.

  • EthStorage: EthStorage — это публичная цепочка, независимая от Ethereum, но узлы, работающие на ней, превосходят узлы Ethereum. То есть узлы, на которых работает EthStorage, также могут одновременно запускать Ethereum. Через коды операций в Ethereum вы можете получить прямой доступ. EthStorage выполняет операции. В модели хранения EthStorage лишь небольшой объем метаданных сохраняется в основной сети Ethereum для индексации, что по сути создает децентрализованную базу данных для Ethereum. В текущем решении EthStorage реализует взаимодействие между основной сетью Ethereum и EthStorage путем развертывания контракта EthStorage в основной сети Ethereum. Если Ethereum хочет сохранить данные, ему необходимо вызвать функцию put() в контракте. Входными параметрами являются двухбайтовые переменные key и data, где data представляет данные, которые нужно сохранить, а key — это их местоположение в сети Ethereum. Идентификацию можно рассматривать как аналогичную существованию CID в IPFS. После того, как пара данных (ключ, данные) будет успешно сохранена в сети EthStorage, EthStorage сгенерирует kvldx и вернет его в основную сеть Ethereum, что соответствует ключу в Ethereum. Это значение соответствует адресу хранения данных в EthStorage. , поэтому изначально это возможно. Проблема необходимости хранения большого объема данных теперь превращается в хранение одной пары (ключ, kvldx), что значительно снижает стоимость хранения в основной сети Ethereum. Если вам нужно вызвать ранее сохраненные данные, вам нужно использовать функцию get() в EthStorage и ввести ключевой параметр. Вы можете быстро выполнить поиск данных на EthStorage через kvldx, хранящийся в Ethereum.

Контракт EthStorage, источник изображения: Kernel Ventures

  • Что касается того, как узлы конкретно хранят данные, EthStorage опирается на модель Arweave. Во-первых, сегментируется большое количество пар (k, v) из ETH. Каждый шардинг содержит фиксированное количество пар данных (k, v). Также существует ограничение на размер каждой пары (k, v). Таким образом обеспечивается справедливость последующей рабочей нагрузки для майнеров в процессе вознаграждения за хранилище. Для выдачи вознаграждений необходимо сначала проверить, хранит ли узел данные. Во время этого процесса EthStorage разделит шардинг (размер уровня ТБ) на множество фрагментов и сохранит корень Merkle в основной сети Ethereum для проверки. Затем майнеру сначала необходимо предоставить nonce для генерации адресов нескольких фрагментов с помощью случайного алгоритма с хешем предыдущего блока на EthStorage. Майнеру необходимо предоставить данные этих фрагментов, чтобы доказать, что он действительно хранит весь шардинг. Но этот nonce не может быть выбран произвольно, иначе узел выберет подходящий nonce, который соответствует только его сохраненному чану, и пройдет проверку. Следовательно, этот nonce должен быть таким, чтобы значение сложности сгенерированного чанка могло соответствовать требованиям сети после смешивания. и хеширование, и только первый узел, представивший одноразовый номер и доказательство произвольного доступа, может получить вознаграждение.

4.2.2 Модульный DA: Селестия

  • Модуль блокчейна: на этом этапе транзакции, которые должна выполнять публичная цепочка Layer1, в основном делятся на следующие четыре части: (1) Разработка базовой логики сети, выбор узлов проверки определенным образом, запись блоков и распределение вознаграждение обслуживающего персонала сети; (2) упаковывать и обрабатывать транзакции и публиковать связанные с ними данные; (3) проверять транзакции, которые будут загружены в цепочку, и определять окончательный статус; (4) хранить и поддерживать исторические данные в блокчейне; В соответствии с различными выполняемыми функциями мы можем разделить блокчейн на четыре модуля, а именно: уровень консенсуса, уровень исполнения, уровень расчетов и уровень доступности данных (уровень DA).

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

  • Модульный DA: сложный метод отделения уровня DA от бизнеса блокчейна и передачи его в публичную цепочку считается возможным решением для растущих исторических данных Layer1. На данном этапе исследования в этой области все еще находятся на начальной стадии, и наиболее представительным проектом на данный момент является Celestia. Что касается конкретного метода хранения, Celestia опирается на метод хранения Danksharding, который также делит данные на несколько блоков, и каждый узел извлекает часть для хранения и использует полиномиальное обязательство KZG для проверки целостности данных. В то же время Celestia использует усовершенствованный двумерный код стирания RS для перезаписи исходных данных в виде матрицы k*k. В конечном итоге можно восстановить только 25% исходных данных. Однако хранилище данных с сегментированием по сути просто умножает нагрузку на хранилище всего сетевого узла на коэффициент общего объема данных. Нагрузка на хранилище узла и объем данных по-прежнему поддерживают линейный рост. Поскольку уровень 1 продолжает улучшать скорость транзакций, нагрузка на хранилища узлов все еще может однажды достичь неприемлемого критического уровня. Для решения этой проблемы в Celestia для обработки вводится компонент IPLD. Данные в матрице k*k не хранятся непосредственно на Celestia, а хранятся в сети LL-IPFS, а в узле сохраняется только CID-код данных по IPFS. Когда пользователь запрашивает часть исторических данных, узел отправляет соответствующий CID компоненту IPLD, и исходные данные будут вызываться в IPFS через этот CID. Если данные существуют в IPFS, они будут возвращены через компонент IPLD, а если они не существуют, данные не могут быть возвращены;

Метод чтения данных Celestia, источник изображения: Celestia Core

  • Celestia: На примере Celestia мы можем получить представление о применении модульного блокчейна для решения проблемы хранения данных в Ethereum. Узел Rollup отправит упакованные и проверенные данные транзакций в Celestia и сохранит данные в Celestia. В ходе этого процесса Celestia сохраняет данные только без излишней осведомленности. Наконец, узел Rollup будет перемещаться в соответствии с размером места хранения. Соответствующие токены TIA будут выплачены Celestia в качестве платы за хранение. Хранилище в Celstia использует DAS и коды стирания, аналогичные тем, что есть в EIP4844, но полиномиальные коды стирания в EIP4844 модернизированы, а двумерные коды стирания RS используются для повторного повышения безопасности хранилища. Только 25% трещин могут восстановить. все данные транзакции. По сути, это просто публичная сеть POS с низкими затратами на хранение. Если ее нужно использовать для решения проблемы хранения исторических данных Ethereum, для взаимодействия с Celestia потребуется множество других конкретных модулей. Например, что касается объединения, на официальном сайте Celestia настоятельно рекомендуется использовать режим Sovereign Rollup. В отличие от обычного Rollup на Layer2, он только рассчитывает и проверяет транзакции, то есть завершает операции уровня исполнения. Sovereign Rollup включает в себя весь процесс исполнения и расчетов, что сводит к минимуму обработку транзакций в Celestia. Когда общая безопасность Celestia слабее, чем у Ethereum, эта мера может максимизировать безопасность всего процесса транзакций. С точки зрения обеспечения безопасности данных, называемых Celestia, основной сетью Ethereum, наиболее распространенным решением на данный момент является смарт-контракт квантового гравитационного моста. Для данных, хранящихся в Celestia, он генерирует Merkle Root (доказательство доступности данных) и сохраняет его в контракте моста квантовой гравитации основной сети Ethereum. Каждый раз, когда Ethereum вызывает исторические данные в Celestia, его хэш-результат будет сравниваться. с Merkle Root используется для сравнения, и если он совпадает, значит, это действительно реальные исторические данные.

4.2.3 Хранение DA публичной сети

С точки зрения технических принципов основной цепи DA, многие технологии, подобные шардингу, заимствованы из публичной цепочки хранения. Среди сторонних DA некоторые напрямую используют общедоступную цепочку хранения для выполнения некоторых задач хранения. Например, данные конкретных транзакций в Celestia размещаются в сети LL-IPFS. В стороннем решении DA, помимо создания отдельной общедоступной цепочки для решения проблемы хранения на уровне 1, более прямым способом является прямое соединение общедоступной цепочки хранения с уровнем 1 для хранения огромных исторических данных на уровне 1. Для высокопроизводительных блокчейнов объем исторических данных еще больше. При работе на полной скорости объем данных высокопроизводительной публичной цепочки Solana приближается к 4 PG, что полностью выходит за пределы диапазона хранения обычных узлов. Решение, которое выбрала Солана, состоит в том, чтобы хранить исторические данные в децентрализованной сети хранения Arweave и хранить данные только за 2 дня на основных узлах сети для проверки. Чтобы обеспечить безопасность хранимого процесса, Solana и Arweave Chain специально разработали протокол моста хранения данных Solar Bridge. Данные, проверенные узлом Solana, будут синхронизированы с Arweave и будет возвращен соответствующий тег. Только через этот тег узел Solana может в любое время просмотреть исторические данные блокчейна Solana. В Arweave нет необходимости всем узлам сети поддерживать согласованность данных и использовать это в качестве порога для участия в работе сети. Вместо этого используется хранилище вознаграждений. Прежде всего, Arweave не использует традиционную структуру цепочки для построения блоков, а больше похожа на структуру графа. В Arweave новый блок будет не только указывать на предыдущий блок, но также случайным образом указывать на сгенерированный блок Recall Block. Конкретное местоположение блока отзыва определяется результатом хеширования предыдущего блока и высотой блока. Местоположение блока отзыва неизвестно до тех пор, пока не будет добыт предыдущий блок. Однако в процессе генерации нового блока узлу необходимо иметь данные блока отзыва, чтобы использовать механизм POW для расчета хеша указанной сложности. Только первый майнер, вычисливший хеш, соответствующий сложности, может получить вознаграждение. что побуждает майнеров хранить как можно больше исторических данных. В то же время, чем меньше людей хранят определенный исторический блок, тем меньше у узлов будет конкурентов при генерации одноразовых номеров, соответствующих сложности, что побуждает майнеров хранить меньше блоков в сети.Наконец, чтобы гарантировать, что узлы постоянно хранят данные в Arweave, он представляет механизм оценки узлов WildFire. Узлы будут иметь тенденцию взаимодействовать с узлами, которые могут быстрее предоставить больше исторических данных, в то время как узлы с более низкими рейтингами часто не могут получить последние данные о блоках и транзакциях как можно скорее и, следовательно, не могут воспользоваться преимуществами конкуренции POW.

Метод построения блоков Arweave, источник изображения: Arweave Yellow-Paper

5. Комплексное сравнение

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

  • Безопасность. Самым большим источником проблем с безопасностью данных являются потери, возникающие в процессе передачи данных, а также злонамеренное вмешательство со стороны нечестных узлов. В межцепочном процессе из-за независимости и статуса двух публичных цепочек безопасность передачи данных имеет первостепенное значение. наиболее пострадавшие районы. Кроме того, уровень 1, которому в настоящее время требуется выделенный уровень DA, часто имеет сильную консенсусную группу, и его собственная безопасность будет намного выше, чем у обычных публичных цепочек хранения. Таким образом, решение DA основной цепи имеет более высокий уровень безопасности. После обеспечения безопасности передачи данных следующим шагом является обеспечение безопасности вызывающих данных. Если рассматривать только краткосрочные исторические данные, используемые для проверки транзакций, те же данные резервируются всей сетью во временной сети хранения. В решении, подобном DankSharding, среднее количество резервных копий данных составляет всего 1/N. количество узлов во всей сети, большая избыточность данных может снизить вероятность потери данных, а также может предоставить больше эталонных образцов во время проверки. Таким образом, временное хранилище будет относительно более безопасным для данных. В стороннем решении DA DA, специфичный для основной цепочки, использует общедоступные узлы с основной цепочкой, и данные могут передаваться напрямую через эти ретрансляционные узлы во время межцепочного процесса, поэтому он будет иметь относительно более высокий уровень безопасности, чем другие решения DA. .

  • Затраты на хранение. Самым большим фактором, влияющим на стоимость хранения, является объем избыточности данных. В решении для краткосрочного хранения основной цепи DA они хранятся в форме синхронизации данных всех узлов сети. Любые вновь сохраненные данные необходимо создавать резервные копии во всех узлах сети, что имеет самую высокую стоимость хранения. Высокая стоимость хранения, в свою очередь, определяет, что этот метод подходит только для временного хранения в сетях с высоким TPS. Второй — метод хранения шардинга, включая шардинг в основной цепочке и шардинг в сторонней DA. Поскольку основная цепочка часто имеет больше узлов, соответствующий блок также будет иметь больше резервных копий, поэтому решение по шардингу основной цепочки будет иметь более высокие затраты. Самая низкая стоимость хранения — это DA общедоступной цепочки хранения, в которой применяется метод хранения с вознаграждением. В этой схеме объем избыточности данных часто колеблется вокруг фиксированной константы. В то же время в общедоступной цепочке хранения данных DA также представлен механизм динамической настройки, чтобы привлечь узлы для хранения меньшего количества резервных копий данных за счет увеличения вознаграждений для обеспечения безопасности данных.

  • Скорость чтения данных. На скорость хранения данных в основном влияет место хранения данных в пространстве хранения, путь индекса данных и распределение данных в узлах. Среди них большее влияние на скорость оказывает место хранения данных на узле, поскольку хранение данных в памяти или SSD может привести к различию скорости чтения в десятки раз. Для хранения общедоступной цепочки DA в основном используется SSD-хранилище, поскольку нагрузка на эту цепочку включает не только данные уровня DA, но также включает в себя личные данные с высоким использованием памяти, такие как видео и изображения, загруженные пользователями. Если сеть не использует SSD в качестве дискового пространства, будет сложно выдерживать огромную нагрузку на хранилище и удовлетворять требования к долгосрочному хранению. Во-вторых, для сторонних DA и DA основной цепочки, которые используют память для хранения данных, стороннему DA сначала необходимо найти соответствующие индексные данные в основной цепочке, а затем передать индексные данные по цепочке третьему. -party DA и вернуть его через мост хранения данных. Напротив, DA основной цепи может напрямую запрашивать данные из узлов и, следовательно, имеет более высокую скорость получения данных. Наконец, в основной цепочке DA метод Sharding требует вызова Block из нескольких узлов и восстановления исходных данных. Поэтому по сравнению с краткосрочным хранилищем без фрагментированного хранилища скорость будет медленнее.

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

Сравнение производительности решений для хранения данных, источник изображения: Kernel Ventures.

6. Резюме

Текущий блокчейн претерпевает трансформацию из Crypto в более инклюзивный Web3. Этот процесс приносит не только множество проектов в блокчейне. Чтобы обеспечить одновременную работу такого количества проектов на уровне 1, обеспечивая при этом работу проектов Gamefi и Socialfi, уровень 1, представленный Ethereum, принял такие методы, как Rollup и Blobs, для улучшения TPS. Среди новых блокчейнов также растет количество высокопроизводительных. Но более высокий TPS означает не только более высокую производительность, но и большую нагрузку на хранилище в сети. Для массивных исторических данных в настоящее время предлагаются различные методы DA, основанные на основной цепочке и третьих сторонах, чтобы адаптироваться к увеличению нагрузки на хранилище внутри цепочки. Каждый метод улучшения имеет преимущества и недостатки и по-разному применим в разных ситуациях.

Блокчейны, ориентированные на платежи, предъявляют чрезвычайно высокие требования к безопасности исторических данных и не стремятся к особо высокому TPS. Если этот тип публичной цепочки все еще находится на стадии подготовки, можно использовать метод хранения, подобный DankSharding, который может обеспечить огромное увеличение емкости хранилища, обеспечивая при этом безопасность. Однако, если это публичная цепочка, такая как Биткойн, которая уже сформировалась и имеет большое количество узлов, существуют огромные риски необдуманных улучшений на уровне консенсуса. Поэтому основная цепочка выделена DA с более высоким уровнем безопасности в хранилище вне цепочки. может использоваться для балансирования вопросов безопасности и хранения. Но стоит отметить, что функции блокчейна не статичны, а постоянно меняются. Например, ранние функции Ethereum в основном ограничивались платежами и простой автоматизированной обработкой активов и транзакций с использованием смарт-контрактов. Однако по мере того, как ландшафт блокчейна продолжает расширяться, к Ethereum постепенно добавлялись различные проекты Socialfi и Defi. в более комплексном направлении. В последнее время, с бурным ростом экологии надписей на Биткойн, комиссии за транзакции в сети Биткойн выросли почти в 20 раз с августа. Это отражает то, что скорость транзакций сети Биткойн на данном этапе не может удовлетворить спрос на транзакции, и трейдеры могут только это сделать. Повышение комиссий позволяет максимально ускорить обработку транзакций. Теперь сообществу Биткойн необходимо найти компромисс: соглашаться ли с высокими комиссиями и низкой скоростью транзакций или снизить безопасность сети, чтобы увеличить скорость транзакций, но противоречить первоначальному замыслу платежной системы. Если биткойн-сообщество выберет последнее, то в условиях растущего давления на данные соответствующее решение для хранения также необходимо будет скорректировать.

Комиссия за транзакцию в основной сети Биткойн колеблется, источник изображения: OKLINK

Публичные сети с комплексными функциями более требовательны к TPS, а рост исторических данных еще больше. Трудно адаптироваться к быстрому росту TPS в долгосрочной перспективе, приняв такое решение, как DankSharding. Поэтому более подходящим способом является перенос данных на хранение в сторонний DA. Среди них DA, специфичный для основной цепочки, имеет самую высокую совместимость и может иметь больше преимуществ, если учитывать только проблемы хранения одной публичной цепочки. Но сегодня, когда публичные сети уровня 1 процветают, межсетевая передача активов и взаимодействие данных стали обычным занятием сообщества блокчейнов. Если принять во внимание долгосрочное развитие всей экосистемы блокчейна, хранение исторических данных разных публичных цепочек в одной публичной цепочке может устранить многие проблемы безопасности в процессе обмена и проверки данных. Таким образом, разница между модульным DA и хранилищем. публичная сеть DA может быть лучшим выбором. Исходя из высокой универсальности, модульный DA фокусируется на предоставлении услуг уровня блокчейна DA, вводя более совершенные исторические данные управления индексными данными, которые могут разумно классифицировать различные данные общедоступной цепочки и хранить данные общедоступной цепочки. Однако приведенное выше решение не учитывает стоимость корректировки уровня консенсуса в существующей публичной цепочке. Этот процесс чрезвычайно рискован. Если возникают проблемы, это может привести к системным уязвимостям и привести к потере консенсуса сообщества. Поэтому, если это переходное решение в процессе расширения блокчейна, более подходящим может оказаться простейшее временное хранилище основной цепочки. Наконец, приведенное выше обсуждение основано на производительности во время реальной работы. Однако, если целью определенной публичной сети является развитие собственной экологии и привлечение большего количества сторон и участников проекта, она также может отдавать предпочтение проектам, которые поддерживаются и финансируются ею. фундамент. . Например, когда общая производительность эквивалентна или даже немного ниже, чем у решений для хранения общедоступных цепочек, сообщество Ethereum также будет склоняться к проектам уровня 2, поддерживаемым Ethereum Foundation, таким как EthStorage, для продолжения развития экосистемы Ethereum.

В целом, функции сегодняшнего блокчейна становятся все более и более сложными, что также приводит к увеличению требований к пространству для хранения. При наличии достаточного количества узлов проверки уровня 1 нет необходимости выполнять резервное копирование исторических данных всеми узлами во всей сети. Только когда количество резервных копий достигает определенного значения, можно гарантировать относительную безопасность. При этом разделение труда в публичной цепочке становится все более детальным. Layer1 отвечает за консенсус и исполнение, Rollup отвечает за расчет и проверку, а для хранения данных используется отдельный блокчейн. Каждая часть может выполнять определенную функцию, не ограничиваясь производительностью других частей. Однако сколько хранить или какая доля узлов для хранения исторических данных может обеспечить баланс между безопасностью и эффективностью, а также как обеспечить безопасную совместимость между различными блокчейнами. Это требует от разработчиков блокчейнов подумать и продолжить. Инвесторам можно обратить внимание на проект DA, ориентированный на основную цепочку, на Ethereum, поскольку на этом этапе у Ethereum уже достаточно сторонников, и ему не нужно полагаться на другие сообщества для расширения своего влияния. Что еще необходимо, так это улучшать и развивать собственное сообщество и привлекать больше проектов в экосистему Ethereum. Однако для публичных сетей, находящихся в догоняющем положении, таких как Solana и Aptos, одна сеть сама по себе не имеет такой полной экологии, поэтому она может быть более склонна объединять усилия с другими сообществами для создания огромной межсетевой экологии. расширить влияние. Поэтому для появляющегося уровня 1 большего внимания заслуживает общий сторонний DA.

Kernel Ventures — это криптовалютный венчурный фонд, управляемый сообществом исследований и разработок, с более чем 70 инвестициями на ранних стадиях, ориентированными на инфраструктуру, промежуточное программное обеспечение, децентрализованные приложения, особенно ZK, Rollup, DEX, модульные блокчейны и вертикальные области для миллиардов пользователей криптовалюты в будущее, например абстракция учетных записей, доступность данных, масштабируемость и т. д. В течение последних семи лет мы стремимся поддерживать рост основных сообществ разработчиков и университетских ассоциаций блокчейнов по всему миру.

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

  1. Селестия: Звездное море модульного блокчейна: https://foresightnews.pro/article/detail/15497

  2. Использование DHT и будущая работа: https://github.com/celestiaorg/celestia-node/issues/11

  3. Ядро Селестии: https://github.com/celestiaorg/celestia-core

  4. Лаборатории Соланы: https://github.com/solana-labs/solana?source=post_page-----cf47a61a9274------------------------ --------

  5. Анонсируем СОЛНЕЧНЫЙ мост: https://medium.com/solana-labs/announcing-the-solar-bridge-c90718a49fa2

  6. справочник-leveldb: https://leveldb-handbook.readthedocs.io/zh/latest/sstable.html

  7. Кушмаул Дж. Деревья Веркле [J]. Деревья Веркле, 2019, 1:1.:https://math.mit.edu/research/highschool/primes/materials/2018/Kuszmaul.pdf

  8. Официальный сайт Arweave: https://www.arweave.org/

  9. Желтая бумага Arweave: https://www.arweave.org/yellow-paper.pdf