В предыдущем номере журнала «Эксперт-Сибирь» (№ 1–4 за декабрь 2017 года) была опубликована статья «Тупые «умные» контракты», в которой обсуждалась одна из актуальных тем цифровой экономики — «умные» (smart) контракты. Во многом разделяя высказанную в статье критическую точку зрения на роль и значение существующих децентрализованных систем, базирующихся на текущем воплощении понятия «умного» контракта, предлагаю продолжить обсуждение этой важной темы, но уже в более позитивном и конструктивном направлении.

Идея «умных» контрактов как основа роботизации деловых отношений агентов/акторов (в роли которых могут выступать люди, оборудование, программы, бизнес-процессы и т.п.), была высказана еще в девяностых годах прошлого столетия, но получила свое практическое воплощение сравнительно недавно. И сразу же привлекла к себе пристальное внимание, поскольку было понятно, что эта инновация обладает огромным потенциалом и способна совершить настоящую революцию в сфере автоматизации управления широкого спектра деловых отношений.

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

 

 

Одной из причин этого является то, что понятие «умного» контракта нашло свое первое практическое воплощение в сети Биткоин и стало для последующих «криптовалютных» проектов неким эталоном. Напомним, что в системе Биткоин «умный» контракт трактуется как любой транзакционный протокол, чей базовый функционал не должен зависеть от доверия к третьим лицам, что обеспечивалось используемой в сети технологией блокчейн. Например, можно задать условие на криптовалютном кошельке, что для его использования надо минимум две подписи (подтверждения) от таких-то пользователей. Так называемые кошельки с мульти-подписью. Или еще один пример «умного» контракта: средства из этого электронного кошелька можно использовать не ранее, чем через заданный промежуток времени. И прочие подобные варианты.

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

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

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

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

В связи с этим возникает вопрос — как такие контракты следует использовать в повседневном бизнесе? Ведь на практике очень важно, чтобы смарт-контракты интуитивно воспринимались бизнес-участниками как обычные контракты, но только более строго и четко оформленные. Кстати, заметим, что программный императивный код контракта не может быть полезным и для его автоматической верификации. Причина в том, что если используется полный по тьюрингу язык программирования (например, язык Solidity), то получаемый код контракта не доступен для автоматической его верификации в силу алгоритмической неразрешимости этой проблемы в таком языке.

Жесткая привязка к единственному виду блокчейна может оказаться весьма обременительным условием, поскольку в разных ситуациях оптимальное решение может быть связано с совершенно другой формой распределенного реестра. Например, смарт-контракты на Эфире могут использовать в основном данные только из блокчейна Ethereum и выдавать данные обратно туда же. То есть, например, невозможно или крайне сложно описать такой смарт-контракт на Эфире, который бы мог реализовывать транзакции еще и в других системах типа Биткоина: например, контракт по обмену биткоинов на эфиры. Или контракт по покупке неких токенов за фиатные деньги с оплатой по карточкам.

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

 

 

Естественно возникает вопрос — как преодолеть указанные выше недостатки и обойти проблемы, присущие текущему пониманию и практическому воплощению понятия «умного» контракта? Ответ следует искать, прежде всего, в отказе от использования для написания «умных» контрактов тьюрингово полных императивных языков программирования и использования для этих целей специальных декларативных языков спецификаций, позволяющих контракт представлять в виде некой вычислимой и, тем самым, исполнимой компьютером модели, достаточно полно и адекватно описывающей и предметную область, к которой относится контракт, и сложную логику его исполнения. Другими словами, предлагается смарт-контракты не программировать, а моделировать! При этом естественно требовать, чтобы такая модель обязательно содержала в себе и наглядно представляла исходную семантику. Подобный семантический смарт-контракт представляет собой автоматически управляемое и юридически правомерное соглашение, сохраняющее смысл (семантику) деловых взаимоотношений агентов/акторов и предназначенное для компьютерного исполнения (возможно, с применением криптографических и иных средств). Если обычные контракты определяют условия взаимодействия партнеров с помощью юридически значимых текстовых документов, то семантический смарт-контракт будет это делать с помощью либо полностью автоматического, либо с использованием оракулов частично автоматического сопровождения и поддержки контрактных операций, при необходимости сохраняя историю их исполнения в том или ином, наиболее подходящем распределенном реестре.

В качестве такого конкретного языка спецификаций контрактных отношений может выступать логико-вероятностный язык Δ0-формул (дельта-ноль формул), развиваемый специалистами. Подобные разработки есть в Институте математики СО РАН и Иркутского государственного университета в рамках концепции семантического моделирования. На базе этого языка в настоящее время создано несколько его диалектов. Примером здесь могут служить язык Libretto и комплекс Discovery, позволяющие моделировать логико-вероятностные контрактные условия. При создании и последующем использовании языков семантического моделирования полностью подтвердилось, что переход от программирования «умного» контракта к его моделированию позволяет гарантированно преодолевать указанные ранее препятствия и устранять недостатки, открывая тем самым новые горизонты развития и возможности дальнейшего совершенствования понятия смарт-контракта. Следует отметить, что именно такой вариант расширенного понимания смарт-контракта и соответствующий ему диалект языка семантического моделирования реализуется в настоящее время в рамках проекта KIRIK.io новосибирских разработчиков из компании MiniApps.pro. И, как утверждают разработчики платформы семантических контрактов, KIRIK позволит специалистам разных предметных областей создавать использовать смарт-контракты без привлечения программистов, при этом откроет возможность объединять разные блокчейны и проводить транзакции на основе семантических контрактов как между разными блокчейнами, так и с привлечением внешних IT-систем, таких, например, как традиционные банковские системы, соцсети, средства искусственного интеллекта и т. п. Появляется возможность организовывать и развивать на принципиально иной основе различные децентрализованные сообщества (экосистемы) и проводить ICO.