Глава 12: Техническая архитектура

12.1 Обзор архитектуры

┌─────────────────────────────────────────────┐
│  Прикладной уровень (DApp, интерфейс Fay,   │
│  UI управления)                             │
├─────────────────────────────────────────────┤
│  Уровень 2: ZK Rollup (Высокочастотная      │
│  обработка транзакций)                       │
│  - Записи вкладов, обновления близости,      │
│    повседневные взаимодействия               │
├─────────────────────────────────────────────┤
│  Уровень 1: Выделенная цепь на Substrate     │
│  (Расчёты и Консенсус)                       │
│  - Привязка корня состояния, управление      │
│    идентичностью, голосование по управлению  │
├─────────────────────────────────────────────┤
│  Уровень идентичности: DID + PKI + ZKP       │
└─────────────────────────────────────────────┘

12.2 Сравнение выбора технологий

В ходе обсуждения были оценены несколько подходов:

Подход	Преимущества	Недостатки	Заключение
Основная сеть Ethereum	Зрелая экосистема, высокая безопасность	Высокие комиссии за газ, низкий TPS (15–30)	Не подходит для высокочастотной записи в масштабе населения
Ethereum L2	Сниженные комиссии	По-прежнему ограничен экосистемой Ethereum	Альтернатива
DAG (IOTA/Nano)	Высокая пропускная способность, без комиссий	Слабая безопасность консенсуса	Недостаточная безопасность
Выделенная цепь на Substrate	Полностью настраиваемая, без комиссий за газ	Требует построения собственной экосистемы	Рекомендуется

Проблема комиссий за газ

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

Проблема пропускной способности

Основная сеть Ethereum обрабатывает приблизительно 15–30 TPS. Для записей вкладов миллиардов пользователей по всему миру этой пропускной способности далеко недостаточно.

12.3 Выделенная цепь на Substrate

Почему Substrate

1. Полностью настраиваемый консенсус: проектирование алгоритма консенсуса, специально подходящего для записи вкладов
2. Без комиссий за газ: может быть спроектирована для бесплатных транзакций
3. Настраиваемые модули управления: естественно подходит для консенсуса сообщества
4. Совместимость с Polkadot: может взаимодействовать с другими цепями через релейные цепи
5. Модульность: компоновка модулей Runtime по мере необходимости

Обоснование

Уникальные требования GMC делают универсальные публичные цепи неподходящими:

• Участие всего населения = чрезвычайно высокий объём транзакций
• Микрозаписи вкладов = высокочастотные транзакции низкой стоимости
• Невозможность взимания комиссий = запись вкладов не должна становиться финансовым бременем
• Требуются пользовательские вычисления затухания и алгоритмы близости

12.4 ZK Rollup

Основная концепция

Выполнение вне цепи, верификация в цепи:

• Ежедневные записи вкладов обрабатываются на высокой скорости на L2, без комиссий и с высокой пропускной способностью
• Доказательства с нулевым разглашением пакетных записей периодически отправляются на L1
• L1 хранит только сжатые корни состояния

ZK Rollup vs. Optimistic Rollup

Характеристика	ZK Rollup	Optimistic Rollup
Метод верификации	Доказательства с нулевым разглашением (математическая гарантия)	Доказательства мошенничества (период оспаривания)
Время подтверждения	Быстрое	Медленное (обычно 7 дней)
Безопасность	Математическая гарантия	Зависит от честных валидаторов
Вычислительные затраты	Высокие	Низкие

Выбор: ZK Rollup — репутационная система требует быстрого подтверждения и математически гарантированной безопасности.

Разделение ответственности

• Обработка L2: создание записей вкладов, вычисление MeriToken в реальном времени, обновления близости
• Привязка L1: корни состояния, регистрация/изменение идентичности, результаты голосования по управлению, записи штрафов

12.5 Хранение данных

В цепи (L1): Реестр идентичностей, корни состояния, записи управления, записи штрафов
Rollup (L2): Балансы и партии MeriToken, близость, записи вкладов
Вне цепи (IPFS и т.д.): Детали взаимодействий, доказательства вкладов, большие файлы

12.6 Механизм консенсуса

• Допуск валидаторов: требуется определённое количество MeriToken (репутационный залог)
• Стимулы для валидации: работа по валидации сама по себе является вкладом и может приносить Merit
• Консенсус L1: GRANDPA/BABE (стандарты Substrate)
• Консенсус L2: облегчённый BFT

12.7 Оценки производительности

При допущении 1 миллиарда пользователей, каждый из которых генерирует 5 записей в день:

• Ежедневный объём транзакций: 5 миллиардов записей
• Требование TPS: ~58 000
• Необходимо: несколько параллельных экземпляров Rollup (шардинг), эффективная генерация доказательств, распределённые узлы L2

12.8 Заметки к обсуждению

Ключевые решения в технической архитектуре:

• Выделенная цепь, а не универсальная публичная цепь: требования GMC слишком специфичны
• ZK Rollup, а не Optimistic: требуется быстрое подтверждение и математические гарантии
• Многоуровневое хранение: баланс между безопасностью и масштабируемостью
• Производительность — главная проблема: масштаб участия всего населения беспрецедентен

Это концепция архитектуры на стадии дискуссионного проекта; фактическая реализация потребует корректировки в зависимости от технологического развития