Закрытый Smart Contract Stack проекта OpenLaw
- Szabo-style смарт контракты блокчейна — наиболее общий и вариативный, «базовый» и предметно-независимый уровень;
- Рикардианские контракты — уровень с интеграцией правового текста в простую машинную обработку через темплатизацию и подписи. Здесь соответствующие части соглашения фиксируются и параметризуются для специализации выше;
- Оракулы — уровень полной специализации, где все параметры заполняются значениями и это представляется в качестве авторизованного цифрового актива.
Это моё понимание этой схемы, а не изложение авторов. Авторы лаконичны и в изложении, и в концептуализации. Я бы не сказал, что с такой визией очевидны какие-то широкие горизонты развития продукта или технологии. Открытый закон закрыт в узкой специализации. Вертикаль утыкается пиком в оракулов — поставщиков данных, что с размахом «открытого закона» соотносится слабо.
Смущает то, что создатели OpenLaw всё ещё смотрят на закон, как на данные, и вся технологическая вертикаль и горизонтали концептуально ориентированы на обработку данных, а не на управление жизненным циклом правового знания.
Знаниецентричная вертикаль может и должна выглядеть несколько иным образом, сводя воедино различные уровни практик такого управления, и соответствующих уровней обобщения состояний, доступа, а также обеспечивающих технологических систем. Схема ниже, разработанная в рамках исследований Минской Лаборатории вычислительного права, может служить такой картой, где PET protocols, атомарные сущности и чейны укладываются на своё частное место, как один из горизонтально «тонких» (функционально узких) вариантов вертикальной (сколь-нибудь функционально полной) поддержки каких-то рыночных практик. С подобной картой верхнего уровня можно начинать проектировать уже не отдельные API для узких академических «школьных» задач, а более масштабные системы поддержки цифрового права, корпоративного или государственного размера.
Предположу, что корпорации вроде Сбербанка или Сибура, инвестирующие во внутренние legaltech-разработки, имеют подобные архитектурные представления. Интересно было бы глянуть на их качество. Можно предположить, что если они создаются ИТ-архитекторами, то будут сильно технологически-зависимы, что для развития систем, переиспользования и масштабирования компонентов рано или поздно станет барьером: и в плане развития концептуального понимания, федерирования онтологий, так и чисто экономического характера — через увеличение затрат на разработку.