ontobox.io

Ontobox: смарт-контракты как документные модели

🕑  12 сентября 2017

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

Семантические модели

Многие годы наша команда разрабатывает методы семантического моделирования и применяет их для описания научных данных.

Семантическое моделирование – направление искусственного интеллекта и математической логики, которое описывает знания о предметной области, представляя их в логической форме. На базе семантических моделей могут работать knowledge mining systems, роботы, системы автоматических рассуждений и машинного обучения. Несколько лет назад одно из изобретений искусственного интеллекта – нейронные сети и deep learning – уже захватило мир. Мы уверены, что сегодня настало время и для семантического моделирования.

Прежде всего семантическое моделирование может дать прорывной эффект в автоматизации управления бизнесами. Сегодня здесь царят SAP R3, Oracle ERP, Microsoft Dynamic Ax, 1С, Salesforce и подобные системы. По большому счету все они – программы, которые управляют бизнес-процессами. Но программирование имеет один крайне неприятный изъян, который мы называем лоботомией смыслов. Единая цельная семантика бизнес-процессов в результате программирования расчленяется и растворяется в базах данных и программном коде. В результате мы теряем прямой контроль над бизнес-процессами. Без доступа к семантике невозможно использовать средства искусственного интеллекта и управленческих роботов – им просто не с чем работать.

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

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

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

Получившаяся модель нам понравилась. Мы создали платформу управления документными моделями, и вместе с нашими бизнес-партнерами начали строить одну за другой новые модели: систему бюджетирования и управления движением товара в ритейлере, CRM-модель, коммерческую отчетность и управление персоналом в торговле, управление производством продуктов, ERP и другие. Сегодня некоторые модели уже внедрены и активно эксплуатируются бизнесами, другая часть пока находится в разработке.

Выводы такие:

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

Это звучит немного фантастично. Например, если подобное удалось бы сделать в строительстве, то здание появлялось на свет сразу после разработки архитектором его проекта (модели здания). Однако в случае семантических моделей это работает.

Семантическое моделирование может заменить программирование в задачах управления бизнес-процессами.

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

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

Смарт-контракт – автоматически управляемое соглашение, предназначенное для заключения и исполнения с применением криптографических средств [1]. Если обычные контракты определяют условия взаимодействия партнеров с помощью юридически значимого текста, то смарт-контракт делает это с помощью автоматической поддержки контрактных операций и сохранения истории их исполнения в блокчейне.

Cмарт-контракты оказались в поле нашего внимания, когда мы занялись описанием взаимодействия компании и её поставщиков. Оказалось, что

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

Как интегрировать смарт-контракты с семантическими моделями? Модели способны самостоятельно обеспечить такие качества смарт-контрактов как (i) автоматизация исполнения транзакций в бизнес-процессах и (ii) автоматический контроль входных данных и результатов. Но для децентрализованного взаимодействия контрагентов нужно еще одно свойство: (iii) автоматизация и децентрализация механизмов безопасности и доверия.

Именно последнее свойство превращает описание бизнес-процесса в смарт-контракт. Его добавление дает возможность использовать семантические модели для построения межфирменных интеллектуальных договорных сетей (smart contractual networks).

Проблемы

К сожалению, пока мы не смогли подключить смарт-контракты к моделированию. Почему? Для этого есть несколько причин.

Проблема 1. Растворение семантики в программе смарт-контракта.

Существующие сегодня методы создания смарт-контрактов базируются на программировании. Но как только мы кодируем бизнес-процесс в программе контракта, его смысл и логическая структура растворяются в программном коде. Декларативное "что" превращается в императивное "как". Код не доступен ни для человеческого, ни для автоматического контроля. Если используется полный по Тьюрингу язык (например, Solidity [2]), то автоматический анализ программы невозможен даже теоретически в силу неразрешимости базовых алгоритмических проблем полного языка.

Для семантических моделей контракты-как-программы вообще не подходят. У нас описания бизнес-процессов – это семантические структуры, прозрачные для средств ИИ. Как только смарт-контракты превращаются в программы, всё теряется в программном коде. И в чем здесь 'smartness'? Наоборот, очевидный шаг назад. Поэтому мы и предлагаем не программировать смарт-контракты, а моделировать, о чем скажем более подробно ниже.

Проблема 2. Закрытость для основных участников.

Еще одна проблема – программы понимают только программисты, да и то не всегда. И что это за работа, если управленцы не понимают контракты, по которым работают? Как использовать смарт-контракты в традиционном бизнесе, если нам нужно прибегать к услугам толмача-программиста? Вряд ли такой сценарий работы станет популярным.

Исключительно важно, чтобы смарт-контракты интуитивно воспринимались всеми участниками процесса как вполне обычные контракты. А мы все знаем, что контракты – это документы. Контракты-программы никак не совместишь и с другими компонентами традиционного бизнеса – там тоже царит документооборот.

Проблема 3. Аутсорсинг исполнения смарт-контрактов.

Аутсорсинг исполнения контрактов на внешнем сервисе (например, Эфириуме [3]), представляется нам узким горлышком технологии. Отрыв смарт-контрактов от бизнес-процессов компании и их размещение на внешней платформе означает вывод конфиденциальной информации за контур безопасности компании. Топ-менеджменту решиться на это довольно трудно. А значит, такую архитектуру будет очень сложно продвигать.

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

Проблема 4. Жесткая привязка к конкретному виду блокчейна.

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

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

Смарт-контракты как модели

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

Моделирование не разрушает смыслы, а структурирует их. Оно делает контракты по-настоящему «смарт» и дает ИИ-роботам инструменты для контроля и управления.

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

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

Если смарт-контракты моделировать, то с точки зрения семантической модели они не будут ничем отличаются от других бизнес-процессов – за исключением ведения лога их жизненного цикла в блокчейне:

Смарт-контракт – это описание бизнес-процесса с дополнительными мерами децентрализованного обеспечения доверия.

Такой подход делает взаимодействие смарт-контрактов и внутренних бизнес-процессов бесшовным, и встраивает смарт-контракты в единую среду управления компанией.

Наконец, моделирование контрактов менее затратно в разработке и поддержке, чем их программирование.

Документные модели

Совместная с партнерами работа по созданию моделей заставила нас решить еще одну проблему. Семантическое моделирование основано на математической логике. Логика – элитарна, труднодоступна и требует специальной подготовки. Это существенно ограничивает её распространение.

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

Документная модель – это семантическая модель, устроенная как коллекция логических структур, которые людьми воспринимаются как «обычные» документы.

С такими «документами» можно корректно работать, не задумываясь о том, что на самом деле это логические формулы. В частности, cмарт-контракты в документных моделях также представлены в виде документов (а не программ!). Математически документные модели описаны нами в работе [4].

Мы разработали стратегию управления документными моделями и смарт-контрактами, которую назвали ontobox.io. Она базируется на следующих принципах.

Ontobox.io определяет смарт-контракты как документные модели бизнес-процессов с обеспечением доверия через блокчейн. Смарт-контракты в ontobox.io не программируются, а моделируются.

Ontobox.io оперирует смарт-контрактами и «обычными» документами в едином документном пространстве. В блокчейне сохраняются только данные, необходимые для обеспечения доверия.

Ontobox.io не фиксирует вид блокчейна, с которыми работают документные модели. Вид блокчейна, способы хранения данных и достижения распределенного консенсуса зависят от контекста задачи и интересов участников.

Ontobox.io в качестве ядра технологии определяет платформу управления документными моделями. При загрузке модели некоторой области на платформу, она начинает действовать как domain specific information system.

В приложении мы демонстрируем, как используется документное моделирование для построения модели книжной библиотеки с бизнес-процессами выдачи и возврата книг. После построения документной модели библиотеки (на это уходит 15-20 минут) модель начинает действовать как обычная IT-система поддержки библиотечной деятельности.

Посмотрим, как документное моделирование может решить проблемы смарт-контрактов, которые мы обсуждали в начале этих заметок.

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

Проблема 2: закрытость для основных участников. Документы как метафора понятны самому широкому кругу участников. Люди, работая с документами, могут даже не осознавать, что они находятся в математически формализованной среде.

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

Проблема 4: жесткая привязка к конкретному виду блокчейна. Документные модели не зависят от вида используемого распределенного реестра. Они способны обеспечить несколько сценариев реализации механизмов доверия – в зависимости от решаемой задачи и уровня доверия между участниками смарт-контрактов.

Ontobox.io: реализация

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

Приложение. Документная модель библиотеки

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

Мы сконструируем модель библиотеки (на практике это занимает 15-20 минут работы на платформе управления документными моделями). В соответствии с концепцией ontobox.io эта модель превратит платформу в domain specific information system поддержки библиотечной деятельности, включая управление реестрами книг и читателей, а также совершение «сделок» по выдаче книг.

В документной модели структура документов разных типов определяется с помощью их форм. Форма документа задает

На платформе работа по формированию модели ведется с помощью интерфейсов- конструкторов, но для демонстрации мы воспользуемся некоторым domain specific language.

Три формы документов определяют структуру библиотечной модели. Две из них – Book и Reader – задают основных акторов модели, а третья – Provision – определяет контракт выдачи книги. Начнем с формы для книг:

Form Book {
    author: String!
    title: String!
    provided: Provision* 
    States: InCollection, BeingRead
}

Звездочка означает, что поле многозначное, '!' – что допускается ровно одно значение. Мы определили библиографическую карточку, которая содержит информацию о книге и ее выдачах (поле provided). Статус книги указывает, где она сейчас находится.

Определим форму для читателя.

Form Reader {
    name: String!
    surname: String!
}

Для читателя не задаем никаких статусов, поскольку не собираемся ими управлять.

Введем теперь форму для контракта выдачи книги Provision

Form Provision {
    book: Book!
    reader: Reader!
    States: Prepared, Borrowed, Returned
}

Процесс выдачи книги состоит из трех этапов (подготовка к выдаче, книга выдана, книга возвращена). Эти этапы отражены в статусах документа.

Транзакция – это переход документа из состояния в состояние, который влечет изменения в документной модели. Для Provision только два перехода имеют смысл:

PreparedBorrowed (книга выдается). Эта транзакция (i) изменяет статус выдаваемой книги на BeingRead и (ii) фиксирует факт выдачи книги читателю (текущий документ Provision добавляется к документу книги).

BorrowedReturned (книга возвращается). Транзакция устанавливает статус книги InCollection.

На нашем domain specific language эти транзакции можно описать так:

Transaction Provision: Prepared ➞ Borrowed {
    guard (book.state == InCollection)  =>  {
        addToField(book.provided, this)
        setState(book, isRead)
    }
    guard _  =>  error("Book Borrowed!")
}

Transaction Provision: Borrowed ➞ Returned {
    guard (book.state == Borrowed)  =>   setState(book, InCollection)
    guard _  =>  error("Book Not Borrowed")
}

Этот код содержит императивные компоненты, но они тривиальны. Описание транзакции является частью модели и имеет вид

{guard Guard_1 => Code_1;  …;  guard Guard_N => Code_N}

В транзакции исполняется крайний левый Code_i, для которого истинен Guard_i. Только Code_i содержит императивную компоненту. Но на самом деле Code_i также не является полностью императивным:

Исполнение Code_i не изменяет напрямую модель, а генерирует линейную цепочку инструкций, которая затем применяется к документной модели, изменяя её.

Прорывной особенностью наших транзакций является то, что сам Code_i исполняется в readonly режиме. Его задача – сформировать цепочку инструкций, которые изменят документную модель. Однако сама модель будет изменена только после завершения Code_i и проведения необходимых проверок. Такой двухшаговый механизм имеет очень важные преимущества. Например, мы можем сохранять инструкции в блокчейне, что навсегда зафиксирует факт проведения транзакции.

Для изменения в модели используется крайне ограниченный набор примитивных инструкций, например,

    createDocument(Formname)
    setField(Field, Value)
    addToField(Field, Value)
    setState(Document, stateName).

Выдавая книгу B читателю R, библиотекарь создает новый документ P формы Provision

P = {
    reader: R
    book: B
    State: Prepared
}

В момент выдачи книги читателю библиотекарь с помощью транзакции переводит документ P из состояния Prepared в состояние Borrowed. Эта транзакция автоматически порождает следующую линейную цепочку инструкций:

    setState(P, Borrowed)
    addToField(B.provided, P)
    setState(B, isRead)

которая затем применяется к документной модели.

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

References

[1] https://ru.wikipedia.org/wiki/Смарт_контракт

[2] https://ru.wikipedia.org/wiki/Solidity

[3] https://ethereum.org/

[4] Малых А., Манцивода А. Теория документного моделирования. http://ontobox.io/mpr.