DeflationChain YellowPaper

0. Abstract

DeflationChain представляет собой блокчейн первого уровня (Layer-1) нового поколения, разработанный с фундаментальной интеграцией дефляционных механизмов непосредственно в протокол консенсуса. В отличие от существующих блокчейн-платформ, где дефляция реализуется исключительно на уровне смарт-контрактов или токеномики, DeflationChain внедряет концепцию Proof-of-Deflation (PoD) — инновационный механизм консенсуса, в котором вес валидатора определяется не только количеством застейканных токенов, но и продолжительностью стейкинга, а также применением дефляционных коэффициентов к балансам участников сети.

Архитектура DeflationChain основывается на семи ключевых уровнях: уровень данных (Data Layer), сетевой уровень (Network Layer), уровень консенсуса (Consensus Layer), уровень конфиденциальных вычислений (Confidential Compute Layer), торговое ядро (Trading Core Layer), уровень исполнения (Execution Layer) и уровень приложений (Application Layer). Данная многоуровневая архитектура обеспечивает модульность системы и позволяет независимо оптимизировать каждый компонент без нарушения целостности протокола.

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

DeflationChain интегрирует централизованный ордер-бук с производительностью до 200 000 операций в секунду и латентностью менее 1 миллисекунды, при этом сохраняя децентрализованное хранение активов и прозрачный settlement на блокчейне. Торговое ядро значительно улучшает концепции HyperLiquid, устраняя выявленные уязвимости (инцидент JELLY) и добавляя уникальные дефляционные механизмы: часть торговых комиссий сжигается, валидаторы получают вознаграждение из существующих токенов (не эмиссии), а система Vault интегрирована с PoD-консенсусом для повышенной безопасности.

Уровень конфиденциальных вычислений, реализованный с использованием технологий Intel TDX (Trust Domain Extensions) и SGX (Software Guard Extensions), обеспечивает возможность приватных AI-вычислений непосредственно на инфраструктуре блокчейна. DeflationChain в части децентрализованного ИИ одерживает вверх над архитектурой Cocoon, устраняя её главный недостаток — централизацию прокси-серверов: в нашей реализации proxy-узлы являются валидаторами сети с PoD-стейком, что обеспечивает экономическую мотивацию честного поведения и отсутствие единой точки отказа.

Блокчейн сохраняет полную совместимость с Ethereum Virtual Machine (EVM), что позволяет разработчикам использовать существующие инструменты, такие как Solidity, Hardhat и Foundry, без необходимости изучения новых технологий. При этом DeflationChain расширяет функциональность EVM специализированными precompile-контрактами для работы с дефляционной логикой, стейкингом и торговыми операциями.

Экономическая модель DeflationChain основывается на механизме ежедневного смарт-сжигания с удвоением: через сутки сжигается 1% от баланса, через двое суток — 2% от остатка, затем 4%, 8%, 16%, 32%, 64% и 100% на восьмой день. Если токены не переведены в стейкинг, они полностью обесцениваются за 8 дней. Система смарт-комиссий распределяет транзакционные сборы между сжиганием, дивидендным пулом, техническим пулом и маркетинговым фондом, создавая устойчивый дефляционный цикл, в котором активное использование сети усиливает дефляцию и, как следствие, потенциальный рост стоимости токена DEF.

Настоящий документ представляет техническую спецификацию всех компонентов DeflationChain, включая математические модели консенсуса, криптографические примитивы, сетевые протоколы и механизмы безопасности. Документ предназначен для разработчиков, исследователей, аудиторов и всех заинтересованных сторон, стремящихся к глубокому пониманию технической архитектуры платформы.

1. Введение

1.1. Мотивация создания DeflationChain

Современная криптовалютная индустрия сталкивается с фундаментальным противоречием между декларируемыми целями децентрализованных финансов и фактической реализацией большинства блокчейн-протоколов. Биткоин, несмотря на ограниченную эмиссию в 21 миллион монет, не обладает активными дефляционными механизмами — его «дефляционность» ограничивается случайной потерей доступа к кошелькам и постепенным замедлением эмиссии через халвинги. Ethereum, Solana, Tron, Avalanche и подавляющее большинство других блокчейн-платформ первого уровня используют инфляционные модели эмиссии для оплаты вознаграждений валидаторам, что фундаментально противоречит концепции «цифрового золота» и сохранения стоимости.

DeflationCoin возник как ответ на эту проблему в форме токена на Binance Smart Chain (BSC), реализующего продвинутые дефляционные механизмы на уровне смарт-контракта. Однако функционирование в рамках чужой инфраструктуры накладывает существенные ограничения: невозможность интеграции дефляционной логики в механизм консенсуса, зависимость от комиссий и пропускной способности базового блокчейна, а также отсутствие контроля над развитием платформы. DeflationChain представляет собой логическое развитие проекта — создание собственного блокчейна первого уровня с нативной интеграцией дефляционных принципов на всех уровнях архитектуры.

Ключевая мотивация создания DeflationChain заключается в построении первого в истории истинно дефляционного блокчейна, где дефляция не является надстройкой над инфляционным базовым слоем, а представляет собой фундаментальное свойство самого протокола. В традиционных Proof-of-Stake системах валидаторы получают вознаграждение в форме новых токенов, что создаёт постоянное инфляционное давление. DeflationChain революционизирует этот подход, вводя концепцию Proof-of-Deflation, где вознаграждения валидаторов формируются не из эмиссии, а из распределения существующих токенов — дивидендного пула, торговых комиссий и части газовых сборов.

Вторым критическим фактором является потребность рынка в высокопроизводительной торговой инфраструктуре, сочетающей скорость централизованных бирж с безопасностью и прозрачностью децентрализованных протоколов. Успех HyperLiquid продемонстрировал жизнеспособность гибридной модели с централизованным ордер-буком и децентрализованным settlement. DeflationChain значительно улучшает этот подход, добавляя интегрированную дефляционную экономику и встроенные AI-сервисы, что создаёт синергетический эффект: активная торговля генерирует комиссии, часть которых сжигается, усиливая дефляцию и потенциально увеличивая стоимость токена, что привлекает новых пользователей и увеличивает торговую активность.

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

Наконец, DeflationChain отвечает на растущий спрос на интеграцию искусственного интеллекта в блокчейн-инфраструктуру. В отличие от проектов типа Cocoon, фокусирующихся исключительно на AI-вычислениях, DeflationChain создаёт комплексную экосистему, где AI-сервисы интегрированы с торговой платформой, дефляционной экономикой и децентрализованным управлением. Использование AI для анализа рынков, управления рисками и автоматизации торговых стратегий создаёт дополнительный спрос на токен DEF, поскольку оплата AI-сервисов производится в нативном токене с применением дефляционных комиссий.

1.2. Проблемы существующих L1 решений

1.2.1. Ethereum

Ethereum, несмотря на статус второй по капитализации криптовалюты и доминирующей платформы для смарт-контрактов, страдает от ряда фундаментальных проблем, которые DeflationChain стремится решить. Главной проблемой остаётся масштабируемость: даже после перехода на Proof-of-Stake и внедрения EIP-1559 с механизмом сжигания базовой комиссии, Ethereum обрабатывает лишь 15-30 транзакций в секунду, что катастрофически недостаточно для глобальной финансовой инфраструктуры. Комиссии за транзакции в периоды высокой нагрузки достигают десятков и сотен долларов, делая платформу недоступной для массового пользователя.

Механизм сжигания EIP-1559, хотя и создаёт элементы дефляции, не является полноценной дефляционной моделью. Эмиссия новых ETH для вознаграждения валидаторов продолжается, и в периоды низкой сетевой активности инфляция превышает сжигание. Более того, дефляционный эффект EIP-1559 зависит от спроса на блокчейн-пространство, создавая парадоксальную ситуацию, при которой экономическая привлекательность актива возрастает только в условиях перегруженности и высоких комиссий.

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

1.2.2. Solana

Solana позиционируется как высокопроизводительная альтернатива Ethereum, декларируя пропускную способность до 65 000 транзакций в секунду. Однако практика продемонстрировала существенные проблемы с надёжностью: сеть неоднократно испытывала полные остановки, длившиеся от нескольких часов до суток. Причины сбоев варьировались от атак на сеть до ошибок в коде и перегрузки в периоды высокой активности.

Более фундаментальной проблемой Solana является централизация валидаторов. Требования к аппаратному обеспечению для запуска полноценной ноды Solana исключительно высоки: рекомендуются 256 ГБ оперативной памяти, 12-ядерный процессор и несколько терабайт NVMe-хранилища. Это приводит к концентрации валидаторов в крупных дата-центрах, преимущественно в Северной Америке и Европе. Значительная часть валидаторов размещена у одного провайдера (Hetzner), что создаёт единую точку отказа.

Токеномика Solana также является инфляционной: начальная инфляция составляла 8% годовых с постепенным снижением до целевого уровня 1.5%. Это означает постоянное размывание долей существующих держателей токенов, не участвующих в стейкинге.

1.2.3. HyperLiquid

HyperLiquid представляет собой наиболее близкий к DeflationChain проект по архитектуре торговой инфраструктуры. Платформа успешно реализовала концепцию централизованного ордер-бука с децентрализованным хранением активов, достигнув впечатляющей производительности: до 200 000 операций в секунду с латентностью менее 1 миллисекунды. Консенсус HyperBFT, основанный на протоколе HotStuff, обеспечивает финализацию блоков менее чем за секунду.

Однако HyperLiquid не обладает дефляционной экономической моделью. Токен HYPE распределяется через стандартные механизмы стейкинга без встроенного сжигания. Кроме того, платформа не ограничивает географическое распределение валидаторов, что потенциально создаёт уязвимость перед регуляторным давлением.

Инцидент с токеном JELLY в марте 2025 года выявил уязвимости в системе управления рисками HyperLiquid: манипулятивный short squeeze привёл к нереализованным убыткам протокольного vault HLP в размере 10 миллионов долларов и потребовал экстренного вмешательства команды. Этот случай подчеркнул необходимость более продуманных механизмов контроля открытого интереса и защиты от манипуляций, которые DeflationChain реализует на уровне архитектуры.

1.2.4. TON и Cocoon

The Open Network (TON), изначально разработанный командой Telegram, представляет собой технически продвинутую платформу с уникальной архитектурой шардирования. Проект Cocoon, запущенный на TON в ноябре 2025 года, демонстрирует передовой подход к интеграции AI-вычислений в блокчейн-инфраструктуру с использованием конфиденциальных вычислений (Intel TDX/SGX).

Тем не менее, ни TON, ни Cocoon не обладают дефляционной экономической моделью. Cocoon фокусируется исключительно на AI-инференсе, не предоставляя интегрированной торговой инфраструктуры. Централизация прокси-серверов Cocoon (управляемых командой проекта) также создаёт потенциальную точку отказа и контроля.

DeflationChain одерживает вверх и над техническими решения Cocoon в области конфиденциальных вычислений (TDX, SGX Seal Server, RA-TLS), и интегрирует их в комплексную экосистему с дефляционной экономикой, торговой платформой и децентрализованными прокси-узлами.

1.3. Эволюция от DEF токена на BSC

DeflationCoin (DEF) был запущен на Binance Smart Chain как экспериментальная реализация продвинутой дефляционной токеномики. Смарт-контракт DeflationCoinUpgradeable реализует несколько инновационных механизмов, которые легли в основу экономической модели DeflationChain.

Механизм BalancePortions разделяет баланс каждого пользователя на отдельные «порции», каждая из которых помечена временной меткой создания. При запросе баланса контракт вычисляет эффективную сумму с учётом дефляционного коэффициента, зависящего от возраста каждой порции. Система ежедневного сжигания применяет принцип удвоения: через сутки сжигается 1% от баланса, через двое суток — 2% от остатка, затем 4%, 8%, 16%, 32%, 64% и 100% на восьмой день. Кумулятивный эффект: после 8 дней бездействия токены полностью обесцениваются. Разница между номинальным и эффективным балансом при каждом обновлении делится пополам: 50% сжигается навсегда, 50% направляется в дивидендный пул.

Смарт-стейкинг позволяет пользователям защитить токены от ежедневного сжигания путём блокировки на срок от 1 до 12 лет. Чем дольше период стейкинга, тем выше мультипликатор для расчёта дивидендов: массив xMultipliers = [1, 2, 3, 4, 5, 6, 7, 10, 12, 14, 16, 20] определяет коэффициенты для каждого года. 12-летний стейк получает 20-кратный мультипликатор по сравнению с годовым, создавая мощный стимул для долгосрочного удержания.

Механизм «Захват внимания» (Attention Grabbing) автоматически направляет 1% от каждого стейка на срок менее 12 лет в 12-летний стейк. Это создаёт постоянный приток средств в долгосрочное хранение, усиливая дефляционный эффект и демонстрируя приверженность пользователей проекту.

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

Смарт-комиссии при каждой транзакции распределяют 5% от суммы перевода: 1% сжигается, 1% направляется в дивидендный пул, 1% — в технический пул, 2% — в маркетинговый пул. При наличии реферальной связи комиссия снижается до 4.5%: 2.25% сжигается, 2.25% направляется рефереру.

Опыт эксплуатации контракта на BSC продемонстрировал жизнеспособность модели, но также выявил ограничения: зависимость от комиссий BSC, невозможность интеграции с консенсусом базового блокчейна, ограниченные возможности расширения функциональности. DeflationChain переносит все эти механизмы на собственный блокчейн, добавляя интеграцию с консенсусом (Proof-of-Deflation), торговой платформой и AI-сервисами.

1.4. Обзор архитектурных решений

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

Уровень данных (Data Layer) отвечает за персистентное хранение состояния блокчейна, включая балансы пользователей, стейкинг-позиции, торговые позиции и состояние смарт-контрактов. Используется модифицированная Merkle Patricia Trie с дополнительными корнями для дефляционного и торгового состояния.

Сетевой уровень (Network Layer) обеспечивает peer-to-peer коммуникацию между узлами сети. Реализован на базе LibP2P с поддержкой gossip-протокола для распространения транзакций и блоков, DHT (Kademlia) для обнаружения пиров, а также Ethereum-совместимого JSON-RPC интерфейса.

Уровень консенсуса (Consensus Layer) реализует Proof-of-Deflation — гибридный механизм, объединяющий элементы Proof-of-Stake с дефляционной экономикой. Вес валидатора определяется формулой с учётом суммы стейка, продолжительности стейкинга и дефляционного коэффициента. Финализация блоков основана на HyperBFT с single-slot finality.

Уровень конфиденциальных вычислений (Confidential Compute Layer) обеспечивает приватные AI-вычисления с использованием Intel TDX для изоляции виртуальных машин и SGX для управления криптографическими ключами. Механизм RA-TLS гарантирует криптографическую верификацию вычислительных узлов.

Торговое ядро (Trading Core Layer) реализует высокопроизводительный ордер-бук с централизованным matching engine и децентрализованным settlement. Система Vault обеспечивает управление ликвидностью, ликвидации и автоделевериджинг с математически обоснованными формулами безопасности.

Уровень исполнения (Execution Layer) представляет собой EVM-совместимую виртуальную машину с расширениями в виде precompile-контрактов для дефляционной логики, стейкинга и торговых операций. Поддерживается Solidity 0.8.x и все стандартные инструменты разработки Ethereum.

Уровень приложений (Application Layer) включает децентрализованные приложения, торговые интерфейсы, AI-сервисы и интеграции с внешними системами.

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

2. Архитектура блокчейна (Многоуровневая модель)

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

2.1. Уровень консенсуса (Consensus Layer)

Уровень консенсуса является сердцем DeflationChain, обеспечивающим согласованность состояния распределённой сети узлов. DeflationChain вводит инновационный механизм Proof-of-Deflation (PoD), который расширяет традиционный Proof-of-Stake путём интеграции дефляционной экономики непосредственно в алгоритм определения веса валидаторов и процесс финализации блоков.

2.1.1. Proof-of-Deflation (PoD) — формальное определение

Proof-of-Deflation представляет собой гибридный механизм консенсуса, объединяющий принципы Proof-of-Stake с уникальной дефляционной экономической моделью DeflationChain. В традиционных PoS-системах вес валидатора определяется исключительно количеством застейканных токенов. PoD расширяет эту модель, вводя дополнительные множители, отражающие долгосрочную приверженность валидатора сети.

Определение 2.1 (Proof-of-Deflation): Механизм консенсуса, в котором право на создание и валидацию блоков распределяется пропорционально дефляционно-взвешенному стейку участников, определяемому как произведение суммы застейканных токенов, срока стейкинга в годах и дефляционного коэффициента, применяемого к незастейканным токенам.

Ключевое отличие PoD от классического PoS заключается в следующих аспектах:

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

2. Дефляционный компонент: Токены, не находящиеся в стейкинге, подвергаются ежедневному сжиганию по принципу удвоения: 1% через сутки, затем 2%, 4%, 8%, 16%, 32%, 64% и 100% на восьмой день (каждый раз от остатка). Это создаёт экономическое давление на участников сети в пользу стейкинга, увеличивая общую безопасность сети.

3. Географический фактор: Для обеспечения геополитической децентрализации вводится ограничение на одного валидатора от каждой юрисдикции. Валидаторы из «дублирующих» юрисдикций получают нулевой geo_factor и не могут участвовать в консенсусе.

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

2.1.2. Математическая модель веса валидатора

Вес валидатора V в механизме Proof-of-Deflation вычисляется по следующей формуле:

Относительный вес валидатора в сети определяется как:

Для практических расчётов в консенсусе используется целочисленная арифметика с масштабированием. Веса нормализуются к диапазону [0, 10^18], что обеспечивает достаточную точность для взвешенного голосования.

2.1.3. Формула дефляционного коэффициента

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

Принцип удвоения (Doubling Burn):

Данный подход обладает уникальными свойствами: в первые дни потери минимальны (1-2%), что даёт пользователям время на реакцию, но затем обесценение резко ускоряется, делая долгосрочное бездействие экономически нецелесообразным. После 8 дней полного бездействия токены полностью обесцениваются.

Сводная таблица кумулятивного эффекта:

День	Дневное сжигание	Сохранённая стоимость
0	0%	100%
1	1% от остатка	99%
2	2% от остатка	97%
3	4% от остатка	93%
4	8% от остатка	85%
5	16% от остатка	71%
6	32% от остатка	48%
7	64% от остатка	17%
8+	100%	0%

Разница между номинальным и эффективным балансом при каждом обновлении распределяется следующим образом:

• 50% сжигается навсегда (уменьшает totalSupply)
• 50% направляется в дивидендный пул (распределяется между стейкерами)

Данный механизм создаёт мощный экономический стимул для участия в стейкинге: токены, находящиеся в стейке, полностью защищены от ежедневного сжигания, в то время как незастейканные токены теряют 100% стоимости за 8 дней.

2.1.4. Механизм голосования и финализации блоков

DeflationChain использует модифицированный BFT-протокол для достижения консенсуса с мгновенной финализацией (single-slot finality). Процесс создания и финализации блока состоит из следующих этапов:

Этап 1: Propose (Предложение)
Лидер раунда, выбранный согласно алгоритму ротации (см. раздел 3.4), формирует блок-кандидат, включающий:

• Транзакции из mempool, отсортированные по gas price
• Торговые события из Trading Core
• AI-запросы из Confidential Compute Layer
• Заголовок блока с необходимыми корнями Merkle-деревьев

Этап 2: Prevote (Предварительное голосование)
Валидаторы получают блок-кандидат, проверяют его корректность и транслируют подписанное prevote-сообщение:

• Положительный prevote, если блок валиден
• Отрицательный prevote (nil), если блок невалиден или не получен вовремя

Этап 3: Precommit (Предварительная фиксация)
После получения prevotes от валидаторов с суммарным весом более 2/3 от общего PoD-веса, валидаторы транслируют precommit-сообщения:

PREVOTE_THRESHOLD = 2/3 × Σ W_all + 1

Этап 4: Commit (Фиксация)
Блок считается финализированным после получения precommits от валидаторов с суммарным весом более 2/3:

COMMIT_THRESHOLD = 2/3 × Σ W_all + 1

После commit блок немедленно добавляется в блокчейн и считается необратимым. В отличие от Ethereum, где финализация требует нескольких эпох (12-15 минут), DeflationChain обеспечивает финализацию в рамках одного слота (менее 1 секунды).

Обработка таймаутов:
Если лидер не предоставляет валидный блок в течение timeout-периода, инициируется переход к следующему раунду с новым лидером. Таймауты экспоненциально увеличиваются при последовательных неудачах для обеспечения eventual liveness.

2.1.5. Интеграция с DEFBFT (improved HyperBFT)

Консенсусный протокол DeflationChain DEFBFT основан на архитектуре HyperBFT, которая, в свою очередь, является оптимизированной версией протокола HotStuff. HyperBFT сокращает традиционный трёхфазный BFT-процесс до двух раундов коммуникации, аналогично протоколам Jolteon, DiemBFT и Fast HotStuff.

Ключевые оптимизации HyperBFT, адаптированные для DeflationChain:

1. Pipelining (Конвейерная обработка): Множественные блоки обрабатываются параллельно на разных стадиях консенсуса, подобно конвейеру процессора. Пока один блок находится на стадии precommit, следующий уже может быть предложен.

2. Optimistic Execution (Оптимистичное исполнение): Транзакции начинают исполняться до полной финализации блока. Если финализация проходит успешно, результаты сохраняются; при откате — отбрасываются. Это снижает эффективное время подтверждения транзакций.

3. Optimistic Responsiveness (Оптимистичная отзывчивость): Консенсус адаптируется к текущим сетевым условиям. При нормальной работе сети блоки производятся с максимальной скоростью; при сетевых задержках протокол автоматически замедляется для сохранения безопасности.

4. Linear Message Complexity: Количество сообщений для достижения консенсуса линейно зависит от числа валидаторов (O(n)), а не квадратично (O(n²)), как в классических PBFT-протоколах.

Целевые характеристики производительности:

• Теоретическая пропускная способность: 200,000+ транзакций/секунду
• Медианная латентность финализации: 0.1 секунды
• 99-й перцентиль латентности: 0.5 секунды
• Время блока: ~1 секунда

2.1.6. Byzantine Fault Tolerance в контексте PoD

DeflationChain сохраняет стандартные гарантии Byzantine Fault Tolerance: сеть остаётся безопасной и живой при наличии не более 1/3 злонамеренных или неисправных валидаторов (измеряемых по PoD-весу, а не по количеству).

Формальные гарантии безопасности:

1. Safety (Безопасность): Если два честных валидатора финализировали блоки на одной высоте, эти блоки идентичны. Гарантируется при f < n/3, где f — суммарный PoD-вес злонамеренных валидаторов, n — общий PoD-вес.

2. Liveness (Живость): При наличии 2/3+ честных валидаторов (по PoD-весу) и стабильных сетевых условиях сеть продолжает производить блоки.

Дополнительные защитные механизмы PoD:

Географическое распределение валидаторов (один на страну) обеспечивает дополнительный уровень защиты: для достижения 1/3 злонамеренного веса потребуется координация валидаторов из приблизительно 65 стран (при равномерном распределении весов). Это существенно повышает стоимость и сложность атаки по сравнению с сетями, где валидаторы сконцентрированы в нескольких юрисдикциях.

2.2. Уровень исполнения (Execution Layer)

Уровень исполнения DeflationChain представляет собой EVM-совместимую виртуальную машину, расширенную специализированными precompile-контрактами для работы с дефляционной логикой, стейкингом и торговыми операциями. Полная совместимость с Ethereum обеспечивает возможность использования существующих инструментов разработки и портирования смарт-контрактов без модификаций.

2.2.1. EVM-совместимость

DeflationChain реализует полную совместимость с Ethereum Virtual Machine на уровне Shanghai fork, включая:

Поддерживаемые opcodes:

• Все стандартные opcodes Ethereum (PUSH, POP, ADD, MUL, etc.)
• Shanghai-специфичные opcodes (PUSH0)
• Будущие EIP, совместимые с архитектурой DeflationChain

Инструменты разработки:

• Solidity: Полная поддержка версий 0.8.x с оптимизатором
• Vyper: Поддержка для разработчиков, предпочитающих Python-подобный синтаксис
• Hardhat: Интеграция для локальной разработки, тестирования и деплоя
• Foundry: Поддержка быстрого тестирования с использованием forge
• Remix IDE: Совместимость для онлайн-разработки
• OpenZeppelin: Стандартные библиотеки безопасности работают без модификаций

Адресное пространство:

• Стандартные 20-байтовые адреса Ethereum
• Одинаковый derivation path для кошельков
• Совместимость с существующими кошельками (MetaMask, WalletConnect)

2.2.2. Газовая модель и дефляционные комиссии

DeflationChain использует модифицированную газовую модель, совместимую с EIP-1559, но с уникальным механизмом распределения комиссий, интегрированным с дефляционной экономикой.

Расчёт комиссии:

Распределение base_fee:

Распределение priority_fee:

Priority_fee полностью направляется валидатору блока

Данное распределение создаёт следующие эффекты:

• Постоянное дефляционное давление через сжигание 20% комиссий
• Дополнительный доход для стейкеров через дивидендный пул
• Устойчивое финансирование развития через treasury
• Экономические стимулы для валидаторов без инфляционной эмиссии

2.2.3. Состояние (State) и Merkle Patricia Trie

DeflationChain использует модифицированную Merkle Patricia Trie (MPT) для хранения состояния, расширенную дополнительными структурами для дефляционной и торговой логики.

Структура состояния:

Оптимизации хранения:

• State pruning: Удаление исторических состояний старше определённого периода для полных нод
• Snap sync: Быстрая синхронизация новых нод через snapshot состояния
• Flat storage: Оптимизированный доступ к часто используемым данным

2.2.4. Транзакции и их жизненный цикл

DeflationChain поддерживает несколько типов транзакций, расширяющих стандартный набор Ethereum:

Тип 0: Legacy Transaction
Стандартные Ethereum-транзакции для обратной совместимости.

Тип 2: EIP-1559 Transaction
Транзакции с динамической комиссией (base_fee + priority_fee).

Тип 100: Staking Transaction (NEW)
Специализированные транзакции для операций стейкинга:

• stake(amount, years, referral) — создание стейкинг-позиции
• extendStake(index, newYears) — продление срока стейкинга
• claimDividends(index, amount) — получение дивидендов
• smoothUnlock(user, index) — плавный разлок после окончания срока

Тип 101: Trading Transaction (NEW)
Транзакции для торговых операций:

• placeOrder(market, side, price, size, leverage) — размещение ордера
• cancelOrder(orderId) — отмена ордера
• depositToVault(vaultId, amount) — депозит в vault
• withdrawFromVault(vaultId, amount) — вывод из vault

Тип 102: AI Request Transaction (NEW)
Транзакции для AI-сервисов:

• submitInference(modelId, input, paymentChannel) — запрос AI-инференса
• registerWorker(attestation, stake) — регистрация compute-провайдера
• reportMalicious(workerId, evidence) — сообщение о нарушении

Жизненный цикл транзакции:

1. Создание и подписание клиентом
2. Отправка в mempool через RPC
3. Валидация и распространение через gossip
4. Включение в блок лидером
5. Исполнение на EVM
6. Финализация в составе блока
7. Генерация receipt с результатами

2.2.5. Precompiles для дефляционной логики

DeflationChain расширяет стандартный набор precompile-контрактов Ethereum специализированными контрактами для эффективной работы с дефляционной логикой:

Address 0x0000…0100: DeflationMultiplier

function getDeflationMultiplier(uint256 timestamp) external view returns (uint256)

Возвращает дефляционный множитель для указанной временной метки с точностью 18 десятичных знаков.

Address 0x0000…0101: PoDWeight

function calculatePoDWeight(address account) external view returns (uint256)

Вычисляет текущий PoD-вес указанного аккаунта для использования в governance и консенсусе.

Address 0x0000…0102: StakingPositions

function getStakingPositions(address account) external view returns (StakePosition[] memory)

Возвращает массив всех стейкинг-позиций аккаунта.

Address 0x0000…0103: EffectiveBalance

function getEffectiveBalance(address account) external view returns (uint256)

Вычисляет эффективный баланс с учётом дефляции для указанного аккаунта.

Address 0x0000…0104: DividendCalculator

function calculateDividends(address account) external view returns (uint256[] memory)

Возвращает массив доступных дивидендов для каждой стейкинг-позиции.

Использование precompiles вместо обычных смарт-контрактов обеспечивает:

• Значительно меньший расход газа (нативное исполнение)
• Атомарную интеграцию с консенсусом
• Невозможность модификации или эксплоитов на уровне байткода

2.3. Уровень данных (Data Layer)

Уровень данных отвечает за персистентное хранение всех состояний блокчейна, обеспечивая целостность, доступность и эффективный поиск данных.

2.3.1. Структура блока

Блоки DeflationChain расширяют стандартную структуру Ethereum дополнительными полями для дефляционной и торговой логики:

Block {
    header: BlockHeader {
        // Стандартные поля Ethereum
        parentHash:        bytes32    // Хеш родительского блока
        ommersHash:        bytes32    // Хеш ommer-блоков (deprecated, = EMPTY_OMMER_HASH)
        beneficiary:       address    // Адрес валидатора
        stateRoot:         bytes32    // Корень MPT состояния аккаунтов
        transactionsRoot:  bytes32    // Корень MPT транзакций
        receiptsRoot:      bytes32    // Корень MPT receipt'ов
        logsBloom:         bytes256   // Bloom-фильтр логов
        difficulty:        uint256    // Deprecated (= 0)
        number:            uint64     // Высота блока
        gasLimit:          uint64     // Лимит газа блока
        gasUsed:           uint64     // Использованный газ
        timestamp:         uint64     // Unix timestamp
        extraData:         bytes      // Дополнительные данные (max 32 bytes)
        mixHash:           bytes32    // Deprecated
        nonce:             bytes8     // Deprecated (= 0)
        baseFeePerGas:     uint256    // EIP-1559 base fee

        // Расширения DeflationChain
        deflationRoot:     bytes32    // Корень MPT дефляционного состояния
        tradingRoot:       bytes32    // Корень MPT торгового состояния
        aiRoot:            bytes32    // Корень MPT AI-состояния
        validatorSignatures: bytes[]  // Подписи валидаторов для PoD
        podWeightSnapshot: uint256    // Snapshot суммарного PoD-веса
    }

    body: BlockBody {
        transactions:      Transaction[]     // Список транзакций
        withdrawals:       Withdrawal[]      // Withdrawals (EIP-4895)
        tradingEvents:     TradingEvent[]    // Торговые события (NEW)
        aiCompletions:     AICompletion[]    // Завершённые AI-запросы (NEW)
    }
}

2.3.2. Хранение состояния

DeflationChain использует двухуровневую систему хранения для оптимизации производительности:

Горячее хранилище (Hot Storage):

• In-memory LRU cache для часто используемых данных
• Оптимизировано для быстрого чтения при исполнении транзакций
• Размер: настраивается, рекомендуется 32-64 GB RAM

Холодное хранилище (Cold Storage):

• LevelDB или RocksDB для персистентного хранения
• Оптимизировано для последовательной записи
• Поддержка сжатия (LZ4, Snappy)
• Рекомендуется NVMe SSD для production

Схема ключей:

Account State:    keccak256(address) → RLP(nonce, balance, storageRoot, codeHash)
Contract Storage: keccak256(address || slot) → value
Deflation State:  0x01 || address || positionIndex → RLP(BalancePortion)
Staking State:    0x02 || address || stakeIndex → RLP(StakePosition)
Trading State:    0x03 || market || positionId → RLP(Position)

2.3.3. Архивные ноды

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

• Исторических запросов (eth_call с указанием номера блока)
• Аналитики и исследований
• Аудита и compliance

Требования к архивной ноде:

• Хранилище: 10+ TB (растёт со временем)
• RAM: 256 GB+ рекомендуется
• CPU: 32+ cores для индексации

Оптимизации для архивных нод:

• Periodic snapshots (каждые 10000 блоков)
• Incremental state diffs между snapshots
• Bloom filters для быстрого поиска логов

3. Модель валидаторов

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

3.1. Геополитическая децентрализация

3.1.1. Принцип «1 валидатор = 1 страна»

Центральным элементом модели валидаторов DeflationChain является принцип географического ограничения: в каждой суверенной юрисдикции может функционировать не более одного активного валидатора. Данное ограничение закреплено на уровне протокола и не может быть изменено без хардфорка с согласия подавляющего большинства участников сети.

Определение юрисдикции: Для целей DeflationChain юрисдикция определяется как суверенное государство, признанное Организацией Объединённых Наций. Это включает 193 государства — члена ООН и 2 государства-наблюдателя (Ватикан и Палестина), что даёт теоретический максимум в 195 валидаторов. Специальные административные районы (например, Гонконг, Макао), зависимые территории и самопровозглашённые государства не рассматриваются как отдельные юрисдикции для целей валидации.

Обоснование ограничения:

1. Устойчивость к регуляторному давлению: Если правительство одной страны принимает решение о запрете криптовалютной деятельности или принуждает валидатора к прекращению работы, это затрагивает не более чем 1/195 (≈0.5%) от максимального количества валидаторов. Для нарушения работы сети (достижения 1/3 злонамеренного веса) потребуется координированное действие приблизительно 65 государств — сценарий, практически нереализуемый в современных геополитических условиях.

2. Истинная глобальная децентрализация: Существующие блокчейны демонстрируют значительную концентрацию валидаторов. Например, более 60% валидаторов Solana размещены в США и Германии; значительная часть стейка Ethereum сосредоточена в нескольких юрисдикциях. DeflationChain гарантирует, что ни одна страна не может контролировать более 1/195 от максимального количества валидаторов.

3. Защита от координированных атак: Даже если группа государств (например, члены G7 или G20) решит координированно атаковать сеть, их совокупное влияние будет ограничено количеством представленных юрисдикций, что значительно ниже порога в 1/3, необходимого для нарушения безопасности BFT-консенсуса.

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

3.1.2. Механизм верификации юрисдикции

Для обеспечения соблюдения принципа «1 валидатор = 1 страна» DeflationChain реализует многоуровневый механизм верификации юрисдикции, сочетающий криптографические методы с процедурами KYC/KYB.

Процесс верификации:

1. Подача заявки: Кандидат в валидаторы подаёт заявку через специализированный смарт-контракт ValidatorRegistry, указывая желаемую юрисдикцию и предоставляя начальный депозит (stake bond).

2. KYB-верификация: Кандидат проходит процедуру Know Your Business через аккредитованного партнёра по верификации. Требуется предоставление:

   • Документов о регистрации юридического лица в указанной юрисдикции
   • Подтверждения физического присутствия (офис, дата-центр)
   • Идентификации бенефициарных владельцев
   • Проверки на соответствие санкционным спискам (OFAC, EU, UN)

3. Криптографическая аттестация: После успешного прохождения KYB партнёр по верификации генерирует подписанную аттестацию (attestation), содержащую:

   Attestation {
       validatorAddress: address
       jurisdiction: bytes2 (ISO 3166-1 alpha-2 код страны)
       verificationDate: uint256
       expirationDate: uint256
       verifierSignature: bytes
   }
   

4. On-chain регистрация: Аттестация публикуется в смарт-контракте ValidatorRegistry. Контракт проверяет:

   • Валидность подписи аккредитованного верификатора
   • Отсутствие активного валидатора в указанной юрисдикции
   • Достаточность stake bond
   • Соответствие технических параметров ноды требованиям

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

Ежегодная ре-верификация:
Для поддержания актуальности информации о юрисдикции валидаторы обязаны проходить ре-верификацию каждые 12 месяцев. Непрохождение ре-верификации приводит к автоматическому исключению из активного набора (jailing) до момента успешного подтверждения статуса.

Защита приватности:
Детали KYB-верификации не публикуются в блокчейне. On-chain хранится только код юрисдикции и хеш аттестации. Полные данные верификации хранятся у аккредитованных партнёров в соответствии с требованиями GDPR и локального законодательства.

3.1.3. Максимальное количество валидаторов

Теоретический максимум валидаторов в сети DeflationChain составляет приблизительно 195, что соответствует количеству признанных суверенных государств. Однако практическое количество активных валидаторов будет варьироваться в зависимости от:

• Наличия желающих и способных операторов в каждой юрисдикции
• Регуляторных ограничений в отдельных странах
• Экономической целесообразности (минимальный стейк, операционные расходы)
• Технической инфраструктуры (доступность интернета, электричества)

Фазы развития сети:

Фаза	Количество валидаторов	Характеристика
Genesis	10-20	Начальный запуск, преимущественно регионы с развитой инфраструктурой
Growth	50-100	Расширение в развивающиеся регионы
Maturity	150-195	Глобальное покрытие

Минимальное количество для безопасности:
Для обеспечения достаточной децентрализации и безопасности BFT-консенсуса рекомендуется минимум 21 активный валидатор (7f+1 при f=3). Протокол не активирует mainnet до достижения этого порога.

3.1.4. Обоснование ограничения и преимущества

Сравнение с традиционными моделями:

Характеристика	Ethereum	Solana	DeflationChain
Макс. валидаторов	~1,000,000+	~1,500	~195
Географ. концентрация	Высокая (US, EU)	Очень высокая (US)	Минимальная (by design)
Регуляторная устойчивость	Низкая	Очень низкая	Максимальная
Координация атаки	Требует $	Требует $	Требует геополитики

Потенциальные критики и ответы:

Критика 1: «Ограничение в 195 валидаторов — это централизация»
Ответ: Централизация определяется не количеством узлов, а концентрацией контроля. 195 валидаторов в 195 странах более децентрализованы, чем 10,000 валидаторов в 5 странах, поскольку последние подвержены координированному регуляторному давлению.

Критика 2: «Богатые страны будут доминировать»
Ответ: PoD-вес определяется стейком и временем, а не богатством страны. Валидатор из развивающейся страны с долгосрочным стейком может иметь больший вес, чем валидатор из G7 с краткосрочной позицией.

Критика 3: «KYC противоречит децентрализации»
Ответ: KYC применяется только к валидаторам (профессиональным операторам инфраструктуры), а не к пользователям сети. Это аналогично требованиям к банковской лицензии — пользователи остаются анонимными, но операторы инфраструктуры идентифицированы.

3.2. Требования к валидаторам

3.2.1. Минимальный стейк DEF

Для участия в качестве валидатора DeflationChain требуется минимальный стейк, обеспечивающий экономическую заинтересованность в честном поведении и покрывающий потенциальные slashing-штрафы.

Параметры стейкинга валидатора:

MIN_VALIDATOR_STAKE = 10,000 DEF
MIN_STAKE_PERIOD = 4 года
STAKE_MULTIPLIER = 4x (соответствует xMultipliers[3])

Обоснование параметров:

• 10,000 DEF: Оптимальный порог для обеспечения серьёзности намерений с учётом общей эмиссии ~21M DEF, доступный для операторов по всему миру
• 4 года: Минимальный срок стейкинга гарантирует долгосрочную приверженность валидатора сети и соответствует типичному горизонту планирования инфраструктурных проектов
• 4x мультипликатор: Валидаторы получают усиленный вес в расчёте дивидендов, компенсируя операционные расходы

Делегированный стейк:
Помимо собственного стейка, валидаторы могут принимать делегированные токены от пользователей. Делегированный стейк:

• Увеличивает PoD-вес валидатора
• Генерирует дивиденды для делегаторов (за вычетом комиссии валидатора)
• Подвергается slashing наравне с собственным стейком валидатора

3.2.2. Технические требования

Валидаторы DeflationChain должны обеспечивать высокопроизводительную и надёжную инфраструктуру для поддержания целевых показателей сети.

Аппаратные требования (минимальные):

CPU:      32 cores / 64 threads, 3.0 GHz+
          Intel Xeon (Sapphire Rapids+) с TDX support — для Confidential Compute
RAM:      128 GB DDR5 ECC
Storage:  2 TB NVMe SSD (DWPD ≥ 1)
          + 10 TB HDD для archive (опционально)
Network:  1 Gbps симметричный, низкая латентность
GPU:      NVIDIA H100/A100 — для AI inference (опционально)

Аппаратные требования (рекомендуемые):

CPU:      64 cores / 128 threads, 3.5 GHz+
          Intel Xeon с TDX + SGX support
RAM:      256 GB DDR5 ECC
Storage:  4 TB NVMe SSD RAID-10
          + 20 TB для archive
Network:  10 Gbps симметричный
GPU:      2x NVIDIA H100 с CC support

Программные требования:

• Операционная система: Linux (Ubuntu 22.04 LTS, Debian 12, RHEL 9)
• Kernel: 6.16+ с поддержкой TDX
• DeflationChain node software (официальный релиз)
• Seal Server (SGX enclave) — для участия в Confidential Compute
• Monitoring stack (Prometheus, Grafana)

Требования к доступности:

Uptime SLA:       99.9% (максимум 8.76 часов downtime в год)
Block production: Участие в ≥95% назначенных слотов
Latency:          <100ms до 90% других валидаторов

3.2.3. Юридические требования

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

Обязательные требования:

1. Регистрация юридического лица в заявленной юрисдикции
2. Наличие лицензий/разрешений для деятельности с криптоактивами (если требуется локальным законодательством)
3. Отсутствие в санкционных списках (OFAC, EU, UN)
4. Прохождение KYB-верификации через аккредитованного партнёра
5. Согласие с условиями участия в сети (Terms of Service)

Рекомендуемые практики:

• Страхование ответственности (cyber liability insurance)
• Регулярный аудит безопасности инфраструктуры
• Документированные процедуры disaster recovery
• Раскрытие информации о бенефициарных владельцах

3.3. Экономика валидаторов

3.3.1. Формула вознаграждения валидатора

Валидаторы DeflationChain получают вознаграждение из нескольких источников без создания новых токенов (инфляционной эмиссии):

Компоненты вознаграждения:

1. Дивиденды от стейкинга (R_dividends):

2. Доля от торговых комиссий (R_trading):

3. Доля от газовых комиссий (R_gas):

4. Доля от AI-сервисов (R_ai):

Ожидаемая доходность:
При полной загрузке сети и равномерном распределении валидаторов ожидаемая годовая доходность составляет 15-30% APY на стейк, что значительно превышает типичные показатели PoS-сетей (4-8% APY) благодаря отсутствию размывания от инфляционной эмиссии.

3.3.2. Slashing условия

Для обеспечения честного поведения валидаторов DeflationChain реализует систему штрафов (slashing), при которой часть стейка конфискуется за нарушения протокола.

Таблица штрафов:

Нарушение	Штраф	Jailing	Дополнительно
Double signing	5% стейка	30 дней	Публикация evidence on-chain
Prolonged downtime (>24h)	1% стейка	7 дней	Предупреждение при 12h
Invalid block proposal	2% стейка	14 дней	Автоматическое детектирование
Censorship (доказанная)	10% стейка	90 дней	Требуется governance vote
Equivocation	5% стейка	30 дней	Противоречивые подписи
Повторные нарушения	2x от базового	2x срок	Кумулятивный эффект

Распределение slashed токенов:

burned = slashed_amount × 0.50    // 50% сжигается
treasury = slashed_amount × 0.30  // 30% в treasury
reporter = slashed_amount × 0.20  // 20% тому, кто сообщил о нарушении

Процесс jailing:

1. Обнаружение нарушения (автоматически или через report)
2. Немедленное исключение из активного набора валидаторов
3. Применение slashing к стейку
4. Период jailing (валидатор не может участвовать в консенсусе)
5. Unjailing после истечения срока и подтверждения исправления

3.3.3. Делегированный стейкинг

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

Механика делегирования:

function delegate(address validator, uint256 amount, uint256 years) external {
    require(validators[validator].isActive, "Validator not active");
    require(years >= 1 && years <= 12, "Invalid stake period");

    // Создание делегированной позиции
    DelegationPosition memory position = DelegationPosition({
        delegator: msg.sender,
        validator: validator,
        amount: amount,
        years: years,
        startTime: block.timestamp,
        lastClaimed: 0
    });

    delegations[msg.sender].push(position);
    validators[validator].totalDelegated += amount;

    // Transfer и lock токенов
    DEF.transferFrom(msg.sender, address(this), amount);
}

Комиссия валидатора:
Валидаторы устанавливают комиссию (5-20% от наград делегатора), которая удерживается при распределении вознаграждений:

Распределение slashing:
При slashing валидатора пропорциональная часть штрафа применяется к делегированному стейку:

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

3.4. Ротация и выбор лидера

3.4.1. Алгоритм выбора лидера раунда

Выбор лидера (proposer) для каждого раунда консенсуса осуществляется детерминированно на основе PoD-весов валидаторов, что обеспечивает справедливое распределение права на создание блоков.

Алгоритм Weighted Random Selection:

def select_leader(epoch: int, round: int, validators: List[Validator]) -> Validator:
    # Генерация псевдослучайного seed
    seed = keccak256(
        epoch.to_bytes(8) ||
        round.to_bytes(8) ||
        prev_block_hash
    )

    # Получение весов валидаторов
    weights = [v.pod_weight for v in validators if v.is_active]
    total_weight = sum(weights)

    # Выбор на основе seed
    target = int.from_bytes(seed[:32]) % total_weight
    cumulative = 0

    for validator in validators:
        if not validator.is_active:
            continue
        cumulative += validator.pod_weight
        if cumulative > target:
            return validator

    # Fallback (не должен достигаться)
    return validators[0]

Свойства алгоритма:

1. Детерминизм: Все узлы вычисляют одного и того же лидера для заданного (epoch, round)
2. Пропорциональность: Вероятность выбора пропорциональна PoD-весу
3. Непредсказуемость: До финализации предыдущего блока невозможно предсказать лидера (зависимость от prev_block_hash)
4. Устойчивость: Отказ лидера приводит к переходу к следующему раунду с новым лидером

3.4.2. Weighted Random Selection на основе PoD

Использование PoD-весов для выбора лидера обеспечивает несколько важных свойств:

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

Защита от Sybil-атак:
Разделение стейка между несколькими валидаторами (если бы это было возможно) не увеличивает суммарную вероятность выбора, поскольку веса аддитивны.

VRF для дополнительной защиты:
Для предотвращения grinding-атак (попыток манипулировать выбором лидера) может быть внедрён механизм Verifiable Random Function (VRF):

vrf_output = VRF_prove(validator_private_key, epoch || round)
leader = select_based_on_vrf(vrf_output, validators)

VRF обеспечивает, что только сам валидатор может сгенерировать доказательство для своего потенциального лидерства, предотвращая pre-computation атаки.

4. Proof-of-Deflation: Формальная спецификация

Proof-of-Deflation (PoD) является центральным инновационным механизмом DeflationChain, объединяющим функции консенсуса, экономического стимулирования и дефляционной токеномики в единую когерентную систему. Данный раздел предоставляет формальную спецификацию всех компонентов PoD с математическими определениями и доказательствами ключевых свойств.

4.1. Определения

4.1.1. Стейкинг-позиция

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

Формальное определение:

Solidity-представление:

struct StakePosition {
    uint256 initialAmount;      // Начальная сумма при создании
    uint256 amount;             // Текущая сумма (может уменьшаться при частичном выводе)
    uint256 finishedAmount;     // Фиксируется при завершении срока
    uint256 startTime;          // Block.timestamp создания
    uint256 year;               // Срок: 1-12 лет
    uint256 lastClaimed;        // YYYYMM последнего клейма
    uint256 claimedStaking;     // Выведено из principal в текущем периоде
    uint256 claimedDividends;   // Получено дивидендов в текущем периоде
}

Инварианты позиции:

4.1.2. Дефляционный множитель

Дефляционный множитель определяет долю сохраняемой стоимости для токенов, не находящихся в стейкинге, в зависимости от времени с момента последнего перемещения.

Формальное определение:

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

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

Свойства принципа удвоения:

Экономическая интерпретация:

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

• Первые 3 дня: минимальные потери (1%, 2%, 4% от остатка ежедневно)
• Средний период (дни 4-6): ускоряющиеся потери (8%, 16%, 32% от остатка)
• Финальная стадия (дни 7-8): критические потери (64%, 100%)

Это создаёт мощный экономический стимул для активного участия в экосистеме через стейкинг, торговлю или использование DeFi-протоколов.

4.1.3. PoD-вес

PoD-вес является ключевой метрикой, определяющей влияние участника в механизме консенсуса и распределении вознаграждений.

Формальное определение:

Свойства PoD-веса:

Пример расчёта:

4.2. Математические формулы

4.2.1. Beta-индикатор (для дивидендов)

Beta-индикатор β используется для расчёта дивидендов с учётом нелинейных мультипликаторов для различных сроков стейкинга.

Определение:

Отличие от β_PoD:
В то время как β_PoD использует линейную зависимость от срока (amount × year), β для дивидендов использует нелинейную шкалу xMultipliers:

Год	PoD-множитель	Дивидендный множитель	Отношение
1	1	1	1.00
4	4	4	1.00
8	8	10	1.25
12	12	20	1.67

Это создаёт дополнительный стимул для сверхдолгосрочного стейкинга (8-12 лет): при равном PoD-весе позиции на 12 лет получают 67% больше дивидендов, чем позиции на 12 × (1-летних).

4.2.2. Beta-PoD (для консенсуса)

Beta-PoD используется исключительно для расчёта весов в механизме консенсуса:

Обновление β_PoD:

// При создании стейка
β_PoD += stake.amount × stake.year;

// При расширении срока
β_PoD += stake.amount × (newYear - oldYear);

// При частичном выводе
β_PoD -= withdrawAmount × remainingYears;

4.2.3. Формула дивидендов

Дивиденды для стейкинг-позиции S за период рассчитываются как:

Учёт времени стейкинга:
Позиции, созданные в текущем месяце, не получают дивидендов за этот месяц:

Учёт уже полученных дивидендов:

4.2.4. Формула ежемесячного вывода

Помимо дивидендов, стейкеры могут ежемесячно выводить часть основной суммы стейка:

Пример:

• Стейк 12,000 DEF на 1 год: SM = 12,000 / 12 = 1,000 DEF/месяц
• Стейк 12,000 DEF на 12 лет: SM = 12,000 / 144 = 83.33 DEF/месяц

Общая формула доступного вывода:

4.3. Консенсус-раунды

4.3.1. Propose → Vote → Commit

Консенсус DeflationChain следует упрощённой двухфазной модели, основанной на HotStuff:

4.3.2. Кворум

Определение кворума:

Минимальный кворум при равных весах:
При N валидаторах с равными весами, минимальный кворум составляет ⌈2N/3⌉ + 1 валидаторов.

Пример: При 100 валидаторах с равными весами требуется 67+ голосов для достижения кворума.

4.3.3. Финализация блока

Финализация в DeflationChain происходит мгновенно после достижения кворума precommits:

4.4. Защита от атак

4.4.1. Long-range attacks

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

Механизмы защиты в DeflationChain:

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

2. Weak Subjectivity Period: Новые узлы должны синхронизироваться с состоянием не старше 2 недель. Это гарантирует, что к моменту синхронизации злоумышленник не успеет создать достаточно длинную альтернативную цепочку.

3. Дефляционная защита: Поскольку незастейканные токены теряют стоимость за 8 дней, валидаторы не могут выйти из стейкинга и сохранить свои токены для будущей атаки — им придётся либо оставаться в стейкинге, либо потерять средства.

4.4.2. Nothing-at-stake

Проблема nothing-at-stake возникает в PoS-системах, когда валидаторы могут голосовать за несколько конфликтующих блоков без экономических потерь.

Решение в DeflationChain:

1. Slashing за double signing: Подпись двух разных блоков на одной высоте влечёт конфискацию 5% стейка.

2. Криптографическая связь: Каждый prevote/precommit содержит уникальную подпись, привязанную к конкретному блоку и раунду. Попытка создать две подписи для одного раунда криптографически доказуема.

3. Экономический стимул: При минимальном стейке 10,000 DEF, потеря 5% (500 DEF) за double signing делает атаку экономически невыгодной.

4.4.3. Дефляционное наказание

DeflationChain усиливает стандартные механизмы slashing уникальным дефляционным компонентом:

Дефляционный эффект:
Сжигание 50% slashed токенов создаёт дополнительный дефляционный эффект при каждом нарушении. Это означает, что атаки на сеть не только наказывают злоумышленника, но и приносят экономическую выгоду честным участникам через уменьшение общего предложения токенов.

5. Централизованный ордер-бук (Trading Core)

Trading Core — это сердце торговой инфраструктуры DeflationChain, представляющее собой гибридную архитектуру, которая объединяет скорость централизованных бирж с безопасностью и прозрачностью децентрализованных систем. DeflationChain развивает и существенно улучшает архитектуру HyperLiquid, устраняя выявленные уязвимости (инцидент JELLY с убытками $10M) и добавляя уникальные функции: нативную дефляционную экономику, интеграцию с геополитически децентрализованной сетью валидаторов, а также улучшенные механизмы контроля рисков и защиты от манипуляций.

5.1. Архитектура торгового ядра

5.1.1. Централизованный Matching Engine

Matching Engine (ME) — это высокопроизводительный компонент, отвечающий за сопоставление ордеров покупателей и продавцов. В отличие от традиционных DEX, где матчинг происходит on-chain с высокой латентностью, DeflationChain использует off-chain matching с on-chain settlement.

Архитектура Matching Engine:

Компоненты системы:

1. Order Gateway: Принимает ордера от пользователей через API/WebSocket, выполняет первичную валидацию (подпись, баланс, лимиты), маршрутизирует в соответствующий Order Book.

2. Order Book Engine: Поддерживает отсортированные списки bid/ask ордеров для каждого рынка, выполняет алгоритм price-time priority matching, генерирует события исполнения сделок.

3. Trade Executor: Обрабатывает исполненные сделки, обновляет позиции и балансы, рассчитывает PnL, генерирует settlement transactions.

4. In-Memory State Manager: Хранит актуальное состояние всех счетов, позиций и ордеров в оперативной памяти для минимальной латентности.

Технические характеристики:

5.1.2. Интеграция с децентрализованным Settlement

Settlement Layer обеспечивает финальную фиксацию всех торговых операций на блокчейне DeflationChain, гарантируя неизменяемость и прозрачность.

Поток обработки сделки:

Этапы Settlement:

1. Trade Aggregation (каждые 100ms): Сделки группируются в батчи для оптимизации gas costs.

2. State Transition Proof: Для каждого батча генерируется доказательство корректности перехода состояния.

3. On-chain Commit: Батч транзакций отправляется в DeflationChain с подписями операторов matching engine.

4. Finalization: После включения в блок и финализации (instant в DeflationChain), settlement считается завершённым.

Формат Settlement Transaction:

struct SettlementBatch {
    uint256 batchId;
    uint256 timestamp;
    bytes32 previousStateRoot;
    bytes32 newStateRoot;
    Trade[] trades;
    bytes operatorSignature;
}

struct Trade {
    address maker;
    address taker;
    bytes32 marketId;
    uint256 price;
    uint256 quantity;
    bool isMakerLong;
    uint256 makerFee;
    uint256 takerFee;
}

5.1.3. Гибридная модель: скорость CEX + безопасность DEX

DeflationChain Trading Core реализует уникальную гибридную модель, которая берёт лучшее от централизованных и децентрализованных бирж:

Сравнительная таблица:

Ключевые принципы гибридной модели:

1. Self-Custody: Пользователи всегда контролируют свои средства через on-chain smart contracts. Matching Engine никогда не имеет прямого доступа к funds.

2. Deterministic Execution: Все правила matching engine открыты и детерминированы. Любой может верифицировать корректность исполнения.

3. Fraud Proofs: При обнаружении некорректного settlement, любой участник может предоставить fraud proof и получить награду из slashed stake оператора.

4. Decentralized Operators: Matching Engine может работать на любом валидаторе, с автоматическим failover при сбоях.

5.2. Типы ордеров

DeflationChain Trading Core поддерживает полный спектр типов ордеров, необходимых для профессиональной торговли.

5.2.1. Базовые ордера

Limit Order:

Определение: Ордер на покупку/продажу по указанной цене или лучше.

Параметры:
- side: BUY | SELL
- price: uint256 (в минимальных единицах quote asset)
- quantity: uint256 (в минимальных единицах base asset)
- timeInForce: GTC | IOC | FOK | GTT

Пример:
{
  "type": "LIMIT",
  "side": "BUY",
  "price": "45000.00",
  "quantity": "1.5",
  "market": "BTC-USDC",
  "timeInForce": "GTC"
}

Market Order:

Определение: Ордер на немедленное исполнение по лучшей доступной цене.

Параметры:
- side: BUY | SELL
- quantity: uint256 (может быть в base или quote asset)
- slippage: uint256 (максимальное отклонение от oracle price, в bp)

Защита от проскальзывания:
max_execution_price = oracle_price × (1 + slippage / 10000)

Stop-Loss Order:

Определение: Ордер активируется при достижении trigger price.

Параметры:
- triggerPrice: uint256
- executionType: MARKET | LIMIT
- limitPrice: uint256 (только для LIMIT)

Логика активации:
IF side == SELL AND mark_price <= triggerPrice: activate()
IF side == BUY AND mark_price >= triggerPrice: activate()

Take-Profit Order:

Определение: Ордер для фиксации прибыли при достижении целевой цены.

Параметры: аналогичны Stop-Loss

Логика активации:
IF side == SELL AND mark_price >= triggerPrice: activate()
IF side == BUY AND mark_price <= triggerPrice: activate()

Trailing Stop Order:

Определение: Stop-ордер с динамическим trigger price.

Параметры:
- trailingDelta: uint256 (в % или абсолютных единицах)
- activationPrice: uint256 (опционально)

Логика:
trailing_price = max_price - (max_price × trailingDelta / 100)
IF mark_price <= trailing_price: activate()

Post-Only Order (Maker Only):

Определение: Ордер гарантированно добавляется в книгу ордеров.

Поведение:
IF order would immediately match: REJECT
ELSE: add to order book

Преимущество: гарантированное получение maker rebate.

Reduce-Only Order:

Определение: Ордер может только уменьшить существующую позицию.

Валидация:
IF order.side == position.side: REJECT
IF order.quantity > position.size: order.quantity = position.size

5.2.2. Perpetual контракты

DeflationChain поддерживает бессрочные фьючерсные контракты (perpetuals) — производные инструменты без даты экспирации.

Linear Perpetuals (USDC-settled):

Характеристики:
- Margin и PnL в USDC (стейблкоин)
- Контракт котируется в USD
- Размер позиции в base asset

PnL расчёт:
PnL = (exit_price - entry_price) × position_size × direction
где direction = 1 для LONG, -1 для SHORT

Пример:
- LONG 10 BTC @ $45,000
- Exit @ $47,000
- PnL = (47000 - 45000) × 10 × 1 = +$20,000 USDC

Inverse Perpetuals (DEF-settled):

Характеристики:
- Margin и PnL в DEF (native token)
- Контракт котируется в USD
- Используется для хеджирования DEF exposure

PnL расчёт:
PnL = position_value × (1/entry_price - 1/exit_price) × direction

Пример:
- SHORT $100,000 контракт @ DEF=$10
- DEF падает до $8
- PnL = 100000 × (1/10 - 1/8) × (-1) = 100000 × 0.025 = 2,500 DEF

Funding Rate Mechanism:

Funding rate — это периодические платежи между holders long и short позиций для привязки цены perpetual к spot price.

Формула funding rate:
F = clamp(
    (mark_price - index_price) / index_price × impact_factor,
    -0.01,  // min -1% per 8h
    +0.01   // max +1% per 8h
)

Funding payment:
payment = position_value × F

Направление:
IF F > 0: longs pay shorts
IF F < 0: shorts pay longs

Периодичность: каждые 8 часов (00:00, 08:00, 16:00 UTC)

Mark Price Calculation:

Mark price используется для расчёта PnL и ликвидаций, защищая от манипуляций spot price.

mark_price = index_price × (1 + funding_basis)

где:
- index_price = TWAP(oracle_prices) за последние 5 минут
- funding_basis = cumulative_funding / 8h_intervals

Oracle sources:
- Chainlink
- Pyth Network
- Internal TWAP от spot markets
- Медиана из 3+ источников

5.2.3. Левередж

DeflationChain позволяет торговать с кредитным плечом до 50x, что увеличивает как потенциальную прибыль, так и риски.

Максимальный левередж по типу актива:

Формулы маржинальных требований:

Initial Margin (IM):
IM = position_notional / leverage

Пример:
- Position: $100,000
- Leverage: 20x
- IM = $100,000 / 20 = $5,000

Maintenance Margin (MM):
MM = IM × maintenance_ratio
maintenance_ratio = 0.5 (50% от initial)

MM = $5,000 × 0.5 = $2,500

Cross vs Isolated Margin:

Cross Margin:
- Вся свободная маржа доступна для всех позиций
- Снижает риск ликвидации отдельных позиций
- Увеличивает системный риск

Isolated Margin:
- Маржа выделяется отдельно для каждой позиции
- Максимальный убыток = allocated margin
- Рекомендуется для высокорисковых сделок

5.3. Производительность

5.3.1. Целевые метрики

DeflationChain Trading Core проектируется для конкуренции с топовыми централизованными биржами:

Оптимизации для достижения целевых метрик:

1. Lock-free data structures: Order books реализованы на lock-free структурах данных для минимизации contention.

2. DPDK networking: Direct kernel bypass для сетевых операций, уменьшая латентность до микросекунд.

3. Memory-mapped persistence: Состояние синхронизируется на диск через mmap без блокировки основного потока.

4. Горизонтальное масштабирование: Каждый рынок обрабатывается независимым shard’ом.

5.3.2. Превосходство над HyperLiquid

DeflationChain превосходит HyperLiquid по большинству ключевых параметрам. Ниже приведено детальное сравнение архитектур:

Уникальные преимущества DeflationChain:

1. Дефляционная экономика: Торговые комиссии частично сжигаются, создавая положительное давление на цену DEF.

2. EVM-совместимость: Разработчики могут использовать существующие инструменты (Solidity, Hardhat, ethers.js).

3. Геополитическая устойчивость: Распределение валидаторов по странам защищает от регуляторных рисков.

4. Интегрированный AI: Возможность использования AI для торговых стратегий с гарантией приватности.

5.4. MEV Protection

MEV (Maximal Extractable Value) — это прибыль, которую валидаторы/секвенсоры могут извлечь путём переупорядочивания транзакций. DeflationChain реализует несколько механизмов защиты.

5.4.1. Fair Ordering Protocol

Fair Ordering Protocol (FOP) — это улучшение над традиционными блокчейнами, где порядок транзакций определяется исключительно block proposer’ом. В классической модели proposer может переупорядочивать транзакции для личной выгоды (front-running, sandwich attacks). FOP устраняет эту возможность через криптографически защищённую очередь.

Ключевая идея: каждый ордер получает sequence number не от одного валидатора, а от threshold группы (2/3 валидаторов). Это делает манипуляцию порядком невозможной без сговора большинства сети. Matching Engine обязан обрабатывать ордера строго по sequence number, и любое нарушение автоматически обнаруживается и карается slashing.

Данный подход реализует fair ordering в смысле “first come, first served” — честный трейдер, отправивший ордер раньше, гарантированно будет обработан раньше, независимо от размера комиссии или связей с валидаторами.

Принцип: Ордера обрабатываются строго в порядке поступления (FIFO).

Реализация:
1. Каждый ордер получает монотонно возрастающий sequence number
2. Sequence number подписывается threshold signature (2/3 валидаторов)
3. Matching Engine обязан обрабатывать ордера по sequence number
4. Нарушение порядка = slashable offense

5.4.2. Commit-Reveal для крупных ордеров

Commit-Reveal — классическая криптографическая схема для предотвращения front-running. Проблема: когда крупный ордер виден в mempool до исполнения, наблюдатели могут открыть позицию перед ним и закрыть после, извлекая прибыль за счёт движения цены, вызванного крупным ордером.

Решение: двухфазное исполнение. В первой фазе (Commit) трейдер публикует только криптографический хеш ордера — никто не знает направление, размер или цену. Во второй фазе (Reveal, через 1 блок) трейдер раскрывает параметры, контракт верифицирует соответствие хешу и исполняет ордер.

Важно понимать trade-off: commit-reveal добавляет задержку в 1 блок (2 секунды). Для небольших ордеров это неприемлемо, поэтому механизм применяется только для ордеров свыше $100,000, где потенциальный ущерб от front-running превышает неудобство задержки.

Для ордеров > $100,000:

Phase 1 - Commit (скрытый):
- User публикует: hash(order || salt || user_address)
- Ордер добавляется в commit queue

Phase 2 - Reveal (через 1 блок):
- User публикует: order, salt
- Верифицируется соответствие hash
- Ордер исполняется

Защита: Front-runners не видят детали ордера до reveal.

5.4.3. Batch Auctions

Batch Auctions — альтернативный механизм исполнения ордеров, активируемый в периоды высокой волатильности. В отличие от continuous trading (где каждый ордер исполняется немедленно), batch auction собирает все ордера за определённое окно времени и исполняет их одновременно по единой клиринговой цене.

Ключевое преимущество: устранение time-priority advantage. В continuous trading HFT-трейдеры с более быстрым соединением имеют преимущество — они успевают отреагировать на информацию раньше других. В batch auction все ордера в рамках окна равноправны, что уравнивает институциональных игроков и розничных трейдеров.

DeflationChain автоматически переключается на batch mode при обнаружении аномальной волатильности или подозрительных MEV-паттернов. Длительность auction window (100-500ms) балансирует между защитой от MEV и приемлемой задержкой для трейдеров.

Альтернативный режим для volatile markets:

1. Ордера собираются в течение auction window (100-500ms)
2. Вычисляется единая clearing price
3. Все ордера исполняются по clearing price

Преимущество: Устраняет time-priority advantage для HFT.

6. Vault System & Leverage Pool

Vault System — это критически важный компонент DeflationChain, обеспечивающий инфраструктуру для маржинальной торговли, ликвидаций и управления рисками. Система спроектирована с учётом уроков, извлечённых из инцидентов на других платформах (включая JELLY incident на HyperLiquid), и включает многоуровневые механизмы защиты.

6.1. Архитектура Vault

6.1.1. Deflation Liquidity Provider (DLP)

DLP — это протокольный vault, представляющий собой эволюцию концепции HLP с устранением выявленных уязвимостей. В отличие от HLP, DLP интегрирует дефляционные механизмы, улучшенный контроль открытого интереса и многоуровневую защиту от манипуляций.

Архитектура DLP:

Ключевые характеристики DLP:

Механизм работы DLP:

1. Депозит: Пользователи вносят DEF в DLP и получают DLP-shares (ERC-20 токены).

2. Ликвидация как контрагент: Когда позиция трейдера ликвидируется, DLP принимает позицию по ликвидационной цене с премией.

3. Market Making: DLP автоматически размещает лимитные ордера на заданном расстоянии от mark price.

4. Ребалансировка: Позиции DLP периодически ребалансируются для поддержания delta-neutral экспозиции.

Формула стоимости DLP share:

6.1.2. Пользовательские Vaults

Помимо протокольного DLP, любой пользователь может создать собственный vault с кастомной торговой стратегией.

Типы пользовательских vaults:

Структура контракта Vault:

contract UserVault {
    // Vault metadata
    string public name;
    address public leader;
    VaultType public vaultType;

    // Economics
    uint256 public performanceFee;     // Leader's share (max 20%)
    uint256 public managementFee;      // Annual fee (max 2%)
    uint256 public highWaterMark;      // For performance fee calculation

    // Shares
    mapping(address => uint256) public shares;
    uint256 public totalShares;

    // Risk parameters
    uint256 public maxLeverage;        // Max leverage for vault
    uint256 public maxDrawdown;        // Auto-close if exceeded
    bytes32[] public allowedMarkets;   // Whitelist of tradeable markets

    // Lock-up
    uint256 public lockUpPeriod;       // Minimum hold time
    mapping(address => uint256) public depositTime;
}

Пример создания vault:

Vault: "DEF Momentum Strategy"
Leader: 0x1234...
Type: Public

Parameters:
- Performance Fee: 15%
- Management Fee: 1%
- Max Leverage: 10x
- Max Drawdown: 30%
- Lock-up: 7 days
- Allowed Markets: [BTC-PERP, ETH-PERP, DEF-PERP]

Initial Deposit: 10,000 DEF (from leader)

6.1.3. Протокольные Vaults

Протокольные vaults — это специализированные резервы, управляемые автоматически смарт-контрактами без вмешательства человека.

Insurance Fund Vault:

Treasury Vault:

Назначение: Финансирование развития экосистемы.

Пополнение:
- 20% от gas fees
- 30% от slashing penalties
- Часть trading fees

Использование (через governance):
- Гранты разработчикам
- Маркетинг
- Аудиты безопасности
- Листинги

Управление: Multi-sig (5/9) + Timelock (48h)

Dividend Pool Vault:

Назначение: Распределение дивидендов стейкерам.

Пополнение:
- 50% от сожжённых балансов (прогрессивное сжигание burnRate)
- 30% от gas fees
- Часть trading fees

Распределение:
- Ежемесячно
- Пропорционально (stake × xMultiplier)
- Snapshot на 1-е число месяца

6.2. Формулы безопасности пула

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

6.2.1. Margin Requirement (Маржинальное требование)

Initial Margin (IM):

Минимальная сумма, необходимая для открытия позиции.

IM = position_notional / leverage

Где:
- position_notional = position_size × mark_price
- leverage = выбранное плечо (1x-50x)

Пример:
Трейдер хочет открыть LONG 10 BTC @ $50,000 с плечом 20x
- position_notional = 10 × $50,000 = $500,000
- leverage = 20x
- IM = $500,000 / 20 = $25,000

Формула IM с учётом тиров:

Для больших позиций применяется прогрессивная шкала:

6.2.2. Maintenance Margin (MM)

Минимальный equity, необходимый для поддержания позиции.

MM = IM × maintenance_ratio

maintenance_ratio = 0.5 (50% от initial margin)

Пример:
- IM = $25,000
- MM = $25,000 × 0.5 = $12,500

Если equity падает ниже $12,500 — начинается ликвидация.

Динамический maintenance_ratio:

Для волатильных активов применяется повышенный коэффициент:

maintenance_ratio = base_ratio × volatility_multiplier

volatility_multiplier = max(1.0, realized_vol_30d / 50%)

Пример для волатильного актива:
- base_ratio = 0.5
- realized_vol_30d = 100%
- volatility_multiplier = 100% / 50% = 2.0
- maintenance_ratio = 0.5 × 2.0 = 1.0 (100% IM = MM)

6.2.3. Liquidation Price

Цена, при которой позиция будет ликвидирована.

Для LONG позиции:

Liq_Price_Long = Entry_Price × (1 - (1/leverage) × (1 - MM_ratio) + fees)

Где:
- leverage = position_notional / initial_margin
- MM_ratio = maintenance_margin / initial_margin
- fees = estimated closing fees (0.1%)

Пример:
- Entry_Price = $50,000
- Leverage = 20x
- MM_ratio = 0.5
- fees = 0.001

Liq_Price = $50,000 × (1 - 0.05 × 0.5 + 0.001)
          = $50,000 × 0.976
          = $48,800

Для SHORT позиции:

Liq_Price_Short = Entry_Price × (1 + (1/leverage) × (1 - MM_ratio) + fees)

Пример:
Liq_Price = $50,000 × (1 + 0.05 × 0.5 + 0.001)
          = $50,000 × 1.026
          = $51,300

6.2.4. Available Margin

Свободная маржа, доступная для открытия новых позиций или вывода.

Available_Margin = Account_Equity - Total_Initial_Margin_Used

Account_Equity = Balance + Unrealized_PnL

Unrealized_PnL = Σ(position_size × (mark_price - entry_price) × direction)

Пример:
- Balance: $50,000
- LONG 5 BTC @ $48,000, mark_price = $50,000
- Unrealized_PnL = 5 × ($50,000 - $48,000) × 1 = +$10,000
- Account_Equity = $50,000 + $10,000 = $60,000
- Position Notional = 5 × $50,000 = $250,000
- IM_used = $250,000 / 10 = $25,000 (при 10x)
- Available_Margin = $60,000 - $25,000 = $35,000

6.2.5. Margin Ratio

Ключевой индикатор здоровья аккаунта.

Margin_Ratio = Account_Equity / Total_Maintenance_Margin

Состояние аккаунта:
- Margin_Ratio > 2.0: Healthy (зелёный)
- 1.5 < Margin_Ratio ≤ 2.0: Warning (жёлтый)
- 1.0 < Margin_Ratio ≤ 1.5: Danger (оранжевый)
- Margin_Ratio ≤ 1.0: Liquidation (красный)

6.3. Механизм ликвидаций

Ликвидация — это принудительное закрытие позиции при недостаточности маржи. DeflationChain использует многоступенчатый механизм для минимизации рыночного воздействия.

6.3.1. Триггер ликвидации

Условие ликвидации:
Account_Equity ≤ Total_Maintenance_Margin

Эквивалентно:
Margin_Ratio ≤ 1.0

Мониторинг:
- Mark price обновляется каждую секунду
- Margin check выполняется при каждом обновлении
- Позиции сортируются по margin_ratio

Процесс инициации:

1. Система обнаруживает margin_ratio ≤ 1.0
2. Аккаунт помечается как "liquidatable"
3. Генерируется событие LiquidationTriggered
4. Liquidation Engine начинает обработку

6.3.2. Частичная ликвидация

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

Алгоритм частичной ликвидации:

WHILE margin_ratio < target_margin_ratio:
    # Шаг 1: Отмена открытых ордеров
    cancel_open_orders()
    recalculate_margin_ratio()

    IF margin_ratio >= target_margin_ratio:
        BREAK

    # Шаг 2: Частичное закрытие (20% от позиции)
    close_ratio = 0.20
    for position in sorted_positions_by_loss:
        close_amount = position.size × close_ratio
        execute_market_close(position, close_amount)
        recalculate_margin_ratio()

        IF margin_ratio >= target_margin_ratio:
            BREAK

target_margin_ratio = 1.5 (150% of maintenance)

Пример частичной ликвидации:

Начальное состояние:
- Equity: $10,000
- Позиция: LONG 10 BTC @ $50,000
- MM: $12,500
- Margin_Ratio: 0.8 (ликвидация!)

Шаг 1: Закрываем 20% (2 BTC)
- Реализованный убыток: -$1,000
- Новое Equity: $9,000
- Новая позиция: 8 BTC
- Новый MM: $10,000
- Новый Margin_Ratio: 0.9

Шаг 2: Закрываем ещё 20% (1.6 BTC)
- Реализованный убыток: -$600
- Новое Equity: $8,400
- Новая позиция: 6.4 BTC
- Новый MM: $8,000
- Новый Margin_Ratio: 1.05

Шаг 3: Закрываем ещё 20% (1.28 BTC)
- После закрытия Margin_Ratio > 1.5
- Ликвидация завершена

6.3.3. Полная ликвидация

Применяется, когда частичная ликвидация невозможна или equity становится отрицательным.

Условия полной ликвидации:
1. Margin_Ratio < 0.5 после частичной ликвидации
2. Позиция слишком мала для частичного закрытия
3. Недостаточная ликвидность для частичного закрытия

Процесс:
1. Все позиции закрываются market order'ами
2. Если final_equity > 0: остаток возвращается трейдеру
3. Если final_equity < 0: убыток покрывается Insurance Fund

6.3.4. Страховой фонд (Insurance Fund)

Insurance Fund — последняя линия защиты от социализации убытков.

Структура Insurance Fund:

struct InsuranceFund {
    uint256 balance;                // Текущий баланс
    uint256 targetBalance;          // Целевой баланс
    uint256 utilizationRate;        // Текущее использование
    uint256 replenishmentRate;      // Скорость пополнения

    mapping(bytes32 => uint256) marketReserves; // Резерв по рынкам
}

Формулы Insurance Fund:

Целевой баланс:
target_balance = max(
    total_open_interest × 0.01,     // 1% от OI
    $10,000,000                      // Минимум $10M
)

Пополнение:
- 50% от liquidation_fees
- 10% от trading_fees
- 30% от slashing_penalties

Использование:
deficit = abs(negative_equity_from_liquidation)
IF insurance_fund.balance >= deficit:
    insurance_fund.balance -= deficit
ELSE:
    trigger_adl()  // Auto-Deleveraging

Прозрачность:

Публичные метрики (обновляются каждый блок):
- insurance_fund_balance
- insurance_fund_utilization_24h
- insurance_fund_replenishment_rate
- largest_single_usage
- adl_trigger_distance

6.3.5. Liquidation Fee Structure

6.4. Формула вывода из Vault

6.4.1. Проверка достаточности маржи

Перед выводом средств система проверяет, не нарушит ли вывод маржинальные требования.

def can_withdraw(vault: Vault, amount: uint256) -> bool:
    """
    Проверяет возможность вывода без нарушения маржинальных требований.
    """
    # Текущий equity
    current_equity = vault.get_equity()

    # Equity после вывода
    equity_after = current_equity - amount

    # Требуемая маржа для открытых позиций
    required_margin = 0
    for position in vault.positions:
        required_margin += position.maintenance_margin

    # Минимальный buffer (120% от maintenance)
    min_equity = required_margin * 1.2

    return equity_after >= min_equity


def max_withdrawable(vault: Vault) -> uint256:
    """
    Рассчитывает максимально возможную сумму вывода.
    """
    current_equity = vault.get_equity()
    required_margin = sum(p.maintenance_margin * 1.2 for p in vault.positions)

    return max(0, current_equity - required_margin)

6.4.2. Алгоритм освобождения маржи

Если пользователь хочет вывести больше, чем available_margin, система автоматически освобождает маржу.

Порядок освобождения маржи:

1. Отмена открытых ордеров (от наименьшей к наибольшей маржи)
   freed_margin += cancelled_order.locked_margin

2. Если недостаточно:
   Частичное закрытие позиций (20% increments)
   - Приоритет: позиции с наименьшим unrealized_pnl

3. Если всё ещё недостаточно:
   Полное закрытие наименьших позиций

4. Повторять пока freed_margin >= requested_withdrawal

Пример:

Запрос: вывести $50,000

Текущее состояние:
- Equity: $100,000
- Open orders locked: $20,000
- Positions MM: $40,000
- Available: $100,000 - $40,000 × 1.2 = $52,000

Шаг 1: Можно вывести $50,000 без изменений ✓

Альтернативный сценарий (Available = $30,000):

Шаг 1: Отменяем ордера на $15,000 margin
       Available теперь = $45,000 (недостаточно)

Шаг 2: Закрываем 20% наименьшей прибыльной позиции
       Freed: $8,000 margin
       Available теперь = $53,000 ✓

Вывод $50,000 разрешён

6.4.3. Lock-up период

Для защиты DLP от резких оттоков ликвидности, применяется lock-up период.

Параметры Lock-up:

DLP:
- Lock-up period: 4 дня
- Early withdrawal penalty: 0.5%

User Vaults (устанавливается leader):
- Min lock-up: 0 дней
- Max lock-up: 90 дней
- Early withdrawal penalty: 0-5% (по выбору leader)

Формула withdrawable_at:
withdrawable_at = deposit_timestamp + lock_up_period

Исключения:
- Emergency withdrawal (при критическом vault state) — penalty 2%
- Governance-approved withdrawal — без penalty

6.5. Auto-Deleveraging (ADL)

ADL — механизм последней инстанции, активирующийся когда Insurance Fund недостаточен для покрытия убытков.

6.5.1. Условия активации

ADL активируется когда:

1. Ликвидируемая позиция имеет negative_equity
2. Insurance Fund недостаточен для покрытия:
   insurance_fund.balance < abs(negative_equity)

Формула:
deficit = abs(liquidated_position.equity)
IF deficit > insurance_fund.balance:
    trigger_adl(deficit - insurance_fund.balance)

6.5.2. Ранжирование по PnL и Leverage

Для ADL выбираются противоположные позиции (контрагенты) на основе ранга.

Расчёт ADL Rank:

adl_rank = pnl_percentile × leverage_percentile

pnl_percentile:
- Сортировка всех позиций по unrealized_pnl
- Присвоение percentile (0-100%)
- Позиции с высоким PnL = высокий percentile

leverage_percentile:
- Сортировка по effective_leverage
- Высокий leverage = высокий percentile

Пример:
Позиция A: PnL = +$50,000 (top 10%, percentile = 90)
          Leverage = 15x (top 20%, percentile = 80)
          adl_rank = 0.90 × 0.80 = 0.72

Позиция B: PnL = +$10,000 (top 40%, percentile = 60)
          Leverage = 5x (top 60%, percentile = 40)
          adl_rank = 0.60 × 0.40 = 0.24

Позиция A будет ADL'нута первой

6.5.3. Формула ADL

ADL Amount Calculation:

remaining_deficit = deficit - insurance_fund.balance

FOR counterparty IN sorted_by_adl_rank(counterparties):
    adl_amount = min(
        counterparty.position_size,
        remaining_deficit / mark_price
    )

    # Закрытие части позиции контрагента
    close_position(counterparty, adl_amount, liquidation_price)

    remaining_deficit -= adl_amount × mark_price

    IF remaining_deficit <= 0:
        BREAK

Компенсация ADL-контрагентам:

ADL Premium (частичная компенсация):
- ADL'нутые позиции закрываются по mark_price
- Дополнительно: 0.1% premium от закрытого размера
- Источник premium: будущие trading fees

Notification:
- ADL риск отображается в UI (light indicator)
- Трейдеры с высоким ADL rank получают warning

6.6. Risk Management

6.6.1. Dynamic Open Interest Limits

Уроки из JELLY incident: ограничение концентрации позиций в отдельных активах.

Расчёт Max Open Interest:

max_oi(asset) = min(
    market_cap × oi_ratio,
    daily_volume × volume_ratio,
    liquidity_depth × depth_ratio
)

Параметры:
- oi_ratio = 0.05 (5% от market cap)
- volume_ratio = 0.5 (50% от daily volume)
- depth_ratio = 10x (10x от orderbook depth ±2%)

Пример для low-cap токена:
- Market Cap: $50M
- Daily Volume: $5M
- Liquidity Depth (±2%): $500K

max_oi = min($50M × 0.05, $5M × 0.5, $500K × 10)
       = min($2.5M, $2.5M, $5M)
       = $2.5M

Любая позиция > $2.5M будет отклонена.

6.6.2. Caps на аллокацию в Liquidation Vault

Лимиты для DLP:

max_single_position = dlp_tvl × 0.05  // 5% max на одну позицию
max_asset_exposure = dlp_tvl × 0.15  // 15% max на один актив
max_net_exposure = dlp_tvl × 0.30    // 30% max net long/short

Пример для DLP с TVL = $100M:
- max_single_position = $5M
- max_asset_exposure = $15M (все BTC позиции)
- max_net_exposure = $30M (delta)

6.6.3. Защита от манипуляций

Oracle Manipulation Detection:

Детекция аномалий:

price_deviation = abs(new_price - twap_5min) / twap_5min

IF price_deviation > 0.10:  // >10% отклонение
    flag_suspicious()
    use_fallback_oracle()

IF price_deviation > 0.20:  // >20% отклонение
    halt_new_positions()
    notify_risk_committee()

Circuit Breakers:

Автоматическая остановка торгов:

Level 1 (5 min halt):
- Price move > 15% за 5 минут
- Действие: пауза на 5 минут

Level 2 (1 hour halt):
- Price move > 25% за 15 минут
- Действие: пауза на 1 час, увеличение margins

Level 3 (Manual intervention):
- Price move > 40% за 1 час
- Действие: ручное рассмотрение, возможно — settle по TWAP

Unusual Activity Monitoring:

Мониторинг подозрительной активности:

1. Large position concentration
   - Alert if single account > 10% of market OI

2. Wash trading detection
   - Matching trades from same entity

3. Spoofing detection
   - Large orders cancelled within 100ms

4. Cross-market manipulation
   - Coordinated moves in spot + perp

7. Confidential Compute Layer

Confidential Compute Layer (CCL) — это инновационный компонент DeflationChain, обеспечивающий приватные вычисления с верифицируемой целостностью. DeflationChain значительно превосходит архитектуру проекта Cocoon (TON), устраняя его главный недостаток — централизованные proxy-серверы. В нашей реализации proxy-узлы являются валидаторами с PoD-стейком, что обеспечивает экономическую мотивацию честного поведения и true децентрализацию. CCL использует технологии Intel TDX и SGX для аппаратной защиты пользовательских данных и AI-моделей.

7.1. Обзор

7.1.1. Назначение Confidential Compute Layer

CCL решает фундаментальную проблему децентрализованных вычислений: как выполнять сложные вычисления (включая AI inference) с гарантией того, что:

1. Приватность данных: Входные данные пользователя не видны оператору вычислительного узла
2. Целостность вычислений: Результат действительно получен от указанной модели/алгоритма
3. Защита моделей: Веса AI-моделей защищены от копирования
4. Верифицируемость: Любой может проверить, что вычисления выполнены корректно

Основные use-cases:

7.1.2. Интеграция с DeflationChain

CCL интегрирован в DeflationChain как опциональный слой, доступный для приложений, требующих приватности:

Поток выполнения конфиденциальных вычислений:

1. User → CCL Gateway: Зашифрованный запрос + оплата в DEF
2. CCL Gateway → Worker Selection: Выбор TDX VM по доступности/локации
3. Gateway → Worker: Forwarding encrypted request
4. Worker: Attestation + Decryption + Computation
5. Worker → Gateway: Encrypted result + Attestation proof
6. Gateway: Verification + Settlement
7. Gateway → User: Encrypted result
8. On-chain: Payment distribution + Usage logging

7.1.3. Сравнение с Cocoon

DeflationChain CCL использует более гибкую и мощную архитектуру, чем Cocoon:

7.2. Технические компоненты

7.2.1. Intel TDX Integration

Intel Trust Domain Extensions (TDX) — это технология аппаратной изоляции, обеспечивающая защиту виртуальных машин от компрометации хост-системы.

Требования к оборудованию:

Hardware Requirements:

CPU:
- Intel Xeon Scalable (4th Gen "Sapphire Rapids" или новее)
- TDX поддержка (проверить через CPUID)
- Minimum: 32 cores, рекомендуется 64+ cores

Memory:
- DDR5 с поддержкой encryption (TME-MK)
- Minimum: 256 GB RAM
- ECC обязательно

BIOS/Firmware:
- TDX enabled в BIOS
- Latest microcode updates
- Secure Boot enabled

Software:
- Linux Kernel 6.16+ с TDX patches
- QEMU/KVM с TDX support
- Custom TDX Guest Image (DeflationChain-certified)

Архитектура TDX Guest VM:

Гарантии безопасности TDX:

TDX Security Properties:

1. Memory Encryption (TME-MK):
   - Вся память VM зашифрована уникальным ключом
   - Ключ генерируется TDX Module, недоступен для хоста
   - AES-128-XTS encryption

2. Execution Isolation:
   - VM изолирована от hypervisor
   - Hypervisor не может читать/писать память VM
   - Interrupt injection ограничен

3. Remote Attestation:
   - Cryptographic proof конфигурации VM
   - Включает: measurements, RTMR registers, TD Quote
   - Верифицируется против Intel attestation service

4. Integrity Protection:
   - Детекция tampering с кодом/данными
   - Replay protection для attestation

7.2.2. SGX Seal Server

SGX Seal Server — это специализированный сервис для управления криптографическими ключами с использованием Intel SGX enclaves.

Назначение:

SGX Seal Server Functions:

1. Key Generation:
   - Генерация ключей внутри SGX enclave
   - Ключи никогда не покидают enclave в открытом виде

2. Key Sealing:
   - Шифрование ключей с привязкой к hardware identity
   - Персистентность между перезагрузками
   - Поддержка key rotation

3. Key Derivation:
   - Детерминированная генерация ключей из master secret
   - Hierarchical key structure (master → domain → session)

4. Attestation Service:
   - Выдача attestation quotes для TDX VMs
   - Верификация worker identity

Архитектура Seal Server:

API Seal Server:

service SealServer {
    // Generate new key pair inside enclave
    rpc GenerateKeyPair(GenerateRequest) returns (GenerateResponse);

    // Seal key for persistent storage
    rpc SealKey(SealRequest) returns (SealResponse);

    // Unseal previously sealed key
    rpc UnsealKey(UnsealRequest) returns (UnsealResponse);

    // Derive child key from master
    rpc DeriveKey(DeriveRequest) returns (DeriveResponse);

    // Get attestation quote for verification
    rpc GetQuote(QuoteRequest) returns (QuoteResponse);

    // Verify attestation of another enclave/TDX VM
    rpc VerifyAttestation(VerifyRequest) returns (VerifyResponse);
}

message GenerateRequest {
    KeyType key_type = 1;  // ECDSA, Ed25519, AES256, etc.
    string purpose = 2;     // "signing", "encryption", "session"
}

message QuoteResponse {
    bytes quote = 1;        // SGX/TDX quote (attestation proof)
    bytes public_key = 2;   // Enclave's public key
    bytes signature = 3;    // Signature over quote
}

7.2.3. RA-TLS (Remote Attestation over TLS)

RA-TLS — это протокол, интегрирующий remote attestation в стандартный TLS handshake, позволяя клиентам верифицировать, что они общаются с подлинным TEE.

Принцип работы:

RA-TLS Handshake Flow:

Client                                          TDX Worker
   │                                                 │
   │  ─────────── ClientHello ──────────────────▶   │
   │                                                 │
   │  ◀─────────── ServerHello ──────────────────   │
   │               + Certificate(RA-TLS)            │
   │               + ServerKeyExchange              │
   │               + CertificateRequest             │
   │                                                 │
   │  [Verify RA-TLS Certificate]                   │
   │    1. Extract TDX Quote from cert extension    │
   │    2. Verify Quote signature (Intel)           │
   │    3. Check RTMR values against allowlist      │
   │    4. Verify Quote freshness (timestamp)       │
   │                                                 │
   │  ─────────── Certificate ──────────────────▶   │
   │              ClientKeyExchange                 │
   │              ChangeCipherSpec                  │
   │              Finished                          │
   │                                                 │
   │  ◀─────────── ChangeCipherSpec ─────────────   │
   │               Finished                         │
   │                                                 │
   │  ═══════════ Encrypted Channel ═══════════   │
   │                                                 │

Структура RA-TLS сертификата:

X.509 Certificate with RA-TLS Extensions:

Certificate:
    Version: 3
    Serial Number: <random>
    Signature Algorithm: ECDSA-SHA256
    Issuer: CN=TDX Worker, O=DeflationChain
    Validity:
        Not Before: <now>
        Not After: <now + 1 hour>
    Subject: CN=TDX Worker <worker_id>
    Subject Public Key Info:
        Algorithm: ECDSA P-256
        Public Key: <ephemeral_public_key>

    X509v3 Extensions:
        1.2.3.4.1 (TDX Quote): <base64_encoded_quote>
            - RTMR[0]: <hash of firmware>
            - RTMR[1]: <hash of kernel>
            - RTMR[2]: <hash of application>
            - RTMR[3]: <hash of user data>
            - Report Data: <public_key_hash>

        1.2.3.4.2 (Worker Info):
            - Worker ID: <uuid>
            - Country: <iso_country_code>
            - Capabilities: [LLM, ImageGen, ...]

        1.2.3.4.3 (Timestamp):
            - Quote Generation Time: <unix_timestamp>
            - Valid Until: <unix_timestamp + validity_period>

Верификация на клиенте:

def verify_ra_tls_cert(cert: X509Certificate, trusted_measurements: List[bytes]) -> bool:
    """
    Verify RA-TLS certificate authenticity.
    """
    # 1. Extract TDX Quote from certificate extension
    quote = extract_quote_extension(cert, OID_TDX_QUOTE)

    # 2. Verify Quote signature (Intel's attestation key)
    if not verify_intel_signature(quote):
        return False

    # 3. Check measurements against allowlist
    rtmr_values = extract_rtmr(quote)
    for i, rtmr in enumerate(rtmr_values):
        if rtmr not in trusted_measurements[i]:
            return False

    # 4. Verify public key binding
    report_data = extract_report_data(quote)
    cert_pubkey_hash = sha256(cert.public_key)
    if report_data[:32] != cert_pubkey_hash:
        return False

    # 5. Check freshness
    quote_time = extract_timestamp(quote)
    if time.now() - quote_time > MAX_QUOTE_AGE:
        return False

    return True

7.2.4. GPU Attestation

Для AI inference требуется поддержка GPU. DeflationChain CCL поддерживает NVIDIA Confidential Computing.

Требования к GPU:

Supported GPUs:

NVIDIA Hopper Architecture:
- H100 SXM5 (80GB HBM3)
- H100 PCIe (80GB HBM3)

Requirements:
- NVIDIA Confidential Computing mode enabled
- GPU Driver 535+ with CC support
- CUDA 12.2+

Attestation:
- GPU attestation через NVIDIA Attestation Service
- Verification of GPU firmware integrity
- Secure channel between CPU TEE и GPU

GPU Attestation Flow:

7.3. Root Contract для Confidential Compute

7.3.1. Обзор Root Contract

Root Contract — это on-chain реестр, хранящий информацию о разрешённых конфигурациях, моделях и workers для CCL.

Структура контракта:

// SPDX-License-Identifier: MIT
pragma solidity ^0.8.20;

contract ConfidentialComputeRegistry {
    // ============ Structures ============

    struct TDXImage {
        bytes32 imageHash;          // Hash of TDX VM image
        string version;             // Semantic version
        bool isActive;              // Can be used for new deployments
        uint256 registeredAt;       // Registration timestamp
        address registeredBy;       // Who registered (governance)
    }

    struct AIModel {
        bytes32 modelHash;          // Hash of model weights
        string name;                // Human-readable name
        string modelType;           // "llm", "image", "audio", etc.
        uint256 inputPricePerToken; // Price per input token (DEF wei)
        uint256 outputPricePerToken;// Price per output token
        bool isActive;
        address owner;              // Model owner (receives royalties)
    }

    struct Worker {
        address workerAddress;      // On-chain identity
        bytes32 countryCode;        // ISO 3166-1 alpha-2
        bytes publicKey;            // Worker's public key (for encryption)
        bytes32 currentQuoteHash;   // Latest attestation quote hash
        uint256 lastAttestationTime;
        WorkerStatus status;
        uint256 totalComputeUnits;  // Lifetime compute delivered
        uint256 stakeAmount;        // Staked DEF
    }

    struct Proxy {
        address proxyAddress;
        string endpoint;            // URL for client connections
        bytes32[] supportedCountries;
        bool isActive;
    }

    enum WorkerStatus {
        Inactive,
        Pending,
        Active,
        Suspended,
        Slashed
    }

    // ============ State Variables ============

    // Allowed TDX images (hash => TDXImage)
    mapping(bytes32 => TDXImage) public allowedImages;
    bytes32[] public imageHashes;

    // Registered AI models (hash => AIModel)
    mapping(bytes32 => AIModel) public registeredModels;
    bytes32[] public modelHashes;

    // Registered workers (address => Worker)
    mapping(address => Worker) public workers;
    address[] public workerAddresses;

    // Workers by country (countryCode => worker addresses)
    mapping(bytes32 => address[]) public workersByCountry;

    // Proxy endpoints
    mapping(address => Proxy) public proxies;
    address[] public proxyAddresses;

    // Governance parameters
    uint256 public minWorkerStake = 10000 * 10**18; // 10,000 DEF
    uint256 public attestationValidityPeriod = 24 hours;
    uint256 public slashingPenalty = 1000 * 10**18; // 1,000 DEF

    // ============ Events ============

    event ImageRegistered(bytes32 indexed imageHash, string version);
    event ImageDeactivated(bytes32 indexed imageHash);
    event ModelRegistered(bytes32 indexed modelHash, string name, address owner);
    event WorkerRegistered(address indexed worker, bytes32 countryCode);
    event WorkerAttestationUpdated(address indexed worker, bytes32 quoteHash);
    event WorkerSlashed(address indexed worker, uint256 amount, string reason);
    event ComputeCompleted(
        address indexed worker,
        bytes32 indexed modelHash,
        uint256 inputTokens,
        uint256 outputTokens,
        uint256 payment
    );

    // ============ Functions ============

    function registerImage(
        bytes32 imageHash,
        string calldata version
    ) external onlyGovernance {
        require(allowedImages[imageHash].registeredAt == 0, "Already registered");

        allowedImages[imageHash] = TDXImage({
            imageHash: imageHash,
            version: version,
            isActive: true,
            registeredAt: block.timestamp,
            registeredBy: msg.sender
        });

        imageHashes.push(imageHash);
        emit ImageRegistered(imageHash, version);
    }

    function registerWorker(
        bytes32 countryCode,
        bytes calldata publicKey,
        bytes calldata initialQuote
    ) external payable {
        require(msg.value >= minWorkerStake, "Insufficient stake");
        require(workers[msg.sender].workerAddress == address(0), "Already registered");
        require(
            workersByCountry[countryCode].length == 0,
            "Country slot occupied"
        );

        // Verify initial attestation quote
        bytes32 quoteHash = keccak256(initialQuote);
        require(verifyQuote(initialQuote), "Invalid attestation");

        workers[msg.sender] = Worker({
            workerAddress: msg.sender,
            countryCode: countryCode,
            publicKey: publicKey,
            currentQuoteHash: quoteHash,
            lastAttestationTime: block.timestamp,
            status: WorkerStatus.Active,
            totalComputeUnits: 0,
            stakeAmount: msg.value
        });

        workerAddresses.push(msg.sender);
        workersByCountry[countryCode].push(msg.sender);

        emit WorkerRegistered(msg.sender, countryCode);
    }

    function updateAttestation(bytes calldata quote) external {
        Worker storage worker = workers[msg.sender];
        require(worker.status == WorkerStatus.Active, "Worker not active");
        require(verifyQuote(quote), "Invalid attestation");

        worker.currentQuoteHash = keccak256(quote);
        worker.lastAttestationTime = block.timestamp;

        emit WorkerAttestationUpdated(msg.sender, worker.currentQuoteHash);
    }

    function recordCompute(
        address workerAddr,
        bytes32 modelHash,
        uint256 inputTokens,
        uint256 outputTokens
    ) external onlyProxy {
        Worker storage worker = workers[workerAddr];
        AIModel storage model = registeredModels[modelHash];

        require(worker.status == WorkerStatus.Active, "Worker not active");
        require(model.isActive, "Model not active");
        require(
            block.timestamp - worker.lastAttestationTime <= attestationValidityPeriod,
            "Attestation expired"
        );

        uint256 payment = inputTokens * model.inputPricePerToken +
                          outputTokens * model.outputPricePerToken;

        // Update worker stats
        worker.totalComputeUnits += inputTokens + outputTokens;

        // Distribute payment
        uint256 workerShare = payment * 70 / 100;  // 70% to worker
        uint256 modelOwnerShare = payment * 20 / 100; // 20% to model owner
        uint256 protocolShare = payment * 10 / 100;   // 10% to protocol

        // Transfer payments...

        emit ComputeCompleted(workerAddr, modelHash, inputTokens, outputTokens, payment);
    }

    function slashWorker(
        address workerAddr,
        string calldata reason
    ) external onlyGovernance {
        Worker storage worker = workers[workerAddr];
        require(worker.status == WorkerStatus.Active, "Worker not active");

        uint256 slashAmount = min(worker.stakeAmount, slashingPenalty);
        worker.stakeAmount -= slashAmount;
        worker.status = WorkerStatus.Slashed;

        // 50% burned, 50% to treasury
        // ...

        emit WorkerSlashed(workerAddr, slashAmount, reason);
    }

    function verifyQuote(bytes calldata quote) internal view returns (bool) {
        // 1. Parse quote structure
        // 2. Verify Intel signature
        // 3. Check RTMR values against allowed images
        // 4. Verify timestamp freshness
        // Implementation depends on attestation library
        return true; // Simplified
    }
}

7.3.2. Worker Registration Process

7.3.3. Model Registration

Model Registration Flow:

1. Model Owner prepares model:
   - Train/fine-tune model
   - Export to supported format (ONNX, SafeTensors, etc.)
   - Calculate model hash: sha256(weights || config)

2. Encrypt model for distribution:
   - Generate content encryption key (CEK)
   - Encrypt model: AES-256-GCM(model, CEK)
   - Encrypt CEK for each worker: ECIES(CEK, worker_pubkey)

3. Upload to decentralized storage:
   - IPFS / Arweave / Filecoin
   - Distribute encrypted CEKs to workers

4. Register on-chain:
   registerModel(
       modelHash,
       name,
       modelType,
       inputPrice,
       outputPrice,
       contentURI
   )

5. Workers download and verify:
   - Fetch encrypted model from storage
   - Decrypt CEK using worker private key (inside TDX)
   - Decrypt model
   - Verify hash matches registered modelHash
   - Load model into inference runtime

7.4. Pricing Model

7.4.1. Compute Pricing

7.4.2. Staking Requirements

Worker Staking:

Minimum Stake: 10,000 DEF

Stake Functions:
1. Slashing collateral (for misbehavior)
2. Quality of service guarantee
3. Economic alignment with network

Slashing Conditions:
- Invalid attestation: 10% of stake
- Prolonged downtime (>24h): 5% of stake
- Incorrect computation (proven): 20% of stake
- Data leak (proven): 100% of stake

Unstaking:
- Unbonding period: 30 days
- Can exit during unbonding (forfeit pending rewards)

8. Дефляционная экономическая модель

Дефляционная экономическая модель — это фундамент DeflationChain, унаследованный и расширенный от оригинального DeflationCoin на BSC. Модель обеспечивает непрерывное сокращение циркулирующего предложения токенов, создавая долгосрочное дефляционное давление на предложение и, теоретически, положительное влияние на стоимость.

8.1. Ежедневное смарт-сжигание

8.1.1. Механизм BalancePortions

Ключевая инновация DeflationCoin — система BalancePortions, которая отслеживает время получения каждой порции токенов и применяет прогрессивное сжигание.

Структура BalancePortion:

struct BalancePortion {
    uint256 amount;     // Количество токенов в порции
    uint256 timestamp;  // Время получения порции
}

// Каждый адрес хранит массив порций
mapping(address => BalancePortion[]) private _balancePortions;

Принцип работы:

При получении токенов:
1. Создаётся новая BalancePortion с текущим timestamp
2. Порция добавляется в массив адреса

При отправке токенов:
1. Вызывается refresh_balance() для актуализации баланса
2. Эффективный баланс = Σ(portion.amount × getMultiplier(portion.timestamp))
3. Разница между номинальным и эффективным балансом — "сожжённая" часть
4. 50% разницы уничтожается навсегда
5. 50% разницы направляется в dividend pool

Логика расходования порций (FIFO):
1. Сначала расходуются самые старые порции
2. Старые порции имеют меньший effective_amount
3. Пользователь теряет меньше при использовании "свежих" токенов

Пример:

День 0: Пользователь получает 1,000 DEF
        BalancePortions = [{amount: 1000, timestamp: Day0}]
        Effective balance = 1000 × 100% = 1,000 DEF

День 3: Пользователь получает ещё 500 DEF
        BalancePortions = [
          {amount: 1000, timestamp: Day0},
          {amount: 500, timestamp: Day3}
        ]
        Effective balance = 1000 × 93% + 500 × 100% = 930 + 500 = 1,430 DEF
        Номинальный баланс = 1,500 DEF
        "Сожжено" = 70 DEF

День 5: Пользователь хочет отправить 1,200 DEF
        Сначала refresh_balance():
        - Порция 1: 1000 × 71% = 710 DEF effective
        - Порция 2: 500 × 97% = 485 DEF effective
        - Total effective = 1,195 DEF

        ОШИБКА: Недостаточно средств для отправки 1,200 DEF!
        Максимум можно отправить 1,195 DEF

8.1.2. Принцип удвоения (Doubling Burn)

Система ежедневного сжигания (Daily Smart Burn) использует принцип удвоения: каждые сутки процент сжигания от текущего остатка удваивается. Это создаёт экспоненциальное давление на неактивных держателей, при этом давая достаточно времени для реакции в первые дни.

Ключевые характеристики принципа удвоения:

• Мягкий старт: в первые дни потери минимальны (1%, 2%, 4%), что даёт пользователям время заметить проблему
• Ускорение к середине: на 4-6 день сжигание становится ощутимым (8%, 16%, 32% от остатка)
• Жёсткий финиш: на 7-8 день потери критические (64%, 100%), делая полное бездействие невыгодным
• Чёткий дедлайн: 8 дней — максимальный срок жизни неактивных токенов

Данный подход стимулирует одно из двух действий: застейкать токены (полная защита + дивиденды) или регулярно использовать их (сброс таймера сжигания при каждой транзакции).

Полная таблица:

Принцип удвоения создаёт характерную S-образную кривую потерь: пологий участок в начале (дни 1-3, потеряно ~7%), крутой спуск в середине (дни 4-6, теряется основная масса) и финальное обнуление (дни 7-8). Эта форма кривой оптимальна для баланса между защитой забывчивых пользователей и эффективным сжиганием «мёртвых» токенов.

Функция getBurnRate:

Данная функция реализует on-chain логику определения процента сжигания на основе возраста порции баланса. Функция оптимизирована для минимального расхода gas и использует предвычисленный массив значений.

function getBurnRate(uint256 timestamp) public view returns (uint256) {
    uint256 daysElapsed = (block.timestamp - timestamp) / 86400;

    if (daysElapsed == 0) return 0;    // 0% сжигания
    if (daysElapsed >= 8) return 100;  // 100% сжигания

    // burnRate индексируется с 1 дня
    // burnRate = [1, 3, 7, 15, 29, 52, 83]
    // burnRate[0] = 1 (день 1 → 1% сжигания)
    return burnRate[daysElapsed - 1];
}

function getPreservedRate(uint256 timestamp) public view returns (uint256) {
    return 100 - getBurnRate(timestamp);  // Сохранённая часть
}

Реализация использует целочисленную арифметику с точностью до процента. Для более точных вычислений в финансовых операциях может применяться масштабирование с коэффициентом 10^18.

Математическая модель сжигания:

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

Пусть N(t) — номинальный баланс пользователя в момент t
Пусть P_i — i-я порция с timestamp t_i и amount a_i

Коэффициент сохранения:
S(d) = (100 - burnRate[min(d, 8)]) / 100

Эффективный баланс:
E(t) = Σ_i (a_i × S(t - t_i))

где burnRate = [0, 1, 3, 7, 15, 29, 52, 83, 100]

Сумма сжигания:
Burned(t) = N(t) - E(t) = Σ_i (a_i × burnRate[min(t - t_i, 8)] / 100)

Поскольку S(d) — ступенчатая функция, сжигание происходит дискретно при переходе через границы дней. Это означает, что обновление баланса можно откладывать без потери точности — итоговый результат будет идентичен ежедневному обновлению.

8.1.3. Распределение сожжённого

При каждом refresh_balance() разница между номинальным и эффективным балансом распределяется:

refresh_balance() logic:

previous_nominal = sum(portions[].amount)
effective = sum(portions[].amount × getMultiplier(portions[].timestamp))

diff = previous_nominal - effective

if (diff > 0):
    burned = diff / 2          // 50% уничтожается навсегда
    to_dividend = diff / 2     // 50% в dividend pool

    totalSupply -= burned
    dividendPool += to_dividend

    emit Burned(burned)
    emit DividendPoolIncreased(to_dividend)

Годовая статистика сжигания (прогноз):

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

Сценарий 1: Активные трейдеры (среднее удержание 3 дня)
─────────────────────────────────────────────────────────
- Средний процент сжигания = (0 + 1 + 3 + 7) / 4 = 2.75%
- При 120 торговых циклов в год:
  Сохранённая доля = (1 - 0.0275)^120 ≈ 3.5% потеряно

Сценарий 2: Умеренно активные (среднее удержание 5 дней)
─────────────────────────────────────────────────────────
- Средний процент сжигания = (0 + 1 + 3 + 7 + 15 + 29) / 6 = 9.2%
- При 72 циклов в год: значительные потери

Сценарий 3: Пассивные держатели (удержание 8+ дней)
─────────────────────────────────────────────────────────
- Полное сжигание через 8 дней
- Стимул: ОБЯЗАТЕЛЬНО стейкать или переводить

Стратегии защиты от сжигания:
1. Стейкинг — полная защита + дивиденды
2. Активная торговля — обнуление таймера при каждой операции
3. Регулярные переводы — periodic reset

Данная модель создаёт уникальное экономическое давление: пассивное удержание («hodl» без стейкинга) экономически невыгодно, в то время как активное участие в экосистеме через стейкинг или торговлю вознаграждается защитой капитала.

8.2. Смарт-комиссии

8.2.1. Стандартная комиссия (5%)

При каждом переводе DEF взимается комиссия 5%, которая распределяется следующим образом:

Стандартный transfer (без реферала):

total_commission = amount × 5%

Распределение:





Получатель
Доля
Назначение




Burn
1% (20%)
Уничтожение токенов


Dividend Pool
1% (20%)
Дивиденды стейкерам


Technical Pool
1% (20%)
Развитие протокола


Marketing Pool
2% (40%)
Маркетинг и продвижение






Пример:
- Transfer: 10,000 DEF
- Commission: 500 DEF
  - Burn: 100 DEF
  - Dividend Pool: 100 DEF
  - Technical Pool: 100 DEF
  - Marketing Pool: 200 DEF
- Recipient receives: 9,500 DEF

8.2.2. Реферальная комиссия (4.5%)

При наличии реферала комиссия снижается до 4.5%, а половина идёт рефереру:

8.2.3. Исключения из комиссий

Адреса, освобождённые от комиссий:
- Staking contract (при стейкинге/анстейкинге)
- Dividend Pool (при распределении)
- Trading Core (для эффективной торговли)
- Bridge contracts (при миграции)
- Validator rewards distribution

Проверка в _transfer():
if (excludedFromFee[sender] || excludedFromFee[recipient]) {
    fee = 0;
}

8.3. Смарт-стейкинг

8.3.1. xMultipliers

xMultipliers определяют бонус к дивидендам в зависимости от срока стейкинга:

xMultipliers = [1, 2, 3, 4, 5, 6, 7, 10, 12, 14, 16, 20]

8.3.2. Механизм “Захват внимания” (Attention Grabbing)

При создании стейка на срок менее 12 лет, 1% от суммы автоматически стейкается на 12 лет:

Attention Grabbing Logic:

function stake(uint256 amount, uint256 years) {
    require(years >= 1 && years <= 12, "Invalid staking period");

    if (years < 12) {
        // 1% автоматически на 12 лет
        uint256 attentionGrab = amount / 100;
        uint256 mainStake = amount - attentionGrab;

        _createStake(msg.sender, mainStake, years);
        _createStake(msg.sender, attentionGrab, 12);
    } else {
        _createStake(msg.sender, amount, 12);
    }
}

Пример:
Пользователь стейкает 10,000 DEF на 4 года:
- Main stake: 9,900 DEF на 4 года (4x multiplier)
- Attention grab: 100 DEF на 12 лет (20x multiplier)

Эффект:
- Пользователь "привязан" к проекту на 12 лет через мини-стейк
- Даже после окончания 4-летнего стейка, остаётся 12-летний
- Создаёт психологическую связь с проектом

8.3.3. Структура StakePosition

Каждая стейкинг-позиция представлена структурой StakePosition, хранящей всю необходимую информацию для расчёта дивидендов, отслеживания выводов и управления сроками блокировки. Структура оптимизирована для gas-эффективности: все временные параметры хранятся как uint256 для совместимости с block.timestamp, а финансовые показатели используют полную точность Wei (10^18).

Ключевая особенность — разделение amount и finishedAmount: первое отслеживает текущую заблокированную сумму (уменьшается при ежемесячных выводах), второе — сумму, доступную для плавного разлока после окончания срока стейкинга. Это позволяет пользователям получать частичную ликвидность в течение срока стейка, сохраняя при этом право на дивиденды.

struct StakePosition {
    uint256 initialAmount;      // Начальная сумма стейка (неизменна)
    uint256 amount;             // Текущая сумма (может уменьшаться при выводах)
    uint256 finishedAmount;     // Сумма для плавного разлока после окончания
    uint256 startTime;          // Unix timestamp создания стейка
    uint256 year;               // Срок стейкинга (1-12 лет)
    uint256 lastClaimed;        // Последний клейм дивидендов (формат YYYYMM)
    uint256 claimedStaking;     // Выведено из основной суммы в текущем месяце
    uint256 claimedDividends;   // Выведено дивидендов в текущем месяце
}

// Каждый пользователь может иметь несколько стейк-позиций
mapping(address => StakePosition[]) private _stakes;

Поле lastClaimed использует формат YYYYMM (например, 202501 для января 2025), что позволяет эффективно проверять, были ли уже получены дивиденды за текущий месяц. Поля claimedStaking и claimedDividends сбрасываются в ноль при переходе к новому месяцу, обеспечивая свежие лимиты на вывод.

8.3.4. Ежемесячный вывод из стейка

Уникальная особенность DeflationChain — возможность частичного вывода из активного стейка без потери статуса и накопленных привилегий. В отличие от большинства PoS-систем, требующих полного анстейкинга для получения ликвидности, DeflationChain позволяет стейкерам выводить до 1/N от суммы каждый месяц, где N — общее количество месяцев стейка.

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

8.3.5. Плавный разлок после окончания

Механизм плавного разлока (Gradual Unlock) является ключевым элементом защиты цены токена от резких колебаний. После окончания срока стейкинга токены не возвращаются пользователю мгновенно, а разлокаются постепенно в течение периода, пропорционального сроку стейка.

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

Формула плавного разлока:

unlock_period = stake.year × 30 дней
daily_unlock = stake.finishedAmount / unlock_period

Временные рамки:
- 1-летний стейк: разлок за 30 дней  (3.33% в день)
- 4-летний стейк: разлок за 120 дней (0.83% в день)
- 12-летний стейк: разлок за 360 дней (0.28% в день)

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

8.4. Дивидендная система

8.4.1. Beta-индикатор

Beta (β) — это глобальный показатель, используемый для расчёта доли каждого стейкера в дивидендном пуле:

β = Σ(stake.amount × xMultipliers[stake.year - 1])

Для всех активных стейков в системе.

Пример расчёта β:
Stake 1: 10,000 DEF × 4x (4 года) = 40,000
Stake 2: 5,000 DEF × 12x (9 лет) = 60,000
Stake 3: 20,000 DEF × 1x (1 год) = 20,000
...
β = 40,000 + 60,000 + 20,000 + ... = суммарный weighted stake

8.4.2. Формула дивидендов

Пример расчёта:

- poolSnapshot = баланс dividend pool на начало периода - β = суммарный beta всех стейков Пример: - Стейк: 10,000 DEF на 8 лет (10x multiplier) - poolSnapshot = 100,000 DEF (месячный дивидендный пул) - β = 5,000,000 (суммарный weighted stake сети) D = (10,000 × 10 × 100,000) / 5,000,000 D = 10,000,000,000 / 5,000,000 D = 2,000 DEF Стейкер получит 2,000 DEF дивидендов за период.

8.4.3. Периодичность и snapshot

Дивидендный цикл:

1. Snapshot (1-е число каждого месяца, 00:00 UTC):
   - Фиксируется poolSnapshot = dividend_pool.balance
   - Фиксируется β = sum of all weighted stakes
   - Записывается в контракт как snapshot[month]

2. Claim period (весь месяц):
   - Стейкеры могут клеймить дивиденды
   - Дивиденды рассчитываются по формуле выше
   - При клейме: stake.claimedDividends увеличивается

3. Next month:
   - Новый snapshot
   - claimedDividends сбрасывается для всех
   - Невостребованные дивиденды остаются в пуле

Auto-compound option:
- Пользователь может включить auto-stake для дивидендов
- Дивиденды автоматически добавляются к существующему стейку
- Увеличивает S.amount без создания новой позиции

8.5. Tokenomics Overview

8.5.1. Источники сжигания

Сжигание токенов происходит из множества источников:

8.5.2. Модель предложения

Supply Model:

Initial Supply (при миграции с BSC): S_0

Годовое изменение предложения:
S(t+1) = S(t) - B(t) + R(t)

Где:
- B(t) = суммарное сжигание за год
- R(t) = награды валидаторам (инфляционный компонент)

Target: B(t) > R(t) → нетто-дефляция

Оценка годового сжигания:
- Daily burn (avg 5% циркуляции × 10% loss × 50%): ~2.5% годовых
- Commission burn: ~0.5% годовых
- Trading/Gas burn: ~1% годовых
- Total burn: ~4% годовых

Инфляция от validator rewards: ~2% годовых

Net deflation: ~2% годовых (при нормальной активности)

8.5.3. Long-term Equilibrium

Долгосрочное равновесие:

По мере уменьшения supply:
1. Цена за токен растёт (при постоянном demand)
2. Абсолютное сжигание уменьшается (тот же %)
3. Скорость дефляции замедляется

Асимптотическое поведение:
- Supply стремится к некоторому S_min
- S_min определяется балансом:
  burned_from_circulation = validator_rewards + network_growth

Защита от hyper-deflation:
- Governance может регулировать параметры сжигания (burnRate)
- Emergency mechanism для снижения burn rate
- Не предполагается достижение 0 supply

9. Сетевой уровень

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

9.1. P2P протокол

9.1.1. Базовая архитектура

DeflationChain использует libp2p как фундамент для P2P коммуникаций, обеспечивая модульность и совместимость с существующей инфраструктурой.

Стек протоколов:

Поддерживаемые транспорты:

9.1.2. GossipSub Protocol

GossipSub — это протокол распространения сообщений в P2P сетях, разработанный Protocol Labs для libp2p. DeflationChain использует GossipSub v1.1 с дополнительными оптимизациями для торговых данных с низкой задержкой.

Принцип работы GossipSub основан на mesh-топологии: каждый узел поддерживает небольшое количество прямых соединений (mesh peers, обычно 8) для каждого топика. Сообщения распространяются через mesh с flood publishing для приоритетных данных. Дополнительно, узлы “сплетничают” (gossip) о недавних сообщениях с peers вне mesh, обеспечивая устойчивость к отказам mesh-соединений.

Критическое преимущество GossipSub — субсекундное распространение даже в глобальных сетях. Для DeflationChain это означает, что консенсусные сообщения достигают всех валидаторов за 200ms, блоки распространяются по всей сети за секунду, а торговые обновления доставляются за 50-100ms.

Топики (channels):

DeflationChain организует сообщения по топикам (channels), каждый со своей семантикой и политикой распространения. Block и consensus топики используют flood publishing для максимальной надёжности, trading топики оптимизированы для низкой latency.

DeflationChain GossipSub Topics:

/deflationchain/1.0.0/blocks
  - Новые блоки
  - Publishers: block proposers
  - Subscribers: все ноды

/deflationchain/1.0.0/transactions
  - Pending транзакции
  - Publishers: любой участник
  - Subscribers: валидаторы, full nodes

/deflationchain/1.0.0/consensus
  - Consensus messages (prevote, precommit)
  - Publishers: валидаторы
  - Subscribers: валидаторы

/deflationchain/1.0.0/attestations
  - Attestations для finality
  - Publishers: валидаторы
  - Subscribers: все ноды

/deflationchain/1.0.0/trading/orderbook
  - Order book updates
  - Publishers: Trading Core
  - Subscribers: trading clients

/deflationchain/1.0.0/trading/trades
  - Executed trades
  - Publishers: Trading Core
  - Subscribers: trading clients

Параметры GossipSub:

Конфигурация GossipSub в DeflationChain оптимизирована для баланса между надёжностью доставки и эффективностью использования bandwidth. Параметр D=8 означает, что каждый узел поддерживает 8 mesh peers на топик — достаточно для устойчивости к выпадению нескольких peers, но не создаёт избыточной нагрузки.

Heartbeat каждую секунду позволяет быстро обнаруживать недоступные peers и перестраивать mesh. History length=5 heartbeats означает, что узел помнит о сообщениях последних 5 секунд для обнаружения дубликатов и ответа на gossip-запросы.

GossipSub Configuration:

D = 8            // Target degree (количество mesh peers)
D_lo = 6         // Minimum degree
D_hi = 12        // Maximum degree
D_lazy = 6       // Lazy push gossip degree

heartbeat_interval = 1s
history_length = 5       // Сообщения хранятся 5 heartbeats
history_gossip = 3       // Gossip о последних 3 heartbeats

fanout_ttl = 60s         // TTL для fanout peers
gossip_factor = 0.25     // Доля peers для gossip

Flood publishing: enabled для high-priority messages (blocks, consensus)

Latency targets:

Целевые показатели задержки критичны для различных типов сообщений. Для консенсуса важна быстрая доставка между валидаторами (200ms) — превышение приводит к увеличению времени блока. Для торговли критична минимальная задержка (50ms) — иначе пользователи будут торговать на CEX. Для обычных транзакций допустима большая задержка (500ms).

Таблица ниже представляет 95th percentile targets — 95% сообщений должны укладываться в указанное время. Это более строгий критерий, чем средняя задержка, поскольку tail latency критичен для пользовательского опыта.

9.1.3. Peer Discovery

Обнаружение peers — фундаментальная задача P2P сети: как новый узел находит других участников? DeflationChain использует многоуровневый подход, комбинируя несколько механизмов для обеспечения надёжного discovery в различных сетевых условиях.

Первый уровень — hardcoded bootstrap nodes. Это стабильные, высокодоступные узлы, управляемые DeflationChain Foundation, адреса которых зашиты в код клиента. Они служат точкой входа для новых узлов.

Второй уровень — Kademlia DHT (Distributed Hash Table). После подключения к bootstrap nodes, узел присоединяется к DHT и может находить других участников по их peer ID. DHT масштабируется на миллионы узлов с логарифмической сложностью поиска.

Третий уровень — DNS-based discovery. DNS TXT записи содержат актуальные адреса активных узлов. Это позволяет обновлять список endpoints без изменения клиентского кода.

Kademlia DHT:

Kademlia — децентрализованная система хранения ключ-значение, используемая для peer discovery. Каждый узел имеет 256-битный ID, расстояние между узлами вычисляется как XOR их ID. Это создаёт структуру, где каждый узел знает больше о “близких” (по XOR-метрике) peers и может эффективно маршрутизировать запросы к любому ID за O(log N) шагов.

Kademlia Configuration:

K = 20              // Bucket size
α = 3               // Parallelism factor
β = 3               // Disjoint paths for lookup

Key space: 256-bit (SHA-256 of peer ID)
Distance metric: XOR

Bootstrap nodes:
- Hardcoded list из 10+ географически распределённых nodes
- DNS-based discovery: _dht.deflationchain.io

Refresh interval: 1 hour
Record TTL: 24 hours

DNS-based Discovery:

DNS-based discovery использует стандартную DNS-инфраструктуру для распространения информации об узлах. Преимущество: DNS обновляется централизованно, но распространяется через глобальную сеть DNS-серверов с кешированием. Это позволяет быстро обновлять список узлов при изменениях в сети.

DNS Records:

_dnsaddr.deflationchain.io TXT
  → "dnsaddr=/ip4/1.2.3.4/tcp/30333/p2p/12D3KooW..."
  → "dnsaddr=/ip4/5.6.7.8/tcp/30333/p2p/12D3KooW..."

Преимущества:
- Обновляемые endpoints без изменения клиента
- Geographic load balancing через DNS
- Fallback при недоступности DHT

mDNS (Local Discovery):

mDNS enabled для:
- Development environments
- Private networks
- LAN-based validators

Service name: _deflationchain._tcp.local

9.1.4. Peer Scoring

Peer Scoring — механизм reputation в GossipSub, позволяющий отличать надёжные узлы от проблемных или злонамеренных. Каждому peer присваивается числовой score, влияющий на приоритет соединения, выбор mesh peers, и решения о disconnection.

Score накапливается из нескольких компонентов. Topic score отражает поведение в конкретных топиках: доставка валидных сообщений повышает score, отправка невалидных — понижает. Application score учитывает специфику DeflationChain: валидаторы с высоким uptime получают бонус. IP score позволяет обнаруживать Sybil-атаки: множество peers с одного IP/подсети получают пониженный score.

Важно: score не используется для цензуры. Даже peer с низким score может отправлять транзакции и получать блоки — он просто не будет выбран в mesh и приоритет его сообщений будет ниже. Это защищает от DoS, не нарушая permissionless-природу сети.

Peer Score Components:

P = w1×P_topic + w2×P_app + w3×P_ip + w4×P_behaviour

где:
- P_topic: поведение в GossipSub топиках
- P_app: application-specific metrics
- P_ip: reputation по IP/subnet
- P_behaviour: общее поведение (latency, uptime)

Topic Score (P_topic):
- Mesh delivery: +points за доставку валидных сообщений
- First message deliveries: +bonus за первую доставку
- Invalid messages: -penalty за невалидные
- Mesh time: +bonus за стабильное присутствие в mesh

Score Thresholds:
- GossipThreshold = -500   // Ниже — не gossip к этому peer
- PublishThreshold = -1000 // Ниже — не publish к peer
- GraylistThreshold = -3000 // Временный бан
- BlacklistThreshold = -10000 // Постоянный бан

9.2. Block Synchronization

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

9.2.1. Full Sync

Full Sync — наиболее надёжный, но медленный способ синхронизации. Узел загружает все блоки с genesis, выполняет все транзакции, и самостоятельно восстанавливает текущее состояние. Преимущество: полная независимость от trust assumptions — узел криптографически верифицирует каждый блок. Недостаток: время синхронизации растёт линейно с возрастом chain.

Full sync рекомендуется для archive nodes (хранящих полную историю), для валидаторов при первоначальной настройке, и в случаях когда важна максимальная верификация без доверия к третьим сторонам.

Full Sync Protocol:

1. Peer Discovery:
   - Найти peers с более высоким block height
   - Приоритизировать peers с хорошим score

2. Header Download:
   - Запросить headers пакетами по 1000
   - Верифицировать header chain (hashes, signatures)
   - Parallel download от нескольких peers

3. Body Download:
   - Запросить тела блоков для полученных headers
   - Parallel download с приоритетом по age

4. State Reconstruction:
   - Выполнить все транзакции последовательно
   - Построить state trie
   - Верифицировать state root против header

5. Catch-up:
   - После sync, переключиться на gossip для новых блоков

Performance Targets:
- Header sync: 10,000 headers/sec
- Block sync: 100 blocks/sec (depending on block size)
- Total time for 1M blocks: ~3 hours

9.2.2. Fast Sync (Snap Sync)

Snap Sync — оптимизированный режим для быстрого запуска нового узла. Вместо выполнения всех исторических транзакций, узел загружает snapshot текущего состояния (state trie) напрямую, а затем синхронизирует только последние блоки.

Ключевая идея: state trie криптографически привязан к block header (через state root). Если загруженный state соответствует state root в block header, подписанном 2/3+ валидаторов, state гарантированно корректен — не нужно перевыполнять историю.

Snap sync значительно быстрее full sync: загрузка 100GB state занимает около часа по сравнению с днями для full sync на mature chain. Это рекомендуемый режим для обычных full nodes и RPC providers.

Snap Sync Protocol:

1. Find Pivot Block:
   - Получить block height от нескольких peers
   - Выбрать pivot = max_height - 128 (safety margin)

2. Download State Snapshot:
   - Запросить state trie начиная с root
   - Parallel download по account ranges
   - Streaming state download

3. Verify Snapshot:
   - Вычислить state root
   - Сравнить с pivot block header

4. Sync Recent Blocks:
   - Download blocks от pivot до current
   - Execute transactions для обновления state

5. Switch to Full Node:
   - После sync, нода может обслуживать запросы

Performance:
- State download: ~1 hour для 100GB state
- Значительно быстрее full sync для зрелых chains

9.2.3. Light Client Sync

Light Clients — минималистичный режим для устройств с ограниченными ресурсами (мобильные телефоны, браузеры, IoT). Вместо хранения полного state, light client синхронизирует только block headers и запрашивает конкретные данные (балансы, транзакции) по мере необходимости через Merkle proofs.

Merkle proof — криптографическое доказательство, что определённое значение включено в state trie. Proof имеет размер O(log N) от размера state и может быть верифицирован против state root в header. Это позволяет light client убедиться в корректности данных без доверия к full node, от которого он их получил.

Light clients идеальны для кошельков: пользователю нужен только свой баланс и возможность отправить транзакцию. Хранение ~50 байт на блок позволяет синхронизировать миллион блоков в 50MB — приемлемо даже для мобильного приложения.

Light Client Protocol:

1. Header Sync:
   - Download block headers только
   - Verify validator signatures
   - Track finalized head

2. State Proofs:
   - При запросе balance/storage:
   - Запросить Merkle proof от full node
   - Verify proof против header state root

3. Transaction Submission:
   - Broadcast через full nodes
   - Monitor inclusion через light sync

Storage Requirements:
- Headers only: ~50 bytes per block
- 1M blocks ≈ 50 MB
- Подходит для mobile/browser clients

9.3. RPC Interface

RPC (Remote Procedure Call) — интерфейс для взаимодействия приложений с блокчейном. DeflationChain предоставляет полностью Ethereum-совместимый API, позволяющий использовать существующие инструменты (MetaMask, ethers.js, web3.py) без модификаций, а также расширения для специфичных функций (дефляция, стейкинг, торговля).

9.3.1. JSON-RPC (Ethereum-совместимый)

JSON-RPC — стандартный протокол для Ethereum RPC. Каждый запрос содержит имя метода и параметры в JSON формате, ответ содержит результат или ошибку. Это синхронный request-response протокол, обычно работающий поверх HTTP или WebSocket.

DeflationChain реализует полный набор стандартных методов eth_, net_, web3_*, обеспечивающих совместимость с существующей экосистемой Ethereum tooling. Это критически важно для adoption: разработчики могут портировать dApps без изменения кода.

Стандартные Ethereum методы:

Ниже приведён список поддерживаемых стандартных методов. Каждый работает идентично Ethereum, обеспечивая drop-in совместимость.

eth_blockNumber
eth_getBlockByNumber
eth_getBlockByHash
eth_getTransactionByHash
eth_getTransactionReceipt
eth_sendRawTransaction
eth_call
eth_estimateGas
eth_getBalance
eth_getCode
eth_getStorageAt
eth_getLogs
eth_chainId
eth_gasPrice
eth_feeHistory
net_version
net_listening
web3_clientVersion

DeflationChain-specific методы:

Помимо стандартного Ethereum API, DeflationChain предоставляет методы def_* для доступа к уникальной функциональности: эффективные балансы с учётом дефляции, стейкинг-позиции, информация о валидаторах, PoD-метрики. Эти методы необходимы для корректного отображения состояния в кошельках и dApps.

Важно: eth_getBalance возвращает номинальный баланс (количество полученных токенов), а def_getEffectiveBalance — реальный баланс с учётом прогрессивного сжигания. Для отображения пользователю всегда следует использовать def_getEffectiveBalance.

def_getEffectiveBalance(address)
  → Returns effective balance after applying burnRate

def_getBalancePortions(address)
  → Returns array of BalancePortions with timestamps

def_getStakingPositions(address)
  → Returns array of StakePositions

def_getDividendInfo(address, month)
  → Returns dividend amount for staking position

def_getValidatorInfo(address)
  → Returns validator status, weight, country

def_getPoDWeight(address)
  → Returns Proof-of-Deflation weight

def_getBeta()
  → Returns current global beta indicator

def_getDividendPoolBalance()
  → Returns current dividend pool balance

9.3.2. Trading Core RPC

Trading Core RPC — специализированный API для взаимодействия с централизованным order-book и matching engine DeflationChain. Эти методы оптимизированы для минимальной latency, критичной для торговли.

Важное отличие от стандартных blockchain RPC: торговые операции обрабатываются off-chain matching engine и попадают в блокчейн уже в исполненном виде. Это обеспечивает скорость CEX при сохранении on-chain settlement и кастодии.

Методы trade_* доступны через отдельный endpoint (trade.deflationchain.io), оптимизированный для низкой latency, с географически распределёнными точками входа для минимизации сетевых задержек.

trade_placeOrder(params)
  → Place new order

trade_cancelOrder(orderId)
  → Cancel existing order

trade_getOpenOrders(address)
  → Get all open orders for address

trade_getOrderHistory(address, limit)
  → Get order history

trade_getPositions(address)
  → Get all open positions

trade_getAccountInfo(address)
  → Get margin, equity, available balance

trade_getOrderbook(market, depth)
  → Get current orderbook

trade_getTrades(market, limit)
  → Get recent trades

trade_getFundingRate(market)
  → Get current/predicted funding rate

trade_getMarkPrice(market)
  → Get current mark price

9.3.3. WebSocket Subscriptions

WebSocket — протокол для двунаправленной real-time коммуникации. В отличие от HTTP (request-response), WebSocket позволяет серверу push’ить данные клиенту без запроса. Это критически важно для торговых интерфейсов, где обновления должны приходить мгновенно.

DeflationChain поддерживает стандартные Ethereum subscriptions (newHeads, logs, pendingTransactions) плюс специфичные trading subscriptions для orderbook и trades. Клиент подписывается один раз и получает все последующие обновления без polling.

Преимущества WebSocket над HTTP polling: минимальная latency (данные приходят сразу после события), эффективность (нет overhead от постоянных HTTP requests), и экономия bandwidth (только полезные данные, без HTTP headers).

WebSocket Endpoint: wss://rpc.deflationchain.io/ws

Subscription Types:

1. New Blocks:
   {"method": "eth_subscribe", "params": ["newHeads"]}
   → Emits block header on each new block

2. Pending Transactions:
   {"method": "eth_subscribe", "params": ["newPendingTransactions"]}
   → Emits tx hash for each new pending tx

3. Logs:
   {"method": "eth_subscribe", "params": ["logs", {"address": "0x..."}]}
   → Emits matching log events

4. Orderbook Updates:
   {"method": "trade_subscribe", "params": ["orderbook", "BTC-PERP"]}
   → Emits orderbook deltas

5. Trade Feed:
   {"method": "trade_subscribe", "params": ["trades", "BTC-PERP"]}
   → Emits each executed trade

6. Position Updates:
   {"method": "trade_subscribe", "params": ["positions", "0x..."]}
   → Emits position changes for address

7. Account Updates:
   {"method": "trade_subscribe", "params": ["account", "0x..."]}
   → Emits balance/margin changes

9.3.4. AI/CCL RPC

CCL RPC — API для взаимодействия с Confidential Compute Layer, позволяющий запрашивать AI-инференс с гарантией приватности. Эти методы отличаются от стандартных RPC: запросы зашифрованы публичным ключом TEE-worker’а, а ответы расшифровываются только клиентом.

Процесс взаимодействия: клиент выбирает модель и worker (или позволяет протоколу выбрать автоматически), шифрует input публичным ключом worker’а, отправляет запрос. Worker выполняет inference внутри TEE и возвращает зашифрованный результат. Никто, включая оператора worker’а, не видит ни запрос, ни ответ.

Для обычных use cases (ChatGPT-подобный интерфейс) существуют SDK, абстрагирующие криптографию. Разработчикам достаточно вызвать ccl_chat() — шифрование и расшифровка происходят автоматически.

ccl_getModels()
  → List available AI models

ccl_getWorkers()
  → List registered workers

ccl_getWorkersByCountry(countryCode)
  → Get workers in specific country

ccl_submitRequest(params)
  → Submit confidential compute request
  params: {
    model: "model_hash",
    input: "encrypted_input",
    worker: "preferred_worker" (optional)
  }

ccl_getRequestStatus(requestId)
  → Get status of submitted request

ccl_getRequestResult(requestId)
  → Get encrypted result (when ready)

ccl_estimateCost(params)
  → Estimate cost for request

10. Криптографические примитивы

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

10.1. Подписи

10.1.1. ECDSA (secp256k1)

Elliptic Curve Digital Signature Algorithm (ECDSA) на кривой secp256k1 является основным криптографическим примитивом DeflationChain для создания цифровых подписей. Этот выбор обусловлен необходимостью полной совместимости с экосистемой Ethereum, что позволяет пользователям использовать существующие кошельки, такие как MetaMask, без каких-либо модификаций.

Кривая secp256k1 была выбрана Сатоши Накамото для Bitcoin и впоследствии принята Ethereum. Её ключевое преимущество — эффективность вычислений благодаря специально подобранным параметрам. В отличие от кривых NIST, secp256k1 имеет прозрачное происхождение параметров, что исключает возможность скрытых уязвимостей (backdoors).

DeflationChain использует ECDSA для трёх основных целей: подпись транзакций (каждая транзакция должна быть подписана приватным ключом отправителя), подпись сообщений по стандартам EIP-191 и EIP-712 (для авторизации off-chain действий), и деривация адресов (адрес кошелька вычисляется как последние 20 байт Keccak-256 хеша публичного ключа).

Параметры secp256k1:

Curve: y² = x³ + 7 (mod p)
p = 2²⁵⁶ - 2³² - 2⁹ - 2⁸ - 2⁷ - 2⁶ - 2⁴ - 1
n = FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFEBAAEDCE6AF48A03BBFD25E8CD0364141
G = (Generator point)

Security level: ~128 bits

Использование в DeflationChain:
- Transaction signatures
- Message signing (EIP-191, EIP-712)
- Account derivation (совместимо с MetaMask, etc.)

Процесс подписи транзакции:

Подписание транзакции в DeflationChain следует стандартному процессу Ethereum, состоящему из четырёх последовательных шагов. Сначала транзакция сериализуется с использованием Recursive Length Prefix (RLP) кодирования — это детерминированный способ преобразования структурированных данных в байтовую последовательность. Затем вычисляется Keccak-256 хеш сериализованных данных, который служит уникальным идентификатором транзакции. После этого приватный ключ отправителя используется для создания ECDSA-подписи хеша, в результате чего получаются три компонента: r, s (координаты точки на кривой) и v (параметр восстановления). Наконец, подпись добавляется к транзакции, формируя готовую к отправке в сеть подписанную транзакцию.

1. Serialize transaction (RLP encoding):
   tx_bytes = RLP([nonce, gasPrice, gasLimit, to, value, data, chainId, 0, 0])

2. Hash transaction:
   tx_hash = keccak256(tx_bytes)

3. Sign hash:
   (r, s, v) = ECDSA_sign(private_key, tx_hash)

4. Create signed transaction:
   signed_tx = RLP([nonce, gasPrice, gasLimit, to, value, data, v, r, s])

Recovery (получение public key из подписи):

Одной из уникальных особенностей ECDSA является возможность восстановления публичного ключа подписавшего из самой подписи. Эта функция критически важна для блокчейна: вместо того чтобы включать 64-байтный публичный ключ в каждую транзакцию, достаточно хранить только подпись, а публичный ключ (и соответственно адрес отправителя) можно математически вычислить. Параметр v в подписи (recovery id) указывает, какую из двух возможных точек на эллиптической кривой использовать для восстановления. В Ethereum после EIP-155 параметр v также кодирует chainId для защиты от replay-атак между различными сетями.

def recover_public_key(tx_hash, v, r, s):
    # v encodes recovery id (27/28 for legacy, EIP-155 adds chainId)
    recovery_id = v - 27 if v < 35 else (v - 35) % 2

    # Recover public key from signature
    R = point_from_x(r, recovery_id % 2)
    e = int(tx_hash, 16)
    public_key = (s * R - e * G) * modinv(r, n)

    return public_key

10.1.2. Ed25519 (для валидаторов)

Ed25519 — это схема цифровой подписи на основе кривой Edwards25519, разработанная Дэниелом Бернстайном. В DeflationChain Ed25519 используется опционально для внутренних операций валидаторов, где критична производительность, а совместимость с Ethereum не требуется.

Главное преимущество Ed25519 — детерминированность подписей: в отличие от ECDSA, здесь не требуется генерация случайного nonce для каждой подписи. Это исключает целый класс уязвимостей, связанных со слабыми генераторами случайных чисел. Кроме того, Ed25519 значительно быстрее ECDSA: создание подписи примерно в 10 раз быстрее, а верификация — в 3 раза.

В контексте DeflationChain валидаторы используют Ed25519 для подписания консенсусных сообщений (prevote, precommit), взаимной аутентификации между валидаторами и подписи внутренних административных операций. Это позволяет обрабатывать тысячи подписей в секунду без значительной нагрузки на CPU.

Параметры Ed25519:

Curve: Edwards curve -x² + y² = 1 + d*x²*y² (Curve25519)
d = -121665/121666 (mod p)
p = 2²⁵⁵ - 19
Security level: ~128 bits

Преимущества:
- Детерминированные подписи (нет random nonce)
- Быстрее ECDSA: ~10x для signing, ~3x для verification
- Устойчивость к side-channel attacks

Использование:
- Consensus signatures (prevote, precommit)
- Validator identity
- Inter-validator communication

Сравнение производительности:

Ниже приведена сравнительная таблица производительности ECDSA и Ed25519 для типичных криптографических операций. Измерения проводились на современном серверном оборудовании (Intel Xeon, одно ядро). Особенно важно преимущество Ed25519 в операции Batch Verify, которая недоступна для ECDSA, но критична для валидаторов, обрабатывающих сотни подписей в каждом раунде консенсуса.

10.1.3. BLS12-381 (агрегированные подписи)

BLS (Boneh-Lynn-Shacham) — это схема цифровых подписей с уникальным свойством агрегации: множество подписей от разных подписантов можно математически объединить в одну компактную подпись. Это свойство революционно для блокчейн-систем, где требуется подтверждение от множества валидаторов.

DeflationChain использует кривую BLS12-381, которая также применяется в Ethereum 2.0. Эта кривая обеспечивает 128-битный уровень безопасности при работе с bilinear pairings — математическими операциями, необходимыми для агрегации и верификации подписей.

Практическое значение агрегации огромно: вместо хранения 100 отдельных подписей (по 48 байт каждая = 4800 байт), достаточно хранить одну агрегированную подпись (48 байт). Это сокращение на 99% критически важно для блоков, содержащих Quorum Certificates — доказательства того, что более 2/3 валидаторов подтвердили блок.

Параметры BLS12-381:

Pairing-friendly elliptic curve
Embedding degree: 12
Field size: 381 bits
Security level: ~128 bits

Группы:
- G1: 48 bytes (compressed)
- G2: 96 bytes (compressed)
- Signature: в G1 или G2 (в зависимости от схемы)

Преимущества:
- Signature aggregation: N подписей → 1 подпись
- Verification: 1 pairing вместо N verifications
- Идеально для consensus с большим числом validators

Агрегация подписей:

Процесс агрегации BLS-подписей элегантно прост с математической точки зрения, но имеет глубокие криптографические основания. Когда каждый валидатор подписывает одно и то же сообщение (например, хеш предложенного блока), их подписи можно просто сложить как точки на эллиптической кривой. Результирующая подпись верифицируется одной операцией pairing, что значительно эффективнее проверки каждой подписи отдельно.

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

BLS Aggregation:

1. Each validator i signs message m:
   σ_i = Sign(sk_i, m)

2. Aggregate signatures:
   σ_agg = σ_1 + σ_2 + ... + σ_n

3. Aggregate public keys (для одинаковых сообщений):
   pk_agg = pk_1 + pk_2 + ... + pk_n

4. Verify aggregated signature:
   Verify(pk_agg, m, σ_agg) = e(σ_agg, g2) == e(H(m), pk_agg)

Storage savings:
- 100 validators: 100 × 48 bytes = 4800 bytes → 48 bytes
- 99% reduction in signature storage

Использование в DeflationChain:

В DeflationChain BLS-подписи применяются в трёх ключевых областях. Во-первых, Quorum Certificates (QC) — каждый финализированный блок содержит агрегированную подпись всех валидаторов, подтвердивших его. Это позволяет любому узлу быстро верифицировать консенсус без проверки сотен отдельных подписей.

Во-вторых, State Sync Proofs — лёгкие клиенты и новые узлы могут доказательно синхронизироваться с сетью, получив компактное доказательство финальности: одну агрегированную подпись плюс bitfield (битовая маска), указывающий каких именно валидаторов подписи были агрегированы.

В-третьих, Cross-shard Communication (планируется) — при потенциальном переходе к шардингу агрегированные подписи позволят эффективно передавать доказательства между шардами без экспоненциального роста overhead.

BLS Use Cases:

1. Quorum Certificates (QC):
   - Prevote signatures aggregated
   - Precommit signatures aggregated
   - Block header включает только 1 aggregated signature

2. State Sync Proofs:
   - Proof of finality для light clients
   - Compact proof: 1 signature + bitfield of signers

3. Cross-shard Communication (future):
   - Aggregated proofs между shards

10.2. Хеширование

10.2.1. Keccak-256

Keccak-256 является основной хеш-функцией DeflationChain, унаследованной от Ethereum для полной совместимости. Важно понимать, что Keccak-256 — это не NIST SHA-3, хотя оба основаны на одном алгоритме. Ethereum выбрал оригинальный Keccak до стандартизации NIST, которая внесла незначительные изменения в padding.

Хеш-функция Keccak использует конструкцию sponge (губка), принципиально отличающуюся от конструкции Меркла-Дамгарда, используемой в SHA-1 и SHA-256. Это делает Keccak устойчивым к атакам length extension, которым подвержены классические хеш-функции.

В DeflationChain Keccak-256 используется повсеместно: для деривации адресов из публичных ключей, хеширования транзакций и блоков, вычисления корней Merkle Patricia Trie, расчёта слотов хранения для смарт-контрактов и генерации селекторов функций (первые 4 байта хеша сигнатуры функции).

Keccak-256 (SHA-3 finalist, но НЕ NIST SHA-3):

Output: 256 bits (32 bytes)
Block size: 1088 bits
Capacity: 512 bits
Security: 128-bit collision resistance

Использование:
- Address derivation: address = keccak256(public_key)[12:32]
- Transaction hashing
- State trie node hashing
- Merkle Patricia Trie
- Storage slot calculation
- Event/function selector: bytes4(keccak256("transfer(address,uint256)"))

Примеры использования:

Ниже представлены типичные паттерны использования Keccak-256 в смарт-контрактах DeflationChain. Деривация адреса демонстрирует, как 64-байтный публичный ключ преобразуется в 20-байтный адрес. Расчёт слота хранения по стандарту EIP-1967 показывает технику предотвращения коллизий при работе с прокси-контрактами. Селекторы функций позволяют EVM идентифицировать вызываемые методы по первым 4 байтам calldata.

// Address derivation
address = bytes20(keccak256(abi.encodePacked(publicKeyX, publicKeyY)));

// Storage slot calculation (EIP-1967)
bytes32 IMPLEMENTATION_SLOT = bytes32(uint256(keccak256("eip1967.proxy.implementation")) - 1);

// Function selector
bytes4 selector = bytes4(keccak256("transfer(address,uint256)"));
// selector = 0xa9059cbb

// Mapping storage location
bytes32 slot = keccak256(abi.encodePacked(key, mappingSlot));

10.2.2. SHA-256

SHA-256 — классическая хеш-функция из семейства SHA-2, стандартизированная NIST. В DeflationChain SHA-256 не является основной хеш-функцией (эту роль выполняет Keccak-256), но используется в специфических контекстах, где требуется совместимость с внешними системами.

Первый важный контекст — Intel TDX attestation. Процесс удалённой аттестации TEE использует SHA-256 для хеширования отчётов и цепочек сертификатов. Это требование Intel, и DeflationChain следует ему для интеграции с CCL (Confidential Compute Layer).

Второй контекст — совместимость с Bitcoin для потенциальных кросс-чейн операций и верификации Bitcoin-подписей. SHA-256(SHA-256(x)) — стандартный паттерн хеширования в Bitcoin протоколе.

Третий контекст — HMAC-SHA256 для деривации ключей, где требуется совместимость со стандартами типа HKDF (RFC 5869).

SHA-256:

Output: 256 bits
Block size: 512 bits
Security: 128-bit collision resistance

Использование в DeflationChain:
- TDX attestation quotes (Intel requirement)
- Bitcoin-compatible operations
- HMAC-SHA256 для key derivation
- Random number generation seed

10.2.3. Blake3

Blake3 — современная высокопроизводительная хеш-функция, разработанная в 2020 году командой, создавшей Blake2. Она объединяет скорость Blake2 с преимуществами параллельной обработки и Merkle tree режима, что делает её идеальной для хеширования больших объёмов данных.

В DeflationChain Blake3 используется для внутренних операций, где не требуется совместимость с Ethereum. Ключевое преимущество — скорость: Blake3 в 3-5 раз быстрее Keccak-256 и SHA-256 на современных процессорах благодаря эффективному использованию SIMD инструкций (AVX-512 на серверах).

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

Blake3:

Output: Variable (default 256 bits)
Security: 128-bit
Performance: 3-5x faster than SHA-256

Характеристики:
- SIMD optimized
- Parallel hashing
- Streaming support
- Keyed hashing mode

Использование:
- Internal node hashing (не consensus-critical)
- Content-addressable storage
- File hashing
- Merkle tree construction (internal)

Сравнение производительности:

Производительность хеш-функций критична для блокчейна, поскольку хеширование выполняется миллионы раз в секунду: при верификации транзакций, обновлении state trie, проверке Merkle proofs. Таблица ниже демонстрирует сравнительную производительность на одном ядре CPU при обработке типичных 64-байтных входных данных. Blake3 лидирует благодаря современной архитектуре, оптимизированной под современные процессоры.

10.3. Шифрование

10.3.1. AES-256-GCM

AES-256-GCM (Advanced Encryption Standard в режиме Galois/Counter Mode) является основным алгоритмом симметричного шифрования в DeflationChain. Этот выбор обусловлен тремя факторами: широкой аппаратной поддержкой (AES-NI инструкции в современных CPU), режимом authenticated encryption (шифрование + проверка целостности в одной операции), и стандартизацией в TLS 1.3.

GCM режим особенно важен для блокчейн-приложений, поскольку обеспечивает AEAD (Authenticated Encryption with Associated Data). Это означает, что помимо шифрования конфиденциальных данных, можно аутентифицировать (защитить от модификации) дополнительные метаданные без их шифрования — например, тип сообщения или идентификатор отправителя.

В контексте DeflationChain AES-256-GCM используется для шифрования payload в TLS-соединениях между узлами, защиты данных в CCL (Confidential Compute Layer), и безопасного хранения приватных ключей валидаторов.

AES-256-GCM:

Key size: 256 bits
Block size: 128 bits
Nonce size: 96 bits (recommended)
Tag size: 128 bits
Mode: Galois/Counter Mode (authenticated encryption)

Security:
- Confidentiality: AES-CTR
- Integrity: GHASH (GCM)
- AEAD: Authenticated Encryption with Associated Data

Использование:
- TLS 1.3 cipher suite
- CCL encrypted payloads
- Key wrapping
- Secure storage

Формат encrypted message:

Структура зашифрованного сообщения в DeflationChain следует best practices криптографии. Nonce (12 байт) генерируется уникально для каждого сообщения — повторное использование nonce с тем же ключом полностью компрометирует безопасность GCM. За nonce следует зашифрованный текст переменной длины, а завершает структуру 16-байтный authentication tag, позволяющий обнаружить любую модификацию данных.

Associated Data (AAD) — данные, которые аутентифицируются, но не шифруются. Это полезно для метаданных, которые должны быть видны (для маршрутизации, логирования), но защищены от подделки. Например, тип сообщения и идентификатор отправителя могут быть в AAD, позволяя промежуточным узлам маршрутизировать сообщение без расшифровки содержимого.

10.3.2. ChaCha20-Poly1305

ChaCha20-Poly1305 — современный AEAD cipher, разработанный Дэниелом Бернстайном как альтернатива AES-GCM. Его ключевое преимущество — отсутствие зависимости от специализированных аппаратных инструкций: ChaCha20 работает быстро на любом процессоре, используя только базовые операции (XOR, сложение, побитовые сдвиги).

Для блокчейна это важно по двум причинам. Во-первых, не все узлы работают на серверах с AES-NI — мобильные устройства, старые процессоры и некоторые ARM-платформы могут не иметь аппаратного AES. Во-вторых, ChaCha20 изначально спроектирован с защитой от timing attacks — время выполнения не зависит от значения ключа или данных, что критично для криптографических операций.

В DeflationChain ChaCha20-Poly1305 используется как fallback для клиентов без AES-NI, для мобильных кошельков и лёгких клиентов, и в протоколах типа WireGuard для VPN-подключения узлов.

ChaCha20-Poly1305:

Key size: 256 bits
Nonce size: 96 bits
Tag size: 128 bits

Преимущества:
- Не требует AES-NI (software-friendly)
- Constant-time на всех платформах
- Без timing side-channels

Использование:
- Mobile clients
- Fallback для устройств без AES-NI
- Wireguard-style protocols

10.3.3. ECIES (Hybrid Encryption)

ECIES (Elliptic Curve Integrated Encryption Scheme) решает фундаментальную проблему: как зашифровать сообщение для получателя, зная только его публичный ключ? Асимметричные алгоритмы напрямую (как RSA) неэффективны для больших данных, поэтому используется гибридный подход.

Суть ECIES — отправитель генерирует одноразовую (ephemeral) ключевую пару, вычисляет общий секрет с публичным ключом получателя через ECDH (Elliptic Curve Diffie-Hellman), и использует этот секрет для симметричного шифрования (AES-GCM). Получатель использует свой приватный ключ и эфемерный публичный ключ отправителя для воссоздания того же секрета и расшифровки.

В DeflationChain ECIES критичен для CCL: пользователь шифрует запрос к AI-модели публичным ключом TEE-воркера, гарантируя что только TEE с соответствующим приватным ключом (защищённым аппаратно) сможет расшифровать данные.

ECIES Process:

Encryption (для получателя с public key P):
1. Generate ephemeral key pair: (e, E = e*G)
2. Compute shared secret: S = e * P
3. Derive encryption key: k = KDF(S)
4. Encrypt message: c = AES_GCM(k, m)
5. Output: (E, c, tag)

Decryption (с private key p):
1. Compute shared secret: S = p * E
2. Derive key: k = KDF(S)
3. Decrypt: m = AES_GCM_decrypt(k, c)

Использование в DeflationChain:
- CCL request encryption (user → worker)
- Encrypted model key distribution
- Secure inter-validator communication

10.4. Key Derivation

10.4.1. HKDF (HMAC-based Key Derivation Function)

HKDF — стандартизированный механизм (RFC 5869) для генерации криптографических ключей из исходного материала ключа (Input Keying Material, IKM). В отличие от простого хеширования, HKDF обеспечивает формально доказанную безопасность и поддержку domain separation — возможность генерировать множество независимых ключей из одного секрета.

Двухфазная архитектура Extract-then-Expand особенно важна для блокчейна. Фаза Extract принимает потенциально слабый IKM (например, результат ECDH) и создаёт криптографически сильный псевдослучайный ключ (PRK). Фаза Expand позволяет из одного PRK генерировать произвольное количество ключей, каждый для своей цели (шифрование, MAC, IV и т.д.).

В DeflationChain HKDF применяется для деривации сессионных ключей после TLS handshake, генерации отдельных ключей для шифрования и аутентификации из одного shared secret, и domain separation между различными протоколами.

HKDF (RFC 5869):

Extract-then-Expand paradigm:
1. Extract: PRK = HMAC(salt, IKM)
2. Expand: OKM = HMAC(PRK, info || counter)

Использование:
- Deriving session keys
- Key stretching
- Domain separation

10.4.2. BIP-32/39/44 (HD Wallets)

Иерархические детерминированные кошельки (HD Wallets) — стандарт индустрии для управления криптографическими ключами, полностью поддерживаемый DeflationChain. Три взаимосвязанных стандарта BIP (Bitcoin Improvement Proposal) обеспечивают совместимость с существующей экосистемой кошельков.

BIP-39 определяет преобразование seed-фразы (12-24 слов из стандартного словаря в 2048 слов) в cryptographic seed через PBKDF2. Это позволяет пользователям запоминать или безопасно записывать seed-фразу для восстановления всех ключей кошелька.

BIP-32 описывает иерархическую деривацию: из одного master seed можно математически вывести неограниченное количество дочерних ключей. Hardened деривация (с апострофом в пути) обеспечивает дополнительную безопасность — компрометация дочернего ключа не раскрывает родительский.

BIP-44 стандартизирует пути деривации для разных криптовалют: m/44’/60’/0’/0/0 для первого Ethereum-адреса. DeflationChain использует свой coin_type для нативных операций, сохраняя совместимость с coin_type 60 (Ethereum) для EVM-транзакций.

Hierarchical Deterministic Wallet:

BIP-39: Mnemonic → Seed
- 12-24 words from 2048-word list
- PBKDF2 with 2048 iterations

BIP-32: Seed → Master Key → Child Keys
- Extended keys: (key, chain_code)
- Hardened derivation для security

BIP-44: Derivation Paths
- m/44'/60'/0'/0/0 (первый Ethereum адрес)
- m/44'/[CHAIN_ID]'/0'/0/x для DeflationChain

10.5. Merkle Structures

10.5.1. Merkle Patricia Trie

Merkle Patricia Trie (MPT) — фундаментальная структура данных Ethereum, унаследованная DeflationChain для хранения глобального состояния. MPT объединяет свойства трёх структур: Merkle tree (криптографические доказательства), Patricia trie (эффективный поиск по ключам), и radix tree (сжатие общих префиксов).

Каждый узел MPT хешируется, и изменение любого значения каскадно изменяет хеши всех родительских узлов вплоть до корня (state root). Это позволяет любому проверить наличие или отсутствие данных, имея только 32-байтный корневой хеш и Merkle proof — доказательство фиксированного размера независимо от общего объёма данных.

DeflationChain использует три отдельных trie: State Trie (балансы, nonce, хеши кода контрактов), Storage Trie (данные хранилища каждого контракта), и Transactions Trie (транзакции в блоке). Корни этих trie включаются в заголовок блока, обеспечивая криптографическую привязку всего состояния к blockchain.

Modified Merkle Patricia Trie:

Node Types:
1. NULL: пустой node
2. Branch: 17 elements (16 nibbles + value)
3. Extension: (shared_nibbles, child)
4. Leaf: (remaining_path, value)

RLP Encoding:
- Nodes кодируются RLP
- Если RLP(node) < 32 bytes: inline
- Если RLP(node) >= 32 bytes: store, reference by hash

State Trie:
- Key: keccak256(address)
- Value: RLP([nonce, balance, storageRoot, codeHash])

Storage Trie:
- Key: keccak256(slot)
- Value: RLP(value)

Transactions Trie:
- Key: RLP(index)
- Value: RLP(transaction)

10.5.2. Verkle Trees (Future)

Verkle Trees — следующее поколение структур данных для блокчейна, планируемое к внедрению в DeflationChain после стабилизации mainnet. Название происходит от “Vector commitment” + “Merkle”, отражая ключевое новшество: замену хеш-функций на polynomial commitments (KZG).

Главное преимущество Verkle Trees — драматическое сокращение размера proof. В MPT proof растёт логарифмически с размером данных и может достигать килобайт. В Verkle Tree proof остаётся почти постоянным независимо от глубины дерева благодаря математическим свойствам KZG commitments.

Для DeflationChain это означает: более эффективные light clients (меньше данных для синхронизации), быстрее state sync для новых узлов, и подготовку к stateless clients — узлам, которые не хранят полное состояние, а получают proofs для каждой транзакции. Миграция с MPT на Verkle планируется как backward-compatible upgrade без хардфорка.

Verkle Trees (Planned Upgrade):

Преимущества над MPT:
- Witness size: O(log n) → O(log n / log k) где k = branching factor
- Для k=1024: ~10x меньше proof size
- Vector commitments вместо hash-based

Polynomial Commitments:
- KZG (Kate-Zaverucha-Goldberg)
- Constant-size proofs
- Batched verification

Planned integration:
- After mainnet stabilization
- Backward compatible upgrade
- Gradual migration from MPT

11. Безопасность

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

11.1. Threat Model

11.1.1. Определение модели угроз

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

Модель угроз DeflationChain строится на четырёх категориях предположений. Криптографические предположения опираются на вычислительную сложность математических задач — если дискретный логарифм на эллиптических кривых будет взломан, криптовалютная индустрия в целом окажется под угрозой. Сетевые предположения используют модель частичной синхронности — сеть может быть асинхронной (сообщения задерживаются произвольно), но после некоторого момента (GST — Global Stabilization Time) сообщения доставляются в течение ограниченного времени.

Экономические предположения основаны на рациональности участников: атаки должны быть экономически невыгодны. Byzantine tolerance требует, чтобы честные валидаторы контролировали более 2/3 PoD-веса — это стандартный порог для BFT-консенсуса, обеспечивающий безопасность при наличии до 1/3 злонамеренных участников.

Базовые предположения:

11.1.2. 51% Attack

Атака 51% — фундаментальная угроза для любой децентрализованной системы: атакующий, контролирующий большинство ресурсов (вычислительной мощности в PoW, стейка в PoS, или PoD-веса в DeflationChain), теоретически может переписывать историю транзакций, осуществлять double-spending, и цензурировать транзакции.

Однако DeflationChain имеет уникальные защитные механизмы, делающие эту атаку практически невыполнимой. Во-первых, накопление 51% PoD-веса требует не только покупки токенов, но и многолетнего стейкинга — существующие долгосрочные стейкеры уже имеют преимущество xMultiplier до 20x. Атакующему, начинающему с нуля, потребуется либо накопить значительно больше токенов, либо ждать годы.

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

Анализ для DeflationChain:

Сценарий: Атакующий хочет получить 51%+ PoD-веса

Расчёт стоимости атаки:
─────────────────────────────────────────────
Предположения:
- Total DEF staked: 5,000,000 DEF (~24% от эмиссии 21M)
- DEF price: $10
- Average stake duration: 4 года
- Target: 51% PoD weight

Required Stake:
- Для 51% при равном сроке стейка: 2,550,000 DEF
- Рыночная стоимость: $25.5M

Дополнительные факторы:
- Slippage при покупке такого объёма: +30-50%
- Price impact от объявления намерений: +100-500%
- Реальная стоимость атаки: $50-150M+

Время на накопление:
- При покупке 1% supply/день: 12+ дней
- За это время: community response, governance action
─────────────────────────────────────────────

Механизмы защиты от 51% атаки:

11.1.3. Validator Collusion

Сговор валидаторов представляет более тонкую угрозу, чем прямая 51% атака. Даже без контроля большинства, группа валидаторов может координировать действия для извлечения выгоды или нанесения вреда сети. Порог в 1/3 PoD-веса критически важен: с ним можно заблокировать finality (хотя не изменить историю), с 2/3 — полностью контролировать сеть.

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

Тем не менее, DeflationChain реализует системы обнаружения аномального поведения: анализ паттернов голосования на подозрительно высокую корреляцию между валидаторами, мониторинг транзакций на цензурирование, и механизмы whistleblower rewards для стимулирования раскрытия сговора.

Типы collusion атак:

Тип атаки                | Требования           | Последствия
─────────────────────────┼─────────────────────┼────────────────────────
Censorship              | 1/3+ PoD weight      | Блокировка транзакций
Double spending         | 2/3+ PoD weight      | Финансовые потери
Liveness attack         | 1/3+ PoD weight      | Остановка сети
State corruption        | 2/3+ PoD weight      | Произвольные изменения

Механизмы обнаружения:

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

Анализ времени голосования выявляет подозрительно синхронные действия — если валидаторы из разных частей мира голосуют с разницей менее 50 миллисекунд, это может указывать на координацию через приватный канал связи. Анализ паттернов выбора отслеживает, голосуют ли определённые валидаторы всегда одинаково даже при наличии альтернативных валидных опций. Анализ отсутствия обнаруживает координированные пропуски голосования, которые могут использоваться для атаки на liveness.

class CollusionDetector:
    """
    Система обнаружения сговора валидаторов
    """

    def detect_voting_patterns(self, votes: List[Vote]) -> Alert:
        """
        Анализ паттернов голосования на признаки сговора
        """
        # Подозрительные признаки:
        # 1. Идентичное время голосования (< 50ms разница)
        # 2. Одинаковые блоки при альтернативных опциях
        # 3. Координированные отказы от голосования

        timing_correlation = self.analyze_timing(votes)
        choice_correlation = self.analyze_choices(votes)
        absence_correlation = self.analyze_absences(votes)

        if timing_correlation > THRESHOLD:
            return Alert.SUSPECTED_TIMING_COLLUSION
        if choice_correlation > THRESHOLD:
            return Alert.SUSPECTED_CHOICE_COLLUSION

        return Alert.NONE

    def detect_censorship(self, mempool: Mempool, blocks: List[Block]) -> Alert:
        """
        Обнаружение координированной цензуры транзакций
        """
        for tx in mempool.pending:
            if tx.age > MAX_PENDING_TIME:
                if tx.fee >= MINIMUM_FEE:
                    # Транзакция с достаточной комиссией игнорируется
                    excluding_validators = self.find_excluding_validators(tx)
                    if len(excluding_validators) > COLLUSION_THRESHOLD:
                        return Alert.SUSPECTED_CENSORSHIP

        return Alert.NONE

Защитные механизмы:

DeflationChain реализует несколько уровней защиты от сговора. Proposer-Builder Separation (PBS) — архитектурное решение, заимствованное из Ethereum, где валидаторы не формируют содержимое блоков напрямую. Вместо этого специализированные builder’ы конкурируют за право включить транзакции, а валидатор только выбирает блок с наибольшей ставкой. Это затрудняет цензуру: builder, исключающий транзакции, проигрывает конкуренцию builder’у, включающему их.

Mandatory Transaction Inclusion требует, чтобы транзакции, находящиеся в mempool дольше определённого времени (обычно N блоков), были обязательно включены. Валидатор, систематически игнорирующий такие транзакции, подвергается slashing. Это делает долгосрочную цензуру невозможной даже при сговоре значительной доли валидаторов.

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

1. Proposer-Builder Separation (PBS):
   - Validators не выбирают содержимое блоков
   - Builders конкурируют за право формирования
   - Снижает возможности для координированной цензуры

2. Mandatory Transaction Inclusion:
   - Транзакции старше N блоков должны быть включены
   - Отказ = slashing offense
   - Crlist mechanism (Ethereum-inspired)

3. Validator Reputation System:
   - On-chain tracking поведения валидаторов
   - Correlation score между парами валидаторов
   - Public dashboard для мониторинга

4. Whistleblower Rewards:
   - Награда за доказательство сговора
   - 10% от slashed amount → whistleblower
   - Анонимный reporting channel

11.1.4. Smart Contract Vulnerabilities

Смарт-контракты представляют уникальный вектор атаки: код публичен, необратим (после деплоя), и управляет реальными активами. История DeFi полна примеров эксплуатации уязвимостей с многомиллионными потерями — от The DAO (2016, $60M) до различных flash loan атак современности.

DeflationChain наследует EVM и, соответственно, классические уязвимости Solidity-контрактов. Reentrancy — атака, где контракт вызывает внешний контракт до обновления своего состояния, позволяя рекурсивные вызовы. Integer overflow/underflow — переполнение целых чисел, исторически критическое, но в Solidity 0.8+ проверяется автоматически. Access control bypass — обход проверок авторизации из-за логических ошибок.

Для DeFi-специфичных атак особенно опасны flash loans — возможность занять огромные суммы без залога в рамках одной транзакции. Это позволяет манипулировать ценами на DEX, эксплуатировать ненадёжные оракулы, и создавать сложные атаки, требующие большого капитала. DeflationChain митигирует эти риски через TWAP-оракулы, лимиты на операции, и обязательные аудиты core-контрактов.

Классификация уязвимостей:

DeflationCoin-специфичные риски:

DeflationCoin имеет уникальную механику, создающую специфические риски, не встречающиеся в обычных ERC-20 токенах. Система BalancePortions с прогрессивным сжиганием требует особого внимания к race conditions и timestamp manipulation.

Первый риск — попытка отправить множество транзакций в одном блоке для обхода механизма сжигания. Если пользователь может обновить balanсe несколько раз за один block.timestamp, он потенциально может “обнулить” счётчик неактивности. Защита реализована через проверку, что каждый адрес может обновляться только раз в блок.

Второй риск — манипуляция временем блока валидатором для получения преимущества в xMultipliers. Хотя валидаторы имеют некоторую свободу в установке timestamp, DeflationChain ограничивает допустимое отклонение от предыдущего блока, делая значимую манипуляцию невозможной.

Третий риск — flash stake атака на dividend pool: займ большой суммы, стейк, получение дивидендов, анстейк, возврат займа — всё в одной транзакции. Защита требует минимального срока стейкинга (30 дней) перед возможностью claim дивидендов.

// Риск 1: Race condition в BalancePortion
// Атака: Множественные транзакции в одном блоке для обхода прогрессивного сжигания

// Защита:
function refreshBalance(address user) internal {
    require(block.timestamp > lastRefresh[user], "Already refreshed this block");
    lastRefresh[user] = block.timestamp;
    // ... обычная логика
}

// Риск 2: Манипуляция со временем стейкинга
// Атака: Validator манипулирует block.timestamp для выгоды в xMultipliers

// Защита:
modifier timestampSafe() {
    require(
        block.timestamp >= previousBlockTimestamp,
        "Timestamp regression"
    );
    require(
        block.timestamp <= previousBlockTimestamp + MAX_BLOCK_DRIFT,
        "Timestamp too far in future"
    );
    _;
}

// Риск 3: Dividend pool drainage
// Атака: Flash stake для получения дивидендов

// Защита:
function claimDividends(uint256 stakeId) external {
    StakePosition storage stake = stakes[msg.sender][stakeId];
    require(
        block.timestamp >= stake.startTime + MINIMUM_STAKE_FOR_DIVIDENDS,
        "Stake too young"
    );
    // MINIMUM_STAKE_FOR_DIVIDENDS = 30 days
}

11.1.5. Oracle Manipulation

Оракулы — мост между блокчейном и внешним миром, предоставляющий данные о ценах активов. Для DeflationChain с интегрированным Trading Core надёжность оракулов критична: некорректные цены ведут к неправомерным ликвидациям, unfair settlement perpetuals, и возможности арбитража за счёт протокола.

Классический сценарий атаки: атакующий с flash loan манипулирует ценой на низколиквидной DEX, которую использует оракул. Оракул фиксирует искажённую цену, что позволяет атакующему выполнить выгодную операцию (открыть/закрыть позицию, вызвать ложную ликвидацию) до возврата цены к нормальному уровню. Всё это происходит в одной атомарной транзакции.

DeflationChain противодействует этому многоуровневой системой: использование TWAP (Time-Weighted Average Price) вместо spot price сглаживает краткосрочные манипуляции, требуя удержания искажённой цены в течение минут, что нереалистично для flash loan атаки. Мульти-оракульная архитектура агрегирует данные из Chainlink, Pyth, Band, и RedStone — манипуляция требует контроля большинства источников. Outlier rejection отбрасывает значения, отклоняющиеся более чем на 2 стандартных отклонения от медианы.

Attack vectors:

DeflationChain Oracle Architecture:

Архитектура оракулов DeflationChain строится на принципе defense in depth — множество уровней защиты, каждый из которых снижает риск успешной атаки. На первом уровне находятся Primary Oracles — проверенные провайдеры данных (Chainlink, Pyth, Band, RedStone), каждый со своей инфраструктурой и методологией сбора цен.

Oracle Aggregator Contract — второй уровень — собирает данные от всех провайдеров и применяет статистическую обработку: вычисляет медиану (устойчивую к выбросам), отбрасывает значения, отклоняющиеся более чем на 2σ, проверяет актуальность данных (staleness check — максимум 60 секунд). Emergency circuit breaker автоматически приостанавливает операции при обнаружении аномалий.

TWAP Engine — третий уровень — сглаживает оставшиеся флуктуации через time-weighted averaging. Mark Price (используется для расчёта PnL и ликвидаций) усредняется за 5 минут, что делает flash loan манипуляции неэффективными. Index Price (эталонная цена с CEX) усредняется за 1 минуту. Разница между ними (premium) используется для funding rate.

11.1.6. MEV Extraction

MEV (Maximal Extractable Value) — прибыль, которую могут извлечь валидаторы и специализированные боты через переупорядочивание, вставку или цензурирование транзакций. Подробно MEV рассмотрено в разделе 5.4; здесь — системный анализ угроз на уровне сети.

MEV создаёт негативную экстерналию: пользователи платят “скрытый налог” в виде ухудшенного исполнения сделок. Front-running делает лимитные ордера предсказуемыми для атакующих. Sandwich attacks извлекают value из AMM-свопов. Time-bandit attacks угрожают finality: если MEV от реорганизации превышает награду за честное поведение, рациональный валидатор может попытаться переписать историю.

DeflationChain применяет комплексный подход к MEV. На уровне протокола: commit-reveal схемы для критических операций, batch auctions вместо FIFO-исполнения, MEV-aware transaction ordering через Flashbots-подобные механизмы. На уровне Trading Core: приоритетное исполнение ликвидаций через DLP (защита от MEV-охотников), частичное исполнение вместо отклонения ордеров. На уровне мониторинга: real-time tracking MEV-активности для адаптации защитных мер.

Extended MEV Threat Analysis:

Тип MEV	Влияние на пользователей	Влияние на протокол	Статус смягчения
Фронт-раннинг	Худшее исполнение сделок	Снижение доверия	✅ Commit-reveal
Sandwitch-атаки	Скрытые издержки	Репутационные риски	✅ Пакетные аукционы
Time-bandit атаки	Риск реорганизаций	Проблемы с финальностью	✅ Быстрая финализация
MEV ликвидаций	Несправедливое ценообразование	Потери LP	✅ Приоритет DLP
JIT-ликвидность	Нечестная конкуренция	Искажение рынка	⚠️ Частично
Block stuffing	Задержки транзакций	Ухудшение UX	✅ Лимиты газа

Cross-domain MEV (Future Risk):

Сценарий: межсетевой арбитраж с использованием задержек мостов

Ход атаки:

1. Наблюдение за крупной сделкой с DEF в сети Ethereum

2. Фронт-раннинг в сети DeflationChain через более быстрый мост

3. Получение прибыли за счёт ценового расхождения

Меры защиты:

• Требования к подтверждению транзакций в мостах

• Ограничение скорости (rate limiting) на переводы через мост

• Мониторинг межсетевого MEV

11.2. Формальная верификация

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

Для блокчейна формальная верификация особенно важна: код публичен (атакующие видят все детали), необратим (ошибки нельзя “откатить”), и управляет реальными активами. Стоимость эксплойта может измеряться миллиардами долларов, что оправдывает значительные инвестиции в верификацию.

DeflationChain применяет формальную верификацию на трёх уровнях: консенсус-протокол (TLA+ для distributed systems modeling), смарт-контракты (Certora, Dafny для инвариантов и pre/post-conditions), и криптографические примитивы (верифицированные реализации из проверенных библиотек).

11.2.1. Консенсус протокол

Для консенсус-протокола формально верифицируются Safety properties (должны выполняться всегда) и Liveness properties (должны выполняться eventually). Safety гарантирует, что ничего плохого не произойдёт: все честные ноды принимают одинаковые решения, принятые значения были кем-то предложены. Liveness гарантирует прогресс: система не застрянет, решения eventually будут приняты.

PoD-специфичные свойства включают корректность расчёта весов (формула weight = stake × years соблюдается), дефляционный инвариант (total supply монотонно убывает), и fairness (вероятность быть лидером пропорциональна PoD-весу).

Свойства для верификации:

Инструменты верификации:

Инструмент	Назначение	Проверяемые компоненты
TLA+	Моделирование распределённых систем	Раунды консенсуса, выбор лидера
Coq	Доказательство теорем	Криптографические свойства
Dafny	Верификация программ	Логика смарт-контрактов
Certora	Специализированная верификация DeFi	Финансовые инварианты
Echidna	Фаззинг на основе свойств	Граничные случаи, инварианты

11.2.2. Core Smart Contracts

Смарт-контракты DeflationChain проходят формальную верификацию с использованием специализированных инструментов для DeFi. Ключевая концепция — инварианты: свойства, которые должны выполняться в любом состоянии контракта, после любой последовательности транзакций.

Для DeflationCoin критические инварианты включают: conservation of value (totalSupply всегда равен сумме всех балансов и стейков — токены не появляются из ниоткуда), дефляционность (totalSupply может только уменьшаться, никогда увеличиваться), ограниченность параметров (staking years всегда в диапазоне 1-12, burnRate всегда в допустимых пределах).

Верификация выполняется с помощью Certora Prover — индустриального инструмента для формальной верификации Solidity. Спецификации пишутся на CVL (Certora Verification Language), декларативном языке для описания правил и инвариантов. Каждое изменение контракта проходит автоматическую проверку: если новый код нарушает любой инвариант, деплой блокируется.

Верифицируемые контракты:

// Invariants для DeflationCoinUpgradeable

/// @notice Verified Invariants:
/// INV-1: totalSupply == Σ(balances[addr]) + Σ(stakes[addr].amount)
/// INV-2: dividendPool + technicalPool + marketingPool ≤ totalFees
/// INV-3: ∀ stake: stake.year ∈ [1, 12]
/// INV-4: ∀ portion: portion.timestamp ≤ block.timestamp
/// INV-5: refreshedBalance(addr) ≤ rawBalance(addr)

contract DeflationCoinVerified {

    /// @custom:invariant totalSupply equals sum of all balances and stakes
    function invariant_supplyConsistency() public view returns (bool) {
        uint256 computed = 0;
        // Note: В реальности это проверяется off-chain или через Merkle proofs
        for (address a in allAddresses) {
            computed += balanceOf(a);
            for (uint i = 0; i < stakeCount(a); i++) {
                computed += stakes[a][i].amount;
            }
        }
        return computed == totalSupply;
    }

    /// @custom:invariant staking years are bounded
    function invariant_stakingBounds() public view returns (bool) {
        for (address a in allAddresses) {
            for (uint i = 0; i < stakeCount(a); i++) {
                if (stakes[a][i].year < 1 || stakes[a][i].year > 12) {
                    return false;
                }
            }
        }
        return true;
    }
}

Certora specifications:

// DeflationCoin.spec

methods {
    balanceOf(address) returns uint256 envfree
    totalSupply() returns uint256 envfree
    transfer(address, uint256) returns bool
    stake(uint256, uint8) returns uint256
}

// Rule: Transfer preserves total supply (minus burns)
rule transferPreservesTotalSupply(address from, address to, uint256 amount) {
    uint256 supplyBefore = totalSupply();
    uint256 fromBalanceBefore = balanceOf(from);
    uint256 toBalanceBefore = balanceOf(to);

    transfer(to, amount);

    uint256 supplyAfter = totalSupply();
    uint256 burned = supplyBefore - supplyAfter;

    // Supply can only decrease (deflationary)
    assert supplyAfter <= supplyBefore;

    // Conservation (accounting for burns and fees)
    assert fromBalanceBefore + toBalanceBefore - burned >=
           balanceOf(from) + balanceOf(to);
}

// Rule: Staking doesn't create tokens
rule stakingNoInflation(uint256 amount, uint8 year) {
    uint256 supplyBefore = totalSupply();

    stake(amount, year);

    uint256 supplyAfter = totalSupply();

    assert supplyAfter <= supplyBefore;
}

// Invariant: Daily reductions are monotonically decreasing
// Инвариант: burnRate монотонно возрастает (каждый день сжигается больше)
invariant burnRateIncreasing()
    forall uint8 i. i < 8 => burnRate(i) < burnRate(i + 1);

11.2.3. Cryptographic Primitives

Криптографические примитивы — фундамент безопасности любой блокчейн-системы. Ошибка в реализации ECDSA или AES потенциально компрометирует всю сеть. Поэтому DeflationChain использует исключительно верифицированные, battle-tested реализации от признанных проектов.

Для ECDSA (secp256k1) используется libsecp256k1 — библиотека, разработанная Bitcoin Core, прошедшая многолетнюю эксплуатацию в production с сотнями миллиардов долларов на кону. Для BLS12-381 используется blst от Protocol Labs — высокопроизводительная реализация с формальной верификацией корректности через proof assistants.

Важный принцип: DeflationChain не реализует криптографию с нуля. Каждый криптографический примитив — импорт из проверенной библиотеки. Это исключает целый класс уязвимостей, связанных с некорректной реализацией сложных алгоритмов. Все используемые библиотеки проходят регулярные аудиты и имеют active maintenance.

Формальная верификация криптографии:

11.3. Аудиты

Аудит — критический компонент безопасности, независимая экспертная оценка кода профессиональными security-исследователями. DeflationChain использует стратегию множественных аудитов: разные аудиторы специализируются на разных аспектах (консенсус, DeFi, инфраструктура), и пересечение их областей экспертизы максимизирует покрытие.

11.3.1. Pre-launch аудиты

Перед запуском mainnet все критические компоненты проходят аудит у ведущих security-фирм индустрии. Выбор аудиторов основан на их track record, специализации и репутации. Каждый аудит включает ручной code review, автоматический статический анализ, и fuzzing-тестирование.

Trail of Bits — известны глубоким техническим анализом и работой с крупнейшими блокчейн-проектами. OpenZeppelin — создатели стандартных библиотек для Solidity, эксперты в smart contract security. Consensys Diligence — специализация на DeFi-протоколах. Certora — лидеры в формальной верификации. NCC Group — экспертиза в системном программировании и инфраструктуре.

Общий бюджет на pre-launch аудиты — $2,000,000. Это инвестиция в репутацию и безопасность: стоимость успешного эксплойта многократно превысит эту сумму.

Запланированные аудиты:

11.3.2. Ongoing Audits

Безопасность — не разовое событие, а непрерывный процесс. После запуска mainnet DeflationChain продолжает инвестировать в security через Continuous Security Program с годовым бюджетом $500,000.

Автоматизированный мониторинг работает постоянно: Slither и Mythril выполняют статический анализ при каждом коммите, Echidna и Foundry fuzz запускают property-based тесты для поиска edge cases, Certora проверяет инварианты при любых изменениях контрактов. Это первая линия защиты, ловящая очевидные ошибки до деплоя.

Периодические ревью обеспечивают экспертный контроль: ежеквартальные внешние security review для оценки новых фич, ежемесячные внутренние code review для поддержания качества, еженедельное сканирование на уязвимости с использованием актуальных баз данных CVE.

Upgrade Audits — любое изменение core-контрактов требует обязательного аудита перед деплоем. Для критических hotfixes существует fast-track процедура с 48-часовым emergency review, но даже она не пропускает непроверенный код в production.

Continuous Security Program:

11.4. Bug Bounty Program

Bug Bounty — краудсорсинг безопасности: сообщество security-исследователей ищет уязвимости в обмен на вознаграждение. Это экономически эффективный механизм: протокол платит только за реально найденные баги, а глобальный пул исследователей многократно превосходит возможности любой аудиторской фирмы.

DeflationChain реализует Bug Bounty через Immunefi — ведущую платформу для блокчейн bug bounties с проверенным track record. Immunefi обеспечивает инфраструктуру (secure submission, triage, payment), а также доступ к сообществу опытных whitehats.

11.4.1. Program Structure

Структура вознаграждений DeflationChain Bug Bounty калибрована на основе реального ущерба от эксплуатации уязвимости. CRITICAL уязвимости (прямая кража средств, бесконечный mint, остановка сети) вознаграждаются до $1,000,000 — это дорого, но потенциальный ущерб измеряется сотнями миллионов. HIGH уязвимости (требующие действий пользователя, временные проблемы) — до $100,000. MEDIUM (griefing, information disclosure) — до $10,000. LOW (minor leaks, best practice violations) — до $1,000.

Total reserve $5,000,000 обеспечивает финансирование программы на годы вперёд. Scope включает весь on-chain код, node software, bridges, CCL — практически всё, что может повлиять на безопасность пользовательских средств.

11.4.2. Disclosure Process

Responsible Disclosure — этический стандарт обращения с найденными уязвимостями. Исследователь сообщает команде приватно, команда исправляет баг, и только после fix публикуется информация об уязвимости. Это защищает пользователей от эксплуатации в window между обнаружением и исправлением.

DeflationChain следует индустриальному стандарту 90-дневного эмбарго: после получения репорта команда имеет до 90 дней на fix до публичного disclosure. Для CRITICAL уязвимостей активируется emergency response с развёртыванием fix в течение 1-3 дней. После каждого инцидента публикуется post-mortem с техническими деталями и lessons learned.

Исследователи получают не только денежное вознаграждение, но и публичное признание (если желают): их имя/handle указывается в security advisory, что важно для построения репутации в security community.

11.4.3. Historical Incidents

Прозрачность — ключевой принцип безопасности DeflationChain. Все security incidents, независимо от severity, будут публиковаться в структурированном формате. Это служит нескольким целям: позволяет сообществу оценить реальное состояние безопасности протокола, помогает другим проектам учиться на чужих ошибках, и создаёт accountability — команда не может “замести под ковёр” инциденты.

Каждый incident log включает уникальный ID, дату обнаружения, severity, текущий статус, техническое описание уязвимости, root cause analysis (почему баг появился), resolution (как был исправлен), сумму выплаченного bounty, и credit исследователю. Публичный incident log доступен на сайте проекта и обновляется в реальном времени.

На момент написания (pre-mainnet) инцидентов не зафиксировано. После запуска этот раздел будет обновляться по мере появления и разрешения security issues.

12. Миграция с BSC

DeflationCoin в настоящее время функционирует на Binance Smart Chain (BSC). Миграция на собственную сеть DeflationChain требует тщательного планирования для сохранения позиций пользователей и обеспечения бесперебойной работы.

12.1. Bridge Mechanism

12.1.1. Архитектура моста

Мост между BSC и DeflationChain построен на проверенной архитектуре Lock-and-Mint, используемой большинством кросс-чейн мостов. Принцип прост: при переводе на DeflationChain токены на BSC блокируются в контракте-хранилище, а эквивалентное количество нативных DEF минтится на DeflationChain. При обратном переводе DEF сжигаются на DeflationChain, и заблокированные токены разблокируются на BSC.

Безопасность моста обеспечивается сетью релейеров — независимых операторов, которые наблюдают за событиями на обеих цепях и подписывают attestations. Для выполнения операции требуется threshold signatures (3 из 5 релейеров должны подтвердить). Каждый релейер обязан застейкать 10,000 DEF, которые могут быть конфискованы (slashed) при обнаружении мошенничества.

Релейеры географически распределены (USA, EU, Asia, LATAM, Africa) для обеспечения устойчивости к региональным сбоям и регуляторным действиям. Ротация и добавление новых релейеров контролируется governance, обеспечивая долгосрочную децентрализацию моста.

Lock-and-Mint Bridge:

12.1.2. Bridge Flow

Процесс перевода токенов между цепями оптимизирован для баланса между скоростью и безопасностью. Deposit (BSC → DeflationChain) занимает 1-2 минуты и включает минимальный risk, поскольку токены на BSC уже были в обращении. Withdrawal (DeflationChain → BSC) занимает 1-1.5 часа из-за challenge period — временного окна для fraud proofs.

Комиссия моста составляет 0.1% от суммы перевода и распределяется поровну: 0.05% сжигается (в соответствии с дефляционной моделью DEF), 0.05% идёт релейерам как вознаграждение за работу. Минимальный перевод — 10 DEF (для предотвращения spam), максимальный — 100,000 DEF на транзакцию (risk management).

Важно понимать асимметрию: deposit относительно безопасен (худший случай — токены застряли на BSC, но не потеряны), withdrawal требует большей осторожности (злонамеренный релейер может попытаться разблокировать токены без реального сжигания на DC). Поэтому withdrawal имеет challenge period.

BSC → DeflationChain (Deposit):

12.1.3. Multi-sig Security

Multi-signature security — краеугольный камень безопасности моста. Вместо доверия одному оператору, каждая операция требует согласия threshold количества независимых подписантов. В текущей конфигурации это 3 из 5 — компромисс между безопасностью (атакующему нужно скомпрометировать 3 ключа) и liveness (мост работает даже если 2 релейера offline).

BridgeLockVault контракт на BSC — критическая точка безопасности, хранящая все заблокированные DEF. Контракт реализует стандартные защиты: replay protection через nonce counter, проверку уникальности подписей (один релейер = один голос), rate limiting через daily limits. Эти меры ограничивают ущерб даже в случае частичной компрометации.

Примечательно, что контракт не хранит приватные ключи — только адреса авторизованных подписантов. Ключи хранятся у релейеров в HSM (Hardware Security Modules) или холодных кошельках, физически распределённых по разным локациям.

contract BridgeLockVault {
    // Multi-sig configuration
    address[] public signers;           // Relayer addresses
    uint256 public threshold;           // Required signatures (3/5)
    uint256 public nonceCounter;        // Replay protection

    // Deposit tracking
    mapping(bytes32 => DepositInfo) public deposits;
    mapping(bytes32 => bool) public processedWithdrawals;

    struct DepositInfo {
        address user;
        uint256 amount;
        uint256 timestamp;
        bool processed;
    }

    /// @notice Lock DEF for bridging to DeflationChain
    function deposit(uint256 amount, address dcDestination) external {
        require(amount >= MIN_DEPOSIT, "Below minimum");
        require(amount <= MAX_DEPOSIT, "Above maximum");
        require(dailyVolume + amount <= DAILY_LIMIT, "Daily limit exceeded");

        bytes32 depositId = keccak256(abi.encodePacked(
            msg.sender,
            amount,
            dcDestination,
            block.timestamp,
            nonceCounter++
        ));

        defToken.transferFrom(msg.sender, address(this), amount);

        deposits[depositId] = DepositInfo({
            user: msg.sender,
            amount: amount,
            timestamp: block.timestamp,
            processed: false
        });

        dailyVolume += amount;

        emit Deposit(depositId, msg.sender, amount, dcDestination);
    }

    /// @notice Process withdrawal from DeflationChain
    function withdraw(
        bytes32 withdrawalId,
        address recipient,
        uint256 amount,
        bytes[] calldata signatures
    ) external {
        require(!processedWithdrawals[withdrawalId], "Already processed");
        require(signatures.length >= threshold, "Insufficient signatures");

        bytes32 message = keccak256(abi.encodePacked(
            withdrawalId,
            recipient,
            amount,
            block.chainid
        ));

        uint256 validSignatures = 0;
        address[] memory usedSigners = new address[](signatures.length);

        for (uint i = 0; i < signatures.length; i++) {
            address signer = recoverSigner(message, signatures[i]);
            require(isValidSigner(signer), "Invalid signer");
            require(!contains(usedSigners, signer), "Duplicate signer");
            usedSigners[validSignatures++] = signer;
        }

        require(validSignatures >= threshold, "Threshold not met");

        processedWithdrawals[withdrawalId] = true;
        defToken.transfer(recipient, amount);

        emit Withdrawal(withdrawalId, recipient, amount);
    }
}

12.1.4. Fraud Proof System

Fraud Proof System — последняя линия защиты моста. Даже если threshold релейеров скомпрометирован и злонамеренный withdrawal инициирован, честные участники сети имеют возможность оспорить операцию в течение challenge period (1 час).

Концепция optimistic verification: мост предполагает, что все операции честные, и выполняет их после короткой задержки. Но если кто-либо предоставит cryptographic proof мошенничества, операция отменяется, а злоумышленники наказываются. Это эффективнее, чем pessimistic verification (проверять каждую операцию on-chain), но требует активного мониторинга.

Fraud proof структурно состоит из block header DeflationChain, Merkle proof включения/исключения транзакции, state proof (при необходимости), и подписей 2/3+ валидаторов, подтверждающих header. Любой может стать challenger, застейкав bond (1000 DEF). При успешном fraud proof challenger получает 10% от оспоренной суммы плюс возврат bond. При ложном fraud proof bond конфискуется.

12.2. Перенос стейкинг-позиций

Миграция стейкинг-позиций — критическая операция, требующая особого внимания. В отличие от простых балансов, стейки содержат временные параметры (startTime, year, lastClaimed), которые определяют xMultiplier и право на дивиденды. Потеря или искажение этих параметров может привести к несправедливому перераспределению наград между стейкерами.

12.2.1. Snapshot механизм

Snapshot — атомарный снимок состояния всех стейков на определённой высоте блока BSC. Процесс разбит на пять фаз, начинающихся за 60 дней до migration date (T=0).

Pre-registration phase позволяет пользователям заранее связать свой BSC-адрес с новым DeflationChain адресом. Это не обязательно, но рекомендуется: пользователи без pre-registration смогут claim позже, но процесс займёт больше времени и потребует доказательства владения BSC-адресом.

В момент snapshot (T=0) фиксируется точное состояние: все StakePosition с их параметрами, Merkle root состояния вычисляется и публикуется. После этого BSC-контракт переходит в read-only mode — никаких новых операций, только просмотр.

Genesis блок DeflationChain включает все migrated позиции с сохранёнными параметрами. Claim period (90 дней) даёт время тем, кто не сделал pre-registration. После 90 дней unclaimed токены переходят в treasury по решению governance.

Процесс миграции стейков:

12.2.2. Сохранение параметров

Ключевой принцип миграции — полное сохранение всех параметров стейка. Это означает, что пользователь, застейкавший токены на BSC 1.5 года назад на 4-летний срок, продолжит стейкинг на DeflationChain с тем же startTime, и ему останется 2.5 года до завершения. xMultiplier будет соответствовать прошедшему времени, не сбрасываясь на начальное значение.

Структура MigratedStake содержит все оригинальные параметры плюс migration metadata: хеш оригинальной BSC-транзакции создания стейка, номер BSC-блока (для аудита), и номер DC-блока миграции. Эта информация позволяет независимо верифицировать корректность миграции.

Критически важно сохранение lastClaimed — месяца последнего claim дивидендов в формате YYYYMM. Если пользователь забрал дивиденды за декабрь 2024 на BSC, он не сможет повторно claim те же дивиденды на DeflationChain. claimedStaking и claimedDividends отслеживают накопленные выплаты для правильного расчёта будущих наград.

// Структура для миграции
struct MigratedStake {
    // Оригинальные параметры (копируются 1:1)
    uint256 initialAmount;
    uint256 amount;
    uint256 finishedAmount;
    uint256 startTime;        // Сохраняется оригинальный timestamp
    uint8 year;
    uint256 lastClaimed;      // YYYYMM format
    uint256 claimedStaking;
    uint256 claimedDividends;

    // Миграционные метаданные
    bytes32 bscTxHash;        // Оригинальная stake tx на BSC
    uint256 bscBlockNumber;   // Блок создания на BSC
    uint256 migrationBlock;   // Блок миграции на DC
}

contract StakeMigration {
    bytes32 public merkleRoot;  // Root of all BSC stakes
    mapping(address => bool) public claimed;

    /// @notice Claim migrated stake
    function claimMigratedStake(
        address bscAddress,
        MigratedStake[] calldata stakes,
        bytes calldata ownershipProof,
        bytes32[] calldata merkleProof
    ) external {
        // 1. Verify ownership of BSC address
        require(
            verifyOwnership(bscAddress, msg.sender, ownershipProof),
            "Not owner of BSC address"
        );

        // 2. Verify Merkle proof
        bytes32 leaf = keccak256(abi.encode(bscAddress, stakes));
        require(
            MerkleProof.verify(merkleProof, merkleRoot, leaf),
            "Invalid Merkle proof"
        );

        // 3. Mark as claimed
        require(!claimed[bscAddress], "Already claimed");
        claimed[bscAddress] = true;

        // 4. Create stakes on DeflationChain
        for (uint i = 0; i < stakes.length; i++) {
            _createMigratedStake(msg.sender, stakes[i]);
        }

        emit StakesMigrated(bscAddress, msg.sender, stakes.length);
    }

    function _createMigratedStake(address user, MigratedStake memory stake) internal {
        // Стейк создаётся с оригинальным startTime
        // Это означает, что оставшееся время сохраняется
        // Например: стейк на 4 года, прошло 1 год → осталось 3 года

        staking.createMigratedPosition(
            user,
            stake.amount,
            stake.year,
            stake.startTime,  // Original timestamp preserved!
            stake.lastClaimed
        );
    }
}

Пример миграции:

User: 0x1234... (BSC)
StakePosition on BSC:
- initialAmount: 10,000 DEF
- amount: 10,000 DEF
- startTime: 2023-06-15 (block 29000000)
- year: 4
- lastClaimed: 202312

Migration at: 2025-01-15

DeflationChain StakePosition:
- initialAmount: 10,000 DEF ✓ (preserved)
- amount: 10,000 DEF ✓ (preserved)
- startTime: 2023-06-15 ✓ (preserved - NOT reset!)
- year: 4 ✓ (preserved)
- lastClaimed: 202312 ✓ (preserved)

Remaining time: 4 years - 1.5 years elapsed = 2.5 years
User receives same xMultiplier benefits they earned on BSC

12.3. Период параллельной работы

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

12.3.1. Transition Timeline

Timeline рассчитан на 180 дней с постепенным ужесточением ограничений на BSC. Первые 60 дней — подготовка и announcement, активная коммуникация с сообществом. Следующие 30 дней — активная миграция после snapshot. Затем в сети BSC переходим в режимы с всё большими ограничениями: READ_ONLY (нет transfers и staking, только view), CLAIM_ONLY (только unstake finished positions и claim), EMERGENCY (аварийный вывод с пенальти), и наконец DEPRECATED (контракт заморожен).

Такая градация позволяет пользователям адаптироваться постепенно. Early adopters получают бонусы за миграцию в первую неделю. Опоздавшие теряют возможности (transfers, new stakes), но сохраняют право на свои средства. Только после 180 дней принимается governance-решение о судьбе оставшихся unclaimed средств.

12.3.2. BSC Read-Only Mode

Технически Read-Only Mode реализуется через state machine в смарт-контракте. Enum ContractState определяет возможные состояния, modifiers проверяют текущее состояние перед выполнением функций. Переходы между состояниями контролируются admin (в конечном счёте — multisig governance).

В ACTIVE состоянии все функции работают нормально. В READ_ONLY блокируются transfer и stake — пользователи могут только просматривать балансы и claim накопленные награды. CLAIM_ONLY дополнительно ограничивает staking операции, оставляя только возможность забрать finished stakes. EMERGENCY позволяет аварийный unstake с пенальти (для пользователей, пропустивших все дедлайны). DEPRECATED полностью замораживает контракт.

Важная деталь: modifiers проверяют состояние, но не изменяют его. Это предотвращает reentrancy-подобные атаки, где атакующий мог бы попытаться изменить состояние во время выполнения функции. State transitions выполняются только через dedicated admin functions с соответствующими access controls.

contract DeflationCoinBSC {
    enum ContractState { ACTIVE, READ_ONLY, CLAIM_ONLY, EMERGENCY, DEPRECATED }

    ContractState public currentState;
    uint256 public stateChangeBlock;

    modifier whenActive() {
        require(currentState == ContractState.ACTIVE, "Not active");
        _;
    }

    modifier whenClaimable() {
        require(
            currentState == ContractState.ACTIVE ||
            currentState == ContractState.READ_ONLY ||
            currentState == ContractState.CLAIM_ONLY,
            "Claims disabled"
        );
        _;
    }

    /// @notice Admin transitions to READ_ONLY after snapshot
    function transitionToReadOnly() external onlyAdmin {
        require(currentState == ContractState.ACTIVE, "Invalid transition");
        currentState = ContractState.READ_ONLY;
        stateChangeBlock = block.number;
        emit StateTransition(ContractState.READ_ONLY, block.number);
    }

    /// @notice Transfer disabled in non-active state
    function transfer(address to, uint256 amount) external whenActive returns (bool) {
        return _transfer(msg.sender, to, amount);
    }

    /// @notice Staking disabled in non-active state
    function stake(uint256 amount, uint8 years) external whenActive {
        _stake(msg.sender, amount, years);
    }

    /// @notice Claims work until EMERGENCY state
    function claimDividends(uint256 stakeId) external whenClaimable {
        _claimDividends(msg.sender, stakeId);
    }

    /// @notice Unstaking finished positions always works
    function unstakeFinished(uint256 stakeId) external whenClaimable {
        StakePosition storage pos = stakes[msg.sender][stakeId];
        require(
            block.timestamp >= pos.startTime + pos.year * 365 days,
            "Stake not finished"
        );
        _unstake(msg.sender, stakeId);
    }
}

12.3.3. Liquidity Migration

Миграция ликвидности — отдельная задача от миграции токенов. LP-токены PancakeSwap представляют долю в пуле ликвидности (DEF + paired token), и их прямой перенос невозможен. Вместо этого DeflationChain использует snapshot-based подход: LP balances фиксируются, эквивалентные позиции создаются на DeflationDEX.

Стратегия трёхэтапная. Во-первых, LP Token Conversion: snapshot всех LP holders, расчёт их доли в DEF и paired token, выпуск новых LP токенов на DeflationDEX с идентичными пропорциями. Пользователи claim через Merkle proof, как и обычные стейки.

Во-вторых, Trading Pair Establishment: genesis DeflationChain включает базовые пулы DEF/USDC и DEF/WETH с начальной ликвидностью из protocol treasury. Для price discovery используется Liquidity Bootstrapping Pool (LBP) — механизм, предотвращающий front-running и манипуляции при запуске.

В-третьих, Migration Incentives: early liquidity providers получают повышенные rewards (+50% первые 30 дней), чтобы стимулировать быструю миграцию и обеспечить достаточную ликвидность с первого дня.

13. Заключение

13.1. Резюме инноваций

DeflationChain представляет собой следующее поколение Layer-1 блокчейнов, объединяющих несколько революционных концепций в единую целостную архитектуру:

Ключевые инновации:

13.2. Сравнительный анализ

Характеристика	Ethereum	HyperLiquid	Solana	DeflationChain
Консенсус	PoS	HyperBFT	PoH + PoS	PoD
TPS	~30	200 000+	~65 000	250 000+
Время блока	12 с	< 1 с	400 мс	< 1 с
Финальность	~15 мин	< 1 с	~2 с	< 1 с
Дефляционная модель	Частично	Нет	Нет	Да (нативно)
Совместимость с EVM	Нативная	Нет	Нет	Да
Нативный трейдинг	Нет	Да	Нет	Да
AI-вычисления	Нет	Нет	Нет	Да (CCL)
Модель валидаторов	Открытая	Открытая	Открытая	Гео-ограниченная
Макс. валидаторов	~1 млн	Неограничено	~3 400	~195
Управление (Governance)	On-chain	Ограниченное	Off-chain	Гибридное

13.3. Заключительное слово

DeflationChain не просто ещё один Layer-1 блокчейн — это переосмысление того, как должна работать криптовалютная экосистема. Улучшая проверенные технологии (HyperBFT, Intel TDX) с инновационной экономической моделью, мы создаём платформу, которая:

1. Решает проблему инфляции — в отличие от большинства криптовалют, DEF математически гарантированно дефляционен
2. Обеспечивает реальную децентрализацию — географическое распределение валидаторов защищает от регуляторных атак
3. Предлагает CEX-grade производительность — без компромиссов в безопасности
4. Интегрирует AI нативно — позволяя строить новое поколение dApps

DeflationChain — это инфраструктура для следующего десятилетия децентрализованных финансов и вычислений.

Источники

1. HyperLiquid Documentation - https://hyperliquid.gitbook.io/hyperliquid-docs
2. HyperBFT Wiki - https://hyperliquid-co.gitbook.io/wiki/architecture/hyperbft
3. Cocoon Architecture (TON Decentralized AI) - https://cocoon.org/architecture
4. Cocoon GitHub - https://github.com/TelegramMessenger/cocoon
5. Intel TDX Documentation - https://www.intel.com/content/www/us/en/products/docs/accelerator-engines/trust-domain-extensions.html
6. Ethereum Yellow Paper - https://ethereum.github.io/yellowpaper/paper.pdf
7. HotStuff: BFT Consensus with Linearity and Responsiveness - ACM PODC 2019
8. EIP-1967: Standard Proxy Storage Slots - https://eips.ethereum.org/EIPS/eip-1967
9. BLS Signatures (IETF Draft) - https://datatracker.ietf.org/doc/draft-irtf-cfrg-bls-signature/
10. Verkle Trees - https://verkle.info/

🛡️ DeflationChain — Deflationary Layer-1 Blockchain with Native AI Computing