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

В интервью 8btc Кевин Леффью, глобальный BD-менеджер Storj, поделился своими взглядами на возможности децентрализованного решения облачного хранения.

8btc: Мы знаем, что по сравнению с репликацией у кодирования стирания все еще есть проблемы, такие как проблема загрузки на большие расстояния и т. Д. Почему Storj по-прежнему использует кодирование стирания? Будет ли он использоваться долго?

Storj: Во-первых, системы, использующие репликацию, сталкиваются с такими же проблемами при загрузке на большие расстояния, что и системы, использующие кодирование со стиранием, однако на самом деле это не проблема для кодирования со стиранием. Если вы загружаете файл с кодировкой стирания 10/30, вы можете восстановить его из любых 10 из 30 его фрагментов. Это означает, что сеть должна запросить только 13-30 штук, а дополнительные 3 компенсируют задержку передачи. Как только самые быстрые 10 частей доставлены, оставшиеся загрузки отменяются, и файл может быть восстановлен. При использовании системы репликации сети потребуется попытаться загрузить дополнительную копию (как минимум) каждого фрагмента файла, в противном случае загрузка всего файла будет отложена, если во время загрузки был задержан хотя бы один фрагмент файла.

Использование кодов стирания значительно снижает коэффициент расширения данных, хранящихся в сети, при этом обеспечивая максимальную надежность. С нашей схемой кода стирания мы можем добиться 11 9-летнего срока службы с коэффициентом расширения менее 3, то есть на каждый ГБ хранимых данных наша сеть использует менее 3 ГБ емкости хранения в сети. Между тем, для достижения такой же надежности в сети, использующей только репликацию, потребуется коэффициент расширения, равный 16 (при этом операторы узлов хранения в этой сети также получат в 5 раз меньше). Например, предположим, что сообщество операторов узлов хранения зарабатывает 5 долларов США на ТБ данных, загруженных в сеть. В сети с кодированием стирания с 3-кратным коэффициентом расширения это можно разделить на 3 части на $ 1,66 за ГБ хранимых статических данных. С сетью, использующей репликацию, это будет разделено на 16 способов на $ 31 за человека. Как вы думаете, что происходит, когда запуск узла хранения перестает быть экономичным? Операторы узла хранения покидают сеть, что увеличивает стоимость ремонта и рискует потерять данные.

Коды стирания не связывают долговечность с коэффициентом расширения. Вы можете настроить свою долговечность, не увеличивая общий сетевой трафик и количество статических данных, хранящихся в сети! Коды стирания широко используются как в распределенных, так и в одноранговых системах хранения. Хотя они являются более сложными и имеют свои собственные компромиссы, принятая нами схема Reed-Solomon существует с 1960 года и используется повсеместно, начиная с компакт-дисков, связи в дальнем космосе, штрих-кодов, расширенных RAID-подобных приложений — вы называете это ,

Многие продукты в этом пространстве (Filecoin, MaidSafe, Siacoin, GFS, Ceph, IPFS и т. Д.) По умолчанию используют репликацию, что означает простое хранение нескольких копий данных на разных узлах. Наша предыдущая сеть также сделала это! Когда вы смотрите на математический как мы делали во время эксплуатации крупнейшей децентрализованной облачной сети хранения данных в мире, это просто не имеет смысла.

8btc: Storj Labs стремится сделать Storj более децентрализованным и выпустила специальные технические решения. Не могли бы вы дать мне более подробную информацию об этих решениях?

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

Мы подробно рассмотрим каждый из этих компонентов в нашем официальном документе V3.

8btc: В техническом документе Storj Labs заявила, что будет использовать набор доверенных спутников для выбора пользователей и узлов хранения. Есть ли у Storj подробный план управления спутником для предотвращения злоупотреблений или других несчастных случаев?

Storj. В то время как Storj является открытым исходным кодом, и любой может использовать спутник, Storj будет использовать определенную группу спутников, называемую Tardigrade Network, которые имеют соглашение об гарантированном уровне обслуживания (SLA) в отношении доступности и долговечности данных (эквивалентно AWS). ) для клиентов. Мы ожидаем, что партнеры и другие будут использовать свои собственные узлы хранения, поскольку сеть децентрализована, имеет открытый исходный код и бесплатна для всех, кто хочет использовать спутник. Однако, как и во всех технологиях с открытым исходным кодом, пользователи будут осторожны при запуске (и подключении) случайных спутников, которые не гарантируют конкретное время безотказной работы.

8btc: Storj прекращает субсидировать узлы хранения с выпуском V3. Будет ли команда терпеть убытки от этого движения в краткосрочной перспективе?

Storj: Как мы упоминали в вопросе 1, уменьшение коэффициента расширения, обнаруженное при переходе к модели с кодированием стирания (по модели с кодированием стирания + репликация), значительно увеличит выплаты для узлов хранения V3 по сравнению с узлами хранения, работающими в сети V2. Кроме того, у нас есть список ожидания почти из 10 000 участников, которые заинтересованы в присоединении к сети, чтобы заработать токены STORJ в обмен на совместное использование емкости и пропускной способности жесткого диска. Поскольку мы привлекаем клиентов к новой сети V3 и увеличиваем выплаты, мы уверены, что сеть будет расти так быстро, как нам нужно.

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

8btc: Как Storj мотивирует узлы хранения вносить постоянный вклад в сеть или предотвращать их от зла?

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

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

Некоторые распределенные системы хранения (например, системы хранения облачных объектов на основе центра обработки данных) работают в среде, где все узлы считаются альтруистическими.

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

8btc: В настоящее время storj по-прежнему использует ERC20 в качестве стимула, рассмотрит ли он в качестве стимула использование своего собственного нативного токена в будущем? Если нет, то почему?

Storj: Storj использует стандарт ERC20 по ряду причин. Во-первых, с моделью ERC20 модель безопасности токена связана с моделью безопасности блокчейна Ethereum, что делает очень трудным выполнение атаки на 51%, в отличие от других решений с пользовательскими блокчейнами. Кроме того, стандарт ERC20 широко применяется провайдерами кошельков, биржами, новаторами DeFI и другими, что облегчает третьим сторонам внедрение Storj и интеграцию его в свои платформы.

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

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

8btc: В официальном документе Storj V3 упоминается совместимость с AmazonS3. Каковы соображения, каковы преимущества для всей сети, и рискует ли она централизацией?

Storj: Совместимость с Amazon S3 просто означает совместимость с открытым стандартом API S3. Это не означает, что мы используем центры обработки данных Amazon или другую инфраструктуру. Разработчики исторически выбирают путь наименьшего сопротивления. Мы хотим максимально упростить для разработчиков, разработчиков DevOps и других пользователей Amazon S3 переход на децентрализованный бэкэнд, чтобы они могли воспользоваться преимуществами безопасности, производительности и экономических выгод, предлагаемых Storj и сетью Tardigrade. ,

Мы в значительной степени являемся конкурентом Amazon S3, и, прокладывая легкий путь к миграции через наш шлюз S3 и конкурируя с ними по основным принципам (цена, производительность, безопасность), мы надеемся упростить и убедить проекты перейти на наш Платформа.

DS

Storj: 5G позволит большему количеству типов устройств стать узлами хранения. Если устройство «всегда включено», имеет избыточную емкость хранилища и подключено к узлу хранения 5G — оно может стать достойным узлом хранения.