1. На ранней стадии развития блокчейна поддержание согласованности данных считается чрезвычайно важным для обеспечения безопасности и децентрализации. Однако с развитием экосистемы блокчейна растет и нагрузка на хранилища, что приводит к тенденции централизации работы узлов. Таким образом, проблема стоимости хранения, вызванная ростом TPS на уровне 1, требует срочного решения.
2. Столкнувшись с этой проблемой, разработчики должны предложить решение, которое полностью учитывает безопасность, стоимость хранения, скорость считывания данных и универсальность уровня DA.
3. В процессе решения этой проблемы появилось множество новых технологий и идей, включая Sharding, DAS, Verkle Tree, промежуточные компоненты DA и т.д. Они пытаются оптимизировать схему хранения данных на уровне DA, сокращая избыточность данных и повышая эффективность проверки данных.
4. С точки зрения расположения хранилища данных решения DA делятся на два типа: DA основной сети и DA сторонних производителей. ПДР основной цепи разработаны с точки зрения регулярной очистки данных и хранения нарезанных данных, чтобы снизить нагрузку на узлы, в то время как ПДР сторонних производителей разработаны для удовлетворения потребностей в хранении данных и имеют разумные решения для больших объемов данных. В результате мы нашли компромисс между совместимостью с одной цепью и совместимостью с несколькими цепями в сторонних DA и предложили три вида решений: DA, ориентированные на главную цепь, модульные DA и DA с хранилищем публичных цепей.
5. Публичные цепочки платежного типа предъявляют очень высокие требования к безопасности исторических данных и поэтому подходят для использования в основной цепочке в качестве уровня DA. Однако для публичных цепочек, которые работают уже долгое время и имеют большое количество майнеров, управляющих сетью, более подходящим будет использование стороннего DA, который не требует изменения уровня консенсуса и обладает относительно высокой безопасностью. Для комплексных публичных сетей более целесообразно использовать выделенное хранилище DA главной сети, обладающее большей емкостью данных, меньшей стоимостью и безопасностью. Однако, учитывая спрос на кросс-цепочку, модульный DA также является хорошим вариантом.
6. В целом, блокчейн движется в направлении сокращения избыточности данных, а также многоцепочечного разделения труда.

1. Справочная информация

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

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

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

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

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

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

2.2 Стоимость хранения

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

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

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

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

2.4 Обобщение DA

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

3. Техники, относящиеся к DA

3.1 Шардинг

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

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

3.2 DAS（Data Availability Sampling）

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

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

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

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

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

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

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

4. Способы хранения ПДР

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

4.1.1 DankSharding-like

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

4.1.2 Временное хранение

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

4.2 Сторонние ПДР

4.2.1 ПДР, специфичный для основной цепи: EthStorage

1. Основная цепочка, характерная для DA: Самое важное в уровне DA - это безопасность передачи данных. Самым надежным на данный момент является DA главной цепочки. Однако хранение главной цепи связано с ограничением пространства для хранения и конкуренцией за ресурсы. Поэтому, когда объем сетевых данных быстро растет, сторонние DA будут лучшим выбором, если необходимо обеспечить долгосрочное хранение данных. Если сторонний DA имеет более высокую совместимость с основной сетью, он сможет реализовать совместное использование узлов, а также обеспечит более высокую безопасность в процессе взаимодействия данных. Поэтому, если учитывать безопасность, то DA, ориентированная на основную цепочку, будет иметь огромные преимущества. Если взять в качестве примера Ethereum, то основным требованием к DA, специфичным для главной цепи, является совместимость с EVM и обеспечение взаимодействия с данными и контрактами Ethereum. Среди представленных проектов - Topia, EthStorage и др. Среди них EthStorage на данный момент является наиболее развитым с точки зрения совместимости, поскольку помимо совместимости на уровне EVM, он также специально создал соответствующие интерфейсы для связи с такими инструментами разработки Ethereum, как Remix и Hardhat, чтобы достичь совместимости на уровне инструментов разработки Ethereum.
2. EthStorage: EthStorage - это публичная цепочка, независимая от Ethereum, но узлы, работающие на ней, превосходят узлы Ethereum. То есть, узлы, на которых работает EthStorage, могут одновременно запускать Ethereum. С помощью кодов операций на Ethereum Вы можете получить прямой доступ к EthStorage. 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 mainnet. Если Вам нужно вызвать ранее сохраненные данные, Вам нужно воспользоваться функцией get() в EthStorage и ввести ключевой параметр. Вы можете быстро искать данные на EthStorage с помощью kvldx, хранящихся в Ethereum.

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

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

4.2.2 Модулирование DA: Celestia

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

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

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

4.2.3 Цепь хранения DA

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

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

5. Синтезированное сравнение

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

1. Безопасность: Самым большим источником проблем с безопасностью данных являются потери, вызванные процессом передачи данных, и злонамеренное вмешательство недобросовестных узлов. В процессе кросс-цепочки, из-за независимости и состояния двух публичных цепочек, безопасность передачи данных является одной из самых проблемных областей. Кроме того, уровень 1, который в настоящее время требует специального уровня DA, часто имеет сильную группу консенсуса, и его безопасность будет намного выше, чем у обычных публичных цепочек хранения. Таким образом, решение DA для главной цепи обладает более высокой степенью безопасности. После обеспечения безопасности передачи данных следующим шагом будет обеспечение безопасности вызывающих данных. Если рассматривать только краткосрочные исторические данные, используемые для проверки транзакций, то эти же данные резервируются всей сетью в сети временного хранения. В решении, подобном DankSharding, среднее количество резервных копий данных составляет всего 1/N от количества узлов во всей сети. Большее количество избыточных данных может снизить вероятность их потери, а также обеспечить большее количество эталонных образцов при проверке. Поэтому временное хранилище будет относительно более надежно защищать данные. В решении DA, разработанном третьей стороной, DA, специфичный для главной цепочки, использует публичные узлы главной цепочки, и данные могут напрямую передаваться через эти ретрансляционные узлы в процессе кросс-цепочки, поэтому он будет обладать относительно более высокой безопасностью, чем другие решения DA.
2. Затраты на хранение данных: Самый большой фактор, влияющий на стоимость хранения, - это количество избыточных данных. В решении краткосрочного хранения главной цепи DA, она хранится в виде синхронизации данных всех узлов сети. Любые вновь сохраненные данные необходимо резервировать во всем узле сети, что требует наибольших затрат на хранение. Высокая стоимость хранения, в свою очередь, определяет, что этот метод подходит только для временного хранения в сетях с высоким TPS. Второй - это способ хранения шардинга, включая шардинг в основной цепочке и шардинг в сторонних DA. Поскольку основная цепочка часто имеет больше узлов, соответствующий блок будет иметь и больше резервных копий, поэтому решение шардинга основной цепочки будет иметь более высокую стоимость. Самая низкая стоимость хранения - у публичной цепочки DA, в которой используется метод хранения вознаграждений. При такой схеме количество избыточных данных часто колеблется вокруг фиксированной постоянной. В то же время, в цепочку публичного хранения DA внедрен механизм динамической настройки, чтобы привлечь узлы к хранению меньшего количества резервных данных путем увеличения вознаграждения для обеспечения безопасности данных.
3. Скорость чтения данных: На скорость хранения данных в основном влияет расположение данных в пространстве хранения, путь индекса данных и распределение данных по узлам. Среди них место хранения данных на узле оказывает большее влияние на скорость, поскольку хранение данных в памяти или на SSD может привести к тому, что скорость чтения будет отличаться в десятки раз. Для хранения данных публичной цепочки DA в основном используются SSD-накопители, поскольку нагрузка на эту цепочку включает не только данные уровня DA, но и личные данные с большим объемом памяти, такие как видео и фотографии, загруженные пользователями. Если сеть не использует SSD в качестве места для хранения данных, ей будет сложно выдерживать огромные нагрузки и удовлетворять потребности в долгосрочном хранении. Во-вторых, для сторонних DA и DA основной цепи, которые используют состояние памяти для хранения данных, сторонним DA сначала нужно найти соответствующие индексные данные в основной цепи, а затем передать индексные данные по всей цепи стороннему DA и вернуть их через мост хранения данных. В отличие от этого, главная цепочка DA может напрямую запрашивать данные у узлов и, следовательно, имеет более высокую скорость получения данных. Наконец, в рамках основной цепочки DA метод Sharding требует вызова Block с нескольких узлов и восстановления исходных данных. Поэтому, по сравнению с краткосрочным хранением без фрагментации, скорость будет ниже.
4. Универсальность уровня DA: Универсальность DA основной цепочки близка к нулю, потому что невозможно передать данные с публичной цепочки с недостаточным объемом памяти на другую публичную цепочку с недостаточным объемом памяти. В DA от третьих лиц универсальность решения и его совместимость с конкретной основной цепочкой являются противоречивыми показателями. Например, в решении DA, разработанном специально для определенной главной цепи, было внесено множество улучшений на уровне типа узла и сетевого консенсуса, чтобы адаптировать его к публичной цепи. Поэтому эти улучшения будут играть важную роль при взаимодействии с другими общественными сетями. огромная помеха. В рамках сторонних DA, хранилище публичных цепочек DA показывает лучшие результаты в плане универсальности по сравнению с модульными DA. У публичной сети хранения DA большее сообщество разработчиков и больше возможностей для расширения, что позволяет адаптироваться к условиям различных публичных сетей. В то же время, публичная цепочка DA для хранения данных более активно получает данные через перехват пакетов, а не пассивно принимает информацию, передаваемую другими публичными цепочками. Поэтому он может кодировать данные своим способом, обеспечивать стандартизированное хранение потоков данных, облегчать управление информацией, поступающей из разных основных цепочек, и повышать эффективность хранения.

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

6. Резюме

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

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

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

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

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

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

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

1. Эта статья перепечатана из[зеркало]. Все авторские права принадлежат оригинальному автору[Kernel Ventures Jerry Luo]. Если у Вас есть возражения против этой перепечатки, пожалуйста, свяжитесь с командой Gate Learn, и они незамедлительно рассмотрят их.
2. Предупреждение об ответственности: Мнения и взгляды, выраженные в этой статье, принадлежат исключительно автору и не являются инвестиционным советом.
3. Перевод статьи на другие языки осуществляется командой Gate Learn. Если не указано, копирование, распространение или плагиат переведенных статей запрещены.