MMS

Введение

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

Проблема масштабирования

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

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

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

Как мы можем подтвердить данные сейчас?

Файлы очень похоже проверяются в децентрализованных сетях хранения с помощью Merkle Trees . Деревья Меркла — это метод хеширования, который позволяет нам доказать, что крошечный фрагмент файла принадлежит большему набору фрагментов, составляющих файл целиком. На веб-сайте Ethereum мы видим, что каждая часть, обозначенная буквой, объединяется со следующей частью в наборе и проходит через алгоритм хеширования. Эти последующие хэши рекурсивно хэшируются вместе, пока не останется только один результат хеширования, известный как корень .

Структура дерева Меркла

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

Доказательство Меркла

Решение для масштабирования в Web3

Пытаясь создать решение для масштабирования сетей хранения, лучше всего смотреть на системы хранения и другие домены в пространстве блокчейна, такие как Layer-2 и ZK-Snarks. Мы можем начать с самого очевидного улучшения: ZK-Snarks. На самом деле, Filecoin уже использует ZK-Snarks для проверки файлов в своей сети. Теоретически снарки должны позволить нам доказать сети, что у нас есть файл, не раскрывая никакой информации о самом файле. Кроме того, нам не нужно предоставлять подробности о доказательстве дерева Меркла. Теоретически это доказательство должно быть невероятно маленьким, однако с некоторыми оговорками этот метод доказательства требует очень маленьких размеров листа, что приводит к тому, что генерация доказательств занимает очень много времени.

Нам нужно быстрое решение, не требующее много места в блоках. Другой маршрут будет черпать вдохновение из Layer-2. Согласно Binance, Layer-2 — это структура для построения сетей, в которых транзакции блокчейна происходят вне цепочки, а состояние вторичной сети периодически фиксируется в базовой цепочке блоков. Что, если бы был способ не только создавать, но и проверять доказательства вне сети, а затем подтверждать, что доказательство действительно, а не само доказательство? Теоретически у этого есть два основных преимущества: доказательства могут быть быстро сгенерированы и не будут занимать место в блоке.

Многоуровневый консенсус

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

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

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

Вопросы безопасности

При попытке атаки на сеть контроль над 2/3 сети провайдера хранилища — верный способ обойти безопасность сети. Чтобы бороться с этим, мы можем добавить залог при создании экземпляра нового провайдера, создав экономический барьер для атаки и гарантируя, что цена создания более 2/3 провайдеров сети станет более дорогостоящей, чем потенциальная выгода от выполнения успешной атаки.

Заключение

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

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

Ethereum.org

Binance Academy

Tendermint

Filecoin

Leave a Reply

Your email address will not be published. Required fields are marked *