Мы рады объявить об интеграции fitchain с Ocean Protocol. Ознакомьтесь с техническими подробностями о сантехнике для интеграции через Соглашения о предоставлении услуг (SEA). Соавтором этого сообщения в блоге является Франческо Гадалета.

Как это работает

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

Традиционные конвейеры машинного обучения также полагаются на тестирование и проверку моделей после обучения. Такой этап проверки обычно выполняется специалистами по данным, которые обещают быть этичными при тестировании своих моделей с так называемыми вневыборочными данными (OOS); то есть данные, которые отличаются от набора наблюдений, используемых для обучения. Фактически, тестирование модели на одном и том же наборе обучающих данных повысит ее точность, сделав весь процесс не только бесполезным (поскольку модели не будут обобщены на невидимые наблюдения), но и технически мошенническим.

В сети fitchain дополнительные участники следят за тем, чтобы это «нежелательное» поведение (или неопытность) специалистов по обработке данных было обнаружено и в конечном итоге остановлено, тем самым препятствуя торгуемости обученной модели на рынке. Примеры таких субъектов: Сплетники и Проверяющие.

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

В последнем столбце Таблицы 1 указывается, делает ли игрок ставку в системе перед тем, как продолжить. Некоторым актерам необходимо сделать ставку один раз на доступный слот. Один слот показывает, какую вычислительную мощность субъект может предоставить для конкретной задачи. Например, CP с мощным графическим процессором может обучать несколько моделей одновременно; аналогично верификатор может проверять несколько моделей; а Gossiper может транслировать и реплицировать журналы для нескольких моделей при наличии достаточной пропускной способности сети и хранилища.
Вообще говоря,

  • Сплетники делают ставку, чтобы участвовать в выборах (круговой график выборов, все еще подверженный атакам 51%), чтобы сплетничать в специальном канале, который создается каждый раз, когда появляется новая модель. обучены.
  • Верификаторы вносят свой вклад в безопасную схему фиксации-раскрытия, чтобы избежать атаки с опережением, и поэтому должны делать ставки до того, как их выберут в верификационную игру.
  • Поставщик вычислений (CP) должен делать ставку для генерации транзакций во время обучения модели. Эта ставка помогает предотвратить неопределенное создание поддельных транзакций, которые могут привести к DoS-атакам. Каждый CP отвечает за размещение ставок в зависимости от количества доступных слотов.
  • Поставщик данных (DP) делает ставку до завершения обучения модели.
  • Потребители на самом деле не делают ставки, но они блокируют платежи, которые будут разблокированы после того, как все условия будут проверены сетью.

Игра сплетников

Когда новая модель запускает вычислительную задачу, создается новый канал слухов с помощью контрактов Fitchain Ethereum. В такой сети несколько сплетников будут транслировать журналы транзакций, созданные CP, которые адресованы MP через канал состояния. Без такой сети было бы трудно оспаривать журнал транзакций, поскольку активно участвовали бы только два участника, а именно CP и MP. Более того, если один из двух участников отключится или будет вести себя некорректно (например, намеренно скрывая транзакции), будет невозможно восстановить такие транзакции без повторного запуска процесса обучения. В некоторых случаях это было бы недопустимо (например, обучение модели на очень больших наборах данных), а повторное создание экземпляра может быть очень дорогостоящим и трудоемким.

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

Окончание обучения отмечается специальной транзакцией под названием End-of-Training (EoT). Сплетник, получивший транзакцию EoT и сохранивший все транзакции с самого начала обучения, может предоставить сети доказательство. Доказательства представлены определенным количеством сплетников в смарт-контракт, который установит model.isTrained = true, как только будет достигнут консенсус. Мы называем такое доказательство доказательством обучения (PoT).

Игра верификаторов

Цель PoT - только доказать, что модель была обучена, при условии, что CP не подделывал такие транзакции без фактического обучения какой-либо модели. Как уже упоминалось, обученные модели по-прежнему требуют процесса проверки с использованием тестовых данных с использованием данных, которые не использовались CP во время обучения. Чрезвычайно сложно предотвратить введение CP некачественными или поддельными данными во время процесса обучения из-за того, что обучение происходит конфиденциально и изолированно. Эта задача имеет точно такую ​​же сложность, как и в традиционном случае найма специалиста по данным, который подделывает результаты, с той лишь разницей, что такого специалиста по данным будет уволить или привлечь к ответственности, если такое поведение будет обнаружено.

Для борьбы с этим типом мошенничества fitchain усложняет жизнь вредоносным CP:

  1. Запрос копии дерева Меркла данных, заявленных в качестве обучающего набора данных, при публикации данных;
  2. Запрос корня Меркла для каждого пакета данных, используемого во время обучения модели
    (CP автоматически отправит такую ​​информацию, просто используя подлинный fitchain-pod);
  3. Реализация механизма раскрытия данных для проверки обучающих данных в любое время после обучения модели.

Верификаторы - это участники, которые выполняют игру по проверке модели, тестируя модели с внешними наборами данных для конкретной предметной области, которые, возможно, курируют эксперты в предметной области (например, кураторы данных Ocean).

Задача v erifiers - получить обученные модели и тщательно отобранные тестовые наборы данных, а затем выполнить вычисления вне сети для оценки точности / ошибки таких моделей. Очевидно, что для выполнения проверки верификаторы используют такие ресурсы, как CPU / GPU и пропускную способность сети. По этой причине они получают вознаграждение от сети при условии достижения консенсуса.

Только после завершения проверочной игры модель будет помечена как проверенная (model.isVerified = true) и готова к отправке потребителю.

Соглашение об исполнении услуг fitchain

Как упоминалось в предыдущих сообщениях блога Знакомство с соглашениями об обслуживании Ocean и Соглашением об оказании услуг (SEA) Ocean, соглашение о предоставлении услуг предназначено для определения ожиданий и обязательств каждого участника с целью уменьшения конфликтов в будущем. Это определение определяет механизмы коммуникации, разрешения споров и общие стратегии или действия, которым обязан следовать каждый рациональный субъект.

Fitchain SEA Шаблон

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

Контракт условий вычислений отвечает за выполнение одного условия, как и контракт управления доступом (выполняется через секретное хранилище). С другой стороны, договор об условиях fitchain отвечает за выполнение трех условий. Все эти контракты предопределены и развернуты в сети Ocean.

Этот образец шаблона не включает разрешение споров (на уровне проверки) и безопасные условия вычислений; однако обратите внимание, что модульная конструкция Ocean SEA может поддерживать будущие обновления.

Жизненный цикл СЭО состоит из трех фаз:

Этап определения СЭО

Ocean SEA предоставляют базовые примитивы для определения условий, а также модели зависимости шаблона SEA. Эти примитивы включают связь между условием и его выполнением, а также определение модели зависимости. Ссылка интерпретируется как условие ключ (или идентификатор), которое определяется следующим образом:

  • Hash(smartContractAddress, functionSignature(selector), dependencyConditionsKeys(ifExist)).

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

На рисунке 2 показано, как строится модель зависимостей для произвольного шаблона Ocean SEA:

Модель зависимостей встроена или закодирована в шаблоне в терминах dependency bits array. Каждое условие в этом массиве представлено 2-bits. 1-й бит относится к dependency condition index, а 2-й бит относится к timeout flag. Например, если у нас есть 5 условий, нам нужно 2 x 5 битов для представления зависимости условий в массиве из пяти элементов. Таким образом, с помощью побитовых операций контракты Ocean SEA могут легко проверить представление зависимости и решить, соответствует ли текущая функция выполнения текущему условию или нет.

У этого подхода есть два преимущества:

  • Он сохраняет память в цепочке, сжимая флаги зависимости до пары битов; а также,
  • Это позволяет Ocean SEA объединить больше функций в модель зависимостей для следующих выпусков.

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

Этап выполнения SEA

На этом этапе участники подписывают соглашение и размещают его в сети. Затем контракт Ocean SEA проверяет подписи и уведомляет участников о начале игры. Во время настройки поставщика услуг попросят предоставить входные значения и значения тайм-аута (также подписанные значения), которые требуются для выполнения условий, включая DID активов / услуг, цену, адрес потребителя, поставщиков, адреса издателей и т. Д. В этот момент условия шаблона создаются путем генерации new condition Instances = Hash(conditionKey, inputsValueHash), где хэш входного значения представляет все связанные входные данные для условия в функции выполнения. Следовательно, если злоумышленник пытается обмануть, передав недопустимый ввод в функцию выполнения, функция восстановит неверный идентификатор экземпляра условия, и смарт-контракт Ocean SEA вернет вызов с сообщением об ошибке.

А где хранятся входные значения? Просто они определены в документе DID услуги / актива. Этот DID-документ описывает представление шаблона SEA вне сети, условия и связанные с ними входные значения. Документ DID предоставляет подробное описание обслуживания активов данных поставщиками данных в Ocean.

Этап прекращения действия SEA

Шаблон SEA Ocean должен быть разработан таким образом, чтобы завершаться. Это означает, что у нас есть два типа расторжения: выполненные и невыполненные договоренности. Некоторые ключевые особенности:

  • Как рациональный поставщик услуг, вы будете заинтересованы в получении более высокого ранга, выполняя SEA в максимально возможной степени. Более того, вы имеете право писать свои собственные условия (т.е. конкретную личность).
  • Как рациональному потребителю важно выполнять свою работу как можно скорее. Кроме того, потребляя услуги, вы заключаете соглашения об оказании услуг. Это означает, что качество обслуживания повысится.

Применение fitchain SEA в океане

На рисунке 3 показано, как специалисты по данным используют сервис fitchain через Ocean, подписывая соглашение об обслуживании.

Со стороны океана у нас, по сути, есть три участника:

  • Data-Scientist - выступает в роли поставщика и потребителя модели;
  • поставщик услуг fitchain - действует как поставщик данных и поставщик вычислений;
  • Свидетели океана - избранные актеры, которые отвечают за свидетельство доказательств по ссылке в fitchain.

Актеры обязаны выполнить следующие шаги (т. Е. счастливый путь):

  • Специалист по данным выбирает данные и вычислительные ресурсы, а также шаблон SEA через торговую площадку fitchain (зарегистрированная торговая площадка Ocean).
  • Специалист по данным подписывает шаблон SEA со значениями, а затем отправляет подписанное сообщение поставщику услуг fitchain (SP).
  • fitchain SP принимает запрос, создавая новый экземпляр Ocean SEA в цепочке.
  • Актеры будут уведомлены о конкретных условиях, прослушивая события из Контракта Ocean SEA.
  • Специалист по данным блокирует платеж в контракте на вознаграждение, чтобы начать игру, а затем отправляет алгоритм в конечную точку службы SP.
  • На этом этапе обе стороны (специалист по данным и ИП) обязаны сотрудничать, чтобы выполнить проверку целостности данных представленного алгоритма. Таким образом, специалист по данным вычислит хэш представленного алгоритма, подпишет его и отправит подписанный хеш (только подпись) в контракт условий вычислений. Если поставщик услуг получил тот же алгоритм, он сможет выполнить условие, отправив хэш представленного алгоритма.
  • Теперь работа делегируется поставщику услуг fitchain, который, в свою очередь, будет обучать модель в сети fitchain, где будут выбраны сплетники для отправки PoT. Точно так же проверяющие представляют доказательство проверки. Наконец, SP фиксирует PoT и ссылочные идентификаторы подтверждения на стороне Ocean.
  • Свидетели Ocean используют идентификатор модели (service agreement Id on the Ocean side) и подтвержденные идентификаторы подтверждения для проверки PoT, а также проверочное доказательство на стороне fitchain. Затем они голосуют на стороне океана.
  • Если оба условия model.isTrained и model.isVerified равны true, ИП предоставит специалистам по обработке данных доступ к результатам через секретное хранилище океана.
  • Наконец, функция вознаграждения запускается SP, где он оценивает статус условий и отменяет платеж, если все условия выполнены.

Интеграция fitchain SEA

Как показано в таблице 2, Ocean SEA по замыслу основана на управляемой событиями архитектуре, где каждое новое условие должно быть связано с автономным (программным модулем) обработчиком. Обработчик в основном подписывается на событие (я) состояния в цепочке и выполняет соответствующие действия в цепочке или вне цепочки. Эти модули подключаются к компоненту сетевого интерфейса Ocean (Squid Python, JS, Java), что, в свою очередь, облегчает взаимодействие с хранителями контрактов. Ключевые особенности таких модулей заключаются в том, что они модульные, инкапсулированные и слабо связанные.

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

  • Реализация одного контракта (контракт условий фитчейна), который выполняет как PoT, так и подтверждение проверки по ссылке, которое происходит со стороны протокола Ocean.
  • То же самое относится к модулям вне сети, которые обрабатывают события условий и обеспечивают целостность доказательств со стороны fitchain.

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

Спасибо Дону Госсену, Димитри де Йонге, Айтору Аргоманису , Самеру Салламу , Фанг Гонг, Джон Эневольдсен, Квинтен Крауэлс, Себастьян Герске

Полезные ссылки

Мы надеемся, что вы готовы погрузиться в дело - загляните в Dev-Ocean, чтобы получить представление о том, над чем мы работаем, и задавайте все свои технические вопросы в нашем чате Gitter.

Следите за Ocean Protocol в Twitter, Telegram, LinkedIn, Reddit, GitHub и Newsletter, чтобы получать обновления и анонсы проектов.