Диффузионный хакатон 2019

Родом из Blockpass Identity Lab, расположенной в солнечной Шотландии, наша команда из трех человек поехала в Берлин, чтобы принять участие в Diffusion; хакатон, организованный Outlier Ventures, посвященный применению и объединению технологий распределенного реестра (DLT), криптографии, Интернета вещей и машинного обучения. По прибытии нас встретили 44 другие команды со всего мира, объединившиеся в этом пространстве и времени, все приверженные использованию новаторских технологий для экспериментов и создания инструментов, которые могут принести пользу обществу в следующем поколении Интернета.

Когда мы проходили через дверь Factory в Берлине, ощущалось ощутимое чувство общности. Мы были потрясены как родословной участников, так и их готовностью обсуждать свой опыт и идеи в качестве пионеров Интернета 3.0. Это дало нам широкую возможность использовать опыт различных наставников и других команд для дальнейшего развития как идеи нашего проекта, так и наших будущих исследовательских интересов, как аспирантов. Сказав это, были времена, когда мы беспокоились, что эта атмосфера может стать нашим крахом, поскольку быстрые поездки за кофе превращались в 45-минутные косвенные беседы на практически неизведанной территории, где встречаются конфиденциальность, машинное обучение и DLT.

Наша команда состояла из трех докторов наук; Уилл, Павлос и Адам. Мы специализируемся на децентрализованной идентификации, DLT и машинном обучении с сохранением конфиденциальности соответственно. Мы хотели создать проект, в котором были бы задействованы все наши сильные стороны. По этой причине мы пошли по пути разработки решения, реализующего распределенное обучение с разрешениями, управляемыми агентами с помощью децентрализованных идентификаторов (DID) и проверяемых учетных данных (VC). Хотя наше решение теоретически могло бы приспособить данные и модели из любой области приложения, мы решили построить наш сценарий использования на основе распределенного обучения на данных о состоянии здоровья. В частности, мы решили облегчить частное обучение на наборе данных, который позволил бы диагностировать психическое здоровье в технологиях.

Hyperledger Овен

Мы решили сосредоточиться на Hyperledger Aries, чтобы обеспечить возможности идентификации, необходимые для нашего проекта, в частности, мы построили на коде aries-cloudagent-python. Овен был выделен из кодовой базы Hyperledger Indy в начале 2019 года, чтобы отделить код на основе бухгалтерской книги от того, что часто называют кодом на основе агентов. Hyperledger Aries заявляет о своей цели: Hyperledger Aries предоставляет общий, многоразовый, совместимый набор инструментов, разработанный для инициатив и решений, направленных на создание, передачу и хранение проверяемых цифровых учетных данных. Aries стремится быть независимым от бухгалтерских книг, поэтому, хотя в настоящее время он поддерживает только Hyperledger Indy, он разработан таким образом, чтобы позволить агентам Aries поддерживать несколько подключаемых реестров в будущем.

Одной из наиболее интересных особенностей этой новой волны инноваций в области идентификации является возможность создавать уникальные попарные соединения децентрализованного идентификатора между агентами, также известные как одноранговые DID. Спецификация для этих идентификаторов находится в стадии разработки. Агент может устанавливать соединения с другими, предоставляя другой уникальный одноранговый DID, который они могут криптографически аутентифицировать как контролирующий, это добавляет как конфиденциальность, так и безопасность. После установления соединения протокол Овна DIDComm обеспечивает безопасную зашифрованную связь между агентами. Это можно использовать для отправки сообщений, а также для представления доказательств и получения проверяемых учетных данных. Мы уверены, что одноранговые DID и защищенные каналы связи, которые они обеспечивают, станут фундаментальным строительным блоком для следующего поколения цифровых инноваций.

Распределенное машинное обучение

Федеративное обучение (FL) - это форма машинного обучения, сохраняющая конфиденциальность, популярность которой растет уже некоторое время. Для первой итерации нашего решения мы решили реализовать FL в его самой простой форме, где модели в виде простого текста пересылаются между агентами. Координатор начинает с модели и набора данных для проверки ее точности. Координатор проверяет точность модели и затем отправляет ее на обучение в больницу. Больница обучает модель на своих обучающих данных, а затем отправляет обновленную модель обратно координатору. Координатор сравнивает модель с набором для проверки и затем отправляет ее в следующую больницу. Этот процесс повторяется до тех пор, пока модель не будет обучена на каждом объединенном наборе данных. Мы называем это Vanilla FL.

Поскольку данные не переходят из рук в руки, этот метод является шагом в правильном направлении по сравнению с традиционным централизованным обучением. Однако с этим подходом все еще существуют некоторые проблемы. Vanilla FL уязвима для кражи модели агентами больниц, поскольку они могут просто сохранить копию модели исследователей после ее обучения. В бизнес-случаях, когда модель представляет интеллектуальную собственность, которую должен защищать Координатор, такая установка не идеальна. С другой стороны, зная модель до и после обучения на каждом частном наборе данных, Координатор теоретически может вывести данные, используемые для обучения модели на каждой итерации. Атаки инверсии модели также возможны координатором исследования, где, учитывая бесконечное количество запросов к модели и тщательно продуманные входные функции, исследователь может теоретически реконструировать обучающие значения.

Хотя Vanilla FL уязвима для этих атак, мы решили разработать MVP, в котором эта базовая функциональность может быть расширена для смягчения этих угроз. В частности, для смягчения атак с инверсией модели мы можем реализовать механизмы дифференцированного частного обучения для модели глубокого обучения PyVacy. Чтобы уменьшить угрозы, связанные с кражей модели и выводом обучающих данных, можно использовать безопасные многосторонние вычисления (SMC) для разделения данных и параметров модели на общие ресурсы. Это позволяет вычислять и обновлять как градиенты, так и параметры децентрализованным образом, когда хранение каждого элемента данных делится на доли, которые будут принадлежать соответствующим участвующим организациям.

Наше решение

Мы стремились создать базовый пример федеративного обучения между агентами Hyperledger Aries. Это позволит использовать одноранговый протокол связи DID (DIDComm), реализованный в Hyperledger Aries в качестве транспортного протокола. Использование агентов Hyperledger Aries также позволило нам реализовать простую экосистему учетных данных со следующими агентами;

  • NHS Trust (эмитент больничных удостоверений)
  • Больница (поставщик данных)
  • Исследователь (координатор машинного обучения)
  • Регулятор (эмитент учетных данных исследователя)

Это было использовано для упрощения авторизации участников тренинга и координаторов. Специалист по данным, который хотел бы обучить модель, получает полномочия от отраслевого наблюдателя, который в реальном сценарии может проверять модель и цель исследования. Между тем, больнице, имеющей частные данные о здоровье, может быть выдано разрешение от органа NHS. Схема учетных данных и DID эмитентов учетных данных записываются в публичный реестр - в нашем примере мы использовали реестр разработок, предоставленный правительством Британской Колумбии. При выдаче учетных данных эмитент создает подпись для набора атрибутов для данной схемы, используя закрытый ключ, связанный с их общедоступным DID через документ DID. В эти атрибуты включен скрытый секрет ссылки для объекта, получающего учетные данные - это позволяет привязать учетные данные к конкретному объекту без необходимости знать это секретное значение эмитенту.

При проверке подтверждения учетных данных верификатор должен проверить ряд вещей.

  1. DID эмитента может быть преобразован в публичный реестр в документ DID. Этот документ должен содержать открытый ключ, который можно использовать для проверки целостности учетных данных.
  2. Сущность, представляющая учетные данные, действительно знает секрет ссылки, который был слепо подписан эмитентом. Владелец создает доказательство с нулевым разглашением, подтверждающее это.
  3. Что выдающий DID имел право выдавать такие учетные данные. Сама по себе подпись лишь доказывает целостность, но если верификатор принимает учетные данные больницы от любых эмитентов, то получить поддельные учетные данные будет легко - их может выдать любой, у кого есть общедоступный DID. Для демонстрации мы жестко кодируем общедоступные DID в соответствующие верификаторы. В масштабной производственной системе это можно сделать с помощью реестра, поддерживаемого структурой управления - юридическим документом, определяющим правила экосистемы.
  4. Наконец, верификатор должен проверить, что атрибуты в действительных учетных данных соответствуют критериям авторизации в системе. Для этого простого варианта использования считается приемлемым простое подтверждение правильных учетных данных.
  5. Не включено в этот пример, но, как правило, верификатору необходимо дополнительно проверить, что учетные данные не были отозваны эмитентом. Они будут делать это, сверяясь с реестром аннулирования, хранящимся в публичной книге.

Любой объект с проверяемыми учетными данными от доверенных эмитентов в экосистеме учетных данных может предоставить подтверждение этих учетных данных через попарное одноранговое соединение DID. Используя это, авторизованные стороны могут взаимно аутентифицировать друг друга как доверенные объекты. В предлагаемой экосистеме это позволило агентам создать надежный канал связи. По этому каналу происходила передача параметров модели для федеративного обучения, хранящихся в файле torch.

Чтобы реализовать Vanilla FL, мы разделили наш исходный набор данных на 4 раздела, три обучающих набора и один набор проверки. Эти данные были загружены в трех разных агентов больницы, поскольку они были контейнеризированы из файлов докеров. Каждая больница также загрузила логику очистки данных и обучения для использования с данными и моделями соответственно. С другой стороны, наш обучающий агент докера координатора загружает параметры необученной модели во время процесса контейнеризации. После инициализации контейнера координатор создал URL-адрес подключения, который был передан участвующим больницам. Это создает попарное соединение DID между больницей и координатором - они генерируют и передают уникальные частные одноранговые идентификаторы DID с документами DID, содержащими конечную точку для безопасной связи. Стоит отметить, что, хотя это соединение является безопасным, ему не обязательно доверять. Все стороны знают о другом, что они контролируют идентификатор, который они предоставили. Чтобы построить доверительные отношения в этой связи, сторонам необходимо доказать некоторые аспекты самих себя. Больница доказывает, что является больницей для координатора, доказывая, что у нее есть удостоверение, выданное властью Национальной службы здравоохранения. Точно так же координатор исследований делает то же самое с документами об исследованиях. После того, как это рукопожатие произошло, обе стороны в соединении знают, что они могут доверять друг другу в конкретном случае использования Vanilla FL. Поэтому координатор теперь готов поделиться моделью с больницей, а больница готова обучить модель на своих личных данных и вернуть обученную модель координатору.

Это объединение Овна и FL позволило нам смягчить некоторые существующие ограничения FL, вызванные отсутствием доверия между участниками тренинга. Конкретно это были;

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

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

Запуск демонстрации

Инструкцию по запуску демо можно найти в нашем репо.

Заключение

К концу распространения мы реализовали все 4 типа агентов с разработанной экосистемой учетных данных, у нас также была рабочая модель глубокого обучения, способная учиться на частных данных. У нас не хватило времени, чтобы объединить их так, чтобы передача параметров модели происходила через установленные доверенные DID-соединения. Однако это всегда было проблемой. Текущий DIDComm, реализованный в Aries, поддерживает только базовые * строковые * текстовые сообщения, тогда как мы пытались отправить файл * байтового массива *, содержащий необученную модель.

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

Авторы;

Адам Джеймс Холл, Уилл Абрамсон и Павлос Пападопулос

Первоначально опубликовано на https://github.com/blockpass-identity-lab/aries-fl-demo/blob/master/blog.md