# Triad Fabric: распределённые файлы, сайты и вычисления

Исследование и проектное предложение, 25 сентября 2026 года. Это архитектура следующих этапов, а не описание уже реализованных гарантий. Числовые лимиты и критерии пилота ниже — предлагаемые параметры для проверки. Site не изменялся.

Triad может стать сетью ресурсов независимых владельцев: телефонов, компьютеров и небольших постоянно работающих узлов. Реалистичный первый продукт — **зашифрованное объектное хранилище с проверяемым восстановлением**, затем публикация статических сайтов и отдельно пакетные вычисления. Для доступности нужна постоянная часть сети; количество зарегистрированных телефонов само по себе её не заменяет. Обещание «все сайты, любые вычисления, государственные секреты» требует совершенно разных технических и организационных гарантий, которых демонстрация шифрования не даёт.

## Роли устройств и отличие от датацентра

| Ресурс | Организованный датацентр | Сеть пользовательских устройств | Решение Triad |
|---|---|---|---|
| Хранение | Управляемые диски, ремонт, резервирование | Очистка приложения, выход владельца, нехватка места | Зашифрованные неизменяемые фрагменты, проверки, запас размещений, непрерывный ремонт |
| Доступность | Оператор управляет питанием и оборудованием | Сон, разряд, выключение, меняющиеся сети | Постоянные узлы плюс добровольные мобильные копии |
| Сеть | Предсказуемее пропускная способность внутри площадки | NAT, мобильный трафик, дорогая отдача, зависимость от провайдеров | Прямые соединения где доступны, несколько ретрансляторов, квоты и учёт реального трафика |
| Вычисления | Известные CPU/GPU, память и среда | Разные архитектуры, нагрев, малая доступная память | Классы устройств и короткие независимые задания |
| Управление | Единый оператор и эксплуатационные процессы | Недоверенные владельцы и возможные ложные отчёты | Проверка результата, ограниченные полномочия, независимость операторов |

Предлагаемые классы: **browser** — участие при открытом приложении, переносимые файлы и короткие задания; **Android native** — планируемая работа с учётом заряда/сети и ограничений ОС; **iOS native** — пользовательские операции и разрешённые системой фоновые окна; **desktop/mini-PC/NAS** — длительное хранение, шлюзы, ремонт и очереди. Apple определяет момент запуска BGProcessingTask и ограничивает продолжение работы после ухода приложения в фон. Android Doze откладывает CPU, сеть и задания; фоновая служба не является универсальным разрешением обходить энергосбережение. [Apple](https://developer.apple.com/documentation/backgroundtasks/choosing-background-strategies-for-your-app), [Android](https://developer.android.com/training/monitoring-device-state/doze-standby).

В браузере требуется проверять квоты и запрашивать persistent storage. Полученное разрешение защищает от обычной политики вытеснения браузером, но пользователь всё равно может удалить данные. Origin, профиль браузера и устройство имеют значение; несколько вкладок одного Mac не являются независимыми хранилищами. [WHATWG Storage Standard](https://storage.spec.whatwg.org/).

## MVP: зашифрованный файл, восстанавливаемый из 3 фрагментов из 9

Начальный предел — 16 MiB на файл, явное согласие на выделенное место и трафик. Последовательность:

1. Клиент создаёт случайный ключ файла и шифрует содержимое проверенной реализацией AEAD; для каждого ключа соблюдается уникальность nonce. Ключ не передаётся узлам хранения.
2. Шифротекст кодируется Reed–Solomon с параметрами k=3, n=9. Получаются девять разных фрагментов, любые три восстанавливают шифротекст. Это примерно тройной объём хранения: 16 MiB превращаются примерно в 48 MiB, плюс небольшие служебные данные и округление.
3. Подписанный владельцем манифест фиксирует версию формата, алгоритмы, параметры кодирования, исходную длину, идентификаторы и хеши фрагментов, хеш шифротекста. Ключ и доверенный идентификатор владельца сохраняются отдельно; экспорт для восстановления обязателен.
4. Размещение распределяется по разным устройствам, владельцам, сетям и источникам питания. Девять ответов одного злонамеренного владельца не доказывают девять независимых мест. В пилоте используется проверенный список операторов, а не открытая регистрация как доказательство независимости.
5. При чтении клиент проверяет подпись манифеста, индексы, длины и хеши, собирает три различных корректных фрагмента, восстанавливает шифротекст и проверяет AEAD. Неверные фрагменты отбрасываются, а не участвуют в голосовании.

Это применение стандартного свойства erasure coding; работоспособность конкретной реализации надо доказать тестами. Хеш или CID без обслуживающих копий не обеспечивает сохранность. [Storj: избыточность](https://storj.dev/learn/concepts/file-redundancy), [IPFS: persistence](https://docs.ipfs.tech/concepts/persistence/).

**Точная гарантия:** если после корректного первоначального размещения остаются доступными три проверяемых различных фрагмента данного объекта, доверенный манифест и ключ, клиент восстанавливает файл. Можно потерять или получить неправильные ответы от шести из девяти держателей этого объекта. Это не гарантия работы при любых 66,6% злонамеренных участников всей сети: атакующий может контролировать все выбранные размещения, заблокировать пути или уничтожить ключ на клиенте. При семи потерянных фрагментах восстановление этой схемой невозможно. Криптография защищает целостность и содержимое, но не вынуждает чужое устройство отвечать.

## Доступность, сохранность и ремонт

Доступность — можно ли получить объект сейчас. Сохранность — не потеряны ли данные безвозвратно. Узел может быть временно недоступен, сохранив диск; различать эти случаи следует консервативно. Предлагаемый порог ремонта — шесть доступных проверенных фрагментов: восстановить размещение до девяти, пока ещё есть запас. Уже при трёх никакого запаса не остаётся. Ремонт выполняется по шифротексту без ключа расшифрования, но требует доверенного манифеста, чтения и исходящего трафика. Неограниченный ремонт от каждого таймаута сам создаст перегрузку; нужны grace period, лимит параллелизма и приоритет объектов с меньшим запасом. Storj отдельно рассматривает churn, независимость отказов и ремонт как необходимые свойства сервиса. [Storj: repair](https://storj.dev/learn/concepts/file-repair).

Иллюстрация, а не прогноз: если каждый из девяти узлов независимо доступен с вероятностью p, вероятность получить хотя бы три равна `1 − (1−p)^9 − 9p(1−p)^8 − 36p²(1−p)^7`.

| Доступность отдельного узла p | Доступность объекта 3-of-9 |
|---|---:|
| 20% | 26,1802496% |
| 50% | 91,015625% |
| 80% | 99,9686144% |

Арифметика проверена Node.js. Общая электросеть, один провайдер, один аккаунт управления или один район делают отказы зависимыми: таблица тогда не даёт обещанной оценки. Нельзя превращать измеренные 30 дней пилота в заявление об «11 девятках» сохранности. Для важных данных на ранней стадии нужна отдельная резервная копия под контролем клиента.

## Сеть и независимость операторов

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

Сигналинг, TURN, HTTP-шлюз, DNS и сервер обновления приложения — разные зависимости. Прямое P2P-соединение между всеми мобильными сетями не гарантировано: TURN предназначен для ретрансляции при невозможности прямого обмена и расходует серверный трафик. Нужны шлюзы минимум у нескольких независимых операторов и проверенный переход между ними; три процесса в одном облачном аккаунте не решают организационную зависимость. [IETF RFC 8656](https://www.rfc-editor.org/rfc/rfc8656.html).

При отсутствии физического канала между регионами Triad не создаёт его программно. Локальная сеть позволяет локальную работу; перенос файлов даёт отложенный обмен. Постоянные узлы могут соединять острова связи при восстановлении транспорта. Схема коротких сообщений store/carry/forward описана отдельно в `triad-resilience-research.md`.

## Сайты и вычисления: следующие самостоятельные сервисы

**Статические сайты:** версия сайта — неизменяемый публичный набор файлов с подписанным манифестом. Для общедоступной публикации эти файлы доступны читателям; модель приватного зашифрованного объекта требует выдачи ключа каждому разрешённому читателю. HTTP(S)-шлюзы обслуживают обычные браузеры. Каждый сайт получает отдельный origin, чтобы пользовательский JavaScript не имел доступ к ключам Triad и данным соседних сайтов; одна общая origin с разными путями не обеспечивает изоляцию. Это прямо отражено в рекомендациях IPFS по subdomain gateways. [IPFS Gateway](https://docs.ipfs.tech/concepts/ipfs-gateway/).

Подпись контента полезна лишь при проверке доверенным клиентом: вредоносный шлюз может подменить начальный HTML обычному браузеру. Поэтому управление ключами, интерфейс клиента и размещаемые сайты следует разделить по origin и цепочке обновлений. Изменяемое имя сайта требует отдельного протокола версий, обнаружения отката и разветвлений; утверждать Byzantine consensus при 2/3 враждебных участников нельзя. Динамические приложения, платежи и базы данных сначала работают на выделенных постоянных узлах с обычными резервированием, журналом и контролем доступа; хранение файлов не заменяет эти системы.

**Вычисления:** первые задания — короткие CPU/WASM-операции над открытыми или нечувствительными данными с дешёвой проверкой результата. Подходят некоторые пакетные преобразования и специализированные вычисления; конкретный первый коммерческий тип выбирается по оплачиваемому пилоту и измеренной себестоимости. Позже — небольшие модели inference, помещающиеся в память одного поддерживаемого устройства. Ускорение зависит от операторов модели и драйверов; частичный перенос на GPU способен замедлить задачу из-за обмена с CPU. Сумма телефонных TOPS не равна кластеру H100. [Google LiteRT GPU](https://developers.google.com/edge/litert/performance/gpu).

Задание получает ограниченную lease, идентификатор и лимиты памяти/времени. После таймаута допускается повторная выдача; принятие и оплата результата идемпотентны. Подпись исполнителя подтверждает автора ответа, но не правильность. Проверяемые задачи принимаются по проверке; большинство ответов не доказывает корректность при злонамеренном большинстве. Для произвольного ML дешёвая универсальная проверка отсутствует в этом проекте. WASM sandbox ограничивает код относительно хоста, но не скрывает входные данные от владельца машины, на которой они обрабатываются. [WebAssembly security](https://webassembly.org/docs/security/). Заявления о гостайне, универсальной конфиденциальности вычислений и соответствии требованиям регулируемых заказчиков требуют отдельного предметного проекта и независимой оценки.

## Масштабирование и экономика ресурсов

Вместо очереди на 40 миллионов постоянных соединений: реестр операторов и возможностей; независимые региональные планировщики; пулы по классу устройств; короткие задания и lease; неизменяемые объекты; клиентская проверка результата. Шардинг по tenant/object ID, разделение хранения метаданных и передачи файлов, ограничение rate и очередей. Проверенные постоянные операторы обеспечивают минимальную услугу; мобильные участники расширяют ёмкость и локальный кэш. Это план, а не уже реализованное масштабирование.

Полезная ёмкость оценивается по реально выделенному, доступному и оплаченному месту: для 3-of-9 верхняя оценка — физическая ёмкость / 3, затем вычитаются резерв ремонта, метаданные и неиспользуемые фрагменты. Исходящая полоса и ремонт могут ограничить её раньше диска. Бюджет включает первичную загрузку примерно 3D, чтения, ремонт, TURN/шлюзы, электричество постоянных узлов, поддержку и выплаты. Часы телефонов оплачиваются только в рамках согласованных условий; квоты трафика, работа на зарядке и возможность немедленно остановить участие обязательны как продуктовые настройки. Отдельная сценарная модель на 40 миллионов регистраций находится в `triad-compute-core/CAPACITY_MODEL.ru.md`; это не число одновременно работающих устройств.

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

## Спутники: транспорт для опорных узлов

Практический следующий шаг — несколько постоянных узлов с UPS, разными наземными провайдерами и покупаемым спутниковым резервом. В Украине такой канал предлагает, например, Kyivstar со Starlink; тариф, доступность, оборудование и действующие условия подключения надо проверять для конкретной площадки. Это уменьшает зависимость от местного кабеля, но сохраняет зависимость от спутникового оператора и питания. [Kyivstar Business](https://kyivstar.ua/business/products/starlink).

Собственный спутник — отдельная космическая программа. Официальный rideshare SpaceX начинается от $350 000 за 50 кг на SSO, дополнительная масса — $7 000/кг. Это цена запуска, а не изготовления аппарата, наземного сегмента, сети терминалов или эксплуатации. [SpaceX Rideshare](https://new.spacex.com/rideshare). Один LEO-аппарат периодически уходит из видимости; непрерывное покрытие требует соответствующего проектирования группировки и наземного сегмента. [ESA: Orbits](https://www.esa.int/Applications/Telecommunications_Integrated_Applications/Orbits). Для спектра и орбитальных ресурсов существуют процедуры международной координации через администрации; готовность купить запуск их не заменяет. [ITU](https://www.itu.int/en/mediacentre/backgrounders/Pages/Regulation-of-Satellite-Systems.aspx).

Важно не путать это со словом Satellite в архитектуре Storj: там оно обозначает службу координации, а не космический аппарат. [Storj concepts](https://storj.dev/learn).

## Путь к production и приёмка

1. **Алгоритмический прототип, тесты до реализации.** Для каждого тестового файла перебрать все 84 комбинации из трёх фрагментов из девяти и получить исходные байты. При двух корректных фрагментах — явная невозможность восстановления. Проверить повреждения, дубли индексов, смешивание объектов/версий, неверную длину, подмену манифеста, неправильный ключ, случайные входы, лимит памяти и отмену. Одна машина подтверждает алгоритм, но не независимость отказов.
2. **Реальные независимые узлы.** Девять устройств с отдельными хранилищами; разные владельцы, сети и питание. Проверить перезапуск приложения, очистку браузера, Doze/сон, NAT с принудительным relay, обрыв посередине записи, переполнение квоты, исчезновение первоначального координатора. UI различает «запись принята узлом», «проверено чтением», «объект доступен», «объект требует ремонта»; никакой receipt не доказывает будущую сохранность.
3. **Пилот хранения.** Проектная цель — 30 дней, не менее 10 000 заранее определённых попыток чтения, успех не ниже 99,5%: бюджет максимум 50 неуспехов. Успех означает восстановление правильного файла до оговорённого deadline; размер файла, положение клиента, допустимые сетевые условия и deadline фиксируются до теста. Показывать результаты каждого оператора и региона, а также общую метрику. Плановые инъекции отказов учитывать отдельно и не скрывать пользовательские сбои.
4. **Бюджет отказов.** Для 3-of-9 максимум шесть одновременно недоступных или отвергнутых фрагментов на объект; это общий бюджет для поломок, вредоносности и недоступной сети. Потеря ключа не входит в этот бюджет и требует собственного backup/recovery. Проектный тест ремонта: при шести доступных фрагментах и наличии свободных исправных узлов вернуть девять размещений за 15 минут для пилотных файлов до 16 MiB. Это проверяемая цель выбранного стенда, не будущая SLA для любой сети.
5. **Промышленная подготовка.** Версионированный протокол, безопасное обновление клиента, независимая проверка криптографии и границ доверия, fuzzing парсера, нагрузочные тесты, наблюдаемость без содержимого файлов, резерв метаданных, ограничение злоупотреблений, отзыв доступа с ясными пределами уже выданных ключей, runbook ремонта и удаления, договоры операторов. Испытать сбой целого провайдера, региона и управляющего аккаунта. Данные для платного SLA собирать на устойчивом пуле и оценивать вместе с расходами ремонта.
6. **Расширение сервиса.** Сначала статические публичные сайты на изолированных origins; затем одна оплачиваемая категория проверяемых пакетных задач; только после этого отдельные проекты динамического runtime и конфиденциальных вычислений. Увеличение числа устройств производится после доказательства пользы и себестоимости каждого класса.

Все ссылки — первичные источники, проверенные при подготовке 25.09.2026. В документе не заявлена готовность реализации, сертификаты, измеренная эксплуатационная надёжность или независимость от всех физических операторов.