Разбираем SEA: соглашения о предоставлении услуг
Этот пост посвящен технической архитектуре Ocean Protocol, а именно углубленному анализу особенностей соглашений о предоставлении услуг или соглашений SEA (Service Execution Agreements). Соглашения о предоставлении услуг объединяют поставщиков услуг, потребителей и верификаторов сети Ocean Protocol.
В наших предыдущих постах [1, 2] мы упоминали, почему стало ясно, что cоглашения об уровне обслуживания или соглашения SLA (Service Level Agreements) в значительной степени фиксируют отношения в мире в том виде, в котором мы привыкли их видеть. Целые цепочки поставок физических и цифровых услуг связаны договорными обязательствами с целью снижения риска взаимодействия контрагентов, обеспечения доступности, надежности и бесперебойного функционирования.
Для Ocean Network важно обеспечивать добросовестный обмен данными и услугами искусственного интеллекта и защиту всех участников бизнес-транзакций. Таким образом условия соглашения об обслуживании известны заранее, а значит, не нужно полагаться на сторонних посредников в случае возникновения споров. Соглашения об обслуживании и их жизненный цикл формируют основу:
В наших предыдущих постах [1, 2] мы упоминали, почему стало ясно, что cоглашения об уровне обслуживания или соглашения SLA (Service Level Agreements) в значительной степени фиксируют отношения в мире в том виде, в котором мы привыкли их видеть. Целые цепочки поставок физических и цифровых услуг связаны договорными обязательствами с целью снижения риска взаимодействия контрагентов, обеспечения доступности, надежности и бесперебойного функционирования.
Для Ocean Network важно обеспечивать добросовестный обмен данными и услугами искусственного интеллекта и защиту всех участников бизнес-транзакций. Таким образом условия соглашения об обслуживании известны заранее, а значит, не нужно полагаться на сторонних посредников в случае возникновения споров. Соглашения об обслуживании и их жизненный цикл формируют основу:
- децентрализованного контроля доступа;
- разрешения споров;
- истории потребления услуг;
- компенсации и мотивации участников сети.
Далее мы более подробно рассмотрим концепции соглашений о предоставлении услуг, реализованных в Ocean Network, с технической точки зрения.
Неудачные сценарии при предоставлении услуг
Многое может пойти не так, когда дело касается услуг передачи данных. Мы представим несколько примеров ниже, однако в предельных случаях может возникнуть гораздо больше вариантов:
- Услуга может не существовать, хотя потребитель за нее заплатил.
- Услуга может быть предоставлена должным образом, однако потребитель отказывается или забывает выплатить вознаграждению поставщику услуги.
- Поставщики услуги могут не предоставить доступ авторизованным пользователям или предоставить доступ неавторизованным пользователям.
- Услуга не соответствует функциональным требованиям потребителя или ожидаемой потребителем производительности.
- Ответ на запрос услуги или регистрационные записи об услуге «потерялись» в сети или при переводе.
Существует множество способов, как преодолеть такие катастрофические сценарии. Обычный отдел закупок заключает юридические соглашения между поставщиком и потребителем. В случае с цифровыми услугами добавляются компоненты математической безопасности (такие как шифрование, подписи, хеши, криптографические доказательства и аттестации) и автоматизации.
Распределенные сервисные сети обеспечивают компонент избыточности за счет репликации. По мере снижения уровня доверия, например, в случае с (анонимными) инклюзивными сетями можно изучить экономические и репутационные стимулы, которые используют лежащий в их основе базовый токен.
Чем важнее услуга в цепочке поставок, тем более строгие уровни гарантий должны быть обеспечены. Можно представить, что система раннего оповещения о стихийных бедствиях требует более высокого уровня допуска, чем датчик влажности в моем огороде базилика (предположительно, конечно).
Условия есть везде
Подобно тому, как юридические соглашения об уровне обслуживания в сфере закупок содержат положения и условия, у соглашений о предоставлении услуг Ocean тоже есть условия, которые могут быть встроены в виде кода в смарт-контракт. Эти условия должны выполняться сторонами, участвующими в соглашении.
В качестве примера мы приводим сценарий, когда поставщик предоставляет верифицированную услуги передачи данных потребителю. Такая услуга передачи данных может варьироваться от простого извлечения данных до сложных вычислений в среде машинного обучения или искусственного интеллекта.
В приведенном выше сценарии поставщик готов предоставить услугу передачи данных после того, как потребитель подтвердит, что услуга будет оплачена по факту ее оказания. Потребитель в свою очередь готов заплатить только в случае предоставления доступа к услуге и подтверждения выполнения услуги верификатором. Верификатор (или сеть верификаторов) также должен увидеть платеж, прежде чем приступить к какой-либо работе по верификации.
Описанный выше сценарий может быть более сложным или более простым в зависимости от конкретного случая. Далее мы еще более подробно проанализируем, как составлены соглашения о предоставлении услуг.
Структура модульного соглашения о предоставлении услуг
В Ocean Protocol соглашение о предоставлении услуг имеет модульную структуру, которая обеспечивает гибкость при подготовке и потреблении различных web2.0 (облачных/локальных) и web3.0 услуг.
Мы выделяем три основные части в соглашении о предоставлении услуг.
Идентификатор услуги
Идентификатор услуги — это криптографический идентификатор, который уникальным образом идентифицирует предоставляемую услугу. Фактические метаданные и сведения о конечных точках услуги / доступе к услуге хранятся вне блокчейне по причинам масштабируемости и конфиденциальности. Такие сведения могут передаваться в одноранговой сети или вычисляться в эксклюзивной или инклюзивной сети метаданных.
Так как мы стремимся к стандартизации и функциональной совместимости, мы решили внедрить новый стандарт децентрализованной идентичности W3C (стандарт DID). Агенты, услуги и домены обозначаются в Ocean Protocol с помощью DID (например, «did:op:12345s3rv1c3»). Соответствующие им документы DID, которые содержат метаданные и информацию о потреблении услуг, находятся в открытых / эксклюзивных / закрытых хранилищах данных. Мы работаем в направлении создания идентификаторов Ocean с проверками целостности, возможностью обновления версий и недопустимостью отказа. Дополнительная информация о процессе реализации этой работы представлена по ссылке OEP7.
Условия и их выполнение
В несовершенном мире мы сталкиваемся с услугами и событиями, которые имеют место вне блокчейна, в блокчейне, в сайдчейнах и в других блокчейновых форматах. Эти услуги могут выполняться корректно, почти корректно или даже не выполняться. Рано или поздно нужно будет, чтобы информация о статусе этих услуг поступила в соглашения о предоставлении услуг Ocean с целью урегулирования или разрешения споров.
Следовательно, мы вводим понятия условий и их выполнения. Вкратце речь идет о криптографических и некриптографических условиях, которые могут быть выполнены. Каждое условие имеет функцию валидации, которая на выходе дает ответ «Истина», «Ложь» или «Неизвестно». Значения, подпадающие под категорию «Неизвестно», подразумевают, что условие не было доказуемо выполнено. Все условия сначала обозначаются как «Неизвестно». Затем в блокчейне выполняется логика валидации. При этом условия могут рассматриваться как входные данные соглашения о предоставлении услуг.
Условия позволяют нам свободно закодировать доказательство оказания услуги в соглашение о предоставлении услуг. Условия — это задачи, подлежащие решению, а выполнение условий — это и есть найденные решения. Логика вознаграждения распределяет исходные данные в зависимости от выполненных условий. Такие условия могут варьироваться от простых криптографических задач (таких как предоставление предварительного изображения, которое вычисляет хеш с конечными нулями, или предоставление доказательства, что у вас есть закрытый ключ, соответствующий открытому ключу) до более сложных (таких как протоколы SN/TARKs (краткого интерактивного аргумента знаний и прозрачного аргумента знаний), вычисление аттестатаций, доказательство пространства-времени, доказательство извлекаемости) и более субъективных (таких как подписи в транзакциях m-из-n в сценариях голосования или курирования, доля владения / сокращение доли владения и другие).
Когда события валидации происходят за пределами сетей Ocean, то, чтобы разрешить спор, условия могут просто связываться с оракулами или связующими контрактами.
Фактическая реализация условий и их выполнения является вариантом проекта Интернет-документа по крипто-условиям технической комиссии Интернета (Internet Engineering Task Force), инициированного протоколом Interledger. Каждые условие / выполнение условия представляют собой криптографическую пару задача/подтверждение, в частности:
- Хеш / предварительное изображение. Найти предварительное изображение, из которого вычисляется данный хеш. Вычисление хеша предварительного изображения осуществляется в блокчейне. Такое условие используется, чтобы доказать, что участник владеет секретной информацией.
- Открытый ключ + сообщение/подпись. Подписать данное сообщение закрытым ключом, соответствующим данному открытому ключу. Верификация подписи осуществляется в блокчейне. Такое условие используется, чтобы установить личность в схеме асимметричной пары ключей.
- Порог m-из-n. Результат валидации — «Истина», если m из n условий выполнены корректно. Такое условие используется, чтобы разрешать споры между несколькими участниками, такие как голосование.
- Запрос/решение. Создать ссылку на общедоступное значение состояния (которое записывается с отметкой времени) и вычислить/сравнить это значение при валидации. Запрос выполняется в блокчейне, поэтому он ограничен операциями метода GET в рамках контекста состояния блокчейна (например, contractAddress.getValue). Такое условие используется, чтобы связывать услуги и получать информацию о значениях вне блокчейна.
Условия могут объединяться в более сложную логику и выражать:
- Условия оплаты. Количество токенов, внесенных в контракт, равно предварительно определенной цене токена.
- Контроль доступа. Секретная информация, предназначенная для контроля доступа, передана потребителю [более подробная информация по теме представлена здесь].
- Верифицированные вычисления. Сеть верификаторов приходит к соглашению и подтверждает, выполнена ли услуга корректно или нет [в ближайшее время планируется публикация нового поста по теме].
Мы ожидаем, что в экосистеме может возникнуть множество условий, поэтому, чтобы дать «зеленый свет» тем условиям, которые можно безопасно подключить к соглашению о предоставлении услуг, требуются тщательные проверки и курирование. В будущем мы сможем использовать контракты управления, такие как управляемые токенами реестры, механизм участия или децентрализованные автономные организации.
Логика вознаграждения
Выходные данные соглашения о предоставлении услуг — это вознаграждения, которые, как правило, распределяются между агентами, выполнившими одно или несколько условий. В рамках функции сетевого вознаграждения вознаграждения могут быть представлены в форме платежей, роялти, разрешений, беджей, репутационных или лотерейных билетов и так далее. Поскольку могут быть предусмотрены многочисленные механизмы вознаграждения, они объединяются в управляемые шаблоны, аналогичные библиотеке условий.
Базовая структура вознаграждений, реализованная в Ocean Protocol, — это эскроу или холд-токен (заблокированный токен). В ней токены заблокированы в соглашении о предоставлении услуг, чтобы:
- Выплатить вознаграждение, если все условия выполнены до истечения времени ожидания. Выполнение платежа означает, что заблокированный токен может быть передан получающей стороне.
- Аннулировать вознаграждение, если не все условия выполнены после истечения времени ожидания. Аннулирование платежа означает, что заблокированный токен возвращается выдавшей его стороне.
В следующих статьях мы расскажем о более сложных схемах вознаграждений, такие как потоки платежей, премии, конкурсы и схемы роялти.
Жизненный цикл cоглашения о предоставлении услуг
При наличии всех компонентов соглашения о предоставлении услуг можно начать публиковать услуги с соглашением о предоставлении услуг и взаимодействовать на торговых площадках с потребителями. Мы объясним каждый шаг чуть позже, но сначала представим некоторые дополнительные данные.
Публикация услуги
Поставщик может предоставлять услуги посредством определения метаданных (см. OEP8) и запросов через программный интерфейс на получение доступа, потребление и мониторинг (см. OEP11).
Затем поставщик берет на себя роль публикатора (или делегирует эту роль) на рынке. Публикатор выбирает из шаблонов соглашение о предоставлении услуг и перед публикацией на рынке включает его в документ об идентификации услуги [с более подробной информаций можно ознакомиться здесь]. Методы публикации варьируются от открытого хранилища метаданных (называемого Aquarius) до сетевых программных интерфейсов / форумов или одноранговых сообщений.
Как только услуга опубликована, она может быть обнаружена потребителем. Это приведет к реализации соглашения о предоставлении услуг обеими сторонами посредством подписания и исполнения соглашения [с более подробной информацией можно ознакомиться здесь].
Далее мы рассмотрим несколько жизненных циклов различных соглашений о предоставлении услуг в ходе их реализации.
Контроль доступа
В рамках одного простого соглашения о предоставлении услуг обеспечивается контроль доступа к ресурсам вне блокчейна с экскроу-вознаграждением. Этот сценарий применения более подробно объясняется здесь. Ниже представлены актуальные для данного соглашения о предоставлении услуг события:
- Подписать и выполнить. Стороны достигают согласия, и создается экземпляр соглашения о предоставлении услуг по контролю доступа.
- Оплата. Потребитель блокирует необходимое количество токенов на эскроу-счете.
- Доступ. Поставщик услуг предоставляет доступ к ресурсу и сообщает об этом событии в блокчейне.
- Вознаграждение: Платеж с эксроу-счета либо будет выполнен, либо аннулирован, исходя из условий доступа и времени ожидания.
Обратите внимание, что в сценарии контроля доступа вне блокчейна доказано только то, что передан какой-то токен доступа, а не то, что этот токен оказался действительным и использовался в сессии.
Верифицированные услуги
Более сложный вариант применения расширяет описанный выше контроль доступа посредством добавления к услуге события верификации [тема находится в разработке, публикация планируется в следующем выпуске]. В данном случае поставщик ресурсов предоставляет сети верификаторов одно или несколько доказательств или аттестаций услуги.
Задача сети верификаторов заключается в разрешении споров о выполнении услуги (например, Truebit, fitchain, Enigma, Filecoin и т.д.). В данном случае соглашения о предоставлении услуг связаны между собой либо оракулами, либо связующими контрактами, которые можно запросить с помощью условий запроса. Следовательно, соглашения о предоставлении услуг смогут просто связаться друг с другом и применить результат разрешения спора, достигнутый сетью верификаторов.
Собираем компоненты воедино
Подводя итог, можно сказать, что мы заложили основу, позволяющую объединить все события жизненного цикла соглашения о предоставлении услуг. Обратите внимание, что несколько соглашений о предоставлении услуг могут легко выполняться параллельно. Ресурсам или серверам авторизации вне блокчейна или в сайдчейне просто необходимо опираться на заранее определенные события, генерируемые соглашением о предоставлении услуг.
Вывод
Мы разобрали структуру и жизненный цикл соглашений о предоставлении услуг Ocean Protocol. Данные соглашения являются основой доказуемой истории потребления услуг, разрешения споров, реализации механизма вознаграждения и так далее. Они, по сути, представляют собой связующее звено между услугами передачи данных в экосистеме Ocean Protocol и за ее пределами.
Теперь, вы знаете, что в Ocean есть соглашения о предоставлении услуг, так что деваться некуда…
Спасибо Дону Госсену, Айтору Аргоманиcу, Фангу Гонгу, Ахмеду Али, Квинтену Краувелсу, Себастьяну Герске, Эмили Хиршберг, Штефану Томасу, Эвану Шварцу, Франческо Гадалета, Джону Эневолдсену, Трою Макконахи, Брюсу Пону и Тренту Макконахи за вдохновение, сотрудничество и редактирование.
Полезные ссылки:
- Глубокий анализ структуры Ocean Protocol: https://blog.oceanprotocol.com/a-deep-dive-into-ocean-protocol-design-8fe78fcf8aa
- Выпуск Trilobite: https://blog.oceanprotocol.com/captains-orders-tis-the-season-for-shipping-d2551982f467
- OEP7 — децентрализованные идентификаторы в Ocean Protocol: https://github.com/oceanprotocol/OEPs/tree/master/7
- OEP8 — онтология метаданных: https://github.com/oceanprotocol/OEPs/tree/master/8
- Введение в OEP11: https://blog.oceanprotocol.com/oep-11-service-agreements-63421ca76d9f
- OEP11 — соглашения о предоставлении услуг: https://github.com/oceanprotocol/OEPs/tree/master/11
- Метаданные Ocean — Aquarius: https://github.com/oceanprotocol/aquarius
- Контроль доступа Ocean — Brizo: https://github.com/oceanprotocol/brizo
- Безопасный блокчейновы контроль доступа для Ocean Protocol: https://blog.oceanprotocol.com/secure-on-chain-access-control-for-ocean-protocol-38dca0af820c
Мы надеемся, что вы готовы узнать еще больше — заходите на Dev-Ocean, чтобы разобраться, над чем мы работаем, а все технические вопросы присылайте в наш чат Gitter.
Подписывайтесь на аккаунты Ocean Protocol в Twitter, Telegram, LinkedIn, Reddit, GitHub и на рассылку, чтобы быть в курсе обновлений и объявлений по проекту.
