В криптовалюте композируемость обычно продается как суперсила.
Все могут говорить со всеми. Контракты могут вызывать контракты. Протоколы могут накладываться на протоколы. Мечта — это гигантская, текучая машина, где ценность и логика свободно текут, и инновации накапливаются, потому что ничто не изолировано.
Эта мечта реальна. Но она имеет свою цену, которую большинство платформ осознает позже: когда все соединено со всеми, неудача распространяется так же легко, как и успех.
Vanar Chain ощущается так, как будто он был разработан с учетом этого компромисса.
Вместо того чтобы рассматривать композицию как чистое благо, она, похоже, рассматривает ее как нечто, что нужно формировать. Не только связи, но и границы. Не только открытость, но и сдерживание. Это не делает систему менее мощной. Это делает ее более выживаемой.
В многих экосистемах композиция растет быстрее, чем понимание. Команды интегрируют, потому что могут, а не потому что должны. Зависимости накапливаются. Предположения просачиваются через слои. И в конечном итоге небольшое изменение в одном месте вызывает рябь через десять других.
Когда это происходит, отладка превращается в археологию.
Позиция Vanar кажется другой. Она не пытается максимизировать, сколько вещей может подключаться. Ей, похоже, больше интересно убедиться, что когда вещи подключаются, радиус взрыва остается разумным.
Это неброская цель. Но она очень взрослая.
На практике это проявляется как предпочтение четким взаимодействиям вместо неявной связи. Вместо того чтобы каждый компонент мог взаимодействовать с каждым другим компонентом, архитектура поощряет более узкие, более явные пути. Вы не просто "используете" что-то. Вы интегрируетесь с этим на определенных условиях.
Это меняет то, как системы эволюционируют.
Когда интеграция дешева и неограничена, люди, как правило, переинтегрируют. Они стремятся к совместному состоянию вместо совместного намерения. Они зависят от внутренних структур вместо контрактов. Это кажется быстрее в данный момент, но делает будущие изменения дорогими.
Когда интеграция имеет границы, команды проектируют для интерфейсов, а не для сокращений. Они думают о том, что они обещают другим частям системы. И, что не менее важно, о том, что они не обещают.
Vanar, похоже, направляет разработчиков в этом направлении — не путем ограничения, а путем создания хороших границ как пути наименьшего сопротивления.
Это дает вознаграждение за надежность.
Большинство крупных неудач в композируемых системах не происходят из-за того, что что-то одно ломается. Они происходят из-за того, что много вещей предполагают, что что-то не сломается. Когда общая зависимость меняет поведение или система нижнего уровня начинает использовать функцию неожиданным образом, проблема не в самом изменении. Проблема в том, что слишком много частей было молчаливо связано с этим.
Поощряя более узкие, более явные связи, Vanar уменьшает площадь этих молчаливых соединений. Когда что-то меняется, меньше вещей удивляются этому. А сюрпризы, как правило, превращают ошибки в инциденты.
Это также изменяет то, как команды думают об обновлениях.
В сильно переплетенных системах обновления кажутся опасными, потому что вы действительно не знаете, кого это затронет. Вы тестируете свой собственный код, но реальный риск заключается в предположениях других людей. Это приводит к медленным, консервативным изменениям — или, что еще хуже, к поспешным изменениям под давлением.
Когда композиция структурирована, обновления становятся более предсказуемыми переговорами. Вы знаете, какие интерфейсы вы затрагиваете. Вы знаете, какие контракты вы соблюдаете. И вы знаете, какие части системы намеренно изолированы от ваших изменений.
Это не исключает координацию. Это делает координацию ограниченной.
Здесь также есть долгосрочный эффект на экосистему.
Платформы, которые оптимизируют максимальную композицию, часто развиваются очень быстро — а затем замирают под собственным сложным весом. Каждый новый продукт должен понимать джунгли взаимодействий. Каждая новая команда унаследует сеть зависимостей, которые они не выбирали.
Платформы, которые оптимизируют дисциплинированную композицию, как правило, развиваются медленнее, но более устойчиво. Новые системы подключаются к четким поверхностям, а не к хрупким внутренним структурам. Старые системы могут эволюционировать, не таща с собой всю экосистему.
Vanar кажется ближе к этому второму пути.
Не потому, что он консервативен, а потому, что он, похоже, предполагает, что большая часть реальной ценности будет поступать от долгоживущих систем, а не от хитроумных единичных решений. И долгоживущие системы должны иметь возможность изменяться, не вызывая цепных реакций.
Мне интересно, как это переосмысляет значение самой композиции.
Это перестает быть "всё может подключаться ко всему".
Это становится "вещи могут подключаться так, чтобы не делать будущие изменения пугающими".
Это более тихое обещание. Но это более операционное.
В реальном мире инфраструктура не терпит неудачу, потому что не может подключиться. Она терпит неудачу, потому что не может безопасно эволюционировать. Чем теснее и более неявные связи, тем сложнее становится эволюция.
Выборы дизайна Vanar предполагают, что он пытается оставить эту дверь открытой.
Не ограничивая креативность.
Но предоставляя креативности более безопасные рамки для работы.
Со временем такой вид сдержанности накапливается. Системы становятся легче для понимания. Зависимости становятся проще для аудита. Изменения становятся легче для внедрения. И экосистема становится менее хрупкой, даже по мере усложнения.
Это не то, что отображается в метриках запуска.
Это проявляется спустя годы, когда платформа продолжает изменяться, а не замораживается на месте из-за собственного успеха.
Vanar, похоже, не ставит на бесконечную связь.
Похоже, он ставит на связь, которая может пережить изменения.
А в инфраструктуре это обычно разница между тем, что расширяется, — и тем, что выдерживает.