Закрытый Smart Contract Stack проекта OpenLaw

Гарвардский (Berkman Klein Center for Internet & Society at Harvard Law School) проект OpenLaw заявляется, как платформа для создания «полностью цифровых, юридически значимых активов без необходимости кодировать» (purely digital, legal-enforceable assets with no coding necessary). По факту — проект пытается выйти из атомарной простоты протоколов чейна (Etherium), ориентированных исключительно на торговлю (DutchX, OpenBazaar) или на DAO-организации (Aragon), и начать вводить в поле вычислений какие-то более богатые правовые состояния в виде first-class objects. Это не единственная попытка: был не очень понятный и на весну 2020 не очень живой на вид проект двух сингапурцев Legalese.com, слегка появившийся к излёту блокчейн-хайпа в 2018-ом проект читабельных смарт-контрактов Lexon, и ещё пара, о которых у меня сохранились лишь смутные воспоминания, но даже не ссылки. Теоретический фон в виде Language for Legal Discourse МакКарти или LEGOL Стампера образца 1970-80-ых оставим за кадром.
 
OpenLaw — проект живой и активный, чему можно только радоваться. Начали с соглашений. Насколько можно оценить состояние проекта, дело создания CLAs — Computable Legal Assets сейчас находится в состоянии формулировки «Reusable Clauses». В этой категории у них реализована синтаксическая поддержка полутора десятка классов простых сущностей, такие как date, money, address и пр., и язык разметки для того, чтобы драфтить с помощью оных соглашения и исполнять их в рамках трёх поддерживаемых «PET protocols»: Payments, Escrows, Tokenization. Плюс, несколько месяцев назад выкатили открытый API для интеграции двух типов сервисов: “Common and Signature”, что эффективно означает «Всякое-разное и Цифровая подпись». Видео-тизер показывает, как просто заинтегрировать туда DocuSign и начать подписывать документы, что означает, что всё тоже в зачаточном состоянии.
В области computational law всё в зачаточном состоянии, но в документации на OpenLaw удивляет простота визии. Стек смарт контрактов (выше) схематизирует интеграцию подсистем с различной вариативностью и предметной зависимостью параметров:
  1. Szabo-style смарт контракты блокчейна — наиболее общий и вариативный, «базовый» и предметно-независимый уровень;
  2. Рикардианские контракты — уровень с интеграцией правового текста в простую машинную обработку через темплатизацию и подписи. Здесь соответствующие части соглашения фиксируются и параметризуются для специализации выше;
  3. Оракулы — уровень полной специализации, где все параметры заполняются значениями и это представляется в качестве авторизованного цифрового актива.

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

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

Знаниецентричная вертикаль может и должна выглядеть несколько иным образом, сводя воедино различные уровни практик такого управления, и соответствующих уровней обобщения состояний, доступа, а также обеспечивающих технологических систем. Схема ниже, разработанная в рамках исследований Минской Лаборатории вычислительного права, может служить такой картой, где PET protocols, атомарные сущности и чейны укладываются на своё частное место, как один из горизонтально «тонких» (функционально узких) вариантов вертикальной (сколь-нибудь функционально полной) поддержки каких-то рыночных практик. С подобной картой верхнего уровня можно начинать проектировать уже не отдельные API для узких академических «школьных» задач, а более масштабные системы поддержки цифрового права, корпоративного или государственного размера.

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

Добавить комментарий