Proof of Training (PoT): использование мощностей крипто-майнинга для распределенного обучения ИИ

В разгар наметившейся тенденции интеграции искусственного интеллекта (ИИ) с крипто-майнингом мы выделяем три основные проблемы, которые создают разрыв между этими двумя областями. Чтобы восполнить этот пробел, мы представляем протокол Proof-of-Training (PoT), подход, который сочетает в себе сильные стороны как искусственного интеллекта, так и технологии блокчейн. Протокол PoT использует практический механизм консенсуса византийской отказоустойчивости (PBFT) для синхронизации глобальных состояний. Чтобы оценить производительность дизайна протокола, мы представляем реализацию децентрализованной обучающей сети (DTN), которая использует протокол PoT. Наши результаты показывают, что протокол демонстрирует значительный потенциал с точки зрения пропускной способности задач, надежности системы и сетевой безопасности.

Знакомство

В мире, где искусственный интеллект (AI) и криптовалютный майнинг стали двумя столпами нашего кибернетического общества, проблемы интеграции этих двух сил становятся все более очевидными. Но, сегодня есть решение - протокол доказательства обучения (PoT), который объединяет AI и технологию блокчейна.

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

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

Вступление

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

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

Доказательство обучения

Главной целью является создание надежного протокола консенсуса, называемого "доказательством обучения" (Proof of Training, PoT), который заложит основу для использования мощности криптовалютного майнинга для распределенного обучения искусственного интеллекта (AI). Разработка этого протокола имеет решающее значение для эффективного и безопасного использования вычислительных ресурсов в децентрализованной сети с целью продвижения обучения моделей AI. В этом разделе мы сосредоточимся на функциях и возможностях протокола, отвлекаясь от конкретных сетевых дизайнов.

Реализация протокола в архитектуре сети

Давайте подробно изучим протокол "доказательства обучения" (Proof of Training, PoT) в рамках архитектуры одноранговой сети через дизайн и реализацию децентрализованной сети обучения (Decentralized Training Network, DTN). DTN агрегирует модели, предложенные множеством независимых поставщиков услуг, и участники сети самостоятельно координируются, чтобы предоставить клиентам лучшие модели. Эта координация децентрализована и не требует доверенных сторон. Безопасное функционирование системы обеспечивается протоколом PoT, который проверяет, что операции правильно выполняются участниками сети.

Конструкция DTN

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

Для эффективного использования потенциала этой децентрализованной сети для обучения AI реализована двухуровневая архитектура: компонент в блокчейне (SC), который записывает поток значений в сети, и компонент вне блокчейна (exec), состоящий из набора протоколов, работающих в DTN, где выполняются службы. Благодаря безопасной интеграции функциональности в блокчейне с огромным массивом услуг вне блокчейна, предлагаемых DTN, он может проявить устойчивость и обновляемость, которых часто не хватает в традиционных решениях уровня 1. В дизайне L1-L2 протоколы и инфраструктуры в основном работают вне блокчейна в децентрализованной сети, тогда как утилиты токенов, такие как передача и снятие, работают на уровне 2 любого основного блокчейна. Эта конфигурация позволяет системе постоянно обновляться с дополнительными функциями и утилитами, сохраняя активы сети и пользовательский опыт без изменений. Дополнительные подробности изображены на рис. 3.

Сеть

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

Определение Схема DTN - это набор алгоритмов, выполняемых клиентами и участниками сети: (Put, Get, Manage)

• Put(order) → OID: Клиенты выполняют Put, чтобы отправить заказ на обучение под уникальным идентификатором OID (ID заказа). Заказ на обучение включает всю информацию, необходимую для выполнения задачи обучения поставщиками услуг.
• Get(OID) → model: Клиенты выполняют Get, чтобы извлечь обученные модели, которые хранятся с использованием OID, по завершении задачи.

Термины "майнеры", "поставщики услуг" и "валидаторы" в этом разделе можно использовать взаимозаменяемо.

Циклы

Цикл работы клиента

Взглянем на цикл работы клиента.

1. Put: Клиент заказывает услугу обучения модели. Клиенты могут обучать свои модели, оплачивая услуги поставщиков с помощью утилитных токенов DTN. Клиент инициирует Put, отправляя заказ в сеть. Затем поставщики услуг самостоятельно решают, хотят ли они конкурировать за этот заказ, что они могут сделать, отправив заявки вместе с сгенерированными моделями в сеть. У клиентов есть гибкость в определении времени обучения, изменяя переменную 'время' в их заказах. Более длительное время обучения может потенциально привести к более высокой точности получаемых моделей.
2. Get: Клиент извлекает модель из сети. Клиенты могут извлекать любую модель, хранящуюся в DTN, получая ссылки на модели из сети. Клиент инициирует Get, отправляя запрос API на одну из агрегаторских узлов. Этот узел затем извлекает ссылку из своей локальной базы данных. Когда находится лучшая модель, созданная майнерами, клиент получает уведомление (с ссылкой на модель) от сети. Обязанностью майнеров является обеспечение постоянной доступности своих ссылок на модели, чтобы избежать штрафов от сети.

Цикл работы поставщика услуг (майнера)

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

1. Регистрация: Поставщики услуг обязуются предоставить свои вычислительные ресурсы сети. Это делается путем внесения залога, через транзакцию в сети, используя Manage.RegisterResource. Этот залог замораживается на время, предназначенное для предоставления услуги, и возвращается по запросу поставщика услуг, если он решает прекратить участие в сети, используя Manage.UnRegisterResource. Как только поставщик услуг зарегистрирован, он может начать генерацию заявок на модели, которые будут добавлены в глобальный реестр.
2. Получение заказов: Поставщики услуг могут получать заказы на обучение из сети. Как только они зарегистрированы, поставщики услуг указывают, сколько заказов они хотели бы получить, используя функцию Manage.FetchOrders. При выполнении этой функции соответствующее количество заказов на обучение извлекается из глобального реестра, сортируется по средней награде за единицу времени обучения и отправляется поставщику услуг. Эти заказы содержат подробности о задачах обучения модели, включая необходимые данные, используемую модель и требуемое время обучения. Получив заказы, поставщики услуг могут свободно решать, какие заказы они хотят обработать, исходя из своих доступных вычислительных ресурсов и других предпочтений.
3. Конкуренция за награды: Поставщики услуг конкурируют за заказ клиента, выполняя обучение с предоставленными данными для обучения. Они стремятся сгенерировать модель с более высокой точностью обучения. Как только генерируется новая, более точная модель, она транслируется в сеть. Эта новая модель заменяет любые предыдущие модели с более низкой производительностью для этого конкретного заказа. Этот процесс продолжается до истечения указанного времени обучения. Затем начинается процесс валидации для этого заказа.
4. Отправка моделей: Поставщики услуг отвечают за обеспечение доступности ссылок на сгенерированные экземпляры моделей на протяжении всего цикла добычи. Это делается через функцию Get.SendModel. Если поставщик услуг не сможет поддерживать доступность этих ссылок на модели, сеть может аннулировать модель, что приведет к тому, что поставщик услуг не получит награды.

Цикл работы проверяющего (валидатора)

Взглянем на цикл работы валидатора. Валидаторы получают награды, обнаруживая неправильные валидации в фазе валидации заказа.

1. Регистрация: Валидаторы обязуются предоставить свои вычислительные ресурсы сети. Это делается путем внесения залога, через транзакцию в сети, используя Manage.RegisterVerifier. Этот залог замораживается на время, предназначенное для предоставления услуги, и возвращается по запросу валидатора, если валидатор решает прекратить участие в сети, используя Manage.UnRegisterVerifier. Как только валидатор зарегистрирован, он может начать вызывать вопросы о валидации в фазе валидации заказа.
2. Получение валидаций: Валидаторы могут получать валидации для конкретного заказа из сети. Как только они зарегистрированы, валидаторы указывают, для какого заказа они хотели бы получить валидации, предоставляя OID заказа с использованием функции Manage.FetchValidations. При выполнении этой функции соответствующие валидации для этого заказа извлекаются из глобального реестра и отправляются валидатору. Получив валидации, валидаторы могут определить, следует ли вызвать вопросы о каких-либо из этих валидаций, выполнив функцию POT.verify на них.
3. Вызов валидаций: Валидаторы вызывают вопросы о валидациях в фазе валидации заказа, выполняя функцию Manage.Challenge. Если валидация оказывается неверной, валидатор получает награду, связанную с успешным вызовом.

Цикл работы сети

Взглянем на цикл работы сети.

1. Обновление: Глобальный реестр будет повторно обновлять заказы в пуле транзакций и соответствующие структуры данных. Например, он будет проверять, перешел ли заказ из фазы обучения в фазу валидации. Если это так, глобальный реестр обновляет переменную состояния и начинает принимать валидации и вызовы, в то время как майнеры начинают отправлять модели. Это обновление использует Unix-метку времени в качестве ссылки и обновляет системные переменные в соответствии с протоколом PoT.
2. Обновление: Глобальный реестр периодически фиксирует состояния системы в умных контрактах на главной цепочке, обновляя глобальный реестр соответственно. Когда заказы проходят обе фазы - валидации и вызова, они отмечаются как завершенные, и их состояние обновляется в глобальном реестре.

Важно отметить, что на схеме 1 ниже представлена последовательная диаграмма, описывающая логику протокола и поток данных в различных фазах цикла задачи. Она содержит фазу обучения [t0, t0 + ∆Ttrain], фазу валидации [t0 + ∆Ttrain, t3 + ∆Tvalidate], фазу вызова [t3 + ∆Tvalidate, t3 + ∆Tvalidate + ∆TChallenge] и фазу финализации. Временные моменты определены в уравнениях 1, 2 и 3.

В заключение, авторы статьи предлагают провести дальнейшие исследования, включая тестирование протокола PoT с использованием реальных токенов и реализацию полной версии DTN, что позволит провести детальный анализ производительности системы на реальных задачах, способствуя дальнейшему развитию и пониманию протокола PoT.

Исходный код, использованный в этом исследовании для реализации протокола доказательства обучения (PoT) и децентрализованной сети обучения (DTN), доступен для просмотра, использования и модификации по условиям лицензии MIT. Вы можете получить доступ к репозиторию по адресу: https://github.com/P-HOW/proof-of-training.

Заключение

В этой статье мы рассмотрели протокол доказательства обучения (Proof of Training, PoT), который представляет собой новый подход к использованию вычислительных ресурсов в сети для обучения искусственного интеллекта. Этот протокол позволяет обеспечить эффективное и безопасное использование вычислительных ресурсов в децентрализованной сети с целью продвижения обучения моделей AI.

Важным аспектом протокола PoT является его способность динамически адаптироваться к изменениям в потребностях рынка и спросе. В системе децентрализованного AI обучения рабочая нагрузка динамически меняется в ответ на изменения предложения и спроса на рынке. В такой системе основной целью является создание ценных моделей AI, а валидация транзакций является второстепенной функцией. Хорошо построенная система должна учитывать эти аспекты, динамически корректируя рабочую нагрузку системы в соответствии с потоком заданий на обучение, обеспечивая бесшовное обновление системы со временем и гарантируя простоту использования и безопасность активов пользователей.

Перевод статьи для вас подготовили команда Anti-Ghost's