Архитектура проекта Юрия Иванова

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

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

Постепенно становится понятно, что перед тобой не просто криптовалюта.

Перед тобой попытка построить программируемую систему деятельности.

Именно это меня больше всего удивило в ходе исследования.

Сначала кажется, что фундаментом системы являются монеты. Потом кажется, что фундаментом являются аккаунты. Потом возникает мысль, что главным элементом являются смарт-контракты.

Но чем глубже читаешь код, тем яснее становится: автор строил систему вокруг участников и их действий.**

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

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

Здесь аккаунт оказывается центральной фигурой архитектуры.

Вокруг него постепенно выстраивается всё остальное.

Сначала появляются права доступа. Затем возникает система вызова контрактов. Потом обнаруживается состояние. Затем события. Затем токены.

И всё это снова возвращается к аккаунту.

Во время исследования особенно интересным оказался механизм хранения состояния.

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

В TERA всё выглядит иначе.

Состояние оказывается связано не столько с самим контрактом, сколько с аккаунтом, через который контракт действует.

В результате возникает довольно необычная философия.

Контракт здесь выглядит не как самостоятельное государство со своей территорией, а скорее как набор правил поведения для определённой области системы.

Ещё интереснее становится, когда доходишь до экономики.

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

Контракт не выглядит всемогущим существом, которое может переписывать экономику по своему желанию.

Он обращается к специальным механизмам системы.

Сначала это кажется мелочью.

Потом понимаешь, что именно так формируется граница между логикой и учётом.

Контракт говорит, что нужно сделать.

Система решает, можно ли это сделать.

Это очень взрослое архитектурное решение.

По мере развития проекта в коде начинают появляться события.

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

Фактически система начинает не только выполнять действия, но и рассказывать о том, что произошло.

Именно здесь впервые появляется ощущение, что автор думал не только о деньгах.

Он думал о деятельности.

Следующим большим открытием стала токенная архитектура.

Я ожидал увидеть отдельную подсистему токенов, которая живёт рядом со смарт-контрактами.

Вместо этого обнаружилась гораздо более красивая идея.

Токен оказался разновидностью контракта.

Не отдельным объектом.

Не отдельной сущностью.

Контрактом, который получил право определять правила собственной валюты.

На мой взгляд, это один из самых сильных архитектурных ходов всей системы.

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

Появляется контракт.

Контракт получает специальные возможности.

После этого он начинает играть роль валюты.

В этот момент система неожиданно начинает напоминать не криптовалюту, а конструктор экономик.

Каждый такой контракт может определять собственные правила поведения.

Особенно интересными выглядят механизмы вроде OnTransfer и OnGetBalance.

Они позволяют контракту участвовать в определении того, как работает перевод средств и что вообще считается балансом.

Это уже не простая бухгалтерия. Это программируемая экономика.

После нескольких циклов исследования возникло ощущение, что автор постепенно двигался в сторону идеи, которую так и не успел довести до логического завершения.

Система получила аккаунты.

Получила полномочия.

Получила контракты.

Получила состояние.

Получила события.

Получила программируемые валюты.

Но следующего шага почти не видно.

Почти не обнаруживается развитой модели коллективного управления.

Нет полноценного слоя предложений, обсуждений, голосований и принятия решений, который естественно ожидался бы после появления программируемой экономики.

Словно строительство большого здания остановилось на этаже ниже.

Фундамент готов.

Несущие конструкции готовы.

Лифты работают.

Электричество подведено.

Но некоторые помещения так и остались без стен.

Именно поэтому исследование TERA оказалось для меня интересным не только как разбор чужого кода.

Оно постепенно превратилось в изучение границы между завершённой инженерной системой и системой, которая могла бы стать чем-то значительно большим.

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

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

Возможно, именно поэтому многие решения проекта выглядят необычно даже спустя годы.

Они создавались не для того, чтобы просто хранить монеты.

Они создавались для того, чтобы описывать отношения между сущностями системы.

А это задача значительно сложнее, чем выпуск ещё одной монеты или ещё одного токена.

Именно в этом месте заканчивается территория, которую можно изучить по исходникам.

И начинается территория, которую каждому следующему разработчику приходится строить самостоятельно. Здесь уже недостаточно читать код. Нужно отвечать на вопрос, каким должен быть мир, который этот код будет обслуживать. И это, пожалуй, самая интересная часть всей истории.