GERM и MOVE: единица передачи описания

Глава 3. GERM и MOVE: единица передачи описания

GERM как контейнер · Биологическое семя · MOVE как ассет или компонент · ROOT-репозиторий и D-компоненты

3. 1. GERM как контейнер

Описание организма само по себе не разворачивается в работающую сеть. MOVE — это вектор в пространстве онтогенеза, статичная структура данных. Чтобы он стал работающей сетью, нужен исполнитель — программа, способная читать MOVE и выполнять процедуры RTR0. И этот исполнитель должен быть приложен к описанию заранее, иначе развёртка не запустится.

В архитектуре Гативус решение этой задачи — GERM (Gativus Embryonic Resource Module). GERM есть контейнер, объединяющий описание организма (MOVE) и минимальную операционную сеть, способную это описание исполнить (OPNG).

a) Состав GERM

GERM состоит из двух обязательных частей.

Первая часть — MOVE, шестнадцатимерный вектор описания организма в пространстве онтогенеза. Все шестнадцать координат, соответствующих диаграммам MOLD, упаковываются в единое представление. Шесть опорных диаграмм (CLSS, COMP, COMM, ACTD, SPCE, RSRC) обычно заполнены полностью; десять резервных могут быть пустыми или содержать частичную информацию. Полнота заполнения определяется сложностью описываемого организма — для простого функционального органа достаточно нескольких диаграмм, для полной сети SRNT — всех.

Вторая часть — OPNG (OPerational Network of Genesis), операционная сеть генезиса. Это минимально необходимый исполнитель, способный читать MOVE и запускать RTR0. OPNG не реализует полную функциональность будущего организма; она реализует только процедуры морфогенеза: парсинг MOVE, нейрогенез, синаптогенез, координацию фаз развёртки, переход к функционированию. После завершения морфогенеза OPNG трансформируется в OPN — операционную сеть собственно функционирования организма. Эта трансформация подробно рассматривается в Главе 4.

b) Самодостаточность GERM

Принципиальное свойство GERM — самодостаточность. Размещение GERM в любой среде с достаточными ресурсами AVEC запускает автономный процесс развёртки без необходимости внешнего управления. GERM не нуждается в координирующей программе, в подключении к серверу управления, в директивах от оператора. Описание и исполнитель внутри GERM достаточны, чтобы начать и завершить морфогенез.

Это свойство выводится из самой архитектуры. MOVE содержит полное описание того, что должно быть построено. OPNG содержит полную процедуру построения. Внешний доступ требуется только к ROOT-репозиторию для получения D-компонентов — и этот доступ опосредован стандартными механизмами сети, не требующими специального протокола.

3. 2. Аналогия с биологическим семенем

Конструкция GERM воспроизводит структуру биологического семени. Аналогия точная и заслуживает подробного разбора, потому что в ней зафиксированы существенные архитектурные решения.

a) Семя, не яйцеклетка

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

GERM по своей конструкции соответствует семени, не яйцеклетке. MOVE содержит полное описание организма; OPNG содержит полный аппарат развёртки. Никакого «оплодотворения» от внешнего источника не требуется. GERM, размещённый на GATE с достаточным AVEC, самостоятельно запускает герминацию.

Это решение не случайное. Архитектура с обязательным внешним вкладом потребовала бы координирующего узла, через который проходят все запросы на создание организмов. Такой узел стал бы единой точкой отказа и узким местом в масштабировании. Самодостаточность GERM устраняет эту проблему: герминация может происходить параллельно в любом количестве GATE, без общего координатора.

b) Среда вместо команд

Семя не получает указаний извне о том, что делать. Оно получает условия — почву, влагу, температуру, свет. Решение о начале прорастания принимает само семя на основании анализа условий: достаточны ли они для развёртки. Если условия недостаточны, семя остаётся в покое — потенциально на годы или десятилетия.

GERM работает аналогично. Размещение GERM на платформе не означает немедленного запуска герминации. OPNG анализирует доступный AVEC: достаточно ли его для развёртки хотя бы минимального жизнеспособного организма по данному MOVE. Если ресурсов хватает — герминация начинается. Если нет — GERM остаётся неактивным, ожидая увеличения квот или перемещения на другую платформу.

Это означает, что GERM может долго храниться в неактивном состоянии. В репозитории, на резервном носителе, в архиве — где угодно, где сохранность данных обеспечена. Активация происходит только при размещении в подходящих условиях. Аналогия с семенем точна и в этом отношении.

c) Результат развёртки

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

GERM при герминации даёт сеть, структурно соответствующую MOVE, но индивидуальную в деталях. Узлы получают новые UNON — не те, что были у узлов исходной свёрнутой сети. Связи SYGA устанавливаются эмерджентно через автономный поиск партнёров и не воспроизводят точно ту топологию, из которой MOVE был получен. Начальные состояния V-секций формируются заново. Результат — новый экземпляр, не копия.

Это согласуется с общим свойством обратной трансформации: RTR# даёт новую реализацию, не восстанавливает оригинал. В случае GTR0 это означает, что один и тот же MOVE, развёрнутый дважды, даёт двух разных особей одного вида — с одинаковой архитектурой, но разными траекториями жизни.

3. 3. Развилка: статус MOVE в архитектуре сети

До сих пор MOVE рассматривался как абстрактная единица — вектор описания, который тем или иным способом передаётся от одного узла к другому. Однако для конкретной инженерной реализации необходимо ответить на вопрос: чем именно является MOVE как объект в сети Гативус? Существует ли он как самостоятельная сущность, или он является частью какого-то узла? Передаётся ли он через стандартные механизмы сети, или требует специального протокола?

Этот вопрос имеет два прямых ответа и один синтетический. Каждый ответ соответствует определённому архитектурному решению с собственными следствиями.

a) Вариант А: MOVE как компонент узла

В этом варианте MOVE существует как M-компонент в M-секции конкретного узла NDDI. M-секция (см. GNET, Глава 3) — это секция узла, хранящая онтогенетическую информацию: описание самого узла, его класс, шаблоны соединителей, ссылки на D-компоненты. MOVE как M-компонент является естественным расширением этой роли: тот же узел, который держит описание собственной структуры, может держать описание целого организма для последующей развёртки.

Передача MOVE между узлами в этом варианте осуществляется через m-отношение — типизированную связь между M-компонентами двух узлов, передающую онтогенетическую информацию. M-отношения работают по тем же протоколам, что и v- и d-отношения, и не требуют специального механизма ассетного учёта.

Биологическая аналогия для этого варианта — точная. ДНК не существует как самостоятельная отчуждаемая сущность с глобальным учётом. Она существует внутри конкретной клетки, как часть её ядра, и при репродукции копируется в ядро потомка. Никакого реестра ДНК не существует, никакого учёта количества копий не ведётся, передача происходит локально между родительской и дочерней клетками.

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

b) Вариант B: MOVE как цифровой ассет

В этом варианте MOVE существует как GATN-ассет в распределённом реестре сети (см. GNET, Глава 4). GATN-ассет имеет уникальный 64-битный идентификатор, регистрируется при создании, передаётся между узлами по протоколу ассетного обмена через нотариальное заверение, и подчиняется иерархии эмитентов ROOT → LRAI → собственник.

Передача MOVE между узлами в этом варианте — это передача ассета. Узел-эмитент создаёт MOVE как новый ассет в реестре, регистрирует его, делегирует право владения узлу-получателю через стандартные четыре варианта передачи (см. GNET, Глава 4, раздел 4.10). После передачи MOVE становится собственностью получателя и может быть использован для запуска герминации.

У этого варианта есть существенные преимущества для инженерной системы. Каждый MOVE имеет уникальный идентификатор, что упрощает учёт версий и трассировку происхождения. Передача MOVE — стандартная транзакция, обрабатываемая существующей инфраструктурой ассетного учёта без специальных протоколов. Цепочка подписей от ROOT прослеживается для каждого MOVE, что обеспечивает защиту от подмены и подделки описаний. Смарт-контракты (см. GNET, Глава 4, раздел 4.13) могут привязываться к MOVE как к ассету, регулируя условия использования.

Биологическая аналогия для этого варианта менее прямая, но всё же существует. Сертифицированные сорта в сельскохозяйственной торговле — это семена, имеющие учётную идентичность: каждый сорт зарегистрирован, его распространение контролируется, передача между производителями документируется. Природное семя при этом остаётся физическим объектом, но получает дополнительный юридический статус как объект учёта.

c) Вариант С: MOVE двойной природы

Третий вариант — синтетический. Он принимает оба предыдущих как одновременно действующие, не как взаимоисключающие. MOVE существует и как M-компонент в узле, и как GATN-ассет в реестре. Это две онтологические проекции одной сущности, аналогичные двум проекциям узла нервной ткани (как клетка и как информационный узел) в Главе 1 GNSS.

Внутри узла MOVE живёт как M-компонент: используется при морфогенезе, доступен через m-отношения, является частью онтогенетического пространства данного организма. В реестре MOVE существует как ассет: имеет уникальный идентификатор, прослеживается его происхождение, регулируется его передача между владельцами.

Эти две роли не противоречат друг другу. M-компонент в узле — это физическая локализация описания, его конкретное место хранения и использования. Ассет в реестре — это юридический статус того же описания как объекта учёта. Один и тот же MOVE может одновременно находиться в M-секции конкретного узла и быть зарегистрирован в реестре как ассет данного типа.

Биологическая параллель здесь — сертифицированный сорт семян. Конкретное физическое семя сорта существует в одном экземпляре, в конкретном месте, физически содержит ДНК этого сорта. Одновременно сорт как юридическая сущность зарегистрирован в реестрах селекционных достижений, имеет код, имеет правообладателя. Физическое семя и юридический сорт — два аспекта одной реальности.

3. 4. Аргументы за каждый вариант

Разбор аргументов проводится по нескольким критериям, существенным для инженерной реализации Гативус.

a) Простота архитектуры

Вариант A — самый простой. MOVE как компонент использует существующие механизмы M-секции, не вводит новых сущностей, не требует ассетной инфраструктуры для базового сценария морфогенеза. Простой случай — запуск герминации одного организма из одного MOVE на одной платформе — реализуется минимальными средствами.

Вариант B усложняет архитектуру: каждый MOVE должен быть зарегистрирован в реестре, должен иметь идентификатор, цепочку подписей, нотариальное сопровождение при передаче. Для простых сценариев это избыточно.

Вариант C добавляет дополнительный слой к B, но не требует обязательного использования ассетной инфраструктуры в простых случаях: MOVE может быть только M-компонентом, не получая ассетного двойника, если последний не нужен. Ассет создаётся только там, где требуется учёт.

b) Биологическая точность

Вариант A наиболее точно воспроизводит биологическую картину. ДНК существует только внутри клеток; никакого глобального реестра ДНК нет; передача от родителя к потомку локальна и не требует учётных операций.

Вариант B существенно отклоняется от биологии: глобальный реестр семян, обязательная регистрация — это не природный, а индустриальный паттерн.

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

c) Защита от подмены и подделки

Вариант A не предоставляет встроенных средств защиты. M-компонент может быть подменён в M-секции узла без очевидных следов. Полагаться приходится на общие средства целостности данных и контроля доступа.

Вариант B обеспечивает строгую защиту: цепочка подписей от ROOT гарантирует подлинность, нотариальное заверение при передаче исключает несанкционированную передачу, иммунная система сети (см. GNET, Глава 4, раздел 4.7) автоматически отторгает MOVE с повреждённой или отсутствующей цепочкой.

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

d) Масштабируемость

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

Вариант B имеет потенциальное узкое место в реестре. Архитектура распределённого реестра, описанная в GNET (дерево ROOT → LRAI → собственник, см. раздел 4.8), решает эту проблему: реестр не централизован, операции локальны для подавляющего большинства случаев. Однако обязательная регистрация каждого MOVE остаётся накладным расходом.

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

e) Поддержка смарт-контрактов

Вариант A не поддерживает смарт-контракты, привязанные к MOVE. Если MOVE — только локальный M-компонент, к нему нечего привязать как к идентифицируемой стороне контракта.

Вариант B полностью поддерживает: MOVE как ассет может быть стороной любого смарт-контракта, описанного на уровне MAP9 как нарратив с привязкой к G-ассету (см. GNET, Глава 4, раздел 4.13).

Вариант C поддерживает выборочно: MOVE с ассетным двойником может быть привязан к смарт-контракту, MOVE только как M-компонент — нет. Это даёт инженеру выбор: создавать ассет только для тех MOVE, которые подлежат контрактному регулированию.

3. 5. Решение: MOVE двойной природы

Из приведённых аргументов следует выбор варианта C — MOVE двойной природы. Это решение основано на следующих соображениях.

Вариант A слишком ограничен. Он работает для замкнутых сценариев — таких, где все MOVE циркулируют в пределах одной доверенной сети без необходимости в учёте версий, защите от подделки или контрактном регулировании. Но Гативус не предполагает замкнутости. Сеть Гативус — глобальная инфраструктура, в которой описания организмов могут передаваться между разными платформами, разными юрисдикциями, разными владельцами. Без ассетной инфраструктуры эти сценарии становятся проблематичными.

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

Вариант C сохраняет преимущества обоих вариантов и избегает их недостатков. Базовый режим работы — MOVE как M-компонент: простой, локальный, биологически точный. Расширенный режим — MOVE с ассетным двойником: учитываемый, защищённый, регулируемый. Выбор режима — архитектурное решение для конкретного сценария, а не обязательное системное требование.

a) Когда создавать ассетного двойника

Решение о создании ассетного двойника для конкретного MOVE принимается по нескольким критериям.

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

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

Создавать ассета не нужно, если MOVE используется локально на одной платформе или внутри доверенной группы разработки, имеет короткий жизненный цикл (тестовые, промежуточные версии), или не имеет специфических требований к защите.

b) Соотношение между M-компонентом и ассетом

Когда ассетный двойник создаётся, между ним и M-компонентом устанавливается определённое соотношение. Ассет регистрирует идентичность MOVE — его уникальный идентификатор, эмитента, цепочку подписей. M-компонент содержит содержание MOVE — собственно 16-мерный вектор с заполненными координатами диаграмм.

Идентификатор ассета записывается в M-компонент как ссылка. M-компонент содержит и собственное содержимое, и идентификатор соответствующего ассета. При передаче M-компонента между узлами идентификатор сохраняется — это позволяет получателю проверить происхождение MOVE через обращение к реестру.

Содержание MOVE может быть целиком в M-компоненте (стандартный случай для рабочих копий), либо только ссылкой на ассетную копию в реестре (для архивных случаев, когда содержание извлекается из реестра по мере необходимости). Это даёт гибкость в управлении хранением: часто используемые MOVE кешируются локально как M-компоненты, редко используемые могут существовать только как ассеты в реестре.

3. 6. Распространение D-компонентов через ROOT

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

D-компоненты являются результатом эволюционного обучения GTR0 (см. Главу 1, раздел 1.6). Каждый D-компонент — это скомпилированный объектный код в формате ELF, реализующий поведение определённого типа узла: его реакции на входящие отношения, его внутреннюю логику, его взаимодействие с другими секциями. D-компонент — обученные веса морфотрансформации, упакованные в исполняемую форму.

a) ROOT как репозиторий генов

Все D-компоненты Гативус хранятся в ROOT — корневом узле сети, исполняющем функцию репозитория. ROOT, переименованный из GLAI, играет в архитектуре Гативус несколько ролей. Как корневой эмитент ассетов, он определяет пространство согласованности CNST₀ и эмитирует системные ассеты (см. GNET, Глава 4). Как репозиторий, он содержит библиотеку D-компонентов, доступных для использования при морфогенезе любого организма.

Биологическая аналогия — пул универсальных генов, разделяемых между разными видами. Многие гены клеточной механики, метаболических путей, базовых сигнальных систем консервативны и присутствуют у организмов очень разной сложности. ROOT-репозиторий играет аналогичную роль для Гативус: содержит универсальные строительные блоки, используемые при морфогенезе разных организмов.

b) D-отношения и доступ к коду

Связь между классом узла в MOVE и соответствующим D-компонентом в ROOT реализуется через d-отношение — типизированную связь, передающую исполняемый код. При морфогенезе ANOD устанавливает d-отношение от каждого создаваемого узла-класса к нужному D-компоненту в ROOT. Через это отношение код передаётся в локальный кеш платформы GATE и используется при инстанцировании конкретных узлов данного класса.

Принципиальное архитектурное следствие: один D-компонент в ROOT обслуживает многие классы во многих GATE через сеть d-отношений. Когда GATE создаёт узлы определённого класса, ему не нужно содержать собственную копию кода — достаточно d-отношения к ROOT. Локальный кеш используется для оптимизации, но истина — в ROOT.

Это даёт важное следствие для эволюции системы. Обновление D-компонента в ROOT автоматически распространяется на все узлы, имеющие к нему d-отношение — при следующей перелинковке (см. GNET, Глава 3, раздел 3.2). Эволюция Гативус как системы происходит через изменения в ROOT-репозитории; каждое изменение постепенно реализуется во всех зависимых организмах через стандартный механизм перелинковки.

c) D-компоненты как ассеты

D-компоненты, в отличие от MOVE, однозначно являются ассетами. Это следует из их природы: D-компонент — результат значительной разработки (или эволюционного обучения, в биологическом случае), имеет определённого автора (или линию наследования), подлежит версионированию, должен быть защищён от подделки. Все эти соображения указывают на необходимость учётной идентичности.

Каждый D-компонент в ROOT-репозитории зарегистрирован как GATN-ассет (см. GNET, Глава 4, раздел 4.9). Идентификатор содержит: номер GATE, на котором эмитирован D-компонент (для базовых системных компонентов это сам ROOT), суффикс UNON эмитента, префикс типа. Цепочка подписей прослеживается до ROOT для всех системных D-компонентов.

Передача D-компонента — стандартная транзакция передачи ассета. Когда GATE загружает D-компонент в локальный кеш, это переоформление d-отношения с регистрацией в реестре (см. GNET, Глава 4, раздел 4.10). Когда узел получает новый D-компонент через d-отношение от другого узла, цепочка подписей проверяется, и компонент принимается только при подтверждении подлинности.

d) Соотношение MOVE и D-компонентов

Различие в статусе MOVE и D-компонентов отражает различие их функций.

MOVE описывает конкретный организм — его уникальную комбинацию классов, пропорций и связей. Конкретный MOVE может быть рабочим, временным, тестовым; может циркулировать локально без учёта; может быть массово копируемым между узлами одного типа. Двойная природа MOVE даёт гибкость в выборе режима учёта.

D-компонент описывает универсальный строительный блок — тип узла, используемый во многих организмах. D-компонент разрабатывается долго, проверяется тщательно, обновляется редко и осторожно. Каждое его изменение влияет на множество зависимых организмов. Для D-компонента ассетная природа — не опция, а необходимость.

Эта асимметрия — между MOVE и D-компонентами — естественная и сохраняется в архитектуре Гативус. MOVE — индивидуальное описание, D-компонент — универсальный код. Соответственно различаются и режимы их учёта в сети.

3. 7. Переход к Главе 4

Настоящая глава определила GERM как контейнер семени, включающий MOVE и OPNG. Самодостаточность GERM, аналогичная самодостаточности биологического семени, обеспечивает автономный запуск морфогенеза при размещении в среде с достаточным AVEC.

Решён вопрос о статусе MOVE как объекта в сети Гативус. Принятое решение — двойная природа: MOVE существует и как M-компонент в узле, и как GATN-ассет в реестре. Это даёт гибкость в выборе режима учёта в зависимости от сценария использования.

Установлена роль ROOT как корневого репозитория D-компонентов и описан механизм их распространения через d-отношения. D-компоненты, в отличие от MOVE, однозначно являются ассетами с полной цепочкой подписей.

Открытым остаётся вопрос о процедуре герминации: как именно GERM, размещённый на платформе, разворачивается в работающую сеть? Какие шаги включает RTR0, в каком порядке они исполняются, как координируются между собой? Этот вопрос — предмет следующей главы. Глава 4 описывает атомарные единицы морфогенеза (MORN, MLOM), процедуры порождения узлов (NRGN) и установления связей (SYGD и SYGA), параллельность фаз и трансформацию OPNG → OPN.