Темпография: от гипотезы к теории; от теории — к практике

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

Для этого нужно разобраться с двумя терминами:

1. Стеганография — “способ передачи или хранения информации с учетом сохранения в тайне самого факта такой передачи (хранения)”;
2. Криптография — “наука о методах обеспечения конфиденциальности (невозможности прочтения информации посторонним), целостности данных (невозможности незаметного изменения информации), аутентификации (проверки подлинности авторства или иных свойств объекта), шифрования (кодировка данных)”.

Таким образом, темпография совмещает способы стеганографии и криптографии, помогая каждому защитить ту информацию (данные), которые для него являются ценными в любой открытой системе: IPFS, блокчейн, DAG-решения и т.п.

Многим может показаться, что такой подход, выделения отдельной области знания, надуманный, но это лишь при первом приближении. Дело в том, что децентрализованные и/или распределенные (ДРС) системы нынешнего образца тесно связаны с автоматизацией времени.

Почему? Ответов множество, но я дам два.

Во-первых, в централизованных системах всегда прав, нет, не клиент, а сервер. Простейший пример — Oauth 2.0 авторизация: поставьте известное Google-приложение и включите вход с двойным подтверждением, на любой CEX, а потом — попробуйте поменять локальное время на смартфоне, где приложение стоит. Что получится? С большой вероятностью — не сможете войти в собственный аккаунт, потому что время с сервером будет рассинхронизировано. И дело не в часовом поясе, а именно в том, что ваше локальное время не совпадает с глобальным временем, на которое ориентируется сервер.

То есть, допустим, вы должны были, по мнению одного из “демонов” сервера, ввести 666 777, а ввели 444 333. Значит, для него вы — взломщик, а не пользователь, который все делает правильно.

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

При этом без времени обойтись совсем не получится: зайдите в любой проводник, навроде Etherscan, и сразу заметите, что время — неотъемлемая часть в процессе формирования блока. Недаром в Белой книге Биткоина об этом рассказано более чем на 3-х страницах из 10, считая приложения.

Но попробуем рассмотреть примеры, чтобы погрузиться глубже.

Timestamps

Временные метки — самое очевидное решение, которое использовал Сатоши, включив в Биткоин наработки прошлых лет. Цитирую: “метка времени показывает, что в данный момент конкретные данные существовали и потому попали в хэш блока. Каждый хэш включает в себя предыдущую метку: так выстраивается цепь, где очередное звено укрепляет все предыдущие”.

Но именно Биткоин породил первые временные аномалии, что при описанном подходе кажется странным. Правда, если не знать об еще одной особенности: “временная метка считается действительной, если она больше, чем медианная временная метка предыдущих 11 блоков, и меньше, чем время с поправкой на сеть (плюс/минус 2 часа)”.

Поэтому, хотя обычно блоки появляются (если брать их характеристику по высоте) в таком порядке: 7х ххх 0, 7х ххх 1, 7х ххх 2 и т.д., все же могут быть случаи, когда блок 7х ххх 3 появляется (точнее — фиксируется) позже по времени, чем 7х ххх 4. И не обязательно это будет связано с эгоистичным майнингом и прочим недобросовестным поведением: нет, сами ДРС закладывают это как неизбежность, пусть и не постоянную.

Поскольку все не DAG-подобные ДРС имеют основную цепь, то фактически это означает (и здесь — требуется ваше предельное внимание) что в локальном времени блокчейна временные аномалии — такая же характеристика, как магические числа, или ID-цепочки.

Но все это кажется красивым, но бессмысленным набором эмпирических данных. Что ж, попробую убедить вас в обратном.

PoH — еще один шаг. Вперед и назад

PoH — не самостоятельный алгоритм консенсуса, хотя и может быть таковым, а составная часть подобного в Solana. И именно он стал одной из причин того, что Solana так часто выходит из строя.

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

К 2022 году это привело вот к чему: “ончейн-хронометраж отстает примерно на 30 минут от настенных часов из-за более длительного, чем обычно, времени блокировки… Хотя это не влияет на производительность или сетевые операции, время, сообщаемое обозревателями блоков и децентрализованными приложениями, может не отражать время настенных часов”. К тому же это может влиять на вознаграждения.

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

Говоря языком обывателя, в Solana, как и других ДРС, можете:

1. Замедлить,
2. Остановить,
3. Ускорить,
4. Инвертировать время.

И это далеко не все векторы атак. Но темпография не только и не столько о них, сколько о защите. Поэтому — еще один пример.

Защищенные каналы

И хотя вернее будет сказать — платежные и каналы состояний, а также “оптимистичные” и zk-роллапы, а к ним добавить еще и сайдчейны и прочее, но все же предпочитаю использовать сокращенный вариант: кому надо — разберется.

Главное — понять суть подхода:

1. Мы выводим вне основную цепочку некие активы;
2. Далее “мастер ключей” (МК) — владелец такого “Канала” (еще раз — это собирательный термин) устанавливает локальное время, через специальных валидаторов или самостоятельно, которое отличается от глобального по каким-то параметрам (размер шага — не секунда, например; или порядок отсчета — обратный: пример);
3. После чего МК может добавить участников Канала, которые через ZK-механики будут производить транзакции, зная, что таковые пришли другой стороне (сторонам) Канала, но в какое именно локальное время и как оно считается — им будет не известно: для них это будет последовательность операций, зафиксированных через порядковые номера (или псевдо-время);
4. При этом любой, кто попробует взломать такой Канал, должен будет не только получить права МК, но еще и узнать работу локального времени, потому как без этого невозможен расчет по транзакциям.

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

Но возможности темпографии на этом не заканчиваются.

Что еще?

На самом деле — много всего. Перечислю несколько вариантов:

1. Нулевое, или “замерзшее” время, которое происходит, допустим, в консенсусе Tendermint при недостижении ⅔, от чего IBC в экосистеме Cosmos стал столь полезен, но подобное наблюдалось и в Avalanche, и Polygon, и BSC (BNB chain), и во многих иных системах;
2. Параллельное время, скажем, когда идет борьба за цепочку с наибольшей работой в Bitcoin, или рождаются награждаемые uncle-блоки в Ethereum;
3. Нарушение синхронности времени в системах с реализацией различных подходов шардинга…

Поэтому хотел бы обратить внимание на ключевое свойство темпографии: универсальность. Да, как и интероперабельность, темпография естественным образом вытекает из архитектуры Web 3.0 проектов, систем и протоколов, а значит — может быть использована, как во зло, так и во благо, не только на L1, но и на L0, L2 и только-только проявляющем себя L3.

Проще говоря, dApps-ы могут использовать темпографию не хуже, чем любые ДРС. Но главное — на каждом уровне она может играть свою роль. Вот ряд примеров, которые есть на сегодня, помимо перечисленных:

1. Прогнозирование среднего времени расчетной единицы за счет введения такого математического показателя, как сложность Сети, которая обратно пропорциональна ее хешрейту: и здесь важен именно момент локального прогнозирования временных рамок с заданной погрешностью (2016 блоков — применительно к Биткоину);
2. Расчет коэффициента обратимости за счет увеличения шага времени обратной конвертации активов: речь идет все о тех же каналах и особенно — роллапах, которые основываются на честной игре до выхода активов в основную цепочку;
3. Алгоритмическое обоснование доступности файла за счет пропорции обращений к таковым и времени их хранения: IPFS и SWARM работают именно на этом базисе.

Кроме того, темпография охватывает множество интересных атак, начиная с примитивных атак по времени (как подвиду атак на сторонние каналы), заканчивая сложными атаками по типу Сивиллы.

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

До!

Владимир Поповъ Menaskop, DAO Synergis