Описание и архитектура

Codex создает надежный механизм хранения данных, который полностью децентрализован и обеспечивает устойчивость к коррупции и цензуре для web3-приложений. Он изначально защищает участников сети, предоставляя хостам правдоподобное отрицание ответственности за хранимые ими данные, а клиентам - доказуемые гарантии долговечности - до 99,99%, оставаясь при этом эффективным с точки зрения хранения и пропускной способности.

Эти четыре ключевые особенности объединяются, чтобы отличить Codex от существующих проектов в нише децентрализованного хранения:

• Кодирование с исправлением ошибок: Обеспечивает эффективную избыточность данных, что повышает гарантии долговечности данных.

• Доказательство извлекаемости на основе ZK: Для легких гарантий долговечности данных.

• Механизм ленивого восстановления: Для эффективного восстановления данных и предотвращения потерь.

• Стимулирование: Для поощрения рационального поведения, широкого участия в сети и эффективного предоставления ограниченных сетевых ресурсов.

Стимулируемая децентрализация

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

Разработка адекватной структуры стимулирования обусловлена следующими целями:

• Спрос и предложение для поощрения оптимального использования сетевых ресурсов.

• Увеличение участия путем предоставления узлам возможности использовать свои конкурентные преимущества для максимизации прибыли.

• Предотвращение спама и сдерживание вредоносного участия.

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

Сетевая архитектура

Codex состоит из нескольких типов узлов, каждый из которых выполняет свою роль в работе сети. Аналогично, требования к оборудованию для каждого типа узла различаются, что позволяет участвовать тем, кто использует устройства с ограниченными ресурсами.

Узлы хранения

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

Узел-агрегатор

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

Клиентские узлы

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

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

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

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

Архитектура рынка

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

Смарт-контракт

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

Основные параметры запроса на хранение:

• количество байтов хранилища, которое запрашивается
• идентификатор контента (CID) данных, которые должны быть сохранены
• срок, на который должны быть сохранены данные
• количество слотов (на основе параметров кодирования с исправлением ошибок)
• количество токенов для оплаты хранения

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

Смарт-контракт также проверяет, что поставщики хранилищ выполняют свои обещания. Поставщики хранилищ размещают залог, когда обещают заполнить слот запроса на хранение. От них ожидается предоставление периодических доказательств хранения в контракт, либо напрямую, либо через агрегатор. Если они неоднократно не делают этого, их залог может быть конфискован. Их слот затем присуждается другому поставщику хранилищ.

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

Покупка

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

Продажи

Модуль продаж является аналогом модуля продаж. Он отслеживает смарт-контракт, чтобы получать уведомления о входящих запросах на хранение. Он ведет список наиболее перспективных запросов, которые он может выполнить. Он будет отдавать предпочтение тем запросам, которые имеют высокое вознаграждение и низкий залог. Как только он найдет подходящий запрос, он попытается сначала зарезервировать, а затем заполнить слот, загрузив связанные данные, создав доказательство хранения и разместив его в смарт-контракте. Затем он продолжит отслеживать смарт-контракт, чтобы предоставлять ему доказательства хранения, когда они потребуются.

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

Белая книга

Прочитайте белую книгу Codex