В начале XVI века была издана книга английского юриста и философа Томаса Мора под названием "Утопия", в которой описывалась идеальная по мнению автора структура общества. Название этой книги стало именем нарицательным и дало имя всему жанру подобных трактатов. Книга Мора была далеко не первой: ещё за две тысячи лет до её выхода в свет древнегреческий философ Платон опубликовал трактат "Государство", в котором излагал свои взгляды на общественное устройство. Кто только не создавал своих утопий: например, Карл Маркс с его манифестом коммунизма и диктатурой пролетариата или Карл Поппер с его "Открытым обществом и его врагами". Почему бы не сделать этого и мне?
Китайский философ-даос Лао-Цзы писал, что когда нечто доходит до предела, оно обращается в свою полную противоположность. Из истории нам известно, что любые попытки воплощения различных утопий в жизнь всегда заканчиваются их полной противоположностью - тоталитарными антиутопиями. Поэтому в этом эссе я планирую описать не утопию, которая практически невозможна, а метаутопию - не то, как общество должно быть устроено, а то на основе чего оно должно быть зиждется и как развиваться. Метаутопия в отличие от утопии может быть применима в реальности и полезна для реального общества.
В основании этой метаутопии лежат два инструмента программирования - типизированный язык программиров��ния и система контроля версий. Возьмём для примера в качестве языка программирования TypeScript, а в качестве системы контроля версий - Git. Сегодня на TypeScript пишут и веб-приложения, и мобильные приложения, и программы командной строки, и сервера для приложений. Почему бы не написать на нём государство?
Основания
Существует два основных подхода по созданию интерфейса взаимодействия между различными модулями системы - "сначала спецификация - потом код" и "сначала код - потом спецификация". Давайте посмотрим, чем они отличаются и какой работает лучше.
В подходе "сначала спецификация" сначала типами задаётся доменная область и интерфейсы взаимодействия между разными модулями системы, а после этого один модуль имплементирует этот интерфейс, а остальные при необходимости обращаются к нему через этот интерфейс. Прямо как мы это делаем в программировании внутри каждого из модулей. Под модулями я здесь имею в виду не папки внутри кодовой базы одной и той же программы, а отдельные друг от друга части системы - фронтенд, бекенд, база данных или отдельный микросервис. Пример такого подхода: пишется типизированная RPC-спецификация интерфейса взаимодействия клиент-сервер, а после бекенд имплементирует этот интерфейс, а фронтенд вызывает методы, указанные в интерфейсе. Или другой пример: пишется Prisma-спецификация модели данных, по которой кодогенератор создаёт миграции для базы данных и код ORM-методов для сервера.
В подходе "сначала код" в начале пишется код одного из модулей, а после этого основанный на средствах рефлексии языка программирования кодогенератор извлекает из этого кода типы и записывает их в спецификацию. Примером такого подхода служит Swagger: сначала пишется код бекенда, а после специальный кодогенератор извлекает из кода Swagger-спецификацию, которая становится интерфейсом для фронтенда. Другой пример: TypeORM, в которой модель данных описывается классами с аннотациями средствами ORM, а после по ним генерируются миграции к базе данных.
За свою долгую карьеру программиста я часто использовал оба подхода и убедился в превосходстве подхода "сначала спецификация - потом код" над подходом "сначала код - потом спецификация". Второй подход почти всегда работает хуже, так как средства рефлексии в языках программирования обычно имеют изъяны и плохо обрабатывают пограничные случаи. Кроме того, второй подход переворачивает логику проектирования система вверх ногами - не модуль имплементирует интерфейс, а модуль декларирует свой интерфейс. Первый же подход, где в основе лежит спецификация, а не код, лёг в основу метода разработки под названием DDD - domain-driven design - проектирование, ориентированное на предметной области. В DDD в начале мы описываем в виде типов все сущности, с которыми мы работаем, а после типизированными интерфейсами задаём как одни части системы взаимодействуют с другими, и только после этого приступаем к реализации проекта.
Похожая идея лежит в основе такого течения мысли как web3. Многие ошибочно полагают, что web3 - это исключительно про криптовалюты. На самом деле, web3 - это гораздо более масштабная, чем криптовалюты, идея. В эпоху web1 интернет был децентрализированным, а интернет-ресурсы представляли собой почти полностью статичные странички или форумы. В эпоху web2 интернет-ресурсы стали веб и мобильными приложениями - гораздо более динамичными и интерактивными, но беда в том, что за это мы заплатили централизацией интернета в руках нескольких крупных платформ, которые владеют всеми аккаунтами и данными и решают, что показывать, а что нет, а кого вообще лишить доступа. Основной идеей web3 было обратно децентрализовать интернет, но не утратить интерактивность и взаимодействие между ресурсами.
Онлайн платежи, подконтрольные в web2 двум крупным сервисам по выпуску карт Visa и Mastercard и нескольким большим сервисам обработки платежей вроде Stripe, в web3 заменяются децентрализованными криптовалютами. Аккаунты заменяются криптовалютными кошельками - подтверждением идентичности служит подпись специального сообщения приватным ключом. Программные интерфейсы заменяются типизированными смарт-контрактами на блокчейне, которые исполняются автоматически. Платформы заменяются протоколами, на которых работают эти самые смарт-контракты. Управление этим всем добром происходит с помощью DAO - распределённых корпораций, работающих на смарт контрактах. Этот дивный децентрализованный интернет web3 был построен и сейчас существует рядом со старым web2, который за счёт своей централизации всё-таки гораздо удобнее в использовании.
Основные принципы web3 - это децентрализация и отсутствие единого центра власти, полное владение собственной идентичностью (твой приватный ключ подтверждает, что ты - это ты), отсутствие разрешений на использование платформ, отсутствие бана и деплатформинга, отсутствие необходимости доверять контрагенту, ведь смарт-контракт исполнится в полном соответствии со своим кодом, и никто не может на это повлиять. Последняя особенность смарт-контрактов и стала лозунгом всего web3-движения: код - это закон. Именно на этом принципе и на DDD-подходе я развиваю свою идею программистской метаутопии.
Метаутопия
Любое государство по своей сути представляет собой систему обработки информации - потоки информации текут из одних частей государственной системы в другие и обратно. А что управляет потоками информации? Код. Сейчас этот управляющий государственной системой код записан в виде законов в юридических документах. В программистской метаутопии этот код будет записан на типизированном языке программирования.
Всё законодательство метаутопии должно быть выражено в виде кода на TypeScript, лежащего в публичном git-репозитории. Законы могут быть разделены по модулям кода: модуль уголовного права, модуль гражданского права, модуль семейного права и так далее. Типы в этом коде отображают аксиоматически определённые понятия: компания, армия, президент, человек, животное, гражданин, иностранец и тому подобные. Наследование типов отображает взаимоотношения между сущностями - ну например, президент, гражданин и иностранец наследуют человеку в случае объектно-ориентированного подхода либо же обладают компонентом "человек" в случае сущностно-компонентной системы (entity component system). Из моего опыта в разработке видеоигр сущностно-компонентный подход проявляет себя гораздо гибче в системах со сложными связями.
Интерфейсы со списком методов отображают контракты взаимодействия различных структур и органов государства друг с другом: например, объект типа "президент" может произвести объект типа "указ" и направить его в метод объекта "армия", которая внутри себя инкапсулирует сложную структуру - объект типа "генеральный штаб" вызывает методы объекта типа "батальон", и так далее. Таким образом, всё законодательство целиком, все формальные взаимодействия разных частей государственной машины полностью выражаются в виде типизированного программного кода. Это позволяет социальному архитектору видеть картину целиком.
Каждое изменение законодательства, каждый законопроект - это пулреквест, каждое кодревью и обсуждение пулреквеста - это по сути работа профильного комитета парламента. Проверка непротиворечивости законов друг другу осуществляется проверкой типов компилятором. Тестировщики пишут юнит-тесты для проверки того, что работа законов соответствует целям их принятия и интеграционные тесты для проверки взаимодействия разных законов друг с другом. Пентестеры проводят аудит законов и пытаются найти эксплойты в законодательстве, которые могли бы использовать злоумышленники. Статический анализ кода проверяет, что нельзя создать закон, который прямо дискриминирует конкретную группу населения.
Такая система будет полностью прозрачна для всех граждан, для всех организаций, для самого государства. Станет возможным гораздо проще проводить реформы - юридическая часть реформ будет представлять собой просто рефакторинг кода, после которого целостность новых законов будет проверяться компилятором и тестами. Государственные и частные организации должны быть обязаны полностью в виде API имплементировать свои интерфейсы. Конечно, наложение этих типизированных интерфейсов на реальные организации - это сложнейшая задача, которой прошлая структура будут сильно сопротивляться, но эволюционным путём за десятки лет это преобразование произвести возможно. Электронные госуслуги со скрипом и треском внедрялись в государствах в течении многих лет, но в конце концов были успешно внедрены.
Конечно, как и любая другая утопия, при реальной имплементации в жизнь эта метаутопия программистов-аутистов может привести к ужасным антиутопическим последствиям. И, скорее всего, обязательно приведёт. Но я верю, что государства XXII века будут похожи именно на такие структуры - state as code.
Больше интересных постов и видео про философию, программирование, буддизм и математику вы можете найти в моём телеграм‑канале. Туда я часто выкладываю то, что из‑за тематических ограничений не могу публиковать на Хабре.
