Дисклеймер

Ряд моментов НЕ буду расписывать подробно. С одной стороны на целостность и полноту это не влияет, с другой — кому надо, тот точно дойдёт сам, используя все ключевые идеи, а вот со скрипт-киддисами не по пути: “пардоньте”.

Аннотация

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

С другой стороны Темпография позволяет работать с временными аномалиями самого разного уровня внутри ДРС (децентрализованных и/или распределённых систем: будь то блокчейн или DAG): что-то спрятать в том, что открыто на обозрение всеобщее, не так-то просто, согласитесь? И да, ZK-механики — хороши, но их легко понять и отследить, чего не скажешь о L2/L3-уровнях дополнительной маскировки (а она в скором времени потребуется). И, таким образом, атаки по времени сильно расширяются в своём значении: а значит? А значит у вас в руках будет новый, пока мало кому доступный, вид вооружения, который позволит объединить очень разные векторы нападений. По этой как раз причине сделал отсылки к ряду статей участников конкурса и дал небольшие комментарии-дополнения, чтобы могли оценить всю красоту такого подхода. 

Но прежде — важное разграничение:

Темпография != атаки по времени

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

И всё же — сначала совсем немного, но именно теории. 

Теория

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

1. Видео, где рассказываю на примерах истории и аналогий о том, как это работает: https://youtu.be/GDMnkgynG0I. В том числе раскрыт концепт хронокапсулы и темпоральной пчелы (развитие концепта поискового паука). 
2. Первая сводная статья по темпографии: https://clck.ru/VA7cG 
3. Вторая и более сложная к восприятию: https://clck.ru/VA7er 
4. Документ по темпоральным аномалиям: https://clck.ru/X3xnB 
5. Трилогия по (D/L)PoS-семейству:
   1. Общие тенденции: https://clck.ru/UpN48 
   2. Формализация ошибок: https://clck.ru/X5EMx 
   3. О важности транзакционной репутации: https://clck.ru/VA7NA 

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

Практика

Здесь разобью на две неравные, но важные части: во-первых, что уже есть и как это работает; во-вторых, что может быть в принципе и как юзать сей сегмент в перспективе. 

Что есть?

Первое — временные аномалии в блоках. Есть несколько ситуаций возникновения временных аномалий в ДРС: 

1. Одновременное нахождение блока пулами и разветвление основной цепочки блокчейна: фактически, если бы это было в “реальном” мире, то имели бы ветвление (части) реальности. Вот пример —  599 587. Ничего в этом страшного нет: всё описано в Белой книге Биткоина, но зато такие реперные точки можно использовать для различных ботов и интересных механик заработка. Сразу — пример: Selfish mining, он же — эгоистичный майнинг, который представляет собой такую тактику, в которой “группы майнеров вступают в сговор, чтобы увеличить свой доход”. Для Биткоина, с учётом сложности, затрат на электроэнергию и т.д. этот сценарий вероятен, но всё же не сильно, а вот для форков Биткоина и прочих PoW-монет с похожей архитектурой — да. Вкупе с атакой 51 это может стать эффективной практикой… например, если захотели сделать дамп валюты и предварительно сыграли в шорт (по классике — с плечом 100х ;). Для понимания: после халвинга 2020 года атака на BCH (bitcoin cash) обходилась всего в 9263 доллара в час: конечно, там ещё нужно учесть стоимость инфраструктуры, электричества и т.п., но это цифры в любом случае достижимые. Особенно — при игре на миллионы. Если захочется погрузиться в эгоистичный майнинг с головой, то лучше начать с первоисточника (2013 год): см. исследование. Главное, что следует вынести в рамках моей статьи, что майнеры по сути локализуют время цепочки с наибольшим количеством выполненной работы, тем самым — получают преимущество перед теми, кто следит за временем (через высоту блока) в нормальных/обычных условиях. Подробней об этом на русском языке можно почитать тут.
2. Зависание PoS-систем: всё (D/L)PoS-семейство работает на некогда доказанном тезисе о необходимом и достаточном одобрении ⅔ участников некого события (нового блока, например). Но как быть, если ⅔ не набирается? Приведу мною любимый пример: “выбор в пользу безопасности (safety) нежели доступности (availability)… что значит, если 2⁄3 голосов не набирается, консенсус становится на паузу и ждёт. Для более осведомлённых товарищей, алгоритм безопасен в условиях асинхронной коммуникации и живуч, т.е блоки создаются в условиях частичной синхронности сети”. Как говорил Д. Воробей (простите, капитан — Д. Воробей): “смекаете?”. Если производите какую-либо атаку на локализацию пользователя (например — атаку Сивиллы), то эта фича может стать багом, потому что временная блокировка основной сети и атака на пользователя есть не что иное как модификация старой доброй связки: через DDoS кладём сайт, пользователю всучиваем фишинговый и крадём у него данные. Кстати, один из участников даже описал методику подделки blockchain.com, которую тут уместно вспомнить. Если вдруг подумалось, что “пример притянут за уши”, то огорчу: в деле Steem vs. Tron было именно так. Д. Сан обладал большим стеком, но не имел нод в достаточном количестве, чтобы элементарно заапрувить форк. История закончилась созданием Hive и полным выходом из игры Steem, которая когда-то была крупнейшей децентрализованной социальной сетью. А как вам спам от китов EOS?
3. Отложенные транзакции: в каком-то смысле это — нормальная практика, хотя и рискованная. Отправил транзакцию, указал высоту блока, на которой она сработает, получил профит в виде, например, временного сейфа (такой подвид холодного хранения: хотя и тут есть нюансы). Но это для моно-блокчейнов: Bitcoin, Ethereum или даже Solana, Cardano. А как быть с ETH2, Avalanche, Cosmos, Polkadot и прочими мульти-блокчейнами, где разных ДРС скомпоновано вместе много? Давайте опять примеры: первый — когда в блокчейне №01 (Б01) привязка сделана к высоте блока №X, при этом сам блок создаётся в течение 10 секунд, а в блокчейне №02 (Б02), где блок создаётся 1 минуту, связанное событие привязано к высоте блока №Y. Теперь представим простую ситуацию: если высота блока №Х в Б01 не достигнута, то связанное событие (например, приз, зашитый в транзакцию) отправляется через связанное событие Б02 на высоте блока №Y. Как этого можно достичь с большей вероятностью? Например, если речь про PoW-системы, использовать отключение мощностей на время (сложность пересчитывается обычно дольше, чем можем падать/расти хешрейт: в Биткоине это 2016 блоков — то есть раз в две недели, усредняя, поэтому не так давно, когда все массово покидали Китай, были блоки, которые майнились не 10 минут в среднем, а 14-19, некоторые и больше 60 минут). Это, кстати, хорошая идея для мини-стартапа: (ставки на свое событие в “своём” блокчейне): какой блокчейн будет стабильно выдавать цифры, близкие к заявленным, тот и победит. Примерно как кубок конструкторов в F1. Главное, что делаем — побеждаем в будущем за счёт манипуляций с майнинг-фичами, нодами в (D/L)PoS-блокчейнах в прошлом. Ещё один пример — создание спам-каналов через LN: “если злонамеренный участник создаст множество каналов и заставит их все одновременно истечь по событию, они могут превысить ёмкость данных блока, что приведёт к истечению срока действия … Результатом этого станет массовый спам в сети Биткоина. Спам может задержать транзакции до такой”. Впрочем, последний пример стоит выделить в отдельный пункт.
4. Uncle-блоки в Ethereum: пожалуй, рассмотрю и их и завершу с эмпирикой в этом аспекте. Если не в курсе про “дядей” (uncle), “сирот” (orphan) и даже про “затхлые” (stale) блоки, то лучше всего почитать русскоязычную статью, а уже потом — пройтись по документации. Главное, что стоит вынести: Orphan + Stale в Эфире дают Uncle-блоки (UB), а значит? А значит, у нас есть две системы временных координат, которые, например, можно использовать при формировании ключей доступа через обращение к предыдущим блокам и/или для создания раскрытия условного хранилища при достижении нужного количества UB у определённого пула за заданный промежуток времени. 

Ещё раз проговорю очевидное:  “поскольку система децентрализована, и все стороны имеют возможность создать новый блок на основе какого-то более старого, ранее существовавшего блока, результирующая структура обязательно представляет собой дерево блоков… Если между узлами возникают разногласия по поводу того, какой путь от корня к листу дерева блоков является «лучшим» блокчейном, то возникает развилка (форк)”. То есть эта фича — обозначена и игнорировать её — не понимать весь потенциал подобных атак (и новых средств защиты заодно). В (D/L)PoS-семействе — аспектов для атаки даже больше: “обратите внимание, что узлы должны определить, не рассинхронизированы ли их часы с часами всех остальных на блокчейне, и в этом случае скорректировать свои системные часы… Это означает, что в определённый момент времени (блок) в системе могут сосуществовать несколько состояний: одни узлы считают, что один блок содержит канонические транзакции, другие узлы считают каноническим какой-то другой блок, потенциально содержащий радикально отличающиеся или несовместимые транзакции. Этого следует избегать любой ценой, поскольку неопределенность, которая может возникнуть, скорее всего, уничтожит доверие ко всей системе”.

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

Хронокапсулы и платёжные каналы

“Мир изменился. Я чувствую это в воде, чувствую это в земле, ощущаю в воздухе Многое из того, что было — ушло. И не осталось тех, кто помнит об этом”. В начале XXI века в моду вошли VR-бунты и борьба дронов против дронов, AR-граффити и скульптуры (например, памятник Сатоши в Киеве), снос столбов с камерами наблюдения и перенос онлайна в оффлайн (цифровая энергия, дроны, печатающие QR-код прямо в воздухе)…

Вся эта история о том, что Мета-Вселенные — не просто хайп, а новый уровень свободы, за который стоит сразиться. И вот здесь вновь на помощь приходит темпография. Как именно? Сейчас расскажу. 

Для начала нужно вспомнить, что такое Lighting Network, Optimistic, ZK-rollups и всё, что на них похоже: обобщённо — это платёжные каналы (роллапы). Не буду вдаваться в подробности различий (хотя для нас существенно, что в роллап можно добавить почти кого угодно, а вот канал обычно открывают для проверенных участников), потому как эта тема отдельная. Почитать по ней можно по ссылкам в подборке ниже. 

Главное же вот что:

1. Канал (роллап) не “подключен” к основной цепочке, если не считать транзакции создания (открытия) и закрытия. То есть он действует как полуавтономная единица, но при этом с теми же сущностями (BTC, ETH, скажем), которые есть в основной цепочке. 
2. Канал имеет свои характеристики, в том числе, временные (см. документацию). 
3. Фактически канал является такой же вложенной сущностью, как AR-скульптура, но только в рамках ДРС, а не реальности вообще. 

Как это использовать на деле? 

Во-первых, можно сделать такой канал, где время будет, например, не 01.01.2011 в момент обращения, а 7777. Когда-то локальное время использовали для взлома игр (и не важно — сетевой Shadowbane или любой на ПК) и всякого рода шароварных программ, но сейчас можно этот же приём использовать как отдельный бастион защиты. Чтобы оценить потенциал вектора, стоит вспомнить, что Oauth 2.0 авторизация и всё в её стиле завязана на время: а) нужна синхронизация вашего клиента с серверным временем; б) сами доступы имеют “период жизни”; в) часто играет роль и время создания начального токена (подробней о expires_in и работе протокола в целом — см. в описательной русскоязычной статье и документации на английском).

Но зачем нам локальное время?! 

Например, захотели рассказать нечто важное, но только тому, кто будет в точке Х (геометка), в период после блока №… в Биткоине и при этом ответит правильно на вопрос: “а который сейчас час?”. Если вернуться к аналогиям, то в “обычном” мире тоже используем разные системы исчисления: Unix-формат, например, вместо стандартного представления сс:мм:чч; или календарь Майя вместо Григорианского, или лунный, или ещё какой-то там, где идёт 5000 с чем-то год от сотворения мира. Но только всё это сложно каталогизировать и тем более — использовать для автоматической защиты, здесь же (в локальном времени каналов) речь идёт о том, что человек (на самом деле не человек — тоже):

1. Должен знать локальное время: его размерность, скорость и др. характеристики; 
2. Понимать направление движения: нулевое время, инвертированное, прямой направленности и т.д.; 
3. Наконец, он должен понимать, в какой момент локального времени хронокапсула сворачивается и как после этого будет вести себя канал: будет закрыт, заблокирован, будут убраны лишние участники т.д. 

Сразу про нулевое время: смотрели “Пятый элемент”? Там герой попался на старую удочку: посмотрел в камеру — увидел чистый коридор, а оказалось — это подставили фото к камере наблюдения. Подобных уловок в Голливуде (из продвинутых и последних примеров — “Гениальное ограбление”) хватает: суть же в том, что атака проста: надо убедить наблюдателя, что он получает картинку в режиме онлайн, а не в записи и/или с изображения. Фактически это похоже на работу при вводе неправильной пасфразы (см. ниже): ввёл не тот пароль даже при правильном seed-е и всё — видишь пустые кошельки. После этого остаётся один шаг: превратить статичный параметр (пасфразу) в динамический (локальное время). 

Очень хорошо это могут проиллюстрировать два примера:

1. Динамические меш-сети: если взять фичи 5G (прежде всего — работа на большой скорости и в достаточном радиусе в режиме точка-точка) и объединить их с описанным подходом, то получится отличная идея для того, чтобы: быстро поднимать/разворачивать локальную сеть при любых блокировках Интернета; вводить системы защиты, начиная от физического перемещения устройств, заканчивая как раз управлением через хронокапсулы в канале. Если ключ доступа сформирован через NFT (при этом — нужна будет активация минимального количества шард / фрактализованных элементов), то, например, в глобальной сети (Ethereum, допустим) этот не взаимозаменяемый токен может использоваться и дальше (как антиквариат), а вот в локальной сети канала — уже будет сожжён, как минимум, за счёт формирования иного локального времени, привязанного к новому NFT. 
2. Индивидуальный игровой мир (фильм с участием deepfake-слепка): дипфейки, XR = VR + AR + MR + RR и в целом эволюция виртуальных миров привели к тому, что с помощью токенизации можно зарабатывать на чём угодно: нарисовал шарж — продал как NFT за $1 000 000 и живёшь дальше. Утрирую. Но благодаря темпографии можно пойти дальше: смотрели “Матрицу”? Наверняка. Помните там был железнодорожник, который владел станцией, из которой даже Neo было вырваться сложно. Так вот, когда вы свой индивидуальный игровой мир защищаете через хронокапсулы, то фактически вам платят не только за вход, но и за выход. 

Это немного абстракции. Вот принципиальная схема работы:

Если прочитали до сего места внимательно, то поняли, что фактически темпография помогает нам применять техники стеганографии в открытых системах, где что-то спрятать крайне сложно. 

Представим себе ещё такой пример: у нас есть некая ZK-система, которая верифицирует отложенные транзакции по заданному алгоритму и во вне — предоставляет ответ, что данная транзакция на момент запроса уже завершена. Поскольку такая система является вероятностной, а не полностью детерминированной, то всегда возможны различные атаки на подделку результата, в том числе — завязанные на время. И здесь на помощь приходит Proof-of-History от Solana (с забавным сокращением PoH): где важно не само локальное время и/или время блока, а то, попадает ли время акцепта в заданный промежуток. 

Процитирую: “в классических распределённых системах есть два способа работы с часами. Сообщения отмечаются по времени отправителем и метка времени подписывается. Узлы отбрасывают сообщения, которые либо слишком старые, либо слишком новые. Этот расчёт основан на разнице между меткой времени и локальными часами. Второй подход заключается в том, что каждый переход состояния имеет локальный тайм-аут до истечения срока действия. Например, в Tendermint состояние preommit имеет тайм-аут в одну секунду” (для тех, кто захочет копнуть глубже — две ссылки: про Byzantine fault-tolerant time & таймстепы). Solona же работает на том основании, что “каждый производитель блока должен доказать, что он выждал достаточное количество времени, и сеть движется вперёд”. 

Отсюда получаем простой алгоритм:

1. Вы отправляете отложенную транзакцию в Блокчейне №01.
2. Одновременно замеряете время по PoH. 
3. При обращении к ZK-инструментарию происходит обращение на шаг №2: скажем, должен пройти отсчёт трёх установленных временных таков в Блокчейне №02, что равно фактически 11 блокам в Блокчейне №01. 
4. Ответ ZK  уведомляет о завершении транзакции, но при этом не знаете, в каком блокчейне и на каком блоке именно искать завершения отложенной транзакции. 
5. Далее механизм может сопоставить, была ли заспамлена сеть (например, по медианному значению Мемпула), если да, то отправитель отложенной транзакции получает уведомление и, если в течение, например, 3 новых полных таков не отзывает транзакцию, она завершается в пользу получателя; если же спама не наблюдалось, то транзакция завершается сразу. При этом проверка на заспамленность может осуществляться и на середине пути, и в онлайн-режиме, и постфактум. 

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

При этом в тактах можем поставить инвертированное время. Следующим шагом усложнения является сбор по принципу IPFS, когда итоговый хеш и есть помещённый контент с одной стороны, а с другой — это, условно — суммарный, хеш представляет собой “сумму” всех хешей распределённого хранилища (и да, это тоже своеобразный шардинг, хоть прямо об этом мало где заявляется). То есть берём и отправляем отложенную транзакцию, в Блокчейне №01, далее с разницей в заданный интервал — в Блокчейне №02 и потом с тем же интервалом в Блокчейне №3. Берём в проверочном блокчейне с PoH-консенсусом проверочные 40 тактов и за это время в первом блокчейне создастся, например, 4 блока, во втором — 240, в третьем — 10 000. Далее нужно вычитать допустимые отклонения: скажем, не больше 1 блока в Блокчейне №01, не больше 60 во втором, и не больше 100 в третьем. В итоге получим: 3+180+9900= 10 083, если итоговое отклонение будет, например, на 10% отличаться от заданного, то система сделает ожидание ещё на нужное количество блоков (например, увеличив в 2 раза, или, напротив, уменьшив). 

Такой подход позволит оптимизировать те процессы, которые сложились в высокочастотном трейдинге (арбитраже — в частности) и которые решить иначе крайне сложно, потому как дорого и долго, как ни парадоксально. В частности, если осуществляете на DEX торговлю 10 активами, то возможны разные манипуляции: от примитивных — через указание “крупных” сделок в “стакане” до разного рода снайпер-ботов при формировании пула ликвидности. В этом же подходе фактически можете принимать ставки в условиях недоверенной среды, где возможны манипуляции по скорости, а значит — времени. Это подходит для игроков, которые обладают большими запасами мощного ПО/железа, ликвидности и т.д., но не подходит для крауд-инвесторов: достаточно вспомнить “газовые войны” в Эфире в эпоху ICO или DeFi, чтобы в этом разобраться. Здесь же достаточно описанную механику совместить, скажем, с голландским или прямым аукционом и каждый получит согласно: а) очерёдности ставок; б) пропорционально взносу; в) объективный механизм работы с активом — без FOMO/FUD-эффектов. 

Ещё одним отличным примером временных аномалий можно назвать мгновенные крипто-кредиты (flash-loans), которые фактически работают в рамках одной транзакции (чаще — сделки). Это открывает множество неизвестных эффектов, как с точки зрения возможностей, так и рисков: модель простая “взять долг — купить монету — продать монету — вернуть средства”. Известный пример от AAVE: взять FL в DAI — заморозить хранилище ETH MakerDAO Vault — продать ETH за BAT — открыть хранилище BAT MakerDAO — закрыть Flash Loan в DAI. Но она и приводит к атакам: на Harvest Finance, TEND, Origin Dollar и др. Фактически за счёт банального повышения цены тех же стейблкоинов можно создать видимость выданного займа (FL), тогда как механика обращения через ZK и с использованием в качестве оракула независимой ДРС нивелирует такие атаки не хуже, чем оборачивание в NFT токенов ликвидности (LP) относительно вампирского майнинга. Нужно лишь задать условия: а) по временному такту; б) допустимым отклонениям к разным ДРС.

Но есть и другой тип атак, который можно вполне попробовать устранить таким способом: Front-Running Attacks, или атаки подстановки. Проблема в них ровно та же: в блокчейне транзакции транслируются в сеть, затем участники, назовём их Супер Узлы (майнеры, делегаты и т.п.), выбирают транзакции, проверяют их и помещают в действительный блок, который в конечном итоге добавляется в блокчейн. Транзакция становится видимой для СУ, когда она распространяется в сети, и прежде чем СУ обработает транзакцию, вредоносный узел может наблюдать за транзакцией, слушая (снифая) сеть, определить цель транзакции и создать свой собственный вредоносный запрос (транзакцию) на основе наблюдаемой: так работают снайпер-боты, киберсквоттеры на .eth и прочих p2p-доменах и многие другие. Основные проблемы возникают также из-за открытости (нет конфиденциальности транзакций), а, кроме того, СУ может произвольно упорядочивать транзакции, что превращает систему в асинхронную. Поэтому, чтобы предотвратить любой тип (вид) атаки с опережением, подходящее решение “должно устранять эти две проблемы или изменить всю структуру для предотвращения условий гонки”. Собственно, работа через временные оракулы + ZK-механики именно это и делает. 

Попробую раскрыть ещё три направления: AMM, алгоритмические стейблкоины и NFT в связке с IPFS/URL. 

Одна из главных проблем AMM, связанных со временем, — непостоянные потери (Impermanent Loss: IL): “временная потеря средств, с которой иногда сталкиваются поставщики ликвидности для AMM из-за волатильности торговой пары. Этот показатель выражается в долларах и показывает убыток относительно суммы фактического вывода, по сравнению с тем, как если бы инвестор просто хранил свои активы в холде”. Обычное решение проблемы: а) активы с низкой волатильностью; б) относительная стабильность цены актива №2 к активу №1. Но тогда теряется весь смысле DEX-торговли обычными криптовалютами. Можно попробовать автоматизировать и эти процессы: скажем, через https://balancer.fi, но это лишь наложение одного автобота на другого (AMM — по сути своей автоматизированные, через математический алгоритм, DEX-ы). Можно пойти в сторону меньшей открытости через ZK-механизм: https://zks.org/en. Но всё же именно темпография помогает решить вопрос на принципиальном уровне: во-первых, можно создать AMM на временные такты, который будет перераспределять доходность к медиане нужного актива, а не только к паре; во-вторых, можно создать ZK-роллап с доступом участников, страхующих от IL на выбранные временные такты, делая условный откат курсовой стоимости выбранной пары к медианному значению. При этом активов может быть и не два, а три и более.

Собственно, отсюда же возникает и решается вопрос об алгоритмических стейблкоинах: сейчас основная идея DAI и похожих на него вещей, в том, чтобы сжигать / эмитировать нужное количество при изменении условий. И даже несмотря на то, что обеспечение DAI через USDc достигало 60% колебания к $1 превышали 10%. На мой взгляд одна из причин этого — малый учёт влияния временных связок внутри ДРС: во-первых, система реагирует медленно при резком скачке / падении курса; во-вторых, из-за высокой цены газа и других условий объективных — возможны временные задержки. Поэтому было бы правильно базовый алгоритм таких стейблов поместить как раз в темпоральную капсулу, где временной алгоритм будет учитывать архитектуру основных активов (а они могут быть в разных сетях: у того же USDt их уже 8 и будет значительно больше), соответственно курс будет зависеть не только от эмиссии / сжигания выбранного актива / активов, но и их темпорального распределения в зависимости от нагрузки на mempool, времени “производства” блока и т.д. 

Описанные механики подводят нас к ещё одной хайповой теме: к NFT. Не так давно чувак под ником  Monsieur Personne (господин Никто) создал поддельные копии одной из самых дорогих НФТишек и записал на листке: “Пусть всегда будет… Нет никаких мер для предотвращения кражи и ненадлежащего использования таких произведений искусства”. На самом деле создание NFT и их продажа НЕ авторами — старая и известная проблема: даже если вы что-то сделали позже, прицепив к своей цифровой картине, допустим, NFT, то большой не факт, что профит не уйдёт воришке. Одно из решений предлагают такие протоколы, как Envelop (NIFTSY): а) можно создать хранилище-накопитель, куда будут поступать средства от продажи NFT, а также различные накопления; б) если случается спорная ситуация, то протокол выступает в качестве арбитража/гаранта/эскроу-агента, который может передать средства по смарт-контракту действительному владельцу. Аналогично: если вы платите за дорогую картину наличными — не факт, что вчера она не висела в “Лувре” и её забрали для вас в лучших традициях “Гудзонского ястреба”, тогда как передача в защищённые хранилища больше похоже на работу в системе хранилищ “Довода”. Причём же тут время? Созданное хранилище может (должно) содержать параметр временной блокировки, в течение которой участник соглашается на арбитраж. Таким образом, продавец обезопасит себя от “левых” сделок; покупатель — от репутационных рисков — за счёт существующей системы страхования — и т.д. Но самая главная фича — в другом: если любой цифровой аватар (ЦА) обернуть (операция wrap) сразу через подобный протокол, то любая сделка будет осуществляться не с файлом (.pdf, .jpg, etc.), не с NFT даже, а с производной сущностью — wNFT и поэтому для похищения злоумышленнику придётся развернуть хранилище, то есть все, вышеописанные, трудности встанут на его пути. Скопом. 

Наконец, ещё один возможный способ реализации темпографии — верификация баланса через транзакцию — в частном случае всё просто: есть HODL-ер, у которого есть баланс, скажем, с 2009-2010 гг. и “чистый”, намайненный некогда, биток. Он хочет подтвердить владение и отправляет средства на вновь созданный кошелёк: например, multisig. Это можно сделать и через подпись, но, поскольку в криптовалютах важен не факт владения, а распоряжения, исходящая транзакция — надёжней. Проблем нет. Но что, если вы — инвестор/трейдер/спекулянт и вам важно понимать, что при большом количестве исходящих транзакций с аккаунтов, созданных с 2009 по 2011 гг. (как и было в 2020-2021 гг. не раз) возможны сильные отклонения фиатного курса и при этом для вас существенно — в какую сторону: в рост или падение? Одно дело — если вы просто получаете аналитический отчёт и “понимаете” рынок (или делаете вид, что понимаете) чуть лучше. Другое дело, если подобные сетевые эффекты наталкивают на мысль, что со средствами на “холоде” надо что-то сделать. Или пример ещё более практичный: к вам пришли, открыли через passphrase фейковое хранилище, например, на Trezor аккаунт с 0.01 btc и вывели эти средства. Если у вас нет доступа (например, доблестные блюстители правопорядка решили организовать 48-часовое пребывание в местах интересных и не очень), то хранимые в канале и/или через отложенную транзакцию BTC должны попасть во временное хранилища, а затем, после определённого времени ожидания осуществить своп, скажем, с LTC & XRM в соотношение ⅓: ⅓ уходит в холод BTC, ⅔ — меняются в пропорции 50% на 50%. При этом на каждом шаге можно использовать уже открытый канал/роллап с функцией дополнительного входа при условии знания начальных условий: по времени, паролю входа и т.д. 

Это всё пока просто набор механик передачи средств через скрипты. Но вот вам последнее усложнение в стиле темпографии: у нас есть компьютер, на нём — виртуальная машина (хорошо бы обернуть через “Планеты” Urbit, но можно и через нечто древнее) — внутри неё локально созданный форк Эфира — внутри него — локально созданный платёжный канал. Для этого, локального, канала обёрнутый эфир (wETH — пример) будет отражать баланс некого реального эфира. При этом за счёт асинхронного выкачивания, например, с 10 кошельков, баланс в каждый момент времени может быть различным (для внешнего наблюдателя, у которого есть доступ только через локальный канал), но при этом ZK-механизм, проверяющий, скажем, от 3 до 5 кошельков одновременно из 10 возможных, понимает, что баланс таковых должен быть, например, не 100, а не больше 30. И таким образом, мы соблюдаем целостность для себя и предоставляем лишь часть данных для внешнего наблюдателя, который прошёл все бастионы защиты и оказался внутри локального канала. При этом ведь можно добавить фейковые/псевдослучайные данные. Но главное — опять время: если ETH застейкан по ETH2-подходу, то фактически у вас будет право требование на внесённые ETH и мониторинг пулов, а не конечного HODL-хранилища. Поэтому главное, что нужно делать: а) перераспределять полученные награды по заданному таймауту; б) тратить немного ETH на создание мультисиг-кошелька каждый раз, когда есть аномальные отклонения от времени доступа к локальному каналу и/или иному важному элементу описанной архитектуры. При этом возникает проблема хранения приватного ключа, поэтому ещё правильней: формирование таковых через бота, работающего на том же начале, что и AMM, но только в основе его будет лежать не курсовая разница, а темпоральная. И опять же: начальные условия кроме владельца всё равно никто не знает. Это своего рода SEED-фраза, к которой привязано сразу несколько приватных ключей, но только она: а) динамическая; б) зависит от аномалий как в локальном времени (канала), так и во вне (ДРС). 

Думаю, на этом общую часть можно и закончить. Теперь можно раскрыть аспекты недалёкого, но будущего. коротко. 

Квантовый компьютер и атаки будущего

Хотим этого или нет, но после заявлений Корпорации (не) Добра придётся снова задуматься о квантовом компьютере (КК): и, если брутфорс даже SHA-256 на нём — сказка для взрослых, то в целом атаки, в том числе — иного формата, на существующие криптографические системы допустимы. 

Фактически, блокчейн того же Биткоина имеет несколько существенных изменений (Taproot — одно из последних), а это значит, что уровень защищённости в 2009 и 2019/2021 гг. у одного и того же пользователя мог быть разным. Даже без его участия. Поэтому при условии создания КК вполне возможно потребуется как раз создание хронокапсул, которые будет защищать доступ любых не верифицированных сущностей в канал, куда помещена все сеть Биткоина до (пост) квантового форка, дабы у HODL-еров не возникло паники. И да: никто не мешает создать квантовый или даже постквантовый форк.

Если привести красочную аллегорию, то это похоже на то, как можно пройти “TimeShift”: без замедления, ускорения, инвертирования и остановки времени — наверное, возможно, но сильно сложнее в сравнении с тем, если эти фичи использовать. Тем более это касается Мета-Вселенных, которые захотят каким-то образом оградиться от внешнего мира: если глобальный распределённый компьютер, создаваемый на уровне хранилищ (Chia, Filecoin, Storj, etc.), оперативной памяти (SONM, Golem, etc.) и других элементов в купе с ОС от Urbit может дать возможность уйти от привязки к железу, то лобовые атаки на ПО — куда сложнее устранить. Впрочем, если только для входа в конкретную Мета-Вселенную не нужно будет предъявить ключи доступа, синхронизированные к локальном времени.  

Поэтому здесь решений по теме исследования возможных три:

1. Хронокапсула изначально создаётся по алгоритмам, недоступным для взлома КК: в этом ничего нового нет, разве что вместо самой сети — берём её обёртку. 
2. В случае, если КК взламывает стандартный чейн и об этом сообщают 2-3-10 (сколько нужно) независимых оракула, то происходит развёртывание нужного форка с генезис-блока и в основном блокчейне система переключается на отправку на контракт сжигания. Сценарий сложный: а) СУ должны это принять; б) КК должен не успеть захватить значимое количество ресурсов; в) и да, не все и не всегда хотят сжечь Москву (хотя и многие за МКАДом). Поэтому это, скорее, сценарий для дорого хонейпота для КК и явно не про ближайшее будущее. 
3. Можно, взять и сделать форк: другой вопрос — что темпография здесь будет ни при чём… если только вы не попробуете внедрить в сеть описанные технологии как ресурс, включаемый в момент резкого, например, увеличения хешрейта. 

В остальном КК — всё ещё красивая, но теория, которая на практике имеет больше нюансов и минусов, чем плюсов. Поэтому — перейдём лучше к обобщению.  

Незаконченный классификатор

Итак, попробую синтезировать сказанное. 

Первое — темпографию можно использовать как отражения, так и для создания атак. В качестве новых атак предложены выше:

1. Изоляция пользователя (атака Сивиллы + создание локального времени);
2. Дискредитация (D/L)PoS-систем за счёт возможностей зависания (при недоборе ⅔): атаки на создание негативной репутации; 
3. Атаки подстановки, усложнённые элементом асинхронного времени:
   1. FL-атаки; 
   2. Атаки подмены авторства NFT (связки по времени); 
   3. Атаки на AMM-механизмы и алгоритмические токены;
   4. Киберсквоттинг 2.0;
   5. Прочие; 
4. Атаки на закрытие платёжных каналов:
   1. Спам-атаки на ДРС;
   2. Атаки на сами платёжные каналы. 
5. Название атак:
   1.  fee-sniping mining  (см. также дополнительно).
   2. flash loan attack
   3. front running attack
   4. иные. 

Что касается уровней защиты, то они могут быть следующими:

1. Создание хронокапсул для отложенных транзакций. 
2. Разработка платёжных каналов с локальным временем (PoH-подход). 
3. ZK-механики + PoH-подход для устранения атак через:
   1. Арбитраж; 
   2. Газовые войны;
   3. Иные преимущества.
4. Использование временных аномалий в ДРС для развёртывания локальных форков, каналов, отправки транзакций и других операций. 
5. Иные.  

Кому станет интересно — к указанным ссылкам — ещё несколько:

1. Интересный механизм в BIP-стандартах. 
2. Пример в Биткоине. 
3. Solana и вопросы синхронизации. 
4. Вспомним ещё раз о мемпулах. 
5. И да — musthave: https://lamport.azurewebsites.net/pubs/time-clocks.pdf и https://lamport.azurewebsites.net/pubs/the-byz-generals.pdf. 

Заключение

Замкнём же временную петлю? Повторю то, с чего начал, ибо это — крайне важно:

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

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

Эти два абзаца из старой работы выше (а это — 1978 год!): всё, что сделал я — показал, что теперь, здесь-и-сейчас, это реально работает. В разных ДРС. Почему? 

“В распределённой системе важно понимать, что порядок, в котором происходят события, является частичным порядком…” Эта идея должна помочь понять основные проблемы многопоточной обработки независимо от механизмов, используемых для их решения: особенно важно, как видится, это в эпоху, когда DAG становится следующим эволюционным шагом ДРС, а (D/L)PoS-семейство консенсусов в блокчейн-решениях выходят на первое место. 

Всем, кто дошёл до конца — поклон и 

До!