Джерри Луо, Kernel Ventures

TL;DR

1. В первые дни публичные сети требовали узлов по всей сети для поддержания согласованности данных для обеспечения безопасности и децентрализации. Однако с развитием экосистемы блокчейна нагрузка на хранилища продолжает увеличиваться, что приводит к тенденции централизации операций узлов. На данном этапе Layer 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

2. Показатели производительности DA

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

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

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

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

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

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

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

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

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

2.4 Общность слоя DA

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

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

3.1 Шардинг

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

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

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

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

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

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

3.3 Режим верификации данных слоя DA

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

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

3.4 Универсальное промежуточное ПО DA

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

4. Схема хранения данных на уровне DA

4.1 Mainchain DA

4.1.1 класс DankSharding

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

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

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

4.2 Сторонние DA

4.2.1 Выделенный DA в основной цепи: EthStorage

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

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

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

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

4.2.2 Модульный DA: Celestia

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

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

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

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

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

4.2.3 Публичная цепочка магазинов DA

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

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

5. Всестороннее сравнение

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

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

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

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

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

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

6. сводка

Блокчейны на данном этапе переживают переход от криптовалюты к более инклюзивному Web3, принося больше, чем просто богатство проектов на блокчейне. Для того, чтобы вместить такое количество проектов, работающих одновременно на уровне 1, обеспечивая при этом опыт проектов Gamefi и Socialfi, уровень 1, представленный Ethereum, внедрил такие методы, как роллапы и большие двоичные объекты для улучшения TPS. Среди зарождающихся блокчейнов растет и количество высокопроизводительных блокчейнов. Но более высокий TPS означает не только более высокую производительность, но и большую нагрузку на сеть. Для массивных исторических данных на данном этапе предлагаются различные методы DA, основанные на основной цепочке и третьих сторонах, чтобы адаптироваться к росту давления на ончейн-хранилище. У каждого метода улучшения есть свои плюсы и минусы, и он по-разному применим в разных контекстах.

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

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

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

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

Источник: Голден Финанс