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

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

Фиксированный короткий код различает лишь конечное число состояний, а пространство возможных файлов растёт экспоненциально с длиной — поэтому один короткий адрес сам по себе не может однозначно обозначать каждую длинную последовательность. Адрес имеет смысл только вместе с каталогом, где объект уже находится. И любой честный результат обязан учитывать полную стоимость: адреса, метаданные, остаток — и саму общую матрицу, которая окупается только при амортизации по многим файлам и устройствам. Поэтому 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-28T21:16:00Z · db:addressor_hypotheses

Гипотезы · 24

Страница 1 / 12

AH-01 NO-GO W1 · 2026-07-13

Матрица-как-словарь (shared dictionary)

Если зафиксировать versioned-immutable глобальный словарь как секцию матрицы и передавать dict_id+поток со словарём, то net-байты на мелких структурированных файлах (<128 KiB) упадут vs локальный zstd, потому что малый файл не успевает выучить собственную статистику.

Класс данных (Z)

small structured files (JSON/HTML/logs/configs)

Адресная цель

н/п

Предсказанный рычаг

>=25% на smalls (предсказание), ->0 на >=4 MiB

Категория потолка

общий контекст (словарь / фрагменты)

Механизм

готовый контекст с первого байта; амортизация однократной доставки словаря

Тест фальсификации

корпус мелких файлов: выигрыш <25% или словарь не амортизируется -> NO-GO

Полная стоимость (total_cost)

address: 8 B dict_id · metadata: zstd-frame header · residual: ВЕСЬ сжатый поток (схема не ссылочная) · amortized: dict_size/N_files устройства + однократная доставка словаря на устройство.

Вердикт пробы

NO-GO по пре-регистрированному бару: реальный zstd-словарь (110 КиБ, train/test split по чётности хэша) дал 2.94 пп абсолютных / 9.95% относительных против плоского zstd-3 — далеко от предсказанных >=25%. Рычаг существует, но величина съедена силой самого локального кодека (семейство Gotcha #11); словарь остаётся полезным baseline-конкурентом для фрагментных схем.

Измеренный результат

date: 2026-07-14
probe: W1-fragments-v1b-fair

split

test_bytes: 305.87 MiB (320 725 794 B)
test_files: 59 936
train_files: 61 704

class_z

small structured files (<128 KiB, text-ish), real KB

verdict: NO-GO
dict_bytes: 110.00 KiB (112 640 B)
gain_abs_pp: 2.94 pp
gain_rel_pct: 9.95%

verdict_note

NO-GO по пре-регистрированному бару: реальный zstd-словарь (110 КиБ, train/test split по чётности хэша) дал 2.94 пп абсолютных / 9.95% относительных против плоского zstd-3 — далеко от предсказанных >=25%. Рычаг существует, но величина съедена силой самого локального кодека (семейство Gotcha #11); словарь остаётся полезным baseline-конкурентом для фрагментных схем.

L1_dict_ratio: 0.2664
L0_plain_ratio: 0.2959

AH-02 GO W1 · 2026-07-13

Матрица-как-CAS чанков (CDC)

Если представить матрицу как глобальный CAS неизменяемых CDC-чанков, то net-байты на повторно встречающемся контенте упадут до последовательности 32B хэш-ссылок, потому что получатель уже хранит чанки, а CDC устойчив к сдвигам.

Класс данных (Z)

OS-образы, пакеты, пересылаемые файлы, бэкапы

Адресная цель

32 Б

Предсказанный рычаг

hit_rate*(1-0.4%) по массе; литература enterprise 10-30x (внешняя)

Категория потолка

identity-дедупликация — ссылка ≪ payload при точном совпадении

Механизм

exact chunk dedup по каталогу; получатель хранит чанки

Тест фальсификации

chunk-hit-rate по массе на кросс-девайсной смеси; <30% -> только режим router (AH-18)

Полная стоимость (total_cost)

address: 32 B на чанк при hit · metadata: манифест файла (список чанков, длины, порядок) · residual: новые чанки целиком + их upload в матрицу · amortized: хранение CAS×время + каталог (AH-09/10) + integrity (AH-21) + первая передача каждого блока (AH-19).

Вердикт пробы

GO: chunk dup-mass 43.01% на 3-хостовом объединении (falsification-бар <30% НЕ сработал) + ИЗМЕРЕННЫЙ competitive-выигрыш charged-адресатора над локальным zstd-3 (+7.81 пп при штрафе чанк-контекста 11.6 пп). Вердикт обусловлен реалистичным составом корпуса; мульти-девайс эмулирован хэш-агрегацией (AH-23), payload не покидал хосты. MULTI-CLASS (2026-07-15): GO устойчив по всем 7 реальным классам — chunk-dup от 7% (media) до 68.4% (archives), кросс-девайсный срез 5.8–27.6%; ни один класс не опровергает рычаг. CDC-SENSITIVITY (2026-07-15): net-charged dup — плато 33.86/33.18/32.25% при среднем чанке 4/8/16 КиБ (один проход, три чанкера): мельче чанк — больше сырого дедупа (+1.1 пп), но дороже refs+каталог (+0.47 пп); рабочая точка 8 КиБ устойчива, параметр некритичен (±0.8 пп на 4-кратном диапазоне).

Измеренный результат

cdc

max: 65 536
min: 2 048
avg_chunk: 8 192

date: 2026-07-14
probe: W1-dupmass-v0

corpus

host: arcana-devs
files: 204 275
roots: ~/arcanada~/cubrim-sources~/cubr-cm-work/cubrim-code

caveat

single-host snapshot; cross-device realism pending AH-23; worktree copies inflate dup-mass

total_bytes: 7.93 GiB (8 517 809 533 B)

verdict: GO

multiclass

date: 2026-07-15
probe: DR-multiclass-v1
cross_pools: prod∪www device-external

chunk_dup_pct_by_class

	cross	intra
web	27.23	27.16
code	19.73	56.68
docs	11.53	24.26
media	6.89	7.02
other	5.82	40.98
config	16.2	52.85
archives	27.59	68.42

competitive

date: 2026-07-14
codec: zstd-3 both sides (level cancels out)
probe: W1-competitive-v1

corpus

host: arcana-devs
files: 197 910

caveat

single-host; worktree copies inflate dup-mass; cross-device pending AH-23

total_bytes: 8.11 GiB (8 709 420 841 B)

local_ratio: 0.5562

charge_terms

refs_bytes: 40.98 MiB (42 971 680 B)
catalog_bytes: 20.69 MiB (21 690 132 B)
residual_comp_bytes: 3.82 GiB (4 099 360 171 B)

verdict_note

РЕАЛЬНЫЙ competitive-выигрыш charged-адресатора над локальным сжатием на этом корпусе (+7.81 пп) несмотря на штраф чанк-контекста 11.6 пп; критерий оператора (net-байты < локальное сжатие при ссылке << payload) ВЫПОЛНЕН на single-host срезе; GO — после кросс-девайсного подтверждения (AH-23 в работе)

win_delta_pct: 7.81%
addresser_charged_ratio: 0.4781
chunk_context_penalty_pct: 11.6%

crossdevice

date: 2026-07-14
probe: W1-crossdevice-v1

union

hosts: arcana-devsarcana-prodarcana-www
total_bytes: 12.05 GiB (12 941 464 032 B)

chunk_dup_intra_pct: 26.8%
chunk_dup_total_pct: 43.01%
chunk_dup_cross_device_pct: 16.21%

charge_terms

catalog_bytes: 20.89 MiB (21 907 639 B)
addr_manifest_bytes: 40.99 MiB (42 980 416 B)

chunks_total: 934 588

verdict_note

GO: chunk dup-mass 43.01% на 3-хостовом объединении (falsification-бар <30% НЕ сработал) + ИЗМЕРЕННЫЙ competitive-выигрыш charged-адресатора над локальным zstd-3 (+7.81 пп при штрафе чанк-контекста 11.6 пп). Вердикт обусловлен реалистичным составом корпуса; мульти-девайс эмулирован хэш-агрегацией (AH-23), payload не покидал хосты. MULTI-CLASS (2026-07-15): GO устойчив по всем 7 реальным классам — chunk-dup от 7% (media) до 68.4% (archives), кросс-девайсный срез 5.8–27.6%; ни один класс не опровергает рычаг. CDC-SENSITIVITY (2026-07-15): net-charged dup — плато 33.86/33.18/32.25% при среднем чанке 4/8/16 КиБ (один проход, три чанкера): мельче чанк — больше сырого дедупа (+1.1 пп), но дороже refs+каталог (+0.47 пп); рабочая точка 8 КиБ устойчива, параметр некритичен (±0.8 пп на 4-кратном диапазоне).

chunks_unique: 638 474

cdc_sensitivity

date: 2026-07-15
probe: DR-cdc-sens-v1 sha:8cc2983c1f8f7d4e
corpus_bytes: 8.60 GiB (9 233 769 960 B)

gross_vs_overhead

4KiB: 34.911.052
8KiB: 33.770.584
16KiB: 32.610.353

net_charged_dup_pct

4KiB: 33.86%
8KiB: 33.18%
16KiB: 32.25%

chunk_dup_mass_pct: 28.09%
naive_stored_ratio: 0.7191
charged_stored_ratio: 0.7267

Страница 1 / 12

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

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