ч2 - https://set.ki/post/mkxk5Gq

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

## Что мы на самом деле строили

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

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

## Универсальные транзакции и потолок

Как раз в то время я работал над унификацией социальной транзакции. Разрабатывать DTO под каждый тип — идея так себе. Но и одно поле вроде JSON — накладно. Так появились первые универсальные транзакции: для индексации «из коробки» набор полей string1, string2, int1, int2 и т. д. Заводить новые по смыслу транзакции стало проще.

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

## Layer-1 и Layer-2

Логично было бы разделить блокчейн и социальные данные. Пусть Layer-1 занимается транспортом и базовым монетарным консенсусом. Layer-2 узлы берут на себя консенсус верхнего уровня — социальный.

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

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

## Разрешено всё, что не запрещено

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

Слишком сильный контроль за структурой payload и социальными контрактами принёс немало головной боли. Мой рецепт: разрешить всё, а при обработке дальше отбрасывать неподходящее. Это закрывает как минимум две проблемы:

- создавать «социальные» (и не только) транзакции без хардфорка — соцсеть, хранилище паролей, почта…; - упростить и удешевить prune — очистку старого ненужного для лёгкого варианта узла.

## Всё в одном — и цена этого требования

Разделение ответственности — хорошая штука. Но превращать децентрализованную сеть в микросервисную архитектуру, думаю, не стоит. Можно нарезать сервисы, собрать их через docker-compose или Kubernetes — и было бы «счастье». Но как быть с пользователями, которые этих слов не знают?

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

## Вместо разбора полётов

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

Сетка не даёт писать совсем большие посты — часть 2 пришлось разбить, поэтому местами скомканность, но уж как есть.

## Эпилог

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

// Side effects: // - 2 AI agents damaged during text formatting and proofreading