Cubrim-2 · исследовательский трек

Глобальный Адресатор

Cubrim-2 задаёт другой вопрос, чем архиватор Cubrim-1: не «как сжать байты локально», а можно ли передавать данные короткими ссылками (стремимся к разумному минимуму — порядка десятков–сотен байт) в общие, заранее распространённые структуры — Универсальные Матрицы Данных Валентовых? Если отправитель и получатель располагают одинаковой большой структурой данных, передавать можно не весь объект, а инструкцию по выбору и сборке нужных фрагментов. Эта страница — живой журнал трека: список гипотез и каждый статус ниже приходят напрямую из исследовательской базы данных — здесь ничего не захардкожено и не приукрашено.

Честное ограничение — прежде всего

Фиксированный короткий код различает лишь конечное число состояний, а пространство возможных файлов растёт экспоненциально с длиной — поэтому один короткий адрес сам по себе не может однозначно обозначать каждую длинную последовательность. Адрес имеет смысл только вместе с каталогом, где объект уже находится. И любой честный результат обязан учитывать полную стоимость: адреса, метаданные, остаток — и саму общую матрицу, которая окупается только при амортизации по многим файлам и устройствам. Поэтому Cubrim-2 не обещает «сжать любой файл в 16 байт». Трек картирует, где глобальная адресация действительно выигрывает у локального сжатия, — и так же открыто фиксирует, где она структурно выиграть не может.

Сколько заняли бы ВСЕ возможные матрицы

Считаем в битах. N-мерный куб — это визуальное представление последовательности бит: куб 4×4×4 — это 64 бита, разложенные в трёх измерениях. Размерность (1D/2D/3D/4D) — способ разложить те же биты, а не другое их количество. Поэтому число всех возможных матриц длины B бит равно 2^B и зависит только от B: у 1D-строки в 64 бита и куба 4×4×4 одинаковые 2^64 ≈ 1.8×10^19 состояний.

B, бит куб-пример всех возможных = 2^B хранить все (байт) влезает в 20 000×1 ТБ?
8 2×2×2 2.56×10² 2.56×10² B да
27 3×3×3 1.34×10⁸ 4.53×10⁸ B да
51 —(порог/threshold) 2.25×10¹⁵ 1.44×10¹⁶ B да
64 4×4×4 1.84×10¹⁹ 1.48×10²⁰ B нет
125 5×5×5 4.25×10³⁷ 6.65×10³⁸ B нет
256 4×4×4×4 (4D) 1.16×10⁷⁷ 3.71×10⁷⁸ B нет
1000 10×10×10 1.07×10³⁰¹ 1.34×10³⁰³ B нет
4096 8×8×8×8 (4D) 1.04×10¹²³³ 5.35×10¹²³⁵ B нет

Ориентир ёмкости: 20 000 дисков по 1 ТБ = 2×10^16 байт = 1.6×10^17 бит. Порог полного перечисления — B = 51 бит: это последняя длина, при которой все 2^B матриц (вместе с содержимым, 2^B×B бит = 1.44×10^16 байт) ещё помещаются; при B = 52 — уже нет (2.93×10^16 байт). Куб 4×4×4 (64 бита): одни только 64-битные адреса всех 2^64 матриц заняли бы 1.48×10^20 байт ≈ 147.6 ЭБ — на четыре порядка больше нашего ориентира. При B = 256 матриц 1.16×10^77 — ещё чуть меньше числа атомов видимой Вселенной (~10^80); граница «больше, чем атомов» проходит на B ≈ 266. Дальше — сверхэкспоненциальный рост без каких-либо шансов на физическое хранение.

Честный вывод: «все возможные матрицы» перечислить нельзя — 2^B расходится сверхэкспоненциально уже на длинах меньше одного машинного слова. Поэтому Адресатор хранит не все возможные, а только РЕАЛЬНО ВСТРЕЧЕННЫЕ уникальные блоки (CAS/дедупликация): их число ограничено объёмом реальных данных и подчиняется измеренным законам трека — 89.9% блоков в некурируемой матрице встречаются ровно один раз (AH-19), а честные 16–64 байта на объект возможны только при точном совпадении с каталогом (AH-05). Это то же фундаментальное ограничение, что и в блоке выше: адрес имеет смысл только вместе с каталогом, где объект уже находится.

Про размерность: 2^B от неё не зависит, но размерность меняет то, какие биты попадают в один куб при нарезке РЕАЛЬНЫХ данных — а значит, сколько уникальных кубов встретится на практике. Это измеряется сканом (часть B эксперимента), а не формулой.

Формулы: число матриц = 2^B; хранить содержимое = 2^B × B бит; ординальный адрес одной матрицы = B бит (2^B состояний). Все числа посчитаны точной целочисленной арифметикой (python), не оценками.

Сколько места нужно под РЕАЛЬНО встреченные матрицы (скан-эксперимент)

Реальный КРОСС-ДЕВАЙС корпус 13.48 ГБ (union трёх хостов: arcana-devs 9.06 + arcana-www 3.38 + arcana-prod 1.04 ГБ; хосты обменивались только хэшами кубов) нарезан на кубы по B = 4096 бит (512 байт) в четырёх раскладках одной и той же длины: 1D-строка 4096, 2D 64×64, 3D 16×16×16, 4D 8×8×8×8. Раскладка группирует РАЗНЫЕ биты файла в один куб (страйдовое тайлинг при ширине строки 4096 байт), поэтому число уникальных кубов на реальных данных различается — хотя число возможных (2^4096) одинаково.

раскладка кубов в скане уникальных % уникальных кросс-хостовое перекрытие (кубов) хранить уникальные
1D 4096 25 890 520 14 965 607 57.80% 1 847 617 7.14 GiB
2D 64×64 19 368 448 12 077 059 62.35% 1 260 924 5.76 GiB
3D 16×16×16 13 959 168 8 020 728 57.46% 943 354 3.82 GiB
4D 8×8×8×8 10 518 528 5 578 363 53.03% 768 085 2.66 GiB

Насыщения НЕТ: число уникальных кубов растёт почти линейно до самого конца скана (кривая на devs-срезе: 1D 10.9 млн уникальных на 7.3 ГБ → 12.3 млн на 8.3 ГБ) — реальные данные на этой длине куба почти не «заканчиваются». На devs-срезе 72–82% уникальных кубов встретились ровно один раз — то же измеренное правило, что и AH-19 (89.9% на CDC-чанках): некурируемая матрица — в основном мёртвый вес. Кросс-хостовое перекрытие реально (0.77–1.85 млн кубов делятся между хостами), и именно оно снижает долю уникальных union-корпуса до 53–62%.

Диски под сам скан: 2.7–7.1 ГиБ уникальных матриц на 13.48 ГБ кросс-девайс данных — доли одного 1 ТБ-диска. Экстраполяция на мировой объём хранимых данных (порядка 10 ЗБ = 10^22 байт; оценка порядка величины по отчётам IDC Global DataSphere): при измеренной доле уникальных 53–62% на кросс-девайс корпусе и ОТСУТСТВИИ насыщения матрицы займут ~5.3–6.2 ЗБ — миллиарды 1 ТБ-дисков, то есть тот же порядок, что и сами данные. ЭКСТРАПОЛЯЦИЯ ЛИНЕЙНАЯ И ПОМЕЧЕНА КАК ДОПУЩЕНИЕ: состав мирового корпуса иной, насыщение на больших объёмах не исключено, но в скане не наблюдалось.

Выводы: (1) хранить даже только ВСТРЕЧЕННЫЕ матрицы в мировом масштабе — порядок самих данных: выигрыш Адресатора живёт не в «складе всех кубов», а в дедупликации повторной части (38–47% на union-корпусе) и курировании r≥2 (AH-19); (2) оптимальная раскладка по критерию «меньше уникальных» — 4D (53.0% уникальных против 62.4% у 2D на union-корпусе) — многомерная группировка действительно собирает повторяющиеся биты чаще, разница умеренная (~6–9 пп); (3) сравнение честное с оговоркой: раскладки требуют разного выравнивания (2D — блоки 256 КБ, 4D — 2 МБ), поэтому покрытие корпуса различается — числа даны по покрытой каждой раскладкой части.

Скрипты: probe_matrix_scan.py + matrix_scan_dump.py (страйды в шапке; кросс-девайс union через обмен только хэшами, MTX-scan-crossdevice-v1); хэш кубов blake2b-96; кривая насыщения — чекпоинты каждые 500 МБ; все числа измерены, экстраполяция помечена.

Волна 1 — исследование завершено

Deep-research волны 1 завершён: каждая из 24 гипотез несёт реальный измеренный вердикт (charged-учёт полной стоимости, falsification-тест прогнан, скрипт+SHA в карточке). GO означает «механизм работает и измерен», NO-GO — «закрыто измерением или строгой арифметикой». Предсказанные рычаги остаются предсказаниями и помечены; измеренные числа — в каждой карточке ниже.

NO-GO · 9 GO · 15
общий контекст (словарь / фрагменты) · 4 identity-дедупликация — ссылка ≪ payload при точном совпадении · 3 структурно не может выиграть (граница) · 4 учёт стоимости инфраструктуры · 10 ближайшее совпадение + дельта · 3

Сформировано: 2026-08-29T00:14:45Z · db:addressor_hypotheses

Гипотезы · 24

Страница 8 / 12

AH-15 GO W1 · 2026-07-13

Near-match адрес + дельта (rsync-родня)

Если адрес указывает ближайший фрагмент матрицы и передаётся только дельта, то net-байты на версионированных данных упадут до address+delta << full, потому что соседние версии близки по содержимому.

Класс данных (Z)
код, документы, бэкап-цепочки
Адресная цель
32 Б
Предсказанный рычаг
крупный (rsync-практика, внешняя ссылка)
Категория потолка
ближайшее совпадение + дельта
Механизм
малые дельты между версиями; rolling-hash поиск ближайшего
Тест фальсификации
charged: address+delta+доля каталога vs локальный zstd-19 со словарём на multiversion; не бьёт -> NO-GO
Полная стоимость (total_cost)
address: 32 B ближайшего фрагмента · metadata: инструкции применения дельты · residual: сама дельта · amortized: rolling-hash индекс по ВСЕЙ матрице — тяжёлая каталожная статья.
Вердикт пробы
GO — вердикт устойчив под ЧЕСТНЫМ сильным баром zstd --ultra -22 (+словарь): charged-дельта 0.0338-0.0358 против бара 0.1409-0.3048 — лучше в 4.2-8.5 раза, выигрыш во всех децилях похожести (реальный zstd patch-from, 339 реальных git-пар). Скоуп прежний: version-chain (идентичность базы бесплатна). Классы binary-media/config не измерены (мало пар в git-истории KB); follow-up — бэкап-цепочки. ХВОСТЫ (2026-07-16): config-класс измерен на малом n=34 (честно помечено) — дельта 0.030 против plain-22 0.298, тот же порядок выигрыша, что docs/code; binary-media пар версий в истории флота НЕ СУЩЕСТВУЕТ (ассеты add-only) — этот класс по построению покрыт identity-дедупом AH-05, дельта ему не нужна. ГЛУБИНА+NEAR-MATCH (2026-07-16): (1) распад по глубине предка грациозный — 0.021/0.054/0.106/0.201 при k=1/2/4/8 (n=28, помечено): даже против базы 8 версий назад дельта в 5 раз лучше plain-22 → бэкап-цепочка может быть разреженной; (2) инкрементальный near-match ЗА пределами version-chain жив: у 5.72% байтов корпуса есть партнёр с >=20% chunk-overlap (кандидаты — бесплатный побочный продукт CAS-каталога chunk->file, НЕ сигнатуры), дельта на них 0.198 и выигрывает на 100% файлов — пре-регистрированный бар (<5% байтов) не сработал. ПОРОГ/TOP-K/КРОСС-ДЕВАЙС (2026-07-16): дельта выигрывает во ВСЕХ полосах перекрытия вплоть до 10–20% (0.666<1; полосы 20+ дают 0.12–0.44) — порог включения near-match можно опускать до ~10%, что добавляет +2.3 пп массы к 20%-порогу; top-3 конкатенация баз даёт лишь 0.971 против best-1 — сложность не окупается, одна лучшая база достаточна; кросс-девайс: 23.49% devs-байтов покрыты пулом других хостов на >=10%, из них 19.72% полностью (это уже чистый CDC-дедуп), частичная полоса ~3.8 пп — кросс-девайс near-match существует поверх дедупа, база собирается из общих чанков.
Измеренный результат
date
2026-07-15
probe
DR-delta-v1

tails

date
2026-07-16

binary_media

finding

пар версий НЕ СУЩЕСТВУЕТ во всей истории флота (40000 коммитов): бинарные ассеты add-only — не мутируют

implication
класс покрывается identity-дедупом (AH-05), дельте там нечего делать

config_smalln

pairs
34
probe
DR-delta-config-smalln-v1

caveat

малое n=34, порог ослаблен до 1КиБ

L22_plain
0.2976
D22_delta_charged
0.03
backend
zstd patch-from (RAWCONTENT dict + LDM) — реальный rsync-потомок
charges
32Б адрес базы + 64Б манифест + 2Б каталог/объект (измеренная точка AH-09)

classes

L3pairsL19_dict_barD19_delta_charged
code0.34061390.14110.0338
docs0.40662000.3050.0358
verdict
GO

scenario

version-chain: база известна по идентичности пути (истории версий/бэкап-цепочки); generic-поиск ближайшего НЕ заряжается — он закрыт AH-14

v2_ultra22

date
2026-07-15
probe
DR-delta-v2-ultra22

classes

L22_dict_barD22_delta_charged
code0.14090.0338
docs0.30480.0358
baseline
zstd --ultra -22 + словарь (директива оператора: базлайн мирового бенчмарка)

sensitivity

выигрыш во ВСЕХ децилях похожести (D19/bar = 0.10-0.21); уровень 3 vs 19 — дельта доминирует на обоих

verdict_note

GO — вердикт устойчив под ЧЕСТНЫМ сильным баром zstd --ultra -22 (+словарь): charged-дельта 0.0338-0.0358 против бара 0.1409-0.3048 — лучше в 4.2-8.5 раза, выигрыш во всех децилях похожести (реальный zstd patch-from, 339 реальных git-пар). Скоуп прежний: version-chain (идентичность базы бесплатна). Классы binary-media/config не измерены (мало пар в git-истории KB); follow-up — бэкап-цепочки. ХВОСТЫ (2026-07-16): config-класс измерен на малом n=34 (честно помечено) — дельта 0.030 против plain-22 0.298, тот же порядок выигрыша, что docs/code; binary-media пар версий в истории флота НЕ СУЩЕСТВУЕТ (ассеты add-only) — этот класс по построению покрыт identity-дедупом AH-05, дельта ему не нужна. ГЛУБИНА+NEAR-MATCH (2026-07-16): (1) распад по глубине предка грациозный — 0.021/0.054/0.106/0.201 при k=1/2/4/8 (n=28, помечено): даже против базы 8 версий назад дельта в 5 раз лучше plain-22 → бэкап-цепочка может быть разреженной; (2) инкрементальный near-match ЗА пределами version-chain жив: у 5.72% байтов корпуса есть партнёр с >=20% chunk-overlap (кандидаты — бесплатный побочный продукт CAS-каталога chunk->file, НЕ сигнатуры), дельта на них 0.198 и выигрывает на 100% файлов — пре-регистрированный бар (<5% байтов) не сработал. ПОРОГ/TOP-K/КРОСС-ДЕВАЙС (2026-07-16): дельта выигрывает во ВСЕХ полосах перекрытия вплоть до 10–20% (0.666<1; полосы 20+ дают 0.12–0.44) — порог включения near-match можно опускать до ~10%, что добавляет +2.3 пп массы к 20%-порогу; top-3 конкатенация баз даёт лишь 0.971 против best-1 — сложность не окупается, одна лучшая база достаточна; кросс-девайс: 23.49% devs-байтов покрыты пулом других хостов на >=10%, из них 19.72% полностью (это уже чистый CDC-дедуп), частичная полоса ~3.8 пп — кросс-девайс near-match существует поверх дедупа, база собирается из общих чанков.

depth_sensitivity

date
2026-07-16
probe
DR-delta-depth-v1

caveat

n=28 длинных цепочек (>=9 версий)

chains
28

delta_ratio_vs_plain22_by_depth

k1
0.021
k2
0.054
k4
0.106
k8
0.201

nearmatch_overlap

date
2026-07-16
probe
DR-nearmatch-overlap-v1 sha:f6a760bdf642

sample

bytes
765.05 MiB (802 210 346 B)
files
5 372
delta_wins_on_pct_files
100
delta_ratio_on_candidates
0.198
files_with_partner_ge20pct_bytes_pct
5.72%

overlap_sensitivity

date
2026-07-16

topk

n
61
verdict
не окупается
top3_concat_vs_best1
0.971

xdev

probe
DR-xdev-overlap-v1
partial_band_pp
3.77 pp
fully_covered_ge99.9pct
19.72%
devs_bytes_covered_by_prodwww_ge10pct
23.49%
probe
DR-overlap-sens-v1 sha:4bdf309ac992

delta_ratio_by_band

>=40
0.239
10-20
0.666
20-30
0.12
30-40
0.437

bytes_pct_with_partner_ge

10
7.32
20
5
30
4.58
40
3.97
falsification_executed
бар «не бьёт zstd-19 со словарём» НЕ сработал: дельта лучше бара в 8.5x (docs) и 4.2x (code)
AH-16 GO W1 · 2026-07-13

Класс невозможности: уже-сжатое/шифрованное уникальное — анти-гипотеза

Если применить любую адресацию к уникальным уже-сжатым/зашифрованным потокам, то total_cost будет строго >= исходника, потому что потоки неотличимы от случайных, hit-rate ~0, а адреса+манифест — чистый оверхед.

Класс данных (Z)
личные .jpg/.mp4/.zst, TLS-дампы
Адресная цель
н/п
Предсказанный рычаг
подтверждение границы: 0 whole-chunk hits (predicted)
Категория потолка
структурно не может выиграть (граница)
Механизм
статистическая случайность + отсутствие глобальных повторов
Тест фальсификации
hit-rate на корпусе уникального медиа; систематический ненулевой hit опроверг бы (не ожидается)
Полная стоимость (total_cost)
address+манифест: чистый оверхед · residual: весь файл · amortized: не окупается ничем — hit-rate ~0 по построению класса.
Вердикт пробы
GO — граница ПОДТВЕРЖДЕНА на измеренно-уникальном корпусе (follow-up исполнен): 2871 реальный медиа-файл (2.8 ГиБ), чья уникальность доказана отсутствием копий во всём флоте, дают лишь 2.75% повторной чанк-массы (остаток — общие структуры контейнеров/EXIF). Для истинно-уникального класса адресация — чистый оверхед, как и предсказано; принадлежность классу определяется ИЗМЕРЕННОЙ дубликатностью (главная находка волны 1 сохранена).
Измеренный результат
date
2026-07-14
probe
W1-unique-media-v1

by_ext

gz
92.59
jpg
93.54
mp3
100
pdf
100
jpeg
93.51
png_2.99GiB
8.82
corpus
3347 media files 3.1 GiB (exact file-dups excluded), union 3-host occurrence pool
verdict
GO

verdict_note

GO — граница ПОДТВЕРЖДЕНА на измеренно-уникальном корпусе (follow-up исполнен): 2871 реальный медиа-файл (2.8 ГиБ), чья уникальность доказана отсутствием копий во всём флоте, дают лишь 2.75% повторной чанк-массы (остаток — общие структуры контейнеров/EXIF). Для истинно-уникального класса адресация — чистый оверхед, как и предсказано; принадлежность классу определяется ИЗМЕРЕННОЙ дубликатностью (главная находка волны 1 сохранена).

verified_unique

date
2026-07-15
bytes
2.61 GiB (2 805 221 650 B)
class
медиа с fleet-wide whole-file occurrence == 1 (уникальность ИЗМЕРЕНА, не по типу)
files
2 871
probe
DR-verified-unique-v1
repeated_chunk_mass_pct
2.752%
repeated_chunk_mass_pct
12.04%

Страница 8 / 12

Где Адресатор не может выиграть у локального сжатия

Волна 1 фиксирует шесть границ — явными анти-гипотезами и no-win-зонами: уникальные высокоэнтропийные данные (личные медиа, шифрованные потоки — глобально ничего не повторяется); мелкие уникальные файлы ниже точки инверсии (постоянные издержки каталога превышают любую экономию); математически генерируемые матрицы (адрес в исчерпывающий или случайный пул стоит не меньше самого содержимого); байтовая гистограмма или хэш как носитель данных (порядок теряется, а его восстановление стоит энтропию файла); long-tail-контент, запрашиваемый примерно один раз (первая передача не окупается); и фрагментные схемы, чей выигрыш вырождается в то, что уже даёт общий словарь. Крошечная ссылка фиксированного размера (десятки байт) на объект честно достижима только при точном совпадении с каталогом, где объект уже хранится; во всех остальных случаях критерий выигрыша один — ссылка со всеми учтёнными издержками должна оставаться много меньше заменяемых данных: размер ссылки — метрика для минимизации, а не жёсткий порог.